EdTechシステム開発の外注方法｜LMS開発を進める判断基準5つ

「既製の SaaS 型 LMS を試したものの、自社の学習フローに合わない」「カスタム開発に踏み切りたいが、どこに、どう発注すればよいのか判断がつかない」。教育・EdTech 業界でシステム開発の発注を検討し始めた担当者から、こうした声を耳にすることが増えています。

教育・EdTech 業界のシステム開発は、他業界と比べて要件が特殊です。生徒・受講者の個人情報を扱う責任、SCORM や xAPI といった教育系標準規格への対応、公開後の長期運用を前提とした設計など、一般的なシステム開発の判断軸だけでは選定を進められない場面が多く発生します。加えて、発注者が取り得る調達手段も、開発会社への一括発注だけではなく、フリーランスチーム編成、SES（準委任契約）の活用など複数の選択肢があり、この使い分け自体が意思決定を難しくしている面もあります。

多くの比較記事では「開発会社リスト」と「選び方の一般論」が並列に列挙されるだけで、教育業界固有の要件をどう発注書に落とし込むか、どの調達手段が自社の状況に合うのか、といった判断基準までは踏み込まれていないのが実情です。その結果、社内で「発注先を選ぶ基準」が定まらず、意思決定が停滞してしまう企業が少なくありません。

本記事では、教育・EdTech 業界でシステム開発を外注する際に押さえるべき論点を、発注者視点で体系的に整理します。開発会社・フリーランスチーム・SES という 3 つの調達手段の使い分け、LMS 開発を進めるうえでの判断基準 5 つ、費用相場と期間・体制の目安、RFP 作成を含む発注前準備、そして陥りやすい失敗パターンまでを一続きに解説します。読み終えた時点で、自社の状況に合った意思決定の輪郭を掴み、社内合意形成と発注先選定の実務に着手できる状態を目指します。

なお、学習塾・スクール事業者向けに「SaaS 型 LMS でカバーするか、カスタム LMS を開発するか」という開発形態そのものの判断、およびカスタム LMS を開発する場合の費用相場・開発会社の選び方に焦点を当てた解説は別記事にまとめています。本記事は「外注方法・調達手段の使い分けと判断基準」に軸足を置いた解説となるため、学習塾特化の SaaS vs カスタム開発の判断軸まで含めて検討したい方は、LMSカスタム開発の費用相場と開発会社の選び方と併読すると意思決定の解像度が上がります。

教育・EdTech業界のシステム開発が「外注方法の判断」で詰まる理由

教育・EdTech 業界のシステム開発は、なぜ発注方法の判断が難しくなるのでしょうか。まずはその構造を整理します。

SaaS型LMSでカバーできない4つの領域

近年は既製の SaaS 型 LMS が充実しており、社員研修や汎用的な e ラーニング用途であれば、初期費用を抑えて短期間に導入できます。一方で、EdTech 事業や学習塾・スクール事業では、SaaS 型では収まりきらない要件が典型的に 4 つ現れます。

1つ目は 独自の学習フロー です。単元・単元テスト・復習・宿題・保護者確認といった順序と条件分岐が、事業ごとに大きく異なります。「宿題を保護者が承認したら次の単元に進める」「テストで一定得点に満たなければ復習コンテンツへ強制遷移する」といった条件は、SaaS のワークフロー設計に収めにくい代表例です。

2つ目は 独自の成績評価ロジック です。単純な点数計算ではなく、独自の学力偏差値、単元別到達度、講師コメントの加重評価など、事業ノウハウが詰まったロジックは SaaS の標準機能で表現しづらい領域です。

3つ目は 保護者・受講者への連絡フォーマット です。学習塾やスクールでは、保護者への進捗連絡・欠席連絡・請求連絡が業務の中核を占めます。連絡テンプレート・送信タイミング・チャネル（メール・LINE・アプリ通知）を独自設計したい場合、SaaS 標準では細部の調整が効かないケースが多く見られます。

4つ目は 外部教材・外部コンテンツとの連携 です。自社開発の学習アプリ、既存の動画配信基盤、外部の演習問題データベースなどとの API 連携は、SaaS のインテグレーション対応範囲を超えると実装が難しくなります。

これら 4 領域のいずれかで SaaS 型の限界が見え始めたとき、発注者はカスタム LMS またはハーフスクラッチでの開発を検討する局面に入ります。

教育業界特有の非機能要件

教育・EdTech 業界のシステム開発では、機能要件と並んで 非機能要件（セキュリティ・標準規格・長期運用） の重みが他業界より大きくなります。

まず 個人情報保護 の観点です。児童生徒・受講者・保護者の個人情報は、氏名・年齢・成績・学習履歴といった機微な情報を含み、改正個人情報保護法の遵守はもちろん、教育現場向けには文部科学省が「教育情報セキュリティポリシーに関するガイドライン」を策定しています。同ガイドラインは 2025 年 3 月に改訂され、情報資産の分類・仕分け・管理方法や、次世代校務 DX 環境への移行を進める上で必要となるセキュリティ対策が見直されています（教育情報セキュリティポリシーに関するガイドライン公表について - 文部科学省）。

次に 教育系標準規格への対応 です。e ラーニングコンテンツの相互運用性を担保するため、SCORM（Sharable Content Object Reference Model）、xAPI（Experience API）、LTI（Learning Tools Interoperability）といった標準規格が広く使われています。自社コンテンツを他 LMS に載せ替えたい場合、または外部の LMS プラットフォームと連携したい場合、これらの規格対応は将来の選択肢を大きく左右します。

最後に 長期運用を前提とした設計 です。LMS は一度公開したら 5 〜 10 年単位で使い続けることが一般的で、生徒・受講者データや学習履歴が年々蓄積されます。データベース設計・バックアップ・世代管理の設計を初期段階で誤ると、数年後に運用が破綻するリスクがあります。

発注方法の判断が難しくなる背景

これらの特殊性がある一方で、Web 上の「教育系システム 開発会社比較」記事の多くは、開発会社を並列に列挙し、選び方のポイントとして「実績・コミュニケーション・セキュリティ・予算/納期・サポート」を汎用的に挙げるにとどまります。フリーランスチーム編成や SES 活用といった他の調達手段との使い分け、教育業界特有の非機能要件を発注書へ落とし込む具体像までは踏み込まれていません。

そのため発注者は「どの会社が良さそうか」は分かっても「自社の要件で本当に外れないのはどこか」「どの調達手段が最適か」を判断する軸が持てず、意思決定が止まってしまうのです。次章以降では、この判断軸を段階的に整理していきます。

教育・EdTech業界で外注検討すべきシステムのパターン

判断基準を提示する前提として、まずは教育・EdTech 業界で外注対象になりやすい代表的なシステムを整理します。自社が開発しようとしているものがどのパターンに当てはまるかを確認しながらお読みください。

LMS（学習管理システム）

いわゆる Learning Management System で、学習コンテンツの配信・受講管理・進捗管理・成績管理を担う中核システムです。EdTech スタートアップの自社プロダクトや、学習塾の受講管理システムの中核として開発されるケースが多く、独自の学習フローを実装する場合はハーフスクラッチ〜フルスクラッチで開発されます。SCORM や xAPI 対応の有無、動画配信・課金・保護者連絡といった周辺機能との統合範囲によって、開発規模が大きく変わります。

学習アプリ・オリジナルコンテンツ配信システム

スマートフォンアプリまたは Web アプリとして提供する、独自の学習体験を実装するシステムです。単語学習アプリ、リスニング演習アプリ、AI による個別最適化学習アプリなど、EdTech プロダクトの表側を担うケースが該当します。学習アプリ単体で完結する場合もあれば、バックエンドで LMS と連携し、進捗データを集約する構成もあります。オフライン学習対応や、通信量制限を意識したコンテンツ配信設計が求められる点が特徴です。

塾・スクール向け業務システム（受講管理・保護者連絡・請求）

学習塾・スクール事業の「業務の裏側」を支えるシステムです。受講者マスタ・スケジュール管理・出欠管理・保護者連絡・月謝請求・講師勤怠管理などを一体で扱います。LMS とは目的が異なりますが、教材配信機能や成績管理と連携する構成では、実質的に LMS の一部として設計されることも珍しくありません。多店舗展開している事業者では、校舎別の運用差分をどう吸収するかが設計上の論点になります。

試験・検定配信・自動採点システム

模擬試験・検定・社内試験を Web で配信し、自動採点・成績分析を行うシステムです。試験時のなりすまし防止、時間制御、大量同時接続への耐性、選択式・記述式・音声問題への対応など、通常の LMS 以上に高い非機能要件が求められる領域です。生成 AI による記述式採点支援を組み込むケースも増えており、外部 AI サービスとの連携設計が新たな論点として加わっています。

LMS開発を外注する3つの方法｜開発会社・フリーランスチーム・SES

自社が開発すべきシステムのイメージが固まったら、次に検討すべきは「どの調達手段で外注するか」です。多くの発注者は「開発会社への一括発注」しか選択肢が見えていないことがありますが、フリーランスチーム編成や SES 活用も含めた 3 つの選択肢を持つことで、意思決定の柔軟性が高まります。学習塾・スクール事業者でカスタム LMS の開発会社選定・費用相場をより具体的に深掘りしたい場合は、LMSカスタム開発の費用相場と開発会社の選び方も併せて参照してください。本章では、汎用的な調達手段の使い分けに絞って整理します。

開発会社（受託ベンダー）への一括発注

要件定義から設計・開発・テスト・リリースまでを、開発会社に一括で発注する方式です。契約は請負契約が中心で、成果物と納期が契約時点で明確になります。プロジェクト管理・品質保証・体制構築を発注先が担うため、発注者側の管理コストは相対的に軽くなります。一方で、要件変更への柔軟性は低くなりがちで、開発途中の仕様変更は追加見積・契約変更を伴います。教育業界での実績・体制を持つ受託ベンダーを見つけられた場合に有力な選択肢です。

フリーランスチーム編成での外注

PM・エンジニア・デザイナーをフリーランスで個別に調達し、チームとして編成する方式です。適切なメンバー構成を組めれば、開発会社に一括発注するよりも費用を抑えつつ、要件変更にも柔軟に対応できるチームを構築できます。準委任契約が中心となり、月額の稼働時間ベースで支払いを行う運用が一般的です。ただし、チームの立ち上げ・進行管理・品質保証は発注者側（あるいは PM 役のフリーランス）が担う必要があり、社内に一定のマネジメント能力があることが前提となります。EdTech スタートアップのように、事業側が仕様に深く関与し続けたいケースと相性が良い方式です。

SES（準委任契約）での人材確保

SES（システムエンジニアリングサービス）は、エンジニアの稼働時間を提供してもらう調達方式です。契約は準委任契約が中心で、指揮命令は発注者側（ただし業務委託指揮命令の枠内）となり、成果物ではなく稼働に対して支払いを行います。既に社内に PM や技術リードがいて、開発リソースだけが不足している状況で活用しやすい方式です。フリーランス個人契約と近い性質を持ちますが、SES 事業者を介在させることで、契約・請求・入替え対応をまとめられるメリットがあります。教育業界固有のドメイン知識までは期待しづらいため、教育業界の要件は発注者側で咀嚼して指示できる状態が前提です。

3つの調達手段の比較

3 つの調達手段の特徴を、費用構造・スピード・柔軟性・教育業界要件への対応・向いているケースの観点で比較します。

自社の要件の固まり具合と、社内のプロジェクトマネジメント能力の水準に応じて、いずれかまたは複数の組み合わせを選択します。実務では「PM とアーキテクト級エンジニアはフリーランスで確保し、実装リソースを SES で補う」といったハイブリッド構成も一般的です。

LMS開発を外注するときの判断基準5つ

調達手段の選択肢が見えたら、次はいよいよ「外注先そのものをどう選ぶか」です。教育・EdTech 業界の外注先選定では、以下 5 つの判断基準を意思決定プロセスに沿った順序で確認することをおすすめします。並列に「実績・コミュニケーション・価格」を眺めるのではなく、それぞれの基準を明確な問いに落とし込んで確認するのがポイントです。

判断基準1: 教育業界の開発実績

最初に確認すべきは、教育業界での開発実績です。ただし「実績あり」というだけでは不十分で、以下の観点で深掘りします。

• どの領域（学校向け・学習塾向け・企業研修向け・EdTech スタートアップ向け）の実績か
• LMS の中核（受講管理・進捗管理・成績管理）を触ったのか、それとも周辺システムのみか
• 自社と同規模（利用者数・データ量）の案件を担当したことがあるか
• 直近 3 年以内の実績か（技術スタックの陳腐化を確認するため）

「教育系実績あり」と紹介される案件が、実は特定校向けの校務システムのみで LMS 中核の設計経験がない、というケースは珍しくありません。ヒアリング段階で、担当者レベルまで踏み込んで実績を確認します。

判断基準2: 個人情報保護・セキュリティ対応

続いて、個人情報保護・セキュリティ対応の水準を確認します。教育情報を扱うプロジェクトでは、以下を発注先が理解していることが最低条件です。

• 改正個人情報保護法の遵守（要配慮個人情報の取り扱いを含む）
• 文部科学省「教育情報セキュリティポリシーに関するガイドライン」の内容と、システム設計への反映方法
• 情報資産の分類・アクセス制御・監査ログの設計指針
• インシデント発生時の対応フロー（発注者と分担する範囲の明確化）

学校教育向けのシステムを開発する場合、教育委員会が独自にセキュリティポリシーを定めていることもあり、そのポリシーへの適合性検証まで含めて対応できるかを確認します。

判断基準3: 教育系標準規格の理解

SCORM・xAPI・LTI といった教育系標準規格への対応可否も、選定時に必ず確認します。「対応できます」という回答だけで済ませず、以下のような具体的な質問を投げます。

• SCORM 1.2 と SCORM 2004 のどのバージョンに対応するか、その理由は何か
• xAPI（LRS 含む）を採用する場合、既存学習履歴データとの互換性をどう設計するか
• LTI 1.3 対応で第三者ツールを取り込む場合の SSO と成績連携の実装経験はあるか

これらの規格は、将来「他社 LMS 基盤に自社コンテンツを載せる」「外部の演習ツールを組み込む」といった拡張の可能性を左右します。初期リリース時点で全対応する必要はなくても、拡張余地を残せる設計になっているかを確認します。

判断基準4: 長期運用・アップデート体制

LMS は「公開してから使う期間のほうが長い」システムです。開発フェーズだけを見て発注先を選ぶと、運用フェーズで詰まります。以下を確認します。

• リリース後の保守契約の範囲と月額目安
• OS・ミドルウェア・ライブラリのバージョンアップ対応方針
• 生徒・受講者の増加に伴うスケール対応（サーバー増強・DB チューニング）
• 制度改定（学習指導要領の改訂、個人情報保護法の改正）への追随体制

「開発は他社、保守は自社」と切り分けるパターンもありますが、その場合は納品時のドキュメント整備と引継ぎフローを契約時点で明確化する必要があります。

判断基準5: 費用構造の柔軟性

最後に、費用構造の柔軟性を確認します。単純な見積総額だけを比較すると、後々の追加コストで想定外の予算超過を招きがちです。

• 初期開発費用と保守運用費用の比率
• 追加機能開発時の単価（人日単価または人月単価）の明示
• サーバー費用・第三者ライセンス費用の負担範囲
• スコープ変更時の見積プロセス（軽微な変更は変更管理内、大規模変更は再見積、といった線引き）

「初期は安いが運用で高い」「初期は高いが運用は安い」といった費用構造の違いを把握し、3 〜 5 年のトータルコストで比較する視点を持つと、意思決定の精度が上がります。

LMS開発の費用相場と開発期間・体制の目安

判断基準が定まったら、自社の予算・スケジュール感が現実的に合うかを照合します。ここでは公開情報に基づく相場観を整理します。

開発形態別の費用相場

LMS 開発の費用相場は、開発形態によって大きく異なります。

• SaaS ベース（設定・軽微カスタム）: 数十万〜数百万円。SaaS 型 LMS を導入し、設定と軽微なカスタマイズで済ませる方式です。
• ハーフスクラッチ（既存フレームワーク活用）: 数百万〜1,000 万円程度。OSS の LMS 基盤や既製のフレームワークをベースに、独自機能を追加開発する方式です。
• フルスクラッチ: 200 万〜1,000 万円がボリュームゾーンで、規模により数千万円に達するケースもあります（eラーニングシステム開発の費用相場と注意点 、スクラッチ開発の費用相場 - 発注ラウンジ を参照）。企業規模による開発体制の差が費用に大きく反映されます。

同じ「LMS 開発」でも、対象機能・想定ユーザー数・非機能要件（可用性・セキュリティ水準）で費用は 10 倍以上変わります。まずは自社の要件を、次章の RFP 準備を通して絞り込むことが、相場感を掴む最短距離です。

LMS開発の期間目安

開発期間の目安も、開発形態で大きく変わります。

• SaaS ベース: 1 〜 3 か月程度で導入・稼働開始が可能です。
• ハーフスクラッチ: 3 〜 6 か月程度。要件の複雑さに応じて延伸します。
• フルスクラッチ: 半年以上が一般的で、要件によっては 1 年以上を要します（アプリ開発期間の目安 - Yappli を参照）。

初期リリース後も、機能追加・改善を継続する前提で計画を立てる点が LMS 開発の特徴です。「初期リリース版でどこまでカバーし、次期リリースで何を追加するか」を計画段階で分けておくと、期間と費用の見通しが立ちやすくなります。

体制モデルの例

LMS 開発でよく採用される体制モデルは、以下のような構成です。

• PM（プロジェクトマネージャー）: 1 名。要件整理・進行管理・発注者との窓口を担う。
• アーキテクト / テックリード: 1 名。全体設計・技術選定・実装レビューを担う。
• バックエンドエンジニア: 2 〜 3 名。API・データベース・認証基盤・LMS 中核ロジックを実装。
• フロントエンドエンジニア: 1 〜 2 名。管理画面・受講者画面・保護者画面を実装。
• QA / テスト担当: 0.5 〜 1 名。テストケース設計・実施・品質報告を担う。
• デザイナー / UX: 0.5 名。学習体験を意識した UI 設計を担う。

初期リリース段階では合計 5 〜 8 名程度、運用フェーズでは 2 〜 4 名程度に絞り込む構成が典型的です。フリーランスチーム編成や SES と組み合わせる場合も、この役割分担の骨格は変わりません。

外注前に整える5つの準備｜要件棚卸しからRFP作成まで

判断基準を持って発注先を選定しても、発注書の不備で失敗するケースは後を絶ちません。ここでは発注前に社内で整えるべき準備事項を、実務フローに沿って 5 つ紹介します。

準備1: 自社の学習フローと独自要件の棚卸し

まず、自社の学習フローと独自要件を、社内で棚卸しします。EdTech スタートアップであれば創業メンバーの頭の中に、学習塾であれば校舎運営マニュアルの中に、事業ノウハウが暗黙知として蓄積されています。これを図（ユーザージャーニー・業務フロー）と文章に書き起こし、発注先に伝えられる状態にします。

「独自の学習フロー」「独自の成績評価ロジック」「独自の保護者連絡フォーマット」の 3 点は、SaaS で表現しづらい典型例です。この 3 点を優先的に言語化しておくと、発注先とのコミュニケーションが噛み合いやすくなります。

準備2: コア機能と周辺機能の切り分け（外注範囲の決定）

次に、コア機能と周辺機能を切り分けます。全機能を一括で外注する必要はなく、「事業の根幹に関わり内製化したい機能」と「外注してよい機能」を分ける判断が重要です。

たとえば、EdTech スタートアップであれば「学習アルゴリズム（AI 推薦ロジック）は内製、LMS の受講管理・進捗管理は外注」といった切り分けが一般的です。学習塾であれば「教材コンテンツは内製、配信基盤と業務システムは外注」といった分け方が考えられます。この切り分けが曖昧なまま外注に進むと、内製化するはずだった部分まで発注先に丸投げされてしまい、事業競争力の源泉を外部に依存するリスクが生じます。

準備3: セキュリティ要件・個人情報取り扱いの明文化

セキュリティ要件と個人情報取り扱いは、発注前に明文化しておく必要があります。以下を書面化します。

• 扱う個人情報の項目一覧（氏名・年齢・成績・学習履歴・保護者連絡先など）
• 保存場所・暗号化方針・保存期間・削除フロー
• アクセス制御の方針（管理者・講師・保護者・受講者の権限マトリクス）
• 監査ログの取得範囲と保存期間
• インシデント発生時の初動対応（発注者・発注先の分担）

学校向けシステムを開発する場合は、教育情報セキュリティポリシーに関するガイドラインで求められる分類・管理方法との整合性も確認します。これらを RFP に含めることで、発注先の提案内容とセキュリティ費用の妥当性が比較可能になります。

準備4: RFP（提案依頼書）の作成ポイント

RFP（Request for Proposal、提案依頼書）は、発注者と開発会社の認識の齟齬を最小限に抑えるための重要書類です。以下の項目を含めることが一般的です（RFP（提案依頼書）とは？作成手順とメリット、注意点 - 発注ラウンジ を参照）。

• 概要・基本情報: 自社概要・背景・依頼の目的
• 前提課題・ゴール: 解決したい課題と、開発によって到達したい状態
• スコープ: 外注範囲・非対象範囲
• 成果物: 納品物のリスト（システム本体・ドキュメント・引継ぎ資料）
• 機能要件: 必須機能・任意機能・優先順位
• 非機能要件: 性能・可用性・セキュリティ・保守性
• 予算: 上限額の明示（幅を広くしすぎない）
• スケジュール: 目標リリース日・マイルストーン
• 提案条件・契約条件: 提案書提出期限、契約形態、支払条件

なお、RFP の前提となる要件定義そのものを社内でどう進めるか（要求整理・機能要件と非機能要件の切り分け・要件レビューの進め方）に不安がある場合は、発注者視点で要件定義プロセス全体を解説した要件定義の進め方【発注者向け完全ガイド】も併せて参照するのがおすすめです。RFP はあくまで要件を発注先に伝えるための書類であり、その中身の質は社内要件定義の解像度で決まります。

RFP 送付から提案書締切までは、大規模案件では 2 週間以上を確保するのが実務の目安です。関連部署（経営層・現場・情報システム担当）から意見を集約し、優先順位を「必ず実現したい」「できれば実現したい」で明示すると、提案精度が上がります。

準備5: 契約形態の選択（請負契約・準委任契約・混合）

最後に、契約形態を選択します。

• 請負契約: 成果物と納期に対して発注先が責任を負う契約。要件がある程度固定できる場合に向く。
• 準委任契約: 稼働時間に対して発注先が責任を負う契約。仕様を練り込みながら進めたい場合に向く。
• 混合型（フェーズ分割）: 要件定義・設計フェーズは準委任、開発フェーズは請負、といった分割方式。要件の不確実性が高い LMS 開発では実務でよく選ばれる。

契約形態は、選んだ調達手段（開発会社・フリーランスチーム・SES）と密接に関わるため、先ほど整理した調達手段と併せて決定します。契約形態の選択を間違えると、要件変更時の追加コストや、成果物の責任範囲でトラブルが発生しやすくなります。

教育・EdTech業界の外注でよくある失敗パターンと回避策

判断基準・準備を整えても、実際のプロジェクトでは以下のような失敗パターンが繰り返し観察されます。先回りで意識づけしておくことで、多くを回避できます。

失敗パターン1: 学習フローの特殊性を見誤り、追加費用が膨らむ

「LMS といっても機能はどこも似たようなもの」という思い込みで発注を進めると、開発途中で「うちの学習フローはここが違う」という指摘が次々に出て、追加費用が膨らんでしまいます。

回避策は、発注前に自社の学習フローを図に書き起こし、SaaS 型 LMS で置き換えを試みたときに詰まった箇所を洗い出しておくことです。RFP には「他社 LMS では表現できなかった要件」を明示的に含めます。

失敗パターン2: 個人情報保護の詰めが甘く、公開直前に手戻り発生

「セキュリティは開発会社に任せておけば大丈夫」という発想は、公開直前の手戻りリスクを高めます。教育情報を扱うシステムでは、公開前のセキュリティ監査や、教育委員会・大手取引先による情報セキュリティチェックリスト対応が必要になるケースがあり、そこで不備が発覚すると数週間〜数か月のリリース遅延に直結します。

回避策は、発注前に扱う個人情報項目・保存方針・アクセス制御を明文化し、RFP と契約書に含めることです。開発途中でも、機能追加時に個人情報の取り扱いが変わる場合は、その都度セキュリティ設計を更新するプロセスを組み込んでおきます。

失敗パターン3: 内製化との併用計画がなく、運用フェーズで詰まる

初期リリース後の運用・改善を全て外注に依存する計画にしていると、運用フェーズで発注先の稼働に予算を吸われ続けます。事業ノウハウの蓄積も、開発会社側に集中してしまいます。

回避策は、外注範囲の決定段階（先ほど紹介した「準備 2」）で、内製化すべき機能・スキル領域を明確に切り分けておくことです。「初期は外注中心、2 年目からは内製比率を上げる」といった段階的な内製化計画を、契約時点で共有しておきます。

失敗パターン4: 標準規格（SCORM/xAPI/LTI）の対応が中途半端になる

SCORM・xAPI・LTI といった規格対応は、要件定義時に曖昧に扱われがちです。「対応する」とだけ書かれ、どのバージョンに、どの範囲で対応するかが決まっていないと、実装後に「思っていた連携ができない」というトラブルが発生します。

回避策は、規格対応の要件を、想定ユースケース（「他 LMS に自社コンテンツを載せられること」「外部演習ツールを SSO 連携で組み込めること」など）に紐づけて具体化することです。ユースケースが定義できると、対応バージョン・対応範囲・テスト方法が明確になります。

まとめ｜LMS開発の外注意思決定を進めるチェックリスト

ここまで、教育・EdTech 業界のシステム開発、特に LMS 開発の外注に関する論点を整理してきました。最後に、社内で発注意思決定を進める際のチェックリストを提示します。

• 自社が開発しようとしているシステムは、LMS・学習アプリ・業務システム・試験配信のどのパターンに近いか整理できているか
• SaaS 型で対応できない領域（独自学習フロー・独自成績評価・独自連絡フォーマット・外部連携）を明文化できているか
• 教育業界特有の非機能要件（個人情報保護・教育系標準規格・長期運用）を、社内で誰が理解し、誰が発注先に伝えるかが決まっているか
• 開発会社・フリーランスチーム・SES の 3 つの調達手段について、自社に合う組み合わせを検討したか
• 発注先の選定基準として、教育業界実績・セキュリティ対応・標準規格理解・長期運用体制・費用構造の 5 つを、それぞれ具体的な質問に落とせているか
• 費用相場（SaaS ベース・ハーフスクラッチ・フルスクラッチ）と期間目安を照らして、自社の予算・スケジュールが現実的か
• 発注前準備 5 つ（学習フロー棚卸し・コア/周辺切り分け・セキュリティ明文化・RFP 作成・契約形態選択）を、社内で誰がいつまでに進めるかが決まっているか
• 失敗パターン 4 つ（学習フロー見誤り・セキュリティ手戻り・内製化計画欠如・規格対応中途半端）に対する具体的な回避策を、プロジェクト計画に組み込めているか

すべてのチェック項目が埋まった段階で、発注先候補への RFP 送付・提案受領・比較選定というフェーズに進めます。教育・EdTech 業界のシステム開発は、他業界より論点が多く意思決定が難しい領域ですが、判断軸を持って一つずつ潰していけば、確実に前進できます。本記事が、社内合意形成と発注先選定の実務に着手するための足場になれば幸いです。