わたしがウォーターフォールを嫌う3つの理由
わたしが担当するプロジェクトの多くは、受注した時点で明確な要求や仕様が提示されていることはまれで、たいていプロトタイピングでアプリケーションを開発していきます。複数のプロジェクトを担当していると、たまに「ウォーターフォール・モデル」を採用するプロジェクトに遭遇します。
運が悪いだけなのか、わたしの立ち回りが下手なのか、ウォーターフォールを採用するプロジェクトではろくなことがありませんでした。このため、ウォーターフォールを採用するプロジェクトを担当させられるのが好きではありません。
わたしがウォーターフォールを採用するプロジェクトが嫌いな主な理由は、次のとおりです。
#1 次工程が見切り発車する
前工程の進ちょくが遅れていても、当初のスケジュールどおり開発を進めるため、やむをえず前工程の作業完了を待たずに次工程の作業を開始します。後戻り作業を減らすためにブレの少なそうな箇所から作業を始めますが、少なからず後戻り作業は発生します。
厳密にウォーターフォール・モデルに従うなら、前工程の作業が完了するまで次工程に着手すべきではないと思います。それが守れないならウォーターフォール・モデルにこだわる必要が分かりません。
#2 成果物が、顧客の要求を満たすか心配になる
じかに顧客から要求を聞き、定期的にプロトタイプを見せて顧客と一緒に仕様を決めながらシステムを開発することに慣れているので、最終工程まで顧客に成果物を見せる機会がないと、それが顧客の要求を満たしているか、とても心配になります。
特に、下流工程を担当していてユースケースが想像できない仕様があると「本当にこれでいいのか？」と不安になるので、上流工程の担当者に質問したり、使えるコネを駆使して顧客の要求の真意を尋ねたりします。必要であれば（余計なお世話かもしれませんが）別の仕様を上流工程の担当者に提案することもあります。
これだけ確認しても、要求を満たすことができないことがありました。そのプロジェクトでは、詳細設計（もちろん、査閲・承認済）どおり実装したアプリケーションがシステムテスト時に顧客の要求を満たさないことが判明し、リリース物件から除外することになってしまいました。
#3 進ちょく率の算出方法が分からない
わたしはいままで、ウォーターフォールを採用するプロジェクトのリーダーを務めたことがないため、ガントチャートを作成したことはありませんし、他のプロジェクトでも進ちょく状況を数値（パーセント）で報告させたことはありません。このため、わたしはプロジェクトリーダーに担当する工程の進ちょく状況を数値で報告しなければならないとき、進ちょく率を算出方法が分からずに困ってしまいます。
テスト工程のように、比較的算出しやすい（実施項目数／全項目数で算出できそう）場合はよいのですが、設計や製造の工程では難易度を考慮しなければならず、進ちょく率を算出する式や難易度をあらわす係数を用意しないと、正確な値を得ることができないと思うのです。
けれど、悩むわたしをよそに、若手技術者でも堂々と「80％完了です！！」などと報告しますが、わたしには何をもって80％完了したと判断したのかが分かりません。きっと、わたしの知らない暗黙の算出式というものが存在するのでしょう。
おわりに……
ウォーターフォール・モデルは、コンピュータでプログラムを実行するコストが高かった（パンチカードを作成してバッチ実行していた？）時代では効率的な開発モデルだったのではないかと想像します。担当者1人に少なくとも1台のPCが与えられる現在では、アジャイル開発や反復型開発など、試行錯誤しながら進められる開発モデル、手法のほうが効率的な場合が多いのではないでしょうか。
少し前にスラッシュ・ドットで話題になっていました。コメントを見る限り、「次工程が見切り発車する」で述べたように、ウォーターフォールの原則をないがしろにして開発を進めているプロジェクトが多いようです。いったい何のためにウォーターフォール・モデルを採用するのでしょうか……。プロジェクトメンバーにスケジュールを遵守させるためのプロジェクト・マネージャのエゴかと勘繰りたくなります。
コメント
CMP
お客様と直接やりとりのできる開発しかやったことがない人が書きそうなコラムですね。私も当初は同じようなことを考えたこともありましたが、もっと大規模なプロジェクトに参加してはいかがでしょうか？
きっと、目からウロコが落ちるような体験・経験が待ってますよ。
その後、もう一度本コラムの内容を見直してみては？
CMPさん、はじめまして。
> お客様と直接やりとりのできる開発しかやったことが
> ない人が書きそうなコラムですね。
そういうわけではありませんが、お客様と直接やりとりしない
プロジェクトを担当した経験は極端に少ないのは確かです。
> もっと大規模なプロジェクトに参加してはいかがでしょうか？
客先に常駐していますので、担当するプロジェクトを選ぶ立場に
ありません。難しいですね。
> きっと、目からウロコが落ちるような体験・経験が待ってますよ。
そういうプロジェクトであれば、是非、担当してみたいものです。
余計な気を遣う必要がなければ、どれだけ楽なことか。
ただ、経験したプロジェクトでも職場を見回しても……
そのような体験ができるとは思えないんです。
> その後、もう一度本コラムの内容を見直してみては？
もし、目からウロコが落ちるような体験・経験ができれば、再考したいと思います。
Jitta
まず、どんな進め方であっても、「定義→仕様→実装」という流れが存在しているのではないでしょうか。それを、完成品の全体で行うか、部分部分だけで行うかの違いのように思います。懇意にしていただいている方が、「俺が満足するときが完成だ！」と宣われ、困っているようです。プロトタイピングであっても、最終的な「完成」の状態は、先に決めておかなければ、いつまで経っても満足しない顧客によって、恐ろしい状態になるのではないでしょうか。
> 前工程の作業が完了するまで次工程に着手すべきではないと思います。
これは、ウォーター・フォール モデルの問題ではなく、それの扱い方の問題ですよね？
> 最終工程まで顧客に成果物を見せる機会がないと
これも、少し違うかと。ウォーター・フォールの中に、「一次成果物」「二次成果物」と混ぜ、ある程度できあがったものをレビューしていただくということもあります。
> きっと、わたしの知らない暗黙の算出式というものが存在するのでしょう。
それを聞き出すのが、リーダーの仕事だと思いますが？
たいていの場合、要求定義、仕様決定の段階で完成品のステップ数や、機能数、FP 法によるポイントといった、「完成した状態」の見積りが出来ているものです。そういった計測可能な数量を元に計算します。
同時に疑問もわきました。プロトタイピングでは、進捗状況の報告をしない、ということですか？それは、「完成」の状態が決められていないから、今できている機能が、完成に対してどれくらい満足しているかが計算できないと言うことでしょうか？
Jittaさん、はじめまして。
> 「定義→仕様→実装」という流れが存在しているのではないでしょうか。
存在します。これを何回か繰り返すか、一発でバンと終えるかの違いだと
思います。
ただ、プロトタイピングの場合で、試行錯誤しなければ分からない要素が
多すぎるときは仕様書の作成を後回しにすることもあります。
> それを、完成品の全体で行うか、部分部分だけで行うかの違いのように
> 思います。
各部で評価して問題なくても完成品全体としてエンドユーザの要求を
満たさないことはあります。あって欲しくはないのですが、実際に体験しました。
システムテストで最終顧客が気付くまでスルーだったりとか。
> 最終的な「完成」の状態は、先に決めておかなければ、いつまで経っても
> 満足しない顧客によって、恐ろしい状態になるのではないでしょうか。
はい、そうなるでしょう。
プロトタイピングなどでは、最終的なイメージをメンバー全員がいかに
共有できるかがプロジェクト成功の鍵だと思っています。
イメージを共有できないまま開発を進めていけば、無限ループに
陥ってしまい、いつまでたっても終了しない地獄絵図になってしまうでしょう。
そのために要求や設計を鵜呑みにせず、自分なりに解釈して理解できない、
または、改善の余地があれば、どんどん質問や提案をすべきだと考えます。
直近でヘルプしたプロジェクトでは、プロトタイピングでアプリケーションを
開発しましたが、要求分析の甘さから2.5ヶ月のうちに3度の
「最初からやりなおし」をさせられました。当然、リーダーと喧嘩しましたし、
マネージャとも一戦交えました。
開発モデルについては、長短があります。すべてのプロジェクトで
反復型開発が効果的だとは思っていません。長短を見極めることなく、
ウォーターフォール…というパターンが多い気がします。
> これは、ウォーター・フォール モデルの問題ではなく、それの扱い方の
> 問題ですよね？
はい、そのとおりです。
しかしながら、前提を崩しながらもかたくなにウォーターフォールを採用する
プロジェクトが多いです。なぜでしょうか？
この「かなくな」なところがプロジェクトマネージャのエゴではないかと
感じてしまうということです。どんなに遅れても再スケジュールなんて
してもらったことは今までありません。
「品質のよい成果物を製造する」ことと「納品日厳守」のどちらを
ゴールとしてウォーターフォールを採用しているのか分からなくなるような
プロジェクト・リーダーやマネージャの言動を耳にすることがあります。
両方を十分に満たせる場合は良いですが、どちらかの実現が厳しい場合
どちらが優先されるのでしょうか。
>> きっと、わたしの知らない暗黙の算出式というものが存在するのでしょう。
> それを聞き出すのが、リーダーの仕事だと思いますが？
プロジェクト計画を把握し、運用することがリーダーの仕事である、
おっしゃるとおりだと思います。経験上、そういうことを聞き出し、
運用するリーダーは少ないし、なんの根拠もなく、報告するメンバーに
問題があると思います。さらにそれを実績値としてガントチャートに
記入していてリーダーは本当に状況を把握できているのか不思議でたまりません。
わたしは、ウォーターフォールを採用するプロジェクトのリーダーとして
携わったことがありません。副業として担当することが多いので、
お手伝いレベルです。
しかし、手伝うにしても「暗黙の了解」のようにいろいろなことが決まっている
ことが多いのですが、末端のプログラマまでプロジェクト計画が説明され、
徹底されていることを見たことがありません。
不具合報告はメールで既定のフォーマットで…などと断片的に
教わることは多々ありますが。
もしかしたら、わたしの職場の近辺だけの特異な現象かもしれません。
そうだとしたら、わたしはかなり高い確率でハズレを引いている
（引かされている？）と言えます。
> たいていの場合、要求定義、仕様決定の段階で完成品のステップ数や、
> 機能数、FP 法によるポイントといった、「完成した状態」の見積りが
> 出来ているものです。そういった計測可能な数量を元に計算します。
上流工程の担当者が未知、または、未経験のプラットホームやライブラリを
採用することを決たとして、彼らが算出したこれらの指標はどこまで
正しいのでしょうか。
やってみなければ分からない要素がないことが前提であれば、
よい精度で指標を算出できるでしょうし、よほどのことがないかぎり、
後戻り作業は発生しないでしょう。
現実には、外していることもあるし、後戻り作業もあります。
予想外の事態を終息させるためのフェーズを設けているプロジェクトを
見たことがありません。リスク・ヘッジはどうされているのでしょうか。
> 同時に疑問もわきました。プロトタイピングでは、進捗状況の報告をしない、
> ということですか？
進捗状況は報告します。数値的に「60%完了です」なんて報告はしませんが、
作業を完了したかどうか、遅れている原因は何か、対処方法はあるのか、
または、回避策はあるのか、顧客に報告し、徹底的に議論します。
他ではどうか分かりませんが、わたしがメインに担当するプロジェクトの
ほとんどはこれがスタンダードです。
> それは、「完成」の状態が決められていないから、今できている機能が、
> 完成に対してどれくらい満足しているかが計算できないと言うことでしょうか？
完成の状態が決められていないのに、どれくらい完成に対して満足するか…
ちょっと分かりません。それは誰にも推し量れないと思います。
プロトタイピングの場合、わたしたちは「絶対にクリアしないといけない命題」
に対して粛々と取り組むだけです。実現可能であればよいですが、
そうでない場合はその理由を報告しなけらばなりませんし、発注元とか受注先、
プロジェクト・マネージャ、リーダーとか一般メンバー、SEとかプログラマなど、つまらない垣根を乗り越えて解決に取り組みます。
発注元の担当者が解決策を提示することもあれば、わたしたちが
解決策を提案することもあります。
ひつじ
私はシステムを発注する側ですが、発注時にはいつまでに何をどうするという話に対してはコミットしてもらえないということでしょうか？
逐一レビューや指示だしなんて、こちらのコストがかかって仕方がないのですが
ひつじさん、はじめまして
システム開発をどう発注するのか（期間開発か完成開発か）にもよると思います。
期間開発の場合は、ちょうど事例が@ITに載っています。
@IT:アジャイル実践者インタビュー（1）
http://www.atmarkit.co.jp/farc/rensai2/prac01/prac01a.html
XPを意識して開発に取り組んでいませんでしたから、ペアプログラミングや
テストファーストは経験ないです。
わたしの主業務では、完成開発で受注しますが、納品物件は上記の事例の
ように発注者と合意がとれた時点で決定します。発注時には、
* 納品物件の一覧(実行形式、設計書など)
* 開発期間
* システムの必須要件
を決定しているだけです。あとは柔軟に対応して開発期間の終了する3週間から
1ヶ月前にどこまで機能を盛り込むか決定します。
わたしの顧客の多くは研究員ですので、発注時に要求がすべて洗い出されて
いない（こういうものを作って欲しいというイメージだけの場合もあります)し、
そもそも、それが実現可能かどうかもわかりませんから、プロトタイプが
できあがったら、その都度、動作させて確認したがります。
規模にもよりますが、1週間から遅くとも1ヶ月に1度ぐらいはプロトタイプを
提出して、動作確認をしてもらいます。
発注時に開発期間と発注者がレビューを行うためのマイルストーンを設定
すれば、逐一レビューしなくても済むと思います。たとえば、開発期間中に
* アルファ版
* ベータ版
を提出し、レビューするためのマイルストーンを設定しておけば2回で済みます。
アルファ版で要求漏れなどに気付けば、ベータ版で改修されていることを確認
することができるでしょうし、ベータ版で致命的な性能問題が発生すれば、
システムテスト時には、ある程度、性能改善された評価対象が得られるのでは
ないでしょうか。
コストについては、どのくらいの頻度でレビューするかによりますので、
発注者次第ではないでしょうか。レビューに必要な工数をふまえて
予算を確保すればいいわけですから。