IT提案の比較表の作り方｜価格・範囲・運用条件をそろえて判断する

IT提案を比べるときは、最初に価格の横へ機能数を並べるのではなく、各案がどこまでを含むかをそろえましょう。安く見える案が導入後の運用を含まなかったり、多機能な案でも必須の業務を満たせなかったりすると、表の合計点だけでは判断できません。

この記事では、複数のIT提案を整理する担当者や、顧客の選定を支援するIT営業向けに、比較表の項目と確認の順番を紹介します。特定製品の優劣や調達制度の手続きを示すものではありません。

比較する前に、選定の目的を一文にする

「新しいシステムを選ぶ」ではなく、何の業務をどの状態に変えたいかを書きます。たとえば「拠点ごとに分かれた申請状況を、管理担当が同じ画面で確認できるようにする」といった形です。

目的に照らして、満たさなければ採用できない条件と、満たすほど望ましい条件を分けます。画面の見た目や付加機能の評価で、必須条件の不足を相殺しないためです。

政府調達の一例として、デジタル庁は価格と技術提案を評価する総合評価落札方式を説明しています。ただし、以下の比較表は民間の社内検討向けの提案であり、政府調達の評価制度をそのまま適用するものではありません。デジタル庁の政府調達入門

「対応可」の印だけでは、標準機能か、追加開発か、運用で補うのかが分かりません。評価欄と根拠欄を分け、提案書の参照箇所や確認した日付を残します。

まだ確認していない事項は「未確認」とします。非対応と同じ評価にせず、判断の前に誰へ何を確かめるかを追加してください。

申請業務を置き換える架空の案件で、A案はデータ移行と利用説明を含み、B案はシステムの設定のみを含むとします。ここでは金額の実測値や相場を示しません。

初期費用の数字だけを比べると、移行と説明を誰が行うかが抜けます。まず、両案に含まれる作業を同じ項目へ分解します。B案で社内が担当するなら、社内で実施できる人と時間を確認し、追加依頼するならその条件を確認します。

継続費用も、利用人数、容量、保守範囲、契約期間など、実際の提案に記載された条件でそろえます。将来の利用量が分からない場合は、一つの確定値へまとめず、条件が変わると費用のどこが変わるかを示しましょう。

比較表には、たとえば「A案は移行作業を含む。B案は社内実施を前提とし、担当確保は確認中」と書けます。どちらが良いかは、費用だけでなく、社内で担える作業と導入期限を合わせて判断します。

点数化は議論を整理する手段ですが、基準の曖昧さまで解消するものではありません。「使いやすさ5点」のような評価では、誰が何を試した結果かが分かりません。

対象者、試す業務、確認方法をそろえ、重要な項目の重みは評価する前に決めます。提案を見てから都合よく重みを変える場合は、その理由と再評価の対象を残しましょう。

同じ点数でも、標準対応と将来開発予定は確実性が異なります。数値の横に、対応時期、条件、根拠の種類を残し、点数だけで結論を説明しないようにします。

比較表の最終行は「おすすめ」だけでなく、採用理由、受け入れる制約、契約前に確認する事項を分けます。選ばなかった案についても、今回の条件で合わなかった理由を残すと、目的が変わった際に再検討できます。

要求と提案の対応を整理したい場合は、RFPへの回答の作り方も参照してください。比較する側では、各案の説明を同じ問いへ変換し、未確認のまま進める点を決定者が理解できる状態にすることが大切です。