今回は、エンジニアのアウトプットの重要性について、私の意見をお話しさせて頂きたいと思います。

アウトプットによって得られた3つの気付き

昨今、ブログやセミナーなどでの登壇によって、自身の学習成果や検証結果などを外部に発信するのがブームとなっております。いわゆるこれが「アウトプット」と言われるものです。そして、私自身も積極的にアウトプットしておりますが、その中で、アウトプットによって得られる効果は以下の3つがあるとの気付きを得ました。

知識の確実なインプット
エンジニア同士の相互扶助
自身にとってベストなノウハウ集の構築

アウトプットによる私自身の気付きをここに共有することで、アウトプットしてくれるエンジニアがもっと増えたらいいなという思いを込めて、ここに一筆したためたいと思います。

先に上げた3つの気付きについて、以降、詳しくお話ししたいと思います。

知識の確実なインプット

一見、「インプット」は「アウトプット」と対極を成すもののように思いますが、実はこの2つは、自動車の両輪のように、2つ組み合わせて初めて成立するものだと思っております。

みなさまも経験があると思いますが、自分が理解したと思っている知識でも、いざ人に説明しようとなると、思ったように出来ず、相手が理解してくれなかったということがよくあります。

技術書籍やネット上の文献を読むだけのインプットは、どうしても、自分の都合のいいようにその内容を解釈してしまいがちです。大してちゃんと理解してないのに、どんどん読み進めているなんてことが起こりがちです。

でも、いざアウトプットしようとすると、そんな誤魔化した理解では出来ないのがわかります。
例えば、インプットした内容をもとに、自身で環境構築し、何がしかのアプリケーションを開発してみようとする場合、曖昧な理解では出来ないなのは自明の理です。

「アウトプット」って、誰かのために何かすることだと思われがちですが、もちろんそういう側面もあるのですけど、そうではなく、自分にとってのリターンが一番大きいものだと思っております。

つまり、アウトプット出来ない知識はインプット出来ていないのです。なので、私はインプットした知識は、必ずプログにアウトプットするようなしてます。

エンジニア同士の相互扶助

これは、言わずもがな、アウトプットした知識は他のたくさんのエンジニアにとって役に立ちます。

公式のドキュメントだと、なかなか載っていないようなハマりポイントってありませんか？こういうのこそ、エンジニアはどんどんアウトプットすべきだと思うのです。

この「ハマりポイントの解決策」こそ、現場で悪戦苦闘するエンジニアにしかわからないものであり、そこには技術力の有無は関係せず、どんなエンジニアのアウトプットでも、役に立つこと間違いなしです。

「アウトプット」っていうと、何か重厚長大な物を想像しがちですが、別にそんなものでなくてもいいと思ってます。ちょっとしたハマりポイントの解決策で、とても助かることってありますよね。

例えば、Kubernetesの証明書更新についての、たった数行の以下のブログも、意外にPVがあったりします。

Azure Kubernetes ServiceのNGINX IngressのSSL証明書更新

なので、臆せずどんどんアウトプットしましょう！！

自身にとってベストなノウハウ集の構築

アウトプットをした内容は、その本人にとっての最高のノウハウ集になります。

それは当たり前で、自分が欲した知識や、自分がハマったポイントを書き連ねていますので、どんなベストセラーな技術書籍よりも、自分にとってベストマッチすること間違いなしです。

事実、私は、何か調べごとをしようとしてGoogle検索をしていると、自分の書いたブログにたどり着くことがよくあります(^^;;

オマケ

これは私自身の超個人的な感覚かもしれませんが、アウトプットすることによって得られるフィードバックが、アウトプットの何よりの原動力になっていたりします。手厳しいご意見もありますが、「参考になった」「役に立った」というご意見を頂くと、とても嬉しいですし、また新たなアウトプットしようと思います。このフィードバックが、現在の私のアウトプットの強力なモチベーションになっていたりします。

アウトプットの手段

では、どのようにアウトプットすればいいでしょうか？私のよく実践するアウトプットの方法を3つご紹介させて頂きます。

ブログ

Qiitaやはてなブログなどのブログサービスで、勉強した内容や調査結果を公開する手法です。これが一番簡単なアウトプットの方法です。好きなときに好きなだけアウトプット出来ますし、SNS等で拡散すれば、多くの人に見てもらえます。私は、ブログによるアウトプットが一番多いです。大体、年間100本くらい書きます。

登壇

技術コミュニティなどによるでの登壇により、自身のアウトプットをプレゼンテーションする方法です。30分や60分という長時間のものもあれば、LTと言われる5分や10分という短いものもあります。

いずれにしても、ブログなどとは違い、限られた時間の中で説明しなければならないので、資料をコンパクトにまとめたりという能力や、プレゼンテーションスキルが求められます。

ブログほど頻繁には出来ませんが、フィードバックをダイレクトに受け取ることが出来ることがメリットだと感じています。フィードバックを受け取る手段は、聴衆の方の反応や登壇後の質問、またTwiiterによるつぶやきなどがあります。

雑誌などでの執筆

一般に販売されている技術情報誌や、Web上の技術情報メディアなどによる情報公開です。

依頼ベースで行うので、頻度はそれほど多くは出来ませんが、アウトプットの手段としては最も効果があるのではないかと思っています。

特に雑誌の場合、一度流通するとやり直しが効かないこともあり、相当内容は精査して書かないといけません。周辺技術の念入りな調査も必要となり、執筆が完了してるころには、その分野に相当詳しくなっています。

アウトプットの頻度

アウトプットの頻度はどれくらいしたらいいですかという質問を受けるときがありますが、私の考えは、多い方がいいと思います。質より量です。特にブログは、後から自由に書き直しが出来るので、検証したことや学習したことは、どんどんアウトプットした方がよいです。だからといっていい加減な内容を書いてもいいということではもちろんないですが、そのあたりはブログというメディアの特性を活かして、適度に折り合いをつけて、アウトプットの量をこなして、たくさんのフィードバックを得た方が自身のためになるかと思います。