ウォーターフォール型開発プロセスの有効性

牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。

こちらも合わせて読んだ

そもそも批判されるようなWF型プロジェクトは実在するのか

本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれに工夫を凝らしているので、実際に批判されるに値する害あるWFというのはあまり存在していないのではないかと考えている。外観をひとことで表現するとWFになるのだけれど、皆が魔改造をしており既にWFではなくなっている気がする。

以下は個人的観測による最近のいわるゆWF的プロジェクトの傾向だが、これが批判されるほどWFなのかは疑問がある。

1.計画駆動・計画重視である

プロジェクトを取り巻く環境や、さらされているリスクに応じて適切に計画駆動・計画重視することは必要に応じてやるべきだし、否定されるものではないと思う。
古くはバリー・ベームが2004に書いた「アジャイルと規律」でもバランスを取ることが重視されているし、

残念ながら、ソフトウェア開発に対するこれら二つのアプローチは、お互いにサポートしあう道を採るのではなく、相手をゼロサムゲームにおける対戦相手のようにみなしている。アジャイル主義者は、伝統主義者を罵倒し、プロセスを崇拝する「テーラー式」還元主義者によってソフトウェア開発の人間性が奪われていると嘆く。すると、主流派はそれに応戦して、ハッキング（ずさんなシステムを適当に作っている）とか、品質が悪いとか、真剣なビジネスの中にお楽しみを持ち込みすぎだと非難する。さらに、それぞれの陣営の真剣な信者がやってきては、ほとんど救世主のように甲高い声で自分の信念を言い立てるので、成功のための真の戦略を見つけ出そうとしているソフトウェア開発者やマネジャーはますます混乱するばかりである。
アジャイルと規律

アジャイルと規律～ソフトウエア開発を成功させる２つの鍵のバランス～

作者:バリー・ベーム,リチャード・ターナー,ウルシステムズ株式会社,河野正幸,原幹,越智典子
発売日: 2004/08/05
メディア: 単行本

近年だとエンタープライズアジャイルのガイドの一つであるDADについても、必要に応じた一定の計画重視を論じていたように記憶している。

ディシプリンド・アジャイル・デリバリー　エンタープライズ・アジャイル実践ガイド

作者:Scott W. Ambler,Mark Lines
発売日: 2013/11/20
メディア: Kindle版

2.フェーズゲートがある

段階的に計画や見通し、状況をチェックしながら進める（たとえば要件定義→設計などのフェーズ移行時）手法はWF的な特徴ではある。しかし実際には利害関係者が多岐に渡る大規模プロジェクトにおける合意形成や、有識者レビューによるリスク軽減を目的にしているものが多く、純WF的なゲートチェックを行うことは最近は少ない。どういうことかというと

○○フェーズ（例えば要件定義）が完了したか

のチェックをするというよりは、

現段階での分析結果について関係者は合意できるのか（みんなサインできる？）
現時点の未確定事項や、リスクを棚卸して、計画を続行してよいか（コントロールはできてる？）

という実践的な確認が中心であり、忌避すべきようなものでは無くなっている印象。

3.プログラミングの工程で要員数が膨らむ

WFのお家芸として

プログラミング能力のないエスイーが大量に設計書を書いて
大量に調達されたプログラマーがエスイーを呪いながらコードを大量生産
効率悪ぃ〜

というものが以前にあったことは確かだけれども、これも現代ではかなり少なくなってきている。
短納期、大量開発が求められる場合もコードの自動生成とかフレームワークをうまく活用して、どこも効率良く開発するようになった。
要求されるスケジュールと規模を勘案して途中の要員数が大きく増えることはあるけれども、ゼロ年代のような人海戦術の精神論はイマドキあまり見かけない。

4.長期間の統合テストやシステムテスト期間が終盤に存在する

これもWFあるあるだけれども、あまり意味なく長大なテスト期間を設ける例は少なくなってきたと思っている。それなりの期間をテストに費やすケースは、

関連システムとのスケジュール同期化を目的としたもの
高い信頼性と品質を求められるために実施する

などの理由がきちんとある事が多い。
また、前述のDADでも統合テストの必要性は論じられていたし、アジャイル開発でも必要に応じて統合テストとかシステムテストは必要であろう。

また、世の中にはこんな事例もあるわけで、これらも含めてWFのタグがついているからと言って石を投げるのはあまりに乱暴な気もする。
www.publickey1.jp

亀だ愚鈍だと批判されることも多いSIerと大手企業システム部門ではあるが、経済成長も鈍化した昨今、それぞれが様々な工夫をこらしており、非効率を放置しているようなことはほとんどない。というか進歩しないと死ぬ。もちろん悪手も多いが、向いている方向性は正しいのではないかと思っている。

WFの課題

牛尾さんの記事では主にWikipediaの記事をベースにウォーターフォールの課題をいくつか挙げているのだけれど、同じ論点については過去に以下の記事でも深堀りをしたことがあるので参考に。

改めて「ソフトウェア工学で大切な10の考え方」からウォーターフォールの論点を抜き出すと、

ウォーターフォールというコンセプト、そのものについては誤解がある（構想者は1回限りの段階プロセスを想定していなかった）
コンセプトの適用は「All of Nothing」ではない。プロジェクトにあわせて最適化せよ
「すべてを先に決定しなければならない」ということはない
しかし、慎重に検証しても大規模プロジェクトでは「納品後のソフトウェアの変更は要求フェーズでの変更より100倍も高くつく」
この事実を踏まえて、適切なプロジェクトの設計が必要である

ということになるというのが私の見解である。そういう意味では、WFもアジャイルも相互補完的に活用するものであり、要は適材適所であろう。というわけでWFもメリットあると思うよ。

エンタープライズ開発とアジャイル

実は最近の実感としてはエンタープライズ開発の領域におけるアジャイル開発プロセスの相性は割と微妙だと考えている。
というのも、企業システムはシステムと人間系が相互に密に連携したワークフローであることが多いため、システム側の適応性をいかに俊敏にしても、人間系が変更に追いついて来ないのだ。準リアルタイムに業務改善のアイデアをシステムに反映していっても、使うユーザー側が追いつかない。もしくは「慣れた頃に変更しやがって」と石を投げられる。

以前に大きな業務改革のプロジェクトに参画したことがある。そのプロジェクトでは、ある店舗業務を無くして新設する専門部門で一括処理を行うというものだったが、新組織を立ち上げるという性格から構想計画分析には多大な時間を要した(マスタースケジュールはとてもWF風だった)。新組織の役割や、そこでの評価の仕組みもかかわってくるわけで、人事や経営も巻き込んだ意思決定について時間をかけた。また当然組織やファシリティはシステムの完成にあわせて立ち上がるので、テストはビッグバン方式にならざるを得ない。この手のプロジェクトに対して、やれアジャイルだ、DevOpsだと言ってもあまり意味はないだろう。（なお、実はソフトウェアの開発部分はScrum採用してた。当時RUPを強く意識していたのだけれども、これはまた別の話)。

だから、人間系と密に結びついた業務ソフトウェア開発プロジェクトにおけるアジャイル開発プロセスの適用は、最近割と慎重に考えるようにしている。アジャイルでやりたいと言われても、ちょっと待て、と実際に言っている。

逆に言えば「人間系」の制約に縛られないソフトウェア、例えばコンシューマ向けのWebサービス事業開発や、自動取引の領域においてはアジャイル開発プロセスの親和性が非常に高いのだろう。ソフトウェアの改修や機能追加を人間系の制約なしに反映させることができるかどうか、人間系のボトルネック無くダイレクトに価値を生み出す事ができる領域なのか、というのが重要なポイントだ。ただ、悲しいかな企業システムの領域でこういった取り組みができる範囲は、割と限られているのではないだろうか。

まとめ / 今後に向けて

まとまらないのだけれども、言いたい事は次の通りである。

現代的に工夫、改良されたウォーターフォール的プロジェクトには課題も多いがメリットも相応にあり、ステレオタイプとして否定非難すべきものではない
ビジネス適応領域に応じて、計画駆動とアジャイル型プロセスを使い分け、最適なプロジェクト設計をすべき

プロジェクト環境と開発プロセスが不適切な組み合わせとなってしまう事が、発注者と受注者（もしくは使用者と開発者）にとって最も不幸な事態である。これを避けるために、個人的には何れの方法論宗教にも組せず、学びを継続し、所属組織の能力向上を図り、顧客に積極的に提言できるポジションに踏み込んでいくことが重要なのではないかと思っている。

2016/6/23追記

わかる範囲で、本記事に反応いただいたブログ記事をご紹介（順次追記）。

2016/6/24以降追記

必ずしも本記事に反応いただいたものに限定していませんが、関連記事ということでピックアップしたものを随時追記。

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。