業務改善について他チームに共有しても「いい話でした」で終わってしまう
小島氏には、5年以上抱えていた悩みがある。「新しいツールで効率化できた」「タスクの進め方を見える化した」といった自チームの改善を他チームに紹介すると、「いい話でした」と称賛され、Slackにもリアクションがつく。しかし、次の日にそれを試してくれることはない。「どうして試してくれないんだろう」「やればよくなるのに」。そう思う日々が続いていたという。
だが、そうなってしまう原因は自身の「届け方」にあったと小島氏は気づく。相手の困りごとを知らないまま、自分のチームでうまくいった解決策を押し付けていただけだったのだ。どのチームにも固有の課題や優先順位がある。今の困りごとに直接つながらなければ、試す理由にはならない。そもそも「誰に相談すればいいかわからない」といったハードルがあり、実際にやってみるには労力が必要だ。そのため、良い取り組みでも「いい話でした」で終わりやすい構造になっていたのである。
小島氏が弥生に入社したのは、約1年前、2025年6月のことだ。配属されたのはすでにスクラムマスター、PdM、デザイナー、エンジニアといった役割が揃ったスクラムチーム。小島氏はそこに新しく加わった「1人のエンジニア」だった。肩書はエンジニアリングマネージャーだが、組織図上は一エンジニア扱いで、特別な権限は何もない。ボトムアップでやっていきたいという思いから、あえてそのような形で加わることを選んだという。
「いい話」を「使われる知見」に変える4つのステップ
そんな1人のエンジニアとしての歩みの中で、前職時代も含め5年以上に及ぶ試行錯誤の末に見つけたのが、「使われる知見」に変えるための道筋だった。「自チームで試し続けて現場の知見を増やす」「発信で認知をつくる」「個別対話を重ねる」そして「相手の困りごとに合わせて知見を渡す」。良い取り組みは押し付けではなく、この4つのステップを踏むことで相手から相談される知見へと変わっていくという。小島氏は、弥生でのこの1年間、実際にこの4つのステップを実践してきた。
その結果、小島氏には個別に相談してくれる人が20人以上、紹介した知見を活用してくれたチームが10チーム以上生まれた。自チームで試した朝会や振り返りの工夫が他チームでも試され、「教えてもらった方法でうまくいきました」といった感謝の声も届くようになったという。権限を持たない1人のエンジニアが、なぜここまで横に影響力を広げられたのか。その具体的な方法を紹介する。
