ベンダー管理チェックリスト｜進捗・品質の確認項目と定例テンプレート

ベンダー管理とは、開発や運用を委託した相手（ベンダー）と、成果物・進捗・品質・変更を合意どおりに進めるための発注側の活動です。 ベンダーコントロール、外注管理、委託先管理とも呼ばれます。

この記事では、発注してから納品を受けるまでの期間に絞り、場面ごとのチェックリスト、週次定例の型、進捗報告で出してもらう項目を載せます。題材は架空の「備品予約システム」の開発委託です。表はMarkdownとタブ区切りの両方で載せているので、そのまま貼って使えます。

確認環境：チェックリストの項目数は Python 3.11 で数えています（確認日 2026-10-05）。契約に関する記述は一般的な項目の例であり、法律上の助言ではありません。実際の契約は、自社の規程と法務担当の確認に従ってください。

この記事の結論

• 発注側が握るのは「完了条件」「進捗の根拠」「変更の合意」の3点です。
• 作業のやり方には踏み込みません。 手順や担当の割り振りは受託側が決め、発注側は結果を確かめます。
• 進捗は「◯%」ではなく、完了した成果物と、その根拠になる記録で確かめます。
• 依頼は受託側の窓口（責任者）へ伝えます。 作業者一人ひとりへ直接指示する形は取りません。

ベンダー管理の早見表（発注側が握る3点）

ベンダー管理チェックリスト（4場面・40項目）

各項目は「はい／いいえ」で答えられる形にしています。「根拠にする資料」の欄に書いた物を見て判定します。

契約前（10項目）

着手時（10項目）

週次（10項目）

納品時（10項目）

タブ区切り版（表計算ソフトに貼り付け）

「結果」に ○／×、「確認日」に日付を書き込んで使います。

No. 場面  確認項目    根拠にする資料 結果  確認日
1   契約前 契約の種類と工程ごとの区分が、契約書に書かれている   契約書、見積書     
2   契約前 成果物の一覧と、それぞれの完了条件が書面にある 成果物一覧       
3   契約前 検収の方法・期間・合格の基準が決まっている   契約書、受入基準        
4   契約前 発注側が用意するもの（環境、データ、回答期限）が書かれている  役割分担表       
5   契約前 変更が出たときの手続きと、費用・期日の決め方がある   変更管理の手順     
6   契約前 報告の頻度と、報告に含める項目が合意されている コミュニケーション計画     
7   契約前 再委託の可否と、する場合の条件が決まっている  契約書     
8   契約前 成果物の権利の扱いと、秘密情報の範囲が決まっている   契約書     
9   契約前 受託側の体制と責任者、連絡窓口が示されている  体制図     
10  契約前 納品後の不具合対応の範囲と期間が決まっている  契約書     
11  着手時 キックオフで目的・範囲・期日を双方で読み合わせた    キックオフの議事メモ      
12  着手時 マイルストーンと判定者が一覧になっている    マイルストーン一覧表      
13  着手時 受託側の計画（WBSまたは工程表）を受け取り、内容を確かめた  工程表     
14  着手時 連絡窓口を双方1人ずつ決め、依頼は窓口を通すと決めた  体制図     
15  着手時 週次定例の曜日・時間・参加者・アジェンダを決めた    定例の開催案内     
16  着手時 進捗報告の様式を決め、初回の記入例を確かめた  進捗報告の様式     
17  着手時 課題・質問を1つの管理表で双方が見られる    課題管理表       
18  着手時 発注側の回答期限の目安を決めた（例：3営業日以内）   コミュニケーション計画     
19  着手時 エスカレーションの経路と重大度の基準を共有した エスカレーション基準表     
20  着手時 環境・アカウント・資料の受け渡しが完了した   受け渡しの記録     
21  週次  進捗が、完了した成果物や件数で示されている   進捗報告        
22  週次  「完了」が、合意した完了条件で判定されている  進捗報告、レビュー記録     
23  週次  計画との差（日数・件数）と、その理由が書かれている   進捗報告        
24  週次  次のマイルストーンの見通し（間に合う／要調整）が示されている  進捗報告        
25  週次  品質の数値（レビュー指摘、テスト消化、不具合の件数）がある   品質報告        
26  週次  新しい課題・リスクが管理表に起票されている   課題管理表       
27  週次  発注側の宿題（回答待ち）の件数と期限を確かめた 課題管理表       
28  週次  変更の依頼が口頭で終わらず、変更管理に載っている    変更管理表       
29  週次  体制の変更（担当の交代、稼働の増減）が無いかを確かめた 進捗報告        
30  週次  決定事項と宿題を議事メモにして、当日中に双方で確かめた 議事メモ        
31  納品時 納品物が成果物一覧と1対1でそろっている    納品書、成果物一覧       
32  納品時 版・日付・ファイル名が納品書と一致している   納品書     
33  納品時 受入テストの全シナリオを、発注側が自分で動かした    受入テスト結果     
34  納品時 受入基準の各項目に合否が付いている   受入基準、判定記録       
35  納品時 残っている不具合の一覧と、対応の期日が合意されている  不具合一覧       
36  納品時 設計書・手順書が、納品されたものの内容と一致している  設計書、手順書     
37  納品時 ソースコード・設定・構築手順で、環境を作り直せる    構築手順書       
38  納品時 アカウント・権限・貸与物の返却と停止が済んでいる    返却の記録       
39  納品時 変更管理表の全件が、反映済みか見送りかに決着している  変更管理表       
40  納品時 検収の結果を、期限内に書面で通知した  検収書     

チェックリストの使い方

週次定例のアジェンダ（30分の例）

定例は、進捗報告を読み上げる場ではなく、決めることを決める場にします。報告は前日までに受け取り、当日は差分と判断に時間を使います。

定例の決まり（例）

• 進捗報告は、定例の前営業日の17時までに送ってもらう。
• 参加者は双方の窓口と、その週の議題に関わる人だけにする。
• 議事メモは発注側が書き、当日中に送る。受託側は翌営業日までに内容を確かめる。
• 定例の場で出た変更の話は、その場で決めきらず、変更管理表に載せてから判断する。

議事メモのテンプレート

# 備品予約システム 週次定例 議事メモ

- 日時：2026-10-09（金）10:00〜10:30
- 参加者：【発注側】佐藤（窓口）、高橋 ／ 【受託側】田中（責任者）、伊藤
- 記録：佐藤

## 1. 決定事項
| No. | 決めたこと | 理由 |
|---|---|---|
| 1 | 予約の取消期限は「利用開始の1時間前まで」とする | 利用部門の回答による |
| 2 | 通知文面の追加は、影響の見積もりを見てから判断する | 期日への影響が分かっていないため |

## 2. 宿題
| No. | 内容 | 担当 | 期限 |
|---|---|---|---|
| 1 | 取消期限の仕様を画面設計書に反映する | 田中 | 10-14 |
| 2 | 通知文面の追加の影響（工数・期日）を見積もる | 田中 | 10-16 |
| 3 | 帳票の見本データを渡す | 佐藤 | 10-13 |

## 3. 進捗
- 状態：注意
- 完了：画面設計書 4本（レビュー記録 No.31〜34）
- 計画との差：計画6本に対し4本。差2本は仕様の回答待ちだった（本日回答済み）
- 次のマイルストーン：M3 基本設計レビュー完了（10-30）は間に合う見通し

## 4. 品質
- レビュー指摘 12件（重要度「高」1件は対応済み）

## 5. 課題・リスク
- 新規2件、継続5件、期限超過0件（課題管理表を参照）

## 6. 変更の依頼
- No.7 通知文面の追加：影響を見積もり中（宿題2）

## 7. 次回
- 2026-10-16（金）10:00〜10:30

決定事項と宿題を先頭に置くのがポイントです。後から読む人は、まずこの2つを探します。

進捗報告で必ず出してもらう項目（12項目）

報告の様式は、着手時に合意しておきます。次の12項目があれば、発注側が握る3点（完了条件・進捗の根拠・変更の合意）を毎週確かめられます。

タブ区切り版

No. 項目  書いてもらうこと    記入例
1   対象期間    いつからいつまでの報告か    2026-10-05〜10-09
2   全体の状態   順調／注意／遅れ の3つから1つ    注意
3   今週完了した成果物   完了条件を満たした物の名前と件数    画面設計書 4本（レビュー済み）
4   完了の根拠   完了と判定した記録の場所    レビュー記録 No.31〜34
5   計画との差   計画に対する日数・件数の差と理由    計画6本に対し4本。差2本は仕様の回答待ち
6   次のマイルストーンの見通し   期日と、間に合う／要調整    M3（10-30）は要調整。回答が10-14までに来れば間に合う
7   品質の数値   レビュー指摘・テスト消化・不具合の件数 指摘12件（うち重要度「高」1件、対応済み）
8   課題・リスク  新規と継続の件数、期限が近いもの    新規2件、継続5件。期限超過0件
9   発注側への依頼 回答・判断・資料の依頼と期限  予約の取消期限の仕様を10-14までに回答
10  変更の依頼   今週出た変更と、その扱い    1件（通知文面の追加）。変更管理表 No.7 で影響を見積もり中
11  体制の変更   担当の交代、稼働の増減 なし
12  来週の予定   完了させる成果物の名前と件数  画面設計書 残り2本、帳票設計書 3本

報告の読み方：3つの質問

「進捗率80%」のような数字だけの報告は、根拠を確かめにくい形です。「何本のうち何本が、どの記録で完了と判定されたか」に言い換えてもらうと、同じ報告から次の動きが決められます。

進捗と品質の確かめ方：直す前と直した後

最後の行が、冒頭の「作業のやり方には踏み込まない」に当たります。満たしてほしい条件を伝え、方法は受託側に任せます。 方法を指定する必要があるとき（社内の標準に合わせるなど）は、契約前に条件として書いておきます。

よくある質問

Q. ベンダー管理とは何ですか？ A. 委託した相手と、成果物・進捗・品質・変更を合意どおりに進めるための発注側の活動です。完了条件、進捗の根拠、変更の合意の3点を確かめることが中心になります。

Q. ベンダー管理とベンダーコントロールの違いは何ですか？ A. ほぼ同じ意味で使われます。この記事では、発注後から納品までに発注側が行う確認と合意の活動を、まとめてベンダー管理と呼んでいます。

Q. ベンダーの進捗が分からないときはどうすればよいですか？ A. 完了した成果物の名前・件数と、完了と判定した記録の場所を報告してもらいます。割合だけの報告を、成果物と記録に言い換えてもらうと状況が見えます。

Q. 委託先の担当者に直接指示してもよいですか？ A. 依頼は受託側の窓口（責任者）へ伝えます。作業者への指示や管理は受託側が行うものなので、優先順位の変更や追加の依頼も窓口を通します。

まとめ

• 発注側が握るのは、完了条件・進捗の根拠・変更の合意の3点です。
• 作業のやり方は受託側に任せ、満たしてほしい条件と結果を確かめます。
• チェックリストは契約前・着手時・週次・納品時の4場面、計40項目。根拠にする資料を見て判定します。
• 週次定例は30分・6議題。決定事項と宿題を議事メモの先頭に書きます。
• 進捗報告は12項目。完了した成果物と、その根拠になる記録を必ず出してもらいます。
• 依頼は窓口へ。変更は変更管理表に載せてから判断します。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。