依頼は承認機能だけだった
社内で実際に使われているシフト管理アプリに、承認機能を追加する仕事から始まりました。 いまは承認・通知・権限・給与計算・勤怠アラートまでを継続的に見る立場になり、インターン初日から今日まで手を入れ続けています。
- 運用中社内の実システムとして稼働しています
- 初日からインターン参加初日から継続して担当
- +Slack通知依頼になかった機能を自発的に追加
課題 ─ 誰でも自由にシフトを登録できてしまう
社内で使われていたシフト管理アプリには、承認という概念がありませんでした。つまり誰でも自由にシフトを登録できてしまう状態で、管理する側には登録内容が妥当かどうかを確認する手立てがありません。
開発長から、シフト承認機能の実装を依頼されました。インターンとして参加して最初に任された仕事です。
依頼になかったSlack通知を追加した
承認機能自体はすぐに形になりました。ただ、実際に使う場面を想像すると問題が残ります。
承認する人がアプリを開かなければ、承認待ちのシフトがあることに気づかない。申請した側も、承認されたかどうかを確認するためにアプリを見に行かなければなりません。承認という仕組みを入れても、それが回るとは限らないわけです。
依頼された範囲
シフトの承認機能。承認待ち・承認済みの状態を管理できるようにする。
実際に納めたもの
承認機能に加えて、Slack botによる通知とメンション。承認待ち件数と承認画面のURLを送り、承認すべき管理者を名指しでメンションする。
Slack botを作り、ユニットごとの承認待ち件数と承認画面へのURLを送るようにしました。さらに、承認待ちを抱えている管理者をメンションで名指しするところまで実装しています。「通知が来ている」だけでは自分ごとにならないと考えたからです。あわせて、アプリのトップページにも承認待ち件数を表示しました。
これは依頼されたことではありません。ただ、小学生向けワークショップで「教本を完璧にしただけでは誰も完成しなかった」経験があったので、仕様を満たすことと、使う人が目的を達成できることは別だという前提で考えました。
つまずき ─ テーブルを1つ足したら、修正範囲が広がった
承認機能を入れるには、承認の状態を持つテーブルを追加する必要がありました。ところがこれを足したことで、既存のDB設計や既存機能とのバッティングが次々に出てきました。これまで「登録されたシフト＝確定したシフト」という前提で書かれていた箇所が、すべて「承認されたシフトだけが有効」に変わるからです。
想定していたより修正範囲は大きく広がりました。設計を作り直す時間もなかったので、既存の実装を一つずつ読んで影響範囲を洗い出し、地道に修正とデバッグを繰り返して対応しました。
ここで学んだのは、あとから機能を足すときは、足す機能そのものより「その機能が既存の前提を壊す範囲」を先に見積もるべきだということです。
どういう作りのアプリか
Next.js と TypeScript で作られた社内向けのWebアプリです。カレンダー上でシフトを登録し、管理者が承認し、勤怠と給与の見込みまで確認できます。
- Next.js / React / TypeScript ─ 画面とAPIの両方
- Prisma + NextAuth ─ データベースへのアクセスと認証
- FullCalendar ─ シフトのカレンダー表示
- Docker / Docker Compose ─ 開発環境と本番用イメージを分けて管理
- Cloud Build ─ ステージング環境と本番を分けた継続的デプロイ
- Jest ─ テストとカバレッジ計測
いきなり本番に出さず、ステージングで確認してから本番に反映する流れがあるのは、実際に人が毎日使っているシステムだからです。自分の変更でシフトが登録できなくなれば、その日の勤務に影響が出ます。
その後に実装してきたこと
承認機能を入れて終わりではなく、実際に使われるなかで出てきた要望や不具合に継続して対応しています。主なものは次のとおりです。
- 権限の設計 ─ 承認できる範囲を全ユーザーから同ユニットのユーザーのみに限定。さらにユニット→チームの階層化とチーム管理者ロールを追加し、承認機能自体のオン・オフも切り替えられるようにしました。
- 通知の作り込み ─ ユニットごとの承認待ち件数の送信、リマインドルールの変更、通知が届かない原因の調査と修正。
- 給与まわり ─ 確定済みの給与だけでなく見込み給与も表示。計算方法の不具合の修正、ユニット管理者への給与エクスポート権限の付与。
- Googleカレンダー連携 ─ 承認待ち・承認後・却下でカレンダー側のUIを変え、反映を即時に。同期のバグも発見して修正しました。
- シフト変更申請 ─ 承認後にシフトを変えたいケースに対応。変更と追加を分けて扱い、これもSlackに通知します。
- スマホ対応 ─ ブラウザ下部のボタンに隠れてページ末尾が見えない問題を修正。
- 運用まわり ─ 退職したインターンの非表示、勤怠未確定者へのアラート機能。
実装はPRを分けて出し、レビューを受けて直すという進め方をしています。給与計算のように影響範囲が違うものは意識的にPRを分けました。
社内システムのため、画面のスクリーンショットは掲載していません。
詳しくお話しできる内容もありますので、必要であればお問い合わせください。
この仕事で変わったこと
それまでの自分は、依頼された機能を実装することが仕事だと思っていました。いまは、要件を理解したうえで必要な情報を念入りにキャッチアップし、ユーザーの視点に立って必要な機能を自分で考えて足す、というところまでを自分の仕事だと考えています。
この案件のSlack通知が、その変化がはっきり形になった最初のものでした。そして「一度作って終わり」ではなく、使われ続けるものを持ち続ける経験ができたことが、いちばん大きかったと思っています。
いまこのアプリは社内のタスク管理上「保守・運用」フェーズに移っています。大きな機能追加は一段落し、退職したメンバーの非表示や勤怠未確定者へのアラートのように、運用していて初めて出てくる要望に対応する段階です。派手さはありませんが、作ったものが生き続けるというのはこういうことだと実感しています。