トップ > CCI > 技術記事を書いてわかったタメになったこと

技術記事を書いてわかったタメになったこと

CCI アドベントカレンダー2024

この記事はアドベントカレンダー12月22日の記事です。

こんにちは、CCIのくっちーです！業務では広告資料管理のプロダクトを開発しています。
少し前にTechブログで技術記事を書いたので、その時の良かったこと、大変だったことを書いていきます。

はじめに

技術記事の定義について、様々な定義があると思いますが、この記事では「技術に関する記事」としています。ふわっとしてて良くないのですが、良い定義が見つからなかったのでこれでいきます。

技術記事の目的*1は主に以下があると考えています

  • 筆者による理解の復習・確認やアウトプットの練習のために書かれる
  • 読者に対する知識の提供を主な価値とする
  • 単なる知識だけでなく、アイデアや技術の新規性を提供する

技術記事を書く前の心境

Techブログは何回か書いているのですが、ポエム系、ゆるいやってみた系の記事しかありませんでした。正直に言うと、技術に知見が深く無いので技術記事を書くのはハードルが高かったです。

技術記事を書くことにした理由

そもそも、なぜ私が技術記事を書こうと思ったかを書いていきます。今年はMongoDBのパフォーマンス改善を担当し、得られた知見をまとめておきたいと思ったので書くことにしました。

techblog.cartaholdings.co.jp

私はMongoDBの知見が少ないので、業務では公式ドキュメントを参考にして進めていました。しかし、公式ドキュメントはパフォーマンス改善に関連する内容が散在しており調査に苦労しました。
そこで、得られた知識を整理しつつ、同じ境遇の人の参考になるようにブログを書くことにしました。

執筆プロセス

業務のISSUE・実装を元にして、調査、改善方法、苦労した点をまとめていきました。ただ書き写すのではなく、自分が根拠を元にした判断、動きを言語化し第三者に伝わるように書き換えました。

例えば、インデックスの使用を確認する方法は以下のように詳しく分解して解説しました。

  • 確認する方法
  • 実行結果で確認する部分
  • 実行結果の解釈
    • queryPlanner.winningPlan.inputStage.stageの値はインデックスを使っている、使っていないで異なる
      • 値の違い
        • COLLSCAN：ドキュメントをフルスキャンしておりインデックスが使われていない
        • IXSCAN：インデックスを使って効率良くドキュメントを読みこんでいる
      • 根拠

根拠となる情報は、正確な情報を提供するために公式ドキュメントから参照するようにしました。業務ではexplain()を実行して、パッと見て判断していたので言語化に苦労しました。

このような執筆の過程で、いくつかの重要な気づきがありました。

執筆中の気づき

執筆を進める中で、根拠となる参考資料を探し、そこから導き出される因果関係を適切に説明することが難しかったです。

この課題を乗り越えるために、社内のレビューで技術記事の書き方、根拠に基づいた文章になっているか、誤った点が無いかを丁寧に見ていただきました。 自分だけでは書くことは出来なかったので、感謝しかありません。協力していただいた方々、本当にありがとうございました！

執筆後の変化

  • Before: 知識が少ないから、技術記事は書かない方が良い
  • After: 技術記事を書いて良かった、今後も機会があれば書きたい

言語化したことで、理解が深まり再現性を持たせられるようになったと思います。また、執筆中に認識に誤りがあることに気づき新たな学びを得ることが出来ました。
今後同じ課題に取り組むときに、最短距離の解決が出来ると思います。自分だけでは無く、チーム内でも活用できそうです。 業務内で得られた知見があった時は、積極的に書いていきたいです！

まとめ

技術記事を書くことは、業務で得られた経験を元に、根拠に基づいた知識を身に着けるために必要だと感じました。また、やったことの再現性を持たせることが出来ると思います。 まずは記事を書く回数を増やしていきます。

*1:引用元：技術記事の3類型: 初心者による技術記事執筆のすすめ(https://zenn.dev/uhyo/articles/technical-articles