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

スポンサーリンク

対象読者

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

結論

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

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

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

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

  • 顧客や開発側の金銭的な損得によってウォーターフォール開発が淘汰されない
  • チームの士気を下げる
  • ソフトウェアの品質が下がる
  • ドキュメントによってソースコードの変更が難しくなる

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

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

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

表1.ウォーターフォール開発のフェーズ
フェーズ 説明
要件定義 機能を指示する文章
設計(基本設計、詳細設計) その機能を満たすソフトウェアの青写真
実装(製造) その青写真を満たすための作業
テスト(単体・結合・受入) 機能の動作確認
リリース(納品) 本番環境でソフトウェアを利用可能にする

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

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

ハードウェアはソフトウェアに比べて以下の性質がある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェアの設計とはドキュメントではなく、ソースコードだ

要件定義の次は設計フェーズだ。しかし、ウォーターフォール開発における設計(以後、ウォーターフォール設計と書く)もイケていない。

ハードウェアの設計は図面として表され、万人に対して解釈が一意である。文章とは違って、数値は誰から見ても同じものである。図面には数値が多用されているため、解釈が一意なのだ。

対して、ウォーターフォール設計は曖昧だ。なぜなら、それは文章や図表(フローチャートなど、図面ほど具体的ではない)によってソフトウェアを表現したものに過ぎず、その”実装”方法には色んなやり方があり得るからだ。

ここでサラッと”実装”と述べた。ウォーターフォール設計では実装のことを製造やコーディングとも呼ぶ。つまり、製造業での製品はウォーターフォール開発でのソースコードに対応する。この捉え方は誤りだ。

製造業では設計に則りさえすれば、ちゃんと製品を作ることができるのは上述の通りだ。しかし、ウォーターフォール設計に従っても、しっかりした製品(ソースコード)が作られる保証はない。そういう意味で、ウォーターフォール設計は製造業における設計の役割を全うできない

もし、ハードウェア設計と同等のものがソフトウェアにあるのなら、それはソースコードに他ならない。ソースコードは解釈が一意であり、それに則って実行ファイルが生成されるからだ。製造業の製品に対応するのは実行ファイルであり、設計に対応するのはソースコードなのだ。

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

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

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

 

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

参考

  1. レガシーコードからの脱却[David Scott Bernstein]

コメント

タイトルとURLをコピーしました