アプリ刷新を外部に発注する進め方は、社内準備、RFP（提案依頼書）の作成、ベンダーの比較と選定、契約締結、発注後の管理と現場定着の順に進みます。どの段階でも、発注側が前提や役割を言葉にして残しておくと、後の手戻りを防ぎやすくなります。
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
アプリ刷新を発注する前にやるべき社内準備
アプリ刷新プロジェクトの成否は、ベンダーに発注する前の社内準備の質で大きく変わります。開発会社の技量が高くても、発注側の準備が足りなければ要件が正しく伝わらず、「作ってほしかったものと違う」という結果になりかねません。
実際に、2025年のNHKと日本IBMの訴訟でも、発注側が「移行要件を100%達成する」という非現実的な前提をベンダーに押し付けたことで、双方の認識が食い違い、訴訟にまで発展しています。大規模な案件に限らず、準備不足による失敗は日常的に起きています。
現行アプリの棚卸しと技術的負債の可視化
まず取り組むべきは、現行アプリの全体像を正確につかむことです。社内のエンジニアや業務担当者へのヒアリングを丁寧に行い、次の2点を押さえておきます。
- 機能と技術スタック：どんな機能があり、どの技術スタック（言語・フレームワーク・ライブラリのバージョン）で動いているかを一覧にします。
- 非公式な機能：長年運用されてきたアプリでは設計書が失われていることも珍しくないため、ヒアリングで現場独自の機能（いわゆる「野良改修」）も洗い出します。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・アプリ刷新の完全ガイド
ベンダー選定の参考になるのが、キングジム社のシステム刷新の事例です。
- 採択されたベンダー：複数のベンダーに提案を依頼したところ、最も高額な見積もりを提示したベンダーでした。
- 採択の理由：そのベンダーだけが「まず旧システムの構成を全部洗い出すことから始める」と明言したことでした。
他のベンダーが「うまく移行できます」と曖昧に答えるなか、技術的負債に正面から向き合う姿勢が信頼につながったのです。つまり、発注側が技術的負債を洗い出しておくと、それ自体が優良なベンダーを見極める手がかりにもなります。
ネイティブ vs クロスプラットフォームの方針決定
アプリ刷新ならではの決めごととして、開発方針があります。iOSとAndroidそれぞれ専用のネイティブアプリとして作るか、React NativeやFlutterといったクロスプラットフォーム技術で一元的に作るかを選ぶ判断です。この選択は、コスト・品質・開発期間・将来の保守性に大きく影響します。
判断を曖昧にしたままRFP（提案依頼書）を作ると、ベンダーごとに前提の違う提案が集まり、比べること自体が難しくなります。
ネイティブとクロスプラットフォームは、重視する条件によって向いている場面が分かれます。
- ネイティブ：カメラ・生体認証・プッシュ通知など端末固有の機能をフルに使いたい場合や、最高水準のUI/UXの性能が必要な場合に向いています。
- クロスプラットフォーム：開発コストを抑えたい、リリースを早めたい、社内のエンジニアが限られているといった事情がある場合に選択肢になります。
自社のユーザー層の端末の比率や、競合アプリの技術的な傾向も判断材料になります。この方針は発注担当者だけで決めず、技術担当者やマーケティング担当者、経営陣と話し合って合意しておくことが欠かせません。
予算確保のための稟議書に盛り込むべき情報
アプリ刷新では、初期開発費用だけでなく、リリース後の保守・運用費、ストア申請対応、OSアップデートへの追随費用まで含めた総所有コスト（TCO）を稟議書に示すと、承認につながります。「開発費用：○○万円」だけを記した稟議書では、後から追加費用が出るたびに再稟議が必要になり、プロジェクトの進みが大きく遅れます。
そこで目安として、初期開発費用の20〜30%を年間の保守費用と見積もり、3〜5年分の総コストを示すと説得力が増します。さらに、現行アプリを放置した場合のリスク（セキュリティ脆弱性・ユーザー離脱・競合優位性の喪失）を数値で示して並べると、投資対効果も明確になります。
RFP（提案依頼書）の作り方【実務テンプレート付き】
RFP（Request for Proposal：提案依頼書）は、複数のベンダーに同じ条件で提案を出してもらうための公式文書です。RFPが曖昧だと、各社の提案内容や見積もりの範囲、前提条件がそろわず、比べられない提案書が集まってしまいます。アプリ刷新のRFPには、Web系システムとは異なる記載事項があるため、その違いを押さえておく必要があります。
アプリ刷新RFPに記載すべき項目と書き方のポイント
アプリ刷新のRFPには、次の項目を必ず入れておく必要があります。
- プロジェクトの背景と目的：なぜ今このタイミングで刷新するのか、何を改善したいのかを書きます。
- 現行システムの概要：技術スタックやユーザー数、月間アクティブユーザー、現在の不具合や課題を具体的に示します。
- 機能要件と非機能要件：三段階（必須・あると望ましい・スコープ外）で整理し、パフォーマンス要件（ページロード時間、同時接続数）やセキュリティ要件も書きます。
- アプリ刷新に特有の記載事項：対応プラットフォームとOSバージョンの範囲、ストア申請（App Store・Google Play）の担当範囲を書きます。
- 特殊機能とブランド：プッシュ通知・ディープリンク・アプリ内課金などの特殊機能の有無、既存ブランドガイドラインへの準拠の要否を示します。
特に、App Store/Google Playの審査対応を開発費用に含めるかどうかは、ベンダーによって見解が大きく異なります。契約後のトラブルを防ぐため、RFPの段階で明示しておくことを強く勧めます。
UI/UXデザインと開発の分離発注の検討
アプリ刷新では、UI/UXデザインを専門のデザイン会社に、エンジニアリング（実装）を開発会社に、それぞれ別々に発注する「分離発注」という方法もあります。分離発注の利点は、デザインと開発のそれぞれの専門性を生かせる点です。
優れたデザイン会社が必ずしも開発に強いとは限らず、逆に開発力の高い会社がUI/UX設計を苦手とする場合も少なくありません。特に、ユーザー体験が競合優位性に直結するBtoC向けアプリでは、デザインに専門会社を起用する価値があります。一方で、分離発注には欠点もあります。
- 連携の管理：発注側の役目になるため、プロジェクトマネジメントの負荷が増えます。
- 仕様と技術のずれ：デザイン仕様と技術の実現性がずれた場合の調整も、発注側が負うことになります。
社内にプロジェクトマネージャーを置けるなら分離発注も機能しますが、難しければワンストップで対応できる会社を選ぶほうがリスクを抑えられます。RFPには「一括発注希望」か「設計・開発の分離発注可能」かを明記し、ベンダーに対応の可否を確認しましょう。
比較しやすい提案を引き出すためのRFP設計
提案を比べやすくするには、RFPで「提案書に必ず記載すべき項目」を指定することが有効です。具体的には、開発体制（プロジェクトマネージャーやエンジニアの人数・経験年数・稼働率）と、工程別のスケジュール（要件定義・設計・開発・テスト・ストア申請の各期間）を指定します。
見積もりの費目内訳（工数・単価が確認できる形式）や、リスク事項と対応策、保守・運用の体制と費用も同じように指定しておくと、比較の軸がそろいます。これらを統一した形式で提出させれば、金額だけでなく、実行可能性・リスク管理能力・チームの質で比べられるようになります。
ベンダー比較・選定プロセスの進め方
RFPを配布したら、複数のベンダーから提案を受け取り、構造的に比較する段階に入ります。ベンダー選定は、価格を比べるだけでなく、プロジェクトの成功確率を高めるためのリスク評価でもあります。ここで手を抜くと、発注後に「やはりこのベンダーには無理だった」という事態になりかねず、手戻りが膨大なコストを生みます。
最低3社からの提案取得と評価基準の設定
ベンダー選定では、最低3社、可能であれば5社程度から提案を取得することが推奨されます。1〜2社では比べる軸が定まらず、価格が妥当かどうかも判断しにくくなります。3社以上あれば、提案内容・見積もり・スケジュールの相場感がつかめるため、突出して安い見積もりや非現実的なスケジュールを出すベンダーにも、早い段階で気づけます。
評価基準は、提案を受け取る前に評価委員会（発注側の複数名）で合意しておく必要があります。代表的な評価軸と重み付けは次のとおりで、参考になります。
- 技術力・実績：40%
- プロジェクト管理体制：25%
- 価格：20%
- 保守・運用対応力：15%
ただし、自社プロジェクトの優先事項に合わせて調整してください。特にアプリ刷新では、モバイル開発の実績（iOS/Android両対応の実績件数）と、UI/UX設計の能力を個別の評価項目として設けることを勧めます。採点は複数人で行って平均すると、特定の担当者の主観による偏りを排除できます。
リファレンスチェックの実施手順【独自テクニック】
ベンダー選定で最も見落とされやすく、それでいて効果の高い確認手段が「リファレンスチェック（参照確認）」です。ベンダーの過去のクライアントに直接連絡を取り、プロジェクトの実態を確かめる方法です。提案書の実績や成功事例は、どのベンダーも肯定的な面を中心に載せます。
実際の発注担当者に直接話を聞くと、「提案では3ヶ月と言っていたが実際は5ヶ月かかった」「途中でキーエンジニアが交替し、品質が落ちた」といった、提案書からは分からない情報が得られます。
あるプロジェクトでは、リファレンスチェックによって、最終候補のベンダーが前の案件で6ヶ月以上の大幅な遅延を起こしていたことが分かり、選定から外すことができました。参照先は、ベンダーの紹介と別ルートの2通りで集めます。
- まず、ベンダーに「直近3件の類似案件の担当者を紹介してほしい」と依頼します。
- 別ルートでも聞く：ベンダーが選んだ先だけに聞くと肯定的な声に偏るため、可能であれば業界の人脈や口コミ情報も並行して集めます。
確認したいのは、次の4点で、ここが核心です。
- 工期：当初のスケジュールどおりに完了したか
- 費用面：追加費用が発生したか、その理由は何か
- 品質面：品質上のトラブルはあったか
- 今後の発注：同様のプロジェクトがあれば再度依頼するか
このリファレンスチェックを行うだけで、ベンダー選定の信頼性は大きく高まります。
モバイル・UI/UX専門技術力の評価基準
アプリ刷新では、モバイル開発ならではの能力も確かめる必要があります。提案のプレゼンでは、具体的に質問すると効果的です。たとえば、過去にApp StoreやGoogle Playの審査で拒否された経験があるか、あればどう対処したかを尋ねます。
ほかにも、次のことを聞くことができます。
- OSのメジャーアップデート：iOS・Androidの新バージョンリリース時の対応フロー
- 性能面：パフォーマンスチューニングやバッテリー消費の最適化の実績
これらに具体的なエピソードを交えて答えられるベンダーは、実際の現場経験を持っていると判断できます。
UI/UXの評価では、ポートフォリオに加えて、次のとおり確かめてください。
- 検証の設計：ユーザーテストや使いやすさの検証をどう設計しているか
- アクセシビリティ：視覚障害者・高齢者への配慮にどう対応するか
- デザインシステム：コンポーネントライブラリを納品物として出せるか
特に納品物の扱いは、将来の保守や改修のコストに大きく響くため、見落としやすい交渉点です。
契約締結のチェックリスト
ベンダーを選んだら、次は契約締結の段階です。この段階で曖昧にした事項は、後々のトラブルの原因になります。スルガ銀行と日本IBMの訴訟（95億円の白紙撤回）では、自社の業務要件に合わないパッケージを選んだうえ、契約上の責任の分け方が不明確だったことが問題を複雑にしました。契約書は法的な保護の最後のよりどころですが、トラブルが起きてから読み返すものではなく、発注前にすみずみまで確認しておくものです。
請負契約と準委任契約の選択基準
IT開発の契約は、大きく「請負契約」と「準委任契約」に分かれます。
- 請負契約：ベンダーが「完成物を納品する義務」を負う契約で、アプリのリリースのように成果物を明確に定められる場合に適しています。
- 準委任契約：「作業を遂行する義務」のみを負う契約で、要件定義の段階や、仕様が流動的なアジャイル開発、保守・運用の段階に合っています。
アプリ刷新では、工程によって契約形態を使い分けるのが実務では一般的です。次のように使い分けます。
- 要件定義・設計：仕様変更が多いため準委任契約とします。
- 設計が固まった開発工程：請負契約を用います。
こうすると、発注側はベンダーに完成の責任を問えるうえ、不確実性の高い上流工程で過大なリスクをベンダーに負わせることなく、建設的な協力関係を保てます。請負契約であっても、発注側が要件を頻繁に変えると契約上の関係が複雑になるため、「変更管理プロセス（Change Control Process）」を契約に明記しておくことが必要です。
App Store/Google Play審査対応の契約上の位置づけ
アプリ刷新ならではの契約上の注意点に、ストア審査対応の扱いがあります。App StoreとGoogle Playへの申請と審査の通過は、開発が完了したからといって自動的に得られるものではありません。Appleのガイドライン違反（プライバシーポリシーの記載不備、特定の機能制限など）やGoogleのポリシー違反によって審査が却下されることは珍しくなく、場合によっては修正対応を何度も求められます。
この審査対応を誰が担うかは、契約書に明確に定めておく必要があります。開発ベンダーが「開発完了＝納品完了」とみなし、ストア審査対応を対象外とした場合、審査で却下が続くと、発注側が自力で対応するか、追加費用を払ってベンダーに頼むしかなくなります。契約書には次の事項を明記し、事前に合意しておくことを強く勧めます。
- 完了の定義：「ストア申請・審査通過をもって当該工程の完了とする」と明記します。
- 修正対応：審査却下時の修正対応の回数の上限と、その費用の負担のあり方。
- 再申請：初回リリースだけでなく、OSアップデート時の再申請も対応範囲に含めるかどうかを確認します。
瑕疵担保責任・追加費用・損害賠償の交渉ポイント
請負契約の「瑕疵担保責任」は、納品後に不具合（バグ）が見つかった場合に、ベンダーが無償で修正する義務を定めたものです。民法改正（2020年施行）で「契約不適合責任」と呼ばれるようになりましたが、実務上の対応は大きく変わっていません。
問題になりやすいのは、「瑕疵（契約不適合）」の定義があいまいな場合です。要件定義書や設計書に明記されていない動作について、ベンダーは「仕様外」と主張し、発注側は「当然含まれるべき機能」と主張して対立が生じます。この認識のずれを防ぐには、契約書の別添として「機能一覧と動作仕様」を詳しく付け、それを基準となる文書だと明記しておくことが欠かせません。
損害賠償の上限額について、多くのベンダーは「受領した報酬の範囲内」または「直接損害のみを対象」とする条項を設けています。交渉で押さえたいのは、次の3点です。
- 間接損害：大規模なシステム障害が起きた場合、ビジネス機会の損失は間接損害に分類されるおそれがあるため、発注側として過度な期待は禁物です。
- 故意・重大な過失：ベンダーの故意や重大な過失による損害について、上限を設けないよう交渉するのは合理的です。
- 追加費用：途中で状況が変わり追加費用が生じる場合の承認者と合意書の取り交わし時期を契約書に定めておくと、口頭合意によるトラブルを防げます。
発注後のプロジェクト管理と現場定着
発注が済んでも、発注側の役割は続きます。アプリ刷新の成功には、開発の各段階での継続的な関わりと、リリース後の現場への定着が欠かせません。「ベンダーに任せた」という姿勢のまま進めると、ベンダー側でも課題を抱え込んで報告が遅れ、気づいたときにはプロジェクトが取り返しのつかない状態になっていた、というケースが後を絶ちません。
チェンジマネジメントとデジタルデバイドへの対応
アプリ刷新で現場の業務の流れが変わる場合、従業員のITリテラシーの差（デジタルデバイド）にどう対応するかが、プロジェクトの成否を左右します。技術的に優れたアプリができても、現場の利用者が使いこなせなければ、投資効果はゼロのままです。実際、多くのDXプロジェクトが「システムは完成したが、現場に浸透しなかった」という結末を迎えています。
有効な方法は、各部署から「システムキーパーソン」を選び、開発の初期から巻き込むことです。テクノロジーに詳しくなくてもかまいません。キーパーソンは、IT推進部門と現場の橋渡し役として、次の役割を担います。
- ユーザーテスト：現場の利用者として参加する役割
- フィードバック：現場の声の収集
- 同僚への研修：周りの社員への使い方の指導
選ぶ際の基準は、自分の職場の業務を誰よりも深く理解し、周囲からの信頼が厚い人物かどうかです。巻き込んでおくと、部門間の利害調整もスムーズになり、「あの部署の要望だけ優先された」という不満も抑えられます。研修も、マニュアルを配るだけでなく、小規模グループでのハンズオン研修や、困ったときに相談できるサポート窓口を設けると、定着率が高まります。
段階的リリース（ベータ版→正式版）による並行稼働戦略
アプリ刷新では、旧アプリから新アプリへ一斉に切り替えると、大きなリスクを伴います。全ユーザーが同時に新しい環境へ移ると、潜在的なバグや使い勝手の問題が一度に表面化し、カスタマーサポートへの問い合わせが殺到しかねません。そこで有効なのが、「段階的リリース（フェーズドロールアウト）」の戦略です。
具体的には、次の順に進めます。
- α版：社内の限られたユーザーでテストします。
- β版：外部の限定ユーザーで検証します。
- 正式版：問題がなければ、全ユーザーへ公開する段階に移ります。
App StoreとGoogle Playは、どちらも「段階的公開（Phased Release）」の機能を備えており、リリース後の1〜7日をかけて対象ユーザーの割合を1%→5%→10%と段階的に広げられます。
この期間中に重大な不具合が見つかれば、すぐに配信を止めて修正版をリリースできるため、被害を最小限に抑えられます。
契約上は、この段階的リリース計画（各フェーズの完了条件・移行判断基準・ロールバック手順）をベンダーとの合意文書に盛り込んでおくことで、責任の所在を明確にできます。特に、段階の区切りと移行の判断を曖昧にしないことが大切です。
- 完了条件：各フェーズをどこで終えたとみなすか
- 移行判断基準：次のフェーズへ進んでよいかを決める条件
- ロールバック：問題が出たときに前の版へ戻す手順
プロジェクト炎上時の「撤退の作法」【競合にない切り口】
どれだけ準備を尽くしても、プロジェクトが深刻な状態に陥ることはあります。そのとき、最も難しい判断の一つが「撤退するかどうか」です。これまでの費用や時間を「サンクコスト（埋没費用）」として切り捨て、プロジェクトの中止や大幅な仕切り直しを決める勇気は、経営判断として欠かせません。
スルガ銀行のケースでは、問題の兆候が明らかになっても当初の方針にこだわり続けたことが、最終的な95億円の損失を招いたとも言われています。
撤退を判断するときの「契約上の身の守り方」として、まず現在の契約が請負か準委任かを確認します。準委任契約では、やむを得ない事情がなければ、相手に損害が生じた場合に賠償責任が生じる可能性もあります。
- 準委任契約：民法第651条に基づき、いつでも契約を解除できます。
- 請負契約：未完成なら発注側から解除できますが、ベンダーは既に履行した部分の報酬を請求できます。
プロジェクトを中止する場合も、ソースコードや設計書、テスト仕様書といった成果物の引き渡しを確実に受け、将来の再起動や別ベンダーへの引き継ぎに備えることが大切です。また、再起動を検討するとき、前のベンダーに依存した設計や特定技術への過度な依存が残っていると、再起動のコストが跳ね上がります。
特定ベンダーへのロックインを防ぐ設計方針（標準技術の採用、インターフェース定義の文書化）は、リスクを抑える備えとして、発注前の段階から意識しておく価値があります。
アプリ刷新は、組織全体の業務改革と密接に結びついています。本記事で扱った各段階を丁寧に踏めば、プロジェクトの成功確率を大きく高められます。特に、リファレンスチェックや段階的リリース計画、撤退戦略の事前策定といった、一般的な記事では触れられない実務の知見を生かして、貴社のアプリ刷新を成功に導いていただければ幸いです。
このテーマ全体の流れを知りたい方は、以下の記事をご覧ください。
▼全体ガイドの記事
・アプリ刷新の完全ガイド
▼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を創業。