システム開発の外注先を比較するポイント｜進行管理の見える化で選ぶ理由

システム開発の外注先を比較するポイントは、実績数や見積金額といった見えやすい指標ではなく、進行管理をどこまで見える化してもらえるかです。具体的には、見積の粒度・スコープ外項目の明示・変更時の手続きの3点を各社の提出物で見比べます。

「3社から見積もりが届いたけれど、金額も内容もバラバラで、どう並べればいいのか分からない」——相見積もりを取った直後の担当者から、私が最もよく受ける相談です。実績件数を数え、金額を並べ、対応が丁寧そうな会社に絞る。多くの方がそうやって比較しますが、その3つはいずれも、発注後の進み方をほとんど予測してくれません。

この記事では、複数社を並べて比較する場面に絞って、何をどう見比べればいいのかを整理します。抽象的な選定基準ではなく、手元に届いた提案書と見積書のどこを開いて何を確かめるか、というところまで落とし込みます。実際の裁判例と公的な調査データも根拠として使います。

システム開発の外注先を比較するポイントは何か

システム開発の外注先を比較するポイントは、進行管理をどこまで見える化してもらえるかです。実績件数や見積金額は各社の資料に必ず載っている一方で、発注後にプロジェクトがどう進むかはそこには書かれていません。比較して差が出るのは、進め方を契約前にどこまで具体的に提示できるかの部分です。

並べた資料の中で、実際に確認する場所は次の3つに絞れます。急いで判断する必要がある場合は、まずここだけでも見比べてください。

• 見積の粒度——工数が「一式」でまとめられているか、工程や機能の単位で分解されているか
• スコープ外項目の明示——何が含まれるかだけでなく、何が含まれないかが書かれているか
• 変更時の手続き——仕様を変更したいときに、どう合意してどう精算するかが決まっているか

この3点が書かれている会社は、自社の案件を具体的に想定して見積もっています。書かれていない会社は、まだ案件の輪郭がつかめていないか、想定を発注側と共有する工程を省いています。金額の高低より、この差のほうが結果に効きます。

外注先の比較でよくある失敗

外注先の比較で最も多い失敗は、実績件数と合計金額という比べやすい2つだけで順位をつけてしまうことです。どちらも数字で並ぶため比較した気になれますが、実績件数は自社の案件との近さを保証せず、合計金額は含まれる作業範囲が各社で違えば比較になりません。

公的な調査でも、開発の実態は担当者の感覚では読みにくいことが示されています。IPAはエンタプライズ分野のソフトウェア開発データを2004年から蓄積しており、2022年に公開した分析データ集では収集データが5,546プロジェクトに達しました。IPAはこの取り組みの背景として、技術者の経験と勘に頼った方法ではなく、実際のプロジェクトデータに基づいた開発プロセスの改善を行う定量的なプロジェクト管理が必要だと説明しています。同データ集では、前回の2020年版が信頼性は向上するも生産性は低下という傾向だったのに対し、2022年版では信頼性も生産性も低下という傾向になったとされています。

出典：IPA「ソフトウェア開発分析データ集2022」（2022年9月26日公開・取得日：2026年8月27日）

プロが集めた数千件のデータをもってしても定量的な管理が必要だとされる領域を、発注側が実績件数と合計金額の2軸で見極めるのは、そもそも無理があります。だからこそ、各社が自分の案件をどう見積もったかという過程のほうを見る必要があります。

比較すべき7つのポイント

システム開発の外注先を比較するときは、7つのポイントを各社の提出物で確認します。重要なのは「その会社ができるかどうか」を尋ねることではなく、提案書と見積書のどこにどう書かれているかを見比べることです。口頭の説明はどの会社も前向きに答えるため、比較の材料になりません。

※ 提出物の名称や様式は各社で異なります。同等の内容が別の資料に書かれている場合もあるため、見当たらないときは所在を確認してください。

7つのうち、最初に見るべきは①と②です。進行管理の見える化においては、契約前に要件・画面構成・体制・スケジュールを提示してもらえるかどうかが、比較の段階での確認しやすさを左右します。契約前に提示できる資料が多いほど、発注側は判断材料を持った状態で意思決定できます。

③から⑤は、費用と変更に関する項目です。ここが曖昧なまま契約すると、開発中に生じた作業が誰の負担かで揉めます。⑥と⑦は、リリース後まで見据えたときの項目です。開発が終わった瞬間に担当者が入れ替わる体制なのか、保守まで同じチームが見るのかで、運用の負担は変わります。

相見積もりで確認する実務

相見積もりで確認する実務は、合計金額を比べる前に各社の見積書を同じ形に揃えることです。前提条件も作業範囲も違う見積書を金額だけで並べると、最も安い会社が最も範囲の狭い会社だった、という結果になりがちです。揃えるべきなのは、工数内訳・前提条件・スコープ外項目・追加費用の発生条件の4つです。

工数内訳の粒度を揃える

まず、各社の見積書がどの単位で分解されているかを確認します。要件定義・設計・実装・テスト・移行・保守といった工程単位まで分かれていれば、どの工程に厚みを持たせた見積もりかが読み取れます。「開発費一式」のような記載しかない場合は、工程ごとの内訳を出してもらいます。内訳を出せない会社は、まだ作業量を積み上げていない可能性があります。見積書の読み解き方はシステム開発の見積書チェックポイントで詳しく整理しています。

前提条件とスコープ外項目を突き合わせる

次に、各社が置いている前提条件を並べます。既存システムとの連携本数、対応ブラウザやOSの範囲、データ移行の有無、テスト環境を誰が用意するか。これらの前提が違えば金額が違うのは当然で、揃えないまま比較しても意味がありません。前提条件の欄が空欄の会社には、何を前提に見積もったかを書面で確認します。

追加費用の発生条件を確認する

最後に、どうなったら追加費用が発生するのかを各社に確認します。仕様変更の申し出があったとき、既存システム側の仕様が想定と違ったとき、テストで想定外の不具合が出たとき。それぞれの局面で誰がどう負担するかが決まっていれば、発注後の話し合いは進めやすくなります。

この3点が実務上の重点になる理由は、公的な調査結果とも一致しています。JUASが企業のIT部門を対象に実施した調査では、システム開発の予算が予定どおりにならなかったと回答した企業が挙げた要因として、想定以上の現行業務・システムの複雑さが51.4%、計画時の考慮不足が51.0%、仕様変更の多発が48.6%となりました。工期についても、計画時の考慮不足が52.5%、想定以上の現行業務・システムの複雑さが48.8%、仕様変更の多発が42.4%と続いています。いずれも、契約前に前提とスコープを詰めきれていたかに直結する項目です。

出典：JUAS（一般社団法人日本情報システムユーザー協会）「企業IT動向調査報告書2026」（2025年度調査・複数回答／予算 n=245、工期 n=297・取得日：2026年8月27日）

方式や費用相場そのものの目安を先に押さえておきたい場合は、Webシステム開発の費用相場と方式比較もあわせてご覧ください。

自社用の比較チェックリストの作り方

自社用の比較チェックリストは、汎用の項目をそのまま使うのではなく、自社の案件で失敗しそうな箇所から逆算して作ります。手順は次の5ステップです。作成にかかる時間は、社内で1〜2時間を見ておけば足ります。

1. 案件で最も不安な点を3つ書き出す。既存システムとの連携なのか、社内の要件がまとまらないことなのか、リリース後の運用体制なのか。ここが人によって違うため、汎用のチェックリストでは拾えません。
2. 不安ごとに、確認したい質問を1〜2問に落とす。「連携仕様はいつ確定させますか」「要件が固まっていない段階から相談できますか」のように、各社に同じ言葉で聞ける形にします。
3. 前章の7つのポイントから、案件に効く項目を選んで足す。全部を使う必要はありません。5〜7項目に収めたほうが、回答を並べたときに差が読み取れます。
4. 回答を記入する欄を、社名×項目の表にする。自由記述のメモではなく表にしておくと、空欄そのものが情報になります。答えられなかった項目が、その会社の弱い部分です。
5. 提出物のどこに書かれていたかを併記する。口頭の回答と書面の記載を分けて記録しておくと、契約段階で「言った・言わない」になりません。

チェックリストができたら、全社に同じ内容をメールで送ります。同じ質問に同じ形式で答えてもらうことが、比較を成立させる条件です。訪問時の口頭説明だけで判断すると、話し上手な担当者がいる会社が有利になり、進行管理の実力とは別の軸で順位がついてしまいます。

発注先タイプ別の整理

発注先は大きく4つのタイプに整理でき、相見積もりに並んだときの見え方もタイプごとに違います。同じ案件で見積もっても、金額の出方も提案書の厚みも変わるため、タイプを踏まえて読むと比較しやすくなります。

※ 各タイプの特徴は一般的な傾向の整理であり、個々の会社の対応範囲は各社公式発表および提案内容によって異なります。

タイプが違う会社を並べる場合、合計金額の単純比較はほとんど意味を持ちません。前章の手順で前提条件を揃えたうえで、同じ範囲に換算してから比べてください。

外注と内製のどちらで進めるか

外注と内製のどちらで進めるかは、社内に開発を継続できる人員がいるか、そして作るものが自社の競争力の中核にあるかで判断します。比較検討を進める中で見積金額が想定を超えたとき、この問いに立ち返る場面が出てきます。

内製が向くのは、継続的に手を入れ続ける前提のシステムで、社内にエンジニアがいる場合です。仕様変更のたびに見積もりと契約を挟む必要がなく、ノウハウも社内に残ります。一方で、人員が離職すると保守が止まるリスクを常に抱えます。

外注が向くのは、開発の山が一度で、必要な技術が自社の主業務と離れている場合です。専門的な知見を必要な期間だけ確保でき、社内のリソースを本業に残せます。ただし、ノウハウは外部に蓄積されるため、将来的に内製へ切り替える計画があるなら、ドキュメントの納品範囲を契約時に決めておく必要があります。

実務では、上流の要件整理を外部に伴走してもらい、運用フェーズから段階的に社内へ移すという中間の形もよく取られます。どちらかに決めきれない場合は、社内で何を決められて何を決められないかを先に洗い出すのが早道です。その整理の進め方はツール導入前の社内整理でまとめています。

目的別のおすすめ

比較した結果をどう決着させるかは、自社の状況によって変わります。目的別に整理すると次のようになります。

中堅・中小で、契約前に進め方を確認しておきたい場合

要件がまだ固まりきっていない、あるいは社内に開発の経験者がいない場合は、伴走型の開発会社が向いています。伴走型の中には、契約前の段階で技術方針の整理や要件定義・画面構成の可視化を行い、機能一覧・体制・スケジュールを提示する会社もあります。比較の段階で確認したい項目をどこまで提案時点で書面にしてもらえるか、要件定義から運用保守までどの範囲を一貫して担当するかを確認しましょう。

オフショア開発を組み合わせる場合は、国内側の誰が要件整理と品質管理を担い、海外拠点の進行をどう統括するのかもあわせて確認しておくと、コストと進行管理のバランスを判断しやすくなります。

大規模な基幹システムで、安定性を最優先する場合

全社の業務が止まると影響が大きい基幹システムでは、大手SIer型が向いています。長期の保守体制と、障害時に動員できる人員の規模が強みです。金額は高くなりますが、比較の観点としては体制の継続性を優先することになります。

仕様が確定していて、コストを優先する場合

作るものが明確に決まっていて、要件が動く見込みが小さい場合は、オフショア専業型でコストを抑えられます。ただし、仕様変更が発生したときの手続きと費用は、契約前に必ず確認してください。

契約前に必ず確認すべきこと

契約前に必ず確認すべきことは、開発が終わったあとの運用と、セキュリティ設計の責任範囲です。比較の観点を「作れるかどうか」だけに置くと、リリース後に残るリスクが検討から抜け落ちます。開発の見積もりは各社が丁寧に出す一方、運用保守とセキュリティの設定責任は書面で曖昧なまま進みがちな領域です。

確認しておきたいのは次の3点です。

• セキュリティ設定の責任範囲——ネットワーク機器やアクセス制御の設定を誰が行い、誰が確認するか
• 納品時の検証方法——設計書どおりに設定されているかを、どの資料でどう確認するか
• 損害賠償の上限条項——契約書に賠償額を制限する条項があるか、その適用範囲はどうか

3点目は見落とされやすい項目です。多くの開発契約には賠償額を契約金額の範囲に制限する条項が入っており、それ自体は合理的な取り決めですが、どういう場合に適用されないのかまでは説明されないことがあります。

また、認証を保有しているかどうかは、比較の材料にはなっても決め手にはなりません。次に紹介する事案では、提案書で認証取得をアピールしていたことから直ちに具体的な注意義務が生じるとまでは認められない、という判断が示されています。

よくある質問

まとめ