Mobile Factory Tech Blog

技術好きな方へ!モバイルファクトリーのエンジニアたちが楽しい技術話をお届けします!

技術ブログが書ける開発をする

この記事はモバイルファクトリー Advent Calendar 2021の25日目の記事です。


メリークリスマス🎉 エンジニアのid:kfly8です。

技術ブログの「ネタがない」といったコメントや「この記事の課題がよくわからない」といった記事レビューをすることがあります。技術アドベントカレンダーの時期は、短期間に記事が集中するので、特に困らせているように感じます。

普段から意識する習慣で、楽ができないかと考えると、「技術ブログが書ける開発をする」のが良いと思いました。

誤解しないでほしいのが、「技術ブログを書くために開発をしよう」と言いたいわけではないです。あくまで、チーム、事業の目的ありきです。

ただ「技術ブログが書ける開発をする」ことは、普段の開発の質を高めると思っています。

技術ブログが書ける開発とは?

モバファクの技術ブログでは、「課題を解決する方法や経験を発信したい」と思っています。課題の大小は気にしていなくて、解決策もエレガントでなくても、最新の技術でなくても全然良いというコンセプトで運用をしています。(継続も大切にしたいので、技術ブログの執筆の敷居はどんどん下げたいです。)

昔、koba04さんに言われたことで、よく覚えている言葉があります。

「半年経って、技術ブログに書くことがなかったら、何かがおかしい。」

当時、エンジニア1年目だった私は、ネタに困ったので、印象に残っています。

今思うと当然のことだと思います。なぜなら、普段の開発は、課題解決の連続だと思うからです。普段やっていることを文章にすれば、技術ブログ1本になる。書けないとしたら、普段、課題解決をしていないかもしれない。そんな気づきを得る言葉だと解釈しました。

つまり、技術ブログが書けるかどうかが、課題を解決する開発になってるかどうかを示すバロメータになっています。技術ブログが書ける開発は、良い開発ができていると思います。

「技術ブログが書ける開発」のための2つの工夫

けれど、実際問題、技術ブログを書きたかったとしても、書くのに苦労します。

不安、恥ずかしい、忙しいといった技術ブログが書けない理由は一旦置いておき、普段の開発で、次の2つの工夫をすると技術ブログを書きやすくなると思います。そして、開発の質も上がると思います。

1つ改善したいことを設定して、開発する

「仕様から動くモノにする」ことは、プロダクト開発をするエンジニアのメイン業務だと思います。ですが、この開発業務をそのまま技術ブログに書くことは難しいです。なぜなら「仕様から動くモノにする」ことは、プロダクトチームの人だけに通じる業務知識が混じり、そのコンテキストを共有しない人は、理解・共感ができないからです。つまり「記事の課題がよくわからない」となりがちです。

そうならないために、1つ改善したいことを課題設定して、開発すると良いと思います。テストケースを足す、ドキュメントを丁寧に書く、不要なコードを消すなど些細なことでも良いと思います。

「本当に改善になるのか?現状がどうなっているか?どうなったら嬉しいか?解くべき問題は?」と少し立ち止まって、普段の開発の抽象度を上げて考えてみます。

例えば「MyApp::Utilsが開発しづらいから改善しよう」より「巨大になったユーティリティクラスを、役割ごとに分割し、ユーティリティと名乗るのをやめたい」の方が、MyApp::Utilsを知らない人にも通じると思います。また、単一責務の原則など一般的な知識を利用できます。

開発業務の抽象度を上げることで、コンテキストを共有していない相手に伝わりやすくなり、一般的な改善方法を適用しやすくなります。

簡単に言えば、改善の取り組みは、そのまま技術ブログに書きやすいです。 もし技術ブログに書きにくい改善の取り組みがあれば、真に改善とは言えない内容かもしれないです。

改善したいことを1つに限定するのは、シンプルさのためです。一度に複数のことをすると効果がわかりにくくなり、リードタイムも長くなり、結果、変化に追いつきにくくなります。

ふりかえりをする

技術ブログの「ネタがない」と言う人は、大抵ネタを持っています。「ネタを思い出せない」「ネタになると認識していない」ため、そんなことを言うんだと思います。

開発業務で様々な経験をしても記憶が薄れれば、大したことがない、当たり前と感じ、わざわざ他人に共有する動機がなくなります。

これは正直、もったいないと感じます。当たり前に感じてることが、他人に取って当たり前とは限らないと思うからです。また、似た失敗をしやすくなると思うからです。

ふりかえりは、すごく普通の対応です。がちゃんとやると良いと思います。ふりかえりで、経験、行動の意味、価値を言葉にし、嬉しかったこと、ハッとしたこと、しくじったときの苦渋など、感情も味わいます。

言葉にできていないことは、思い出しづらく、認識がしづらいです。

まとめ

  • 開発に関する技術ブログを書くには、開発の課題解決を抽象化する必要がある
  • 改善やふりかえりは、課題解決の抽象化、言語化を助ける
  • もし技術ブログを書けないとしたら、真に課題を解決していないかもしれない

以上です。それでは良いお年を!