教育機関向けシステムのRFP/要件定義書/提案依頼書について

教育機関向けシステムのRFP(提案依頼書)と要件定義書は、発注者の視点で、機能要件と非機能要件を書き分け、要件に優先度を付けることから始まります。

SLAと責任分界点、移行と調達条件を整理すると、提案の質と導入後の安定運用につながります。全体像は教育機関向けシステムの完全ガイドもご覧ください。

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

RFPに書くべき機能要件・非機能要件の整理

機能要件と非機能要件を、業務機能の洗い出しや優先度、アクセス管理、性能・可用性に分けた図。
優先度と品質条件をそろえると、提案の比較軸が見えやすくなります。

RFPと要件定義書では、機能要件と非機能要件を分けて書きます。機能要件はシステムが行うこと、非機能要件は利用時間や速度、安全性などの品質条件です。特に、教育機関の調達では非機能要件が曖昧になりやすく、運用トラブルの原因になります。

校務・連絡・行政事務の機能要件の洗い出し

機能要件は、現場の業務フローをたどって洗い出します。必要な業務を一覧にして優先度を付けておくと、ベンダーは提案の重点を組み立てやすくなります。

  • 校務:学籍管理、出欠、成績処理、通知表・指導要録の作成、保健管理
  • 連絡:保護者との連絡に必要な機能
  • 行政事務:自組織の事務を効率化する機能
  • 優先度:各機能を「必須・推奨・任意」に分ける

優先度が示されていないと、ベンダーは注力点を判断できず、提案を比べにくくなります。

また、自組織独自のルールを仕様にどこまで含めるかも、あらかじめ線を引いておく必要があります。成績評価や帳票様式は教育機関ごとの差が大きいため、すべてをカスタマイズしようとすると費用が膨らみます。

標準仕様の要件数は、標準化の流れで平均1.2倍となり、一部の領域では3倍以上に増えました。要件が多いほどコストと開発リスクが上がります。そこで、標準機能とカスタマイズが必要な機能を分けて記載します。

発注者がベンダーに対応方針を提案させれば、過剰なカスタマイズを防ぎやすくなります。

セキュリティ・性能・可用性の非機能要件の明記

非機能要件では、セキュリティを最優先で記述します。設定ミスによる情報漏えいが起きていることを踏まえ、個人情報を守る条件を具体化するとともに、初期設定の責任の所在も仕様に含めます。

  • アクセス管理:役割ベースの権限と外部接続の制限
  • 記録:監査ログの取得範囲と保存期間
  • 暗号化:通信と保存データの保護
  • 性能・可用性:応答速度、稼働率、計画停止の通知、障害時の復旧目標

学期末の成績入力が集中しても快適に動く応答速度など、性能と可用性は数値で示します。

クラウド型校務支援システムへの移行が進むなかで、「遅い」「止まった」というトラブルに備えるには、SLAで数値を約束させておくことが欠かせません。数値にできるかどうかが、RFPの完成度を左右します。

教育機関の利用は年度替わりや学期末、行事の前後に集中するため、その時期に動作が重くなると、現場の業務を妨げてしまいます。

性能は、平時ではなく繁忙期を基準に定めます。そこで、RFPには最も利用が集中する時期の同時アクセスでも快適に動くことを明記します。

ベンダーに負荷試験を求めれば、ピーク負荷への耐性を確認できます。

ポイント

判断の目安は、各機能に必須・推奨・任意の優先度が付いているか、非機能要件を数値で書けているかです。優先度がないと、提案の比較が難しくなります。

マルチベンダーのSLAと責任分界点の設定

統括役を中心に、一次窓口、切り分け、責任分界点を配置したマルチベンダー環境の役割図。
連絡先と責任の境界を先に決めると、障害時の調整先が定まります。

校務支援、学習プラットフォーム、行政の基幹システム、クラウド基盤など、教育機関では複数ベンダーの製品が連携する場合があります。

こうした環境では、SLAと責任分界点の設定が見落とされやすく、トラブルの原因にもなります。曖昧なままだと、障害のたびに発注者が原因を切り分けることになります。

障害時の切り分けと一次窓口の定義

接続エラーのたびに、学校や教育委員会が複数ベンダーの間に立つ状態は、マルチベンダー環境で起こりやすい失敗です。

ガバメントクラウドへの接続でも同じ構図が問題になり、市側が原因を切り分ける実態が報告されています。専門知識のない事務職員に任せるのは、現実的ではありません。

  • 一次窓口:障害時に窓口を務める担当者
  • 切り分け:ベンダー間の原因究明と連絡調整の責任者
  • 責任分界点:各システムの境界と責任範囲の図示、文書での確定

統括役(プライムベンダーやインテグレーター)に一次窓口と切り分けの責任を持たせると、発注者は一つの窓口に連絡すれば済みます。

稼働率・復旧時間・保守範囲の数値目標

SLAは、数値で約束させて初めて機能します。そのうえで、保守時間帯を平日日中だけにするか、行事のある休日も含めるかを、自組織の運用実態に合わせて要件に書き込みます。

  • 稼働・復旧:稼働率の目標値と障害発生から復旧までの目標時間
  • 問い合わせ:問い合わせへの一次回答時間
  • 保守時間:対応する曜日・時間帯と休日対応の有無
  • 保守範囲:障害、法改正、軽微な改修、操作問い合わせへの対応

学校では、土日や長期休暇に集中作業が入ることもあります。保守費用は、パッケージ型なら初期費用の年10〜15%程度が一般的です。一方、SaaS型は月額にサポートが含まれる形が多くなります。

RFPでは、保守に含まれる範囲と、含まれない作業の単価を提示させます。そうすれば、運用時の追加費用を把握しやすくなります。

riplaは、フルスクラッチ受託と国内開発の立場から、SLAと責任分界点を契約前に文書で固めることが、長期運用の安定につながると考えています。

導入後の定着支援・オンボーディングの要件化

RFPで見落とされがちなのは、導入後の定着支援を要件として明記することです。

納品で支援が終わると、現場が使いこなせず利用率が下がるおそれがあります。教員のICT校務活用能力は全国平均90.7%ですが、研修受講率は群馬58.8%〜岐阜95.8%と地域差があります。

支援が薄い地域ほど定着が遅れます。そのため、RFPで定着支援を契約に含めておく必要があります。

  • 研修:操作研修の回数と対象者
  • 利用状況:利用ログ分析の頻度
  • 個別支援:つまずいている教員へのフォロー体制
  • 改善:定期的な改善ミーティングの実施

要件定義書に定着支援を盛り込むかどうかで、稼働後に現場へ根づくか、形骸化するかが変わります。あわせて、納品後の伴走がサービスに含まれるか、別料金かも明示させます。

導入の入り口だけでなく、定着までを設計したRFPが、投資を成果につなげます。

定着支援の要件化は、費用を明らかにすることにもつながります。支援内容が曖昧なまま契約すると、追加サポートのたびに想定外の費用が生じ、運用予算が膨らみます。

支援の範囲と頻度を先に定め、その費用は初期費用ではなく運用費として、TCO(総所有コスト)に含めます。こうすれば、5年スパンの総コストを正確に見積もれるうえ、予算の予見性も高まります。

RFPで定着支援まで言語化すれば、現場の安心と予算の見通しを両立できます。

定着支援をどれだけ重く見て提案しているかは、ベンダーが長期運用に責任を持つ意思や体制を見極める材料になります。支援を軽く扱う場合、稼働後に頼りにならないおそれがあります。

RFPは機能だけでなく、長期的なパートナーを選ぶプロセスでもあります。

ポイント

判断の目安は、障害時にどの窓口が原因を切り分け、どこから先を誰が受け持つかを、文書で示せているかです。曖昧なままだと、障害のたびに発注者が調整を担うことになります。

データ移行と過渡期連携の要件化

データ移行と新旧混在期に確認する、クレンジング、リハーサル、照合、年度切り替えの項目を並べた図。
移行準備と切り替え時期を合わせて設計できます。

データ移行と過渡期連携は軽視されがちですが、ここで失敗すると、本番初日に業務が止まるおそれがあります。そこで、既存システムや紙の台帳からデータを移す段取りと責任を、要件定義書に明記します。

データクレンジングと移行リハーサルの範囲

移行で最初に直面するのは、既存データの品質です。表記の揺れや重複、欠損、古い情報が残ると、新システムに誤った情報が表示されてしまいます。

たとえば、自治体の標準化移行では、クレンジングが不足したため、移行後に未納データが誤って表示されるトラブルが起きています。教育機関の学籍や成績データにも、同様のリスクがあります。

  • クレンジング:移行前に誰がどこまで行うか
  • リハーサル:本番前に何回実施するか
  • 照合:移行元と移行先の一致を誰が確認するか

吹田市の標準化移行は約25人月の規模で計画されました。移行は片手間でこなせる作業ではないため、工数と責任分担が曖昧なRFPは、本番直前の混乱を招きます。

新旧混在期の連携と切り替え計画

システムは一夜にして切り替わるわけではありません。新システムの稼働後も、旧システムや別システムと連携する過渡期が生じます。

この新旧混在期の連携は現場にとって難しく、設計しないまま本番を迎えると、二重入力やデータ不整合が起こります。

  • 展開方式:全校一斉か、モデル校から段階展開か
  • データ連携:移行期間中の連携手段
  • 並行稼働:旧システムを動かす期間と停止時期
  • 年度切り替え:年度替わりに合わせた切り替え日

学籍や成績は年度の区切りに強く依存するため、年度替わりのどの時期に切り替えるかは、教育機関特有の重要な論点です。

段階展開では、先行校で得た課題を全校展開に反映する手順も要件に含めます。過渡期の計画を立てておくことが、安定稼働への近道になります。

ポイント

判断の目安は、データのクレンジングとリハーサル、照合の担当と回数が決まっているかです。切り替え時期が年度の区切りに合っているかも、判断材料になります。

調達制度・補助金に合わせた進め方

公費で行う教育機関の調達では、公平で透明な手続きと、補助金制度との整合が求められます。方式や補助要件を後回しにすると、要件定義が制度に合わなくなり、調達のやり直しや補助金の取りこぼしにつながります。

調達方式と補助要件は、要件定義の前段で固めておくことが大切です。

総合評価入札・プロポーザル・共同調達の選択

調達方式は、求める内容に応じて選びます。価格だけでなく提案の質を評価したい場合や、要件をベンダーの知見で磨きたい場合は、評価項目をRFPに示しておきます。

  • 総合評価一般競争入札:大阪市がクラウド運用の管理補助者を調達した例
  • 公募型プロポーザル:北九州市がAIチャットボットで用いた例
  • 共同調達:複数校・自治体で要件を揃えて調達する方式

仕様が固まりきらず、知見を借りて要件を磨く段階では、プロポーザル方式が有効です。評価項目には、機能だけでなく、移行・運用・サポート体制の実現性も含めます。

規模の小さい教育機関では、共同調達により費用とベンダー調整の両面で効果が期待できます。1校あたりのコストを抑えられ、調達事務の負担も分担できます。

発注者は、要件定義の段階で単独調達か共同調達かを決めます。共同調達を選ぶ場合は、参加組織間で必須要件をすり合わせておくと、後の合意形成を進めやすくなります。

補助金要件のRFPへの織り込み

補助金を活用すると、初期投資の負担を抑えられます。ただし、制度には適用要件と期限があるため、RFPを作成する前に対象範囲を確認します。

  • 次世代校務DX関連:1校あたり最大約680万円、補助率1/3等
  • 自治体のデジタル基盤改革支援補助金:対象要件の確認
  • デジタル人材シェアリング:費用の半額を自治体が補助する例もある

対象経費やクラウド化などの条件を満たすよう、構成と調達日程を設計します。

要件定義書に補助要件を明記して、補助対象に合う提案をベンダーに求めます。

riplaは、フルスクラッチ受託と国内開発の立場から、調達制度と補助金をRFPに含め、要件定義から運用まで一貫して支援する進め方を重視しています。

評価項目とスケジュールの明確化

提案の評価項目とスケジュールを明確にすることは、RFPの完成度を高める最後の要素です。評価方法を示さないと、各社の提案がばらばらになり、公平に比べられません。

そこで、配点とともに評価項目を提示し、機能だけでなく移行と運用の実現性も重く見ると、稼働後のトラブルを減らせます。

  • 機能:充足度
  • 移行:計画の現実性
  • 運用:SLA、責任分界、定着支援の体制
  • 費用:TCO(総所有コスト)

日程は、学籍や成績が年度の区切りに依存する点を踏まえて組みます。RFPでは、切り替え時期、移行リハーサルの期限、補助金の交付時期と調達時期を時系列で整理します。

約25人月規模で計画される標準化移行の例のように、無理な日程は現場を疲弊させ、品質を落とします。

評価と日程を明確にすると、正確な提案が集まり、発注者の意思決定にもつながります。

要件・SLA・移行・調達に加えて、評価とスケジュールまで描くことで、RFPを完成させます。

ポイント

判断の目安は、調達方式と補助要件が要件定義の前段で決まっているかです。補助要件を後から足すと、調達のやり直しや補助金の取りこぼしにつながります。

まとめ

教育機関向けシステムのRFP・要件定義で押さえる柱は四つです。第一は、優先度を付けた機能要件と、数値で書く非機能要件です。

第二は、マルチベンダー環境でのSLA・責任分界点・一次窓口の確定です。第三は、データクレンジング・移行リハーサル・過渡期連携を含む移行要件です。第四は、調達方式と補助金の整合です。

標準仕様の要件増、約25人月規模の移行、最大約680万円の補助も、検討事項を具体化する材料です。

機能を網羅するだけでなく、障害・移行・調達の課題を先回りして文書にしておくと、SLA・移行手順・補助要件まで整理したRFPになります。それが、提案の質と導入後の安定運用につながります。

riplaはフルスクラッチ受託と国内開発を組み合わせ、業務から逆算した要件整理と制度整合を支援します。全体像は教育機関向けシステムの完全ガイドもご覧ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。