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

スポンサーリンク

DD対象読者

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

結論

私はアジャイル開発を座学し、ウォーターフォール開発の実務を経験した者に過ぎない。よって、アジャイル開発に対して過度な希望を持ち、ウォーターフォール開発を卑下するような先入観に支配されているだけかもしれない。

しかし、それを差し置いても、ウォーターフォール開発は余りにもバカげていると実感した。思考停止して慣習を模倣した愚か者がウォーターフォール開発なぞをやっているのではないか。アジャイル開発こそが理想的かつ実践的なソフトウェア開発の手法なのではないか。

そう思った根拠は以下のように要約できる。

  • ドキュメントによる多重管理

では、それぞれの理由を詳述していく。

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

ウォーターフォール開発とは、以下のようにソフトウェア開発工程を分割し、滝の如く後戻りなく工程を進めていく手法のことだ。

  1. 要件定義
  2. 設計(基本設計、詳細設計)
  3. 実装 or 製造
  4. テスト(単体テスト、結合テスト、受入テスト)
  5. リリース or 納品

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

しかし、ハードウェアの開発手法をソフトウェアに適用できるのだろうか。ソフトウェアを作るのとハードウェアを作るのは性質が異なる。ハードウェアはソフトウェアに比べて

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

よって、ハードウェア開発は、

  • 工程の見積もりが(ソフトウェアに比べて)容易であり、
  • 手戻りが許されない

そういった状況に適しているのがウォーターフォール開発だったのだ。

逆にソフトウェアは

  • 実体がなく抽象的なため、見積もりが困難であり、
  • データはタダでコピーできるため、製造コストはほぼゼロ

である。明らかにソフトウェアの性質はハードウェアとは異なる。

なのに、ハードウェア開発と同じ工程を使うのは正しいことなのだろうか。ソフトウェア開発にはソフトウェア開発に適したやり方があるのではないか。それが「アジャイル開発」だと思う訳だ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

参考

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

コメント

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