ウォーターフォールは最悪の開発プロセス
まず始めに
いい加減「ウォーターフォール開発にもメリットがある」という話を見るのが嫌になったので書きます。
ただし、「アジャイル開発がいい」という結論ではありません。 あくまで「ウォーターフォールは最悪の開発プロセス」という話。
「ウォーターフォール」とは
まず、自分が最悪とまで言い切る「ウォーターフォール」が何を指しているかという話です。 それは、この記事を前提として話をします。
この記事ではウォーターフォールという言葉がどこから出てきたという話をしていますが、 自分が否定するのはこの記事における「IEEE/EIA 12207.2-1997の “Once-Through(Waterfall)"」のことです。
逆に言えば、小規模な開発における「Grand Design」や、 アジャイル開発のアンチパターンとして知られる「ミニ・ウォーターフォール」についてはこの記事では特に否定しません。
繰り返しますが、否定するのはあくまでも「小規模な開発を除く、繰り返しなしのウォーターフォール(Once-Through)」です。 それ以外を肯定するわけではないですが、議論の対象外です。
以下では、この小規模な開発を除く、繰り返しなしのウォーターフォールの話に限定します。
常に設計は必要
ソフトウェア開発には様々なプロセスがありますが、大規模なシステムでも、ちょっとしたツールでも、常に設計は必要です。 外からみたら思いつきで開発しているように見えても、頭の中で設計が行われています。 その設計を見える形にしたものが「設計書」です。
ここで「設計」はどうやって行うのか、という論点があります。
まず設計で重要なのは、不確実性を減らしていくことです。 不確実性は仕様に起因することもあれば、技術に起因することもありますが、不確実性は後のフェーズに残せば残すほどマズいです。 そのため、最も不確実性の高いものから潰していくことが大切です。
そして、技術に起因する不確実性は、技術によって解決するのが早いことが多いです。 具体的には実際にプロトタイプレベルのコーディングをしたり、画面を作ります。 例えば自分は前の会社で、次のように設計していました。
- ビジネスロジック: 「型」を使ってコードで表現
- 画面設計: HTMLで実際に画面を作って確認
そして、設計した結果を文章として設計書に残していました。 ときにはほとんど完成させてから設計書に内容を記載していました。
同じようなことをやった人はたくさんいると思います。 結果として設計書は必要でも、設計をするためには机上でなく、実際にコードを書いたほうが早い、そんなことはよくあります。
これらをまとめると、次のようになります。
- 設計で最も重要なのは、不確実性を減らしていくこと。
- 不確実性を減らす最良の方法は、最も大きい不確実性から潰していくこと。
- 最も不確実性が高いものは状況によって違い、仕様に起因することもあれば、技術に起因することもある。
- 技術に起因する不確実性は、技術によって解決するのが早いことが多い。
なぜ「ウォーターフォール」が最悪なのか。
先程の内容をまとめると、設計を進めるためには、最も大きい不確実性を減らす必要があり、 それを減らす手法は、状況に応じて変わることがあります。
自分は綿密に設計したほうがいいと判断すればまず表や文書を書きますし、 作ってみないと分からないと判断すればまず作ってみます。 結果として当初作った設計に問題がなく、そのままスムーズに行く場合もあります。 その場合は「結果として」ウォーターフォールのように見えるだけです。 これが自然な方法です。
一方で「ウォーターフォール(Once-Through)」は、「各工程が終了してから次へ進む」という前提があります。 すなわち、最も大きい不確実性を減らすための最良の方法が使えません。 なので、ウォーターフォールは正しい方法ではありません。不自然な方法です。ただの足枷です。
ウォーターフォールはこの足枷があることで、後々にまで大きい不確実性を残して炎上してしまったり、 「試しに作って見ればわかるもの」に対して延々と机上で設計を行う、無駄な努力を強いられます。 なので最悪であるという結論です。
プロジェクト全体でも同じです。繰り返し開発ができるだけでもだいぶリスクは軽減されます。 大規模開発で繰り返しができないほど非効率で、リスクが高い方法はありません。
なお「繰り返し開発ができる＝繰り返しリリースしないといけない」ではありません。
ジュニアエンジニアにはどう対応するか
シニア、ジュニア、素人の違いで書いた通り、チームにはジュニアエンジニアが必要です。 経験の浅いジュニアエンジニアに対してはどうすべきでしょうか。 自分は、不確実性が低い、小さいものを最初から最後までやってもらっています。
システム開発には、難易度が高く、要件が不明瞭なものもあれば、 難易度が低く、要件のブレが少ないものもあります。 そのようなものからやってもらうのが最適です。
組織の壁こそがウォーターフォールしか採用できなくなる原因
「ウォーターフォール開発は大規模開発に向いている」という言説があります。 これは言うまでもなく大間違いです。なぜなら、大規模なプロジェクトほど不確実性が大きくなるからです。 逆に言えば、小規模なプロジェクトなら不確実性が少ないため「Grand Design」プロセスが存在する余地があります。
ではなぜ「ウォーターフォール開発は大規模開発に向いている」と思われているのでしょうか。 正しいのは逆で、「大規模開発における制約がウォーターフォール開発しかできなくしている」からです。
大規模開発では必然的に、多くの人が関わることになります。 多重下請け構造のSI業界では、多くの会社の様々な人が1つのプロジェクトに関わります。 そのとき多くの場合、3つの「壁」が出来上がります。
1つ目の「壁」は、顧客とベンダー側の壁です。「請負開発」というのは一つの壁です。 この壁によって「要件を確定して契約しないと進めない」という制限が生まれます (受注を見越して先に進めることも可能ですが)。
2つ目の「壁」は、元請けと下請け、あるいはプロジェクトマネージャとメンバーといった、開発内での上下関係です。 幸いにも自分はその「壁」に当たったケースが少なく、ほとんどの場合自由にさせてもらっていました。 だからこそ「ほとんど完成させてから設計書に内容を記載」することもできました。 もっとも、自由にさせてもらえなかったケースは本当に最悪でしたが。
もし元請けやプロジェクトマネージャが「設計が終わらないと次に進んではいけない」という考えに囚われている場合、 必然的にウォーターフォール開発しかできません。
3つ目の「壁」は、メンバー間の壁です。 隣にいる人が何をしているのか分からない、何をしているのか興味がない、そんな関係では、 漏れたタスクを拾ってくれる、そんなことは起きません。 だからこそ、分業して自分の目の前のことだけをこなせる、ウォーターフォール開発を取らざるを得ません。
これらの3つの壁があるからこそ、ウォーターフォール開発という足枷を自らつけないといけなくなります。
逆に言えば、組織の壁を壊せばこの制約を外せます。 顧客とベンダーの関係を変え、元請けと下請けの関係を変え、メンバー間の関係を変える必要があります。 そうすれば、ウォーターフォール開発をやめて、自然な開発手法に戻ることができます。
「ウォーターフォール開発をやってるけど自分たちは〜」
例えば「ウォーターフォール開発をやってるけど繰り返しは当たり前にやっている」 そういう人がいたら、やめるべきは「ウォーターフォール開発という言葉を使うこと」だと思います。
←仕事が変わりました(会社はそのままで)
シニア、ジュニア、素人の違い→