プロジェクトでの変化
-
申込フロー画面数段階表示で集約
-
離脱率想定範囲内に収束
-
リリース計画10ヶ月で予定通り
課題
金融商品の申込フォームは、規約・本人確認・職業情報・勤務先情報・運用機関の選択など、入力項目が多くフローが複雑になりがちな領域。画面遷移を細かく分けると離脱が増え、まとめると入力負担が大きい、というトレードオフを設計段階で詰める必要があった。さらに金融商品ならではの監督官庁や関連機関側の要件も踏まえる必要があり、後工程での仕様揺れが起きると影響範囲が大きい。「正しさ」と「完了させやすさ」を両立する申込体験を、要件定義の段階で骨格固めしておくことが必須だった。
アプローチ
- 01 業務要件と監督官庁や関連機関の要件を整理し、入力項目を分類・優先度付け
- 02 Laravel + Livewire で「1画面・段階表示」のフォームUIを設計し、画面遷移を増やさない方針を採用
- 03 AWS上でステージング/本番を分離し、本人情報を扱う領域とそれ以外をVPC・IAMレベルで分離
- 04 Tailwindで申込フォーム専用のデザインシステムを最小構成で構築
- 05 Livewire のサーバ側状態管理でバリデーションを集約し、フロント由来の検証漏れを構造的に排除
- 06 監督要件と業務要件を兼ねたテストケースをCIに組み込み、リリース時の不確実性を低減
成功要因
- 段階表示型のフォーム設計
- 画面遷移を増やさずLivewireで段階表示し、入力負担と離脱率のトレードオフを設計段階で詰めた。
- 監督要件の事前整理
- 監督官庁や関連機関の要件を入力項目分類に先に落とし込み、後工程での仕様揺れを抑えた。
- 本人情報の境界明確化
- AWS上でVPC・IAMから設計し、本人情報を扱う領域とそれ以外を最初から物理的に分離した。
- サーバ起点の状態管理
- Livewireで状態管理をサーバ側に寄せ、フロント由来の検証漏れが起きにくい構造にした。
ソリューション
Laravel本体に Livewire を組み合わせ、SPA的な体験をしつつもサーバ側でバリデーション・状態管理を完結。AWSはVPC・IAMの設計から行い、本人情報を扱う領域とそれ以外を物理的に分けた。10ヶ月の計画スケジュールでリリースまで到達し、想定範囲内の離脱率に収束。後続の機能追加でも同じフォーム設計パターンを再利用できる構造に。