システム比較表の評価項目｜必須条件・重み・未確認の扱い方

システム比較表は、候補の機能を並べるだけでなく、自社が必要とする条件に対して、何を確認し、どう判断したかを残す表です。評価項目は「満たさないと導入できない必須条件」と「候補間の違いを採点する項目」に分けます。

この記事では、営業部門で使うシステムを選ぶ架空の例で、項目・採点基準・重み・未確認情報の扱いを説明します。特定製品の評価や、すべての会社に共通する配点ではありません。

比較表を作る手順

1. 導入後に実現したい業務を一文にする。
2. 必須条件と採点項目を分け、確認方法を決める。
3. 点数の基準と重みを合意してから、同じ条件で試す。
4. 未確認を解消し、重みを変えたときの結論も確かめる。
5. 選定理由と残る確認事項を記録する。

最初に「導入後にできるようにしたいこと」を一文にする

「使いやすいシステムが欲しい」だけでは、担当者ごとに評価するものが変わります。たとえば、CRMの選定なら、次のように対象業務を絞ります。

営業担当が商談後に案件を更新し、上司が週次会議の前に、停滞案件と次回アクションを確認できるようにする。

この目的なら、見た目の好みより「商談後の更新が完了するか」「更新漏れを発見できるか」「会議用の情報を取り出せるか」を試すことが先です。目的と関係が薄い機能を大量に採点すると、必要な業務ができない候補でも総合点が高くなりかねません。

IPAの要件定義の解説でも、利用者の要求を関係者と合意し、要件としてまとめる流れが示されています。要件定義と比較の準備では、利用部門と管理部門で「何のための導入か」をそろえます。

必須条件は総合点と別に判定する

必須条件とは、満たせなければ他の長所では埋め合わせられない条件です。単に重みを大きくするのではなく、採用候補として検討を進められるかを別に判定します。

これらは例です。認証や移行がすべての案件で同じ必須条件になるわけではありません。「未確認」と「満たさない」も区別します。未確認なら、条件を満たすと決めつけて候補を確定させません。

採点する項目は、確認できる行動に置き換える

SaaSなどの比較では、抽象的な「機能性」「操作性」を、その会社で試せる内容に置き換えます。次の表は、項目を作るためのたたき台です。

費用は月額だけを比べず、同じ条件にそろえます。たとえば10人で使う案と30人で使う案、標準プランと必要機能を追加したプランを、そのまま横に並べないようにします。

点数は根拠をそろえ、重みは採点前に合意する

点数は候補の確認結果、重みは自社が何を重視するかです。この二つを混ぜないようにします。

たとえば「案件更新の負担」なら、先に同じ操作課題を決め、4点を「必要な操作を担当者が自力で完了」、5点を「必要操作に加え、事前に決めた追加の期待まで満たす」、3点を「おおむねできるが軽微な不足が残る」と定義します。2点は一部に不足、1点は大きな不足として、何を不足とするかも評価前に決めておきます。まだ試していなければ未確認です。

次は、必須条件を確認済みの候補A・Bを比べる、説明用の小さな例です。数値は架空です。

5点満点の点数を100点換算するなら、ここでは次の簡易計算を使います。

総合点 = Σ（点数 × 重み）÷（5 × 重みの合計）× 100
候補A =（5×3 + 3×2 + 2×1）÷ 30 × 100 = 76.7点
候補B =（3×3 + 5×2 + 5×1）÷ 30 × 100 = 80.0点

この条件ではBが上位です。後述の比較表ツールでは総合点を整数で表示するため、Aは77点、Bは80点になります。ただし、費用条件の重みを1から0へ変えれば、Aは84.0点、Bは76.0点になり、順番が変わります。これはBが間違いという意味ではなく、「費用を評価に含めることが、この例の判断を左右している」と分かる材料です。

重みを変える確認は、好きな候補を勝たせるために行いません。関係者で意見が割れている項目があるなら、その違いが結論にどの程度影響するかを確かめ、採用した条件と理由を残します。

ここでの計算は、社内の比較を整理するための簡易な採点です。厳密な意思決定分析と同じものではありません。英国政府のMCDA解説も、単純な点数と重みの計算を正式なMCDAと混同しないよう区別しています。

未確認の情報がある間は、順位を暫定扱いにする

未確認を最低点にすると、まだ調べていない候補が不利になります。逆に、資料に記載があるだけで高得点を付けると、実際に試した候補との比較条件がそろいません。

対応は、まず追加確認の担当者と期限を決めることです。すぐに仮の比較が必要なら、全候補で確認できた共通項目だけで計算し、除外した項目を明記します。その順位は、未確認項目を含む最終順位ではありません。

たとえばBの運用のしやすさが未確認なら、その項目をAだけ採点して比較しません。両候補から同じ項目を外した暫定値にするか、確認が終わるまで順位を出さず、分かっている違いを文章で整理します。

よくある失敗

• 同じ長所への二重加点：「機能数」「多機能」のように同じ理由で採点する項目は整理します。
• 未確認を最低点にする：確認済みの低評価と分け、追加確認を依頼します。
• 好きな候補に合わせて配点を変える：条件変更の理由を記録し、関係者で合意します。

比較表を選定理由と次の確認につなげる

最後に、「Bが80点で最高だった」だけでなく、何を重視し、何が残っているかを短い文章にします。

目的：案件更新と週次会議の準備をそろえる。
暫定候補：B。業務適合・運用・費用を3:2:1で評価した結果。
留意点：費用条件を評価から外すとAが上位になる。
残る確認：本番相当のデータ量でも同じ操作ができるか。
担当と期限：運用担当が試用環境で確認し、選定会議までに記録する。

資料だけでは確かめられない重要な条件は、試用やPoCで確認する対象にします。候補側へ同じ条件で提案を求める必要がある場合は、RFPの作り方で目的・要件・提出内容をそろえると、比較の前提を合わせやすくなります。

比較表は結論を自動的に正しくするものではありません。目的、必須条件、根拠、未確認事項が残っていれば、後から条件が変わったときにも、どこから判断し直すかを追えます。