この記事でわかること
Photo by Arnold Francisca on Unsplash
システム開発会社の選び方で最も重要なのは「価格より相性と実績」です。本記事では、依頼前の準備から比較・契約までの具体的な手順と、会社タイプ別の特徴を解説します。選定に迷っている方が、自信を持って判断できる状態になることを目指しています。
この記事は、初めてシステム開発を外注する発注担当者・経営者の方に向けたガイドです。
この記事でわかること
- 開発会社選びで失敗する典型パターンと、その回避方法
- 依頼前に整理しておくべき3つの準備（要件・予算・内製外注範囲）
- 発注先を見極める7つの判断ポイントと、商談での確認質問例
- 大手SIer・中堅・スタートアップなど会社タイプ別の向き不向き
- 契約前に確認すべきチェックリストと、失敗しない比較の進め方
- 候補の会社を公的な情報で確かめる方法と、再委託（下請け）の扱い
システム開発会社選びで失敗する主な原因
Photo by Austin Distel on Unsplash
外注プロジェクトが途中で頓挫したり、納品物が期待と大きくズレたりするケースには、共通したパターンがあります。まず「なぜ失敗するのか」を把握しておくことが、正しい選び方の第一歩です。
価格だけで決めてしまう
複数社から見積もりを取ったとき、最安値の会社を選びたくなるのは自然な心理です。しかし、開発費用が安い理由には「経験の浅いエンジニアが担当する」「仕様変更のたびに追加費用が発生する」「サポートが薄い」といったケースが含まれることがあります。
初期費用だけでなく、運用・保守・改修コストを含めた「総所有コスト（TCO）」で比較する視点が欠かせません。費用の内訳や相場感はシステム開発の費用相場と内訳の解説記事で詳しく整理しています。
要件が曖昧なまま発注する
「とりあえず相談してから決めよう」という進め方は、認識のズレを生みやすいです。開発会社は提示された情報をもとに見積もりを出すため、要件が不明確だと見積もり精度が下がり、後から追加費用が発生しやすくなります。
発注前に「何を・なぜ・誰のために作るのか」を言語化しておくことが、トラブル防止につながります。要件を固める具体的な手順は要件定義の進め方の解説記事を参考にしてください。
運用・保守まで考慮していない
システムは納品がゴールではありません。リリース後のバグ対応、機能追加、サーバー管理など、運用フェーズのコストと体制を事前に確認していないと、後から「保守は別会社に頼むしかない」という状況に陥ることがあります。
失敗パターンと、選定の段階で防ぐ確認の対応表
開発会社選びの失敗は、発注した後に表に出ますが、原因の多くは選定の段階で確認できます。受託開発の側から見て、よく起きる失敗と、契約前に何を確認すれば防げたかを対応させると次のとおりです。
| 発注後に起きる失敗 | 多い原因 | 選定の段階で防ぐ確認 |
|---|---|---|
| 担当者が途中で替わり、品質や速度が落ちる | 提案時に説明した体制と、実際に手を動かす人が違う（再委託を含む） | 担当者の氏名・役割と再委託の有無を、契約前に体制図として文書で受け取る |
| 追加費用が次々に発生する | 見積もりの前提条件と「含まない作業」が書かれていない | 見積書に前提条件・対象外の作業・変更時の単価が書かれているかを見る |
| 納品後に直せない、ほかの会社に引き継げない | ソースコード・設計書の納品と権利の帰属を決めていない | 納品物にソースコードと設計書を含め、著作権の帰属を契約書で確認する |
| 作ったのに現場で使われない | 業務を理解しないまま、要望どおりに作った | 「今回の要件で、やらないほうがいい部分はありますか」と聞き、業務から考えているかを見る |
| 開発会社の撤退や担当者の退職で止まる | 特定の1人に知識が集中し、記録が残っていない | 会社の実在と体制を公的な情報で確かめ、ソースコードを発注側の管理する場所に置く |
| 情報漏えいなどのセキュリティ事故 | 開発環境や顧客データの扱いを確認していない | ISMS・プライバシーマークの有無、なければ社内規程とアクセス管理を文書で確認する |
使われないシステムが生まれる構造は使われないシステムが生まれる理由の記事、引き継げなくなる仕組みはベンダーロックインの記事、開発会社の乗り換えを考える段階の判断はシステム開発の失敗と乗り換え判断の記事で詳しく説明しています。
依頼前に必ず整理しておくべき3つの準備
Photo by Romain Dancre on Unsplash
目的・課題・要件を言語化する
「業務効率化したい」という漠然とした要望ではなく、「月次の請求書処理に毎月40時間かかっているので、自動化したい」のように具体化します。課題の背景・現状のフロー・理想の状態を文書にまとめておくと、開発会社との初回打ち合わせがスムーズになります。
この段階では完璧な仕様書は不要です。A4用紙1〜2枚程度の「要求概要メモ」で十分です。
予算と納期の目安を設定する
予算と納期を「ある程度決めてから相談する」ことで、開発会社も現実的な提案を出しやすくなります。「予算は未定」「納期は早ければ早いほど良い」という状態では、提案の質が下がりがちです。
目安として、Webシステムの場合は数十万円〜数百万円、基幹系システムになると数百万円〜数千万円規模になることが一般的とされています。概算の出し方や見積書の見方はシステム開発の見積もりガイドで解説しています。まず社内で「使える予算の上限」を確認しておきましょう。
内製・外注の範囲を決める
要件定義だけ自社で行い、設計・開発は外注する、あるいは要件定義から一括で任せるなど、どこまでを外注するかを事前に決めておきます。この判断が、依頼する会社のタイプや契約形態の選択にも影響します。
システム開発会社を選ぶ7つのポイント
Photo by Markus Winkler on Unsplash
1. 自社ニーズに近い開発実績があるか
「ECサイト構築が得意な会社」に社内業務システムを依頼しても、ノウハウのミスマッチが起きることがあります。会社のWebサイトに掲載されている事例や、商談時に提示される実績資料を確認し、自社の業種・規模・システム種別に近いプロジェクトを手がけているかを確認しましょう。
確認の質問例：「弊社と同規模・同業種での開発実績を教えていただけますか？」
2. 得意領域・専門分野が自社と合っているか
開発会社によって、Webアプリ・スマホアプリ・組み込み系・AIシステムなど得意領域は異なります。また、特定の業界（製造・医療・物流など）に特化している会社もあります。自社の課題解決に直結する専門性を持つ会社を選ぶことで、提案の質が上がります。
3. 技術スタックと開発体制が適切か
使用するプログラミング言語・フレームワーク・クラウド環境が、自社の既存システムや将来の拡張方針と合っているかを確認します。また、プロジェクトマネージャー・エンジニア・デザイナーなど必要な役割が社内で揃っているか、外部委託（二次請け）が多い体制でないかも確認ポイントです。
確認の質問例：「今回のプロジェクトに関わるメンバーの構成と、外部委託の有無を教えてください。」
4. 要件定義のサポート力があるか
自社で要件を完全に整理できている企業は多くありません。「要件定義から一緒に進めてくれるか」「ヒアリングの質が高いか」を確認することが、システム開発会社の選び方において見落とされがちな重要ポイントです。
初回の打ち合わせで、担当者が「何を実現したいのか」を深掘りする質問をしてくれるかどうかが、サポート力を見極める手がかりになります。
5. コミュニケーションの質と頻度
開発期間中の報告頻度・連絡手段・担当窓口の明確さは、プロジェクトの進行品質に直結します。「週次で進捗報告があるか」「課題が発生したときに迅速に連絡が来るか」「専任の担当者がいるか」を確認しましょう。
商談時の対応スピードや説明のわかりやすさも、実際の開発中のコミュニケーションを予測する材料になります。
6. 納品後の運用・保守サポートがあるか
リリース後のバグ修正・機能追加・サーバー監視などを依頼できるかを、契約前に確認します。保守契約の有無・費用感・対応時間（営業時間内のみか24時間対応か）を明確にしておくことで、運用フェーズのリスクを減らせます。
確認の質問例：「納品後の保守・運用サポートのプランと費用感を教えてください。」
7. 費用の透明性とコストパフォーマンス
見積書の内訳が「一式」でまとめられている場合は注意が必要です。工程・機能・工数ごとに費用が分解されているか、追加費用が発生する条件が明記されているかを確認します。安さだけでなく「何にいくらかかるか」が明確な会社を選ぶことが、後のトラブル防止につながります。
システム開発会社の探し方・比較方法
Photo by Compagnons on Unsplash
比較サイト・マッチングサービスを活用する
開発会社の比較サイトやマッチングサービスを使うと、条件を絞り込んで候補を効率よくリストアップできます。口コミ・評価・実績件数などの情報を参考にしつつ、最終的には直接コンタクトして確認することが大切です。
複数社に相見積もりを取る
1社だけに相談すると比較軸が生まれず、適正価格の判断が難しくなります。一般的には3〜5社程度に相見積もりを依頼するのが目安とされています。同じ要件で複数社に提案を求めることで、費用感・提案内容・対応の質を比較できます。
提案書・見積書の見方と比較ポイント
提案書を比較する際は、「要件の理解度」「提案の具体性」「リスクへの言及があるか」に注目します。見積書は金額だけでなく、工程の分解方法・前提条件・含まれない作業の記載があるかを確認しましょう。
候補の会社を公的な情報で確かめる方法
提案書や会社のWebサイトは、その会社が自分で書いたものです。候補を2〜3社に絞ったら、第三者が管理している情報でも確かめておきます。どれも数分で調べられます。
| 確かめること | 調べる先 | 見るポイント |
|---|---|---|
| 法人として実在するか、所在地 | 国税庁 法人番号公表サイト（無料） | 商号と本店所在地。変更履歴も検索できるので、短期間に商号や所在地の変更が繰り返されていないかを見る |
| 設立日・役員・事業の目的 | 法務局の登記事項証明書（登記情報提供サービスでも閲覧可・有料） | 会社の設立年月日、役員の顔ぶれ、事業の目的にソフトウェア開発が入っているか |
| 情報セキュリティの管理体制 | ISMS認証取得組織検索（ISMS-AC） | 認証の有無と、登録範囲に開発部門が含まれているか |
| 個人情報の取扱い体制 | プライバシーマーク付与事業者情報（JIPDEC）の付与事業者検索 | 付与の有無。顧客データを扱うシステムでは特に重要 |
| 実際に手を動かす体制 | 提案時の体制図と、契約書の再委託条項 | 担当者が自社の社員か、再委託先か |
注意点が2つあります。1つ目に、ISMSは認証を取った組織のうち、公表に同意した組織だけが検索に出ます。検索で見つからないことが、すぐに未取得を意味するわけではありません。 気になる場合は、認証登録番号を会社に直接たずねてください。2つ目に、小規模な開発会社では、ISMSやプライバシーマークを取っていないことも珍しくありません。認証が無いこと自体で候補から外すのではなく、情報管理の社内規程や、開発環境・本番データへのアクセス管理のやり方を、口頭ではなく文書で出してもらえるかで判断します。
再委託（下請け）の扱いを契約前に決める
「実際に手を動かすのは誰か」は、契約の形とも関係します。準委任契約では、民法644条の2により、受任者は委任者の許諾を得たときか、やむを得ない事由があるときでなければ、復受任者（再委託先）を選任できません。一方、請負契約には民法上このような制限の定めが無いため、契約で決めておかないと、開発会社は再委託できると考えられます。
実務では、契約書に「事前の書面による承諾なく再委託しない」という条項を入れ、承諾する場合も再委託先に同じ秘密保持義務を負わせるのが一般的です。再委託をすべて禁止すると、専門的な作業（デザインやセキュリティ診断など）を頼めなくなることもあるため、禁止するより「事前に知らせてもらい、承諾してから」にするのが現実的です。契約形態ごとの違いは請負契約と準委任契約の違いの解説記事にまとめています。具体的な条項の書き方は、弁護士などの専門家に確認してください。
会社タイプ別の特徴と向いているケース
会社タイプごとの違いはSIerと一般の開発会社の違いの解説記事や、大手とベンチャーの開発会社の違いを比較した記事でも詳しく整理しています。あわせて読むと、自社に合うタイプの見当がつきやすくなります。
作りたいものが決まっている場合は、領域別の選び方も参考になります。
- AI・生成AIを使うシステム … AI開発会社の見分け方｜非専門家でも使える7つのチェックポイント
- 販売管理・在庫管理などの業務システム … 業務システム開発会社の選び方と費用相場
- そもそも外注すべきか迷っている … システム開発を外注する7つのメリットと失敗しない選び方
大手SIer・ITベンダー
特徴： 大規模プロジェクトの実績が豊富で、体制・品質管理・セキュリティ対応が充実している。 向いているケース： 数千万円以上の大規模開発、官公庁・金融など高いセキュリティ要件が求められる案件。 注意点： 小規模案件は優先度が下がりやすく、費用が高めになる傾向があります。
中堅・独立系開発会社
特徴： 特定の業種や技術領域に強みを持つ会社が多く、コストと品質のバランスが取りやすい。 向いているケース： 数百万〜数千万円規模の業務システム・Webアプリ開発。 注意点： 会社によって得意領域の差が大きいため、実績の確認が重要です。
スタートアップ・少数精鋭の開発会社
特徴： 機動力が高く、コミュニケーションが取りやすい。新しい技術への対応が早いケースもある。 向いているケース： 小規模なMVP開発、スピード重視のプロトタイプ作成。 注意点： 会社の継続性・体制の安定性を事前に確認することが望ましいです。
契約前に確認すべきチェックリスト
以下の項目を契約前に確認しておくことで、後からのトラブルを減らせます。
- 自社と近い業種・規模の開発実績を確認する
- プロジェクト担当者の名前・役割・経験を確認する
- 外部への再委託（二次請け）の有無と範囲を確認する
- 法人番号公表サイトや登記で、会社の実在と所在地を確認する
- 見積書の工程・機能ごとの費用内訳を確認する
- 追加費用が発生する条件と上限を確認する
- 進捗報告の頻度・形式・連絡手段を確認する
- 納品物の定義と検収条件を文書で確認する
- 納品後の保守・運用サポートの有無と費用を確認する
- 契約形態（請負か準委任か）と責任範囲を確認する
- 知的財産権（著作権）の帰属先を確認する
- 情報漏えい・セキュリティ対応の方針を確認する
相見積もりを「感覚」で比べない｜重み付きスコアシートの作り方
3社から提案を受けても、比較の軸が揃っていないと結局「話しやすかった会社」を選びがちです。提案を受け取る前に評価軸と重みを決めておくと、判断が属人的になりません。
重み付けの例
重みは合計100になるように配分します。以下は「要件がまだ固まっていない中小企業の初回発注」を想定した配分例です。自社の状況に応じて重みは変えてください。 要件が確定済みなら「要件定義の支援力」を下げ、「見積もりの精度」を上げます。
| 評価軸 | 重み | 5点の状態 | 1点の状態 |
|---|---|---|---|
| 近い業種・規模の実績 | 20 | 同業種で同規模の稼働実績を提示できる | 実績が抽象的、または規模が大きく異なる |
| 要件定義の支援力 | 20 | 曖昧な要求を論点に分解して返してくる | 「言われたとおり作ります」で終わる |
| 見積もりの透明性 | 15 | 工程・機能ごとに内訳と前提条件がある | 一式表記、前提条件の記載なし |
| 体制と担当者 | 15 | 担当者の氏名・経験・稼働率が明示される | 「弊社のエンジニアが対応」のみ |
| 運用・保守の設計 | 15 | 納品後の費用と対応範囲が契約前に出る | 「別途ご相談」で金額が出ない |
| コミュニケーション | 15 | 返答が速く、専門用語を翻訳して話す | 反応が遅い、こちらの言葉に合わせない |
使い方
- 提案を受ける前に、上の重みを自社向けに調整して確定させる（後から動かさない）
- 各社を1〜5点で採点し、
点数 × 重みを合計する - 合計点が拮抗したら「1点が付いた軸」を見る。 総合点が高くても、運用・保守が1点の会社は納品後に必ず揉めます
この方式の利点は、社内で意見が割れたときに「どの軸を何点と見たか」で議論できることです。「なんとなくA社が良さそう」という議論は収束しません。
提案を受けたその場で聞くべき5つの質問
スコアの根拠を取るための質問です。回答の歯切れの悪さそのものが情報になります。
| 質問 | 何を見ているか | 注意したい回答 |
|---|---|---|
| 「この見積もりで、想定していない作業が出たらどうなりますか」 | 追加費用のルールが決まっているか | 「その都度ご相談」だけで条件が出てこない |
| 「実際に手を動かすのはどなたですか。再委託はありますか」 | 体制の実在性と多重下請けの有無 | 契約前に体制図が出せない |
| 「要件が途中で変わった案件を、直近でどう進めましたか」 | 変更への現実的な対応力 | 一般論しか出てこない |
| 「納品後1年間の運用費用は概算でいくらですか」 | TCO を提示できるか | 開発費しか話さない |
| 「今回の要件で、やらないほうがいい部分はありますか」 | 発注側の利益で考えるか | 全部やりましょう、しか言わない |
最後の質問は特に有効です。受注額を下げる提案ができる会社は、事業目的から逆算して考えています。 見積もりの妥当性そのものを確かめたい場合は、システム開発の発注チェックリストもあわせて使ってください。
まず何をすべきか：次の3ステップ
システム開発会社の選び方を理解したら、次の3つのアクションから始めましょう。
- 要求概要を文書化する — 目的・課題・理想の状態をA4用紙1〜2枚にまとめる
- 候補を3〜5社リストアップする — 比較サイトや紹介を活用し、自社ニーズに近い実績を持つ会社を選ぶ
- 同じ条件で相見積もりを依頼する — 提案内容・費用・対応の質を比較し、コミュニケーションの相性も確認する
もし要件整理の段階から専門家のサポートが必要な場合は、要件定義支援を提供している開発会社やITコンサルタントに相談することも選択肢の一つです。
「どの開発会社に頼めばいいか」で迷っている方へ
シンシアでは、開発会社選びの壁打ちや、受け取った提案・見積もりの第三者評価を無料で承っています。要件が固まっていない段階でも、要求概要の整理から一緒に進められます。
よくある質問（FAQ）
システム開発会社を選ぶ際に最も重視すべきポイントは何ですか？
一概に「これが最重要」とは言いにくいですが、自社ニーズに近い開発実績と、コミュニケーションの質は特に重要です。技術力が高くても、認識のズレが積み重なるとプロジェクトは失敗しやすくなります。初回打ち合わせでの対応の丁寧さや、質問の深さを観察することをおすすめします。
相見積もりは何社に依頼するのが適切ですか？
一般的には3〜5社程度が目安とされています。1〜2社では比較軸が生まれにくく、6社以上になると評価・調整の工数が増えすぎる傾向があります。まず3社に依頼し、提案内容を見てから追加で検討する方法もあります。
開発実績が少ない会社に依頼するリスクはありますか？
実績が少ない会社がすべてリスクというわけではありませんが、類似プロジェクトの経験が少ない場合、想定外の課題への対処が遅れる可能性はあります。実績が少ない場合は、担当エンジニアの個人的な経験や、小規模な試験的プロジェクトから始めるなどの対策が有効です。
要件定義は自社で行う必要がありますか？開発会社に任せられますか？
要件定義のサポートを提供している開発会社は多くあります。ただし、「何を実現したいか」という業務上の目的や課題は自社にしかわからないため、完全に丸投げするのは難しいです。開発会社と協力しながら進める形が一般的です。
システム開発の費用相場はどのくらいですか？
システムの種類・規模・機能数によって大きく異なります。目安として、シンプルなWebシステムで数十万〜数百万円、業務系システムで数百万〜数千万円、大規模な基幹システムになると数千万円以上になることが一般的とされています。詳細は要件を整理したうえで複数社に見積もりを取ることで把握できます。
システム開発の期間はどのくらいかかりますか？
規模と要件の複雑さによりますが、目安として小規模なWebシステムで1〜3か月、複数部門で使う業務システムで3〜6か月、大規模な基幹システムでは1年以上かかることもあります。要件定義に想定以上の時間がかかるケースも多いため、納期から逆算する場合は早めに開発会社へ相談し、現実的なスケジュールを確認しておくと安全です。
納品後の運用・保守は別途契約が必要ですか？
多くの場合、開発契約と保守契約は別になります。月額固定の保守契約、スポット対応、SLA（サービスレベル合意）付きの契約など形態はさまざまです。契約前に保守の範囲・費用・対応時間を確認しておくことを強くおすすめします。
開発会社が信頼できるかを、公的な情報で確かめるには？
国税庁の法人番号公表サイトで商号と所在地（変更履歴を含む）を、登記事項証明書で設立日・役員・事業の目的を確認できます。情報セキュリティや個人情報の管理体制は、ISMS認証取得組織検索やプライバシーマークの付与事業者検索で確かめられます。ただしISMSの検索に出るのは公表に同意した組織だけなので、見つからない場合は会社に認証登録番号をたずねてください。
再委託（下請け）は禁止したほうがよいですか？
全面的な禁止より、「事前の書面による承諾なく再委託しない」とする方が現実的です。準委任契約では民法上、委任者の許諾かやむを得ない事由がなければ再委託できませんが、請負契約にはこの制限の定めが無いため、契約書で決めておく必要があります。承諾する場合も、再委託先に同じ秘密保持義務を負わせてください。
オフショア開発会社を選ぶ場合の注意点は何ですか？
コスト面でのメリットがある一方、言語・時差・文化的背景の違いによるコミュニケーションコストが増える可能性があります。日本語対応の窓口担当者がいるか、過去の日本企業との実績があるか、品質管理の体制はどうかを確認することが重要です。
契約形態（請負・準委任）の違いと選び方を教えてください。
請負契約は成果物の完成を約束する形態で、仕様が明確な場合に向いています。準委任契約は作業の提供を約束する形態で、要件が変わりやすいアジャイル開発などに向いています。どちらが適切かは開発の性質によって異なるため、開発会社と相談しながら決めることをおすすめします。両者の違いは請負契約と準委任契約の違いの解説記事で詳しく整理しています。
開発会社の比較で、価格以外の軸をどう数値化すればよいですか？
評価軸ごとに重み（合計100）を決め、各社を1〜5点で採点して 点数 × 重み を合計する方法が実務的です。重要なのは提案を受け取る前に重みを確定させ、後から動かさないことです。本文の「重み付きスコアシートの作り方」で配分例を示しています。総合点が拮抗した場合は、1点が付いた軸を優先して見てください。
提案内容が良い会社と、実際に進めやすい会社は違いますか？
違うことがあります。提案書の完成度は営業担当やプリセールスの力量に依存し、実際に手を動かすメンバーとは別であることが少なくありません。契約前に「実際に担当する方の氏名・経験・稼働率」と「再委託の有無」を確認しておくと、このギャップを減らせます。
小規模なシステム開発でも大手に依頼すべきですか？
必ずしもそうではありません。大手SIerは大規模案件を主軸にしているため、小規模案件は優先度が下がったり、費用が割高になったりするケースがあります。小規模開発には、中堅・独立系や少数精鋭の開発会社の方が機動力が高く、コストも合いやすいことがあります。
開発会社との相性を見極めるにはどうすればよいですか？
初回打ち合わせでの「質問の質」を観察することが有効です。自社の課題を深掘りしようとしているか、提案が画一的でなく自社の状況に合わせてカスタマイズされているかを確認しましょう。また、メールや問い合わせへの返信スピードも、実際の開発中の対応を予測する材料になります。
