はじめに

現在 Qiita にて開催中の「Qiita Engineer Festa 2024」では、期間内にある一定数の記事を書くともれなく全員にプレゼントが贈られるということで、チャレンジしてみようと思ったのが一ヶ月前。分かってはいたが、結構大変だ。
こんな状況になったことが過去にあまりないので、進めていく中で頭の中に沸き起こってきたことをつらつらと書き下してみた。

前提

この記事でのアウトプットとは、「同じような構成を取ることができる、小規模な記事を複数書くこと」とさせていただく。よって、「崇高で長大な論文を一本完成させる」ような作業に対しては有効なアプローチであるとは考えていない。

アウトプットを行う目的

Qiita のような記事だけに関わらず、何かしらのアウトプットを行う目的には以下のようなものがあるのではと考えている。

知識の整理、体系化
新技術に触れる機会
コミュニティへの参加、本業以外での評価¹
承認欲求の充足

本題

1. 期限とアウトプット量が適切か

全ての仕事には期限がある。アウトプットを行うときも例外ではなく、いつまでにそれを書かなければいけないか、もしくは書きたいと思っているのか、は最初に注意すべき事項である。またこれはアウトプットの量と表裏一体である。今週中に記事一本なら可能だが、今週中に記事 100 本なら話は全然別だ。期限とアウトプットの量はどちらも定数にも変数にもなりうるため、状況に応じて何を優先すべきかは常に考える必要がある。

ポイント

無理なものは無理と諦める。
本業や家庭などのプライベートと照らし合わせ、期限かアウトプット量、またはその両方を調節し、現実的な予定を立てられるように心がける。

2. タイトル（何について書くか）のみを決める

これがクリアできるとかなりゴールに近づく。
ここでは技術記事を書くとして、以下のような観点でタイトルを捻出していく:

自分が自信を持って表現できる内容
自信はないからこそ、あえてこれを機会に知識を整理する上で書きたい内容
全く新しい技術に触れるきっかけとして記事を書く場合
忘備録

自分が自信を持って表現できる内容

このタイプの内容の場合は、どんなことを書くべきでどこに価値があるかが分かっている場合が多い。
筆の進みも良いことが想定されるため、まずはここから始めるのが良い。
このタイプの記事をどれだけ増やしていけるかが、エンジニアとしての力量に繋がるのではと思っている。

自信はないからこそ、あえてこれを機会に知識を整理する上で書きたい内容

今度は逆に、自信がないからあえてアウトプットに踏み切るパターンである。
これにより、その分野の自分のレベルを一段上げることを期待している。
確認作業を綿密にしながらの執筆となるため負荷は高いが、得られるものは大きい。

全く新しい技術に触れるきっかけとして記事を書く場合

個人的にコスパがいいと思っているパターンであり、一粒で 2 度美味しいを体現できる方式である。
例えばアプリか何かの開発をしていて初めて触るライブラリがあった場合に、その使用感やユースケースについて記事にするなどである。
その気になれば、1 ライブラリ 1 記事を書くことでアウトプットを量産できる。

忘備録

Qiita でもよくみるタイプである。
未来の自分または同じように悩んだり調べたりしているであろう他者に向けて記事を書いておく。
メモ的な趣向が強いが、実用性は高い。
また、「この記事は忘備録です」というラベルを貼ることで、書くことに対するバーを下げられるのは良いことだと思っている。

ポイント

タイトルを必要数だけ 1 ページにリストアップし、全体の進捗を俯瞰してみられるようにすることが重要である。
各タイトルに対して絵文字で装飾すると、全体的に可愛らしい仕上がりになってアガる⤴️⤴️

以下の画像は、Engineer Festa 用に書こうと思った記事のタイトルたちである。
タイトルの横のアイコン (✅: Done, 🚧: 執筆中, 📌: 取り掛かり予定) が賑やかしに一役買っている。
ものによっては、タイトルの下に書きたいことの概要をメモしているものもあり、後に生きる場合もある。

3. 共通フォーマットを準備する

全ての記事のタイトルが決まったら、さぁ内容の執筆！..ではない。
どの記事でも大体同じような内容を書くところがあるので、それは最初から用意しておくべきだ。

ポイント

マークダウンで言うと、h2 ヘッダーのレベルで共通化しておくのが柔軟性もあって良いと感じている。(h1 をタイトルそのものであるとした場合)
例えば、以下のような簡単なものでも構わないだろう。

## はじめに

## 環境・前提

### ここは必要に応じてインプリメントする

## 作業内容

### ここは必要に応じてインプリメントする 1
### ここは必要に応じてインプリメントする 2
### ここは必要に応じてインプリメントする 3
...

## 考察

## 終わりに

実際に記事を書き始めると、必ずと言っていいほど基本形から少し逸脱して書いた方がより説明がしやすい場面に出くわす。そのような時は都度最適な書き方をすればよく、あくまでも最低レベルの箱を用意することに意義がある。また、実際の記事で使ってみた構成が良く、他のケースでも有用だと判断した場合はそれをリバースエンジニアリング的に共通フォーマットの方に取り込むのも全然アリだ。

4. 個別の記事を書く (前編)

h2 見出しが入った状態の箱に対して、内容を埋めていく。
上から順に書いていきたいところであるが、ちょっと待った！そうするにはまだ早い。
ここでそうしてしまうと、全体のバランスが崩れがちになり、頭でっかちやお尻でっかちになりがちである。また、この記事で何を伝えたいのか、どこが重要なのかがぶれてしまう可能性がある。そのため、まずは「h2 見出しの下に h3/h4 レベルの詳細度を上げた見出しを付加していく」に留めるのが良いと思っている。

ポイント

詳細度を上げた内容を付与するやり方としては、レベルの低いヘッダーを利用する他にも、スピード重視でとりあえずリストで箇条書きにしていくのも有効だ。レベル感などは次のステップで考えられるため、まずは「そこで大体何を書くのか」を明らかにすることが重要だ。
また、次のステップで書くべき具体の内容を一旦明示的にしておきたい場合は、「TODO: いい感じのスクショ入れる」 のようなことを書いていても後から見てわかりやすく有効だ。

5. 個別の記事を書く (後編)

これまでのステップで骨子はできているため、あとはそれに肉付けをしていく。
具体的にやることは以下のようなものがある:

見出しの内容が過不足なく伝わるように文章で記述する
前後関係がスムーズに繋がるように必要に応じて補足等入れる
"TODO" 項目対応 (こちら)
場合によっては内容の精査・再検討もあり
最後に、typo チェック、個人情報の記載がないことの確認

ポイント

少し別の角度からの言及となるが、記事の詳細を詰めている最中に行き詰まってしまうことがある。そんな時は、別の記事の執筆に切り替えるのも手だ。メリットとしては、時間の有効活用や、気分転換、後の新たなアイディアの湧出が期待されるなどがあると思っている。逆にデメリットとしては、あまりコンテキストをスイッチしすぎると、書いている内容がおかしくなったりミスしたりする可能性があるので、きちんと管理できる範囲内において複数記事を同時並行で進めることで、生産性の向上が見込まれる。

最後に

ここまで読んでいただいた方には感謝申し上げたいが、実はこの記事で述べた方法論に基づいてこの記事は書かれていないという衝撃の事実がある。理由としては、本当に数時間前にふと今回のような内容を思いついて記事にしよう、と思い立ったためであり、そういえばこんな感じで記事書いてきたし、数をこなすにはこうあるべきだよね、というのを詰め込んだつもりだ。要は、絶対このやり方が良いというのはなく、状況や勢い・直感にも身を任せつつ、されどフレームワークまでとは行かないまでもちょっとした指針があればという思いである。

本業（仕事）として何らかのアウトプットを行っている場合を除く ↩