この記事の初出は、Software Design 2023年1月号です。

はじめに

「ハピネスチームビルディング」では、新しい技術・ツール・プラクティスを積極的に試行して、得た知見をアウトプット(技術記事で情報発信)する事を繰り返して、皆で楽しく成長する事を目指しています。
その中でポイントになるのが、記事を書く習慣を身につける事です。

この活動を始める前、私のチームは私を含めて全員が技術記事を書いた経験がありませんでした。
そしてチームのメンバーは、記事を書く事にハードルや不安がありました。
その状態から、全員が記事を毎月書き続けられるようになった方法を紹介します。

記事を書くハードルを下げる

成長するための1つの施策として、皆で技術記事を毎月書く事にトライしてみようとなったものの、メンバーは記事投稿に対して高いハードルを感じていました。
それは「書こうと思った事と同じ内容の記事がすでに世の中にあるので、書くネタがない」ということでした(ちなみに、その後、技術記事の投稿経験のない社内の若手20人に聞いたところ、記事を書かない理由で最も多いのがこれでした)。

そこでいろいろ調べて分かった事は「自分なりの視点で書いた記事なら、どんな記事も価値がある」という事です。
この考え方を説明するために、具体例となる記事として下図を参照ください(私の後輩の記事です)。

この記事内容は「C#の初心者の視点」で「C#の型スイッチ」という機能を説明した記事です。
同じ内容を扱った記事は、世の中にすでに存在しますが、記事内に書かれている「この機能は地味だけど意外と便利でオススメ」という初心者ならではの視点が、同じ初心者にとって価値があるかもしれません。
そもそも人により前提知識が異なるため、同じ記事でも「分かりにくい」「得る知見は無かった」と思う人と「分かりやすい」「良い知見を得た」と思う人がいます。
だから、同じ技術を扱った記事でも、それが色んな視点(初心者の視点、熟練者の視点、組み込み開発経験者の視点など)で複数あった方が、より多くの人に刺さる可能性が高まります。
つまり、自分なりの視点で得られた知見を書いた記事なら、どんな記事も世の中に貢献していると言えます。

その考え方をチームのメンバーに伝える事で、記事投稿のハードルを下げる事ができました。

業務と平行して記事を書く環境作り

記事を書く事のハードルが下がっても、メンバーの不安はまだありました。
それは、記事を書くのに時間がかかりそうだから、業務と並行して記事を書き続けられるかということです。

これに対しては、記事を書く意義を皆で共有しました。
例えば、記事を書く過程でその技術の理解が曖昧だったことに気付け、調査しながら書くことで確かな知識を得られます。
もし記事を書かなければ、曖昧な理解のまま間違った使い方をしてしまうリスクがあると考えました。
また、記事を書いてアウトプットしながら成長する方が、長期的にはチームの生産性が高まると考えました。
よって、記事を書く事は遠回りのようでいて、チームにとって必要な取り組みということをチーム内で共有しました。
その上で、技術記事を書くための学習時間を踏まえて業務の計画を立てるように調整しました。

それにより、業務と平行しながら記事を書き続ける環境を整えることができました。

最初は二人三脚で書く

記事を投稿した事のない若手メンバーが、記事を書き上げるためにはサポートが必要でした。

慣れていないと記事のネタが思いつかないので、そのメンバーが最近どういう活動をやってきたか一緒に振り返った上で、一緒に記事を書くネタを考えました。
例えば、最近学習したデザインパターンの用途やメリットを自分なりの視点で書くと理解が深まるのではと提案したり、業務で調査中のライブラリについて分かった事や自分なりに使えそうだと思った用途を書いてはどうかと提案したりしました。

それで書くネタが決まったら、記事を書いてもらいましたが、最初は自信がないということで、下書きの記事を見せてもらいました。
下書きに対しては、内容が間違っていないかと読み手が概ね理解できるかだけをチェックして、それ以上のクオリティは求めずに、とにかく投稿してもらう事を優先しました。
投稿完了したらポジティブフィードバックを必ずしました。

最初の数ヶ月はこれを毎月繰り返すことで、全員が毎月記事を投稿できました。

記事を書き続ける事で起きた変化

私自身も、それまで記事を書いていなかったため、記事を書くことで様々な気付きがありました。

まず痛感したことは、今まで自分は技術記事を読んで、分かった気になっていたということです。
人に説明しようと思って記事を書いてみると、実は全然理解できていなかったということに気付きました。
記事を書きながら理解し直すことで、やっとそれが「使える知識」になりました。
だから技術記事を書くことで「その技術を理解して自分が成長できる」という事を実感できました。

また、技術記事を書く前は、私はなんとなく情報をインプットしていましたが、自分で記事を書くようになると、それが大きく変わりました。
無意識のうちに「人に説明するために自分なりの解釈」をしようと試みながら情報をインプットするようになりました。
アウトプットする前提でインプットするので、それまでよりも情報を理解する効率が上がりました。

それと、以前は記事を書く人に対して興味を持ちませんでしたが、自分が記事を書く経験を積むと、たくさん読まれる記事を書く人に興味を持つようになり、他にどんな記事を書いているかが気になって興味を持って記事を読むようになりました。
つまり、記事を書く事で、記事を読むことが楽しくなり、そのおかげでより多くの情報を楽しく理解できるようになりました。

このような変化は、程度の差はあれ、メンバーそれぞれにもあったようで、記事を書き続けることでやっとその意義が実感できました。

アウトプット状況の可視化

アウトプットの状況を全員に見えるようにするために、月初に先月の各自の記事の投稿件数やいいねの件数が、自動で通知される仕組みを作りしました。
月初の朝会にて「先月は全員2件投稿できて凄いですね」などのフィードバックをしています。
状況が可視化されてフィードバックがある事で、一部のメンバーの記事を書くモチベーションが上がりました。

初心者を勇気付ける情報

私のチームには、新入社員がよく配属されます。
経験の少ない初心者の場合、自分の書く記事が、他の人にとって迷惑にならないかを心配してしまう事もあります。
そういう人には、以下の勇気付ける情報を提供しています。

世の中には「自分にとって価値の低い記事が増えると、自分にとって価値の高い記事の検索性が下がる」とネガティブなことを言う人もいます。
そこで私は過去に下図のようなアンケートを匿名で実施しました。

その結果、私のエンジニア仲間106人中100人(94%)が 1 の「適切な情報を探すのは探す方の責任」を選択しました。
だから、初心者でもまずは自分なりの視点で自分の学んだ事を書けば良いと思います。
最初はあまり人の役に立つ記事が書けなくても、経験を積んで成長すれば、きっと多くの人に貢献する記事が書けるようになると思います。

まとめ

最初の頃は、毎月サポートしながら記事を書いてもらっていましたが、記事を書く事を継続しているうちに、メンバーは自分で成長を実感し、主体的に記事を書くように変わっていきました。
そのため、まずは記事を書くのを続けてみる事をお勧めします。

連載「ハピネスチームビルディング」の次回の記事はこちら↓

前回の記事はこちら↓