外注先のデモを見たときはスムーズに見えても、検収の段階でログインが時々失敗する、決済コールバックが通っていない、バックエンドのデータが一致しない——こうした手戻りが最も厄介です。App開発の外注における検収は、本質的に「動くかどうかを一目見る」ことではなく、要件・品質・納品物の3つを項目ごとに突き合わせることです。以下、実行可能な順序で明確に説明します。
一、まず要件リストを検証し、「感覚」で検収しない
検収の最初の資料はインストールパッケージではなく、要件定義書と機能リストです。多くの手戻りは、最初から明確に書かれていなかったことに起因します。誰が使うのか、どのような場面で使うのか、異常時にはどう通知するのか。
実施の提案：
- 要件をチェック可能な項目に分解し、各項目に「入力—操作—期待結果」を明記する。例えば「電話番号ログイン：未登録の番号を入力すると、未登録である旨を通知し登録へ誘導する」。
- 優先度を明記し、コアフロー（登録ログイン、注文・決済、中核業務操作）は100%通過必須とし、次要機能は修正項目としてリスト化してよい。
- 検収時は項目ごとにチェックし、その場でスクリーンショットや画面録画を記録する。「これはダメ」と口頭で言うだけで証拠がない状態を避ける。
トラブル回避：「思っていたのと違う」を検収基準にしないこと。UIの細部は調整可能だが、機能の欠落やデータの誤りは必ず修正票に記載し、責任と期限を明確にする。
二、実機テストは機種と異常シナリオをカバーする
シミュレーターで動いても実機で問題ないとは限りません。App開発で最もよくある手戻りは、某ブランドのスマホでクラッシュする、弱電波で白画面になる、権限拒否後にフローが止まる、といったものです。
具体的な方法：
- 主要なiOSとAndroidそれぞれ2～3台の実機を最低限カバーし、低スペック機種を1台含める。
- 異常系を重点的にテストする：ネットワーク切断、バックグラウンドから復帰、着信割り込み、権限拒否、送信ボタンの連打。
- 決済、プッシュ通知、位置情報、カメラなどOS機能に依存するモジュールは、必ず実機で個別に検証する。
- クラッシュログと再現手順を記録し、修正の根拠とする。
トラブル回避：「正常系」だけをテストすることが検収における最大の落とし穴です。異常系こそユーザーが実際に遭遇する状況であり、後の保守コストが最も高くなる部分です。
三、API、バックエンド、データをまとめて検証する
Appはフロントエンドに過ぎず、データがどこから来てどこへ保存されるかが、システムを長期的に運用できるかを決めます。多くのプロジェクトではフロントエンドは見栄えが良いものの、バックエンド管理システムでデータが検索できなかったり、エクスポートが文字化けしたり、権限が混乱していたりします。
検収時の注目点：
- APIが安定しているか、重複リクエスト、タイムアウト、異常なレスポンス時にApp側でフォールバックの通知があるか。
- バックエンド管理システムのCRUD、権限階層、データエクスポートが使用可能か。
- 重要データが追跡可能か。例えば注文ステータスの変更に記録が残るか。
- ミニプログラム開発やWebサイト開発で同一のバックエンドを共用する場合、マルチデバイス間のデータ整合性を確認する。
トラブル回避：Appの画面だけを見ないこと。バックエンド管理システムは運用の日常ツールであり、検収時に実際に使う人に操作してもらう方が、技術デモよりも説得力があります。
四、コード、ドキュメント、アカウントを完全に納品する
手戻りは「担当者が変わる」ときに起こりがちです。コードが手元になく、サーバーアカウントが相手側にあり、デプロイ手順書がなければ、以後の修正のたびに費用交渉が必要になります。
納品リストは契約書に記載することを推奨します：
- 完全なソースコードとビルド手順書。クリーンな環境で起動できること。
- APIドキュメント、データベース構造の説明、サードパーティサービス設定の説明。
- サーバー、ドメイン、アプリストア、決済、プッシュ通知などのアカウント管理権限。
- バージョン履歴と既知の問題リスト。
トラブル回避：検収前に「納品物リスト」を支払いノードの条件としておくこと。コードを自社アカウントでホスティングし、権限を移転可能にしておくことが、口頭の約束より信頼できます。
五、リリースと保守期間を事前に取り決める
リリースは終点ではありません。アプリストアの審査、証明書の期限切れ、OSアップデートによる互換性問題は、納品後に発生します。
明確にすることを推奨：
- リリースの申請は誰が担当するか、審査却下時の修正は誰が行うか。
- 納品後の無償保守期間はどのくらいか、範囲には何が含まれるか（クラッシュ修正、互換性問題）。
- 追加要件の価格設定方法。「小さな修正」が際限なく膨らむのを避ける。
具体的なシナリオ：ある企業が予約系Appを開発し、検収時には機能がすべて通過しましたが、リリース後に旧バージョンのAndroidで日付選択ツールがずれて表示され、ユーザーが時間を選択できなくなりました。検収段階で低スペック実機テストを行っていれば、このような問題は事前に発見できたはずです。
MIC Studioが適しているケース
以下のような段階にある方は、MIC Studioの関与をご検討ください：要件がまだ固まっておらず、リスト化を手伝ってほしい；既存のAppや企業サイトの改修、バックエンド接続が必要；リリース前にセキュリティテストやリバーステストを行い、APIやデータに明らかな脆弱性がないか確認したい；あるいはチームの人手が足りず、スクリプト開発、Webサイト開発、ミニプログラム開発などのサポートが必要。私たちはまず検収基準と納品物を明確に話し合ってから着手する習慣があり、後期の手戻りを減らします。
最後に実行可能な3つの提案
1. 検収前に機能リストと納品物リストを入手し、項目ごとにチェックし、問題は修正票に記載して期限を約束する。
2. 実機テストは低スペック機種と異常シナリオをカバーし、決済、プッシュ通知、権限は個別に検証する。
3. ソースコード、ドキュメント、アカウント権限、無償保守範囲を契約書に記載し、支払いノードの条件とする。