学習アプリのRFP/要件定義書/提案依頼書について

学習アプリ開発で成否を分ける最大の分岐点は、要件定義です。目的・ターゲット・成果KPIを言語化しないままRFP(提案依頼書)を出すと、開発後に手戻りが起きやすくなります。

学習アプリ開発の全体像をまだ把握していない方は、まず学習アプリ開発の完全ガイドからご覧ください。

目的・ターゲット・成果KPIの定義

学習アプリの成果KPIとして、基礎テストの平均点、合格率、ITパスポートの合格率を数値例とともに並べた図。
平均点と合格率では、目標の表し方が異なります。

要件定義の出発点は、何のために、誰に向けて、どんな成果を狙う学習アプリなのかを言語化することです。ここが曖昧なまま機能の検討に進むと、ベンダーは作りやすい機能を提案しがちで、肝心の成果につながらないアプリになります。そこで、目的とターゲットを定め、測定できるKPIまで決めておくことが欠かせません。

学習者像とユースケースの具体化

まず固めるべきは、ターゲットとなる学習者像です。小学生なのか、資格を目指す社会人なのか、企業の新入社員なのかによって、必要なUXは大きく変わります。

子ども向けの場合は、ゲーミフィケーションと保護者の関与が重要になります。一方、社会人の資格対策では、すきま時間での効率的な学習と復習アルゴリズムが効いてきます。

そのうえで、学習者像を具体的に描き、RFPに明記します。そうすると、ベンダーは的確な提案を出しやすくなります。

ユースケースも具体化しておくと、要件が現場の場面から自然に見えてきます。「通勤電車で5分だけ問題を解く」「就寝前に今日の復習をする」といった場面を描けば、オフライン対応や通知のタイミングといった要件が導かれます。

学習者が日常のどこでアプリを使うかを想定すると、実際に使われる要件定義につながります。この学習者像とユースケースは、要件定義書の冒頭に置くべき、最も重要な前提です。

  • 対象者:年齢や学習目的など、誰に向けたアプリかの記述
  • 利用場面:時間帯や場所ごとに、どう使われるかの想定

継続率・合格率・点数のKPI設定

学習アプリの要件定義で特に重要なのは、成果KPIを数値で設定することです。

学習アプリの成果は曖昧になりがちです。しかし「継続率」「合格率」「点数の伸び」といった指標で目標を定めれば、開発の方向性が定まり、リリース後の改善も評価できます。

たとえば、基礎テストの平均点を15%向上、合格率を10ポイント向上といった目標を置けます。また、ITパスポートの合格率が60%から85%へ上がったといった一次データの実績を参考に、自社の現状値と目標値を設定します。

とりわけ、KPIの中心に「継続率」を据えることをおすすめします。学習アプリは、継続率がすべての成果の前提になるからです。

継続の指標を目標に組み込むと、ベンダーに「続けさせる設計」を要件として示せます。

KPIを曖昧にしたまま発注すると、ベンダーは機能の完成をゴールにしてしまい、継続率という肝心の成果が置き去りになります。測定可能なKPIを定めることが、成果を出す要件定義の要です。

  • 継続の指標:30日後・90日後の利用継続、連続学習日数の平均
  • 成果の指標:基礎テストの平均点、合格率、点数の伸び

ポイント

目的とターゲットが定まり、成果KPIを数値で書けているかが、判断の目安になります。学習者像やユースケースまで具体的に描けていれば、ベンダーは的確な提案を出しやすくなります。

継続率を高めるUX要件の言語化

継続率を高めるUX要件として、報酬の付与ルール、通知、出題調整、復習の仕組みを4項目で示した図。
学習者への働きかけと出題内容の調整が並びます。

成果KPIを定めたら、それを実現するUX要件を言語化します。継続率を高めるゲーミフィケーションや通知、復習アルゴリズムといった仕掛けは、「とりあえず付けてほしい」という依頼のままでは成果につながりにくくなります。そのため、どんな学習者に、どのタイミングで、どんな報酬や通知を返すかまで、要件として具体化する必要があります。

ゲーミフィケーション・通知の要件化

ゲーミフィケーションを要件化するときは、どの仕掛けを使うかと、どんな条件で付与するかを決めます。仕掛けには、ポイントやバッジ、ランキング、アバターなどがあります。

「毎日続けると連続記録が伸びる」「一定の正答で次のレベルに上がる」といった具体的なルールを示せば、ベンダーは継続を生む設計を実装できます。

進研ゼミのタブレット教材では、東京大学の藤本徹准教授監修のゲーミフィケーションが導入された例があります。こうした例からも分かるように、報酬の出し方は専門的な設計対象です。そのため、要件としても丁寧に記述することが大切です。

プッシュ通知では、どんな内容を、いつ、どの頻度で送るかを定義します。

「学習が途絶えて3日経ったら復帰を促す」「毎朝決まった時間に今日の学習を届ける」といった通知シナリオを要件に書くと、習慣化を支える設計につながります。

通知は押しつけがましいと逆効果になるため、頻度の上限やオプトアウトの仕組みも要件に含めます。UX要件を曖昧にせず言語化することが、継続率というKPIを達成する前提になります。

具体的な機能の一覧は、『学習アプリの必要機能や標準機能の一覧について』もあわせてご覧ください。

  • 付与のルール:連続記録や正答数など、報酬を出す条件の数値
  • 通知の設計:文面、送信のタイミング、受け取りの停止方法

AI個別最適化・復習アルゴリズムの要件化

AIによる個別最適化を要件化するときは、何のデータをもとに、何を調整するかを明確にします。

正答率や解答時間、つまずいた単元といったデータを使い、出題の難易度や順序をどう調整するかを定義します。

AIアダプティブラーニングは実装の難易度が高く、そのぶん費用も上がります。AI活用型は800〜2,000万円以上です(出典:ripla)。

そのため、自社のKPIに本当に必要かを見極めたうえで、要件に含めることが大切です。「AIを使いたい」とだけ曖昧に書くと、過剰な投資につながりかねません。

復習アルゴリズムの要件も具体化します。忘却曲線に基づいて、いつ、どの問題を、何回復習させるかのロジックを、自社の学習内容に合わせて定義します。

資格対策のように明確なゴールがある場合は、試験日から逆算した復習スケジュールを要件に組み込むのも有効です。AI個別最適化と復習アルゴリズムは、成果KPIに直結する一方で、費用を押し上げる領域でもあります。

だからこそ、要件定義の段階で「必須・優先・将来追加」の優先順位を付け、初期リリースで何を実装するかを決めておくことが、予算管理につながります。

  • 調整の対象:正答率、解答時間、つまずいた単元と、出題の難易度・順序
  • 復習の仕組み:出題する問題、復習の回数、試験日からの逆算

ポイント

継続率を高める仕掛けについて、どんな学習者に、どのタイミングで、どんな報酬や通知を返すかが書かれているかが、判断の目安です。通知の頻度の上限まで書けていれば、UX要件として具体的といえます。

著作権・保護者同意の要件への翻訳

学習アプリを中心に、利用許諾の範囲や期限切れ時の非表示、16歳未満の個人情報、保護者の同意取得を囲む保護要件の図。
権利の管理と保護者同意を、要件として並べて確認できます。

ここは、学習アプリの要件定義で最も見落とされやすく、差がつきやすい部分です。多くの記事は「法律に注意」とだけ書いていますが、実務で必要なのは、法律をシステムの具体的な要件に翻訳することです。

学習アプリ特有の論点は、教材や試験問題の著作権処理と、子どもの学習ログを扱う際の保護者同意の取得です。これらを要件として明文化しないまま開発を進めると、リリース後に重大な問題に直面します。

教材・試験問題の著作権処理の要件化

学習アプリでは、他人が作成した教材や過去問、試験問題をデジタル配信するケースが多くあります。見落とされやすいのが、この著作権の権利処理です。

紙の教材なら問題がなかったものでも、アプリで不特定多数に配信すると、複製権や公衆送信権の侵害になる可能性があります。

要件定義の段階で、どの教材や問題が自社のオリジナルかを整理します。外部の著作物を使う場合は、利用許諾をどう取るかも決めておきます。そのうえで、出典管理や利用範囲の制御を、システム上の要件として落とし込む必要があります。

具体的には、教材コンテンツに権利者情報や利用許諾の範囲を紐づけて管理する仕組みや、許諾期限が切れたコンテンツを自動で非表示にする仕組みを要件にします。

これらは機能としては地味ですが、著作権侵害は事業の存続に関わるリスクで、後から対応するのは困難です。

教材の著作権処理は、学習アプリの要件定義で必ず押さえるべき法的要件です。この要件を書けるかどうかは、ベンダーの専門性を測る指標にもなります。

コンテンツの権利処理を曖昧にしたまま開発を進めることは、避けるべきです。

  • 出典の区分:自社オリジナルか、外部の著作物かの区分
  • 公開の制御:利用許諾の期限と、期限切れ時の非表示

子どもの学習ログと保護者同意の要件化

子ども向けの学習アプリでは、学習ログや成績といった個人情報を扱います。そのため、保護者の同意取得が、法的にも倫理的にも欠かせません。

2026年の改正個人情報保護法では、16歳未満の個人情報の取り扱いがより厳しくなります。法定代理人(保護者)の同意取得や、子どもの最善の利益への配慮が求められます。

これをシステム要件に翻訳すると、保護者が同意した記録を残す仕組みと、子ども自身では同意できないようにする流れが必要になります。

とくに大切なのは、保護者同意を取得する画面のUI/UX設計です。同意画面が分かりにくかったり、子どもが簡単に通過できてしまったりすると、同意の有効性が問われます。

誰が、いつ、何に同意したかを明確に記録し、後から証明できる形で残しておく必要があります。

これらの保護者同意に関する要件は、子ども向け学習アプリの根幹です。要件定義の段階でUI/UXまで具体化しておくことが、後のトラブルを防ぐ最大の予防策になります。

  • データの扱い:学習ログの収集範囲、保存期間、第三者提供の有無
  • 保護者の権限:データの確認や削除を求められる仕組み

ポイント

著作権と保護者同意が、画面や記録、非表示といったシステム要件の形で書かれているかが、判断の目安になります。法律の内容を並べるだけで終わっていないかも、見直すとよいでしょう。

既存システム連携とRFPの記載項目

機能とUX、法的要件を固めたら、最後に既存システムとの連携要件と、RFPに盛り込む項目を整理します。

学習アプリは単独でも動きますが、学校の校務システムや企業の人事・研修管理システム、決済システムなどと連携すると、運用の負荷を下げられます。さらに、成果管理も効率化できます。

この連携要件と非機能要件をRFPに明記すると、見積りの精度とベンダー比較の公平性が高まります。

連携要件と非機能要件の明文化

連携要件では、どのシステムと、どのデータを、どの方向にやり取りするかを定義します。たとえば企業研修なら、人事システムから受講者情報を取り込み、学習結果を研修管理に戻す連携が考えられます。

決済が絡むサブスクリプション型では、決済システムとの連携が必須です。連携の内容を明記すると、ベンダーは連携の工数を正確に見積もれます。

連携要件が曖昧だと、見積りに大きなブレが生じ、後から追加費用が発生します。

非機能要件も欠かせません。同時アクセス数の想定(試験前に学習者が集中するなど)や、画面表示やレスポンスの速度を定めます。さらに、セキュリティ(個人情報の暗号化・アクセスログ)や、対応する端末・OSも要件に含めます。

また、可用性(稼働率の目標)も定義します。学習アプリは、すきま時間にストレスなく動くことが継続率に直結するため、性能要件を外せません。

これらの非機能要件をRFPに盛り込めば、ベンダーは現実的な構成を提案でき、リリース後に「アクセスが集中すると重くて使えない」といった事態を防げます。

  • 連携の定義:連携先のシステム名、データ項目、連携頻度(リアルタイムか日次バッチか)
  • 非機能の目標:同時アクセス数、レスポンス速度、稼働率、セキュリティ、対応端末

RFPに盛り込む項目と見積りの比較観点

RFP(提案依頼書)には、ここまで整理してきた要素を体系的に盛り込みます。

中心になるのは、プロジェクトの目的と背景、ターゲット学習者、成果KPIです。そのうえで、機能要件は必須・優先・将来追加の優先順位を付けて書き、UX要件もあわせて示します。

法的要件や既存システム連携、非機能要件も、同じRFPに含めます。さらに、予算とスケジュールの目安、運用・保守の範囲も書いておきます。

これらを網羅したRFPを各ベンダーに同じ条件で示せば、提案を比べやすくなり、見積りの妥当性も判断しやすくなります。

見積りを比べるときは、金額の安さだけで判断しないことが大切です。継続率を高めるUX設計の理解度や、著作権・保護者同意への対応力、運用・改善の体制まで含めて評価します。

学習アプリは、作って終わりにせず、継続率を育てる長い運用が成果を左右します。そのため、運用フェーズの提案内容こそ、重点的に比べる対象になります。

単機能型は50〜150万円、AI活用型は800〜2,000万円以上と、費用には幅があります。そのなかで、自社のKPIに見合う投資かを見極める必要があります。RFPの精度が高いほど、この見極めの精度も高まります。

riplaは、フルスクラッチ受託とノーコードの両方を手がける立場から、要件整理とRFP作成を発注企業と一緒に進める支援を行っています。

  • 必須の記載:目的と背景、学習者像、成果KPI、機能要件の優先順位
  • 比較の観点:金額以外の評価軸を、提案ごとに同じ項目でそろえた比較

ポイント

連携先や連携頻度、非機能要件の数値目標がそろっているかが、見積りのブレを減らす目安になります。同じRFPを受け取ったベンダーが同じ前提で比べられるかも、確かめてください。

まとめ

学習アプリの要件定義は、目的・ターゲット・成果KPIの定義から始まります。そのあと、継続率を高めるUX要件を言語化し、著作権や保護者同意を法律からシステム要件へ翻訳します。そして、既存システム連携と非機能要件を整理して、RFPにまとめるのが基本の流れです。

なかでも、継続率・合格率・点数という測定可能なKPIを起点に、機能を逆算することが大切です。加えて、競合が触れにくい著作権処理と子どもの保護者同意のUI/UXを要件化することが、成果を出しつつリスクを避ける要件定義の核心です。これらを網羅したRFPがあれば、ベンダー比較の精度と見積りの妥当性が高まります。

要件定義で何より大切なのは、発注側が主体性を持つことです。学習者像やKPIは自社が一番よく知っているため、その核は自社が主導します。そのうえで、技術面と法的な翻訳は、ベンダーと協働で進めます。

この役割分担が、開発後の手戻りを防ぎます。riplaは、フルスクラッチ受託とノーコードを組み合わせ、ヒアリングから法的要件の翻訳、RFP作成までを発注企業と一緒に支援しています。全体像をつかむには、あらためて完全ガイドをご活用ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。