1. はじめに

この記事は弥生 Advent Calendar 2025の 8日目のエントリーです。

私が所属しているプロダクトの開発チームは、Aチーム～Eチームまでの5チームが存在します。
エンジニア、マネージャー、スクラムマスター、QA、デザイナーなど、開発に関係するメンバーは50人くらいです。
そのように関係者が多くいましたが、異なるチーム間であまり知見が共有できていない状態でした。
そこで、複数チーム間で楽しく知見を共有しながら称賛し合うイベントを開催したことで、解決のきっかけが得られました。そのやり方を具体的に紹介します。

2. チーム横断で出てきた課題

ある日、そのプロダクトに関する5チームの代表者数人でチーム横断の課題について話し合った時に、以下の課題があることに気付きました。

プロダクト全体のためになる課題を報告したり改善を提案したりしても、それに対するインセンティブがない。称賛されることもない
他チームが、何をしているのか、どんな知見を活用しているのか知らない人が多い
他チームのことを知らないから、他チームもそのメンバーにも興味を持てない人が多い
プロダクト全体のチャンネルで、自分の考えや知見を頻繁に発信する人は皆から知られるが、発信しない人は知られる機会がない

注釈：他チームに興味を持たないことはイノベーションを妨げ、チーム間で知見をシェアして刺激し合う方が生産性は向上しやすいという考え方を前提にしています。

3. 対策：「Best Team Award」の開催

課題を解決するための対策として、そのプロダクトの5チーム全員が参加する「Best Team Award」というオンラインイベントを開催することを提案しました。

3.1 概要

1～3ヶ月ごとに各チームが会社に貢献した活動を5分で発表する会議を30分枠で実施します。
会社に貢献した活動というのは、プロセスの改善、機能の実現、技術的負債の解消、社内に知見を提供などです。
そして、イベントの最後に参加者が投票して、最も素晴らしいチームを決め、みんなでそのチームを称えます。

これは、課題を解消するだけでなく、以下の効果も狙って実施しました。

各チームの知見が共有されて今後の生産性アップにつながること
1位を目指すために、チーム同士で刺激し合う効果が生まれること

以降では、このイベントのやり方の詳細を説明します。

3.2 発表フォーマットはテキスト形式

発表準備が開発チームの負担にならないように、発表フォーマットはテキスト形式としました。
テキストで概要を記して、詳細な資料がもしあれば、リンクをつける程度としました。
イベントまでに、各チームが下図のようなテキスト形式で発表準備をします。

(実際に使った報告内容から、公開できるように一部、架空の内容・データに修正しています)

テキスト形式で書くポイントとして、誰がその活動を行ったのか、個人名をなるべく記載することを推奨しました(例：XXXさんが自動化スクリプトを作成)。
個人名を出して、その人が何をしたかを示した方が、その人に興味を持ちやすいからです。

3.3 タイムテーブル

タイムテーブルは下図の通りです。
5チーム以内であれば、30分で完了できます。
当日も、このタイムテーブル通りに実行できました。

タイムテーブルの冒頭に以下のように記載していますが、これは冒頭に進行係が言う重要なセリフです。

感想をSlackに投稿するアクションもお願いします。「すごい」「素晴らしい」と思ったら、その気持ちをぜひSlackに投稿してください。それが称賛し合う文化の土壌になります。

これを言った上で、途中で投稿された内容を画面共有して、皆で投稿する必要性を念押しすると、書いてもらいやすいと思います。
ちなみに、参加者の投稿を盛り上げやすくするための常套手段があります。自分が信頼する何名かのメンバーに、最初に呼び水となるような投稿をしてもらうことをお願いしておくのです。みんなが気軽に投稿している感じを見れば投稿しやすく感じるので、呼び水となる最初の数件の投稿はとても重要です。

3.4 あらかじめ疑問視されそうな点をQ&Aで解消

このイベントのやり方に対して疑問視されそうな点を、イベントの詳細ページにあらかじめQ&Aとして記載しておくことで、できるだけ関係者に納得してもらうように努めました。
以下に、参考までに私が該当ページのQ&Aに記載した内容を記します。

Q. 以前、スプリントごとにA～Eチームの進捗を共有しあう全員参加の会議をしていたけど、それは参加していて面白くなかった。それの二の舞いになるのでは？

以前の会議の問題点に対して対策しています。以下に問題①②③それぞれの対策を記します。

問題①：各チームの進捗は、他チームのエンジニアにとって興味の対象ではないので聞いていて面白くない
- 対策：進捗報告はしません。エンジニアが期待するのは新たに得られる「知見」なので、それが中心になる会議設計とします。また、個人の成果にフォーカスされる報告なので、自分の成果が報告されて、その反応がどうなるかを考えるとドキドキする想定です。
問題②：会議に参加しても、ほとんどのメンバーは聞くだけで何もアクションすることがない。
- 対策：最後に投票するというアクションがあります(そのため、会議の内容をしっかり聞く必要がある)。感想をSlackに投稿するアクションもお願いします。「すごい」「素晴らしい」と思ったら、その気持ちをぜひSlackに投稿してください。それが称賛し合う文化の土壌になります。
問題③：自分があまり発言しない会議で1時間もの会議はだれやすい
- 1時間は長いので、30分にして、だれにくくします。

Q. なぜ投票して順位を決めるのですか？知見を共有して生産性アップを狙うだけなら、投票しなくてもいいでは？

１つは、称賛し合う文化作りのためです。会社のためやプロダクト全体のためになることを提案したり実施したりしても、それを称賛される機会がなかったため、その機会を創出します。

もう1つは、他チームに興味を持ちやすくするためです。人は自分が行ったアクションの結果が気になります。たとえば政治に興味がなく選挙に行かなかった人でも、選挙に行けば自分の投票結果がどうなるのか気になります。これと同様に、他チームに興味がなかった人でも、投票するための一連の体験を通して興味を持ちやすくなります。

Q. 知見の発信は、プロダクト全体のつぶやきチャンネルでいつでも自由にできる。わざわざ会議を設ける意味は？

主体的に知見を投稿するのを得意としない人も存在します。でも、そういう人の中でも、機会が用意されれば、有益な知見を提供できる人は多くいます。

この活動は、上記の方々にそういう機会を提供することで、チーム横断のメンバー同士で知見をシェアし合って刺激し合う関係性の土台を作ることを狙います。

最終的には、この活動で他チームのメンバーに興味を持つことにより個別で別チームの人との交流が生まれて、そこからイノベーションが起きることを期待します。

3.5 アンケートの作成

イベントの最後に一番素晴らしいチームを決めるために、1分間で投票してもらうためのアンケートを、下図のように作成します。
1分間で投票してもらうために、設問は1つだけとします。
当日の投票の様子を見ていると、15秒前の時点でほとんどの参加者が投票を終えたので、投票時間は1分間で問題ないと思います。

また、今後のイベント運営のために、アンケートを行います。
第1回では、下図のようなアンケートを行いました。参考にしてください。

アンケートの結果としては、下図のように、他チームへの興味が「すごく増した」という意見が多くありました。

3.6 当日の進行

進行係は、イベントが始まる直前に、Slackに下図のように、各チームの発表に対するコメント投稿用のスレッドを立てておきます。こうすれば、どのコメントが、どのチームに対してのコメントなのか、分かりやすくなります。
ちなみに参加率は100％で参加者50人くらい(うち、業務委託20人くらい)で、30分間で76件のコメントをいただけました。

下図は実際のコメント例です。
こんな感じで、ポジティブフィードバックがいっぱいあると、発表したチームは成功体験が得られて、また頑張ろうと思ったりします。

発表が5分をオーバーする場合は、残念ながら打ち切らせてもらうことを事前に伝えておきます。
30分で5チームが発表する場合は、時間カツカツなので、時間厳守が必要です。
参加者も5分のスピーディーな発表を聞きながらコメントを書く必要があるので、とても忙しいです。
ただ、発表者が時間に追われ、参加者が忙しいというのは良い状況なので、それをあえて作ります。
その方が、時間当たりに得られる学びの密度が高まるため、イベントに対する参加者の満足度が上がります。
そのため、あえてカツカツのタイムテーブルを時間厳守で実行することを推奨します。

まとめ

アンケートの結果、他チームへの興味を増した人が多く、またやりたいという声も多数いただきました。
これで課題を解消したわけではありませんが、課題を解消するためのきっかけになりましたので、引き続き第2回も開催することになりました。

本稿の内容が、関係者が多くて、チーム間であまり知見が共有できていない組織において、参考になれば幸いです。もし実施してみた場合は、こちらの記事のコメントかX(旧Twitter)から教えてもらえると私が泣いて喜びます。

X(旧Twitter)でも役立つ情報を発信しますのでフォローしてもらえると嬉しいです → @kojimadev