なぜこのブログを書こうと思ったか？ 📝
とある1on1で「テックブログってどうやって書いているんですか？」と聞かれたのが発端です。
自分は数ヶ月に1記事くらいの頻度で執筆しており、その過程をあらためて言語化して社内に展開したところ、意外とポジティブな反応をもらえたのでブログにも書き起こしてみました。
皆さんの執筆の後押しになれば幸いです🙆
そもそもなぜテックブログを書くのか？ 🤔
自分の場合、以下の3つの理由でテックブログを書いています。（上から重視している順に並んでいます）
- 思考の整理&深掘り
- 文章を書く練習
- 対外的なアピール
理由その1: 思考の整理&深掘り
1つ目の理由としては、記事を書くことで思考を整理したい意図があります。
たとえば「こういう事象やバグを改善した」という内容のブログを書くときに、「どうやってその事象やバグを改善したのか」については書くと思います。その過程で
- 改善するためにどういう実装をしたのか
- その実装をするためにどのドキュメントを参考にしたのか
- 実装した後の動作確認はどうやったのか
- etc...
などを順序立てて説明する必要があるので、その過程が思考の整理につながると考えています！
また思考の深掘りという点に関しても少し説明します。
上記の例で言うと「その事象やバグをより早く見つけ出すために何かできることはなかったのか」とか「動作確認をもっとやりやすくするために何かできることはなかったのか」など、よりプロダクトを良くするためにできることはないのか、という方向性で思考を深ぼるイメージです。
ブログを書いているときは比較的自由な時間が多い状況だと思うので、その時にあらためて振り返ってみると意外とこういうことが改善できそうとか、こういうところももう少し調べたほうが良かったなとか、そういった発見が見つかりやすいのかなと感じます！
理由その2: 文章を書く練習
2つ目の理由としては、文章を書く練習になると思っているからです！
職種にもよりますが、個人的には文章を書く機会はとても多いと思います。たとえば、エピックやタスクを作成するとき、自分が取り組んだタスクなどを会議などで報告するとき、仕様書や設計書を書くときなどです。
（コードを書くという意味ではなく）PRを作成するとき、レビューするときでさえも文章を書く場面と捉えています。
上記のような場面では、読み手に自身の伝えたいことが伝わるように
1. 使用する言葉や言い回しに注意する
2. 伝わるような構成を考える
ということが求められると考えています。その練習としてブログを書いています。
会社に所属しているならば、周りの同僚や上司にブログのレビューをしてもらうことを通してそういった能力を向上できるかと思います。
理由その3: 対外的なアピール
IT業界ではQiitaやZennなどで技術的なことをアウトプットすることが良しとされる傾向にあると感じています。
結果として業界内での知名度やプレゼンスが向上され、さまざまなメリットを享受できると考えています！
全体の流れ
さて、実際に自分がテックブログを書くときの流れは以下のようになっています！
- ネタを集める
- 書き始める前に全体を整理する
- 書いている途中に微修正する
自分はGoに関するブログを書くことが多いので、具体例ではGoの話が出てきますが、他言語や技術でも同じようなことができると思います！
ネタ集め 🏃
まずはネタを探すところからスタートします。
ネタ集めの切り口としては以下のような切り口があるかと思います！
- 英語の記事の翻訳
- 業務でこういうこと解決した/改善した系
- Goの新機能の紹介 ⭐オススメ⭐
- 単純に気になったこと ⭐オススメ⭐
- 自社の技術スタック紹介
それぞれについて具体例を交えながら説明してみます！
1. 英語の記事の翻訳
個人的には、英語の記事をちゃんと日本語に翻訳してくれている記事は少ないと感じます。そして、英語が難しいという人のために翻訳の記事を書くことの需要は一定数あると考えています！
また 「英語のドキュメントを自分なりに正しく理解して小さいコードベースでも試して挙動を確かめることができる」というスキルは、新しい技術を導入する際にとても役に立つ能力だと思っています。 このような切り口でのブログ執筆がそういった能力を研鑽する機会の1つだと捉えることもできます。
自分は以下のようなソースから書けそうな、あるいは気になる記事をピックアップしたりしてます。
- The Go Blog
- Documentation
-
https://github.com/golang/go
- おもしろいissueを追ってみたり、discussionをまとめてみたりする
-
https://golangweekly.com/
- Goに関するニュースレターを毎週配信してくれるので、その中からトピックを選ぶ
自分の記事の例で言うと Go Wiki: LoopvarExperiment を参考に以下の記事を書いてみたりしました。
2. 業務でこういうこと解決した/解決したい系
普段の業務で勉強したことや改善した問題をまとめる方向性も割とブログを書きやすいのではないのでしょうか？
あるいは、こういう技術があれば業務のこういう部分が解決できるんじゃないかってのを自分の手元だけで検証する、という方向性でも書きやすいと感じます！
自分の記事の例でいうと以下が該当します。その当時は「フロントの画面とバックエンドのAPIがどう関連しているのか分からないな〜」というのが問題だと感じていて、それをOpenTelemetryを使えば解決できるかもしれないと感じて執筆した記憶があります。
3. Goの新機能の紹介 ⭐オススメ⭐
Goの機能や新しいpackageを紹介する形式の切り口になります。
Goは半年ごとにマイナーバージョンが更新されるので、そこで登場する機能の仕様や使い方をまとめてみる形になります。リリースされた新しいGoのバージョンをどう自分のプロダクトに組み込めるか、という視点でブログを書くと楽しかったりします！
自分の記事の例としてはGo1.23で新しく実装されたイテレータの解説記事がそれにあたります。
4. 単純に気になったこと ⭐オススメ⭐
単純に気になることを深ぼる、というのもテックブログのネタになることが多いと思います。外部packageの使い方や新しい技術の紹介などを記事に起こす形です。
気になったことについては、言語間の差異やコンパイル/実装時に遭遇したエラーなどを深掘ると良いかと思います。
また「新しい技術」というと対象がとても広くなってしまうことがあるので、その中の1つの概念に絞ったりすると記事を書きやすかったりします。
自分の記事の例としては以下が挙げられます。
こちらの記事は、Go1.23でリリースされたイテレータを導入してみようと思って修正をしていたものの、思ったより上手くいかない場面が出てきて、どういうコードを書けば良いのかな〜と思ったのがきっかけで執筆したブログになります！
またこちらの記事は、インターフェイスを実装するように構造体にメソッドを実装したものの、コンパイルエラーになって何が原因なんだろう、と考え始めたのがきっかけになりました
5. 自社の技術スタック紹介
どういう技術選定で今の構成になっているのかなどを書く、というのもテックブログのネタになると思います。大体先に入社した人が書いていることが多いので書きづらいケースもあります。
ちなみに自分はこの切り口でブログを書いたことはありません😢
書き始めに考えること
ネタが決まった後に執筆を開始するわけですが、自分の場合はいきなり書き始めず、その前に考えることがいくつかあります。
具体的には
1. 全体構成を考える
2. タイトル/見出しをわかりやすくする
3. 「何を書くか、何を書かないか」をはっきりさせる
4. いつの時点の情報かはっきりさせる
1, 2はわかりやすいと思うので、3, 4について詳しく説明したいと思います。
3. 「何を書くか、何を書かないか」をはっきりさせる
「何を書くか、何を書かないか」をはっきりさせることで、書く範囲を絞ってモチベーションを下げないメリットがあると思っています！
取り上げるネタの内容によっては、書こうと思えば延々と書けてしまう場合もあります。そういった状況を防ぐために、何を書くのか/何を書かないのかをはっきりさせることで、書くモチベーションを下げることを防ぎます。
4. いつの時点の情報かはっきりさせる
「いつの時点の情報かはっきりさせる」ことは、記事の質を担保することにつながると考えています！古い記事の「こうすると解決するよ」っていうコマンドをコピペして「やっぱうまくいかんやん」って経験は誰しもあるのではないでしょうか。そういったことを防ぐために、言語やライブラリのバージョン等を明示的に記載するようにしています。
そうすることで記事の質の担保にもつながるのはもちろん、記事を見て良かったと感じた人が「いいね」やフォローをしてくれるとさらに記事を書いて良かったな/もっと記事を書いてみようという気持ちになるのではないでしょうか？
書いてる途中に考えること
最後に自分が記事を書く途中に考えていることを記載しておきます！
1. 事実 → 説明 → 検証 → 結果の順で文章を書く
2. 個人的意見と事実を分ける
3. 文体を揃える/ワーディングを統一する
4. (可能な限り) 曖昧/抽象的な表現を避ける
1つ1つ説明したいと思います！
1. 事実 → 説明 → 検証 → 結果の順で文章を書く
これは自分がよく使用する書く順序です。
- 事実: 公式docsやコードなどを引用する
- 説明: その引用を自分なりに解釈して翻訳（あるいは説明）したり、仮説を立ててみたりする
- 検証: 実際に動くコードで検証する
- 結果: 検証してみてわかったことをまとめる
というような感じですね！
2. 個人的意見と事実を分ける
大前提として事実に対する解釈は個人によって異なる可能性があると思っています。
事実と個人的意見が混じると伝えたいことが誤解されることもあるので、事実を書く文と個人的意見を書く文を分けるようにしています。たとえば、「AはBになると予想されます！（個人的意見）」→「実際に試してみましょう」→「確かにAはBでした（事実）」のように文を構成するというような感じです！
3. 文体を揃える/ワーディングを統一する
記事を読むとき、内容にフォーカスして欲しいのでそれ以外の部分で読み手の負荷や違和感に繋がらないように文体やワーディングを統一することはとても重要だと考えています！
たとえば、以下の文章は Go言語/go, インターフェイス/interface が混じっていたり、「だ・である」と「です・ます」が混じっていて読みにくいと思います。
この記事はGo言語のインターフェイスについて説明した記事である。goのinterfaceとは...のことです。
細かいですが、こういったところも記事を読んでもらうための1つとして自分が工夫していることになります。
4. (可能な限り) 曖昧/抽象的な表現を避ける
そのままですが、曖昧/抽象的な表現を避けるということも自分の中では大事だと思っています。
たとえば「AよりBの方が良い」ではなく「XXXという観点でAよりBの方が良い」とか「YYYの時、実装コストはAよりBの方が低いので良い」という表現にすると、言いたいことが伝わりやすいのかなと思います。
また言葉で説明するのが難しい場合は、図を書いたり引用することも言いたいことをより正確に伝えるために有効だと思います。
まとめ
ここまで自分が記事を書くとき、どういったところからネタを集めているのかや執筆中に考えていることを紹介しました！
個人的にはドキュメントを書くのは思考の整理につながって好きな作業でもありますし、仕事でもよく文章を書く場面に遭遇するので、これからも書き続けたいと思っています！
皆さんも、これを参考にテックブログを書いてみてはいかがでしょうか？
ここまで読んでくださり、ありがとうございました。
Discussion