複雑なUIコンポーネントとの ⻑い付き合い⽅：波及するバグからテスト戦略を経て、安全な再設計へ

2026/10/12開催「フロントエンドカンファレンス関西2026」の登壇資料です。「マスタ選択UI」を題材に、複雑な共通UIコンポーネントと長く付き合うための考え方を話しました。作りは複雑なままで、テストで品質を担保してくための取り組みとして「状態遷移テスト」「プロパティベーステスト」で守り、安全な再設計への指針を紹介しています。

Transcript

1. フロントエンドカンファレンス関⻄ 2026 複雑なUIコンポーネントとの ⻑い付き合い⽅ 波及するバグからテスト戦略を経て、安全な再設計へ 2026年10⽉12⽇ 株式会社ログラス｜あさマック（Masahiko Asai） 1
2. ⾃⼰紹介 あさマック / 浅井 雅彦 Masahiko Asai X: @mixplace 株式会社ログラス 技術本部 フロントエンド基盤チーム エンジニア フロントエンドエンジニアとしてWeb制作会社、ベンチャー企業2社を経て、 2021年10⽉にログラスに⼊社。UIデザインを含む、フロントエンド開発全般 を主に担当。 2024年夏からは「フロントエンド基盤チーム」を⽴ち上げ、複数の プロダクト‧機能開発チームをフロントエンド領域から⽀援する役割と、 フロントエンド基盤領域やデザインシステムといった共通資産部分の開発を 担っている。 2
6. 本⽇のテーマ 複雑なUIコンポーネントとの ⻑い付き合い⽅ 6
7. ボタン テキストフィールド 7
8. 出典: https://quilljs.com カレンダー期間選択 リッチテキストエディター 8
9. UI ライブラリを活⽤して アプリケーションを作り上げる選択もあれば
10. ⾃作する決断をすることも あるでしょう
11. そのUIが プロダクト価値の中⼼であるなら。
12. 複雑なものは、作らないほうがいい―― しかし、それでも 向き合わないといけないこともある。
13. ソフトウェアを設計するには、2通りの⽅法がある。 1つは、とてもシンプルに設計して、明らかに⽋陥がないようにすること。 もう1つは、とても複雑に設計して明らかな⽋陥がないようにすることだ。 前者の⽅がはるかに困難である。 C.A.R.ホーア“The Emperor's Old Clothes / The 1980 ACM Turing Award Lecture より引⽤ 13
14. アジェンダ 1 複雑なUIコンポーネント: マスタ選択UI 2 どのような品質改善に取り組んできたか 3 安全な再設計へ 14
15. 1 複雑なUIコンポーネント: マスタ選択UI 15
16. 複雑なUIコンポーネント: マスタ選択UI きっかけ: 対象のアイテムを選ぶ「マスタ選択UI」の作り直すことにした ‧管理会計の要である分析業務では、数字を⾒たい「部署」「科⽬」 「商品」を選ぶユースケースが多くある 営業本部, 東日本営業部, 西日本営業部, 製品… ‧プロダクトローンチ後、機能追加と改善を繰り返す中で、 類似のSelectコンポーネントが数種類乱⽴していた ‧メンテナンスコストも上がる中で、2024年秋から作り直すことに ‧既存UIではパフォーマンス限界が⾒えており、 当時1年後には顕在化が予想されていた ‧ユーザーにパフォーマンス劣化が顕在化する前に 先⼿を打って対応しようとした 16
17. 複雑なUIコンポーネント: マスタ選択UI 初期開発が完了すると数々の要望が プロダクトへの早期展開が必要に ‧旧コンポーネント利⽤箇所でのパフォーマンス低下が顕在化しつつあった。 1年後に来ると予想していたが、実際は半年後に訪れた。 ‧作り直したコンポーネントも当初は想定した性能が出ず、さらなるパフォーマンス最適化が必要であった。 特定の新機能を開発にあたり、アイテム選択仕様のカスタマイズ要件 • 標準仕様の振る舞いでは、将来の機能要件に適合しないケースも • 追加要件対応を考慮、拡張性を担保するために疎結合な内部設計に変えた 新規プロダクトからの「早く利⽤したい」という要望 • 社内パッケージ提供の期待 • 提供すべきコア機能と品質が担保できてからの⽔平展開が重要 17
18. ツリー構造という複雑性と 性能の両⽴を図る必要があった
19. 複雑なUIコンポーネント : マスタ選択UI 品質を保ち続けることが難化していく • 既存利⽤箇所の置き換えを進めていた中で、細かな不具合が発⾒される • 不具合発⽣時は、修正とポストモーテムを実施 • 機能開発では都度、テスト設計分析を経てテストの拡充を進めていた 操作はインテグレーションテスト、純ロジックはユニットテスト • それでもUIの複雑度が⾼いがゆえ、テストを拡充してもカバーできているのか⼿応えがない状況に 19
20. 複雑なUIコンポーネント : マスタ選択UI 品質を保ち続けることが難化していく • 既存利⽤箇所の置き換えを進めていた中で、細かな不具合が発⾒される • 不具合発⽣時は、修正とポストモーテムを実施 • 機能開発では都度、テスト設計分析を経てテストの拡充を進めていた 操作はインテグレーションテスト、純ロジックはユニットテスト • それでもUIの複雑度が⾼いがゆえ、テストを拡充してもカバーできているのか⼿応えがない状況に コンポーネント品質を向上しないと 全プロダクトに波及する ⼤規模障害が起きる未来が来るのでは？ 20
21. 共通 UI コンポーネントの不具合は お客様の業務を⽌めてしまう 信頼を失ってしまうことは 避けなければならない 21
22. 2 どのような品質改善に取り組んできたか 22
23. どのような品質改善に取り組んできたか • 「このUIがプロダクトにおいてなぜ⼤切なのか」を問う • 「なにをテストで守りたいのか？」を明確にする • テスト設計を⾏い、テスト網羅性を上げる 23
24. 営業本部, 東日本営業部, 西日本営業部, 製品… そもそも なぜこのUIが⼤切なのか
25. どのような品質改善に取り組んできたか このUIがなぜ⼤切なのか アイテムを選ぶ体験を通して、 経営判断に資する数字を⾒て判断している アイテムの選びやすさはもちろんのこと、 ユーザーが意図した通りに選択できていることが極めて重要 25
26. なにを守りたいのかも⾒えてくる
27. どのような品質改善に取り組んできたか 「なにをテストで守りたいのか？」明確にする 選択したアイテムと値と⼀致している チェックボックスで選択したアイテムの値は必ずセットされる。選んでいないアイテムは値がセットされない。 バックエンドで持っているデータと、UIで表⽰されている内容が⼀致していること。 ⾒た⽬がずれない チェックボックスの表⽰が正しいこと。チェックの状態と値が⾷い違わない。 勝⼿に変わらない ユーザーが選択操作をしていないのに、選択した値が勝⼿に書き換わらない。 動作が重くならない クリックでUIが反応する。ブラウザでの「ページが応答しません」が発⽣しない。 27
28. ではどうやって テストで網羅性を上げていくか
29. どのような品質改善に取り組んできたか 網羅性を上げるためのテスト技法を知る • 状態遷移テスト ‐ Nスイッチカバレッジ（0スイッチ / 1スイッチ / Nスイッチ） • プロパティベーステスト 29
30. 網羅性をどう上げていくか 状態遷移テスト • システムの「現在の状態」と「発⽣したイベント（操作や⼊⼒）」によって、 システムが「どのように別の状態へ変わるか」を検証するテスト技法。 • ユーザーの操作順序や時間の経過によって動作が変わるシステムのテストに⽤いられる • 状態遷移テストを作成する際は、モデル化するために図と表を作成するのが⼀般的 ‐ 状態遷移図 ‐ 状態遷移表 30
31. 網羅性をどう上げていくか 状態遷移図 選択状態：なし 選択状態：⻄⽇本営業部 選択 西日本営業部 ポップアップ 1 閉じている 4 表⽰：なし 開く 適⽤ ポップアップ 2 ポップアップ 表⽰：⻄⽇本営業部 適⽤ 選択 開いている チェック：なし 閉じている ポップアップ 3 クリア 開いている チェック：⻄⽇本営業部 ⼀例: 「開く → ⻄⽇本営業部を選ぶ/クリア → 適⽤」という遷移シナリオ 31
32. 網羅性をどう上げていくか 状態遷移表 今の状態 ＼ 操作 ポップアップ： 1 閉じている 表⽰：なし ポップアップ： 2 開いている チェック：なし ポップアップ： 3 4 開いている チェック：⻄⽇本営業部 ポップアップ： 閉じている 表⽰：⻄⽇本営業部 開く 2 ⻄⽇本営業部を ⻄⽇本営業部を クリア 適⽤ — — — 選択 ⻘枠 部分 状態遷移図の⽮印通りに — 3 — 1 — — 2 4 動くか 灰⾊枠「—」 部分 起きないはずのことが 3 — — — 起きないか 32
33. どのような品質改善に取り組んできたか 0スイッチ‧1スイッチ‧Nスイッチ カバレッジ • 状態遷移テストにおける「網羅の深さ（カバレッジ基準）」を定義するための技法。 「状態の移り変わりを、何回続けて辿ったか」でテストの網羅度を測る。 • 連続して起こるイベントのパターンを一定の深さ（N回の切り替え）まで網羅的にテストすることで、思わ ぬ組み合わせで発生する不具合を検出しやすくなる。 ‐ 0 スイッチ: 状態Aから状態Bへ 1回の操作で移る状態遷移 ‐ 1 スイッチ: 状態Aから状態Bへ 2回の操作で移る状態遷移 ‐ N スイッチ: 状態Aから状態Bへ N回の操作で移る状態遷移 • Nが1増えるごとに、パターン数が指数関数的に増えるため、適切に絞ることが必要。 33
34. 網羅性をどう上げていくか 状態遷移図 選択状態：なし 選択状態：⻄⽇本営業部 選択 西日本営業部 ポップアップ 1 閉じている 4 表⽰：なし 開く 適⽤ ポップアップ 2 ポップアップ 表⽰：⻄⽇本営業部 適⽤ 選択 開いている チェック：なし 閉じている ポップアップ 3 クリア 開いている チェック：⻄⽇本営業部 ⼀例: 「開く → ⻄⽇本営業部を選ぶ/クリア → 適⽤」という遷移シナリオ 34
35. 複雑なUIコンポーネント: マスタ選択UI 営業本部, 東日本営業部 , 西日本営業部 , 製品… UI上でできる操作が多い • メニューを開く / 閉じる • アイテムの選択 / クリア ◦ 末端アイテムの選択 / クリア ◦ 親アイテムの選択 / クリア • ▼ トグルを開く / 閉じる • すべて選択 / すべてクリア • 検索による絞り込み / 絞り込み解除 • 適⽤ / キャンセル ボタン 35
36. どのような品質改善に取り組んできたか プロパティベーステスト ⾃動⽣成した多様な⼊⼒データを⽤いてその性質（ルール）が 常に成り⽴つかを検証するテスト⼿法。 • 短いコードで膨⼤なテストケースを検証できる • テストケースが⾃動⽣成されるため、想定外のエッジケースをテストできる • TypeScript なら fast-check というライブラリが著名 • テストが失敗した場合、⼿数を少なくしても失敗するかを調査してくれる（Shrinking） 36
37. どのような品質改善に取り組んできたか プロパティベーステスト 例1 トグルの開閉操作を加えても 値は変わらないこと 操作をランダムに複数回操作 例2 何もせず適⽤をクリック しても値は変わらないこと アイテム 選択 適⽤ アイテム 選択 適⽤ 操作をランダムに複数回操作 選択値A ▸ 開閉 ▸ 開閉 選択値B 選択値 A ポップアップ 開き直す 何もせず適⽤ 選択値 B 選択値A と 選択値B は 同じかどうかをテストできる 37
38. どのような品質改善に取り組んできたか ユースケースを明確にし、⾜りていないギャップを⾒つける ⼊⼒ マスタデータ 選択設定値 UI上の操作 出⼒ 選択設定値 UI上での操作一例 連続した操作とその結果に対して テストケースの拡充が必要だった 38
39. どのような品質改善に取り組んできたか やってみてどうだったか • 0スイッチ‧1スイッチ（2回操作）は全パターン実施 ‐ ポップオーバー内でできる操作が多いため。2回操作が正しく動作することは担保 • Nスイッチは7スイッチ（8つの操作）まで担保 ‐ 3スイッチ⽬から未発⾒の不具合を数件⾒つけることができた ‐ どのプロダクトでも使われていないが、将来顕在化し得るものもあった ‐ → 隠れた因⼦、隠れた⽔準が⾒つかった • どのスイッチでテストが失敗するかわかることで、不具合の原因特定もしやすくなった ‐ 問題箇所がわかることで、影響範囲と解決の道筋がつきやすくなった 39
40. どのような品質改善に取り組んできたか やってみてどうだったか デメリットもある • テスト実⾏時間は⻑くなる ‐ スイッチ数を増やすことで指数関数的に増える ‐ 意味のあるテストパターンで削っていくことが必要不可⽋ 40
41. 3 安全な再設計へ 41
42. 複雑なUIも インテグレーションテストの拡充から 品質を守ることができてきた
43. 複雑なUIに この先どう向き合っていくか
44. 安全な再設計へ 再設計の道筋 • 機能を減らす • アーキテクチャの根本的な変更 44
45. 安全な再設計へ 再設計の道筋：機能を減らす • 使われていない機能は⾮推奨にして消していく • 機能が減って複雑さが 1つでも減らせるなら取り組むべき 45
46. 安全な再設計へ 機能を減らす：各プロダクトの利⽤状況を把握 ts-morph の静的解析を活⽤したコンポーネント利⽤箇所調査 • 全プロダクトのコードベースから 「各UI」がどのように使われているか、コード解析できるようにした • コンポーネントで利⽤の少ない機能を明らかにでき、今後の改善判断にも使える • 調査が必要になった際、プロダクト影響範囲の把握が容易になる 46
47. 安全な再設計へ 機能を減らす：ユーザーの便益も考える必要がある • ⼀度リリースしたUIの変更‧削除は、業務アプリケーションでは困難が伴う ‐ PdMやデザイナー‧エンジニアと課題と解決策を握る必要がある • 使い慣れている操作を変えることになるので、移⾏計画が必要 （事前にアナウンス、⼀定期間まで新旧併⽤できるようにする等） 47
48. 安全な再設計へ アーキテクチャの根本的な変更 • 相応なリソースが必要であり、 フロントエンドだけに留まる話ではないことが多い • デザイナー/エンジニア/PdM/との対話しながら合意形成を図ることになる • 今の UI をいつまでメンテナンスしていくのか。 投資であり数年単位の計画作りが必要 48
49. まとめ 49
50. まとめ • プロダクト価値の中⼼となるUIならば、⻑く付き合う覚悟を持つ • “UIのプロダクト価値はなにか” “なにを守りたいのか”を明確する • 最適なテスト設計技法を選ぶ ◦ 隠れ因⼦‧隠れ⽔準があるか探索してみる ◦ UIの状態変化を調べるために「状態遷移テスト」「プロパティベーステスト」は有⽤だった ◦ テスト網羅性が上げて、⻑く付き合っていける状態に持っていく • 将来の再設計に向けて計画する ◦ 多くのステークホルダーとの対話が必要であり、戦略と計画を描く必要がある 50
51. プロダクト価値の中⼼であるUIは、製品である もはやフロントエンドに限った話ではない
52. 複雑なものは、作らないほうがいい――
53. しかし 複雑になっても 向き合うべき時がある。
54. そのUIが プロダクト価値の中⼼であるなら。
55. Frontend, Unbounded. フロントエンドは、みんなの話やで。
56. ご清聴 ありがとうございました 56