保育・学童のシステム開発外注｜業界規制を発注仕様に翻訳する判断軸

保育所や認定こども園、放課後児童クラブを運営するなかで、既存の保育ICTパッケージだけでは自法人の業務や自治体との連携要件を満たしきれず、追加開発やスクラッチ開発の外注を検討する場面が増えています。しかし、いざ発注に踏み切ろうとすると「保育所指針や放課後児童クラブ運営指針、こども家庭庁の保育DX方針といった業界特有の規制を、業界知識のない開発会社に本当に伝えられるのか」という不安が壁になりがちです。

保育・学童保育のシステム開発外注が難しいのは、業務の運用実態が国の指針・通知でこと細かに規定されており、児童の要配慮個人情報という重い責任も伴うためです。汎用の業務システム開発と同じ感覚で仕様書を組んでしまうと、監査対応や自治体連携で「実運用に耐えないシステム」ができあがってしまうリスクがあります。

さらに令和7年の放課後児童クラブ運営指針改正や、こども家庭庁が推進する保育DX（施設管理プラットフォーム連携・データ標準化）といった制度側の動きは、発注仕様に直接影響します。制度解説だけでは発注の意思決定には不十分で、規制を発注仕様書のどの項目にどう落とし込むかという「翻訳」の視点が欠かせません。

本記事では、保育・学童保育のシステム開発外注で失敗しないために、業界特有の規制を発注仕様に翻訳する観点、既存パッケージ／スクラッチ／ハイブリッドの判断軸、発注先候補に投げるべき業界理解チェック質問リスト、そして発注失敗を防ぐ工程設計と契約形態を、発注実務の順序に沿って解説します。制度解説と製品比較の間で分断されがちな情報を、発注準備の一連の流れとして整理することを目指します。

保育・学童保育のシステム開発外注が「一般的な業務システム開発」と決定的に違う3つの理由

保育・学童保育のシステム開発外注は、一般的な業務システム開発と比べて、発注段階で押さえるべき前提が大きく異なります。汎用の業務システムであれば「業務フローをヒアリングして要件を固める」ことから始められますが、保育・学童保育の場合、業務フローそのものが国の指針・通知で規定されており、システム化の自由度に最初から制約がかかります。この特殊性を発注前に理解しておくことが、要件定義工程で「仕様がぶれる」「監査で使えないシステムができあがる」といった失敗を防ぐ第一歩になります。

ここでは、他業界の業務システム開発と決定的に異なる3つの理由を整理します。

業務運用が指針・通知で細かく規定されている

保育所の業務は、厚生労働省告示の保育所保育指針によって、保育の内容・安全管理・保護者との連携・記録の取り扱いまでが体系的に定められています。放課後児童クラブについても放課後児童クラブ運営指針が定められ、令和7年に改正が行われています（こども家庭庁「放課後児童対策」ページ参照）。

これらの指針は「望ましい業務のあり方」を示すだけでなく、監査（実地指導・指導監査）で確認される具体的な運用項目にもつながっています。つまり、開発会社が「業務フローをヒアリングして仕様化する」のではなく、発注者側が「指針・通知で規定された運用要件を仕様書に翻訳して渡す」ことが求められます。この翻訳作業を怠ると、開発会社は「顧客に言われた通り作った」システムを納品し、監査時に運用上の穴が露呈するという事態になりかねません。

こども家庭庁の保育DX方針が発注仕様に直接影響する

こども家庭庁は「保育DX」の方針を打ち出し、保育所等におけるICT化を制度と補助金の両面で推進しています。特に注目すべきは、施設管理プラットフォーム連携やデータ標準化の動きです。デジタル庁が公表している保育施設等管理システム連携における仕様整理に係る調査研究では、施設・自治体・関係機関の間でデータ連携を進めるための仕様整理が示されています。

これは「今後、標準化されたAPIやデータ項目に沿った実装が求められる可能性が高い」ことを意味します。スクラッチ開発でも、独自データ構造を作り込みすぎると、後から標準化対応のための大規模改修が必要になるおそれがあります。発注仕様書には「将来の標準化対応を見据えたデータ設計」「自治体別様式差異への対応方針」を明記することが望ましく、この観点を持たない開発会社に任せきりにすると、数年後の作り直しリスクを抱え込むことになります。

児童の要配慮個人情報を扱う責任が設計初期から発生する

保育・学童保育のシステムは、児童の健康状態・アレルギー・与薬記録・写真・防犯カメラ映像・保護者情報など、個人情報保護法における要配慮個人情報を含む極めてセンシティブなデータを扱います。要配慮個人情報は、取得時に本人の同意が必要とされるなど、通常の個人情報よりも厳格な取り扱いが求められます。

この責任は、システム設計の初期段階から発生します。「まず動くものを作って、あとでセキュリティを固める」というアプローチは、要配慮個人情報を扱う領域では通用しません。アクセス制御・監査ログ・データ暗号化・保護者側の閲覧範囲設計といった要件を、発注仕様書の初期版から盛り込んでおく必要があります。開発会社が要配慮個人情報の扱いに慣れていない場合、後付けで対応するとコストが跳ね上がるだけでなく、本番稼働後にインシデントを引き起こすリスクも高まります。

保育・学童保育のシステム開発外注で押さえる業界特有の規制

前章で示した「一般的な業務システム開発との違い」を踏まえ、実際に発注仕様書に落とし込むべき規制を整理します。ここでは、規制の解説にとどまらず「仕様書のどの項目に、どのような要件として反映するか」まで具体的に示します。発注仕様書のテンプレートを持っている場合は、以下の各項目を照らし合わせて漏れを確認してください。

保育所保育指針・放課後児童クラブ運営指針と業務要件

保育所保育指針と放課後児童クラブ運営指針は、日常業務からシステム化する項目まで幅広く影響します。特に発注仕様書に反映すべき業務要件は次の通りです。

• 安全計画・BCP（事業継続計画）関連の記録機能：安全計画の策定・訓練実施記録・事故発生時の対応記録などを、指針に沿った項目立てで管理できるようにする
• 保護者との連絡機能：連絡帳・お知らせ配信・欠席連絡・延長利用申請などを、指針の求める「保護者との連携」要件に整合する形で設計する
• 保育・活動の記録機能：日誌・週案・月案・児童一人ひとりの記録などを、監査時に指針との整合性を示せる粒度で残せるようにする
• 職員配置と資格管理：職員配置基準・資格要件を満たしているかを常時確認できるダッシュボードやアラート機能を設計する

令和7年の放課後児童クラブ運営指針改正では、安全計画の策定を含む安全確保、保護者との連絡におけるICT活用の位置付け、性暴力等の防止に係る対応の明確化などが盛り込まれました。既存の学童ICTを利用中であっても、指針改正に対応した記録項目の見直しが必要になることが多いため、追加開発やスクラッチ開発の発注仕様書には「指針改正に対応した記録項目」を明記することが重要です。

こども家庭庁の保育DX方針と施設管理プラットフォーム連携

こども家庭庁が推進する保育DXの一環として、保育所等におけるICT化推進等事業が展開されています。ここでは、保育業務のICT化に加えて、施設管理プラットフォームとの連携やデータ標準化が視野に入っています。

発注仕様書に反映すべき観点は次の3点です。

• データ標準化への追従方針：将来的にこども家庭庁やデジタル庁が示すデータ項目・API仕様に対応できる設計にする（独自データ構造の作り込みを避け、変換レイヤーを設けるなど）
• 自治体別様式差異への対応：補助金請求・報告書式・監査書類の様式は自治体によって微妙に異なるため、フォーマット差異を吸収する仕組みを想定する
• 標準化対応の改修枠：将来の制度改正・標準化対応のための改修工数を、保守契約の枠内で確保できる契約形態にする

これらは開発会社が業界に精通していなければ発想として出てきにくい観点です。仕様書に明記し、発注前面談で開発会社の対応方針を確認しておくことが望ましいでしょう。

個人情報保護法と要配慮個人情報

保育・学童保育のシステムは、個人情報保護委員会が所管する個人情報保護法に基づき、要配慮個人情報を含む多岐にわたる情報を扱います。発注仕様書に反映すべき要件は次の通りです。

• アクセス制御：職員のロール（園長・主任・保育士・栄養士・事務・非常勤等）ごとに閲覧・編集範囲を細かく制御する
• 監査ログ：誰がいつどの児童情報にアクセスしたかを、監査・インシデント対応に耐える粒度で記録・保存する
• 写真・映像の取り扱い：写真販売サービスや防犯カメラ映像の保存期間・削除ポリシー・保護者への公開範囲を明確にする
• 保護者側の閲覧範囲：保護者アプリで閲覧できる情報を、児童本人および同意された範囲に限定する
• データ持ち出し制限：職員の私物端末での閲覧・ダウンロード・スクリーンショットに関するポリシーを設計に反映する

これらの要件は「後から追加する」ことが技術的に難しい項目が多く、初期設計段階から盛り込む必要があります。要配慮個人情報の扱いに関する開発会社の実績・体制は、必ず発注前に確認しておきましょう。

補助金制度と発注順序の制約

保育所等におけるICT化推進等事業などの補助金を活用する場合、発注順序に重要な制約があります。原則として、多くの補助金制度では交付決定通知を受ける前に発注・契約・支払いを行うと、補助対象外になるルールがあります。

このため、発注実務では次の順序を守る必要があります。

1. 補助金の公募情報を確認し、要件・スケジュールを整理する
2. 補助金申請書類（見積書を含む）を作成する（この段階では正式契約は結ばない）
3. 補助金の交付決定通知を受け取る
4. 交付決定通知後に、開発会社と正式契約を締結する
5. 開発着手・支払い

見積依頼と正式契約を混同してしまうと、補助金を受けられなくなるリスクがあります。開発会社側にも「補助金交付決定前は正式契約を結ばない」ことを事前に共有し、スケジュールに余裕をもたせておきましょう。制度の詳細・最新情報は必ず自治体・こども家庭庁の公募要領で確認してください。

保育・学童保育のシステム開発外注の発注判断（既存パッケージ／スクラッチ／ハイブリッド）

規制を発注仕様に翻訳する観点が整理できたら、次は「どの発注形態で進めるか」の判断です。保育・学童保育のシステムには、多くの既存SaaSパッケージが存在し、パッケージだけで足りる業務範囲と、追加開発・スクラッチが必要になる業務範囲が明確に分かれる傾向があります。ここでは3つの判断軸で発注方針を整理します。

判断軸1: 業務のうち標準化された部分／独自運用部分の切り分け

保育・学童保育の業務には「業界全体で標準化されている部分」と「自法人・自地域の独自運用が入る部分」が混在しています。

• 標準化されている部分（既存パッケージで対応しやすい）：登降園記録・保護者連絡・シフト管理・請求書作成・一般的な指導記録・写真販売など
• 独自運用が入りやすい部分（追加開発・スクラッチを検討）：自治体別の補助金請求書式・独自の監査書類フォーマット・多拠点の帳票統合・関連法人（社福・営利・NPO）間のデータ統合・独自の教育プログラム記録など

まずは「標準化された部分」は既存パッケージに任せる前提で棚卸しし、「独自運用が入る部分」だけを外注対象にするのが、コスト・期間・品質のバランスが取りやすい選択です。全部をスクラッチにすると、パッケージが日々の改善で追従している標準機能まで自前で保守することになり、TCO（総所有コスト）が跳ね上がります。

判断軸2: 自治体連携・監査書類の対応範囲

保育・学童保育のシステムで最も難易度が高いのが、自治体連携と監査書類対応です。自治体ごとに次の差異があります。

• 補助金請求書式・報告書式のフォーマット差異
• 提出方法（紙・PDF・Excel・自治体独自のポータル・電子申請システム）
• 提出頻度・締切
• 監査・実地指導で確認される項目の粒度

複数拠点を複数自治体で運営している法人ほど、この差異吸収の負荷が大きくなります。既存パッケージが自治体ごとの差異にどこまで対応しているかは製品によって幅があり、対応していない自治体分をスクラッチで補うか、拠点ごとに別パッケージを使い分けて業務側で吸収するかの判断が必要です。この判断を発注前に整理しておかないと、発注仕様書が肥大化して見積が跳ね上がる原因になります。

判断軸3: 補助金活用の可否と発注スケジュール

前章で述べた通り、保育所等におけるICT化推進等事業などの補助金を活用する場合、交付決定通知前の発注は補助対象外となるルールがあります。この制約は、発注形態の選択にも影響します。

• 既存パッケージ導入：初期費用・月額費用の見積が明確で、補助金申請書類の作成がしやすい
• スクラッチ開発：見積の精度を高めるための要件定義に時間がかかる。補助金申請までに要件定義を完了させる必要があるが、要件定義自体を有償で外注する場合の扱いは補助金制度により異なる
• ハイブリッド：パッケージ部分は補助金対象、追加開発部分は補助金対象外というケースもあり、切り分けと申請書類作成が煩雑になる

補助金を活用したい場合は、公募開始から交付決定通知までの期間を逆算し、要件定義完了時期・見積確定時期を計画する必要があります。

判断軸の適用例

前記の3つの判断軸を組み合わせると、発注方針は次のようなイメージで決まります。

• パッケージ×スクラッチ拡張：既存パッケージで登降園・保護者連絡・シフト・請求など標準業務を賄い、独自の監査書類・自治体連携・関連法人統合部分だけをスクラッチで開発してAPI連携する形。多拠点法人で選ばれることが多い
• フルスクラッチ：業界向けSaaSを企画するスタートアップや、既存パッケージが自法人の運用と決定的に噛み合わない大規模法人が選択。TCOと制度追従の体制構築が課題
• 複数パッケージ連携：拠点ごとに異なるパッケージを使い、本部で統合ダッシュボードだけをスクラッチ開発する形。M&Aで複数法人を統合した場合などに検討される

いずれのパターンでも「業界特有要件を発注仕様書に翻訳できているか」「開発会社が業界を理解しているか」の2点は共通の成功要因になります。

参考: 保育・学童向けシステムのスクラッチ開発費用相場と落とし穴

保育・学童向けのシステムをスクラッチ開発した場合の費用は、機能範囲や規模により大きく変動します。一般的な業務システムのスクラッチ開発費用については、複数の発注支援サービスが目安を公開していますが、保育・学童領域には次の追加要因があるため、汎用の費用相場をそのまま当てはめると見積が甘くなりがちです。

• 要配慮個人情報対応のためのセキュリティ設計コスト：アクセス制御・監査ログ・暗号化を設計初期から組み込むため、汎用システムより工数が増える
• 自治体連携の実装・検証コスト：自治体ごとの様式差異への対応工数、テスト工数が読みにくい
• 制度改正への追従コスト：初期開発だけでなく、保守契約に改修枠を含める必要があり、保守費用が高めになる傾向

見積を取る際は「初期開発費用」だけでなく「5年運用時のTCO（改修・保守・追加要件対応）」を必ず比較しましょう。安く見える初期見積が、5年後には制度追従の改修費で高くつくケースは珍しくありません。フルスクラッチでの開発を検討する場合の全体プロセス・費用構造・失敗パターンは、フルスクラッチ開発ガイドも参考になります。

発注先候補に確認すべき「業界理解チェック」質問リスト

ここまで整理した規制と発注判断を踏まえ、発注先候補の開発会社と面談する際に、業界理解を測るための質問リストを提示します。汎用の「システム開発会社選び方」記事にはない、保育・学童業界に特化した観点です。面談時に開発会社側の反応・回答の具体性を観察することで、業界理解の深さを一次評価できます。

保育・学童業務のドメイン理解を測る質問

• 「延長利用の申請・承認・請求までの業務フローをどう設計しますか？」
• 「お迎え変更（急な祖父母のお迎え等）が発生した際の、保護者連絡・職員周知・記録の一連の流れをシステムでどう扱いますか？」
• 「与薬記録の運用について、児童の健康・安全管理の観点でどのような機能が必要と考えますか？」
• 「アレルギー児童への配食管理を、栄養士・保育士・保護者間でどのように連携させますか？」
• 「監査時に指導監査で確認される書類（保育日誌・児童票・職員配置記録等）を、システムからどのように出力できますか？」
• 「保育料・延長料金・実費徴収の請求書作成、口座振替、未収管理までの業務フローをどう設計しますか？」

これらの質問に対して「具体的な業務語彙で回答が返ってくるか」「他社事例を交えた説明ができるか」が、業界理解の指標になります。

データ標準化・自治体連携の対応力を測る質問

• 「こども家庭庁が推進する施設管理プラットフォーム連携について、どの程度追従の準備をしていますか？」
• 「複数自治体にまたがる複数拠点運営で、補助金請求書式の差異をどう吸収する設計を提案できますか？」
• 「将来のデータ標準化に対応するため、初期のデータ設計でどのような配慮をしますか？」
• 「自治体の電子申請システムとの連携実績はありますか？」

この領域は、業界経験のある開発会社であってもまだ探索段階のことが多いため「知らない」と正直に答える会社の方が信頼できる場合もあります。逆に「何でも対応可能です」という回答は要注意です。

児童の要配慮個人情報とセキュリティ設計に関する質問

• 「要配慮個人情報の取り扱いについて、設計初期からどのようなガードを組み込みますか？」
• 「職員のロール別アクセス制御はどの粒度で設計しますか？」
• 「監査ログの保存期間・出力形式・改ざん防止の設計方針を教えてください」
• 「写真販売・防犯カメラ映像の保存期間と削除ポリシーを、どのように仕様書化しますか？」
• 「多要素認証の導入について、職員の端末事情も踏まえた現実的な提案はありますか？」
• 「インシデント発生時の初動対応・報告体制の設計はどこまで支援できますか？」

セキュリティに関しては、抽象論ではなく「具体的な設計例」「他業界での実装経験」を語れるかどうかが重要です。

制度改正・監査対応への追従体制に関する質問

• 「保育所指針・放課後児童クラブ運営指針の改正が発生した場合、どのようにシステム改修を進めますか？」
• 「保守契約に制度改正対応の改修枠は含まれますか？含まれる場合、どの範囲まで対応可能ですか？」
• 「自治体の様式変更が発生した際の、通知から改修完了までのリードタイムはどの程度ですか？」
• 「監査（実地指導）に立ち会った実績、または監査対応で改修を求められた経験はありますか？」

制度改正・監査対応は「導入時の一発勝負」ではなく「継続的な追従体制」が必要な領域です。運用契約の設計と合わせて、開発会社の体制を確認しましょう。

発注失敗を防ぐ工程設計と契約形態

発注仕様書と業界理解チェックが整理できたら、最後は工程設計と契約形態の設計です。保育・学童保育のシステム開発外注では、契約の切り方一つで失敗リスクが大きく変わります。ここでは実務的に有効な工程設計と契約形態を4つ紹介します。

発注前に「業界要件整理フェーズ」を単独契約で切り分ける

いきなり本開発の一括請負契約を結ぶのではなく、「業界要件整理フェーズ」を単独契約で切り分けることを強く推奨します。このフェーズでは次のような成果物を作ります。

• 保育所指針・放課後児童クラブ運営指針・こども家庭庁の保育DX方針を、自法人の業務に落とし込んだ「業界要件整理書」
• 現状業務のプロセス図と、既存パッケージで賄える範囲・追加開発が必要な範囲の切り分け
• 自治体別様式差異の一覧と、対応方針
• 要配慮個人情報の取り扱いに関するセキュリティ要件書
• 補助金申請と発注スケジュールの整合表

このフェーズを単独契約にすることで、複数の開発会社から並行してこのフェーズだけの見積を取り、業界理解の深さを実際の成果物で比較できるようになります。本開発の一括請負契約は、このフェーズの成果物が固まってから、同じ会社に発注するか別会社に発注するかを判断できます。

パッケージ×スクラッチのハイブリッド開発時の契約分割

パッケージ×スクラッチのハイブリッド開発では、契約が複雑になりがちです。次のような契約分割を検討しましょう。

• パッケージ利用契約：既存SaaSベンダーとの利用契約（月額課金）
• スクラッチ開発契約：追加機能の開発を担当する開発会社との請負契約
• 連携・統合契約：パッケージとスクラッチ部分のAPI連携を担当する契約（開発会社が兼務するか、別の統合SIerに委託するかは規模による）
• 運用・保守契約：開発完了後の保守・改修を担当する契約

契約を分割する際は「責任分界点」を明確にすることが重要です。障害発生時に「パッケージ側の問題か、スクラッチ側の問題か、連携部分の問題か」の切り分けができないと、対応が長期化します。契約書の中に「障害切り分けプロセス」「情報連携の義務」を書き込んでおきましょう。

制度改正・監査対応を運用契約に組み込む

保育・学童保育のシステムは、初期構築後も制度改正・監査対応で継続的な改修が発生します。運用契約の設計時には次の観点を組み込みましょう。

• 改修枠：年間の制度改正対応工数を、月額保守費用に含める（例: 年20人日など）
• SLA（サービス品質保証）：制度改正・自治体様式変更の通知から改修完了までのリードタイム
• 改修費の扱い：改修枠を超えた場合の単価、緊急改修の扱い
• 監査書類出力の保証：監査時に必要な書類が、システムから正確に出力できることの保証
• エスカレーション体制：制度改正情報を、開発会社と発注者側でどう共有・優先度付けするか

これらを契約書に明記しないまま「後で相談」で進めると、制度改正が発生した際に「改修は別料金です」と言われる可能性があります。

多重下請け構造への対応

システム開発業界では、元請けが受注して下請け・孫請けに実開発を再委託する構造が広く存在します。保育・学童保育のように業界特有の理解が必要な領域では、この多重下請け構造が失敗リスクを高めます。「元請けは業界を理解しているが、実際に開発するのは業界を知らない下請け会社」というケースが起きうるためです。

発注前に次を確認しておきましょう。

• 実際に開発を担当する会社（体制図で誰が何を担当するか）
• プロジェクトマネージャーが元請け側にいるか、下請け側にいるか
• 業界要件の理解を担保する仕組み（元請けから下請けへの要件伝達の質保証）
• 情報セキュリティ責任の分界点

契約書には「再委託の可否」「再委託先の事前承認」「再委託先の情報セキュリティ責任」を必ず盛り込みましょう。児童の要配慮個人情報を扱うため、再委託先が把握できない状態は避けるべきです。

まとめ｜保育・学童保育のシステム開発外注で失敗しない発注準備の進め方

本記事では、保育・学童保育のシステム開発外注について、業界特有の規制を発注仕様に翻訳する観点から発注準備の進め方を整理しました。要点を再度まとめます。

• 保育・学童保育のシステム開発外注は、業界の運用実態が保育所指針・放課後児童クラブ運営指針・こども家庭庁の保育DX方針で細かく規定されており、汎用の業務システム開発とは前提が大きく異なる
• 発注仕様書には、指針・通知に沿った業務要件、こども家庭庁のデータ標準化への追従方針、要配慮個人情報のセキュリティ要件、補助金活用時の発注順序制約を明記する必要がある
• 発注方針は「既存パッケージで賄える標準化された業務」と「独自運用が入る業務」を切り分け、パッケージ×スクラッチのハイブリッドを軸に検討するのが現実的
• 発注先候補には、業界特有の業務ドメイン理解・データ標準化と自治体連携の対応力・要配慮個人情報のセキュリティ設計・制度改正への追従体制を測る質問リストで一次評価を行う
• 発注前に「業界要件整理フェーズ」を単独契約で切り分けると、複数の開発会社を実成果物で比較でき、本開発のリスクが大きく下がる
• 制度改正・監査対応は運用契約に改修枠として組み込み、多重下請けによる業界理解の希薄化リスクにも契約書レベルで対策する

明日から取れる次のアクションとしては、次のステップを推奨します。

1. 自法人の業務を「標準化された部分」と「独自運用が入る部分」に棚卸しし、外注対象範囲を仮決めする
2. 保育所指針・放課後児童クラブ運営指針・こども家庭庁の保育DX方針・要配慮個人情報の各観点を、既存の発注仕様書テンプレートに反映する
3. 補助金を活用する場合は、公募スケジュールから逆算して要件定義完了時期を計画する
4. 「業界要件整理フェーズ」を単独契約で発注する候補として、複数の開発会社にコンタクトを取り、本記事の質問リストで一次評価を行う
5. 運用契約に含めるべき改修枠・SLA・監査対応保証の要件を、社内で言語化する

保育・学童保育のシステム開発外注は、業界特有の規制と実運用を発注仕様に翻訳できるかが最大の分岐点です。「業界知識のない開発会社に本当に伝わるのか」という不安は、規制の翻訳表と業界理解チェック質問リストを準備することで、実行可能な発注プロセスに変わります。制度と実務を接続する視点をもって、発注準備を一歩ずつ進めていただければ幸いです。