「役務と一括」っていう感じで
休憩 - サンフランシスコ出羽守手記(masayangの日記
また、暑い日が続く折、熱いエントリをお届けします。ちょっと疲れたｗ
まず一発目は「思う」から。
これもウォーターフォールがいろいろの失敗をした時っていう仮定の上に乗っかった話だよね。「はずだ」だし。
「はずだ」っていうのが問題だと思うのなら、ご自身の書き込みにおける「思う」の回数を勘定されたし。
「思う」のはしょうがないよｗ 統計とか調べたわけじゃなし断定できる立場にない。自分の経験から「一般的にはこのことが成り立つんじゃない？」っていう推測を説明するのに「こうなる！」って言い切る程の自信家じゃあないです。「俺はこう思うぜ」って言うしかないよ。その論理に飛躍があったり、論拠になっている事実に誤認があるならそれを指摘すればいいじゃん。
続く記述には意識して「思う」をつけてない所もある。ウォーターフォールの構造上の弱点について書いた所はかなり断定的に書いたけど、これは「本質的に否定し得ない」と論理で自分の中で決着をつけた部分です。
自分はそれなりの数のウォーターフォール開発プロジェクトに関わってきたし、それらは全部といっていいほど失敗しているわけよ。
* リスケジュール
* 追加人員投入
* 長時間労働
* バグ頻発
* 予算超過このどれか一つでもつけば、それは失敗でしょ。自分が関わってきたウォーターフォールプロジェクトは残念ながら100%失敗。
Rintaさんとはここで認識がずれていると「思う」のだけど、如何？
ここのところだけど、最初のウォーターフォールだめだめっていう７項目の記述をぱっと表層だけ見てつい熱くなってしまって書いたのが、失敗だったなと反省してます；； という事で、今回はなんでウォーターフォールがそーゆー失敗を起こすのか、その根本原因についてちょっと考えてみました。
ちょっと横道にそれるけど ウォーターフォール１００％失敗という話について
君の経験では１００％失敗かもしれないけど、私は小規模ならだいたい成功してるんだ。統計とったわけじゃないけど３０人月未満なら感覚的に３／４のプロジェクトは成功（利益がなくなるほどのオーバーランはなく、瑕疵期間を乗り切っている）してる。いちおー乳飲み子が普通免許とれちゃうぐらいまでの期間働いての感覚なので、件数はそれなりにあると思ってＯＫ。品質や財務のメトリクスを示す事はできないけどさｗ。
この業界がまだ続いているのは１００％失敗赤！じゃなくて、大規模で大失敗でも全体で平均したときビジネス的にはプラスの期待値があるってことは簡単に想像がつくじゃん。なにがなんでも１００％失敗なんだ！とは言えないよ。前も書いたけど規模のマジックがあるんだ。そこに触れずに論理を展開するのはおかしいよ。
昔の大手ベンダーなら汎用機のハードの売り上げと定期保守で最終的にペイするっていうスキームもあったと思うけど、さすがにここ１０年はハードウェアの単価も下がって食えなくなってるから、ソフトウェア開発プロジェクトだけで利益を出すスキームに転換してますよ。
失敗の原因について
７つの項目を挙げていたけど、どれも「現象」でしかないと思う。ウォーターフォールを大規模でやると、これらの問題が発生しやすくなるのは事実だけど、小規模だとやられる事は少ない。もっと根本的な構造上の弱点がウォーターフォールにはあって、そこを見つめていかないと、「そーゆー場合もある」で終わっちゃう。で、私なりに導いた答えが下。
この弱点を補う為に、リスク費っていう考えを導入したりして補っているけど、一定の効果はあるにしろ対症療法でしかない。アジャイルがウォーターフォールに対して優位なのは、この構造上の弱点を持たないスキーム（役務）になっているからだ。突き詰めて突き詰めて、最終的に残るのは回帰テストでもペアプログラミングでもない、ここのスキームの違いだと思う。一口で言うと「最初の契約で成果、金額、納期を約束するかどうか」がウォーターフォールとアジャイルの分かれ目になる。十分すぎる期間が与えられたら、アジャイルでもウォーターフォールでも最初に成果を約束してもできるとは思うけど、それは例外ということで。
小規模だとウォーターフォールでも成功しやすいのは、開発期間と規模が小さければ、変更が入るリスクが小さいから（あるいは変更があっても許容できる大きさに収まる）って理由で、説明もつくね。
５項目目の「重複冗長だらけのコード」は上のスキームとは別の所に原因があって、それはウォーターフォールがソースを凍結する文化で、アジャイルがリファクタリングする文化だから、が原因かな。上流の設計で盛り込まれる冗長さは上のスキームの問題だけど。
最終的に「大規模やれんの？」という点では「序々に実績が積みあがってきている」ということで了解。SCRUMの事例も参考になりました。
アジャイルの生産性
自分のところでは小規模ながらAgile開発とウォーターフォール開発の生産性比較をやったけど、どう考えてもAgileのほうが効率がよい。それはなぜじゃろう、と考えるとウォーターフォールのオーバーヘッドがでかすぎる、という結論しかでてこない。このあと徐々に大きな開発に適用していくけど、チームが複数になったときのチーム間の同期が鍵だろうと考えている。
Agileで作業量が減るのは他社でも同様。
http://www.agilemanagement.net/Articles/Papers/StretchingAgiletoFitCMMIL.html
→MicrosoftがAgileでCMMI Level 3を取得する時の話。従来に比べて文書作成作業が圧倒的に減ったことが報告されている。伝える努力は高くつくのだよ。
これは文書作成云々のところ以外同意。アジャイルの方が生産性が高いのは、その通りだと思う。大規模にするときの問題点もその辺にあると思う。チーム連携のモデルは階層型とネットワーク型の両方で実験して比較とかされるんだろうけど、ネットワーク型はノードが増えるとパスの量が爆発的に増えるから、大規模には耐えられないんじゃないかなーとは、思う。
ただ、文書作成云々のところは誤解がある。そこは下で説明。
伝える努力
別に間違いを犯してるとは言ってないってば。
* Rintaさんのいう「伝える努力」→膨れ上がる文書類や会議
* 後戻りが高くつくという本質→膨れ上がる要件＋最適化されない実装という性質があるから、ウォーターフォールでは作業量が増えるでしょ、ということ。
２項目目は上の節で、根本原因に触れたので、ここではパス。変化に耐えられないスキームだからおかしくなるってことでＯＫ。
で、１点目だけど、これは誤解だよ。私の言う「伝える努力」は、文字通り伝わる為の努力なんだ。１００ページの詳細設計書とかをイメージしてるんだろうけど、それは違う。１００％失敗の経験しかないからそんな想像しかできないのかもしれないけどさ。*2 伝える努力が伴えば、冗長な記述は消えて、その時必要な情報だけをタイムリーに伝えるようになる。冗長な記述なんて誰でも出来るんだよ。それを煮詰めて一発で分かる簡潔な、でも仕様を構成する必要十分な記述は外さない表現にすることに時間と努力が必要になる*3。媒体は付箋のメモかもしれないし、Ａ４一枚の図かもしれない。一通の電子メールでもいい。「成果物」は私はウォーターフォールで日ごろやっているから設計ドキュメントの事が多いけど、緊急のバグ対応なんかでは、メモ一枚でやる事もあるよ（これはウォーターフォールってスキームではないけど）。「良質なコミュニケーションの為の努力」と言い換えてもいい。
表現に使う技法は、文字通りテクニックで、それ自身は愛でもなんでもない。そのテクニックを習得して、適切な媒体で、タイムリーに使う。その行動の原動力として、愛が必要だよ！という主張です。
でも、チーム内に無関心、官僚主義、形式主義が蔓延していたら、杓子定規な、それこそ役に立たないただ長いだけのドキュメントが出来上がると思う。伝えたい情熱があっても、相手との共感がなければ、一方的なエゴでしかない（セクハラやストーキングと同じかな。それを愛とは呼ばないでしょ。）。例えば最先端の設計技法だけど、チームで知っているのは書いている一人だけ、なんてケースとか。みんなが理解しなきゃいけないなら、みんなが知っている技法を使うべきだし、チームがそれを使うべきだと思うなら、勉強会をやらなきゃいけない。無関心しか持ち合わせていないチームで、そんな事は行われないよ。
きっと引っかかっているのは「努力」なんじゃない？ アジャイルはチームを小さくすることでコミュニケーションの密度を極限まで高める力がある。チームがうまく機能している限り良質なコミュニケーションの為に「努力」なんていらない。でも、チームがうまく機能する為には、チームの中に相互理解、思いやりが必要なんだ。ケント・ベックっていう援軍もあるし、これはゆずりませんよｗ
設計ドキュメントがアジャイルでは使われないから「成果物を通じて伝える」という事を受け入れないんだろうけど、狭義に設計ドキュメントである必要はないんだ。「良質なコミュニケーション」の為に必要ということで。
