イテレーション単位についての考察

　アジャイル開発において、イテレーションの単位は重要です。しかしながら、そのことについて海底ある資料が見つからないので自分で書くことにしました。
　私は様々なプロジェクトで、週、日、時の三つの単位を実践してみました。その結果わかったことがあります。それは、プロジェクトの規模、ユーザーの受け入れスピード、開発側の作成スピードの三要因から適切なイテレーション単位が決まるという事です。
　昔、いくつかの不定形プロジェクトで、全てが1イテレーションになってしまったことがあります。単位は週です。これはどういうことかというと、ユーザーが要望する事柄が全て1週間で納品する状態です。このプロジェクトは、ゴールはある程度決まっていたものの、情報システムに慣れていないお客様は手探りの状態であり、慎重に確認を取りながら進める必要がありました。従って、お客様が具体的に要求を決め、その成果物を元に話し合い、次の要望を決めるという開発サイクルに自然となりました。こうなってしまうと、一度に決定する要望が少なく、何でも1週間以内に納品までできる状態になってしまったのです。
　イメージしずらいと思いますので、会話形式で状況のイメージを書きます。むろん守秘義務のため細部を書きません。

お客様「先週分の商品を検品している最中です。今のところ、大好評です。」
私「有難うございます。」
お客様「それで、次に話しを進めたいのですが、
　インドリさんはどうすればよいと思いますか？」
私「貴社におかれましては、○○業務を情報化し、
　コスト削減と利益増大を目指すのが得策かと思います。」
お客様「なるほど、○○業務ですか。
　あの辺は、検証もしやすく、効果も見やすいので、我が社としても助かります。」
私「承知いたしました。その方針で進めるとなると・・・、
　かくかくしかじかになりますが、よろしいでしょうか？」
お客様「業務手順に変更がありますか？」
私「そうですね・・・貴社の業務手順から言うと、
　○○の行程を省略し、今回開発するシステムの○○を使用するという形になります。
　操作法につきましては、既存画面のパターンを踏襲しますから、
　教育コストもあまり要らないと思います。
画面はこんな感じでいかがですか？」
ここで私は下手なGUI画面の絵をかきます。
お客様「なるほど、この画面だと今まで同じ操作感覚のようですね。
　ただ、前回と操作する人が別になりますので、大丈夫でしょうか？」
私「担当者は○○課の人ですよね？」
お客様「ええ、そうです。」
私「貴社の業務書類を拝見したところ、今回話題になっている業務手順では、
　いくつかの書類を記入するという事になっています。」
お客様「ええと、これらの書類ですか？」
私「はい。今回、それらの書類から項目を抜き出し纏めてみました。
　ですから、業務で慣れ親しんでいる形式となっているので、
　違和感を減らせると思います。」
お客様「それはいいアイデアですね。それは、いつ出来上がりますか？」
私「有難うございます。来週出来上がります。」
お客様（笑顔で）「やはり、来週ですか。
　インドリさんならばそういうと思いました。」
私「どうしてですか？」
お客様「何を頼んでも、インドリさんは、来週までには出来上がるといいますから。
　しかも、実際に作ってくるので正直言って驚いております。
　システム会社の人はみんなそうなんですか？」
私「いえ、普通のシステム会社は、人月単価で運用されているので、多分違うと思います。
　私の場合個人ですから、余計な会議も意思決定もいらず、
　今現在開発しながら打ち合わせをしておりますので、
　今現在の技術で考えられる最高スピードで開発していると思います。」
お客様「それは、すごいですね。
　X社さんから評判を伺っておりましたが、
　ここまで仕事が速いとは思いませんでした。」
私「有難うございます。
　それでは、画面のサンプルについては今日明日中に送信しますので、
　ご確認して頂きたく思います。
　気になったことがあれば、何でもおっしゃってください。
　変更が無ければ、来週には完成品を持ってきます。」
お客様「その方向でよろしくお願いいたします。」

大体こんな具合です。お客様が喜んでいるから問題がないとも考えられますが、私自身はこの状況を問題視しています。何故ならば、イテレーションの意味が全くないからです。
　アジャイル開発は、適切なイテレーションを決定し、お客様と歩調を合わせつつ開発する事が重要です。たとえお客様が喜んでいても、開発手法としては間違いです。お客様に喜んでいただけるのは前提で、今よりもっと正しく開発することを目指さなければなりません。
　そんな事情から、随分前に日単位のイテレーションを採用しています。それでも二三年前から、日単位のイテレーションでも違和感を覚えるようになりました。日単位では、ちょっと曖昧で、お客様のスケジュールを乱す場合があり得ます。私としては、お客様のスケジュールを1ミリも変えないようにしたいので、より精密で高度な開発手法を考えている最中です。私は、お客様がシステム開発の依頼前と全く変わらずに、業務を続けられることを目指しているのです。
　そういった経緯から、1イテレーション1時間のアジャイル開発を考えたのですが、結局のところ全面的に導入できない状態です。その理由を考えるために分析し、次の関係を導き出しました。アジャイル開発のスピードは、開発規模を超えない（第一の壁）。また、お客様の受け入れ態勢（第二の壁）と、開発側の製作スピード（第三の壁）が採用可能なイテレーションを決定する。

1イテレーション＝規模÷受け入れ態勢÷開発スピード。

　すなわち、プロジェクトの性質・受け入れ態勢・開発スピードの酸要因により、適切なイテレーションは決定します。ですから、毎回イテレーションの決定を行う工程が必要になります。私はこの工程を削減し、どのようなプロジェクトでも、いかなる状況下でも正しい、理想的なイテレーションを探しているのですが、残念ながら今のところ発見できていません。
　纏めます。アジャイル開発の単位である1イテレーションには、週・日・時の三単位が考えられます。イテレーションの単位は、プロジェクトの性質、受け入れ態勢、開発スピードの三要因で決定されます。残念ながら、絶対的に正しいイテレーションは発見できておらず、現状は1イテレーションの単位を毎回決定しなければなりません。この稚拙な文章が少しでも役立てば幸いです。