プロジェクトでの変化
- チケット発行〜利用一連の
動線を 一画面に 集約 - 運用負荷問い合わせ件数の
抑制 - リリース計画スケジュールで
着地
課題
発行して、
アプローチ
- 01 チケットの
発行〜利用までの ライフサイクルを 整理しました - 02 Laravel で
管理画面と 発行APIを 設計・実装しました - 03 Docker で
ローカル〜本番までの 環境を 統一しました - 04 AWS上での
配信・ データ取り扱いも 含めて 構成しました - 05 運用部門の
オペレーションを 起点に 画面構成を 組み、 説明書が なくても 使える 状態を 目標に しました - 06 発行ロジックと
管理画面を 同時に 設計し、 片方の 都合が もう 片方の 体験を 歪めない 構造に しました
成功要因
- ライフサイクル整理
- 発行・配布・利用・集計の
ライフサイクルを 最初に 整理し、 管理画面の 構成方針を 一本化しました。 - 運用部門起点の
画面設計 - 運用部門の
オペレーションを 基点に 管理画面を 組み、 問い合わせ起点の 負荷を 構造的に 抑えました。 - 発行ロジックと
管理画面の 同時設計 - 発行APIと
管理画面を セットで 設計し、 片方の 都合が もう 片方の 体験を 歪めないようにしました。 - 環境統一に
よる 安定運用 - Docker + AWS で
ローカル〜本番の 環境を 揃え、 リリース後の 運用立ち上げを スムーズに しました。
ソリューション
管理画面と
