成長の為にアウトプットがなぜ必要なのか。mattn氏が語る持続的なアウトプットのススメ

• keyboard_arrow_down はじめに
• keyboard_arrow_down 自己紹介
• keyboard_arrow_down そもそもアウトプットとは
• keyboard_arrow_down アウトプットする際の注意点
• keyboard_arrow_down おわりに

こんにちは。mattn といいます。ソフトウェアエンジニア職をしながらオープンソースソフトウェア （以下 OSS） に沢山コントリビュートを続けているエンジニアです。

今回、以下のような悩みを持っておられる方に僕なりのアウトプット習慣を身に付ける方法を少しでもお伝えできたらと思い、数回に渡ってお話をさせていただこうと思います。宜しくお願いします。

当然ながらこれからお話させていただくのは僕の例であり、すべての話がみなさんに当てはまる訳ではありません。同じソフトウェアエンジニアではあるけれど、業務内容も異なれば、興味のある分野も、置かれている状況も異なります。なるべく一般論としてお伝えするつもりではいますが、幾らかの話はソフトウェアエンジニアに特化したものであったり、僕の働き方に依存したものであったり、僕の興味のある OSS に限った話、と偏った内容になってしまうことをご了承ください。

普段はどちらかというとお堅い SI （System Integration） 業で仕事をしています。社会人になってから今まで一度も Web 業界と呼ばれる B2C （Business to Customer） な職種に就いたこともありません。

ですが、今では OSS （オープンソースソフトウェア） を通して、いろいろなイベントに登壇させていただいたり、GitHub Stars （GitHub 社が選ぶスターエンジニア） （※）に選出していただいたり、Google Developers Expert Go を担当させていただいたりと、OSS 界の中での立ち位置も少しずつですが大きくなってきたと感じています。
（※）（GitHub Stars は 2021〜2023）

仕事では主にバックエンドエンジニアではありますが、OSS 活動では種類を問わず、フロントエンドを含むウェブアプリやウェブフレームワーク、バックエンドツールやテキストエディタ、プログラミング言語など、あらゆる物にコントリビュートしています。

ではアウトプットの方法を解説していく前に、そもそもアウトプットとは何なのかを説明していきたいと思います。

インプットとアウトプット

インプットとは情報を得ることです。ブログを読んだり本を読んだり、外からの情報を溜め込むフェーズがインプットです。いっぽうで溜め込んだ情報を使ってプログラムを作って公開したり、ブログ記事を書いたり、何かを成果を残すフェーズをアウトプットといいます。

我々は通常、インプットとアウトプットを交互に行うことで成長していきます。これはソフトウェア界隈に限った話ではありません。外から情報を得て、自分なりに解釈・吟味・検討し、その情報を使って成果を出します。この成果の積み重ねが記録となり、資産となり、評価の対象となります。

インプットもアウトプットも重要ですが、これを繰り返すことが重要です。

アウトプットの定義

では、アウトプットにはどんな種類があるのでしょうか。アウトプットの方法が分からないと悩んでいる方がいるかもしれませんが、実はアウトプットの方法は沢山あります。ソフトウェア界隈に限って言えば以下のようなものです。

もちろん、アウトプットはこれらに限るという物ではなく皆さんの思う情報発信の方法でやると良いと思います。

アウトプットの例

なかなかイメージしづらいかもしれませんので、ここで僕がよくやる簡単なインプットとアウトプットの例を紹介しましょう。

まずは興味のあるプログラミング言語で興味のある分野の OSS を探します。なんでもいいです。例えば Go 言語に興味があり、Go 言語を使った todo 管理アプリを探しているとしましょう。

見つかったならば実際に使ってみて、良かったならそれを情報発信すると良いでしょう。見つかったけれど気に入らなかったのであれば、改造してみるのも良いでしょう。改良して良くなったのであれば pull-request を送ってみるのも良いでしょう。

気に入った物が見つからなかったのであれば、自作するのも良いでしょう。

この図を見て貰うと分かりますが、大事なのは、可能な限りアウトプットで終えることなのです。

アウトプットの意味するもの

なぜエンジニアはアウトプットするのでしょうか。アウトプットには何の意味があるのでしょうか。「インプットだけでも勉強になるのでは？」と考える方も多いと思います。

しかしアウトプットすることはエンジニアにとってとても大きなメリットがあります。

まずアウトプットすることで、自分のインプットの理解度を確かなものにすることができます。よく技術書を読んでいて、本当は大事なことが書いてあるのに何も頭に入らないまま数ページ読んでしまっていることに気づき、巻き戻って読み直した体験はないでしょうか。気づくならまだしも気づかないまま読み終えてしまうことも、恐らくはあるはずです。

これがなぜ起きるのかというと、「これは以前見たことがあるアレだ」という体験が乏しいからです。

情報は入力することで記憶に残り、知識として蓄えられるのですが、実際に使ってみるまで本当に知識として蓄えられたのかどうかはわかりません。そこでアウトプットが重要になります。ブログ記事で読んだテクニックは自分で試してみてようやく知識として残ります。

そして、そうやって試した結果をどこかに残して置くのが重要です。人の記憶など実は大した物ではありません。特定の感情や出来事に紐付かない記憶は数年どころか数ヶ月で忘れてしまいます。僕もそうです。

例えば新しいプログラミング言語を見付けて興味を持ったら、まずは試してみるのが良いでしょう。その際に、ブログ記事を書いてみたり、SNS 等で連投してみたり、実際にそのプログラミング言語で何かを作り GitHub にソースコードを置いておくのも良いです。後から見返すことができるのが重要です。

そしてそうやって残されたアウトプットは、他の人達から見てもらえる事があります。そして興味を持ってもらえれば 、GitHub リポジトリにスターを付けてもらえたり、プルリクエストをもらえたり、SNS でリアクションをもらえたりします。

アウトプットをみたひとからのリアクションは励みとなり、以降も継続してアウトプットしようというモチベーションや自信へと変わっていくのです。

良いことづくめのアウトプットに見えますが、幾つか注意事項があります。知っておかないと、アウトプットを始めても逆に自信を無くしてしまったりすることもあります。

ライフスタイルの違い

ひとくちに「アウトプットが大事」と言っても、人によって仕事の状況や家庭環境が大きく異なります。SNS で誰かがアウトプットしているのを見て、その量と自分のアウトプットの量を見比べて少なさに悩んだりする必要はありません。

ライフスタイルは個々にバラバラです。そんな状況で行われたアウトプットを定量的に比較しても無意味なのです。重要なのは「小さい単位でも自分のペースで続けること」です。

続けるためのコツ

幾つかは既に記していますがアウトプット活動を続けるためのコツは、おおよそ以下のものです。

最後の「習慣化すること」はライフスタイルによっては実現しづらいかもしれません。また、はじめの慣れないうちは難しいと思います。

慣れてくると、並行してイテレーションを行うこともできるようになります。

例えば僕の場合であれば、Go言語で何かを数日に分けて作りながら、Zigで面白そうな物を探すといったこともよくあります。これは一見デメリットがありそうに見えますが、見つけた OSS にプルリクエストを送っても作者に取り込んで貰えなかったり、特定言語の標準ライブラリのバグを踏んでしまい詰んでしまうこともあるからです。また無料のサービスだと思っていて調べてみたら実は有料のサービスだった、なんてこともあります。

何をするかを雑に決める

アウトプットすることに慣れていない方にとって、一番難しいのは「何をアウトプットするか」を決めることだと思います。

これは「何をするか」を決めることを難しく考えすぎてしまっているからです。エンジニアの皆さんであれば、何かしらの情報収集源を持っておられるかと思います。

そして情報を収集している状態を確認してみてください。

まず、やることを選ぶほど情報が降ってこないという方は、情報収集源が少ないのが原因です。これは僕のやり方なので全ての方に向いている訳ではないのですが、こういった情報は常に流れる様にしておき、気になったものだけをピックアップする程度で良いと思っています。街中で流れる音楽に耳を傾け「あっ、この曲いいな」とばかりにインターネットを検索してみる、その程度で良いと思っています。情報量が多すぎて選べないという方は、街中に流れる音楽に耳を傾け過ぎなんだと思います。

逆に情報量は足りているがどれも難しいという方は、聴いているジャンルが合ってないのだと思います。ボサノバが好きなのであればボサノバばかり流れる喫茶店に行ったり、ハードロックが好きなのであればハードロックばかり流れる理髪店に行ったり、微調整が必要かもしれませんね。SNS で別のカテゴリの方をフォローしてみては如何でしょうか。

こんな感じにアウトプットはもっと気軽に、思いつきでやれば良いと思っています。僕は割と気軽にこれをやっていて、前述のフロー図の途中で投げ出してしまう物も案外あります。

複数同時にやってるのはそういう意味もあります。無理にやり続ける必要はありません。

前述のように、調べていた物が思っていた物と違ったというのもありますし、途中で飽きてしまうこともあります。もし現時点で追っかけている OSS がひとつだと、次の OSS を見つけるまでにブランクが空いてしまいますね。

そうすると「何かアウトプットしなきゃ」という不必要な義務感と「今日も何をするか決められなかった」と何もせずに終えてしまった消失感に苛まされてしまいます。

そういう事がないように保険を掛けているという意味もあります。

おそらくですが、これは僕だけでなくアウトプットが得意なエンジニアの方であれば、「いずれやってみたいな」と思っているネタを、常日頃から数個はストックとして持っていると思います。それは別に新しい物でなくても良いのです。ずっとメンテナンスを続けている OSS に新しい機能を追加する、それもアウトプットです。やり終えたなら SNS で宣伝すると良いでしょう。ユーザーが増えるだけでなく、リアクションを貰えて新たなモチベーションにもなります。

リアクションが少ない

なかにはこういったアウトプット活動を続けているにも関わらず、リアクションがそれほど得られなくてモチベーションへと繋げにくいと感じている方もおられるかもしれません。安心してください。どなたでも今よりリアクションを貰やす方法はあります。こちらについては次回で具体的にご紹介していきたいと思います。

今回は技術者にとってのアウトプットとは何か、そして成長の為にはアウトプットがなぜ必要なのかを説明しました。またアウトプットをする上での注意点やコツについてもお伝えしました。次回はもっと具体的に、どのようなアウトプットを実際に行っているのかを僕の実例を交えてお伝えしたいと思います。