本稿は夏のデブサミ(Developers Summit 2026 Summer) での発表内容をより詳しく解説した記事です。発表スライドは以下で公開しています。

1. 良い取り組みが「いい話でした」で終わってしまう問題

良い取り組みを社内で紹介しても、「いい話でした」で終わってしまう。

私は過去に5年以上、この壁に何度もぶつかってきました。

でも、届け方を変えた結果、今の会社に入社してから1年で、次のような状態になりました。

個別に相談してくれた人：20人以上
私が紹介した知見を活用してくれたチーム：10チーム以上

この記事では、権限のない一人のエンジニアが、良い取り組みを「聞いて終わり」にせず、他チームでも試してもらうためにやったことを書きます。

以前の私は、自分のチームでうまくいったやり方を、もっと他チームにも試してほしいと思っていました。

新しいツールで作業を効率化したり、AIで定型作業を自動化したり、タスクの進め方を見える化したり。小さな工夫で生産性が上がると嬉しいし、その知見を他チームにも役立ててほしいと思うことがあるのではないでしょうか。

「このやり方はかなり良い」

「きっと他のチームにも役に立つ」

「Slackで紹介したり、社内発表したりすれば、みんな試してくれるはず」

私は、そう思っていました。

でも、実際にはそう簡単には広がりませんでした。

発表後に「いい話でした」と言ってもらえる。Slackにリアクションもつく。その場では好意的に受け取ってもらえる。

でも、次の日から他チームの仕事のやり方が変わるわけではない。

当時の私は、「なんで試してくれないんだろう」「同じようにやれば良くなるのに」と少し不満に思っていました。

でも、今振り返ると、試してもらえなかった理由は相手にあったのではなく、自分の届け方にありました。

相手の困りごとや優先していることを知らないまま、自分のチームでうまくいったやり方をそのまま渡していただけでした。

どのチームにも、そのとき抱えている課題や優先順位があります。良さそうなやり方を聞いても、今すぐ困っている問題とつながらなければ、試す理由にはなりにくいです。

それに、新しいやり方を試すにはエネルギーが要ります。今の進め方を変えてよいのか、どこから始めればよいのか、うまくいかなかったらどうするのか。そういう小さな不安があると、「良さそうだけど、今の自分たちにはどう使えばいいか分からない」で止まってしまうことがあります。

そこから私は、やり方を少しずつ変えました。

自チームで試し続け、現場の知見を増やす
発信で認知をつくる
個別対話を重ねる
相手の困りごとに合わせて知見を渡す

その結果、自チームで試したタスクの進め方やふりかえりの工夫が、別のチームでも使われるようになりました。AIエージェントを使った業務自動化の知見が、エンジニアだけでなく、PdM、PjM、お客様向けコンテンツ作成、問い合わせサポートなど、多職種の業務改善につながることもありました。

後日、「教えてもらった方法でうまくいきました」「うちのチームでも使えました」と言ってもらえることもあります。自分が直接手を動かした仕事ではなくても、知見が誰かの仕事を少し楽にする。そう感じられる瞬間は、働いていてとても楽しいです。

ここからは、実際にやったことを、できるだけ再現しやすい形で書きます。

長いので、要点だけ知りたい方は各章の最後にあるおすすめアクションだけ読んでもらえれば大丈夫です。
タイトルの「黒歴史物語」に興味を持って来た人は、「3.4 黒歴史物語：失敗談は距離を縮める」を見てもらえればと思います。

2. 自チームで試し、生きた知見をつくる

2.1 生きた現場の知見は、試す中で増えていく

良い取り組みを他チームに広げたいなら、まず自分自身が、生きた現場の知見を持っている必要があります。

ここで言う知見は、きれいに整理された一般論ではありません。

「このやり方は良さそう」と思って試してみたら、実際にはどこでつまずいたのか。どんな条件ではうまくいき、どんな条件では合わなかったのか。そういう、現場で試したからこそ分かる話です。

AIの進化によって、一般的なノウハウは誰でも手に入りやすくなっています。だからこそ価値があるのは、自分のチームで実際に試して、悩んで、調整して、少し前に進んだ経験です。

私は1年前(2025年6月)に弥生株式会社へ入社し、あるスクラムチームへ配属されました。チームにはすでにスクラムマスターも、PdMも、デザイナーも、エンジニアもいました。

肩書はエンジニアリングマネージャーでしたが、チームや組織に対する権限は何も持っていませんでした。あえて一人のエンジニアとしてチームに入り、開発業務をしながら、ボトムアップで改善提案をしていきました。

朝会のやり方を少し工夫したり、タスク着手時に集中検討を徹底したり。一つひとつは小さな試行ですが、重ねると「現場で試した知見」が増えていきます。

相手に知見を渡すとき、一般論だけだと「なるほど、良さそうですね」で終わりやすいです。でも、「自分のチームではこういう困りごとがあり、こう試したら、ここは効いた。でも、ここは合わなかった」と話せると、相手も自分のチームに置き換えて考えやすくなります。

おすすめアクション：良い取り組みを広げたいなら、まず自分自身が、生きた現場の知見を多く持つ。そのために、自チームで小さく試せる改善を提案してみる。

2.2 「まず試す」を軽くする

自チームを試し続けるチームにする上で、大事なのは、改善を重い意思決定にしすぎないことです。

「これからずっとこのやり方でいきましょう」と言われると、受け取る側は慎重になります。だから私は、できるだけ小さく試すようにしました。

まず2週間だけ試してみる。良さそうなら続ける。合わなければやめる。

このくらい軽くすると、新しいやり方を試しやすくなります。

ちなみに、私が過去に自分のチームで試してきたプラクティスはこちらに30件以上ありますので、そちらを参照ください。ここで伝えたいポイントは、施策の細かい手順ではありません。

良い取り組みを広げるために必要なのは、完璧な成功事例を持つことではないと思います。
自分のチームで試し続け、うまくいったことも、うまくいかなかったことも、次の人が試せる形で言葉にしておくことが大切です。

おすすめアクション：改善を提案するときは、「まず2週間だけ試してみて、合わなければやめましょう」とセットで伝えてみる。その経験が多くあると、他チームにも渡せる生きた知見が増えていく。

3. 発信で、相談される入口をつくる

3.1 発信は、導入ではなく認知をつくる

ここからは、自チームで試して得た知見を、まだ面識のないチームにも知ってもらうための話です。

私は、自チームで試したことや得られた知見を、社内のエンジニア組織全体(約300人)が見るSlackチャンネルに投稿しました。社内LTでも発表しました。社外で発表した資料も社内に共有しました。

ただし、大人数に発信しただけで、すぐに組織が変わるわけではありません。

発信すると、反応はあります。「いいですね」「参考になりました」と言ってもらえることもあります。でも、それだけで他チームのやり方が変わるわけではありません。

では、大人数への発信は意味がないのか。そうではありません。

なぜなら、大人数への発信の役割は、その場で相手に導入を決めてもらうことではないからです。

他チームには、他チームの事情があります。こちらが「良い取り組みです」と紹介しても、相手の具体的な困りごとと接続していなければ、すぐに試されないのは自然です。

だから、「いい話でした」で終わること自体は失敗ではありません。

大人数への発信でまずつくるべきなのは、導入ではなく認知です。

「この人はこういうことを考えている」

「こういうプラクティスを試している」

「困ったら相談できそう」

そう思ってもらえる入口を増やすことが、発信の役割です。

その場で誰かのチームが変わらなくても、後日その人が似た課題に直面したときに、「そういえば、あの人が何か試していたな」と思い出してもらえるかもしれません。発信は、その未来の相談のために種をまく行為でもあります。

おすすめアクション：大人数への発信は「すぐに導入してもらうため」ではなく、「このテーマなら相談できそう」と思ってもらうために行う。

3.2 認知は、小さな発信の積み重ねでつくる

認知をつくるには、一度だけ大きく発信するよりも、小さな接点を何度もつくる方が効くと思っています。

私は、自チームで試したことをSlackに投稿しました。うまくいった施策だけでなく、なぜ試したのか、どんな課題があったのか、やってみて何が分かったのかも書くようにしました。

たとえば、NotionでJiraのようなチケット管理を試していたときは、「チケットの完了時に完了日を自動設定する方法」を、自チームで使っていた設定例とGIFを添えて共有しました。

これくらい小さなTipsでも、似た運用をしているチームにとっては、そのまま試せる材料になります。ポイントは、自分がやったことを他の人が再現できる情報を添えることです。

社外に投稿した記事や発表スライドも、ただURLを貼るだけではなく、「この資料では何を話したのか」「社内のチームづくりに関係しそうなポイントはどこか」を添えて共有しました。社内LT、部会、全社員向けイベントでも発表しました。Findy Team+の推進役にも立候補し、試して分かったことをSlackや部会で共有しました。

社外イベントでの発表予定もSlackに投稿しました。スクラムフェスで発表することになったときは、発表予定だけでなく、なぜ挑戦したのか、どんなテーマで話すのかも添えて投稿しました。

これは、「自分は外で発表しています」と見せたかったからではありません。そのテーマについて一定の経験や知見を持っていると知ってもらう機会でもあり、同じテーマで困っている人が「この人に聞けば何かヒントがあるかもしれない」と思ってもらいやすくなります。

大事なのは、「目立つ場所で発信すること」ではなく、自分が何を試しているのか、何に困っているのか、何を学んだのかを、周囲の人が何度も目にする状態をつくることです。

最初の一歩は、登壇や大きなイベントである必要はありません。自チームで試した小さな工夫を、再現できる形でSlackに置くだけでも十分です。

そうした接点が増えるほど、「この人はチーム改善について継続的に試している人だ」という認知が少しずつできます。その認知があると、後述する個別対話でも話を聞いてもらいやすくなります。

おすすめアクション：認知は一度の大きな発信ではなく、小さな発信の積み重ねで作られる。だから、Slack投稿、社内LT、部会の発表などで継続して共有する。

3.3 強く学んだことは、発表の形で届ける

社外イベントや記事で強く学んだことがあれば、社内で発表する機会をつくれないか考えるようにしました。

参加レポートを書いてSlackで共有する方法もあります。記事やレポートは読み手の都合で読める良さがある一方で、「こういうセッションを聞きました」という共有で終わりやすいです。

一方で、発表の形にすると、学んだ内容だけでなく、自分がなぜそれを大事だと思ったのかまで届けやすくなります。聞き手がその時間だけテーマに集中してくれるので、話の背景や問題意識まで受け取ってもらいやすくなります。

人は、正しい情報を見ただけではなかなか動きません。発表を聞くと、「この人はこういうことを大事にしている人なんだ」と人物像ごと知ってもらえます。

その上で大事なのは、社外で得た学びを、自分たちの現場で試せる言葉に置き換えることです。

「このセッションが良かったです」だけではなく、「自社のチームづくりに置き換えると、ここが使えそうです」「今の自分たちの現場なら、まずここから試せそうです」と、自分の言葉で整理して話します。

私の場合は、Agile Japan というカンファレンスに一般参加したあと、エンジニア組織全体に対して、任意参加の45分発表として会議案内を送って実施しました。印象に残ったプラクティスをそのまま紹介するだけではなく、自分たちの組織ならどこに活かせそうか、まず何から試せそうかも添えて話しました。

Slackで発表の案内をするときも、単に「参加レポートを発表します」とは書きませんでした。なぜこのテーマを共有したいのか、どんな人に聞いてほしいのか、聞くと何が持ち帰れそうなのかを先に書きました。

発表の中身を詳しく説明する前に、「これは自分たちの組織にも関係がありそうだ」と感じてもらえる入口をつくるためです。

結果として、約100人が参加してくれて、発表後には「このプラクティスを自チームでも試してみたい」という声も多くありました。

だから、強く学んだことがあるときは、参加レポートだけで終わらせず、発表の形で届けることをおすすめします。

おすすめアクション：社外イベントや記事で強く学んだことがあれば、参加レポートだけで終わらせず、社内で発表する機会をつくる。何を学んだかだけでなく、なぜ大事だと思ったのか、自分たちの現場なら何から試せそうかまで伝える。

3.4 黒歴史物語：失敗談は距離を縮める

社外で得た学びを社内で使える形に置き換えて返すのと同じように、自分の経験から得た学びも、読み手に届く形に変えることができます。

教科書的な知識や一般論は、AIに聞けばきれいに整理された答えが返ってきます。だからこそ、知見を発信するときに価値を持つのは、自分や自分のチームが実際に試して、何が起きたのかという生の話です。

その中でも、失敗談は強い題材になります。

うまくいった話を読むと、「すごい」「参考になる」と思う一方で、「それはその人だからできたのでは」「うちのチームとは状況が違う」と少し遠く感じることもあります。

一方で、失敗談には距離を縮める力があります。

「分かる、自分もやりそう」

「自分も近いことをしていたかもしれない」

「この失敗は回避したい」

そう思ってもらえると、失敗談は単なる恥ずかしい話ではなく、誰かが同じ落とし穴を避けるための知見になります。

私は過去のチームマネジメントで、いろいろな失敗をしてきました。

レビューで何十件も指摘して、相手を自信喪失させてしまったことがあります。

会議で発言しない人に対して、「発言しない方に原因がある」と思い込んでいたことがあります。

ペアプログラミングで、自分の方が分かっていると思い、相手の意見を素直に受け入れられなかったことがあります。

とても恥ずかしい過去です。でも、こういう失敗談にこそ、失敗を回避してもらうための知見が詰まっています。

だから私は、自分の過去のチームマネジメントの失敗を、ただのノウハウ記事ではなく、もっと興味深く読んでもらえる物語として届けることにしました。

その取り組みが、ラノベ風の社内連載「黒歴史物語」です。

意識したのは、最初から正解を説明しないことです。

まず、過去の自分が何を考えていたのかを書く。なぜその行動をしてしまったのかを書く。その結果、相手に何が起きたのかを書く。そして、あとから振り返って、どこが間違っていたのか、どう考え方を変えたのかを書く。

そうすると、読み手は「正解を教えられる」のではなく、「失敗の過程を一緒に追体験する」形になります。

さらに、タイトルやサムネイルも、少し読みたくなるように意識しました。

ただ「レビューの失敗から学んだこと」と書くよりも、「自信喪失させるレビューの闇」と書いた方が、何が起きたのか気になります。

ただ「モブワークのすすめ」と書くよりも、「自分でやった方が速いという呪いを解くモブワーク」と書いた方が、過去の自分にも刺さる感じがあります。

これまでに公開した5話のタイトルは、次のようなものです。

第1話「自信喪失させるレビューの闇」
第2話「自分でやった方が速いという呪いを解くモブワーク」
第3話「会議で発言してもらえない原因は私だった」
第4話「こんな事も知らないの？とマウントしていた私」
第5話「教えているつもりで考える機会を奪っていた」

↑こちらは第1話のアイキャッチ画像(私の写真をAI加工したもの)

どのタイトルも、過去の自分の失敗がそのまま見えるようにしています。

「自分も似たことをしているかもしれない」と思える話は、単なるノウハウよりも読み手の心に入りやすいことがあります。

ありがたいことに、社内でも多くの方に読んでもらえました。エンジニアだけでなく、マネージャーやサポートや広報など、さまざまな職種の方にも届きました。

実際に感想でも、「胃が痛くなった」「指摘する側として耳が痛い」「自分も同じことがあるなと思った」といった声がありました。これは、失敗談が単なる読み物として消費されたのではなく、読み手自身の経験や振る舞いに重なったということだと思います。

さらに、「無意識の思い込みがないかを考えるきっかけになった」「自分も気を付けようと思った」「自分の失敗談を発信することにも挑戦してみたい」といった反応もありました。読んだ人の心が少し動き、次の行動や内省につながったことは、黒歴史物語として届けたからこその効果だったと感じています。

読んでもらうためには、公開しただけで終わらせないことも意識しました。

黒歴史物語を社内報で公開したときは、全社員(約800人)が参加するSlackチャンネルにも投稿しました。ただURLを貼るだけではなく、「自分の方が上だと思い込んでいた」「その思い込みによって残念なペアプロをしていた」という、自分の失敗が見える導入を書き、興味を持ってもらいやすい形で紹介しました。

知見は、正しく説明するだけでは届かないことがあります。読みたくなる形に変換することで、初めて届くことがあります。

もし自分の中に「昔の自分はこう失敗した」「今なら別の関わり方をする」と思える経験があるなら、それを社内で物語として公開してみることをオススメします。

とはいえ、最初から物語として書くのは難しいと思います。必要であれば私の原稿をお渡しします。

なお、「黒歴史物語」の原稿そのものは、諸事情によりインターネット上には公開できません。もし興味があれば、私のXアカウントにDMをください。社内限定での共有や、私の原稿をベースに自分の失敗談へ置き換えて社内向けに公開する用途であれば、相談いただければお渡しできます。

おすすめアクション：自分の失敗談を一つ選び、「当時の自分は何を正しいと思っていたか」「その結果、相手やチームに何が起きたか」「今ならどう考えるか」の流れで社内向けに書いてみる。単なる反省ではなく、同じ失敗を避けるための知見として渡す。

4. 個別対話を起点に、困りごとに合う知見を渡す

4.1 まず1on1で、相手の困りごとを知る

発信だけで相手のチームの状況まで理解することはできません。実際に知見を受け取ってもらうには、相手が何に困っているのかを知る必要があります。

さらに、他チームと関わる意味は、自分の知見を渡すことだけではありません。他チームにも、そのチームの現場で試してきた生きた知見があります。

だから私は、発信でできた小さな接点を、1対1の対話につなげていきました。

とはいえ、待っているだけで誰かから連絡が来るとは限りません。自分から1対1で話せる機会をつくっていく方が大事だと思っています。

一番の王道は、社内Slackへの投稿や社内発表を見て、自分に興味を持ってくれていそうだと感じた人に、思い切って1on1でお話しさせてもらえないか打診することです。

たとえば、私は次のようなDMを送っていました。

先日は発表を聴いてくださって、ありがとうございます。
○○さんのチームについて興味があります。
どんな感じで開発しているのかお聞きしたいです。
良かったら、一度30分枠で1on1をお願いできないでしょうか？

ポイントは、いきなり「相談に乗ります」と言わないことです。まずは相手のチームに興味があること、教えてもらいたいことを伝えます。その方が、一方的に教えに行く人ではなく、相手から学びたい人として関係を始めやすくなります。

出社イベントで知らない人に話しかけるときも同じです。社内で発信していると、「あの投稿を見ました」「この前の発表、面白かったです」と言ってもらえることがあります。そういう小さなきっかけがあると、初対面でも話がはずみやすくなります。

まずは、オンラインで1on1をする。あるいは、出社したタイミングでオフラインで話す。相手の困りごとを聞き、自分の考えも知ってもらう。そうして関係性ができてくると、次にチームの会議へ参加させてもらいやすくなります。

おすすめアクション：自分の発信に反応してくれた人に、まず1on1をお願いしてみる。相手の困りごとやチームの状況を聞き、自分が何を試してきたのかも少し話してみる。

4.2 他チームのふりかえりに学びに行く

ここで大事なのは、1対1の関係で終わらせず、そこからチームの活動に参加させてもらうことです。

1on1で相手の困りごとやチームの状況を少し理解できたら、「もしよければ、勉強させてもらいたいので、チームのふりかえりに参加させてもらえませんか」と相談してみます。

私は、他チームの朝会、モブプログラミング、ふりかえりなど、いくつかの活動に参加させてもらいました。その中でも、特に学びが大きかったのは、ふりかえりでした。

ふりかえりに参加すると、そのチームが最近どんなことに取り組んでいるのか、何に困っているのか、どんな改善を試しているのかが見えてきます。自分のチームにはない良い取り組みを知れることもありますし、ふりかえりの進め方自体から学べることもあります。

まず大事なのは、助言することではありません。そのチームの良いところを見つけて、言語化して伝えることです。以下は例です。

「○○さんは、感謝の内容を凄く具体的に伝えてて素晴らしいです」

「ふりかえり中に、にぎやかしの称賛スタンプを皆でたくさんでしていて素晴らしいです」

1時間の会議なら、10件くらい見つけたいところです。

良いところを言語化して伝えると、そのチームにとっても、自分たちの取り組みの価値を再認識するきっかけになります。こちらも一方的に教える人ではなく、相手から学ぶ人として関われます。さらに、相手の良いところを自分の言葉で説明しようとすることで、自分自身の学びも深まります。

そして、そこで得た知見は、自分の中だけに閉じなくてよいと思っています。あるチームのふりかえりで見つけた良い工夫が、別のチームの困りごとに役立つことがあります。

もちろん、そのまま横流しすればよいわけではありません。

だから、「Aチームではこうしていました」と紹介するだけでなく、「あなたのチームの状況なら、この部分だけ小さく試せるかもしれません」と翻訳して渡します。

たとえば、あるチームのふりかえりで、課題を出すだけでなく次に試す行動を小さく決める進め方がうまく回っていたとします。それを別チームに話すときは、「同じフォーマットを使いましょう」ではなく、「今出ている課題の中から、次の2週間だけ試す行動を1つ決めるところから始めると合うかもしれません」と伝える。

このときも、相手の自由を奪わないことが大事です。

「これをやった方がいいです」と言われると、受け取る側は身構えるかもしれません。

でも、「別のチームではこういうやり方が合っていました。チームによって合う合わないがあるので、もし今の困りごとに近そうなら、まず2週間だけ試してみて、いまいちだったらやめれば良いと思います」と伝えると、相手のチームが自分たちで選べます。

横の影響力は、相手の自由を奪わない形で広げる方が良いと思っています。

こうして他チームのふりかえりに参加していると、自分は知見を持っていく人であると同時に、知見を受け取る人にもなります。組織の中にある知見を少しずつ回す潤滑油になることは、権限のない一人のエンジニアにもできることだと思っています。

おすすめアクション：1on1を起点に、ふりかえりに参加させてもらう。参加時は、そのチームの良い工夫を見つけて伝える。そのチームの困りごとにも役立ちそうな知見があれば、相手の状況に合わせて参考情報として渡してみる。

4.3 教わった知見を、相手の仕事で使える形にする

こうした1on1やチーム活動への参加を通じて、私が相手に何かを伝えるだけでなく、逆に教えてもらうことも増えていきました。

次に考えたのは、そこで教えてもらった知見を、エンジニア以外の方々にも役立てられないかということでした。

このとき、私が渡せそうだと思った知見の一つが、AIエージェントを用いた業務自動化でした。MCPやBrowser Automationを使って日々の作業をAIに実行してもらい、その流れをコマンド一発で実行できる形にする方法です。

ただし、私がAIエージェントによる業務自動化の熟練者だったわけではありません。私は他チームのエンジニアから「こういう使い方ができますよ」と教えてもらった立場でした。

だからこそ、完璧なノウハウとして広げるのではなく、教えてもらった方法を相手の業務で使えそうな形に置き換えて、一緒に試してみる。それくらいなら、自分にもできるのではないかと考えました。

エンジニアの中には、AIを使って自分の作業を自動化できる人も多くいます。一方で、PdM、PjM、お客様向けコンテンツ作成やサポート対応をするなど、多職種の方々にとっては、自分の業務で使うところまではまだ少し距離があるように感じていました。

そこで、まずは身近なPdM、PjM、お客様向けコンテンツ作成やサポート対応をする方々に声をかけ、小さく試せる場を作りたいと考えました。

そうして実施したのが、Cursorを用いた自動化のハンズオン勉強会です。

勉強会では、参加メンバーが実際の業務で行うことを題材に実施しました。CursorでMCPとBrowser Automationを使って作業をAIで実行し、次からはコマンド一発で自動化できるところまでを体験してもらいました。

大事にしたのは、単に手順をなぞってもらうことではありません。

「自分の週次レポート作成にも応用できそう」

「この流れなら、いつも手作業でやっている確認作業を自動化できそう」

業務が1つ自動化できたこと、他の業務にも活用できそうなイメージを持ってもらうことでした。

参加者からは、「活用できそう」「こんなことができるなんて知らなかった」「感動」「衝撃」といった感想をもらいました。さらに、その後は各メンバーが、自分で作った自動化手順(Skill)を共有するようになりました。

自分の業務を自動化するだけなら、個人の効率化で終わります。でも、自動化手順を残して共有すれば、他の人が見て学び、似た業務に応用できます。そうなると、知見が個人の中に閉じず、組織の中を流れ始めます。

同じ考え方は、お客様からの問い合わせサポートを担当する方々への支援でも使えました。DevinやGemini in Chromeのスキルを、そのまま「便利なAIツール」として紹介するのではなく、仕様確認やエンジニアへの依頼文作成など、問い合わせ対応の中で時間がかかっている作業に当てはめて、使いやすいプロンプトや手順に置き換えました。

どちらの取り組みでも大事だったのは、AIツールの機能説明から始めないことでした。

「AIを使えば便利です」と伝えるだけでは、なかなか業務は変わりません。

まず相手の仕事を聞く。毎週やっている作業、手作業で時間がかかっている確認、エンジニアに依頼するときに毎回悩んでいる文章作成。そうした具体的な業務に当てはめて初めて、「それなら自分も試せそう」と思ってもらえます。

おすすめアクション：自分が詳しくなりきってから勉強会を開こうとせず、まずは知見を届けたい相手に、毎週やっている作業や少し面倒に感じている作業を聞いてみる。自分が試したことや教えてもらった方法が役立ちそうなら、相手の具体的な業務に置き換えて、一緒に小さく試してみる。

5. まとめ：自分の現場の学びを、次の人が試せる形にする

ここまで書いてきたことに共通しているのは、学びを自分の中に閉じ込めず、次に試す人へ渡すことです。

自チームで試して分かったことを、発信して認知をつくる。反応してくれた人と1on1で話す。相手の困りごとを聞き、そのままでは使いにくい知見を、相手の仕事で使える形に変える。

大事なのは、正しいノウハウをそのまま渡すことではありません。

「うちではこういう困りごとがあった」

「まずここだけ試した」

「ここはうまくいったけれど、ここは合わなかった」

「あなたのチームなら、この部分だけ小さく試せるかもしれない」

そうやって、相手が自分の現場に置き換えられる形で渡すことです。

発展例として、私の場合は「Best Team Award」という横断イベントも試しました。同じプロダクトを開発する複数チームで、各チームが最近試したことや学んだことを短く共有し、参加者がSlackで感想を書き、最後に良かったチームを投票で称賛する場です。

ポイントは、進捗報告会ではなく、知見と称賛を流通させる場にしたことでした。聞くだけの会議にせず、感想を書く、投票する、称賛するという小さな参加の動きを入れました。また、最初から継続前提にはせず、「まずは1回だけ試してみて、良さそうなら続けましょう」と提案しました。

詳しいやり方は、以前の記事「複数チーム間で楽しく知見を共有して称賛するイベント Best Team Award のやり方」に書いています。ここで伝えたいのは、いきなり大きな仕組みを作ることではありません。身近な数チームでも、学びを共有し、反応し、称賛する場を小さく作ると、知見がチームの外へ流れやすくなるということです。

もちろん、最初から横断イベントを作る必要はありません。

まずは、自分のチームで最近少し良くなったことを一つ書き出すだけで十分です。何に困っていて、何を試し、どこでつまずき、何を変えたら少し前に進んだのか。

それをSlackに短く書く。チームの定例で話す。興味を持ってくれた人と1on1で話す。反応があれば、相手の状況を聞いて、「そのまま使うなら難しそうだけど、こう変えれば使えるかもしれませんね」と一緒に考える。

この記事で書いたことも、最初からうまくいった話ではありません。

良い取り組みを紹介しても広がりませんでした。自分自身の過去にも、黒歴史と呼びたくなる失敗がありました。

それでも、なんとかしたくて試行錯誤しました。自チームで試し続け、現場の知見を増やす。発信で認知をつくる。個別対話を重ねる。相手の困りごとに合わせて知見を渡す。

そうやって、自分の現場で起きたことを言葉にし、誰かが試せる形で渡していくと、少しずつ反応が返ってきます。

もしこの記事を読んで、「自分にも何か発信できることがあるかもしれない」と思ってもらえたら、とても嬉しいです。

大きな成功談でなくてもいいと思います。うまくいかなかったことでもいい。誰かに助けてもらいながら、少しだけ状況が良くなった話でもいい。

価値があるのは、あなたの現場で実際に何が起き、何を試し、何を変えたら少し前に進んだのかという具体的な話です。

権限がなくても、横の影響力はつくれます。

その最初の一歩は、自分の現場で何を試し、どう変わったのかを、誰かが次に試せる形で言葉にすることです。

おすすめアクション：うまくいかなかったこと、少しだけ前に進んだこと、誰かに助けてもらいながら試したこと。あなたの現場で起きたその物語には、同じように悩んでいる誰かを動かす力があります。だからぜひ、あなたの物語を、誰かが次に試せる形で発信してみてください。