ウォーターフォールはこう使え（その3）: わたしが知らないスゴ本は、きっとあなたが読んでいる

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

　ちょっと思い出して欲しい。次の弾丸が飛んでくるのはいつだろうか?

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

　よい子のみんなはもちろん分かってる。納品が間近に迫ってきたときだね。品質がアレなのか、そもそもマトモにできていないことが明らかになったか、トリガーは様々だけど、たいていはプロジェクトも終盤になってそんな弾丸が飛んでくる。

　これは「仕様のあいまい性」を先送りしてきたツケだ。実はこの弾丸、プロジェクトを通じて3度発射する機会があるという。

1回目：顧客との契約時、仕様の確認をするとき
2回目：ベンダーと請負会社の契約直前に、請負会社から仕様の確認を求められ、顧客に問い合わせるとき
3回目：火ダルマになっていることが知れ渡り、顧客が乗り込んできて「こんなのを作れなんて言ってない」と言い放つとき

.…にもかかわらず、3回目がほとんどだろ。この弾丸を発射するときがチャンスで、口を尖らせて「そもそもかくあるべき」論がくりひろげられる。そんなんなら最初から言えやボケェ！と叫びたくなるのをグッとこらえるのに苦労しただろう。

　だから、この弾丸は最初に撃ってもらおう。1回目こそが決戦地。ここでは、仕様をきちんと落とし込むためのテクニックは書かない。テクニックはUMLでもマジカでも好きな武器を手にすればよい。ここでは、決戦地で闘うための戦略を書く。戦略は2つある。

* * *

「仕様の再確認」によるあいまい性の排除

　一つ目の戦略。決戦地は「受注確定直後」。ここで決めなければいつまでたってもあいまいなまま。極端な話、動いたものが仕様ですなんてシャレにならん冗談もある。確定直後、「システム仕様の再確認」をやる。ミーティング形式だろうが、題名は　"　仕　様　の　再　確　認　"　であること。

　そもそも受注時にまともな仕様が決まっているハズがない。顧客も営業も社内手続きや次案件に忙殺されてて、内部ネゴが通れば後は済んだ事にしたがる。だから、契約書に添付されている「仕様書もどき」を見ても、ペラペラのスカスカだ。

　だから受注確定時、「分析・検討フェーズ」と称して「仕様の御用聞き」をやってるわけだ。顧客にとってはベンリだよな。契約でスケジュールをしばって、仕様は後付けで決められる。都合の悪いところは「そう読めるじゃねーかよ」と切り返す。どうとでも読み取れるような書き方をしているからだ。

　そこが問題なり。仕様は決まっていないのに、あたかも決まった上での契約として扱われ、フリーハンドの余地をたっぷりと残している。しかも決めにくいところは先送りできる。そうしたしわ寄せは後の人に押し付けられる。

　こいつを回避するためにすることは「仕様の再確認」。仕様は既に凍結しており、今やってることはその再確認に過ぎない、という姿勢で臨む。そこにはペラペラの「仕様もどき」から全力で肉付けしたドキュメントを準備しておく。

　すると顧客は「そうじゃない」とくる。あたりまえだ。顧客自身、真剣に深堀りして考え抜いたわけじゃないからだ。けれども、ペーパープロトタイピングでも何でもいいから、形になったものをとにかく突きつける。顧客はそこで初めて考え始める。仕様を考えるベースラインがあれば、そいつに朱入れしてもらうなり、顧客自身に書き直してもらうことができる。何も土台がないまま空中戦を続けても何も残らない。

　それでも「仕様の再確認」という姿勢はくずさない。なぜか? 「すべきこと」は決まっているから。（その2）で出てきた「空欄込みのすべきこと」が効いてくる。プロジェクトのゴールが決まっていて、そこから逆算してすべきことが洗い出されていて、順序性と未決定事項がオープンになっているから。仕様は今決まっていないと、順序が崩れるから。「そうじゃない」と"今"言われても困るから。"今"（＝契約直後）に決まっていないと、ゴールは望めないということを、"今"たっぷりと自覚してもらう。

　これができるのは、空欄が入っててもいいから「すべきこと」が全部マナ板の上に乗っているから。「走りながら考える」「とりあえず動いてから決める」姿勢でいる限り、いつまでたっても決まらない。

　プロトタイプ開発方式での仕様決めに参加したことがあるだろうか。プロトタイピングのだんだん肉付けするやり方は、作るのには適しているが、決めるのには最悪なり。これを理解していないと、いつまでたっても決まらない画面をいじりまわしているうちに時間切れになる。顧客が決めたいのは文字の色やボタンの配置なのではなく、そこでやりたいこと、即ち仕様なり。「大学で情報工学を専攻してました！」という連中が最も陥りやすい罠。むしろ、そういう研究室上がりこそ、「色やボタンの配置こそが"仕様"じゃありませんかッ」と詰め寄ってくるので「画面仕様書を「作らない」リスク」あたりを読んで理解してもらおう。

　何が欲しいのか、顧客が説明できないのであれば、何を作っても満足させることはできない。プロトタイピングが根本的に誤解しているのは、ここだ。顧客を巻き込むまでは正しい。しかし、顧客の言うとおりにスパイラルをくり返したところで、顧客が満足するアウトプットは出ない。だから最初にアウトプットを出して「そうじゃない」と顧客自身に言わせる。顧客にとっての"銀の弾丸"は、最初に撃ち尽くしてもらおう。