eラーニングシステムのRFP/要件定義書/提案依頼書について

eラーニングシステムの導入を成功させられるかどうかは、開発に着手する前のRFP（提案依頼書）と要件定義書の出来で、その大半が決まります。多くの失敗は、技術や予算ではなく「何を作りたいのかを発注側が言語化できていなかった」ことに起因します。配信したい教材、想定する受講者数、必要なテスト要件、既存システムとの連携、運用体制といった要素を曖昧にしたままベンダーに丸投げすると、提案の比較もできず、完成後に「思っていたものと違う」という事態を招きます。

本記事は、eラーニングシステムのRFP・要件定義書・提案依頼書の作り方を、発注企業や教育機関の視点から実務的に解説する「要件定義特化」の内容です。RFPに盛り込むべき項目の構成、機能要件と非機能要件の整理、受講者規模やセキュリティといった見落としがちな前提条件、そして調達・選定プロセスの設計まで、つまずきやすいポイントを具体的に取り上げます。読み終えるころには、自組織のRFPの骨子を描けるようになるはずです。なお、eラーニングシステム全体の検討プロセスをまだ把握していない方は、まずeラーニングシステムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・eラーニングシステムの完全ガイド

RFP・提案依頼書に盛り込むべき項目

RFP（提案依頼書）は、ベンダーに「こういうシステムを作ってほしい」という条件を伝え、各社から比較可能な提案を引き出すための文書です。ここが曖昧だと、ベンダーごとに前提がばらばらの提案が返ってきて、金額も機能も横並びで比較できません。逆に、必要な項目を漏れなく整理したRFPは、提案の質を高め、見積もりの精度を上げ、後の認識違いを防ぎます。

RFPの冒頭で必ず記すべきが、導入の背景と目的です。「集合研修の運営コストを削減したい」「全社員のコンプライアンス研修の受講率と証跡管理を改善したい」「教育機関として児童生徒の学習履歴を一元管理したい」など、何のために導入するのかを言葉にします。この目的が明確なほど、ベンダーは目的に沿った提案を返しやすくなり、機能の優先順位も自ずと定まります。

あわせて、達成したいゴールをできるだけ定量的に示します。「研修運営工数を年間でどれだけ削減したいか」「受講率を何パーセントまで引き上げたいか」といった目標値があれば、提案の評価軸にもなります。目的とゴールを最初に共有することで、ベンダーとの間に「このプロジェクトは何のためにあるのか」という共通認識が生まれ、要件のぶれを防ぐ土台になります。背景・目的・ゴールの明文化は、RFPの中でもっとも重要な出発点です。

RFPには、今回の調達がカバーする対象範囲を明記します。教材作成までベンダーに依頼するのか、システム構築だけを求めるのか、導入後の運用保守を含むのか、といった範囲の線引きです。範囲が曖昧だと、提案に含まれる作業が各社でばらつき、見積もりの比較ができなくなります。研修コンテンツの制作を含むかどうかは、費用に大きく影響する典型的な論点です。

予算とスケジュールの提示も欠かせません。予算の概算を示すことで、ベンダーは現実的な範囲で提案を組み立てられます。SaaS型の利用なら初期数十万円から数百万円、月額数万円から数十万円が一つの目安ですが、独自要件を満たすフルスクラッチや既存システムとの密な連携を伴う場合は規模が変わります。希望する稼働開始時期や、研修の実施時期に合わせたマイルストーンを示せば、無理のない計画での提案を引き出せます。対象範囲・予算・スケジュールの三点は、提案を比較可能にするための必須情報です。

機能要件と非機能要件の整理

要件定義の中核が、機能要件と非機能要件の整理です。機能要件は「システムが何をできるべきか」、非機能要件は「どれだけの性能・品質・安全性を満たすべきか」を定めます。eラーニングでは機能要件に目が行きがちですが、非機能要件を軽視すると、稼働後にアクセス集中で落ちる、セキュリティ事故が起きる、といった深刻なトラブルにつながります。両方をバランスよく定義することが大切です。

機能要件は、配信・テスト・受講管理・権限・分析・連携といった軸ごとに、必要な機能を列挙します。このとき重要なのが、すべてを「必須」にしないことです。「絶対に必要な機能（必須）」と「あれば望ましい機能（任意）」を分けて優先度をつけると、ベンダーは予算内で何を実現するかを判断しやすくなり、現実的な提案が返ってきます。すべてを必須にすると、見積もりが膨らみ、優先すべき機能まで実現できなくなる恐れがあります。

各機能要件は、できるだけ具体的に記述します。「テスト機能が必要」ではなく、「選択式・記述式の出題に対応し、合格点を設定して不合格者を再受験させ、出題順をランダム化できること」と書けば、提案のずれが減ります。記述があいまいだと、ベンダーは最小限の解釈で見積もり、後から「その機能は別途費用」となりがちです。機能要件は、優先度づけと具体的な記述の二点が、提案の精度を左右します。

機能要件を正しく洗い出すには、いきなり「欲しい機能」を列挙するのではなく、まず現状の研修運営がどう行われているかを棚卸しすることが近道です。今どんな研修を、誰に、どんな頻度で実施し、どこに手間や課題があるのかを整理すれば、システムで解決すべきことが自ずと見えてきます。現場の担当者へのヒアリングを通じて、表に出にくい運用上の困りごとを拾い上げることが大切です。

現状業務を可視化すると、「実は不要な機能」も見えてきます。あれもこれもと欲張って要件を盛り込むと、費用が膨らみ、使いこなせない機能が増えるだけです。現状の課題に直結する機能に絞り込むことで、過不足のない現実的な要件になります。要件定義は、理想を並べる作業ではなく、自組織の業務実態から逆算して必要なものを見極める作業です。現状業務の棚卸しという地道な一手間が、無駄のないRFPと、稼働後に本当に使われるシステムの土台になります。

非機能要件では、まず性能要件を定めます。eラーニングは、コンプライアンス研修の締め切り前や、新学期の開始時などにアクセスが集中しがちです。「同時に何人が利用してもストレスなく動作するか」「動画がスムーズに再生されるか」といった性能を、想定するピーク時の同時アクセス数とともに示すことが重要です。締め切り直前にシステムが落ちれば、受講率も信頼も損なわれます。

あわせて、可用性（どれだけ止まらずに動くか）、バックアップ・障害復旧の方針、保守・運用のサポート体制、対応ブラウザや端末の範囲も非機能要件として定めます。保守費用の目安はパッケージで初期費用の年10〜15%程度とされることが多く、運用フェーズのコストとして見込んでおくべきです。SLA（サービス品質保証）として稼働率や障害時の対応時間を明記すれば、稼働後の責任分界も明確になります。非機能要件は、稼働後の安定運用を左右する、見落としてはならない領域です。

すでに別のeラーニングや独自の仕組みで研修を運用している組織では、既存の教材や過去の受講履歴をどう新システムに移すかが、見落とされがちな要件です。過去の修了記録は、法定研修の証跡や人事データとして引き継ぐ必要があることが多く、移行できないと過去の実績が断絶してしまいます。RFPには、移行対象のデータ種別・量・形式と、移行をベンダー作業に含めるかを明記すべきです。

データ移行は、見た目以上に手間とリスクを伴う作業です。旧システムからデータを正しく取り出せるか、新システムの形式に変換できるか、移行後に欠損や重複がないかの検証が必要になります。移行要件を曖昧にしたまま契約すると、稼働直前に「過去データが移せない」と判明し、計画が破綻しかねません。新旧システムが並行稼働する過渡期の運用方針も含めて、データ移行を要件として早期に詰めておくことが、スムーズな切り替えの前提になります。

受講者規模・セキュリティなど見落としがちな前提

RFPで意外と抜け落ちるのが、受講者の規模やセキュリティといった前提条件です。これらは機能の一覧には現れにくいものの、システムの設計やコストを根本から左右します。前提が共有されていないと、提案が現実とかけ離れ、稼働後に「これでは運用できない」という事態を招きます。前提条件こそ、最初に丁寧に詰めるべき要素です。

受講者の総数と、ピーク時の同時アクセス数は、システムの規模を決める根本の前提です。総数100名と1万名では、求められる性能もライセンス費用も大きく異なります。SaaS型の多くはアカウント数や同時アクセス数に応じた料金体系のため、規模の見積もりは費用に直結します。現時点の人数だけでなく、将来の拡大も見越して幅を持たせて示すことが大切です。

あわせて、将来の拡張余地を要件に含めておくと、後の手戻りを防げます。今は社内研修だけでも、将来は取引先や顧客向けの研修にも広げたい、教育機関なら対象校を増やしたい、といった展望があれば、それを前提に拡張性のある設計を求められます。スモールスタートで始めつつ将来の拡大に耐える設計にするか、最初から大規模を見据えるかで、アーキテクチャの選択が変わります。受講者規模と拡張性は、RFPで必ず数値とともに示すべき前提条件です。

RFPで意外と抜けるのが、導入後に誰がどう運用するのかという前提です。教材を作る担当、受講状況を管理する担当、問い合わせに対応する担当を、自組織のどの部署が担うのかを整理しておかないと、稼働後に「運用する人がいない」という事態に陥ります。専任の担当者を置けないなら、運用負荷の少ないシンプルな構成を選ぶ、あるいは運用代行をベンダーに依頼する、といった選択が必要になります。

あわせて、管理者や受講者への操作教育をどう行うかも前提として共有すべきです。どれだけ優れたシステムでも、使い方が分からなければ活用されません。管理者向けのマニュアルや操作研修、受講者向けの利用案内をベンダー作業に含めるかどうかは、RFPで明確にしておきたい点です。導入後の運用体制と教育の前提を要件に織り込んでおくことで、「導入したのに使われない」という典型的な失敗を、調達の段階から予防できます。運用を見据えた要件定義こそ、定着するシステムの出発点です。

eラーニングは、受講者の氏名・所属・受講履歴・成績といった個人情報を扱います。とくに教育機関では児童生徒の個人情報を、規制業種では従業員の研修記録を扱うため、セキュリティ要件は厳格に定める必要があります。データの暗号化、アクセス制御、通信の保護、ログの取得といった基本要件に加え、データの保管場所（国内データセンターの指定など）を求めるケースもあります。

組織として準拠すべきセキュリティ基準があれば、それをRFPに明記します。情報セキュリティの認証取得状況や、官公庁・自治体・教育委員会の調達では政府情報システムのセキュリティ評価制度などへの対応を求めることもあります。設定ミスによる個人情報の外部閲覧といった事故は、ベンダー任せにした結果として起こりがちです。誰がどのデータにアクセスできるかの権限設計と、事故時の責任分界をRFPの段階で定めておくことが、後の重大なトラブルを防ぎます。セキュリティ要件は、機能要件と同等以上に重視すべき項目です。

調達・選定プロセスの設計

RFPを作っただけでは、よい調達にはなりません。どのように提案を募り、どの基準で評価し、どう選定するかというプロセスの設計が、最終的なベンダー選びの質を決めます。とくに教育機関や公的機関では、公募型プロポーザルや総合評価方式といった調達手続きが定められていることもあり、プロセスの設計は要件定義と同じくらい重要です。

提案を比較する際は、評価基準を事前に定めておくことが公正な選定の前提です。価格だけで選ぶと、安くても要件を満たさない提案や、運用が立ち行かない提案を選んでしまいかねません。機能の充足度、非機能要件への対応、運用サポートの体制、ベンダーの実績、価格といった複数の観点に重みづけをして総合評価する方法が、バランスのよい選定につながります。

提案内容を正しく見極めるには、デモやトライアルを評価プロセスに組み込むことも有効です。実際の操作感や、自組織の教材を載せたときの動作を確認すれば、書類だけでは分からない使い勝手を評価できます。受講者となる現場の担当者にも触ってもらい、その声を評価に反映すると、稼働後の「使われない」リスクを下げられます。評価基準を明文化し、デモで実物を確かめるプロセスが、選定の精度を高めます。

提案の良し悪しは、機能と価格だけでは判断しきれません。同業種・同規模での導入実績があるベンダーは、自組織特有の課題を理解しやすく、提案の精度も高くなります。教育機関や規制業種なら、その分野での実績を確認しておくと安心です。あわせて、導入後のサポート体制も評価に含めます。問い合わせ窓口の対応時間、障害時の連絡フロー、運用面の相談に乗ってくれるかといった点は、稼働後の安心感を大きく左右します。

大規模な導入や独自要件が多い場合は、本格契約の前に小規模な試行（PoC、概念実証）を行うことも有効です。一部の部署や限られた教材で実際に運用してみれば、机上の検討では見えなかった課題が早期に表面化し、本格展開のリスクを下げられます。試行で得た知見をもとに要件を見直せば、本契約の精度も上がります。実績・サポート体制の確認とPoCの活用は、調達の失敗を未然に防ぎ、提案の信頼性を見極める実務的な手段です。書類とデモだけでなく、実績と試行で裏づけを取ることが、堅実な選定につながります。

調達の大きな分岐点が、既製のSaaS型eラーニングを使うか、独自にフルスクラッチで構築するかの判断です。標準的な研修配信と受講管理が主目的で、要件が一般的な範囲に収まるなら、SaaS型を活用するのが初期費用を抑えつつ早く始められる現実的な選択です。一方、既存の基幹システムとの密な連携、独自の学習フロー、厳格なセキュリティや運用要件がある場合は、フルスクラッチが適することがあります。

判断の軸は「要件の独自性」と「既存システムとの連携の深さ」です。要件が標準的で連携も軽いならSaaS、独自性が高く連携が複雑ならフルスクラッチ、という整理がひとつの目安になります。riplaはフルスクラッチ受託と国内開発の立場から、まず要件を整理し、SaaSで足りる部分とフルスクラッチが必要な部分を切り分けたうえで、無理のない構成を提案することを重視しています。RFPの段階でこの判断軸を持っておくと、過剰投資も機能不足も避けられます。調達・選定プロセスの設計こそ、要件定義の成果を実際の成功につなげる最後の鍵です。

まとめ

eラーニングシステムのRFP・要件定義書を整理すると、導入の背景・目的・ゴールの明文化を土台に、機能要件と非機能要件のバランスのよい定義、受講者規模やセキュリティといった前提条件の共有、そして評価基準とSaaS／フルスクラッチの判断軸を含む調達プロセスの設計が、成功の骨格を成すことが見えてきます。機能要件は必須・任意で優先度をつけ、非機能要件はピーク時の同時アクセスやセキュリティを軽視せず、前提条件は数値とともに示すことが、提案を比較可能にする鍵です。

RFPを作るときに大切なのは、ベンダーに丸投げするのではなく、「何のために、誰が、どれだけの規模で使うのか」を発注側が言語化することです。この一手間が、提案の質と見積もりの精度を高め、稼働後の「思っていたものと違う」を防ぎます。riplaはフルスクラッチ受託と国内開発を組み合わせ、要件の言語化から、SaaSとフルスクラッチの切り分け、無理のない構成設計までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

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