一ヶ月間 毎日ブログを書いてみた

コンバンハ、千葉（幸）です。

さる 2022年11月に毎日ブログを1本以上書く、という取り組みをしました。

何か明確な目的があってやったわけではないのですが、せっかくなので振り返りをしてみたいと思います。

ブログを書きたい、という方の何らかの参考になれば幸いです。

なぜ始めたのか

冒頭の繰り返しになりますが、特に理由はありません。最初の3日間くらいたまたま毎日ブログを書けたので、「3日いけたなら30日いけるんじゃないか」という考えが頭をもたげてきたのでそのまま続けることにしました。

後付けをするなら以下の理由も含まれてくるかと思います。

• しばらくまとまった量をかけていなかったので書きたかった
• チームに波及させたかった

後者について補足すると、いま自分はアソシエイトレベルのメンバーが集まるチームのマネージャーをしています。ブログによるアウトプットは大事なミッションのひとつなので、どんどん書いていこうぜ！と発破をかける立場です。

メンバーに「書こうぜ！」という前に自分でも書いてみるか、という気持ちがありました。なかなかブログを書けない、というメンバーもいるので、自分でやってみた上で何らか方法論的なものを伝えたいという思いもあったりします。結局11月に書き切ったものの「自分の場合はこうだったよ」的な話を何もできていないので、そこをカバーする意図も含めてこの振り返りを書くことにします。

ブログのネタはどこから持ってきているのか

自分がブログを書くときの元ネタは大体以下に分類されます。

• A. AWS アップデート
  • 言わずもがなの AWS アップデートです
  • アップデート内容を噛み砕いて説明することを目的とします
• B. ブログから派生
  • ブログを書いたことで生まれるブログネタです
  • ひとつのブログに色々詰め込むとそのブログで何を伝えたいかがブレるな、という時に別のブログにして書きます
  • アップデートブログから派生することもあればそれ以外のブログから派生することもあります
• C. 業務
  • 普段対応している案件対応などを元ネタとするブログです
  • 案件で学んだことをブログでアウトプットする、というのはクラスメソッドのカルチャーです
• D. その他
  • Twitterやら外部サイトやらを眺めている時に気になったものや、過去にブログネタ引き出しにしまっておいたものです

2022年11月の結果を分類してみると以下のようになりました。

分類	本数
A.アップ	14
B.派生	5
C.業務	4
D.その他	10

re:Invent を前にアップデートが多くリリースされていた月ということもあり、アップデートブログの割合が多かったです。

改めて眺めると業務きっかけに書いたブログが少ないので、テコ入れをしたいところです。

どのくらい時間をかけてブログを書いているのか

2022/11分を平均すると2.614時間でした。

わたしはブログを書くときはエントリごとに Toggl で時間を計測しています。「このくらいのブログを書くときはこのくらいの時間がかかる」というのが何となく見えてくるので、まとまった量をアウトプットしたいという時には必要な視点かと思います。

平均値、中央値、合計値はこのような感じ。

項目	値
平均値	2.614
中央値	2.5
合計値	86.25

所要時間と本数の関係はこのような感じでした。

過去3年弱のトータルで考えた場合の平均値は3.552、中央値が3なので、流石にいつもよりは短めのブログが多い月になりました。

いつブログを書いているのか

これまたわたしは記録をつけているので、まとめてみると以下の結果になりました。縦軸は30分単位の時間です。凡例は画像の中に含めています。

クラスメソッドではブログを書くのも業務のうちなので、業務時間中にブログを書いても問題ありません。わたし個人としては頭の切り替えがしづらいので業務時間外に書くことが多いのですが、当月は流石に業務時間に食い込むことが多々ありました。

まとめるとこのような感じです。（前述の合計値と少しずれていますが、計測方法の違いによるものです。）

区分	時間
業務時間内	15
平日の業務時間外	30.5
休日・祝日	46.5
合計	92

全部業務時間内で済ませていたとしたら5本程度しかかけていなかったということですね。

どのようにブログを書いているのか

使用するツール

• Typora — a markdown editor, markdown reader.（マークダウンエディタ）
• Skitch | Evernote（スクショ、加工）
• フローチャートやワイヤーフレーム、プレゼン資料まで作れる | Cacoo(カクー)（お絵かき）

DevelopersIO ではマークダウンで執筆できるので、下書きはすべてローカルのマークダウンエディタで済ませています。Typora は有料のエディタですが、リアルタイムでマークダウンを描画してくれるので気に入って使っています。

Typora に対して Skitch で取得した画像をドラッグ&ドロップするとローカルの専用のフォルダに格納した上で埋め込んでくれます。

わたしの環境で言えば/Users/chiba.yukihiro/Library/Application Support/typora-user-images/です。

ひとまずスクショをどんどん放り込んでいって後から本文を書く、という書き方をすることもあります。

現在 DevelopersIO の CMS には WordPress が採用されているので、

1. ローカルの画像を一括で WordPress にアップロードする
2. ローカルの下書きの画像 URL のパスを「採番された新たな画像 URL のパス」に一括で置換する

という操作をすることである程度ラクに複数画像を含むブログを書けています。

ブログの構成

下書きをどう作っていくか、という観点では、以下の流れで進めることが多いです。

1. 書きたい内容を決める
2. 仮のタイトルをつける
3. 本文を考える（後述）
4. 正式なタイトルを考える
5. 記事の概要を考える

はじめに来るのは「何を書きたいのか」を決めることです。AWS アップデートブログであれば「新しく発表されたアップデートについて『やってみた』を交えて分かりやすく説明する」といった具合で迷う部分は少ないと思います。

「XXXをやってみた」の場合は、

• 一通りの手順を紹介したいのか？
• 特定のハマりポイントを紹介したいのか？
• やりたいことがある場合にこういった手法でできる、という紹介をしたいのか？
• ……

などなど、そのブログで何を伝えたいのかの軸を定める必要があります。軸が書く前から決まっていればいいですが、そうでないこともあります。その場合は本文を書いているうちに固めて、それを正式タイトルや概要に反映させる、ということをよくやります。

また、本文については以下の構成を意識することが多いです。

• リード文
• 冒頭のまとめ
• 前提・背景の説明
• 本文
• 締めのまとめ
• 締めの文章

もちろん内容に応じて省略する項目もありますが、上記に当てはめて考えると抜け漏れが起こりくい気がします。

この辺りは好みですが、わたしの場合は以下順番で書いていくことが多いです。

• リード文（4）
• 冒頭のまとめ（3）
• 前提・背景の説明（2）
• 本文（1）
• 締めのまとめ（3）
• 締めの文章（5）

なぜブログを書いているのか

この辺りは過去に先人が何度も言語化しています。

• クラスメソッドに入社して2年が経ちました | DevelopersIO
• DevelopersIO 著者のみんなに色々聞いてみた Advent Calendar 2021 の記事一覧 | DevelopersIO

自分も過去にそういった要素を含むブログを書いたことがあります。

• 某ブログの会社に JOIN して 354 日でブログ 100 本書いてみた | DevelopersIO
• クラスメソッド AWS 事業本部コンサルティング部のマネージャーになってみた | DevelopersIO

当時の自分が書いた内容で頷ける部分もあるのですが、いまこのタイミングで自分のことに限って言うと以下に集約されるかと思います。

• テコの原理を働かせたいから
• 出さないと気持ち悪いから

テコの原理を働かせたいから

例えば「1時間かければ理解できる事柄」があったとします。

わからないことがあった場合に、ドキュメントを読み込んだり手を動かしたりして1時間くらいあれば理解できるだろう、というものを思い浮かべてください。

わたしはいま1時間かけて事柄Aを理解しました。それをブログにしようと思うと何倍もの時間がかかります。例えば4時間かかるとしましょう。インプットにかけた時間よりアウトプットにかかる時間のほうが圧倒的に長いです。とすると、アウトプットをするより次にインプットに移ったほうが効率が良さそうです。

ここで「効率が良さそう」をよくよく考えると、個人に閉じていることが分かります。例えば自分が書いたブログによって、それを読んだ人は事柄Aを10分で理解できるようになったとします。

そうすると、こうです。これが今回言いたいことです。

自分がブログを書くのにかけた時間より多くの時間を節約できる可能性があります。そういった意味ではこちらのほうが効率が良いです。わたしは頑張っても一日16時間くらいしか働けませんが、ブログは24時間365日、世界中のどこででも働いてくれます。そういった意味でも効率が良さそうです。

「自分が書いたブログが誰かの役に立ってるかも」と思うことそれ自体がモチベーションになりますし、直接フィードバックをもらえることもあります。未来の自分が過去の自分に助けられることもあります。

いまの自分にとってはこれが一番「なぜブログを書くのか」の理由になる気がしています。

出さないと気持ち悪いから

もちろんブログを書くたびに毎回そんな高尚なことを考えているわけではありません。ニッチすぎて「これはテコの原理の働かせがいがないな」と思うものもあります。

それとは別に「これブログにできそうだなと思ったのにそれを出せていない」というのが単純に気持ち悪い、というモチベーションもある気がします。何を持って「気持ち悪い」なのかはよくわかっていませんが、「区切りがついていない」が一番近い気がします。

ブログにしていないということは自分の頭の中にしかないということです。ここは常々不便だなと感じているのですが、自分の頭の中を見ることはできません。「理解した」と思っていても本当に理解したのかが分かりません。そして脳内にあるものは時間経過とともに消えてなくなっていきます。

その点ブログにすると自分の目で見ることが出来ますし、そこに残り続けます。そこでひとまず区切りがつけられる気がします。せっかくインプットした内容なのに一区切りつけずに自分の脳内でずっと漂わせておくのか？というのが気持ち悪さの根底にある気がしています。

番外：なぜブログを書いて欲しいのか

少し本題からズレた内容となりますが、マネージャーとしての目線でチームメンバーになぜブログを書いて欲しいのかも考えてみます。

クラスメソッドの文化だから

「そういう会社だから」に尽きる気がします。ブログを書くのも仕事のうち、という文化です。

特にわたしが所属する AWS 事業本部コンサルティング部ではその傾向は強いです。他の部署に比べればブログを書きやすい環境であるはずです。仕事なんだから案件対応もだけでなくブログもバランスよくやろうよ、という感覚です。

ブログを書いて、誰かの助けになったり、クラスメソッド全体の価値を高めたり、個人としてセルフブランディングをしていったりして欲しいです。みんなそういうことがやりたくてクラスメソッドに転職してきたんじゃないの？と思っています。

できることの把握に必要だから

メンバー全員の能力をわたしは詳細に把握しているわけではありません。これは部署によって異なる部分だと思いますが、少なくともわたしのチームではそうです。

もちろん直接案件のメンターについたり他のメンターからの報告を聞いたりして大まかには把握していますが、それにも限度があります。そういった意味だと「その人がどんなブログを書いているか」は重要な観点です。

ブログを書くためにはネタ探し、時間確保、文章の推敲などなどさまざまな要素が絡みます。コンスタントに書けている人はアンテナを張ったり時間管理がきちんとできているのだろう、とか、最近この人はこのサービスを重点的に書いているからそういった案件に対応しているのかな、といった部分が見えてきます。

検証がきっちり出来ているからある程度任せられそうだな、とか文章に怪しい部分があるから顧客対応も少し注視が必要そうだな、という判断に使ったりもします。

ブログを書いて読んだ人の課題解決に貢献する、というのが一番重要な観点ですが、それだけではありません。社内のメンバーにも読まれています。レベルの高いブログを書いて、並み居る先達を脅かしていって欲しいです。

一ヶ月間やってみてどうだったか

ふとした思いつきで「毎日ブログ書いたら面白いかな」と思って一ヶ月間やってみたけど、人間がやれることじゃないなと分かったので一区切りとして終わります pic.twitter.com/dyJRB5mn1o

— Batchi（チバユキ） (@batchicchi) December 1, 2022

人間がやれることじゃないなと感じました。 ^*1

今後は自分のペースで粛々と書いていこうと思います。

終わりに

一ヶ月間 毎日ブログを書いてみた、というポエムでした。

年末はポエムを書いてもいい、という話を同僚（イマジナリー）から聞いたのでしたためてみました。振り返ってみてまたブログを書くモチベーションが湧いてきたので、来年も粛々と書いていきます。支点が悲鳴を上げるくらいのテコの原理を働かせていきたいと思います。

以上、 チバユキ (@batchicchi) がお送りしました。

付録

2022/11に書いたブログについて、所要時間と分類をまとめました。

#	投稿日	タイトル	所要時間	分類
1	11/01	[アップデート] IAM Access Analyzer が新たに 6 つのリソースタイプの分析に対応しました（全12種に！）	2.5	A.アップ
2	11/02	[アップデート] Elastic IP（EIP）を AWS アカウント間で移行できるようになりました！	1	A.アップ
3	11/03	[アップデート] EC2 インスタンスの無停止でのルートボリューム置き換え時に任意の AMI を復元のソースとして指定可能になりました！	4	A.アップ
4	11/04	[アップデート] AWS Private CA のプライベート CA に短期間の証明書のみを発行できるお求めやすい価格のモードが登場しました	3.75	A.アップ
5	11/05	[アップデート] Amazon RDS マルチ AZ DB クラスターが CloudFormation でサポートされました	2	A.アップ
6	11/06	AWS Private CA のプライベート CA は利用期間に応じた課金だけど一時的に計算前の金額が請求ダッシュボードに表示されたのでドキッとした	2.5	B.派生
7	11/07	令和なのに SSL/TLS サーバー証明書を ACM ではなくIAMにアップロードしてみた	2	D.その他
8	11/08	[アップデート] 別アカウントから共有されたプライベート AMI を共有された側でオプトアウトできるようになりました	2.5	A.アップ
9	11/08	[新機能] リージョン・サービスを横断してリソースを検索できる AWS Resource Explorer が使えるようになっていました	1.25	A.アップ
10	11/09	AWS Resource Explorer のアグリゲータインデックスを削除/降格させると次のアグリゲータインデックスの準備まで 24 時間待つ必要がある	1.25	B.派生
11	11/10	令和なのに NAT インスタンスを手作りして使ってみた	3.25	D.その他
12	11/11	NAT インスタンス用の AMI を Packer で作ってみた	2	B.派生
13	11/12	[アップデート] CloudWatch Logs エクスポート機能が出力先として SSE-KMS 暗号化 S3 バケットをサポートしました	3	A.アップ
14	11/13	Amazon AppFlow 入門として Slack から S3 へデータをロードするフローを作ってみた	3.5	C.業務
15	11/14	Amazon AppFlow カスタムコネクタ入門として amazon-appflow-custom-jdbc-connector をデプロイして MySQL から S3 にデータ転送してみた	5	C.業務
16	11/15	Amazon AppFlow カスタムコネクタで使用する Lambda 関数を VPC Lambda にする場合は Secrets Manager への通信経路を確保する必要がある	3	B.派生
17	11/16	Amazon AppFlow カスタムコネクタで Slack から MySQL にデータ転送してみた	4	B.派生
18	11/17	[アップデート] Amazon RDS イベントサブスクリプションを通じた SNS イベントにメッセージ属性が含まれるようになりました	3.5	A.アップ
19	11/18	AWSについて調べものをするときに英語版の公式ドキュメントだけが検索結果に現れるようにする	2.5	D.その他
20	11/19	AWS Nitro System による旧世代のインスタンスのサポートが本格的に始まりそうです	2.25	A.アップ
21	11/20	[アップデート] Amazon AppFlow フローの実行が CloudWatch メトリクスによるモニタリングに対応しました	1	A.アップ
22	11/21	AWS の障害分離境界について学べるホワイトペーパー AWS Fault Isolation Boundaries を読んでみた	3.75	D.その他
23	11/22	IAM ユーザーが所属している IAM グループとアタッチされている IAM ポリシーの一覧を AWS CLI で取得する	2	C.業務
24	11/23	[アップデート] SNS サブスクリプションフィルターのスコープとしてメッセージ属性に加えメッセージ本文がサポートされました	2.75	A.アップ
25	11/24	マストドン(Mastodon)のインスタンスを AWS でホストしてみた	5.25	D.その他
26	11/25	[アップデート] Amazon EBSで ごみ箱(Recycle Bin)の保持ルールをロックできるようになりました	1.5	A.アップ
27	11/25	特定時刻だけ CloudWatch アラームを抑制する、Amazon EventBridge Scheduler で。	2.25	D.その他
28	11/26	CloudTrail イベントに"errorMessage": "CallerValidation check failed"と記録されたときに気にすること	1.5	C.業務
29	11/27	AWS Step Functions ステートマシンで実行されるタスクはそれぞれセッションプリンシパルが異なる	3.5	D.その他
30	11/28	[アップデート] EFS ファイルシステムのライフサイクルポリシーで 1 日を設定できるようになりました	1	A.アップ
31	11/28	AWS CloudShell からクロスアカウントのスイッチロールをしてみた	2.75	D.その他
32	11/29	AWS CloudShell 上でフェデレーションサインイン用 URL を生成してみた	2.25	D.その他
33	11/30	AWS Cloud9 環境をちょっとだけ手軽に作ってサッと接続する	2	D.その他

脚注