アプリ更改を外部のパートナーに依頼しようとしたとき、最初の関門になるのが「何を、どこまで、どんな条件で頼むのか」を文書としてまとめる作業です。OSのサポート終了や端末更新、ストア要件変更といった契機が迫るなかで、現状を正しく把握しないまま見積もりだけを取ると、後になって対象範囲の認識がずれ、追加費用やスケジュール遅延を招きます。アプリ更改を成功させる土台は、現状を可視化するアセスメント、更改の中身を固める要件定義、そして発注条件をまとめるRFP（提案依頼書）という3つのステップを丁寧に踏むことにあります。
本記事では、アプリ更改のアセスメント・要件定義・RFPについて、現状分析で押さえるべき観点、要件定義に盛り込むべき項目、RFPに記載すべき内容とベンダー評価の基準まで、発注に向けた実務の流れに沿って解説します。進め方そのものの解説ではなく、「発注準備として何を文書化し、何を基準に選ぶか」に焦点を絞っているのが本記事の特徴です。あわせて、更改全体の手法や費用感を体系的にまとめたアプリ更改の完全ガイドもご覧いただくと、本記事の発注準備の話を全体像の中で位置づけやすくなります。本記事では、その完全ガイドでは概要にとどめた「アセスメントからRFPまでの具体的な作り方」を掘り下げます。
▼全体ガイドの記事
・アプリ更改の完全ガイド
アセスメント：現状（AS-IS）を可視化する
アプリ更改の出発点は、現行アプリの現状（AS-IS）を可視化するアセスメントです。刷新プロジェクトが失敗する大きな原因として、現行システムの仕様書欠如やブラックボックス化による「要件定義の不十分さ」が広く指摘されています。アプリの場合も、当初の開発担当者がすでに離れ、何がどう動いているのか正確に把握できないまま更改に入ると、見積もりの精度が下がり、想定外の追加作業が後から噴出します。
アセスメントの目的は、更改の判断材料を客観的なデータとして揃えることです。費用相場でも、要件定義・業務棚卸しのみで200万〜500万円という目安が示されるように、現状分析そのものに相応のコストと工数をかける価値があると認識されています。ここを省略して見積もりに進むと、結局は後工程で何倍もの手戻りを招きます。アセスメントは、急がば回れの典型といえる工程です。
資産棚卸しと依存関係の可視化
アセスメントで最初に行うのは、アプリを構成する資産の棚卸しです。利用している開発言語やフレームワークのバージョン、依存している外部ライブラリ・SDKの一覧、サーバーAPIや外部サービスとの連携箇所、そして各機能がどのコードに紐づくかを洗い出します。とくにOS・SDKサポート終了が契機の更改では、どのライブラリがサポート終了の影響を受けるのか、その影響がどの画面・機能に波及するのかを明確にすることが核心です。
この依存関係の可視化には、専用のツールや手法が役立ちます。アプリケーション資産の複雑度や依存関係を可視化する取り組みは、システムモダナイゼーションの分野で重視されており、富士通が提供する「ソフトウェア地図」のように資産を地図として整理する手法が知られています。アプリ更改でも、依存関係を地図のように見える化してから着手すると、影響範囲の見落としや「直したつもりが別の場所を壊す」といった事故を防げます。
棚卸しの結果は、後のRFPで「現行構成図」として提示する基礎資料にもなります。発注先のベンダーが正確な見積もりを出せるかどうかは、この現状資料の精度に大きく依存します。曖昧な現状認識のまま発注すると、ベンダー側も見積もりにリスク分を厚く乗せざるをえず、結果として費用が膨らみます。可視化された現状こそが、適正な見積もりを引き出す前提になります。
更改後の姿（TO-BE）とのギャップを定義する
現状（AS-IS）を可視化したら、次に更改後にありたい姿（TO-BE）を定義し、両者のギャップを明確にします。OSサポート終了に追従するだけでよいのか、この機会に保守しやすい構成へ作り替えるのか、利用者の使い勝手まで改善するのかで、更改の規模は大きく変わります。アセスメントの段階で「今回の更改で何を達成したいのか」というゴールを言語化しておくことが、後の要件のブレを防ぎます。
ギャップを定義する際は、契機となった外部要因への対応を最低限の必須要件として置き、その上に「あると望ましい改善」を積み上げる構造にすると整理しやすくなります。必須要件と任意要件を分けておくことで、予算やスケジュールの制約に応じて何を残し何を次回に回すかを判断しやすくなり、限られた予算を重要な領域へ集中できます。
このTO-BEの定義は、次の要件定義フェーズへの橋渡しになります。アセスメントが「現状を正しく知る」工程だとすれば、要件定義は「更改の中身を具体的に固める」工程です。両者を地続きに進めることで、現状認識とゴールがずれない一貫した更改計画が組み立てられます。
要件定義：更改の中身を具体化する
アセスメントで現状とゴールが明確になったら、要件定義で更改の中身を具体化します。アプリ更改の要件定義は、新規開発とは異なり「既存の動きをどこまで維持し、どこを変えるか」を軸に整理する点が特徴です。利用者がすでに慣れ親しんだ操作や、業務に組み込まれた機能を不用意に変えると混乱を招くため、維持すべき仕様と変更すべき仕様を切り分ける作業が中心になります。
機能要件：維持・変更・廃止を切り分ける
機能要件の整理では、現行アプリの機能を一つずつ「維持」「変更」「廃止」に分類します。維持する機能は、新しい基盤の上でも同じ動きを再現する必要があるため、現行の挙動を仕様として正確に書き起こします。変更する機能は、なぜ変えるのか、変更後にどう動くべきかを明記します。廃止する機能は、利用状況のデータをもとに「本当に使われていないか」を確認したうえで判断します。
この切り分けで重要なのは、客観的なデータに基づいて判断することです。担当者の感覚だけで「この機能は使われていないだろう」と廃止すると、一部の利用者から強い反発を招くことがあります。利用状況の計測データや問い合わせ履歴を根拠にすることで、納得感のある取捨選択ができます。更改は機能を増やす場ではなく、本当に必要な機能だけを残して整理する好機でもあります。
機能要件を書き起こす際は、各機能の入力・処理・出力を具体的に記述し、曖昧な表現を避けることが肝心です。「使いやすくする」といった抽象的な要件は、ベンダーによって解釈が分かれ、後のトラブルの種になります。要件は誰が読んでも同じ動きをイメージできる粒度まで具体化することが、見積もりの精度と完成物の品質を左右します。
非機能要件と移行後のKPI
機能要件と並んで重要なのが、性能・セキュリティ・保守性といった非機能要件です。アプリの起動速度や画面の表示速度、同時アクセス時の安定性、通信のセキュリティ水準などを具体的な数値で定義します。OSやストアが求めるセキュリティ要件は年々厳格化しているため、現行水準の維持ではなく、更改後に求められる基準を満たすことを前提に要件を立てます。
あわせて、更改後に達成したいKPIを定義しておくことが、更改の成果を測るうえで欠かせません。クラッシュ率を何ポイント改善するか、保守工数を何割削減するか、リリース頻度をどこまで上げるかといった指標を事前に置くことで、更改が「やって終わり」になるのを防げます。製造業の基幹系刷新で夜間バッチを8時間から90分へ短縮し保守費を約65%削減した事例のように、定量目標を最初に置くからこそ、達成度を後から評価できます。
非機能要件とKPIは、後のRFPで「移行後のKPI」として明記する重要な項目になります。これらを曖昧にしたまま発注すると、完成したアプリが「動くけれど遅い」「保守が楽にならない」といった結果に終わりかねません。測定可能な基準をあらかじめ定めることが、更改の費用対効果を担保します。
RFP作成とベンダー評価の基準
アセスメントと要件定義で固めた内容を、発注先に伝える文書としてまとめたものがRFP（提案依頼書）です。RFPの品質は、ベンダーから引き出せる提案と見積もりの質を直接左右します。曖昧なRFPには曖昧な提案しか返ってこず、各社の提案を横並びで比較することもできません。本章では、RFPに盛り込むべき項目と、提案を受けた後のベンダー評価の基準を整理します。
RFPに盛り込むべき項目
アプリ更改のRFPには、少なくとも次の項目を盛り込みます。
・更改の背景と目的（OSサポート終了・端末更新・ストア要件変更などの契機）
・現行構成図（アセスメントで可視化した資産・依存関係・連携の現状）
・機能要件（維持・変更・廃止の一覧）と非機能要件（性能・セキュリティ）
・移行後のKPI（クラッシュ率・保守工数・リリース頻度などの目標値）
・希望するスケジュールと、ストア審査などの外部締め切り
・想定する移行方式（段階移行か一括移行か）と運用・保守の範囲
とくに「現行構成図」「性能要件」「移行後のKPI」は、RFPに含めるべき重要項目とされています。これらが明記されていれば、ベンダーは前提を揃えた状態で提案でき、各社の提案を同じ土俵で比較できます。逆にこれらが欠けると、見積もりに大きなばらつきが生じ、安いように見えて実は範囲が狭いだけ、という見かけの安さに惑わされかねません。
RFPは一方的な要求書ではなく、ベンダーとの対話の土台でもあります。すべてを発注側で決めきれない論点については、「貴社の推奨する移行方式を提案してください」といった形で提案を求めることで、ベンダーの知見を引き出せます。決めるべきところは明確に決め、専門的な判断はベンダーに委ねるという、要求と提案依頼のバランスがRFPの質を高めます。
ベンダー評価の5つのチェックポイント
提案を受けた後のベンダー選定では、価格だけで判断せず、客観的な基準で評価することが重要です。アプリ更改のような稼働中サービスの刷新では、ベンダー評価のチェックポイントとして次の5つが参考になります。
・同業界・同規模のアプリ更改や刷新の実績があるか
・一括ではなく段階移行を設計できる力があるか
・更改時のダウンタイムや審査リスクを具体的に見積もれているか
・公開後の不具合対応を含む保守体制が整っているか
・品質・セキュリティに関する認証（ISO9001／27001等）を備えているか
これらの観点は、稟議を通すための客観的な根拠にもなります。とくにアプリ更改では、稼働中アプリを止めずに切り替えられるかが成否を分けるため、段階移行の設計力とダウンタイムの見積もり精度は重視すべきポイントです。実績を確認する際は、抽象的な「豊富な実績」ではなく、自社と近い契機・規模の具体的な事例を示せるかどうかを見極めます。
ベンダーへの「丸投げ」は、刷新が炎上する典型的な要因の一つです。要件定義をベンダー任せにすると、認識のずれや過剰な追加開発を招きやすくなります。発注側がアセスメントと要件定義をしっかり行い、RFPで前提を揃えたうえで、客観的な基準でベンダーを選ぶ。この一連の準備こそが、アプリ更改を成功に導く最大の保険になります。
まとめ
本記事では、アプリ更改のアセスメント・要件定義・RFPについて、発注準備の流れに沿って解説してきました。まずアセスメントで現行アプリの資産と依存関係を可視化し、更改後のありたい姿とのギャップを定義します。次に要件定義で、機能を維持・変更・廃止に切り分け、性能やセキュリティといった非機能要件と移行後のKPIを具体的な数値で定めます。そしてRFPに、背景・現行構成図・機能要件・移行後のKPI・スケジュールを盛り込み、客観的な5つのチェックポイントでベンダーを評価します。
この一連の準備で一貫して重要なのは、「現状を正しく把握し、要件を具体化してから発注する」という順序です。現状分析を省いて見積もりに進んだり、要件を曖昧にしたままベンダーに丸投げしたりすると、追加費用やスケジュール遅延、完成物の品質低下といった問題を招きます。要件定義・業務棚卸しに200万〜500万円を投じる価値があるとされるのは、この準備が後工程の手戻りを大きく減らすからにほかなりません。
自社のアプリ更改を発注準備の段階から進める際は、まずアセスメントで現状を可視化することから着手してみてください。そのうえで、更改全体の手法や費用感、進め方の選択肢を体系的に押さえたい場合は、完全ガイドもあわせて活用すると、発注準備を全体像の中で確かめられます。丁寧な準備こそが、適正な見積もりと信頼できるパートナー選定を引き出し、アプリ更改を成功へ導く確かな土台になります。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。