保育園・幼稚園向け保育士シフト管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

保育園・幼稚園向け保育士シフト管理システムは、勤務表を自動で並べるだけではなく、園児数、年齢・クラス、開所時間、資格、経験、希望休、早番・遅番、急な欠勤までを同時に確認し、保育の安全と職員の働きやすさを両立させる仕組みです。

導入や開発を成功させるには、いきなり製品や開発会社を決めるのではなく、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズで進めることが重要です。この記事では、各段階で決めること、デモや見積もりで確認すること、クラウド型と個別開発の費用レンジを、実務で使えるチェックポイントに分けて解説します。

▼全体ガイドの記事
・保育園・幼稚園向け保育士シフト管理システム開発の完全ガイド

保育園・幼稚園向け保育士シフト管理システムの全体像

保育施設のシフトは、職員の希望を集めて勤務時間に割り当てれば完成するものではありません。時間帯ごとに必要な職員数を満たしながら、クラス、年齢、資格、経験、担任、休憩、勤務間隔、行事、延長保育などを組み合わせる必要があります。システムの役割を「自動で正解を出す機械」と考えるよりも、配置不足や禁則勤務を早く見つけ、園長や主任が説明可能な判断をできるようにする業務基盤と考えると、要件が整理しやすくなります。

一般的な勤怠システムは、出退勤の記録や労働時間の集計を得意とします。一方、保育士のシフト作成では、園児の人数と年齢に応じた配置、クラスごとの担当、保育士資格の有無、経験者と新人の組み合わせ、短時間勤務者の勤務可能時間まで考慮しなければなりません。さらに、早番と遅番の偏り、連続勤務、休憩の確保、土曜保育、延長保育、行事日といった園独自のルールもあります。

CoDMONが公開する導入施設アンケートでは、シフト作成に3〜4時間かかる回答が32％、5〜6時間以上が28％あり、修正があるとの回答は93％でした。2020年12月実施、n=146の導入施設アンケートであり、2026年の市場全体を示す統計ではありませんが、月次作成が終わった後も変更対応が続くという現場課題を理解する材料になります（出典: CoDMON導入施設アンケート、2020年、n=146）。

最初から必要になりやすいのは、職員マスタ、雇用形態・資格・経験年数・所属クラス・勤務可能時間の登録、勤務パターン、希望休の収集、月間シフトの作成、日次の配置過不足確認、欠勤時の交代、勤務時間・残業・有休の集計、Excel・PDF・CSV出力です。これらは日々の判断と給与締めに直結するため、画面の見栄えよりも、入力のしやすさと計算結果の確認しやすさを優先します。

出退勤打刻、登降園予定との連携、給与計算への勤怠CSV連携、職員アプリへの通知、保護者連絡、複数園の横断集計は、法人の状況に応じて第2段階へ回せます。小規模園が最初からすべてを個別開発すると、データ整備と現場研修が追いつかないことがあります。まずは「配置不足を防ぎ、月次作成と当日変更を記録し、勤怠へつなぐ」範囲をMUSTとし、AI提案や高度な分析をWANTに分けると、投資判断を説明しやすくなります。

自動生成は、必要人数、希望休、勤務パターン、連続勤務の回避、経験者の配置など、規則に落とせる条件を高速に処理する部分に向いています。反対に、職員の体調、保護者対応の経験、園内の人間関係、特別な行事の配慮など、数値化しにくい事情まで機械に委ねると、現場が納得しないシフトになりかねません。システムには、作成結果を手修正できる画面、変更理由の記録、変更後の再計算、配置不足の警告を用意します。

保育士シフト管理システム開発・導入の進め方

進め方の基本は、6フェーズを順番に進めながら、各フェーズの成果物を次の判断に使うことです。要件整理で現状を言語化し、選定で既製品と個別開発を比較し、設計・開発でルールを画面と計算式に落とし込みます。その後、実データを使ったテスト、限定園での稼働、利用状況を確認する定着支援へ進みます。

最初に、現在のExcelや紙の勤務表を集め、希望休の提出、原案作成、主任確認、園長承認、職員への配布、当日変更、勤怠・給与への転記までを時系列に並べます。通常月だけではなく、年度替わり、土曜保育、延長保育、運動会や発表会、職員の休職、複数人の欠勤が起きた月のデータも確認します。作成者だけでなく、園長、主任、担任、非常勤職員、法人本部、給与担当へのヒアリングを行うと、表に書かれていない例外が見つかります。

成果物は、業務フロー、職員・クラス・園児データの項目一覧、配置ルール一覧、権限一覧、MUSTとWANTの優先順位です。特に「配置不足」と表示する条件を、年齢・クラス・時間帯・資格・経験の単位で明記します。配置基準を満たすことをシステムが支援しても、最終的な運営責任や自治体への確認がなくなるわけではありません。こども家庭庁の保育関連ページには令和8年4月1日に更新された基礎資料も掲載されているため、制度改正を前提に設定を変更できる要件にします（出典: こども家庭庁「保育」政策ページ、2026年8月確認）。

選択肢は、保育ICTのパッケージ・クラウド、シフト特化型のサービス、ローコードやAPI連携、スクラッチ開発に分けて比較します。クラウド型は導入が早く、インフラ更新や法改正対応の負担を抑えやすい一方、園独自の細かい勤務ルールが設定できるかを確認する必要があります。スクラッチ開発は複数園の権限や独自の承認手順を作り込めますが、初期費用、保守、制度改正時の改修費を自法人で負担することになります。

デモでは、きれいなサンプル画面だけを見てはいけません。実際の2〜3か月分のシフト、職員条件、園児数、希望休、行事、欠勤ケースを匿名化して渡し、0〜2歳児と幼児の配置、短時間勤務、土曜保育、延長保育、看護師や調理員の扱い、クラス兼務、締め後の交代を再現します。確認項目は、条件を登録できるか、配置不足の根拠が表示されるか、手修正後に再計算されるか、Excel・CSVで戻せるか、スマートフォンで職員が確認できるかです。

要件を決めたら、画面、データ、権限、外部連携、計算処理を設計します。職員マスタには雇用形態、職種、資格、経験年数、所属クラス、勤務可能時間、休憩条件を持たせ、園児・クラス側には年齢、在籍数、登降園予定、必要配置数を持たせます。月次シフトと日次の実績・変更を分けて保存し、誰がいつどの理由で修正したかを追跡できるようにすると、給与確認や職員からの問い合わせにも対応しやすくなります。

画面設計では、シフト作成者向けの一覧と、職員向けの確認画面を分けます。作成者は時間帯、クラス、職種、経験者の有無、休暇数を横断して見られる必要があります。職員は自分の勤務、変更通知、希望休の受付状況だけをスマートフォンで確認できれば十分な場合もあります。開発中は、月次画面だけでなく、急な欠勤を受けた朝の操作を実際に試し、電話や紙の代替手順も含めて仕様にします。

テストでは、画面が開くかだけでなく、配置の判定が業務ルールと一致するかを確認します。まず職員・園児・クラス・勤務パターンのマスタを登録し、通常の月次シフトを作成します。次に、希望休の集中、経験者の不足、短時間勤務、土曜保育、延長保育、行事日、複数人の欠勤、締め後の交代、日をまたぐ勤務を順番に入れ、警告と再計算の結果を主任と園長が確認します。

受入テストでは、現場が紙やExcelで行っていた判断を、システムでも再現できるかを見ます。合格基準は「配置不足がゼロ」だけではありません。警告の理由が理解できること、例外を手修正できること、変更履歴が残ること、CSV出力の時間や項目が給与担当の要件を満たすこと、職員が自分の勤務を確認できることまで決めます。ここを曖昧にすると、稼働後に「自動作成できるが使えない」という評価になりやすくなります。

複数園を運営する法人でも、最初から全園を同時に切り替えない方が安全です。代表園を1園選び、シフト作成者、承認者、職員の一部でパイロット運用を行います。移行するデータは、職員マスタ、クラス、勤務パターン、休暇残数、直近のシフトなどに絞り、古いExcelの重複や表記ゆれを整理してから登録します。1〜2か月は旧運用との並行確認期間を設け、給与締めや監査資料に影響がないか確認します。

稼働初日の前に、欠勤連絡の受付者、交代候補の探し方、承認者が不在のときの代替者、障害時の紙運用、問い合わせ先を決めます。システムが使えない場合にも保育が止まらないことが優先です。職員には全機能を一度に説明せず、希望休の提出、勤務確認、変更通知の確認という日常操作から案内し、管理者には配置確認と変更履歴の確認を追加で研修します。

稼働後は、作成時間、修正回数、配置不足の警告件数、希望休の反映率、早番・遅番の偏り、残業時間、職員からの問い合わせ数を月次で確認します。導入前の1か月分と、導入後の1か月分を同じ条件で比べると、効果を説明しやすくなります。作成時間だけが短くなっても、修正回数や職員の不満が増えている場合は、配置ルールや承認フローを見直す必要があります。

制度改正、開所時間の変更、クラス編成、職員の採用・退職があれば、マスタと配置ルールを更新します。AIや自動生成の精度を追いかけるより、警告を見た主任が理由を説明できること、職員が公平性を感じられること、欠勤時に短時間で代替を決められることを重視します。四半期に一度、現場代表と法人本部でチェックリストを見直す運用にすると、導入効果が一時的なものになりにくくなります。

保育士シフト管理システムの費用相場とコストの内訳

費用は、既製クラウドを使うか、既存システムと連携するか、保育法人独自のシステムを開発するかで大きく変わります。ここで示す金額は、公開料金とリサーチノートに基づく比較レンジです。保育園専用の公的な平均価格ではない推定値も含むため、予算申請では必ず自園の職員数、園数、連携範囲、移行データ、研修内容を前提条件として添えます。

公開料金を比較すると、1園で既製クラウドを導入する場合の初期費用は0円から数十万円程度、月額は必要な機能を絞っておおむね5,000〜40,000円程度が一つの目安です。たとえばCoDMONは初期費用0円から、基本利用料が定員30名以下で月額3,300円、31〜60名で5,500円、61〜100名で8,800円です。シフト管理などのオプションは各月額3,300〜8,800円で、複数機能のパックは定員30名以下27,500円、31〜100名33,000円、101名以上38,500円と案内されています（出典: CoDMON公式料金表、2026年8月確認）。

WEL-KIDSは初期費用0円、月額5,500円から、KidsViewは指導計画・要録機能付きで月額7,000円からと案内されています。ただし、シフト管理だけの料金か、登降園・帳票・請求・勤怠などを含む料金かはサービスごとに異なります。端末、初期設定、データ移行、研修、複数園、追加オプション、サポート、補助金の対象経費は別に確認し、月額の安さだけで決めないことが大切です。

シフト作成、配置確認、希望休、CSV出力に絞った小規模な個別開発は、500万〜1,500万円程度が推定レンジです。登降園予定、勤怠、職員台帳、給与連携、複数園の法人管理まで含める中規模開発では、1,500万〜4,000万円程度が推定レンジになります。これは保育園専用システムの公的な平均価格ではなく、リサーチノートが参照した人事・労務システムの工数・単価情報を保育業務へ置き換えた推定です。既存SaaSのAPI連携や画面追加で済む場合は下振れする可能性があり、複雑な配置計算や大量の既存データ移行を含む場合は上振れします。

工程別の配分は、要件整理が総額の約10％、設計が10〜20％、開発が40〜60％、テストが10〜20％という考え方が一つの目安です。期間は、SaaSの設定・移行・研修なら数週間〜3か月程度、小規模な個別開発なら4〜8か月、複数領域を含む新規開発なら6か月〜1年以上を見込みます。見積書では、開発費だけでなく、要件定義、データクレンジング、現場UAT、並行運用、保守、法改正対応の費用を分けて記載してもらいます。

比較では、初期費用と月額だけでなく、3〜5年総額を作ります。具体的には、利用料、オプション、端末、通信環境、初期設定、旧Excelの整理と移行、研修、問い合わせ対応、追加園、給与・勤怠連携、バックアップ、障害対応、契約終了時のデータ出力を含めます。クラウド型は初期負担を抑えやすい一方、長期利用では月額と追加機能が積み上がります。スクラッチ型は自由度が高い一方、保守費と制度改正時の改修費が継続します。

補助金や加算制度を使える場合でも、年度と自治体によって対象経費、申請時期、上限、実績報告が異なります。ベンダーが「補助金対応」と案内していても、園の所在地と施設種別をもとに自治体の公募要領を確認します。補助金が不採択になった場合の自己負担額、契約開始時期、対象外となる端末や保守費まで事前に書面化すると、後から予算が足りなくなるリスクを抑えられます。

見積もりを取る際のポイントとチェックリスト

良い見積もりは、金額が安い見積もりではなく、前提条件と追加費用が明確な見積もりです。同じ要件を複数社へ渡し、機能、データ、運用、保守を同じ粒度で比較します。見積依頼の前に、代表園の職員数、園児数、園数、シフトの締め日、現在のファイル、連携先、管理者数、スマートフォン利用の有無を整理しておくと、提案の差が見えやすくなります。

RFPには、目的、対象施設、職員・園児の規模、現在の業務フロー、必要機能、データ項目、外部連携、権限、出力帳票、導入希望時期、予算レンジ、検収条件を記載します。機能欄は「希望休を集める」だけで終わらせず、「職員がスマートフォンから提出し、締め切り後は主任の承認を必要とし、変更履歴を残す」のように、利用者、操作、状態、権限まで書きます。

配置に関する要件は、計算ルールと警告・承認ルールを分けます。たとえば「時間帯ごとの必要人数を計算する」は計算ルール、「不足時は赤色で警告し、園長の承認なしに確定できない」は警告・承認ルールです。さらに、資格者が必要な時間帯、経験者と新人の組み合わせ、休憩の扱い、短時間勤務、臨時職員、クラス兼務、締め後の交代を例として書き出します。曖昧な「柔軟に対応」は、追加費用や納期延長の原因になります。

最低3社へ同じ資料を渡し、機能適合度、導入期間、初期費用、月額、追加開発費、移行費、研修費、保守費、障害時の対応、データ出力、契約終了時の返却条件を同じ表で比べます。総合ICT、シフト特化、既存園務システムとの連携に強い会社では、得意な範囲が異なります。価格非公開の会社も、初期設定や複数園の追加を含む総額を出せるか、見積もりの前提を説明できるかで評価します。

デモの評価は、通常の月次シフトだけで決めません。新人とベテランを同じ時間帯に配置するケース、土曜保育、延長保育、短時間勤務、急な欠勤、特定クラスへの応援、園児数の変動を同じシナリオで再現します。画面上で結果を作れても、根拠が見えない、手修正すると配置判定が消える、出力後に再計算できない場合は、運用上の負担が残ります。

システムには、園児・保護者・職員の個人情報、勤務実績、休暇、給与に関わる情報が集まります。役割別のアクセス権限、多要素認証、通信・保存データの暗号化、操作ログ、バックアップ、復旧目標、脆弱性対応、再委託先、データ返却・消去の条件を確認します。個人情報保護委員会のガイドラインを参考に、委託先の安全管理措置を契約前に確認し、契約書や定期報告で監督できる形にします。

IPAは2026年3月に中小企業の情報セキュリティ対策ガイドライン第4.0版を公開しています。最新のガイドラインをRFPの確認項目に使い、サービス提供会社からセキュリティ資料、障害時の連絡体制、復旧実績、監査や認証の範囲を受け取ります（出典: IPA「中小企業の情報セキュリティ対策ガイドライン」、第4.0版、2026年）。また、「法改正対応」「追加園」「連携項目の変更」「データ再移行」が標準保守に含まれるかを確認し、含まれない場合の単価や上限を見積書に明記してもらいます。

保育園・幼稚園向け保育士シフト管理システムのよくある質問

保育施設では、園の規模、運営形態、職員構成、既存の園務システムによって最適な進め方が変わります。以下では、導入前に特に質問されやすい点を、費用、機能、期間、運用の観点から回答します。

価値はありますが、最初から大規模な個別開発を行う必要はありません。職員数が少ない園では、希望休の収集、配置不足の確認、欠勤時の交代、勤怠への転記など、毎月繰り返す負担が大きい業務から始めると費用対効果を判断しやすくなります。公開価格のあるクラウド型では、初期費用0円から、月額5,000円前後から始められる例もあるため、3〜5年総額と削減できる作業時間を比べます。

不要にはなりません。システムは必要人数、資格、経験、勤務時間、希望休など、登録された条件をもとに候補を作り、配置不足や禁則勤務を警告する役割を担います。職員の体調、保護者対応の経験、行事の細かな事情などは現場の判断が必要です。自動生成率よりも、警告の理由を確認でき、手修正後に履歴を残して園長が承認できることを重視します。

短期間で始めたい、標準的なシフトや勤怠を使いたい、制度対応やインフラ運用を任せたい場合はクラウド型が向いています。複数園にまたがる独自の承認、自治体向け帳票、既存システムとの複雑な連携、固有の配置計算が経営上重要な場合は個別開発を検討します。迷う場合は、既製品を代表園で試し、足りない部分だけAPI連携や追加開発で補う段階導入が現実的です。

クラウド型の設定、データ移行、研修で数週間〜3か月程度、小規模な個別開発で4〜8か月、複数領域を含む新規開発で6か月〜1年以上が一つの目安です。実際の期間は、要件の複雑さ、既存データの品質、給与・勤怠・登降園との連携、現場UATの日程で変わります。年度替わりや職員の入れ替え時期に合わせる場合は、開発完了日ではなく、移行・並行運用・研修を含めた稼働可能日から逆算します。

まとめ

保育園・幼稚園向け保育士シフト管理システムは、勤務表を作る機能だけでなく、園児数と配置基準、職員の資格・経験、希望休、急な欠勤、勤怠・給与連携を一つの業務として扱う仕組みです。成功のポイントは、自動作成の派手さではなく、配置不足を見つけ、現場の判断を残し、職員が納得できる運用を作ることです。

進め方は、(1)現状の業務と配置ルールを整理する、(2)実データで製品や開発会社を比較する、(3)計算ルールと権限を設計する、(4)通常月と例外ケースでテストする、(5)代表園から稼働する、(6)効果を測定して定着させる、という6段階です。費用は、公開価格のあるクラウド型なら初期0円から月額5,000〜40,000円程度が比較軸になり、個別開発は小規模で500万〜1,500万円程度、中規模で1,500万〜4,000万円程度の推定レンジです。いずれも自園の条件で変わるため、3〜5年総額で判断します。

まず代表園を1園決め、直近2〜3か月のシフト、職員条件、園児数、希望休、急な欠勤による変更例を集めます。次に、作成時間、修正回数、配置不足、残業、希望休の反映率を導入前の基準値として記録します。そのうえで、MUST機能とWANT機能を分け、3社程度に同じシナリオでデモと見積もりを依頼します。迷った場合は、シフトと配置確認を先に整え、勤怠、登降園、給与、複数園分析を段階的に広げる計画が、費用と定着のバランスを取りやすい方法です。

▼全体ガイドの記事
・保育園・幼稚園向け保育士シフト管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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