システム開発会社を選ぶとき、多くの人はまず実績の数や会社の規模、知名度を見ます。もちろん参考にはなりますが、それだけでは「自社の案件をうまく進めてくれるか」は分かりません。実績がいくら多くても、自社の業務を理解しようとしない相手や、見積もりの前提をはっきりさせない相手と組めば、プロジェクトはつまずきます。
開発会社選びで本当に確かめるべきなのは、提案書と面談の場で直接確認できることです。こちらの要件をどこまで理解しているか、誰がどんな体制で担当するのか、見積もりは何を前提にしているのか、公開後の保守はどう考えているのか。こうした点は、質問の仕方さえ準備しておけば、専門知識がなくても見極められます。
この記事では、初めて開発会社を選ぶ事業責任者や、複数社の提案を前に判断に迷っている担当者に向けて、提案書と面談で見極める8つの確認点を整理します。確認点ごとの質問例、比較表の作り方、選定までの手順、よくある失敗までをまとめているので、そのまま選定の準備に使えます。
開発会社選びで「実績数」や「規模」だけを見てはいけない理由
実績数や会社規模が判断材料として不十分なのは、それが「過去にできたこと」を示すだけで、「自社の案件で何が起きるか」を示さないからです。
まず、実績として掲げられている案件と自社の案件では、業務の内容も、関係者の数も、求める品質も違います。同じ業界の実績があっても、担当したのは別のチームかもしれません。大きな会社であっても、実際に案件を担当するのは数人のチームであり、そのチームの経験と相性が成否を左右します。
また、会社の規模が大きいほど安心とも限りません。規模の大きな会社は体制や品質管理の仕組みが整っている一方、小さな案件では担当者の優先順位が下がったり、意思決定に時間がかかったりすることがあります。逆に小さな会社は柔軟で速い反面、担当者が抜けたときの代わりがいないリスクがあります。どちらが良いかは案件によって変わります。
だからこそ、比較の軸を「面談で確かめられること」に置くのが有効です。以下の8つの確認点は、いずれも提案書を読み、質問をすることで判断できるものです。
提案書と面談で見極める8つの確認点
8つの確認点と、それぞれで何を見るかを一覧にします。詳しい質問例はこの後で順に説明します。
| 確認点 | 見るべきこと | 危ないサイン |
|---|---|---|
| 1. 要件の理解度 | 目的や業務を自分の言葉で説明できるか | 機能の説明ばかりで目的に触れない |
| 2. 提案の具体性 | 自社向けに考えた提案になっているか | どの会社にも出せる一般論が中心 |
| 3. 担当体制 | 誰が担当し、どこまで社内で行うか | 担当者が決まっていない、再委託が不明 |
| 4. 見積もりの前提 | 何が含まれ、何が含まれないか | 「一式」のみで内訳と前提がない |
| 5. 進め方と意思決定 | 定例会、課題管理、確認の方法 | 進め方の説明がなく「お任せください」 |
| 6. 品質の考え方 | テストの範囲と方法 | テストについて質問しても曖昧 |
| 7. 保守・運用の方針 | 公開後の対応範囲と体制 | 公開後の話が提案に含まれていない |
| 8. 権利と引き継ぎ | ソースコードの権利、資料の納品 | 権利や引き継ぎの話を避ける |
1. 要件の理解度：目的を自分の言葉で言い換えられるか
最初の打ち合わせで伝えた目的や課題を、相手が自分の言葉で言い換えられるかを確認します。「つまり、御社が解決したいのは〇〇ということですね」と要約できる相手は、要件の背景を理解しようとしています。
質問例としては、「今回のシステムで一番大事なことは何だと理解されていますか」「現在の業務で一番困っている点はどこだとお考えですか」などが有効です。ここで機能の話しか返ってこない場合は、目的との結びつきを意識していない可能性があります。
もう一歩踏み込むなら、「この要件の中で、実現が難しそうな点や、確認が必要な点はどこですか」と聞いてみるのも有効です。要件を本当に読み込んでいる相手は、曖昧な箇所やリスクを具体的に挙げてきます。「すべて対応できます」とだけ答える相手より、懸念を率直に伝えてくれる相手のほうが、開発が始まってからの行き違いは少なくなります。
2. 提案の具体性：自社向けに考えられているか
提案書の中に、自社の業務や課題に即した具体的な記述があるかを見ます。会社紹介や一般的な開発工程の説明が大半を占め、自社に関する記述がわずかな提案は、手間をかけずに作られたものかもしれません。
良い提案には、こちらが気づいていなかったリスクや、範囲を絞る提案、既製サービスを活用する代替案などが含まれていることがあります。「ご要望の機能のうち、これは初回は手作業で補えます」といった提案は、目的を理解したうえで費用対効果を考えている証拠です。
3. 担当体制：誰が担当し、どこまで自社で行うか
実際に案件を担当するのは誰か、その人は面談に出ているかを確認します。営業担当だけが面談に出て、開発の担当者には会えないまま契約するのは避けたいところです。
あわせて、開発のどこまでを自社で行い、どこを外部に委託するかも確認します。再委託そのものが悪いわけではありませんが、多重の下請け構造になると、伝言のたびに情報が欠け、責任の所在も曖昧になります。この構造については多重下請け構造の解説も参考にしてください。
4. 見積もりの前提：何が含まれ、何が含まれないか
見積もりの金額そのものより、前提条件と除外事項が明記されているかを見ます。工程ごとの内訳、対応する端末やブラウザ、テストの範囲、データ移行の有無、確認の回数などが書かれているかを確認しましょう。
前提が明記されていない見積もりは、後から「それは範囲外です」と追加費用が発生する原因になります。見積もりの読み方はシステム開発の見積もり比較のコツで詳しく解説しています。
5. 進め方と意思決定：どう確認し、どう決めるか
プロジェクトの進め方について、具体的な説明があるかを確認します。定例会の頻度、課題や質問の管理方法、成果物の確認の仕方、仕様変更が出たときの手続きなどです。
「どのくらいの頻度で、何を見せてもらえますか」と聞いてみてください。動く画面を定期的に見せる進め方であれば、認識のずれに早く気づけます。逆に、最後まで成果物を見せない進め方では、完成してから期待と違うことが分かるリスクがあります。
6. 品質の考え方：テストをどこまで行うか
テストの範囲と方法について質問し、具体的な答えが返ってくるかを見ます。どの段階でどんなテストを行うか、テストの記録を共有してもらえるか、発注側が受入テストで行うことは何かを確認します。
テストの範囲が曖昧なまま契約すると、品質確認の負担が発注側に回ってきます。見積もりが安い理由が、テストの薄さにあるケースもあります。
7. 保守・運用の方針：公開後をどう考えているか
システムは公開してからが本番です。不具合が見つかったときの対応、OSやライブラリの更新への対応、監視の有無、軽微な改修の受け方など、公開後の方針を確認します。
提案書に公開後の話がまったく含まれていない場合は、作って終わりの姿勢かもしれません。保守契約の中身についてはシステム保守契約に含めるべき内容で整理しています。
8. 権利と引き継ぎ：将来の選択肢を残せるか
ソースコードの権利がどちらに帰属するか、設計書や運用手順書を納品してもらえるかを確認します。権利や資料が発注側に残らないと、将来ほかの会社に保守を移したり、内製に切り替えたりすることが難しくなります。
この話題を嫌がる相手には注意が必要です。将来の選択肢を残すことは発注側の正当な関心事であり、誠実な開発会社であれば条件を説明してくれるはずです。
開発会社を選定するまでの手順
8つの確認点を実際の選定に組み込む手順を示します。
- 自社の要件と優先順位を整理する：目的、必須機能、予算の目安、期限、重視する点（速さ、品質、費用、保守体制など）を書き出します。何を重視するかが決まっていないと、比較の軸がぶれます。
- 候補を3〜5社に絞る：紹介、検索、比較サイトなどで候補を集め、得意分野や対応できる規模が合いそうな会社に絞ります。多すぎると比較の手間が膨らみます。
- 同じ資料を渡して提案を依頼する：要件の資料と回答してほしい項目をそろえて渡します。条件がそろっていないと、提案同士を比べられません。
- 面談で8つの確認点を質問する：事前に質問リストを作り、全社に同じ質問をします。開発の担当者にも同席してもらうよう依頼します。
- 比較表で採点する：確認点ごとに評価を書き込み、重視する点に重みを付けて比較します。
- 上位の会社と条件を詰める：見積もりの前提、体制、保守、権利の条件を具体的に確認し、疑問点を解消します。
- 契約条件を確認して決定する：契約形態、支払い条件、検収の方法、仕様変更の扱いを確認したうえで契約します。
選定にかける期間も、あらかじめ決めておくとよいでしょう。期限を決めずに進めると、各社とのやり取りが長引き、提案の前提となる状況が変わってしまうことがあります。逆に急ぎすぎると、確認点を十分に質問できないまま決めることになります。提案の依頼から決定までの日程を最初に各社へ伝えておけば、相手も準備がしやすくなり、提案の質も上がります。選ばなかった会社にも結果と簡単な理由を伝えておくと、将来別の案件で相談するときの関係を保てます。
比較表の作り方と使い方
面談の印象は時間がたつと薄れ、最後に会った会社の印象が強く残りがちです。確認点ごとに評価を記録する比較表を作っておくと、冷静に判断できます。
比較表は、縦に8つの確認点、横に候補の会社を並べ、各欄に「評価（3段階など）」と「根拠となった発言や記述」を書き込む形が使いやすいです。根拠を書いておくと、社内で説明するときにも役立ちます。面談に複数人で参加できる場合は、終わった直後に各自が評価を書き込み、その後で突き合わせると、一人の印象に引きずられずに済みます。
重視する点に重みを付けるのも有効です。たとえば、新規事業で早く検証したいなら「進め方と意思決定」や「提案の具体性」の重みを大きくし、長く使う基幹業務のシステムなら「保守・運用の方針」や「品質の考え方」の重みを大きくします。重みは選定の前に決めておき、提案を見てから変えないことが公平な比較のコツです。
金額は比較表とは別の欄で扱うことをおすすめします。金額を確認点と同じ表で採点すると、安さに引きずられて他の評価がゆがみやすくなるからです。確認点で候補を絞ったうえで、金額と照らし合わせて最終判断するほうが、納得感のある選定になります。
提案書を読むときの順番
提案書は表紙から順に読むより、読む順番を決めておくと比較がしやすくなります。おすすめは、まず「自社の課題をどう理解したか」が書かれた部分を読み、次に「提案する範囲と範囲外」、続いて「体制とスケジュール」、最後に「見積もり」という順番です。最初に金額を見てしまうと、その後の内容を金額の印象で読んでしまいがちだからです。
また、提案書の中で質問したい箇所には、その場で印を付けておきます。面談では印を付けた箇所を中心に質問すれば、限られた時間で各社の考え方の違いを引き出せます。質問への答え方そのものも評価の材料になります。分からないことを分からないと言い、確認して回答すると約束する相手は、契約後のやり取りでも信頼しやすい相手です。
架空の例：2社で迷ったときの判断
ここで、仕組みを理解するための架空の例を紹介します。ある会社が、取引先向けの受発注システムの開発会社を探し、最終的に2社で迷ったとします。
A社は大規模な実績が多く、提案書も厚く整っていました。ただ、面談に出てきたのは営業担当と部門の責任者だけで、実際の担当者は契約後に決めるとのことでした。見積もりは工程別の内訳がありましたが、データ移行が範囲に含まれるかどうかは明記されていませんでした。
B社は規模の小さな会社でしたが、面談には開発の担当者が同席し、こちらの受発注の流れについて具体的な質問を重ねてきました。提案書には「取引先ごとの価格設定は初回は管理画面からの手入力で補い、利用状況を見て自動化を検討する」という範囲を絞る提案が含まれていました。
この会社は比較表に沿って評価し、要件の理解度、提案の具体性、担当体制の3点でB社を高く評価しました。一方で、B社は担当者が少ないため、担当者が不在になったときの対応を確認し、設計書と手順書の納品を契約に入れることで懸念を解消しました。規模の大小ではなく、確認点ごとの評価とリスクへの手当てで判断した例です。
もしこの会社が金額だけで判断していたら、結果は違っていたかもしれません。A社の見積もりはB社より低く見えましたが、データ移行が含まれていない前提でした。移行を加えて条件をそろえると差はほとんどなくなり、比較の焦点は自然と体制と進め方に移りました。金額の比較は、条件をそろえてから行わないと判断を誤らせるという点でも示唆のある例です。
開発会社選びでよくある失敗と避け方
- 金額だけで選ぶ：安い理由が範囲の狭さやテストの薄さにあることがあります。安い理由を確認し、前提をそろえて比較しましょう。
- 営業担当の印象で決める：契約後に実際に一緒に働くのは開発の担当者です。担当者に会い、話のしやすさや理解度を確かめてから決めます。
- 候補を増やしすぎる：10社近くに声をかけると、比較の手間で選定自体が長引きます。事前に絞り込み、3〜5社で丁寧に比べるほうが判断の質が上がります。
- 条件をそろえずに提案を依頼する：各社に違う説明をすると、提案の違いが会社の違いなのか、伝え方の違いなのか分からなくなります。資料と質問をそろえて渡します。
- 公開後のことを確認しない：開発費だけで比較して、保守費用や対応範囲を確認しないと、公開後に想定外の費用や対応の遅さに悩まされます。
- 契約条件を後回しにする：権利の帰属や検収の方法を契約直前に確認すると、条件が折り合わず選定がやり直しになることがあります。気になる条件は面談の段階で確認しておきます。
- 社内の決裁者を選定に巻き込まない：担当者が時間をかけて比較しても、最後に決裁者が別の観点で判断を覆すと、選定はやり直しになります。重視する点と比較表の重みは、選定を始める前に決裁者と合意しておきましょう。
面談前に準備するチェックリスト
- 目的、必須機能、予算の目安、期限をまとめた資料を用意したか
- 重視する点の優先順位と、比較表の重みを決めたか
- 全社に同じ資料と同じ質問リストを渡す準備ができているか
- 開発の担当者に同席してもらうよう依頼したか
- 見積もりの内訳と前提条件、除外事項を出してもらうよう伝えたか
- テストの範囲と受入テストでの発注側の役割を質問する準備があるか
- 公開後の保守の範囲と体制を質問する準備があるか
- ソースコードの権利と資料の納品について質問する準備があるか
- 社内の決裁者に、選定の基準と進め方を共有したか
提案を依頼する際の資料づくりはRFP（提案依頼書）の書き方で詳しく扱っています。依頼先の候補にフリーランスも含める場合は、フリーランスと開発会社のどちらに頼むべきかもあわせてご覧ください。
よくある質問
Q. 何社くらいから提案をもらうのがよいですか？
案件の規模にもよりますが、3〜5社程度が比較しやすい数です。それより多いと比較の手間が大きくなり、少なすぎると相場観や提案の幅がつかみにくくなります。
Q. 業界の実績がない会社は避けるべきですか？
必ずしも避ける必要はありません。業界の知識は発注側が補えることも多く、それより要件の理解度や進め方のほうが成否を左右することがあります。面談で業務について質問を重ねてくるかどうかで、理解しようとする姿勢を確かめましょう。
Q. 面談で開発の担当者に会わせてもらえない場合はどうすればよいですか？
契約前に担当者が決まらない事情があることもありますが、その場合は担当予定者の経験や、担当が決まった後に面談の機会を設けられるかを確認します。担当者との相性を確かめる場を契約前に持てるかどうかは、重要な判断材料です。
Q. 提案書の出来栄えはどこまで重視すべきですか？
見た目の整い方より、自社向けに考えられた中身があるかを重視します。分厚く整った提案書でも一般論が中心なら評価は高くできませんし、簡素でも課題を正しく捉えた提案は価値があります。
Otsumuに相談できること
要件と優先順位がはっきりしていて、社内に比較表を作って選定を進められる担当者がいる場合は、この記事の確認点と手順に沿って進めれば、自社に合った開発会社を十分に選べます。選定の過程そのものが、自社の要件を見直す良い機会にもなります。
一方で、何を基準に選べばよいか分からない、提案の良し悪しを判断できない、そもそも作るべきものが定まっていない、といった場合は、事業と開発の両方を理解する相手に相談したほうが早く進むことがあります。選定の前に要件や範囲を整理しておくと、各社からより具体的な提案を引き出せます。
Otsumuは、自ら事業を手がける実践者として、目的から逆算して必要な機能に絞る提案を行い、構想から開発・運用・改善までを一気通貫で担当しています。AIを活用した開発で少人数・短期間で進められるのも特徴です。システム開発のページでは種類別の進め方を紹介しています。依頼先の一つとして比較いただくことも、選定の考え方についての相談も歓迎しています。
まずは30分の無料相談で、検討中の案件についてお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01