今回の問いはこれです。RFPの要件ごとに、提案書の何ページで答えているかをすぐに示せますか？
評価者が、片側に自社の提案書、もう片側にRFPを広げている場面を想像してください。要件4.3.2まで来たところで、ページをめくり始めます。答えはたぶんどこかにあります。二つの章に分かれているかもしれませんし、顧客の言葉ではなく自社の言葉で書かれているかもしれません。見つからなければ、点数はつけられません。この瞬間を防ぐ道具がコンプライアンス・マトリクスです。すべての要件を並べ、提案書の中でその答えがある場所を指し示す表です。チームにとってはチェックリストであり作業計画、評価者にとっては地図です。
このシリーズでは、APMP Foundation Study Guideに要約されたAPMP Body of Knowledgeを順に読み解いています。第1回ではコンプライアンスとレスポンシブネスの違いを説明し、コンプライアンス・マトリクスとレスポンス・マトリクスを並べて紹介しました。今回からは、戦略を実際の成果物に変えるCreate Deliverablesのパートに入ります。最初のテーマはマトリクスそのものです。何を入れるのか、いつ作るのか、誰が使うのか、どうやって正確に保つのかを見ていきます。
コンプライアンス・マトリクスとは何か、誰のためのものか
Body of Knowledgeは、コンプライアンス・マトリクスを二つの仕事をする道具として説明しています。提案書の作成過程を管理することと、顧客に準拠を示すことです。どちらも一つの単純な構造に支えられています。左に要件、右に答えがある場所です。
そのため、マトリクスは二種類の読み手のためのチェックリストになります。
- 提案チームは、すべての要件に回答、担当者、目次上の位置があるかを確かめます。
- 評価者は、要件から自社の回答へ迷わずたどり着きます。
二人目の読み手は軽く見られがちです。提案書の評価だけが仕事という評価者はまれで、多くの評価者は案件の技術分野の専門家でもありません。Study Guideの助言は、評価者の作業をできるだけ速く楽にすること、そしてRFPが求めていなくてもマトリクスを入れることです。置き場所は、RFPの要件を扱う最初の章の前です。評価者が本文より先に地図を手にするようにするためです。
顧客がRFPと一緒に独自のマトリクスを渡してくることもあります。そこに並ぶ項目は顧客の必須事項と受け止めてください。ただし、それがすべてだとは思わないでください。この点は後で改めて取り上げます。
マトリクスで押さえるべき準拠の三つの層
「準拠」はよく「要件に答えたか」に狭められます。Body of Knowledgeはもっと広く捉えています。準拠した提案書は、経験があり、プロフェッショナルで、付き合いやすい相手だという印象を顧客に与えます。その印象は三つの層にかかっています。
| 層 | 対象 | 確認の問い |
|---|---|---|
| 提出指示 | 提案書をどう出すか | 指定の形式と梱包・提出方法に従ったか？すべての質問に答え、すべての様式と添付を埋めたか？正しい相手に、正しい場所へ、期限までに出すか？ |
| 要件 | 顧客がしてほしいこと | そのサービスを本当に提供できるか？提案する要員は本当に参加できるか？各要件の背後にあるニーズに応えたか？満たせない要件はあるか？ |
| 社内の準拠 | 自社組織のルール | 法務などの社内要件を満たしたか？案件をCRMなど決められた場所に登録したか？適切な人と管理階層が関わったか？提出の承認を得たか？ |
二つ目の層だけを追うマトリクスでは、一つ目の層で負けることがあります。様式が一枚抜けていた、アップロードが遅れた、という負け方です。三つ目の層で負けることもあります。誰も承認していない提案書が出てしまう場合です。そのため多くのチームは、提出指示と社内承認を独立した行や同じファイルの別シートで管理し、提出前に確認する場所を一つにまとめています。
書き始める前に作る
このパートで最も大切な原則はタイミングです。コンプライアンス・マトリクスは、目次と同じくRFPの構成をそのままなぞるべきもので、目次と並行して、内容の計画と執筆が始まる前に作ります。草案を書き終えてから作るのは、壁を建て終えてから間取り図を描くようなものです。問題の場所はわかりますが、何かを動かすにはもう高くつきます。
早く作ったマトリクスは、索引にはできない仕事をします。
- 執筆者の行動計画になります。執筆者は、自分の章が答えるべき要件を正確に把握できます。
- RFPを束に分けます。要件をまとめて適切な人に回せます。原価や価格を見積もる人も含まれます。
- 責任をはっきりさせます。要件ごとに名前がつくので、ビッドマネージャーやプロポーザルマネージャーのフォローアップがずっと楽になります。
- 漏れの可能性を減らします。穴が、まだ埋める時間のあるうちに空欄として見えてきます。
目次を組んでいる間に、行ごとに問うべきことがあります。どの章で答えるのか？誰が書くのか？レビュアーはどこで確認するのか？完了をどう判断するのか？
コンプライアンス・マトリクスは最後に付ける索引ではありません。最初から見ながら建てる設計図です。
RFPを一行ずつ分解する
マトリクスづくりは、よくシュレッディング（分解）と呼ばれる作業から始まります。RFPを一行ずつ読み、要件を一つずつ別の行に切り出す作業です。英語のRFPならshall、must、willといった義務表現、日本語のRFPなら「〜すること」「〜しなければならない」といった表現が目印です。identify（明示する）、describe（説明する）、provide（提出する）、demonstrate（実証する）、discuss（論じる）といった指示動詞も同じです。
要件は群れで現れることがよくあります。次はこの記事のために書いた段落で、サービス案件のRFPによくある形です。
RFP 3.4 移行。受託者は、移行を主導する主要要員を明示し、現行事業者からサービスを中断なく引き継ぐ計画を説明しなければならない。提案者は記入済みの様式C（移行スケジュール）を提出し、移行期間中は週次の状況報告書を提出すること。
この段落を一行のままにすると、一部だけ答えてしまいがちです。執筆者は引き継ぎ計画を詳しく書き、要員には軽く触れ、様式は忘れてしまいます。分解すれば、それぞれ割り当て、書き、確認できる四つの行になります。
| RFP番号 | 要件（顧客の言葉どおり） | 提案書の章 | 担当者 | ステータス |
|---|---|---|---|---|
| 3.4 (a) | 移行を主導する主要要員を明示 | 2.1 移行体制 | 人事担当 | 草案 |
| 3.4 (b) | 現行事業者からサービスを中断なく引き継ぐ計画を説明 | 2.2 移行方針 | ソリューションアーキテクト | レビュー中 |
| 3.4 (c) | 記入済みの様式C（移行スケジュール）を提出 | 添付C | 入札コーディネーター | 未着手 |
| 3.4 (d) | 移行期間中の週次状況報告書を提出 | 2.4 管理と報告 | デリバリーマネージャー | 草案 |
Study Guideは分解の利点をさらに二つ挙げています。執筆者は何に答えるべきかの正確な一覧を、レビュアーは何を確認すべきかの正確な一覧を手にできます。そして要件がそれぞれ独立した行になっているので、RFPの修正やアウトラインの変更があっても、表全体を作り直さず数セルを直すだけで済みます。
一覧にない要件を探す
RFPの番号付き要件や、顧客が渡したマトリクスにすべてが入っていると思い込まないでください。Body of Knowledgeは、要件と明示されていない要件もあると警告しています。それらは事業の背景、現状の課題、業務範囲の一文といった本文の説明の中にあります。「現在、担当者は毎月かなりの時間を報告書の手作業での突き合わせに費やしている」といった一文が、顧客が発注した本当の理由かもしれません。
こうした要件を見つけて答えることには、準拠の穴を埋める以上の効果があります。文書全体を読んで理解したことが顧客に伝わり、第1回で扱ったレスポンシブネスへ一歩近づきます。
並べ替えられるスプレッドシートで管理する
Body of Knowledgeはスプレッドシートを勧めています。理由は実用的で、マトリクスは絶えず変わるからです。章番号が変わったり、修正通知で要件が書き換えられたりしたら、そのセルを直して並べ替えればよいのです。並べ替えを切り替えれば、一つの表で人ごとに違う問いに答えることもできます。
| 並べ替えの基準 | 答える問い | 主に尋ねる人 |
|---|---|---|
| RFP順 | 顧客の要件が、顧客の順序で漏れなく追跡されているか？ | ビッドマネージャー、最終準拠チェック担当 |
| 提案書の章 | 自社の目次の各部分は何に答えるべきか？ | 執筆者、ボリュームリード |
| 担当者 | それぞれが何をいつまでに担当するか？ | ビッドマネージャー、各執筆者 |
| ステータス | 未着手、草案、レビュー中のものはどれか？ | ビッドマネージャー、経営層 |
第1回では基本的な列の構成を紹介しました。実務では、章ごとのページ制限や、要件に関係する評価項目を加えるチームも多くあります。執筆者が、何を書くべきかと、それがどう採点されるかを一緒に見られるからです。
顧客の番号と言葉に従う
評価者がマトリクスをずっと使いやすくなる習慣が二つあります。
RFPの番号体系を使います。マトリクスでも、提案書そのものでもです。Study Guideは、これが自社の望む話の流れとぶつかることがあると認めていますが、そうすることで評価者は行ったり来たりせずにチェックリストを順にたどって採点できます。自社のストーリーに別の流れが必要なら、顧客の構成を捨てるのではなく、その構成の中で語ってください。
顧客の言葉を使います。マトリクスで要件を自社の用語に言い換えないでください。そして各行を、RFPが使っている動詞で始めてください。動詞が、評価者の期待する答えの種類を執筆者に伝えるからです。
| RFPがこう言っていたら… | 評価者が期待するのは… |
|---|---|
| 明示する（Identify） | 一般的な説明ではなく、具体的な名前、項目、役割 |
| 説明する（Describe） | どう機能するか：手順、順序、責任 |
| 提出する（Provide） | 成果物：様式、計画書、証明書の添付または記載 |
| 実証する（Demonstrate） | 機能することの証拠：実績、レファレンス、プルーフ・ポイント |
| 論じる（Discuss） | 選択肢とトレードオフを含む自社の判断の根拠 |
自社の用語に言い換えた見出し
「2.2 シームレス・マイグレーション手法」――これがRFP 3.4 (b)への答えだと、評価者が自分で突き止めなければなりません。
顧客の用語を使った見出し
「2.2 サービスを中断しない引き継ぎ計画（RFP 3.4 b）」――評価者は自分の言葉どおりの要件と、その番号をすぐに目にします。
一つのマトリクス、五人の読み手
ビッドマネージャーしか開かないマトリクスは、半分しか使われていません。Body of Knowledgeは、同じ文書をチームの各メンバーがどう読むかを整理しています。
| 役割 | マトリクスの使い方 |
|---|---|
| ビッドマネージャー／プロポーザルマネージャー | 提案内容のマスタープランであり、各要件を原価・価格の算定や回答を担う人に回すための道具 |
| ボリュームリード | 担当ボリュームの要件がすべて扱われているかを確かめるチェックリスト |
| 執筆者 | 各章に何を書くべきかを示すガイド |
| レビュアー | 各章に何があるべきかを定めた評価ツール |
| 経営層 | 計画とその背後にある戦略をひと目で見る概要 |
Study Guideのまとめにあるとおり、だからマトリクスは回答割り当て表の役割も果たします。ビッドマネージャーが多くの協力者に仕事を割り振り、一つずつフォローするための手段です。
提出まで最新に保つ
マトリクスを作るのは計画の仕事で、正確に保つのは提案書を出すまで続く仕事です。Body of Knowledgeは、更新が必要になる変化を次のように挙げています。
- 目次：章の名前、番号、順序、ページ配分が変わったとき。
- チーム：章の執筆者が変わったとき。
- RFP：指示、評価基準、要件、追加通知が変わったとき。
マトリクスの更新責任を、チームの一人にはっきり任せてください。古いマトリクスは、ないより悪いものです。チームがそれを信じて動き続けるからです。レビューも、カラーチームのチェックも、最終の準拠確認も、基準にする表と同じ程度にしか正確になりません。
失格要件と部分準拠の行に注意する
マトリクスを確定する前に、特に見ておくべき行が二種類あります。一つは失格事由とされている要件です。一つでも落とすと提案書が評価さえされない可能性があるので、はっきり印をつけて最初に確認してください。もう一つは「部分準拠」や「非準拠」とした行です。一つずつ顧客の要件と照らし合わせ、ソリューションや回答を完全準拠に近づけられないか検討してください。残る差を正直に説明する方法は第1回で扱いました。
提出版：レスポンス・マトリクス、対照表、そして売り込みの道具
チームが使うマトリクスと、提出する表は同じ文書ではありません。提出版はBody of Knowledgeではレスポンス・マトリクスと呼ばれ、実務ではクロスリファレンス表や対照表とも呼ばれます。担当者やステータスは外し、評価者に必要なものだけを残します。要件、RFPの番号、そして自社が答えている場所です。ページ制限で別の表を入れる余裕がなければ、第1回で説明したように、同じ参照を見出しに入れることもできます。
RFPがこの表の様式を指定しているなら、そのとおりに従ってください。ただしStudy Guideによれば、多くのRFPは様式を指定しておらず、そのおかげでこの表は場所を指す以上の仕事ができます。たとえば主要な要件の横に顧客にとっての便益を短く書く列を置けば、味気ない索引が、ウィンテーマがもう一度現れる場所になります。
| RFP番号 | 要件 | 回答箇所 | 顧客にとっての意味 |
|---|---|---|---|
| 3.4 (b) | サービスを中断なく引き継ぐ計画の説明 | 2.2節、14–17ページ | 拠点ごとの段階移行と各段階の切り戻し計画で、窓口サービスが止まらない |
| 5.1 | 24時間のサービスデスク対応 | 3.1節、22–24ページ | 昼も夜も同じチームが対応し、夜間の別チームに問い合わせが引き継がれない |
追加の列は短く、事実にもとづいて書いてください。すべての評価者が必ず使う表に入るので貴重な場所ですが、表を見渡しにくくしてはいけません。
よくある失敗
- マトリクスを最後に作る。その時点では穴を記録できるだけで、防ぐことはできません。
- 顧客の一覧を信じ込む。RFPの番号付き要件や顧客のマトリクスの項目数は、本当の要件の数と一致しないことがあります。本文の説明も読んでください。
- 更新しない。修正通知が届き、目次が変わり、執筆者が交代しても、誰も表を直さない。その瞬間からチームは間違った計画で動いています。
- 顧客の言葉を言い換える。自社の用語のほうが良くても、評価者のチェックリストと照合しにくくなります。
- 準拠で止まる。Body of Knowledgeは、コンプライアンスとレスポンシブネスは重要でも、顧客が考慮するのはそれだけではないとはっきり述べています。完全に準拠した提案書にも、差別化要因、便益、勝てる価格が必要です。
次の提案書のためのチェックリスト
- RFP全体を読みます。何かを作る前に、事業背景や業務範囲の説明まで読みます。
- 一行ずつ分解します。義務表現や指示動詞ごとに一行、RFPの番号と言葉はそのまま。
- 本文で見つけた隠れた要件を加え、失格要件に印をつけます。
- 目次と一緒にマトリクスを作ります。執筆前に、すべての行に提案書の章、担当者、ステータスをつけます。
- 三つの層をすべて扱います。提出指示、要件、社内承認。
- スプレッドシートで管理し、役割ごとに必要な並べ替えビューを共有します。
- 更新担当を一人決め、目次・チーム・RFPが変わるたびに直してもらいます。
- 確定前に、部分準拠と非準拠の行をすべて見直し、埋められるものは埋めます。
- レスポンス・マトリクスを提出します。要件に答える最初の章の前に置くか、見出しにRFP番号を入れます。顧客の様式があればそのとおりに、なければ短い便益の列を加えます。
Contrlでは
コンプライアンス・マトリクスでいちばん時間がかかるのは最初の作業です。RFPを分解し、要件ごとにどこで答えるかを決めることです。ContrlにRFPをアップロードすると、要件、指定された目次、評価基準を抽出し、要件ごとにその目次のセクションへ対応づけるので、一ページも書かないうちにマトリクスができあがります。スライドが書かれると、各ページが自分の答えるRFP要件を示すため、要件とページのつながりは、誰かが忘れずに直さなければならない別の表ではなく、ページの上にそのまま残ります。
次回予告
マトリクスは、すべての要件がどこで答えられるかを教えてくれます。数字を求める要件も同じです。第13回はコスト・価格データ（Cost and Pricing Data）を取り上げます。価格の裏に何があるのか、なぜ公共と民間の顧客ではそれを見せるよう求めるやり方がこれほど違うのか、そして価格設定の論理を示すことがなぜ提案書全体の信頼性を高めるのかを見ていきます。
この記事は、APMP Body of Knowledgeを要約したAPMP Foundation Study Guide 第4.2版（© 2025 APMP）にもとづく独立した学習用の解説です。原典を言い換え、解説したもので、APMPの承認を受けたものではありません。RFPの例文とその分解した行、並べ替え基準と指示動詞の表、見出しの比較、隠れた要件の一文、便益の列の例は、この記事のために書いたもので、例示です。正式な本文と資格についてはapmp.orgをご覧ください。