「エンジニアたるものブログ等でアウトプットせい！」みたいな風潮あったりしませんか？ ブログ書いている私が言うのもアレですが、けっこう辛いと感じる人も多いと思っています。
一方でどうやったらアウトプットできるようになるか、いい感じにまとまっている情報ってあんまりなくて、いろいろすっ飛ばして「学んだことをブログに書いてみよう」で終わってたりします。
0から0.5に進むための考え方を紹介します。
今北産業のまとめです。
- インプットをうまくアウトプットに変換しよう
- アウトプットは型があるので、構成に迷わないように先に勉強しておこう
- まずは自分のためで良い
前提
アウトプットには、必ずなんらかのインプットが必要です。それは意識的にインプットとして行ったこと（本を読む、ブログを読む、カンファレンスで話を聞く）もあれば、無意識的にインプットになっているもの（会社での経験、雑談、タイムラインで見かけた）もあります。無意識的なインプットには、その場での感情（経験に対しての喜怒哀楽、快/不快）や考えも含まれると考えています。
無意識まで含めれば濃度はどうであれ、誰しもがある程度のインプットをしていると言えるわけです。
しかもあなたは、今この「ブログを読んで」います。
一方でアウトプットができない理由はインプットをどう消化し、昇華すれば良いかわからないという点にあります。具体的には次のような悩みがあるでしょう。
- みんな知っている気がする
- 新規性がない
- 間違っていたらどうしよう
- ググればわかること
- 話のまとめかたがわからない
- 書き方がわからない
- どこで書けばいいの？
このような不安を少しでも解消できればと思っています。 なぜアウトプットするかは他のブログに任せます。
そもそもアウトプットって何？
本記事では一旦ブログにしぼります。「ブログを書けるようになる。」、本記事の目標はこれだけです。
他にはLTやカンファレンスでの登壇、社内での勉強会、技術同人誌の執筆、自分でシステムを作っちゃう等ありますが、ブログが一番ハードルが低いと思います。
そのため、まずはブログに注力します。
アウトプットへの考え方
ブログを書く最初の障壁は「ネタ探し」です。
普段からブログを書く人は息を吸うようにインプットし、吐くようにアウトプットします。 それは普段から自分なりの「解釈」を考えながらインプットしているからのように思えます。
つまり、ブログを書くためにネタを探す人と咀嚼するだけでネタができている人の差です。
インプットがあってアウトプットがあるというのは最初に示した通りです。図示すると次のようなイメージです。
インプットとアウトプットの間に「ずらす」「深ぼり」「混ぜる」というのが挟まってきました。
個人レベルでブログに書くアウトプットの本質はこの「解釈」だと私は考えています。
まずは「ブログを書こうと決意してからネタを考える」で進めていき、いずれは吐くようにアウトプットできるように、インプット時点でアウトプットを想像できるようになっていきましょう。
インプット（=データ）を「解釈する」ためのテクニック
前述の図の通り、「ずらす」「深ぼり」「混ぜる」などのテクニックが「解釈」の基本になると考えます。それぞれ例を出して説明していきます。
2024/04/22のはてなブックマークのテクノロジーカテゴリ、ホットエントリーにあったテキトーな情報をインプットのサンプルとします。
今回選んだのは次のインプットです。 ja.react.dev
4ページ分、日本語のReactのルールというReact実装時のガイドラインが追加されたようです。
ずらす
まずはこのインプットに対して少しずれたことをします。これは後述の深ぼりとも重複する部分が出てきます。
例えば次のようなアイディアがあるかと思います。
- 追加されたルールに従っていないサンプルコードを示す
- 一般的にルールと呼ばれているものを探してみる
- Vueでの書き方を確認してみる
けっこう調査が必要な項目ばかりになってしまいましたね......。サンプルが悪かったかもしれません。 イメージとしては重箱の隅をつついて検証してみるようなものです。
深ぼり
ずらすの例もほぼ深ぼりになっていますが、もっと明確にやっていきます。
- マイReactルールを考えてみる
- DOM操作の実装を追う
- 有名なライブラリがこのルールに従っているか確認し、有用性を考える
- 他のドキュメントを改めて追って要点をまとめる
これもけっこう調査が必要になります。
混ぜる
他のインプットと混ぜて一つのアウトプットにする方法です。最もわかりやすいのは、「自分の経験と混ぜる」ことです。
例えば「ルールに従ってなかったがために失敗した経験談」をブログにし、他の人が失敗しないように啓蒙するようなブログです。
他にも次のような例が考えられます。
- Svelte等の他フレームワークと比較する
- 過去の実装がルールに適合していたか検証する
- Reactへリプレイスしてみる
- 何が変わったのか精査してみる
- 他の人の反応をまとめてみる
経験という軸を加えるだけでできることがかなり増えると思います。
アウトプットの型に沿う
テーマが決まっても、まとめ方で迷い、筆が進まないケースもあります。そのために型を覚えて、当てはめながら進めると良いです。
どのようなものをアウトプットするかでパターンを作ると良いと思います。
体験をアウトプットする場合
カンファレンスの感想等がこれにあたります。 次のような見出しで考えていくと良いと思います。
- なぜその体験をしたか
- どんな体験をしたか
- どう感じたか
- どのような場面で活かせそうか、一般化
学びをアウトプットする場合
学びをアウトプットするときは結論から書いて論理立てて展開すると良いです。
- 結論はなにか
- 根拠・理由
- 学びの例示、一般化
エラーへの対応方法等をアウトプットする場合
これも基本的には学びのアウトプットと同様です。
- 解決したい課題
- 結論、解決方法
- 解決方法の根拠・理由
- 解決への糸口、手順
- 手順の一般化
ほかにもいくつかパターンはあるかと思いますので、自分なりの型を見つけてみてください。
モチベーション
さて、ネタ探しと記事作成の方法、構成はわかりました（たぶん）。 とはいえ書くモチベーションがないですよね？
そりゃそうです。このブログだってここまで書くのに1時間くらいかけてますし、インプットから構想練ってって考えると倍以上です。
偉そうに書いてますけど、最終的には自分用の備忘録と転職のためのネタになるが落とし所かなと思っています。
結果的に多くの人のためになり、「情けは人の為ならず」となれば良いですが、たいていのアウトプットは見向きもされず埋もれていきます。
まずはそれで良いと割り切り、自分の思考や指向をまとめ、ポートフォリオにしていってください。
どうしたって評価を考えると悲しくなるので......。
まとめ
三行まとめを再掲します。
- インプットをうまくアウトプットに変換しよう
- アウトプットは型があるので、構成に迷わないように先に勉強しておこう
- まずは自分のためで良い
難しく考えすぎずに自分含めて今後とも気軽にアウトプットしていければ良いなと思います。
2024/04/23 追記
Xにてこのような情報をいただきました。
各ブログを書くパターンごとに型を用意してるのはいいな。誰かに書いてもらうときとかの参考にさせてもらおう。
— luccafort (@luccafort) 2024年4月22日
個人的にonkさんのこの資料がとてもよくまとまってるのでぼくはよく引用させてもらったり共有させてもらっている。https://t.co/ncuxTmRDKH https://t.co/n8n8qRdSv5
私の言いたかったこと、だいぶ書かれていますね。後半のコミュニティづくりの話は参考になりました。
モチベーションを保つことが難しいというのは、前述の通りですが、コミュニティにそこを担ってもらえれば、相互に刺激のある環境が作れそうです。
今考えると私は幸いにも、会社の同僚（Kanonさん）がその役割をしてくれていて、非常に助かっているように思えます。
X上にはアウトプットを定期的に出している人も多いので、積極的に関わり、刺激を受けていきたいですね。（プレッシャーにならない程度に......。）
