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

モバイルアプリ開発の初回の打ち合わせは、案件の成否がほぼ決まる場です。ここで聞き漏らした一つの項目が、数ヶ月後に作り直しとして戻ってきます。しかも戻ってきたとき、聞かなかった側の責任として扱われることが多い。この記事では、最初の打ち合わせで何を聞き、何をその場で決め、終わったあとに何を送るかを、後戻りを防ぐ観点から順に整理します。

最初の打ち合わせで実際に決まっていること

初回の打ち合わせは、見積もりを出すための情報収集の場だと考えられがちです。実際にはそれ以上のことが決まっています。

決まっているのは、進め方の主導権が誰にあるか、確認の頻度、判断する人が誰か、そして条件を文字にする関係かどうかです。これらは議題に上がらないまま、その場の振る舞いによって決まります。質問をせずに「承知しました」だけで終えた打ち合わせは、その後もこちらが受け身で進む案件になります。

アプリの開発は、一つ作り上げるまでに幅広い工程が必要です。

アプリを1つ完成させるまでには、設計や実装はもちろん、エラー対応から公開手続き、さらにはリリース後の運用改善まで、一連の工程をすべて自ら経験することになります。 出典: i3design.jp

この工程の全体像が依頼者と共有できていないと、依頼者は「実装」だけを開発だと考えたまま話を進めます。初回に工程の全体を示すことは、単なる説明ではなく、後の範囲の合意の土台になります。

打ち合わせの前に用意しておくもの

準備なしで臨むと、聞き漏らしが必ず出ます。三つを用意します。

一つ目は、質問の一覧です。その場で思い出しながら聞くと、相手の話の流れに引きずられて抜けが出ます。紙でも画面でも構わないので、項目を並べたものを手元に置きます。

二つ目は、進め方を示す資料です。工程の一覧、それぞれで何をするか、依頼者側に何をお願いするか。この資料を先に見せると、相手の質問の質が上がります。

三つ目は、議事録の型です。決まったこと、決まらなかったこと、次にやること、確認をお願いする項目。この四つの見出しだけを先に作っておき、打ち合わせ中に埋めます。

目的を確認する質問

最初に聞くのは機能ではなく目的です。ここが曖昧なまま進むと、あとで判断の基準がなくなります。

何を解決したいのか

「アプリを作りたい」の背後には必ず具体的な困りごとがあります。問い合わせの電話が多い、来店の予約が電話でしか受けられない、既存のWebサイトがスマートフォンで使いにくい。この困りごとが分かると、機能の優先順位が自動的に決まります。

答えが出てこない場合、その場で無理に引き出す必要はありません。「解決したい課題の整理から一緒に進める工程を設けましょうか」と提案し、その工程を別に見積もる形にします。

誰が使うのか

利用者が社内の従業員なのか、既存の顧客なのか、これから獲得する新規の利用者なのかで、設計はまったく変わります。社内の利用であれば端末を限定できますが、一般に公開するなら幅広い端末とOSに対応する必要があります。

利用者の年齢層や、利用する場面も聞きます。屋外で使うなら通信が不安定な状態を想定した設計が必要になり、これは工数に直結します。

成功をどう測るのか

何をもって成功と判断するかを聞いておくと、後の議論が減ります。ダウンロード数なのか、業務の時間の削減なのか、問い合わせ件数の減少なのか。

指標が決まっていると、機能を追加するかどうかの判断もその指標に照らして行えます。指標がないと、判断が「あったほうがよさそう」という感覚に依存し、範囲が膨らみます。

範囲を確定する質問

目的を確認したら、範囲を絞ります。ここで曖昧に流すと、見積もりが成立しません。

対応するプラットフォームは、iOSとAndroidの両方か、片方かを確認します。片方でよいなら、どちらを優先するかと、その理由も聞きます。理由が「社内はiPhoneが多いから」であれば、社外向けの展開時に方針が変わる可能性を想定できます。

既存のシステムとの連携があるかは必ず確認します。連携がある場合、その仕様書が存在するか、担当者と話せるかまで踏み込みます。仕様書がなく担当も不明という状態は珍しくなく、その場合は調査の工程が必要になります。

既存のデータを引き継ぐ必要があるかも聞きます。「いまのデータはそのまま使えます」という回答は、実際に形式を確認するまで信用できません。件数と形式、抽出できるかどうかを確認します。

管理する仕組みが必要かも確認します。アプリに表示する内容を依頼者側で更新したいなら、そのための画面が必要です。通知を送りたいなら、送信を管理する仕組みが必要です。ここを聞かずに進めると、開発の終盤で「更新はどうやるのですか」と聞かれます。

前提を確認する質問

範囲が決まっても、前提が揃っていなければ日程は組めません。

デザインがどこまで用意されているかを聞きます。全画面のデザインデータがあるのか、一部だけか、まったくないのか。ないなら、デザインの工程を含めるかどうかを決めます。含めない場合、デザインの提供時期が日程の前提になります。

アプリに載せる文言や画像を誰が用意するかも確認します。素材の提供が遅れる案件は非常に多く、これが日程を押す主要な原因になります。

配信用のアカウントを保有しているかも聞きます。持っていない場合、法人としての登録には手続きの時間が必要です。証明書や鍵を誰が管理するかも、この時点で決めておきます。

公開に必要な情報も確認します。プライバシーに関する方針の文書、問い合わせ先、事業者の情報。これらは審査で求められる項目であり、用意がないとリリース直前で止まります。

案件の全体像と工程ごとの関わり方を確認しておきたい場合は、アプリケーション開発のお仕事で、開発の受注がどのような流れで進むかを見ておくと、聞くべき項目の抜けを減らせます。

アプリが扱うデータを確認する

機能の一覧だけを聞いて進めると、データの扱いに関する確認が抜けます。ここは公開の審査と法務の両方に関わるため、初回で触れておきます。

利用者から取得する情報を洗い出します。氏名や連絡先を登録させるのか、位置情報を使うのか、カメラや写真の読み取りがあるのか、端末に保存されている連絡先を参照するのか。取得する情報の種類が増えるほど、利用者に示す説明の文章が増え、審査で確認される項目も増えます。

取得した情報をどこに置くかも決めます。端末の中だけで完結するのか、依頼者側の環境に送るのか、外部のサービスに預けるのか。保存先が決まると、通信の保護や認証の設計が決まり、工数が見えます。ここを曖昧にしたまま設計に入ると、後から保存先が変わったときに作り直しになります。

外部のサービスを使う予定があるなら、その契約を誰の名義で結ぶかを確認します。地図、通知、分析、認証、課金の代行。これらは依頼者側の名義で契約するのが原則で、利用の枠を超えた場合の費用も依頼者の負担になります。開発する側の個人名義で契約したまま納品すると、引き継ぎの段階で必ず問題になります。名義と支払いの手段を、この時点で一覧にしておきます。

利用の状況を計測する仕組みを入れるかどうかも聞きます。入れるなら、何を数えたいのかを先に決めます。目的のない計測は、利用者に示す説明の項目を増やすだけで、依頼者の判断材料にはなりません。

課金と決済の扱いを確認する

金銭のやり取りが発生するアプリでは、その方法によって作り方も審査の通り方も変わります。

売るものがアプリの中で使う権利や機能なのか、現実の物品や対面のサービスなのかで、使わなければならない決済の仕組みが変わります。ここを取り違えると、審査で差し戻されてから設計を変えることになります。判断が微妙な場合は、その場で断定せず持ち帰り、公開の規約の該当箇所を読んでから回答します。初回で断定して間違えるより、持ち帰るほうが安全です。

継続して課金する形にするなら、解約をどこで行えるようにするか、期間の管理をどちら側で持つかを決めます。解約の導線が分かりにくい設計は、審査で指摘の対象になります。

領収や請求の書類が必要かも聞きます。必要なら、誰が発行するのか、どの情報を載せるのか、いつ発行するのかを決めておきます。この確認を飛ばすと、公開の直前に書類の話が出て、仕組みの追加になります。

すでにあるアプリを引き継ぐ依頼のとき

新規の開発ではなく、他の会社や個人が作ったアプリの改修や運用を引き継ぐ依頼も少なくありません。この場合、初回で確認する項目が新規とは別に増えます。

まず、いま公開されているものと同じ状態のものを、手元で動かせるかを確認します。ソースの一式が揃っているか、動かすために必要な設定や鍵が揃っているか、外部のサービスの接続先が生きているか。この確認が取れるまでは、改修の見積もりを出せません。動く状態を再現するまでの調査を、独立した工程として先に置く形にします。

公開に使っている登録の情報と、署名に使う証明書や鍵の所在も確認します。前の担当者の個人の名義になっている場合、名義の移し替えが必要になり、これには時間がかかります。手続きの主体は依頼者側になるため、初回で伝えて着手してもらいます。

外部のサービスの契約が誰の名義かも同じように確認します。支払いが前の担当者のままになっていると、支払いが止まった時点でアプリの一部が動かなくなります。

前の担当者と連絡が取れるかどうかも聞きます。取れるなら、引き継ぎの場を一度設けてもらいます。取れないなら、仕様を読み解く調査の時間を工程に入れます。連絡が取れない前提で見積もると、時間の見積もりが現実に近づきます。

設計や仕様の資料が残っているかも確認します。残っていない場合、改修の前に現状を整理する工程が必要です。この工程を省いて改修に入ると、直した箇所とは別の場所が動かなくなり、原因の特定に時間を取られます。

体制と意思決定の質問

技術の話と同じくらい重要なのが、誰がどう決めるかです。

最終的に承認するのが誰かを、初回に一度だけ聞きます。「最終的にこの画面を承認されるのはどなたになりますか」。この質問は失礼ではなく、むしろ社内の合意形成を意識している相手として受け取られます。

窓口の担当者とは別に承認者がいる場合、要所の確認にその人が入る段取りを決めます。承認者が不在のまま進んだ案件で終盤に作り直しが起きるのは、担当者の力不足ではなく、進め方の設計が抜けていたためです。

確認の頻度と手段も決めます。週に一度の定例を置くのか、必要なときだけ連絡するのか。連絡はどのツールを使うのか。受け口が複数あると依頼を数えられなくなるため、一つに決めます。

依頼者側の作業も明確にします。素材の提供、確認への回答、アカウントの発行、審査に必要な情報の準備。これらを相手の作業として一覧にし、遅れると日程が動くことを共有します。

日程と予算の質問

時期については、希望の日付だけでなく理由を聞きます。展示会に合わせる、キャンペーンに合わせる、決算の前に稼働させる。理由がある日付は調整の余地があり、理由が説明されない日付は後から動く可能性が高いものです。

予算については、枠があるかを聞きます。金額を言いたがらない相手もいますが、社内で予算が確保されているかどうかだけでも確認します。確保されていない段階で提案の作業を進めると、その作業がそのまま無償になります。

判断の期限も聞きます。いつまでに発注の可否が決まるのか。この期限が分かっていれば、こちらの稼働の計画も立てられます。

契約条件の確認

法務の観点で、初回に触れておくべき項目があります。堅苦しく感じられるかもしれませんが、後で持ち出すほうがはるかに気まずくなります。

発注する側には、取引条件を書面や電子メールなどで明示する義務があります。業務の内容、報酬の額、支払期日といった項目です。つまり、条件を文字にすることは相手にとっても義務であり、こちらが特別なことを求めているわけではありません。

支払期日も確認します。成果物を受け取った日から起算して60日以内のできる限り短い期間内に定める必要があります。「検収完了後に支払う」とだけ書かれていて検収の期限がない場合、実質的に期日が存在しない状態になります。検収の期限を明記してもらうよう求めます。

成果物の権利をどう扱うかも聞きます。全部を譲渡するのか、利用を許諾する形にするのか。あわせて、再委託が可能かも確認します。作業の一部を協力者に依頼する可能性があるなら、この確認は必須です。

これらの条項について、契約書の文面が妥当かどうか判断に迷う場合は、弁護士に確認してください。契約書の作成や確認を専門にしている専門家に相談する方法もあります。条件を確認すること自体は、相手を疑う行為ではありません。両方が同じ前提で進むための手続きです。

契約や条件の整理は、開発以外の受託でも共通する論点です。業務の設計や運用の支援を含む案件では、要件が固まりきらないまま進みやすいため、同じ確認がより重要になります。仕事の性質はAIコンサル・業務活用支援のお仕事でも整理されています。

テストと検収の基準を初回で決める

完成の定義が決まっていない案件は、いつまでも終わりません。初回のうちに、何をもって受け入れとするかを決めておきます。

確認する端末とOSの範囲を決めます。どの世代まで対応するのか、大きな画面の端末を含むのか、依頼者側が確認に使う端末は何か。範囲を決めずに進めると、公開の直前に手元の古い端末で不具合が見つかり、それが対応の範囲かどうかの議論から始まります。範囲は書面に残し、範囲の外で見つかった事象は別の作業として扱うことを合意しておきます。

不具合と仕様の変更の線引きも決めます。決めた通りに動かないものが不具合、決めたこと自体を変えたいものが仕様の変更です。この二つを同じ窓口で同じように扱うと、仕様の変更が無償の修正として積み上がります。報告の様式を一つ決め、再現する手順、使った端末、OSの版、起きたことと期待していたことを書いてもらう形にすると、切り分けが早くなります。

確認の期間も決めます。成果物を渡してから何日で確認を終えるのか、期間内に連絡がなければどう扱うのか。期間が書かれていない受け入れは、事実上いつまでも終わらない状態になり、支払いの起点も定まりません。

公開後の扱いを初回で線引きする

公開して終わりではないことは依頼者側も感じていますが、範囲として言葉にされることは多くありません。ここを初回で線引きしておくと、後の関係が楽になります。

引き渡してから一定の期間、決めた通りに動かない箇所を直す。この範囲を最初に書いておきます。対象になる範囲と、対象にならないものを分けて書きます。対象にならない例としては、新しい機能の追加、OSの新しい版への対応、外部のサービスの仕様が変わったことによる改修があります。

OSは定期的に新しい版が出ます。その都度の確認と修正を含めるのか、別の取り決めにするのかを決めます。含めない場合、含めないことを文字にして残します。書いていないと、公開から時間が経ってから無償の対応を求められます。

不具合が起きたときの連絡の手段と、応答できる時間帯も決めます。夜間や休日にどこまで対応するのかを最初に決めておかないと、期待だけが積み上がります。対応できないなら、できないことを最初に伝えるほうが、後で断るより角が立ちません。

利用者からの問い合わせを誰が受けるのかも決めます。公開の画面に載せる連絡先は依頼者側のものにするのが通常で、その受け口を用意する作業も、依頼者側の作業として一覧に入れておきます。

打ち合わせ中にやること

質問するだけの場にしないために、その場でやることを決めておきます。

その場で決めるのは、対応するプラットフォーム、承認者、確認の頻度と手段、次に何をするかの四つです。この四つが決まらないまま終わった打ち合わせは、もう一度同じ場を設けることになります。

持ち帰るのは、金額と日程です。その場で概算を口にすると、その数字が上限として記憶されます。「持ち帰って整理し、◯日までにお出しします」と伝えるだけで足ります。

答えが出なかった項目は、その場で「未確定」として一覧に残します。曖昧にしたまま次に進むと、誰も覚えていない状態になります。未確定として記録し、いつまでに決める必要があるかも一緒に書きます。

時間の配分を決めておく

聞くべき項目が多いため、時間の使い方を決めておかないと、話しやすい話題だけで終わります。

冒頭は、相手の話を聞く時間に充てます。何を作りたいか、なぜ作りたいかを、遮らずに聞きます。この段階でこちらから機能の提案をすると、相手は本来の困りごとを言わなくなります。

次に、範囲と前提の確認に時間を割きます。ここが最も長くなる部分で、質問の一覧を順に潰していきます。相手が答えられない項目が出たら、その場で止まらず「未確定」として記録し、次に進みます。

体制と意思決定の確認は短くて済みます。承認者、確認の頻度、連絡の手段の三つを決めるだけです。

最後に、次にやることを確認して終えます。誰が、いつまでに、何をするか。この確認を口頭で終わらせず、その場でメモに書き、後で議事録として送ります。

技術の詳しい話は、初回では深追いしません。実装の方法を細かく説明しても、相手は判断できないためです。技術の話が必要になるのは、選択によって費用や日程が変わるときだけです。

相手が答えられないときの聞き方

質問に対して「まだ決まっていません」と返ってくることは頻繁にあります。この回答を、そのまま受け取って次に進むと、後で困るのはこちらです。

有効なのは、選択肢を示して反応を見る方法です。「対応するのは両方でしょうか」と聞いて答えが出ない場合、「片方から始めて、反応を見てもう片方を追加する進め方もありますが、いかがでしょうか」と提案します。選択肢があると、判断の材料が具体的になります。

もう一つは、影響を先に示す方法です。「この項目が決まらないと、この工程に着手できません」と伝えると、相手の社内でも優先度が上がります。責めるための説明ではなく、順番の説明として伝えます。

それでも決まらない項目は、決める期限を置きます。「◯日までに決まらない場合、日程はその分後ろに動きます」と、条件として書いておく。この一文を議事録に残しておくと、後から日程の話になったときに事実で説明できます。

打ち合わせで出た言葉を、そのまま要件にしない

相手が使った言葉と、こちらが理解した内容がずれていることは、非常に多く起こります。同じ言葉でも、業界や社内の慣習によって意味が違うためです。

「ログイン機能」と言われたとき、それがメールアドレスとパスワードによるものか、電話番号を使うものか、他のサービスの認証を使うものかで、作業量は大きく変わります。「会員機能」も同様で、登録して情報を保持するだけの場合と、権限を分けて管理する場合では別物です。

対処は単純で、言葉が出るたびに具体化して確認します。「ログインは、メールアドレスとパスワードで想定されていますか」と、その場で聞きます。この確認を五回か六回繰り返すだけで、後の認識のずれはかなり減ります。

議事録に書くときも、相手の言葉をそのまま写さず、具体化した内容で書きます。相手が読んで違和感があれば指摘が来ますし、指摘がなければ合意として扱えます。

画面越しの打ち合わせで気をつけること

オンラインでの打ち合わせが中心になると、対面では自然に得られていた情報が減ります。

一つは、その場にいる人の反応です。画面には発言者しか映らないことが多く、他の参加者が納得しているかが分かりません。要所で「ここまでで気になる点はありますか」と、名前を挙げて確認します。

もう一つは、資料の共有です。口頭だけで進めると、後から認識がずれます。画面を共有しながら、その場で項目を埋めていく形にすると、参加者全員が同じものを見て確認できます。

録画については、必ず事前に許可を取ります。記録が残ることに抵抗を示す相手もいるため、録画しない場合は、その分メモを丁寧に取り、終了後の議事録で補います。

二回目までに準備すること

初回で得た情報をもとに、次の打ち合わせまでに用意するものがあります。

一つ目は、確認事項の一覧です。未確定として残した項目を並べ、それぞれの期限と、決まらなかった場合の影響を書きます。

二つ目は、範囲の一覧です。今回の対応に含めるものと、次の段階に回すものを分けて書きます。この一覧があると、予算の話になったときに、金額ではなく範囲の議論ができます。

三つ目は、進め方の提案です。要件が固まりきっていないなら、整理の工程を先に置く提案をします。段階を分ける提案に応じる相手は、その後の工程でも協力的に進みます。

四つ目は、見積もりです。前提条件と除外事項を必ず添えます。金額だけの書類を出すと、条件の合意が成立しないまま金額の交渉だけが始まります。

なお、運用や基盤の知識を体系的に持っていることは、初回の説明でも役に立ちます。公開後の運用や監視まで含めた話ができると、相手は工程の全体像を理解しやすくなります。技術の裏付けを示す手段としては、CCNA（シスコ技術者認定）のような認定が、保守を含む提案の説得力を補います。

打ち合わせのあと、すぐにやること

打ち合わせが終わったら、できるだけ早く議事録を送ります。時間が経つほど、記憶にずれが生じます。

議事録には四つの見出しを置きます。決まったこと。決まらなかったこと。次にやること。確認をお願いする項目。

この形式には理由があります。決まったことだけを書くと、決まっていない項目が忘れられます。決まらなかったことを明示すると、相手の社内でも検討が始まります。

議事録の最後には、「内容に相違がありましたらご指摘ください」と添えます。指摘がなければ、この内容で合意したという記録になります。口頭の合意しかない状態と比べて、後の説明のしやすさがまったく違います。

送る手段は、文字が残るものにします。会議のあとに電話で確認しても記録は残りません。

聞かなかった項目が、どう後戻りになるか

初回に確認しなかった項目は、決まった形で戻ってきます。

既存システムとの連携を確認しなかった案件では、実装が進んだ段階で「基幹システムのデータも表示したい」という要望が出ます。この時点での対応は、設計の変更を伴います。

承認者を確認しなかった案件では、デザインの合意後に決裁者が現れ、方針が最初から議論しなおしになります。

配信用アカウントを確認しなかった案件では、開発が完了してから登録の手続きが始まり、公開が数週間遅れます。

プライバシーに関する方針の文書を確認しなかった案件では、審査でリジェクトされてから文書を用意することになり、再提出の時間が加わります。

いずれも、初回に一つ質問しておけば防げたものです。質問にかかる時間は数分で、後戻りにかかる時間は数週間です。この差を知っていることが、経験の中身になります。

海外の依頼者と仕事をする場合は、時差と商習慣の違いにより、初回の確認がさらに重要になります。契約前に何を確認するかは、Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法でも実務の観点から整理されています。

現場を見てきた立場からの観察

在宅とフリーランスの仕事の市場を20年見てきた運営者の立場から言えば、案件が順調に進むかどうかは、初回の打ち合わせで質問をしたかどうかでかなりの部分が説明できます。技術の力量の差より、この差のほうが結果に効いています。

質問をためらう理由は、たいてい「聞くと仕事が来なくなるのではないか」という不安です。実際に起きているのは逆で、質問が具体的な相手のほうが信頼されます。依頼する側からすれば、何を確認すべきか知っている相手は、経験がある相手に見えるからです。

もう一つ、長く続く人に共通しているのは、初回で必ず「相手の作業」を明示していることです。素材の提供、確認の返答、アカウントの発行。これらを相手の担当として一覧にしておくと、遅れが出たときも責任の押し付け合いになりません。準備を頼むことは、相手を軽んじる行為ではなく、一緒に進めるための設計です。

仲介の手数料が乗らない直接の取引では、同じ予算で依頼する側はより多くを頼めて、受ける側は手取りが厚くなります。手数料0%という条件が効いてくるのは金額そのものよりも、その余白を「最初に条件を詰める時間」に回せる点です。初回の確認に十分な時間をかけられる案件は、その後の後戻りが目に見えて減ります。

条件を確認し、記録に残し、文字で合意する。この三つを最初に済ませておけば、あとで何かが起きたときに守ってくれるものが手元に残ります。法律は、その手続きを踏んだ人の側に立ちます。

よくある質問

Q. 初回の打ち合わせで、契約条件まで踏み込んで聞いてよいですか？

問題ありません。発注する側には取引条件を書面や電子メールなどで明示する義務があるため、業務内容、報酬額、支払期日を確認することは相手にとっても必要な手続きです。あわせて成果物の権利の扱いと再委託の可否も確認します。条項の妥当性に迷う場合は、弁護士に確認してください。

Q. 承認者を確認する質問は、失礼になりませんか？

なりません。むしろ社内の合意形成を意識している相手として受け取られます。窓口の担当者とは別に承認する人がいる場合、要所の確認にその人が入る段取りを最初に決めておきます。承認者が不在のまま進んだ案件で終盤に作り直しが起きるのは、進め方の設計が抜けていたためです。

Q. その場で概算の金額を聞かれたらどう答えますか？

持ち帰ります。その場で口にした数字は上限として記憶され、後から正確な見積もりを出しても比較の基準になってしまいます。「持ち帰って整理し、いつまでにお出しします」と伝えるだけで足ります。金額と日程は持ち帰り、プラットフォーム、承認者、確認の頻度、次の行動はその場で決めます。

Q. 打ち合わせのあと、何を送るべきですか？

議事録を早く送ります。決まったこと、決まらなかったこと、次にやること、確認をお願いする項目の四つを見出しにします。決まらなかったことを明示すると相手の社内でも検討が始まります。末尾に相違があれば指摘してほしい旨を添えると、指摘がない場合に合意の記録として機能します。

Q. 相手が要件をうまく説明できない場合はどうしますか？

無理にその場で引き出す必要はありません。課題の整理から一緒に進める工程を提案し、その工程を別に見積もる形にします。要件が固まらないまま完成を約束する契約を結ぶと、完成の定義がないまま責任だけを負うことになります。整理の工程と開発の工程を分けることで、双方の負担が明確になります。