これは何か
ベンダー評価表は、提案を出した複数の会社（ベンダー）を、事前に決めた観点と基準で比べ、選んだ理由を残す成果物です。
提案依頼書（BUS-005）で「何を提案してほしいか」を伝え、その提案を、この評価表で同じ物差しにそろえて比べます。
なぜ作るか
- 「一番安い」「印象が良い」だけで選ぶことを防ぐ
- 評価する人によって、見るところがばらばらになるのを防ぐ
- 選んだ理由と、選んだ会社の弱みを、あとから確かめられるようにする
- 契約で何を決めるか（02-05）を考える材料になる
誰が使うか・いつ作るか
- 作る人：選定を担当するチーム（IT 部門、業務部門、調達・購買の担当など）
- 使う人：選定を決める責任者。評価に参加する各分野の担当
- 一般的には、提案依頼書を出す前に、評価の観点・重み・採点の基準を決めておきます。提案が届いてから基準を決めると、特定の会社に有利な基準になりやすいためです
- アステリア案件で、どのような評価・選定が行われたかは、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
Vendor 4社と担当範囲
- マルチベンダーのプロジェクトで、Vendor は4社
- Vendor A / ネクサスシステムズ — 新基幹アプリケーション
- Vendor B / クラウドブリッジ — クラウド基盤、ネットワーク、IAM、連携、CI/CD、監視
- Vendor C / ファイナンスシステムサービス — FIN-CORE、会計連携
- Vendor D / タイムリンク — 勤怠・工数管理SaaS
- Vendor PM：P-A01 井上 健一（Vendor A）、P-B01 吉田 圭介（Vendor B）、P-C01 大森 裕（Vendor C）
正本にあるのは、4社とそれぞれの担当範囲です。候補になった会社の数、評価の観点・点数、選んだ理由、選定を決めた人と時期は、正本に記載がありません。未確定 この教材では、4社に点数や評価を付けません。
主な項目
一般的には、次の項目で構成します。
- 評価の観点：何を比べるか（要件の理解、実現の方法、体制、実績、品質の管理、移行・運用、費用など）
- 重み：観点ごとの大切さ。合計を決めておく
- 採点の基準：何ができていれば何点か。点数ごとの説明
- 必須条件：満たさなければ点数に関係なく選ばない条件
- 評価と根拠：会社ごとの点数と、その根拠（提案書のどこに書かれていたか）
- 懸念とその扱い：弱み・不明点と、契約や計画でどう補うか
- 評価者と日付：誰が、いつ評価したか
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 評価表の一部
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、評価表の構造を学ぶための例です。「候補X社」「候補Y社」は架空の会社で、アステリア案件の Vendor A〜D とは関係ありません。重み・点数もすべて教材上の架空の値です。
| 観点 | 重み | 候補X社 | 候補Y社 | 根拠・メモ |
|---|---|---|---|---|
| 要件の理解 | 20 | 4 | 3 | Y社は連携の要件への回答が一般論にとどまる |
| 実現の方法 | 20 | 3 | 4 | X社は移行の方法の説明が少ない |
| 体制 | 15 | 4 | 2 | Y社は責任者の経験が提案書から読み取れない |
| 品質の管理 | 15 | 3 | 3 | 両社ともテストの終了基準の案がある |
| 移行・運用 | 15 | 2 | 4 | X社は稼働後の支援の期間が書かれていない |
| 費用 | 15 | 3 | 4 | 総額は Y社が低い。運用費の前提が両社で違う |
点数は1〜5の5段階（教材上の例）。重みを掛けた合計だけで決めず、懸念の扱いと必須条件の確認を合わせて判断します。
| 懸念 | 対象 | 扱い（教材上の例） |
|---|---|---|
| 稼働後の支援の期間が不明 | 候補X社 | 質問で確認し、契約に期間を書く |
| 責任者の経験が不明 | 候補Y社 | 面談で確認する。必須条件を満たさなければ対象外 |
| 運用費の前提が違う | 両社 | 同じ前提で再見積もりを依頼する |
読み方
- 評価の観点・重み・採点の基準が、提案を受け取る前に決められているか（日付を見る）
- 点数ごとに根拠が書かれているか。「良い」「弱い」だけになっていないか
- 費用が、同じ前提（範囲・期間・運用の有無）で比べられているか
- 選ばれた会社の弱みが書かれ、その扱いが決まっているか
- 必須条件を満たしているかの確認が、点数とは別にあるか
書き方
- 提案依頼書を出す前に、観点・重み・採点の基準・必須条件を決め、承認を得る
- 評価する人を決め、観点ごとに担当を分ける（1人で全部を見ない）
- 提案書を読み、点数と根拠（提案書の該当箇所）を書く
- 不明点は質問や面談で確かめ、その結果も残す
- 評価者どうしで点数の差が大きい観点を話し合い、理由を残す
- 懸念とその扱いを書き、選定を決める人に渡す
何を書いてはいけないか
- 根拠のない点数
- 提案が届いてから変えた重み・基準（変える場合は理由と承認を残す）
- 費用の前提をそろえないままの金額の比較
どこを見るか
- 基準を決めた日付と、提案を受け取った日付の前後関係
- 費用の比較の前提（範囲・期間・運用費の有無）がそろっているか
- 選ばれた会社の懸念と、その扱い
- 評価者が複数いて、観点ごとの担当が分かれているか
- 選定の最終判断をした人と、その理由
赤信号
- 費用の点数だけが大きく、他の観点の差が見えない
- 選ばれた会社の懸念の欄が空欄
- 評価者が1人だけ
- 提案書にない内容（営業担当の口頭の説明など）で点数を付けている
よくある失敗
- 総額の安さで選び、運用費や追加費用で高くつく（02-04）
- 評価表の懸念を契約に反映せず、あとで責任の範囲が争いになる
- 選んだ理由が残っておらず、担当が替わると説明できない
関係するUnit・成果物・危機演習
- Unit：02-04 一番安い会社を選べばよいのか、02-02 RFIとRFPとは何か、02-03 良いRFPとは何か、02-05 契約で何を決めるのか
- 成果物：BUS-005 提案依頼書（RFP）、ARC-003 システム責任分担表
- 危機演習：この成果物を直接の題材にする危機演習はありません。選ばれた複数のベンダーが一緒に働く場面は、CR03 Vendor AとVendor Cが責任を押し付け合う で体験します（学習上の接続です。正式な対応関係ではありません）
AI WORKFLOW
AIは、提案書の中から、評価の観点ごとに該当する記述を探し出す下書きに役立ちます。
「次の提案書から、評価の観点（要件の理解、実現の方法、体制、品質の管理、移行・運用、費用）ごとに、該当する記述とそのページを抜き出してください。点数は付けず、記述が見つからない観点は『記述なし』としてください。」
REVIEW
- 抜き出した記述とページが、提案書と合っているか
- AIが点数や「優れている」などの評価を付けていないか
- 「記述なし」とされた観点を、人が提案書で確かめたか
- 提案書を AI に渡してよいか（秘密の扱い）を、事前に確かめたか
人間が判断すること
- 評価の観点・重み・必須条件
- 点数とその根拠
- どの会社を選ぶか。懸念を受け入れるか
- 選定の理由として何を残すか
いつ使うか
この教材では STAGE 02｜誰に作ってもらうのか の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この評価表を見た人は、「なぜこの会社を選んだのか」を、金額以外の理由で説明できますか？