学習管理システム開発事例｜0から作るLMSの4か月全工程

「SaaS型のLMSをいくつも比較したのに、どれも自社の研修フローに合わない」——学習管理システム（LMS）の導入を検討する過程で、こうした壁に突き当たる事業担当者の方は少なくありません。資格講座と自社オリジナルコンテンツを一元管理したい、受講者の区分が一般的なツールの想定と違う、といった独自要件があるほど、既製品では「あと一歩」が埋まらないものです。

そこで浮かぶのが「いっそ0から作るべきか」という選択肢です。とはいえ、スクラッチ開発と聞くと「どのくらいの期間がかかるのか」「いくらかかるのか」「社内に開発チームがないのに本当に進められるのか」「途中で頓挫しないか」と、判断材料が乏しいまま不安だけが膨らみがちです。Web上の情報の多くはSaaS型LMSの選び方や設定手順にとどまり、実際にLMSを作る開発プロジェクトの中身まで踏み込んだものは多くありません。

この記事では、研修サービスを展開するEdTech企業（本記事では仮にA社とします）が、自社向けのLMSを0からスクラッチ開発した4か月のプロジェクトを、工程ごとに分解して解説します。要件定義からリリース・運用まで、各フェーズに何週間をかけ、どんな意思決定をし、どこでつまずき、どう乗り越えたのかを、外注を検討する発注者の判断材料としてまとめました。

なお本記事は、特定案件の機密実額を開示するものではなく、一般的なスクラッチ開発の相場観とLMSの標準的な構成に基づく代表的なモデルケースとして再構成しています。誇張した成果数値は記載していません。自社のLMS開発を外注すべきか、どんな準備をすべきかを判断する際の解像度を上げる読み物としてご活用ください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

なぜ既製のLMSではなく0からの開発を選んだのか

LMS（Learning Management System／学習管理システム）は、eラーニング教材の配信や受講者の学習進捗・成績を一元管理し、教育・研修の効果を高めるためのプラットフォームです（LMS（学習管理システム）とは｜NTT東日本）。市場には多機能なSaaS型LMSが数多く存在し、多くの企業はまずそうした既製サービスの導入から検討を始めます。A社も例外ではありませんでした。

しかしA社の場合、SaaS型LMSの比較検討を重ねた末に「自社の研修事業の根幹をなすフローが、どの製品にも収まらない」という結論に至りました。ここで重要なのは、A社が思いつきで開発を選んだわけではない、という点です。買う・カスタマイズする・作る、という選択肢を比較した上での判断でした。

SaaS型LMSで合わなかった3つの壁

A社が既製のSaaS型LMSで行き詰まった理由は、大きく3つに整理できます。

1つ目は、独自の研修フローとの不一致です。A社は資格取得講座を軸にしており、受講者が「申込→受講→確認テスト→修了判定→資格付与」という一連の流れを進みます。この修了判定や資格付与の条件が自社独自のルールに基づいていたため、SaaS型LMSの汎用的な進捗管理ロジックに当てはめると、運用上の例外処理が膨大に発生してしまう状態でした。

2つ目は、資格講座と自社コンテンツの統合管理です。A社は外部の資格カリキュラムと、自社制作のオリジナル教材の両方を扱っていました。これらを別々のツールで管理すると、受講者一人ひとりの学習状況が分断され、横断的な進捗把握ができません。一元管理を実現しようとすると、SaaS型LMSの標準機能の枠を超えたデータ構造が必要でした。

3つ目は、拡張性の限界です。研修サービスは事業の成長に合わせてコンテンツや受講者区分が増えていきます。SaaS型LMSはカスタマイズの範囲が契約プランや製品仕様に縛られるため、「将来こうしたい」という構想に対して都度ベンダーの対応可否に依存する状態が、事業のスピード感に合いませんでした。

スクラッチ開発を選ぶ判断基準

これら3つの壁に直面したとき、すぐに「作る」と決めるのは早計です。一般的に、システムの調達方法には「既製のSaaS／パッケージを買う」「パッケージをカスタマイズする」「0から作る（スクラッチ開発）」の3つがあり、それぞれにメリットとデメリットがあります。スクラッチ開発は自社要件に完全に合わせられる一方で、開発期間が長く、費用も高くなる傾向があります（スクラッチ開発とは｜SHIFT）。

A社が最終的にスクラッチ開発を選んだ判断基準は、次のような問いに整理できます。

• その独自要件は、事業の競争力の源泉か。それとも「あれば便利」程度か
• 既製品のカスタマイズで対応する場合、カスタマイズ費用と制約が、作る場合と比べて割に合うか
• 今後数年にわたって機能を増やし続ける見込みがあるか

A社の場合、独自の研修フローと統合管理はまさに事業の差別化要因そのものであり、ここを汎用ツールに合わせて妥協することは事業の弱体化を意味しました。だからこそ「作る」価値があると判断したのです。逆にいえば、独自要件が本質的でない場合は、SaaS型の導入やカスタマイズの方が合理的なケースも多くあります。この見極めこそが、LMS開発を検討する最初の分岐点です。

LMS開発プロジェクトの全体像｜4か月のタイムラインと体制

「作る」と決めたあと、発注者が最も知りたいのは「結局どのくらいの期間と体制で、いくらかかるのか」という相場観でしょう。ここでは、A社のLMS開発プロジェクトを1枚の地図として俯瞰します。

A社のプロジェクトは約4か月（16週間）で、初期リリースまでをひと区切りとしました。なお、フルスクラッチ型LMSの開発費用相場は機能規模によって幅があり、一般には150万円から1,000万円程度、要件が大規模になれば数千万円規模に達することもあります（eラーニングシステム導入の費用相場｜比較ビズ、スクラッチ開発の費用相場｜システム幹事）。4か月という期間は、機能を欲張らず初期スコープを絞り込んだ場合の一つの目安として捉えてください。

4か月の工程配分（フェーズ別の週数の目安）

A社のプロジェクトでは、4か月を以下のように配分しました。重要なのは、要件定義に全体の4分の1近くを割いている点です。

この配分から見えてくるのは、「コードを書く期間」だけがプロジェクトではない、ということです。要件定義と設計を合わせると全体の3分の1以上を占めます。後ほど詳しく述べますが、ここを急ぐと後工程が崩れます。

プロジェクト体制と役割分担

4か月のプロジェクトを動かすには、役割の異なるメンバーが連携する体制が必要です。A社のプロジェクトでは、おおむね次のような役割で構成しました。

• プロジェクトマネージャー（PM）: 全体スケジュール・課題管理、A社との窓口。意思決定の交通整理を担う
• 要件定義担当（兼設計）: 業務フローを引き出し、機能要件・非機能要件に落とし込む。LMSドメインの知見が問われる役割
• バックエンドエンジニア: 受講ログ・進捗管理・権限制御などサーバー側のロジックを実装
• フロントエンドエンジニア: 受講者・管理者それぞれの画面と操作性を実装
• QA（品質保証）担当: テスト設計と動作検証。受講シナリオ単位での確認を担う

ここで発注者側に求められるのは、「丸投げできる体制」を期待しないことです。要件定義フェーズでは、A社側の事業担当者が業務フローや判断基準を言語化して提供する必要があります。開発会社がどれだけ優秀でも、A社の研修ルールを知っているのはA社だけだからです。後述するとおり、この発注者側の関与度合いがプロジェクトの成否を大きく左右します。

費用感の考え方（何が費用を左右するか）

費用については「いくら」という単一の数字より、「何が費用を押し上げるか」という構造を理解する方が判断に役立ちます。スクラッチ開発の費用は、おおむねエンジニアの人数 × 期間（人月）で決まり、エンジニア1人あたり月額100万円前後が一つの相場とされています（スクラッチ開発の費用相場｜発注ラウンジ）。つまり費用を左右するのは、次の要素です。

• 機能の数と複雑さ: 実装する画面・機能が増えるほど工数が増える
• 非機能要件の厳しさ: 同時受講者数や大容量コンテンツ配信への対応は、設計・インフラのコストを押し上げる
• 要件の固まり具合: 開発中に仕様が二転三転すると手戻りが発生し、工数が膨らむ

逆にいえば、初期スコープを絞り、要件を早期に固めることが、費用を予算内に収める最大のレバーになります。

要件定義｜LMS特有の要件をどう固めたか

要件定義は、LMS開発プロジェクトで最も重要なフェーズです。ゼロから作るスクラッチ開発では、現状の業務フローを洗い出し、搭載すべき機能や運用方法を決める要件定義と設計が成否を分けます（eラーニングシステム導入の費用相場｜比較ビズ）。ここでの判断の質が、後工程のすべてに波及します。

LMSで決めるべき機能要件のチェックリスト

LMSには、汎用的な業務システムにはない「学習ドメイン固有」の機能要件があります。A社のプロジェクトで洗い出した主な機能要件は次のとおりです。

• 学習コンテンツの配信: 動画・PDF・テキストなど多様な教材を、受講者に適切な順序・タイミングで届ける
• 受講進捗・成績管理: 誰がどこまで学習し、どのテストで何点を取ったかを記録・集計する
• 受講ログの取得: 受講者がいつ・どのコンテンツに・どれだけアクセスしたかの履歴を残す
• 権限・受講者区分の管理: 一般受講者・管理者・講師など、立場に応じて見える情報や操作を分ける
• テスト・レポート機能: 確認テストや課題提出、修了判定のロジックを組む
• 学習履歴の標準規格対応の要否: SCORMやxAPI（後述）といった標準規格に対応するか

A社の場合、独自の修了判定ロジックがあったため、進捗・成績管理とテスト機能の連携をどう設計するかが要件定義の山場でした。汎用ツールでは例外処理だらけになった部分を、スクラッチだからこそ自社ルールそのままに作り込めるわけです。

ここで判断が必要になるのが、学習履歴の標準規格への対応です。LMSにはSCORMやxAPI（Experience API）という国際標準規格があります。SCORMは完了ステータス・スコア・受講時間といった事前定義されたデータをLMSに送信する規格で実装が比較的シンプルですが、記録できる学習行動は限定的です。一方、後継規格とされるxAPIは、LMS外での学習活動も含め、より細かな学習行動を記録できます（SCORMの後継規格…xAPI？｜プロシーズラボ）。外部教材を取り込む予定があるかどうかで、対応の要否と優先度が変わります。A社は将来的な外部教材連携を見据えつつ、初期リリースではまず自社コンテンツの管理を優先し、標準規格対応は段階的に検討する判断をしました。

見落としやすい非機能要件

機能要件に目が行きがちですが、LMSでは非機能要件の見落としが後で大きな問題になります。A社のプロジェクトで特に注意したのは次の3点です。

• 同時受講者数: 研修期間の締切直前など、受講が一時的に集中するタイミングがあります。ピーク時に何人が同時にアクセスしても落ちないかを、設計段階で見積もる必要があります
• 受講ログの保持期間と容量: 受講履歴は法令や社内規定で一定期間の保持が求められることがあります。ログが蓄積し続ける前提で、データ量とストレージを設計します
• コンテンツ容量と配信負荷: 動画教材は容量が大きく、配信時のネットワーク負荷も無視できません。動画をどこに置き、どう配信するかは、初期段階で方針を決めておくべき論点です

これらは「動くかどうか」ではなく「使い続けられるかどうか」を左右する要件です。リリース直後は問題なく動いていても、受講者やコンテンツが増えてから顕在化するため、要件定義の段階で先回りしておくことが肝心です。

要件定義でのつまずきと回避策（「全部入り」を避ける）

スクラッチ開発の失敗要因として典型的なのが、要望する機能をすべて盛り込もうとして、かえって使いにくいシステムができてしまうケースです。A社のプロジェクトでも、要件定義の初期には「あれもこれも」と要望が膨らみました。

ここでの回避策は、初期リリースのスコープを意図的に絞ることでした。具体的には、要望に出た機能を「初期リリースに必須」「あると良いが後回し可」「将来構想」の3段階に仕分けし、初期リリースは必須機能だけに集中する方針を取りました。研修事業を回すうえで「これがないと業務が成立しない」機能を見極め、それ以外はリリース後の改善サイクルに回したのです。

この仕分けを発注者と開発会社が一緒に行えたことが、4か月という期間を守れた最大の要因でした。全機能を一度に作ろうとすれば、期間も費用も倍以上に膨らみ、しかも完成したころには現場のニーズが変わっている、という悪循環に陥りがちです。

設計・開発｜技術選定とLMSならではの実装上の勘所

要件が固まったら、設計と開発に進みます。発注者にとっては技術の詳細まで理解する必要はありませんが、「どんな判断軸で技術が選ばれ、どこに難所があるのか」を知っておくと、開発会社との対話の質が上がり、無理のない計画かどうかを見極められます。

技術選定の判断軸

スクラッチ開発では、どのプログラミング言語・フレームワーク・インフラを使うかを選定します。A社のプロジェクトで重視した判断軸は次の3つでした。

• 拡張性: 将来コンテンツや受講者区分が増えても無理なく機能を追加できるか
• 運用負荷: リリース後の保守・監視・障害対応がどれだけ手間になるか
• チームのスキルセット: 開発チームが習熟している技術を使うことで、開発速度と品質を担保できるか

ここで陥りやすいのが、「最新だから」「流行しているから」という理由だけで技術を選んでしまうことです。LMSは長期にわたって運用し続けるシステムなので、目新しさよりも、安定して保守できることや、トラブル時に対応できる人材が確保しやすいことを優先する方が、結果的に総コストを抑えられます。

LMS開発で詰まりやすい3つの実装ポイント

LMSには、汎用的なWebシステムにはない実装上の難所があります。A社のプロジェクトで特に工数を要したのは、次の3点でした。

1つ目は、大量の動画コンテンツの配信です。教材動画は1本あたりの容量が大きく、本数も多くなります。これをサーバーに単純に置くだけでは、配信速度や負荷の問題が出ます。動画の保存先・配信方式・視聴履歴の取り方を一体で設計する必要があり、ここはLMS開発の代表的な難所です。

2つ目は、進捗のリアルタイム反映と受講ログの整合性です。受講者が動画を途中まで見た、テストに合格した、といった状態は、できるだけ正確に・遅延なく記録されるべきです。しかし通信が途切れたり、複数の端末で同時に学習したりすると、進捗データに食い違いが生じることがあります。「どの時点の状態を正とするか」のルールを明確に設計しないと、受講ログの信頼性が損なわれます。受講ログはLMSの心臓部であり、ここの整合性が崩れると、修了判定や成績証明の根拠そのものが揺らいでしまいます。

3つ目は、権限制御の作り込みです。一般受講者・管理者・講師など、立場によって見える情報と操作できる範囲が異なります。「管理者だけが受講者全員の成績を見られる」「受講者は自分の履歴しか見られない」といった権限を、機能を追加するたびに正しく適用し続けるのは、見た目以上に細かい作業です。ここを曖昧にすると、本来見えてはいけない情報が他人に見えてしまうといった事故につながります。

これらの難所に共通するのは、「画面に見えない部分ほど難しい」という点です。発注者からは地味に見える進捗管理や権限制御こそが、LMSの品質を決めます。A社のプロジェクトでは、優先順位の高い機能から段階的に開発し（いわゆるMVP＝必要最小限の製品から作る考え方）、難所を早い段階で検証することで、後半の手戻りを抑えました。

テスト・リリース・運用｜サービスイン後に効く準備

開発が一段落しても、プロジェクトはまだ終わりではありません。テスト、本番移行（カットオーバー）、そしてリリース後の運用までを見据えて初めて、LMSは事業に使えるものになります。発注を検討する段階で、この「作ったあと」のイメージを持っておくことが、外注後の自社の関わり方を判断するうえで重要です。

LMSのテストで重視した観点

LMSのテストは、単に「ボタンを押したら動くか」を確認するだけでは不十分です。A社のプロジェクトで重視したのは、受講シナリオ単位での動作確認でした。

たとえば「新規受講者が申し込み、動画を視聴し、確認テストを受け、合格して修了する」という一連の流れを、実際の受講者の動きをなぞって検証します。このとき特に念入りに確認したのが、受講ログと進捗の正確性です。途中で視聴を中断して再開したときに進捗が正しく引き継がれるか、テストの点数が正しく記録されるか、修了判定が独自ルールどおりに動くか——これらはLMSの根幹であり、ここに不具合があると受講者の学習成果そのものが信頼できなくなります。機能単体のテストに加えて、こうした業務シナリオ全体を通したテストを行うことが、LMSの品質を担保する鍵でした。

カットオーバーと既存データの移行

新しいLMSへの切り替え（カットオーバー）では、既存の受講者データをどう引き継ぐかが論点になります。A社の場合、それまで別の仕組みで管理していた受講者情報や学習履歴を、新システムに移行する必要がありました。

データ移行で気をつけたのは、次の点です。

• 移行対象の範囲を決める: すべての過去データを移すのか、一定期間分だけにするのかを事前に決める
• データ形式の差異を吸収する: 旧システムと新システムでデータの持ち方が違うため、変換ルールを設計する
• 移行リハーサルを行う: 本番移行の前に、テスト環境で移行を試して問題を洗い出す

カットオーバーは「サービスイン」とも呼ばれ、稼働・移行の段取りを誤ると、切り替え当日に受講者がログインできない、過去の履歴が消える、といった重大なトラブルにつながります。A社のプロジェクトでは、移行作業を本番反映する前にリハーサルを重ね、受講者への影響が最小になるタイミングを選んで切り替えを実施しました。

リリース後の運用・改善サイクル

LMSはリリースして終わりではなく、運用しながら改善し続けるシステムです。要件定義の段階で「後回し可」「将来構想」に仕分けた機能は、リリース後の改善サイクルで順次追加していきます。

A社のプロジェクトでは、リリース後に次のような体制を整えました。

• 問い合わせ・不具合の受付窓口: 受講者や管理者からの声を集める仕組み
• 改善要望の優先順位付け: 寄せられた要望を、事業インパクトと工数で評価して順位を決める
• 定期的な機能追加: 優先順位に沿って、計画的に機能を追加・改善する

ここで発注者が意識すべきは、「リリース後も開発会社との関係が続く」という前提です。スクラッチ開発のLMSは自社専用である分、保守・改善も自社の判断で進められますが、そのためには運用フェーズの体制と予算をあらかじめ見込んでおく必要があります。初期開発費だけを見て判断すると、運用フェーズで想定外のコストに直面することになります。

この事例から見える、LMS開発を外注する前に準備すべきこと

ここまでA社のLMS開発プロジェクトを工程ごとに見てきました。最後に、この事例から読み取れる「発注者が外注前にやっておくべき準備」を整理します。自社が同じようにLMSをスクラッチ開発できるかどうかは、開発会社の力量だけでなく、発注者側の準備で大きく変わります。

外注前に発注者が固めておくべき3点

A社のプロジェクトが4か月で立ち上がった背景には、発注者側の準備がありました。外注を検討する段階で、次の3点を固めておくことをおすすめします。

1つ目は、目的の言語化です。「なぜ既製品ではなく作るのか」「このLMSで何を実現したいのか」を明確にしておくことです。A社の場合、「独自の研修フローと統合管理が事業の競争力の源泉だから作る」という目的が明確だったため、要件定義での判断がぶれませんでした。

2つ目は、優先機能の絞り込みです。すべての要望を一度に実現しようとせず、「これがないと業務が成立しない」必須機能を見極めておくことです。これが曖昧だと、要件定義の段階で議論が発散し、期間も費用も膨らみます。

3つ目は、社内の意思決定体制の整備です。要件定義フェーズでは、業務フローや判断基準を発注者側が言語化して提供し、仕様の判断を迅速に下す必要があります。誰が何を決められるのかが曖昧だと、開発会社からの確認待ちでプロジェクトが停滞します。

4か月で立ち上げるために避けたい進め方

逆に、A社の事例から見えてくる「避けるべき進め方」もあります。

• 要件定義を急ぐ: コードを書く期間を増やそうと要件定義を圧縮すると、後工程で手戻りが多発し、結局トータルの期間が延びます
• 全機能を一度に作ろうとする: 「全部入り」を目指すと、使いにくいシステムができ、期間も費用も倍増します
• 作ったあとを考えない: 運用・改善の体制と予算を見込まずに初期開発費だけで判断すると、リリース後に行き詰まります
• 発注者が関与しない: 「丸投げ」では、自社の研修ルールが正しく反映されません。発注者の関与こそがLMS開発の品質を決めます

LMSのスクラッチ開発は、確かに期間も費用もかかります。しかし、独自要件が事業の競争力に直結する場合、既製品で妥協するよりも長期的に大きな価値を生みます。大切なのは、本記事で見てきたように、要件定義に十分な時間をかけ、初期スコープを絞り、発注者と開発会社が二人三脚で進めることです。この記事が、自社のLMS開発を外注すべきか、どう準備を進めるべきかを判断する一助になれば幸いです。