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

スポンサーリンク

対象読者

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

結論

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

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

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

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

  • 企業による制約 金銭的な損得
  • チームの士気を下げる
  • ソフトウェアの品質が下がる
  • ドキュメントによってソースコードの変更が難しくなる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

より効率的に開発が進み、予定していた金額よりも安上がりになった

アジャイル開発では、

  • 1-2週間という短期間で
  • 優先度が高い機能から実装し、
  • 動作するソフトウェアを顧客に提示する

フィードバックを繰り返すことでソフトウェアを開発していく。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

参考

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

コメント

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