サイボウズフロントエンドの活動から考える探究と発信

2026-03-13 株式会社カケハシ様向け 社内講演での資料です

Transcript

1. サイボウズフロントエンドの活動から考える探究と発信 2026/3/13 @mugi_uno
2. Hajime Mugishima / @mugi_uno サイボウズ株式会社 kintone フロントエンドイネイブリング
3. 発信、やってますか？
4. 🔍️ カケハシ ブログ
5. ブログ・登壇、ちゃんとやっててすごい 🎉 （今日話すことあるのか…？）
6. (ちなみに…) サイボウズ フロントエンド関連での探究・発信活動の例
7. Cybozu Inside Out サイボウズエンジニア全体でのブログ
8. Zenn チームによって Zenn Publication で記事を公開
9. Note 主にデザイナーが中心となって公開
10. (社内) Frontend Weekly 社内での毎週開いているフロントエンドの情報共有会 #frontend-topic チャンネルに自由に投げられたトピックを１時間でみんなで共有
11. YouTube / Cybozu Frontend Monthly その月に話題になったフロントエンドトピックについての雑談を公開
12. PodCast / サイボウズフロントエンド通信 サイボウズでの取り組みをテーマにした PodCast 技術よりは、組織や人にフォーカスした内容になっている
13. 技術記事の寄稿 社外メディアからの依頼を受けて会社名義で技術記事の寄稿 直近では web.dev・gihyo.jp など
14. CYBOZU SUMMER BLOG FES チーム横断で短期間で行うブログリレーイベント
15. カンファレンス・イベントでの登壇 多くのメンバーが多種多少なイベント・カンファレンスで登壇しています
16. スポンサーブースでの交流 最近は「話す」だけに特化したブースにしています JSConf JP Burikaigi
17. （めっちゃ色々やってた…）
18. そもそも、なぜ発信をする？ 🤔 Thinking Time ⏱️
19. 何を思いついたでしょうか 自身の学びの確認のため 会社のプレゼンス向上、知ってもらうため 採用に繋げるための第一歩 コミュニケーションのきっかけになる 個々人のブランディングのため 技術コミュニティへの貢献のため 転職時に役に立つから 評価に繋がって給料が上がるから 単純に楽しいから …
20. 自分たちにとって何が正解？ 個人と組織でも違う 意識を揃えるのって難しくない？
21. 「探究・発信のサイクル」という考え方
22. e.g. サイボウズ内で共有した「探究・発信のサイクルイメージ」
23. つまり、発信活動によって… 個人の学習→発信→自信→さらに探究…、の循環ができる スコープが広がり、組織としても同様に循環する
24. 自分のための発信は結果的に組織のためになる 組織のための発信も結果的に自分のためになる
25. お得！！ 〜 Win-Win 〜
26. サイボウズフロントエンドでどうやって探究・発信を実現しているか？
27. ⚠️ 注意点 完全な再現性は無い可能性があります 「ここは真似できそう」みたいなところを見つけて貰えるとありがたい
28. 昔はあんまり活発じゃなかった 左の図は 2018年〜2019年の Cybozu Inside Out における フロントエンド関連の記事 3本しかない 2017年以前だとほぼ皆無になる ブログ自体は2009年からある kintone(フロントエンドをフル活用)は 2011年から提供している
29. 転機 / Frontend Expert Team の発足 2017年に社内にFrontend Expert Team が発足 支援に限らず、探究・発信も活動の主軸に置いていた 探究・発信が好きという人たちがメンバーだった そして、色々と活動を始める Frontend Weekly (社内勉強会) Frontend Monthly (YouTube) 登壇活動 スポンサー＆ブース提供 など…
30. 徐々に同じ活動をするメンバーが増えた 最初は Frontend Expert Team だけの活動という感じだったが… 社内勉強会に、チーム外のメンバーも参加するようになる 採用活動の中で「発信を見た」というケースが増えてくる 実際に入社し、同じような活動をするメンバーが増えていく 先に紹介したような多くの取り組みに繋がっていった
31. Frontend Expert Team の活動を振り返ってのポイント 1.「小さくはじめて」 2.「とにかく続ける」
32. 小さくはじめる どの活動も最初は小さいところから Zenn Publication 最初は Frontend Expert Team メンバーだけでやっていた YouTube / Frontend Monthly 回数を重ねてから、他チームや社外ゲストを招くように 登壇 CFPを一緒に考える会、などを開催するように スポンサーブース 最初は Frontend Expert Team メンバーだけが立ってた いまはフロントエンドエンジニア全員で取り組んでいる
33. とにかく続ける 効果が出るまでは時間がかかる 新しい取り組みをはじめて、何らかの効果を感じるまでは時間がかかる 採用などを想定した場合は１年後とか２年後を想定したほうがよい 長く続けられるような工夫が必要になる 小さい形にしておくのも続ける工夫のひとつ それでも続けるのは大変、なぜか…
34. コスパのよい形を考える 続かない大きな理由は 「コストに見合わない」 から やり方を見直してコストを下げるのも大事 e.g. YouTube / Frontend Monthly すべてライブ配信 → 事前収録での配信中心に変更 スケジュール調整が容易になり、問題があっても編集でカットできるという安心感 e.g. スポンサーブース対応 入念な準備が必要なブース企画を実施していた (e.g. クイズコンテンツを用意し、限定のノベルティを配布など) エンジニアがブースに立ち「好きなトピックで話せる」というブースに変更 事前準備はかなり小さくなり、参加者との交流も深くなりやすくなった
35. 続けてるうちに「二人目に踊るやつ」が現れる
36. ここまでが発信の話
37. 「探究」は？
38. サイボウズにおける「探究」 「推奨はされるが強制もない」 Frontend Expert Team のみは、活動全体の2割を充てるのを健全としていた 業務に関連するかは必須ではないが、組織にとってプラスか、をうっすら意識 それ以外は、基本的に各チーム・個人に委ねられている 業務のうち週N時間を使う、みたいな話もたまに聞く
39. 興味のあるもの・楽しいものを掘り下げているだけ Frontend Expert Team の人たちは、そもそも探究活動が好きな人たちだった 誰に言われるでもなく、好きで休日にやってるような ただ、各々で関心の強い領域について探究し、それ自体を楽しんでいた そこから生まれた発信に呼応して、似た思想のメンバーが増えていった そもそも個人の探究活動の手綱を組織が握るのは難しい どこから給料が発生するんですか、という話になる
40. 発信とセットにして考えてみる ただ探究しろ、と言われても難しいはず 先に挙げた、何らかの発信をゴールとして探究してみると良い サイボウズでも発信駆動での探究は珍しくない e.g. ブログフェスがあるのでこの機会に◯◯について調べてみた、など
41. 探究・発信の両方で言えること
42. 先にやってる人はフォローしてあげてほしい 興味はあるけどやれてない、という人も結構いたりする やり方を教えてあげたり、背中を押してあげるといい e.g.サイボウズで実際に実施されたこと ブログネタのアウトラインを一緒に書く そもそもブログネタを一緒に考える カンファレンスCFPを考える会の開催 YouTubeにチーム外のメンバーを招待 なお、 「◯◯さん、これをやってみません？」のように名指しがオススメ 「誰かやりません？」だと手が挙がりにくい
43. 機会自体を創出する 発信については、組織視点では「場そのものを作る」のも重要 サイボウズがスポンサーする大きな理由の一つ スポンサーセッション枠を、登壇経験として使ってもらう 明確に仕事としてやれるので、背中を押しやすいし、本人も時間を使いやすい イベントを企画し開くのもあり サイボウズでは「BARフロントえんどう」というイベントを企画・開催した (カケハ シからも @nkgrnkgr さんにご登壇いただきました) 「登壇して」というのは簡単だけど、登壇しやすい場を作る努力はできているか？
44. もう少し現実的な話
45. そうは言ってもですね… 現実的には難しいところもたくさんある 「自分には難しい気がする」 「〜が理由でできなさそう」 「効果が出るのか…？」 その気持ちもわかるので、 よくあるお悩みと対策を考える
46. 「発信するネタがない」
47. 本当に？ "１日８時間働いていて、何もネタがないわけがない" @koicさんのスライド「私のスライド作成術」より https://speakerdeck.com/koic/without-practice-no-emergence?slide=27 仕事は掘り下げると課題解決の繰り返し その中で学んだことや感じたことはあるはず (もし無いなら、それはそれで違うところに問題がある) 日頃からストックしておくと良い e.g. "ブログネタ" のような Slack Emoji リアクションをチャンネル集約する
48. 過去の自分の経験をそのまま求めてる人がいる "２ヶ月前の自分が泣いて喜ぶような記事を書く" @jnchitoさんの記事「個人的な良い記事のガイドライン」より https://qiita.com/jnchito/items/5c3eb3640ad57b3edc6c 「この記事があれば自分の仕事は一瞬で終わったのに！」も一つの目安 世の中、思ったよりも同じことで悩んでる人はいます
49. 仕事に関係あることを、もう一歩掘り下げてみる たとえば、いま使っているライブラリを一つ思い浮かべてみて 「知らないこと」を棚卸ししてみる それは、どういう経緯で誕生したのか 今後計画されている機能はあるのか 他に類似するライブラリが登場してないか 実はそれ代替機能で実現可能だったりしないか 単純にどういう実装で実現されているのか 内部でさらに利用されている依存先はなんなのか どうやって最新情報を得ることができるのか …
50. 「レベルの高いものを発信しなきゃ…」
51. 🔍️ JavaScript 入門
52. 大前提: 初心者向けの発信・初心者からの発信はしても良い 大事なのは前提を丁寧に伝えること 自分がどういう理解度であり、何を学んだのか どういった状況のときに得た知見であり、どういうゴールになったのか どのような人に向けた記事・登壇であり、何を学べるのか 間違っても「これでReactを100%理解できる」とか書かない 100人いたとして、100人全員に刺さる記事を書く必要はない ただし、ターゲットが10人なら90人は読まなくて良い旨がわかるようにする
53. 発信する場所を選ぶ いきなり JSConf JP で登壇する必要はないんです 記事なら、目的によってメディアを分けてみる e.g. Cybozu Inside Out → サイボウズ文脈が強い話, Zenn → 技術特化の話 個人ブログを書いてみるのもいい 登壇なら、最初は社内勉強会からでも良い 大きいカンファレンスではなく、小さめの勉強会などからはじめる フルセッションではなく、5分のLTからはじめてみる
54. 「時間がありません」
55. アウトプットのサイズをコントロールする 大きなナレッジであれば 第1回・第2回、と分割してもいい e.g. 技術評論社の連載 → トピックごと別の記事にしている
56. 必ずしも大作を作る必要はない ポイント一個だけを抑えた小さい記事でさっさと出してしまう e.g. Next.jsのビルドにesbuild(esbuild-loader)を使う https://zenn.dev/mugi/articles/42affdb1beae5c 気になった → 調べた → 試した ということを一瞬で書いたもので、990文字しかない そのわりに Zenn では 40 Likes 程度ついて、一定の需要はあった 個人での発信ならこのぐらいから始めるのもあり
57. 「AI時代に意味あるんかな…」
58. 丁寧に作られたアウトプットにこそ価値が出てきている AIで簡単に長文の記事が作られてしまう時代ですが… 「これAIで公式ドキュメント読ませただけやな…」みたいな記事も増えている 自分の体感では、こういう記事にはネガティブな印象が多い 人が求めているのは、実際の経験と熱量が含まれる発信だが、 これを見極めて探すこと自体に一定のコストが発生してしまっている 結果的に「発信元」の重要度が上がってきている 読む側からすると、組織として実施されている発信は、一定の保証がある 登壇は性質上必ず人が介在するため、引き続き価値がある発信の場になる
59. 最後に大事なこと
60. 発信・探究は、楽しくやりましょう！