エンジニアの呼び出し対応を最適化する「オンコールスケジューラー」開発の舞台裏
はじめに：なぜオンコール管理は見落とされがちなのか
インフラや保守を伴うシステム開発現場において、「障害対応時のオンコール体制」は非常に重要な運用項目です。しかし、多くの企業ではこの運用が「口約束」や「Excel表ベース」のまま放置されており、緊急時の混乱や対応遅れを引き起こしています。特に、24時間365日体制が求められるWebサービスや、業務インフラに直結する業務システムにおいては、この問題が顕在化しやすくなっています。
こうした状況にもかかわらず、オンコール体制は「どうにか回っている」という認識から抜け出せず、技術的な最適化や継続可能な運用設計まで踏み込めないケースが多くあります。その結果、人的な疲弊、情報共有の断絶、障害対応の属人化といった構造的な問題が慢性化します。本記事では、実際にある受託開発プロジェクトで導入された「オンコールスケジューラー」システムの開発知見をもとに、開発背景、設計方針、技術構成、そして導入後の運用効果までを余すところなく紹介します。
開発のきっかけと現場の課題感
本プロジェクトの対象は、月間2,000万PVを超える大規模メディアを運営する企業でした。日中は自社の開発チームが社内で運用保守を行う体制が整っていたものの、夜間・休日の緊急対応は特定のエンジニアに依存し、負担が集中していました。
現場では、以下のような課題が慢性化していました：
・Slackでの「@here」呼び出しが属人的で、責任の所在が曖昧になる ・誰が当番なのかを全員が常時把握できないため、確認に時間がかかる ・深夜の障害アラートが見逃されるケースが月2〜3件発生していた ・対応内容が口頭ベースのため、翌日チーム全体への情報共有が途切れる
これらの課題を解決するためには、「オンコール体制を明文化し、担当者を明確化」「通知・対応の記録と共有を自動化」「属人化せずに持続可能な仕組み」といった要素を統合的に設計する必要がありました。
要件定義と設計方針：シンプルかつ継続可能な仕組みを目指して
オンコールスケジューラーの要件は、単なる当番表の管理にとどまりません。緊急事態に即応できる体制を「いかに無理なく」「継続的に」回せるかを前提とし、以下のような実践的な仕様を定義しました。
・当番表をGoogleカレンダーと連携し、社内既存資産を活用して管理工数を最小化 ・Slack通知を自動化し、エスカレーション先も時間帯に応じて柔軟に切り替え ・アラート対応時に「確認中」「対応完了」などを選べるUIボタンを提供し、ワンクリックで記録 ・履歴情報（発報内容・対応者・所要時間・コメントなど）を時系列で自動蓄積 ・平日日中／夜間休日で異なるルールを定義し、自動で切り替えるスケジューリング機能
この設計方針の中核には、「日々の運用の中に自然に組み込まれ、エンジニアの手間が増えないこと」が置かれました。UI設計や通知の文面も含め、できる限りストレスレスに運用が回るよう設計されています。
技術スタックと構成：軽量＆自走可能なアーキテクチャ
開発はFirebaseを中心に、次のような構成で進められました：
・通知基盤：Slack Webhook（Incoming Webhook App を活用） ・スケジューリング：Google Calendar API と連携し、Firebase Functionsでトリガーを生成 ・フロントエンドUI：Next.js + Tailwind CSS によりレスポンシブかつ軽量な管理画面を構築 ・データストア：Firestore に履歴情報や当番スケジュールを保存 ・認証基盤：Firebase Auth を利用し、ロール別に操作を制限（管理者、当番者、閲覧のみなど）
Googleカレンダーとの統合は、既存の社内運用フローに直接フィットするため、導入コストを抑えながらも高い導入効果が得られる構成となりました。また、Slack通知の内容もカスタマイズ可能とし、平日昼間／夜間休日／特定期間中（大型連休など）といった条件ごとの文面切り替えも可能にしています。
UI/UXの工夫：現場ストレスを軽減する設計
・Slack通知には当番者の氏名・アイコン・担当時間帯を明示 ・通知文中のアクションボタンから、即座に「対応中」「対応完了」「エスカレーション」などを選択可能 ・管理画面では、過去のアラート履歴を日次・週次・月次で切り替えて表示し、対応状況を可視化 ・未対応アラートが一定時間を超えた場合、自動で管理者へリマインド通知を送信 ・アクションログにはタイムスタンプと担当者名、メモも含まれ、レビューや振り返りに活用
エンジニア視点で「通知の押し付け」にならず、「対応しやすく」「共有しやすい」デザインにこだわりました。また、深夜帯や連休中などでもスムーズに対応が回るよう、操作を最小限に抑えたUIが好評でした。
導入後の成果と現場評価
導入から3ヶ月で、以下のような定量的改善が得られました：
・アラート対応漏れ件数：月平均2〜3件 → 0件に削減 ・Slack通知から初回アクションまでの平均時間：27分 → 12分 ・対応履歴の蓄積により、翌朝の引き継ぎ・状況確認の精度が大幅に向上 ・当番スケジュールの更新が属人化せず、Googleカレンダーにより誰でも変更可能 ・週次レビュー時の議論が「誰が対応したのか不明」から「記録に基づいた振り返り」へと進化
エンジニアからは「夜間にSlackを見る心理的負担が減った」「履歴が残ることで安心感が増した」といった評価が寄せられ、管理側からも「組織としての運用力が上がった」と好反応が得られました。
まとめ：運用の仕組み化は技術負債を防ぐ第一歩
オンコール体制の整備は、システムの安定運用を支えるだけでなく、エンジニアの働き方の質や組織の信頼性にも直結する重要なテーマです。「とりあえずExcelで管理」「Slackで呼び出せばOK」といった場当たり的な運用から脱却し、技術と運用設計の融合によって、持続可能で再現性の高い仕組みへと進化させる必要があります。
受託開発においても、こうした「運用フェーズを見据えた提案力」がクライアントからの信頼獲得につながります。オンコールスケジューラーはその一例に過ぎませんが、「回る仕組み」を支えるシステム開発こそが、今後ますます重視される領域となるでしょう。
