仕様が後から増えたときの、モバイルアプリ開発でのトラブル対処と線引き

2026年1月26日

朝比奈蒼

この記事のポイント

✓モバイルアプリ開発で仕様が後から増えたときのトラブル対処を
✓線引きの方法から整理しました
✓着手前に決めておく条件

モバイルアプリ開発で最も多いトラブルは何か。結論から言うと、技術的な失敗ではなく「仕様が後から増えたこと」に関する食い違いです。実装が難しくて頓挫する案件より、当初の話になかった機能が次々と足され、どこまでが契約の範囲なのか誰も説明できなくなる案件のほうが、はるかに多く見られます。

そして厄介なのは、この状況が悪意なく発生することです。発注者は追加しているつもりがなく、受注者は追加されていると感じている。この認識のずれが数週間続いた末に、納品と報酬をめぐって関係が壊れます。

この記事では、モバイルアプリ開発で仕様が増えたときのトラブル対処を、線引きの方法を軸に整理します。追加と修正をどう区別するか、増えたときにどう扱うか、着手前に何を決めておけば防げるか、そして実際に報酬が支払われない事態になったときにどうするか。順番に見ていきます。

なぜモバイルアプリ開発では、仕様が増えやすいのか

対処法の前に、構造を理解しておく必要があります。これは個々の発注者の性格の問題ではなく、この分野特有の事情によるものです。

発注側が、開発の全体像を持っていないことが多い

Webサイトの制作と違い、アプリ開発は発注側にとって経験の少ない領域です。何を決めておくべきか自体が分からないまま相談が始まることも珍しくありません。

顧客体験の向上や業務効率化の手段としてモバイルアプリ開発の需要は伸び続ける一方ですが、アプリ開発の知識を誰もが持っているわけではありません。実際に検討をはじめると、開発にかかるコストや期間・要件の決め方・デザイン・開発言語・配信方法・運用保守など、多くの検討が必要なことが、特に技術的な知識を持たないビジネスサイドの方にとって大きな課題となります。出典: ncdc.co.jp

ここで挙げられている検討事項は、本来なら着手前に固めておくものです。しかし現実には、動く画面を見て初めて「こうしたい」が具体化します。つまり、仕様が後から増えるのは異常事態ではなく、この分野では標準的な進み方だということです。

正直なところ、この前提を持たずに「決めたとおりに作れば終わる」と考えて受注すると、ほぼ確実に苦しみます。増えることを前提にした受け方をするほうが現実的です。

準備不足がそのままリスクとして跳ね返る

もう1つ、開発着手前の詰めの甘さが、後の問題に直結するという指摘もあります。

携帯/モバイルアプリ開発における最大の注意点は、iOS・Android両OSに対応させる過程で見落とされがちな「技術的リスク」と「運用上のリスク」を、企画段階で見積もれているかどうかです。モバイルアプリの約30%はリリースから18ヶ月以内にサービス終了しているとされ、失敗の多くは開発着手前の準備不足に起因します。出典: note.com

注目したいのは「失敗の多くは開発着手前の準備不足に起因する」という部分です。仕様が増えること自体は避けられませんが、増えたときの扱い方を着手前に決めておくかどうかで、結果はまったく変わります。

「小さな変更」の積み重ねが最も危険

大きな機能追加は、さすがに発注者も追加だと認識します。問題になるのは、1つずつは数十分で終わるように見える依頼です。

ボタンの位置を変える、文言を修正する、並び順を入れ替える、確認画面を1つ挟む。個別に断る理由がないため受けてしまい、気づくと当初の見積もり工数を大きく超えている。しかも、記録が残っていないので後から説明もできない。これが典型的な崩れ方です。

追加と修正を区別する、実務的な基準

線引きの出発点は、依頼を2種類に分けることです。これができていないと、すべての依頼が同じ扱いになります。

修正は「合意した仕様どおりに動いていない」もの

修正は、こちらの責任範囲です。当初の仕様書やメールで合意した動作と、実際の挙動が違っている場合。これは追加費用の対象にならず、無償で直すのが筋です。

明らかな不具合、たとえば特定の操作でアプリが落ちる、入力した内容が保存されない、といったものもここに入ります。ここを渋ると、信用を一気に失います。

追加は「合意した仕様に書かれていない」もの

一方、当初の合意に含まれていない挙動を求められた場合は追加です。「使ってみたら不便だったので変えたい」は、正当な要望ですが、修正ではありません。

判断が難しいのは、仕様書に書かれていない部分についてです。書いていないから対応不要とも、書いていないから含まれているとも言えます。この曖昧な領域が、トラブルの温床になります。

だからこそ、仕様書に「今回は対応しないこと」を明記しておく価値があります。含めるものを書くより、含めないものを書くほうが、後の線引きははるかに楽になります。

判断がつかないものは、その場で決めずに持ち帰る

会議中に「これくらいできますよね」と聞かれると、断りづらい空気になります。ここで即答すると、後から取り消せません。

対応としては、「範囲に含まれるか確認して、明日までにお返事します」と返すだけで十分です。これは引き延ばしではなく、正当な確認です。その場の空気で決めた約束が、数週間後に自分を追い詰めます。

増えたときに使う、変更管理の手順

区別ができたら、次は運用です。難しい仕組みは要りません。3つの手順で回ります。

手順1：依頼をすべて1か所に記録する

チャットで来た依頼、会議中に出た要望、メールの追伸に書かれていた一文。これらを1つのリストにまとめます。

記録するのは、依頼日、内容、依頼者、そして分類（修正か追加か）の4項目です。この一覧があるだけで、「言った、言わない」の争いはほぼ消えます。

一覧は発注者と共有してください。こちらだけが持っていると、証拠にはなっても合意にはなりません。共有された状態で異議が出なければ、それは事実上の確認になります。

手順2：追加分に、工数と影響を添えて返す

追加と判断したものには、必ず工数と納期への影響を書いて返します。金額を出しにくい段階でも、日数だけは示せるはずです。

「この変更は2日かかるため、公開予定日が2営業日後ろになります。予定日を優先する場合は、別の項目を次回に回す形になります」。この書き方が有効なのは、断っていないからです。やるかやらないかではなく、何を優先するかの相談に変えています。

正直なところ、この一手間を惜しんで安請け合いする人が非常に多い。そして、後から報酬の話を持ち出して揉めます。順番が逆です。

手順3：決まったことを、その都度短く残す

やり取りの結論は、短い文面で残します。長い議事録は要りません。「本日の打ち合わせで、通知機能の追加は次期対応とし、今回は公開までの範囲に含めないことで合意しました」。この2行で十分です。

送る先は、決裁できる立場の人を含めてください。現場の担当者だけと合意していると、上長が入れ替わった瞬間に前提が消えます。実際、担当者の異動をきっかけに「そんな合意は聞いていない」となる例は少なくありません。

着手前に決めておけば、大半は防げる

ここまでの対処は、起きてからの話です。本来は着手前に決めておくほうが、はるかに負担が軽くなります。

条件の明示は、法律上も発注者の義務

2024年11月に施行されたフリーランス保護新法（特定受託事業者に係る取引の適正化等に関する法律）では、発注者が業務を委託する際、業務の内容、報酬の額、支払期日などを書面または電磁的方法で明示することが義務づけられています。口頭やチャットの流れだけで着手させるのは、本来の姿ではありません。

つまり、条件を文面で求めるのは、こちらのわがままではなく制度上の前提だということです。「細かいことを言う人だと思われないか」と気にする方がいますが、気にする必要はありません。むしろ、条件を整理して確認してくる相手のほうが、発注側からは安心して見えます。

なお、発注者の規模や取引の形態によっては、下請取引に関する法律の適用対象になる場合もあります。この領域の基礎はフリーランスを守る「下請法（取適法）」の知識｜発注書・契約書の必須項目チェックリストにまとまっているので、発注書の項目を確認する際の材料になります。※制度は改正されることがあるため、2026年8月時点の内容を前提にせず、最新の情報は公正取引委員会などの公的な情報源で確認してください。

見積書には、前提条件を必ず書く

金額と工数だけを書いた見積書は、後から範囲を主張する根拠になりません。前提条件の欄を作って、そこに範囲を書きます。

書いておきたいのは次の項目です。対応するOSの版、対応する端末の範囲、画面数、外部サービスとの連携の有無、デザインの提供元、テストの範囲、修正対応の回数、今回対応しない事項。

特に「修正対応の回数」は効きます。回数の上限があると、発注者側も要望を整理してから出すようになります。無制限だと、思いつくたびに送られてきます。これは相手を疑う話ではなく、双方の作業を減らすための設計です。

検収の基準を、着手前に決める

何をもって完了とするかが決まっていないと、いつまでも終わりません。「動作すること」という基準は、実質的に基準がないのと同じです。

具体的には、確認する項目の一覧を先に作っておきます。主要な操作の流れが完了すること、指定した端末で表示が崩れないこと、通信が失敗したときに指定の表示が出ること。この一覧に沿って確認し、すべて通れば検収完了とする。ここまで決めておくと、検収が主観の勝負になりません。

アプリの場合、審査を通るかどうかを検収条件に含めるかも論点です。審査の結果はこちらの努力だけでは決まらないため、「ビルドの提出をもって納品完了とし、審査の指摘に伴う修正は別途対応」といった切り方をしておくと、支払いが審査の都合に引きずられません。

追加要望が出やすい場面は、事前に予測できる

仕様が増える場面には、決まったパターンがあります。予測できるなら、その手前で手を打てます。

動く画面を初めて見せたとき

最も要望が集中するのが、最初に実物を触ってもらったタイミングです。それまで文字と図でしか共有されていなかったものが、初めて具体的になるからです。

ここで出てくる要望は、多くの場合まっとうです。実際に触ってみて不便だと分かったなら、直したほうが良いものになります。問題は、この段階の要望をすべて無償の修正として扱ってしまうことです。

対策としては、初回の確認を「意見をもらう場」だと最初から位置づけておくことです。「この回で出た要望は一覧にまとめ、範囲内のものと追加になるものを分けてご連絡します」と先に伝えておく。こう言っておくだけで、後から線引きを持ち出すより角が立ちません。

デザインが後から差し替わるとき

デザインの提供元が発注者側の場合、実装が進んだ後に新しい案が出てくることがあります。見た目の変更は簡単だと思われがちですが、画面構造が変わる変更は実装の作り直しになります。

ここは事前の説明が効きます。「文言や色の変更は軽微ですが、画面の構成そのものが変わる場合は実装をやり直すことになります」と、着手前に一度伝えておく。技術的な事情を知らない相手には、この違いが見えていません。

外部サービスとの連携が絡むとき

決済、地図、認証など、外部のサービスを使う部分は、こちらの都合だけで完結しません。相手側の仕様変更や審査が入ることもあります。

この領域の作業を見積もるときは、こちらが制御できない工程があることを明示しておいてください。「外部サービス側の審査に要する期間は工数に含まれません」と一行あるだけで、遅延の責任の所在が変わります。

ストアの審査から要求が返ってくるとき

審査の指摘によって、当初なかった実装が必要になることがあります。権限の説明を追加する、退会の導線を用意する、購入の扱いを変える、といった対応です。

これは発注者にとっても予期しないものですが、対応しなければ公開できません。だからこそ、着手前に「審査の指摘に伴う対応は別途協議とする」と決めておく価値があります。決めていないと、こちらの見落としと受け取られることがあります。

関係を壊さずに線引きを伝える書き方

線引きの中身が正しくても、伝え方を誤ると関係が悪化します。実務では、この部分の差が大きく出ます。

否定から書き始めない

「それは範囲外です」から始まる文面は、内容が正しくても反発を招きます。相手は要望を拒否されたと受け取り、以降のやり取りが硬くなります。

順番を変えるだけで印象が変わります。まず要望の意図を受け止め、次に実現方法を示し、最後に範囲と工数に触れる。「操作の手数を減らしたいというご意図と理解しました。実現するには確認画面の構成を変更することになり、2日ほど必要です。今回の範囲には含まれていないため、扱いをご相談させてください」。同じことを言っていますが、受け取られ方は別物です。

断るのではなく、順番を提案する

追加要望に対して「できません」と答える場面は、実はそれほど多くありません。多くの場合、できるが今ではない、という話です。

「今回の公開に間に合わせるなら次回に回す形になります」「今回に含めるなら公開を1週間後ろに倒す形になります」。この2択を示すと、判断は発注者に戻ります。こちらが決めるのではなく、材料を渡して選んでもらう。これが最も摩擦の少ない形です。

相手側の事情も想定しておく

追加要望を出してくる担当者にも、社内の事情があります。上長から指摘された、他部署から要望が来た、競合のアプリを見て焦っている。こうした背景があると、担当者自身も断れない立場にいます。

この前提で見ると、対立の構図が変わります。担当者を説得するのではなく、担当者が社内で説明できる材料を渡すという発想になります。工数と影響を書いた一覧は、そのまま社内資料として使えます。実際、この形で渡すと話が早く進むことが多いです。

正直なところ、ここまで踏み込む必要はないと感じる方もいると思います。ただ、継続的に依頼を受けている人は、ほぼ例外なくこの視点を持っています。技術の提供者ではなく、進行の管理まで担える相手として見られるからです。

記録は、争うためではなく共有するために残す

依頼の一覧や合意の確認を残すことを、対立の準備のように感じる方がいます。ただ、実際に効いているのは、揉めた後ではなく揉める前の場面です。

一覧が共有されていると、発注者側も自分たちが何を頼んだかを把握できます。社内で要望が重複していたり、優先度の低いものが混ざっていたりすることに、相手自身が気づきます。結果として、要望の総量が自然に減ることも珍しくありません。

つまり記録は、証拠であると同時に、双方の認識を揃える道具です。この位置づけで運用すると、共有を求めるときの心理的な負担も軽くなります。

途中で条件を変える必要が出たときも、同じ手順で扱う

線引きは、こちら側の都合が変わったときにも使います。想定より実装が難しいことが判明した、体調や他の案件の都合で日程が厳しくなった。こうした場合も、黙って遅らせるのが最悪の対応です。

分かった時点で、現状と見通しを文面で共有してください。遅れの連絡は、早いほど受け入れられ、遅いほど問題になります。これは相手が追加要望を出す場面と、構造としてはまったく同じです。条件が変わったら、その時点で共有して合意を取り直す。この一貫性がある人は、トラブルの局面でも信用を保てます。

支払いが止まった場合の対処

線引きをしていても、こじれることはあります。その場合の順序を整理しておきます。

まず、事実関係を時系列で並べる

感情的なやり取りに入る前に、記録を整理します。契約または条件が示された日、着手日、納品日、検収の連絡、支払期日、督促した日。これを時系列にするだけで、どこに問題があるかが明確になります。

この作業は、後で誰かに相談するときにも必要になります。相談を受ける側が最初に求めるのは、この時系列だからです。

支払期日の考え方を確認する

同法では、発注者は成果物を受領した日から起算して60日以内のできる限り短い期間内に支払期日を定め、その日までに報酬を支払う義務があるとされています。「検収が終わらないから支払わない」という状態が無制限に許されるわけではありません。

また、あらかじめ定めた報酬を後から一方的に減額することや、受注者の責任がないのにやり直しをさせることについても、禁止される行為として整理されています。仕様の追加を無償で押し込まれている状況は、この観点から問題になる可能性があります。

段階を踏んで対応する

いきなり法的手続きに進むのは現実的ではありません。順番があります。

最初は、事実を淡々と書いた督促のメールです。感情を書かず、契約内容、納品日、支払期日、未入金の事実だけを並べます。この段階で解決する例は少なくありません。

次が、内容証明郵便による請求です。ここまで来ると、相手の対応が変わることがあります。

それでも解決しない場合は、公的な相談窓口や弁護士への相談に進みます。少額の案件では費用が見合わないこともあるため、実際にかかる費用の目安を知ってから判断するのが現実的です。未払い報酬を回収する！弁護士の着手金・成功報酬と支払督促の流れ【2026年最新】に手続きの流れと費用感がまとまっているので、判断材料になります。

途中で止める場合の扱いも決めておく

関係が続けられないと判断した場合、途中で終了させる選択もあります。このとき問題になるのが、それまでの作業分の扱いです。

契約書に中途解約の条項があるかを確認してください。ない場合は、着手済みの工程に応じた精算を提案する形になります。ここでも記録が効きます。どの機能がどこまで完成しているかを一覧にして示せると、交渉が進みます。

なお、途中で止める場合でも、預かっている資料やアカウントの返却は速やかに行ってください。ここを人質のように扱うと、こちらの立場が悪くなります。

線引きができる人が、結果的に継続を得ている

フリーランスと在宅ワークの市場を20年運営してきた立場から見ていると、興味深い傾向があります。仕様の追加を何でも受け入れる人より、線引きを明確にする人のほうが、同じ発注者から繰り返し依頼を受けています。

理由は明快です。線引きが明確な相手は、発注者にとって予算と日程が読めるからです。何でも受ける相手は一見ありがたいものの、いつ終わるのか、いくらになるのかが読めません。社内で予算を通す立場の人にとって、これは扱いにくい状況です。

もう1つ、運営者として見てきた限りでは、中間マージンが乗らない直接取引のほうが、この種の食い違いが起きにくい傾向があります。間に立つ担当者を経由して仕様が伝わると、意図が薄れ、誰が決めたのかも曖昧になります。直接やり取りできる関係では、追加が出た時点でその場で判断でき、記録も1本にまとまります。手数料0%という条件は、金額の話にとどまらず、同じ予算の中で発注者はより多く頼め、受け手は手取りが厚くなるという意味を持ちます。その厚みがあるぶん、小さな追加を丁寧に扱う余裕も生まれます。

一方で、直接取引では条件を詰める責任も自分に来ます。だからこそ、ここまで挙げた見積書の前提条件や検収基準を、自分で用意できるかどうかが分かれ目になります。

実務の教訓は、経験者の記録から拾える

線引きの技術は、失敗から学ぶより、他者の記録から先に学ぶほうが早く身につきます。開発の現場で得られた教訓は、公開されているものも多くあります。

今回の記事では、React Nativeでのモバイルアプリ開発において、私が経験から得た「気づき・教訓」や「知っておきたかったこと」を共有しました。出典: fintan.jp

こうした記録に共通しているのは、技術的な失敗より、前提の確認不足に関する反省が多いという点です。使う技術の制約を知らないまま約束してしまい、後から実現できないと分かる。これも仕様のトラブルの一種です。

依頼がどういう形で出てくるかを事前に知っておくと、前提の確認漏れが減ります。開発分野の依頼の出方はアプリケーション開発のお仕事に、業務改善やAI活用と絡む相談の背景はAIコンサル・業務活用支援のお仕事にまとまっています。発注者が何を解決したくて依頼しているのかを掴んでおくと、追加要望が出たときにも意図を読み違えません。

見積もりの妥当性を判断するには、報酬の水準を知っておく必要もあります。職種ごとの分布はソフトウェア作成者の年収・単価相場で確認できます。相場を把握しないまま追加対応を積み重ねると、実質的な時間単価がどこまで下がっているかに気づけません。

そして、ここまで書いてきた手順のほとんどは、文書を書く作業です。依頼の一覧、変更の通知、合意の確認、督促の文面。これらが読みやすく正確であるかどうかが、そのまま交渉力になります。文書作成の基礎を確認する枠組みとしてはビジネス文書検定があります。開発者が軽視しがちな領域ですが、トラブルの場面で最も効く技術です。

仕様が増えること自体は、止められません。止められるのは、増えたものが記録されないまま流れていくことのほうです。増えた瞬間に一覧へ足し、工数を添えて返す。この習慣がある人は、同じ状況に置かれても揉めずに終わります。