はじめに
本記事はアウトプットの心構えのカレンダー | Advent Calendar 2023の4日目の記事です
こんにちは！！@Sicut_studyです！
私はアウトプットの大切さを日頃から発信しており、実際にQiitaにたくさんの記事を投稿しています
そんな中で、自分なりに高速に記事としてアウトプットできるフレームワークを使っているのでそのフレームワークについて紹介していきます
アウトプットの大切さ
まず言っておきたいのはアウトプットは質より量です
量が増えるとだんだんと質もあがります
私は駆け出しのエンジニアの方に普段から「100本記事を書けば人生変わる」と言っています。
そもそも世の中に100本記事を書いたことのある経験をしたことがある人はごく僅かです
そんなごく僅かな人になれれば絶対人生が変わります。
多くの人ができないことをやり遂げられる。しかも記事という形で目に実力が見えるので評価されるようになります。100本も記事を書けば、技術力も自然に付きます(やらないと記事はかけません)
実際に私自身も私の周りもアウトプットによって人生を変えました
ここまでの話を聞いて、「人生変えるために100本アウトプットしてやる」と思って始めてくれる人がいてくれたら嬉しいのですが、やろうと思うとかなり難しいことに気づきます
- 書く内容がない
- 習慣化しなかった
- 投稿するハードルが高い
そんなやる気はあるけど、一歩が踏み出せない人に向けて今回は私が実際に使っている高速記事作成フレームワークを紹介します
記事には2種類ある
フレームワークを紹介する前に記事には2種類あることについて紹介します
1.多くの読者に向けた記事
1つ目は「多くの読者に向けた記事」です。
私の場合は以下のような記事がそれに該当します
このような記事に関しては、多くの人に呼んでもらえるように
- 記事の構成をしっかりと作る
- 画像などをしっかり入れてビジュアル的にわかりやすくする
- 文章量もおおい
ということに気を使って書いています
この記事を「これからアウトプット頑張るぞ」という方が書くのはかなり難しいです
1つの記事を書くのに数時間かかるので、習慣化ができません。このような記事がハードルの高い記事となっています
私が最初の100本で書いて欲しいのは次に紹介する雑な記事だが誰かのためになる記事です
2.誰かのために向けた記事
100本書くのに書いてほしい記事はこちらです
多くの人には読まれないが、困ったと思う誰か1人のために記事を書いていきます
特定の言語のとある目的をしたい人が困ったときに見る記事になります
このような記事は1の記事に比べて全く見られませんし、いいねは0か1という記事がほとんどです
しかし、このような記事を書くことはアウトプットする習慣をつける以外にも大きな目的があります
自分が困ったことは世界中の誰か1人は必ず同じ困りごとに遭遇する。その人の1秒でも早く問題を解決できるようにする
このような考えを持って書くことで継続的にアウトプットしつづけることができます
誰かに向けた記事を書くときは要点をまとめた記事を書くことで高速にアウトプットすることができます
雑に記事を書くフレームワーク
誰かに向けた記事を書くとときに読む人が求めるのことは以下です
記事を読んですぐに解決方法がわかる、またはこの記事が自分の求めている問題の解決法でないことがすぐにわかる
ということはしっかりとした記事を書く必要がなく問題と解決方法がかかれていれば記事としての価値があるのです
ということで私が作成したのが「高速に雑に記事を書くフレームワーク」です
# はじめに
# 問題
# 解決方法
# おわりに
# 参考
この項目について最低限の情報を書いていくだけで記事が完成します
はじめに
今回の記事を書く背景などを書いていきます
一言で全然大丈夫です
例えば私は以下のように書いていました
Railsを久しぶりに使ってGemで困ったのでまとめます
問題
ここで実際に自分が起きたエラーをまとめます
実際のエラーログであったり、そのときに使ったコードなどを丁寧に載せるようにします
(ここで同じ問題かを読者は判断しています)
解決方法
実際にどのように解決したかを簡素に書きます
コードなどがあればそちらも載せましょう
おわりに
問題を通して感じたことを一言書きます
私は以下のように書いていました
時間をすこしロスしました
もはや必要かはわかりませんが、話したいことがあるときもあるので一応毎回書いています
参考
解決のために参考にしたリンクをすべて貼っておきます
記事を書くタイミング
記事を書こうと何か内容を考えようと思うと継続することはできません
記事を書く動機を自動化することが大切です
私が記事を書くタイミングは
自分が問題にぶつかって解決に10分以上使った内容は記事にして書く
ようにしています。ポイントはすぐに調べて解決したことはかかないことです
このようなものはすでに記事にまとめっているので、困った人がその記事を見て解決することができるからです
解決に10分以上時間がかかったということは、「そもそも解決の記事がない」や「記事のタイトルが自分の調べたワードと異なっている」などの理由があるのでそれは記事として投稿する価値が十分にあると考えます
また以下のことを徹底して行っています
エラーが起きたコード、エラーの内容、参考にした記事のリンクは問題が解決したタイミングでメモに残しておく
問題を解決したその日に絶対に記事を投稿する
これは記事をすぐにその日にかけるようにするための工夫です
記事をその日に書くことは、あとでまとめて書こうとしてたまりすぎて書かなくなるであったり、記事の内容が日が経つごとに薄れていくというのを防ぐためです
私はだいたい1記事書くのに5分程度で完了します
これなら100本記事を書くハードルが下がると思いませんか？
おわりに
書くためにはやはり何かしらの開発を行わないといけないと思います
書くためのアウトプットができないと思う人はぜひ私が行っているコーチングサービスを受けていただけたらと思います
わざとこの記事を雑に書くというのも思いついたのですが、あえて丁寧に記事を書いてみました
ここまで読んでいただけた方はぜひいいねとストックよろしくお願いします。
少し宣伝します🔥🔥🔥🔥🔥
これからエンジニアになろうとしている人を本気でコーチングして3か月の期間で立派なエンジニアにするようなチャレンジをしてみたいなと考えております。
もし、本気でエンジニアを目指してコーチングを受けてみたいという方がいれば、Twitterに「プログラミング教えてほしいです」みたいなリプライ送っていただけたらなと思います！！
以上です。
今週もプログラミング頑張りましょう！
