サイボウズフロントエンドの横断活動から考える AI時代にできること

2025/08/20 すごくすごい。フロントエンドミートアップ
https://formx.connpass.com/event/364158/

Transcript

1. サイボウズフロントエンドの横断活動から考える AI時代にできること 2025/8/20 - すごくすごい。フロントエンドミートアップ @mugi_uno
2. 麦島 一 / mugi / @mugi_uno サイボウズ株式会社 kintone フロントエンドイネイブリング
3. kintoneの開発体制とフロントエンドについて
4. kintone - 領域ごとにチームが分かれている チームごとに裁量を持った開発 1チームは EM・PG・デザイナー・QA などの少人数で構成される kintoneエンジニアリングマネージャー業務紹介 - https://www.docswell.com/s/cybozu-tech/ZMX8X8-kintone-engineering-manager#p6
5. フロントエンドの分割と横断的な課題の発生 刷新をきっかけにフロントエンドエンジニアは 0人 → 15人以上に 横断的な課題も多く発生するようになった 「フロントエンドイネイブリングチーム」が発足し、 横断での支援・課題解決に取り組んでいる https://blog.cybozu.io/entry/2022/02/04/171154
6. 一方そのころ
7. 気づけば誰しもがAIの話をしている ZennのトレンドもAIだらけやで…!!!
8. もちろん弊社も例外ではない 🔗 サイボウズで利用可能な AI コーディングツールの紹介 - https://blog.cybozu.io/entry/2025/07/17/170000
9. 便利な半面、ふと頭をよぎる疑問
10. 「我々の仕事ってなくなるのでは…？」
11. 今回話すこと サイボウズでのこれまでの取り組みを踏まえて、 私たち（特にシニアっぽいフロントエンドエンジニア）は AI時代に一体何ができるのか/何をやるべきなのかを考えてみる 複雑GUI・アーキテクチャ設計の話はしません。ほんとすいません
12. そもそもシニアに求められることって何だろう？
13. 「領域・チームを超えて、横断した課題を解決に導く」 （実際には多岐にわたるが、ひとつの例）
14. AI活用と領域・責務の分割 現時点では、ツール問わずコンテキストウィンドウのサイズが制限となる （Claude Code で compact が走ると一気にクオリティが落ち始めたり） プロンプトエンジニアリングでタスクを細分化する余地はあるが、 そもそも最初から対象領域が狭いほうが効率や精度が良い 組織・チームの構造を考える際、これらも考慮事項となってくる FYI: 逆コンウェイの法則
15. チーム分割の光と闇
16. チーム分割によって得られる恩恵 オーナーシップ・責任感が生まれやすい チーム構造と管理対象コードが一致すると認知負荷（Team Cognitive Load）も低減する FYI: Team Topologies 理解コストが低減し、個々の意思決定も速くなる 先述の通り、AIツール観点でも把握すべきコンテキストが小さくなる
17. 新たに生じる課題 チームの外を意識しないと気付けない課題が発生し始める 「まずはチーム内で解決しよう」という考えが働きやすい 正解かもしれないし、実はチーム外を巻き込むべきポイントかもしれない じわじわ見えない課題が膨らんでいき、気づけば大きな負債になる可能性がある 現状ではAIでこれらを発見するのは難しい
18. e.g. kintoneでの課題事例 - グローバルスタイル
19. 統一的なグローバルスタイルのルールがない 各チームが、それぞれでグローバルスタイル(CSS)を持っている kintone 開発のサブチームは基本的に画面によって異なるため、 各チーム内からの視点では、これによる問題意識は湧きづらい
20. e.g. 気づけば増殖していたグローバルスタイル関連のコンポーネント
21. 🆕 「多くの画面に共通UIパーツを伴う新機能を導入したい」
22. 共通パーツを作成するチームに、みんなのグローバルスタイルが牙を剥く！ そもそも、どのスタイルの存在を前提としてパーツを作れば良いのか 画面によってスタイルが微妙にズレたり ある画面だけ全然スタイルが適用されなかったり そしてやむなく付与される !important
23. そのほかの課題や相談の例 技術選定 e.g. 「Web Components 使ってみようと思うんですが、どう思います？」 ドキュメントの整備 e.g. 「チーム内と開発全体で使うドキュメントの違いって何？」 テストポリシー e.g. 「どのテストで何をどこまで担保するべき？」
24. これらの課題はAIがあれば各チームで解決できるか？
25. 実作業なら任せられそう 共通部位の抽出、ライブラリ化、テストの追加… 意思決定が必要な類なものは、AIには相談することしかできない AIに指示を出せば修正できるとしても、そもそも誰がその指示を出すのか 作業結果が「妥当か？」の判断は誰がやるのか 作業が終わったあとのことを考えるのも人間の仕事になる メンテナンスはどうする？オーナーは誰？など
26. 「AIに作業は任せられるが、人間が責任を取る必要がある」 横断対応は影響範囲も広がるため、サブチーム内だけでの判断は難しい 関わる人数も増え、一気にコストが高くなる もろもろ踏まえると、「コレやったほうがよさそうだけど…」と 思ってる人はいるが、誰も動けない、という状態になる。
27. 横断的な課題に対して何ができるか？
28. 「課題の抽出」 「整理・優先順位付け」 「意思決定」 チームや組織を横断した課題を抽出し言語化する コードベースから見えないものを見つける チーム内でうっすら問題意識を感じているケースもある。それを拾う 課題を整理し、本質的な問題が何なのかを探る 全体を見たときに、何からやるべきか？といった優先順位の判断 実際にやるぞ！という決定および推進（完了後の体制も含め）
29. サイボウズでの取り組みの例
30. ヒアリングや観測から課題感を抽出 EM・フロントエンドエンジニア全員にヒアリングを実施 泥臭い動きだが大事 「技術選定で迷う」 「他チームに助けを求められていない」といった課題感 先に挙げた、グローバルスタイルへの問題意識も聞こえてくる 全チームのコードやドキュメントを確認し、目に見える課題も調査
31. 集めた情報をもとに課題を整理 チームに技術的な裁量があったが自由すぎて逆に迷う状態にあった すべてが自由 = すべてを決めないといけない e.g. 「TypeScript を使うべきか？」に意思決定が必要 「他チームも必ず使ってるもの」も曖昧 潜在的にリスクの高い決断をする可能性がある
32. 実際のアクション → 「フロントエンド技術標準」の策定
33. なぜ技術標準？ 多くの課題に「ベースになる指針がない」という前提があった 全チームが遵守すべきことを言語化し、意思決定の支柱・ガードレールとして機能させる チームを俯瞰して見て、どこが「共通」かの線引はいまのところ人間の仕事 共通の線引をしておくことで、AI活用を踏まえた際も、 ドキュメントやプロンプトをチームを跨いで活用する余地が生まれる
34. ここまでを踏まえ「AI活用」の文脈では何ができる？ （弊社もまだやれてないことも多分に含みます）
35. 大前提 - 自らも率先して試す 「落ち着くまで様子見」はマズいと思う 色々なところで言われてるが、実際に手を動かして触ってみるのが大事 「こうすれば上手くいくな」 「これは工夫しないと上手くいかないな」を体験しておく それが無い状態で、活用のために必要なことの判断は難しい
36. フロントエンドの知見も引き続き必要 Webフロントエンドは動作環境が強制的に変化し、モダンな仕様も増えていく LLMの性質上、情報が多いものからコードが生成される Widely Available になりたての機能などは活用してくれない可能性が高い こちらが知識を持って明確に指示する必要がある 従来通りのスキルアップのための努力も不要になるわけではない e.g. Claude Opus 4.1 でも <dialog> を使ってくれない様子
37. AIツールを活用しやすい土台の整備 代表例はドキュメントの整備 チーム複数ある場合、それぞれが同じ課題感を持つ 似たようなドキュメントが量産される可能性がある ドキュメントの書き方を言語化しておく どこに書くか・何を残すべきか・どういう書き方だと機能しやすいか テンプレートを用意するのもよい 「チーム問わず必須になる知識」を共通ドキュメントとして整備する AIによってコードが量産される際に、全体の品質の底上げになる
38. そもそも活用度合いを高めるために動く チームでAIツールが利用可能でも、活用度合いには個人差がある e.g. Tab補完でのみ使っている e.g. 単純作業のときに任せている e.g. Claude Code の Rate Limit に苦しむレベルで酷使してる 「AIを活用していこう」という意識を高めるために動く必要がある 率先した情報発信 知見共有の場を整える ペアプロ・モブプロ
39. まとめ AIの活用でチーム内の生産性は高まるが、 「人」や「チーム」が絡む部分には課題は残される 課題を見つけるためには泥臭い動きも必要になるし、 実際に何をすべきか？の判断は我々が行う必要がある とはいえスキルを蔑ろにもできない （やること増えて、以前より大変になってない？？）
40. 採用のための温かみある外部発信も人類に残された仕事です！
41. We are hiring !! https://cybozu.co.jp/recruit/