既存のスマートフォンアプリやWebアプリが老朽化し、「そろそろ作り直しが必要だ」と感じていても、アプリ更改の発注をどこに依頼すればよいか、何をどう準備すればよいかわからないという担当者の方は少なくありません。新規開発とは異なり、現行システムの資産を引き継ぎながら刷新するアプリ更改には、発注特有の落とし穴と成功のための独自ノウハウがあります。

本記事では、アプリ更改の発注・外注・委託を検討している企業の担当者に向けて、発注前の準備からRFP作成、ベンダー評価、契約リスクヘッジ、発注後のプロジェクト管理まで、一連のプロセスを体系的に解説します。ソースコード所有権の取り決めや予算提示の駆け引き術など、競合記事には書かれていない実践的なノウハウも惜しみなく盛り込んでいますので、ぜひ最後までご一読ください。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・アプリ更改の完全ガイド

アプリ更改の発注前に準備すべきこと

アプリ更改プロジェクトが失敗する原因の多くは、発注前の準備不足にあります。現行アプリの問題点が曖昧なまま外注を始めると、ベンダーへの要件伝達が不正確になり、納品後に「思っていたものと違う」という事態に陥りやすくなります。発注を成功させるために、まず発注側で徹底的に準備すべき2つの作業を解説します。

アプリ更改の出発点は、現行アプリが「なぜ作り直す必要があるのか」を定量・定性の両面から明確にすることです。「古くなった」「動作が遅い」という感覚的な理由だけでは、ベンダーに適切な要件を伝えることができません。具体的な指標として、月間アクティブユーザー数の推移、クラッシュ率、レビュー評価の変化、サポートへの問い合わせ件数などを収集し、現状の問題を数値で示せるように整理しましょう。

加えて、実際のユーザーへのインサイト調査も欠かせません。社内の印象だけで課題を設定すると、ユーザーが本当に困っている点と乖離したアプリ更改になりかねません。アンケートやインタビュー、アプリ内のヒートマップ分析などを活用し、ユーザーが離脱するポイントや使いにくいと感じている画面を具体的に把握します。こうした定量・定性データをドキュメント化しておくことで、後工程のRFP作成でも具体的な要件として落とし込めるようになります。

また、競合アプリの機能比較も重要な準備作業です。自社アプリが競合と比べてどの機能が劣っているのかを整理し、更改後に実現すべき機能の優先度付けに活用します。この段階で「必須機能」「あれば良い機能」「将来的に対応する機能」の3段階に分類しておくと、後のベンダーとのスコープ交渉が格段にスムーズになります。

アプリ更改における最大の特徴の1つが、現行システムの資産を新しいベンダーに引き継ぐ必要があるという点です。新規開発と異なり、更改では既存のソースコードや設計書を精査した上で「何を引き継ぐか、何を捨てるか」を判断する工程が必要になります。この引き継ぎ準備が不十分だと、新しいベンダーが現行システムを理解するための調査工数が膨れ上がり、見積もり金額が跳ね上がったり、プロジェクト序盤で多くの時間を調査に費やしたりする事態になります。

具体的には、現行アプリのソースコードリポジトリへのアクセス権限の整理、画面設計書・ER図・API仕様書などのドキュメント類の棚卸し、インフラ構成図の最新化などを発注前に完了させておきましょう。これらが整っているほど、ベンダーからの見積もり精度が高まり、プロジェクト立ち上げ期間の短縮にもつながります。なお、ドキュメントが存在しない場合は、現行ベンダーや自社エンジニアにドキュメント作成を依頼する工程を先行して発注することも有効な手段です。

RFI・RFPの作成方法と実践テンプレート

発注前の準備が整ったら、次のステップはベンダーへの情報提供依頼書（RFI）と提案依頼書（RFP）の作成です。これらのドキュメントの質がそのまま集まる提案の質に直結するため、十分な時間をかけて丁寧に作成する必要があります。特にアプリ更改ではRFIとRFPに盛り込むべきアプリ固有の項目があり、一般的なシステム開発の発注書とは異なる工夫が求められます。

RFI（情報提供依頼書）はベンダーの技術力・実績・体制を把握するための調査書です。アプリ更改においては、一般的なRFI項目に加えて以下のアプリ固有の確認事項を必ず盛り込みましょう。

まずiOS・Android両プラットフォームへの対応実績です。アプリ更改では現行アプリが対応しているプラットフォームをそのまま引き継ぐケースが多いため、両OSへの対応経験が豊富なベンダーを選定する必要があります。特にFlutter・React NativeなどのクロスプラットフォームフレームワークやSwift・Kotlinなどのネイティブ開発、それぞれの経験年数と納品実績をRFIで確認します。

次に段階的リリースの実施経験です。アプリ更改ではユーザーへの影響を最小化するため、全ユーザーに一斉リリースするのではなく、一部ユーザーから段階的にリリースを展開するロールアウト戦略が重要になります。Google PlayのトラックやTestFlightを活用した段階リリースの経験があるベンダーを選ぶことで、リリース時の障害リスクを大幅に低減できます。このほか、App Store・Google Playの審査対応経験、AppレビューのA/Bテスト実施経験なども確認しておくと後の提案評価が容易になります。

RFP（提案依頼書）はベンダーへの正式な提案依頼であり、この文書の完成度がプロジェクト全体のクオリティを決定づけます。アプリ更改のRFPには以下の項目を必ず含めるようにしましょう。

①プロジェクト概要（更改の背景・目的・解決したい課題）
②現行アプリの概要（プラットフォーム・技術スタック・ユーザー数・主要機能）
③更改後のアプリに求める要件（機能要件・非機能要件・UI/UXの方向性）
④引き継ぎ資産の一覧（ソースコード・設計書・インフラ情報）
⑤プロジェクトスケジュール（希望リリース時期・マイルストーン）
⑥体制・役割分担（発注側の担当者・決裁者・テスト担当者の有無）
⑦評価基準（提案をどのような観点で評価するか）

書き方のコツとして特に重要なのが「非機能要件」の明確化です。パフォーマンス要件（画面表示速度3秒以内など）、可用性要件（稼働率99.9%以上など）、セキュリティ要件（個人情報の暗号化方式など）を具体的な数値で示すことで、ベンダーが提案範囲を正確に把握でき、見積もり精度が格段に向上します。また「将来的に追加予定の機能」もRFPに記載しておくと、ベンダーがアーキテクチャを設計する際に拡張性を考慮してくれるため、後々の追加開発コストを抑えることができます。

RFPに予算を記載するかどうかは、発注担当者がよく悩む問題です。「予算を明示すれば適切な提案が来る」という意見がある一方で、実務の現場では予算非提示を推奨するケースが多くあります。その理由は明確です。予算上限を提示すると、多くのベンダーがその上限いっぱいに合わせた見積もりを出してくる傾向があるからです。2,000万円という上限を示せば、1,500万円で実現できる案件でも「2,000万円ちょうど」の提案が来やすくなります。

発注側として有利な交渉を進めるためには、「競争入札形式で提案を受け付け、各社が独立して積み上げた見積もりを比較する」という姿勢をRFPで明示するのが効果的です。予算については「合理的な範囲であれば予算調整可能」と記載するにとどめ、具体的な数字は提示しないほうが適正価格での提案を引き出しやすくなります。また、提案審査後に上位2〜3社と個別交渉に入る際に初めて予算感を開示するというステップを踏むことで、価格競争を有利に進めることができます。ただし、スコープが非常に広い案件や提案準備に多大な工数がかかる場合は、ベンダーが参加を見送るリスクもあるため、「数百万円規模」「数千万円規模」という程度の情報提示はやむを得ない場合もあります。

ベンダー提案の評価・比較手法

複数のベンダーから提案を受け取ったら、公平かつ論理的な評価プロセスで選定を行う必要があります。「なんとなく良さそう」という感覚的な判断ではなく、定量評価と定性評価を組み合わせた体系的な評価手法を採用することで、選定の根拠を社内で共有しやすくなり、後悔のない意思決定につながります。

スコアリングシートは、評価項目ごとに点数をつけて各ベンダーを数値で比較するための評価ツールです。評価項目と重みづけの設定が評価の公平性を左右するため、提案受領前にあらかじめ評価基準を決定しておくことが重要です。

アプリ更改の評価項目としては、①技術力・アーキテクチャの妥当性（25点）、②スケジュールの実現可能性（20点）、③価格・コストパフォーマンス（20点）、④同種プロジェクトの実績・事例（15点）、⑤プロジェクト管理体制・体制図の充実度（10点）、⑥アフターサポート・保守体制（10点）という配点設計が一般的です。各評価者がそれぞれ採点し、複数名の平均点で順位をつける方式を採ることで、特定の個人の好みに左右されない客観的な評価が実現できます。また価格評価については、単純に安い順で点数をつけるのではなく、最安値ベンダーを満点とし、そこからの乖離率に応じて減点する方式が実態に合っています。

スコアリングシートによる定量評価だけでは見えてこない重要な要素が、担当プロジェクトマネージャー（PM）の対応力と自社の企業文化との相性です。アプリ更改は数か月から1年以上にわたる長期プロジェクトになることも多く、担当PMと自社担当者の関係性がプロジェクトの成否に直結します。

PMの対応力を見極めるポイントとして特に重視したいのが「曖昧な質問への回答の仕方」です。プレゼンテーション後の質疑応答で「要件が不明確なときにどのように対応しますか？」「想定外の問題が発生した際の判断フローを教えてください」といった意図的に曖昧な質問を投げかけてみましょう。問題解決に向けた具体的なプロセスを答えられるPMは、実際のプロジェクトでも適切なリスク対応ができる可能性が高くなります。反対に「お客様のご要望に柔軟に対応します」という抽象的な回答しか返ってこない場合は注意が必要です。

企業文化との相性については、発注側が重視する価値観（スピード重視か品質重視か、報告頻度はどの程度か、課題発生時の報告タイミングなど）を明示した上で、ベンダーの開発スタイルと合致しているかを確認します。アジャイル開発で進めたい場合にウォーターフォールしか経験がないベンダーに委託すると、プロセスのすり合わせだけで多大な工数が発生してしまいます。

評価の結果が上位2社で拮抗した場合、最終判断の基準として有効なのが「過去の類似プロジェクトの発注元企業への直接確認（レファレンスチェック）」です。ベンダーが提示した事例の発注元企業に連絡を取り、「実際の開発品質はどうでしたか？」「遅延や想定外の追加費用は発生しましたか？」「同じベンダーに再発注したいと思いますか？」という3点を中心に確認します。ベンダー側が見せたい情報だけではなく、実際の顧客体験を直接聞けるため、提案書や口頭説明では見えにくい信頼性を判断するための非常に有効な手段です。

契約締結時に押さえるべきリスクヘッジ

ベンダーを選定したら、いよいよ契約締結のフェーズに入ります。アプリ更改の契約は、新規開発以上に複雑なリスク要因を孕んでいます。現行システムの引き継ぎに関わる知的財産権の問題、要件変更による追加費用のトラブル、納品後の不具合対応の責任範囲など、契約書に適切な条項を盛り込まなければ、後になって深刻な紛争に発展するケースがあります。

アプリ更改において特に重要なのが「ソースコード所有権（著作権）」の取り決めです。新規開発のアプリでは発注元が著作権を保有するケースが多いのですが、更改プロジェクトではベンダーが独自に開発したライブラリやフレームワーク部分の扱いが曖昧になりやすく、プロジェクト終了後に別ベンダーへ乗り換えようとした際に「このコードはうちの著作物だから提供できない」というトラブルが実際に発生しています。

契約書には以下の3点を明記することを強く推奨します。①更改後のアプリのソースコード著作権は発注者に帰属する旨、②ベンダー独自のライブラリ・フレームワークを使用する場合は使用許諾（ライセンス）の範囲と条件を明示すること、③プロジェクト終了後にソースコード・設計書一式を発注者に納品する義務を明記すること。この3点が契約書に明確に記載されているかどうかを必ず確認してください。

SLA（サービスレベルアグリーメント）についても、アプリリリース後の保守・運用フェーズで適用される内容を具体的に取り決めましょう。「バグ発生時の初回応答時間」「優先度別の対応完了期限」「定期メンテナンスの実施頻度と通知方法」などを数値で合意しておくことで、リリース後の障害対応における認識のズレを防げます。また、契約形態については準委任契約と請負契約の使い分けを理解しておくことが重要です。要件が確定している工程は請負契約（成果物の完成責任をベンダーが負う）、要件が流動的なフェーズは準委任契約（稼働時間に対する対価を支払う）という形で工程ごとに使い分けることが、リスク分散の観点から有効です。

アプリ更改プロジェクトで実際に発生しやすい法的トラブルのトップが「要件漏れによる追加費用の負担」と「納品物の品質不足に対する対応費用の争い」です。民法改正（2020年4月施行）により、従来の「瑕疵担保責任」は「契約不適合責任」へと変更されており、発注者の権利として追完請求・代金減額請求・損害賠償請求・解除が認められています。ただし、これらの権利は「知った時から1年以内に通知する」という期間制限があるため、納品後の検収体制をしっかり整えることが重要です。

遅延損害金については、「1日あたりの遅延損害金額（例：契約金額の0.1%/日）」と「遅延損害金の上限額（例：契約金額の20%）」の両方を契約書に明記することが標準的です。遅延損害金の規定がない契約書では、ベンダーが納期を守る動機が薄れ、スケジュール管理が形骸化するリスクがあります。一方で、上限を設けずに無制限の遅延損害金を設定すると、ベンダーが過度なリスク回避から保守的なスケジュールを設定し、本来不要なバッファを積み増す原因にもなります。双方にとって合理的な水準での合意が重要です。

ベンダーロックインとは、特定のベンダーへの依存度が高まることで、他社への乗り換えが実質的に困難になる状態を指します。アプリ更改においては、ベンダー独自の技術・ツール・インフラを多用されることでこのリスクが高まります。契約書にはベンダーロックインを防止するための以下の条項を盛り込むことを検討してください。

まず「技術選定の透明性確保」として、採用する技術スタック・ライブラリ・クラウドサービスをあらかじめ合意し、ベンダー独自のプロプライエタリ技術を一方的に採用させない旨を明記します。次に「ドキュメント納品義務」として、開発過程で作成されたすべての設計書・仕様書・テスト仕様書の発注者への納品を契約に含めます。さらに「移行支援義務」として、契約終了後に別ベンダーへの引き継ぎを円滑に実施するための移行支援（一定期間の技術的サポート）を義務付ける条項も有効です。これらの条項があることで、ベンダーとの関係が悪化した場合でも円滑に切り替えができる体制を維持できます。

発注後のプロジェクト管理と障害対応

契約締結後、いよいよプロジェクトが始動します。アプリ更改は現行システムの稼働を維持しながら新バージョンを開発するため、新規開発よりも複雑なプロジェクト管理が求められます。発注側の担当者が適切に関与し、進捗を把握しながらリスクを早期発見・対処できる体制を整えることが、プロジェクト成功の鍵を握ります。

アプリ更改後の本番稼働直後は、想定外の不具合が発生しやすい時期です。この時期の障害対応を適切に行うために、あらかじめ「暫定対応」と「根本対応」の2段階フローをベンダーと合意しておくことを強く推奨します。

暫定対応とは、バグの根本原因を特定・修正する前に、ユーザーへの影響を最小化しながら業務を継続させるための一時的な対処です。具体的には、問題が発生している機能の一時停止、代替フローへの誘導（例：アプリ内決済が使えない場合はWebへ誘導）、影響範囲の限定（特定バージョンや特定ユーザーへのロールバック）などが該当します。このフェーズでは「業務継続」を最優先とし、完全な解決より迅速な影響軽減を優先します。

根本対応は、暫定対応で業務を安定させた後に行う本質的なバグ修正です。障害の発生原因を特定し、プログラムの修正・テスト・再デプロイを経て恒久的な解決を図ります。このフローを事前に合意しておくことで、障害発生時にベンダーと発注者の間で「すぐ直すべきか、影響を抑えることを優先すべきか」という議論で時間を費やすことなく、速やかに適切な対応を開始できます。障害対応フローはドキュメントとして整備し、関係者全員が参照できる場所に共有しておきましょう。

アプリ更改の大きなリスクの1つが、大規模なリリース時に全ユーザーへ一斉に不具合が波及してしまうことです。これを防ぐための有効な手段が「段階的リリース（ロールアウト）」です。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段階フローをあらかじめ合意しておくことと、段階的リリース計画による初期流動管理の体制構築が、アプリ更改特有のリスクを最小化します。これらのポイントを体系的に実践することで、アプリ更改プロジェクトを円滑に推進し、ユーザーに価値を届ける新しいアプリを確実にリリースできるでしょう。アプリ更改の発注・外注・委託をご検討中の方は、ぜひ本記事のポイントを参考にプロジェクトを進めてみてください。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・アプリ更改の完全ガイド

株式会社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を創業。