LASSIC Media らしくメディア
開発パートナーの選び方｜評価7軸とRFP活用で失敗を防ぐ
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 開発パートナー選びで失敗する企業には、技術力偏重・価格重視・コミュニケーション不全という3つの共通パターンがあります
- 評価軸は7つあり、元請（プライムベンダー）かどうかの確認と見積り根拠の透明性が特に見落とされやすい観点です
- RFPを活用した提案評価プロセスを設計することで、複数社を公平に比較し最適なパートナーを選べます
目次
開発パートナー選びで失敗する企業の共通点
開発パートナーの選び方とは、システム開発やアプリ開発を外部委託する際に、委託先（外注先）を評価・選定するためのフレームワークを指します。単に技術力や価格を比べるだけでなく、体制・コミュニケーション・契約形態・元請か再委託かという複数の軸で総合評価することが、長期的な開発品質の維持につながります。
経済産業省「IT人材需給に関する調査」（2019年）によれば、国内のIT人材は2030年に高位シナリオで約79万人規模の不足が生じると試算されています*1。この人材不足を背景に、システム開発を外部パートナーに委託する企業は増えています。その一方で、委託先の選定を誤ったことによる開発の遅延・品質の低下・コスト超過の事例も後を絶ちません。
以下では、失敗に至る3つの典型パターンを整理します。
技術力だけを重視して体制・責任範囲を確認しないパターン
技術スタックの豊富さや過去の開発実績に惹かれて契約したものの、担当エンジニアが途中で入れ替わり、引き継ぎ不備によって開発が止まったというケースがあります。
技術力は評価の出発点ですが、それを支える体制（誰が担当し、交代時のルールは何か）と責任範囲の明確化が伴っていないと、プロジェクトは途中で空洞化します。
価格重視で選んで見積り外のコストが膨らむパターン
複数社から見積りを取り、価格が最も低い会社を選んだ結果、要件変更のたびに追加費用が発生し、最終的な支払いが当初想定の2倍以上になったという状況はめずらしくありません。
見積りの根拠（工数の算定ロジック・変更時の単価・別途対応になる範囲）を比較しないまま価格だけで判断すると、後から費用が膨らみます。見積り段階での「何が含まれていないか」の確認が大切です。
コミュニケーション不全で進捗が不透明になるパターン
月次報告しかなく、問題が発覚したときには手戻り工数が膨大になっていたというケースがあります。報告頻度・報告フォーマット・課題のエスカレーション先を契約前に握っていなかったことが原因です。
コミュニケーション体制は、契約書や業務委託仕様書に具体的な条件として盛り込むことが大切です。
見落とせない7つの評価軸と比較ポイント
開発パートナーを選定する際は、以下の7つの軸で総合評価することが実務上有効です。1軸だけを重視するのではなく、7軸すべての水準を確認した上で候補を絞ります。
| 評価軸 | 確認すべき内容 | 見落としやすい観点 |
|---|---|---|
| ①技術力・開発実績 | 類似規模・類似領域の開発実績。 使用言語・フレームワーク・クラウド対応範囲。 |
実績が古い、または担当者が既に退職していないか確認する。 |
| ②元請か再委託か | 窓口企業が実際に開発を担うか、下請けに再委託するかを確認する。 再委託先の管理責任の所在を確認する。 |
「元請（プライムベンダー）として受託します」という文言が契約書にあるかどうかを確認する。 |
| ③体制・チーム構成 | プロジェクトマネージャー・エンジニアの人数と役割。 担当者交代時のルールと引き継ぎ手順。 |
提案書に記載されたメンバーが実際に担当するか、人員確保の保証があるか確認する。 |
| ④コミュニケーション体制 | 定例会の頻度・形式・参加者。 課題・リスクの報告フォーマットとエスカレーション先。 |
口頭合意ではなく、報告体制を業務委託仕様書または別紙で明文化できるかどうか確認する。 |
| ⑤見積りの妥当性・透明性 | 工数・単価・変更対応費の算定根拠。 「含まれないもの」の明示があるか。 |
総額だけでなく工数内訳を提示させ、同じ要件で複数社を比較する。 |
| ⑥契約形態の選択 | 準委任契約（作業提供型）か請負契約（成果物納品型）かの区別。 変更時の取り扱い。 |
要件が固まっていない段階で請負契約を選ぶと、変更費用が膨らみやすい。 |
| ⑦セキュリティ・情報管理 | 機密情報・個人情報の取り扱いポリシー。 サブベンダーへの情報共有範囲。 |
ISMS（情報セキュリティマネジメントシステム）認証の有無や社内規程の水準を確認する。 |
①技術力・開発実績の確認方法
実績確認は、完成した成果物のURLや画面キャプチャだけでなく、プロジェクトの規模・期間・関与した役割を具体的に聞くことが大切です。「御社が元請として担当しましたか、それともサブとして参加しましたか」という質問で、実質的な関与度がわかります。
担当予定エンジニアのスキルシートを提案段階で開示してもらい、類似業務の経験年数を確認することも有効です。
②元請（プライムベンダー）か再委託かの確認
開発会社の中には、顧客との窓口は担うものの、実際の開発作業は別の会社（下請け）に再委託するケースがあります。再委託が悪いわけではありませんが、窓口企業が再委託先の品質と進捗を管理できているかを確認しないと、問題発生時の責任範囲が曖昧になります。
提案依頼の段階で「元請（プライムベンダー）として受託いただけますか、再委託先がある場合はその範囲と管理体制を教えてください」と明示して聞くと、各社の回答から管理意識の差が明確になります。
③〜④体制・コミュニケーション体制の確認ポイント
体制については、「誰が何をするか」だけでなく「誰かが抜けたときどうなるか」を確認します。特に長期プロジェクトでは担当者変更が不可避なため、知識共有の仕組み（ドキュメント化のルール・レビュー体制）を事前に握ることが大切です。
コミュニケーション体制については、週次・月次の定例会の実施義務、課題管理ツール（Redmine、Backlogなど）の共有可否、リスク発生時のエスカレーションルートを業務委託仕様書に明記するよう求めます。
⑤見積りの妥当性を検証するポイント
見積りを比較する際は、工数を「要件定義・設計・開発・テスト・リリース」の各フェーズに分解して提示させます。フェーズ別の工数が極端に少ない箇所がある場合、そこでリスクが顕在化する可能性があります。
同じ要件書をもとに複数社から見積りを取ることで、工数単価の相場感と各社のアプローチの違いが把握できます。価格の安い会社ほどどのフェーズを短縮しているかを確認することが大切です。
⑥契約形態（準委任 vs 請負）の選び方
準委任契約（SES（システムエンジニアリングサービス）型とも呼ばれる作業提供型）は、作業時間に対して報酬が発生する契約です。要件が変動しやすいアジャイル開発や、仕様の詳細が固まっていないフェーズに適しています。
請負契約は、成果物の完成・納品に対して報酬が発生する契約です。要件が明確で成果物の定義が厳密な場合に向いています。ただし、要件変更時の扱いを事前に取り決めておかないと、変更費用でトラブルになるリスクがあります。
契約形態の詳細な違い（指揮命令・偽装請負リスク等）については、派遣と外注の比較記事もあわせてご確認ください。
RFPで複数社を公平に評価するプロセスの進め方
RFP（Request For Proposal：提案依頼書）とは、発注者が要件・評価基準・スケジュールを明文化した文書で、複数の候補会社に対して同一条件で提案を求めるために使います。RFPを活用することで、候補各社の提案を同じ軸で比較でき、選定の公平性と根拠を確保できます。
RFPに盛り込む5項目
- プロジェクト概要：開発の目的・背景・対象ユーザー・現状の課題
- 機能要件・非機能要件：開発範囲・性能・セキュリティ・可用性の要件
- スケジュール・予算：開始希望時期・完了目標・予算規模（概算でもよい）
- 体制・契約形態への期待：元請としての受託を求めるか、再委託の許容範囲
- 評価軸の提示：技術力・実績・体制・価格・コミュニケーション等の評価ウェイト
評価軸を事前に開示することで、候補会社が評価されたい点を強調した提案を出しやすくなり、比較が容易になります。
提案書・デモ・PoC評価の進め方
提案書を受け取ったら、まず評価シート（後述）に基づいて一次評価を行います。一次評価を通過した会社には、プレゼンテーションまたはデモを依頼します。
デモやPoC（Proof of Concept：概念実証）を設定することで、技術力の実証と担当チームのコミュニケーションスタイルを同時に確認できます。特に初めて取引する会社との場合、小規模なPoC案件から始めることも有効です。PoC段階での報告内容・対応速度・成果物の品質を見れば、本開発フェーズの品質感が把握しやすくなります。
複数社比較のための評価シート設計
評価シートは、前述の7軸を評価項目とし、各項目に重み付けを設定します。重み付けの例として、技術力・実績20点、元請体制15点、コミュニケーション体制15点、見積り妥当性20点、契約形態10点、セキュリティ10点、企業信用力10点のように合計100点で設計すると実務上使いやすくなります。
複数の評価者（情報システム部門・開発部門・法務・調達等）がそれぞれ採点し、平均点と各者のコメントを突き合わせることで、選定の恣意性を抑えられます。
元請（プライムベンダー）か再委託かが品質を左右する
開発パートナー選定で特に確認すべき観点のひとつが、受託会社が元請（プライムベンダー）として実際に開発を担うのか、業務を再委託するのかという点です。
再委託構造が引き起こす品質リスク
再委託が行われる場合、発注者と実際の開発者の間に中間業者が入ります。この構造では、品質基準や要件の伝達に遅れやズレが生じやすくなります。また、問題が発生したとき「元請が管理不足だった」「再委託先の作業品質に問題があった」と責任が分散し、迅速な対応が難しくなります。
再委託先の体制・スキル・セキュリティポリシーを元請が適切に管理できているかを確認しないと、発注者が期待した品質水準に到達しない可能性があります。
窓口一本化と責任範囲の明確化
元請（プライムベンダー）に発注するメリットは、窓口が一本化されることにあります。発注者は元請の1社だけとやり取りすればよく、再委託先との個別調整が不要です。問題が発生した場合も元請が一次責任を担うため、対応の速度と責任の明確さが確保されます。
契約書には「業務の全部または主要な部分を第三者に再委託する場合は事前に書面で同意を得ること」という条項を盛り込むと、再委託リスクをコントロールできます。
また、SLA（サービスレベル合意）として「障害発生から〇時間以内に一次報告」「月次報告書の提出期限は翌月〇営業日以内」といった指標を明記することで、元請の責任範囲を具体化できます。
まとめ：技術力・体制・透明性の3軸でパートナーを選ぶ
本稿では開発パートナーの選び方について、失敗パターンの分析から評価軸・RFP活用・元請確認まで整理しました。要点を3つに集約すると次の通りです。
第一に、開発パートナーの評価は7軸で行い、特に「元請（プライムベンダー）かどうか」と「見積りの根拠の透明性」は見落とされやすい観点です。価格の安さや技術スタックの豊富さだけで判断すると、後から体制・コミュニケーション・責任範囲の問題が表面化します。
第二に、RFP（提案依頼書）を活用することで、複数の候補会社を同じ評価軸で比較できます。評価シートに重み付けを設定し、複数の評価者が採点することで、選定の恣意性を抑えられます。
第三に、元請（プライムベンダー）として受託するかどうかを契約書に明記し、再委託が発生する場合の管理責任の範囲を事前に取り決めることが、長期的な開発品質の維持に欠かせません。開発パートナーとの関係は単発の取引ではなく、継続的な協力関係として設計することが大切です。
よくある質問
開発パートナーの選び方でよく使われる評価軸は何ですか
実務上よく使われる評価軸は、技術力・開発実績、元請（プライムベンダー）か再委託かの確認、体制・チーム構成、コミュニケーション・報告体制、見積りの透明性、契約形態（準委任 vs 請負）、セキュリティ・情報管理の7つです。1軸だけを重視せず、7軸すべての水準をRFPを通じて比較することで、後からのトラブルを防ぎやすくなります。
開発会社に見積りを依頼するとき注意すべき点は何ですか
見積りの総額だけでなく、要件定義・設計・開発・テスト・リリースのフェーズ別の工数内訳を開示してもらうことが大切です。工数が極端に少ないフェーズがある場合、そこでリスクが表面化しやすくなります。また「何が含まれていないか」の記載があるかを確認し、変更対応時の単価と手順も事前に確認しておくことで、追加費用のトラブルを防ぎやすくなります。
準委任契約と請負契約はどちらが開発に向いていますか
要件が変動しやすい場合や仕様の詳細が固まっていない段階では、作業提供型の準委任契約が向いています。成果物の定義が厳密で要件変更が少ないプロジェクトには、納品型の請負契約が適しています。いずれの場合も、変更時の対応手順・追加費用の計算方法を事前に書面で定めておくことで、後からのトラブルを防ぎやすくなります。
開発パートナーの実績はどのように確認すればよいですか
実績確認では、完成した成果物のURLやスクリーンショットだけでなく、プロジェクトの規模・期間・関与した役割を具体的に確認します。「元請として担当したか、サブとして参加したか」という質問で実質的な関与度がわかります。担当予定エンジニアのスキルシートを提案段階で提示してもらい、類似業務の経験年数を確認することも有効です。
元請（プライムベンダー）に発注するメリットは何ですか
元請（プライムベンダー）に発注すると、発注者は1社とのやり取りだけで開発全体が管理できます。再委託先との個別調整が不要になり、問題発生時の一次責任が元請に集約されるため、対応速度と責任の明確さが確保されます。また、元請が再委託先の品質と進捗を管理する責任を担うため、発注者が期待する品質水準を維持しやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：経済産業省「IT人材需給に関する調査」（2019年）
