人よりちょっとだけアウトプットができるようになるためのコツ
はじめに
みなさん、アウトプットしていますか?
この質問に対して「はい!しています!」と自信満々に答えられる人は少ないのではないでしょうか?
かくいう自分も息を吸うようにアウトプットできているかと言われれば、正直なところ Yes とは言い切れません。
ですが、普通の人よりも「ちょっとだけ」アウトプットをしてきた自負はあります。
傍から見れば大したことないかもしれませんが、エンジニアを目指し始めてから今まで目に見えるアウトプット(=成果物)としては以下のようなものをしてきました。
- 技術記事を 30 記事投稿
- Qiita では 3149Contributions を獲得
- Zenn では 1077Likes を獲得
- SpeakerDeck に 9 つのスライドを公開
今回はそんな自分が実践してきた 「ちょっとだけ」人よりアウトプットができるようになるコツをいくつかご紹介したいと思います。
- アウトプットにハードルを感じている方
- アウトプットを始めたいが、何から手を付ければいいかわからない方
などの参考になれば幸いです。ぜひ最後までご覧ください。
1. 「アウトプットをしない」という選択肢を消す
まずアウトプットを人よりしたいなら 「アウトプットをしない」という選択肢を消してください。
「突然どうしたんだお前」と思われる方が多いでしょうが、正直これが 1 番大切だと思います。
「毎日仕事やらプライベートやらで忙しいからアウトプットできない」
=> この考え方をやめましょう!
「忙しいからできない」は個人的にはただの言い訳だと思っています。
相対的にアウトプットの優先順位が下がっているだけで、もし仮にどんな仕事やプライベートよりもアウトプットすることの優先順位が高くなったとすれば、全人類アウトプットできるはずです。(暴論ですが...)
つまり、最優先とまではいかなくても多少優先順位を上げるだけでも「忙しくてできない」という状況は改善されるかと思います。
とはいえ仕事のほうが優先順位は高いですし、息抜きのためにもプライベートの時間を確保することは重要です。
これらと両立させるのが難しいから、みんな苦労するのだと思います。
そういった状況を改善するために自分が普段意識していることとしては、「優先順位を上げざるを得ない状況を作る」 ということです。
例えば、会社の目標設定に組み込んでしまったり、所属しているコミュニティなどで強制的にアウトプットする機会を作る...といったことを自分は行っています。
こうした工夫をすることで、アウトプット習慣が全くない状態から多少なりとも脱却できるようになるかと思います。
2. 日頃からメモをとる
日頃から業務のログやキャッチアップした内容、その他思いついたことをメモすることも大切です。
基本的に技術記事などのネタは、日常生活(仕事も含む)の中で思い浮かぶことが多いです。
例えば、実装に詰まった場合などはチャンスです。
自分の場合、
- 何が原因だったのか?
- 解決策
を一言くらいでまとめて、メモっておきます。
ショートカットキーのすすめ
また業務中に疑問に思った点や気付いた点などをログとして残すこともおすすめです。
業務後の振り返り時に見返すことで、技術記事のネタが見つかることが自分の場合は割とあります。
(以下は自分の Slack 分報チャンネルへのメモの一例)
3. クオリティを求めすぎない
次は実際にアウトプットをする段階の話ですが、「過度にクオリティを追い求めすぎない」 ということも大切です。
特に最初の頃はマサカリなどが怖くてクオリティを追い求めがちですが、(アウトプットしたことがない人が)いきなりハイクオリティのものを出すのは不可能ですので、まずは完成させることを最優先にしましょう。
イメージとしては、「自分にだけわかるくらいのメモ」として記事を書いていくことをおすすめします。
とはいえ「学習メモ程度のクオリティで書いちゃうとマサカリが飛んでくるから怖い!!」という方も多いでしょう
そういった方はひとまず防御策(=言い訳)をあらかじめ用意しておくことをおすすめします。
具体的には以下のような"言い訳"を冒頭に入れておくとよいでしょう。
-
その分野に対して知識がない場合は、初心者であることを明示しておく
## 記事を読むうえでの注意点 私自身〇〇については経験が浅く、一部おかしな記述があるかもしれません。 そのためもし間違いなどがありましたらご指摘いただけると幸いです。よろしくお願いします。
-
あくまで「学習メモ」程度であることを明示しておく
- 「学習したことをまとめました」などと事前に伝えておく
こうすることで間違いを指摘するにしてももう少し優しく指摘してくれるでしょうし、なんなら優しい人ならアドバイスをくれるかもしれません。
4. 型をいくつか用意しておく
アウトプットに慣れてきたら、ようやくクオリティを求める段階に入ります。
これは主に技術記事に当てはまるのですが、「型をいくつか用意していおくこと」 が大切です。
基本的に技術記事にはいくつかパターンが存在していて、私的分類では以下の 6 種類くらいに分かれるのかな?と勝手に思っています。
-
特定の領域における課題解決や知見
-
言語フレームワークなどのベストプラクティス
-
概念や仕組み・歴史の解説
-
やってみた系・個人開発
-
ライブラリや便利ツールの紹介
-
ポエム・その他チーム文化など
各ジャンルごとに大枠の流れが決まっているので、それらをある程度用意しておくことが大切です。
例えば自分の場合は、 2 や 3 (たまに 4)のような記事を書くことが多いのですが、基本的には以下のような流れで書くことを心がけています。
## はじめに
紹介しようと思った背景などを説明する
## アンチパターンの明示
具体的にどういった部分が辛いのか?も明示する
## 上記を解消するベストプラクティス
複数ある場合は複数書いて良い
## まとめ・補足
ベストプラクティスをもう1度箇条書きなどでまとめる
## はじめに
なぜそのことについて興味を持って書こうと思ったのか?説明する
## 概念の詳細な説明
比較対象やその概念自体が密接に関連するものなども明示できればなお良い。
説明したい概念の粒度に応じて章立てて説明していく
### ○○○
### △△△
...
## まとめ
概念系の記事は他のジャンルの記事よりも最後のまとめが大事。
複雑なものであればあるほど、簡単にまとめてあげることが大切です。
(ここに関してはいろいろ書き方があるかと思いますので、あくまで一例です)
## はじめに
## 作ったものややったことの説明
個人開発などの場合はここに
・使い方
・技術スタック
・作るまでの過程(スケジュール)
などを書いていきます。
## 工夫した点・印象に残ったこと・苦労した点などの紹介
## おわりに
改めてやってみた感想などをシェア
「図解」のすすめ
上記以外で技術記事を書く上で個人的に大切にしていることは 「図解を入れること」 です。
特に理解力が求められる概念系の記事であればあるほど、図解というのは効果を発揮します。(自分の場合は概念系であろうがなかろうが、どんな記事であっても最低 1 枚はわかりやすい図を入れることを心がけています。)
意外とやっている人が少ないので、技術記事のクオリティをあげていきたい人にはおすすめです。
5. いいねやバズらせれたか?をモチベーションにする
最後に世間の目にさらされる以上は 「いいね数」や「バズったかどうか?」などは意識するでしょう。
過度にそれらをモチベーションにしすぎるのはあまりおすすめしませんが、ちょうど良いバランスを取りながらバズを狙っていくことはむしろ大切だと思っています。
自分のスタンスとしては 「わからなかったり疑問に思った部分を言語化して理解を深める」ということを最優先の目的として書きつつ、「これでいいねがもらえたらラッキー ♪」くらいの感覚でいます。
具体的には先述した「図解を入れる工夫」や「どの時間帯や曜日に投稿したら伸びやすいか?」「SNS でシェアした際に目を引くようなタイトルは何か?」などといった、バズるための下準備は最低限しています。
慣れてくるとこのあたりはゲーム感覚に近いので、適度に楽しみながら色々試すことをおすすめします!
おわりに
いかがでしたでしょうか?
自分が思うアウトプットが人より「ちょっとだけ」できるようになるためのコツについてだらだらと話してきました。
ただし、今回の内容はあくまで個人的な見解に過ぎず、万人に当てはまるわけではないと思いますのでそれだけはご認識いただけると幸いです。
今回紹介した内容のいずれかが参考になって、アウトプットを行う人が少しでも増えれば嬉しいです。
最後までご覧いただきありがとうございました!
COUNTERWORKS では絶賛エンジニア募集中です!!
テックブログなどを通じて積極的にアウトプットを行いたいと考えている方は、下記のリンクからぜひご応募ください!
参考資料
ポップアップストアや催事イベント向けの商業スペースを簡単に予約できる「SHOPCOUNTER」と商業施設向けリーシングDXシステム「SHOPCOUNTER Enterprise」を運営しています。エンジニア採用強化中ですので、興味ある方はお気軽にご連絡ください! counterworks.co.jp/
Discussion