開発会社との初回打ち合わせは、その後の開発全体の方向性を決める、重要な機会です。しかし、初めての発注では、何を聞けばいいのか分からず、開発会社側の説明を一方的に聞くだけで終わってしまうこともあります。この記事では、初回打ち合わせで必ず聞くべきことを解説します。
この記事で分かること
初回打ち合わせは、開発会社からの提案を聞くだけの場ではなく、自分から積極的に質問し、開発会社の姿勢や実力を見極める場でもあります。この記事では、聞くべき質問を3つに整理して紹介するとともに、それぞれの質問をどう深掘りすればよいか、良い回答と危険な回答の見分け方、初回打ち合わせ後に振り返るためのチェックリストまで、実践的にまとめます。
結論を先に示すと、必ず聞くべきことは次の3つです。
- 進め方とスケジュールの見通し
- コミュニケーションの方法と頻度
- 想定されるリスクや懸念点
初めて発注する立場からすると、「開発会社の提案を聞いて、良さそうだと思ったらお願いする」という進め方になりがちです。しかし、提案の内容そのものよりも、質問への「答え方」に、その開発会社の実力や誠実さが表れることが少なくありません。以下、質問ごとに、聞くべき理由と、深掘りの仕方を具体的に見ていきます。なお、質問する側にも準備が必要で、ヒアリングでつまずかないための実践的なコツも、初回打ち合わせに臨む前の参考になる。
質問1：進め方とスケジュールの見通し
「この開発は、どのような順番で進みますか。それぞれの工程に、どれくらいの期間がかかりますか」という質問は、初回打ち合わせで必ず確認しておきたい内容です。開発の進め方（要件定義→設計→実装→テスト、といった工程）と、それぞれの期間の見通しを聞くことで、全体のスケジュール感を把握できます。
この質問への回答が具体的であればあるほど、その開発会社が、進め方について明確なイメージを持っていることが分かります。逆に、「進めながら決めていきましょう」というような、曖昧な回答しか得られない場合、進め方について、より詳しく確認することをおすすめします。
深掘りの仕方：工程ごとの「完了の定義」を聞く
進め方を聞いたら、それだけで終わらせず、「それぞれの工程は、どうなったら完了と言えますか」まで踏み込んで確認することをおすすめします。たとえば要件定義の完了が「要件定義書に発注者が承認印を押した時点」なのか、「口頭で合意した時点」なのかによって、後々の認識のズレの起きやすさが大きく変わります。
工程の切れ目が曖昧なまま進むと、「まだ設計段階だと思っていたのに、もう実装が始まっている」「テストの期間がいつの間にか短くなっている」といった行き違いが起きやすくなります。初回打ち合わせで、工程ごとの完了条件をひとつずつ確認しておくと、後になってからの「言った・言わない」を減らせます。
良い回答の例と、注意したい回答の例
良い回答の例としては、「まず2週間程度で要件定義を行い、要件定義書をお渡しして確認いただいた上で、設計に進みます。設計には3〜4週間、実装には規模に応じて2〜3ヶ月、テストには2〜3週間を想定しています」というように、工程ごとの期間の目安と、次の工程に進む条件（承認をもらう、など）がセットで語られるものが挙げられます。
一方で、注意したい回答の例としては、「だいたい3ヶ月くらいでできると思います」というように、総期間だけが語られ、工程の切れ目や、その間に発注者側が何を確認・承認する必要があるのかが説明されないものが挙げられます。総期間だけの回答では、開発が進んでいる間、発注者側は「今どの工程にいて、いつ何を確認すればいいのか」が分からないまま、進捗を見守るだけになってしまいがちです。
スケジュールの前提条件も確認しておく
見通しを聞く際は、「そのスケジュールは、どのような前提のもとに成り立っていますか」も、あわせて確認しておくとよいでしょう。多くの開発会社が提示するスケジュールには、「発注者側からの確認・回答が、依頼から何日以内に得られること」「要件定義の内容が、途中で大きく変わらないこと」といった前提が置かれています。
この前提を事前に共有してもらっておくことで、自分自身がスケジュールを守るために、何をいつまでにすべきかが明確になります。逆に、この前提が示されないまま進んでしまうと、発注者側の確認が遅れたことが原因でスケジュールが延びた場合にも、「開発会社の見通しが甘かったのではないか」という不要な不信感につながりやすくなります。
質問2：コミュニケーションの方法と頻度
「開発中、どのくらいの頻度で進捗を報告してもらえますか。連絡方法は何を使いますか」という質問も、重要な確認ポイントです。開発が始まった後、進捗が全く分からない状態が続くと、不安を感じやすくなります。
定期的な報告の頻度（週1回のミーティング、隔週での報告など）や、連絡手段（メール、チャットツールなど）について、事前に確認しておくことで、開発が始まった後の不安を減らせます。
「誰が」「どのタイミングで」報告するかまで確認する
頻度と手段に加えて、「誰が報告してくれるのか」「その担当者は、打ち合わせに出ている人と同じか」も確認しておくと安心です。開発会社によっては、営業担当が初回打ち合わせに出て、実際の開発が始まると別のディレクターやエンジニアが窓口になるケースもあります。窓口が変わる可能性がある場合は、いつ、どのように引き継ぎが行われるのかも聞いておくと、開発中に「誰に連絡すればいいのか分からない」という状態を避けられます。
また、「進捗が遅れそうなとき、それが分かった時点で連絡してもらえるか、それとも定例の報告のタイミングまで待たされるか」も、実務上は重要な確認ポイントです。遅れが発生してから発注者に伝わるまでの時間が短い開発会社ほど、対応の誠実さが高いと考えてよいでしょう。
コミュニケーションコストと開発コストのバランスも意識する
なお、報告や打ち合わせの頻度を増やせば安心感は高まりますが、その分、開発会社側の対応にも工数がかかり、結果として費用や期間に影響することもあります。「できるだけ細かく報告してほしい」という要望自体は自然なものですが、その要望が費用や期間にどう影響するのかも、あわせて確認しておくと、後になって「思っていたよりコミュニケーションコストがかかっている」という感覚のズレを避けられます。
質問例のバリエーション
状況に応じて、以下のような聞き方も有効です。
- 「進捗報告は、口頭だけでなく、文書やチャットのログとして残りますか」
- 「緊急の連絡が必要になった場合、通常の連絡方法とは別の手段はありますか」
- 「打ち合わせの議事録は、どちらが作成しますか」
これらは些細に思えるかもしれませんが、開発が長期化した際に、後から経緯を振り返る手がかりになります。特に議事録の作成者を決めておくことは、双方の認識のズレを未然に防ぐ、地味ながら効果の大きい工夫です。
質問3：想定されるリスクや懸念点
「この開発を進める上で、何かリスクや懸念点はありますか」という質問は、開発会社の誠実さを見極める上で、特に重要な質問です。誠実な開発会社であれば、この質問に対して、具体的なリスクや懸念点を答えてくれるはずです。
「特に心配なことはありません」という回答しか得られない場合、リスクについて深く検討していない可能性があるため、注意が必要です。開発にはさまざまな不確実性が伴うため、リスクが全くないという回答は、むしろ不自然だと考えることをおすすめします。
どのようなリスクが挙げられるのが自然か
具体的には、以下のようなリスクへの言及があると、その開発会社が要望をしっかり理解した上で検討していると考えやすくなります。
- 要件が固まっていない部分について、「開発を進める中で仕様が変わる可能性があり、その場合はスケジュールや費用に影響が出る」という言及
- 外部サービスとの連携がある場合、「連携先のAPIの仕様変更や制限によって、想定通りに動かない可能性がある」という言及
- 専門分野の業務ロジックがある場合、「業界特有のルールの理解に、想定より時間がかかる可能性がある」という言及
- 人員体制について、「担当エンジニアの並行案件の状況によって、対応スピードが変動する可能性がある」という言及
これらは、いずれも「言われてみれば当然」の内容ですが、事前に言葉にしてもらうことで、後になって同じ問題が起きたときに、「想定されていたリスクが実際に起きた」という受け止め方ができます。逆に、何も言われていない状態で問題が起きると、「見通しが甘かったのではないか」という不信感につながりやすくなります。
リスクを聞いた後、さらに確認したいこと
リスクを聞けたら、そこで終わらせず、「そのリスクが実際に起きた場合、どのように対応してもらえますか」まで確認しておくと、より安心です。リスクの存在を認識していることと、リスクが起きたときに実際に対応できることは、必ずしも同じではありません。対応方針まで具体的に語れる開発会社であれば、リスク管理の面でも、より信頼できると考えられます。
その他、状況に応じて聞いておきたいこと
担当者の変更の可能性について
長期間の開発になる場合、担当者が途中で変わる可能性があるかどうかも、確認しておくとよいでしょう。担当者が変わる場合、それまでの経緯や意図がうまく引き継がれるかどうかも、あわせて確認しておくことをおすすめします。
具体的には、「引き継ぎの際、どのような資料やドキュメントが用いられますか」「引き継ぎ後、しばらくは前の担当者にも確認できる体制がありますか」といった質問も有効です。担当者の変更自体は避けられない場合もありますが、引き継ぎの質は、開発会社の体制次第で大きく変わります。
開発中に要望が変わった場合の対応について
開発を進める中で、当初の要望が変わることは、決して珍しいことではありません。「開発中に要望が変わった場合、どのように対応してもらえますか」という質問をしておくことで、変化への対応の柔軟さを事前に把握できます。
この質問への回答としては、「変更の規模に応じて、軽微なものはその場で調整し、大きな変更は見積もりを取り直します」というように、変更の大小によって対応が変わることを説明してもらえると、実務上イメージしやすくなります。反対に、「基本的に変更はできません」という回答しか得られない場合、開発途中で状況が変わった際に、身動きが取りづらくなる可能性があるため、注意が必要です。
保守・運用フェーズについて
初回打ち合わせの段階では、開発完了後のことまで話が及ばないことも多いですが、可能であれば「開発が完了した後、不具合が発生した場合の対応や、保守契約の有無」についても、簡単に触れておくとよいでしょう。開発フェーズと保守フェーズを別契約とする開発会社も多いため、開発完了後にどのような選択肢があるのかを、早い段階で把握しておくことは、後々の判断に役立ちます。
質問しても、うまく答えてもらえない場合
質問をしても、曖昧な回答しか得られない、あるいは質問自体をはぐらかされる場合は、その開発会社との相性や、対応の誠実さについて、慎重に見極める必要があります。危険な開発会社のサインについては、別記事で詳しく解説しています。
一度の打ち合わせで判断がつかない場合は、「先ほどの質問について、もう少し具体的に伺えますか」と、その場で重ねて聞いてみることも有効です。重ねて聞いた際に、話がより具体的になるのか、それとも同じように曖昧なままなのかで、その開発会社の実力や準備の度合いが見えてくることがあります。
初回打ち合わせで、聞かれる側になることも想定しておく
初回打ち合わせでは、自分から質問するだけでなく、開発会社側からも、要望の背景や目的について、さまざまな質問を受けることが一般的です。事前に、自分のアイデアや要望を整理しておくことで、こうした質問にもスムーズに答えられます。アイデアメモの作り方については、別記事で詳しく解説しています。
聞かれる側になったときによく出てくる質問としては、「このサービスを使うのは、どのような人ですか」「なぜ今、このサービスを作りたいと思ったのですか」「予算や期限について、決まっている範囲はありますか」といったものが挙げられます。これらに即答できなくても問題はありませんが、事前に一度でも考えを整理しておくと、打ち合わせの時間をより有意義に使えます。
専門知識を活かしたツールの場合、追加で聞いておきたいこと
専門分野の業務ロジックを含むツールの場合、「この分野の開発経験はありますか。どのように専門知識を補いながら進めますか」という質問を追加しておくことをおすすめします。専門性の理解に不安がある場合、開発会社がどのように学習・確認しながら進めるかを、事前に把握しておくことが重要です。
具体的には、「過去に同じ分野のツールを開発した実績はありますか」「その分野に詳しい担当者が社内にいますか、それとも都度調べながら進めますか」「専門的な判断が必要な場面では、発注者側に確認を取ってもらえますか」といった質問が考えられます。専門分野の知識がゼロの状態から開発が始まる場合でも、キャッチアップの仕方が明確であれば、大きな問題にはなりにくいものです。逆に、「大体分かります」というような曖昧な回答しか得られない場合は、業務ロジックの部分で、後から手戻りが発生するリスクが高くなることを念頭に置いておくとよいでしょう。
初回打ち合わせ後に振り返りたい、チェックリスト
打ち合わせが終わった後、記憶が新しいうちに、以下の項目を振り返っておくことをおすすめします。当日中、あるいは翌日までに振り返ることで、次の打ち合わせや、他の開発会社との比較の際にも役立ちます。
- 進め方の工程ごとに、期間の目安と完了条件が説明されたか
- スケジュールの前提条件（発注者側の確認スピードなど）が共有されたか
- 進捗報告の頻度・手段・担当者が明確だったか
- 遅れが発生した場合の連絡タイミングについて、触れられたか
- リスクや懸念点について、具体的な内容が挙げられたか
- リスクが実際に起きた場合の対応方針まで語られたか
- 担当者変更の可能性と、引き継ぎの仕組みについて確認できたか
- 要望が変わった場合の対応方針について確認できたか
- 保守・運用フェーズの選択肢について、簡単にでも触れられたか
- 質問に対して、曖昧な回答やはぐらかしが目立たなかったか
このチェックリストのうち、多くの項目に具体的な回答が得られていれば、その開発会社は、進め方について明確なイメージを持っていると考えられます。反対に、複数の項目で曖昧な回答が続く場合は、他の開発会社との比較検討も含めて、慎重に判断することをおすすめします。
実際によくある失敗パターンから学ぶ
ここまで紹介した3つの質問が、なぜそれほど重要なのかを、実際によくある失敗パターンに沿って見てみます。いずれも、初回打ち合わせの時点で質問しておけば防げた、あるいは早い段階で気づけた可能性がある事例です。
失敗パターン1：スケジュールの前提を確認しなかったケース
「3ヶ月でできます」という説明を受け、そのまま契約に進んだところ、実際には5ヶ月かかってしまった、というケースはよく耳にします。後から振り返ると、その3ヶ月という見通しには「発注者側からの確認・回答が、依頼から2営業日以内に得られること」という前提が置かれていました。しかし、この前提は初回打ち合わせでは共有されず、発注者側は普段の業務の合間に確認作業を行っていたため、実際には1回の確認に1週間近くかかることが常態化していました。
このケースでは、「そのスケジュールは、どのような前提のもとに成り立っていますか」という質問を初回にしておけば、発注者側も「自分がどれくらいのスピードで対応すべきか」を事前に把握でき、確認のための時間を業務スケジュールにあらかじめ組み込むことができたはずです。前提条件を知らないまま進めてしまうと、遅れの原因が発注者側にあったとしても、それに気づかないまま「開発会社が遅い」という印象だけが残ってしまいます。
失敗パターン2：報告の「担当者」を確認しなかったケース
初回打ち合わせに出席したのは、経験豊富なベテランの営業担当者でした。安心して契約を進めたところ、実際の開発が始まると、進捗報告は別の若手ディレクターが担当することになり、しかも初回打ち合わせでの合意事項がうまく引き継がれていなかった、というケースもあります。
このケースでは、「担当者は変わりますか。変わる場合、初回打ち合わせの内容はどのように引き継がれますか」という質問を、初回の段階でしておくことで、引き継ぎの有無や質を事前に確認できたはずです。担当者が変わること自体は、会社の体制上避けられない場合もありますが、引き継ぎの仕組みが整っているかどうかは、質問すれば事前に見えてくる部分です。
失敗パターン3：リスクについて聞かず、思わぬところで手戻りが発生したケース
外部の決済サービスと連携する機能を含む開発で、初回打ち合わせでは特にリスクについての言及がありませんでした。開発が進む中で、連携先のサービス側の仕様変更があり、想定していた実装方法が使えなくなったことが分かり、大きな手戻りが発生しました。
このケースの場合、外部サービスとの連携があることは、初回打ち合わせの時点で分かっていた情報です。「外部サービスとの連携部分に、どのようなリスクがありますか」と質問していれば、開発会社側から「連携先の仕様変更の可能性」への言及があったかもしれません。仮に言及がなかったとしても、後から「その可能性について、なぜ触れてもらえなかったのか」を振り返る材料にはなります。リスクについての質問は、リスクそのものをゼロにするものではありませんが、想定の有無を早い段階で確認できる、という点に価値があります。
失敗パターンから見えてくる共通点
3つの失敗パターンに共通しているのは、いずれも「聞いておけば、事前に気づけた可能性がある」という点です。開発が始まってから問題が発覚すると、原因の切り分けや対応に多くの時間がかかりますが、初回打ち合わせの段階であれば、質問して回答を聞くだけで、同じ情報にたどり着けたはずのケースがほとんどです。この記事で紹介している3つの質問は、いずれも「開発が始まる前に、無料で得られる安心材料」だと捉えると、質問することへのハードルが下がりやすくなります。
質問する側の準備として、メモを作っておく
初回打ち合わせの当日になって、いきなり質問を考えようとすると、緊張やその場の流れで、聞きたかったことを聞き忘れてしまうことも少なくありません。この記事で紹介した質問は、事前に紙やメモアプリに書き出しておき、打ち合わせの最後に「聞き忘れがないか」を確認する時間を作っておくと、より確実に活用できます。
メモには、質問そのものだけでなく、「なぜその質問をするのか」という理由も一緒に書いておくとよいでしょう。理由を書いておくことで、開発会社からの回答が、その理由に対して十分に答えているかどうかを、その場で判断しやすくなります。たとえば「担当者の変更について聞く理由は、長期開発になりそうだから」とメモしておけば、開発会社から「担当は変わりません」という回答があった場合にも、「本当に変わらないのか、変わる場合の想定はあるのか」を、その場で重ねて確認しやすくなります。
オンラインでの初回打ち合わせで、特に意識したいこと
近年は、初回打ち合わせがオンラインの会議ツールで行われることも増えています。対面の打ち合わせと比べて、オンラインでは、相手の表情や、間の取り方が伝わりにくく、曖昧な回答をそのまま聞き流してしまいやすい、という側面があります。オンラインで打ち合わせを行う場合は、以下の点を意識しておくと、質問の効果をより高めやすくなります。
- 可能であれば、録画・録音の許可を得ておく。後から回答内容を振り返る際に役立ちます。
- 画面共有で資料を見せてもらいながら質問すると、回答があいまいになりにくい傾向があります。スケジュールの見通しなどは、口頭だけでなく、図や表を共有画面に出してもらいながら確認するとよいでしょう。
- チャット機能を使って、質問事項を事前に書き出しておき、話しながらチェックしていくと、聞き忘れを防げます。
- 打ち合わせの最後に、「本日確認した内容を、簡単にまとめて送っていただけますか」と依頼しておくと、記憶違いや聞き間違いを、後から補正できます。
オンラインでの打ち合わせは、移動の手間がなく、複数の開発会社と続けて話しやすいというメリットもあります。一方で、記録が残りにくい形式で進んでしまうと、後から「何を確認したか」が分からなくなるリスクもあるため、記録を残す工夫は特に意識しておくとよいでしょう。
初回打ち合わせは「一度きりの機会」ではないと考える
初回打ち合わせで聞き忘れたことがあったとしても、それで発注の判断ができなくなるわけではありません。多くの開発会社は、初回打ち合わせの後に、追加の質問や確認を受け付けています。「あの場で聞けばよかった」と後悔するよりも、打ち合わせが終わった後に、メールやチャットで追加の質問を送ることも、十分に有効な手段です。
むしろ、初回打ち合わせの場では時間の制約もあるため、この記事で紹介した3つの質問を優先的に確認し、その他の細かい確認事項は、打ち合わせ後にあらためて確認する、という進め方も現実的です。重要なのは、「聞くタイミング」よりも、「聞くべきことを、契約前のどこかの時点で必ず確認する」という姿勢です。
打ち合わせ後に追加で質問する際も、この記事で紹介したチェックリストを参照しながら、「まだ確認できていない項目はどれか」を洗い出しておくと、抜け漏れなく確認を進められます。特に、契約書を確認する段階になってから初めて「担当者変更時の対応」や「要望変更時の対応」が話題に出ることのないよう、契約前のどこかのタイミングで、必ず一度は言葉にして確認しておくことをおすすめします。
この記事の次に読みたい記事
初回打ち合わせで聞くべきことを理解したら、次はまだ固まっていないアイデアの伝え方についても確認しておきましょう。あわせて次の記事も参考にしてください。
