プロジェクトでの変化
- 申込フロー画面数段階表示で集約
- 離脱率想定範囲内に収束
- リリース計画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ヶ月の計画どおりリリースし、離脱率も想定の範囲に収まりました。同じフォーム設計は、後から足す機能でもそのまま使い回せます。
