こちらはコドモン Advent Calendar 2024の2日目の記事です🎅🎄
こんにちは！ コドモンプロダクト開発部のPdM天川です⛄️
今回は「所在確認アラート」機能の開発において、保育の文脈が強い、かつ前例のない機能の仕様をどのように決めたかを紹介します！
こんな人に向けて書きました
- Vertical SaaSで働くPdM
- ドメイン特化ゆえ前例がない機能を作っている
- ユーザーによって微妙に違う業務をどのように仕様へ落とし込もうか迷っている
所在確認アラートってなに？
子どもの登園予定時刻までに打刻がなかった場合に、施設と保護者の両方へアラートを出す機能です。
登園予定と打刻実績から自動でアラートを表示することで、施設の安全管理を補助しています。
所在確認アラートのむずかしさ
ここからは、所在確認アラートを作る際に悩んだポイントとどのように判断したかを紹介します。
悩みポイント1：ドメインに特化した機能で前例がない
このプロジェクトは「登園予定の子どもの不在にすぐ気づけるようにすることで、取り残し事故を防止する」を目標に始まりました。
アラート機能を作ることは決まりましたが、子どもの命を守るためにはアラートを通して、いつ・誰が・どのような状態になっているべきでしょうか？
前例のない機能を作るために、登園〜点呼の標準的なフローと「来ているはずの子どもがいない」ケースを洗い出し、保護者や施設職員（保育士など）の動きを把握するところから始めました。
悩みポイント2：「標準外」をどう扱うか
「来ているはずの子どもがいない」と告げるアラートは保護者・施設職員の不安に繋がるため、普段以上に誤アラートは許されません。
しかし、施設によって一日の流れやコドモンの運用は異なりますし、操作忘れでアラートが出る可能性もあります。 標準フローから外れたケースがいくつも見つかる中で、意味のあるアラートをどのように作るかが課題でした。
悩みポイントを抱えながらアラートを作るために
ユーザーを理解し標準を作る
まずは社内の元保育士や施設ユーザーへヒアリングを行いました。
アラートが動作する前後の動きも把握するため「来ているはずの子どもがいない」ときの職員の動きを特に深堀っています。
- 点呼はいつ誰が確認している？バス通園の場合は？
- 電話したが保護者が出なかった場合は？
- 打刻忘れで「来ていない」扱いになっていた場合は？
- 施設の欠席データ登録が間に合わなくて「来ていない」扱いになるケースはない？
下2つは事故につながるケースではありませんが、システム上「来ているはずの子どもがいない」扱いになるためアラートが出ます。
ヒアリング前に仮の仕様を考えたことで、仕様を固めつつ、問題になりそうなパターンを同時に発見できました。
「標準」以外をどこまでフォローするか
施設に標準的なフローをヒアリングした結果、仕様は以下のように決めました。
【対象者】
朝9:00〜11:00までに登園予定があるが、予定時刻までに打刻されていない園児
【アラート時刻】
施設向けのアラート → 9:00〜11:00に10分おき更新
保護者向けのアラート → 9:30に一度のみ送信
標準外の発見
標準フローに従って仕様を決めていたことで、実態としてアラートが不要にも関わらずアラート対象になる例がいくつも見つかりました。
アラート対象になる例
- 想定できなかった施設の運用
- 登園予定のない曜日にも一律で登園予定が入っている
- 電話で受けた欠席連絡を午後に登録している
- 避けられない人的ミス
- 保護者の打刻忘れ
- 保護者からの欠席連絡の承認忘れ
- システムが対応できていない
- 欠席と遅刻が両方登録されている場合
- 平日が祝日となり打刻されなかった場合
これらのケースはエンジニアがデータ調査から発見してくれたものもあれば、開発終盤にCSから相談を受けて発覚したものもありました。
標準外をどう判断する？
見つかった標準外は、発見次第アラート対象にするか判断していました。
施設ごとの運用に沿うのは難しいため、ヒアリング中にもらった要望も含めて以下の軸で対応を判断しています。
（上から優先度高）
- システムダウンやプッシュ通知遅延など、事故リスクを上げる可能性のある問題を引き起こさないか
- 施設の安全確認をより効果的にサポートできるか
- 誤アラートによる信頼性低下や混乱に繋がらないか
優先度の判断においては
- 施設にとって重要なものをより優先度高くする
- 全員に使ってもらうことより、標準を適用できるユーザーに早く価値を届ける
ことを重視しています。 （途中で変更もありましたが、それについては後述）
その結果、以下のように判断しました。
対応しなかった例
施設による登園時刻や点呼時刻の違いに対応したい
- 要望例：登園時刻は9:15なのでアラートも9:15以降に表示してほしい
- 対応しなかった理由
- 施設向けアラートが登園時刻より早めに出ても「保護者への架電は9:15以降に行う」と運用ルールを決めてもらえれば影響はほぼない
- 登園予定時刻が正しく設定されていればアラートも出ないため、信頼性低下や負荷リスクにも繋がらない
承認されずに放置された欠席連絡でアラートが出ないようにしたい
- 対応しない理由
- 承認する必要は無い連絡（誤った連絡）か、承認忘れかシステムは判断できない
- 承認状態を無視してアラート対象外にすることもできたが、「安全管理＞施設負荷」の優先度でアラート対象とした
- 「疑わしきはアラート」を合言葉に類似のケースも判断
- 対応しない理由
保護者の打刻忘れによってアラートが出ないようにしたい
- 対応しない理由
- 送り担当の保護者は打刻忘れが理由だとすぐ気づくため、混乱のリスクも低い（パートナー間のやり取りは必要）
- 欠席連絡の放置と同じく、アラート対象にしてもシステムに負荷をかける数ではない
- 対応しない理由
対応した例
- 登園予定のない曜日にも一律で登園予定が入っている施設がある
- 対応方針
- 施設アラート・保護者アラートそれぞれでON/OFFが設定できるようにして、保護者アラートはデフォルトをOFFにした
- アラート対象が50人以上になった場合は保護者アラートを配信停止にした
- 対応した理由
- 実際の打刻状況を調査したところ、数十人のアラート対象者が出る施設が数百施設も見つかり、誤アラートが大量の保護者へ送信されるリスクがあった
- 実態に沿った設定への変更作業を全施設へ促すのは、非現実的かつ機能を利用していただけなくなる懸念もあり断念
- システム負荷と保護者影響がない施設向けアラートはデフォルトONにして、範囲を限定しつつ価値提供した
- 対応方針
リリースを振り返って
やってよかったこと
先行リリースによりシステム負荷やユーザー影響を予想できた
所在確認アラートは施設向け・保護者向けに分かれていますが、施設向けアラートは3ヶ月早く提供開始しました。
これにより、施設向けアラートのリアルなデータを見ながら保護者向けアラートの仕様検討ができました。ここで得たデータが無ければ「標準外」のケースのリスク判断や仕様検討はできなかったと思います。
もっとよくできた
判断軸に関わるリスクをもっと早く見つけたかった
「50人以上がアラート対象になった場合は保護者アラートを配信停止」の仕様決定にはかなり時間がかかり、途中で仕様変更もありました。
理由は検討の過程で保護者アラートの対象ユーザーが想定以上だとわかったことです。
当初は「一人でも多くの子どもにアラートが出せる、かつ誤アラートにならない」ラインを探って仮説立て→データ確認→仮説立て......を繰り返しましたが、途中でシステム負荷の懸念が想定以上だとわかり「システムダウンやプッシュ通知遅延など深刻な問題を引き起こさない」が最優先となりました。
システム負荷のリスクをもっと早く調査できていれば、まず「遅延が出ない送信人数の上限」を確認してそれを満たす仕様を考えられたと思います。
まとめ
所在確認アラートは子どもの安全に繋がる重要な機能だからこそ、イレギュラーな事態の取り扱いがいつも以上に難しい機能でした。 この開発を通して、
- ユーザーをとにかく理解する
- 判断軸と優先度を明確に決める
- リスクは複数の角度から早めに調査して潰す（先行リリースも効果⭕️）
という当たり前のことが、Vertical SaaSならではの開発にもしっかり効くことを再認識しました💪
最後に宣伝
株式会社コドモンは12/5（木）〜6（金）のpmconf(プロダクトマネージャーカンファレンス2024)にSilver Sponsorとして参加します！
6日にはブース参加もしますので、コドモンのPdMに興味のある方はぜひお越しください✨
