アジャイルしか勝たん!時代遅れのウォーターフォールはデメリットばかり

対象読者

• ドキュメント作りに追われて肝心のコーディングに手が回らない方
• アジャイル開発がウオーターフォール開発よりも絶対的に優れている理由を知りたい方

結論

ソフトウェアをウォーターフォールで開発することには構造的な問題があり、個人の努力では改善の余地はない。

ウォーターフォール開発の対義語は「反復型開発」であり、その代表として、アジャイル開発やスクラムがある。

一般に、複数の手法がある場合、どちらにも長所と短所があって、絶対的な優劣は決められない。しかし、ウォーターフォール開発は絶対的に劣っているし間違っている。

その根拠は以下の３つの観点によって要約できる。

• 人月という間違った単位
• ソフトウェアは柔軟であり、後戻りをなくすのは非現実的かつ非効率的
• ドキュメントによる二重管理コスト

このようなデメリットがあるため、欧米ではアジャイル開発が主流となっている。にも関わらず、ウォーターフォール開発は日本のSIerにおいて現在も根強く残っている。その理由を要約すると、「顧客の金銭面の制約や開発側の金銭的な損得によってウォーターフォール開発が淘汰されないから」である。

それらを詳述する前に、まずはウォーターフォール開発の出自について説明する。

ウォーターフォール開発が生まれた歴史

1960年代後半、集積回路やCADなどの技術発展によりハードウェアが低価格化するのと同時にソフトウェアが大規模化して、開発・保守コストが上がってきた。これを受けて、ソフトウェア開発の供給が追い付かなくなることが危惧された。これをソフトウェア危機と呼ぶ。

実は、ウォーターフォール開発は1970年代に製造業の工程をパクって作られた手法である^[1]。

伝統的なモノづくりは製品の品質を職人芸に頼ってきた。しかし、それでは品質にバラつきが出るし、費用も大きいというデメリットがあった。近代工業的なやり方では、普通の労働者の集まりを組織的に利用し、標準化を行うことでこのデメリットを改善した^[2]。

職人芸(手芸的プログラミング)という属人性を排除し、仕様書に基づいて誰でも作業が行えるようにする。このような近代工業の手法をソフトウェア開発に援用し、ソフトウェア危機に立ち向かうために生まれた手法がウォーターフォール開発なのだ。

ウォーターフォール開発はハードウェア開発の猿真似

ウォーターフォール開発とは、ソフトウェア開発をフェーズごとに分割し、滝の如く後戻りなく開発を進めていく手法だ(表１)。

しかし、製造業の手法をソフトウェアに適用できるのだろうか。ソフトウェアとハードウェアは性質が異なるはずなのに、同じ手法を使うことが適切なのだろうか。ハードウェアはソフトウェアに比べて以下の性質がある。

• 物理的制約から予め使用する部品を定めるのが容易
• 製造コストが大きい

よって、ハードウェア開発は工程の見積もりがソフトウェアに比べて容易であり、手戻りコストが大きい。そういった状況に適しているのがウォーターフォール開発だったのだ。

逆に言えば、ソフトウェアはハードウェアに比べて、

• 実体がないため、どんな部品が必要なのかを見積もるのが困難
• データはタダでコピーできるため、製造コストはほぼゼロ

である。ソフトウェア開発は手戻りが容易だ(故にソフト)。

にも拘らず、ソフトウェア開発をウォーターフォールで行うのは正しいことなのだろうか。断じて否！

以下でウォーターフォール開発が間違っている点を指摘していく。

人月の神話

上述のとおり、ウォーターフォール開発においてプログラマは職人ではなく、誰でも能力に大差ない労働者であり、交換可能な人的資源と見做される。そして、１人が１カ月に生産できる仕事量の単位を「人月」という。

そんなワケあるか！ボケェ！！

もちろん製造業の実装者、たとえば工場のライン作業者も熟練度によって能力は変わってくるはずだ。しかし、プログラマの生産性の格差はその比ではない。なぜなら、プログラマの技術的選択肢は多様であるからだ。

例えば、単純な肉体労働であれば、体力がある人の方が普通の人よりも生産性は高いはずだ。しかし、その能力差は2~5倍とかその程度だろう。同じ人間なのだから。対して、技術的な要素が強い仕事においては

要件を実現する計画に落とし込んで

上記のように、

人月の神話　大人数は無理

実体がない　後戻りをなくすのは非現実的　要件定義、実装、テスト

ドキュメントの二重管理　ドキュメント修正はおろそかになることがソースコード第一だという証拠

安心安全のウォーターフォール開発？

しかし、ソフトウェア開発を発注する側(以降、「顧客」と呼ぶ)には、ウォーターフォール開発を採用したくなるような事情がある場合が多い。

企業という階層型組織では、予め固定の予算が割り当てられる。そのため、顧客は予算の範囲内でしかソフトウェア開発を発注することができない。

「アジャイル開発は良いらしい」という噂を聞いた顧客も多いはずだ。しかし、アジャイル開発は「納期までに予め指定した機能を全て提供する」ことを保証しない。そのため、固定された予算で約束された機能を提供するウォーターフォール開発の方が良さそうに見える。

しかし、ウォーターフォール開発の安心安全は神話である。実体のないソフトウェア開発の見積もりが困難であることは前述の通りだ。ウォーターフォール開発はソフトウェア開発をあたかも予測可能なように見せかけたものなのだ(詳細は後述)。

対して、アジャイル開発はソフトウェア開発が見積もり不可能だという事実を受け入れ、以下のように憶測ではなく実測を重視する(ただし開発が進むにつれて見積もりの精度は上がる)。

• 1-2週間という短期間で、
• 優先度が高い機能から実装し、
• 動作するソフトウェアを顧客に提示し、
• 顧客がそれを触って得たフィードバックから要件そのものや優先順位の見直す

小まめなフィードバックを繰り返すことでソフトウェア開発のブラックボックスが暴かれ、当初想定していたことが間違いだったことが明らかになるし、早期発見によって対応が可能だ。例えば、

• そもそもこの要件は重要ではなかった
• 他に欲しい要件が見つかった
• 思ったよりも開発が速く進み、納期が前倒しになった

このように、アジャイル開発によって予算を節約できるかもしれない。しかし、これは顧客にとってはメリットではない。予算を余らせるとむしろ来年度の予算枠が削られるリスクがある。また、予算を超過することも許されない。

このように、組織構造の力学は企業にウォーターフォール開発という虚構を選択させる。

請負開発側にとってもお得なウォーターフォール開発

ウォーターフォール開発は請負開発側にとっても魅力的だ。以下のように、開発側に実質よりも大きな売上をもたらしてくれるからだ。

• 要件が曖昧な場合、リスク係数をかけて多くの開発費を提示できる
• 顧客をだまして、実態よりも大袈裟な開発費を請求してもバレにくい

逆に過小に見積もれば、開発側は損をする。ウォーターフォール開発のPMとは、根拠が曖昧な見積もりによって利益を出そうとするギャンブラーなのだ。

さらには、ウォーターフォール開発はソフトウェアの品質を落とす(後述)。しかし、低品質であればあるほど、機能追加や変更のコストが上がって、保守費用を引き上げることができる。

しかし、不当な金額の上乗せであっても、ソフトウェアの品質が低くても、顧客は予算以内・納期通りに要件を満たしていさえすればそれで構わない。顧客も開発側もソフトウェア開発のブラックボックス性によってwin-winになれるのだ。

以上で、「アジャイル！」と叫ばれつつも、顧客や開発側の金銭的な損得によってウォーターフォール開発が生き残っていることを説明した。

しかし、変化に迅速に対応していくことで企業の競争力を高めなければ生き残れない

権威主義的なリーダーはあじ

工程の後戻りが起きないような確実性の高いプロジェクトであればウォーターフォール型開発は適しています^[3]。

要件定義という「早すぎる最適化」

要件定義とは、ソフトウェア開発をする目的を定め、それを実現するために必要となる機能(要件)を洗い出す最初の工程だ。まず、何を作らなければならないかを明確にしなければ開発は始まらないからだ。

このような考え方は、要件は前もって固定しなければならない、という誤った先入観を与えかねない、という意味で誤りだ。

しかし、何も作っていない段階で、必要な機能を漏れなく具体的に洗い出すことができるだろうか。いや、出来る訳がない。フィードバックがなく知識が乏しい状態では、重要な要件が抜けていることに気づけない。

まだ知識が足りていない状態で、最適な方法を探すことを「早すぎる最適化」と呼ぶ。何が最適なのか分からない中で捻りだした解は最適足り得ない、というだけの話だ。

ソフトウェアには形がないことも、この工程の難易度を上げている。なので、プロトタイプを作って、顧客に具体的なイメージをフィードバックし、顧客の考えを練り上げる材料にすべきだ。

要件はフィードバックループの中で発見するもの

ウォーターフォール開発でも、画面のスケッチなどをによって、簡易的なプロトタイプを顧客に示す。スケッチはとても良いやり方だと思う。こうして、要件が固まるまで顧客とコミュニケーションを繰り返すことになる。

でも、ウォーターフォール開発の原則として、要件定義が終わるまで他の工程の作業を行うことができない。なので、要件定義の先にある工程である実装というフィードバックを経ないまま、要件定義を終わらせなければならない。

しかし、要件を最も詳細に理解できるのは実装フェーズだ。結局、要件とは「こんな感じのことがしたい」というのを定めたものに過ぎず、実際にそれが実現できるかは実装を通して証明するしかない。その機能の仕組み・手順を具体的に理解しなければ、実装できないからだ。

しかも、実装を進めていく中で、よりよい機能の表現が見えてきたり、その要件はそんなに重要じゃなかったり、もっと重要な要件が見つかったりする。つまり、要件とは発見していくものなのだ。予め、要件を固定すべきではない。

故に、頻繁に成果物の途中経過をフィードバックするアジャイル開発のやり方の方が良いと思う。ウォーターフォールでは、顧客はイメージ通りのものを得られず、技術者は顧客の真の要望を空想しなければならない。お互いに不幸ではないだろうか。

権威主義的なリーダーは、フェーズを分割して、下流のプログラマに命令を下したいだけ

ドキュメントは重複によってソフトさを殺す

テスト結果をドキュメントとしてまとめる愚かさ

本記事によって、少しでもソフトウェア開発を請負で契約する企業が減り、アジャイル開発を導入しようとする方が増えればいいな。

参考

1. レガシーコードからの脱却[David Scott Bernstein]
2. 計算機科学の基礎[八村広三郎]
3. ウォーターフォール型開発はなぜ時代の潮流に合わないのか？