# 開発会社への質問リスト｜商談での見極め方 - 公開日: 2026-10-16 - 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星 - URL: https://www.geek-bridge.com/public/column/development-company-interview-questions 開発会社を商談で見極めるには、実績数よりも「前提を確認する質問」「見積もりの除外範囲」「担当者と意思決定体制」「品質・保守・権利」を具体的に聞くことが重要です。候補3〜5社へ同じ質問を行い、回答の根拠と透明性を採点すると、価格だけでは見えない発注リスクを比較できます。 ## 開発会社との商談で確認すべきポイント 開発会社との商談は、単に見積金額を聞く場ではありません。自社の目的を正しく理解し、予算や期限の制約を踏まえて、現実的な進め方を提案できる会社かを確認する場です。 発注者が確認すべきポイントは、大きく次の6つです。 - 事業目的と利用者を理解しているか - 不明点やリスクを自ら発見して質問できるか - 見積もりの前提・内訳・除外範囲が明確か - 実際に担当する人と開発体制が見えるか - 品質管理やセキュリティの進め方が具体的か - 納品後の保守、権利、アカウント管理まで考慮しているか 実績が豊富でも、今回の案件に適した進め方ができるとは限りません。反対に、同じ業界の実績が少なくても、業務を丁寧に理解し、類似する技術・運用上の課題に対応した経験があれば、有力な候補になり得ます。 ### 選定にかかる期間の目安 候補会社を探し始めてから契約するまでの期間は、一般的に3〜6週間程度が目安です。稟議や契約審査が必要な企業では、さらに1〜2週間以上かかる場合があります。 | 段階 | 期間の目安 | 発注者が行うこと | |---|---:|---| | 依頼資料の準備 | 3〜5営業日 | 目的、機能、予算、期限を整理する | | 候補会社の絞り込み | 3〜7営業日 | 実績、得意領域、会社情報を確認する | | 初回商談 | 1週間程度 | 同じ資料と質問を各社へ提示する | | 質疑・提案・概算見積もり | 1〜2週間 | 追加質問へ回答し、提案を比較する | | 最終面談・条件調整 | 3〜7営業日 | 体制、範囲、契約条件を確定する | | 契約・社内決裁 | 1〜2週間 | 法務確認、稟議、発注手続きを行う | 初回相談や概算見積もりは無料の会社が多い一方、詳細な要件整理や既存システムの調査は有料になることがあります。ディスカバリー（＝本開発前に課題・要件・技術リスクを調べる工程）として切り出す場合、規模や調査範囲により数十万〜数百万円、期間は2〜6週間程度が一般的な目安です。 無料で詳細な調査まで求めるより、調査の成果物と費用を明確にして依頼したほうが、その後の見積もり精度を高められる場合があります。 ## 初回商談前に準備する情報 商談前には、完成した仕様書ではなくても、各社が同じ前提で提案できる資料を用意します。資料の完成度以上に重要なのは、確定事項と未確定事項を分けて伝えることです。 最低限、次の情報を1〜3ページ程度にまとめておきましょう。 - 開発を検討した背景と解決したい課題 - システムを利用する人と利用場面 - 必須機能と、できれば追加したい機能 - 現在の業務方法や既存システム - 連携が必要な外部サービスや社内システム - 希望する公開時期と、その期限を設定した理由 - 初期開発と運用に使える予算の目安 - セキュリティ、社内規程、利用端末などの制約 - 社内の決裁者、窓口、現場確認者 - 今回の選定基準と選定予定日 画面数が多いシステムやWebサービスでは、文章だけでなく、利用者がどの画面を通るかを簡単な図にすると認識が合いやすくなります。詳しい整理方法は、[画面遷移図の作り方｜開発依頼前の準備](https://www.geek-bridge.com/column/screen-flow-diagram-guide)も参考にしてください。 ### 予算は幅を持たせて共有する 予算を伏せれば安い提案を得られるとは限りません。開発会社は、予算が分からなければ安全側に多くの機能や作業を盛り込むか、反対に最低限の条件で見積もることになります。その結果、各社の提案条件がそろわなくなる可能性があります。 たとえば「初期開発は800万〜1,200万円を想定している」「まず500万円以内で検証版を公開し、その後に追加投資を判断したい」のように幅と投資方針を伝えます。そのうえで、予算内で実現できる範囲と、後回しにすべき範囲を提案してもらいましょう。 ### 発注者側の確認体制も伝える 開発会社だけでシステム開発を完結させることはできません。業務ルールの確認、画面の承認、テストデータの準備、受入確認などは、発注者側の協力が必要です。 誰がどの判断を行うのかが決まっていない場合、開発会社が優秀でも進行が止まります。必要な役割や工数は、[システム開発の発注者体制｜役割・工数・作り方](https://www.geek-bridge.com/column/system-development-client-team)で詳しく解説しています。 ## 開発会社を見極める質問リスト 質問は「対応できますか」という二択ではなく、「どのように進めますか」「その判断の根拠は何ですか」と聞くのが基本です。ここでは、初回商談と提案面談で使える質問を分野別に紹介します。 ### 1. 課題理解と提案力に関する質問 まず、自社の依頼内容をどの程度理解し、開発範囲を主体的に考えられるかを確認します。 - 当社が今回解決したい課題を、どのように理解していますか - 現時点で不足している情報や、判断できない点は何ですか - この計画で実現が難しい部分や、優先順位を下げるべき部分はありますか - 同種の課題に対応した経験と、その案件での担当範囲を教えてください - 当社案以外に、費用や期間を抑えられる方法はありますか - 最初の公開時点で外してもよい機能はどれですか - 開発せずに既存サービスを利用したほうがよい部分はありますか - 成功を判断する指標をどのように設定しますか 良い開発会社は、依頼内容をそのまま肯定するだけでなく、目的に対して不要な機能や見落としている運用を指摘します。ただし、初回商談の段階ですべての正解を求める必要はありません。分からないことを分からないと明示し、確認方法を示せるかが重要です。 類似実績を聞くときは、会社名や件数だけでなく、実際の担当範囲を確認してください。「同業種のシステムを開発した」という実績でも、一部機能のみを担当した場合と、要件整理から保守まで担当した場合では経験の内容が異なります。 ### 2. 見積もりとスケジュールに関する質問 見積金額そのものより、金額を算出した条件と変動要因を確認します。 - 見積もりはどの資料と前提条件を基に算出しましたか - 要件定義（＝作るものと条件を具体化する工程）、設計、開発、テストの費用内訳はありますか - プロジェクト管理や打ち合わせの費用は含まれていますか - 見積もりに含まれていない作業は何ですか - 外部サービスの利用料、サーバー費、ライセンス費は含まれていますか - 仕様変更が発生した場合、費用と納期をどう決めますか - 発注者側で行う作業と必要な工数を教えてください - スケジュール上の重要な判断期限はいつですか - 遅延が発生しやすい箇所と、その対策を教えてください - 本開発前に有料調査を行う必要はありますか 見積書では、要件定義、設計、実装、テスト、公開作業、プロジェクト管理、インフラ、保守を分けて確認します。「システム開発一式」としか記載されていない場合は、内訳と除外項目を追加で依頼しましょう。 安価な見積もりが提示された場合も、すぐに評価するのではなく、テスト、データ移行、既存システム連携、公開後の不具合対応などが外れていないかを確認します。反対に高額な見積もりには、どのリスクを見込み、どの品質や体制を確保するための金額なのかを聞きます。 ### 3. 担当者と開発体制に関する質問 提案した営業担当者ではなく、契約後に誰が責任を持つかを確認します。 - 契約後の責任者と日常の窓口は誰ですか - プロジェクトマネージャー（PM＝進行・予算・品質を管理する責任者）は専任ですか - 初回商談や提案に参加した人は、開発開始後も関与しますか - 実際の担当者の経験と、今回の稼働予定を教えてください - 再委託や外部パートナーを利用する予定はありますか - 担当者が交代する場合の引き継ぎ方法を教えてください - 課題や遅延は、どの頻度・形式で報告されますか - 意見が分かれた場合、最終的に誰が判断しますか - 緊急時の連絡とエスカレーション（＝上位責任者へ判断を引き上げること）の手順はありますか 開発会社へのご相談を受ける立場でも、発注者からよく聞かれるのが「営業担当者の印象は良かったが、実際の担当者が分からない」という問題です。可能であれば契約前の最終面談にPM候補者や主要担当者の参加を依頼し、説明力や相性を確認してください。 再委託自体が問題なのではありません。再委託先を含めた責任の所在、情報管理、品質確認の方法が明確かを確認することが大切です。 ### 4. 品質とセキュリティに関する質問 品質は「十分にテストします」という説明だけでは判断できません。どの段階で、誰が、何を確認するかを具体的に聞きます。 - テストの種類と実施担当者を教えてください - テスト項目や結果は発注者にも共有されますか - 受入テスト（＝発注者が業務上問題なく使えるか確認するテスト）はいつ行いますか - 不具合の重要度と修正優先順位をどう判断しますか - コードレビュー（＝別の技術者がプログラムを確認すること）は行いますか - セキュリティ要件はどの段階で決めますか - 個人情報や機密情報をどのように取り扱いますか - 開発環境、テスト環境、本番環境は分離されますか - 障害発生時に原因を調べるための記録は残りますか - バックアップと復旧方法は誰が設計しますか 確認したいのは、特定の技術用語に詳しいかではなく、想定される事故と事業への影響を説明できるかです。たとえば個人情報を扱うサービスなら、不正アクセス対策だけでなく、権限設定、操作記録、退職者のアカウント停止、データ削除なども検討対象になります。 必要な品質はシステムの用途によって異なります。社内の限定的なツールと、決済や個人情報を扱う一般公開サービスに、同じ品質水準を求める必要はありません。用途に応じた費用配分を提案できるかを見ます。 ### 5. 契約・納品・保守に関する質問 開発中だけでなく、納品後に自社で管理し続けられる条件かを確認します。 - 契約は請負と準委任のどちらを想定していますか - 納品物には何が含まれますか - ソースコード、設計資料、テスト結果は受け取れますか - 著作権や成果物の利用権はどちらに帰属しますか - サーバー、ドメイン、外部サービスの契約名義は誰になりますか - 検収条件と検収期間はどのように設定しますか - 検収後に不具合が見つかった場合の対応条件は何ですか - 公開後の保守範囲と月額費用の目安を教えてください - 将来、別の会社へ保守を移管する場合に必要なものは何ですか - 契約終了時のデータ返却・削除・引き継ぎ条件はありますか 請負契約は完成した成果物の納品を約束する契約、準委任契約は専門業務を適切に遂行する契約です。どちらが優れているというものではなく、仕様の確定度や開発の進め方に合わせて選びます。 特に、クラウド、ドメイン、アプリストア、外部サービスなどの重要なアカウントは、原則として発注者名義で作成できるか確認してください。開発会社名義のままだと、保守会社の変更や契約終了時に移管が難しくなる場合があります。 ## 回答・見積もりを公平に評価する方法 各社の印象だけで決めず、同じ評価項目と配点で記録することが重要です。商談直後に複数の参加者が個別採点し、その後に評価理由を話し合うと、知名度や営業担当者の印象への偏りを抑えられます。 ### 評価表の例 | 評価項目 | 配点例 | 確認する内容 | |---|---:|---| | 課題理解 | 20点 | 目的、利用者、業務を理解しているか | | 提案力 | 15点 | 優先順位や代替案を提示できるか | | 見積もりの透明性 | 20点 | 前提、内訳、除外項目が明確か | | 体制・コミュニケーション | 15点 | 担当者、報告方法、責任者が明確か | | 品質・セキュリティ | 15点 | テストとリスク対策が具体的か | | 契約・継続性 | 15点 | 権利、アカウント、保守、移管条件が適切か | | 合計 | 100点 | 自社の優先順位に応じて配点を調整する | 各項目を5段階で採点する場合は、「評価点÷5×配点」で換算できます。ただし、合計点だけで自動的に決定してはいけません。セキュリティ、契約条件、担当体制など、一定水準を下回った場合に候補から外す項目も事前に決めておきます。 ### 良い回答と注意が必要な回答 | 確認内容 | 評価しやすい回答 | 追加確認が必要な回答 | |---|---|---| | 未確定事項 | 不明点と確認方法を説明する | 根拠なく「すべて対応可能」と答える | | 見積もり | 前提、内訳、除外項目がある | 総額だけで算出根拠がない | | スケジュール | 発注者の作業や判断期限も示す | 開発会社側の工程しか示さない | | 体制 | 実担当者、役割、稼働予定が分かる | 契約後に担当者を決める | | 品質 | テスト内容、担当、成果物が分かる | 「十分に確認する」という説明のみ | | 仕様変更 | 判断・見積もり・承認手順がある | 口頭で「柔軟に対応する」とだけ答える | | 保守・移管 | 必要資料と引き継ぎ条件が明確 | 他社への移管を想定していない | 注意が必要な回答が一つあっただけで、不適切な会社と判断する必要はありません。初回商談では情報が不足している可能性もあるため、追加質問への対応速度と回答内容も含めて評価します。 ### 総額ではなく条件をそろえて比較する 見積金額が大きく異なるときは、各社の単価差だけが原因とは限りません。含まれる機能、テスト範囲、管理工数、インフラ構成、保守、リスクの見込み方が異なる可能性があります。 次の項目を横並びにしてください。 - 初期開発に含まれる機能 - 要件定義、デザイン、テスト、公開作業の有無 - データ移行と外部システム連携の範囲 - 発注者が担当する作業 - 外部サービスやインフラの初期費用 - 月額保守費とサービス利用料 - 仕様変更時の単価や算定方法 - 検収後の不具合対応期間 - ソースコードや資料の納品範囲 初期費用が安くても、月額費用や改修費が高ければ、中長期の総額は高くなる場合があります。TCO（＝導入後の保守・利用料まで含めた総保有コスト）を、少なくとも公開後1〜3年程度の想定で比較しましょう。 要件が不明確で各社の金額差を説明できない場合は、すぐに本開発を発注せず、要件整理や技術調査だけを小さく依頼する方法もあります。開発範囲、成果物、調査後の本開発契約が任意であることを確認したうえで進めてください。[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からも、発注前の要件整理や見積もり条件についてご相談いただけます。 ### よくある選定の失敗と回避策 開発会社選びでは、質問の数より、回答をどのように判断するかが重要です。特に次の失敗に注意してください。 - **価格だけで決める**：安さの理由が、効率化なのか作業範囲の不足なのかを確認します。 - **営業担当者だけで判断する**：契約前にPM候補者や主要担当者と話します。 - **実績の社数だけを見る**：今回と共通する課題、担当範囲、成果物を確認します。 - **各社へ違う情報を渡す**：同じ資料、質問、回答期限を設定します。 - **口頭説明だけで決める**：重要な回答は提案書、見積書、議事録、契約書へ反映します。 - **「柔軟に対応」を鵜呑みにする**：変更時の費用、承認、納期調整の手順を確認します。 - **発注者側の工数を考慮しない**：承認、資料提供、受入テストに必要な担当者を確保します。 商談では、すべての要望に即答する会社より、条件を確認してから責任ある回答をする会社のほうが適切な場合があります。分からない点を曖昧にせず、調査方法と判断時期を示せるかを評価してください。 ## まとめ - 開発会社との商談では、価格だけでなく課題理解、見積もり前提、体制、品質、契約、保守を確認します。 - 候補3〜5社へ同じ資料と質問を提示し、条件をそろえて比較することが基本です。 - 質問は「できますか」ではなく、「どのように進めるか」「根拠は何か」という形式にします。 - 実績は件数や顧客名だけでなく、担当範囲と今回の案件との共通点を確認します。 - 見積もりは総額ではなく、作業内訳、除外項目、外部費用、保守費を比較します。 - 契約前に実際のPM候補者や主要担当者と面談し、報告方法と責任体制を確認します。 - ソースコード、設計資料、アカウント、データの管理・移管条件まで確認します。 - 要件が不明確な場合は、本開発前に有料の要件整理や技術調査を切り出す方法があります。 ## よくある質問 ### 初回商談は何社程度に依頼すべきですか？ 一般的には3〜5社が目安です。候補が多すぎると質問や評価の条件をそろえにくくなるため、実績や対応領域で事前に絞り込んでから商談を依頼します。 ### 技術知識がなくても開発会社を見極められますか？ 技術の正解を判断できなくても、説明の分かりやすさ、前提条件、選択肢、リスク、費用への影響が具体的かを確認すれば比較できます。専門用語を質問したときに、事業への影響へ置き換えて説明できる会社かも重要です。 ### 初回商談で予算を伝えてもよいですか？ 予算は可能であれば幅を持たせて伝えることをおすすめします。予算内で何を優先し、何を後回しにするかという提案力を確認できるためです。予算の上限だけでなく、その金額を設定した背景も共有します。 ### 会社によって見積金額が大きく違う場合はどうすればよいですか？ 機能範囲、品質条件、担当体制、外部サービス費、データ移行、保守、変更対応が同じ前提かを確認します。差額の理由を各社へ質問し、総額だけでなく見積もりに含まれる作業と除外項目をそろえて比較してください。