アプリ開発の見積もり比較：開発範囲と引き継ぎ条件
あるベンダーは一式を「開発完了」と見積もり、別のベンダーは要件整理、デザイン、QA、デプロイを個別に計上しています。合計金額だけを並べても、どちらが本当に高いのかは判断できません。まず、すべてのベンダーが同じ成果物を見積もっていることを確認しましょう。
開発範囲をそろえてから価格を比較する
各提案が以下の項目をカバーしているか確認してください：
- ウェブアプリのみ、それともネイティブのiOSとAndroidアプリも含むか
- 合意した画面、ユーザーフロー、管理機能
- デザインの編集用ファイル、レスポンシブ対応、アクセシビリティ対応
- 既存データの移行とサードパーティ統合
- テスト、セキュリティレビュー、バグ修正の範囲
- サーバーのデプロイとアプリストアのレビュー支援
- 引き継ぎ後の保証内の修正と有料メンテナンス
抜けている項目は、後から追加費用になることがあります。逆に、不要なプラットフォームや継続サポートが見積もりに含まれている場合もあります。ベンダー名と合計金額だけで比べず、含む・含まない・前提条件の3列で比較表を作りましょう。
プロトタイプは仕様書ではなく、認識合わせの道具として使う
Claude Code、Codex、Cursor、Lovableで作ったプロトタイプは、文章だけの概要よりも意図した操作の流れを明確に示せます。ただし、画面が動くからといって仕様がすべて固まっているとは限らず、そのコードをそのまま本番で使えるとも限りません。
Lovableが作るのは、基本的にWebアプリです。PWAや別途用意するラッパーを使えば端末にインストールできる形にはできますが、技術評価をせずにWebプロトタイプをネイティブiOS・Androidアプリの開発実績として数えるべきではありません。
プロトタイプで確認できたことと、まだ評価が必要なことを分けましょう。
すでに示されている
- スクリーンフローとコアテキスト
- ユーザーが行うべき主なアクション
- 希望されるビジュアルの方向
まだ評価が必要
- コードが再利用可能かどうか
- モバイルデバイスとブラウザでの動作、アクセシビリティを含む
- 認証、認可、支払いの安全性
- テスト、デプロイ、モニタリングのアーキテクチャ
- ライブラリやアセットのライセンス
こう整理すれば、プロトタイプの価値を誇張せずに活用でき、すでに決めた製品要件を一から説明し直す手間も省けます。
本開発の前に短期間の技術評価を依頼する
リポジトリを調べずに「現行コードの80%を再利用できる」「すべて作り直す必要がある」と責任を持って断言することはできません。まず、有料の技術評価を依頼し、評価後に何を納品してもらうか合意しましょう。
最低限、レビュワーに以下の点を確認してもらいましょう：
- READMEに従って、クリーンな環境でプロジェクトがインストール・実行可能か
- 主なスクリーンとフローがまだ動作しているか
- 秘密情報がコードやログに含まれていないか、認証やユーザー単位の認可に明らかな欠陥がないか
- 自動テストでカバーされている項目と、まだ手動で確認が必要な項目
- アプリが依存しているライブラリ、ホスティングサービス、外部アカウント、ライセンス
次の3案を出してもらいます。現状を生かして完成、対象箇所のみリファクタリング、全面的に再構築です。各案には範囲、リスク、スケジュールを明記してもらいましょう。プロトタイプが必ず工数削減につながるわけではありませんが、粗いコードにも再利用できる部分はあります。技術評価を通じて、その境界を見極めます。
引き継ぎパッケージはリポジトリだけではありません
新しい開発者がアクセス権を受け取った当日から作業を始められるよう、次を準備します。
- インストール、実行、ビルドのコマンドを含むREADME
- 必要な環境変数の名前と取得方法、実際の値は別のセキュアなチャネルを通じて送信してください
- スクリーンと機能のリスト、および既知の欠陥
- テストアカウントとテスト手順
- サーバー、ドメイン、支払い、分析、アプリストアアカウントのリスト
- 重要な決定を記録するGitリポジトリとコミット履歴
引き継ぎ直前に、重複しているように見えるAI生成ファイルや未使用らしいファイルを削除しないでください。まず、正常に動く状態をタグかブランチに残し、技術評価の中で削除してよいか確認します。
実際の値やAPIキーを含む.envファイルをコミットしないでください。実際の値を含まない.env.exampleを作成し、必要な変数名のみをリストしてください。キーをすでにコミットしてしまった場合は、まず無効化またはローテーションし、その後でGit履歴の削除が必要か検討してください。
運用上の主導権を契約に明記する
アカウントの所有者や納品物を曖昧にすると、特定のベンダーから離れられなくなることがあります。契約前に、次の項目を書面で確認しましょう。
- どのリポジトリにソースコードと完全なGit履歴が渡されますか？
- ドメイン、ホスティング、アプリストア、決済サービスの契約名義は誰ですか？
- 編集可能なデザインファイル、フォント、画像、有料ライセンスは引き継ぎに含まれますか？
- 各受け入れマイルストーンに含まれる機能と、何が承認とみなされるか
- スコープの変更を承認する責任者は誰ですか？記録方法と価格設定方法は？
- 保証内の修正と有料メンテナンスの基準は？
可能な限りクライアントの名前で主要なアカウントを作成し、ベンダーに必要なアクセス権限のみを許可してください。既存のGitHubリポジトリが所有者を変更する必要がある場合、引き継ぎ計画にGitHubの移管プロセスと移管後の権限確認を含めてください。
短い見積もり依頼で十分です
動作するWebプロトタイプとGitリポジトリがあります。
目標：管理画面を備えたレスポンシブWebアプリ
見積もり範囲：コード評価、認証・決済レビュー、デプロイ、引き継ぎ文書
対象外：ネイティブiOS・Androidアプリ
納品物：ソースコードとGit履歴、デプロイ設定、README、テスト結果
まず有料の技術評価を実施し、「現状を生かして完成」「対象箇所のみリファクタリング」「全面的に再構築」の3案を個別に見積もってください。
すべてのベンダーに同じドキュメントを送り、質問と回答を保存してください。最も比較しやすい見積もりは必ずしも最も安いものではありません。見積もりから除外された項目と引き継ぎ条件が明確かどうかが重要です。ベンダーを選択する前に、契約専門家にスケジュール、支払い条件、知的財産に関する条文、ライセンス条項をレビューしてもらうことを検討してください。