起きたときに、どう収束させるか
第1回で発注前の準備、第2回で進行中の管理を扱いました。それでも、問題はゼロにはなりません。最終回は、トラブルが起きたときの収束のさせ方と、プロジェクトの終わらせ方を整理します。共通するのは、「気合いで乗り切らない／構造で対処する」という姿勢です。
成果物の品質が、要求水準に達しない
ベンダーの成果物がレビューで「これでは使えない」となる。ここで「やり直してください」とだけ伝えても、同じものが出てきます。自社で抱えて修正するのも筋が違います。
- 品質基準を文書化する：何をもって「使える」とするかを、先に明示しておく
- 早期にレビューを設定する：完成後ではなく、中間段階でレビューを挟む
- サンプルを提示する：「こういうレベルが期待値」と具体例で示す
- 改善計画を求める：単なる「やり直し」ではなく、原因と対策をセットで出してもらう
品質は、完成してから測るものではありません。何を「合格」とするかを発注側が先に言葉にしておくことが、出戻りを防ぎます。
テストでバグが大量に出る
受け入れテスト（UAT）で想定の何倍ものバグが報告される。数に動揺して「全部直します」と引き受けると、収拾がつかなくなります。「数」ではなく「重要度」と「原因」を見るのが、収束の早道です。
- 重要度別に分類する：致命的／高／中／低
- 致命的・高のみ即対応する：中・低は次フェーズへ回す判断もある
- 根本原因を分析する：なぜ大量に出たか（テスト不足／要件の曖昧さ／設計の問題）
- 再発防止策を講じる：単発の対応で終わらせない
たとえば、想定の3倍のバグが報告された場面なら、こう動きます。
- 重要度で分類する（致命的2件／高8件／中30件／低60件）
- 致命的・高の10件を今回の対象とし、中・低は次フェーズへ回す合意を取る
- なぜ大量に出たかを分析する（今回は「要件のあいまいさ」が主因と判明）
- 再発防止として、残りの開発分は中間レビューを挟む運用に変える
「100件のバグ」に動揺するのではなく、「致命的・高の10件をいつまでに、残りはどう扱うか」に分解する。これだけで、見通しが立ちます。
想定よりボリュームが大きい・予算が足りない
着手したら予想の2倍の工数が必要だった、予算の80%を消費したのに進捗は60%——よくある資源の問題です。黙ってスケジュールを延ばしたり、残予算で品質を落として完成させたりするのは最悪手です。
- 超過見込みを正確に算出する：感覚ではなく工数の積み上げで
- 早期にステークホルダーへ報告する：「あと◯◯万円・◯週間必要です」と具体的に
- オプションを3つ提示する：①納期延長 ②リソース追加 ③スコープ削減
- 再計画を文書化する：変更内容と承認者を記録に残す
ここでも「どうしましょう」ではなく、選択肢を並べて意思決定者に選んでもらう形にします。
人が足りない・現場が疲弊する
主要メンバーが「もう限界」と訴える。励ましたり静観したりするだけでは、離職という最悪の結果を招きます。
- 負荷状況を可視化する（誰がどれだけ稼働しているかを数字で）
- タスクを再配分する（他メンバー・外注で吸収する）
- スコープ削減を検討する（本当に必要な機能だけに絞る）
- 離職リスクを上層部にエスカレーションする（人員追加の判断を仰ぐ）
撤退・縮小も、選択肢に入れる
どうしても立て直せないとき、「これまでかけた費用がもったいない」と続けるのは危険です。すでに使ったコストは戻りません。
- 「ここまでの投資」ではなく「これから得られる価値」で判断する
- 縮小（スコープを大きく絞り、最小限で着地する）という中間案も検討する
- 撤退・縮小も、選択肢として意思決定者に提示する
止める勇気も、立派なプロジェクト管理です。傷を最小限にする判断は、感情ではなく数字で行います。
リリース直前の致命的な問題
リリース1週間前に重大なバグが発覚。強行リリースも全面延期も、どちらも安直です。
- 影響範囲を特定する：どの機能・どのユーザーに影響するか
- 判断基準を明確にする：致命的なら延期、限定的なら回避策で凌ぐ
- 3つの選択肢を提示する：①延期 ②段階リリース ③回避策で予定通り
- 意思決定者を巻き込む：PM だけで判断しない
そもそも、一度に全機能を本番投入すると、問題が起きたときの影響が大きくなります。可能なら、件数の多い中心業務から先に出し、周辺業務や例外は後の段階へ回す——段階的なリリースにしておくと、問題が出ても影響範囲が限定され、切り戻しやすくなります。
本稼働後に「使ってもらえない」
無事にリリースしても、「使い方がわからない」「前のシステムの方が良い」と言われることがあります。研修やマニュアルを増やすだけでは解決しません。
- 使えない理由を分析する：UI の問題／業務フローの問題／心理的な抵抗
- 現場のキーパーソンを巻き込む：現場のリーダーがまず使い始める
- 早期の成功体験をつくる：「これは便利」と実感できる場面を演出する
- 継続改善を約束する：「ご意見を反映して改善します」と返す
見積もりは、1回で決めない
最初の見積もりは「叩き台」です。要件を整理し、機能を足し引きしながら、双方向の擦り合わせを経て固めます。
- 「予算オーバー」で止めず、「ここを削れば何が外れるか」を一緒に検討する
- 再見積もりは、初回からの差分（何を・いくら・なぜ削ったか）を文書で残す
- 追加の要望が来ても拒否せず、「Aを引いてBを入れると差し引き＋◯万円」と変更案を出す
「一度出したから」と相談を断るベンダーより、「もう一巡擦り合わせましょう」と返すベンダーの方が、結果的に炎上しません。発注側も、その姿勢を引き出す関わり方をします。
「検収」を、感覚で通さない
納品物を受け入れる検収は、トラブルの最後の関門です。「だいたい動いているからOK」で通すと、後から問題が出ても言いにくくなります。
- 検収基準を、発注前に決めた要件・完了の定義と突き合わせる
- 機能要件だけでなく、非機能（性能・セキュリティなど）も確認する
- 異常系（エラー時・権限外の操作）の挙動もテストする
- 残課題があれば「いつ・誰が・どう直すか」を合意してから受け入れる
検収は「合格・不合格」の二択ではなく、「何が残っていて、いつ片づくか」を握る場と捉えると、現実的に進みます。あわせて、契約や支払いの区切りを工程ごとに分けておくと、「終わらないプロジェクト」になりにくく、双方が見通しを持って動けます。
クロージングが進まない
「ほぼ完成」の状態が何か月も続く——終わらないプロジェクトの典型です。「あとちょっと」を繰り返さず、終わらせる仕掛けを入れます。
- 完了基準を明示する：何をもって「完了」とするか
- 残タスクを可視化する：「あと◯件で完了」を数字で
- デッドラインを設定する：「◯月◯日にクロージング会議」
- 未完了タスクは次フェーズへ：完璧を目指さない
「悪い報告」が上がる場をつくる
トラブルを早く収束させられるかは、悪い情報が早く上がってくるかにかかっています。「解決してから報告しよう」は、遅延の最大の原因です。そして、問題が起きたときに「誰のミスか」を探し始めると、報告はますます上がってこなくなります。
- 悪い情報は、見つけた瞬間に「問題があるが、こうする」の形で出す
- 伝えるときは、事実（何が起きたか）・影響（誰に・どれだけ）・対策案（①〜③）を分ける
- 「悪い情報を早く出した人」を責めず、評価する
- 原因を「不注意」で片づけず、工程やチェックの側を直す（人ではなく仕組みを見る）
責める文化はバッドニュースを遅らせ、遅れた報告は炎上を招きます。心理的な安全を保つことが、結局はトラブルの早期収束につながります。
本番後の運用・保守まで見据える
リリースはゴールではなく、運用の始まりです。終盤になって慌てないよう、保守・運用の体制も早めに決めておきます。
- 障害時の連絡先・対応時間（保守契約の範囲）を決めておく
- 軽微な修正や設定変更を、誰がどこまで対応するかを取り決める
- マニュアルや問い合わせ窓口を、本稼働前に用意する
「作って終わり」ではなく「使い続けられる」状態まで設計しておくと、リリース後のトラブルが減ります。
振り返りを、次に活かす
振り返り会をやっても、次のプロジェクトで同じ失敗を繰り返すなら意味がありません。「次は気をつける」で終わらせないことが肝心です。
- Keep / Problem / Try で整理する：続けること・問題・試すこと
- 具体的な仕組みに変換する：「気をつける」ではなく「◯◯のチェックを追加する」
- 次プロジェクトの計画に反映する：振り返りの結果をテンプレート化する
- 組織知化する：個人の経験を、組織のナレッジにする
総括——PM の3つの基本原則
連載で見てきた発注前・進行中・トラブル対応は、最終的に次の3原則に集約されます。
- 早期発見・早期対応：問題は時間とともに悪化する。「もう少し様子を見る」が最も危険。異変を感じたら24時間以内にアクションする
- 構造化された情報共有：「順調」「大丈夫」では情報にならない。数字 + 期限 + 担当をセットで報告する。悪い情報こそ詳しく
- 選択肢の提示：「どうしましょう？」ではなく「①〜③のどれにしますか？」。意思決定者の負担を最小化し、自分の推奨案も併記する
この3原則を守れば、ほとんどの困りごとは「炎上」する前に収束できます。
連載まとめチェックリスト
- 品質は「合格基準」を先に文書化し、中間でレビューしているか
- 問題は「数」でなく「重要度・原因」で分類しているか
- 資源不足は早期に報告し、選択肢を3つ提示しているか
- 見積もりは擦り合わせ前提で、差分を記録しているか
- クロージングの完了基準とデッドラインを決めているか
- 振り返りを「仕組み」に変換し、次に引き継いでいるか
関連教材：本連載のベースになっている要件定義・プロジェクト管理の講座は、無料公開のITコンサルティング・ガイドブックで詳しく学べます。
おわりに
ベンダーコントロールは、特別な才能ではなく、地味な習慣の積み重ねです。発注前に握り、進行中に止めず、トラブルを構造で収束させる。この3回分を実践するだけで、プロジェクトの景色は大きく変わります。
とはいえ、これらを社内のリソースだけで回すのは負担が大きいのも事実です。私たちは開発会社として手を動かしてきたからこそ、発注側に立つ PMO として、見積もりの妥当性評価から進行・トラブル対応まで伴走できます。「自社だけでは舵取りが不安」という段階で、お気軽にご相談ください。
