こんにちは！開発組織のエンゲージメント向上をミッションとしている Developer Engagement Group (以下、DEG) の滝口(@ytakiguche)です。普段は「ぐるなびウエディング」の開発を担当するかたわら、開発組織全体の働きやすさ向上に取り組んでいます。
DEG に関しては以下の記事もぜひご覧ください。
開発組織において、ナレッジ共有を「仕組み」として定着させるのは、想像以上に骨が折れる仕事です。「勉強会を立ち上げたはいいものの、次第にネタが枯渇する」「参加者が固定化して形骸化する」「結局、目の前の案件が忙しくて後回しになる」……。そんな理想と現実のギャップに直面したことがある方は多いのではないでしょうか。
私たちの組織では、毎週金曜日に「ナレッジ共有会」を開催しており、足掛け3年ほどこの習慣を継続しています。もちろん、発表者が集まらずにスキップする週もありますが、無理に完走することに固執しない「しなやかさ」こそが、長く続いてきた理由かもしれません。
なぜ、兼務メンバー中心の運営でこれほど長く、多様な知見が循環し続けているのか。その舞台裏にある文化作りと、自動化による泥臭い工夫を公開します。
目次
- 目次
- 1. 業務の手を止める「カイゼンタイム」という公式の枠組み
- 2. 発表のハードルを下げる「思想」
- 3. 兼務チームでも回せる「運営の自動化」
- 4. 運営が直面した課題と、その「アプローチ」
- 5. ナレッジ共有会が生んだ「4つの変化」
- 最後に：まずは「名前を書く場所」を作ることから
1. 業務の手を止める「カイゼンタイム」という公式の枠組み
生産性の向上や自己研鑽の重要性を説く際によく引用される物語に、「木こりのジレンマ」というエピソードがあります。「刃を研ぐ時間を惜しんで木を切り続けるよりも、一度手を止めて刃を研いだほうが、結局は多くの木を切れる」という教えです。
人や組織の成長には、この「余裕・余力」を意図的に作ることが不可欠です。そこで私たちの開発組織では、「カイゼンタイム」という、毎週金曜日は自己研鑽をしよう！という公式のルールを設けています。これには以下の狙いがあります。
- 「業務の手を止める」という決断: 毎週金曜日の一定時間は、通常業務（開発）の手を完全に止め、サービス改善やスキルアップに充てる時間として定義されています。
- 全員参加の文化: 特定のメンバーだけでなく、エンジニア全員が参加することを原則としています。
- 目的の明確化: スキルアップはもちろん、グループを超えたコミュニティ活動（フロントエンド、バックエンド、SREなど）を活性化させることを目指しています。
ナレッジ共有会はこの枠組みの中で開催されており、組織として「刃を研ぐ時間」を担保しています。
2. 発表のハードルを下げる「思想」
3年間継続できている理由のひとつは、「立派な発表を求めない」という空気を作ってきたことです。
「モダン」じゃなくていい
「最新の技術スタックを使って、完璧な成果を出した話」だけを求めていると、ネタはすぐに尽きてしまいます。私たちは以下のスタンスを強調しています。
「あなたの『当たり前』は、誰かにとっての『新しい発見』になる」
- 他のチームが何をやっているかを知ること自体に価値がある。
- 成功体験だけでなく、「しくじり（失敗談）」こそが組織の資産になる。
- 業務に関係のない、個人の興味関心（技術勉強）の共有も大歓迎。
実際に共有されたタイトル例
これまでに共有された内容は多岐にわたります。
【AI・最新ツール】
- GitHub Copilot Agent Modeをフル活用する
- スプシでの作業・資料作成でGeminiを使おう
- ChatGPTにE2Eテストを改修させてみた
【技術深掘り・アーキテクチャ】
- ぐるなびウエディングのマイグレーション戦略
- 「データ基盤」について少し語ります
- 社内ネットワークの過去・現在・未来
- 意外と考えないといけないログ実装
【デザイン・UX・アクセシビリティ】
- 知ることから始める Web アクセシビリティ
- 複雑な「情報」をわかりやすくするデザイン
- ぐるなびウエディングリニューアルにおけるテーマカラー検討のプロセス
【知見共有・読み物】
- テストのしくじり（仮）100連発
- SlackワークフローのWebHookが神すぎる件
- UMAME!の開発秘話
- 明日は我が身!?小ネタ集 〜正常性バイアス〜
3. 兼務チームでも回せる「運営の自動化」
私たち運営（DEG）メンバーは、全員が本来のエンジニア業務やマネジメント業務を抱えながら「兼務」で活動しています。そのため、運営コストを削るため、GAS (Google Apps Script) + Slack API などを活用して仕組み化しています。
- Slack告知の自動化: 登壇管理用のスプレッドシートに「登壇者名」「タイトル」を入力すると、その情報をプレースホルダーとして読み込み、広域Slackチャンネルへ自動で告知が飛ぶようにしています。
- エントリーの簡略化: 発表したい人は、スプレッドシートの空いている日付の枠に「名前を入れるだけ」でエントリー完了です。企画書の提出や事前承認などは一切不要にしました。
ナレッジ共有会開催の告知例:
ナレッジ共有会開催後の案内:
4. 運営が直面した課題と、その「アプローチ」
3年も続けていると、当然いくつかの壁にぶつかりました。
課題①：アンケートが集まらない
フィードバックは登壇者の最大の報酬ですが、回答率は自然と下がっていきます。
- 解決策: アンケートを「満足度・理解度・活用度」の3つの指標＋自由記述のみに絞り、1分で終わる内容にシンプル化しました。また、毎週上長経由でリマインドを依頼するなど、組織ぐるみで「フィードバックの価値」を伝えています。
課題②：発表者が集まらない
「自分なんかが話しても……」という遠慮をどう取り除くか。
- 解決策: 開発部の全体会議で登壇者を改めて紹介し、感謝を伝える場を作りました。また、半期に一度の表彰制度（アワード）を設け、素晴らしい共有を行ったメンバーをDEGとして表彰し、アウトプットが讃えられる文化を作っています。
課題③： 深い技術共有が少ない
どうしても「全員参加」の勉強会では、尖った内容や高度な技術共有が減ってしまう傾向がありました。
- 解決策：Deep Dive Sessionの導入: 「全員参加」から、特定のテーマに興味がある人が集まる「意欲ある参加」へシフトした枠組みを新設しました。SREやフロントエンドなど対象を絞ることで、より専門的で深い議論ができる場へと進化させています。
5. ナレッジ共有会が生んだ「4つの変化」
この習慣を約3年続けた結果、組織には目に見える変化が現れました。
- スキルアップの加速: 効率的な知識共有により、各チームの技術水準が底上げされました。
- チーム間の壁が消えた: 職能を越えたコミュニティ活動が活発化し、横の繋がりが強固になりました。
- 改善アイデアの源泉: 「他チームの事例を自分のプロジェクトでも試してみる」という動きが日常化しました。
- モチベーションの向上: アウトプットを称え合う文化が、エンジニアとしての自信と意欲を支えています。
最後に：まずは「名前を書く場所」を作ることから
ナレッジ共有会を成功させる鍵は、高度な技術スタックを自慢し合う場にすることではなく、「情報を循環させることそのものを楽しむ」文化を組織全体で育むことです。
もし、あなたの組織でナレッジ共有が滞っているなら、まずは「名前を書くだけの自由な予約表」を作り、最初の一人を全力で称賛することから始めてみませんか？今の小さな一歩の積み重ねで決まります。
