ハイブリッドアプリのRFP/要件定義書/提案依頼書について

ハイブリッドアプリの開発を成功させられるかどうかは、コードを書き始める前の要件定義でほぼ決まります。ハイブリッドアプリは、WebView上でHTML・CSS・JavaScriptの画面を動かしつつ、CordovaやIonic、Capacitorといったフレームワークを介してカメラやプッシュ通知などのネイティブ機能を呼び出す構造を持ちます。この「Web部分とネイティブ部分の境界線をどこに引くか」を要件定義で明確にしないまま発注すると、リリース後に「この機能はハイブリッドでは性能が出ない」「WebViewだけでは実現できなかった」という致命的な手戻りが発生します。コスト削減を狙ってハイブリッドを選んだはずが、結局ネイティブで作り直すことになり、かえって高くつくという失敗は珍しくありません。

本記事は、ハイブリッドアプリのRFP（提案依頼書）・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。WebViewとネイティブの機能境界を要件にどう落とすか、CordovaかIonicかCapacitorかというフレームワーク選定をRFPでどう扱うか、コスト削減と性能限界のトレードオフを要件にどう織り込むか、Must/Wantをどう仕分けて社内合意を取るか、そして見積りの妥当性をどう判断するかまで、実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まずハイブリッドアプリ開発の完全ガイドから読むことをおすすめします。

形態選定を起点にする要件定義の進め方

ハイブリッドアプリの要件定義は、「どんな機能が欲しいか」を並べるところから始めてはいけません。出発点は、自社が作りたいアプリの機能を洗い出したうえで、「その機能はそもそもハイブリッドという形態に合っているのか」を見極めることです。ハイブリッドはコスト削減に有効な選択肢ですが、すべてのアプリに適しているわけではありません。形態が要件と合っていないと、後から必ず性能の壁にぶつかります。

最初に行うべきは、作りたいアプリの中核となる体験が、WebView（アプリ内に埋め込まれたブラウザ）で十分に成立するかの見極めです。コンテンツ表示、フォーム入力、会員機能、商品一覧といった画面が中心であれば、ハイブリッドは非常に相性が良い形態です。既存のWebサイトやWebアプリのHTML・CSS・JavaScript資産をそのまま流用でき、iOSとAndroidを単一コードベースで同時に開発できるため、開発と保守のコストを大きく削減できます。

一方で、滑らかなアニメーションを多用するゲーム的なUI、高速で連写するカメラ、リアルタイムの動画処理、大量データの高速描画といった体験が中核にある場合は、ハイブリッドは要件と合いません。これらはWebViewの描画性能の限界に直接ぶつかるためです。要件定義の最初の関門は、自社のアプリがどちら側に属するかを正直に判定し、ハイブリッドで進めてよいかを意思決定することにあります。この判断を曖昧にしたまま「安いから」という理由だけでハイブリッドを選ぶと、後の手戻りを招きます。

ハイブリッドを選ぶと決めたら、次に行うのが既存のWeb資産（AsIs）の棚卸しです。自社にすでにレスポンシブ対応のWebサイトやWebアプリがあるか、そのコードはどの程度アプリに流用できるか、デザインシステムやAPIは整っているかを洗い出します。ハイブリッドの最大の利点は既存Web資産の流用にあるため、ここで流用できる資産の量を正確に把握することが、コスト削減の効果と見積りの精度を左右します。

そのうえで、アプリ化した後のあるべき姿（ToBe）を設計します。Webブラウザで見ていた体験を、アプリではどう変えるのか。プッシュ通知でユーザーを呼び戻すのか、ホーム画面に常駐させてリピート率を高めるのか、カメラ連携で新しい体験を加えるのか。アプリにする目的とToBeを描いたうえで、それを実現するために必要な機能を逆算します。ToBeを描かずに「とりあえずWebサイトをアプリにする」だけでは、ストアにあるだけで使われないアプリになりがちです。形態選定の妥当性は、関連記事のメリット・デメリットの比較もあわせてご覧いただくと、より立体的に理解できます。

WebViewとネイティブの機能境界を要件に落とす

形態とToBeを定めたら、いよいよハイブリッドアプリ要件定義の核心、「WebViewで作る部分」と「ネイティブのプラグインに任せる部分」の境界線を機能要件に落とし込みます。ここがハイブリッド特有の最重要工程です。境界の引き方を間違えると、性能不足やプラグイン不在による作り直しが発生します。機能を一覧化し、それぞれをWebView側・プラグイン側・ネイティブ部分併用のどれで実現するかを、要件定義書に明記します。

機能仕分けの基本は、まず各機能をWebViewだけで実現できるかどうかで分類することです。コンテンツの表示、商品一覧や詳細、フォーム入力、会員登録・ログイン、カート、決済画面の表示といった機能は、WebViewだけで問題なく動きます。これらはHTML・CSS・JavaScriptの範囲で完結するため、ハイブリッドの得意領域です。要件定義書では、これらを「WebView実装」と明記し、流用できる既存Web資産があれば対応付けておきます。

一方、プッシュ通知、カメラ撮影、GPS位置情報、生体認証、端末ストレージへのアクセス、ファイル操作といったOS機能は、WebViewから直接は呼び出せません。これらはCordova・Ionic・Capacitorが提供するプラグインを介してネイティブ機能を呼び出す形で実現します。要件定義書では、これらの機能ごとに「どのプラグインで実現するか」「対応するプラグインが存在するか」を確認し、明記します。ここで重要なのは、欲しいOS機能に対応するプラグインが本当に存在し、保守されているかを事前に検証することです。プラグインが古くて新しいOSに対応していない、というケースは実際にあり、これを見落とすとリリース直前に機能が動かない事故につながります。具体的にどの機能がどちら側になるかは、関連記事の必要機能の解説もあわせてご覧ください。

機能仕分けでもっとも慎重を要するのが、性能限界に触れる機能の見極めです。プラグインが存在しても、ハイブリッドでは実用的な性能が出ない機能があります。代表例が高速カメラです。学術的なベンチマーク（アムステルダム自由大学等の修士論文）では、iOSでネイティブのカメラ起動が平均5.85msだったのに対し、クロスプラットフォーム実装では平均247.87msと大きな遅延が報告されています。バーコードを連続スキャンするような用途では、この差が業務の停滞に直結します。

アプリの容量にも違いが出ます。同じ研究では、iOSでネイティブが1.3MBだったのに対しクロスプラットフォームでは28.5MBと約22倍に肥大化したという報告があります。容量の大きさはダウンロード時の離脱や、端末ストレージの圧迫につながります。要件定義書では、こうした性能・容量のトレードオフを把握したうえで、「高速性が必須の機能」と「多少遅くても許容できる機能」を切り分けます。性能が必須の機能だけはネイティブを部分併用する、という設計判断を要件に書き込むことで、ハイブリッドの安さを活かしつつ、致命的な性能不足を避けられます。

フレームワーク選定とコスト要件の織り込み

機能境界を定めたら、それを実現するフレームワークの方針と、コストに関する要件を整理します。ハイブリッドの代表的なフレームワークにはCordova、Ionic、Capacitorがあり、それぞれ思想と保守性が異なります。要件定義の段階で、どのフレームワークを前提とするか、あるいはベンダーの提案に委ねるかを決め、その判断軸を持っておくことが重要です。

Cordovaは古くからあるWebView型の基盤で、既存Web資産を最短で動かせる反面、近年はメンテナンスの勢いが弱まり、プラグインの保守が止まるリスクがあります。Ionicは、CordovaやCapacitorの上にUIコンポーネント群を載せたフレームワークで、見栄えの良い画面を効率的に作れます。Capacitorは、Ionicチームが開発したモダンな後継基盤で、ネイティブプロジェクトを直接管理でき、新しいOSへの追従や保守性に優れます。新規開発であれば、保守性の観点からCapacitorを軸に据える判断が合理的なケースが多くなっています。

RFPでは、フレームワークを発注者が一方的に指定するより、「保守性と将来のOS追従を重視する」「既存のWeb資産（使用しているフレームワーク名）を流用したい」といった要件と制約を示し、最適なフレームワークの提案と理由をベンダーに求めるのが実務的です。そのうえで、提案されたフレームワークが数年後も保守され続ける見込みがあるか、社内またはベンダーに保守できる人材がいるかを確認します。フレームワーク選定は、短期の作りやすさだけでなく、長期の保守リスクまで含めて要件化することが肝心です。

ハイブリッドを選ぶ最大の動機はコスト削減です。iOSとAndroidを別々にネイティブ開発すると、おおむね二つ分の工数がかかりますが、ハイブリッドなら単一コードベースで両OSに対応できるため、開発費と保守費を抑えられます。要件定義書では、この「単一コードで両OS対応」という前提を明記し、コスト削減効果を見積りの土台にします。さらにコストを圧縮する手法として、AI駆動開発の活用もあります。riplaの関連会社（ぷらすわん合同会社）では、市場相場700〜1,500万円（13〜18人月）の案件を、AIコード自動生成と分割発注の組み合わせで実質8人月・約500万円に圧縮した事例があります。

ただし、コスト削減は性能限界とのトレードオフです。要件定義では、「安く作る」という目的のために、どこまでの性能を妥協できるかを明確にしておく必要があります。たとえば「カメラはあれば便利だが、業務の中核ではないので多少遅くても許容する」のか、「カメラ性能が事業の生命線なので、そこだけネイティブを併用してでも担保する」のか。この妥協ラインを要件に書き込まないと、ベンダーは「全部ハイブリッドで安く」作ってしまい、後で性能不足が露呈します。コスト削減の前提と、譲れない性能要件を両方明記することが、トレードオフを健全に管理する要件定義です。

Must/Wantの仕分けとRFP・見積り判断

機能とコストの要件が固まったら、それをRFP（提案依頼書）にまとめ、複数のベンダーに提案を依頼します。RFPの質が、集まる提案と見積りの質を決めます。とくにハイブリッドでは、機能境界とMust/Want（必須・希望）の仕分けが明確であるほど、ベンダーは精緻な見積りを出せます。曖昧なRFPには曖昧な見積りしか返ってこず、横並びの比較ができません。

要件定義の現場では、しばしば「現場は多機能を求め、経営層はコストと短期リリースを求める」という板挟みが起きます。これを解くのがMust/Wantの仕分けです。「これがないとアプリが成立しない」Must機能と、「あると望ましいが初期になくても運用できる」Want機能を明確に分け、社内で合意を取ります。ハイブリッドの場合、性能限界に触れる機能をWantに振り分けられるかどうかが、ハイブリッド採用の可否を左右することもあります。

仕分けにあたっては、各機能を「事業のKGIにどれだけ貢献するか」という軸で評価します。担当者の思い入れではなく、目的への貢献度で優先度を決めることで、社内合意が取りやすくなります。Mustを絞り込んでWantを段階リリースに回せば、初期費用を抑えてまず市場に出し、効果を見ながら機能を追加できます。この仕分けと優先度付けは、予算超過時に「どの機能を初期から外すか」を冷静に判断する材料にもなります。すべてをMustにすると、予算オーバー時に削るものがなくなり、プロジェクトが頓挫します。

RFPには、最低限以下を盛り込みます。アプリ化の目的とKGI、ハイブリッドを選ぶ前提と既存Web資産の状況、機能要件（WebView実装・プラグイン実装・ネイティブ併用の区分付き、Must/Wantの分類付き）、性能要件（許容できる遅延と必須の高速性）、フレームワークに関する要望、運用・保守の体制要求、予算とスケジュールの目安です。とくに保守体制は重要で、プラグインやフレームワークが将来のOS更新に追従できるか、誰が保守するのかを明記させます。

集まった見積りの妥当性を判断するには、まず相場観を持つことです。アプリ開発費は手法・対応OS・機能規模で数十万円から数千万円まで幅があります。発注先別の人月単価は、フリーランス60〜80万円、中小開発会社80〜120万円、大手SIer150〜300万円が目安で、この差は中間マージンや組織維持費によるものです（出典：ぷらすわん調べ）。ハイブリッドは両OS同時開発で工数を抑えられるため、ネイティブを二本作る見積りより安くなるのが通常です。見積りがこの理屈と合っているか、「開発一式」のような不透明なまとめになっていないかを確認し、機能ごと・工程ごとの内訳開示を求めて精査します。要件定義とRFPが詳細であるほど、ベンダーは精緻な見積りを出さざるを得ず、ブラックボックスを解明しやすくなります。riplaはフルスクラッチ受託と国内開発の立場から、要件の透明な整理と見積り内訳の明示を重視しています。

まとめ

ハイブリッドアプリの要件定義・RFP・提案依頼書は、機能の列挙からではなく、作りたい体験がWebViewで成立するかという形態適合の判定から始めるのが鉄則です。そのうえで、各機能をWebView実装・プラグイン実装・ネイティブ併用に仕分け、高速カメラのような性能限界に触れる機能を見極めます。CordovaかIonicかCapacitor（新規なら保守性でCapacitorが有力）というフレームワークは要望をRFPに示してベンダーの提案を求め、単一コードで両OS対応というコスト削減効果と譲れない性能要件の両方を明記します。Must/WantをKGI貢献度で仕分けてRFPに落とせば、見積りを横並びで比較でき、相場（人月単価フリーランス60〜80万・中小80〜120万・SIer150〜300万：出典ぷらすわん調べ）に照らして妥当性も判断できます。

ハイブリッドはコスト削減に有効な形態ですが、その安さは要件定義の精度に支えられています。形態適合の判定とWebView・ネイティブの境界の明記を怠ると、性能不足で作り直しになり、かえって割高になります。riplaはフルスクラッチ受託と国内開発、AI駆動でコストを3分の1に圧縮した知見を組み合わせ、形態選定から機能境界の仕分け、フレームワーク選定、RFP作成までを発注企業と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。