アウトプット やり方 その1
記事のタイトルをTODOにする
私は期限があるスケジュール以外すべて"TODO: "のprefixをつけてプレーンテキストで管理しているのですが、Zennに書く予定の内容もTODOにして残しています。
もしそれがコーディングに関する内容であればコーディングを先にやって、その後に記事を書けばいいわけですから、1つのTODOで複数のアウトプットができてお得です。
とりあえず「はじめに」「おわりに」などの見出しを書く
技術記事の場合は「はじめに」「おわりに」とか、「Intro」「Outro」とか、「まとめ」「参考文献」とかを先に書くと記事の流れやゴールを決めることができたり、記事に必要なリンクがあちこちに散らばったりしなくなるのでおすすめです。
ZennでもVS CodeでもWordでも見出しをたくさん書くと自動的に目次やアウトラインを作ってくれるので、記事内の移動も楽になります。
見出しごとの内容を短くする
いきなり2000文字とか10000文字とか書こうとすると詰んでしまうので、Xのスレッドを書くような感じで見出しごとの内容を短くしたほうが書きやすいですし、何より読みやすいです。
ただZennの技術記事でコードを掲載する場合だとコード量含め文字数が多くなりがちですから注意が必要ですね。
情報ではなく経験をアウトプットすること
私がめっちゃ技術記事を書くようになったのはid:lacolacoさん[1]がはてなブログで書いた以下の記事がきっかけです。
ああすればできます、こうすればできますといった内容はAIに聞けば分かるようなことなので、読者のために書くのは長続きしません。
もし情報を書きたいのであれば、関連付けを行い情報量を増やすとか、トレンドにのっかるとか、そういった工夫が必要になると思います。
ただ同じ情報を書いた場合、有名な人が書いた記事が最も読まれるので、トレンドにのっかり記事を書く前に似たような記事がないか確認したほうがいいかもしれません。
何か前にも似たようなこと書いたな。
手段を目的にしない
アウトプットはごちゃごちゃになった情報を整理したり、目に見えない世界を信じるためにやるので、別に無理して記事にしたりPublicにする必要はないと思います。
私は「テックブログ」が採用とか広報とかの文脈で語られることが増えすぎているので、いよいよ壁ドンみたいに意味が変わってしまうのではないかと思うところもあり、なるたけPublicにしています。
このまま企業の技術記事ばかりになりインフレを続けても誰も幸せになりませんからね。
自分の目的にあわせたアウトプットを心がけましょう。
評価されないことに慣れる
別に世界中の天才と戦って勝たなければ生きていけないわけではないので、アウトプットすれば評価されるという思い込みはなくしたほうがいいかもしれませんね。
私は長らくOSS開発をやっていますが、アウトプットの延長線上としてやっていますし、開発したツールたちは作業を減らすためにあるのであって、別に評価されたいためにやっているわけではないので。
けれど悲しいかな、自分のためだけに生きるのに卑しいものを感じることは人間誰にでもあることなので、こうやって様々なものをアウトプットして何かが変わればいいなあと思うところはあります。
その2があるのか分かりませんが、多分他にもアウトプットのやり方はあると思うのでとりあえずその1として書きました。
-
私はVue.jsやAlpine.jsをやる前にAngularDartをやっていたので ↩︎
Discussion