システム開発会社の選び方｜比較の観点とチェックリスト
技術力の見極めは難しくても、「聞き方」を変えれば差は見えてきます。
システム開発の発注が難しいのは、出来上がるまで中身が見えないからです。 ホームページと違い、途中の成果物を見ても良し悪しが判断しにくく、 失敗に気づくのは納品間際になります。
そこで、技術を評価するのではなく「聞き方」で差を見る方法を整理します。 発注が初めてでも使える観点です。
1. 会社の種類を知る
同じ「システム開発会社」でも、成り立ちによって得意なことが違います。
| 種類 | 得意なこと | 注意点 |
|---|---|---|
| 受託開発（自社で作る） | 要件定義から実装まで一貫。仕様変更にも比較的柔軟 | 会社の規模で対応できる案件量に上限がある |
| SIer（大規模・多重下請け） | 大規模案件の管理、基幹システムとの連携 | 実際に作るのは別会社のことがある。誰が書くのかを確認 |
| SES（人を出す） | 自社に開発チームがある場合の増員 | 「完成させる責任」は基本的に負わない |
| Web系開発会社 | Webサービス、業務のWeb化、UIまで含めた設計 | 会計・生産管理など業務知識が必要な領域は要確認 |
| オフショア活用 | 単価が安い。まとまった開発量がある案件 | 仕様書の粒度が細かく必要。別記事で解説 |
「作りたいもの」と会社の型が合っていないと、どれだけ優秀でも噛み合いません。 最初に相手がどの型かを聞いておいてください。
2. 実績は「規模」と「業務」で見る
実績一覧を見ても、自社に当てはまるかは分かりません。次の2軸で確認してください。
- 規模が近いか：500万円の案件と5,000万円の案件では進め方がまったく違います。
- 業務が近いか：在庫・受発注・会計などは業界特有の慣習があり、 経験があると説明の手間が大きく減ります。
「この案件で、いちばん大変だったのはどこですか？」
実際に手を動かした会社は、仕様変更・データ移行・性能問題など具体的に答えます。
答えが抽象的なら、営業と開発が分断されているか、下請けに丸投げしている可能性があります。
3. 誰が担当するのかを確認する
提案の場に来る人と、実際に作る人が違うことは珍しくありません。 成果物の質は担当する個人に大きく左右されます。
- 提案してくれた人は、この案件に入るのか。入るなら何%の稼働か。
- 要件定義は誰がやるのか（営業か、エンジニアか）。
- 実装は自社の社員か、パートナー会社か。パートナーなら何社入るか。
- プロジェクトマネージャーは何案件を並行して見ているか。
聞きにくい質問に思えますが、まともな会社ほど率直に答えます。 はぐらかされたら、それ自体が判断材料です。
4. 見積もりの読み方
金額の合計ではなく、内訳の比率を見てください。 一般的なシステム開発では、次のような配分になります。
| 工程 | 全体に占める割合の目安 | 薄いときに起きること |
|---|---|---|
| 要件定義 | 10〜20% | 作ってから「思っていたものと違う」となる |
| 設計 | 15〜25% | 後半で作り直しが発生する |
| 実装 | 30〜40% | — |
| テスト | 20〜30% | 納品後に不具合が続出する |
| プロジェクト管理 | 10%前後 | 進捗が見えず、遅延に気づくのが遅れる |
テストが極端に薄い見積もりは要注意です。 安く見えても、公開後の障害対応で結局同じだけ払うことになります。 詳しい内訳は システム開発の費用相場 にまとめています。
5. 見えないところの要件を聞く
機能の話は誰でもします。差が出るのは非機能の話題です。 相手から次の質問が出てくるかを見てください。
- 同時に何人が使いますか（ピーク時は？）
- データはどのくらいの量になりますか。何年分保持しますか
- 止まると業務にどれくらい影響しますか
- 誰がどこからアクセスしますか（社内のみ／外部含む）
- 個人情報や決済情報を扱いますか
これらを聞かずに見積もりを出す会社は、あとで「その要件は含まれていません」と言います。
・要件をほとんど聞かずに金額が出てくる
・「何でもできます」と言い、できないことを挙げない
・見積もりが「一式」でしか書かれていない
・契約形態（請負か準委任か）の話を避ける
・ソースコードの権利や引き渡しについて明言しない
どれも、後で揉める典型的な入口です。契約の観点は
請負と準委任の違い を参照してください。
6. 開発中のコミュニケーションを決めておく
発注前に、次の3つを取り決めておくと進行が安定します。
- 定例の頻度：週1が標準。月1だと軌道修正が効きません。
- 動くものを見せるタイミング：早い段階で触れると認識のズレが減ります。
- 仕様変更の扱い：どこまでが範囲内で、どこからが追加費用かの基準。
7. 保守まで含めて判断する
システムは作って終わりではありません。むしろ運用のほうが長く続きます。 発注時点で次を確認してください。
- 保守の月額と、含まれる作業の範囲
- 障害時の連絡先と、対応する時間帯
- 担当者が辞めたときに引き継げる状態か（ドキュメントの有無）
- 別の会社に引き継ぐ場合、ソースコードと設計書を渡してもらえるか
費用の目安は システムの保守・運用費用の相場 にまとめています。
よくある質問
何社くらいから見積もりを取るべきですか？
3社が現実的です。1社だと金額の妥当性が判断できず、5社を超えると説明と比較の手間が発注側の負担になります。ただし全社に同じ資料を渡してください。伝えた内容が違うと比較になりません。
技術力はどう見極めればよいですか？
発注側が技術を評価するのは困難です。代わりに「似た規模・似た業務の実績があるか」「その案件で何が大変だったかを説明できるか」を聞いてください。実際にやった会社は失敗談を具体的に話せます。良いことしか言わない提案は、経験が浅いか、話を聞いていないかのどちらかです。
安い見積もりを選んで大丈夫ですか？
金額だけで比べないでください。安い見積もりは「テストが含まれていない」「要件を狭く解釈している」「若手だけの体制」のいずれかであることが多く、追加費用や納期遅延として戻ってきます。安い理由を説明できる会社なら問題ありません。
大手と中小、どちらに頼むべきですか？
予算と、求める安定性で決まります。数千万円以上・長期運用が前提なら体制が厚い会社、数百万円規模でスピードを重視するなら小回りの利く会社が向きます。重要なのは規模ではなく、<strong>その会社の中で誰が担当するか</strong>です。
まとめ
- 技術力を直接評価するより、実績・体制・聞かれる質問で判断する。
- 「この案件で大変だったところ」を聞くと、実際にやった会社かが分かる。
- 見積もりは合計ではなく、工程ごとの比率を見る。テストが薄いものは危ない。
- 非機能（同時利用者・データ量・停止許容時間）を聞いてくる会社を選ぶ。
- 保守と引き継ぎの条件まで含めて比較する。
掲載している金額は、一般的な発注で見かける水準をもとにした目安です。 実際の費用は要件・地域・体制によって変わります。必ず複数社から見積もりを取り、 「何が含まれていて、何が含まれていないか」を比べたうえでご判断ください。