煩雑な動作確認をStorybookで解決。コード修正時間を大幅短縮
リニューアルプロジェクトは2025年3月から5月にかけて実施され、長坂氏がエンジニアリングマネージャーとテックリードの両方の役割を担った。チーム構成は長坂氏に加えてプロダクトマネージャー1名、バックエンドエンジニア2名、フロントエンドエンジニア1名の計5名体制だ。
まず案件作成を容易にするため、UIの見直しを行った。そこで導入したのがReactのStorybookだ。これを使って各UIコンポーネントを単体で検証・修正できる環境を整備した。「技術的な負債の解消に最も大きく貢献したのがStorybookです」と長坂氏は強調する。
案件作成フローには約10ページのステップが存在した。その結果、最終ページの修正を確認するためだけに、前のステップをすべて入力し直す必要があった。前のステップでの入力条件によって最終ページの表示内容が変化するようなケースもあり、確認作業が非常に煩雑だった。
Storybookの導入により、特定のUIコンポーネントのみを切り出して、他の画面遷移を経ずに単体で表示・テストできるようになった。そして、修正内容がどのように改善されたかを即座に確認でき、効率的な修正が可能になった。
また、バリデーション確認も大幅に効率化された。従来は、フォーム全体を通して最後まで入力を完了しないと、各入力項目のバリデーションが正しく動作しているかを確認できなかった。Storybookでは、個々のコンポーネントごとにテストを行えるため、エラー値をあらかじめ設定しておけば、わざわざ実行時に手入力し直さなくてもバリデーションの動作確認が可能になった。
長坂氏は従来の固定的なページ遷移設計を根本から見直した。以前の実装では各ステップが固定の順序で結びつけられていたため、ページの順番をわずかに入れ替えようとするだけでも、大幅なコードの修正が必要になっていた。
これを解決するため、各ページ同士の依存関係を切り離し、案件全体の流れをデータとして定義する仕組みを導入した。これにより、ステップの順序を柔軟に変更できるようになり、構成変更への対応が格段に容易になった。
「今後も案件の設計や作成フローが変化していくことが想定されるため、構造自体をあらかじめ拡張性のある形に見直しました」と長坂氏は将来を見据えた設計思想を説明する。
さらに、作成用のコンポーネントと編集用のコンポーネントが別々になっていた問題も解決した。バリデーションライブラリとしてZodを採用し、入力値の検証が以前は統一されていなくて、項目によってバリデーションの方法が違うという問題を解消。作成と編集時で同じものが利用できるようにバリデーション方法を統一した。
全ての入力項目が統一されたフォーマットで作成される「ベースコンポーネント」の仕組みを導入し、そのルールに従って全てのコンポーネントを作っていく体制を構築した。これによってバリデーションや入力値の検証が統一され、新しいコンポーネントを増やすときも、そのフォーマットに従って追加していけばよいという形になった。
