BtoBアプリの開発をベンダーに発注するとき、プロジェクトの成否をもっとも左右するのが要件定義とRFP（提案依頼書）の質です。「とりあえず営業が使えるアプリが欲しい」といった曖昧な依頼のままベンダーに丸投げすると、現場の業務と噛み合わないアプリが出来上がり、予算超過や納期遅延、そして誰も使わないという最悪の結果を招きます。BtoBアプリはSSO・権限管理・基幹システム連携・MDM配布といった業務固有の要件が重く、これらを発注者側がどこまで言語化できるかが、品質と費用を決定づけます。
本記事は、BtoBアプリの要件定義書・RFP（提案依頼書）を、発注企業の視点から実務的に解説します。現場業務（AsIs）の可視化からあるべき姿（ToBe）の設計、SSO・権限・MDM・基幹連携といったBtoB固有要件の言語化、機能要件・非機能要件の整理とMust／Wantの仕分け、RFPに盛り込むべき項目と見積りの妥当性判断まで、人月単価などの一次データとあわせて具体的に解説します。読み終えるころには、ベンダーに渡せる要件定義・RFPの骨格が描けるようになるはずです。なお、全体像をまだ把握していない方は、まずBtoBアプリ開発の完全ガイドから読むことをおすすめします。
要件定義の出発点：AsIs業務とToBeの設計
BtoBアプリの要件定義は、機能の希望リストを作ることから始めるのではありません。まず現場の業務が実際にどう回っているか（AsIs）を可視化し、そのうえで業務をどう改善するか（ToBe）を描くことが出発点です。この順序を守るかどうかが、現場に使われるアプリと、誰も使わないアプリを分けます。
現場業務（AsIs）をヒアリングで可視化する
要件定義の最初の一歩は、現場の関係者へのヒアリングです。営業・現場作業者・管理者・経理など、アプリを使うことになる人たちに「実際にどう業務を進めているか」「どこに無駄や手戻りがあるか」「何に困っているか」を細かく聞き取ります。紙やExcel、電話、口頭での申し送りといった現状のやり方を、業務フローとして書き起こすことで、アプリで解決すべき課題が具体的に見えてきます。この工程を省くと、経営層の理想だけが反映された、現場の実態と乖離したアプリになりがちです。
ヒアリングで特に注意したいのが、現場と経営層で「欲しいもの」が食い違う点です。現場は今の業務を楽にする多機能を求め、経営層はコストと短期成果を重視します。この板挟みを放置すると、要件が膨張するか、逆に現場無視の機能になります。要件定義では、双方の声を可視化したうえで、どの課題を優先的に解決するかの合意形成が必要です。AsIsの可視化は、その合意のための共通言語を作る作業でもあります。現場の業務理解を怠った要件定義が招く失敗は、関連記事『BtoBアプリ開発／導入の失敗／課題／注意点／リスクについて』で詳しく扱っています。
ToBeモデルで業務定着までを設計する
AsIsを可視化したら、次はあるべき業務の姿（ToBe）を設計します。ToBeモデルとは、アプリ導入後に業務がどう変わるかを描いた青写真です。たとえば「営業が訪問先でアプリに受注を入力し、それが基幹システムに自動連携され、事務の再入力がなくなる」といった、改善後の業務フローを具体的に定義します。ここで重要なのは、アプリの機能だけでなく、誰がどう使い、どう業務が回るかという「定着までの絵」を描くことです。機能を作っても運用が回らなければ意味がありません。
ToBe設計では、業務の変化に対する現場の抵抗も見込んでおく必要があります。新しいアプリは、慣れた紙や電話のやり方を変えることを意味し、現場には負担に感じられます。だからこそ「今より明確に楽になる」体験を設計し、移行期の二重運用や教育まで要件に含めることが、業務定着の鍵になります。ToBeモデルは、アプリの仕様書である以上に、業務改革の設計図です。この設計図があるからこそ、ベンダーは発注者の意図を正しく理解し、適切な提案ができます。AsIsとToBeの設計こそ、要件定義の心臓部だと言えます。
BtoBアプリ固有の要件を言語化する
BtoBアプリの要件定義がBtoCアプリと決定的に異なるのが、業務固有の要件の重さです。SSO・権限管理・MDM配布・基幹システム連携といった要件は、発注者が明確に言語化しなければ、ベンダーは見積もれません。これらを曖昧にしたまま発注すると、後から大きな追加費用や手戻りが発生します。
SSO・権限管理・MDM配布の要件化
SSO（シングルサインオン）は、どのID基盤（Microsoft Entra ID、Google Workspace、各種IDaaSなど）と、どのプロトコル（SAML、OIDC）で連携するかを要件に明記します。あわせて、多要素認証や生体認証をどこまで求めるかも記載します。権限管理については、組織のどの役割が、どのデータや機能にアクセスできるかという「権限マトリクス」を作成するのが理想です。営業・マネージャー・経理・管理者といったロールごとの権限を一覧化しておくと、ベンダーは正確に設計でき、リリース後の「この人にこの情報を見せてはいけなかった」というトラブルを防げます。
MDM配布についても、要件として明確にします。アプリをApp StoreやGoogle Playで一般公開するのか、それともApple Business Manager（ABM）やManaged Google Play、MDM製品（Microsoft Intune等）を使って許可した端末にだけ配布するのかを指定します。配布方法によってアプリの設計や審査対応が変わるため、これを後から決めると手戻りになります。さらに、紛失時のリモートデータ消去や強制アップデートといった管理要件も、運用を見据えてRFPに盛り込んでおくべきです。これらBtoB固有の要件の言語化が、的確な見積りと提案を引き出す前提になります。
基幹システム連携とオフライン要件の整理
基幹システム連携は、要件定義でもっとも詰めるべき領域の一つです。どの基幹システム（ERP・SFA・CRMなど）と、どのデータ（受注・在庫・顧客マスタ・請求など）を、どの方向に（アプリから基幹へ／基幹からアプリへ）、どの頻度で（リアルタイム／バッチ）連携するのかを具体的に整理します。相手システムが連携用のAPIを持っているか、持っていない場合はどう接続するかも確認が必要です。連携要件が曖昧だと、開発の後半で「連携できなかった」という致命的な手戻りが起きます。
オフライン要件も、現場で使うBtoBアプリでは欠かせません。通信が不安定な場所で使うなら、どの機能をオフラインで動かし、どのタイミングで同期するかを要件に定義します。オフライン対応は実装コストに直結し、技術形態の選定にも影響するため、要件の段階で明確にしておく必要があります。これらの連携・オフライン要件は技術的な詰めが必要なため、要件定義のフェーズからベンダーや技術者と協働し、実現可能性を検証しながら固めるのが現実的です。どんな機能をどう実現するかは、関連記事『BtoBアプリの必要機能や標準機能の一覧について』もあわせてご覧ください。
機能要件・非機能要件とMust／Wantの仕分け
要件は、機能要件と非機能要件に分けて整理します。機能要件は「何ができるか」、非機能要件は「どのくらいの性能・安全性・安定性で動くか」です。BtoBアプリでは、見落とされがちな非機能要件が品質を左右します。あわせて、機能をMust／Want／将来に仕分けることが、コストと納期を守る要諦です。
機能要件を必須・優先・将来で分類する
機能要件は、すべてを同列に扱うのではなく、優先度をつけて分類します。「これがないと業務が回らない」必須（Must）、「あると効果が高い」優先（Want）、「いずれ欲しい」将来（Future）の3段階に仕分けるのが基本です。SSO・権限管理・基幹連携・オフライン対応といった土台はMust、凝ったダッシュボードやAI予測はWantやFutureに置く、というように分けます。この優先順位づけがあると、予算や納期の制約が出たときに、何を削るかの判断が即座にできます。
仕分けの過程では、現場と経営層の合意形成が不可欠です。現場の「あれもこれも」をすべてMustにすると、要件が膨張して予算を超過します。逆に経営層のコスト優先で必須機能まで削ると、使われないアプリになります。両者の声を踏まえ、ROIや業務影響を基準にMust／Wantを線引きすることが、要件定義担当者の腕の見せどころです。まずはMustだけでMVP（最小限の製品）をリリースし、現場の定着を見ながらWant・Futureを追加していく段階的アプローチが、失敗リスクを大きく下げます。
非機能要件（性能・セキュリティ・可用性）とOS／言語の指定
非機能要件は、性能・セキュリティ・可用性などを定義します。性能では、画面の応答速度や同時利用人数、データ量の上限などを示します。セキュリティでは、通信の暗号化、データの保管方法、監査ログ、規制業界なら準拠すべき基準を明記します。可用性では、稼働率の目標や障害時の復旧時間を定めます。これらの非機能要件は、見た目に表れにくいぶん軽視されがちですが、業務の根幹を支えるBtoBアプリでは、止まったときの影響が大きいため極めて重要です。
あわせて、対応OS（iOS／Android）と技術形態・言語の方針もRFPで指定します。日本市場はiOSのシェアが高く、物流・製造の業務端末ではAndroidが多いなど、ターゲットによって優先するOSは変わります。技術形態（ネイティブ／ハイブリッド／Web）や言語（Swift／Kotlin／Flutterなど）は、性能要件と内製化の方針から選びます。言語別の年収相場はKotlinが約873万円、Swiftが約868万円とほぼ同水準で、内製化を見据えるなら採用市場まで考慮が必要です。指定を細かくしすぎるとベンダーの提案の幅を狭めるため、「必須の制約」と「ベンダーに委ねる部分」を区別して書くのがコツです。
RFPの書き方と見積りの妥当性判断
要件を整理したら、それをRFP（提案依頼書）にまとめてベンダーに渡します。RFPは、ベンダーが正確な提案と見積りを出すための情報源であり、その質が相見積もりの精度を左右します。ここでは、RFPに盛り込むべき項目と、返ってきた見積りの妥当性を判断する軸を整理します。
RFPに必ず盛り込むべき項目
RFPには、最低限、次の項目を盛り込みます。プロジェクトの背景と目的、解決したい業務課題（AsIsとToBe）、機能要件（Must／Want／将来の分類つき）、非機能要件（性能・セキュリティ・可用性）、BtoB固有要件（SSO・権限・MDM配布・基幹連携）、対応OSと技術形態の方針、想定予算と納期、運用保守の条件、そして提案・選定のスケジュールです。これらが揃っていると、ベンダーは前提を揃えて提案でき、各社の見積りを同じ土俵で比較できます。
RFPで特に意識したいのが、「何を実現したいか（目的）」と「どう実現するか（手段）」を分けて書くことです。目的を明確にしつつ、実現手段はベンダーの専門性に委ねる余地を残すと、各社の知見を活かした多様な提案が集まります。手段まで細かく縛りすぎると、ベンダーは言われた通りに見積もるだけになり、より良い代替案が出てきません。良いRFPは、発注者の意図を正確に伝えつつ、ベンダーの提案力を引き出すバランスの上に成り立ちます。
見積りの妥当性を判断する軸（人月単価）
複数のベンダーから見積りが返ってきたら、その妥当性を人月単価から判断します。発注先別の人月単価の目安は、フリーランスが60〜80万円、中小開発会社が80〜120万円、大手SIerが150〜300万円です。同じ規模でも、誰に頼むかで総額は数倍変わります。価格差は、中間マージンや組織維持費、多重下請けの保険料に由来します。見積りを比較するときは、総額だけでなく「何人月で、どの単価か」に分解して見ることが重要です。
「開発一式◯◯円」とだけ書かれた見積りには注意が必要です。内訳が不透明だと、後から「これは別費用です」という追加請求が発生しやすくなります。要件定義・設計・開発・テスト・運用保守の各工程が、それぞれ何人月かが明示されている見積りを選ぶべきです。また、運用保守費は初期開発費の年間15〜20%が相場とされるため、初期費用だけでなくTCO（総保有コスト）で比較します。要件定義を有償フェーズとして切り出し、まず要件を固めてから本開発の見積りを取る、という二段階の進め方も、見積り精度を高める有効な手段です。見積りの落とし穴については、関連記事『BtoBアプリ開発／導入の失敗／課題／注意点／リスクについて』もご覧ください。
まとめ
BtoBアプリの要件定義とRFP作成を振り返ると、成功の核心は「現場業務（AsIs）の可視化とToBe設計を起点に、SSO・権限・MDM・基幹連携という固有要件を言語化し、機能要件をMust／Want／将来に仕分け、非機能要件と技術形態の方針までRFPに盛り込む」ことに集約されます。見積りは人月単価と工程別内訳で妥当性を判断し、運用保守費を含めたTCOで比較します。要件定義はベンダー丸投げにせず、業務知識を持つ発注者が主役として関与し、技術的な部分はベンダーと協働で固めるのが現実的です。
要件定義の質は、そのままアプリの品質と費用に跳ね返ります。現場を起点にし、固有要件を丁寧に言語化し、必要なら要件定義を有償フェーズとして切り出す。この一手間が、予算超過や使われないアプリという失敗を防ぎます。riplaはフルスクラッチ受託と国内開発の知見をもって、業務から逆算した要件整理を支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。