アプリ更改の発注は、発注前の準備、RFI・RFPの作成、ベンダー提案の評価、契約締結、発注後のプロジェクト管理という順に進みます。
現行システムの資産を引き継いで刷新するアプリ更改には、新規開発にはない落とし穴があります。各段階で何を用意し、どこでつまずきやすいかを先に押さえましょう。
▼全体ガイドの記事
・アプリ更改の完全ガイド
スマホアプリ開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
アプリ更改の発注前の準備
アプリ更改プロジェクトが失敗する原因の多くは、発注前の準備不足にあります。現行アプリの問題点が曖昧なまま外注を始めると、ベンダーへの要件伝達が不正確になり、納品後に「思っていたものと違う」という事態になりがちです。発注側でまず行うのは、現行アプリの課題を洗い出すことと、ソースコードや設計書を引き継ぎに備えて整えることです。
現行アプリの課題分析とユーザーインサイト調査
アプリ更改の出発点は、現行アプリが「なぜ作り直す必要があるのか」を定量・定性の両面から明確にすることです。「古くなった」「動作が遅い」といった感覚的な理由のままでは、ベンダーに適切な要件を伝えられません。そこで、月間アクティブユーザー数の推移、クラッシュ率、レビュー評価の変化、サポートへの問い合わせ件数などを集め、現状の問題を数値で示せるように整理しましょう。
加えて、実際のユーザーへのインサイト調査も欠かせません。社内の印象だけで課題を決めると、ユーザーが本当に困っている点とずれたアプリ更改になりかねません。アンケートやインタビュー、アプリ内のヒートマップ分析などを使い、ユーザーが離脱する箇所や使いにくいと感じている画面を具体的に把握します。
こうした定量・定性データは、ドキュメントにまとめておくと、後工程のRFP作成で具体的な要件として落とし込めます。また、競合アプリとの機能比較も重要な準備作業で、自社アプリのどの機能が競合より劣っているかを整理し、更改後の機能の優先度付けに活用します。この段階で機能を次の3段階に分類しておくと、後のベンダーとのスコープ交渉が格段にスムーズになります。
- 必須機能：初回リリースに欠かせない機能
- あれば良い機能：優先度は下がるが、対応するとよい機能
- 将来的に対応する機能：今回の更改では必須とせず、後の段階で対応する機能
ソースコード・設計書の整理と引き継ぎ準備
アプリ更改の大きな特徴の一つは、現行システムの資産を新しいベンダーに引き継ぐ必要がある点です。新規開発と異なり、既存のソースコードや設計書を精査して、何を引き継ぎ、何を捨てるかを判断する工程が必要になります。
この引き継ぎ準備が不十分だと、ベンダーが現行システムを理解するための調査工数が膨らみ、見積もり金額が跳ね上がったり、序盤の多くの時間が調査に費やされたりします。そのため、発注前にソースコードリポジトリのアクセス権限の整理、画面設計書・ER図・API仕様書などドキュメントの洗い出し、インフラ構成図の最新化を済ませておきましょう。
これらが整っているほど、ベンダーの見積もり精度が高まり、プロジェクト立ち上げ期間の短縮にもつながります。なお、設計書などが存在しない場合は、現行ベンダーや自社エンジニアに作成を依頼する工程を先に発注するのも有効です。
RFI・RFPの作成方法と実践テンプレート
発注前の準備が整ったら、次はベンダーへの情報提供依頼書（RFI）と提案依頼書（RFP）を作成します。これらの出来栄えが、集まる提案の質を左右するため、十分な時間をかけて丁寧に作る必要があります。特にアプリ更改では、両文書にアプリ固有の項目を入れる工夫が求められ、一般的なシステム開発の発注書とは異なります。
アプリ更改特有のRFI項目（iOS/Android対応・段階リリース実績確認）
RFI（情報提供依頼書）は、ベンダーの技術力・実績・体制を把握するための調査書です。アプリ更改では、一般的なRFI項目に加えて、アプリ固有の確認事項も盛り込みます。まずiOS・Android両OSへの対応実績について、現行アプリのプラットフォームをそのまま引き継ぐケースが多いため、両OSの経験が豊富なベンダーを選ぶ必要があります。
Flutter・React Nativeなどのクロスプラットフォームと、Swift・Kotlinなどのネイティブ開発について、それぞれの経験年数と納品実績をRFIで確認します。次に、段階的リリースの実施経験も確認します。アプリ更改では、ユーザーへの影響を抑えるため、全ユーザーへの一斉リリースではなく、一部から段階的に広げるロールアウト戦略が重要になります。
Google PlayのトラックやTestFlightを使った段階リリースの経験があるベンダーを選ぶと、リリース時の障害リスクを大幅に低減できます。このほか、App Store・Google Playの審査対応経験やAppレビューのA/Bテスト実施経験も確認しておくと、後の提案評価が容易になります。
RFPに盛り込むべき必須項目と書き方のコツ
RFP（提案依頼書）はベンダーへの正式な提案依頼です。この文書の完成度が、プロジェクト全体の質を左右します。ベンダーが比較可能な提案を作れるよう、RFPには次の5項目を記載します。
- 背景と現行環境：更改の目的、現行アプリの仕様、利用状況、課題
- 要件とUI/UX：機能・非機能の要件と、画面の使い勝手の方向性
- 引き継ぎ資産：ソースコード、設計書、インフラ情報の一覧
- 工程と体制：リリース時期、マイルストーン、役割分担
- 評価基準：提案を評価する観点と、選定の方法
書き方のコツとして特に重要なのが、「非機能要件」を明確にすることです。パフォーマンス要件（画面表示速度3秒以内など）、可用性要件（稼働率99.9%以上など）、セキュリティ要件（個人情報の暗号化方式など）を、具体的な数値で示します。
そうすれば、ベンダーは提案範囲を正確に把握でき、見積もり精度が格段に上がります。また、将来的に追加予定の機能もRFPに記載しておくと、ベンダーが拡張性を考えて設計してくれるため、後々の追加開発コストを抑えられます。
予算の記載方法と交渉の進め方
RFPに予算を書くかどうかは、発注担当者が迷いやすい問題です。予算を示せば適切な提案が来るという意見がある一方で、実務では予算を示さないケースが多くあります。予算の上限を示すと、多くのベンダーがその上限いっぱいに合わせた見積もりを出す傾向があるためです。
たとえば、2,000万円という上限を示すと、1,500万円で実現できる案件でも「2,000万円ちょうど」の提案が来やすくなります。そこで、次の2点を押さえると、発注側として有利に交渉しやすくなり、適正価格での提案を引き出せます。
- 交渉の姿勢：「競争入札形式で提案を受け付け、各社が独立して積み上げた見積もりを比較する」という姿勢をRFPで明示する
- 予算の書き方：「合理的な範囲であれば予算調整可能」と記載するにとどめ、具体的な数字は示さない
また、提案審査後に上位2〜3社と個別交渉に入る段階で初めて予算感を開示すると、価格競争を有利に進められます。ただし、スコープが非常に広い案件や提案準備に多大な工数がかかる場合は、ベンダーが参加を見送るリスクもあります。そのため、「数百万円規模」「数千万円規模」という程度の情報提示は、やむを得ない場合もあります。
ベンダー提案の評価・比較手法
複数のベンダーから提案を受け取ったら、公平で論理的な評価プロセスで選定を行います。「なんとなく良さそう」という感覚に頼らず、定量評価と定性評価を組み合わせた手法を使うと、選定の根拠を社内で共有でき、後悔のない意思決定につながります。
定量評価（スコアリングシート）の設計方法
スコアリングシートは、評価項目ごとに点数をつけて各ベンダーを数値で比べるための評価ツールです。評価項目と重みづけが公平性を左右するため、提案を受け取る前に評価基準を決めておく必要があります。
アプリ更改の一般的な配点は、①技術力・アーキテクチャの妥当性（25点）、②スケジュールの実現可能性（20点）、③価格・コストパフォーマンス（20点）です。残りは、④同種プロジェクトの導入事例・実績（15点）、⑤プロジェクト管理体制・体制図の充実度（10点）、⑥アフターサポート・保守体制（10点）です。
各評価者がそれぞれ採点し、複数名の平均点で順位をつける方式にすると、特定の個人の好みに左右されない客観的な評価が実現できます。また、価格評価は、最安値のベンダーを満点とし、そこからの乖離率に応じて減点する方式が実態に合っています。
定性評価（PMの対応力・企業文化との相性）の見極め方
定量評価で見えにくいのは、担当プロジェクトマネージャー（PM）の対応力と、自社の企業文化との相性です。アプリ更改は数か月から1年以上の長期プロジェクトになることも多く、担当PMと自社担当者の関係性が、プロジェクトの成否に直結します。PMの対応力を見極めるうえで特に重視したいのが、「曖昧な質問への回答の仕方」です。
プレゼンテーション後の質疑応答では、「要件が不明確なときにどのように対応しますか？」「想定外の問題が発生した際の判断フローを教えてください」のような、意図的に曖昧な質問を投げかけます。問題解決に向けた具体的なプロセスを答えられるPMは、実際のプロジェクトでもリスクに適切に対応できる可能性が高いといえます。
反対に、「お客様のご要望に柔軟に対応します」といった抽象的な回答しか返ってこない場合は、注意が必要です。
企業文化との相性は、発注側が重視する価値観を伝えたうえで、開発スタイルが合うかを確かめます。価値観の例は、次のような点です。
- 開発の方針：スピード重視か品質重視か
- 報告の頻度：どのくらいの間隔で報告を受けるか
- 課題発生時の報告：どのタイミングで報告を受けるか
たとえば、アジャイル開発で進めたいのに、ウォーターフォールしか経験がないベンダーに委託すると、進め方のすり合わせだけで多大な工数がかかります。
同点時の最終判断基準
評価の結果が上位2社で拮抗した場合は、最終判断の基準として、過去の類似プロジェクトの発注元企業への直接確認（レファレンスチェック）が有効です。ベンダーが提示した事例の発注元企業に連絡を取り、「実際の開発品質はどうでしたか？」「遅延や想定外の追加費用は発生しましたか？」「同じベンダーに再発注したいと思いますか？」の3点を中心に確認します。
ベンダー側が見せたい情報だけでなく、実際の顧客体験を直接聞けるため、提案書や口頭説明では見えにくい信頼性を判断する手段として非常に有効です。
契約締結時に押さえるべきリスクヘッジ
ベンダーを選んだら、いよいよ契約締結に進みます。アプリ更改の契約は、新規開発以上に複雑なリスク要因を抱えています。現行システムの引き継ぎに関わる知的財産権の問題、要件変更による追加費用のトラブル、納品後の不具合対応の責任範囲などは、契約書に適切な条項がないと、後で深刻な紛争に発展するケースがあります。
ソースコード所有権・SLA・契約形態の取り決め
アプリ更改で特に重要なのが、「ソースコード所有権（著作権）」の取り決めです。新規開発では発注元が著作権を持つことが多い一方、更改ではベンダー独自のライブラリやフレームワークの扱いが曖昧になりやすいです。プロジェクト終了後に別のベンダーへ乗り換えようとした際、「このコードはうちの著作物だから提供できない」というトラブルが、実際に起きています。
契約書には次の3点を明記することを強く推奨します。
- 更改後のアプリのソースコード著作権は発注者に帰属する旨
- ベンダー独自のライブラリ・フレームワークの使用許諾（ライセンス）の範囲と条件
- プロジェクト終了後にソースコード・設計書一式を納品する義務
この3点が契約書に明確に記載されているかを、必ず確認してください。
SLA（サービスレベルアグリーメント）は、リリース後の保守・運用フェーズに適用される取り決めです。次のような項目を数値で合意しておくと、障害対応での認識のずれを防げます。
- バグ発生時の初回応答時間
- 優先度別の対応完了期限
- 定期メンテナンスの実施頻度と通知方法
契約形態は、準委任契約と請負契約を工程ごとに使い分けると、リスク分散の観点から有効です。たとえば、次のように分けます。
- 要件が確定している工程：請負契約（完成までの責任をベンダーが負う）
- 要件が流動的な工程：準委任契約（稼働時間に対する対価を支払う）
契約不適合責任・遅延損害金の取り決め
アプリ更改で起きやすい法的トラブルは、「要件漏れによる追加費用の負担」と「品質不足への対応費用の争い」です。民法改正（2020年4月施行）で「瑕疵担保責任」は「契約不適合責任」になり、発注者には追完請求・代金減額請求・損害賠償請求・解除が認められています。ただし、この権利には「知った時から1年以内に通知する」という期間制限があり、検収体制を整えておくことが大切です。
遅延損害金は、「1日あたりの遅延損害金額（例：契約金額の0.1%/日）」と「遅延損害金の上限額（例：契約金額の20%）」の両方を契約書に明記するのが標準的です。遅延損害金の規定がない契約書では、ベンダーが納期を守る動機が薄れ、スケジュール管理が形骸化するリスクがあります。
一方で、上限を設けずに無制限の遅延損害金を設定すると、ベンダーが過度なリスク回避から保守的なスケジュールを組み、本来不要なバッファを積み増す原因にもなります。そのため、双方にとって合理的な水準で合意しておくことが大切です。
ベンダーロックイン防止条項
ベンダーロックインとは、特定のベンダーへの依存度が高まり、他社への乗り換えが実質的に困難になる状態を指します。アプリ更改では、ベンダー独自の技術・ツール・インフラが多用されると、このリスクが高まります。契約書には、ベンダーロックインを防ぐための条項を盛り込むことを検討してください。
まず「技術選定の透明性確保」として、採用する技術スタック・ライブラリ・クラウドサービスをあらかじめ合意し、ベンダー独自のプロプライエタリ技術を一方的に採用させない旨を明記します。次に「ドキュメント納品義務」として、開発中に作られたすべての設計書・仕様書・テスト仕様書を、発注者への納品に含めます。
さらに「移行支援義務」として、契約終了後に別のベンダーへ引き継ぐための一定期間の技術的サポート（移行支援）を義務づける条項も有効です。これらの条項があると、ベンダーとの関係が悪化した場合でも、円滑に切り替えられる体制を保てます。
発注後のプロジェクト管理と障害対応
契約締結後、いよいよプロジェクトが始動します。アプリ更改は現行システムの稼働を続けながら新バージョンを開発するため、新規開発より複雑なプロジェクト管理が求められます。そのため、発注側の担当者が適切に関与して進捗を把握し、リスクを早期に見つけて対処できる体制を整えることが、成功の鍵を握ります。
暫定対応（業務継続優先）と根本対応（バグ修正）の2段階フロー
アプリ更改後の本番稼働直後は、想定外の不具合が発生しやすい時期です。この時期の障害対応を適切に行うため、「暫定対応」と「根本対応」の2段階フローをベンダーと事前に合意しておくことを強く推奨します。合意しておけば、障害発生時に「すぐ直すべきか、影響を抑えることを優先すべきか」で議論する時間を減らし、速やかに対応を始められます。
暫定対応とは、バグの根本原因を特定・修正する前に、ユーザーへの影響を最小限に抑えながら業務を続けるための一時的な対処です。具体的には、機能の一時停止、代替フローへの誘導（例：アプリ内決済が使えない場合はWebへ誘導）、影響範囲の限定（特定バージョンや特定ユーザーへのロールバック）などです。このフェーズでは「業務継続」を最優先に、完全な解決よりも迅速な影響の軽減を図ります。
根本対応は、暫定対応で業務を安定させたあとに、障害の原因を特定し、プログラムの修正・テスト・再デプロイを経て恒久的な解決を図るバグ修正です。なお、障害対応フローはドキュメントとして整備し、関係者全員が参照できる場所に共有しておきましょう。
段階的リリース計画と初期流動管理
アプリ更改の大きなリスクの一つが、大規模なリリース時に全ユーザーへ一斉に不具合が波及することです。これを防ぐ有効な手段が「段階的リリース（ロールアウト）」で、Google PlayやApp Storeの仕組みを使えば、最初は全ユーザーの1〜5%にだけ新バージョンを配信できます。段階的リリース計画は、フェーズを順に進める形で設計することを推奨します。
第1フェーズは社内テストユーザー（α版）、第2フェーズはベータユーザーや社外の一部モニター（β版）に配信し、基本動作と実環境での挙動を確認します。第3フェーズでは全体の5〜10%に広げ、クラッシュ率・エラーレート・レビュー評価などをリアルタイムで監視します。指標が正常範囲内であれば、25%・50%・100%と段階的に拡大します。
初期流動管理の期間中（リリースから2〜4週間が目安）は、ベンダーと発注者の専任担当者が指標の変化を毎日確認します。また、クラッシュ報告ツール（Firebase Crashlyticsなど）と分析ツール（Firebase Analytics・Amplitudeなど）を事前に導入すると、早期発見と迅速な対応につながります。段階的リリースと初期流動管理を組み合わせることで、リスクを大幅に軽減できます。
まとめ
アプリ更改の発注を成功させるには、発注前の準備からRFP作成、ベンダー評価、契約、発注後の管理まで、一貫した戦略と細部への注意が欠かせません。発注前には、現行アプリの課題を定量・定性の両面から明確にし、ソースコード・設計書の整理と引き継ぎ準備を終えることが出発点になります。
RFP作成では、アプリ更改特有のRFI項目（iOS/Android対応・段階リリース実績）を確認し、非機能要件を具体的な数値で示すことが重要です。予算は、競争原理を活かすため原則として示さず、各社が独自に積み上げた見積もりを比べる姿勢が、発注側に有利に働きます。
ベンダー評価では、定量評価（スコアリングシート）と定性評価（PMの対応力・企業文化との相性）を組み合わせ、拮抗した場合はレファレンスチェックで最終判断を行うことを推奨します。
契約では、ソースコード所有権の取り決めを明確にすることが不可欠です。具体的には、「更改後のアプリのソースコード著作権は発注者に帰属する」という条項を必ず盛り込み、将来のベンダー切り替えを妨げるリスクを排除しましょう。
また、契約不適合責任・遅延損害金・ベンダーロックイン防止条項も、具体的な数値・条件を明記することで、トラブル発生時の対応を迅速化できます。
発注後の管理では、暫定対応（業務継続優先）と根本対応（バグ修正）の2段階フローをあらかじめ合意しておきます。そのうえで、段階的リリース計画と初期流動管理の体制を整えることで、アプリ更改特有のリスクを最小化できます。
これらのポイントを体系的に実践すれば、アプリ更改プロジェクトを円滑に推進し、ユーザーに価値を届ける新しいアプリを確実にリリースできるでしょう。アプリ更改の発注・外注・委託をご検討中の方は、ぜひ本記事のポイントを参考にプロジェクトを進めてみてください。
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を創業。