eラーニング導入の成否の大半は、開発前に作るRFP（提案依頼書）と要件定義書で決まります。そこで、RFPに背景・目的、対象範囲、予算、スケジュールを示し、要件と前提を整理しておくと、各社の提案を同じ前提で比べられます。
▼全体ガイドの記事
・eラーニングシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
RFP・提案依頼書に盛り込むべき項目
RFP（提案依頼書）は、システムに求める条件をベンダーに伝え、比較できる提案を得るための文書です。条件が曖昧なままだと、各社の前提がずれ、金額や機能を横並びで比べられません。そこで、必要な事項を先に整理しておくと、提案の質と見積もり精度が上がり、認識違いも防げます。
導入の背景・目的とゴールの明文化
RFPには、まず導入の背景と目的を書きます。目的が明確だと、ベンダーは目的に沿って提案を組み立てられ、機能の優先順位も決めやすくなります。背景と目的、ゴールは、課題と目標という別々の観点から書き分けます。
- 背景と目的：導入で解決したい課題を具体的に示す
- 達成するゴール：可能な範囲で定量的な目標を置く
目的の例は、集合研修の運営コストを減らすことや、全社員のコンプライアンス研修の受講率と証跡管理を改善することです。さらに、教育機関では、児童生徒の学習履歴をまとめて管理する目的もあります。
目標値の例は、研修運営の工数を年間でどれだけ減らすか、受講率を何パーセントにするかです。また、目的とゴールを共有しておくと、プロジェクトの認識がそろい、要件がぶれにくくなります。背景・目的・ゴールは、RFPの出発点です。
対象範囲・予算・スケジュールの提示
RFPには今回の調達範囲を明記し、予算とスケジュールも示します。どこまでを頼むか、いくらを見込むか、いつまでに動かすかを、提案の前に揃えておきます。
- 対象範囲：教材制作や構築、導入後の運用保守を含むか
- 予算：概算を示して現実的な提案につなげる
- 予定：稼働開始時期と研修に合わせた節目を示す
範囲が曖昧だと作業内容がばらつき、見積もりを比べにくくなります。なお、教材の制作を含めるかどうかも、費用を左右する論点です。予定では、希望する稼働開始時期を示し、研修時期に合わせたマイルストーンも置きます。
この3点をそろえておくと、同じ前提で各社の提案を比べられ、無理のない計画にもなります。予算の目安として、SaaS型は初期費用が数十万円から数百万円、月額が数万円から数十万円です。ただし、独自要件のフルスクラッチや密なシステム連携では、規模が変わります。
機能要件と非機能要件の整理
要件定義では、機能要件と非機能要件を整理します。機能要件は「何ができるか」、非機能要件は性能・品質・安全性の水準です。
両方をバランスよく定義することが大切です。特に、非機能要件を後回しにすると、稼働後のアクセス集中やセキュリティ事故につながります。
機能要件の必須・任意による優先度づけ
配信、テスト、受講管理、権限、分析、連携など、必要な機能を分野ごとに洗い出します。そのうえで、どれを必須にし、どれを任意にするかを決めると、予算に合う提案を得やすくなります。
- 必須：実現が欠かせない機能
- 任意：あれば望ましい機能
すべてを必須にすると、見積もりが膨らみ、優先機能まで実現できない恐れがあります。また、機能は具体的に書く必要があります。「テスト機能」ではなく、選択式・記述式の出題、合格点、不合格者の再受験、出題順のランダム化まで示します。
曖昧な記述だと、ベンダーは最小限の範囲で解釈するため、後から別途費用がかかる場合があります。優先度と具体性が、提案の精度を左右します。
現状業務の洗い出しから導く要件
機能要件は、現在の研修運営を洗い出し、そこから導くのが近道です。欲しい機能を先に並べるより、実際の業務に即した要件になります。洗い出しは、研修の実態を押さえ、現場の声を聞いたうえで、必要な機能を絞る流れで進めます。
- 研修の実態：内容、対象者、実施頻度を整理する
- 現場の課題：担当者への聞き取りで運用上の困りごとを拾う
- 必要な機能：課題に直結するものに絞り込む
業務を一覧にすると、不要な機能も見えてきます。理想の機能を並べるのではなく、実態から必要なものを見極めます。さらに、要件を増やしすぎると費用が膨らみ、使いこなせない機能ばかりが残ります。こうした洗い出しの一手間が、無駄のないRFPと、稼働後に使われるシステムの土台になります。
性能・可用性・運用の非機能要件
コンプライアンス研修の締め切り前や新学期には、アクセスが集中しがちです。そのため、ピーク時の性能と稼働後の運用条件を先に定めておきます。性能、可用性と復旧、運用条件の三つは、それぞれ具体的な水準で書きます。
- 性能：同時利用人数や動画再生の水準を示す
- 可用性・復旧：稼働、バックアップ、障害復旧の方針を示す
- 運用条件：サポート体制、対応端末やブラウザを定める
締め切り直前の停止は、受講率と受講者の信頼を損ないます。また、可用性とは、どれだけ止まらずに動くかを指します。
パッケージの保守費用は、初期費用の年10〜15%程度が目安とされることが多いため、運用費として見込んでおきます。加えて、稼働率や障害時の対応時間をSLA（サービス品質保証）に記載すると、稼働後にどこまでを誰が受け持つかがはっきりします。
非機能要件は稼働後の安定運用を左右するため、見落とさないよう定めておきます。
既存教材・受講履歴のデータ移行要件
別のeラーニングや独自の仕組みで運用中の組織では、教材や受講履歴の移行が見落とされがちです。そこで、移行対象と作業範囲をRFPに記載します。移行では、移すデータの中身、ベンダーに任せる範囲、新旧の切り替え方の三点を押さえます。
- 移行対象：データの種類、量、形式を示す
- 作業範囲：移行をベンダー作業に含めるか決める
- 切り替え方針：新旧システムの並行稼働も検討する
特に、過去の修了記録は、法定研修の証跡や人事データとして引き継ぐ必要がある場合があります。移行できないと、過去の実績が途切れてしまいます。
データ移行は、見た目以上に手間とリスクを伴います。具体的には、旧システムからの抽出、新システムの形式への変換、欠損や重複の検証が必要です。
移行要件が曖昧だと、稼働直前になってデータを移せないと判明し、計画が破綻する恐れがあります。だからこそ、移行の要件は早い段階で詰めておく必要があり、それが切り替えの前提になります。
受講者規模・セキュリティなど見落としがちな前提
RFPで抜け落ちがちなのが、受講者規模やセキュリティなどの前提条件です。機能一覧には現れにくいものの、設計やコストを左右します。さらに、前提が共有されないと、提案が現実とかけ離れ、稼働後に運用できない恐れもあります。そのため、前提条件は提案を受ける前に丁寧に詰めるべき要素です。
受講者数・同時アクセス・将来の拡張
システムの規模は、今の受講者数だけでなく、将来の拡大も見越して決めます。受講者規模と拡張性は数値で示し、幅を持たせると提案の前提がぶれません。規模を考えるときは、利用の大きさ、広がりの見込み、始めるときの規模の三つを見ます。
- 利用規模：受講者総数とピーク時の同時アクセス数
- 拡張の展望：対象者や対象校を広げる可能性
- 開始時の規模：小さく始めるか、当初から大規模にするか
総数100名と1万名では、必要な性能もライセンス費用も異なります。SaaS型はアカウント数や同時アクセス数に応じた料金体系が多く、規模の見積もりが費用に直結します。また、小さく始めて拡大に耐える設計にするか、最初から大規模を見据えるかで、アーキテクチャが変わります。
たとえば、社内研修を取引先や顧客向けにも広げる場合が考えられます。その展望を要件に含めておくと、後の手戻りを防げます。
導入後の運用体制と教育の前提
RFPで見落とされがちなのが、導入後に誰がどう運用するかという前提です。運用の担当と教育の方法を決めておかないと、稼働後に運用する人がいない事態になりかねません。どこまでを社内が担い、どこからをベンダーに任せるかを、運用担当、運用支援、操作教育の三つで整理します。
- 運用担当：教材作成、受講管理、問い合わせ対応の担当部署
- 運用支援：専任者がいない場合の簡素な構成や運用代行
- 操作教育：管理者・受講者向け案内をベンダー作業に含めるか
社内に専任者を置けない組織では、負荷の少ない構成やベンダーへの運用代行を検討し、どの作業を任せるかを早めに決めておく必要があります。せっかく導入しても、使い方が分からなければシステムは活用されません。そこで、教育をどこまで誰が担うかを要件の段階で決めておきます。
運用と教育を要件に含めておけば、導入したのに使われないという失敗を、調達の段階で防げます。そのうえで、管理者向けのマニュアルや操作研修、受講者向けの利用案内をどう行うかも共有します。また、運用を見据えて要件を定めることが、定着するシステムづくりの第一歩です。
個人情報保護とセキュリティ要件
eラーニングでは、氏名、所属、受講履歴、成績などの個人情報を扱います。教育機関は児童生徒の情報を、規制業種は従業員の研修記録を扱うため、要件を厳格に定める必要があります。対策の基本、保管場所、責任の範囲の三つを、要件として押さえます。
- 基本対策：暗号化、アクセス制御、通信保護、ログ取得
- 保管場所：国内データセンターなどの指定条件
- 責任の範囲：データへの権限と、事故時に誰が責任を負うかを定める
組織のセキュリティ基準や認証の取得状況は、RFPに明記します。なお、官公庁・自治体・教育委員会の調達では、政府情報システムのセキュリティ評価制度への対応を求める場合もあります。
設定ミスによる個人情報の外部閲覧などは、ベンダー任せにしていると起こりがちです。要件の段階で決めておけば、重大なトラブルを防げます。特に、セキュリティ要件は、機能要件と同等以上に重視すべき項目です。
調達・選定プロセスの設計
RFPを作るだけでなく、提案を募る方法、評価基準、選定の進め方も設計する必要があります。プロセスの組み方が、ベンダー選びの質を左右します。また、教育機関や公的機関では、公募型プロポーザルや総合評価方式など、調達の手続きが定められていることもあります。
評価基準と提案比較の方法
公正に選ぶには、提案を比べる評価基準を事前に決めておきます。価格だけで選ぶと、要件を満たさない提案や、運用が難しい提案を選んでしまう恐れがあります。評価の観点は、提案の中身、実物での確かめ、現場の声の三つに分けて考えられます。
- 提案評価：機能、非機能要件、サポート、実績、価格を総合評価する
- 実物確認：デモやトライアルを選定過程に組み込む
- 利用者の声：受講者となる現場担当者の評価を反映する
観点ごとに重みをつけて比べると、一つの項目だけで決まるのを避けられます。さらに、デモでは操作感や自組織の教材を載せた動作を確かめ、書類では分からない使い勝手も評価します。
現場の声を選定に取り入れると、稼働後に使われないリスクを下げられます。加えて、評価基準を文書にし、実物を確かめる過程を踏むことが、選定の精度を高めます。
実績・サポート体制の確認とPoC
機能と価格だけでなく、同業種・同規模の導入実績やサポート体制も評価します。必要に応じて、試行で提案の中身を確かめます。
- 導入実績：教育機関や規制業種など自組織に近い事例
- サポート：窓口の時間、障害時の連絡、運用相談の可否
- PoC：独自要件や大規模導入での小規模試行
同業種や同規模での経験がある会社は、特有の課題を踏まえた提案を出しやすいと考えられます。また、サポートの内容は、稼働後の安心感を左右します。
PoC（概念実証）は、契約前に一部の部署や限られた教材で試す方法です。机上では見えない課題を早い段階で把握し、本格展開のリスクを下げます。
試行で得た知見をもとに要件を見直せば、本契約の精度も上がります。実績と試行の両方で提案を裏づけることが、堅実な選定につながります。
SaaS活用とフルスクラッチを分ける条件
SaaS型にするか、フルスクラッチで作るかは、要件の独自性と既存システムとの連携の度合いで決まります。標準的な研修配信が中心か、独自要件や複雑な連携があるかを見て、どちらが合うかを分けます。
- SaaS型：標準的な研修配信・受講管理が中心の場合
- フルスクラッチ：独自要件や複雑な連携がある場合
- 要件整理：SaaSで足りる範囲と独自開発の範囲を分ける
標準的な要件で連携が軽ければ、SaaS型は初期費用を抑えて早く始められる現実的な選択です。一方で、密な基幹連携や独自の学習フロー、厳格な要件があるなら、フルスクラッチが適することがあります。
要件定義の成果を導入の成功につなげる最後の鍵は、調達・選定プロセスの設計です。riplaは、フルスクラッチ受託と国内開発の立場から、要件の整理を支援し、無理のない構成を提案します。RFPの段階で判断の基準を持つと、過剰投資と機能不足を避けられます。
まとめ
大切なのは、ベンダー任せにせず、発注側が「何のために、誰が、どれだけの規模で使うか」を言葉にすることです。この整理ができていると、提案の質と見積もりの精度が上がり、稼働後の認識違いも防げます。
機能要件は必須と任意で優先度をつけ、ピーク時の同時アクセスやセキュリティも定めておきます。そのうえで、評価基準やSaaS・フルスクラッチの判断の基準も含め、提案を比べられる調達プロセスを設計します。
riplaはフルスクラッチ受託と国内開発を組み合わせ、要件を言葉にするところから、方式の切り分けと構成設計まで支援します。全体像は完全ガイドにまとめています。
▼全体ガイドの記事
・eラーニングシステムの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。