モバイルアプリ開発の納期に間に合わないとき｜伝える順番

結論から書きます。モバイルアプリ開発で納期遅れが見えたときに最も大切なのは、遅れの理由でも挽回策でもなく、伝える時期と順番です。同じ内容でも、確度が下がった時点で伝えた場合と、期日の前日に伝えた場合とでは、相手の受け取り方も、その後の関係もまったく別のものになります。この記事では、遅れの兆候を早く掴む方法、伝える順番の設計、一報の書き方、相手側に原因があるときの扱いまでを順番に整理します。

伝える順番の結論

先に全体像を示します。納期遅れが見えたときの手順は次の順です。

事実を確定する。原因を分類する。影響の範囲を特定する。選択肢を作る。伝える。記録する。

この順番には理由があります。事実が曖昧なまま伝えると、相手は「どのくらい遅れるのか」を聞き返すしかなく、会話が二往復増えます。選択肢を持たずに伝えると、判断を相手に丸投げした形になり、相手は不安だけを受け取ります。順番を守ると、一度の連絡で相手が判断できる状態になります。

正直なところ、この順番を守れずに失敗する例は非常に多く見られます。理由も単純で、遅れを認識した瞬間の心理は「まだ挽回できるかもしれない」に傾くからです。挽回の見込みを探している間に日数が過ぎ、伝えられる選択肢が減っていきます。

遅れは確定する前に兆候が出る

納期遅れは、期日の直前に突然起きるものではありません。必ず前段階で兆候が出ます。

進捗の報告が同じ数字で止まる

進捗の報告が二週続けて同じ水準にとどまっている場合、実際には止まっています。作業をしていないのではなく、残っている作業が見えていない状態です。

この現象は、残作業を「あとは細かい調整だけ」と表現し始めたときに起こりやすくなります。細かい調整の中身を一つずつ書き出すと、数十件の項目が出てくることは珍しくありません。数字が動かないと感じた時点で、残作業を項目に分解して数え直します。

確認待ちの項目が積み上がる

相手の返答を待っている項目が三つ以上並んだら、その時点で日程は動いています。待っている間に別の作業を進めれば吸収できると考えがちですが、確認待ちの項目は後続の作業と繋がっていることが多く、順番を入れ替えると手戻りが増えます。

待ちが発生した時点で「この項目の回答が◯日を過ぎると、リリース日に影響します」と伝えておくと、遅れの原因が後から明確になります。

未確定の項目が減らない

着手時に未確定だった項目が、中盤になっても同じ数だけ残っている案件は、ほぼ確実に遅れます。決まっていないことは、決まった瞬間から作業が始まるためです。

未確定の一覧に期限を書き、期限を過ぎたものには「◯日超過」と表示しておきます。この表示があるだけで、相手の社内でも優先度が上がります。

モバイルアプリ固有の遅延要因

Webの案件と同じ感覚で計画を立てると、モバイルアプリでは足りなくなります。固有の要因があるためです。

モバイルアプリ開発の期間がWebシステムと最も異なるのは、iOS・Androidという2つのプラットフォーム、App Store・Google Playという2つのストア、そして毎年のOSアップデートという、モバイル固有の制約がスケジュールに直接効いてくる点です。これらは「開発が終わったら最後にやる作業」ではなく、企画段階から織り込んでおくべき変数です。ここを軽視すると、開発自体は順調でもリリース直前で足止めを食らう、という事態に陥ります。 出典: ripla.co.jp

この指摘のとおり、遅れの多くは開発そのものではなく、最後の工程で発生します。要因を分けて見ます。

二つのプラットフォームで作業が二重になる

iOSとAndroidを両方対応する案件では、一つの実装に対して二つの確認が必要です。クロスプラットフォームのフレームワークを使っても、レイアウトの崩れ方、キーボードの挙動、戻る操作の扱い、通知の権限の求め方は違います。片方で直したものが、もう片方で崩れる確認は毎回発生します。

計画を立てるときに「実装の工数」だけを積むと、この確認の時間が抜けます。片方の対応が終わってから、もう片方の確認と調整に一定の期間を置く形で計画します。

ストアの審査は自分では短縮できない

審査に要する時間は自分の努力で縮められません。しかもリジェクトされる可能性があり、その場合は原因を調べて修正し、再提出する時間が必要になります。

計画には、審査に出す日ではなく、審査を通す日を書きます。そのうえで、リジェクトが一度発生しても間に合う余裕を置きます。この余裕がない計画は、審査に一度でも引っかかった時点で破綻します。

OSの更新と端末の差

OSは毎年更新されます。更新の時期に開発が重なると、それまで動いていた実装が動かなくなることがあります。また、依頼者が確認に使う端末が古い機種である場合、手元では起きない事象が報告されます。

これらは「予期できない事故」ではなく、毎年起きる定例の変数です。計画に組み込んでおけば、遅れの理由として説明する必要すら生じません。

外部の連携先の都合

決済、地図、認証、通知。外部のサービスと連携する案件では、その申請や審査に時間がかかります。申請してから利用できるまでに日数を要するものもあり、これは開発の進み具合と関係なく発生します。

連携が必要な項目は、着手直後に申請を出します。後回しにすると、開発が終わっているのにリリースできない状態が生まれます。

伝える順番を具体化する

兆候を掴んだら、次は伝える準備です。順番どおりに進めます。

事実を確定する

まず、何が、どれだけ遅れるかを数字で確定します。「少し遅れそうです」は事実ではありません。「合意していた◯日の納品に対して、現時点の見込みは◯日です」という形にします。

このとき、楽観的な見込みを書かないことが重要です。挽回できるかもしれない前提の日付を伝えると、その日付も守れなかったときに信用が二重に失われます。実現の確度が高い日付を出します。

原因を分類する

原因を三つに分けます。自分側の要因、相手側の要因、どちらでもない外部の要因です。

分類は責任追及のためではなく、対処の方法が違うためです。自分側の要因なら体制や進め方を変えます。相手側の要因なら相手の行動が必要です。外部の要因なら日程そのものを見直します。分類せずに伝えると、原因の話が感情の話に変わります。

影響の範囲を特定する

遅れが何に影響するかを確認します。相手にとって重要なのは開発の日程ではなく、その先にある予定です。展示会、キャンペーン、決算、社内の報告。これらのどれに影響するかによって、相手の判断が変わります。

影響の範囲が分かっていれば、「全体が遅れる」ではなく「この機能の公開だけが◯日遅れます」と伝えられます。相手の被害が小さくなる伝え方は、事実を曲げなくても作れます。

選択肢を作る

伝えるときには、必ず選択肢を添えます。典型的なのは三つです。

日付を守り、一部の機能を次の段階に回す。全機能を揃え、日付を後ろに動かす。日付も機能も維持し、体制を増やす。

三つ目には費用の話が絡むため、相手の判断が必要です。選択肢を出すことの意味は、相手に決めてもらうことにあります。判断材料を持たない相手は不安になり、不安は不信に変わります。

伝える相手と手段を選ぶ

伝える相手は、窓口の担当者だけでは足りない場合があります。日程が社内の予定と繋がっているなら、その予定を管理している人にも伝わる必要があります。ただし、担当者を飛び越えて連絡すると関係が悪化します。担当者に伝えたうえで、「社内で共有が必要な方はいらっしゃいますか」と確認するのが実務的です。

手段は、文字で残る形を必ず使います。電話や会議で先に伝える場合も、その後に同じ内容を文字で送ります。文字がないと、後から内容が変わって記憶されます。

記録に残す

伝えた内容、伝えた日、相手の返答、決まったこと。この四つを残します。遅れの経緯は、後の請求や検収の場面で必ず参照されます。

記録は相手を追い詰めるためのものではありません。双方が同じ前提で会話するための土台です。

一報の文面の型

実際の連絡は、次の順で書くと伝わります。

最初に結論。「◯日の納品予定に遅れが生じる見込みです」。次に現在の見込み。「現時点で◯日を見込んでいます」。次に原因を一行で。次に影響。次に選択肢。最後に、いつまでに判断が必要かを書きます。

謝罪は冒頭に一度だけで足ります。長い謝罪は、読む側にとって本題を遅らせるだけです。原因の説明も、必要な分量を超えると言い訳に見えます。目安として、原因の説明は選択肢の説明より短くします。

説明が必要なのは、相手の判断に影響する情報だけです。「審査に想定より時間がかかっている」は判断に影響するので書きます。「今週は他の案件が立て込んでいた」は判断に影響しないので書きません。

やってはいけない三つの対処

黙って作業時間で吸収する

夜間や休日の作業で埋めて、遅れを報告しないまま日付を守る。この選択は、短期的には問題が起きないように見えますが、次の案件の計画がさらに厳しくなります。相手は「この分量はこの期間でできる」と学習するためです。

さらに、無理な作業で作ったものは品質が落ち、リリース後の不具合対応で結局時間を失います。

品質を落として日付だけ守る

テストを省いて日付を守る選択は、モバイルアプリでは特に危険です。不具合が見つかった場合、修正版を出すには再びストアの審査を通す必要があり、ユーザーの手元に届くまでに時間がかかります。

日付を守るために品質を落とすなら、その判断は相手と共有します。何を確認していないかを明示したうえで出す。黙って出すのとは、後の展開がまったく違います。

できた部分だけを報告する

進捗の報告で、完了した部分だけを伝えて残りに触れないと、相手は順調だと理解します。この状態が続いた後で遅れを伝えると、相手は「なぜ今まで報告がなかったのか」を先に問います。

報告には、完了したこと、進行中のこと、止まっていること、判断を待っていることの四つを毎回入れます。止まっていることを毎回書いていれば、遅れの連絡は突然のものではなくなります。

相手側の原因で遅れているとき

回答が来ない、素材が届かない、承認が下りない。これらが理由で作業が止まっている場合も、伝え方の原則は同じです。

責任の所在を主張する形にはしません。「回答をいただけていないため進められません」ではなく、「この項目の回答をいただいた時点から◯日で完了します。◯日以降になるとリリース日に影響します」と、事実と条件で伝えます。

重要なのは、待ちが発生した当日に伝えることです。二週間待ったあとで「待っていました」と言っても、その二週間は自分の遅れとして扱われます。待ちが発生した日に記録し、期日への影響を先に共有しておけば、事実として説明できます。

なお、発注する側には取引条件を明示する義務があり、成果物を受け取った日から起算して一定の期間内に報酬を支払う義務もあります。遅れの原因が相手側にあるにもかかわらず、報酬の減額ややり直しを求められるような場合は、契約の条項と経緯の記録を確認したうえで、必要に応じて弁護士や公的な相談窓口に相談してください。

遅れが確定した後の再計画

日付を動かすと決めたら、新しい計画は前より詳しく作ります。同じ粒度で作り直すと、同じ理由でまた遅れます。

残作業を項目に分解し、それぞれに必要な日数を置きます。確認待ちが必要な項目には、相手の作業として何が必要かを明記します。審査に出す日と通す日を分けて書きます。そのうえで、途中に一度、進み具合を確認する日を設定します。

新しい日付には余裕を含めます。余裕を含めた日付を出すことは、水増しではありません。一度遅れた案件で、余裕のない計画を出すことのほうが誠実さを欠きます。

計画の粒度を上げると、相手にも進み具合が見えるようになります。見えている案件では、相手からの問い合わせも減ります。開発の受注がどのような工程で進むかを整理しておきたい場合は、アプリケーション開発のお仕事で、案件の流れと関わり方を確認しておくと、計画の抜けを減らせます。

遅れの規模によって対応を変える

すべての遅れを同じ手順で扱う必要はありません。規模によって、必要な連絡の重さが変わります。

数日の遅れ

一つの工程が数日ずれる程度なら、後続の工程で吸収できることがあります。この場合でも、吸収できる見込みであることを含めて伝えます。

書き方は簡潔で構いません。「この工程が◯日ずれていますが、後続で吸収できる見込みです。最終の納品日に影響はありません」。この一報があると、相手は状況を把握したうえで安心できます。何も言わずに吸収して、後で別の理由で遅れたときに、まとめて説明することになるほうが厄介です。

数週間の遅れ

最終の納品日が動く規模になると、相手の社内でも調整が必要になります。この段階では、選択肢を三つ用意したうえで、判断の期限も添えます。

判断の期限を書くのは、相手を急かすためではありません。判断が遅れるほど、選べる選択肢が減るためです。「◯日までにご判断いただければ、機能を分けて先に出す方法が選べます。それ以降は日付を動かす方法のみになります」と、時間と選択肢の関係を示します。

リリース時期そのものが変わる規模

事業側の予定に影響する規模の遅れでは、担当者だけで判断できません。この場合は、担当者が社内で説明するための資料を作る手伝いまでを含めて考えます。

現状、原因、選択肢、それぞれの影響を一枚にまとめた資料を渡すと、担当者は社内で説明しやすくなります。受注側が社内政治に踏み込む必要はありませんが、担当者が説明に困らない材料を渡すことは、その後の関係に効きます。

一人で受けている場合に取れる手段

組織なら人を足せますが、個人で受けている場合は選択肢が限られます。それでも取れる手段はあります。

一つ目は、範囲を分けることです。全部を同時に出すのではなく、動く部分から順に出す。この方法はモバイルアプリでも成立します。最初のリリースで中核の機能だけを出し、次の更新で残りを出す形です。ストアの審査を分割して通せるため、リスクも分散します。

二つ目は、作業の一部を切り出して協力者に依頼することです。ただし、再委託が契約で禁止されている場合があります。契約書の再委託の条項を確認し、必要なら事前に承諾を得ます。無断で外部に出すと、それ自体が契約違反になります。

三つ目は、確認の作業を相手に分担してもらうことです。動作確認は依頼者側でも実施できます。確認の観点を一覧にして渡し、報告の形式を決めておけば、確認の工程を並行させられます。

いずれの手段も、着手後に慌てて選ぶより、計画の段階で「遅れたときに取る手段」として用意しておくほうが機能します。案件の種類ごとに向く手段が違うため、扱う領域を広げておくことも備えになります。関連する分野の仕事の性質はAI・マーケティング・セキュリティのお仕事でも整理されており、工程の切り分け方の考え方は共通しています。

契約と請求の観点で確認すること

遅れが発生したとき、契約書のどこを見るかを知っておくと、判断が速くなります。

見るのは、納期に関する条項、遅延に関する条項、検収の条項、支払いの条項の四つです。

納期の条項では、日付が確定として書かれているか、目標として書かれているかを確認します。前提条件が併記されている場合、その前提が満たされているかも見ます。

遅延の条項では、遅れた場合の取り扱いが書かれているかを確認します。損害の賠償や違約金の定めがある場合、その内容と上限を把握しておきます。

検収の条項では、検収の期限を確認します。納品が遅れた場合でも、検収の期限は納品日を起点に進みます。

支払いの条項では、支払期日の起点がどこにあるかを確認します。成果物を受け取った日を起点に定められている必要があり、期限のない検収に紐づいた条件は、実質的に期日が存在しない状態になります。

条項の解釈に迷う場合や、遅れを理由に契約の内容と異なる要求を受けた場合は、自己判断で応じる前に弁護士に相談してください。感情的なやり取りに入る前に、書かれている条件を確認することが、結果として最も早い解決につながります。

相手が日付の維持しか認めないとき

事情を説明しても「とにかく間に合わせてほしい」としか返ってこない場合があります。この状況で必要なのは、説得ではなく、選択の可視化です。

日付を守る場合に何が起きるかを、具体的に書いて示します。確認していない項目が残る。不具合が出た場合、修正版がユーザーに届くまでに審査の時間が必要になる。リリース後の対応工数が増える。

そのうえで、日付を守る判断をするなら、確認していない範囲を明記した文書を残します。「◯日のリリースにあたり、以下の項目は確認が完了していません」という一覧です。この文書があると、後から不具合が出たときの責任の所在が明確になります。

多くの場合、この一覧を見た段階で相手の判断は変わります。変わらない場合でも、記録が残っていれば守るべきものは守れます。判断そのものは相手のものであり、受ける側の役割は、判断に必要な情報を揃えることです。

次の案件に効く予防

遅れの経験は、次の見積もりに反映してはじめて意味を持ちます。

反映すべきなのは、作業の見積もり時間ではありません。作業以外の時間です。確認の待ち時間、審査の期間、実機での確認、リジェクト時の再提出。これらを工程として最初から書いておきます。

見積もりに「確認待ちの期間」が書かれていると、相手も自分の作業として認識します。書かれていなければ、相手にとって確認は「いつでもできること」になります。

また、契約の段階で日程の前提条件を書いておく方法もあります。「本日程は、確認事項へのご回答を◯営業日以内にいただけることを前提としています」という一文です。前提が崩れたときに日程が動くことを、着手前に合意しておく形になります。

長く続けるためには、技術の維持と運用まで含めた提案ができることも効きます。運用に関わる基礎知識を体系的に示す手段としては、CCNA（シスコ技術者認定）のような認定が、保守や監視まで含めた計画の説得力を補います。

週次の報告を型にしておく

遅れの一報が重くなるのは、それまでの報告が薄いからです。毎週同じ形で状況を出していれば、遅れの連絡は「いつもの報告の続き」になります。型を決めておくと、書く側の負担も小さくなります。

4つの区分で書く

報告は、完了したこと、進行中のこと、止まっていること、判断を待っていることの4つに分けて書きます。区分を毎回同じにするのが要点です。順番も見出しも変えません。同じ形が並ぶと、相手は前回との差だけを読めるようになります。

止まっていることの欄は、書くものがない週でも「なし」と書いて残します。この欄が普段から埋まっていない報告では、初めて何かが書かれた週に、相手は事故が起きたと受け取ります。毎回ある欄なら、書かれていても落ち着いて読まれます。

数字で書ける項目を1つ置く

文章だけの報告は、進み具合の比較ができません。残っている画面の数、確認が終わった項目の数、未確定のまま残っている項目の数。どれか1つでよいので、毎週同じ数え方で書きます。数字が2週続けて動いていなければ、その時点で相談の材料になります。

数え方は途中で変えません。変えると比較ができなくなり、報告そのものの信頼が落ちます。数え方を変える必要が出たときは、変えることと理由を明記したうえで切り替えます。

相手の作業も同じ表に書く

報告に書くのは自分の作業だけではありません。相手側で必要な作業と、その期限も同じ表に置きます。素材の提供、文言の確定、審査に使うアカウントの準備、社内の承認。これらが遅れると日程が動くという関係を、毎週見える形にしておきます。

自分の作業だけを報告していると、遅れが出たときに原因の説明が後出しになります。最初から同じ表に並べていれば、どこで止まったかは説明する前に共有されています。

日程の前提条件を先に文章にする

再発を防ぐ手立てのうち、最も効くのが前提条件の明文化です。日付だけを約束すると、条件が崩れても日付だけが残ります。

書く内容は難しくありません。確認事項への回答をいただく日数の目安、素材を受け取る期限、審査に要する期間の見込み、確認に使う機種とOSのバージョン。この4つを日程の欄に添えます。

そのうえで、前提が崩れたときにどうなるかを一行で書きます。「ご回答が期限を過ぎた場合、超過した日数に応じて以降の日程を見直します」という形です。この一行があると、遅れの連絡が交渉ではなく、着手前に合意した手順の実行になります。

前提条件を書くことに抵抗を感じる場合もありますが、依頼する側にとっても利点があります。自分たちが何をいつまでにやれば日付が守られるのかが、着手の時点で分かるためです。条件が書かれていない日程は、相手にとっても管理できない日程になります。

遅れを伝えたあとに何をするか

一報を出して終わりにすると、相手の不安は残ったままになります。伝えたあとの動き方まで決めておきます。

判断をもらったら、その日のうちに新しい日程を文字で返します。口頭の会議で決まった内容も、同じ日に文書にして送ります。決まった内容を文書にする役目は、受ける側が引き受けるほうが早く終わります。相手が社内で共有する資料も、その文書がそのまま使われます。

そのうえで、次の報告の日を指定します。遅れが出た直後は、報告の間隔を短くします。週に一度だった報告を、立て直しの期間だけ週に二度にする形です。間隔を短くすると、進んでいることが伝わり、相手からの問い合わせが減ります。作業の手が止まらないという点でも、こちらに利があります。

新しい日程で進めている間に、さらに条件が変わることもあります。そのときも同じ手順を繰り返します。事実を確定し、原因を分類し、影響を特定し、選択肢を添えて伝える。二度目の連絡が一度目と同じ形で来ることが、相手にとっては安心の材料になります。形が毎回変わる連絡は、内容が正しくても不安を残します。

立て直しが終わったら、経緯を短くまとめて手元に残します。何が原因で、どの時点で気づけたはずで、次はどこに余裕を置くか。この記録がないと、同じ案件の種類で同じ遅れを繰り返します。記録は相手に見せるものではなく、次の見積もりに使う自分の材料です。

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

在宅とフリーランスの仕事の市場を20年見てきた運営者の立場から言えば、納期を一度も遅らせたことがない人はほとんどいません。差が出るのは、遅れたかどうかではなく、遅れをどう扱ったかです。

継続して依頼を受けている人に共通しているのは、遅れの連絡が早いことです。確度が下がった段階で一報を入れ、選択肢を添える。この動きをしている人は、遅れたあとも同じ相手から依頼を受けています。逆に、期日の直前まで報告せず、当日に「間に合いませんでした」と伝える人は、その案件が完了しても次がありません。

もう一つ、長く続く人は、遅れの原因を相手のせいにしません。相手側の要因があっても、それを主張するのではなく、事実の記録として残しておく。そのうえで、次の案件では前提条件を契約に書く。この対処の仕方が、結果として同じ問題の再発を防いでいます。

仲介の手数料が乗らない直接の取引では、依頼する側は同じ予算でより多くを頼めて、受ける側は手取りが厚くなります。手数料0%という条件が効くのは金額そのものよりも、その余白を「余裕のある日程を組む」ことに使える点です。値切られた分を無理な日程で埋める必要がなくなれば、遅れそのものが起きにくくなります。

海外の依頼者と仕事をする場合は、時差と休日の違いで確認の往復に日数がかかります。日程の前提条件をどう書くかは、Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法でも、契約前の確認事項として整理されています。

よくある質問

Q. 納期に間に合わないと分かったら、いつ伝えるべきですか？

遅れが確定した時点ではなく、間に合う確度が下がった時点です。挽回できるかもしれないと考えている間に日数が過ぎ、相手が選べる選択肢が減ります。早い段階なら、機能を分けて先に出す、日付を動かす、体制を増やすといった判断が可能ですが、前日の連絡ではどれも選べません。早さは誠実さより実務的な価値があります。

Q. 一報にはどこまで原因を書くべきですか？

相手の判断に影響する情報だけを書きます。審査に想定より時間がかかっている、外部の連携先の申請が下りていないといった内容は書きます。他の案件が立て込んでいたといった事情は、相手の判断を変えないため書きません。原因の説明が選択肢の説明より長くなると、言い訳として受け取られます。

Q. 相手の回答が来ないせいで遅れている場合はどうしますか？

待ちが発生したその日に記録し、影響を伝えます。責任の所在を主張するのではなく、「この項目の回答をいただいた時点から何日で完了します。何日以降になるとリリース日に影響します」と、事実と条件で書きます。二週間待ったあとで伝えると、その期間は自分側の遅れとして扱われてしまいます。

Q. モバイルアプリで特に遅れやすい工程はどこですか？

開発そのものより、最後の工程です。iOSとAndroidの二重の確認、ストアの審査、外部サービスの申請、OS更新への追従が代表的です。審査は自分の努力では短縮できず、リジェクトされれば再提出の時間が必要になります。計画には審査に出す日ではなく、審査を通す日を書き、一度のリジェクトを吸収できる余裕を置きます。

Q. 日付を動かしたあとの計画はどう作りますか？

前より細かい粒度で作り直します。残作業を項目に分解して日数を置き、相手の作業として必要なことを明記し、審査に出す日と通す日を分けて書きます。途中に進み具合を確認する日も設定します。一度遅れた案件で余裕のない計画を出すと、同じ理由で再び遅れるため、余裕を含めることが誠実な対応になります。