プロジェクトは複数のシナリオでリスクを洗い出す

ワタシ「見積もりは何か前提があってこの提案になっているんじゃないのかな」
提案SE「いえ、やることは提案書にかいてあるとおりです」
ワタシ「いやね、その提案がね、あなたしか知らないことがあるような気がするんだけど」
提案SE「そうですか」
ワタシ「例えばさ、このスケジュールはマイルストーンが１つもないけどお客さまから受領するものとかないのかな」
提案SE「ありますよ。システムの要件とか」
ワタシ「それ、いつまでにもらわないといけないの」
提案SE「そうですね、要件定義の遅くても中頃にはもらわないとフェーズの中で終わらないです」
ワタシ「そのシステム要件とか欲しい時期とかていあんしょのどこかにかいてあったっけ」
提案SE「えっと、そうですねぇ、書いてありませんね」
ワタシ「それ書かないとお客さまはこの提案書からは読み取れないよ」
提案SE「そうですか。それは拙いですね」
ワタシ「その要件をもらうのって、自然とお客さまからもらえると思っていたのかな」
提案SE「えぇ、そういう『前提』で考えていましたけど」
ワタシ「もしお客さまが気づかなかったらどうなると思うかな」
提案SE「プロジェクトがトラブりますね」
ワタシ「もう少し具体的に何が起きると思う」
提案SE「スケジュールがフェーズの期間を超える…」
ワタシ「それもこの提案書から起きる可能性があるシナリオだね。じゃあ、前のページの技術仕様はどうかな」
提案SE「提案する機能ですか」
ワタシ「そう、機能の技術仕様のページ。それ、何を提供するのか明確かな。あと提供するシステムと他のシステムとの界面はどこまでかけているかな」
提案SE「今の時点ではこの仕様までしか書けないです」
ワタシ「でもさ、さっきと同じようにここまで仕掛けないけど書いた仕様を考えるときに前提にしたことがあるでしょう」
提案SE「えぇ、あったかなぁ」
ワタシ「だってさ、機能で対応する数量が書いてあるじゃない。それって何か条件があるのでしょう」
提案SE「これですか。数量が多くなるのと工数が今の見積もりじゃ足りなくなっちゃうんですよ」
ワタシ「それも前提なんだよ。数量が記載までなら提案する価格で提供できるけど、超えるとプロジェクトに影響しちゃうんでしょ。そういったこともね、１つのシナリオなんだよ」
提案SE「そうなんですかー」
ワタシ「（わかってるのかなぁ…）」

見積もりに限らず、プロジェクトを扱うときにはプロジェクトがどのように進んでいくのか想像する力が必要です。これは絶対に必要なスキルです。（キッパリ

見積もりでもプロジェクト計画でも提案している技術仕様と範囲に課される制約条件と前提条件があります。それらの条件があって、プロジェクトの役割分担に出てくる登場人物が期待されることを担うこととすべての想定がお花畑のようにすべてが想定どおりに行った場合に、そのプロジェクトが想定どおりに進む、かもしれないのです。

まだこの時点でも期待どおりに進むかもしれない、です。

これは「進まない」と言っているわけです。察してください。なぜ、うまく「進まない」と言えるのか。それは、想定している範囲が限定されているから、です。あくまでも提案する側が知っている情報を組み立てて、想定を置いているから。知らないところで何か起きてもそれは想定できないですよね。

だから、プロジェクトがどのように進んでいくのかを想定しないといけないのです。それも、その前提が想定どおりにならなかった場合のシナリオで。これができないと慌てますよ。だから、その想定どおりの対象の前提条件を聞いているのです。

見積もりでもプロジェクト計画でも、前提条件を明記しないとまずは話になりません。その上で、策を用意しておくわけですがそれもそのとおり行かないことを見越して

「想定どおりにいかなかったら」

と考える。これって、計画の穴を見つけられるんですよ。視点が強制的に変わるので。システムを自分で作るエンジニアであるからこそ、プロジェクトのシナリオを複数考えるスキルを身につけないといけません。