あなたの会社に、複数チームが集まる定例MTGはありますか？
そのMTG、「各チームの進捗報告をして終わり」になっていませんか？
うちはまさにそうでした。
隔週で全チームの開発メンバーが集まるのに、自チームの話をして、他チームの話を聞いて、それでおしまい。フルリモートだと余計にそうなりがちで、チーム間の壁がどんどん厚くなっていく感覚がありました。
この状況を変えたくて、定例に一つだけ手を加えてみました。
結果、いつもなら各チームが進捗を報告して静かに終わる会議が、30分以上にわたって質問や意見が飛び交うナレッジ共有の場に変わったんです。
良い取り組みはチーム横断で取り入れたい
チーム間の交流がなさすぎて、「良い取り組み」や「良いナレッジ」が社内に浸透しない。これが私の感じていた課題です。
弊社は全社員フルリモートの自社開発企業で、6チーム計20名のエンジニア/デザイナーがいる組織です。
チームごとに担当するサービスが異なり、サービス間の連携も少ないため、どうしても距離が生まれがち。
進捗報告だけで終わる定例
隔週で全サービスチームの開発メンバー（エンジニア・デザイナー）が集まる定例MTGがあります。
ここでは各チームが自分たちの進捗を話すのですが、基本的にはそれだけ。
他チームの取り組みに関心を寄せて深掘りしたり、チーム間で議論が生まれたりすることはほとんどありませんでした。
勉強会の限界
こういった課題を解消しようと、これまで月1回ペースで全開発メンバーを対象に勉強会を別途開催してきました。
私はAI推進リードなので、AI駆動開発周りの勉強会を主催することが多かったです。
ただ、いくつかの問題がありました。
- 私が勉強会を辞めたらナレッジ共有が止まる
- 準備・開催の工数がそれなりにかかる
- どうしても主催者の一方的な発表になりがち
- 参加者に「自分ごと」の意識をもってもらえ（ているか分から）ない
勉強会の効果が一定あったことは確認できています。ですがこれだけではダメだと思いました。
AIの進化に置いていかれないために
特にAI駆動開発が急速に進む中、先進的な取り組みをこまめに共有して横展開していく必要があります。
私が主催する勉強会だけではそのスピード感に追いつけません。
組織一丸となって、全員で、キャッチアップ・ナレッジ共有を進めていかないといけない。
そういう危機感を抱いていました。
定例MTGに「ナレッジ共有会」をねじ込んだ
マネージャーに相談した結果、定例MTGに「ナレッジ共有会」を行う枠を作ることができました。
新しい会議体を増やすのではなく、既存の定例MTGにパートとして追加 する形にしました。
新しい取り組みをスムーズに導入し、かつ継続していくためには、これが一番だと判断しました。
基本設計
| 項目 | 内容 |
|---|---|
| 頻度 | 隔週実施のうち、2回に一度（月一くらい） |
| 時間 | 定例の後半30分（共有会がある回は定例を1時間に拡大） |
| 構成 | 前半：通常の進捗報告 → 後半：ナレッジ共有会 |
テーマの決め方
- 事前にテーマを募集：Slackなどで「他チームに聞いてみたいこと」を自由に書き出してもらう
- 投票で決定：気になるテーマにスタンプを付けてもらい、最多投票のテーマを採用
- 発表チームを選定：投票者の指定、あるいは そのテーマに最も関連する取り組みをしているチームに発表を依頼
この「テーマ投票制」はかなりよくて、テーマを投稿した人も、投票した人も、自分たちが聞きたいテーマだから発表への関心が高い状態でスタートできます。
初回の実施内容 ― AI駆動開発の全体像
テーマ選定の経緯
初回のテーマ募集では複数の候補が集まりましたが、最多投票だったのは 「AI駆動開発の全体像」。社内でAI活用が進む中、「先進的に取り組んでいるチームが実際にどうやっているのか、全体像を知りたい」という声が多かったようです。
発表は、AI駆動開発を積極的に実践しているラッコIDチームが担当してくれました。
発表の概要
発表では、開発フロー（タスク起票 → 要件整理 → 実装 → レビュー → マージ）の 全フェーズでAIをどう使い分けているか が共有されました。
特に印象的だったのは、「全フェーズでAIが活用されている」 という点と、ツールごとに得意な領域を見極めて使い分けている という点でした。
細かい内容は省きますが、参考までにスライドをぜひご覧ください。
予想以上に盛り上がった質疑応答
正直、ここまで盛り上がるとは思っていませんでした。発表後の質疑応答では、さまざまなチーム・メンバーから意見や質問が飛び交いました。
実際に出た質問・議論の例
「仕様書駆動開発で作った仕様書って、どう管理してるんですか？」
仕様書駆動開発とは、AIに実装を任せる前にまず仕様書（要件定義書や設計書）を作成し、それをコンテキストとして渡して実装させる開発手法です。この仕様書の管理方法について議論が盛り上がりました。Gitリポジトリに含める派と、タスク管理ツールのドキュメントに紐づける派に分かれたんです。リポジトリに含めるメリットは、PRに仕様書が同梱されるため「どんな意図でこの実装をAIに作らせたのか」がレビュアーに伝わる点。一方、タスク管理ツールのドキュメントに置けばIssueと紐づけて管理しやすいという意見もあり、正解は一つではなくチームの運用に合わせて使い分けている状況が共有されました。
「簡易タスクをDevinに任せるフロー、他チームでも使えるのでは？」
発表チームでは、UIのバグ修正などの簡易タスクをDevin（AIコーディングエージェント）に実装させるフローを運用しています。タスク管理ツール上でラベルを付けるだけでDevinが自動で実装を開始し、PRまで作成してくれる仕組みです。前回のスプリントでは50件近くのタスクをこの方法で処理したとのこと。他チームのデザイナーも使い始めていて、「フロントエンドで完結するような修正は特に得意」「事故も起こりにくい」という声が出ました。マネージャーからも「簡易タスクは人がやらなくていい方向に進めよう」という方針が示されました。
「Dependabotの自動レビュー対応、他チームでもやれるのでは？」
Dependabotとは、ライブラリの更新PRを自動で作成してくれるGitHubの機能です。ただ、PRが大量に来ると人間がレビューする負担が大きい。発表チームでは、AIコーディングエージェント（Devin）にこのPRを自動でレビューさせ、影響範囲のレポートを作成、人間は最終確認だけすればOKという仕組みを構築していました。マネージャーから「これは各チームで早期に導入すべき」と横展開の指示がその場で出ました。
「CLAUDE.mdには何を書くと効果的？」
「CLAUDE.mdはできるだけ軽い方がいい」「スキルにコンテキストを寄せていくと自然とCLAUDE.mdは軽くなった」という実践知が共有されました。また、レビュー時にAIに読ませたい指示をREVIEW.mdとして別ファイルに分ける運用も紹介されました。
「調査メモや作業メモをGitリポジトリで管理するメリットは？」
発表チームでは、実装時の調査メモや要件定義の補足資料、日々の作業メモなどをMarkdownファイルとしてGitリポジトリやObsidianで管理しているとのこと。こうしておくとClaude CodeなどのAIコーディングツールから直接メモを読み取れるため、「この前調べた内容を踏まえて実装して」といった指示がスムーズに通るのがメリットだそうです。一方で「情報が分散するのでは？」という懸念も出て、「タスクに紐づく情報はタスク管理ツール側に、個人メモはローカルに」という使い分けの議論に発展しました。
ナレッジ共有会の収穫
初回を終えて、想定以上の収穫がありました。
- 各チームの悩みや取り組み状況が可視化された: 発表チームの話を聞くだけでなく、質問を通じて「うちも同じことで悩んでいた」「こういう工夫をしている」といった各チームの状況が自然に表に出てきました
- 横展開のアクションがその場で決まった: DependabotのAIレビューやDevinによる簡易タスク対応など、「これは他チームでもすぐやろう」というアクションがマネージャー主導でその場で決まりました。勉強会だと「いい話を聞いたな」で終わりがちだったのが、大きな違いです
- 発表者側にも発見があった: 発表したチーム自身も、質問を受けることで自分たちの運用を言語化・整理する機会になったとのこと。「当たり前だと思っていたことが他チームには新鮮だった」という気づきもあったようです
うまくいったポイントを振り返る
1. 「発表」より「対話」が生まれる場の設計が大事
一方的な勉強会と比べて、質疑応答の時間が長く取れる構成にしたことで、双方向のコミュニケーションが生まれました。発表者も「目新しいことはないかもしれないけど、ちょっとした違いが発見できれば」というスタンスだったのが良かったと思います。
2. 強制的に当事者意識を生む
テーマ投票制については、自分たちが投票して選んだテーマなのでニーズに合っていて、かつ当事者意識も生まれやすいと思います。
また、本文では触れませんでしたが、参加チームに対して事前に「1チームかならず1度は発言して」とお願いしていました。
3. 既存の枠に載せることで継続しやすい
新しい定期ミーティングを増やすのはハードルが高いですが、既存の定例に30分追加する形なら負担が小さい。準備する側も「発表」というよりは「共有」ぐらいの温度感でやれるので、心理的なコストも低いです。
4. 横展開のアクションが自然に生まれる
「これは他チームでもやった方がいい」というアクションが、マネージャー主導で自然に出てきました。勉強会では「いい話を聞いたな」で終わりがちだったのが、定例の場で具体的な指示につながったのは大きな違いです。
まとめ
もし同じような課題を感じている方がいたら、この記事が参考になれば幸いです！
最後まで読んでいただき、ありがとうございました！
Discussion