開発会社の選び方｜実績以外に見るべき7つの比較軸と候補の絞り込み方

システム開発の見積もりを依頼したら、候補が5社にもなってしまった。どの会社のホームページにも立派な実績が並んでいて、正直どこも良さそうに見える。開発会社の選び方で迷う発注者の多くが、この「決め手がない」状態で立ち止まります。

先に結論をお伝えします。実績は「候補に入れるかどうか」を決める入口で、最終的な決め手にはなりにくいものです。本当に差が出るのは、「提案が自社の課題をどれだけ理解しているか」「実際に誰が担当するのか」「見積もりの前提がはっきりしているか」といった、実績の一覧からは見えない部分です。

この記事では、実績以外に見るべき7つの比較軸と、5社程度の候補を無理なく2社まで絞り込む進め方を、比較表・チェックリスト・開発会社への質問例とあわせて解説します。特定の会社をおすすめするものではなく、どの会社を比べるときにも使える「ものさし」の作り方です。

開発会社選びで「実績」だけでは決められない3つの理由

まずは、実績だけで選ぼうとすると迷ってしまう理由を整理しておきます。

理由1：実績の一覧は、どの会社も「良く見える」ように作られている

開発会社のホームページに載っている実績は、その会社が見せたいものを選んで載せています。これは悪いことではなく、どの業界でも同じです。ただ、その結果として、候補の5社がどれも「似た実績を持つ、良さそうな会社」に見えてしまいます。

また、守秘義務で実績を公開できない会社も多く、「掲載実績が少ない＝経験が浅い」とは限りません。

理由2：実績を作ったチームと、あなたの案件を担当するチームは別かもしれない

会社としての実績が豊富でも、実際に案件を担当するのは数人〜十数人のチームです。有名な実績を手がけたメンバーが、あなたの案件にも入るとは限りません。見るべきなのは「会社の実績」よりも「担当予定のチームの経験」です。

理由3：選定で本当に比べるべきは「価格」でも「実績」でもなく総合力

発注先の選び方については、公的機関の資料にも考え方が示されています。

📰 出典：IPA（情報処理推進機構）「情報システム・モデル取引・契約書」第二版

IPAが公開している「情報システム・モデル取引・契約書」の解説では、発注者（ユーザ）は各社から出された提案書とその他の情報を総合的に判断して開発会社を選ぶこと、そして単に安い会社を選ぶのではなく、履行体制（＝実際に作業を進める人員や体制）にも配慮し、TCO（＝導入後の運用・保守まで含めた総費用）で判断すべきことが述べられています。極端な安値には注意が必要だ、という指摘もあります。

つまり、実績や見積金額といった「1つの数字」で決めるのではなく、複数の軸で総合的に比べることが基本です。では、具体的に何を比べればいいのでしょうか。

実績以外に見るべき7つの比較軸

候補を比べるときの軸を、比較表にまとめました。すべてを完璧に見る必要はありません。自社にとって重要な軸を3〜4つ選んで重点的に確認するのが現実的です。

比較軸	何を見るか	どうやって確認するか
1. 課題の理解度	自社の目的や業務を理解した提案になっているか	提案書・初回打ち合わせでの質問内容
2. 担当体制	誰が担当し、再委託（＝一部の作業を他社に任せること）はあるか	体制図・担当予定者との面談
3. 見積もりの透明性	内訳と前提条件が書かれているか	見積書の内訳・前提条件・対象外の項目
4. 進め方と連絡体制	発注者が何をいつ決めるかが明確か	スケジュール案・定例会の頻度・連絡手段
5. 契約条件	契約形態・権利・変更時の扱いが明確か	契約書案・契約条件の説明
6. 公開後の運用・保守	作った後の面倒を誰がどう見るか	保守の範囲・費用・対応時間の説明
7. 情報管理と会社の継続性	情報の扱いと、長く付き合えるか	情報管理の方針・第三者認証・会社情報

軸1：課題の理解度（提案が「自社向け」になっているか）

最も差が出やすいのが提案の中身です。こちらが伝えた目的や困りごとが提案書に反映されているか、どこの会社にも出せる一般的な内容になっていないかを確認します。

分かりやすいサインは、開発会社からの質問の質です。「その作業は月に何件くらいありますか」「例外的な処理はどんな時に起きますか」と業務の中身まで踏み込んで聞いてくる会社は、あなたの業務を理解しようとしています。逆に、要望をそのまま機能一覧にしただけの提案は、後で「思っていたのと違う」が起きやすくなります。

また、「その目的なら、新しく作らず既存のサービスを使う方法もあります」のように、発注者の要望とは違う選択肢を示してくれるかどうかも、課題を理解しているかの目安になります。

軸2：担当体制（実際に誰が作るのか）

📰 出典：IPA「情報システム・モデル取引・契約書」第二版

前述のIPAのモデル契約書の解説では、提案書に書かれるべき内容として、必要な技術・資格・経験を含めた推進体制や責任体制を記述すること、そしてその体制には予定されている再委託先も記述することが挙げられています。

確認したいのは、次のような点です。

• プロジェクトの責任者（PM＝進行管理の責任者）は誰か、他の案件と兼任か
• 自社の窓口になる人は誰か、打ち合わせに出てくるのは誰か
• 開発作業の一部を他社に任せる予定はあるか、ある場合はどの部分か

なお、再委託そのものは珍しいことではありません。同じ解説でも、開発では多数の再委託先を起用している実態があることに触れています。大切なのは「再委託があるかないか」ではなく、誰が責任を持って品質を管理するのかが説明されているかです。

軸3：見積もりの透明性（金額より「前提」を比べる）

5社の見積もりを並べると、金額に大きな差が出ることがよくあります。このとき金額だけを比べるのは危険です。見積もりの差の多くは、会社ごとに「何を含めているか」「どんな前提で計算したか」が違うことから生まれるためです。

比べるべきは、次の3点です。

• 内訳：設計・開発・テスト・導入支援・プロジェクト管理などに分かれているか
• 前提条件：画面数、利用者数、連携するシステムなど、何を前提に計算したか
• 対象外の項目：サーバー費用、データ移行、公開後の保守などが含まれているか

前提条件や対象外の項目がきちんと書かれている見積もりは、それだけ誠実に検討された見積もりだと考えられます。「一式」ばかりで中身が分からない場合は、内訳を出してもらえるか遠慮なく相談しましょう。見積もりの具体的な比べ方は「システム開発の見積もりが3倍違うのはなぜ？相見積もりの正しい比べ方」で詳しく解説しています。

軸4：進め方と連絡体制（発注者の出番が明確か）

システム開発は、発注者が「確認して決める」場面の連続です。

📰 出典：IPA「情報システム・モデル取引・契約書」第二版

IPAのモデル契約書の解説でも、提案書の開発計画には、発注者（ユーザ）が自らの責任で承認しないと次の工程に進めない部分を明確に書くことが挙げられています。

• 定例の打ち合わせはどのくらいの頻度か
• 連絡手段は何か（メール・チャット・電話）、返信の目安はどのくらいか
• 発注者が確認・承認するタイミングはいつで、どれくらいの作業量か
• 途中で動くもの（画面の試作など）を見せてもらえるか

「発注者に何をお願いするか」を最初に説明してくれる会社なら、進行中の相談もしやすくなります。

「発注者の方に決めていただくことを最初に共有できると、後半のスケジュール遅れがぐっと減るんです」

軸5：契約条件（最初に確認しておくほど揉めにくい）

契約形態（請負か準委任か）、完成したシステムの著作権の扱い、仕様変更時の手続き、不具合が見つかったときの対応などは、会社によって考え方が異なります。

📰 出典：IPA「情報システム・モデル取引・契約書」第二版

IPAのモデル契約書の解説でも、提案依頼の段階で契約類型・再委託・損害賠償・知的財産権の帰属・検収や支払いの条件などをあらかじめ明らかにしておく必要があるとしています。

契約条件は、会社を決めてから交渉するものと思われがちですが、比較の段階で「標準的な契約条件」を聞いておくと、後から「その条件だと困る」と振り出しに戻ることを防げます。なお、契約内容の個別の判断は、必要に応じて弁護士などの専門家に確認してください。

軸6：公開後の運用・保守（作った後も付き合えるか）

システムは完成して終わりではなく、公開後の不具合対応、OSやライブラリ（＝システムの部品として使う既製のプログラム）の更新、機能追加が続きます。開発会社を選ぶことは、多くの場合「数年付き合う相手を選ぶこと」でもあります。

• 保守契約の範囲（不具合対応だけか、問い合わせ対応や改修も含むか）
• 月額費用の目安と、範囲外の作業の費用の決まり方
• 障害時の連絡先と対応時間（平日日中のみか、夜間・休日も対応か）
• 将来、別の会社に引き継ぐことになった場合に、設計書などの資料を渡してもらえるか

IPAが「総費用（TCO）で判断すべき」としているのは、まさにこの部分です。開発費が安くても、保守費用が高かったり、改修のたびに大きな費用がかかったりすれば、トータルでは高くつくことがあります。保守費用に何が含まれるのかは「システムの保守費用は何に払っている？月額保守費の内訳」も参考にしてください。

軸7：情報管理と会社の継続性

開発中は、顧客データや社内の業務情報を開発会社に渡すことがあります。情報をどう扱うかの方針は、事前に確認しておきたいポイントです。

📰 出典：IPA「SECURITY ACTION」

目安の一つとして、IPAが運営する情報セキュリティ対策の自己宣言制度「SECURITY ACTION」や、個人情報の保護体制を評価するプライバシーマーク（JIPDECが付与）などがあります。

📰 出典：プライバシーマーク制度「制度概要」

ただし、これらを取得していないから情報管理が不十分、というわけではありません。制度の有無だけでなく、「預けたデータをどこで・誰が扱い、終了後にどう消すのか」を具体的に説明してもらえるかを確認しましょう。

会社の継続性については、会社の所在地や正式な商号を公的な情報で確認しておくと安心です。

📰 出典：国税庁 法人番号公表サイト

国税庁の法人番号公表サイトでは、法人の商号・所在地・法人番号を検索できます。

📰 出典：IPA「情報システム・モデル取引・契約書」第二版

また、IPAのモデル契約書の解説では、提案を依頼する先を選ぶために、開発会社の背景情報や他の顧客の情報、財務状況、組織図などの提供を求めることがあると紹介されています。長く付き合う予定の相手であれば、会社概要を尋ねるのは失礼なことではありません。

5社の候補を2社まで絞り込む3つのステップ

7つの軸を全社で深く確認するのは大変なので、段階的に絞り込みます。

ステップ1：同じ情報を渡して、同じ条件で提案を依頼する（5社）

比較の前提として、全社に同じ資料を渡すことが大切です。目的・現状・予算の目安・希望時期などを1枚にまとめたメモ（作り方は「作りたいシステムを開発会社にどう伝える？」を参照）を用意し、同じ内容で提案と見積もりを依頼しましょう。渡す情報が会社ごとに違うと、提案の差が「会社の差」なのか「伝え方の差」なのか分からなくなります。

提案の依頼時には「提案書に体制図と見積もりの前提条件を入れてください」とお願いしておくと、後の比較が格段に楽になります。

ステップ2：書類で3社程度に絞る（軸1・3を中心に）

届いた提案書と見積書を、次のような簡単な評価シートで比べます。重みは自社の状況に合わせて変えてかまいません。

比較軸	重み	A社	B社	C社	D社	E社
課題の理解度	×3
担当体制	×2
見積もりの透明性	×2
進め方と連絡体制	×1
契約条件	×1
運用・保守	×2
情報管理・継続性	×1

各項目を「◎○△」や1〜3点でつけていきます。点数の合計で機械的に決めるのではなく、「なぜこの点数にしたか」を一言メモしておくのがコツです。社内で説明するときの根拠にもなります。

ステップ3：面談で2社に絞り、担当予定者と話す（軸2・4・6を中心に）

最後の2〜3社とは、営業担当だけでなく、実際に担当する予定のPMやエンジニアに同席してもらって面談します。提案内容への質問に、担当者自身が自分の言葉で答えられるかは、書類からは分からない重要な情報です。

面談では、後述の「開発会社への質問例」をそのまま使ってください。

状況別：どの比較軸を重く見るか

すべての軸が同じくらい重要というわけではありません。案件の性質によって、重く見るべき軸は変わります。

状況	特に重く見たい軸	理由
初めての発注で、社内にITに詳しい人がいない	課題の理解度・進め方	発注者の判断を支えてくれるかが成否を分けるため
取引先や一般の利用者が使うWebシステム	情報管理・運用保守	公開後の障害や情報漏えいの影響が社外に及ぶため
社内の業務システム	課題の理解度・担当体制	業務の細かな例外を理解してもらう必要があるため
予算が限られている	見積もりの透明性・運用保守	何を削れるかと、総費用を判断する必要があるため
長く使い続ける予定のシステム	運用保守・継続性・契約条件	数年後の改修や引き継ぎに影響するため

迷ったときは「このシステムが止まったら誰が一番困るか」を考えてみてください。そこに直結する軸が、最も重い軸です。

開発会社選びでやりがちな失敗

• 一番安い会社に即決する：前提条件や対象外の項目を比べずに決めると、後から追加費用が発生しやすくなります。安い理由が説明できるかを確認しましょう
• 営業担当の印象だけで決める：営業担当は開発の現場に入らないことも多いものです。担当予定者と話してから決めましょう
• 会社ごとに違う情報を渡してしまう：伝え方の差が提案の差になり、公平な比較ができなくなります
• 「実績がある業界」だけで選ぶ：同じ業界でも業務のやり方は会社ごとに違います。自社の業務を理解しようとする姿勢も見ましょう

発注者がやることチェックリスト

• ☐ 自社にとって特に重要な比較軸を3〜4つ選んだ
• ☐ 全社に同じ内容の資料（目的・現状・予算の目安・希望時期）を渡した
• ☐ 提案書に体制図と見積もりの前提条件を入れるよう依頼した
• ☐ 見積もりの内訳・前提条件・対象外の項目を並べて比べた
• ☐ 評価シートに点数と「その理由」を記録した
• ☐ 最終候補の2社で、担当予定のPM・エンジニアと面談した
• ☐ 保守の範囲と費用を含めた総費用で比べた
• ☐ 標準的な契約条件（契約形態・著作権・変更時の扱い）を確認した

開発会社への質問例

面談でそのまま使える質問です。全社に同じ質問をすると、答え方の違いが比較材料になります。

• 「この案件を担当していただく予定の方は、どなたですか？似た規模や内容の案件の経験はありますか？」
• 「作業の一部を他社に依頼する予定はありますか？その場合、品質の管理はどのように行いますか？」
• 「この見積もりの前提条件と、含まれていない作業を教えてください。」
• 「開発中、私たち発注者が確認や判断をするのは、いつ頃・どのくらいの作業になりますか？」
• 「公開後の保守の範囲と費用の目安、そして将来ほかの会社に引き継ぐ場合に受け取れる資料を教えてください。」

答えが具体的か、分からないことを「確認して回答します」と言えるかも、見極めのヒントになります。

まとめ：実績は入口、決め手は「提案・体制・前提」

開発会社を選ぶとき、実績は候補を絞るための入口にすぎません。最終的な判断では、次の点を比べることが大切です。

• 自社の課題を理解した提案になっているか
• 実際に誰が担当し、誰が品質に責任を持つのか
• 見積もりの内訳・前提条件・対象外の項目がはっきりしているか
• 発注者の出番や連絡体制が明確か
• 契約条件、公開後の保守、情報管理まで含めて納得できるか

候補が5社あっても、同じ資料を渡し、書類で3社、面談で2社と段階的に絞れば、無理なく比べられます。まずは自社にとって重要な比較軸を3〜4つ選ぶところから始めてみてください。

あわせて読みたい関連記事