教育機関向けシステムの導入を成功させられるかどうかは、実は開発が始まる前のRFP（提案依頼書）と要件定義の質でほぼ決まります。とくに学校や教育委員会の調達は、公費を使う以上、公平性・透明性が求められ、仕様書の書き方ひとつでベンダーの提案の質も、その後の運用トラブルの多さも大きく変わります。連携要件やSLA（サービス品質保証）を曖昧にしたまま発注すると、後から「これは仕様外です」「追加費用が必要です」と言われ、現場が苦しむことになりかねません。だからこそ、要件定義書とRFPの勘所を体系的に押さえることが重要です。
本記事は、教育機関向けシステムのRFP・要件定義書・提案依頼書を、発注する側の視点で実務的に解説する「要件定義特化」の内容です。機能要件と非機能要件の書き分け、マルチベンダー環境でのSLAと責任分界点の設定、レガシーからのデータ移行と過渡期連携の要件化、そして補助金・調達制度に整合させる進め方まで、一次データを交えて整理します。読み終えるころには、自組織のRFPに盛り込むべき項目の骨格が描けるはずです。なお、教育機関向けシステムの全体像をまだ把握していない方は、まず教育機関向けシステムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・教育機関向けシステムの完全ガイド
RFPに書くべき機能要件・非機能要件の整理
RFPと要件定義書の出発点は、機能要件と非機能要件を漏れなく書き分けることです。機能要件は「学籍・出欠・成績を一元管理する」といったシステムが何をするかであり、非機能要件は「いつ使え、どれだけ速く、どこまで安全か」という品質の条件です。教育機関の調達では、この非機能要件の記述が甘くなりがちで、それが後の運用トラブルの温床になります。
校務・連絡・行政事務の機能要件を洗い出す
機能要件は、現場の業務フローを起点に洗い出します。学籍管理、出欠、成績処理、通知表・指導要録の作成、保健管理、保護者連絡、行政事務の効率化など、自組織が必要とする機能を業務単位で列挙し、それぞれに「必須・推奨・任意」の優先度を付けます。優先度を付けないRFPは、ベンダーがどこに力を入れるべきか判断できず、提案の比較も難しくなります。
このとき重要なのが、自組織の独自ルールをどこまで仕様に盛り込むかの線引きです。成績の評価方法や帳票の様式は教育機関ごとに違いが大きく、すべてをカスタマイズで再現しようとすると費用が膨らみます。標準仕様の要件数は標準化の流れのなかで平均1.2倍、一部は3倍以上に増えた領域もあり、要件が多いほどコストと開発リスクが上がる関係にあります。RFPでは「標準機能で実現するもの」と「どうしてもカスタマイズが必要なもの」を分けて記述し、ベンダーに対応方針を提案させることが、過剰なカスタマイズを防ぐ鍵になります。
セキュリティ・性能・可用性の非機能要件を明記する
非機能要件では、まずセキュリティを最優先で記述します。役割ベースのアクセス権限、監査ログの取得範囲と保存期間、通信と保存データの暗号化、外部接続の制限など、機微な個人情報を守る条件を具体的に明記します。設定ミスによる情報漏えいが現実に起きていることを踏まえ、初期設定の責任所在まで仕様に含めておくと安全です。
あわせて、性能と可用性の要件も数値で示します。学期末の成績入力が集中する時間帯でも快適に動く応答速度、稼働率の目標、計画停止の事前通知ルール、障害時の復旧目標時間などです。クラウド型校務支援システムへの移行が進むなか、これらをSLAとして約束させることが、後の「遅い」「止まった」というトラブルへの備えになります。非機能要件を数値で書けるかどうかが、RFPの完成度を左右します。
非機能要件で見落とされがちなのが、ピーク負荷への耐性です。教育機関のシステムは、利用が一年を通して均一ではなく、年度替わりや学期末、行事の前後に負荷が集中します。普段は快適でも、繁忙期に動作が重くなれば、現場はもっとも忙しいときに足を引っ張られます。RFPには「最も利用が集中する時期の同時アクセス数でも快適に動くこと」を要件として明記し、ベンダーに負荷試験の実施を求めると安心です。平時ではなく繁忙期を基準に性能を定めることが、実用に耐えるシステムの条件になります。
マルチベンダーのSLAと責任分界点の設定
教育機関のシステムは、校務支援、学習プラットフォーム、行政の基幹システム、クラウド基盤など、複数のベンダーの製品が連携して動くマルチベンダー環境になりがちです。この環境でもっとも見落とされ、もっともトラブルを生むのが、SLAと責任分界点の設定です。ここを曖昧にすると、障害のたびに発注者側が原因の切り分けを強いられます。
障害の切り分けと一次窓口をRFPで定める
マルチベンダー環境の典型的な失敗は、接続エラーが起きるたびに、発注者である学校や教育委員会が複数ベンダーの間に立って原因を切り分けさせられることです。ガバメントクラウドへの接続で同様の構図が問題化しており、市側が障害のたびに原因の切り分けを強いられる実態が報告されています。専門知識を持たない事務職員がこれを担うのは現実的ではありません。
これを防ぐには、RFPの段階で「障害時の一次窓口を誰が務めるか」「ベンダー間の切り分けと連絡調整を誰が責任を持つか」を明記します。複数ベンダーをまとめる統括役（プライムベンダーやインテグレーター）に一次窓口と切り分け責任を持たせる構成にすれば、発注者は一つの窓口に連絡すれば済みます。要件定義書には、各システムの境界（責任分界点）を図示し、どこまでが誰の責任範囲かを文書で確定させておくことが欠かせません。
稼働率・復旧時間・保守範囲を数値で約束させる
SLAは「がんばります」では意味がなく、数値で約束させてこそ機能します。稼働率の目標値、障害発生から復旧までの目標時間、問い合わせへの一次回答時間、保守の対応時間帯（平日日中のみか、行事のある休日も含むか）などを具体的に定めます。学校現場は土日や長期休暇に集中作業が入ることもあるため、保守対応の時間帯は自組織の運用実態に合わせて要件化する必要があります。
保守の費用感も把握しておきましょう。パッケージ型では保守費用が初期費用の年10〜15%程度かかるのが一般的で、SaaS型では月額にサポートが含まれる形が多くなります。RFPでは、保守に含まれる範囲（障害対応、法改正対応、軽微な改修、操作問い合わせ）を明示させ、含まれない作業の単価も提示させると、運用フェーズの追加費用を予見できます。riplaはフルスクラッチ受託と国内開発の立場から、SLAと責任分界点を契約前に文書で固めることが、長期運用の安定に直結すると考えています。
導入後の定着支援・オンボーディングを要件化する
RFPで見落とされがちなのが、導入後の定着支援を要件として明記することです。納品で支援が終わると、現場が使いこなせないまま利用率が下がる悪循環に陥りやすくなります。教員のICT校務活用能力は全国平均90.7%と高い一方、研修受講率には群馬58.8%〜岐阜95.8%という地域差があり、支援が薄い地域ほど定着が遅れます。この差を埋めるには、要件定義の段階で定着支援を契約に組み込む必要があります。
具体的には、操作研修の回数と対象、導入後の利用ログ分析の頻度、つまずいている教員へのフォロー体制、定期的な改善ミーティングの実施などを、RFPの要件として書き込みます。納品後の伴走を「サービスに含まれるか」「別料金か」をベンダーに明示させれば、運用フェーズの実態を見極められます。要件定義書に定着支援を盛り込むかどうかが、稼働後に現場へ根づくシステムと、形骸化するシステムを分けます。導入の入り口だけでなく、定着の出口まで設計したRFPが、投資を確実に成果へ変えます。
定着支援の要件化は、費用の透明化にもつながります。導入後の支援を曖昧にしたまま契約すると、現場が困って追加サポートを依頼するたびに想定外の費用が発生し、運用フェーズの予算が膨らみます。あらかじめ支援の範囲と頻度を要件として固め、その費用を初期費用ではなく運用費としてTCOに組み込んでおけば、5年スパンの総コストを正確に見積もれます。RFPで定着支援まで言語化することは、現場の安心と予算の予見性を同時にもたらす、実務的に価値の高い投資だと言えます。
定着支援を要件に含めるかどうかは、提案するベンダーの姿勢を見極める材料にもなります。導入後の伴走を前向きに提案するベンダーは、長期的な運用に責任を持つ意思があり、納品で終わらせず成果まで見届ける体制を備えていることが多いものです。逆に、定着支援を軽く扱うベンダーは、稼働後のトラブルで頼りにならないおそれがあります。RFPに定着支援の項目を設けることは、機能の充足だけでなく、ベンダーとの長期的な関係を見極める試金石としても機能します。要件定義は、良いパートナーを選ぶプロセスでもあるのです。
データ移行と過渡期連携の要件化
RFPで軽視されがちで、しかし現場をもっとも苦しめるのがデータ移行と過渡期連携の要件です。既存システムや紙の台帳から新システムへデータを移すこの工程は、見た目以上に泥臭く、失敗すると本番初日に業務が止まります。要件定義書に移行の段取りと責任を明記しておくことが、円滑な切り替えの前提になります。
データクレンジングと移行リハーサルを要件に含める
移行で最初に直面するのが、既存データの品質です。表記の揺れ、重複、欠損、古い情報が残ったまま移行すると、新システムで誤ったデータが表示されます。自治体の標準化移行では、クレンジングを十分に行わなかったために、移行後に未納データが誤って表示されるなどのトラブルが起きています。教育機関でも、学籍や成績のデータに同様のリスクがあります。
これを防ぐため、RFPには「移行前のデータクレンジングを誰がどこまで行うか」「移行リハーサルを本番前に何回実施するか」「移行後の照合（移行元と移行先のデータが一致するかの検証）を誰が確認するか」を要件として盛り込みます。吹田市の標準化移行が約25人月の規模で計画されたように、移行は片手間でこなせる作業ではありません。移行作業の工数と責任分担を曖昧にしたRFPは、本番直前の混乱を招きます。
新旧混在期の連携と切り替え計画を定める
システムは一夜にして完全に切り替わるわけではありません。新システムを稼働させつつ、一部の業務は旧システムや並行する別システムと連携させる「過渡期」が必ず生じます。この新旧混在期の連携調整は、現場にとって難易度が高く、ここを設計しないまま本番を迎えると、二重入力やデータの不整合が発生します。
RFPでは、切り替えの方式（全校一斉か、モデル校から段階展開か）、移行期間中のデータ連携の手段、旧システムの並行稼働期間と停止時期までを要件として定めます。学籍や成績は年度の区切りに強く依存するため、年度替わりのどのタイミングで切り替えるかは、教育機関特有の重要論点です。段階展開を選ぶ場合は、先行校で得た課題を全校展開へ反映するプロセスも要件に含めると、混乱を最小化できます。過渡期をどう乗り切るかまで描けたRFPが、安定稼働への近道です。
調達制度・補助金に整合させる進め方
教育機関の調達は公費で行われるため、公平・透明な調達手続きと補助金制度への整合が、RFP作成と一体で求められます。調達方式の選択や補助金の要件を後回しにすると、せっかくの要件定義が制度に合わず、調達のやり直しや補助金の取りこぼしにつながります。ここを要件定義の前段で固めておくことが大切です。
総合評価入札・プロポーザル・共同調達を選ぶ
調達方式は、求めるものに応じて使い分けます。価格だけでなく提案の質も評価したい場合は、大阪市がクラウド運用の管理補助者を調達した総合評価一般競争入札や、北九州市がAIチャットボットで用いた公募型プロポーザルが適しています。仕様が固まりきらず、ベンダーの知見を借りて要件を磨きたい段階では、プロポーザル方式が有効です。RFPの評価項目には、機能の充足度だけでなく、移行・運用・サポート体制の実現性を必ず含めます。
規模の小さい教育機関では、共同調達が費用とベンダー調整の両面で効果を発揮します。複数校・複数自治体が要件を揃えて共同で調達すれば、1校あたりのコストを抑えつつ、調達事務の負担も分担できます。要件定義の段階で「単独調達か共同調達か」を方針として決め、共同調達なら参加組織間で必須要件をすり合わせておくことが、後の合意形成をスムーズにします。
補助金の要件をRFPに織り込む
補助金を活用すれば、初期投資の負担を大きく抑えられます。次世代校務DXに関する補助では1校あたり最大約680万円（補助率1/3等）が用意され、自治体のデジタル基盤改革支援補助金や、デジタル人材シェアリング（費用の半額を自治体が補助する例もある）など、組み合わせられる制度があります。これらは適用に要件と期限があるため、RFP作成前に対象範囲を確認しておく必要があります。
補助金には、対象となる経費の範囲やクラウド化などの条件が定められていることが多く、その条件を満たすようにシステムの構成や調達のスケジュールを設計する必要があります。要件定義書に「この補助金の要件を満たすこと」を明記し、ベンダーにも補助対象に合致する提案を求めれば、補助金を確実に取り込めます。riplaはフルスクラッチ受託と国内開発の立場から、調達制度と補助金の要件をRFPに織り込み、要件定義から運用まで一貫して支援する進め方を重視しています。制度との整合まで含めて設計してこそ、RFPは実効性を持ちます。
評価項目とスケジュールをRFPで明確にする
RFPの完成度を高める最後の要素が、提案の評価項目とスケジュールの明確化です。何をどう評価するかをベンダーに示さないと、各社の提案がばらばらになり、公平な比較ができません。機能の充足度、移行計画の現実性、SLAと責任分界の妥当性、運用・定着支援の体制、そして費用（TCO）を、それぞれ配点とともに提示します。とくに教育機関では、機能だけでなく移行と運用の実現性を重く評価することが、稼働後のトラブルを減らします。
スケジュールも要件として欠かせません。学籍や成績は年度の区切りに強く依存するため、年度替わりのどこで切り替えるか、いつまでに移行リハーサルを終えるか、補助金の交付時期と調達の時期がずれていないかを、RFPの中で時系列に整理します。標準化移行が約25人月規模で計画される例が示すように、スケジュールに無理があると現場が疲弊し、品質も落ちます。評価項目と日程を明確にしたRFPは、ベンダーに正確な提案を促し、発注者側の意思決定も速くします。要件・SLA・移行・調達に加え、この評価とスケジュールまで描いて、RFPは完成します。
まとめ
教育機関向けシステムのRFP・要件定義書を整理すると、押さえるべき柱は(1)優先度を付けた機能要件と数値で書く非機能要件、(2)マルチベンダー環境でのSLAと責任分界点・一次窓口の確定、(3)データクレンジング・移行リハーサル・過渡期連携を含むデータ移行の要件化、(4)総合評価入札・プロポーザル・共同調達といった調達方式と補助金への整合、という四点に集約されます。標準仕様の要件増、約25人月規模の移行工数、最大約680万円の補助といった一次データは、RFPで何を詰めるべきかを具体的に示してくれます。
要件定義で大切なのは、機能の網羅よりも、運用フェーズで起きる障害・移行・調達のトラブルを先回りして文書で固めることです。SLAと責任分界、移行の段取り、補助金の要件まで描けたRFPは、ベンダーの提案の質を引き上げ、導入後の安定運用に直結します。riplaはフルスクラッチ受託と国内開発を組み合わせ、業務から逆算した要件整理と制度整合を支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。