アプリのリプレイスは「今のアプリを新しくしたい」という一見シンプルな要望から始まりますが、実際に発注してみると、見積もりの大幅なズレ、仕様をめぐるベンダーとの水掛け論、想定外の追加費用請求、プロジェクトの遅延といったトラブルが後を絶ちません。その多くは、発注前の準備と契約の設計が不十分なことに起因しています。

この記事では、アプリリプレイスを外注・委託する際の発注プロセスの全体像から、ベンダーから良い提案を引き出すRFPの書き方、見積もりの精査方法、そして多くの競合記事が触れていない「契約の法務的な落とし穴」「発注後のプロジェクト管理ノウハウ」まで、実務で使える具体的な情報をまとめて解説します。

▼全体ガイドの記事
・アプリリプレイスの完全ガイド

アプリリプレイスの発注プロセス全体像

アプリリプレイスの発注は、単に「開発会社を探して依頼する」という行為ではありません。発注側が主体的にプロセスを設計し、ベンダーをコントロールしていく継続的な取り組みです。発注プロセスは大きく「RFI（情報提供依頼）」「RFP（提案依頼）」「評価・選定」「契約締結」という4ステップで構成されます。このフローを正しく理解しているかどうかが、プロジェクト成否の最初の分岐点となります。

発注プロセスの第一段階である「RFI（Request for Information）」は、ベンダー候補から自社の課題解決に役立つ情報を収集するためのヒアリングです。アプリリプレイスの場合、「現行アプリはiOS/Android両対応でReact Nativeを使っているが、最新技術へのリライトは可能か」「バックエンドAPIとの連携実績はあるか」といった技術的な情報を複数社から収集し、発注先の候補を絞り込みます。RFIには必ずしも正式な書面は不要で、メールや簡単な説明資料で十分です。

次のステップが「RFP（Request for Proposal）」です。RFIで絞り込んだ3〜5社程度に対して、正式な提案と見積もりを依頼するための提案依頼書です。RFPの質がそのままベンダーから受け取る提案の質を左右するため、ここに最も時間と労力を投入すべきです。RFPを受け取ったベンダーは、通常2〜4週間の期間をかけて提案書と見積書を作成します。

「評価・選定」のフェーズでは、各社の提案内容を同一の評価軸で比較します。金額だけでなく、技術的なアプローチの妥当性、プロジェクト体制、PM（プロジェクトマネージャー）の経験、保守運用の体制なども評価軸に加える必要があります。最終候補が絞れたら「最終プレゼン（オーラルセッション）」を設定し、提案内容の詳細確認と質疑応答を行います。

そして最後が「契約締結」です。契約形態の選択（請負か準委任か）、責任範囲の明確化、SLAの設定、支払い条件など、この段階での設計が後々のトラブルを大きく左右します。多くの発注担当者がプロジェクトに先を急ぐあまり契約の精査を疎かにしてしまいますが、契約書は「何かあったとき」に初めて機能するものであり、丁寧に設計することが不可欠です。

アプリリプレイスの発注先は大きく5種類に分類できます。それぞれ得意領域と費用感が異なるため、自社の要件に合った発注先を選ぶことが重要です。

まず「大手SIer・コンサルティングファーム」は、プロジェクト管理体制が充実しており、複雑な要件や大規模なリプレイスに強みを持ちます。ただし人月単価が高く（上級エンジニアで140〜250万円/月）、中小企業には予算的にハードルが高い場合があります。次に「中堅・独立系SIer」は、特定業種やシステムへの専門性を持つ企業が多く、費用対効果が高い傾向にあります。特にモバイルアプリ開発に特化したSIerは、iOS/Android両対応や最新のクロスプラットフォーム技術（Flutter、React Native等）に詳しいケースが多いです。

「アプリ専門の開発会社」は、スタートアップや中小企業向けのアプリ開発実績が豊富で、スピードと柔軟性に優れています。一方で、大規模なバックエンド連携や基幹システムとの統合が必要なケースでは実績が限られることもあります。「フリーランスチーム・クラウドソーシング」は、小規模なリプレイスや予算が限られた場合に選択肢になりますが、プロジェクト管理の責任が発注側に重くなるため、PMスキルのある担当者がいない場合は慎重に検討すべきです。最後に「コンサルティングファーム＋開発パートナー」というハイブリッド型もあります。要件定義・設計フェーズのみコンサルに依頼し、実装はコスト効率の良い開発会社に委ねる分業モデルで、コスト最適化と品質担保を両立しやすい形態です。

RFPの書き方――ベンダーから良い提案を引き出すコツ

RFPはアプリリプレイスプロジェクトの成否を決める最重要ドキュメントです。「RFPの質＝ベンダーの提案の質」と言っても過言ではなく、曖昧なRFPからは曖昧な見積もりと提案しか返ってきません。逆に、具体的で網羅的なRFPを作れる発注担当者は、ベンダーから「この会社は要件が明確だから、良い仕事ができそうだ」と評価され、より精度の高い提案と正確な見積もりを引き出すことができます。

アプリリプレイスのRFPには、少なくとも以下の項目を盛り込む必要があります。まず「プロジェクトの背景と目的」として、なぜ今リプレイスが必要なのか（旧アプリの技術的負債、OSバージョン対応限界、パフォーマンス劣化、UX改善ニーズ等）を具体的に記述します。次に「現状のシステム構成」として、現行アプリのプラットフォーム（iOS/Android/クロスプラット）、フレームワーク、バックエンドAPI、連携する外部サービス（決済、プッシュ通知、分析ツール等）を明示します。

「機能要件」では、新アプリに実装すべき機能をMoSCoW分析（Must have／Should have／Could have／Won’t have）で優先度分けして記述します。「非機能要件」は、パフォーマンス要件（画面読み込み2秒以内等）、可用性（稼働率99.9%等）、セキュリティ要件（認証方式、暗号化基準等）、スケーラビリティを数値で明記します。「UI/UX要件」としては、デザインガイドラインの有無、参考にしたいアプリのURL、アクセシビリティ対応の要否を記載します。そして「予算の上限」「希望納期」「提案評価基準と選定スケジュール」「質問受付の締め切り」も忘れずに明記することが重要です。

特にアプリリプレイスで重要なのが、既存ユーザーのデータ移行とストアレビューの引き継ぎ方針です。App StoreやGoogle Playのアプリはアカウントと紐づいているため、新アプリへの移行時にレビュー数がリセットされる場合があります。この点をRFPに明記し、ベンダーから具体的な対策提案を求めることが必要です。

RFPで最も多い失敗が「曖昧な表現による認識のズレ」です。「使いやすいUI」「高速なレスポンス」「セキュアな設計」といった表現は、ベンダーと発注側で解釈が異なる典型例です。これらは必ず数値化・具体化して記述します。「使いやすいUI」であれば「ユーザビリティテストで主要タスクの達成率90%以上」、「高速なレスポンス」であれば「APIレスポンスタイム95パーセンタイルで2秒以内」、「セキュアな設計」であれば「OWASP Mobile Top 10への準拠」のように記述することで、後々の「言った・言わない」を防ぐことができます。

また、「現行踏襲」という言葉はRFPで使わないことをお勧めします。「現在と同じ機能」という表現は、ベンダーにとっては「現行仕様書の全項目が対象」と解釈される一方、発注側は「主要な機能だけで良い」と考えているケースが多く、見積もりが数倍以上異なる原因になります。「踏襲する機能」と「不要な機能」を明示的にリスト化することが、精度の高い見積もりを引き出す近道です。

発注後の追加費用トラブルの最大の原因は「スコープクリープ」——つまり、当初の合意範囲を超えて要件が追加・拡大していく現象です。これを防ぐには、RFPの時点でスコープの境界線を明確にしておくことが不可欠です。RFPには「スコープイン（今回のリプレイスに含めるもの）」と「スコープアウト（今回は対象外のもの）」を明示的に分けて記載します。たとえば「バックエンドAPIのリファクタリングはスコープアウト」「Push通知の新機能追加はフェーズ2以降」と明記しておくことで、ベンダーが追加費用を請求する根拠を作らせないようにします。

また、契約後に要件変更が生じた場合の「変更管理プロセス（Change Request Process）」もRFPに盛り込んでおくことを推奨します。変更依頼の提出書式、影響試算の期間、承認フロー、追加費用の上限のガイドラインなどをあらかじめ合意しておくことで、発注後の要件変更を「トラブル」ではなく「マネジメントできる事象」として扱えるようになります。

見積もりの精査と相見積もりの比較方法

複数社から見積もりを取ると、多くの場合、金額が2〜5倍以上異なることがあります。安い見積もりを出したベンダーが良いわけでも、高い見積もりを出したベンダーが悪いわけでもありません。見積もりの金額差には必ず理由があり、その理由を読み解く力が発注担当者に求められます。

見積もりを精査する際に確認すべき5つのポイントを解説します。

①「工程別の内訳が明示されているか」：要件定義・設計・開発・テスト・移行・PM管理費の各工程の費用が明示されているかを確認します。「一式〇〇万円」という見積もりは、後から追加費用が発生しやすい危険なサインです。開発工程別の費用比率の目安は、開発・実装50〜60%、要件定義10〜15%、設計10〜25%、テスト5〜10%、運用保守15〜20%です。これらの比率から大きく外れていないかを確認します。

②「工数（人月）と単価の積算になっているか」：見積もりは「誰が・何ヶ月・いくらで」という人月×単価の積算式になっているはずです。エンジニア単価の目安は、新人〜80万円/月、一般80〜140万円/月、上級140〜250万円/月です。これらを参考に、計上されている工数が妥当かを判断します。

③「テスト工程が独立して計上されているか」：テストコストを圧縮して安く見せている見積もりは、後からバグ修正費用が膨らむリスクがあります。IPA「ソフトウェア開発データ白書」によれば、総合テスト段階で1KSLOC（1000行）あたり中央値0.32件のバグが検出されています。適切なテスト工程が確保されていない安い見積もりは、長期的には高くつく可能性があります。

④「非機能要件（性能・セキュリティ）の対応コストが含まれているか」：非機能要件への対応は費用がかかります。安い見積もりにはこれが省かれていることが多く、後から「性能改善のための追加対応」として別途請求されるケースがあります。⑤「保守・運用フェーズの費用が明示されているか」：リリース後の保守運用費（バグ修正、OSバージョン対応、サーバー費用）が見積もりに含まれているかを確認します。初期開発費が安くても、保守コストが高ければトータルで割高になります。

複数社の見積もりに大きな金額差がある場合、その原因は大きく2つに分類できます。1つ目は「前提条件の解釈の違い」です。RFPの記述が曖昧な場合、あるベンダーは「最小限の機能で解釈」し、別のベンダーは「拡張的に解釈」した結果、金額差が生じます。この場合は、全社に同じ質問を投げかけて前提を揃えた上で再見積もりを依頼します。

2つ目は「見積もり段階による不確実性」です。これは「見積もり変動は構造的なものである」という重要な事実を発注側が理解しておく必要があります。要件定義が完了していない段階での見積もりは「超概算」であり、±50%の変動は当然起こりえます。概算（基本設計完了後）でも±20〜30%の変動があり、確定見積もり（詳細設計完了後）でようやく±10%以内になります。「なぜ最初と見積もりが違うのか」とベンダーを責める前に、「そもそもどの段階の見積もりだったのか」を発注側が把握しておくことが肝心です。プロジェクト初期の超概算段階では、変動することを前提とした予算計画を立てることが重要です。

契約の落とし穴と法務的注意点

アプリリプレイスの発注において、多くの競合記事が触れていないのが「契約の法務的な落とし穴」です。契約書は「普段は見ないが、トラブルが発生したときに唯一の判断基準となる文書」です。ここでは、アプリ開発特有の契約上の注意点を詳しく解説します。

システム開発の契約形態は「請負契約」と「準委任契約」の2種類が主流です。両者の最大の違いは「完成責任の有無」にあります。請負契約では、ベンダーは合意した成果物（アプリ）を「完成させる義務」を負います。成果物に欠陥があれば、発注側は修正や損害賠償を求めることができ（契約不適合責任）、発注側にとって責任の所在が明確で安心感があります。

一方の準委任契約は、ベンダーは「業務を誠実に遂行する義務」を負いますが、成果物の完成を保証しません。アジャイル開発や要件が流動的なフェーズで採用されることが多く、柔軟性が高い反面、発注側が積極的にプロジェクトに関与してディレクションしていく必要があります。

アプリリプレイスでは、フェーズによって使い分けるのが実務上の最適解です。要件定義・基本設計フェーズは不確実性が高いため「準委任」、詳細設計・開発・テストフェーズは要件が固まっているため「請負」、保守運用フェーズは継続業務のため「準委任」という組み合わせが一般的です。フェーズを問わず一律に請負契約にすると、要件変更のたびに契約変更が必要になり、プロジェクトが硬直化するリスクがあります。

2020年の民法改正で「瑕疵担保責任」は「契約不適合責任」に改正されました。請負契約において成果物が契約の内容に適合しない場合、発注側は「追完請求（修補・代替物の引渡し）」「代金減額請求」「損害賠償請求」「契約解除」のいずれかを選択できます。

実務上の注意点は「契約に合致する要件が明文化されているか」です。「アプリが正常に動作しない」というだけでは契約不適合を主張しにくく、「ユーザー認証機能において、正しいパスワードを入力した場合に100%ログインできること」のように、機能要件が仕様書・契約書に具体的に記載されている必要があります。RFPの機能要件を詳細に書いておくことは、法的なリスクヘッジという観点からも重要なのです。また、契約不適合責任の行使期間は「不適合を知った時から1年」です。アプリリリース後も一定期間、動作確認と記録を残しておくことが推奨されます。

アプリリプレイスを外注する際、発注側の企業規模と委託先の規模によっては「下請代金支払遅延等防止法（下請法）」が適用されます。下請法は、発注側（親事業者）が受注側（下請事業者）に対して不当に不利な取引条件を強いることを防ぐための法律です。

下請法が適用される主な条件は、情報成果物（ソフトウェア）の委託では「資本金3億円超の会社が資本金1,000万円超3億円以下の会社に発注する場合」または「資本金1,000万円超3億円以下の会社が資本金1,000万円以下の会社に発注する場合」です。大企業が中小の開発会社にアプリリプレイスを発注する場合は、ほぼ確実に下請法が適用されると考えておく必要があります。

下請法で最も重要なルールが「60日以内の支払い」です。ベンダーからアプリの納品を受けた日（受領日）から起算して60日以内に下請代金を支払わなければなりません。重要なのは、起算日が「検収日」ではなく「受領日（納品を受けた日）」である点です。「検収に3か月かかったため、支払いが受領から90日後になった」という場合、下請法違反となります。違反が認められると公正取引委員会からの勧告に加え、年率14.6%の遅延利息の支払い義務が生じます。発注側の管理部門・経理部門に、下請法の支払いルールを事前に共有しておくことが必要です。

アプリのリリース後の保守運用フェーズで特に重要なのが、SLA（Service Level Agreement：サービスレベル合意）の設計です。SLAとは、ベンダーが提供するサービスの品質水準（稼働率・応答時間・障害対応時間等）を数値で定めた合意書です。保守運用契約を締結する際には必ずSLAを含めるべきです。

アプリのSLAで設定すべき主な項目は以下の通りです。稼働率については「月間サービス稼働率99.9%以上（許容停止時間：月間約43分）」という水準が一般的です。ただし、メンテナンス時間を除外する免責事項と、測定方法（外形監視か内部監視か）も明記する必要があります。レスポンスタイムについては「API応答時間の95パーセンタイルが2秒以内」のように具体的な数値で定めます。障害対応については「重大障害（アプリ全停止）の初動対応：30分以内に連絡」「軽微なバグ対応：報告後5営業日以内に修正案を提示」のようにレベル分けして定めます。

ペナルティ条項は「SLAを下回った場合に月額保守費用の〇%を減額」という形式が実務では一般的です。ただし、ペナルティ設定が過大すぎるとベンダーが契約を嫌がったり、保守コストが高くなったりします。「稼働率が99.0%を下回った月は月額費用の10%を減額」程度が現実的な水準です。あわせて、地震・火災・通信回線障害等の不可抗力による免責事項も明記しておくことで、ベンダーが適正価格で保守契約を結ぶことができます。

発注後のプロジェクト管理――ベンダーをコントロールする技術

契約を締結したらプロジェクトは動き出しますが、発注後の管理が甘いと「ベンダーに主導権を握られ、気づけば大幅遅延・予算超過」という最悪のシナリオに陥ります。発注側が主体的にプロジェクトをコントロールするための実践的なノウハウを解説します。

多くのアプリリプレイスプロジェクトで問題になるのが「フェーズ完了の判定基準」です。「設計フェーズ完了」「開発フェーズ完了」という判定は、一般的には「成果物（設計書・コード等）の提出」で行われますが、これだけでは実際に次のフェーズへ移行できる状態かどうかを保証できません。

そこで有効なのが「ILUO（イルオ）スキル評価」を活用したフェーズゲートです。ILUOは製造業発祥のスキル評価フレームワークで、I（知っている）→L（補助があればできる）→U（独立してできる）→O（他者に教えられる）の4段階でスキル成熟度を評価します。これをITプロジェクトに応用すると、フェーズ移行の条件として「発注側（ユーザー企業）の担当者が、成果物を独立して理解・操作できる状態（U評価）に到達していること」を定義できます。設計フェーズ完了であれば「設計書を読んでシステムの全体像を説明できること」、テストフェーズ完了であれば「テスト手順書をもとに独力でテストを実行できること」が基準となります。このフレームワークを採用することで、ベンダーが成果物を提出しただけで「完了」と主張するのを防ぎ、発注側の理解・習熟を客観的な移行基準として設定できます。

アプリリプレイスプロジェクトは、当初予算の20〜50%超過が珍しくありません。特にアプリ開発は要件の不確実性が高く、開発中に発見される技術的な課題や仕様変更により、追加費用が発生することがあります。この状況で求められるのは、経営陣に「なぜ予算が増えるのか」を論理的に説明し、追加予算を獲得する力です。

経営陣への説明では「なぜ増えたか（原因）」「増やさなかった場合のリスクと損失」「追加予算承認後の完了見通し」の3点をセットで提示することが重要です。原因については、「要件定義フェーズで判明した非機能要件の追加対応（セキュリティ強化）」「OSバージョンアップへの緊急対応」のように具体的に示します。損失については「追加投資をしなかった場合、現行アプリが来年のiOS新バージョンで動作しなくなり、月間アクティブユーザー〇万人が利用不能になる」という形でビジネスへの影響を金額換算します。そして完了見通しについては「追加〇〇万円で〇ヶ月後に確実に完成する」という確度の高い見通しを提示します。

最も難しい判断の1つが「プロジェクトの損切り」です。すでに多くの予算と時間を投資してしまったため、「今さら中止できない」という心理が働くことがありますが、これが「サンクコストの誤謬（コンコルドの誤謬）」です。過去に投資したコストは戻ってこないため、「今後の見通し」だけを基準に継続・中止を判断する必要があります。

プロジェクト中止を真剣に検討すべきサインとして、以下のような状況が挙げられます。当初の完成見込みが繰り返し後倒しになり、現時点での完成見通しが3回以上大幅に変更されている。ベンダーが根本的な技術的問題（アーキテクチャの設計ミスなど）を認識しているにもかかわらず、対処を先送りにしている。追加費用の請求が続き、最終的なコストが当初見積もりの2倍を超える見通しとなっている。発注側の要件担当者とベンダーとの信頼関係が崩壊し、定例会議が対立の場になっている。こうした状況になった場合、追加投資の継続よりも「スコープを大幅に削減した最小限のリプレイス（MVP）で早期リリースする」か「別のベンダーで最初からやり直す」という選択肢を検討することが、長期的には合理的な判断となる場合があります。

まとめ

アプリリプレイスを成功させる発注の要点を改めて整理します。まず、発注プロセスの全体像として「RFI → RFP → 評価・選定 → 契約締結」という4ステップを正しく踏むことが基本です。特にRFPの質が後のプロジェクト全体の品質を決定づけるため、機能要件・非機能要件・UI/UX要件を具体的な数値で記述することが不可欠です。

見積もりの精査においては、金額の大小だけでなく「工程別の内訳」「工数と単価の積算根拠」「テスト工程の充実度」を確認します。また、見積もりはプロジェクト初期段階では構造的に変動するものという理解を発注側が持ち、適切な予算バッファを設定することが重要です。

契約面では、フェーズに応じた請負・準委任の使い分け、契約不適合責任の要件書への反映、下請法の60日支払いルールの遵守、そしてSLAとペナルティ条項の設計が重要なポイントです。これらは多くの企業が見落としがちな部分であり、事前に整備しておくことでトラブル発生時のリスクを大幅に軽減できます。

発注後のプロジェクト管理では、ILUOスキル評価を活用したフェーズ完了判定の導入により、「成果物の提出＝フェーズ完了」という形式的な判断を避けることができます。そして万一プロジェクトが暗礁に乗り上げた際には、サンクコストにとらわれず「今後の見通し」だけで継続・中止を判断する冷静さが求められます。アプリリプレイスの発注は、準備と知識があれば必ず成功に近づきます。ぜひ本記事の内容を実務に役立ててください。

▼全体ガイドの記事
・アプリリプレイスの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。