アプリリプレイスの発注は、RFI（情報提供依頼）、RFP（提案依頼）、評価・選定、契約締結の4ステップで進みます。
見積もりのズレや仕様の食い違い、追加費用の請求、遅延といったトラブルは、その多くが発注前の準備と契約の設計の不足から生じます。
▼全体ガイドの記事
・アプリリプレイスの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
アプリリプレイスの発注プロセス全体像
アプリリプレイスの発注は、発注側が主体となってプロセスを設計し、ベンダーを管理しながら進める継続的な取り組みです。
発注プロセスは4つのステップで構成されており、その流れを正しく理解しているかどうかが、プロジェクトの成否を分ける最初の分岐点になります。
- ステップ1：RFI（情報提供依頼）による情報収集
- ステップ2：RFP（提案依頼）による提案と見積もりの取得
- ステップ3：提案の評価と発注先の選定
- ステップ4：契約内容の確認と締結
RFI → RFP → 評価・選定 → 契約の4ステップ
RFI（Request for Information）は、ベンダー候補から自社の課題解決に役立つ情報を集め、候補を絞るためのヒアリングです。たとえば、「現行アプリはiOS/Android両対応でReact Nativeを使っているが、最新技術へのリライトは可能か」「バックエンドAPIとの連携実績はあるか」といった問いを、複数社に投げかけます。
RFIには必ずしも正式な書面は要らず、メールや簡単な説明資料で十分です。
続くRFP（Request for Proposal）は、RFIで絞り込んだ3〜5社程度に正式な提案と見積もりを依頼するための提案依頼書です。RFPの質がベンダーから受け取る提案の質を左右するため、ここに最も時間と労力を投入すべきです。ベンダーは通常、2〜4週間をかけて提案書と見積書を作成します。
- 評価・選定：金額に加え、技術的なアプローチの妥当性、プロジェクト体制、PMの経験、保守運用の体制を同じ評価軸で比べます。
- 最終段階：最終候補には「最終プレゼン（オーラルセッション）」を設け、提案内容の詳細確認と質疑応答を行います。
- 契約締結：契約形態（請負か準委任か）、責任範囲、SLA、支払い条件の設計が、後々のトラブルを大きく左右します。
多くの発注担当者は、プロジェクトを早く前に進めたい思いから、契約内容の精査を後回しにしがちです。しかし、契約書は「何かあったとき」に初めて機能する文書なので、丁寧に設計しておくことが欠かせません。
発注先の種類と特徴
発注先は大きく5種類あり、得意分野や費用感が異なるため、自社の要件に合う発注先を選ぶ必要があります。大手SIer・コンサルティングファームは、プロジェクト管理体制が充実し、複雑な要件や大規模なリプレイスに強みを持ちます。ただし人月単価が高く（上級エンジニアで140〜250万円/月）、中小企業には予算面でハードルが高い場合があります。
中堅・独立系SIerは、特定の業種やシステムへの専門性を持つ企業が多く、費用対効果が高い傾向にあります。特にモバイルアプリ開発に特化したSIerは、iOS/Android両対応や最新のクロスプラットフォーム技術（Flutter、React Native等）に詳しいケースが多いです。「アプリ専門の開発会社」は、スタートアップや中小企業向けのアプリ開発実績が豊富で、スピードと柔軟性に優れています。
- 大規模案件の注意点：大規模なバックエンド連携や基幹システムとの統合が必要なケースでは、実績が限られることもあります。
- フリーランス・クラウドソーシング：小規模で予算が限られる場合に選べますが、プロジェクト管理の責任が発注側に重くなり、PMスキルのある担当者が必要です。
- コンサルティングファーム＋開発パートナー：要件定義と設計をコンサルに、実装を開発会社に任せる分業型で、コストと品質を両立しやすい形態です。
RFPの書き方――ベンダーから良い提案を引き出すコツ
RFPは、アプリリプレイスプロジェクトの成否を決める最も重要な文書です。RFPの質はベンダーの提案の質と言っても過言ではなく、曖昧なRFPからは曖昧な見積もりと提案しか返ってきません。
反対に、具体的で網羅的なRFPを作れる発注担当者は、ベンダーから「この会社は要件が明確だから、良い仕事ができそうだ」と評価され、より精度の高い提案と正確な見積もりを引き出せます。
RFPに記載すべき項目一覧：機能・非機能・UI/UX要件の網羅
まず背景と目的として、なぜ今リプレイスが必要かを、旧アプリの技術的負債、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の時点でスコープの境界線を明確にしておくことが欠かせません。
RFPには、「スコープイン（今回のリプレイスに含めるもの）」と「スコープアウト（今回は対象外のもの）」を分けて記載します。たとえば「バックエンドAPIのリファクタリングはスコープアウト」「Push通知の新機能追加はフェーズ2以降」と明記しておくと、ベンダーに追加費用を請求する根拠を作らせずに済みます。
契約後に要件変更が生じた場合に備え、「変更管理プロセス（Change Request Process）」もRFPに盛り込むことを推奨します。変更依頼の提出書式、影響試算の期間、承認フロー、追加費用の上限のガイドラインなどを、あらかじめ合意しておきます。そうすれば、発注後の要件変更を「トラブル」ではなく「マネジメントできる事象」として扱えます。
見積もりの精査と相見積もりの比較方法
複数社から見積もりを取ると、多くの場合、金額が2〜5倍以上異なることがあります。安い見積もりが良いとは限らず、高い見積もりが悪いとも限りません。
金額差には必ず理由があり、その理由を読み解く力が発注担当者に求められます。
見積もりの妥当性を判断する5つのチェックポイント
「一式〇〇万円」という見積もりは、後から追加費用が発生しやすい危険なサインです。開発工程別の費用比率の目安は、開発・実装50〜60%、要件定義10〜15%、設計10〜25%、テスト5〜10%、運用保守15〜20%で、この比率から大きく外れていないかを見ます。見積もりを精査する際に確認すべきポイントは、次の5つです。
- 工程別の内訳：要件定義から移行、PM管理費まで各工程の費用が明示されているか。
- 工数と単価：人月×単価の積算になっているかを、単価目安と照らして判断する。
- テスト工程：テストが独立して計上されているか。
- 非機能要件：性能・セキュリティの対応費用の有無。
- 保守・運用費：バグ修正、OSバージョン対応、サーバー費用が含まれているか。
工数の判断に使う単価目安は、新人〜80万円/月、一般80〜140万円/月、上級140〜250万円/月です。テストを圧縮した安い見積もりは、後からバグ修正費用が膨らむリスクがあります。実際、IPA「ソフトウェア開発データ白書」では、総合テスト段階で1KSLOC（1000行）あたり中央値0.32件のバグが検出されています。
安い見積もりでは、性能やセキュリティの対応費用が省かれ、後から「性能改善のための追加対応」として別途請求されるケースがあります。初期開発費が安くても、保守の費用が高ければトータルで割高になります。
金額差が大きい場合の見極め方――「構造的な変動」の理解
金額差の原因は大きく2つあり、1つ目は「前提条件の解釈の違い」です。RFPの記述が曖昧な場合、あるベンダーは最小限の機能として、別のベンダーは拡張的に解釈した結果、金額差が生じます。この場合は、全社に同じ質問を投げて前提を揃えたうえで、再見積もりを依頼します。
2つ目は「見積もり段階による不確実性」で、見積もりの変動は構造的なものだと発注側が理解しておく必要があります。要件定義が完了していない段階の「超概算」では±50%の変動が当然起こりえ、概算（基本設計完了後）でも±20〜30%、確定見積もり（詳細設計完了後）でようやく±10%以内になります。
「なぜ最初と見積もりが違うのか」とベンダーを責める前に、そもそもどの段階の見積もりだったのかを発注側が把握しておくことが肝心です。プロジェクト初期の超概算段階では、変動を前提にした予算計画を立てておくことが欠かせません。
契約の落とし穴と法務的注意点
アプリリプレイスの発注で見落とされやすいのが、「契約の法務的な落とし穴」です。契約書は、普段は見ないものの、トラブルが発生したときに唯一の判断基準となる文書です。
請負契約と準委任契約――アプリ開発での使い分け
システム開発の契約形態は「請負契約」と「準委任契約」が主流で、両者の最大の違いは「完成責任の有無」です。請負契約では、ベンダーは合意したアプリを「完成させる義務」を負い、アプリに欠陥があれば、発注側は修正や損害賠償を求められます（契約不適合責任）。
一方の準委任契約は、ベンダーに「業務を誠実に遂行する義務」はあるものの、完成までは保証しません。アジャイル開発や要件が流動的なフェーズで採用されることが多く、柔軟性が高い反面、発注側が積極的にディレクションしていく必要があります。アプリリプレイスでは、フェーズによって使い分けるのが実務的な進め方です。
要件定義・基本設計は不確実性が高いため「準委任」、詳細設計・開発・テストは要件が固まっているため「請負」、保守運用は継続業務のため「準委任」という組み合わせが一般的です。フェーズを問わず一律に請負契約にすると、要件変更のたびに契約変更が必要になり、プロジェクトが硬直化するリスクがあります。
契約不適合責任（旧：瑕疵担保）の実務的な押さえ方
2020年の民法改正で「瑕疵担保責任」は「契約不適合責任」に改正されました。請負契約で、アプリが契約の内容に適合しない場合、発注側は「追完請求（修補・代替物の引渡し）」「代金減額請求」「損害賠償請求」「契約解除」のいずれかを選べます。
実務上の注意点は、契約に合致する要件が明文化されているかどうかです。「アプリが正常に動作しない」というだけでは契約不適合を主張しにくいため、機能要件を仕様書・契約書に具体的に書いておく必要があります。たとえば「ユーザー認証機能において、正しいパスワードを入力した場合に100%ログインできること」のように書きます。
RFPの機能要件を詳細に書いておくことは、法的なリスクヘッジの観点からも欠かせない準備です。さらに、契約不適合責任の行使期間は「不適合を知った時から1年」です。そのため、アプリリリース後も一定期間、動作確認と記録を残しておくことが推奨されます。
下請法の適用条件と注意すべき支払いルール
アプリリプレイスを外注する際、発注側の企業規模と委託先の規模によっては「下請代金支払遅延等防止法（下請法）」が適用されます。下請法は、発注側（親事業者）が受注側（下請事業者）に対して不当に不利な取引条件を強いることを防ぐための法律です。大企業が中小の開発会社に発注する場合は、ほぼ確実に適用されると考えておく必要があります。
情報成果物（ソフトウェア）の委託で主な条件になるのは、「資本金3億円超の会社が資本金1,000万円超3億円以下の会社に発注する場合」です。または「資本金1,000万円超3億円以下の会社が資本金1,000万円以下の会社に発注する場合」も該当します。下請法で最も重要なルールは「60日以内の支払い」で、ベンダーから納品を受けた日（受領日）から起算して60日以内に支払わなければなりません。
起算日は「検収日」ではなく「受領日（納品を受けた日）」で、「検収に3か月かかったため、支払いが受領から90日後になった」場合は下請法違反となります。違反が認められると、公正取引委員会の勧告に加え、年率14.6%の遅延利息の支払い義務が生じます。発注側の管理部門・経理部門に、下請法の支払いルールを事前に共有しておく必要があります。
SLA（サービスレベル合意）の設計とペナルティ条項
保守運用フェーズで特に重要なのが、SLA（Service Level Agreement：サービスレベル合意）の設計です。SLAは、稼働率や応答時間などの品質水準を数値で定めた合意書で、保守運用契約には必ず含めるべきです。レスポンスタイムは、「API応答時間の95パーセンタイルが2秒以内」のように具体的な数値で定めます。
稼働率は「月間サービス稼働率99.9%以上（許容停止時間：月間約43分）」という水準が一般的です。ただし、メンテナンス時間を除外する免責事項と、測定方法（外形監視か内部監視か）も明記する必要があります。障害対応は、「重大障害（アプリ全停止）の初動対応：30分以内に連絡」「軽微なバグ対応：報告後5営業日以内に修正案を提示」のようにレベル分けして定めます。
ペナルティ条項は、「SLAを下回った場合に月額保守費用の〇%を減額」という形式が実務では一般的です。ただし、ペナルティが過大すぎるとベンダーが契約を嫌がったり保守コストが高くなったりするため、「稼働率が99.0%を下回った月は月額費用の10%を減額」程度が現実的です。さらに、地震・火災・通信回線障害等の不可抗力による免責事項も明記すると、ベンダーが適正価格で保守契約を結べます。
発注後のプロジェクト管理――ベンダーをコントロールする技術
契約を締結するとプロジェクトは動き出しますが、発注後の管理が甘いと、ベンダーに主導権を握られ、気づけば大幅な遅延や予算超過に陥りかねません。
発注側が主体的にプロジェクトを進めるための実践的な考え方を紹介します。
ILUO評価によるフェーズ完了判定の導入
多くのアプリリプレイスで問題になるのが、「フェーズ完了の判定基準」です。一般には「設計書やコードなどの提出」で完了を判定しますが、これだけでは次のフェーズへ移れる状態かどうかを保証できません。そこで有効なのが、「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スキル評価を使ったフェーズ完了判定を導入すると、「提出したら完了」という形式的な判断を避けられます。万一プロジェクトが暗礁に乗り上げたときは、サンクコストにとらわれず、今後の見通しだけで継続か中止かを判断する冷静さが求められます。
アプリリプレイスの発注は、準備と知識があれば必ず成功に近づきます。本記事の内容を、ぜひ実務に役立ててください。
▼RFP作成前に読みたい無料ホワイトペーパーはこちらをご覧ください。
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。