子育て支援システム開発の発注/外注/依頼/委託方法について

子育て支援システムの発注・外注では、自治体基幹、園向けICT、保護者向けアプリの対象範囲を分け、標準仕様との差分と運用まで含めて委託先を選ぶことが成功の条件です。

「何をRFPに書けばよいのか」「パッケージとスクラッチのどちらがよいのか」「提示された見積をどう比較すればよいのか」と迷う担当者に向けて、発注形態の選び方、要件整理、契約形態、費用相場、委託先選定、見積比較、導入後の責任分界までを順番に解説します。

▼全体ガイドの記事
・子育て支援システム開発の完全ガイド

子育て支援システムの発注・外注で最初に決める全体像

子育て支援システムという言葉は、ひとつの製品だけを指すものではありません。発注前に対象業務を切り分けないまま相談を始めると、自治体向けの基幹システムを探しているのに園向けSaaSを紹介されたり、保護者アプリの開発費だけで予算を判断したりする行き違いが起こります。

自治体基幹は、子ども・保護者・世帯の台帳、教育・保育給付の認定、施設管理、利用申込、入所管理、保育料や利用者負担額の算定、給付費の請求・審査・支払、通知書や統計帳票、国のシステムとのデータ連携を扱います。住民記録、税、福祉、母子保健、児童手当、子ども医療費助成と連携する場合は、自治体の情報政策部門も発注体制に加える必要があります。

園向けICTは、園児名簿、登降園、欠席連絡、電子連絡帳、午睡・健康観察、指導計画、保護者連絡、請求管理などを効率化します。保護者接点は、制度や相談窓口の検索、利用申込、予約、助成申請、申請状況確認、プッシュ通知などを担います。3層を同時に外注する場合も、どのデータをどのシステムが正本として持つかを決めておくことが重要です。

最初に「誰の、どの負担を、どの指標で減らすシステムか」を決めます。たとえば、保育担当者の審査時間を短縮するのか、園職員の二重入力を減らすのか、保護者の窓口来庁を減らすのかで、必要な機能と優先順位が変わります。オンライン申請率だけを目標にすると、入力途中で離脱した家庭や、申請後の不備確認が紙で残る問題を見落としやすくなります。

対象者も、自治体職員、園長、保育士、施設管理者、保護者、事業者、審査・支払担当に分けて洗い出します。利用者ごとに、必要な権限、利用端末、通信環境、支援が必要な場面、代替手段を整理すると、発注先に伝える要件が具体的になります。

発注形態はどれを選ぶ？パッケージ・SaaS・スクラッチの違い

発注形態は、初期費用の安さだけでなく、標準化への適合、制度改正への追従、データ移行、連携の自由度、5〜7年の総保有コスト、契約終了時のデータ返却を比較して決めます。標準準拠が求められる自治体基幹と、短期間で導入したい園の業務システムでは、適した方式が異なります。

自治体の子ども・子育て支援システムでは、標準仕様に沿ったパッケージを導入し、自治体固有の制度や住民向け機能を外付けする方式が基本候補になります。こども家庭庁は「子ども・子育て支援システム標準仕様書（第2.0版）」を2026年1月30日に公開しており、機能要件や帳票要件を確認できます（出典: こども家庭庁、2026年）。

発注時は、必須機能、オプション機能、自治体独自の追加機能を分け、標準パッケージ本体に過剰なカスタマイズを入れない設計を依頼します。標準化の対象外である相談予約、地域サービス検索、申請状況の見える化などは、住民ポータルや連携基盤として切り分けると、将来の制度改正に対応しやすくなります。

園の登降園、連絡帳、欠席連絡、請求、保護者通知を短期間で整えたい場合は、既存SaaSを利用し、自治体基幹とはAPIや標準データで連携する方式が候補になります。すべてを一社にまとめる必要はありませんが、園児ID、施設ID、保護者の同意、データ更新の責任者を発注書と連携仕様書に明記します。

保護者アプリを独自開発する場合は、画面開発だけでなく、制度情報の更新、通知の配信停止、端末変更、アクセシビリティ、多言語、問い合わせ対応、アプリストア審査まで委託範囲に含めます。デジタル庁の子育て支援制度レジストリは、2025年11月にアプリ事業者へのAPI連携を開始し、2026年1月には民間アプリの連携も始まっています。制度情報を自前で重複管理するか、レジストリを活用するかをRFPで確認します（出典: デジタル庁、2026年）。

スクラッチ開発は、自治体独自の相談支援、予約、給付、地域サービス、複数制度の横断検索など、市販パッケージだけでは実現しにくい価値を作る場合に向いています。一方で、標準仕様に含まれる認定、給付、施設管理、帳票までゼロから作ると、制度改正のたびに検証と改修が必要になり、移行費と保守費が増えやすくなります。

「基幹は標準準拠パッケージ、住民接点は外付け、データ連携は共通API」という構成も、発注形態の一つです。見積依頼では、各方式について初期費用だけでなく、法改正、脆弱性対応、データ返却、終了時の移行支援まで含む5〜7年の総額を提出してもらいます。

RFPと要件整理は業務・データ・連携から始めます

RFPは機能の羅列ではなく、現状の業務、解決したい課題、必須条件、提案してほしい範囲、評価方法を伝える文書です。委託先の提案力に任せすぎると、各社が異なる前提で見積を作り、価格だけでなく範囲も違う比較になります。発注者側で最低限の共通条件をそろえておくことが大切です。

入所申込、認定変更、退所、保育料算定、給付費請求、審査、通知、年度更新を、担当者の作業順に図式化します。通常ケースだけでなく、不備の差し戻し、世帯変更、転園、DV等支援措置、制度改正、年度末の集中処理も含めます。画面一覧だけでは、紙の確認、電話照会、Excelでの集計、承認者の押印といった実際の負荷が見えないためです。

業務フローには、入力者、確認者、決裁者、データの発生元、保存期間、帳票、連携先、処理時間を記載します。保護者が入力した情報を園が確認し、自治体が認定し、別のシステムが請求に使う場合は、どこで不備を検知し、誰が修正するのかまで決めます。

標準仕様第2.0版の機能要件、帳票要件、データ要件、連携要件を確認し、自自治体の現行機能と一つずつ照合します。各項目を「標準で対応」「設定で対応」「追加開発が必要」「対象外」「要確認」に分類すると、委託先の提案を同じ基準で比較できます。

独自事業を追加開発する場合は、標準機能への改修なのか、外部サービスなのか、連携処理なのかを分けます。独自要件を標準本体に埋め込む提案は一見便利でも、次回の標準仕様改定やベンダー変更の際に影響範囲が大きくなります。RFPには、標準部分を継続的に更新できる構造を必須条件として書きます。

RFPには、処理件数や同時接続数、稼働時間、応答時間、バックアップ、障害復旧、認証、権限、操作ログ、暗号化、脆弱性管理、監査、再委託、データセンター、アクセシビリティ、多言語対応を記載します。子どもの氏名、住所、世帯、所得、健康・発達、相談記録などを扱う可能性があるため、情報の重要度ごとにアクセス範囲を分けます。

さらに、現行データの件数と期間、欠損・重複の状態、データクレンジング、移行リハーサル、年度切替、並行稼働、職員研修、問い合わせ窓口、法改正対応、契約終了時の返却形式を示します。ここが曖昧だと、開発費は安く見えても、移行直前や稼働後に追加費用が発生します。

契約形態と責任分界を発注前に決めます

子育て支援システムは、要件が固まった開発だけでなく、調査、要件定義、設計・開発、移行、運用保守を段階的に外注することが多い領域です。すべてを一つの契約に詰め込むより、成果物と判断ポイントが明確な工程は請負、変化が多い工程は準委任や運用サービスなど、仕事の性質に合わせて契約を分ける方が管理しやすくなります。

請負契約は、合意した成果物を完成させる工程に向いています。要件定義書、設計書、プログラム、テスト結果、移行計画書など、検収対象を明確にしてから依頼します。準委任契約は、発注者と受託者が協議しながら要件を詰める調査や伴走支援に向いていますが、作業時間を確保しただけで目的が達成されるわけではないため、会議体、課題管理、成果物、報告頻度を合意します。

SaaSは利用規約やサービス契約で、月額または年額の利用料を支払う形態です。利用料に含まれる機能、初期設定、データ移行、追加アカウント、API、サポート、障害対応、バックアップ、解約時のデータ出力を確認します。開発委託とSaaS契約を組み合わせる場合は、障害の一次窓口と原因調査の責任者を一つに決めます。

子育て分野では、法令や公定価格、帳票、申請項目が変わる可能性があります。契約書には、標準仕様の改定、法改正、自治体独自の制度変更、発注者都合の追加要望を分け、それぞれの費用負担、見積承認の手順、納期、緊急対応の扱いを記載します。

変更管理では、口頭依頼を受け付けず、変更票に目的、影響範囲、画面・帳票・連携への影響、テスト範囲、費用、納期、承認者を記録します。変更の積み残しが年度切替に集中すると危険なので、月次の変更審査と、制度改正前の臨時レビューを設定します。

データ移行では、受託者が変換プログラムを作るだけでなく、発注者がデータの正しさを確認し、旧システム側が抽出形式を提供する場合があります。誰が抽出、クレンジング、変換、検証、承認を担当するかを工程表に落とします。契約終了時に、CSVなどの再利用可能な形式でデータを返却できるかも確認します。

保守契約では、受付時間、重大度ごとの一次回答・復旧目標、計画停止、バックアップ世代、復旧訓練、脆弱性対応、再委託先、インシデント報告、ログの保管期間を確認します。千葉市の標準準拠移行・運用保守の公告でも、情報セキュリティ、品質管理、同種同規模の履行実績、プロジェクト管理者などが参加条件になっています（出典: 千葉市の政府公共調達公告、2024年）。

子育て支援システムの費用相場と見積の内訳

子育て支援システムの費用は、人口、園・施設数、年間申請件数、連携数、移行データ量、標準仕様との差分、クラウド構成、契約期間で大きく変わります。以下のレンジは全国一律の定価ではなく、公開調達や公開調査を基にした予算検討用の目安です。委託先には、同じ前提条件で内訳を提出してもらいます。

1園向けの標準的な保育ICTは、初期設定費が0〜30万円程度、利用料が月1〜5万円程度、導入期間が2週間〜3か月程度というレンジで検討できます。端末やWi-Fiは別途で、園の規模や建物によって10万〜100万円程度の整備費が発生する可能性があります。複数園の保護者アプリや請求連携まで含める場合は、初期50万〜500万円程度、月額10万〜100万円程度など、園数・園児数に応じて増えます。

札幌市私立保育園連盟の2025年調査では、ICT導入園210園の月額利用料は「1万円〜2万円未満」が30％、「2万円〜3万円未満」が19％でした。保護者から利用料を徴収している園は5％にとどまり、Wi-Fi整備費は累計20万円未満が最多でした（出典: 札幌市私立保育園連盟「令和6年度 保育園・認定こども園のICT化に関する調査報告書」、2025年）。SaaSの比較では、月額だけでなく初期設定、端末、研修、保護者サポートを合算します。

中小自治体の標準準拠パッケージ移行は、初期・移行費1,000万〜8,000万円程度、年額の運用保守500万〜3,000万円程度、期間9〜18か月を一つの目安にできます。大規模自治体で、多数の外部連携、独自機能、データクレンジング、並行稼働、ガバメントクラウド対応を含める場合は、初期・移行費5,000万〜3億円程度、年額2,000万〜1億円程度、期間18〜36か月まで広がる可能性があります。

公開事例として、千葉市の標準準拠システム移行・運用保守業務は、契約締結日から2030年12月31日までの期間で、参考価格を税込4億1,822万7,000円以内として公告しています。この金額は大都市の長期契約における個別事例であり、すべての自治体に当てはまる相場ではありませんが、移行と長期保守を別々の費用として考える必要性を示します（出典: 千葉市の政府公共調達データベース、2024年）。

見積書は、要件定義、Fit＆Gap、設定、追加開発、外部連携、帳票、データクレンジング、移行、端末・ネットワーク、テスト、研修、並行稼働、運用監視、法改正、障害対応、バックアップ、ライセンス、クラウド利用料に分けます。合計額だけの見積は、安いのではなく、作業が別項目に隠れている可能性があります。

5〜7年のTCOでは、毎年の保守・クラウド費、制度改正対応、端末更新、追加アカウント、API利用料、研修の追加回、監査・セキュリティ対応、契約終了時のデータ移行を足します。初期費用が低くても、独自改修の保守料やデータ返却費が高い構成なら、長期では逆転する場合があります。

委託先の選定と見積比較で確認すべきポイント

委託先は、会社の知名度や提示価格だけで決めません。標準仕様への対応、同規模自治体や同数の園を扱った実績、移行・保守の体制、連携の設計力、現場定着の支援力を、提案書とヒアリングで確認します。実績の件数だけでなく、どの範囲を担当し、誰が現在も保守しているかを聞くことが重要です。

候補会社には、標準仕様第2.0版の適合状況、必須・オプション機能の対応方法、標準外機能の外付け方針、データ要件・連携要件への対応資料を求めます。既存システムからの移行では、移行リハーサルの回数、エラーの扱い、年度切替の経験、旧システムとの並行稼働の実績を確認します。

保守体制は、担当者の人数だけでなく、制度改正の情報をどう収集し、標準仕様の更新をどう製品へ反映し、障害発生時に誰が自治体・園・保護者へ説明するかを確認します。主担当が休んだ場合の代替、再委託先、担当者の交代、契約終了時の引き継ぎも、長期委託では評価項目になります。

比較表には、作業項目、成果物、数量、単価、工数、担当、納期、前提条件、除外事項、再委託、追加費用を並べます。たとえば「データ移行一式」ではなく、抽出、変換、クレンジング、移行ツール、テスト移行、本番移行、検証、手戻り対応に分けてもらいます。各社の見積項目がそろうと、価格差の理由を説明できます。

技術点と価格点を分けて評価する方式も有効です。価格が低い会社でも、追加開発が多い、導入後の現場支援が薄い、データ返却が有償、法改正が別見積という条件なら、実際の負担は大きくなります。候補会社には同じ業務シナリオを使ったデモを依頼し、処理時間、不備の表示、権限変更、帳票出力、問い合わせ対応を比較します。

評価項目は、機能適合、標準化、連携、セキュリティ、移行、操作性、アクセシビリティ、保守、費用、実績、プロジェクト管理、研修、問い合わせ対応に分けます。現場職員が毎日使う画面では、入力項目の多さやエラーの分かりやすさを、保護者画面ではスマートフォンでの入力完了、多言語、通信が不安定な場面を確認します。

採用後に想定した効果が出ない場合の見直し条件も決めます。たとえば、入力完了率、不備・差し戻し率、窓口来庁回数、審査時間、給付費請求の手作業時間、問い合わせ件数、園職員の記録時間を、導入前後で測定します。KPIが改善しない場合に、設定変更、研修、運用変更、追加開発のどれで対応するかを定例会で判断します。

2026年時点の発注で確認したい標準化・API・データ連携

2026年の発注では、従来の機能一覧だけでは不十分です。標準仕様の更新、自治体間で共有されるデータ要件、保護者に情報を届けるAPI、保育施設の業務電子化、要支援家庭に関するデータ連携を見据えた設計が必要です。新しいサービスを追加する場合も、既存の基幹データと責任分界が崩れないようにします。

RFPには、参照する標準仕様の版、機能要件、帳票要件、データ要件、連携要件を明記します。提案を受ける時点で版が変わった場合の差分確認方法も決めます。標準準拠という言葉だけでなく、適合状況の証跡、未対応項目、対応予定、自治体独自要件との関係を資料で提出してもらいます。

また、制度改正にともなって帳票やデータ項目が変わる可能性を前提に、設定変更で対応できる範囲と、プログラム改修が必要な範囲を分けます。標準仕様の改定を受けたアップデートを誰が、いつ、どのテストで確認するのかを運用設計へ組み込みます。

デジタル庁の子育て支援制度レジストリは、主に未就学児向けの124種類の制度類型を対象に、自治体が制度情報を登録し、アプリ事業者がAPIで取得できる仕組みです。自治体側の制度改廃や内容変更が遅れると、保護者に古い情報が届くため、登録・承認・更新の担当部署を定めます（出典: デジタル庁、2025年11月時点の対象制度と2026年の運用情報）。

アプリを外注する場合は、APIの認証、取得頻度、キャッシュ、障害時の表示、制度情報の有効期限、リンク先の変更、通知対象の判定をRFPで確認します。レジストリを使わない場合も、制度情報の出典、更新履歴、公開承認、誤情報を訂正する手順を設けます。

子ども・家庭の情報を複数の制度や部門で連携する場合は、利用目的、法的根拠、対象データ、保存期間、アクセス権限、本人・保護者への説明、誤判定時の訂正方法を整理します。要支援家庭を把握する仕組みでは、データの不一致や欠落が支援の遅れにつながるため、システムが出した候補を職員が確認する運用を残します。

RFPには、MFA、通信・保存時の暗号化、操作・閲覧ログ、権限の定期棚卸し、バックアップ、脆弱性診断、再委託先の管理、インシデント報告を含めます。AIや自動判定を利用する場合でも、給付や支援可否を機械だけで決めず、職員が根拠を確認し、判断を記録できる画面を依頼します。

発注後の進め方と失敗を防ぐ導入計画

委託先が決まった後は、要件定義を終わらせることだけを目標にせず、現場が本番で使える状態までを計画します。自治体基幹の移行では9〜18か月程度、大規模な移行・連携では18〜36か月程度の期間を想定することがありますが、データの品質、年度切替、調達手続、研修回数によって変わります。

全施設を一度に切り替える前に、規模や運用が異なる代表園、複数の申請パターン、認定変更、給付費請求などでPoCや先行稼働を行います。検証では、機能が動くかだけでなく、保護者の入力完了率、不備率、職員の記録時間、審査時間、問い合わせ件数を測定します。

スマートフォンの小さな画面、通信が不安定な環境、外国語を使う家庭、支援者が代理入力する場面も試します。園職員には、実際の繁忙時間帯に入力してもらい、操作の迷い、確認者の見落とし、紙へ戻る箇所を記録します。PoCで見つかった問題は、追加開発の前に業務手順や入力項目を見直します。

本番移行の前に、データ抽出、変換、取込、件数照合、サンプル確認を複数回行います。年度切替では、旧年度の履歴を参照できること、新年度の認定や施設情報が正しく作られること、通知書・請求データ・統計が一致することを確認します。移行失敗時に旧システムへ戻せる期限と判断者も決めます。

研修は本番直前の一度で終わらせず、管理者向け、現場職員向け、問い合わせ担当向けに分けます。マニュアル、短い操作動画、よくある質問、障害時の紙運用を用意し、稼働後の問い合わせ窓口を一定期間強化します。導入後の定例会では、ログと問い合わせを見ながら、使われていない機能や二重入力を減らします。

よくある質問

子育て支援システムの発注では、対象範囲、費用、契約、標準化、運用に関する質問が多く寄せられます。ここでは、発注前に判断しやすいよう、特に確認されやすい3つの疑問に直接回答します。

自治体基幹は、標準仕様への適合と制度改正への追従を優先し、標準準拠パッケージを軸にする方法が現実的です。自治体独自の相談、予約、情報発信などは、外付け開発やSaaSで補うと、標準本体の保守負担を抑えやすくなります。

現状業務と課題、対象範囲、標準仕様との差分、機能・帳票・データ・連携、非機能、セキュリティ、移行、研修、保守、契約終了時のデータ返却を入れます。特に、年間処理件数、施設数、既存データの状態、外部連携先、制度改正対応、追加変更のルールを示すと、各社が同じ条件で見積を作れます。

機能、工数、移行対象、連携、保守、制度改正、除外事項を同じ様式に並べ、価格差がどの前提から生まれたかを確認します。初期費用だけでなく、5〜7年のTCO、データ返却、追加開発、研修、障害対応まで含め、同じ業務シナリオのデモと実績ヒアリングを組み合わせて判断します。

まとめ

子育て支援システムの発注では、自治体基幹、園向けICT、保護者接点を分け、標準仕様と独自要件の差分を整理します。パッケージ、SaaS、スクラッチ、外付け開発を組み合わせる場合も、データの正本、API、セキュリティ、移行、保守、契約終了時の返却を明確にします。

費用は園向けSaaSの月額数千円〜数万円台、自治体の標準準拠移行の数千万円〜数億円規模など、対象と期間で大きく変わります。公開事例の金額をそのまま自社予算に当てはめず、要件定義、移行、連携、テスト、研修、保守を分解した5〜7年のTCOで比較します。最後に、代表園や代表手続で使い勝手とKPIを検証し、導入後の改善まで伴走できる委託先を選ぶことが重要です。

▼全体ガイドの記事
・子育て支援システム開発の完全ガイド

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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