スケジュールの短縮はリスクのバッファと前提条件の整合性を添えて

「お疲れ様です。今時間大丈夫ですか。」
「お疲れ様です。はい。何かありましたか。」
「前に追加案件の日程をざっくり出してもらったんですが、その日程のエンドを月末に前倒しして欲しんですが。」
「何言っているんですかー。あの追加の件、手を付けるにだって、『前提条件が揃わないと始められないんですよ』って説明して理解されていたじゃないですか。」
「そうなんですが、先方から月末にまで終えて欲しいと要請があって。」
「ダ・カ・ラ、あのスケジュールだって、その前のスケジュール案から随分短縮しているんですよ。それ忘れていませんよね？」
「ハイ、もちろん。」
「(ハイとか言っているよ。なら何でさらに縮めろって言えるわけ？イミフ)」
「説明したときのホワイトボードのキャプチャはその時に送りましたが“今”もう一度送りますから一緒に観ながら話しましょう。」
「届きましたか。」
「一寸待ってください。はい届きました。」
「いいですか。この作業をして、次に……。」
「それはわかっているですが、先方から……。」
「あのね、日程を見積もった条件がありますよね。」
「はい。」
「それ、何も変わっていないでしょ？」
「はい。」
「どこにスケジュール変わる要素あるの？」
「ないですね。」
「では、お疲れ様。」
「いやちょっと。」
「そうですね、手ぶらで帰るのもアレですね。ではこうしましょう。最後の作業はリリースに直接影響しないのでその前の試験まで月末に入るように考えます。その場合、もう1週間時間が足りません。なので、開始を1週間早く着手しましょう。つまり、前提条件となっていることを1週間前倒しして揃えてください。これで月末まで収まりますよ。」
「ありがとうございます。」
「いえいえ。お疲れ様です。」

あのですね。作業の日程を見積もるとき、その作業の前提とか前後関係とか人の手配とか、いろいろあるわけです。それを考慮して、日程を組んでいるんですね。さらに、メンバの作業に対する成熟度や正確性を勘案することもスケジュールのリスク対策の一部です。

開発や試験では、想定していてもインパクトの大きな出来事があるものです。それの解決にはそれなりの時間の確保が必要です。それ、誰がどこで担保するのか、ってことです。ワタシのプロジェクトならワタシが担保するバッファを確保しないといけないです。出来なければ、それは博打です。そんなもの誰が掛けるかってことです。

あと、むやみに先方の要求にむやみに合わせることは、先の見積もりなり作業の前提条件がいい加減であることを証明するようなものです。頑張って、出来る限り応えてあげるにしても、整合性を確保しなければなりません。

「で、前提条件揃うと思っています？」
「いや、どうでしょう。あははっ。」
「（だめじゃん）」