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