発信で他チームはすぐに変わらない、だが「認知」はつくれる
まず土台となるのが、自チームで小さく試して「生きた知見」を蓄積することだ。きれいに整理された一般論ではなく、自分のチームで試して、どんな条件でうまくいき、どんな条件では合わなかったのかといった、泥臭く試行錯誤したからこそ得られた知見をためておく。小島氏はこれまで30件以上のプラクティスを試してきた。これらは社内にとどまらず、小島氏自身のnoteでも公開されている。
次に重要なのが「発信」の捉え方だ。数百人が見るSlackチャンネルに投稿したり、社内会議で発表したりしても、それだけで他チームのやり方がすぐに変わることは少ない。しかし、それは失敗ではないと小島氏は話す。「発信する→すぐ導入される」ではなく「発信する→認知をつくる」ことこそが、発信の本当の役割だという。
発信は、いわば未来の相談のための種まきだ。発信によって「この人はこれに詳しい」という認知をつくっておけば、他チームの人が類似の課題に直面したときに「そういえばあの人が何か試していたな」と思い出し、相談してもらえたり、それまでの発信を見返してもらえたりする。ポイントは、一度の大きな発信ではなく、小さな接点を何度もつくることだ。例えば、NotionでJiraのようなチケット管理をする際、完了日を自動設定するTipsをGIF動画つきでSlackに紹介する。そのような些細な投稿でも構わない。大切なのは、他の人が再現できる情報を添えておくことだ。
社外での発表も認知を広げるチャンスになる。小島氏は社外イベントへの登壇を事前に社内へ告知する際、発表予定だけでなく「なぜ挑戦したのか」「どんなテーマで発表するのか」も添えるようにしている。社外で発表している事実自体が、「あの人はこのテーマなら知見を持っていそうだ」という認知を強めるからだ。
また、学んだことを強く伝えたいときは、記事ではなくあえて発表の形を選ぶことも重要だという。小島氏があるイベントで学んだ内容を社内に共有した際は、開発組織全体の約300人に向けて任意参加の45分の会議案内を送り、「参加者全員が、明日から試せるプラクティスを1件以上持ち帰ること」をゴールとして設定し告知。結果、約100人が参加し、発表後には「紹介された施策を試してみたい」という声も多く上がったという。
過去の失敗をラノベ風の物語にして社内に公開
発信で相談される入口をつくる取り組みの中で、小島氏ならではの独自性が強いのが、自らの失敗談を物語として公開する『黒歴史物語』だ。
AI時代に価値を持つのは、教科書的な一般論よりも、実際に試し、悩み、体験した、自分にしか語れない話だと小島氏は考えている。中でも失敗談には力がある。成功談は「すごい」「参考になる」と評価される一方で、「その人だからできた」「うちとは状況が違う」と一歩引かれてしまうことがある。それに対して失敗談は「わかるわかる、自分もやりそう」と自分ごとに感じやすく、同じ落とし穴を避けるための共感を生む。
小島氏自身も、レビューで何十件も指摘して相手を自信喪失させてしまったり、会議で発言しない人に対して、発言しない側に原因があると思い込んでいたり、ペアプログラミングで自分のほうがわかっていると思い込み、相手の意見を素直に受け入れられなかったりと、知られたくないほどの恥ずかしい過去がいくつもあるという。
この失敗を、小島氏はラノベ風の物語に仕立て、社内報で月刊連載している。その名も『黒歴史物語』。過去の自分が何を考え、なぜその行動をしてしまい、結果どんな悲惨な事態が起きたのか。そしてそこから何に気づき、どう対策したのか。正解を提示するのではなく、失敗の過程を一緒に追体験できる構成にしているのが特徴だ。第1話「自信喪失させるレビューの闇」、第2話「自分でやった方が速いという呪いを解くモブワーク」、第3話「会議で発言してもらえない原因は私だった」など、記事タイトルも思わずクリックしたくなる形に工夫している。
社内で公開された『黒歴史物語』には、開発組織以外のチームからも大きな反響が寄せられた。「胃が痛くなった」「指摘する側として耳が痛い」といった共感の声に加え、「無意識の思い込みがないかを考えるきっかけになった」「自分の失敗談を発信することにも挑戦したい」という反応もあり、実際に社内発信を始めたエンジニアも現れたという。では、発信で生まれたつながりを、小島氏はその後どのように深めていったのか。
