Qiitaに週5ペースで継続して投稿しているフローとポイントをまとめてみた

[技術的ポエム Advent Calendar 2018 \- Qiita](https://qiita.com/advent-calendar/2018/poem)の8日目の記事となります。

7月末から[アイレット株式会社](https://www.iret.co.jp/)にJOINした甲斐と申します。
アイレット株式会社は[cloudpack](https://cloudpack.jp)というサービスを主体としたAmazon Web Services（AWS）の専業クラウドインテグレータです。

>実績・経験が豊富なデザイナー、システムエンジニアがデザイン・システム設計・開発、そしてクラウドベースのインフラ設計・構築、運用監視にいたるまでワンストップ体制で、あらゆる側面からお客様の課題に向き合い、解決に導きます。


そんな会社で配属となった部署のKPIにブログ投稿数があり、これまでブログを始めてもすぐに飽きてしまい続かなかった私が、どうにか継続して技術記事を投稿できるようになってきたので、投稿までのフローとポイントをまとめてみました。

## 前提

あくまでも**継続して投稿すること**が主目的となります。いいねやストックを多くもらえる記事はかけてませんので、そういう内容を期待していた方は申し訳ありませんがいいねをポチッとだけしてブラウザバックください。

## 実績

2018/7/4からQiitaに投稿をはじめまして、本投稿がちょうど100投稿目となりました:tada:
2018/8/6から出勤したら1投稿するようになり、現在も継続中です。たま～に休みの日にも投稿しています。月に20投稿ペースですね。

ざっくりとした記事内訳は下記のとおりです。基本的には実務で扱った言語・フレームワーク・環境に関する知見をまとめて記事にしています。

- Python関連: 30
- TypeScript関連: 14
- Vue(Nuxt).js関連: 21
- Flask関連: 9
- GCP関連: 30
- AWS関連: 9
- API関連: 15
- Qiita関連: 13
- Unity関連: 9
- Docker関連: 7

※言語・フレームワーク・環境でカウントのため記事数と一致していません。

ありがたいことに、100以上いいねをいただけた記事もありました。

- 140いいね: [Vue CLIのプロジェクト管理UIがいい感じだった - Qiita](https://qiita.com/kai_kou/items/8fcabc7a8445c1be8a30)
- 122いいね: [Vue.js+TypeScriptで開発するときの参考記事まとめ - Qiita](https://qiita.com/kai_kou/items/19b494a41023d84bacc7)
- 100いいね: [DockerでVue.js+TypeScript開発環境を構築する - Qiita](https://qiita.com/kai_kou/items/d581a9f8f3ee8605aed1)

## 投稿までのフロー

そんな私の投稿までのフローとなります。基本的には実務でメモをしておいて、あとから記事にまとめて投稿する感じです。

![qiita-post-flow.png](https://qiita-image-store.s3.amazonaws.com/0/48549/7502912c-d0c8-1f20-6701-38a06aad926c.png)


はい。
PlantUMLはこちらです。これもコードで良いですよね？

```uml
@startuml
state 開発 {
  実装 --> 調査ー検証
  実装 --> ハマる
  実装 --> 不具合
  不具合 --> 調査ー検証
  ハマる -right-> ストックする
  調査ー検証 --> 手順
  調査ー検証 --> 失敗
  手順 -right-> ストックする
  失敗 -right-> ストックする
  環境構築 --> 調査ー検証
  環境構築 --> 手順
  環境構築 --> 失敗
  環境構築 --> バージョンアップ
  バージョンアップ --> 手順
  バージョンアップ --> ハマる
  失敗 --> 再現検証
  手順 --> 再現検証
  ハマる --> 再現検証
  note right: ミニマムな実装
}
state 情報収集 {
  はてぶ --> お試し
  Qiita --> お試し
  Twitter --> お試し
  techfeed --> お試し
  お試し -left-> 開発
}
state 業務外 {
  サービス設計 -left-> 開発
}
state 業務内 {
  要件定義ー設計ー提案 -left-> 開発
}
state ストックする {
  HackMD -right-> Qiita下書き
  GitHub --> HackMD
  HackMD --> GitHub
  GitHub --> Qiita下書き
  再現検証 --> GitHub
}
ストックする: 忘れないうちにメモ
ストックする: 記事にするかかかわらずメモ
state 投稿する {
  HackMD --> 投稿する
  Qiita下書き --> 投稿する
  限定共有投稿 --> 公開: AWS Lambdaで予約投稿
  限定共有投稿: しばらく寝かせてから再校正
  公開 --> [*]
}
投稿する: ストックが5記事超えると心理的安心が得られる
@enduml
```

## ポイント

### 投稿する目的

業務で開発に携わって得られた知見をできる限りアウトプットすることを目的としてQiitaへの投稿をはじめました。

転職時に前職での技術的な引き継ぎにとても~~面倒だった~~時間がかかってしまったことが、これからはアウトプットしようと決意したきっかけです。

開発したサービス・システムの保守だけでいえば、保守に関わる内容をドキュメントにまとめるだけでなんとかなるかも知れません。

ただ、今後も改善を進めていくようなサービス・システムの場合には言語・フレームワーク・環境構成を習得してもらう必要があります。今後の改善方法なんてドキュメントにできないですよねー

現時点の情報だけでなく、習得に必要な道筋もある程度提示しなければ引き継ぎが大変なので、じゃあ開発初期の段階から、調査や学習の経験を全部アウトプットしおいたら、それをトレースしてもらえて流れがわかりやすいよね？という考えに至りました。(暴論)

そして、転職したら部署の目的にブログ投稿などによるアウトプットがあったのでちょうど実践しやすかったわけです^^


### 投稿は開発ありき

Qiitaに投稿しようと決めたのは下記ガイドラインがしっくりときたからです。

良い記事を書くためのガイドライン - Qiita:Support
https://help.qiita.com/ja/articles/qiita-article-guideline

>Qiitaは、プログラミングに関する知識を記録・共有するためのサービスです。Qiita上の記事は、投稿者以外の人にとっても価値のある記事であることが望まれます。


引き継ぎが面倒で始めたのならば社内で完結しておけばいいじゃない？と思われるかも知れませんが、社外に公開しても良い内容だったら or 社外に公開できる内容にしたら、投稿してもいいじゃない。そんな感じです。


ガイドラインの内容については上記を読めばわかると思いますので、割愛しますが、できる限りガイドラインに準拠しようと意識はしています。(全部できているとは言えません)


### すぐに投稿しようと考えない

もしこれから投稿を始めよう！という方であれば、まずは何かしらの調査・環境構築・実装・検証をしたら並行してメモを取りましょう。以下のフォーマットで、あとから何に取り組んでいたのか思い出せる程度で良いと思います。
3〜10ほどメモが溜まってきたら「そろそろ投稿しようかなぁ」と考え始めたら良いと思います。
慣れてくると記事にする前提でメモを取り始める病に侵されます。

```markdown

# やってること

## 実装、コマンドのメモ

## ハマった内容

## 参考にした記事・ドキュメント

```

### 失敗したりハマったほうが記事が書きやすい

例えば、初めて触れる言語・フレームワーク・環境構築について情報収集して、みつけたドキュメントやBLOG記事のとおりに実装・設定して、うまく動作するならば記事にし難いです。それみてできるなら記事にできないじゃない。

いかにハマるかが、記事できるかどうかに関わってきます。


### こだわらずに1テーマ1記事くらいに分けて投稿する

継続して投稿をしようと考え始めると、「いかにして記事数を稼ぐか」という点が最重要項目になってきます。なりました。

例えば、Amazon CognitoでTOTP認証が使えるようになってたから検証することになりました。
で、それを記事にしよう！となった際に、私はそれをネタに3記事投稿しました。

- [Amazon Cognitoのワンタイムパスワード(TOTP)認証をNode.jsで試してみた - Qiita](https://qiita.com/kai_kou/items/aa7dc0042b44649f576a)
- [PythonでAmazon Cognitoのユーザープールを作成してみる - Qiita](https://qiita.com/kai_kou/items/f1623ac1f3d7aaab23fe)
- [AWS CloudFormationでCognitoユーザープールをMFAのTOTPを有効にして作成する - Qiita](https://qiita.com/kai_kou/items/f56bb13a5d47ee05d766)


まとめてしまえば1記事にできる内容です。
ただ、「いかにして記事数を稼ぐか」を目的とするならば、記事は分割したほうがお得。です。

記事を分けることで、内容が絞り込まれてキーワードがはっきりしてくると検索にも引っかかりやすくなるのでは？という考えもあります。(未検証)


### 複数のテーマをまとめて投稿する

先ほどとは逆のことを言っています。けれど大切です。

例えば、すでにわかりやすいドキュメントや解説記事があって記事にしてもなぁ。という状況だったとします。せっかく手を動かしたのに投稿できないのは悔しいですね。

そういうときは、複数のテーマ・Tipsをまとめてみましょう。言語xフレームワークx環境の組合せなどは鉄板です。無限の可能性があります(言い過ぎ

それぞれの解説は、ドキュメントや解説記事をありがたく参照させていただきましょう。

例)
TypeScriptで実装 + Nuxt.jsを利用 + AWS Lambdaにデプロイ
= [Nuxt\.js\(v2\.2\.0\)\+TypeScriptなアプリをAWS Lambda\+αにデプロイしてみた \- Qiita](https://qiita.com/kai_kou/items/5b1ebb9abc5d62545e04)


### すぐに投稿しようと考えない(2回目)

ストックもたまり、投稿する記事もできた！となったら、すぐに投稿せず記事を寝かせましょう。

人は否が応でもタイポするのです。読み返すとよくわからないことを書いていたりするのです。

最低でも1日は寝かせて、読み直してから投稿しましょう。書いた内容を忘れるくらいだとちょうどよいです。客観的にチェックできます。

修正はすぐにできるので、投稿してからでも読み返して校正できますが、タイトルでタイポしていたらあちこちでインデックスやキャッシュされてしまうので、訂正がとても面倒です。(面倒でした


## まとめ

まとめてみたものの、これからも継続して投稿ができるかは自分自身でもまだ未知数です。これからもフローやポイントのブラッシュアップは発生すると思います。

他にもポイントはありますが、記事数を稼ぎたいので、反響が良ければ別で投稿しようと思います^^


それでは、みなさんもぜひぜひアウトプットをしていきましょう！

## 参考

良い記事を書くためのガイドライン - Qiita:Support
https://help.qiita.com/ja/articles/qiita-article-guideline

PlantUML Cheat Sheet - Qiita
https://qiita.com/ogomr/items/0b5c4de7f38fd1482a48