このエントリははてなエンジニアAdvent Calendar 2023の2024年1月8日の記事です。
昨日は
id:handatさんのGitHubでパブリックリポジトリへの誤投稿を防ぐ拡張機能「GitHub Public Repo Alert」の紹介 - handatのdatファイルでした。
私
id:arthur-1はサーバー監視サービスMackerelの開発チームでアプリケーションエンジニアをしております。
昨年末に開催したMackerel Advent Calendar 2023において、「arthur-1 Mackerel Advent Calendar 2023 マラソン」と称し、一人で25日分記事を投稿することができました。Mackerel開発の裏話を放出したり、ちょっとした便利ツールや実装例を作ってリリースしたり、将来の夢を語ったりしました。
このエントリでは「Advent Calendarを25日分続ける技術、あるいは物を発明し素早く作る技術」と題して、25日分の投稿を実現させた様々な技術についてご紹介します。
周囲を見渡してネタ帳を書く
Advent Calendarを25日分書くにあたって最初の関門が25日分のネタを探すところにあります。私はAdvent Calendarに限らずアウトプットできそうなことが思いついたら手元のネタ帳に書き留めるようにしています。
- 世の中にまだないけど作れそうなもの
- プロダクトを良くするためのアイデア
- 具体的な仕事から得た一般化できそうな知見
- 技術的に試行錯誤してみた記録
上記に限りませんが、思いついたことは忘れないうちにどこかに記録しておきます。思いついた段階ですでにストーリーがある程度浮かんでいる場合には早速ブログ記事を書いたり、社内のグループウェアでラフな感じに書いたりすることもあります。
自分の仕事の責任範囲が広がると勝手に見える景色も変わってくるし、そこまでしなくても周りの仕事にちょっと首を突っ込んで観察するだけでもネタ探しに役立ちます。また、いろんな意味でオープンな環境で仕事をすることで、自分で捻り出さなくてもネタが見つかると思います。はてなのオープンネスを重視した環境（例えば他のチームのSlackの様子も見られる）がまさに絶好の場です。
論理的思考からアイデアを生む
自分は何かを体系的に学ぶより、モノづくりの過程で学んだことをアウトプットすることが多いです。実際、今回のMackerel Advent Calendarでもさまざまなソフトウェアを作りました。そして、モノづくりにはアイデアが必要不可欠です。
アイデアマンでいるために重要なのが論理的思考（とりわけゼロベース思考）とドメインへの理解だと思っています。
「誰のどのような問題を解決したいのか」という本質だけを固定して思考実験すると、世界には無数の択があることがわかります。すると、固定観念や既存のプロダクトの仕様に引きずられずにアイデアを得ることができるでしょう。そしてそれがまだ世の中（あるいはもう少し狭くして現在のプロダクト）に存在しないものだからこそ、ユニークな情報としてブログのネタにすることができます。
ここで攻めた思考をする際に道を踏み外さないために、ドメインへの十分な理解というガードレールが役に立つと考えています。ユーザーが本当に求めているのは何か、これを解像度高く理解していなければ、本当に突拍子もなく役に立たないアイデアに走ってしまう可能性があります。ドメインへの理解が十分だからこそ、道を離れる（≠踏み外す）ことができるのです。
新しい技術に触れる
枯れた技術に関する情報はネットを検索すると先駆者がいて出てくることが多いです。Advent Calendarで二番煎じなネタに走らないためにも、日頃から新しい技術に触れておくのは大事なことです。
私は仕事以外でも精力的に個人開発をしていますが、そこは自分の庭のようなもので金銭面以外での制約がほとんどないため、積極的に新しい技術を取り入れるようにしています。その結果得た知識をブログなどにアウトプットしています。例えばこのブログでは、Next.js App RouterでのStatic Exportsに疲弊している記事のアクセス数が比較的多いですね。
2023年に自分が新たに触れたのは以下のような技術で、普段のブログやAdvent Calendarではこれらと絡めた投稿を多めにしていました：
- GraphQL
- Kubernetes
- GitOps
- Next.js App Router
- OpenTelemetry
- Slack次世代プラットフォーム
開発からリリースの広い範囲において、自分の鉄板技術を持つ
思いついたアイデアを形にするためのモノづくりに時間がかかっていると、Advent Calendarのスピード感に追いつけません。
私はアプリケーションエンジニアとして仕事をしていますが、アプリケーションを作る（サーバーサイド・フロントエンド）、そしてそれをリリースするまでの一連の技術を一通り触れるようにしています。また、典型的なアプリケーションを作るならこの技術をこのようにして使うというテンプレートを自分の中に持つようにしています。
最近自分がWebアプリケーションを作るとしたら選択する鉄板スタックは以下の通りです：
- サーバー: Go・go-chi
- フロント: TypeScript・React
- CI: GitHub Actions
- インフラ*1: Terraform・AWS Lambda・API Gateway・Cloudflare Pages
Advent Calendarのために何らかの物を作る際も、新しい挑戦以外の部分では自分の手に馴染む技術をこれまでと同じように利用する（＝だいたいコピペでOK）ことで高速に開発・リリースできるようにしています。
隙間家具コーディネート職人になる
これも素早く物を作るためのテクニックなのですが、できる限り自分で手作りしすぎないようにしています。ではどうするかというと、すでに世の中に存在するライブラリや隙間家具OSS*2をうまく繋ぎ合わせて実現できないかをまず考えるようにしています。
例えば以下の記事では、Mackerelでシナリオ監視ができるツールを、runnというシナリオテストツールを組み込むことによって開発しました。本来であればシナリオの記述やテストの実行ロジックをまるまる作らなければならなかったところを、runnのソースコードで公開されている関数をimportすることでサクッと実装することができました。
汎用的なライブラリを作ってくださっている人たちのおかげで、自分がアイデアの実現に集中してクリエイティブに活動できるのは本当にありがたいことです。
仕事でも良い文章をたくさん書く
いくらアイデアや制作物があっても、Advent Calendarとしては他者が読む文章にしなくてはなりません。読者に伝わる良い文章を書くために、普段の仕事の経験も活かすことができます。
エンジニアとして自分が良く書いている文章はArchitecture Decision Record（ADR）です。ADRとは、アーキテクチャの決定やその背景・理由などを記録する文書です。Mackerel開発チームでは技術的な決定を行う際にADRを書き、テックリードの確認を受けることになっています。
自分がADRを書く際には、一目読んだだけで何に関するどのような決定かが分かるようなタイトルをつけたり、決定の合理性が他者に伝わるよう簡潔に論理的に記述したりすることを心がけています。
他にも、Mackerelのブログで公開されているリリース告知に対して開発者としてレビューする機会があります。
ここでは、一文が長くなり過ぎないように区切るなど、読みやすい日本語にするための指摘を気付きベースで行っています。また、新機能のターゲットとなるユーザー像を思い浮かべ、その機能で何が嬉しいのかがより伝わりやすいように具体例を提示するといった助言もするようにしています。
こういった業務での経験が、頭の中の思考をAdvent Calendarの記事として書き起こす際にも非常に役立っていると感じます。
雑多に色々書き綴ってしまったのでまとめます。Advent Calendarマラソンのために特化した技術はそこまで必要ではなくて、モノづくりができる人であり続ければその延長線として実現できることなのだと思っています。
これを読んだ皆さんも今年のMackerel……に限らず何かのAdvent Calendarを一人で完走してみませんか？
*1:個人開発なので安さ重視の選定になっています。マネージドRDBはどうするの問題は未解決です
*2:cf.) https://speakerdeck.com/fujiwara3/xi-jian-jia-ju-ossfalsesusume
