新卒入社から1年ちょっと経ったころ、開発チーム内での席替え*1があり、Mackerel の OpenTelemetry 対応という大きな開発プロジェクトからは離れることとなった。それまで自分が携わってきた OpenTelemetry 対応については Mackerel 公式ブログに記事を書いたのでぜひ読んでほしい。
このプロジェクトを離れた代わりに、Mackerel チーム内で新たに発足した、大小様々な顧客要望に優先度をつけて仮説検証型アジャイル開発のサイクルを回し、インパクトの大きなものを高い頻度でユーザーに提供し続けることを目指したユニットに所属し、エンジニアをすることになった。このユニットでの取り組みによって、最近だと以下のような機能の提供が実現された：
- ホスト一括操作強化
- ホスト一覧でのホスト名による絞り込み機能
- 外形監視レスポンスタイムグラフの単位をデフォルトでmillisecondsに設定
- mkr annotations コマンドで設定する description をファイルや標準入力から読めるようにするオプション追加
- 領収書の簡易インボイス対応
- Debian 12 対応
- グラフアノテーションの一覧表示・検索機能
- 監視ルール一覧での検索ボックスの上部固定
この中で、良いなと思った機能・こうするともっと良くなると思った機能があれば、ぜひ私にフィードバックして欲しい。開発者に会って話せる機会もどんどん設けていく予定で、直近だと Mackerel Meetup #10 Tokyo が 8/30（水）に行われる。ユーザーの要望を拾ったり膨らませたりするために自分も積極的に顔を出す予定だ。
さて、このユニットは職種混合で構成されており、その中でエンジニアである自分に課せられた使命として、
- サービスの開発者でありユーザーでもある2つの目線を活かし、MVP（Minimum Viable Product）の発見に必要な意見を提供すること
- 取り組む優先順位を決め、アジャイル開発の予測可能性を高めるために、ストーリーポイントを見積もること
- MVP を手早く開発してリリースすること
- 仮説検証を行うためのデータを観測可能にすること
などが挙げられる。また、このユニットに属するエンジニアをリードしていくことも期待されている（と勝手に思っている）。
そんな状況下で、自分がどういう思考をして仕事に臨んでいるかを書き綴っていく。仮説検証型開発と絡めて書いたつもりだが、一例にすぎず一般的なエンジニアリングの話をしているような気もする。
使命を果たすために、自分に足りないスキルは何か
このプロジェクトの肝である仮説検証型サイクルに必要な要素として、リリースした MVP を検証するステップがある。ここで、ユーザーの行動や機能の利用状況を分析するためのデータ基盤への理解が浅いことに気づいた。
データ基盤を触れるエンジニアが固定化されているというチームの状況下で、すでにスキルを持っているエンジニアに丸投げするのではなく、まずは教えてもらい自分の手でデータ基盤のタスクに取り組むことにした。今では典型的なものであれば自走して取り組めるようになっている。
スキルマップを見つめて、自分は次に何をできるようになるべきか悩むことがあるだろう。できるマネージャーは各個人に対する期待感を言語化して説明してくれるのだが、その期待に応えるための具体的な手段は自分で見繕わなければならない。触れたい技術ややりたい仕事を見つける手段として、当たり前ではあるが個人への期待から深掘る方向性もあるよという話である。
目標を達成するために解決したい技術的課題は何か
ユニットの目標は「インパクトの大きなものを高い頻度でユーザーに提供し続ける」である。これを実現するために足枷になっている障害は何か、技術的課題であればどうやったら解決できるのか、というのを考えている。
見つけた課題についてはまず Slack に書き込みチームメイトの反応を伺うことにしている。よりコストパフォーマンスの良い解決方法が見つかるかもしれないし、適切な批評がもらえることもあるだろう。なんなら、自分が手をつけるより早く問題解決をしてくれる場合もある。
声を上げた上で、概ね以下のような分類で取り組んでいる：
- 自分がやればすぐ解決できそうなこと
- まずは勝手にやってみる。上手くいきそうであれば共有しチームに展開する
- 例) ドキュメントの整備、壊れにくいテストを書く、壊れにくいスタイル定義を書く、CI をちょっと直すなどの規模感
- 自分がある程度の時間かければ解決できそうなこと
- スプリントタスクではなくやりたいことをやっていい時間が確保されているので、その枠で取り組む
- 例) テストの高速化など、答えが見えきっていない規模感
- チーム全体の合意を取って進めたいこと
- 作文して開発チームの会議に挙げる。場合によっては ADR（Architecture Decision Record） を書く
あるべき理想を掲げるだけでも一仕事だが、実現できるように動くのはもっと大変だ。腕力を高めていくのと同時に、腕力で解決しきれない問題をどうチームで取り組めるように持っていくかという2軸の難しさがある。自分はどちらにもまだ伸び代が大分あると自覚していて、この半期で何か大きな実績を積めればいいなと考えている。
MVP の実装における、少し先の未来を見据えた設計
MVP はその名の通り Minimum な Product であるから、それを出したきりで終わりということはなく、さらなる拡張や方向性の修正が後に行われることがある。対応コストとのバランスという問題もあるが、ある程度未来を見据えた設計を最初のうちにしておくというのは大事なことで、長い目で見たときの工数を節約できると考えている。
未来の見通しがはっきりしているなら、その余地を作れば良い。地下鉄の延伸計画があるなら、今は不要でもホームを余分に作っておく、といった具合である。API を提供しているサービスでは、その破壊的な変更を行いにくいという難しさがある。段階的な移行手順を用意しなければならず、段取りを立てたり関係者とコミュニケーションを取ったりするだけで一苦労であるからだ。スキーマやモデリングに関しては、将来的に破壊的な変更が起こりにくいような堅牢な設計であることをレビューで確認したい。ただ、こういう筋の良い設計スキルというのは日々の経験で身に付いていくものだと思う。自分もまだまだ経験が浅く微妙な設計をしてしまったと後悔することがある。
別解としては、破壊的な変更を行うことをユーザーに了解してもらう方法も考えられる。各種サービスで beta ラベルや experimental フラグをつけて提供されている機能が思い浮かぶだろうか。
見通しがついていなくても最低限、後にそのコードを改修する際に嫌だなと思われないような開発は心がけたい。レガシーという了解がある技術・手法にわざわざ触れないようにしている。これはコピペコーディングに頼っているとついついやってしまいがちである。テックリードやある技術に長けた人の啓蒙をちゃんと聞いて納得し、自分のスキルとする動きを続けると良い。
未来を描き説得力を持って語る
前述の話題に関連して、未来を見据えるためには、そもそも未来を描かなければならない。自分は不定期でチーム内に向けてエントリを書き、プロダクトやそれを構成するアーキテクチャについてこんな夢を持ってるという話を共有している。時には夢と夢同士が結合し一つの一般化された夢になることもある。アイデアが自分の頭の中だけにあっても、その未来は自分にしか見えず、チームとしての仕事に寄与しない。
ただ、何でもかんでもやりたいです！と叫ぶだけでは、その夢はきっと実現できないだろう。チームとして取り組む優先度を見積もるための材料（理屈）も用意することも必要だ。プロダクトのミッション・ビジョン・バリューに紐づけるだとか、ユニットや事業の目標達成に寄与することを説明するだとか、そういったコミュニケーションから逃げずに向き合っている。こういった説得力というのは本当に馬鹿にならない大事なスキルなのだと思う。これは、プロダクトに関することでも、直接は価値提供に繋がらない開発基盤に関することでも同じである。
