相見積もりを取るために、開発会社1社目との初回打ち合わせの日程が決まった。何を話せばいいのか、どんな資料を持っていけばいいのか、そもそも自分の説明で通じるのか——。システム開発を外注した経験がほとんどない情シス・総務兼任の担当者にとって、初回打ち合わせは緊張する場面です。相手は開発のプロで、こちらは業務のプロ。知識の非対称性がある中で、聞くべきことを聞けずに終わってしまうと、その後の見積もり比較も的外れになりかねません。
結論から言うと、初回打ち合わせの目的は「契約するかどうかを決める場」ではなく「この会社と話を進めてよいかを見極めるための情報を集める場」です。聞くべき質問はあらかじめ決まっており、その場で思いつきで質問するよりも、事前にリスト化して持参する方が圧倒的に効果的です。この記事では、初回打ち合わせで聞くべき質問を「進め方」「体制」「契約・お金」「保守・その後」の4つの観点に整理し、それぞれの質問の意図と、回答から何を読み取るべきかまで具体的に解説します。
なお本メディアはシステム開発会社である株式会社ゼットリンカー自身が運営しています。この記事は特定の開発会社を想定したものではなく、業界一般で通用する質問リストとして中立的にまとめています。運営方針の詳細は運営者情報をご確認ください。
この記事で分かること
初回打ち合わせを控えた担当者が抱きがちな疑問に、順番に答えていきます。
- 初回打ち合わせで何を目的にすればよいか
- 聞くべき質問を4つの観点に分けたチェックリスト
- 質問への回答から何を読み取ればよいか
- 逆に聞かれたときに困らない準備
- 打ち合わせ後にやるべきこと
初回打ち合わせは「口頭の要望」を伝える場ではない
初めて開発会社と打ち合わせをする担当者の多くが、「自社がやりたいこと」を一生懸命説明することに時間を使い、終わってみると「相手のことは何も分からなかった」という状態になりがちです。これは打ち合わせの目的を取り違えていることが原因です。
初回打ち合わせの本来の目的は、次の2つです。
- 自社の要望が、その会社に正しく伝わったかを確認すること
- その会社が信頼できる相手かどうかを見極める材料を集めること
1つ目については、要件のまとめ方: 開発会社に伝わる資料の作り方で紹介されているような資料を事前に用意し、打ち合わせの場で読み上げながら補足する形にすると、伝達の精度が上がります。この記事で扱うのは主に2つ目、つまり「相手を見極めるための質問」です。
質問リストを事前に用意しておくメリットは、単に聞き漏らしを防げるだけではありません。複数社と打ち合わせをする場合、同じ質問を全社にぶつけることで、回答の質を横並びで比較できるようになります。相見積もりの比較は金額だけでなく、この「回答の質」の比較でもあります。
相見積もりそのものの取り方については、相見積もりの取り方と比較の観点で依頼社数の目安や金額以外の比較の観点を解説しています。
質問リストの全体像
まずは4つの観点と、それぞれに含まれる質問の全体像を一覧にします。次の章から、それぞれを具体的に解説していきます。
| 観点 | 主な質問 |
|---|---|
| 進め方 | 開発体制、開発手法、コミュニケーション方法、スケジュールの立て方 |
| 体制 | 担当者の実務経験、下請け構造の有無、類似案件の実績 |
| 契約・お金 | 契約形態、見積もりの前提、追加費用の発生条件、支払い条件 |
| 保守・その後 | 納品後のサポート範囲、著作権・データの帰属、乗り換えのしやすさ |
すべての質問を一度に聞く必要はありません。打ち合わせの時間は限られているため、自社にとって特に不安が大きい観点から優先的に聞くのが現実的です。
観点1: 進め方について聞くべきこと
どんな体制・手法で開発を進めるのか
「誰が」「どんな手順で」開発を進めるのかは、最初に確認すべき事項です。特に確認したいのは以下の点です。
- プロジェクトマネージャー・実装担当者・デザイナーなど、体制の役割分担
- 要件定義から納品までの大まかな工程と、それぞれにかかる期間の目安
- 進捗確認の頻度(週次ミーティングなのか、都度チャットで報告なのか)
- 使用するコミュニケーションツール(メール、Slack、チャットワーク等)
体制の説明が「詳しくはお任せください」で終わってしまう会社よりも、役割と工程を具体的に説明できる会社の方が、実際の開発フェーズでも透明性の高い進行が期待できます。
スケジュールはどう決まるのか
希望する納期を伝えたときに、その根拠を説明できるかどうかも重要な確認ポイントです。
「その納期であれば問題ありません」とだけ即答する会社よりも、「要件定義に2週間、設計に3週間、実装に6週間、テストに2週間かかるため、合計で約3ヶ月です」というように、工程ごとの内訳を示せる会社の方が、後から「間に合わない」という事態になりにくい傾向があります。
スケジュールの内訳を尋ねたときに、開発会社側が即座に、かつ具体的に答えられるかどうかは、その後のプロジェクト管理能力を占う材料になります。
観点2: 体制について聞くべきこと
実際に開発を担当するのは誰か
打ち合わせに同席している営業担当者と、実際にコードを書く実装担当者が別人であることは珍しくありません。むしろ多くの会社で当然の分業です。問題になるのは、実装担当者の経験やスキルセットが打ち合わせの場でまったく共有されないケースです。
以下のような質問で、実装体制の透明性を確認してください。
- 「実際にこの案件を担当するのは、営業の方ですか、それとも別のエンジニアの方ですか」
- 「担当予定のエンジニアと、契約前に一度お話しする機会をいただけますか」
- 「似た規模・業種の案件を、直近でどれくらい担当していますか」
契約前にエンジニアと直接話す機会を依頼して、快く応じてくれるかどうかも、会社の透明性を測る材料になります。
下請け構造はあるか
打ち合わせに来た担当者の名刺の会社名と、実際に契約主体となる会社名が異なるケースがあります。これは元請けが受注し、実際の開発は協力会社に再委託される構造が背景にあることが多く、この構造があること自体が直ちに問題というわけではありません。
ただし、この構造を隠さず開示してくれるかどうかは重要です。率直に「実際に開発を担当するのは御社のみですか、それとも協力会社が入りますか」と聞いてみてください。下請け構造がある場合、障害発生時にどちらへ連絡すればよいか、契約が変更された場合に担当がどう変わるかまで、あわせて確認しておくと安心です。
観点3: 契約・お金について聞くべきこと
どんな契約形態になるのか
システム開発の契約形態には、大きく分けて請負契約と準委任契約の2種類があります。請負契約は成果物の完成と引き換えに報酬が支払われる契約で、契約不適合責任(納品後に不具合が見つかった場合の責任)が生じます。一方、準委任契約は業務の遂行そのものに対して報酬が支払われる契約で、成果物の完成は契約上の直接の義務にはなりません。
契約形態は工程によって使い分けられることも多く、例えば要件定義フェーズは準委任契約、実装フェーズは請負契約というように分かれるケースもあります。打ち合わせの場では、以下を確認してください。
- 各工程が請負契約と準委任契約のどちらになるか
- 契約形態が工程ごとに変わる場合、その理由と切り替えのタイミング
- 検収(成果物を確認して受け取る手続き)の基準がどう定義されるか
契約形態そのものの違いについては、請負契約と準委任契約の違い:システム開発の契約形態はどちらを選ぶべきかで詳しく解説しています。
見積もりの前提条件は何か
見積もりを依頼する際、多くの担当者が金額の総額にばかり注目してしまいますが、同じくらい重要なのが「その金額がどこまでの作業を含んでいるか」という前提条件です。
- 見積もりに含まれる工程・機能の範囲(逆に、含まれていない範囲)
- 想定している開発期間と、その期間が延びた場合の追加費用の有無
- 仕様変更が発生した場合の見積もり修正のルール
- テスト工程(単体テスト・結合テスト・受け入れテスト)がどこまで含まれるか
これらの前提条件を明確に説明せず、「詳細は契約後に詰めましょう」と流そうとする会社には注意が必要です。見積書そのものの読み方については、システム開発の見積書、この内訳の見方で損を防ぐで工数・単価・バッファの構造を詳しく解説しています。
追加費用はどんなときに発生するか
追加費用に関するトラブルは、開発外注で最も多いトラブルの1つです。契約前に、追加費用が発生する条件を具体的に聞いておくことで、後々のトラブルを大きく減らせます。
- 「当初の要望になかった機能を追加したい場合、どんな手続きで見積もりが発生しますか」
- 「軽微な修正(ボタンの文言変更など)も追加費用の対象になりますか」
- 「開発途中で要件を変更した場合、スケジュールと金額にどう影響しますか」
これらの質問に対して、明確な基準(例えば「工数がN人日を超える変更は追加見積もり」といった線引き)を答えられる会社は、追加費用に関する運用が整備されている可能性が高いといえます。
支払い条件はどうなっているか
支払いのタイミングと割合も、契約前に必ず確認すべき事項です。
- 着手金の有無と割合
- 中間金・検収後の残金の支払いタイミング
- 検収完了前に全額の支払いを求められることがないか
- 途中で契約を解除する場合の精算方法
着手金として契約金額のほとんどを前払いで求められる、あるいは返金・減額に関する条項が契約書に一切ないといった条件が見られた場合は、内容を慎重に精査してください。前払い自体が直ちに不当というわけではなく、特に小規模な開発会社にとっては開発リソースを確保する意味合いもあります。問題視すべきは、成果物が完成しない場合でも、発注側が支払った金額を取り戻す手段が契約書上まったく用意されていないケースです。
観点4: 保守・その後について聞くべきこと
納品後のサポート範囲はどこまでか
「作って終わり」ではなく、納品後にどんなサポートが受けられるのかは、意外と後回しにされがちな確認事項です。
以下の項目は、契約前に必ず聞いておくべきです。
- 検収後、一定期間は無償で不具合対応してもらえる条項があるか
- 保守契約は開発契約に含まれるのか、別契約(月額の保守契約)になるのか
- 障害発生時の対応時間や、対応までの目安期間(SLA（サービス品質保証）に近い取り決めがあるか)
- 軽微な仕様変更が保守費用の範囲内で対応してもらえるのか、都度見積もりになるのか
これらが口頭の説明だけで済まされ、契約書や見積もりに明記されない場合、納品後に「聞いていた話と違う」というトラブルに発展しやすくなります。
著作権・データの帰属はどうなるか
「納品したシステムのソースコードの著作権は、契約後どちらに帰属しますか」という質問は、初回打ち合わせの段階でぜひ聞いておきたい質問です。著作権法上、契約書に譲渡条項がなければ、成果物の著作権は制作者である開発会社側に残るのが原則です。発注側が「お金を払ったのだから当然自社のもの」と思い込んでいても、契約書に明記がなければソースコードの改変や他社への引き継ぎに、開発会社側の許諾が必要になる場合があります。
この質問に対して、明確に答えなかったり話をそらしたりする会社には注意が必要です。ベンダーロックインは、契約時点でこの確認を怠ったことが遠因になっているケースが多く見られます。
将来、他社に乗り換えることは可能か
「もし将来、御社以外の開発会社に改修を依頼することになった場合、必要なデータや資料は提供していただけますか」という質問も、初回打ち合わせで聞いておくと安心です。
健全な会社であれば、この質問に対して不快感を示すことはなく、「もちろん可能です。ソースコード一式と仕様書をお渡しします」というように具体的に答えてくれます。逆に、この質問に対して露骨に嫌な顔をされたり、曖昧な回答に終始したりする場合は、将来的なマルチベンダー体制への移行が難しい関係になる可能性を考慮しておく必要があります。
質問リストのまとめ(印刷・持参用)
ここまでの質問を、打ち合わせにそのまま持参できる形でまとめます。
進め方
- 開発体制(役割分担)を教えてください
- 要件定義から納品までの工程と、それぞれの期間の目安を教えてください
- 進捗確認の頻度と方法を教えてください
体制
- 実際に開発を担当するのはどなたですか
- 担当予定のエンジニアと契約前にお話しする機会はいただけますか
- 類似の規模・業種の案件の実績を教えてください
- 下請け・協力会社が入る場合、その体制を教えてください
契約・お金
- 各工程の契約形態(請負・準委任)を教えてください
- 見積もりに含まれる範囲、含まれない範囲を教えてください
- 仕様変更・追加費用が発生する条件を教えてください
- 着手金・中間金・残金の支払いタイミングを教えてください
保守・その後
- 検収後、無償で不具合対応してもらえる期間はありますか
- 保守契約は別契約になりますか。その場合の費用感を教えてください
- 障害発生時の対応時間の目安を教えてください
- ソースコードの著作権の帰属を教えてください
- 将来他社に乗り換える場合、必要な資料は提供してもらえますか
すべてを1回の打ち合わせで聞き切る必要はありません。時間が足りない場合は、事前にリストを送付し「打ち合わせまでに回答をご準備いただけますか」と依頼するのも有効な方法です。
回答から何を読み取るべきか
質問リストを用意しても、回答をどう評価すればよいか分からなければ意味がありません。ここでは、回答の質を見極める視点を整理します。
具体性のある回答と、具体性のない回答の違いを意識してください。
「大丈夫です、お任せください」という回答は、一見すると安心感を与えるように聞こえますが、実務能力のある担当者であれば、多少専門的な質問であっても可能な範囲で具体的に答えようとします。逆に、実務経験が浅い、あるいは実際の開発体制が整っていない会社ほど、質問をはぐらかして安心感だけを演出する傾向があります。
回答の質を評価する際のポイントを整理します。
- 数字(工数・期間・金額)を交えて具体的に答えているか
- 質問の意図を正しく理解した上で答えているか、それとも用意された定型の説明を繰り返しているだけか
- 答えにくい質問(トラブル事例、著作権の帰属など)にも、はぐらかさず向き合っているか
- 「持ち帰って確認します」と回答した場合、後日きちんとフォローアップがあるか
打ち合わせ直後は、記憶が鮮明なうちに回答内容をメモに残しておくことを強くおすすめします。複数社と打ち合わせを重ねると、どの会社が何と答えたのか混同しやすくなるためです。
逆に聞かれたときに困らない準備
初回打ち合わせは一方的に質問する場ではなく、開発会社側からも当然質問が返ってきます。よく聞かれる質問への準備をしておくと、打ち合わせがスムーズに進みます。
- 「予算感はどれくらいをお考えですか」への回答(明確な数字がなくても、上限の目安だけでも伝えられるようにしておく)
- 「なぜこのタイミングでシステム化を検討されているのですか」への背景説明
- 「現状、業務はどう回っていますか(Excel運用か、紙運用か等)」への回答
- 「いつまでに稼働させたいですか」への希望納期
予算感を聞かれたときに「言えません」と答えてしまうと、開発会社側も精度の高い見積もりを出しにくくなります。厳密な金額でなくても、「◯◯万円〜◯◯万円程度で考えている」という幅を示せるように準備しておくと、その後のやり取りが建設的になります。
要望を整理した資料があれば、打ち合わせの冒頭で共有すると、開発会社側の理解も早まります。資料の作り方については要件のまとめ方: 開発会社に伝わる資料の作り方を参考にしてください。
オンライン打ち合わせで特に意識すべきこと
近年は初回打ち合わせから契約までをオンライン会議で完結させるケースが一般化しています。対面と比べて候補社を比較しやすい利点がある一方、意識しておきたい点もあります。
- 画面共有される資料が毎回同じテンプレートで、こちらの質問に応じて内容が更新されないままになっていないか
- 議事録やチャットログを、こちらから提案しないと残そうとしないか(口頭の合意だけで進めようとする会社は要注意です)
- 同席する人数が毎回異なり、誰が最終的な意思決定者なのか分からない状態になっていないか
打ち合わせの内容は、可能な限りその場で、あるいは直後にチャットやメールで文書化し、双方の認識が一致しているかを確認する習慣をつけることをおすすめします。「言った・言わない」のトラブルは、対面よりもオンラインの方が起こりやすい傾向があります。
案件の性質によって重視すべき質問は変わる
すべての案件で同じ質問の重み付けが正しいわけではありません。案件の性質に応じて、特に重視すべき観点は変わってきます。
既存の基幹システムを刷新する案件: データ移行の手順や検証方法について、具体的に説明できるかを重点的に確認してください。データ移行は失敗すると業務そのものが止まりかねない工程です。
新規にゼロから作る案件(フルスクラッチ開発開発など): 要件定義のプロセスがどれだけ丁寧に設計されているかを重視してください。ゼロから作る案件ほど、初期の要件のすり合わせが甘いと、後工程での手戻りが大きくなります。
まず小さく試したい案件: いきなり本開発を発注するのではなく、PoC（概念実証）やMVP（実用最小限の製品）から始められるかを確認するとよいでしょう。小さく発注して試す考え方については、小さく発注して試す: PoC発注のすすめで解説しています。
既存システムとの連携を伴う案件: 連携先システムの制約(APIの有無、バージョン依存等)をどこまで事前調査してくれるかを重視してください。連携部分は想定外の作業が発生しやすく、見積もり時点での調査の丁寧さが、その後のトラブルの少なさに直結します。
初回打ち合わせでよくある失敗パターン
質問リストを用意していても、実際の打ち合わせの場では思うように聞けないことがあります。ここでは、初めて開発会社と打ち合わせをする担当者が陥りやすい失敗パターンを紹介します。
要望を話すことに時間を使い切ってしまう: 自社の要望を丁寧に説明しようとするあまり、打ち合わせの大半の時間を「話す側」として過ごしてしまい、相手への質問をする時間が残らないまま終わってしまうケースです。事前に要望資料を用意し、口頭説明を最小限にとどめることで、質問の時間を確保できます。
専門用語に気後れして聞き返せない: 開発会社側の担当者が専門用語を交えて説明したときに、理解できないまま相槌を打ち続けてしまうケースです。分からない言葉が出てきたら、その場で「恐れ入りますが、それはどういう意味でしょうか」と聞き返して構いません。むしろ、分からないことをその場で確認せず後から誤解が発覚する方が、双方にとって手戻りが大きくなります。
担当者の人柄の良さだけで判断してしまう: 打ち合わせに来た担当者が話しやすく、感じが良かったという印象だけで、質問リストの回答内容を十分に検証しないまま好印象を持ってしまうケースです。人柄と実務能力は別の軸であり、この記事で紹介した質問への回答内容を、印象とは切り離して評価することが重要です。
1社目の説明を鵜呑みにしてしまう: 初めて話を聞いた開発会社の説明を「業界の常識」だと思い込み、2社目・3社目との比較をせずに話を進めてしまうケースです。契約形態や見積もりの前提条件の説明は、会社によって重視するポイントが異なります。最低でも2〜3社と打ち合わせをした上で、回答の傾向を比較することをおすすめします。
これらの失敗パターンに共通するのは、いずれも「準備不足」または「その場の空気に流されてしまう」ことが原因になっている点です。質問リストを紙やタブレットで手元に置き、1つずつチェックしながら進める姿勢が、こうした失敗を防ぐ最も確実な方法です。
打ち合わせ後にやるべきこと
初回打ち合わせが終わったら、その日のうちに次の3つを行うことをおすすめします。
- 質問への回答内容を、忘れないうちにメモとして書き出す
- 「持ち帰り」となった質問があれば、いつまでに回答をもらえるか期限を確認しておく
- 複数社と打ち合わせをしている場合、比較用の一覧表に回答を転記する
比較用の一覧表を作っておくと、最終的な意思決定の場面で「どの会社が何と答えたか」を一目で振り返ることができます。金額だけでなく、この記事で紹介した質問への回答の質も、あわせて一覧化しておくと判断材料としての価値が高まります。
複数社の見積もりや回答をどう比較するかについては、相見積もりの取り方と比較の観点で、金額以外の比較の観点を詳しく解説しています。
まとめ: 質問リストを「使い切る」ことが最大の防御
初回打ち合わせで聞くべきことを改めて整理します。
- 初回打ち合わせの目的は契約の決定ではなく、相手を見極める情報収集にある
- 「進め方」「体制」「契約・お金」「保守・その後」の4観点で質問を用意する
- 回答の具体性(数字や事例を交えているか)を意識して評価する
- 予算感や現状業務など、逆に聞かれる質問への準備もしておく
- 打ち合わせ後はその日のうちに回答内容をメモし、複数社の比較に備える
質問リストは作って満足するものではなく、実際に打ち合わせの場で使い切ることで初めて価値を発揮します。緊張する場面ではありますが、リストを手元に置きながら、1つずつ確認していく姿勢が、その後の発注の成否を大きく左右します。
次に読む記事としては、初回打ち合わせで気になる違和感の正体を具体的に整理した危険な開発会社のサイン10選、そして打ち合わせ前に用意しておきたい要望資料の作り方を解説した要件のまとめ方: 開発会社に伝わる資料の作り方をおすすめします。
