この記事で書くこと
技術ブログを書くと色々いいことがあるよということを書きます。
普段コードをガリガリ書く開発エンジニアの方にも読んでいただきたいですが、インフラエンジニアのような普段コードを書かないエンジニアの方に特に見てほしいことを書きます。
私(投稿者)について
- 社会人エンジニアデビュー(社会人歴=エンジニア歴)
- ずっとインフラエンジニア (エンジニア歴=インフラエンジニア歴)
- コードはほとんど書かない(たまにshellとかpythonとか簡単なスクリプトを作る程度)
- 普段やっていること
- AWSの設計/構築/運用
- NewRelicやDatadogを利用した監視の設計/導入
技術ブログ書くのってめんどくさいよね
技術ブログを作成して公開するのはとても面倒臭いです。。。
自分の頭にあることを整理して、言語化するにはかなりの労力が必要です。。。
しかし、その手間に見合うメリットがあると思います！
私が思う、インフラエンジニアが技術ブログを公開するメリットを紹介していきます！
インフラエンジニアが技術ブログを公開するメリット
スキルの証明になる
普段コードをガリガリ書くエンジニアであれば、自分が書いたコードをGitなどのレポジトリに保存し、それを公開することでスキルの証明ができます。エンジニアの採用面接でも、Gitを見せろということがありますよね。
ではインフラエンジニアなど普段コードを書かないエンジニアはどうやってスキルを証明するか？
自分の成果物を公開していないとスキルの証明が難しいです。
自分が業務でやったこと/学んだこと/やらかしたことを技術ブログで公開しましょう！
構築した際の記録や手順、ハマったことの調査記録や解決手段、ポストモーテムなどなんでも良いと思います。
そのアウトプットの積み重ねがスキルの証明になります！
(機密情報の取り扱いには十分注意しましょう)
備忘になる
当たり前の話ですが、アウトプットすることは備忘になります。
ここで注意事項があります。それは未来の自分は他人であるということです。
皆さんご経験がないでしょうか？
チャチャっと自分用に雑にメモをして、それを数ヶ月後に見ると「????」状態になることが。
自分のやったことを技術ブログとして公開するということは、他人に見られるという前提で書くことになります。そうすると自ずと丁寧さ/わかりやすさを意識して書くことになります。
他人に見られても良いくらい丁寧に書いたものは、将来の自分(=他人)が見ても理解できるものになっているでしょう。
理解度がわかる
一見理解していると思っていたことでも、ブログに書くために言語化しようとしてみたらなかなかできないことがあります。
言語化できない=理解できていないです。
読んでわかった気になっていることも、いざブログに書き出してみようとして初めて自分の理解が曖昧だったと気づくことができます。
理解できていないことはインプットしましょう！アウトプットできるようになるまで！
自分の誤りに気づける
(理解度の話に似てますが...)
誤った知識を公開していれば、(多分)指摘という名のまさかりが飛んできます。
ショックを受けますが、自分の誤りに気づけるチャンスです。
そして、誤っていたところは必ずインプットし直して、修正しましょう！
「インプット → アウトプット → まさかり → インプット → インプット .....」といったサイクルを経て、自分の知識を確かなものにしていくことができると思います！
認知/信頼してもらえる
技術ブログをコンスタントに公開している人は、「お！この人またブログ書いているな！」と社内外で認知してもらいやすくなります。そして、それが誰かの助けになれば、信頼を得ることができます。
数年前、転職活動中に、私が投稿したQittaの記事を過去に読んだことのある方が面接官になり、選考が有利に進んだ経験があります。
技術ブログを公開すると他の人から認知/信頼されて、それが思わぬ形となって自分の助けになります！
最後に
インフラエンジニアが技術ブログを公開すると、以下のメリットがある
- スキルの証明になる
- 備忘になる
- 理解度がわかる
- 自分の誤りに気づける
- 認知/信頼してもらえる
もちろん上記はインフラエンジニア以外の全てのエンジニアが当てはまることだと思っています。
私がインフラエンジニアなので、他のインフラエンジニアの方にも技術ブログを公開する良さについて理解して欲しいと思い、記事にこのようなタイトルをつけさせていただきました。
これを見て、一人でも多くの方が技術ブログを公開するようになっていただけると幸いです！