自分は今新卒 3 年目なのですが、直近の 2 年間は毎月何かしらのアウトプットを継続して行ってきました。
色々な記事[1][2][3]に書かれているように、アウトプットをすることはたくさんのメリットがあります。自分自身、それらのメリットを享受できていると感じているので、アウトプットして来てよかったと思っていますし、今後も継続して行きたいと思っています。
（あくまで個人的に意識していることなので、全ての方に当てはまるものではないことをご了承ください）
しかし、アウトプットに対してハードルを感じている方や、アウトプットをしてみたいと思っていても何から始めればいいかわからない方もたくさんいると思います。
そこで今回は、自分が継続的にアウトプットをするために、普段から意識していることを紹介したいと思います！
これによって少しでも、アウトプットにハードルを感じている方や、アウトプットにチャレンジしようと思っている方の手助けになれば幸いです。
過度にクオリティを求めない
自分はアウトプットする上で、とにかくまずはアウトプットすること自体が重要というマインドを大事にしています。
これは、クオリティを上げるには時間と経験が必要だと考えているからです。中には最初からハイクオリティなアウトプットを出せる人もいるとは思いますが、自分も含め世の中的にそうじゃない人の方が多数派だと思います。では、どうすればアウトプットのクオリティが上がるかというと、これは経験しかないと思います。逆に言えば、技術記事の執筆や勉強会の登壇などのクオリティは、繰り返すうちに後からついて来ます。なので、アウトプットのクオリティを上げるためという意味でも、とにかくまずはアウトプットすること自体が重要だと思います。
そうは言っても最低限のクオリティの担保は必要だと思っているので、その基準として自分は下記の2点を意識しています。
新規性はあるか
すでにネットにある記事などの情報を焼き回すだけでは、すでにあるその情報をみれば済むので、改めて新たに情報をネットに公開する意味は薄いと思います。逆にネットにまだない情報であれば、ある程度ニッチな情報でもそれによって恩恵を受けられる人は少なからずいると思うので、新規性は重要視するようにしています。
情報が正確か
情報を発信する以上、正確な情報を発信しようと務めることは必要です。発信しようとしている情報に少しでも不安や心配がある場合は、1次ソースを元に自分の中で確認が持てるまで調査します。正しい情報を発信しようと深いところまで調べることで、理解が深まり、知識の定着にも繋がります。
小さく始める
前述したように、まずはアウトプットすること自体が大事だと思っています。ただ、いきなり大規模カンファレンスに登壇したり、バズる記事を書くのは難しいですし、公開するスコープが広ければ広い程、心理的ハードルも上がると思います。なので、まずは公開するスコープを絞ってアウトプットを行い、徐々にそのスコープを広げていくのが良いと思います。
具体的には、まずは日頃からメモをとる習慣をつけたり、それらを体系的にドキュメントにまとめてチームに公開するなどです。もうちょっとスコープを広げると、作成したドキュメントを全社的に公開したり、社内 LT などの文化がある企業であれば、社内 LT で登壇するなどがあると思います。そうしてスコープを広げていくことで、最終的に Zenn・Qiita やテックブログなどで記事を執筆してネットに公開したり、外部の勉強会やカンファレンスへ登壇につながると思います。
繰り返しにはなりますが、まずはアウトプットすること自体が重要なので、必ずしも最初からネットに公開する必要はありません。なので、ネットや外部に公開するのに抵抗がある方は、まずは公開するスコープを絞って、小さく始めるのが良いと思います。
日頃からメモをとる
日頃から業務のログやキャッチアップした内容のメモをとるようにしています。ここでメモする内容はクオリティや体裁は全く気にせず、とにかく発散させています。そして、そのメモがある程度溜まったら見返して、発散させた内容をまとめてアウトプットに繋げています。
下記は Apollo Client のバージョンアップをキャッチアップした際のメモと、それをまとめて執筆した記事の例です。
キャッチアップメモ
上記の例もそうですが、自分は Slack の times チャンネルにメモを投稿することが比較的多いです。times チャンネルに投稿することで、自分が書いたものを他の人に見てもらうことに慣れたり、コメントをもらいやすいのでおすすめです。他にも X（旧 Twitter）や Zenn のスクラップなどのツールも選択肢としてありますが、自分はメモの公開スコープは小さくしておきたいので times チャンネルを使用しています。
実装に詰まった時はチャンス
実装で詰まって、調べても解決策がヒットしなかった場合は、アウトプットのチャンスです。詰まった場合は、大抵同じように詰まっている人が他にもいると思います。詰まった内容と解決策を記事にしたりすることで、その後同じ課題に直面する方の助けになります。
先に目標を定める
ネタができたらアウトプットしようと思っていても、なかなかネタは出てこないです。継続的にアウトプットするとなると、なおさらネタが出てくるのを待っていては継続は難しいです。
先に「アウトプットする」という目標を定めてやらざる得ない状況にすることで、意外とネタが見つかったり、究極ネタを作るための行動が生まれます。なので、自分はあらかじめアウトプットすることを宣言したり、声がかかったものはネタがあろうがなかろうが、とりあえず Yes と回答し、その後にネタ探しやネタづくりを行うようにしています。
「ネタがあるからアウトプットする」ではなく、「アウトプットするためにネタを作る」というマインドを持つことで、日頃から技術的挑戦を行うようになり、エンジニアとしての成長にも繋がります。
優先順位をあげる
忙しくてアウトプットできないという声をよく聞くのですが、それは相対的に優先順位が下がっているからだと思います。仮にどんな実装よりもアウトプットすることの優先順位が高くなれば、全てのリソースを注ぎ込めるので、アウトプットすることはさほど難しくなくなると思います。最優先とまではいかなくても、多少優先順位を上げることで、忙しくてできないという状況は改善されると思います。
その上で、自分の中ではアウトプットの優先順位はかなり高いのですが、これには2つ要因があります。
1つ目は意図的に優先順位を上げる環境を作っているからです。自分は先述したように先に目標を定めたり、会社の目標設定に組み込むようにすることで、やらざる得ない状況を作り、強制的に優先順位を上げています。
2つ目はアウトプットに時間をかけるだけの価値があると感じているからです。アウトプットを通して、他者に説明できるレベルまで理解を深められたり、継続的なアウトプットのためにインプットが増え学習サイクルが強化されたりと、エンジニアとしての成長に繋がっていると実感できています。アウトプットすることはエンジニアの成長にとってプラスになることが本当に多いので、まずはアウトプットをしてみて、それらを実感してもらえると嬉しいです。
成長のバロメーターにする
インプットや技術的挑戦などを日頃から行えていないと、ネタがストックされず、継続的にアウトプットすることができません。インプットや技術的挑戦などはエンジニアの成長にとって必要な要素だと思います。そのため自分は、継続的にアウトプットできているかどうかを、成長のバロメーターにもしています。逆に自分にとってアウトプットするネタがない状態は、インプットが不足していたり、技術的挑戦ができておらず、成長が滞っているアラートとして捉えています。
このように捉えることで、アウトプットをすることが自分の成長にも繋がっている実感が湧いて、継続するモチベーションにも繋がります。
まとめ
今回紹介した内容はあくまで自分個人の意見なので、万人に当てはまるものではないと思います。ただ紹介した内の何個かでも参考になって、アウトプットする方が少しでも増えてくれたら嬉しいです！
Discussion