Qiita株式会社 Advent Calendar 2021(2)の22日目の担当は、CX向上グループの@xrxoxcxoxです!
この記事の概要
意気込んで記事を書こうとしても「何を書いたら良いんだろう……」と悩んでしまう方をよく見ます。
分かります。記事のネタってぽいぽい浮かぶものじゃないですよね。
そんな悩みを解放すべく、できるだけ気軽に記事を投稿する(=アウトプットを増やす)ためのTipsを書いてみました。
流れ
- 前提:なにかしらのものを作る
- どこかで苦労するので、スクリーンショットを撮る or エラー内容をコピーしておく
- Qiitaの下書きを開いて、簡単な説明とともにスクショやエラーメッセージを添付しておく
- 頑張って開発して、上手く動いたらそれもスクリーンショットする
- 一連の流れをまとめる
前提:なにかしらのものを作る
さすがに無から有を生み出すことはできませんから、何かを作っている前提です。
もちろん、だいそれたものでなくてもOK。
GASやVBAを用いた、ちょっとした業務効率化ツールでも、趣味で作っているプロダクトでも、業務で書いているコードでも、何かがあれば大丈夫です。
どこかで苦労するので、スクリーンショットを撮る or エラー内容をコピーしておく
ものをつくっているのに、初めから全てが上手くいくわけがありません。
大なり小なり苦労がやってきます。
しかし大変な場面に遭遇したときこそむしろチャンス。
コンソールに流れるエラーや崩れた画面、それらをスクリーンショットに収めるかエラー文をコピーして保存しておきましょう。
私はデスクトップに「次のQiita記事用」とか適当な名前をつけたフォルダを作成し、雑多に保存しています。
どんなときに発生した画面 or エラー文なのかもセットで記録しておくと更にGOOD。
後から再現しようと思っても何故かおきないとか、一度上手くいったのにもう一度エラーを撮影するためだけにコミットを遡るとか、面倒なのでなかなかやれません。
リアルタイムで記録しておくのが手間が少なくておすすめです。
Qiitaの下書きを開いて、簡単な説明とともにスクショやエラーメッセージを添付しておく
画像やテキストファイルとして保存しておくと後から訳が分からなくなりそう……という場合は、この段階でQiitaの下書きに保存するのも良いと思います。
時系列で画像やエラー文を載せて、およその見出しをつければ振り返りもしやすいのではないでしょうか。
ちなみにこの段階で文章にこだわる必要は全くありません。
ただ、説明を多少丁寧に書いておくと後から肉付けするだけで良くなります。
頑張って開発して、上手く動いたらそれもスクリーンショットする
エラー内容が変わったとか、上手く動いたとか、そういう変化があればスクリーンショットを撮って適宜保存しておきます。
また、参考にしたURLなどもこの時点でメモしておくと良いでしょう。
一連の流れをまとめる
完成してから振り返れば当初どこが間違っていたのかも明らかになっているはず。
最初はどんなミスをしていて、どんな検索をしたらどんな資料を見つけて、どのように動くようになったのか……をまとめていきます。
この書き方のメリットは、自然と実際の開発内容に基づくことです。
あなた自身の振り返りとしても、似たような技術スタックで開発している人にとっても、どちらにとっても役立つ記事になりやすいでしょう。
まとめ
- 記事を書こう!とすると難しい
- 備忘録をつけておいて、後から文章の体裁だけ直す方が楽
- かつ、実際の作業に基づいた記事が書けて良い感じ