仕様変更や手直しによるスケジュール遅延を見込む
これまでも、プロジェクト完了時に報告会やクロージングミーティングなどと言った名前で、現場にいた頃は振り返りを実施してきました。
その中から具体的事例に対する分析と対策について検討してきた中で、最も効果的なものの１つとして
解析資料の変更／追加が頻繁に発生し、
リスケ(再計画)が十分に行えず、スケジュールが明確にできなかった
という課題への対策があります。
既存システムや業務上のルール・仕組みが既にお客様の中で存在していてもその資料や手順が明らかでない（いわゆる仕様が不明瞭）…と言うケースは、この業界では珍しくありません。
これは大手メーカーでも同様で、納品後３年も経てば当時の成果物管理が杜撰になります。そのことを知っておくと、仕様書や要件が不明、不鮮明な場合を想定した
・あらかじめ調査する期間をスケジュール上に設ける
・クリティカルパスを設定し、そのクリティカルパス超過時の
対応策についてお客さまと検討する
・要件定義とそれ以降の開発工程で契約を分割し、
規模が明らかになった時点で"再見積り"タイミングを設ける
（「情報システム・モデル取引・契約書」参照）
等、いくつかのリスク回避、あるいはリスク低減方法が検討できることでしょう。これは一般的に頻出しやすく、ほぼ間違いなく顕在化することが前提の"汎用リスク"です。
そのため、どんなにしっかりした取引先が相手でも「もし、そうだったら？」は常に考えられるようにしておきましょう。
発生しなければ"杞憂"に終わるだけで何も問題にはなりませんが、発生したとき、あらかじめ対応しておけば発生による被害をゼロまたは最小限に食い止めることが可能になります。
仮にこういったリスクについて見積り時にお客さまに危険性を投げかけておけば、
「（予算が潤沢にある場合）見積りに積んでおいてください」
とお願いされることもあります。
なにもこれは珍しいことではありません。
私たち自身がそうであるように、国にしても、民間企業にしても、必ず年度の初めに『予算』と言う枠を作ります。
たとえば、
ＩＴ投資費：〇〇円
と言った感じで枠として予算化されることでしょう。
原則としてこの枠は絶対です。
これを超過する場合は"稟議"を必要とするでしょうし、自分から年度初めの計画が甘かったことをさらけ出す"稟議書"は書きたくないものです。
よって原則として枠内に収めようとしますし、逆に予算枠内であればお客さまはさほどお金に対してうるさく言いません。しかもリスクが顕在化しなかったからと言って、契約を締結してしまった以上は「あとで返して」と言われることもありませんし、顕在化しなければそのまま私たちのプロジェクト活動の純利益に流れることもあるので覚えておいて損はないでしょう。
さて、このことを予め計画に組み込んでおく場合は、
・リスクが顕在化した場合
・リスクが顕在化しなかった場合
の２種類のスケジュールを作ってお客さまと合意しておくことが求められます。
…と聞くと管理工数をあまり使いたくないマネージャーやリーダーの方たちはあまりいい顔しないかもしれませんが、こうして対処しておくだけで非常にお客さまからの信頼を得やすくなります。
もし、お客さま（特に部長クラス以上のある程度、決裁権や決定権を持っている方）を味方に引き込んで、今後の活動に対して主導権を以って行いたいのであれば、少々手間でも実施しておくことをお勧めします。
とはいえ「リスクが顕在化したら、納期も伸ばします」では逆にマネージャーの資質を疑われかねません。お客さまにとっては、製品が納品されてからが本当のスタートであり、その後のことも含めて計画が行われているはずです。
にもかかわらず、そういった事情を一切勘案しない提案は、
「自分たちのことをわかってくれようとしていない」
と認識されても致し方ありません。このように、お客さまにとってもスケジュールは比較的mustな要素ですので、最終的なDelivery的目標値(=納期)に影響を与えることなく、調整する案を持っていけるように工夫しましょう。
たとえば、
・要員等の追加による、予算調整
（誰でも考えつきそうな一般案）
・必須ではない機能を削る
（一般的な予算維持策）
・進捗を報告するためだけの会議体で移動・出張する機会を減らす
（管理工数の低減および生産性ゼロ作業の縮小）
・要求仕様を維持したまま規模縮小できるアーキテクチャの見直し
（これができればかなりの上級者）
・今後の付き合いも考えて、特に調整を表面化させず、高稼働でカバー
（その場しのぎの愚策）
など色々検討するとよいでしょう。もちろんこれらの組み合わせにより負担を偏らせないことも有効な策の１つです。
このような調整には、単純にマネジメントスキルだけを持っていても必ずしも良い案が出るとは限りません。テクニカルな開発スキル（特にアーキテクチャ面）や、業務・ハードに精通した知識なども活用することで、より高度なマネジメントが可能になります。
技術的なことがサッパリでマネジメントにばかりかまけていると、お客さまにとってより良い、ひいては当社にとってより有利となる調整は困難になり、時として相手をがっかりさせてしまうことにもなる点を頭の片隅に入れておくといいでしょう。
仮に、自分の中にそうした案が思いつかない、知識がない場合などは、テクニカルな面で信用できるメンバーとも連携しておくことが求められます。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。