教育機関向けシステム開発の発注/外注/依頼/委託方法について

「教育機関向けのシステム開発を外部に依頼したいけれど、どこから手をつければよいのかわからない」――そんな悩みを抱える学校・大学・教育委員会の担当者は少なくありません。教育機関のシステム開発は、個人情報保護や文部科学省のガイドライン対応など一般企業とは異なる固有の要件が多く、発注側に一定の知識がないと、ベンダーとの認識齟齬や費用超過、納品後の不具合などのトラブルに直結します。実際、システム開発プロジェクトの約7割が何らかの問題を抱えるといわれており、その主因の多くが発注準備の不足にあります。

本記事では、教育機関がシステム開発を外注・委託する際の具体的な手順を、要件定義の作り方からRFP（提案依頼書）の書き方、ベンダーの選定基準、費用相場、失敗しないためのポイントまで網羅的に解説します。これからシステム開発の発注を検討している担当者の方が、失敗なく発注を完了できるよう、実践的な情報を凝縮してお届けします。

▼全体ガイドの記事
・教育機関向けシステム開発の完全ガイド

教育機関向けシステム開発を外注する前に知っておくべき基礎知識

教育機関のシステム開発は、一般企業向けの業務システム開発と比べると、法令・セキュリティ・予算執行のルールなど、考慮すべき要素が多岐にわたります。発注を成功させるためには、まず教育機関特有の特徴と、発注・外注・委託という言葉の違いを正しく理解することが出発点です。

教育機関のシステム開発で最初に意識しなければならないのは、個人情報保護と情報セキュリティへの高い要求水準です。文部科学省が公表している「教育情報セキュリティポリシーに関するガイドライン」では、生徒・学生の個人情報を扱うシステムに対してゼロトラストを前提としたセキュリティ設計や、細かいアクセス権限制御が求められています。2025年には「次世代校務DXガイドブック」も公表され、パブリッククラウド環境を前提とした校務系システムへの移行が国全体で推進されています。こうした動向を踏まえた上で発注を行わないと、完成後に法令違反や省庁指導のリスクを抱えることになります。また、教育機関の予算執行は年度単位で厳密に管理されており、一般企業のように柔軟に予算追加できるケースは少ないため、当初の見積もり精度が非常に重要です。さらに、学校・大学では教職員・学生・保護者・外部連携機関など多くのステークホルダーが存在するため、要件定義段階で関係者全員の意見を吸い上げることが不可欠です。

「発注」「外注」「委託」はいずれも外部の開発会社にシステム開発を依頼する行為ですが、それぞれニュアンスが異なります。「発注」は仕様書や成果物を明確に定めた上で依頼する行為全般を指し、契約形態としては請負契約が用いられることが多いです。「外注」は社内でできる業務の一部を外部に切り出す場合に使われることが多く、特定の工程だけを切り出す部分委託のケースで多用されます。「委託」はより広い意味を持ち、業務の遂行そのものを外部に任せる行為を指します。準委任契約（SES）での利用が多く、開発者に一定期間作業してもらいながら仕様を詰めていくスタイルに向いています。教育機関のシステム開発では、要件が明確に固まっている場合は請負契約（一括発注）が、要件が流動的な場合は準委任契約（ラボ型・SES）が向いています。どちらの形態を選ぶかによって費用構造やリスクの所在が大きく変わるため、契約形態の選択は発注前に必ず検討しなければなりません。

発注準備フェーズ―要件定義とRFP作成

発注を成功させる鍵は、発注前の準備にあります。開発会社に声をかける前に、自組織が「何を作りたいか」「なぜ作る必要があるか」を明確にしておくことが、後工程での認識齟齬やコスト超過を防ぐ最大の防衛策です。発注準備フェーズでは主に要件定義の整理とRFP（提案依頼書）の作成という2つの作業を行います。

要件定義とは、「開発するシステムがどのような機能を持ち、どのような課題を解決するのか」を発注者側が言語化する作業です。開発会社にとっての設計図の出発点となるため、あいまいな要件のまま発注すると、契約後に仕様変更が多発して費用と納期の両方がオーバーするリスクが高まります。一般的にシステム開発全体の費用のうち、要件定義フェーズには20〜25%の工数をかけることが推奨されており、仮に総開発費が1,000万円であれば200万〜250万円が要件定義コストの目安です。教育機関の要件定義では、①解決したい課題（例：成績管理の二重入力をなくしたい）、②利用するユーザーの種類と人数（教職員・学生・保護者の別と規模）、③外部システムとの連携要否（学籍管理システム・LMSなど）、④セキュリティ・個人情報保護の要件、⑤利用開始希望時期と予算上限、以上5つを最低限整理しておくことが求められます。特に教育機関では、担任・学年主任・教頭・校長といった職層ごとのアクセス権限設計が複雑になりやすいため、権限マトリクスをあらかじめ作成しておくと開発会社との打ち合わせがスムーズに進みます。

RFP（Request for Proposal＝提案依頼書）は、整理した要件をもとに複数の開発会社へ提案を求めるための文書です。RFPを作成することで、各社から同一条件での見積もりと提案を受けられるため、比較・選定が格段にしやすくなります。RFPに必ず記載すべき項目は、①プロジェクトの背景と目的、②システムの概要と主要機能、③想定利用者と業務フロー、④技術要件（クラウド環境・セキュリティ基準など）、⑤スケジュール（希望納期・マイルストーン）、⑥予算規模の目安、⑦選定基準と提案書の提出方法、の7点です。「何を、いくらで、いつまでに」という3要素がRFPの核心であり、この3点があいまいだと開発会社から的外れな提案が返ってくる原因になります。また、RFP作成は担当者一人ではなく、情報システム担当・現場教職員・管理職の複数メンバーで進めることが推奨されます。現場の声を反映しないシステムは、完成後に誰も使わない「お蔵入りシステム」になるリスクがあるためです。RFPを各社に送付した後は、会社ごとに個別の質問受付期間を設け、回答をFAQ形式で全社に共有する公平な運営を行うことで、提案の質が均一に高まります。

開発会社の選び方と比較・選定方法

RFPへの提案が集まったら、いよいよ開発会社の比較・選定フェーズです。教育機関のシステム開発では、一般的な業務システムの知識に加えて、教育分野特有の法令・セキュリティ要件への理解が求められます。費用の安さだけで選定してしまうと、後から追加費用が発生したり、教育機関向けの要件への対応力が不足していたりするケースがあります。

開発会社を選定する際に最初に確認すべきは、教育機関向けシステムの開発実績です。校務支援システム・学習管理システム（LMS）・出欠管理・成績管理・入試システムなど、教育分野特有のシステム開発の経験を持つ会社は、業界慣行や法令要件に精通しているため、要件定義から運用まで的確なサポートが期待できます。提案書には「類似プロジェクトの事例」を必ず記載してもらい、教育機関との取引実績があるかどうかを確認してください。また、文部科学省や総務省・デジタル庁が示す「次世代校務DXガイドブック」や「教育情報セキュリティポリシーに関するガイドライン」への理解度をヒアリングすることも重要です。セキュリティ認証（ISMSやプライバシーマーク）の取得状況も、個人情報を扱う教育機関のシステム開発を依頼する上での重要な判断材料となります。

複数社から見積もりを受け取った際、金額の大小だけで判断するのは危険です。見積もりの内訳を確認し、「何が含まれていて、何が含まれていないのか」を精査することが求められます。例えば、初期開発費用は安くても、運用保守費用・ライセンス費用・サーバー費用が別途かかるケースでは、トータルコストが高騰することがあります。一般的にシステム開発費用のうち人件費が60〜70%を占め、残りがインフラ・ライセンス・運用保守費用です。見積もりを比較する際は、少なくとも5年間のトータルコスト（TCO：Total Cost of Ownership）で比較することを推奨します。また、見積もりの前提条件として「要件変更が発生した場合の追加費用の計算方式」を確認しておくことも重要です。要件変更ゼロのプロジェクトはほぼ存在しないため、変更が発生した際にどのくらいの費用が追加されるのかを把握しておくことで、予算オーバーのリスクを事前に管理できます。

開発会社との契約形態として代表的なのが「請負契約」と「準委任契約」の2種類です。請負契約は、成果物（完成したシステム）の引き渡しを約束する契約で、仕様が明確に決まっている場合に向いています。費用は固定されますが、仕様変更が難しく、変更時には都度追加費用が発生します。一方、準委任契約は、開発者の作業時間・工数に対して対価を支払う契約で、要件が流動的だったりアジャイル開発を採用したりする場合に向いています。費用は変動しますが、要件変更への柔軟性が高いのが特徴です。教育機関の場合、年度をまたいだ予算管理の都合から請負契約を好む傾向がありますが、要件の確定が難しいシステムや規模の大きいプロジェクトでは、フェーズを分けて最初は準委任で要件を固め、後半は請負で開発するハイブリッド型の契約を取ることも有効な選択肢です。いずれの場合も、契約書には「成果物の定義」「瑕疵担保責任の範囲と期間」「知的財産権の帰属」を必ず明記させることが重要です。

発注から納品までの流れ

開発会社との契約が締結したら、いよいよ開発プロジェクトがスタートします。教育機関のシステム開発は、一般的に「要件定義・設計」「開発・テスト」「リリース・運用保守」という3つのフェーズで進みます。発注者側も各フェーズで積極的に関与することで、完成品の品質と現場への定着率が大きく変わります。

契約後、最初に行われるのが開発会社と発注者が一緒に進める詳細な要件定義です。RFPで示した内容をさらに深掘りし、画面設計・データ設計・外部システムとの連携仕様などを文書化します。この工程で発注者側の担当者が積極的に意見を出さないと、開発者の解釈でシステムが作られてしまい、「思っていたものと違う」という問題が生じます。要件定義書が完成したら、必ず発注者側の責任者（プロジェクトオーナー）が内容を確認し、承認した上で次フェーズに進むことが重要です。設計フェーズでは、基本設計（どのような機能をどのように実現するかの全体像）と詳細設計（具体的な処理の仕組み）が行われます。教育機関向けのシステムでは、年度替わりや入学・卒業などのイベントに合わせたデータ移行・初期化処理の設計が特に重要なポイントとなります。

設計が承認されると、いよいよ実際のコーディングが始まります。開発中は、定期的な進捗報告（週次・隔週など）を開発会社に求め、スケジュールのずれが生じていないかを確認します。マイルストーンごとに発注者が動作確認（受け入れテスト）を行うことで、問題を早期に発見して手戻りを最小限に抑えられます。テストフェーズでは、単体テスト（各機能単体の動作確認）・結合テスト（複数機能の連携確認）・受け入れテスト（実際のユーザーが使って問題ないかの確認）の3段階が行われます。教育機関のシステムでは、セキュリティテスト（脆弱性診断）も必須で、特に個人情報を扱う機能については外部の専門機関による診断を受けることが推奨されます。また、教職員への操作研修の実施時期についても、リリース前に計画を立てておく必要があります。

システムをリリースした後も、継続的な運用保守が必要です。教育機関のシステムは学期・学年に合わせた定期的なデータメンテナンスや、法令改正・セキュリティパッチの適用が求められます。運用保守の費用は、一般的に年間で初期開発費の10〜20%程度が目安とされています。例えば、初期開発費1,000万円のシステムであれば、年間100万〜200万円の保守費用が必要です。発注前の段階で、運用保守費用も含めた5年間のTCOを試算しておくことが、予算管理上の重要なポイントです。また、リリース後に現場のユーザーから上がるフィードバックを収集・整理する仕組みを作り、次のバージョンアップや機能改善に繋げる体制を整えることも、システムの長期的な活用のために欠かせません。

費用を抑える発注のコツ

教育機関のシステム開発は、予算の制約が厳しいケースが多いのが現実です。限られた予算の中で必要な機能を最大限実現するためには、開発方針と活用できる制度の両面からコスト最適化を図ることが有効です。

MVP（Minimum Viable Product＝最小限の実用的な製品）開発とは、まず必要最低限の機能だけを開発してリリースし、実際の使用感を確かめながら段階的に機能を追加していく開発手法です。一度に全機能を開発しようとすると、初期費用が膨らむだけでなく、使われない機能に多大な予算が費やされるリスクがあります。MVP開発では、最初のリリース費用を100〜300万円程度に抑え、実際の運用データと現場のフィードバックをもとに2期・3期の開発で機能を追加していくことが可能です。特に教育機関では、全機能を一度に完成させるウォーターフォール型より、段階的にリリースするアジャイル型のほうが現場の課題に柔軟に対応できる場合が多くあります。「まず成績入力と集計機能だけを作り、次年度に保護者への通知機能を追加する」といった段階的アプローチが、限られた予算を有効活用する典型的な方法です。

教育機関のシステム開発には、国や自治体が提供する補助金・助成金を活用できる場合があります。代表的なものとして、デジタル庁・文部科学省が推進する教育DX関連の補助事業や、各都道府県の教育委員会が提供するDX推進補助金があります。2025年以降は、次世代校務DX環境への移行を促進するため、都道府県単位での共同調達支援や、パブリッククラウドへの移行費用を支援する制度の拡充が予定されています。補助金を活用するためには、公募期間・申請要件・補助対象費用の範囲を事前に確認することが必要です。補助金によっては、対象となる費用の種類（開発費・ハードウェア費・運用費など）や補助率（2分の1〜3分の2程度が多い）が異なるため、複数の制度を比較した上で最適な制度を選択することが重要です。また、補助金申請には相応の事務手続きが伴うため、申請実績のある開発会社やコンサルタントのサポートを受けることも検討の価値があります。

発注でよくある失敗とその対策

教育機関のシステム開発で発注が失敗に終わる事例には、いくつかの共通したパターンがあります。こうした失敗を事前に把握し、対策を講じることで、プロジェクトの成功率を大幅に高められます。

最も多い失敗パターンは、要件定義が不十分なまま発注してしまうケースです。「使いやすいシステムにしてほしい」「現在の業務を効率化したい」といったあいまいな要件で発注すると、開発会社は自分たちの解釈でシステムを作ります。完成品を見て「思っていたものと違う」と感じても、仕様書通りに作られていれば追加費用なしでの修正はできません。この失敗を防ぐためには、要件定義書を「誰が読んでも同じ解釈ができる」レベルまで具体化することが必須です。例えば「成績を管理する」ではなく「教科ごと・学期ごとの成績をCSVでインポートでき、5段階評価で保存・閲覧でき、学年末に一括で証明書PDFを出力できる」というように、機能の入力・処理・出力を具体的に定義することが求められます。また、開発会社との打ち合わせ議事録を毎回文書化し、双方が確認・署名する仕組みを作ることも、後からの「言った・言わない」トラブルを防ぐ有効な方法です。

ベンダー選定での最大の失敗は、見積もりの安さだけで開発会社を決めてしまうことです。提示金額が他社より大幅に安い場合、機能の一部が含まれていない、品質保証が弱い、保守体制が不十分など、何らかの要素が削減されているケースが多くあります。実際、「安いベンダーを選んだ結果、開発途中でプロジェクトが頓挫した」「完成後すぐにバグが多発してほぼ使えなかった」という事例は教育機関に限らず多数報告されています。正しいベンダー選定のためには、価格だけでなく「教育分野の開発実績」「セキュリティへの対応実績」「プロジェクト管理体制（PMOの有無）」「リリース後の保守対応力」の4点を総合的に評価することが重要です。また、担当者との相性も見逃せない要素です。システム開発は半年〜1年以上にわたる長期プロジェクトであり、密なコミュニケーションが求められます。提案プレゼンテーション時に、担当予定者が直接出席するかどうか、質問への回答が的確かどうかを確認することで、コミュニケーション能力の高い担当者が付いてくれるかを事前に見極めることができます。

まとめ

教育機関向けシステム開発の発注を成功させるためには、「準備8割・開発2割」という意識が重要です。要件定義とRFP作成に十分な時間をかけ、複数の開発会社を適切な基準で比較・選定することが、プロジェクト全体の成否を大きく左右します。本記事で解説した通り、教育機関特有の法令・セキュリティ要件への対応、年度予算に合わせた発注スケジュールの設計、段階的な開発によるコスト最適化、そして補助金の活用といった観点を総合的に踏まえた上で発注計画を立てることで、現場で真に使われるシステムを実現できます。発注に不安がある場合は、コンサルティングから開発まで一気通貫で支援できる開発会社に相談し、第三者の視点からアドバイスを受けることも選択肢の一つです。教育DXが加速する現在、適切な発注・外注・委託の手続きを踏んでシステム開発を進めることが、教育機関の競争力と現場の働き方改革を同時に実現する近道となります。

▼全体ガイドの記事
・教育機関向けシステム開発の完全ガイド

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