AI時代のフロントエンド開発には、仕様書に載らない情報の言語化が重要ではないだろうか

LayerX Web Frontend Night資料

Transcript

1. © LayerX Inc. AI時代のフロントエンド開発には、仕様書に載 らない情報の⾔語化が重要ではないだろうか Jun @jude638 2025/09/24 LayerX Web Frontend Night
2. © LayerX Inc. 2 Jun @jude638 株式会社LayerX バクラク債権管理チーム所属 これまではフロントエンドエンジニアとしてスタートアップ数社を経験 ⾃⼰紹介
3. © LayerX Inc. 3 ‧今回の内容は、試⾏錯誤の過程を話すものです ‧私はClaude Codeを主に使っているので、その前提で話します ‧まだ個⼈レベルの取り組みです 🙇 前置き
4. Structured communication is the bottleneck (AIが発達するに従って)構造化された コミュニケーションがボトルネックとなる
5. © LayerX Inc. 5 Structured communication is the bottleneck ‧The New CodeというプレゼンでOpenAIのSean Grove⽒が述べた⾔葉 ‧今後、AIがコード⽣成を担うようになるにつれて、ボトルネックとなるのは、  コードを書くことではなく、開発プロセス全体を整理‧構造化すること  ‧なぜそれを作るのか？  ‧どのように仕様を決めたのか？（チームでの議論）  ‧できたものが意図した通りに動いているか？ 👉こうした「⼈間のコミュニケーションを整理して記録する」がAIとの開発では⼤事
6. 「⼈間のコミュニケーションを整理して記録」 つまり...それは仕様書？🤔
7. © LayerX Inc. 7 仕様書を作成するツールは増加中 これらのツールは「⼈間のコミュニケーション」を「仕様書」という形に整理して 記録する。 ‧Kiro ‧Spec Kit ‧cc-sdd ‧spec-workflow-mcp
8. © LayerX Inc. 8 私のチームは、仕様書‧テストが不⾜しがち ‧バクラク債権管理は2025年春にリリースされた新しいプロダクト ‧エンジニアが開発しながら仕様を決めていくので、最初の仕様書はざっくりとしか書かれ  ていない ‧仕様書が更新されないままQAに渡ってしまい、エンジニア‧QA間で認識のズレが⽣まれ  たりする。機能リリース後は更新されない ‧テストはフロントエンドはあまり書けていない 👉つまりエンジニア‧QA‧AI間での認識のズレが起こりがち
9. © LayerX Inc. 9 仕様書‧テストがちゃんとメンテナンスされれば３者間の「整理されたコミュニケー ション(Structured Communiation)」がうまくいくのでは？
10. それなら仕様書とテストを ⾃動で作れたらいいのでは？ そうすればメンテナンスもしやすい💡
11. © LayerX Inc. 11 mastraで仕様書⾃動⽣成をやってみた mastraでAIワークフローを作って、仕様書の草案とプルリクエストを元に⾃動⽣成させてみ た
12. © LayerX Inc. 12 実際のチャット画⾯
13. © LayerX Inc. 13 簡単にはいかなかった ‧仕様はそれっぽいが、網羅性もなく微妙なものが出来上がった  ‧よく分からないAIっぽい⾔葉選びや表現  ‧スクショがないので画⾯のイメージがしづらい → このままだとQAに渡せない ‧GitHubのプルリクは、開発初期のPRが⼊ってむしろノイズになってしまった ※プロンプト修正、cc-sddなどをもっと活⽤して改善できそうなことは多い
14. © LayerX Inc. 14 テストの⾃動⽣成もやってみた  Shortestという⾃然⾔語からテストを⽣成できるツールを使ってみた // 請求書一覧の最初の請求書をクリックする shortest("/invoices ページで、一覧の一番上の請求書をクリックする "); // 「請求メモ」に入力する shortest("「請求メモ」と書かれた入力欄をクリックする "); shortest("「これは請求メモです」と入力する "); //　「下書き保存」ボタンをクリックする shortest("「下書き保存」ボタンをクリックする ");
15. © LayerX Inc. 15 簡単にはいかなかった ‧テスト結果が毎回変わって不安定（１回の実⾏に30円くらいかかる） ‧アクセシビリティが間違っているところで⽌まってしまう(Locatorで取得できない) ‧結局、毎回の結果を安定させるにはPlaywrightのようなコード化が必要
16. © LayerX Inc. 16 Playwrightも書かせてみた ‧正常系の⾃動⽣成は意外とできた ‧仕様書が完璧でないので、網羅的なテストケースを作成するのが難しい ‧他の機能との複合したテストケースを考慮してくれない ‧Playwright MCPはrefの採番をしているので要素が取得できるが、普通のPlaywrightだと  それができないのでa11y対応が重要
17. ⾃動⽣成はもっと試⾏錯誤が必要そう...。 そもそも仕様書とテストが⾃動⽣成 できたらそれでOK？🤔
18. © LayerX Inc. 18 この３者間のコミュニケーションは「仕様書＋テストコード」だけ？
19. © LayerX Inc. 19 「Structured communication === 仕様書＋テストコード」ではない 仕様書とテストだけではカバーできない、開発における⼈間のコミュニケーションはたくさ ん存在する
20. © LayerX Inc. 20 仕様書でカバーできないものとは ‧仕様書でカバーできないものはフロントエンドに多い  ‧marginやpadding (例：なぜここは1remではなく2remのmargin-top？)  ‧アクセシビリティ ‧開発過程の議論  ‧なぜここのボタンは右寄せにしたのか  ‧なぜこのテーブル「メモ‧ラベル」カラムは２つに分けずに１カラムなのか  ‧当初のデザインからなぜ変更されたのか 👉 こうした仕様書やコードベースに載りにくい、でもフロントエンドエンジニアが知って  いる背景がたくさんある
21. © LayerX Inc. 21 開発過程での同僚への質問や相談も仕様書に載りにくい 「このモーダルは他のモーダルと違って、なぜ下に閉じるボタンがあるんですか？」 「この機能は別のバクラクのプロダクトと連携するから、ここだけ違うデザインにわざとし ています」
22. こうした「仕様書に載らない情報の⾔語化」 がフロントエンドでは特に重要
23. © LayerX Inc. 23 具体的にどう⾔語化するか 1. margin、paddingなどのUI ‧DOM構造なのでJestのスナップショットでAIが読める形にできる ‧詳細な単体テストを書く時間はなくても、スナップショットテストならすぐ書ける ‧実際のコードベースだと条件分岐も⼊ってくるので、できればスナップショットのような  レンダリング結果がいい   
24. © LayerX Inc. 24 具体的にどう⾔語化するか 2. アクセシビリティ ‧PlaywrightでアクセシビリティツリーのJSONを出⼒させる ‧できればDOMのスナップショットと近い場所に置く    const a11ySnapshot = await page.accessibility.snapshot(); { "role": "WebArea", "name": "ログイン", "children": [{ "role": "text", "name": "メールアドレス/ログインID" }, … ] }
25. © LayerX Inc. 25 具体的にどう⾔語化するか 3. 開発過程‧気になったことを、リポジトリ内にメモを作ってどんどん書く ‧仕様書やコード上のコメントに書くほどではないものを書く  （⾃分⽤メモに近い） ‧主に書くのはその機能に関する試⾏錯誤の過程 ‧コーディングルールはrulesなどに載せているので書く必要はない ‧メモのような、煩雑なドキュメントでOK
26. © LayerX Inc. 26 例 /z/settings/representativeSettingsPage.md これは「代表入金先設定機能」のメモである。似ているページは「◯◯設定」と「◯◯設定」ページ。 開発過程での議論: - 新規作成ボタンは他の設定ページと違って左に寄せている。その理由は◯◯ - 他の設定ページを作る場合は、このページのボタンの UIに沿わない方が良さそう メモ： - そういえばdivタグでとりあえず実装してしまったけど、 sectionタグ使うべきだった - そのうちモーダルは共通化した方がいいかも - このモーダルのFormの項目増えたら負債になりそう
27. © LayerX Inc. 27 今後はこうしたい ‧MCP化して、⾃動でClaude Codeと対話させるようにしたい ‧理想はどんな細かいメモや議論も、本来の仕様書に含めるようにしたい  ‧「⾃分⽤メモ」が存在するということは、つまり仕様書に全てを書けていない  ‧古い機能の挙動やUIに関する議論は、古いNotionの仕様書ではなく、コードの近くに   配置する ‧greptileなどのレビューツールで、他のページのスナップショットとa11yツリーを⾒た上  で⽐べてもらいたい
28. © LayerX Inc. 28 最後に ‧「うちではこうやっているよ」、「こんなやり⽅はどうか？」という⽅がいればぜひご意   ⾒ください！ ‧絶賛採⽤中なので、よかったら以下のカジュアル⾯談のリンクより話しましょう！
29. ご清聴ありがとうございました