ベンダーに開発を委託しているプロジェクトで、こんな状態になっていませんか？
- 「定例で進捗報告を聞いて、問題なさそうならOK」
- 「課題が出たら、ベンダーに対応をお願いする」
- 「成果物は納品されてから確認する」
一見、管理しているように見えます。でも実態は、報告を聞いているだけです。
本当は、
「もっと早く手を打てたんじゃないか」
「リリース直前になって品質問題が噴出するのを防げたんじゃないか」
と思ったことがある方も多いのではないでしょうか。
報告ベースの管理は、事後対応にしかなりません。問題が起きてから動くので、常に後手に回ります。
- 報告を聞いているだけでは、問題の予兆に気づけない
- 事後対応では、手戻りコストが膨らむ
- 結果として、QCDが崩れていく
この記事では、報告ベースの受動的な管理から、フェーズに応じて介入度を変える能動的なベンダー管理への転換を、実務経験をもとに解説します。
この記事でわかること
- ベンダー管理がなぜ必要なのか
- ベンダー管理の全体像
- フェーズ別の管理ポイントとよくあるトラブル
ベンダー管理はなぜ必要なのか？
「ベンダーとは契約を結んでいるのだから、成果物はちゃんと出てくるはず」
そう思っている方もいるかもしれません。確かに、請負契約であれば、ベンダーには成果物を納品する義務があります。
しかし、契約があるからといって、プロジェクトのQCDが守られるとは限りません。
なぜなら、プロジェクトは不確実性の塊だからです！
- 要件が途中で変わる
- 想定外の技術的課題が出てくる
- 関係者間の認識がズレたまま進む
こうした不確実性は、契約書では吸収できません。契約はあくまで「何を、いつまでに、いくらで」という枠組みを定めたものです。その枠組みの中で日々発生する不確実性に対処していくのは、プロジェクト運営の仕事です。
だからこそ、発注者側の人間がベンダーの作業状況に介入し、QCDを守るための管理を行っていく必要があります。
ベンダー管理の目的は、契約を監視することではありません。
プロジェクトのQCDを守るために、発注者として能動的に介入すること です。
ベンダー管理とは、「報告を受けて、問題があれば指摘する」という受動的な作業ではなく、フェーズや状況に応じて介入の深さを変えながら、QCDをコントロールしていく能動的なマネジメント です。
ベンダー管理の全体像
ベンダー管理のスコープは、契約開始から終了までです。その間にやることは、大きく3つの管理軸に分けられます。
ベンダー管理の3つの軸
- 進捗管理 ：計画通りに進んでいるかをチェックする
- 課題管理 ：発生した課題を可視化し、対処する
- 品質管理 ：成果物が求める品質を満たしているかを確認する
この3つの管理軸は、すべてのフェーズで均等に力を入れるものではありません。フェーズによって、重点的に管理する軸が変わります。 これが、ベンダー管理を能動的に行うための重要なポイントです。
次のセクションでフェーズごとに詳しく解説しますが、まずは全体像として「フェーズによって力の入れどころが違う」ということを押さえていきましょう。
契約形態による介入度の違い
もう一つ、ベンダー管理で重要な前提があります。それは、契約形態によって介入の深さを変えるということです。
準委任契約の場合、ベンダー側に成果物の完成責任がありません。極端に言えば、作業時間分の対価を支払う契約です。
つまり、発注者側が介入しなければ、時間だけが過ぎて成果物が出来上がらないという事態が起こり得ます。しかも、その場合に契約上ベンダーを責めることは難しい。追加契約で対応するしかなくなります。
だからこそ、準委任契約のフェーズ、特に要件定義などの上流工程では介入を深めることが重要です。
一方、請負契約では成果物の完成責任がベンダー側にあります。そのため、相対的に介入度は低くなります。ただし、「請負だから任せておけばいい」というわけではありません。品質を確認せずに納品を受け取ると、後から大きな手戻りが発生するリスクがあります。
フェーズ別：ベンダー管理のポイント
ここからは、フェーズごとに何を重点的に管理し、どんなアクションを取ればいいかを解説します。
契約〜キックオフ
このフェーズでは、ベンダー管理の土台となるルールを整備します。ここでルールを作っておくと、その後の管理がスムーズに回ります。
キックオフまでに決めておくことは、主に3つです。
キックオフまでに決めること
- 報告・共有のルール ：いつ、どのフォーマットで進捗と課題を報告するか
- コミュニケーションのルール ：どのチャネルでやり取りするか
- ドキュメント管理のルール ：どこに何を格納するか
特に報告のルールは、定例会議の頻度・アジェンダ・報告フォーマットまで合意しておくのがおすすめです。「何を報告すればいいか」が曖昧だと、ベンダーからの報告も曖昧になり、問題の予兆を掴みにくくなります。
また、このタイミングで契約形態を確認し、フェーズごとの介入度の方針を決めておくことも大切です。
調査・要件定義
このフェーズでは、品質管理を重点的に行います。
調査・要件定義は、多くの場合、準委任契約で行われます。つまり、成果物の完成責任はベンダー側にありません。だからこそ、発注者側の介入度を深くする必要があります。
このフェーズは、成果物や作業内容が曖昧になりがちです。「何を、どこまで、どの粒度で作ればいいか」が明確でないまま進むと、後続の設計・開発で大きな手戻りが発生します。
やるべきことはこんな感じです。
- フェーズ開始時点で、成果物の品質基準（何を、どの粒度で作るか）をベンダーとすり合わせる
- フェーズを通じて、その品質基準をクリアできているかを定期的にチェックする
品質基準のすり合わせは、「完了条件を決める」だけでは不十分です。完了条件は決めていても、その条件が意味する粒度について認識がズレていると、結局は手戻りが発生します。 この点については、後述の実体験パートで詳しく触れます。
よくあるトラブル：開発に入ってから要件定義の不備が発覚する
要件定義の品質管理が甘いと、設計・開発フェーズで「要件が足りない」「粒度が荒い」という問題が噴出します。このタイミングでの手戻りは、スケジュールとコストに大きなインパクトを与えます。
設計
このフェーズでは、品質管理と課題管理を重点的に行います。
設計フェーズでやるべきことの中心は、成果物（設計書）のレビューです。要件を設計に落とし込む過程で、要件の解釈違いや考慮漏れが発生しやすいからです。
発注者側でできることとして、次のアクションが効果的です。
- 設計書のレビュー ：要件に対して設計が網羅的になされているかを確認する
- 要件内容の説明・業務レクチャー ：ベンダーが業務を十分に理解していない場合、設計の精度が落ちる。必要に応じてフォローする
- 課題の可視化と管理 ：要件を設計に落とし込む過程で課題が多く出る。ベンダーの話を聞き、課題を可視化した上で管理を進める
よくあるトラブル：設計の考慮漏れが後続テストで発覚する
設計フェーズで見逃した考慮漏れは、テストフェーズになるまで見えません。発覚が遅れるほど修正コストは大きくなるため、可能な限り発注者側でも設計レビューを行い、品質を担保することが重要です。
開発・テスト
このフェーズでは、進捗管理と課題管理を重点的に行います。
開発フェーズ、特にテストに入ってからは課題が山積しやすくなります。バグ、仕様の解釈違い、環境の問題など、さまざまな課題が一気に顕在化するタイミングです。
課題が増えれば、当然それに引きずられて進捗も遅延しやすくなります。
だからこそ、このフェーズでは定例会議などで予兆を早期にキャッチし、問題が大きくなる前に対処していくことがポイントです。
- 定例で進捗の遅れや課題の増加傾向をチェックする
- 課題が増えている場合は、原因の分類と優先順位づけを行う
- 必要に応じて、定例の頻度を上げる
よくあるトラブル：課題が山積して炎上する
特に請負契約の場合、「請負なのだからベンダーが対応すべき」と課題対応をベンダーに押し付けがちです。しかし、プロジェクトの成功は発注者・ベンダー双方の協力で成り立ちます。発注者側としても課題対応に介入し、プロジェクト全体で課題に向き合う姿勢が重要です。
実体験：IT要件定義で品質管理に失敗した話
ここで、私自身がベンダー管理で失敗した経験を共有します。
あるプロジェクトで、IT要件定義フェーズをベンダーに委託していました。RFPの段階で、完了条件として「設計に必要な情報を可視化すること」を明記していました。
完了条件は決めていた。ベンダーもその条件に合意していた。だから、大丈夫だと思っていました。
しかし、いざ設計フェーズに入ってみると、要件定義の成果物の情報粒度が荒く、設計に必要な詳細が足りていないことが判明しました。結果として、設計フェーズでIT要件定義と似たような作業をやり直す羽目になりました。
何が問題だったのか。振り返ると、原因は明確でした。
完了条件は決めていたが、その条件が意味する情報の粒度について、発注者側とベンダー側で認識が揃っていなかった。
「設計に必要な情報を可視化すること」という完了条件。この文言自体は間違っていません。しかし、「設計に必要な情報」がどの粒度を指すのか、具体的なイメージが共有されていなかったのです。
この経験から学んだことは、品質管理とは完了条件を決めることではなく、その条件が意味する粒度の認識を揃えることだということです。
品質管理のポイント
- 完了条件を決めるだけでは不十分
- 「その条件が意味する粒度」を、具体例や成果物のサンプルで認識を揃える
- フェーズ開始時に一度すり合わせるだけでなく、途中で定期的にチェックする
もし可能であれば、設計を担当するエンジニアに「どんな情報があれば設計できるか」を具体的に聞いておくと、粒度の基準が明確になります。
まとめ
ここまで、ベンダー管理の目的・全体像・フェーズ別のポイントを解説してきました。
改めて、この記事で伝えたかったことを整理します。
まず、ベンダー管理の目的です。
ベンダー管理の目的は、契約を監視することではなく、プロジェクトのQCDを守るために発注者として能動的に介入すること です。
そして、能動的に介入するためのポイントは次の3つです。
- フェーズによって重点管理する軸を変える ：すべてを均等に管理するのではなく、フェーズの特性に応じて力の入れどころを変える
- 契約形態によって介入度を変える ：準委任では深く、請負では相対的に浅く。ただし放置はしない
- 品質管理は粒度の認識合わせまでやる ：完了条件を決めるだけでなく、その条件が意味する具体的な粒度を共有する
報告を聞いて「問題なさそうですね」で終わるのは、ベンダー管理ではありません！
フェーズと契約形態に応じて介入の深さを変えながら、QCDを守るために能動的に動いていく。それがベンダー管理です。
おまけ：NGパターン
最後に、ベンダー管理でやりがちなNGパターンを紹介します。
NG① ベンダーに丸投げして品質を見ない
「請負で契約しているから、成果物はベンダーの責任」
そう割り切って、プロジェクト期間中はほとんど介入しないケースです。定例で報告を聞くだけ。成果物のレビューもしない。
確かに、請負契約では成果物の完成責任はベンダー側にあります。しかし、成果物が納品されることと、その品質がプロジェクトの要求を満たしていることは別の話です。
契約上は成果物が上がってきます。でも、その品質まではコントロールできていない。リリースしてから不具合が噴出する。こうしたケースは、発注者側が品質を確認していれば防げたかもしれません。
請負契約であっても、成果物の品質は発注者側で確認する。丸投げではなく、レビューや品質チェックを通じて、プロジェクトのQCDを守る介入を行うことが大切です。
NG② 発注者の立場で高圧的に振る舞う
「こっちは金を払っている側なのだから」
このスタンスで、ベンダーに対して高圧的な態度を取るケース。私自身も、実際にこうしたプロジェクトを見たことがあります。プロジェクト期間中はベンダーに丸投げしておきながら、リリースで不具合が出たら怒鳴りつける。これは最悪のパターンです。
契約関係はあっても、実際にプロジェクトで働いてくれているのは人です。
高圧的な態度は、ベンダー側のモチベーションを下げ、情報共有を萎縮させます。課題やリスクを早期に共有してもらえなくなると、問題の発見が遅れ、結果としてQCDに跳ね返ってきます。
ベンダーは「管理する対象」ではなく、プロジェクトの目的に向かって一緒に進むパートナー です。一人の人として向き合い、協力して課題に取り組むスタンスが、結果としてQCDを守ることにもつながります。
関連記事