ベンダーコントロールの最小セット：契約後に効く運営ルール設計術

ベンダーコントロールは「契約後の運営」で決まる

ベンダーコントロールというと「契約」「見積」「発注」の話に寄りがちですが、現場で揉める原因の多くは契約後に発生します。たとえば、次のような問題です。

• 仕様の解釈がズレていて、後で追加費用を請求された
• 進捗が悪いのに、会議では「問題ありません」と言われ続けた
• 障害や品質問題が起きたとき、責任範囲が曖昧で収束しない
• 変更が積み重なって納期が崩れたのに、誰も止められなかった

これらの共通点は「運営ルールが決まっていない」ことです。逆に言うと、契約後の運営ルールを最小限でも整えると、プロジェクトは驚くほど安定します。

ここでいう“運営ルール”は、難しい規定集ではありません。誰が、何を、いつまでに、どの手順で決めるか――その交通整理です。簡単に運用できるよう、必要なものを「最小セット」に絞って解説します。

守るべき5つの運営ルール

契約後に効く運営ルールは、まず次の5つを押さえれば十分に効果的です。

1. 窓口・意思決定・エスカレーション
2. 会議体・議事録・合意の取り方
3. 課題管理（起票〜クローズ）
4. 変更管理（スコープ・コスト・納期のコントロール）
5. 品質・受入れ（合格条件とやり直しの扱い）

ポイントは「成果物」ではなく「運用の流れ」を決めることです。たとえば課題管理なら、課題表を作るだけでは足りません。起票されてから、誰がいつまでに調査し、いつ合意し、どう閉じるかまでがルールです。

以降の章で、各ルールを“最小限の決め事”に落としていきます。

ルール①：窓口・意思決定・エスカレーション設計

最初に決めるべきは「誰が話すか」「誰が決めるか」です。ここが曖昧だと、ベンダー側は確認先が増えて止まり、発注側は口頭の指示が増えて混乱します。

窓口は「一本化」する

最低限、発注側・ベンダー側それぞれに窓口（一次窓口）を置きます。

• 発注側窓口：PM/PLのどちらか（できればPM）
• ベンダー側窓口：PMまたはリーダー（責任を持って回答できる人）

窓口以外からの依頼・指示は原則禁止にします。例外が必要なら、例外ルール（緊急時のみ、など）も明記します。

意思決定者を明確にする

「誰が決裁できるか」を決めます。意思決定が曖昧だと、ベンダーは“保留”を増やし、スケジュールが徐々に遅れていきます。
最低限、以下の意思決定は決裁者を固定してください。

• 仕様解釈（どちらの解釈が正か）
• 変更の承認（追加費用・納期変更の可否）
• 受入れ合否（合格/不合格の最終判断）

エスカレーションの条件を決める

揉めたときの上げ先と、上げる条件を決めます。

例）

• 24時間以内に回答が得られない
• 重大障害（業務停止/データ不整合）が発生
• 納期影響が出る見込み（例：2営業日以上の遅れ）
• 追加費用が一定額以上（例：10万円以上）

「揉めたら上に報告する」ではなく、「条件に当てはまったら機械的に報告する」がコツです。

ルール②：会議体とコミュニケーションの型

プロジェクトが荒れるとき、会議が“報告会”になっていることが多いです。会議体は「意思決定の場」「リスクを早期に露出させる場」として設計します。

会議体は最小限でOK

まずはこの2つで十分です。

• 週次定例（60分）：進捗・課題・リスク・次週計画の合意
• 個別打合せ（随時）：技術・仕様・障害など論点別に短時間

定例の目的は「合意すること」です。報告だけなら資料を読めば終わりなので、会議の価値がなくなります。

定例アジェンダの固定化

毎回同じ順序で回すと、抜け漏れが減ります。

例）

1. 先週の宿題の完了確認
2. 進捗（計画との差分と理由）
3. 課題（期限超過・新規・ブロッカー）
4. リスク（兆候、対応方針）
5. 変更（見積・影響・承認要否）
6. 次週の作業と合意事項

議事録は「決定事項」と「宿題」だけでいい

議事録を長文化すると誰も読みません。最小構成はこれです。

• 決定事項（何を、いつ、誰が、どう決めたか）
• 宿題（担当、期限、完了条件）
• 未決事項（次回までの確認項目）

また、議事録の締め方もルール化します。
例：会議後24時間以内に発行、異議は48時間以内、なければ合意とみなす。
これで「聞いてない」「そんな合意してない」を抑止します。

ルール③：課題管理の型

課題管理は“表を作る”より、“動かす”ことが重要です。最小セットでは、次の3点を決めます。

課題の定義を揃える

課題は「放置すると納期・品質・コストに影響する懸念」です。
単なるメモや相談まで課題にすると、管理が破綻します。
目安：期限が必要なものだけ課題にする。

状態（ステータス）を固定する

ステータスは増やすほど混乱します。最小はこれで十分です。

• 新規
• 調査中
• 対応中
• 確認待ち（発注側/ベンダー側どちらの確認か明記）
• クローズ

期限とエスカレーションをセットにする

課題が放置される最大の理由は「期限がない」ことです。

• 起票時に暫定期限を必ず入れる（不明でも仮で入れる）
• 期限超過は定例で必ず取り上げる
• 超過が続く場合はエスカレーション条件に連動させる

加えて、課題にはオーナーを1人に固定します。「みんなで対応」は誰も対応しません。

ルール④：変更管理の型

契約後に最も揉めるのが変更です。変更管理の目的は「変更を止める」ではなく、影響を見える化して意思決定することです。

変更の入口を一本化する

変更要求は窓口に集め、口頭やチャットの指示を“変更扱い”にしないことが重要です。

例）

• 変更要求は変更票（チケット）で起票
• 起票されていない要求は作業に着手しない

影響評価の必須項目を決める

見積の粒度が粗いと揉めます。最低限、次を埋めさせます。

• 追加作業内容（何を作る/直す）
• 工数/費用（根拠も一言）
• 納期影響（いつまでに何日ずれる）
• 品質影響（テスト追加、リスク）
• 代替案（やらない/簡易案/後回し）

承認ルール（閾値）を作る

誰が承認するかを金額・納期で分けると運用しやすいです。

例）

• 追加費用〜5万円：PM承認
• 〜30万円：部門責任者承認
• 30万円超：役員/ステコミ承認
  納期影響も同様に閾値を設定します（例：1週間以上は上位承認）。

ルール⑤：品質・受入れの型

品質トラブルは「基準がない」「受入れが曖昧」で起きます。最小セットでは、受入れの判定基準を先に決めます。

合格条件（DoDのようなもの）を決める

成果物ごとに「合格」の定義を短文で置きます。

例）

• 基本設計：レビュー指摘が“重大0件”、残指摘は期限合意済み
• テスト：必須シナリオ100%実施、重大バグ0件、重要バグは回避策合意
• リリース：運用手順書・監視項目・ロールバック手順が揃っている

レビュー運用（指摘の扱い）を決める

揉めやすいのは「指摘が直ってないのに次に進む」パターンです。

例）

• 指摘は一覧化し、重大/重要/軽微の区分を付ける
• 重大が残っている成果物は原則“未承認”
• 次工程へ進む条件（重大0、重要は合意、など）を固定する

“やり直し”の扱いを明文化する

受入れ不合格のとき、追加費用を請求される/されないで揉めます。
契約条項に依存しますが、運営ルールとしては「不具合起因」「仕様変更起因」を切り分ける基準を決め、議事録で合意するとよいです。

プロジェクト立ち上げ時にやること

プロジェクト開始する前に用意するのが理想です。

• 窓口・意思決定者・エスカレーション条件を1枚にする
• 定例アジェンダ、議事録テンプレ、合意のルールを決める
• 課題表（ステータス・期限・オーナー）を作り、運用開始する
• 変更票のフォーマットと承認フローを決める
• 主要成果物の合格条件を短文で列挙する

この“初期設定”が終わると、以後の揉め事はだいたい手順で処理できます。

うまくいかない典型パターンと処方箋

パターン1：進捗が楽観的で、気づいたら手遅れ

処方箋：進捗は％ではなく「完了条件」で語る。定例では“差分と理由”を必ず言わせる。

パターン2：課題が増えるだけで閉じない

処方箋：オーナー1名固定、期限必須、期限超過は定例で毎回レビュー。

パターン3：変更が雪だるまで納期崩壊

処方箋：起票なし着手禁止、影響評価の必須項目、承認閾値で抑止する。

パターン4：受入れで揉める

処方箋：合格条件を短文化し、重大指摘が残る状態で次工程に進まないルールにする。

まとめ

ベンダーコントロールは、強く言うことでも監視を増やすことでもありません。契約後の現場を安定させる鍵は、「誰が決めるか」「どう合意するか」「課題・変更・品質をどう回すか」を最小限の運営ルールとして固定することです。

最小セットは次の5つでした。

1. 窓口・意思決定・エスカレーション
2. 会議体と議事録・合意の型
3. 課題管理（起票〜クローズ）
4. 変更管理（影響評価と承認）
5. 品質・受入れ（合格条件と指摘運用）

この5つをプロジェクト開始時に整えるだけで、「言った言わない」「押し付け合い」「静かな遅延」が激減します。小さく始めて、プロジェクトに合わせて必要なルールだけ育てていきましょう。