モバイルアプリ開発の修正を何回まで受けるか｜先に決めておく

モバイルアプリ開発の修正対応で消耗する原因は、技術力でも相手の人柄でもありません。ほとんどの場合、「どこまでが修正で、どこからが追加の仕事か」を着手前に文章にしていないことが原因です。受注のときに決めておけば5分で終わる話が、納品直前になると立場の弱いほうが飲み込むしかない話に変わります。この記事では、モバイルアプリ開発の受注後に修正対応をどう設計するか、決め方の順番と書き方を具体的にまとめます。受託の現場で実際に揉める箇所は限られており、あらかじめ言葉の定義と回数の配分、記録の残し方を決めておくだけで、その大半は起こらなくなります。読み終えたときに、次の見積書へそのまま書き写せる文言が手元に残る状態を目標にしています。

修正の回数を決めないまま受注すると何が起きるか

受託でモバイルアプリを作るとき、多くの見積書には「修正対応込み」とだけ書かれています。この一行が、あとで最も高くつきます。

依頼の性質は途中から静かに変わる

開発の序盤に来る修正依頼は、たいてい本物の不具合です。ボタンを押しても画面が進まない、入力した文字が保存されない。これは直すべきものであり、直して当然のものです。

ところが中盤を過ぎると、依頼の言葉づかいは似たまま中身が変わります。「ここ、もう少し余白がほしい」「一覧の並び順を変えたい」「やっぱりログインは後からでも使えるようにしたい」。発注側からするとどれも同じ「修正」ですが、作る側から見れば最初のものは不具合対応、次はデザイン調整、最後は仕様変更です。かかる時間は10倍以上違うこともあります。

この変化は悪意から起きるものではありません。動くものを見た人が、はじめて具体的に考えられるようになるという、ごく自然な現象です。だからこそ、性質が変わることを前提に線を引いておく必要があります。

無制限の修正が始まる入り口

回数が決まっていない案件は、次のような入り口から崩れていきます。

一つ目は、口頭やチャットの流れで「ついでにこれもお願いできますか」と依頼が届き、その場で「はい」と答えてしまう形です。一件ずつは小さくても、積み上がると新機能ひとつ分の工数になります。

二つ目は、社内の別の人が途中から会議に加わる形です。決裁者が変わると評価の軸も変わり、それまで合意していた画面が最初から議論しなおしになります。

三つ目は、リリース日だけが先に決まっていて、内容の合意が曖昧なまま進む形です。日付を守ることが最優先になるため、作る側が「今回は飲み込みます」を繰り返す構造になります。

モバイルアプリの修正が他の受託と違う三つの理由

Webサイトの制作と同じ感覚で修正回数を見積もると、必ず足りなくなります。モバイルアプリには固有の増幅要因があります。

プラットフォームが二つあると修正も二重になる

iOSとAndroidの両方に対応する案件では、一件の修正依頼が実質二件の作業になります。クロスプラットフォームのフレームワークを使っていても、レイアウトの崩れ方、キーボードの挙動、戻る操作の扱いはプラットフォームごとに違うため、片方で直したものがもう片方で崩れる確認作業が毎回発生します。

この点は、開発の現場でも繰り返し指摘されています。

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

共通化できる部分が多いフレームワークを選んでも、プラットフォームの差を吸収する作業そのものは消えません。見積もりの段階で、修正一件あたりの作業を「片方だけ」で数えないことが基本になります。

ストアの審査が外部要因として挟まる

Webの案件なら、直したものはその場で反映できます。アプリは違います。修正を反映するには、ビルドを作り、ストアに提出し、審査を通す必要があります。審査は自分の努力では短縮できません。リジェクトされれば、内容によっては仕様そのものを見直すことになります。

つまりモバイルアプリの修正には、自分の作業時間とは別に、待ち時間と審査対応という不確定要素が乗ります。「何回まで」という回数の合意には、この待ち時間を誰が負担するかも含めておく必要があります。

実機の差で「直っていない」が生まれる

手元では直っているのに、依頼者の端末では直っていないように見えることがあります。OSのバージョン、画面の大きさ、文字サイズの設定、通信環境。これらの違いが、同じアプリを別物のように見せます。

このとき起きるのは、本来なら追加の調査であるものが「修正の再依頼」として扱われる事態です。回数の合意をするときは、再現しない不具合の調査をどう数えるかも決めておくと、後戻りが減ります。

回数を決める前に、修正の定義をそろえる

「修正3回まで」とだけ書いた見積書は、ほとんど機能しません。何を1回と数えるかが決まっていないからです。回数より先に、言葉の定義を決めます。

不具合の修正と仕様変更を分ける

最初に分けるべきは次の二つです。

不具合の修正とは、合意した仕様どおりに動いていない状態を、仕様どおりに戻す作業です。これは本来、回数を数える対象ではありません。作る側の責任範囲であり、無償で直すのが原則です。

仕様変更とは、合意した仕様そのものを変える作業です。画面を増やす、項目を足す、処理の順番を変える。これは新しい依頼であり、工数と納期を再見積もりする対象です。

この二つを混ぜたまま「修正3回まで」と書くと、不具合対応で回数を使い切ってしまい、本当に必要な変更ができなくなります。

デザインの調整はどちらに入るか

判断が分かれるのがデザインです。ここは事前に決め方の基準を作っておきます。

合意済みのデザインデータどおりに実装されていないなら、不具合の修正です。デザインデータ自体を変えたいなら、仕様変更です。デザインデータを作っていない、または画面の一部しか用意していない状態で着手すると、この判定ができなくなります。着手前に、どの画面のどの状態までデザインが確定しているかを一覧にしておくと、後の議論がほぼ消えます。

「軽微な修正」という言葉を契約書に書かない

現場でいちばん揉める言葉が「軽微」です。依頼する側は「文言を一つ変えるだけ」と考え、受ける側は「その文言が入る箇所は全画面にある」と知っています。軽微かどうかは、作る側にしか判断できません。

契約書や見積書には、軽微という主観的な言葉ではなく、「文言の変更」「色の変更」「画面遷移の追加」のように、作業の種類で書きます。種類で書けば、どの箱に入る依頼なのかを双方で確認できます。

回数の決め方は「工程ごとに配る」

総量として「修正3回まで」と決めるより、工程を区切って配分するほうが実務では機能します。

工程を区切って各工程に割り当てる

たとえば次のように区切ります。

デザイン確定の工程で修正2回まで。実装後の動作確認の工程で修正2回まで。ストア提出前の最終確認で修正1回まで。

工程ごとに配ると、前の工程の合意が次の工程に効くようになります。デザインを確定させてから実装に入る流れが自然にでき、実装後にデザインを議論しなおす事態が減ります。総量だけを決めると、依頼者は最後まで回数を温存しようとするため、かえって終盤に集中します。

回数ではなく期間で区切る方法

依頼者側に複数の関係者がいて、意見をまとめるのに時間がかかる案件では、回数より期間のほうが運用しやすいことがあります。

「納品日から14日間は修正依頼を受け付ける。期間内であれば回数は問わない。期間を過ぎた依頼は別途見積もり」という決め方です。作る側は終わりの日付が読めるようになり、依頼者側は意見を集める猶予を得られます。ただし期間中に無限の依頼が来ないよう、対象範囲は仕様変更を除くと明記します。

使い切ったあとの扱いを先に書く

回数でも期間でも、超えた場合の扱いを同じ文書に書きます。書き方は単純で構いません。「規定回数を超える修正は、内容を確認のうえ追加のお見積もりとします」。この一文があるかないかで、超過が起きたときの会話がまったく違うものになります。

先に書いておけば、それは事前の合意にもとづく事務連絡になります。書いていなければ、途中で条件を変える交渉になります。同じ内容でも、相手の受け取り方は大きく変わります。

見積書と契約書への落とし込み

決めたことは、必ず相手が読める形で残します。

見積書に書く項目

見積書には、金額の内訳のほかに次を入れます。

修正対応の範囲。何回まで、またはいつまでか。1回の数え方。不具合修正は回数に含まないこと。仕様変更の扱い。超過分の考え方。検収の期限。

金額の欄だけで構成された見積書は、条件の合意書としては機能しません。金額は同じでも、条件が書いてある見積書は後で自分を守ります。

業務委託契約書で確認する条項

契約書では、検収、契約不適合責任、再委託、知的財産権の四つを最低限見ます。修正対応に直接効くのは検収と契約不適合責任です。

検収の条項では、検収の期限と、期限までに連絡がない場合にどう扱うかを確認します。期限の定めがないと、いつまでも検収が完了せず、支払いも修正対応も終わりません。

契約不適合責任の条項では、期間を確認します。期間の定めがないまま「不具合は無償で対応する」とだけ書かれていると、何年先でも無償対応の義務が残ると読まれかねません。

なお、発注者には取引条件を書面や電子メールなどで明示する義務があります。条件が曖昧なまま作業を始めるよう求められた場合、それ自体が確認すべき兆候です。契約条件の判断に迷う場合は、弁護士や、契約書のチェックを扱う専門家に相談してください。

書面がないまま着手しない

急ぎの案件ほど「詳細は後で詰めましょう」と言われます。この状態で着手すると、修正対応の条件を持ち出すタイミングが永久に来ません。最低限、見積書に条件を書いて相手の承諾のメールをもらう。この一往復だけで、後の消耗の大半は防げます。

開発の受注全体でどのような契約形態や工程があるかを整理したい場合は、アプリケーション開発のお仕事で、案件の進み方や求められる関わり方を確認しておくと、条件を詰めるときの土台になります。

着手後の運用

決めた条件は、運用しなければ意味がありません。

依頼の受け口を一本にする

チャット、メール、電話、会議中の口頭。受け口が複数あると、依頼を数えることができません。数えられないものは管理できません。

受け口は一つに決めます。ツールは何でも構いません。決めるべきなのは「ここに書かれたものだけを依頼として扱う」という運用です。会議で出た話も、その場で終わらせず、同じ場所に書き起こしてから着手します。この一手間が、後の「言った言わない」をほぼ消します。

消費した回数を共有する

回数を決めたなら、いま何回目かを相手にも見えるようにします。修正の対応が終わるたびに、「今回で2回目です。残り1回です」と伝えるだけです。

これを言わずに黙って対応していると、超過したときに突然の値上げに見えます。毎回伝えていれば、相手も残りを意識して依頼の優先順位を考えるようになります。回数の管理は、請求のためではなく、相手に優先順位をつけてもらうための道具です。

数えない修正を決めておく

すべてを厳密に数えると、関係がぎくしゃくします。数えないものも先に決めておきます。

誤字の修正、明らかな不具合、こちらの実装ミスに起因するもの。これらは回数に含めないと宣言しておくと、線引きが「相手を縛るため」ではなく「両方が判断できるようにするため」のものになります。

検収とリリース後の切り分け

検収基準を文章にする

検収基準がない案件では、修正はいつまでも終わりません。基準は難しく書く必要はなく、「合意した画面一覧のすべてが、指定した端末とOSバージョンで、記載どおりに動作すること」で足ります。

重要なのは、確認する端末とOSのバージョンを具体的に決めておくことです。ここが決まっていないと、依頼者が持っている古い端末で偶然起きた事象が、いつまでも未完了の理由になります。

検収後の修正の扱い

検収が完了したら、そこから先は保守の領域です。検収前と同じ条件で無償対応を続けると、案件はいつまでも終わりません。

検収完了の連絡をもらう。もらったら、その旨を明記して次の段階に移る。この区切りを毎回作ることが、次の案件を受ける余力を残す条件になります。

リリース後の修正と保守

アプリは公開してからのほうが長く続きます。OSは毎年更新され、使っているライブラリも更新されます。放置すればいずれビルドが通らなくなり、ストアの要件を満たさなくなります。

この領域は開発の契約とは分けて、保守として別に合意します。含める範囲は、OS更新への追従、ストアの要件変更への対応、証明書やアカウントの更新、不具合の調査。これらを月単位や年単位で契約する形が一般的です。開発の契約に混ぜてしまうと、納品後も終わらない案件になります。

技術の維持そのものが仕事の質を左右する領域であるため、ネットワークやセキュリティの基礎知識を体系的に持っておくことも効きます。運用に関わる基礎を証明する資格としては、CCNA（シスコ技術者認定）のような認定が、保守を含む提案の説得力を補強します。

見積書と連絡文に書き込む文言

決めた内容を実際にどう書くかまで用意しておくと、条件を伝えるときの手間がなくなります。硬い契約文ではなく、進め方の説明として自然に読める形にしておきます。

修正の扱いは、4つの文で足ります。「合意した仕様どおりに動作していない箇所は、回数に含めず修正いたします」「デザインや表示の調整は、工程ごとに規定の回数を目安にお願いしております」「画面や項目の追加、処理の順序の変更にあたるご希望は、内容を確認のうえ追加のお見積もりとします」「規定の回数を超えるご依頼も、同様に追加のお見積もりとします」。

依頼の出し方については、「ご依頼は指定の場所にご記入ください。そちらに記載されたものを正式なご依頼として扱います」と書きます。会議で出た話も、その場で着手せず、同じ場所に書き起こしてから作業に入る運用にします。

確認の環境については、「動作の確認は、指定の機種とOSのバージョンで実施いたします」と明記し、対象の一覧を添えます。この一文がないと、依頼者の手元にある古い機種で偶然起きた事象が、いつまでも完了しない理由として残ります。

検収については、「納品のご連絡から指定の日数以内にご確認をお願いいたします。期間内にご連絡がない場合は、検収完了として扱います」と書きます。期限のない検収は、支払いも修正の終わりも決まらない状態を作ります。

これらの文言は案件ごとに書き直す必要はありません。一度作って手元に置き、工程の区切り方と回数、確認の対象になる機種の一覧だけを案件ごとに差し替えます。

確認する環境を毎回そろえる

回数の合意があっても、確認する環境がずれていると、同じ依頼が何度も往復します。環境をそろえる手順を運用に入れておきます。

まず、配布するビルドに番号を振ります。どのビルドで確認した結果なのかが分からないと、直したはずの箇所を「直っていない」と報告されます。番号が振ってあれば、古いビルドで確認していたと分かった時点で往復が止まります。

次に、不具合の報告に必要な項目を先に決めて渡します。ビルドの番号、機種、OSのバージョン、操作した順番、期待した動きと実際の動き。この5つが書かれていない報告は、再現の作業から始めることになります。報告の形式を先に渡しておけば、依頼者は埋めるだけで済みます。

再現しない事象については、扱いを決めておきます。指定した環境で再現しない報告は、調査そのものを作業として数えるのか、数えないのかを着手前に合意します。調査は目に見える成果が残らないため、数えない運用にすると、その時間が丸ごと計上されないまま積み上がります。

最後に、確認する側の人数も決めておきます。依頼者側で複数の人が別々に触ると、同じ事象が別の言葉で何度も報告されます。報告をまとめる担当を1人決めてもらい、重複を整理したうえで送ってもらう形にすると、件数そのものが減ります。誰が確認するかは、着手前の打ち合わせで聞いておける項目です。

相手が回数の設定を嫌がったとき

条件を提示すると、まれに「窮屈だ」という反応が返ります。この反応そのものは、悪い兆候ではありません。多くの場合、回数を制限されること自体ではなく、「困ったときに助けてもらえないのではないか」という不安が理由です。

伝え方を変えると、たいてい解決します。制限として説明するのではなく、優先順位づけのための仕組みとして説明します。回数を決めることで、限られた時間を本当に必要な変更に使えるようになる。不具合は回数に含めないので、動かないものは何回でも直す。この二点を先に伝えると、多くの依頼者は納得します。

それでも「無制限でなければ発注しない」と言われる場合は、条件が合わない相手だと判断する材料になります。開発以外の領域でも、条件を書面にすることを避ける相手との取引には共通の傾向があります。案件の性質ごとの相場観を掴んでおきたい場合は、ソフトウェア作成者の年収・単価相場で、職種としての位置づけを確認しておくと判断の目安になります。

やり取りの記録の残し方

修正対応の条件は、記録がなければ主張できません。記録の作法は、案件が始まった初日に決めます。

依頼は一件ずつ独立した単位で扱います。チャットに三つの要望が並んで書かれていたら、そのまま返信するのではなく、三件に分けて番号を振り、それぞれに対応の可否と工数の見込みを書いて返します。まとめて「対応します」と答えると、あとで何件分の作業だったのかを説明できなくなります。

対応が完了したときは、完了の連絡に、どの依頼に対応したかの番号と、その結果を書きます。「ご指摘の3点、いずれも修正しました」ではなく、番号ごとに何をどう変えたかを一行ずつ書きます。手間に見えますが、この記録は検収時の確認資料になり、そのまま次回の見積もりの根拠にもなります。

判断が分かれた依頼については、判断の理由も残します。「この依頼は当初の仕様に含まれていないため、追加の見積もりの対象になります」と、その場で書いて送る。後から言うと交渉に見えますが、その場で書けば運用のとおりの処理になります。記録は相手を追い詰めるためのものではなく、双方が同じ前提で会話するための土台です。

記録の量が増えると管理そのものが仕事になりますが、案件の規模に対して過剰な仕組みを入れる必要はありません。依頼に番号がついていて、完了の連絡が番号と紐づいていて、判断の理由が残っている。この三つが揃っていれば、後の説明はほぼ足ります。

そもそも修正依頼を減らす作り方

回数を決めるのは守りの設計です。あわせて、依頼そのものが減る作り方をしておくと、決めた回数を使い切らずに済みます。

動くものを早く見せる

修正が終盤に集中する案件には共通点があります。依頼者が動くものを見るのが遅いことです。仕様書と静止画のデザインだけで合意した内容は、実機で触った瞬間にほぼ必ず変わります。画面の切り替わり方、入力のしやすさ、読み込み中の見え方は、絵では判断できないからです。

対策は単純で、完成度が低い段階でも早く触ってもらうことです。ボタンが押せるだけの試作でも、依頼者の頭の中の想像と実物の差はそこで埋まります。序盤に出た変更は工数が小さく、終盤に出た同じ変更は大きくなります。同じ内容の依頼でも、いつ出るかで費用がまったく違うという事実を、着手時に共有しておくと協力が得やすくなります。

判断する人を最初に確定させる

途中から決裁者が現れる案件は、ほぼ必ず作り直しが起きます。着手前に「最終的にこの画面を承認するのはどなたですか」と一度だけ聞いておきます。窓口の担当者とは別に承認者がいるなら、要所の確認にはその人に入ってもらう段取りを、最初の打ち合わせで決めます。

この確認は失礼にはなりません。むしろ、社内の合意形成を意識している相手として受け取られます。承認者が不在のまま進んだ案件で修正が膨らむのは、担当者の力不足ではなく、進め方の設計が抜けていたためです。

決まっていないことを一覧にする

着手時点で決まっていない項目は、必ずいくつか残ります。ログインの方式、通知の文言、利用規約の掲載場所、問い合わせ先。これらを「未確定」として一覧にし、いつまでに決めてもらう必要があるかの期限を添えて渡します。

未確定の項目は、期限を過ぎると自動的に納期に影響します。この因果を先に示しておくと、遅れが発生したときに責任の押し付け合いになりません。作業が止まっていた期間を記録しておくことも、後の説明を助けます。

受注前に修正が多発する案件を見分ける

条件をどれだけ整えても、構造的に修正が膨らむ案件は存在します。受ける前に見分けられれば、条件を厚めに設定するか、受けないという判断ができます。

判断材料になるのは、まず要望の伝わり方です。実現したいことを、機能ではなく目的の言葉で説明できる相手は、途中の判断が速く、修正も少なくなります。逆に、他社のアプリの画面を見せて「これと同じものを」とだけ伝えてくる場合、目的が言語化されていないため、作ったものを見てから初めて要望が出てきます。

次に、社内の体制です。窓口の担当者が一人で、他部署の意見を集める仕組みがない場合、承認の直前に別の意見が噴出します。関わる部署が多い案件ほど、確認の場を定例で持つ設計にしておく必要があります。

三つ目は、予算と要望の距離です。要望の量に対して予算が明らかに小さい案件では、削る判断が必要になりますが、その判断を作る側に丸投げされる傾向があります。着手前に「今回の予算で入る範囲」と「次の段階に回す範囲」を分けた一覧を作り、合意しておくことで、後から範囲が膨らむのを防げます。

案件の入り口で相手と条件を詰める作業は、開発に限った話ではありません。業務の設計や運用の支援を含む案件では、同じ論点がさらに広い範囲に及びます。関連する仕事の性質はAIコンサル・業務活用支援のお仕事でも整理されており、要件が固まりきらない案件をどう区切るかという考え方は共通しています。

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

在宅とフリーランスの仕事の市場を20年見てきた運営者の立場から言えば、修正対応で疲弊し続ける人と、長く同じ相手と仕事を続ける人の差は、技術の差ではありません。差が出るのは、条件を最初に文章にしているかどうかの一点です。

条件を出すと嫌われるのではないか、と考えて何も言わないまま受けてしまう人は少なくありません。実際に起きているのは逆です。条件が明確な相手のほうが、依頼する側にとっても計画が立てやすく、社内の説明もしやすい。結果として、条件を先に出す人のほうが継続の依頼を受けています。

もう一つ、長く続く人に共通しているのは、回数を「相手を縛る道具」ではなく「一緒に優先順位を決める道具」として使っていることです。残り回数を共有し、どれを先に直すかを相手と一緒に決める。この進め方をしている案件では、そもそも超過が起きにくくなります。

仲介の手数料が乗らない直接の取引では、依頼する側は同じ予算でより多くを頼めて、受ける側は手取りが厚くなります。手数料0%という条件が効いてくるのは、金額そのものよりも、この余白が「条件をきちんと詰める時間」に回せる点にあります。値切られた分を修正対応の飲み込みで埋める必要がなくなるからです。

海外の案件を受ける場合は、契約条件の書き方がさらに重要になります。国内と商習慣が異なる相手とどう条件を詰めるかは、Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法で、契約前の確認事項を含めて整理されています。

よくある質問

Q. 修正は何回までに設定するのが妥当ですか？

総量で決めるより、工程ごとに配分するほうが機能します。デザイン確定で2回、実装後の動作確認で2回、ストア提出前の最終確認で1回といった配り方です。工程ごとに区切ると前の工程の合意が次に効き、終盤に依頼が集中する事態を防げます。回数の妥当性より、1回の数え方を先に定義することのほうが重要です。

Q. 不具合の修正も回数に数えてよいですか？

数えません。合意した仕様どおりに動いていない状態を仕様どおりに戻す作業は、作る側の責任範囲であり、無償で対応するのが原則です。回数を数える対象は仕様変更、つまり合意した仕様そのものを変える依頼です。この二つを混ぜると、不具合対応で回数を使い切り、本当に必要な変更ができなくなります。

Q. 見積書には修正条件をどう書けばよいですか？

金額の内訳とは別に、修正対応の範囲、何回までか、1回の数え方、不具合修正は回数に含めないこと、仕様変更の扱い、超過分の考え方、検収の期限を書きます。とくに「規定回数を超える修正は内容を確認のうえ追加のお見積もりとします」の一文は必ず入れます。書いてあれば事務連絡として扱えますが、なければ途中の条件変更交渉になります。

Q. 相手が回数の設定を嫌がった場合はどうしますか？

多くは制限そのものではなく、困ったときに対応してもらえない不安が理由です。制限としてではなく、限られた時間を本当に必要な変更に使うための優先順位づけの仕組みとして説明し、不具合は回数に含めず何度でも直すと伝えると、たいてい納得が得られます。それでも無制限を条件にされる場合は、条件が合わない相手と判断する材料になります。

Q. リリース後の修正はどこまで対応すべきですか？

開発の契約とは分け、保守として別に合意します。含める範囲はOS更新への追従、ストアの要件変更への対応、証明書やアカウントの更新、不具合の調査などで、月単位や年単位で契約する形が一般的です。開発の契約に混ぜると納品後も終わらない案件になります。検収完了の連絡をもらった時点で区切りを作ることが前提になります。