フロントエンドエキスパートチームの解散は 「いい話」なのか？

2025-12-19 Node学園47時限目

Transcript

1. フロントエンドエキスパートチームの解散は 「いい話」なのか？ 2025-12-19 Node学園47時限 目 mugi / Cybozu Inc.
2. @mugi_uno mugi / Hajime Mugishima Cybozu Inc. FEE Team
3. はじめに
4. YAPCで落ちたプロポーザルを拾って頂いた
5. 本トークにおける注意点 • 技術の話はありません • 組織・チーム・ 人 の話です • チームを供養させてください
6. 序章 Frontend Expert Team について
7. Frontend Expert Team (以後 "FEE") • 2017年10 月 にチームが発 足 。最初は 一 名 • 当時、社内にフロントエンド専 門 のメンバーはいなかった • フロントエンドを 片手 間でやるのが困難に • 役割の増加 • エコシステムの複雑化 • etc.. • 専 門 性を持って探求・ 支 援を 行 うチームが必要という問題意識
8. 過去の社内向けの資料から抜粋した図
9. その後、FEEが掲げたミッション
10. FEE活動における健全性 • 支 援50%・探求30%・発信/啓蒙20% を理想とした • 「健全性」と称して活動割合を週次で共有
11. 活動を続けた結果… • 「サイボウズのフロントエンドエキスパート」に 一 定の知名度 • フロントエンドに強いメンバーが増えた（15名以上に） • 支 援/探求/発信活動をFEE以外も積極的に 行 うように
12. 過去の社内向けの資料から抜粋した図 （※現在は少し異なります）
13. チーム創設当初の課題感の 一 部が解消された • FEEが担っていたことをFEE以外でもできるようになった • 当初の課題の 一 部は解決されたとも 言 える • チームとしては 一 定の役 目 を終えた
14. 「 目 標を達成しての解散なわけですね！！」
15. 「ある意味、いい話ですね！」
16. 「本当に？」
17. 現場からすると「それだけじゃない」 • 自分たちのチームを無くすまでに多くの葛藤があった • 横断支援チームの立ち回りの難しさ、 環境の変化に伴う自分たちの存在意義の喪失..など • 楽しい本編はここからだ！！！
18. 第一章 横断支援チームのジレンマと アイデンティティの喪失
19. プロダクト外からの支援は障壁が多い • 受け身で何かを変化させるのは難しい • 「FEEっているけど、何してもらえるかわからん」 • 「エキスパート怖そう。変な相談したら怒られそう…」 • そもそも「相談しよう」という発想に至らないことも多い • ヒアリングしてみたら「実は…」というケースがあったり
20. とはいえ"何でも屋"ではない • プロダクトチームの開発タスク消化をするのはちょっと違う • 社内外注？ • 各チームが自分たちでやれるために手伝う、あるいは 技術的に難易度の高い部分のサポートを役割としたい • これを表に強く出すと 「えっ、やっぱエキスパートチーム怖…」となる
21. 能動的な支援が多くなる • 外野から意見を伝えるだけだと影響は限定的 • 信用貯金が必要 / 理想の押し付けになる • そもそも現場は作業工数が足りない • フロントエンドスキル不足からスピードも出ない • 結果、内部に深く入って伴走、あるいはリードするケースが多い
22. kintoneフロントエンド刷新への介入 • FEEは「プロダクトに依存しない支援チーム」だが、 事業貢献も必要でしょ…という議論も出やすい • 会社にとってはkintoneの重要度は高い • そして50万行を超えるレガシーコードが含まれる • ここから目を背けて「最高にする」って何？という話になる • 刷新プロジェクトが発足 → 深く入り込んでの支援 • 効果が出ている。前進してる実感もある。だが…
23. 俺達ってどこのチームの人だっけ？ • 健全性が失われる • 支援8-9割が基本に • しかも長期に渡って続く • 俺達はどこのチームの人？ • これでいいんだっけ？ 当時の健全性のデータ
24. 人数がいれば緩和されるが… • メンバーが多ければ 「人によっては支援に集中している」というだけで済む話 • ただ、エキスパートの採用は非常に難しい
25. 健全性を取り戻したい • FEEとして支援90%とかは良くない、という認識があった • 社内情報共有会 Frontend Weekly や、 YouTube, Podcast などの外部発信は続けていた • 探求から繋がる活動を増やしたい… • どうする？
26. やったこと: 気合で増やした • 同期的にテーマを決めて探求会の開催 • "探求共有会"で毎週の探求成果発表をチーム内で必須に (俺達は義務でもいいでしょ、という全員の合意のもと） • いま冷静に考えると、これはこれで全然健全じゃない 物騒な名前のMTGたち
27. フロントエンドエンジニアが増えた • イベントや採用活動の中で「見てます」といった声を聞くように • 実際に採用に繋がるようになった • 「よかった、支援以外でFEEっぽいことやれてるかもしれない」
28. FEEと同じ活動をするメンバーが増加 • 序章で触れた通り、探求/発信活動を 多くのメンバーが積極的に行うようになった • またそれを見た人が増えて…という良い循環ができた
29. 「あれ、俺達との違いって何？」 • FEEメンバーはかなりの比重で支援活動をしている • FEE以外のメンバーも従来のFEE相当の探求・発信をしている • 同じ姿をしている……？？
30. 第二章 "エキスパート" の呪い
31. "エキスパート" って何？ • 前述の状況から、そもそも "フロントエンドエキスパート" とは何なのか、 我々の活動はこれでいいのか、という議論が頻発 永遠に悩んでいる人々の議事録
32. FEEチームのメンバー変遷 • 創設時は１名 • 最大７名ほどにまで増える • キャリアチェンジなど、様々な事情でFEEは徐々に減る • 一方でフロントエンドエンジニアは順調に増える • 最終期は3名にまで減る
33. 過去のメンバーの亡霊 • 去ったメンバー達の亡霊を追ってしまう • 実際すごい人が多かった • 俺達はそれと比べてどうなんだ？という問答が生まれ始める 亡霊を追う様子 nus3が自ら登録した議題
34. じゃあ何もできていなかった？ • そんなことはなく、実際のところ 支援活動の中でフロントエンドのリードはできている • 登壇や執筆もやれてるし、採用にも貢献してる気がする… • でも、この姿が俺達の目指した姿なんだっけ？
35. "エキスパート"の呪いと中年クライシス • 定義が曖昧な "エキスパート" という言葉に囚われ続ける • 「それってただの中年クライシスじゃない？」という ストレートなアドバイスを受けて 「知ってたけど俺達は中年だったのか…」と傷つく
36. 第三章 再定義の試行と解散
37. エキスパートチームの再定義を試みる • 従来の活動ではFEEとFEE以外の境界が曖昧になった • 改めて「エキスパートチームの役割とは？」という議論をした
38. "支援"を関わり方によって区別 • 🎯 フォーカス支援 • 深く入り込み、進捗やスケジュールにも責任を持つ • 場合によってはプロダクトオーナーやテックリードも兼ねる • 🗺 スポット支援 • FEEが主導権を持ち外部から働きかけるもの • ヒアリングや、技術動向の調査・PRでの反映など • どういうスタンスか？を明確にして支援先と期待値を揃える
39. サイクルと循環 • 探求/発信/啓蒙は、いまやFEEだけのものではない • 組織とフロントエンドエンジニアの活動には関連と循環がある • これを回すよう働きかけるのがFEEの役割では？という仮説
40. https://speakerdeck.com/cybozuinsideout/frontendexpert-team?slide=8
41. が、思うように活動ができない状態が続く • 再定義した内容は腑に落ちていて、間違ってなさそう • ただ、それを主軸に活動するには人数と時間が足りない • 理想は描けているが今の支援も重要で放り出せない状況 • 結果、"フォーカス支援" から抜け出せない状態が続く… • 「フロントエンドエンジニア」の採用は順調だが、 「フロントエンドエキスパート」の採用は相変わらず難航
42. 逆にFEEの存在が枷になる部分も • そもそも誰かがリードせずともやれる人がたくさんいるはず • FEEがいなくてもやっていくぞ！という状態が FEEの理想でもある • 枠を超えたトライをするにも 「FEEがいるからな…」「FEEが◦◦やってるしな…」 という発想になりやすい
43. 解散へ • このままだと状況は変わらないだろう…という結論に • As-Isに併せた形にチーム体制を見直したい • FEE以外が主体的に活躍できるステージに進みたい • このまま惰性でチームを続けるのも メンバーの心情的にもよくない • チームとしては解散へ
44. 解散にあたり発生した議論 • 「フロントエンドエキスパート」という名称を残すか • 残したとして、誰がそれを名乗る？ • 名乗るためには条件/基準はいらないのか？ • 自称でいいのか？評価には結びつかないのか？ • 結局のところ「エキスパートとは何か」の議論に戻ってしまう • 実は外部発信はすでにFEEとは切り離していたので、 そこまで名前に固執する理由は無かった
45. 終章 Look Back FEE
46. 結局、FEEのメンバーはどうなったの？
47. kintone Frontend Enabling Team • 元々の 支 援でかなりの 比 重を占めていた形を引き継ぎ、 kintone Frontend Enabling Team として再始動 • kintone にフォーカスした形でのフロントエンド 支 援チーム • プロダクト内に正式に位置づけられたことで、 相談も 目 に 見 えて増え、踏み込んだ議論がしやすくなっている • マネージャー視点でも、技術課題を移譲できる先が出来たので、 関 心 事を分離して考えやすくなったらしい
48. @mugi_uno mugi / Hajime Mugishima Cybozu Inc. FEE Team kintone FrontEnd Enabling
49. いや〜、よかったよかった
50. メンバー個々 人 の悩みも 全部解決したということですね！
51. そうだったらいいのにな • 開発本部長を巻き込んで相談しても解決はしなかった • 個々人の思う「エキスパート」のイメージが違っていて、 そことの比較での納得感が必要。各々で消化するしかない • ただ、一旦看板を降ろしたことで、少し安堵した気持ちもある • と同時に、まだ何かやれたのでは…という気持ちも消えない • 中年は終わらない
52. ただ、改めて冷静に思い返して…
53. 解散時にいた我々は 果たして何もできなかったのか？
54. 我々の後にも少しは 足 跡が残っている（…はず） • FEE創世記のメンバーが作った 文 化を維持・発展させてきた • Zenn Publication, Podcast などは新しく 生 み出したフィールド • プロダクトチームの内部に踏み込んだ 支 援による効果も挙げられた • 登壇/執筆なども(気合で)続けて、道を切り開くことはできたと思う • 「続ける」のはそれだけでもエネルギーが必要なこと
55. 時間がかかることを効果が出るまで続けてきた • 「 文 化を創る」「採 用 に繋げる」のは時間がかかる • 探求共有会/Podcastなどの効果を感じ始めたのは１年後とか • FEE以外の発信が増えたのは 人 が増えてからなのでもっと先 • Frontend Weekly なども、最初はFEEだけでやっていたが、 今ではFEEがいなくてもトピックがたくさん集まるように
56. 最後に
57. 結局「フロントエンドエキスパート」とは何だったのか？
58. 「エキスパート」の定義は 非 常に曖昧 • 個 人 ・組織の状況に応じた相対的なものでしかない • 社内で技術的にリードして意思決定できればいい？ • 登壇・執筆をバリバリやっていればいい？ • 著名なOSSをメンテナンスしていればいい？ • 自 信を持てていればそれでいい？ • サイボウズFEEでは創設時点からすでに悩んでいた記録がある
59. 今から創設時の状況を考えてみると • 当時のサイボウズの状況において思い描かれた 「フロントエンドで◦◦ができる 人 がいれば…」 というラインがあった • ◦◦に暗黙的に 支 援・探求・発信/啓蒙 が含まれており そこに "フロントエンドエキスパート" という名前が与えられた • そして現在、全体がそのラインに達しつつある、 というのが単純な答えなのかもしれない • こういった定義での "エキスパート" は、 組織のフェーズにおいては需要があり役 目 も多い
60. 反省点 • "エキスパート" に求められるラインがあるとすれば チームの活動も「どこで終わりなのか？」も定めてもよかった • 「サイボウズのフロントエンドを最 高 にする」は ポリシー/マインドセットとしては 非 常に良かったが、 もっと具体的なゴールラインを置くべきだった
61. そして現在 • 全体が当初思い描いたラインに達したなら、 さらに上のラインの定義が必要なのかもしれない • 元FEEのメンバーが 目 指すべきはそこかもしれない
63. 我々は永遠に "エキスパート" を追いかける…