モバイルアプリ開発委託— 書面・台帳運用

1. 仕様変更の捕捉

1-1. 変更依頼のチャネル統一

チャット・メール・口頭が混在すると、何が合意されたか後から追えません。
変更依頼はチケットまたは変更依頼書に一本化し、発注記録にリンクします。

1-2. 影響見積もりと承認

工数・納期への影響が出る変更は、見積もり提示後に発注者が承認してから着手します。
承認前の作業は、無償範囲か追加発注かを事前に決めます。

1-3. ストア審査対応の位置づけ

リジェクト対応が当初見積もりに含まれるかは契約で明記します。
審査対応を無償とみなすか、追加費用とするかでトラブルが分かれます。

2. 書面と記載事項

2-1. 初回発注書面の必須項目

業務内容・報酬・支払期日・検収条件を、取引開始前に書面で示します。
記載事項のテンプレートと発注書面の3条書面を併用すると漏れが減ります。

2-2. 変更のたびに足す書面

大幅な仕様追加には変更契約または追加発注書を交付します。
軽微な変更でも、チケットに報酬影響なし・ありをタグ付けします。

2-3. 口頭依頼の追完

緊急の口頭依頼は、48時間以内に書面または記録で追認するルールを社内に置きます。
追完されない変更は、検収・支払の対象外とする方針も選択肢です。

3. 検収とストアリリース

3-1. テスト完了とストア公開

社内テスト完了時点を検収とするか、ストア公開後を検収とするかを契約に書きます。
検収基準の設計は検収基準の決め方を参照してください。

3-2. iOS / Android 別マイルストーン

プラットフォームごとに納期・報酬を分ける場合、台帳も分けて管理します。
片方だけ遅延したときの支払いを、契約で明確にします。

3-3. ソース・証明書の納品

Apple Developer 等の証明書・キーストアの引き渡しも納品物に含めます。
受領日は、リポジトリ譲渡日かストア公開日かを事前に定めます。

4. 台帳運用の実務

4-1. 変更履歴のバージョン管理

要件定義の版番号と、発注書面の版番号を対応づけます。
どの版に対する給付かが分かると、検収争いが減ります。

4-2. 支払と変更の紐づけ

スプリント請求に含まれる変更範囲を、請求書の明細に書きます。
支払期日は検収基準の決め方のとおり受領日起算で管理します。

4-3. 担当者交代時の引き継ぎ

PM 交代時に、未反映の口頭依頼・未承認変更を洗い出します。
台帳のステータス（検収済・保留・追加見積中）を共有します。

5. 実務シナリオと社内運用

5-1. 口頭依頼が増えたときの追完

現場のスピード優先で口頭・チャット依頼が増えたら、48時間以内の書面追認ルールを徹底します。
追認されない依頼は検収・支払の対象外とする方針を、取引先にも事前に共有しておきます。
発注全体の流れは記載事項のテンプレートで定期的に見直します。

5-2. 担当者交代時の引き継ぎ

発注担当・経理・法務が交代するタイミングで、未検収・保留・追加見積中の案件一覧を引き継ぎ資料に含めます。
受領日が空欄の取引先を優先的に洗い出し、埋め漏れを解消してから引き継ぎを完了します。

5-3. 四半期ごとの台帳レビュー

四半期に一度、取引先ごとの支払遅延・検収遅延・書面未交付の有無をレビューします。
支払期日の計算ルールは検収基準の決め方に統一し、例外運用を増やしすぎないようにします。
記載事項のテンプレートは発注書面の3条書面を最新版に更新し、新規発注から適用します。

よくある質問

Q. 軽微な UI 変更も都度書面が必要ですか

契約で無償修正回数内と定めた範囲は書面不要な場合もあります。
範囲を超える変更は追加合意が安全です。

Q. βテスト期間のバグは無償ですか

契約の瑕疵担保・保守範囲の定義次第です。
β期間の不具合対応をどこまで含むか事前に書きます。

Q. Flutter などクロスプラットフォームは1件の検収でよいですか

納品単位の定義次第です。
ストア別の審査結果が異なる場合は、分けて検収する設計もあります。

Q. 既存アプリのリプレイス案件は

移行対象機能の一覧と、移行完了の定義を書面にします。
レガシーとの並行運用期間の扱いも合意します。

Q. デザインのみ外注で実装は内製の場合

デザインデータの受領日を検収起点にし、実装は別管理します。
デザイン修正の回数上限を契約に書きます。

まとめ

• 変更依頼はチャネル統一し、影響見積もり後に承認する
• 初回書面に加え、大幅変更は追加発注で記録する
• テスト完了とストア公開のどちらを検収とするか明確化する
• 版番号・受領日・支払を台帳で一貫管理する

6. モバイルアプリ開発委託の発注前チェックリスト

• 変更依頼の受付チャネルを一本化したか
• ストア審査リジェクト対応が見積もりに含まれるか明記したか
• テスト完了とストア公開のどちらを検収とするか決めたか
• iOS/Android 別の納期・報酬を分ける必要があるか確認したか
• ソース・証明書の納品形式を契約に書いたか

仕様変更が口頭だけで進むと、検収時にスコープ争いになります。
緊急の口頭依頼は48時間以内に書面追認するルールを徹底してください。
要件定義の版番号と発注書面の版を対応づけると、後からの説明が楽になります。

7. 現場で起きやすい落とし穴

7-1. OS メジャーアップデート対応

新しい iOS が出るたびに動作確認が必要になる場合、保守契約に含めるか開発契約に含めるかを分けます。
含めない場合は、都度の追加発注として見積もり・承認を取ります。

7-2. ストアガイドライン変更

プライバシー表示やログイン方式の変更は、開発スコープ外のポリシー対応として扱うことがあります。
審査リジェクトの原因がガイドライン変更かバグかを切り分け、無償修正の範囲を明確にします。

7-3. デザイン差し替えの連鎖

画面デザインの全面差し替えは、実装工数に直結するため追加発注になりやすいです。
デザイン委託と実装委託が別ベンダーのとき、引き渡し日と修正回数の上限を双方の契約で揃えます。

8. 台帳と経理の連携

ストア公開日と検収承認日がずれている取引先は、どちらを起算にするか契約を再確認します。

変更依頼が多い取引先は、月次で未承認変更の有無を台帳ステータスで管理します。

証明書・リポジトリの引き渡し記録を、検収メモ欄に URL や日付で残します。

バージョン番号を発注書面と要件定義の両方に振り、突合ミスを防ぎます。

9. 関連ルールの押さえ直し

モバイルアプリ開発は納期と仕様変更がぶつかりやすいため、支払期日の起点を定期的に見直します。
支払60日ルールの起算点を社内標準にし、受領日の空欄をゼロにすることが先決です。
発注書面の記載漏れは記載事項のテンプレートで補完し、取引開始前に交付してください。

継続的な改修フェーズに入ったら、新規開発とは別の台帳行で管理し、検収単位を月次に切り替えることも検討します。
口頭変更が常態化している取引先は、契約見直しまたは社内承認フローの強化を検討してください。

注意

本記事は取適法・フリーランス新法に関する一般的な情報の整理であり、トリカク（torikaku） の機能説明を含みますが、法的助言ではありません。
個別の契約内容・取引実態については専門家にご確認ください。