学校向けシステムの調達で失敗を避けるうえで、もっとも重要かつ難所になるのがRFP（提案依頼書）と要件定義書の作成です。公共・教育分野の調達は、入札やプロポーザルといった手続きの制約があり、いったん仕様を固めて公告すると後から要件を足しにくいという特性があります。要件が曖昧なまま調達に進むと、ベンダー任せの開発になり、現場の業務と噛み合わない「使われないシステム」を生む原因になります。だからこそ、RFP・要件定義書の段階で、機能要件・非機能要件・移行要件・運用要件を漏れなく言語化しておくことが欠かせません。
本記事は、学校向けシステムのRFP・要件定義書・提案依頼書の作り方を、発注する学校・教育委員会の視点から実務的に解説する「要件定義特化」の記事です。校務の機能要件をどう棚卸しするか、情報漏えいを防ぐ非機能要件・権限要件をどう書くか、既存システムからのデータ移行と過渡期連携の要件、複数ベンダー環境でのSLA・責任分界点の定め方、そして補助金・調達手続きとの整合まで、一次データとあわせて具体的に解説します。なお、学校向けシステム全体の検討手順をまだ把握していない方は、まず学校向けシステムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・学校向けシステムの完全ガイド
機能要件を棚卸しして定義する
要件定義の出発点は、自校・自治体の校務業務を棚卸しし、必要な機能を漏れなく洗い出すことです。学籍・出欠・成績・指導要録・通知表・調査書といった中核機能、保健・時間割・グループウェア、保護者連携、学習系との連携など、業務の単位で「現状どう運用しているか」「システムで何を実現したいか」を整理します。ここを丁寧に行うほど、RFPに載せる機能要件の精度が上がります。
現状（AsIs）と理想（ToBe）を分けて記述する
機能要件を書くときは、まず現状の業務フロー（AsIs）を可視化し、そのうえで理想の姿（ToBe）を描き分けることが重要です。担任、教科担当、養護教諭、事務職員、管理職がそれぞれどう校務を処理しているかをヒアリングし、二重入力や手戻りがどこで起きているかを特定します。そのうえで、システム導入後にどう改善したいかを要件として記述します。この一手間を省くと、現場と乖離した要件になりがちです。
とくに学校では、自治体や学校独自の運用慣行が積み重なっており、標準仕様にそのまま当てはまらない部分があります。自治体の標準化の文脈でも、標準仕様書の要件数が平均1.2倍、一部では3倍以上に膨らんだという指摘があり、独自要件の扱いを誤ると後で費用が膨らみます。RFPでは「標準機能で満たす部分」と「独自にカスタマイズが必要な部分」を分けて明記し、独自要件には理由と優先度を添えると、ベンダーからの提案精度が上がります。
独自要件を検討するときは、「その慣行は本当に残すべきものか」を一度問い直すことも有効です。長年続けてきた手順のなかには、紙の時代の制約から生まれたもので、システム化を機に見直せるものも含まれます。すべての独自慣行をそのままシステムに移そうとすると、カスタマイズが膨らみ、費用とベンダー依存が増します。現場ヒアリングで業務を可視化する過程で、「残す慣行」「やめる慣行」「標準に合わせる慣行」を仕分けることが、要件をすっきりさせ、後の運用も軽くします。要件定義は、業務そのものを見直す好機でもあります。
優先度（MUST/WANT）を付けて要件を整理する
洗い出した機能要件には、必ず優先度を付けます。絶対に外せないMUST要件と、できれば実現したいWANT要件を分けておくと、予算とのバランスでスコープを調整しやすくなります。すべてを「必須」にすると、見積もりが膨らみ、ベンダーも提案の的を絞れません。校務支援システムの整備率が94.8%に達するなか、各社の標準機能でカバーできる範囲は広がっているため、MUSTは標準機能で満たせるものを中心に据えるのが現実的です。
優先度付けは、関係者の合意形成のうえでも役立ちます。担任、事務職員、管理職など、立場が違えば「重要だと思う機能」も異なります。それぞれの要望をすべて並列に扱うと収拾がつかなくなりますが、MUST/WANTという共通の物差しで整理すれば、何を最優先にするかを組織として決めやすくなります。要件定義は技術的な作業であると同時に、学校内の意見を束ねる調整の作業でもあります。優先度を明示することで、後から「あの機能を入れてほしかった」という不満を減らし、納得感のある調達につなげられます。
費用感を要件と照らし合わせることも大切です。パッケージ型は初期数百万〜数千万円で保守が年10〜15%、SaaS型は初期数十万〜数百万円で月額数万〜数十万円、オーダーメイドは小規模で500万〜1,500万円、中規模で2,000万〜8,000万円が相場とされ、オフショア活用で30〜50%の削減も可能です。MUST/WANTの整理ができていれば、どの提供形態が自校の予算と要件に合うかを判断しやすくなります。要件と予算は往復しながら詰めていくものだと考えてください。
非機能要件・セキュリティ要件を定義する
学校向けシステムは、児童生徒の成績・保健情報という極めて機微な個人情報を扱うため、機能要件と同等以上に非機能要件・セキュリティ要件が重要です。性能、可用性、セキュリティ、運用・保守、移行といった非機能要件をRFPに明記しないと、ベンダー間で前提が揃わず、後から「これは見積もりに含まれていない」というトラブルになります。
権限管理・アクセス制御・監査ログの要件
非機能要件のなかでも最優先で定義すべきが、権限管理・アクセス制御・監査ログです。役割（管理職・担任・教科担当・養護教諭・事務職員など）ごとに、どの情報を閲覧・編集できるかを細かく制御する要件を明記します。設定ミスにより患者・利用者の個人情報が外部から閲覧可能になってしまった失敗事例は、医療など他分野でも報告されており、学校でも同様のリスクは現実的です。アクセス制御の要件を曖昧にすると、こうした漏えいに直結します。
監査ログの要件も欠かせません。誰が、いつ、どの情報にアクセスし、何を変更したかを記録し、後から追跡できる仕組みを要件として求めます。これは情報漏えいの抑止と、万一の際の原因究明の両面で機能します。さらに、データの保管場所、バックアップの頻度と保管期間、システム停止時の復旧目標（RTO/RPO）といった可用性の要件も明記しておくと、ベンダーの提案を同じ土俵で比較できます。セキュリティ要件は「あって当然」と省略せず、必ず文書化してください。
非機能要件では、性能の要件も忘れずに定義します。同時に何人がアクセスしても快適に動くか、成績入力が集中する学期末の繁忙期に処理が滞らないか、といった負荷を想定した要件です。学校では、教員が一斉に成績を入力する時期や、保護者が欠席連絡を送る朝の時間帯にアクセスが集中します。こうしたピーク時の性能を要件として示しておかないと、いざ運用が始まってから「重くて使えない」というトラブルになりかねません。可用性・性能・セキュリティを三本柱として、数値で要件化することが、安定したシステムの土台になります。
マルチベンダーのSLA・責任分界点を定める
学校向けシステムは、校務支援、学習系、ネットワーク、クラウド基盤など複数のベンダーが関わるマルチベンダー環境になりがちです。このとき要件定義で欠かせないのが、SLA（サービス品質保証）と責任分界点の明確化です。公共分野では、クラウド接続でエラーが起きるたびに発注側が原因の切り分けを強いられ、どのベンダーの責任か判然としないまま対応に追われる、という実態が指摘されています。
これを防ぐには、RFPの段階で「どこからどこまでが各ベンダーの責任範囲か」という責任分界点を図示し、障害時の一次受付窓口や切り分けの責任者を定めておくことが有効です。SLAでは、稼働率、障害対応の応答時間・復旧時間を数値で定めます。発注側が自前で切り分けに奔走する事態を避けるため、できれば全体を取りまとめる主たる事業者を置き、その役割をRFPに明記することをおすすめします。責任分界の設計は、運用フェーズの負担を大きく左右します。
SLAを定めるときは、数値の根拠と、未達だった場合の対応もあわせて要件化します。たとえば「稼働率99.5%以上」と書くだけでなく、それを下回ったときにどう報告し、どう改善し、場合によってはどう補償するかまで取り決めておくことが、実効性を持たせる鍵です。学校向けシステムは、成績入力や保護者連絡が止まれば現場に直接影響するため、止まらないことと、止まったときに速やかに復旧することの両方を、SLAで担保する必要があります。責任分界点とSLAをセットで設計することが、マルチベンダー環境を安心して運用するための要件定義の要になります。
データ移行・調達手続きの要件を盛り込む
要件定義で見落とされがちなのが、既存システムからのデータ移行と、調達手続きとの整合です。学籍・成績といった重要データの移行は、システム刷新プロジェクトの成否を左右する難所であり、要件として明確に定義しておく必要があります。あわせて、公共・教育分野特有の調達手続きや補助金の要件にも合わせて、RFPを組み立てます。
データ移行・過渡期連携の要件を明記する
データ移行の要件では、移行対象のデータ範囲、移行の方式、データクレンジング（不整合データの修正）の責任分担、移行リハーサルの実施などを明記します。クレンジングを実施しないまま移行した結果、誤ったデータが表示されてしまうトラブルは公共分野でも報告されています。要件として「移行前にクレンジングを行うこと」「移行後の検証を行うこと」を求めておくことが、こうした事故を防ぎます。
さらに、新旧システムが一時的に併存する過渡期の連携要件も重要です。年度の切り替えタイミングや、一部の学校から段階的に移行する場合、旧システムと新システムの間でデータをどう連携させるかを定めておかないと、現場が混乱します。吹田市の標準化移行が約25人月の規模で計画されたように、移行は軽い作業ではありません。移行と過渡期連携の工数・体制を要件に織り込み、見積もりの前提を揃えておくことが、後のトラブルを防ぎます。
移行要件では、移行のスケジュールを学校の年間カレンダーと整合させることも欠かせません。学籍や成績のデータは年度の節目で大きく動くため、年度末・年度初めの繁忙期に移行を重ねると、現場の負担が一気に増します。要件として、いつのデータ断面を移行するか、移行作業を行う時期はいつか、移行中に旧システムでの業務をどう続けるかを明記しておくと、関係者の認識が揃います。データ移行は技術的な作業であると同時に、現場の業務スケジュールとの調整が成否を分ける、極めて実務的な要件領域です。
調達方式・補助金要件との整合を取る
公共・教育分野では、調達方式そのものが要件定義の前提になります。総合評価一般競争入札にするか、公募型プロポーザルにするかで、RFPに求める内容が変わります。たとえば大阪市はガバメントクラウドの運用管理補助者を総合評価一般競争入札で調達し、北九州市は観光向けのAIチャットボットを公募型プロポーザルで調達しています。価格だけでなく提案内容を評価したい場合は、プロポーザル方式が向きます。
補助金を活用する場合は、補助対象になる機能・時期・補助率をRFPの前提に組み込みます。次世代校務DXでは1校あたり最大約680万円（補助率1/3等）の補助があったケースがあり、こうした制度の要件に合わせてスケジュールと仕様を逆算することが、負担を抑えるうえで有効です。ただし、補助の締め切りに合わせて要件定義を急ぐと、現場と乖離した「使われないシステム」を生むリスクがあります。補助は活用しつつ、要件の詰めは妥協しないという姿勢が、調達成功の条件です。
運用・保守要件と提案評価の基準を定める
RFPは、構築するシステムの要件だけでなく、導入後の運用・保守や、提案をどう評価するかの基準まで含めて作り込むことが大切です。学校向けシステムは導入して終わりではなく、年度更新や法改正への対応が毎年発生するため、運用フェーズの取り決めが甘いと後で苦労します。あわせて、提案を公平に比較するための評価基準も、あらかじめ定めておく必要があります。
導入後の研修・オンボーディング・伴走を要件化する
要件定義で見落とされがちなのが、導入後の研修と定着支援です。納品時点でベンダーの伴走が終わると、現場の利用率が下がり、結局は紙やExcelに戻ってしまうという悪循環は、多くの組織で起きています。これを防ぐため、RFPには初期研修だけでなく、導入後の利用ログ分析、現場ヒアリング、UI・運用ルールの改善といった継続的なオンボーディングを要件として盛り込むことが有効です。
教員のICT校務活用能力は平均90.7%とされますが、研修受講率は群馬県の58.8%から岐阜県の95.8%まで地域格差が大きく、研修の手厚さが定着を左右します。要件として「年度更新時のサポート」「操作だけでなく業務フローに沿った実践研修」「問い合わせ窓口の応答時間」などを具体的に記述しておくと、運用フェーズの混乱を抑えられます。保守費用についても、年10〜15%といった相場を踏まえ、改定ルールや上限をRFPで取り決めておくことが、後のコスト膨張を防ぐ注意点になります。
提案評価の基準と配点をあらかじめ示す
提案を公平に比較するには、評価基準と配点をRFPに明示しておくことが重要です。価格、機能の充足度、実績、運用・サポート体制、セキュリティ対応などをどの比重で評価するかを示すことで、ベンダーは的を絞った提案を出せ、発注側も客観的に選定できます。総合評価一般競争入札やプロポーザル方式では、この評価基準の設計が選定の質を決めます。
とくに学校向けシステムでは、価格の安さだけで選ぶと、後から運用コストの肥大化や連携不可といった失敗に直結します。安さ優先で既存システムと連携できず、二重入力が常態化して入れ替えに至り、投資が無駄になった失敗事例は他分野でも報告されています。評価基準には、初期費用だけでなくTCO（総保有コスト）や連携性、定着支援の手厚さを織り込み、長期的な費用対効果で判断できる設計にしておくことが、調達成功の鍵になります。提案依頼書は、良い提案を引き出すための設計図だと捉えてください。
評価の場面では、提案書の記述だけでなく、デモンストレーションや既存導入先への確認も組み合わせると、実態をつかめます。提案書では「対応可能」と書かれていても、実際の操作感や運用の手間は使ってみないと分かりません。可能であれば、主要な業務シナリオに沿ってデモを依頼し、現場の教員にも確認してもらうと、導入後のギャップを減らせます。要件定義からベンダー選定までを一貫した基準で進めることが、現場に使われ、長く活きるシステムを手に入れる近道です。RFPは作って終わりではなく、選定・評価まで貫く判断軸として機能させてください。
まとめ
学校向けシステムのRFP・要件定義書を作るうえで核になるのは、現状（AsIs）と理想（ToBe）を分けて機能要件をMUST/WANTで整理し、権限管理・監査ログ・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を創業。