ベンダー比較評価項目の作り方 | 大阪府堺市・東京のWEBサイト制作会社

Webサイトのリニューアルや制作会社の乗り換えで失敗しやすいのは、「提案の良し悪し」ではなく「比較の物差し」が揃っていないことです。経営判断で必要なのは、見た目の印象よりも、費用・体制・リスク・成果が一つの基準で説明できる状態です。本稿では、複数社へ提案依頼を出す前に作るべき評価項目と、点数化して決め切る手順を整理します。選定の途中で迷いが出ても、評価基準に立ち戻れるように設計していきます。

ベンダー比較で「評価項目を先に決める」べき理由

提案は「前提」を揃えないと比較できない

RFP＝複数社へ提案を依頼するために、要件と評価基準をまとめた文書です。
RFPが曖昧なままだと、各社が得意領域で提案を組み立てるため「A社はデザイン重視、B社は運用重視、C社は開発重視」のように前提がズレます。ズレた提案を並べても、結局は社内の好みや声の大きさで決まりやすく、後から追加費用や遅延が起きたときに説明ができません。先に評価項目を決める目的は、提案内容を同じ土俵に乗せ、意思決定の根拠を残すことにあります。

「安い提案」が高くつく典型パターン

最初の見積が安いほど、後から費用が増えるとは限りません。ただし「対象外」の範囲が曖昧な提案は、結果として高くつくことがあります。例えば、原稿整理・画像調達・フォーム周りの調整・検証環境の用意などが対象外だと、社内工数が膨らみ、公開が遅れやすい領域です。評価項目を先に決めるのは、価格そのものより「価格が成立している前提」を比較するためでもあります。

意思決定の論点は4つに整理できる

ベンダー選定で経営層が確認したい論点は、突き詰めると次の4つです。

費用：初期・月額・追加費用を含めて妥当か
体制：誰が責任を持ち、進行と品質を担保できるか
リスク：セキュリティ、引き継ぎ、運用で詰まらないか
成果：公開後にKPIで改善し、目的に近づけられるか
KPI＝目標達成度を測るための指標です。
この4分類で評価項目を作ると、提案書の派手さに引っ張られにくく、稟議資料にも転用しやすくなります。

「制作」ではなく「運用の仕組み」を買う意識が重要

CMS＝Web更新を管理画面で行う仕組みです。
サイトは公開がゴールではなく、公開後の更新・改善で成果が決まります。つまり、ベンダーを選ぶことは「運用の仕組み（誰が、何を、どの頻度で改善するか）」を選ぶことでもあります。提案依頼の時点で、運用責任の所在、改善の進め方、レポートの型まで確認できる評価項目を用意しておくと、乗り換え後の混乱を減らせます。

提案依頼前に整理する要件定義の最小セット

要件定義は「やること・やらないこと」を決める工程

要件定義＝実現したいことを、範囲・優先順位・条件として文章に落とす工程です。
最小セットとしては、細部の仕様よりも「何を成功とするか」と「どこまでを今回の範囲にするか」を先に決めます。ここが曖昧だと、見積もりもスケジュールもブレ続けます。

目的・対象・優先順位を1ページにまとめる

経営者／事業責任者が押さえるべきは、次の3点です。

目的：問い合わせ増、採用応募増、資料請求増など（言葉を短く）
対象：誰に何を伝えるか（部門ではなく顧客像で整理）
優先順位：最優先の成果は何か（複数ある場合は順位を付ける）
UI/UX＝画面の使いやすさや体験価値を設計する考え方です。
目的と対象が定まると、UI/UXや導線設計の判断が速くなります。

現状資産と制約条件だけは先に棚卸しする

提案精度を上げるために、最低限以下は共有します。

現状サイトのURL、主要ページ、更新方法（誰が更新しているか）
サーバー／ドメイン／DNSの管理者情報（権限の所在）
DNS＝ドメイン名とサーバーの対応を管理する仕組みです。
解析環境（例：アクセス解析ツールの有無）と現状課題
連携システム（問い合わせフォーム先、MA等）
MA＝見込み顧客の育成や配信を自動化する仕組みです。
ここが不明なままだと、移行やフォーム改修が後工程で発覚し、追加費用になりやすい領域です。

提案依頼で「対象外」の扱いをルール化する

対象外（別途）とは、今回の見積・スケジュールに含めない作業領域です。
対象外を禁止するのではなく、「対象外にする場合の前提（誰が、いつまでに、どの品質で用意するか）」まで書かせると比較が一気に楽になります。社内工数が増える領域ほど、提案依頼の時点で先に扱いを決めておくのが安全です。

評価項目の設計方法：必須条件・加点条件・重み付け・スコアリング

まず「失格条件」を決めてから点数化する

必須条件（失格条件）とは、満たさない場合に比較対象から外す条件です。
例：セキュリティ要件を満たせない、運用引き継ぎの体制が出せない、見積の前提が不透明など。必須条件を先に定めることで、価格だけが低い提案に引っ張られるリスクを下げられます。

加点条件は「成果に効く差分」に絞る

加点条件とは、満たすほど評価が上がる条件です。
デザイン表現の好みのような主観ではなく、「成果に効く差分」に寄せます。たとえば、計測設計の提案力、改善の運用設計、社内合意を作る進行力は、公開後の成果に直結しやすい加点ポイントです。

重み付けで“会社の事情”を数値に翻訳する

重み付け＝評価項目ごとの重要度を配点で表すことです。
例えば「短納期が最優先」「運用内製が前提」「複数部署が関わる」など、会社ごとの事情は異なります。事情を会議で言い合う代わりに、配点で表現すると判断が一貫します。

評価項目テンプレ

評価カテゴリ	評価項目	配点（重み）	確認方法
費用	TCOの見通し（初期＋月額＋追加）	15	見積内訳と前提条件の提示
費用	追加対応の単価と変更手順	10	単価表・変更管理の説明
体制	PM体制と役割分担の明確さ	15	体制図・会議体・議事録サンプル
体制	進行管理（品質・期限）の方法	10	スケジュール案・管理ツール方針
リスク	セキュリティと権限管理	15	チェックリスト・運用ルール案
リスク	引き継ぎ・移行計画の現実性	10	移行手順・切替リハーサル案
成果	KPI設計と計測の提案力	15	計測設計案・改善レポート例
成果	公開後の改善サイクルの設計	10	改善頻度・優先度決めのプロセス

PM＝計画・調整・進行管理を担う責任者です。
TCO＝導入後の運用費も含めた総コストです。
スコアリング＝配点に沿って点数を付け、合計点で比較する方法です。
この表をRFPに添付し、「各項目に対する回答」「前提条件」「対象外（別途）の範囲」を同じフォーマットで返してもらうと、比較の摩擦が大きく減ります。

スコアリングを機能させる運用ルール

点数表があっても、運用が曖昧だと結局ぶれます。次のルールを決めておくと、意思決定が速くなります。

評価者を固定し、同席できない場合は後追い採点をしない
価格は最後に見る（先に体制・リスク・成果を評価する）
「満点の根拠」をメモに残し、決裁者に説明できる形にする
ここまで整えると、次に検討すべきは費用・契約の読み方です。次回は、見積内訳の読み替えと、追加費用が出やすい論点を整理します。

費用・契約の評価項目：見積内訳、追加費用、TCO、支払条件

見積は「ページ数」より「作業と前提」を比較する

同じサイトリニューアルでも、ベンダーごとに含める作業が違います。比較の起点は、デザイン案の数やページ数ではなく「誰が・何を・どこまでやるか」という前提です。前提が曖昧な見積は、後から追加費用と社内工数の増加を招きます。
見積の段階で、原稿整理、素材準備、移行、テスト、公開手順、更新マニュアル作成までを項目として明示してもらい、対象外（別途）の理由と代替案まで書けるかを評価項目に入れます。

見積内訳の最低構成を揃える

比較のために、内訳の粒度は最低限そろえます。粒度が違うと、安く見える提案ほど「中身が省略されている」可能性が残ります。

企画・要件整理：目的と範囲の整理、優先順位付け
情報設計：サイト構造、導線の設計
デザイン：主要テンプレートとパーツ設計
実装：CMS組み込み、表示速度の配慮、フォーム
移行：既存ページ・画像・PDFなどの扱い
テスト・公開：検証、切替、公開後の初期監視
ドキュメント：運用手順、権限、更新ルール
この構成に対して、各社の見積を「読み替え」できる状態にすることが、投資判断の土台になります。

契約形態と責任範囲を揃える

請負＝成果物の完成を約束する契約形態です。
準委任＝作業時間や役務の提供を約束する契約形態です。
要件定義支援や公開後の改善は準委任、制作は請負、といった組み合わせになることがあります。ここが混在すると、責任の境界が曖昧になり「どこまでが確約か」が説明しづらくなります。提案依頼では、工程ごとに成果物・作業範囲・責任者を分けて提示できるかを評価します。

TCOを出すためのチェック項目

TCO＝導入後の運用費も含めた総コストです。
初期見積だけでは判断できないため、少なくとも次を揃えます。

月額に含まれる作業と回数（更新、軽微修正、改善提案）
監視・バックアップ・障害対応の範囲と費用
外部サービス費（フォーム、メール配信、画像素材など）の想定
内製する場合の教育・マニュアル整備の工数
「月額が安いが社内工数が増える」構図を避けるため、社内側の負担も含めて比較します。

追加費用が出やすい論点を先に潰す

追加費用は仕様変更だけでなく、前提の抜けから発生します。代表例は、フォーム仕様の増減、既存CMSからの移行、画像の権利確認、英語ページなどの多言語、既存URLの整理とリダイレクトです。リダイレクト＝旧URLから新URLへ転送する設定です。
評価項目では、追加費用の算定方法（単価・上限・承認フロー）と、変更管理の手順（誰が判断し、いつ反映するか）が提示できるかを重視します。

見積比較の読み替え例（内訳と注意点）

項目	ベンダーA	ベンダーB	注意点（前提・追加）
ディレクション/進行	月1定例・議事録作成	週1・議事録は社内	社内工数と意思決定速度に影響
情報設計/ワイヤー	主要ページ中心	全ページ	範囲差が導線と品質に直結
移行/リダイレクト	移行対象を要確認	移行計画を提示	検索流入の変動はここで左右
テスト/公開	テスト項目提示・立会い	手順書のみ	公開時のトラブル耐性が変わる

支払条件と検収条件で「揉めどころ」を減らす

検収＝成果物の受領を確認する手続きです。
支払が着手・中間・検収後など段階分割される場合、検収の定義が曖昧だと、修正対応が長引きやすくなります。評価項目としては、修正回数の扱い、対応期限、納品データの範囲（デザインデータ、ソースコード、設計資料）を明確にできるかを見ます。
あわせて、保守費に含まれる範囲（軽微修正、監視、障害一次対応、改善提案）を言語化してもらうと、TCOの見通しが立ちやすくなります。

体制・進め方の評価項目：PM体制、コミュニケーション、スケジュール管理

体制は「誰が責任を持つか」を名指しで確認する

PM、デザイン責任者、実装責任者、運用の窓口が曖昧だと、判断が遅れ、品質もぶれます。提案書に体制図と役割分担、連絡手段、会議頻度、意思決定の方法（決裁者と承認手順）が含まれるかを評価項目にします。担当変更が起きた場合の引き継ぎ手順まで提示できるベンダーは、継続運用でも安定します。

コミュニケーションは「記録が残るか」で差が出る

口頭の合意が増えるほど、後工程で認識差が出ます。評価項目としては、議事録の品質、決定事項の管理、課題管理表の運用、レビューの手順（誰が何を確認するか）が提示できるかを見ます。社内側の確認窓口が少人数でも回る設計になっているかは、10〜500名規模の体制では重要です。

スケジュールは「作業」ではなく「合意」を置く

遅延要因は制作作業より、社内合意の停滞に出やすい傾向があります。各マイルストーンに、確認者・確認期限・判断材料を置けるかが重要です。マイルストーン＝工程の節目となる重要な日程です。
要件が固まりにくい場合は、決める順番の設計（先に目的と範囲、次に導線、最後に表現）を提示できるかを評価します。

言語化とストーリー設計ができるか

提案の差は、見た目より「目的の翻訳力」に現れます。目的や強みが整理できていない状態でも、ヒアリングから価値を言語化し、ページ全体のメッセージやストーリーに落とせるかが重要です。デザインは問題解決である、という姿勢で進められるかは、成果の再現性を左右します。

品質・リスクの評価項目：セキュリティ、運用保守、SLA、引き継ぎ

セキュリティは機能より「運用ルール」を見る

管理画面の権限、パスワード方針、更新ログ、外部委託時のアクセス管理など、運用で破綻しない設計かを確認します。二要素認証＝パスワードに加えて別の確認要素を使う認証です。
提案依頼では、実装可否だけでなく、権限設計の考え方と運用ルール案まで出せるかを評価項目にします。

保守のSLAと連絡系統を具体化する

SLA＝対応時間や復旧目標などのサービス水準を定めた合意です。受付時間、一次回答の目安、エスカレーション（上位担当へ引き上げる手順）、緊急時の連絡手段を提示できるかを比較します。さらに、障害の切り分け（サーバー、CMS、外部サービス）を誰が担うかまで明確だと、責任分界が揃います。

公開切替のリスクと戻し手順を確認する

切替当日に想定外が起きても事業影響を抑えるには、手順の現実性が重要です。ロールバック＝問題が起きた際に元の状態へ戻す手順です。切替リハーサルの有無、公開後の監視期間、トラブル時の判断者を提示できるかを評価項目にします。

引き継ぎとベンダーロックイン回避を評価する

ベンダーロックイン＝特定ベンダーへの依存で乗り換えが難しい状態です。ドメイン・サーバー・解析・フォーム等のアカウント保有者、ソースコードと設計資料の引き渡し、更新マニュアルの整備、ステージング環境の扱いを確認します。ステージング環境＝本番と同等に近い検証用環境です。
ここを評価項目に入れておくと、将来のベンダー変更や体制変更でも選択肢を残せます。

成果・KPIの評価項目：計測設計、改善サイクル、レポート運用

成果を「指標」に落とせるベンダーが強い

KPI＝目標達成度を測るための指標です。
CV＝問い合わせ・資料請求・応募など、成果につながる行動です。
リニューアルの意思決定で重要なのは、見た目の良し悪しではなく「何を増やすのか」を合意し、そのための設計と運用を作れるかです。評価項目としては、KPIを階層で整理できるか（例：最終KPI→中間指標→行動指標）を見ます。

計測設計は「あとから足せる」ではなく最初に決める

計測設計＝どの指標を、どの方法で、どの画面で見られるようにするかを決めることです。
公開後に成果を説明するには、最低限「現状の基準値」と「公開後に比較する指標」が必要になります。提案依頼では、次が提示できるかを評価します。

主要CVの定義（何をCVとみなすか）
計測の設置範囲（フォーム送信、電話タップ、資料DLなど）
レポートの型（誰が見ても判断できる体裁）

改善サイクルを回す設計があるか

改善サイクル＝計測→仮説→実施→検証を繰り返す運用です。
公開後の改善が回らない典型は「誰が判断し、いつ何を直すか」が決まっていない状態です。評価項目として、月次の改善会議、優先順位の決め方、対応範囲（文言修正までか、構造変更までか）を明示できるかを確認します。

比較表での最終判断：面談質問、提案書の読み方、決裁資料の作り方

提案書は「できること」より「前提と責任」を読む

提案書の差は、機能やデザイン案よりも「前提条件」「対象外（別途）」「責任範囲」の明確さに出ます。最終判断では、採点表の合計点に加えて、次の観点でブレを抑えます。

追加費用になりやすい論点が先回りされている
進行と品質の責任者が名指しされている
公開後の運用（改善・保守）のやり方が具体的

面談で差が出る確認質問例

論点	質問例	期待する回答	リスクサイン
費用前提	見積の対象外と、社内側の作業は何か	社内作業の一覧と期限が出る	「都度相談」「ケースバイケース」が多い
進行管理	遅延しやすい工程と、その予防策は何か	合意形成の設計と代替案がある	制作作業だけの説明に偏る
品質担保	レビューとテストの手順、基準は何か	確認観点と責任分担が出る	「確認してください」が中心
運用設計	公開後の改善提案は誰が、何を見て行うか	指標と改善頻度が具体的	運用は保守窓口のみで改善がない

決裁資料は「4分類」で1枚にする

稟議で通すには、情報量より整理が重要です。次の4点を1枚にまとめると、説明が短くなります。

費用：初期＋月額＋追加費用の考え方（TCOの見通し）
体制：責任者、会議体、社内工数の見込み
リスク：移行、セキュリティ、運用保守の懸念と対策
成果：KPI、計測、公開後の改善サイクル

乗り換え・リニューアルを成功させる移行計画（止めない・戻せる設計）

「止めない」ために必要なのは段取りの設計

移行計画＝現行から新環境へ切り替えるための手順と役割分担です。
事業影響を抑えるため、評価項目として次を確認します。

移行対象の棚卸し（ページ、PDF、画像、フォーム、外部連携）
URLの扱い（変更の有無、転送の方針）
公開手順（切替当日の作業、監視、緊急連絡）
ロールバック（問題時に元へ戻す手順）を用意できるか
ロールバック＝障害時に元の状態へ戻す手順です。

SEOのリスクは「移行で起きる」前提で管理する

検索流入の変動は、デザイン変更よりURL・構造・計測の切替で起きやすくなります。評価項目として、転送（旧URLから新URLへの適切な誘導）と、公開後の点検項目（主要ページ、計測、フォーム）を提示できるかを見ます。

要件定義支援・PM支援・運用設計の相談ポイント

相談の論点は「比較できない」を解消すること

ベンダー選定が長引く主因は、社内の要件が言語化されず、提案の前提が揃わないことです。外部支援を入れる価値は、制作そのものより「要件と評価基準を整え、比較と決裁を前に進める」点にあります。

支援で整理できる成果物の例

要件定義のたたき台（目的・範囲・優先順位・制約条件）
RFP（提案依頼の条件と評価基準）
評価表（重み付け、スコアリング、面談質問）
移行計画のレビュー（止めない、戻せる段取り）
運用設計（改善サイクル、レポート、役割分担）
みやあじよでは、依頼側が整理しきれていない魅力や目的を言語化し、問題解決として設計へ落とし込む姿勢を重視しています。

まとめ

ベンダー比較を成功させる鍵は、提案を集めてから悩むのではなく、提案依頼の前に「評価項目」と「前提条件」を揃えることです。費用はTCOで見通し、体制は責任者と合意形成の設計で見極め、リスクは移行と運用まで含めて潰し、成果はKPIと計測・改善サイクルで再現性を確認します。評価表と面談質問まで用意できれば、選定は説明可能な意思決定になり、乗り換え後も揉めにくくなります。