システム開発会社の選び方｜発注前の比較ポイント

システム開発会社は、価格だけでなく、課題理解、提案内容、担当体制、品質管理、見積もりの透明性、契約条件を同じ基準で比較して選ぶことが重要です。候補は3社程度に絞り、実際に担当する責任者との面談を経て決定すると、発注後の認識違いを減らせます。

• システム開発会社の選び方で比較すべき7項目
  • 1. 業界実績より「案件の難しさが近いか」を見る
  • 2. 提案力は「できないことの説明」に表れる
  • 3. 営業担当者ではなく実際の開発責任者を確認する
  • 4. 品質とセキュリティは具体的な工程で確かめる
• 候補探しから契約までの進め方
  • ステップ1：最低限の依頼条件を整理する
  • ステップ2：候補を集めて3社程度に絞る
  • ステップ3：同じ条件で提案を依頼する
  • ステップ4：評価表と面談で決める
• 開発費用の相場と見積もりの見方
  • 見積金額ではなく前提条件をそろえる
  • 初期費用だけでなく3年間の総費用を比べる
  • 要件が曖昧なら調査・要件定義を分けて契約する
• よくある失敗と発注前チェックリスト
  • 失敗1：価格だけで決めて対象外作業が後から判明する
  • 失敗2：営業担当者だけで判断する
  • 失敗3：発注者側の役割を決めていない
  • 失敗4：ソースコードやアカウントの管理を確認しない
  • 契約前の最終チェックリスト
• まとめ
• よくある質問
  • システム開発の相見積もりは何社に依頼すべきですか？
  • 同じ業界の開発実績がある会社を選ぶべきですか？
  • 最も安い見積もりを選ぶと問題がありますか？
  • 要件が固まっていなくても開発会社へ相談できますか？

システム開発会社の選び方で比較すべき7項目

結論として、開発会社は「依頼した機能を作れるか」だけでなく、「事業上の目的を理解し、予算と期限の中で現実的な進め方を提示できるか」で選ぶ必要があります。同じ機能一覧を渡しても、会社によって前提となる品質、テスト範囲、プロジェクト管理、保守性は異なるためです。

発注のご相談を受ける開発会社の立場から見ると、発注者が特に誤解しやすいのは「同じ機能なら見積もりも同じ条件になっている」という点です。実際には、画面上で見える機能が同じでも、障害への備え、セキュリティ、管理画面、データ移行、運用設計によって費用は大きく変わります。

比較する際は、次の7項目を確認してください。

1. 業界実績より「案件の難しさが近いか」を見る

同業界の開発実績は、業務用語や商習慣を理解してもらいやすい点で有利です。ただし、「同業界の実績が多い会社が必ず最適」とは限りません。

たとえば、今回の開発で重要なのが大量データの処理、複数サービスとの連携、厳格な権限管理であれば、業界名よりもこれらの難しさを経験しているかが重要です。実績を確認するときは、次の質問をすると担当範囲を見極めやすくなります。

• その案件では、どの工程を担当しましたか
• 新規開発、改修、保守のどれでしたか
• 開発規模とチーム人数はどの程度でしたか
• 難しかった点と、どのように解決したかを教えてください
• 今回の案件に応用できる知見は何ですか
• 実績として掲載されている企業と直接契約していましたか

守秘義務によって顧客名や詳細を公開できない場合はあります。その場合でも、匿名化したうえで規模、担当工程、技術的な難所を説明できるかは確認できます。

2. 提案力は「できないことの説明」に表れる

信頼できる提案は、発注者の希望をすべて肯定するものとは限りません。予算や納期に対して実現が難しい場合に、理由と代替案を提示できる会社のほうが、発注後の追加費用や遅延を抑えやすくなります。

提案書では、次の内容を確認します。

• 開発の目的と成功条件が整理されている
• 必須機能と後回しにできる機能が分けられている
• 採用する方式と採用しない方式の理由がある
• 発注者側で必要な作業も記載されている
• 想定されるリスクと対処方法が示されている
• リリース後の保守運用まで考慮されている

特に「予算を抑えるなら、どの機能を後回しにするか」という質問への回答は、会社の理解度と優先順位付けの能力を確認するうえで有効です。

3. 営業担当者ではなく実際の開発責任者を確認する

契約前の説明が丁寧でも、契約後に担当者が変わり、意思疎通が難しくなるケースがあります。契約前に、プロジェクトマネージャー（PM＝開発全体の進行・品質・課題を管理する責任者）や主要な担当者と面談してください。

面談では、次の点を確認します。

• PMの類似案件経験と同時担当案件数
• 要件を決める会議に誰が参加するか
• 設計・開発・テストを自社と協力会社のどちらが担当するか
• 週次報告や課題共有をどのように行うか
• 担当者が交代した場合の引き継ぎ方法
• 発注者からの質問や意思決定をどのように管理するか

協力会社やフリーランスを含む体制自体は珍しくなく、それだけで品質が低いとは判断できません。重要なのは、誰が最終責任を持ち、設計や品質を統制するかが明確になっていることです。

4. 品質とセキュリティは具体的な工程で確かめる

「高品質」「セキュリティに配慮」といった表現だけでは比較できません。どの工程で、誰が、何を確認するかを質問してください。

確認対象には、非機能要件（＝速度、安全性、安定性など、画面上の機能以外に求める条件）も含まれます。必要な項目は、非機能要件の決め方｜外注前チェックリストでも詳しく解説しています。

具体的には、以下を確認します。

• 設計やプログラムを別の担当者がレビューするか
• テストの種類、担当者、合格基準は何か
• 不具合をどのように記録し、再発を防ぐか
• 個人情報や機密情報へアクセスできる担当者を制限するか
• 開発用データに本番の個人情報を使用しない設計か
• 脆弱性への対応範囲と公開後の連絡体制はどうなっているか

情報セキュリティ関連の認証は管理体制を判断する材料になりますが、認証だけで個別案件の安全性が保証されるわけではありません。案件に対する具体的な設計と運用を併せて確認する必要があります。

候補探しから契約までの進め方

開発会社の選定は、準備から契約まで3〜8週間程度を確保するのが一般的な目安です。大規模案件や社内稟議、セキュリティ審査が必要な案件では、2〜3か月以上かかることもあります。急いで1社に決めるより、同じ情報を渡して比較できる状態を作ることが重要です。

ステップ1：最低限の依頼条件を整理する

発注前に詳細な仕様書を完成させる必要はありません。しかし、何を解決したいのかが曖昧なままでは、各社が異なる想定で見積もるため比較ができません。

最低限、次の項目を1〜3ページ程度にまとめます。

• 現在の課題と開発の目的
• 想定する利用者と利用人数
• 必ず必要な機能と、あると望ましい機能
• 現在使用しているシステムやデータ
• 他システムとの連携の有無
• 希望する公開時期と、その理由
• 初期開発と保守に使える予算の目安
• 社内の責任者と意思決定者
• 個人情報、決済情報、機密情報を扱うか
• 成功を判断する指標

予算は隠すほど安くなるとは限りません。予算を伝えない場合、開発会社は安全側に多くの作業を見込むか、最低限の構成を想定することになります。「上限1,000万円」「初期開発は500万〜800万円を想定」など、幅を持たせて伝えると現実的な提案を受けやすくなります。

ステップ2：候補を集めて3社程度に絞る

候補探しには、検索、知人からの紹介、比較・マッチングサービスなどがあります。それぞれに特徴があるため、1つの経路だけに依存しないほうが選択肢を確保できます。

最初に5〜10社程度を調べ、企業情報、類似実績、対応範囲、開発体制を見て3社程度に絞ると、比較の質と選定負担のバランスを取りやすくなります。

ステップ3：同じ条件で提案を依頼する

候補会社には、同じ依頼資料と回答期限を提示します。ある会社から重要な質問を受け、その回答が見積もり条件を変える場合は、他社にも同じ情報を共有してください。

提案時に指定しておきたい提出物は次のとおりです。

• 提案書
• 機能別または工程別の見積書
• 開発スケジュール
• 体制図と主要担当者の経歴
• 前提条件と対象外作業の一覧
• 想定リスクと対応策
• 開発後の保守運用費
• 契約形態と支払条件

提案形式をそろえても、各社独自の代替案まで制限する必要はありません。「指定条件での見積もり」と「推奨案」を分けて提示してもらうと、公平な価格比較と提案力の評価を両立できます。

ステップ4：評価表と面談で決める

印象や営業担当者との相性だけで決めず、事前に評価項目と配点を決めます。配点例は次のとおりです。

価格を重視する案件でも、価格だけで半分以上の配点を占めると、必要な品質や体制を評価しにくくなります。自社の目的に応じて配点を調整し、複数人が採点したうえで、評価が分かれた理由を話し合ってください。

開発費用の相場と見積もりの見方

システム開発費は、機能数だけでなく、利用者数、権限、データ量、外部連携、セキュリティ、テスト、移行の難しさで変わります。次の金額と期間は、外注する場合の一般的な目安であり、個別案件の見積額を保証するものではありません。

既存サービスの活用範囲や要件によっては、上記より安く、または高くなる場合があります。クラウド利用料、外部サービス利用料、端末費、データ登録、保守費などが初期見積もりに含まれないケースもあるため、含有範囲を確認してください。

見積金額ではなく前提条件をそろえる

たとえば、A社が800万円、B社が1,200万円だったとしても、A社がデータ移行とセキュリティテストを対象外にし、B社が含めていれば、A社のほうが安いとは断定できません。

見積書では、少なくとも次の項目を確認します。

• 要件定義（＝作るものを決める工程）の範囲
• 画面、機能、権限、外部連携の対象
• デザイン制作と原稿・画像準備の担当者
• インフラ構築とクラウド利用料
• テストの種類、対象端末、対象ブラウザ
• 既存データの整理、変換、移行回数
• 操作マニュアルと利用者教育
• プロジェクト管理費
• リリース作業と公開後の初期対応
• 保守運用の範囲と月額費用
• 対象外作業と追加費用が発生する条件
• 税金、交通費、外部サービス利用料の扱い

また、安い見積もりを提示した会社には、「どの工夫で費用を抑えているのか」を聞いてください。既存部品やクラウドサービスを適切に活用している、機能を段階的に分けているなど、合理的な理由がある場合は有力な選択肢になります。

一方、必要な作業を見積もりから外し、契約後に追加請求する前提で安く見せている場合は注意が必要です。変更時の単価、見積もり方法、承認手続きまで契約前に確認します。

初期費用だけでなく3年間の総費用を比べる

TCO（＝導入から運用・廃止までにかかる総費用）の考え方で比較すると、初期費用が安くても保守費や外部サービス費が高い提案を見つけやすくなります。

3年間で比較する場合は、次の費用を合計します。

• 初期開発費
• 月額または年額の保守費
• クラウド・サーバー利用料
• 外部サービスやライセンスの利用料
• 軽微な改修に使う予算
• 障害対応や監視の追加費用
• 契約終了時のデータ出力・移管費用

保守費は、初期開発費の一定割合で設定される場合と、必要な担当者の稼働量で設定される場合があります。金額だけでなく、問い合わせ可能時間、障害対応時間、軽微な修正を含むかを確認してください。

要件が曖昧なら調査・要件定義を分けて契約する

要件が決まっていない段階で開発全体の固定価格を求めると、開発会社は不確実性を上乗せするか、多数の前提条件を置くことになります。初期調査や要件定義を先に契約し、その成果をもとに開発費を見積もる方法が現実的です。

初期調査・要件整理には、小中規模案件で2〜8週間、50万〜300万円程度かかることがあります。既存システムの解析、複雑な業務整理、多数の関係部署との調整が必要な場合は、それ以上になることもあります。

要件定義と開発で適する契約が異なる場合もあります。請負と準委任の違いや使い分けは、システム開発契約の選び方｜請負・準委任を比較を参考にしてください。

よくある失敗と発注前チェックリスト

開発会社選びの失敗は、会社の技術力不足だけで起こるものではありません。目的や役割分担が曖昧なまま契約し、発注者と開発会社が異なる完成像を持っていることも大きな原因です。

失敗1：価格だけで決めて対象外作業が後から判明する

最安値の会社へ発注した後、データ移行、管理画面、テスト、公開作業が含まれていないことが判明すると、追加費用や納期変更が必要になります。

回避するには、各社の見積もりを機能別・工程別に並べ、金額がない項目を「無料」と判断せず、含まれるか質問してください。比較表には金額に加えて、前提条件と対象外も記載します。

失敗2：営業担当者だけで判断する

提案時の説明と、契約後の進行方法が異なるケースです。営業担当者の説明力は重要ですが、実際のPMや設計担当者の経験、稼働状況、コミュニケーション方法も確認する必要があります。

契約前の面談では、想定トラブルを1つ提示し、「納期に遅れが出そうな場合、いつ、どのように報告するか」を質問すると、進行管理の具体性を確認できます。

失敗3：発注者側の役割を決めていない

開発会社へ発注すれば、社内調整まで自動的に進むわけではありません。業務ルールの決定、資料提供、画面確認、受け入れテストには発注者側の対応が必要です。

少なくとも、次の役割を決めておきます。

• 予算や優先順位を決める責任者
• 日常的に開発会社と連絡する担当者
• 現場業務を説明する担当者
• セキュリティや法務を確認する担当者
• 完成したシステムを確認する利用部門

意思決定者が会議に参加できず、回答に数週間かかると、開発会社だけではスケジュールを守れません。発注者側の回答期限もプロジェクト計画に含めてください。

失敗4：ソースコードやアカウントの管理を確認しない

開発後のソースコード、設計資料、クラウドアカウント、外部サービスの契約名義が開発会社側だけにあると、保守会社を変更するときに移管が難しくなる場合があります。

契約前に、次の点を確認してください。

• ソースコードと成果物の権利は誰に帰属するか
• 発注者がソースコードを閲覧・取得できるか
• クラウドやドメインを誰の名義で契約するか
• 設計書、テスト結果、操作手順を納品するか
• 契約終了時のデータ出力形式と移管支援費用
• 外部ライブラリや有料サービスの利用条件

すべてを発注者名義にすればよいとは限りませんが、将来の保守継続や切り替えを妨げない状態にしておくことが重要です。

契約前の最終チェックリスト

以下の項目に未確認がある場合は、契約前に書面で確認します。

• 開発の目的と成功条件を社内で合意している
• 必須機能と後回しにできる機能を分けている
• 各社へ同じ前提条件を伝えている
• 実際のPMまたは開発責任者と面談した
• 類似実績における具体的な担当範囲を確認した
• 見積書に工程、作業範囲、対象外が記載されている
• データ移行、テスト、公開作業の担当を確認した
• 仕様変更時の追加見積もりと承認方法を確認した
• 発注者側の担当者と意思決定期限を決めた
• 品質管理とセキュリティ対策を具体的に確認した
• ソースコード、データ、アカウントの扱いを確認した
• 検収条件と不具合修正の範囲を確認した
• 保守費と3年間の総費用を比較した
• 契約終了時のデータ返却・移管条件を確認した

自社に合う開発方式や見積もりの比較に迷っている場合は、要件が固まる前の段階でも開発のご相談はこちらからご相談いただけます。

まとめ

システム開発会社を選ぶときは、安さや知名度だけでなく、事業目的を理解して実行可能な計画へ落とし込めるかを確認することが重要です。

• 候補会社は広めに探した後、3社程度へ絞って比較します
• 業界名だけでなく、規模、外部連携、データ移行など案件の難しさが近い実績を確認します
• 営業担当者だけでなく、実際のPMや主要担当者と契約前に面談します
• 見積金額は、作業範囲、前提条件、対象外、追加費用条件とセットで比較します
• 初期費用に加え、保守費やクラウド費を含む3年間の総費用を確認します
• 要件が曖昧な場合は、調査・要件定義と開発を分けて契約する方法を検討します
• 品質、セキュリティ、権利、データ移管、契約終了時の条件を契約前に書面化します
• 発注者側でも責任者、現場担当者、意思決定期限を決めておきます

会社同士の比較だけでなく、「自社が発注後に必要な判断を行える体制になっているか」も成功を左右します。評価表とチェックリストを使い、提案内容と契約条件を客観的に確認してください。

よくある質問

システム開発の相見積もりは何社に依頼すべきですか？

基本は3社程度が適切です。2社では比較材料が少なく、5社以上では質疑応答や提案評価の負担が大きくなります。特殊な技術や業界知識が必要な案件では、候補を広めに探してから3社程度に絞ると進めやすくなります。

同じ業界の開発実績がある会社を選ぶべきですか？

業界実績は有力な判断材料ですが、必須とは限りません。業務フローや法規制への理解に加え、必要な技術、システム規模、外部連携、データ移行など、自社案件と近い難易度の経験があるかを確認してください。

最も安い見積もりを選ぶと問題がありますか？

安いこと自体が問題なのではなく、安い理由を説明できるかが重要です。対象外の作業、再利用する仕組み、開発体制、テスト範囲、追加費用の条件まで確認し、同じ前提で比較できている場合は合理的な選択肢になります。

要件が固まっていなくても開発会社へ相談できますか？

相談できます。ただし、すぐに開発費の確定見積もりを求めるのではなく、要件定義や調査を先に依頼する方法が適しています。解決したい課題、利用者、予算上限、希望時期、絶対に必要な機能を整理しておくと提案を受けやすくなります。