アプリ刷新を発注する前にやるべき社内準備

アプリ刷新プロジェクトの成否は、ベンダーに発注する前の社内準備の質によって大きく左右されます。外部の開発会社がどれだけ優秀であっても、発注側の準備が不十分であれば要件の伝達がうまくいかず、最終的に「作ってほしいものと違うものができた」という事態を招きます。実際に、2025年のNHKと日本IBMの訴訟事例でも明らかになったように、発注側が「移行要件を100%達成する」という非現実的な前提をベンダーに押し付けた結果、双方の認識齟齬が訴訟にまで発展しています。これほど大規模なプロジェクトでなくとも、準備不足による失敗は日常的に起きているのです。

まず取り組むべきは、現行アプリの全体像を正確に把握することです。どのような機能があり、どのような技術スタック（言語・フレームワーク・ライブラリのバージョン）で動いているかを一覧化します。長年運用されてきたアプリでは、もともとの設計書が失われていることも珍しくありません。その場合、社内のエンジニアや業務担当者へのヒアリングを丁寧に行い、現場で独自に追加された非公式な機能（いわゆる「野良改修」）も含めて洗い出す必要があります。

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

▼全体ガイドの記事
・アプリ刷新の完全ガイド

ベンダー選定において、キングジム社のシステム刷新事例は示唆に富んでいます。複数のベンダーに提案を依頼した際、最終的に採択されたのは最も高額な見積もりを提示してきたベンダーでした。その理由は明快で、そのベンダーだけが「まず旧システムの構成を全部洗い出すことから始める」と明言したからです。他のベンダーが「うまく移行できます」と曖昧な提案をする中、技術的負債を直視する姿勢を示したベンダーが信頼を勝ち取ったのです。つまり、発注側が技術的負債を可視化しておくことは、優良なベンダーを見極めるフィルターとしても機能します。

アプリ刷新に特有の発注前決定事項として、開発方針の選択があります。iOSとAndroidそれぞれ専用のネイティブアプリとして開発するか、React NativeやFlutterといったクロスプラットフォーム技術を採用して一元的に開発するかは、コスト・品質・開発期間・将来の保守性に大きな影響を与えます。この判断を曖昧にしたままRFP（提案依頼書）を作成すると、ベンダーによって前提が異なる提案が集まり、比較自体が困難になります。

判断の目安としては、カメラ・生体認証・プッシュ通知など端末固有のハードウェア機能をフル活用したい場合や、最高水準のUI/UXパフォーマンスが必要な場合はネイティブが向いています。一方、開発コストを抑えたい、リリースサイクルを短縮したい、社内のエンジニアリソースが限られているといった事情がある場合はクロスプラットフォームが選択肢になります。自社のユーザー層のデバイス比率や、競合アプリの技術的傾向も参考になります。この方針は、発注担当者が単独で決めるのではなく、技術担当者・マーケティング担当者・経営陣を巻き込んで合意形成を行うことが重要です。

アプリ刷新プロジェクトは、初期開発費用だけでなく、リリース後の保守・運用コストや、ストア申請対応、OSアップデートへの追随費用まで含めた総所有コスト（TCO）を稟議書に明示することが承認獲得の近道です。「開発費用：○○万円」だけを記載した稟議書は、後から追加費用が発生するたびに再稟議が必要となり、プロジェクトのスピードを著しく低下させます。目安として、初期開発費用の20〜30%を年間保守費用として想定し、3〜5年分の総コストを示すと説得力が増します。また、現行アプリを放置し続けた場合のリスク（セキュリティ脆弱性・ユーザー離脱・競合優位性の喪失）を定量化して対比させることで、投資対効果を明確に示すことができます。

RFP（提案依頼書）の作り方【実務テンプレート付き】

RFP（Request for Proposal：提案依頼書）とは、複数のベンダーから均一な条件で提案を引き出すための公式文書です。RFPが曖昧だと、各社の提案内容・見積もり範囲・前提条件がバラバラになり、「比較できない提案書」が集まる結果になります。アプリ刷新の場合、Web系システムのRFPとは異なる記載事項が存在するため、その点を押さえておくことが重要です。

アプリ刷新のRFPには、次の要素を必ず盛り込む必要があります。まず「プロジェクトの背景と目的」では、なぜ今このタイミングで刷新するのか、何を改善したいのかを明確に記述します。次に「現行システムの概要」として、技術スタック・ユーザー数・月間アクティブユーザー・現在の不具合や課題を具体的に示します。「機能要件と非機能要件」では、必須機能・あると望ましい機能・スコープ外機能を三段階で整理し、パフォーマンス要件（ページロード時間・同時接続数）やセキュリティ要件も記載します。

アプリ刷新に特有の記載事項として、「対応プラットフォームとOSバージョン範囲」「ストア申請（App Store・Google Play）の担当範囲」「プッシュ通知・ディープリンク・アプリ内課金などの特殊機能の有無」「デザインガイドラインの有無（既存ブランドガイドラインへの準拠の要否）」があります。特に、App Store/Google Playの審査対応を開発費用に含めるかどうかは、ベンダーによって見解が大きく異なる項目です。契約後のトラブルを防ぐため、RFP段階で明示しておくことを強く推奨します。

アプリ刷新では、UI/UXデザインを専門のデザイン会社に、エンジニアリング（実装）を開発会社に別々に発注する「分離発注」という選択肢があります。分離発注のメリットは、それぞれの専門性を最大限に活かせる点にあります。優れたデザイン会社は必ずしも開発能力が高いわけではなく、逆に開発力の高い会社がUI/UX設計に弱い場合も多いです。特にユーザー体験が競合優位性に直結するBtoC向けアプリでは、デザインに専門会社を起用する価値があります。

一方で分離発注のデメリットも存在します。デザインと開発の連携管理が発注側の責任となるため、プロジェクトマネジメントの負荷が増大します。デザイン仕様と技術的実現可能性の間にギャップが生じた場合、その調整コストを発注側が負担することになります。社内にプロジェクトマネージャーを立てられる体制がある場合は分離発注が機能しますが、そうでない場合はワンストップで対応できる会社を選ぶほうがリスクを抑えられます。RFPには「一括発注希望」か「設計・開発の分離発注可能」かを明記し、ベンダーにも対応可否を確認しましょう。

ベンダーから均質な提案を引き出すために、RFPには「提案書に必ず記載すべき項目」を指定することが有効です。具体的には、開発体制（プロジェクトマネージャー・エンジニアの人数・経験年数・稼働率）、工程別スケジュール（要件定義・設計・開発・テスト・ストア申請の各期間）、見積もりの費目内訳（工数・単価が確認できる形式）、リスク事項と対応策、保守・運用体制と費用、を指定します。これらを統一フォーマットで提出させることで、単純な金額比較ではなく、実行可能性・リスク管理能力・チームの質での比較が可能になります。

ベンダー比較・選定プロセスの進め方

RFPを配布したら、複数のベンダーから提案を受け取り、構造的に比較するプロセスに入ります。ベンダー選定は単なる価格比較ではなく、プロジェクト成功確率を高めるためのリスク評価でもあります。ここで手を抜くと、発注後に「やはりこのベンダーには無理だった」という事態を招き、プロジェクトの手戻りが膨大なコストを生みます。

ベンダー選定では最低3社、可能であれば5社程度から提案を取得することが推奨されます。1〜2社だけでは比較の軸が定まらず、価格の妥当性も判断できません。3社以上あれば、提案内容・見積もり・スケジュールの「相場観」を把握でき、突出して低い見積もりや非現実的なスケジュールを持つベンダーを早期に識別できます。

評価基準は、提案を受け取る前に評価委員会（発注側の複数名）で合意しておく必要があります。代表的な評価軸として、技術力・実績（40%）、プロジェクト管理体制（25%）、価格（20%）、保守・運用対応力（15%）といった重み付けが参考になりますが、自社プロジェクトの優先事項に合わせて調整してください。特にアプリ刷新の場合、モバイル開発実績（iOS/Android両対応の実績件数）とUI/UX設計能力を個別の評価項目として設けることを推奨します。採点を複数人で行い平均化することで、特定の担当者の主観バイアスを排除できます。

ベンダー選定において、最も見落とされがちかつ最も効果的な確認手段が「リファレンスチェック（参照確認）」です。これは、ベンダーの過去クライアントに直接コンタクトを取り、プロジェクトの実態を確認する手法です。提案書に書かれた実績や成功事例は、どのベンダーも肯定的な側面しか掲載しません。実際の発注担当者に直接話を聞くことで、「提案では3ヶ月と言っていたが実際は5ヶ月かかった」「途中でキーエンジニアが交替し品質が落ちた」といった、提案書では絶対に分からない情報が得られます。

実際の事例として、あるプロジェクトではリファレンスチェックによって、最終候補のベンダーが前案件で6ヶ月以上の大幅遅延を起こしていた事実が判明し、選定から外すことができました。手順は次のとおりです。まずベンダーに「直近3件の類似案件の担当者を紹介してほしい」と依頼します。ベンダー側が選んだ先だけに聞くと肯定的な声に偏るため、可能であれば業界の人脈や口コミ情報も並行して収集します。確認すべき質問は「当初スケジュール通りに完了したか」「追加費用が発生したか、その理由は何か」「品質上のトラブルはあったか」「同様のプロジェクトがあれば再度依頼するか」の4点が核心です。このリファレンスチェックを実施するだけで、ベンダー選定の信頼性は格段に向上します。

アプリ刷新特有の技術評価として、モバイル開発固有の能力を確認する必要があります。提案プレゼンの場では、以下の点を具体的に質問することが有効です。「過去にApp StoreやGoogle Playの審査で拒否された経験があるか、またその場合どう対処したか」「OSのメジャーアップデート（iOS・Androidの新バージョンリリース）時の対応フローはどうなっているか」「パフォーマンスチューニングやバッテリー消費最適化の実績はあるか」これらの質問に具体的なエピソードを交えて回答できるベンダーは、実際の現場経験を持っていると判断できます。

UI/UXの評価は、ポートフォリオを見るだけでは不十分です。ユーザーテストや使いやすさの検証プロセスをどのように設計しているか、アクセシビリティ（視覚障害者・高齢者への配慮）への対応方針はどうか、デザインシステム（コンポーネントライブラリ）を納品物として提供できるかを確認してください。特にデザインシステムの納品は、将来の保守・改修コストに大きく影響するため、見落としがちですが非常に重要な交渉点です。

契約締結のチェックリスト

ベンダーを選定したら、次は契約締結のフェーズです。この段階で曖昧にしておいた事項が、後々のプロジェクト炎上の火種になります。スルガ銀行と日本IBMの訴訟（95億円の白紙撤回）では、自社の業務要件に合わないパッケージを選定した上、契約上の責任分解が不明確だったことが問題を複雑化させました。契約書は法的保護の最後の砦ですが、トラブルが発生してから読み返すものではなく、発注前に隅々まで確認するものです。

IT開発の契約形態は大きく「請負契約」と「準委任契約」に分かれます。請負契約は「完成物を納品する義務」をベンダーが負う契約で、アプリのリリースという成果物が明確に定義できる場合に適しています。一方、準委任契約は「作業を遂行する義務」のみを負う契約で、要件定義フェーズや、仕様が流動的なアジャイル開発、保守・運用フェーズに適しています。

アプリ刷新プロジェクトでは、工程によって契約形態を使い分けることが実務的には一般的です。要件定義・設計フェーズは仕様変更が多いため準委任契約とし、設計が固まった開発フェーズは請負契約とすることで、発注側はベンダーに完成責任を問える一方、不確実性の高い上流工程での過大なリスク負担をベンダーに強いることなく、建設的な協力関係を維持できます。ただし請負契約であっても、発注側が要件を頻繁に変更すれば契約上の義務関係が複雑になるため、「変更管理プロセス（Change Control Process）」を契約に明記しておくことが必要です。

アプリ刷新特有の契約上の注意点として、ストア審査対応の取り扱いがあります。App StoreおよびGoogle Playへの申請・審査通過は、開発が完了したとしても自動的に達成されるものではありません。Appleのガイドライン違反（プライバシーポリシーの記載不備・特定の機能制限等）やGoogleのポリシー違反により、審査が却下されることは珍しくなく、場合によっては複数回の修正対応が必要です。

この審査対応を誰が担うかは、契約書に明確に規定しておく必要があります。開発ベンダーが「開発完了＝納品完了」とみなしてストア審査対応を対象外とした場合、審査却下が続くと発注側が自力で対応するか、追加費用を払ってベンダーに依頼するしかなくなります。契約書には「ストア申請・審査通過をもって当該工程の完了とする」という文言を明記するとともに、審査却下時の修正対応回数の上限・費用負担の在り方を事前に合意しておくことを強く推奨します。特に初回リリースだけでなく、OSアップデート対応時の再申請についても対応範囲を契約に含めるかどうか確認が必要です。

請負契約における「瑕疵担保責任」は、納品後に不具合（バグ）が発見された場合にベンダーが無償修正する義務を規定したものです。民法改正（2020年施行）により「契約不適合責任」と呼ばれるようになりましたが、実務上の対応は大きく変わっていません。問題は、「瑕疵（契約不適合）」の定義があいまいな場合です。要件定義書や設計書に明記されていない動作については、ベンダーが「仕様外」と主張し、発注側が「当然含まれるべき機能」と主張する対立が生じます。この認識齟齬を防ぐため、契約書の別添として「機能一覧と動作仕様」を詳細に添付し、それが基準文書であることを明記することが重要です。

損害賠償の上限額については、多くのベンダーは「受領した報酬の範囲内」または「直接損害のみを対象」とする条項を設けています。大規模なシステム障害が発生した場合、ビジネス機会損失は間接損害に分類される可能性があるため、発注側として過度な期待は禁物です。ただし、ベンダーの故意・重大な過失による損害については上限を設けないよう交渉することは合理的です。また、プロジェクト途中で状況が変化し追加費用が発生する場合の意思決定フロー（誰が承認し、いつ合意書を取り交わすか）を契約書に規定しておくことで、口頭合意による後日トラブルを防ぐことができます。

発注後のプロジェクト管理と現場定着

発注が完了したからといって、発注側の役割が終わるわけではありません。アプリ刷新プロジェクトの成功には、開発フェーズを通じた継続的な関与と、リリース後の現場定着への取り組みが不可欠です。「ベンダーに任せた」という姿勢のまま進めると、ベンダー側でも課題を抱え込み、報告が遅れ、気づいたときにはプロジェクトが取り返しのつかない状況に陥っていた、というケースが後を絶ちません。

アプリ刷新によって現場の業務フローが変わる場合、従業員のITリテラシー格差（デジタルデバイド）への対応が、プロジェクト成功を左右する重要な要素になります。技術的に優れたアプリが完成しても、現場の利用者が使いこなせなければ投資効果はゼロです。実際、多くのDXプロジェクトが「システムは完成したが現場に浸透しなかった」という結末を迎えています。

有効なアプローチは、各部署から「システムキーパーソン」を選出し、開発初期から巻き込むことです。このキーパーソンはIT推進部門と現場の橋渡し役を担い、ユーザーテストへの参加・フィードバック収集・同僚へのトレーニングを担当します。テクノロジーに詳しくなくてもかまいません。自分の職場の業務を誰よりも深く理解しており、周囲からの信頼が厚い人物であることが選出基準として重要です。このアプローチにより、部門間の利害調整もスムーズになり、「あの部署の要望だけ優先された」という不満を抑制できます。トレーニングについても、一般的なマニュアル配布だけでなく、小規模グループでのハンズオン研修や、困ったときに相談できるサポート窓口の設置が定着率を高めます。

アプリ刷新において、旧アプリから新アプリへの一斉移行は大きなリスクを伴います。全ユーザーが同時に新しい環境に切り替わると、潜在的なバグや使い勝手の問題が一度に顕在化し、カスタマーサポートへの問い合わせが殺到します。これを防ぐのが「段階的リリース（フェーズドロールアウト）」戦略です。

具体的には、まず社内の限られたユーザー（α版）でテストし、次に外部の限定ユーザー（β版）で検証し、問題がなければ全ユーザーへの公開（正式版）へと移行します。App StoreもGoogle Playも「段階的公開（Phased Release）」機能を提供しており、リリース後1〜7日かけて対象ユーザーの割合を1%→5%→10%と段階的に拡大することができます。この期間中に重大な不具合を検知した場合、即座に配信を停止して修正版をリリースできるため、被害を最小化できます。契約上は、この段階的リリース計画（各フェーズの完了条件・移行判断基準・ロールバック手順）をベンダーとの合意文書に盛り込んでおくことで、責任の所在を明確にできます。

どれだけ準備を尽くしても、プロジェクトが深刻な状態に陥ることはあります。そのとき、最も難しい判断の一つが「撤退するかどうか」です。これまでに費やした費用や時間を「サンクコスト（埋没費用）」として切り捨て、プロジェクトの中止または大幅な仕切り直しを判断する勇気は、経営判断として非常に重要です。スルガ銀行のケースでは、問題の兆候が明らかになっても当初の方針にこだわり続けたことが、最終的な95億円の損失を招いたとも言われています。

撤退を判断する際の「契約上の身の守り方」として、まず現在の契約が請負か準委任かを確認します。準委任契約の場合、民法第651条に基づき、いつでも契約の解除が可能です（やむを得ない事情がなければ相手に損害が生じた場合に賠償責任が生じる可能性はあります）。請負契約の場合は、未完成の場合は発注側からの解除が可能ですが、ベンダーは既履行部分の報酬を請求できます。プロジェクトを中止する場合も、ソースコード・設計書・テスト仕様書といった成果物の引き渡しを確実に行い、将来の再起動や別ベンダーへの引き継ぎに備えることが重要です。また、プロジェクト再起動を検討する場合、前のベンダーに依存した設計や、特定技術への過度な依存が残っていると再起動コストが跳ね上がります。特定ベンダーへのロックインを防ぐ設計方針（標準技術の採用・インターフェース定義の文書化）は、リスクヘッジとして発注前段階から意識しておく価値があります。

アプリ刷新プロジェクトは、単なるシステム更新ではなく、組織全体の業務改革と密接に結びついています。本記事で解説した社内準備・RFP作成・ベンダー選定・契約締結・発注後管理の各プロセスを丁寧に踏むことで、プロジェクト成功確率を大幅に高めることができます。特にリファレンスチェックや段階的リリース計画、撤退戦略の事前策定といった、一般的な記事では触れられない実務的な知見を活用して、貴社のアプリ刷新を成功に導いていただければ幸いです。

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

▼全体ガイドの記事
・アプリ刷新の完全ガイド

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