アプリ開発の最初の打ち合わせで聞くこと｜後戻りを防ぐ

アプリ開発で後戻りが起きる原因の大半は、開発中ではなく初回の打ち合わせで作られます。結論から言うと、初回で聞くべきことは金額でも技術でもなく、「何のために作るのか」と「誰が決めるのか」の二つです。この記事では、アプリ開発の初回の打ち合わせで確認すべき項目を、目的、利用者、機能範囲、技術前提、体制、スケジュール、契約の七つに分けて整理します。

初回打ち合わせのゴールは、後戻りしない条件を揃えること

初回の打ち合わせを「提案の場」だと考えていると、聞くべきことを聞かないまま話が進みます。実際には、初回のゴールは受注そのものではなく、見積もりと設計の前提を揃えることです。

初回で決まらないと、後工程がすべて揺れる

アプリ開発の工程は、要件定義、設計、実装、テスト、リリースという順で進みます。前の工程が確定していないまま次に進むと、後ろに行くほど修正の影響範囲が広がります。実装段階で画面の増減が発生すると設計とテストの両方に手を戻すことになり、リリース直前で目的の再確認が起きると、作ったものの一部が使われないまま終わります。

つまり、初回の打ち合わせは「聞き漏らしを潰す場」です。正直なところ、初回で気を遣いすぎて質問を減らす人は多いのですが、これは後で必ず自分に返ってきます。質問が多い相手のほうが信頼されるという傾向は、複数の現場で共通して見られます。

打ち合わせ前に送っておくもの

初回の時間を有効に使うには、事前に質問項目を送っておくのが効率的です。項目を先に見てもらうと、発注者側で答えを用意してくれるうえ、社内で決まっていない論点があぶり出されます。

送る内容は、目的、想定する利用者、必須の機能、対応したい端末、希望時期、体制の六つで十分です。これ以上細かい項目を最初から送ると、回答の負担が大きくて返信自体が止まります。細部は打ち合わせの中で掘ります。

進め方の全体像を共有してから質問に入る

いきなり質問を並べると、尋問のような空気になります。最初にアプリ開発の一般的な進み方を共有し、そのどの段階で何を決める必要があるかを説明してから質問に入ると、質問の意図が伝わります。

実際にアプリを開発する具体的な手順について紹介してきます。一般的なアプリ開発の手順は、大きく分けると以下の6つです。 出典: hnavi.co.jp

工程の全体像を先に見せると、「今日はこの最初の工程を固める時間です」という位置づけが共有できます。これだけで、その場で金額を求められる展開が減ります。

目的と成功の基準を聞く

最初に確認するのは、なぜアプリを作るのかです。ここが曖昧なまま進むと、機能の取捨選択の基準がなくなります。

何のために作るのかを一文にする

「アプリを作りたい」という依頼の裏には、必ず別の目的があります。既存顧客との接点を増やしたい、紙の業務をなくしたい、問い合わせ対応の負担を減らしたい、といった目的です。この目的を発注者の言葉で一文にしてもらい、議事録の先頭に書きます。

一文にできない場合、社内で目的が固まっていない可能性が高いです。その場合は、目的の整理そのものを最初の作業として提案するほうが結果的に早く進みます。

成功をどう測るかを聞く

目的とセットで確認するのが、何をもって成功と判断するかです。利用者数なのか、業務時間の削減なのか、問い合わせ件数の減少なのか。測る指標が決まると、機能の優先順位が自動的に決まります。

指標が決まっていない場合は、こちらから候補を出します。「利用者数を見るなら初回起動から継続利用までの導線が重要になります」「業務時間を見るなら入力の手間を減らす設計が優先です」といった形で、指標と設計方針を結びつけて説明すると、発注者側の判断が進みます。

そもそもアプリである必要があるかを確認する

これは聞きにくい質問ですが、初回で触れておく価値があります。目的を達成する手段として、ウェブサイトの改善や既存ツールの活用のほうが適している場合があるからです。

正直なところ、この確認をしないまま作ったアプリは使われません。使われないアプリを納品しても次の依頼にはつながらないので、初回で手段の妥当性を一度検討するのは、受注側にとっても合理的です。ここで「アプリでなくてもよいのでは」と言える相手は、結果として信頼されます。

使う人と使われ方を聞く

目的の次に聞くのは、誰がどう使うかです。ここが具体的になるほど、画面設計の判断が速くなります。

利用者の属性と規模

社内向けか社外向けか。社内なら部署と人数、社外なら想定する顧客層。年齢層や、スマートフォンの操作にどれくらい慣れているかも重要です。操作に不慣れな層が対象なら、画面の数を減らして一画面あたりの情報量を増やす設計になります。

いつ、どこで使うか

通勤中に片手で使うのか、店舗で立ったまま使うのか、デスクで腰を据えて使うのか。使われる場面が分かると、必要な画面の形が変わります。屋外での利用が多いなら通信が不安定な状況を想定した設計が要りますし、片手操作が前提なら操作要素の配置が変わります。

既存の業務と、その中でのアプリの位置づけ

とくに業務用アプリでは、現在どのような手順で作業しているかを聞くのが重要です。紙とエクセルで回している業務をアプリ化する場合、いまの手順をそのまま移すと使いにくくなることがあります。逆に、業務手順ごと変える提案は、現場の反発を招くことがあります。

初回では「いまどうやっているか」を具体的に聞き、それを議事録に残します。この情報は、後で機能を削る相談になったときに判断材料として効いてきます。

機能の範囲を聞く

機能の話は最も盛り上がる一方、最も後戻りの原因になります。範囲を確定させるより、範囲を分類することを優先します。

必須と希望を分ける

出てきた機能を、「これがないと目的を達成できないもの」と「あったほうがよいもの」に分けます。この分類はその場で発注者に判断してもらいます。こちらが勝手に分類すると、後で「あれは必須だったはず」という話になります。

分類の際に有効なのが、「これがない状態でリリースしたら、目的は達成できますか」という問いです。この聞き方をすると、必須と希望の線が自然に引けます。

画面と処理の粒度まで下ろす

「予約機能」という言葉のままにしておくと、後で内容が膨らみます。初回の時点で、予約の一覧画面、予約の入力画面、確認画面、完了画面、キャンセルの操作、通知の有無、というところまで下ろします。

すべてを初回で決めきる必要はありませんが、「この機能はいくつの画面と処理に分かれるか」という感覚を発注者と共有しておくと、後の追加要望が「小さな追加」ではなく「相応の作業」として認識されます。

後で足す前提の機能を確認する

将来的に追加したい機能を聞いておくと、設計の判断が変わります。後で決済を入れる予定があるなら、最初からその余地を残した作りにします。逆に、拡張の予定がないなら簡素に作ります。

この質問は「今回の範囲ではないが、将来どうしたいか」という形で聞きます。今回の見積もりに入れないことを明示しながら聞くのが重要で、そうしないと聞いた機能がそのまま範囲に入ったと解釈されます。

技術的な前提を聞く

技術の話は、発注者が答えられない部分もあります。答えられない項目は、こちらから選択肢を出して決めてもらいます。

対応OSと端末、バージョンの範囲

iOSとAndroidの両方か片方か。どのバージョンまで対応するか。タブレットを含むか。この三つは工数に直結します。

発注者が判断できない場合は、利用者の属性から逆算して提案します。社内向けで支給端末が決まっているなら対応範囲を絞れますし、社外向けなら幅広い対応が必要になります。

開発の方針をどう決めるか

プラットフォームごとに個別に作るのか、共通のフレームワークで両方に対応するのか。この選択は、作りたい体験と予算のバランスで決まります。技術的な背景を噛み砕いて説明したうえで、発注者に選んでもらう形にします。

Androidアプリの開発には、Javaをはじめとした開発言語を習得しなければなりません。初心者にとって、Javaは習得が難しいといわれている開発言語です。一方、iPhoneアプリ開発では、Swiftが使用されることが一般的です。 出典: hnavi.co.jp

外部サービス連携とアカウントの準備

決済、地図、通知、認証、分析。使う可能性のある外部サービスを洗い出し、それぞれについて三点を確認します。アカウントを誰が用意するか、審査や申請が必要か、利用料を誰が負担するか。

とくに決済まわりは、事業者情報の提出や審査に時間がかかります。この待ち時間を初回の時点でスケジュールに織り込んでおかないと、後で開発の遅れとして扱われます。

既存システムとデータの持ち方

すでに何らかのシステムがある場合、そこと連携するのかしないのかを聞きます。連携する場合は、接続の仕様書があるか、担当者と話せるかを確認します。仕様書がない外部システムとの連携は、調査の工数が読めません。

データを誰が持つかも重要です。サーバー側の準備が必要なのか、端末内で完結するのか。ここが決まらないと、必要な作業の範囲が二倍以上変わることがあります。

アカウントと配信の主体

ストアの開発者アカウントを誰の名義で用意するか。この確認は初回でしておくべきです。受注側の名義で取得すると、契約が終わった後もアプリの管理権限が受注側に残り続けます。発注者の資産として残す設計にするなら、発注者名義で取得してもらう必要があり、その手続きの時間もスケジュールに含めます。

体制と意思決定の仕組みを聞く

技術より重要かもしれないのがこの部分です。誰が何を決めるのかが不明確な案件は、確実に後戻りします。

決裁者は誰か

打ち合わせに出ている人が決められる人とは限りません。デザインの最終判断を誰がするのか、機能の追加を誰が承認するのか、金額を誰が決裁するのかを、それぞれ確認します。

とくに多いのが、進んだ後に上位の役職者が登場して方針が変わる展開です。初回で「最終的に確認いただく方はどなたですか」と聞き、可能ならその人にも早い段階で成果物を見てもらう約束を取ります。

窓口は何人か

複数の担当者からばらばらに要望が来ると、どれが正式な指示か分からなくなります。窓口を一人に絞ってもらうか、要望をまとめる担当者を決めてもらいます。

窓口を絞れない場合は、こちらが要望を一覧にして「これで合っていますか」と確認する運用にします。この確認の作業も工数なので、打ち合わせの回数として見積もりに反映します。

発注者側の作業と、その担当者

素材の提供、文言の作成、テストへの参加、アカウントの取得。発注者側にも作業があります。誰がいつまでにやるかを初回で決めておかないと、その待ち時間が受注側の遅延として扱われます。

スケジュールと制約を聞く

日付の話は最後ではなく、体制の話の直後に置きます。体制が分かっていないと、現実的なスケジュールが引けないからです。

動かせない日付があるか

展示会、キャンペーン、決算、年度替わり。動かせない日付がある場合、そこから逆算します。逆算した結果、間に合わないと分かったら、初回のうちに範囲を減らす提案をします。

初回で「厳しいです」と言えないまま受けて、後から間に合わないと伝えるのが最悪の展開です。この時点で範囲の相談ができれば、段階的なリリースという選択肢が出せます。

審査にかかる時間を織り込む

ストアの審査には時間がかかり、内容によっては差し戻されます。この時間は開発の外側にあるので、スケジュールに別枠で確保します。初回でこれを説明しておくと、リリース直前の混乱が減ります。

発注者側の確認にかかる時間

デザインの確認、テストの実施、検収。これらは発注者側の作業であり、その組織のスピードに依存します。「確認に何日いただけますか」と初回で聞き、その日数をスケジュールに書き込みます。

契約と条件を聞く

初回で契約の話をするのは早いと感じるかもしれませんが、条件の枠組みだけは触れておく必要があります。

契約の形と、範囲の決め方

完成物を納める形か、作業に対して稼働で支払われる形か。前者なら範囲の確定が必要で、後者なら期間と稼働の合意が必要です。どちらの形を想定しているかを聞き、こちらの想定と違えば早い段階ですり合わせます。

検収と支払いの条件

いつ支払われるか、分割はあるか、検収の基準は何か。細かい条件は見積もりの段階で詰めますが、初回では「検収の基準を事前に文書で決めさせてください」という方針だけ伝えます。

権利の扱い

作ったものの権利をどうするか。全部を渡すのか、汎用的な部分は残すのか。実績として公開してよいかも、この段階で聞いておくと後で困りません。実績公開の可否は、後で聞くと断られやすくなります。

打ち合わせの進め方と記録の残し方

聞く内容が揃っていても、記録が残らなければ意味がありません。

議事録は当日中に送る

打ち合わせの記憶は当日で薄れます。当日中、遅くとも翌営業日には議事録を送ります。送るときに「この内容で相違なければご返信ください」と一文添えると、記録が合意の証拠になります。

決まったこと、宿題、保留の三つに分ける

議事録は時系列ではなく、この三分類で書きます。決まったことは確定事項、宿題は誰がいつまでにやるか、保留は次回までに判断が必要な論点です。この形式にすると、次回の打ち合わせがそのまま宿題と保留の確認から始められます。

保留の項目に期限を書いておくのが重要です。保留のまま放置された論点が、後になって設計のやり直しを引き起こします。

言葉ではなく絵で確認する

初回で完全な設計はできませんが、簡単な画面の流れを手書きでもよいので描いて共有すると、認識のずれが早く見つかります。言葉だけで合意した内容は、双方が違うものを想像していることがよくあります。

打ち合わせの記録を音声で残すか

内容を正確に残したい場合、録音の可否を確認する方法があります。ただし、無断での録音は信頼を損なうので、必ず事前に断りを入れます。断られた場合は、その場でのメモに集中し、聞き逃した箇所は後から確認の連絡を入れます。

録音があると議事録の精度は上がりますが、録音に頼りすぎるとその場での確認がおろそかになります。復唱による確認は、録音の有無にかかわらず行ってください。

用語を揃える

「会員」「ユーザー」「顧客」が同じものを指しているのか、違うものなのか。「登録」が何を意味するのか。初回で用語の定義を一覧にしておくと、後の仕様書の読み違いが激減します。

初回でやってはいけないこと

やるべきことと同じくらい、やらないほうがよいことがあります。

その場で金額を答える

「だいたいいくらですか」と聞かれても、その場で数字を言わないことです。口に出した数字は、条件が変わっても記憶に残り続けます。持ち帰って、前提条件とセットで文書にして出します。

すべての要望に「できます」と答える

技術的にできるかどうかと、この予算と期間でできるかどうかは別の問題です。初回で全部に「できます」と答えると、後から範囲を減らす相談が非常にしにくくなります。「実現方法はいくつかあるので、条件を整理してからご提案します」という返し方に統一します。

専門用語で押し切る

技術的な説明を丁寧にするのはよいことですが、専門用語のまま話すと発注者は判断できません。判断できないまま進んだ項目は、後で必ず覆ります。用語を使うなら、必ず言い換えを添えます。

相手の言葉をそのまま仕様として受け取る

発注者が使う言葉は、その組織の中での意味を持っています。「承認機能がほしい」と言われたとき、承認が一段階なのか複数段階なのか、差し戻しがあるのか、代理承認があるのかは、組織ごとに違います。言葉をそのまま受け取って設計に入ると、実装した後で「うちの承認はそういう流れではない」となります。

対策は、聞いた言葉を必ず具体的な操作の流れに置き換えて確認することです。「誰が申請して、誰が見て、差し戻しはあるか」という形で口頭で復唱し、その場で図に描きます。

その場で画面の細部を決めてしまう

初回で画面の色や配置まで話が及ぶことがありますが、ここに時間を使うのは効率が悪いです。細部は目的と利用者が固まってから決めるものであり、先に決めると後で覆ります。

細部の話が始まったら、「その論点はデザインの工程で扱います」と伝えて、保留として記録します。保留にすること自体を議事録に残しておけば、忘れたと思われることはありません。

次回の日程を決めずに終わる

初回の終わりに次回の日程と、そこまでの宿題を確定させます。日程が決まっていないと、宿題の期限も曖昧になります。

予算と競合の状況を聞く

金額そのものは持ち帰る一方で、予算の枠と競合の有無は初回で確認しておく価値があります。

予算の枠を聞くときの言い方

「ご予算はいくらですか」と直接聞くと、答えを避けられることが多いです。避けられる理由は、先に言うと足元を見られると警戒されるからです。この警戒を解くには、聞く目的を先に説明します。

有効なのは、「ご予算の枠が分かると、機能の優先順位のご提案ができます」という聞き方です。金額を決めるためではなく、範囲を決めるために聞いていると伝わると、答えてもらえる確率が上がります。それでも答えが出ない場合は、こちらから幅のある選択肢を出して、どのあたりが現実的かを反応で探ります。

相見積もりかどうかを確認する

他社にも声をかけているかを聞くのは、失礼にはあたりません。むしろ、比較されている前提で提案内容を組み立てられるので、双方にとって効率的です。

比較がある場合は、比較の軸を聞きます。金額なのか、実績なのか、体制なのか、スピードなのか。軸が分かれば、提案書のどこを厚くすべきかが決まります。正直なところ、軸を確認せずに提案を出すのは、的を見ずに矢を放つのと同じです。

過去に開発を依頼した経験があるか

過去に別の会社や個人に依頼した経験があるなら、そのときに何がうまくいかなかったかを聞きます。前回の失敗は、今回の期待値そのものです。「連絡が遅かった」「言ったことが伝わっていなかった」「途中で費用が増えた」といった答えが返ってくれば、そこに重点を置いた進め方を提案できます。

初めての依頼である場合は、進め方の説明をより丁寧にする必要があります。工程ごとに何が起きるか、発注者側に何をお願いするかを、最初にまとめて共有しておきます。

初回で使う質問リストの組み立て方

ここまでの内容を、実際の打ち合わせで使う形に落とします。項目を暗記するのではなく、順番を決めておくのがコツです。

順番は目的から入り、契約で締める

質問の順番は、目的、利用者、機能、技術、体制、スケジュール、予算と競合、契約の順にします。この順番には理由があります。目的と利用者が分かっていないと機能の話が発散し、機能が見えていないと技術の判断ができず、体制が分からないとスケジュールが引けないからです。

逆に、技術や契約から入ると、発注者は身構えます。目的の話から入ると、発注者は自分の事業について話すことになるので、会話が自然に進みます。

一つの質問を深く掘るより、全体を一周する

初回で一つの論点を掘り下げすぎると、他の分野に触れないまま時間が終わります。まずは全分野を一周し、答えが出なかった項目を保留として記録します。深掘りは二回目以降にします。

一周する過程で、発注者側が答えられない項目が浮かび上がります。その項目こそが、後戻りの原因になる論点です。保留として記録し、次回までにどちらが調べるかを決めます。

聞いた内容をその場で復唱する

各分野の質問が終わったタイミングで、聞いた内容を短くまとめて口頭で確認します。「いまのお話ですと、対象は社内の営業担当の方で、外出先での入力を減らすのが目的、ということでよろしいでしょうか」という形です。

この復唱をその場でやると、認識のずれがすぐ見つかります。議事録を送ってから訂正が来るより、はるかに早く安全です。

市場から見た初回打ち合わせの重み

初回の打ち合わせを丁寧にやる人と、そうでない人の差は、案件の取り方にも表れます。

アプリ開発の仕事がどのような形で募集されているかは、AIチャットボット・アプリ開発のお仕事で確認できます。募集内容を見ると、機能一覧まで書かれた案件と、目的だけが書かれた案件があります。後者は、初回の打ち合わせで要件を整理できる人にしか進められません。整理できる人にとっては競合が少ない領域になります。

隣接する分野として、AI・マーケティング・セキュリティのお仕事では、アプリに付随する分析や情報管理の業務がどう切り出されているかが分かります。初回で「データをどう扱うか」を聞ける人は、この領域の相談も受けられるようになります。

職種としての位置づけは、ソフトウェア作成者の年収・単価相場で統計にもとづく分布を確認できます。自分の担当領域を言葉で説明できると、初回の打ち合わせで役割の合意が取りやすくなります。ネットワークや基盤の知識が必要な案件では、CCNA（シスコ技術者認定）のような認定が、技術的な前提を説明する際の裏づけになります。

20年この市場を見てきた運営者の立場から言えば、継続して指名される人には共通の型があります。初回の打ち合わせで質問が多く、その日のうちに議事録が届き、決まったことと保留が明確に分かれている。この三つが揃っている人は、技術力の評価に関係なく次も呼ばれます。逆に、初回で「なんでもできます」と答えた人は、範囲の話ができないまま摩擦を起こして終わることが多いという傾向があります。

もうひとつ、運営者として見てきた限りでは、中間マージンの乗らない手数料0%の直接取引をしている人ほど、初回の打ち合わせに時間をかけています。手取りが厚い分、要件を整理する時間を確保できるからです。仲介を挟んで手取りが薄くなると、打ち合わせの時間を削って着手を急ぐことになり、結果として後戻りが増えます。初回に時間をかけられる構造そのものが、品質の差を生んでいます。

海外の案件でも考え方は同じです。Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法では、海外プラットフォームでの進め方が整理されています。言語や商習慣が違う分、初回での確認事項はさらに増えます。

初回の打ち合わせは、提案の場ではなく、後戻りの芽を摘む場です。聞くべきことを聞いた分だけ、後の工程が静かになります。

よくある質問

Q. 初回の打ち合わせはどれくらいの時間を確保すべきですか？

目的、利用者、機能範囲、技術前提、体制、スケジュール、契約の七つを扱うには、まとまった時間が必要です。一度で終えるのが難しい場合は、目的と利用者と機能範囲までを初回、技術前提と体制以降を二回目に分ける形が現実的です。事前に質問項目を送っておくと、発注者側で答えを準備してもらえるため、当日の進行が大きく速くなります。

Q. 発注者が技術的な質問に答えられない場合はどうしますか？

こちらから選択肢を出して選んでもらう形にします。対応OSであれば利用者の属性から逆算した候補を提示し、開発の方針であれば作りたい体験と予算のバランスで二案を並べます。専門用語をそのまま使うと判断できないまま話が進み、後で覆る原因になります。必ず言い換えを添えて、判断できる形にしてから聞いてください。

Q. 初回の打ち合わせで金額を聞かれたらどう答えますか？

その場で数字を言わないことです。一度口にした数字は前提条件が変わっても記憶に残り、後の交渉を縛ります。「前提条件と一緒に文書でお出しします」と伝えて持ち帰り、対応OSや機能範囲などの条件をセットにした概算として提示してください。条件つきで出せば、要件が変わったときに金額を見直す会話が成立します。

Q. 議事録はどのような形式で残すのがよいですか？

時系列ではなく、決まったこと、宿題、保留の三つに分けて書きます。宿題には担当者と期限、保留には判断が必要な期限を書き添えます。送付時に「この内容で相違なければご返信ください」と一文添えると、記録が合意の証拠として機能します。当日中、遅くとも翌営業日には送ってください。

Q. そもそもアプリが不要だと感じた場合、初回で指摘すべきですか？

指摘したほうがよい場面が多いです。目的を達成する手段としてウェブサイトの改善や既存ツールの活用が適している場合、アプリを作っても使われず、次の依頼にもつながりません。否定ではなく、目的から逆算した手段の比較として提示してください。手段の妥当性を検討できる相手として評価され、別の形の依頼につながることもあります。