ウォーターフォールはこう使え（その2）

　ウォーターフォール・モデルとは一言で説明するなら、「プロジェクトの構造化」だ。逐次実行や先手管理、進捗の予実管理なんざ、特徴的だが本質ではない。それらはキチンと構造化された後に実現できる。プロジェクトの構造化をしないまま先手管理しようとするからおかしくなる。

* * *

プロジェクトの構造化はこうやる

　ウォーターフォールは逐次的な開発技法であり、ウォーターフォール全体として「分析>設計>製造>試験」とはならない。顧客受けしやすいようそんな絵を書くこともあるが、実質は異なる。

　「すべきこと」単位に分解して、「すべきこと」同士の順序性を決めた後、「すべきこと」同士では逐次的な関係を守らせるようにすることが本当。

　「すべきこと」の分け方は「分析」「設計」「製造」「試験」ではない。これらは分断するものではない。「なんちゃってウォーターフォール」をダメにしているのは、工程（＝フェーズ）ごとにチームを割り、それぞれの工程を1回でカンペキにこなせるという期待なり。運を点（≠天）に任せているとしかいいようのない希望的観測のおかげで、どれだけの呪詛が生まれたことか…

　学び取るなり盗むなりしてきちんと身に着けていない連中が見よう見まねでマネジメントしていることが、元凶。しかもその部下で実績を積んだ人が、今度はPMとして「なんちゃってウォーターフォール」を任される …悪夢の再生産やね。

　では、どのように分けるのか? プロジェクトにより異なるが、

• 方式
  
• 業務
  
• データ
  
• 環境
  
• 品質
  

に割れる。そして、アサインされたチームがそれぞれの役割を果たす。役割はこんなカンジ。

• 方式　→　ネットワーク、データベース、通信制御、他のシステムとのインタフェースを決定・実装・試験
  
• 業務　→　ビジネスプロセスを分析・実装・試験
  
• データ　→　方式・業務で必要なテーブルセットを準備し、予め用意するべき内容を入れる
  
• 環境　　→　方式・業務・データの開発・試験に必要な環境（ネットワーク・クライアント・サーバなど）を準備
  
• 品質　→　要求されたものと提供するものが合致するためのあらゆる努力（具体的には品質保証/品質管理/品質基準）を実施[参考]
  

　デカいプロジェクトになると、「方式」や「業務」もさらに割れる。ポイントは、役割をアサインされたチームの中で「分析>設計>製造>試験」を回すことと、チーム間での成果物渡しは逐次的なこと。フェーズの名前が気に入らない。なら「検討>執筆>レビュー>」（仕様決め・契約の場合）だろうと、「方針検討>環境構築>実施>検証」（テストの場合）だろうと、お好きな名前をどうぞ。

　仮にウォーターフォールが「逐次的な開発手法」というならば、ココのことを指す。相手チームに渡したら、原則として手戻りは許されない。品質的にアレな場合や、相手チームからのフィードバックがあって初めて手戻りをすることができる。

　「すべきこと」を週単位まで割ることができるならWBSが定義できるが、プロジェクトの最初の段階では全部WBSまで割るのは難しい。だから「すべきこと」はデカいカタマリ単位でOK。このとき大切なのは網羅性。「後で足せばいいや」「やり直しがきくから」なんて甘いことは許されない。なぜなら、「チーム」が別会社にある場合、「契約」が発生してくるから。「あいまいだから分からない」は逃げ。そんなセリフ吐くPMは、いつまでたってもWBS定義をやるはずがない。

　そして、「すべきこと」とWBSが混ざっててもよいから、ネットワークダイアグラムの形にする。つまり、順番を決め、作業量を見込み、矢印で結んでゆき、クリティカルパスを見つける。たいていの場合は、「仕様のあいまい性」がボトルネックとなる作業がクリティカルパス上に乗ってくる。

* * *

構造化すれば、プロジェクトが「見える」

　プロジェクト全体を俯瞰し、プロジェクトを構成する部分を見極め、作業順番を決定し、チームに役割を振ること。これがプロジェクトの構造化。「あいまいなこと」は極力排除するが、残ったところは「あいまいなところ」として「見える化」する（つまり、顧客との共有情報に"空欄"を作っておく）。

　「このプロジェクトの全て」を可視化して、「全体>部分」の構造をオープンにする。まだ決まっていないところや、あいまいな部分は「未決定項」や「未確定事項」として、空欄で定義しておく（←これ重要。これをやっておかないと、変更や追加の要求を受ける際、「変更・追加するモトとなるもの」があやふやになる）。プロジェクトのベースラインを決めることで、そこからのブレを管理することができる。

　しかし、「あやふやなもの」を放置しておけば破綻する。いったんは空欄としてベースにしたとしても、いずれ明確化する必要はある。この連載では、「あやふやなもの」の真っ先のターゲットとして挙げられる「仕様のあいまい性」に着目する。

　　「すでに決まったはずではないか」
　　「そう読み取れるではないか」
　　「いまさら言われても困る」

　「あいまい仕様」に対し、顧客の使う三大文句はこれだ。顧客にとっては銀の弾丸だが、先送りしているにすぎず、いずれ破綻する。破綻のケツはPM/SE/PGに持ってこられる場合が多い。では、ウォーターフォールを使って、誰がどう動けば「仕様のあいまい性」を排除もしくは低減することができるのか?