見積もり
http://d.hatena.ne.jp/Rinta/20070817#p4
君の経験では１００％失敗かもしれないけど、私は小規模ならだいたい成功してるんだ。統計とったわけじゃないけど３０人月未満なら感覚的に３／４のプロジェクトは成功（利益がなくなるほどのオーバーランはなく、瑕疵期間を乗り切っている）してる。いちおー乳飲み子が普通免許とれちゃうぐらいまでの期間働いての感覚なので、件数はそれなりにあると思ってＯＫ。品質や財務のメトリクスを示す事はできないけどさｗ。
「利益がなくなるほどのオーバーランはなく、瑕疵期間を乗り切っている」というのは、自分の基準では「失敗」に分類される可能性が高いね。
この業界がまだ続いているのは１００％失敗赤！じゃなくて、大規模で大失敗でも全体で平均したときビジネス的にはプラスの期待値があるってことは簡単に想像がつくじゃん。なにがなんでも１００％失敗なんだ！とは言えないよ。前も書いたけど規模のマジックがあるんだ。そこに触れずに論理を展開するのはおかしいよ。
もちろん、開発後の運用や保守で開発時の赤を回収できるのなら開発で無理して黒字を出す必要はない。でも、納期に間に合わせるための前提として過酷な長時間労働があるのは正しい姿ではないよね。
1. ウォーターフォールプロセスでは、プロジェクト開始時点で最終的な成果と対価としての金額、構築に要する期間を確定させ、一括受託で契約する。*1
2. しかしながら、要求事項は時間の経過とともに変化する。
3. 一括受託では、最初に構築に必要なリソースを確定している為、変化に対応することが難しい。
4. 故に、要件が変化した時トラブル（開発遅延、品質悪化、コストオーバー等）が発生する。
Rintaさんと議論がかみ合ってないのは上記１の「プロジェクト開始時点」が異なっているからではなかろうか。自分のいう「プロジェクト開始時点」というのは、「何がほしいか」という要求分析の始まる段階であり、この時点では最終的な成果も金額も期間も確定しようがない。これらを確定させるための労力は要件の規模に応じて重くなっていく。でも、お客さんが期待する納期は普通は決まっているから、最終的な成果と金額が決まる頃にはプロジェクトに黄色信号が灯っている。あるいは決まらないうちにうやむやに見切り発車。これは自分が体験し、見てきた世界。そしてこれはシステムの規模が関係するのではなくて、お客さんの財布（財務状況）とお客さんのシステム部門の「力」が絡むのではないかと。Rintaさんはこのあたりで恵まれていたのかもね。
ちなみにAgileでも受託契約はできる。最初に粗い要件をきめて、大雑把な期間を提示して、それからAgileで開発を始めるというのは自分の所では普通。地元のAgile開発者が集まる会議が毎月あるのだけど、そこで聞いた限りでは、受託の割合はざっと半分くらいじゃないかな。
ちなみにAgileだからといってお客を開発に巻き込む必要はない。そうじゃなければ、アメリカから日本の開発なんて受けられないでしょ...
でも、チーム内に無関心、官僚主義、形式主義が蔓延していたら、杓子定規な、それこそ役に立たないただ長いだけのドキュメントが出来上がると思う。
これはその通り。特にISO9000とかCMMI-Level Nとかの制約をかけられた現場はその傾向が強い。そして自分の知る日本の現場はこんなのばかりなわけよ。
設計ドキュメントがアジャイルでは使われないから「成果物を通じて伝える」という事を受け入れないんだろうけど、狭義に設計ドキュメントである必要はないんだ。「良質なコミュニケーション」の為に必要ということで。
手書きのメモとか、ホワイトボードに書いた絵とかで設計思想を共有するというのは自分の現場でも実践している。それはもちろん、「良質なコミュニケーション」のため。これは否定しないよ。
「コミュニケーション」は人と人とが実時間で対話すること。文書は書いた時点で内容が確定しちゃう。でも、その場では「これで充分」と思われた文書が、後々に読む人にとって充分である保証はない。「ここ、どういう意味っすか？」と尋ねる相手がいなければ、コミュニケーションは成立しないからね。
そこを「後々読む人が誰でも理解できるように」と「思いやり」を持ち込んだ先に官僚主義・形式主義な人たちがいれば、たちまちその現場は分厚いドキュメント製作所となる。自分が「愛」とか「思いやり」とかいう言葉を現場に持ち込むのが嫌いなのは、それらの言葉で自分の行為を正当化する人たちが必ず出てくるから。Rintaさんがそうだ、といってるわけじゃないよ。念のため。
大規模
となると、大規模開発の鍵は「コミュニケーション」ということになる。「Agileはコミュニケーション依存だから大規模に向かない」というのは、「ウォーターフォールはコミュニケーション依存だから大規模に向かない」というのと大差はないと自分は考えている。でも（今年はいけなかったけど）Agile関係のカンファレンスでは大規模事例はどんどん発表されている。ポイントは
- チーム内のローテーション
- チーム間のローテーション
- チーム横断プロジェクト管理チームの存在
らしい。
「ほげほげモジュール担当」みたいに、ある人に何かをまかせっきりにするからいけないのであって、「今日のほげほげモジュール担当はＸＸさん」みたいに仕事を回覧板のように回していくことで伝える努力を強制していく。そしてその伝える努力とはチーム標準にのっとったきれいなコードを書くことに他ならない。チーム横断プロジェクト管理チームは、それらのローテーションや「きれいなコード」が徹底されているかをみていく。 これが大規模Agileのポイントということなんだけど...やってみなければわからないね。
自分のところでも開発者のローテーションや、開発者が地理的に分散した状態のAgile開発は実験途上だけど、なんとかなりそうという印象を持っている。あとは1チームから2チーム、3チームと規模を徐々に増やしていけば大規模もなんとかなるのではないかと考えている。
