アプリ開発を外注する方法｜依頼先・費用・契約前の注意点

アプリ開発の外注は、仕様書を渡して完成を待つ仕事ではありません。発注側が目的、優先順位、受け入れ条件、アカウントとデータの所有を決め、受注側と判断を積み重ねる共同プロジェクトです。依頼先の知名度や見積総額だけで選ばず、公開後と契約終了後まで設計します。

1. 外注する目的を一文にする

「アプリを作る」ではなく、誰のどの行動をどう変えるかを決めます。新規顧客獲得、既存顧客支援、社内業務短縮など目的が違えば、必要な画面、計測、公開方法も変わります。成功指標と、今回は扱わない課題も書きます。

2. 内製する判断を残す

事業方針、優先順位、法務、個人情報、受け入れ、公開可否は自社が判断します。調査、デザイン、実装、テストを外注しても、責任まで移るわけではありません。社内責任者と日常の窓口を決めます。

3. 依頼範囲を工程で分ける

企画、要件、情報設計、UI、実装、外部連携、テスト、ストア申請、分析、保守を並べ、自社、外注、共同のどれかを割り当てます。「開発一式」では成果物と対象外が分かりません。既存システムの改修やデータ移行も別にします。

4. 提案依頼書を作る

対象ユーザー、利用場面、必須機能、対象OS、既存システム、データ、品質、安全、アクセシビリティ、希望時期、予算条件、成果物を候補各社へ同じ形で渡します。未確定事項は隠さず、仮定と追加時の扱いを回答してもらいます。

外注の進め方

目的から契約へ直行せず、共通条件で提案を受け、小さい検証で協働方法を確かめます。

5. 依頼先の種類を選ぶ

開発会社は複数工程をまとめやすく、専門会社や個人は特定領域へ絞りやすい傾向があります。ただし名称だけで能力は判断できません。実担当、再委託、似た要件で担当した工程、公開後の体制を個別に確認します。

6. 秘密保持と情報開示

提案に必要な情報を段階的に開示します。初期は匿名化した業務と要件、契約後は必要最小限のデータと権限にします。秘密保持契約があっても、本番の顧客データや共有パスワードを無条件に渡しません。

7. 提案の見方

機能の多さではなく、課題理解、技術選択の理由、制約、検証方法、対象外を見ます。要望をすべて肯定する提案より、作らない選択や段階導入を根拠付きで説明できるかを確認します。

8. 実担当と再委託

営業担当だけでなく、責任者、設計、デザイン、開発、テスト、保守の担当を確認します。再委託先、所在地、管理責任、交代時の引き継ぎ、緊急連絡を文書にします。担当変更を契約後に初めて知る状態を避けます。

9. 見積を同じ列で比較する

工程、成果物、単価、数量、前提、対象外、追加単価、外部費、保守、移管を横並びにします。安い見積が同じ範囲とは限りません。不明項目は「含む」と推測せず、質問して再提示を受けます。

費用の考え方

初期開発だけでなく、要件変更、クラウド、外部サービス、ストア、OS更新、監視、問い合わせ、不具合、分析、社内工数を含む総保有費で考えます。金額は要件と契約で変わるため、一律の相場を事実のように置きません。

10. 契約方式と検収

請負や準委任という名称だけでなく、何を納め、誰が指示し、いつ検収し、変更をどう扱うかを契約本文で確認します。要件が不明なら、調査・要件定義を先に分ける方法があります。曖昧なまま固定価格へ押し込みません。

11. 知的財産と成果物

ソースコード、デザイン、仕様、テスト、素材、データ、学習成果、既存部品の権利を分けます。納品される形式、利用・改変・再委託・移管の範囲、第三者ライセンスを確認します。「成果物一式」だけで済ませません。

12. アカウントは自社で所有する

AppleやGoogleの開発者アカウント、クラウド、ドメイン、リポジトリ、分析、通知、証明書は原則として自社名義で作り、外注先を必要な権限で招待します。担当者個人や外注会社だけが管理すると、終了時に公開や更新が止まります。

13. 開発環境と安全

ソース管理、レビュー、秘密情報、依存関係、端末、ログ、バックアップ、脆弱性対応を確認します。本番データを開発へコピーしない方法、退職・契約終了時の権限削除、事故時の連絡と記録も決めます。

14. テストと受け入れ

対象端末、OS、画面、通信条件、権限、アクセシビリティ、性能、安全、障害復旧を定義します。誰がテストデータを用意し、どの不具合なら公開を止めるかを合意します。受け入れ期間と修正後の再確認も必要です。

15. ストア公開

AppleとGoogleの公開工程では、署名、ビルド、掲載情報、プライバシー申告、審査対応が必要です。公式要件は更新されるため、公開時点で確認します。外注先に審査通過を保証させるのではなく、差し戻し時の担当を決めます。

16. 変更管理

変更理由、影響、追加費、納期、優先順位、承認者を記録します。口頭依頼を積み重ねると範囲が崩れます。新要望は既存の何と入れ替えるか、次回へ送るかを判断します。

17. 進捗報告

作業量だけでなく、完成条件、課題、決定待ち、品質、予算影響を共有します。定例会の多さより、決定と根拠が追跡できることが重要です。発注側の確認遅れも記録し、納期だけを外注先の責任にしません。

18. 保守契約

受付時間、一次応答、復旧目標、対象作業、月間上限、時間外、OS更新、外部障害、脆弱性、報告を確認します。「保守込み」では足りません。機能改善と障害対応を分け、費用と優先順位を管理します。

19. 解約と移管

コード、設計、データ、鍵、アカウント、未解決課題、運用手順を返却する形式と時期を決めます。移管支援、データ削除、バックアップ、権限削除を契約前に合意します。終了時だけ交渉すると選択肢が狭まります。

20. 契約前チェック

目的、範囲、担当、再委託、総費用、受け入れ、安全、権利、アカウント、保守、解約が提案・見積・契約で一致するか確認します。確認できない項目は「-」として残し、営業担当の口頭説明だけで埋めません。

小さく外注して確かめる

本開発の前に、利用者調査、画面試作、技術検証など限定した成果物を依頼すると、質問の質、記録、速度、品質、連絡を実際に確認できます。試行を無償前提にせず、範囲と権利を決めます。

まとめ

発注後に品質を保つ実務

発注後は、週ごとの進捗率だけでなく、利用者が完了できるシナリオを基準に確認します。画面の完成数が増えても、認証、データ、エラー、復旧がつながらなければ公開品質には届きません。節目ごとに動く成果物を自社環境で受け取り、受け入れ条件へ照らします。

決定事項は、日付、選択肢、採用理由、影響、承認者を残します。チャットだけに重要判断を散らさず、仕様と課題管理へ反映します。担当者が替わった時も同じ判断を再現できる状態が、保守費と移管リスクを抑えます。

請求の確認では、見積行、実績、変更承認、成果物を対応させます。予定との差が出た時は責任追及から始めず、要件、技術課題、自社回答、外部審査のどこで発生したかを分け、残予算と優先順位を更新します。

公開前には権限一覧、バックアップ、監視、問い合わせ、障害連絡、ストア連絡先を自社で確認します。公開後の最初の期間は、クラッシュ、認証失敗、主要行動、問い合わせを集中的に見ます。取得するログは目的と保持期間を決め、個人情報を不用意に含めません。

外注先を評価する際は、納期だけでなく、課題を早く開示したか、根拠を説明したか、記録を残したか、修正を再検証したかを見ます。次回の選定に使えるよう、確認できた事実と確認日を残し、担当者の印象を会社全体の評価へ広げません。

アプリ開発の外注は、共通の依頼条件で提案と見積を比較し、自社所有のアカウントで進めます。公開だけを終点にせず、保守と移管まで契約に入れ、小さい工程で協働方法を確認してください。