提案の比較表の作り方｜評価軸・必須条件・重みを後付けしない
推したい案を選んだ後、その案が一番になるよう評価軸や重みを作る。これでは比較表が判断の材料ではなく、結論の飾りになってしまいます。提案の比較表は、必須条件の確認と、条件を満たす案の評価を分けて作ります。点数の合計だけで選ばず、不確実性や運用負担も説明できる表を目指しましょう。
比較する意思決定と必須条件を決める
まず「何を選ぶか」と適用範囲をそろえます。全社導入と一部門の試験導入を同列に比べると、費用や影響の前提がずれます。現状維持も選択肢に含めるか確認します。必須条件は、満たさなければ採用できない条件です。組織のセキュリティ基準、必要な接続、期限などを判断者と確認します。「高得点だから必須条件の未達を補える」とは扱いません。条件を見直すなら、採点と別に正式な判断が必要です。
足切りと採点を二段階にする例
以下は架空の作業管理方式の比較です。特定製品の評価ではありません。
| 案 | 必須の権限管理 | 運用負担の確認 | 採点へ進めるか |
|---|---|---|---|
| A 現行方式の整理 | 満たす | 確認済み | 進める |
| B 新方式の試験導入 | 確認待ち | 確認待ち | 保留 |
| C 権限を分けられない方式 | 満たさない | 未確認 | 現条件では対象外 |
Bの不明をゼロ点にせず、確認待ちとして残します。Cを除外する理由も記録し、後から結果だけ見た人が候補不足と誤解しないようにします。
評価軸と点数の意味を先に定める
使いやすさ、導入負担、継続負担などを選び、各点数の意味を具体化します。「便利」は人によって意味が違うので、主要操作を誰が何回行うかなど、確認する場面へ変えます。評価軸が重複すると同じ強みを二重に数えます。導入費用と初年度費用を両方採点するなら、含む範囲が重ならないかを確認してください。重みは判断者と先に合意します。例えば3・2・1の重みで各軸が4・3・2点なら、加重平均は(3×4＋2×3＋1×2)÷6＝約3.33点です。この数値は合意した尺度上の評価で、成功確率ではありません。
根拠と不確実性を点数の横へ残す
確認済みの操作結果、公式仕様、見積もりと、推測を区別します。点数だけ並ぶと、実際に確かめた案と未確認の案が同じ確かさに見えます。期間、利用者数、含む費用をそろえます。見積もり対象外の作業や将来の費用も記録し、初期費用だけで安いと断定しません。主観評価を使う場合、評価者と対象場面を明記します。少人数の試用結果を全員の満足度へ一般化しないようにします。必要な専門確認は利用者の好みの点数で置き換えません。
重みが変わっても結論が保たれるかを見る
重みを少し変えると順位が逆転するなら、その選択は特定の優先順位に強く依存しています。どの条件で逆転するかを示し、安定した優位と区別します。未確認項目の結果で結論が変わるなら、そこを優先して調査します。表を精緻にするより、判断を変える情報を取りに行く方が有効なことがあります。最後に推奨案、採用条件、残る不確実性、必要な承認を記します。点数は判断の補助であり、責任者の判断を自動化するものではありません。
次に確認したい実務ガイド
PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。
参考情報とこの記事の位置づけ
意思決定の役割を明確にする公開情報を参考にしました。採点の設計と例は当サイトの独自提案です。 Atlassian：DACI Decision-making Framework（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。
背景と目的の違いも必要な作業に合わせて参照してください。
アイキャッチ写真：2H Media / Unsplash。職場の実写ではなくイメージ写真です。
