Qiita記事を1h以内に書く方法

(追記)申し訳ありません..推敲していないので見にくかったです...ちょこちょこ直します...m(_ _)m

なんでこんなこと考えようと思ったのか？

「最近何も書いてないなー...あっ!!アドベントカレンダー!!...めんどくさい。。」
と感じたのがきっかけ。

これはTY(とっつきにくいから、やらない)の原則だなっと思ったので、
定形フロー決めれば解決すると思い立ちました。

なので1hで考えて書いてみます。
今は 12/1 9:15 すでに4分経過...

タイトルを決めよう！

まず公式の書き方を読んでみました...!!
良い記事を書くためのガイドライン
なるほど、タイトル大事みたいです。

ちょっとポイントをひねり出してみます。

ポイント① 検索するときの文言を意識すること

素直に考えると検索されてなんぼなのでどう検索されるか考えてみましょう★

- 「qiita記事さっと書くのどうすればいんだっけ。。。」
	→「qiita 記事 早く 面倒」
	→「qiitaの記事を高速に書くテンプレート！！」

ポイント②人に伝えやすい・覚えやすいこと

上手く行けば人に教えようとしてくれるかもしれません。
覚えやすい特徴的なワードを入れてみましょう！

- 「qiita記事書くの面倒？じゃあのー...なんだっけ、qiita、記事、爆速で検索してみて★」
	→ 「qiita、記事、爆速」
	→　「Qiita記事を1h以内に書く方法 ~爆速テンプレート~ 」

とはいえ...検索ワードを沢山入れすぎると長くなったりするので、ある程度諦めは必要かもです。
「Qiita記事を早く爆速に書くためのテンプレート、面倒くさくない(めんどくさくない)よ」とかお腹いっぱいなタイトルにしたくなりましたが、
この記事も我慢しています。

どういう時に見てほしいか、から一歩進んで、どう検索されるか、どう共有されるか考えてみましょー★

起きている現象と前提条件をまとめてみよう！

前提としてOSが違ったりバージョンが違うと意味がなくなってしまいます。
どういう人が対象になるのかまとめてみましょう★

起きている現象も明確にして、どういう場面で必要になったかも記載すると読みやすいかもです。

書く際のコツ

起きている事象を先に書き、影響する前提を後から考えるとまとめやすそうです。

とはいえ前提って難しいですよね...
影響する前提を正確に把握・検証する時間はないかもしれませんが、修正リクエストもあるので書くことに意味があります。
何書けばいいかなって思った時は類似トピックで前提書いてくださっている先人をリスペクトすると吉です！

読み手が今回想定している対象読者となっているか判断できるようにしましょー★

中身は書かずに見出しを全部書いてみよう

プログラムでも0から100までを「順番に作る」って難しいですよね。
文章でも多分同じなので、インターフェースを定義するつもりで見出しを書いてみましょう。

書く際のコツ

見出しだけを読めば話が完結するように意識する

できているかチェックする方法

粒度がずれてないか、飛び感がないかを、実際に見出しだけ声に出して読んで見ると自分で気づきやすい気がします！

読み手に時間がないことも考え、短い時間で望んだ情報を得られるように工夫しましょう★

起承転結(=導入/ポイント/注意点/結論)を意識してみよう

注意点が多すぎたり、原理原則ばかりで何がいいたいかわからないことってありますよね。。。
それって、結論が抜けたり、原理原則/注意点/結論が混同していたりすることが原因だと思いませんか？(むりやり)
先に分類しちゃいましょう。

各項目のポイント

• 「導入」でハードルを下げたり、あるあるネタで話に入りやすくしましょう！
• 「ポイント」は使いやすいように原則を書いていくと良い気がします。
• 「注意点」は、原理原則が実施できないパターンを想定して、救いになるような内容があれば嬉しいと思います。
• 「結論」はポイントで書いたことの拡張。この記事でいうと、書き手と読みてがいるので、ポイントは書き手側、結論は読み手側から書いてみます。
• 具体例は全セクションで必要に応じて書きましょう。注意点で書く救いの例を書いてみます。

例えば、クリーンアーキテクチャで依存をきれいにする場合に、「例えばORMライブラリの依存を嫌って全部インターフェース化するのは厳しかったりします。例外を作ることは現実的にあると思いますが、例外の対象と範囲を明確にして開発を進めましょう」というのをどこかで見て、少し救われたりしました。

構成段階で明示的に分けると、読み手が何について書いているか迷子にならず、読みやすくなる気がします★
ってかここまで書いたけど読みにくい、文章力の問題でしょうか...すみません...

最後の挨拶を考えよう！

最後どうやって終わるかって悩みませんか？私は悩みます...!!

ポイント

• 歯切れの良い締めが印象を良くする

注意点

• あまり中二病的な文言つかうと後から後悔するので、インパクトは弱めでも良いかもしれません。
  「闇の炎に抱かれて○○ろ」とか割と真面目に好きですが、書いたら後から後悔しそうです。

さわやかに歯切れよく終わってみましょう★

最初の挨拶を考えよう！

ここはインパクト勝負です！(←偏見)
個人的には、有名な「よく訓練された・・・」とかすごく好きな見出しです。
※勝手に使って申し訳ありませんm(_ _)m問題あれば削除します...!!

こんにちは！！筋肉系ポモドーロエンジニア、izumixです★ (今更!!ｗ)

この記事書きながら作ったテンプレートはこちら！

# タイトル

# 前提条件

# 解決したい問題

# 見出し一覧
## {見出し}
{導入}
{ポイント}
{ひっかかりポイント}
{結論}

## {見出し}
{導入}
{ポイント}
{注意点}
{結論}

# 最後の挨拶

# 最初の挨拶

実際のメモはこちら

# タイトル
Qiita記事を1h以内に書く方法

# 前提条件/現象
- Qiitaに記事書きたいけど、面倒くさいなって思ってしまう
- 適当に書いて文章の質がブレるのは嫌

# 解決したい問題と方法
- 面倒くささをなくす
	- 面倒と感じる原因 = どう書き始めるか悩むから
	- 対策 = *手順を見える化する*

- 文章の質をある程度固定する
	- 文章の質がブレる原因 = 書きっぷりはおいておこう、構成が一定ではないから
	- 対策 = *手順を見える化する*

----------
やばい、一個しか解決策でない。
これ解決策からの逆算すぎかな...ま、そうだからいいや
----------

# 見出し一覧
## タイトルを決めよう
{導入}　
- [良い記事を書くためのガイドライン]https://help.qiita.com/ja/articles/qiita-article-guideline
{ポイント}
- 検索するときの文言を意識すること
	- 「qiita記事さっと書くのどうすればいんだっけ。。。」
		→「qiita 記事 早く」
		→「qiitaの記事を高速に書くテンプレート！！」

- 人に伝えやすい・覚えやすいこと
	- 「qiita記事書くの面倒？じゃあのー...なんだっけ、qiita、記事、爆速で検索してみて★」
		→ 「qiita、記事、爆速」
		→　「Qiita記事を1h以内に書く方法 ~爆速テンプレート~ 」

{注意点}
- 検索ワードを沢山入れすぎると長くなったりするので、ある程度諦めは必要

{結論}
- どういう時に見てほしいか、から一歩進んで、どう検索されるか、どう共有されるか考えてみよう

## 現象と現象が起こる条件をまとめよう
{導入}
- 前提としてOSが違ったりバージョンが違うと意味がなくなってしまうので、どういう人が対象になるのかまとめてみましょう！
- また起きている事象を明確にして、どういう場面で必要になったかも記載すると読みやすいです。
{ポイント}
- 起きている事象を先に書き、影響する前提を後から考えるとまとめやすそうです。
{注意点}
- 影響する前提を正確に把握・検証する時間はないかもしれませんが、修正リクエストもあるので書くことに意味があります。
{結論}
- 読み手が今回想定している対象読者となっているか判断できるかどうか、が大切。

## 中身は書かずに見出しを全部書いてみよう
{導入}
- 0から100まで順番に作るってプログラムでも難しいですよね。
  文章でも多分同じなので、インターフェースを定義するつもりで見出しを書いてみましょう。
{ポイント}
- 見出しだけを読めば話が完結するようにする
{注意点}
- 実際に見出しだけ声に出して読んで粒度がずれてないか、飛び感がないか確認しないと後から見返すとずれてたりします...
{結論}
- 読み手に時間がないことも考え、短い時間で望んだ情報を得られるように工夫しましょう。

## 起承転結(=導入/ポイント/注意点/結論)を意識してみよう
{導入}
- 注意点が多すぎたり、原理原則ばかりで何がいいたいかわからないことってありますよね。。。
  それは、結論が抜けたり、原理原則/注意点/結論が混同していたりすることが原因が多いです、先に分類しちゃいましょう。
{ポイント}
- 導入でハードルを下げる
- ポイントは使いやすい原理原則を書く
- 注意点は、原理原則が実施できないパターンを想定して、救いになるような内容があればいいと思います。
- 結論はポイントで書いたことの拡張。この記事でいうと、書き手と読みてがいるので、ポイントは書き手側、結論は読み手側から書いてみます。
- 具体例は全セクションで必要に応じて書きましょう。注意点で書く救いの例を書いてみます。
例えば、クリーンアーキテクチャで依存をきれいにする場合に、「例えばORMライブラリの依存を嫌って全部インターフェース化するのは厳しかったりします。例外を作ることは現実的にあると思いますが、例外の対象と範囲を明確にして開発を進めましょう」というのをどこかで見て、少し救われたりしました。

{注意点}
- なし
{結論}
- 構成段階で明示的に分けると、読み手が何について書いているか迷子にならず、読みやすくなる気がします。
ってかここまで書いたけど読みにくい、文章力の問題か。

## 最後の挨拶を考えよう
{導入}
- 最後どうやって終わるかって悩みませんか？私は悩みます...!!
{ポイント}
- 歯切れの良い締めが印象を良くする
{ひっかかりポイント}
- あまり中二病的な文言つかうと後から後悔するので、インパクトは弱めでも良いかもしれません。
「闇の炎に抱かれて○○ろ」とか割と真面目に好きですが、書いたら後から後悔しそうです。
{結論}
- さわやかに歯切れよく終わってみましょう。

## 最初の挨拶を考えよう
こんにちはー筋肉系ポモドーロエンジニア、izumixです。

今が10:06！！奇跡！いや投稿ボタン押す時に微妙に超えるかも！(超えました...)タイトル詐欺と思い込み記事すみません。
これを活用して今年はアドベントカレンダーいくつか書いてみようと思います★