一人のエンジニアから始める、横の影響力のつくり方 ～チームを越えて知見を広げた1年の物語～

一人のエンジニアから始める、横の影響力のつくり方 ～チームを越えて知見を広げた1年の物語～ 2026/07/17 Developers Summit 2026 Summer 弥生株式会社 エンジニアリングマネージャー(EM) 小島優介

自己紹介 名前：小島 優介 (@kojimadev) 所属：弥生株式会社(1年前に入社) 職種：エンジニアリングマネージャー(EM) 社外活動： 「ハピネスチームビルディング」をテーマに発信 Developers Summit 2020 KANSAI ベストスピーカー賞1位 Microsoft Build 2022 スピーカー ITエンジニア向け月刊誌「Software Design」にて3年間連載 Qiita で 20,000 Contributions の記事投稿

• https://x.com/kojimadev

Agenda 1. 良い取り組みが「いい話でした」で 終わってしまう 2. 自チームで試し、生きた知見をつくる 3. 発信で、相談される入口をつくる 4. 個別対話を起点に、困りごとに合う知見を渡す 5. 組織の学習速度を上げることも事業貢献 6. まとめ

良い取り組みが「いい話でした」で終わってしまう 新しいツールで タスクの 効率化できた！ 進め方を 見える化！ 発表して紹介！ 他のチームにも 役に立つので 試してくれるはず！ 「いい話でした」と称賛 Slackでリアクションもつく しかし・・・ 次の日、それを 試してくれることはない 「どうして試して くれないんだろう？」 「やれば良くなるのに」 （5年以上、そう思っていた）

試してもらえない理由は届け方にあった 相手の困りごとを知らないまま、 自分のチームでうまくいった解決策を 押し付けていただけ どのチームにも課題や優先順位がある 困っている問題につながらなければ 試す理由にはならない 今の進め方を変えてよいのか、誰に相談すればよいのか 良さそうだけど、今の自分たちにはどう使えばいいか分からない

「いい話」から「使われる知見」へのステップ 何年間もの試行錯誤の結果 使われるための届け方を発見 4. 相手の困りごとに 合わせて知見を渡す 3. 個別対話を重ねる 2. 発信で認知をつくる 1. 自チームで試し続け、現場の知見を増やす

使われる知見へのステップを実行した結果 今の会社に入社してから1年 • 個別に相談してくれた人：20人以上 • 紹介した知見を活用してくれたチーム：10チーム以上 以下のようなことがあり、とても嬉しい • 自チームで試した朝会やふりかえりの工夫が他チームでも試される • 発信を見た人から相談をもらう • 他チームの人から、後日に感謝の言葉をもらう 「教えてもらった方法でうまくいきました」 「あのやり方、うちのチームでも使えました」

一人のエンジニアが再現できる方法を紹介 「いい話でした」で終わる状態から抜け出すために 実際にやったことを、できるだけ再現しやすい形で紹介 なんの権限もない一人のエンジニアでもできること このやり方を再現すれば 良い取り組みを他チームでも試してもらえる状態に近づける 他チームの次の一歩に関われるようになり 働いていてとても楽しい

Agenda 1. 良い取り組みが「いい話でした」で 終わってしまう 2. 自チームで試し、生きた知見をつくる 3. 発信で、相談される入口をつくる 4. 個別対話を起点に、困りごとに合う知見を渡す 5. 組織の学習速度を上げることも事業貢献 6. まとめ 知見を広げるためには、現場の生きた知見を多く持つ必要があるので そのための土台づくりの話から紹介

自チームで試し、生きた知見をつくる必要性 良い取り組みを他チームに広げるには 自分自身が、現場で泥臭く掴んだ生きた知見を多く持つ必要がある きれいに整理された一般論でなく 実際に自分のチームで試して、どんな条件でうまくいき、 どんな条件では合わなかったのか、現場で試したからこそ分かる知見

1年前(2025年6月) 弥生株式会社に入社 配属されたのはスクラムチーム すでにスクラムマスター、PdM、 デザイナー、エンジニアなど 必要なロールは揃っていた 私は、新しく入ってきた 「一人のエンジニア」 （肩書はEMだけど 組織図上はエンジニア扱いで 特別な権限は何もない） SM PdM デザイ ナー エンジ ニア エンジ ニア エンジ ニア エンジ ニア エンジ ニア エンジ ニア エンジ ニア

自チームで小さく試す この1年でやってきたことは、エンジニアとして開発業務をしながら 朝会のやり方を少し工夫したりなどの小さな改善提案 たくさん試行して「現場で試した知見」を蓄積 他チームに知見を渡すとき、一般論だけだと 「いい話でした」で終わりやすい 自分の現場で起きたことまで含めて話せると共感してもらいやすい (参考：私が過去に試したプラクティスはこちらで30件以上を公開)

• https://note.com/kojimadev/m/me68d438e12d4

この章でのおすすめアクション • まず自分自身が、生きた現場の知見を多く持つ そのために、自チームで小さく試せる改善を提案してみる

Agenda 1. 良い取り組みが「いい話でした」で 終わってしまう 2. 自チームで試し、生きた知見をつくる 3. 発信で、相談される入口をつくる 4. 個別対話を起点に、困りごとに合う知見を渡す 5. 組織の学習速度を上げることも事業貢献 6. まとめ

3. 発信で相談される入口を増やす この章では以下の4つを紹介 1. 2. 3. 4. 発信は、導入ではなく認知をつくる 認知は、小さな発信の積み重ねでつくる 強く学んだことは、発表の形で届ける 黒歴史物語：失敗談は距離を縮める

大人数に発信しても、すぐには変わらない 自チームで試したことをSlackチャンネルに投稿、社内LTで発表 このような大人数(数百人)への発信で 他チームのやり方が変わることは少ない

大人数への発信の役割は認知づくり 各チームにはそれぞれの事情、困りごと、優先順位がある 「良い取り組み」と紹介しても 今の困りごとと接続しなければ、すぐに試さないのは自然 「いい話でした」で終わる → 全く失敗ではない × 誤った期待 ○ 本当の役割 発信する → すぐ導入される 発信する → 認知(相談の入口)

発信は、未来の相談のための種まき この人はこういうことを考えて色々試している、困ったら相談できそう と思ってもらえる入口を増やすことが発信の役割 発信により 「これに詳しい人」 という認知を作る 他チームの人が 類似の課題に直面 「あの人が何か 試していたな」 と思い出し相談

3. 発信で相談される入口を増やす この章では以下の4つを紹介 1. 2. 3. 4. 発信は、導入ではなく認知をつくる 認知は、小さな発信の積み重ねでつくる 強く学んだことは、発表の形で届ける 黒歴史物語：失敗談は距離を縮める

認知は、小さな接点を何度もつくる方が効く 認知をつくるには、一度だけ大きく発信するよりも、 小さな接点を何度もつくる方が効く • • • • • 自チームで試して成功した施策をSlackで紹介 社外発信した記事やスライドをポイントを添えて紹介 社内LT大会 部署での定例会議での発表 全社員向けのイベントでの発表

例：Notionでチケット管理を試した時のTips投稿 些細な知見でOK ポイントは他の人が再現 できる情報を添えること

社外発表は認知を広げる良い機会 以下のような社外イベントでの発表予定も社内のSlackで紹介 • スクラムフェスで発表 • 日経新聞社主催のイベントに招待されて発表 • Qiita FM でゲスト出演してPodcastで公開 社外発表する ＝ そのテーマについて一定の経験や知見を持っている と社内の人に思ってもらいやすい そのテーマで困っている人がいたときに 「この人に聞けば何かヒントがあるかも」になりやすい

社外発表予定を投稿する例 発表予定だけでなく、なぜ挑戦したのか、 どんなテーマで発表するのかも添えて投稿

大事なのは「何度も目にする状態」 × 目立つ場所での発信 ○ 日常の接点を増やす 1回だけの注目は効果小さい 自分が何を試し、何に困り、 何を学んだかを繰り返し発信 身近な一歩 • Slackで小さなTipsの紹介 • 社内LT • 社外記事やスライドの共有 「この人は、この分野で色々試している人だ」という認知をつくる

3. 発信で相談される入口を増やす この章では以下の4つを紹介 1. 2. 3. 4. 発信は、導入ではなく認知をつくる 認知は、小さな発信の積み重ねでつくる 強く学んだことは、発表の形で届ける 黒歴史物語：失敗談は距離を縮める

強く学んだことは、発表の形で届ける 記事に書いて共有するだけでは、背景や温度感までは伝わりにくい カンファレンスに参加したときは、その内容の中で 社内で活用できそうな知見に厳選して発表するのがオススメ

発表だから伝わるものがある 記事(テキスト) 発表 消費のされ方 流し読みされやすい 時間と場を共有し、 集中を生む 伝わる情報 知識のみ 知識＋声の温度＋人物像 「ふーん、なるほど」 「この人はこのテーマに 本気なんだ」 受け手の印象 発表の最大の価値は、「知識」でなく「熱量」を届けること

カンファレンスの学びを発表する時の告知例 開発組織全体(約300人)に対して、任意参加の45分の会議案内を送信

発表を聴くメリットを伝える 「学んだことを発表します」でなく その発表を聴くことで何を持ち帰れるのかを伝える 発表を見てもらい、集中して聴いてもらうには聴くメリットが重要 前述の例では、約100人が参加し、発表後には 「紹介された施策を試してみたい」という声もあり 発表を通じて、自分がどんな課題意識を持っているのか伝わると 「このテーマで困ったら、この人に聞いてみよう」の可能性が上がる

3. 発信で相談される入口を増やす この章では以下の4つを紹介 1. 2. 3. 4. 発信は、導入ではなく認知をつくる 認知は、小さな発信の積み重ねでつくる 強く学んだことは、発表の形で届ける 黒歴史物語：失敗談は距離を縮める

AI時代に価値を持つ知見とは × 教科書的な一般論 ○ 自分だけの生きた話 AIを使えば瞬時に 手に入るきれいな知識 実際に試し、悩み、体験した、 あなたにしか語れない話 AIから得られない、個人の泥臭い体験が価値を持ち それは聞き手の心を動かせる

失敗談には、距離を縮める力がある 成功談 失敗談 相手の反応 「すごい」 「参考になる」 「分かる」 「自分もやりそう」 心理的距離 「その人だからできた」 「うちとは状況が違う」 尊敬するが一歩引く 自分ごとに感じやすく 親近感が湧きやすい 失敗談には、同じ落とし穴を避けるための「共感の力」がある

私自身の痛切な「失敗」 私自身、チームマネジメントで数々の失敗をしてきた 1. レビューで何十件も指摘して、相手を自信喪失させてしまう 2. 会議で発言しない人に対し「発言しない方に原因がある」と 思い込んでいた(本当は自分が原因) 3. ペアプログラミングで、自分の方が分かっていると思い、 相手の意見を素直に受け入れられなかった これらは、とても恥ずかしい過去 しかし、この失敗談にこそ、失敗回避の知見が詰まっている

失敗を「ノウハウ」ではなく「物語」にする この恥ずかしい失敗を、より興味深く読んでもらうために 単なるノウハウ記事ではなく、ラノベ風の物語にして社内で月間連載 無味乾燥な記事 「黒歴史物語」 自分の黒歴史をさらし、どう考えどう改善したのか物語に

正解を教えるのでなく、失敗の過程を一緒に追体験 過去の自分が何を考えていたか なぜその行動をしてしまったのか 結果、何が起きたのか(悲惨な結果) 後から振り返り、どこが間違っていたか どう考え方を変えたのか(新たな気付き)

記事タイトルも、読みたくなる形に ・第1話「自信喪失させるレビューの闇」 ・第2話「自分でやった方が速いという呪いを解くモブワーク」 ・第3話「会議で発言してもらえない原因は私だった」 ・第4話「こんな事も知らないの？とマウントしていた私」 ・第5話「教えているつもりで考える機会を奪っていた」 過去の自分の失敗がそのまま見え、 何が起きたのか気になる 第1話のアイキャッチ画像 (私の写真をAI加工したもの)

第1話「自身喪失させる レビューの闇」の冒頭

黒歴史物語をSlackチャンネルで全社員に告知 「自分の方が上だと思い込む」 「残念なペアプロしていた」 という、自分の失敗が 見える導入を書き、興味を持っ てもらいやすい形で紹介

開発組織以外の方々からも多くの反響 「胃が痛くなった」「指摘する側として耳が痛い」 「自分も同じことがあるなと思った」 → 失敗談が、読み手自身の経験や振る舞いに重なった さらに 「無意識の思い込みがないかを考えるきっかけになった」 「自分も気を付けようと思った」 「自分の失敗談を発信することにも挑戦してみたい」 → 読んだ人の心が少し動き、次の行動や内省につながったことは 失敗の物語として届けたからこその効果

あなたの失敗の物語も公開しましょう 「自分も似たことをしているかも」と思える失敗は、 教科書的な解説記事より、興味を持たれ共感されやすい もし自分の中に「昔の自分はこう失敗した」と思える経験があるなら それを社内で物語として公開してみることをオススメ 恥ずかしい失敗談ほど、同じように悩んでいる誰かに届く

黒歴史物語の原稿提供のご案内 とはいえ、失敗の物語を書くのは難しいと思います 参考にできるものがあった方が書きやすいため 社内限定での共有や、私の原稿をベースに自分の失敗談へ置き換えて 社内向けに公開する用途であれば、相談いただければお渡しできます XアカウントにDM いただければ提供します @kojimadev (リンクはこちら)

• https://x.com/kojimadev

この章でのおすすめアクション 1. 大人数への発信は「このテーマなら相談できそう」と 思ってもらうために行う 2. 認知は一度の大きな発信ではなく、小さな発信の積み重ねで作る 3. 社外イベントや記事で強く学んだことがあれば発表する 4. 自分の失敗談を公開する

Agenda 1. 良い取り組みが「いい話でした」で 終わってしまう 2. 自チームで試し、生きた知見をつくる 3. 発信で、相談される入口をつくる 4. 個別対話を起点に、困りごとに合う知見を渡す 5. 組織の学習速度を上げることも事業貢献 6. まとめ

4. 個別対話を起点に、困りごとに合う知見を渡す この章では以下の3つを紹介 1. まず1on1で、相手の困りごとを知る 2. 他チームのふりかえりに学びに行く 3. 教わった知見を、相手の仕事で使える形にする

認知を広げたら、次は1対1の関係性につなげる 発信だけでは、相手のチームの状況は理解できない 実際に知見を受け取ってもらうには 相手が何に困っているのか、どんな状況か知る必要がある 発信でできた小さな接点を、1対1の対話につなげる 待っているだけで連絡が来るとは限らない 自分から1対1で話せる機会をつくっていく方が大事

自分から1対1で話せる機会をつくる 相手が自分に興味を持ってくれている方が話を始めやすいため 社内Slackへの投稿や社内発表の反応から見て 自分に興味を持ってくれたと思える人に、思い切って1on1を打診 (私の場合はオンラインで30分の1on1を実施) あとは、出社イベントなどで知らない人に積極的に話しかける 社内発信により「あの投稿を見ました」「発表、面白かったです」 と言ってもらえることがあり、そういう小さなきっかけがあると、 初対面でも話がはずみやすい

話したことない人に1on1を打診する例 1on1を打診するときのDMの例 「先日は発表を聴いてくださって、ありがとうございます ○○さんのチームについて興味があります どんな感じで開発しているのかお聞きしたいです 良かったら、 一度30分枠で1on1をお願いできないでしょうか？」 1対1で、相手の困りごとを聞き、自分の考えも知ってもらう

4. 個別対話を起点に、困りごとに合う知見を渡す この章では以下の3つを紹介 1. まず1on1で、相手の困りごとを知る 2. 他チームのふりかえりに学びに行く 3. 教わった知見を、相手の仕事で使える形にする

関係性ができたら、ふりかえりに参加する 1対1で関係性ができたら、チームの会議へ参加させてもらう 「もしよければ、勉強させてもらいたいので、 チームのふりかえりに参加させてもらえませんか」と相談する 朝会、モブプログラミング、ふりかえりなど、いろいろな活動に 参加させてもらったが、特に学びが大きかったのが「ふりかえり」 そのチームが何に取り組んで、何に困って、何を試しているのか見える それが自チームに活用できる学びになることも多い

チームの良いところを見つけて言語化する 参加した会議で、そのチームの良いところを 見つけて言語化して伝える 「感謝の内容を凄く具体的に伝えるの素晴らしい」 「にぎやかしスタンプを皆でしていて素晴らしい」 (1時間の会議なら10件くらい見つけたい) そのチームが自分たちの取り組みの価値を再認識できる こちらも相手から学ぶ人として関われる 良い点を適切に言語化することを通して自身の学びも深まる

知見は、相手が選べる形で渡す ふりかえりの中で助言を求められたときや チームの人たちが困っていることが見えたときに もし参考になればという形で、自分の持っている知見を提供する 「自分のチームでは、これを試してみて効果ありました。 チームによって合う合わないがあるので、試しに2週間くらい やってみて、いまいちだったらやめれば良いと思います」 と伝えると、相手のチームが自分たちで選べ、提案が重くならない (ふりかえりはチームのアクションを決める場なので採用されやすい)

4. 個別対話を起点に、困りごとに合う知見を渡す この章では以下の3つを紹介 1. まず1on1で、相手の困りごとを知る 2. 他チームのふりかえりに学びに行く 3. 教わった知見を、相手の仕事で使える形にする

多職種の方々に役立ちそうな知見を見つける ふりかえり参加などの関係性の中で、知見を教わることが多い たとえば、教わった知見の中で、AIエージェントを用いた業務自動化は エンジニア以外の多職種の方々にも役立ちそう (PdM、PjM、お客様向けにコンテンツ作成やサポートする方々)

熟練者でなくても、一緒に試してみることは可能 自分はAIエージェントによる業務自動化の熟練者ではない 「こういう使い方ができますよ」と教えてもらった立場 それでも、相手の業務で使えそうな形に置き換えて 一緒に試してみることは可能 多職種のメンバーの中で、AIエージェントの活用に距離がある人もいる それらの人に声をかけ、小さく試せる場を作る

AIエージェントによる自動化のハンズオン勉強会 事前に参加メンバーの業務内容を教えてもらった上で 勉強会で、実際の業務を題材にする AIエージェント(Cursor)でMCPとBrowser Automationを使って その作業を実行してもらう 次からはコマンド一発で自動化できるところまでを体験 × AIエージェントの説明 ○ 相手の業務に寄り添う MCPやBrowser Automationで 色んな作業を自動化できます (エンジニア向けの説明) 実際の業務を教えてもらって、 その業務を自動化することを 実際にやってもらう

すぐに業務に使えるやり方を伝える効果 業務が1つ自動化できたことで他にも活用できそうなイメージを 持ってもらえる 「自分の週次レポート作成にも応用できそう」 「手作業でやっている確認作業を自動化できそう」 実際に翌日に毎週のレポート業務を自動化したメンバーもいた

この章でのおすすめアクション 1. 自分の発信に反応してくれた人に、まず1on1をお願いしてみる 2. 1on1を起点に、ふりかえりに参加させてもらう 参加時は、そのチームの良い点を見つけて伝える そのチームの困りごとに役立ちそうな知見があれば渡してみる 3. エンジニア以外の多職種の業務内容を聞いてみる 役立ちそうなら、相手の業務に置き換えて、一緒に試してみる

Agenda 1. 良い取り組みが「いい話でした」で 終わってしまう 2. 自チームで試し、生きた知見をつくる 3. 発信で、相談される入口をつくる 4. 個別対話を起点に、困りごとに合う知見を渡す 5. 組織の学習速度を上げることも事業貢献 6. まとめ

組織の学習速度を上げることも事業貢献 今回のデブサミのテーマは「事業貢献」 組織の学習速度を上げることも エンジニアにできる大事な事業貢献 あるチームが試したことを別のチームが知る 別のチームが、自分たちの状況に合わせて少し変えて試す その結果をまた共有する この循環が速くなれば組織全体で学習速度が向上 (組織全体のパフォーマンス向上)

組織の学習速度を上げる横断イベントの例 「Best Team Award」 5チーム横断で、各チームが最近試したことや学んだことを 30分枠の中で5分ずつで発表し、参加者がSlackで感想を書き、 最後に良かったチームを投票で称賛する場 進捗報告ではなく、知見と称賛を流通させる 聞くだけの会議にせず、感想を書く、投票する、称賛するという 全員に参加の動きを入れる Best Team Award のやり方の詳細はこちらの記事を参照

• https://qiita.com/kojimadev/items/f988b6e17cd82ab1fb30

小さなことを、自分だけの改善で終わらせない いきなり大きな仕組みを作ろうとしなくてもいい 小さな行動でも、誰かの次の一歩に繋がることがある 自チームの 良くなったことを 書き出してみる なぜ良くなったのか 何を試したのかを 発信する 興味を持って くれた人と 関係性をつくる

前に進めたのは、受け入れてくれた人たちがいたから まだ道半ばで、うまくいっていないこともある 少しずつ試してくれるチームが増え、相談してくれる人が増え、 発信を受け取ってくれる人が増えてきた それは、社内の方々が温かく受け入れてくれたおかげ 1年前に入社した私の提案を、試してくれたチームメンバー、 横断イベントに協力してくれた他チームの方々、 発信に反応してくれた方々、1on1などでお話してくれた方々、 困りごとを率直に教えてくれた方々のおかげで前に進めた

Agenda 1. 良い取り組みが「いい話でした」で 終わってしまう 2. 自チームで試し、生きた知見をつくる 3. 発信で、相談される入口をつくる 4. 個別対話を起点に、困りごとに合う知見を渡す 5. 組織の学習速度を上げることも事業貢献 6. まとめ

使われる知見へのステップをやった結果 「教えてもらった方法でうまくいきました」 と言ってもらえて嬉しい 4. 相手の困りごとに 合わせて知見を渡す 3. 個別対話を重ねる 2. 発信で認知をつくる 1. 自チームで試し続け、現場の知見を増やす

AI時代に価値があるのは、あなたの物語 現場を助けるために必要なのは きれいに整理された正解だけではない 現場で何を試したのか 何に失敗したのか どう人を巻き込んだのか 何を変えたら、少し前に進んだのか そういう、その人にしか語れない物語

物語は知識を得るだけでなく心を動かせる 誰かの具体的な物語に触れると、知識を得るだけでなく共感できる 「自分も似たところでつまずいている」 「この人も、最初はうまくいかなかったんだ」 「このくらい小さく始めてもいいんだ」 私も最初は良い取り組みを紹介しても誰にも広がらなかった 自分自身の過去にも、黒歴史と呼びたくなる失敗があった この発表は、それでも、なんとかしたくて試行錯誤してきた物語

ぜひ、あなたの物語を発信しましょう もしこの発表を聴いて 「自分にも何か発信できることがあるかもしれない」 と思ってもらえたら、とても嬉しい 小さく試したことでもいい うまくいかなかったことでもいい 誰かに助けてもらいながら、少しだけ状況が良くなった話でもいい あなたの物語は、同じ悩みを持つ誰かにとって、価値ある知見になる

まとめ あなたの物語には価値がある 誰かが次に試せる形で、あなたの物語を発信しましょう