目次
「ベンダー選定で結果の7割が決まる」。システム開発の世界では、こう言われることがある。実際、JUAS「企業IT動向調査2025」によると、IT予算増加の理由として「基幹システムの刷新」が44.5%を占めた（出典：JUAS 企業IT動向調査2025）。刷新に投資する企業は増えている。しかし、そのパートナー選びに明確な基準を持つ企業は少ない。
IT整備士協会の報告では、ベンダー選定の失敗企業に共通するパターンとして「価格だけで選ぶ」ことが最多に挙がっている（出典：IT整備士協会「ベンダー選びで失敗した企業の共通点と対策法」）。ある製造業では、最安値のベンダーを選んだ結果、追加開発費が当初見積もりの3倍に膨れ上がった。
本記事では、システム刷新のベンダー選定で使える5つの評価軸を整理する。これから刷新を控える情シス担当者が、社内稟議にそのまま活用できる内容を目指した。
システム刷新のベンダー選定が重要な理由
本題に入る前に、なぜベンダー選定がこれほど重要なのかを確認しておく。
刷新プロジェクトの特殊性
通常のシステム開発と異なり、刷新プロジェクトには固有の難しさがある。既存システムの理解、データ移行、業務の継続性担保。これらすべてに対応できるベンダーでなければ、プロジェクトは破綻する。
BCGの調査によれば、500人月以上のシステム投資でQCDを計画どおり達成できた企業は2割を下回る（出典：BCG「2025年の崖 システム投資に失敗する理由」）。失敗の要因は多岐にわたるが、ベンダー選定の段階で回避可能なものも多い。
ベンダー選定の失敗が招く具体的損害
選定を誤った場合の損害は甚大だ。代表的なリスクを3つ挙げる。
- コスト超過。 要件の認識齟齬から追加費用が発生し、当初予算の2〜3倍に膨らむ。
- スケジュール遅延。 技術力不足による手戻りが重なり、稼働時期が半年〜1年遅れる。
- 品質問題。 テスト不足や設計品質の低さから、稼働後に障害が頻発する。
過去には、ベンダーへの丸投げが原因で200億円超の減損が発生し、訴訟に発展した大手インフラ企業の事例もある（出典：日経クロステック）。ベンダー選定は、プロジェクトの成否を左右する最重要の意思決定だ。
刷新プロジェクトで起こりやすい失敗パターンの全体像は、システム刷新プロジェクトの失敗パターン5選と回避策で詳しく解説している。
システム刷新ベンダー選定の評価軸1：技術力
5つの評価軸のうち、最も重要なのが技術力だ。刷新対象の言語・フレームワーク・インフラに精通しているかどうかが、プロジェクトの命運を分ける。
確認すべきポイント
技術力を見極めるには、以下の観点から評価する。
- 対象技術への習熟度。 刷新元（レガシー側）と刷新先（モダン側）の両方に知見があるか。COBOLからJavaへの移行なら、双方の経験が必要になる。
- アーキテクチャ設計力。 単にコードを書く力だけでなく、全体構造を設計する能力があるか。マイクロサービスやクラウドネイティブの知見も評価対象になる。
- 現行システムの解析能力。 設計書のないレガシーシステムを、ソースコードから正確に読み解く力があるか。
評価方法
技術力の評価は、提案書の記述だけでは不十分だ。以下の方法を組み合わせて判断する。
- 技術質問への回答精度。 RFPの段階で、技術的な質問を10問程度用意する。回答の具体性と正確性を見る。
- PoCの実施。 可能であれば、小規模な検証を依頼する。実際の開発力を見極める最も確実な方法だ。
- エンジニアとの面談。 営業担当だけでなく、実際に手を動かすエンジニアと会話する。技術的な質問に即答できるかを確認する。
なお、現行システムの解析を自社で先行して進める方法もある。ソースコードの構造解析や依存関係の可視化をあらかじめ実施しておけば、ベンダーへの要件伝達が格段に正確になる。
システム刷新ベンダー選定の評価軸2：実績
技術力に次いで重視すべきは、類似案件の実績だ。「できます」と「やったことがあります」の間には大きな差がある。
確認すべきポイント
実績の評価では、以下の4点を重点的に確認する。
- 同業種・同規模の導入実績。 製造業の基幹システム刷新なら、製造業での実績があるベンダーを優先する。業種固有の業務知識は、短期間では習得できない。
- 同一技術スタックでの実績。 対象言語やフレームワークでの開発経験が豊富か。
- プロジェクト規模の実績。 数千万円の案件しか経験のないベンダーに、数億円の案件を任せるのはリスクが高い。
- リファレンスの取得。 過去の顧客に直接ヒアリングできるかどうか。応じてくれるベンダーは、顧客との関係が良好な証拠だ。
実績がない場合の判断
特殊な技術領域では、十分な実績を持つベンダーが見つからないこともある。その場合は以下を基準に判断する。
- 類似技術での実績はあるか
- 社内に対象技術の専門家がいるか
- 学習・キャッチアップの計画は具体的か
実績の少なさ自体が問題なのではない。そのリスクを認識し、具体的な対策を示せるかどうかが判断基準になる。
システム刷新ベンダー選定の評価軸3：コミュニケーション
技術力と実績を備えていても、コミュニケーションに問題があれば、プロジェクトは確実に停滞する。刷新プロジェクトでは、業務部門・経営層・IT部門・ベンダーの4者間で認識を合わせ続ける必要がある。
確認すべきポイント
コミュニケーション品質を事前に見極めるのは難しい。しかし、以下の観点から一定の判断は可能だ。
- 提案段階の応答速度。 問い合わせへの回答は迅速か。RFP提出後の質疑対応は丁寧か。
- ドキュメント品質。 提案書や議事録の品質は、プロジェクト中の成果物品質と相関する。
- 非エンジニア向けの説明力。 技術的な内容を、経営層や業務部門にもわかる言葉で説明できるか。専門用語を並べるだけのベンダーは注意が必要だ。
- 課題やリスクの開示姿勢。 都合の悪い情報も正直に伝えてくれるか。「問題ありません」としか言わないベンダーは危険信号だ。
プロジェクトマネジメント体制
コミュニケーションと密接に関連するのが、PM（プロジェクトマネージャー）の質だ。
- PMの経験年数と過去の担当案件を確認する
- プロジェクト計画書のサンプルを提出してもらう
- 進捗報告の頻度と方法を事前に合意する
IPA「ソフトウェア開発分析データ集2022」では、要件定義工程の工期比率が中央値で約15%と報告されている（出典：IPA ソフトウェア開発分析データ集2022）。限られた期間で要件を正確にまとめるには、ベンダー側の傾聴力と整理力が不可欠だ。
システム刷新ベンダー選定の評価軸4：保守体制
システムは「作って終わり」ではない。刷新後の運用・保守体制を、選定段階で見極めておく必要がある。
確認すべきポイント
保守体制の評価では、以下を重点的に確認する。
- 保守契約の範囲と内容。 障害対応のSLA（応答時間・復旧時間）は明確か。「最善努力」という曖昧な表現は避けるべきだ。
- 担当者の継続性。 開発メンバーが保守フェーズにも関与するか。開発と保守で完全に人が入れ替わると、引き継ぎコストが発生する。
- ナレッジの移転方針。 運用マニュアルや手順書の作成が契約に含まれているか。ベンダーに依存しない体制を目指すべきだ。
- エスカレーションルート。 緊急時の連絡経路と対応フローが明確か。夜間・休日の対応可否も確認する。
ベンダーロックインの回避
保守体制を評価する際に、もう一つ意識すべきなのがベンダーロックインのリスクだ。
- ソースコードの著作権・知的財産権の帰属は明確か
- 他社への引き継ぎが可能な設計・ドキュメントが納品されるか
- 独自フレームワークや独自ツールへの依存度は高くないか
経済産業省のDXレポートでは、IT予算の約80%が現行システムの維持・運用に費やされている構造が指摘されている（出典：経済産業省 DXレポート）。この構造を再び作らないためにも、保守体制の設計は選定段階から始めるべきだ。
システム刷新ベンダー選定の評価軸5：価格
最後の評価軸は価格だ。ただし、価格は「最も重要」ではなく「最後に評価すべき」項目として位置づける。
確認すべきポイント
価格評価で重要なのは、単純な安さではなく「妥当性」だ。
- 見積もりの内訳が明確か。 工数・単価・前提条件が詳細に記載されているか。「一式○○万円」は危険な見積もりだ。
- 追加費用の発生条件。 要件変更や仕様追加が発生した際の費用算定ルールが明示されているか。
- 支払い条件の柔軟性。 マイルストーン払い、検収後払いなど、リスクを分散できる支払い方法に対応しているか。
- TCO（総保有コスト）の提示。 開発費だけでなく、保守・運用まで含めた5年間のトータルコストを比較する。
見積もり金額の相場感
IPA「ソフトウェア開発分析データ集2022」によると、外部委託の工数比率は平均58.6%だ（出典：IPA ソフトウェア開発分析データ集2022）。自社の規模と工数から、一定の相場感を持っておくことが選定時の判断材料になる。
相場を大きく下回る見積もりには要注意だ。エンジニアの技術力が低い、工数を過少に見積もっている、後から追加請求が来る。いずれかのリスクが潜んでいる可能性が高い。
ベンダー選定の評価フレームワーク：5軸スコアリング
ここまで解説した5つの評価軸を、実務で使えるフレームワークに落とし込む。
スコアリングシートの設計
各軸を5点満点で評価し、重み付けを行う。以下はシステム刷新における推奨配分だ。
| 評価軸 | 配点 | 重み | 加重得点（満点） |
|---|---|---|---|
| 技術力 | 5点 | 30% | 1.5点 |
| 実績 | 5点 | 25% | 1.25点 |
| コミュニケーション | 5点 | 20% | 1.0点 |
| 保守体制 | 5点 | 15% | 0.75点 |
| 価格 | 5点 | 10% | 0.5点 |
| 合計 | 100% | 5.0点 |
価格の重みを10%に設定している点がポイントだ。前述のとおり、最安値で選んで失敗するケースが後を絶たない。技術力と実績で合計55%を占める設計にしている。
評価の進め方
- RFP送付前に評価項目を確定する。 後出しで基準を変えると、公平な比較ができなくなる。
- 複数名で独立に評価する。 最低3名が個別にスコアリングを行い、平均値を算出する。
- 定量評価と定性評価を分ける。 価格は定量的に比較できるが、コミュニケーション品質は定性的な判断が必要だ。
- 最終候補2〜3社でプレゼンを実施する。 書面だけでは見えない相性や姿勢を確認する。
システム刷新のベンダー選定でよくある5つのミス
評価軸を理解していても、選定プロセスで陥りやすいミスがある。代表的な5つを紹介する。
ミス1：価格最優先で選ぶ
最も頻度の高い失敗パターンだ。入札方式で最安値を採用し、品質問題に苦しむ企業は多い。先述のとおり、ある製造業では最安値ベンダーを選んだ結果、追加費用が当初の3倍にまで膨らんだ。
対策： 価格の重みは全体の10〜15%に抑える。TCOで比較する。
ミス2：大手ベンダーなら安心と思い込む
ネームバリューだけで大手を選ぶケースも多い。しかし大手ベンダーの場合、実際の開発を下請け・孫請けに委託するケースがある。契約先と実装者が異なると、コミュニケーションコストが跳ね上がる。
対策： 実際に開発するチームの体制を確認する。再委託の有無と範囲を契約前に明確にする。
ミス3：現行システムの理解を丸投げする
「御社の方で現行システムを調べてください」とベンダーに丸投げするパターンだ。自社のシステムを最も理解すべきは自社であり、ベンダーは外部の協力者に過ぎない。
対策： 現行システムの棚卸しを自社主導で実施する。機能一覧、データフロー図、技術的負債の一覧を事前に準備する。ソースコードの規模が大きい場合は、AIを活用した構造解析も選択肢になる。
ミス4：RFPが曖昧なまま選定に進む
要件が曖昧なRFPでは、各ベンダーの提案内容がばらつき、比較が困難になる。結果として「なんとなく良さそう」で決めてしまう。
対策： RFPには最低限、以下を明記する。
- プロジェクトの目的と背景
- 現行システムの概要と課題
- 必須要件と優先順位
- 予算の目安とスケジュール
- 評価基準と選定プロセス
ミス5：選定後のコミュニケーションを怠る
選定が終わった瞬間に安心し、その後のコミュニケーションが疎かになるケースだ。キックオフから要件定義の期間こそ、最も密にやり取りすべきフェーズだ。
対策： 選定後、速やかにキックオフを実施する。週次の定例会議を設定し、課題管理表を共有する。
ベンダー選定前に自社でやるべき準備
ベンダー選定の精度は、実は自社の事前準備で決まる。選定に入る前に、以下を整理しておくことを強く推奨する。
現行システムの可視化
ベンダーに正確な情報を伝えるためには、まず自社のシステムを正確に把握する必要がある。
- 機能一覧の作成。 現行システムで実現している機能を一覧化する。
- システム構成図の整備。 サーバー構成、ネットワーク構成、外部連携先を図示する。
- ソースコードの規模と構造の把握。 総行数、言語構成、モジュール間の依存関係を整理する。
ソースコードが数十万行を超える場合、人手での解析には膨大な工数がかかる。SysDockのようなAIマルチエージェントによる構造解析サービスを活用すれば、最短1週間でシステム全体の構造を可視化できる。Word・PowerPoint・React Flowでの納品に対応しており、非エンジニアの経営層への報告資料としても活用可能だ。ソースコードを外部に送信せずに解析できるため、セキュリティ面での懸念も少ない。
予算とスケジュールの目安策定
ベンダーに提示できる予算の幅とスケジュールの制約を、社内で合意しておく。予算の目安がない状態でRFPを出すと、見積もり金額が大きくばらつき、比較が困難になる。
社内体制の確保
ベンダー任せにしないためには、自社側のプロジェクト体制も重要だ。プロジェクトオーナー、情シス担当者、業務部門の代表者。最低限この3者を確保する。
まとめ：システム刷新のベンダー選定は「5軸」で判断する
システム刷新のベンダー選定は、技術力・実績・コミュニケーション・保守体制・価格の5軸で評価すべきだ。特に重要なのは、技術力と実績で合計55%の重みを持たせることだ。価格最優先の選定は失敗の温床になる。
JUAS「企業IT動向調査2025」が示すとおり、基幹システムの刷新に投資する企業は増え続けている。しかし投資の成否は、パートナー選びの段階で大きく左右される。本記事で紹介した5軸の評価フレームワークを活用し、自社に合ったベンダーを選定してほしい。
そして、ベンダー選定の精度を高めるうえで最も効果的なのは、自社システムの現状を正確に把握しておくことだ。現行システムの構造が可視化されていれば、RFPの精度が上がり、提案内容の比較も容易になる。
現行システムの構造解析を検討中の方へ。SysDockは、AIマルチエージェントによるレガシーシステム構造解析サービスだ。ソースコードを外部に送信せずに解析を実施し、Word・PowerPoint・React Flowで結果を納品する。ライト30万円から、最短1週間で対応可能。着手金0円・完全後払いなので、まずは気軽にお見積りいただきたい。
SysDockのお見積りはこちら → sysdock.genbacompass.com
関連サービス：