看護師100名規模のシフト・給与・スキル評価を、ひとつの仕組みに。33名・1か月分のシフトを数秒で自動作成

病棟を持つ医療法人では、シフト作成が看護師長（管理者）の重く属人的な業務になりやすい。日勤・夜勤それぞれの必要人数、夜勤の責任者や小児科の担当、チームのリーダー確保、新人看護師の同時勤務制限、月の労働時間上限といった多くの決まりごとを、毎月Excelなどの手作業で組み直す負担が大きい。同じ規模の医療法人で一般的に見られる課題として、次が想定される。

• シフト作成がベテラン頼みで重い: 守るべき条件が多く、無理のないシフトを組めるのは特定の人だけ、という状態になりやすい。
• 労働時間の超過が見えにくい: 月180時間上限の確認が手作業で、超過に気づくのが後手になりやすい。
• 給与計算の手間とミス: 残業・夜勤・スキル・資格などの手当を個別に計算するため、勤務実績との突き合わせが手作業だと計算・転記のミスが起きやすい。
• 評価と処遇のつながりが不透明: スキル評価の基準が整っておらず、評価結果が手当などの処遇にどうつながるか本人に見えにくい。
• 関係者が多い: 看護部・人事・情報システム・経営層が関わるため、情報がきちんと守られるか・権限が適切に分かれているか・既存の仕組みと連携できるか、への説明が求められる。

業務をよく知る担当者が、現場のルールを聞き取り、そのまま動く仕組みに落とすところまで一気通貫で担当。「現場が言いたいこと」と「出来上がる仕組み」のズレを抑えた。

• 現場のルールを、まず言葉で整理: 日勤・夜勤の必要人数、夜勤の責任者や小児科の担当を最低何人置くか、月の労働時間は180時間まで、といった配置の決まりごとを一か所にまとめて明文化。現場と合意した基準がそのまま仕組みに反映される形にした。
• シフトを自動で組むロジックを実装: 夜勤の責任者→小児科→残りの夜勤→リーダー→日勤の優先順位で各日の人員を埋め、勤務日数・休日数・夜勤回数に偏りが出ないよう公平に割り当て。条件を満たせないときは段階的に条件をゆるめて埋める二段構えにし、実際の人員でも無理なく組めるようにした。
• AIを開発の補助に活用: 決まりごとが多く確認すべきパターンが複雑な領域のため、開発とテスト作りにAIを活用し、シフト・給与・労働時間の計算を短いサイクルで検証しながら作り込んだ。
• 「なぜそうなるか」を共有できる状態に: なぜこの配置順なのか、なぜ180時間で調整するのかを、看護部・人事の関係者が確認できる形で残した。

看護部の勤務管理を、シフト・勤怠・申請・評価・給与をまたいだひとつのWebシステムとして提供した。同じ勤務実績がそのまま給与や評価につながるので、二重入力やズレが起きにくい。

• シフトの自動作成: 看護師ごとの条件（所属チーム、日勤／夜勤のどちらに入れるか、夜勤の希望回数、リーダーや夜勤責任者・小児科の担当可否）をもとに、1か月分のシフトを自動で組む。夜勤の翌日は自動で「明け（休み相当）」とし、月の労働時間が上限を超えそうな人は勤務日を自動で調整する。
• 労働時間の見える化: 看護師ごとの勤務日数・日勤／夜勤の回数・合計労働時間を集計し、月の目標に対して『良好／要注意／違反』を自動で判定。上限超過の兆しを早めに把握できる。
• 本人向けマイページ: 希望休や残業の申請を本人が出し、管理者が承認する流れ。自分の勤務状況や給与の推移も本人が確認できる。
• スキル評価: 評価項目ごとにレベルを記録し、その結果から4段階の評価ランクを算出。評価にも『申請→承認』の流れを設け、誰が承認したかが分かる。
• 給与の自動計算: 勤務実績（打刻データや自動作成したシフト）から労働時間・残業・夜勤回数を割り出し、基本給に加えて残業・夜勤・スキル・資格の各手当を自動で合算。月末にまとめて全員分を計算し直すこともできる。
• 通知・情報共有: 申請の承認などの出来事を通知として記録し、現場の連絡を電子化する土台を用意した。

利用サービスとしては、AI-Pathの担当者による伴走開発、現場ルールを仕組みに落とす設計（シフトの自動配置）、AIを使った開発・テストの効率化、安全なログイン・データ管理の基盤づくりを提供した。

1. FDEによる伴走開発（Forward Deployed Engineer）
2. 現場ルールを仕組みに落とす設計（シフトの自動配置）
3. AIを活用した開発・テストの効率化
4. 安全なログイン・データ管理の基盤づくり

規模が増えても無理なく動き、将来は別のクラウドや人事システムとも無理なくつなげられる構成にした。特定の製品に縛られず、コストや要件に応じて土台を入れ替えられる柔軟性を持たせている。要点は次の3点。

• 堅牢でスケールする構成: 利用者が増えても安定して動く、実績ある標準的な構成を採用。
• 既存業務と無理なく連携できる: 人事システムや勤怠打刻などとつなぐことを見越し、広く使われている標準的なつなぎ方で受けられるようにした。
• 土台を入れ替えられる柔軟性: データの置き場所やログインの仕組みを、利用側の使い勝手を変えずに差し替えられる設計。当初はある基盤で構築し、その後コスト最適化のため別のクラウド基盤へ無理なく移行できた。将来のコスト見直しや自社クラウドへの移行も低リスクで検討できる。

採用した具体的な技術名は技術スタック（tech_stack）に集約。詳細な内部実装は競合に手の内を渡さないため省略している。

現場のルールが変わっても安全に直せ、特定の担当者やベンダーに縛られにくい。長く使い続けられることを重視した。

• 現場ルールの変更が一か所で済む: 必要人数や勤務時間の基準などを一か所にまとめてあるため、ルールの見直しを安全に反映でき、特定の担当者に依存しない保守ができる。
• 土台の入れ替えが局所で済む: データ管理とログインの仕組みを切り離してあるため、基盤の差し替えが一部の変更だけで済む。今後のコスト最適化や自社クラウドへの移行も低リスクで検討できる。
• AIを活かした継続開発: 決まりごとが多いシフト・給与の計算はAIによるテスト作りと相性がよく、機能追加やルール変更を検証付きで素早く回せる開発スタイルを確立した。
• 今後の拡張余地: アクセス制限の本番強化、操作の監査ログ、シフト希望のさらなる反映、メール通知、管理者向けダッシュボード、スマートフォン対応を計画的に整えていく。