プロジェクトでの変化
- チケット発行〜利用一連の動線を一画面に集約
- 運用負荷問い合わせ件数の抑制
- リリース計画スケジュールで着地
課題
発行して、配って、使われて、集計する。福利厚生のチケットは扱う段階が多く、管理画面が分かりにくいと運用部門の負荷が一気に増えます。発行ロジックが複雑なぶん、利用の段階で不整合が出れば問い合わせはすべて運用部門へ向かいます。しかも運用部門は専任のエンジニアではありません。複雑な手順を覚え込んでもらう前提では設計できないということです。ロジックの正しさと、迷わず使える画面。この両方を詰める必要がありました。
アプローチ
- 01 チケットの発行〜利用までのライフサイクルを整理しました
- 02 Laravel で管理画面と発行APIを設計・実装しました
- 03 Docker でローカル〜本番までの環境を統一しました
- 04 AWS上での配信・データ取り扱いも含めて構成しました
- 05 運用部門のオペレーションを起点に画面構成を組み、説明書がなくても使える状態を目標にしました
- 06 発行ロジックと管理画面を同時に設計し、片方の都合がもう片方の体験を歪めない構造にしました
成功要因
- ライフサイクル整理
- 発行・配布・利用・集計のライフサイクルを最初に整理し、管理画面の構成方針を一本化しました。
- 運用部門起点の画面設計
- 運用部門のオペレーションを基点に管理画面を組み、問い合わせ起点の負荷を構造的に抑えました。
- 発行ロジックと管理画面の同時設計
- 発行APIと管理画面をセットで設計し、片方の都合がもう片方の体験を歪めないようにしました。
- 環境統一による安定運用
- Docker + AWS でローカル〜本番の環境を揃え、リリース後の運用立ち上げをスムーズにしました。
ソリューション
管理画面と発行ロジックは Laravel で実装し、運用基盤は Docker + AWS で整えました。画面構成は、運用部門の手順に合わせて組み直しています。発行から利用、集計までの動線を一画面に集めたのがそれです。結果として問い合わせは想定より少なく、立ち上げのコストも抑えられました。運用部門が使い方を覚えるまでの時間も短く済んでいます。
