システム開発・AI導入におけるRFP策定の勘所とベンダ選定の評価基準

ITストラテジスト（ST）、プロジェクトマネージャ（PM）、システムアーキテクト（SA）の午後I記述および午後II小論文では、「外部ベンダの活用」「パッケージ・SaaSの選定」「生成AIなど新技術導入時のPoC（概念実証）と調達」が繰り返し出題されています。 IPAの採点講評で毎年のように減点対象として挙げられるのが、「ベンダの提案をそのまま受け入れた」「見積金額の安さだけで発注先を決めてしまい、後から非機能要件（性能・セキュリティ・データ移行）や業務適合性の不足が判明した」という論述です。これは試験上の減点要素であると同時に、実務のシステム企画でも要件定義のやり直しや追加費用の発生につながる典型的な失敗パターンです。 特に生成AI（社内文書検索RAGや業務特化ワークフロー）やクラウド移行を伴う案件では、従来のスクラッチ開発を中心とするSIerと、特定領域に特化した開発会社とで得意分野や見積もりの前提条件が異なります。発注側には、解決したい業務課題と制約条件をRFP（提案依頼書）として明文化し、同種案件の実績を持つ複数の開発会社から提案を受けて比較するプロセスが求められます。 実務でRFP策定や発注先候補のリストアップを進める際は、既存の取引先だけでなく発注ナビのような開発会社紹介サービスを併用し、自社の業種や技術要件に近い実績を持つベンダを複数社ピックアップして比較検討するアプローチが有効です。

午後II小論文の設問イで「ベンダ選定やシステム方式の決定において工夫したこと」を論述する際、「複数社から相見積もりを取って比較した」とだけ書くと、評価基準が曖昧なため具体性に欠けると判断されがちです。論文に実務の具体性を持たせるには、以下の4つの観点で提案内容を比較・検証したプロセスを記述するのが効果的です。 ・業務適合度とFit&Gapの妥当性 　自社の基幹業務フローに対する理解度と、パッケージやSaaSの標準機能で合わない部分（Gap）に対して「業務側の見直し（BPR）」と「最小限のアドオン開発」のどちらを提案しているか。 ・技術的実現性と非機能要件の担保 　既存システムとのデータ連携方式（API連携・日次バッチ等）、ピーク時の性能目標、セキュリティ対策や監査ログ要件への対応方針が具体的か。 ・プロジェクト推進体制と類似案件の実績 　会社全体の規模ではなく、実際にプロジェクトに参画するPMやアーキテクトが同業界・同規模のシステム導入を経験しているか。 ・初期開発費だけでなく運用保守を含めたTCO（総所有コスト） 　初期構築費用だけでなく、稼働後5年間のライセンス費用、クラウド利用料、保守運用費を含めた総額が投資対効果（ROI）の試算範囲に収まっているか。

一方、実際の業務で情報システム部門や企画部門の担当者として開発案件を任された場合、「自社の予算規模や技術領域に合う開発会社をどうやって探すか」という実務上の課題に直面することが少なくありません。 知名度の高い大手ベンダに相談すると二次請け・三次請け構造によって見積額が予算を超過しやすく、逆にWeb検索で見つけた開発会社に個別問い合わせを行うと、1社ずつ背景を説明するだけでも多くの工数がかかります。 そうした選定工数を抑える手段として、アイティメディアグループが運営する発注ナビの無料相談窓口があります。全国5,000社以上の開発会社データベースの中から、IT専門のスタッフが案件の目的・予算・必要な技術（業務システム刷新、生成AI活用、クラウド構築、アプリ開発など）をヒアリングし、条件に合う開発会社を厳選して紹介する仕組みです。 発注企業側の相談・紹介手数料は無料で、RFPが固まりきる前の「大まかな企画段階での相場確認」や「既存ベンダ以外のセカンドオピニオン探し」としても利用できるため、システム企画や調達実務の選択肢として押さえておくと役立ちます。