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