2023年は、これからまさにプラットフォームエンジニアリングを行っていく組織にICとして転職し、プラットフォーム立ち上げの様々な課題に立ち向かいました。
メンバー構成やプロジェクトのフェーズ、解決すべき課題を踏まえて大きく立ち回りを変えているのでずっとプラットフォームエンジニアリングにICとして取り組んでいたわけではありません。それでも昨年末に掲げた「ワシ（自分が一定以上貢献したと自分で感じられる限りワシら）が育てたと思えるものが一昨年以上に大きくなっていること」を達成できた1年でした。
過去分
2023年
４年目にやったこと
4年目は以下のような活動に取り組みました。コンテキストがあってはじめてつながる話なので、ちぐはぐに感じる部分もあるかもしれません。今はまだコンテキストを語るタイミングではないので、場を改めてそのあたりのお話や体外的な発信をしていけたらと思います。
- 一人目プラットフォームエンジニアとしての活動
- アーキテクトとしての意思決定
- 基盤プロジェクトのマネジメント
- Goバックエンドサービスの技術選定とテンプレート実装
- アプリケーションリポジトリのCI
- KubernetesリソースのCD
- proto管理
一人目プラットフォームエンジニアとしての活動
アーキテクトと兼務しながら一人目のプラットフォームエンジニアとして活動を始めました。
最初の1週間で行ったのはプラットフォームエンジニアリングを行うチームのビジョン・ミッション・バリューのドキュメント化です。アプリケーションプラットフォームの必要性が高まっていた時期に入社したこともあり、その背景となる課題感が書かれたドキュメント、それまでのエンジニアリング観点の振り返り、取り組むプロジェクトの1〜2年のイメージを共有してもらった上で、目指したいプラットフォームを定義しました。プラットフォームエンジニアリングと関連の深い既存の取り組みやチーム、スコープとなるシステムコンポーネントも合わせて整理しています。1年後に目指したい状態という別ドキュメントで、より詳細なロードマップを描いています。
プラットフォーム構築に向けて動き始めたものの、歴史的経緯を踏まえて生み出そうとしていたdedicated SREとの棲み分けや、embedded SREやイネーブルメント機能をもつ役割との分担はプロジェクトを進める中でまだやるべきでないと感じました。そのため、現状プラットフォームとそれらの枠割を分けずにアプリケーションが動く基盤を作る部分にフォーカスしています。コンポーネントにもよりますが、開発者の生産性が上がるようなインフラが抽象化されたプラットフォームにはなっていません。一通り開発フローを通してから、理想像への方向性の組織的な合意や文化形成をやりながら、課題感が大きい部分の優先度付をした上で開発体験を上げていきたいと考えています。
基盤プロジェクトのマネジメント
プラットフォームエンジニアリングを推進するICとして活動をはじめたものの、メンバー構成やプロジェクトの状況を踏まえ、インフラ構築含めたプロジェクトマネジメントのロールに費やす比率が大きくなりました。プロジェクト全体のマイルストーンを踏まえ、直近数ヶ月のフォーカス整理、メンバーのアサイン、各アプリケーション開発チームなどステークホルダーとの調整、横断的な課題解決など、プラットフォームのコンポーネント実装と並行してプロジェクトを推進しています。ピープルマネジメントはやっていません。
プロジェクトのリードのロールを担う上で、プロジェクトマネジメント的性質をもつのはよくあることと思いますが、よくあるプロジェクトマネジメントとプロダクトマネジメントの違いとして挙げられる「プロジェクトがQCDを考慮していかに終わらせるものであるかに対し、プロダクトマネジメントは継続的によくするものである」というのを強く感じた1年でした。もちろんプロダクトマネジメントもQCDは意識しますし、プロジェクトマネジメントも継続的な改善はするのでしょう。しかし、思考の性質として収束と発散は相容れず、プロジェクト思考が強いとロードマップを描いて発展させていく心境にはなりづらいです。今年はプロジェクトマネジメントにより重きを置いていこうと思います。
SREやインフラの道を歩んできたわけではないので、インフラ構築に重きを置くフェーズでリードしづらいという課題感もあります。まわりのメンバーの力を最大限借りて日々生きています。何かしらの課題は究極的には腕力で何とかできる状態でありたいですが、課題へのアプローチはhowの可能性を提示する、明らかに異なる可能性を閉じる、寝かせるべき課題だと意思決定する、詳しい人に巡り合わせる、期間を調整する、他の負荷を減らす、アサインを調整するなどいろいろとあるので、課題解決を前進させるためのアクションをとれるリードであろうと思います。
アーキテクトとしての意思決定
プロジェクトの技術的意思決定を行うアーキテクトを兼務しています。インフラやアプリケーションプラットフォームに閉じずに議論し、design doc、decision record、ガイドラインを書いたり、レビューしたり、実装したりしています。やりたかった仕事のひとつなのでやりがいはあるものの、力不足は否めません。現在は立場上、特にインフラ（とスキーマ、Goのテンプレートやミドルウェアなどインフラとアプリケーションの接点）観点でよりよい意思決定ができるよう意見する必要があると思っています。意思決定技術要素すべてにハンズオンでの経験がある状態を目指すのは難しいにしても、議論する上で決定を後押しするか待ったをかけるかはできるように、意思決定の汎用作法を身につける（可逆・不可逆意思決定かどうかの判断、情報の前提をそろえるなど）、ソフトウェアエンジニアリングやコンピュータサイエンスの常識・論点のカバレッジを高める、特定要素の解像度を高めるのをやっていきます。コンポーネントレベルの解像度を上げるにあたっては、大体頭に入っていて即座に議論できるもの、コードや設定を見たり調べればわかるもの、設計ドキュメントを見ても基礎がなっておらずよくわからないものを分けるところから取り組む必要があります。
Goバックエンドサービスの技術選定とテンプレート実装
バックエンドのサーバーをGoで書き始めるということで、DBアクセスのあるサーバーを書くにあたり必要な各種ライブラリの選定、テンプレート実装、ローカル開発のためのMakefile、CIを準備しました。connectrpc/connect-go、sqlc-dev/sqlc、matryer/moqの導入が特徴的です。ライブラリの好みは個人それぞれだとは思いますが、ある程度公式やGoogleが出しているガイドやコミュニティで一般的なものも念頭にときながら、組織がおかれたエンジニアリング・ビジネス状況やアーキテクチャを踏まえてpros/consを比較し妥当な落し所を見つけるのがアーキテクトの醍醐味と感じる場面がありました。これもコンテキストなしには語りづらい部分と思います。
バックエンドエンジニアとしてGoの経験があったので取り組んだものの、アーキテクトとしてなのか、プラットフォームエンジニアとしてなのか、まわりから見たらどういう位置づけで準備されたかわかりづらいものだったのかなと思います。個別のサービスでないテンプレートやミドルウェアはプラットフォーム的なチームが継続的にメンテできるとよいですが、インフラとしてのアプリケーションプラットフォームにかなりのパワーが必要な中でどう関わっていくかは悩みどころです。
Proto管理
サービス間通信にConnect（フロント -> バックエンド）とgRPC（バックエンド）を採用したので、protoファイルや生成コードを管理するしくみ、CI、ガイドラインを整備しました。生成コード管理にはBuf Schema Registry（BSR、Proプラン）を採用し、CIはBuf CLIを主軸に構築しています。続々と機能追加されて便利になっていくBSRの恩恵を受ける一方で、一部の利用言語でbufbuild/protovalidateとBSRのプライベートなインスタンスのかみ合わせがよくないなど、いろいろと踏んでいます。Bufべったりなので、ConnectのCNCF寄贈など、エコシステムの安定化とさらなる発展を祈っています。
アプリケーションリポジトリのCI
歴史的経緯を踏まえ、複数サービスとスキーマをモノレポ管理しています。組織における理想的なリポジトリ構成が見てない中でモノレポ用ツールで最適化するのは時期尚早と判断し、GitHub Actionsのcomposite actionとサービス毎のトリガーファイルで構成しています。サービス追加時に言語を選択することで適切なcomposite actionを利用するトリガー用のworkflowを作成し、サービス固有で必要な処理は各サービスが追加するという立て付けです。サービス数が増えても破綻しない形で、8割のユースケースをカバーする標準と必要に応じてカスタマイズできる状態をシンプルに実現しています。高速化やコスト最適化、セキュリティ観点での改善など、かなり伸びしろがあります。
KubernetesリソースのCD
GKE上で稼働するアプリケーションのデプロイは、GitOpsを徹底すべくArgo CDとArgo CD Image Updaterを採用しました。1サービス内でサーバー以外にも補助的な各種ワーカーを管理したり、ワークロード間の整合性を保った状態でスキーママイグレーションを行ったり、テストや非機能要件に基づいて環境毎に異なるデプロイ戦略をサポートしたりするためにいろいろ工夫して実装しているところです。各サービス要件に応じて柔軟に実装してほしい一方で、コンテナの作成方法など一定の制約を設けないと標準化も難しくなります。柔軟性を認めて生まれる維持コストに見合うメリットが大して得られないこともあるので、「8割のユースケースをカバーする標準と必要に応じてカスタマイズできる状態」を実現するためのさじ加減や制約（妥協）、利用者から見えづらい（見せてはいけない）部分の実装の複雑さとやりきる腕力は、その時点・状況・情報で考えられたベストな設計と時間の経過とともに浮き彫りになる後悔と改善を繰り返して高めていかねばと思います。
複業
学業の負荷増大により、細々と続けていた複業もお休みさせていただいています。お休み前はCloudflare Workersのログ整備などをやっていました。
プライベートOKRとインプット・アウトプット
業務とは別に、プライベートOKRで四半期毎に身につけたいことを決めて取り組みました。取り組みたいことは無限にあるので、「この四半期はこれ以外はやらない」をはっきりさせる意味合いが強いです。
OKRは、各記事でなぜそれが達成したいのかや、どの程度達成したのかなどの振り返りと合わせてまとめています。
- 2023年1〜3月ふりかえりと2023年4〜6月OKR 〜開発しやすさを探求するための土台づくり〜
- 2023年4〜6月ふりかえりと2023年7〜9月OKR 〜落ち着いて生きる〜
- 2023年7〜9月ふりかえりと2023年10〜12月OKR 〜唯一の必修に備え、最高の家に一歩踏み出す〜
- 2023年10〜12月ふりかえりと2024年1〜3月OKR 〜諦めよく、よいリズムで生きる〜
学業
大学院の振り返りはnoteに書きました。
残り半分、このまま分散システムやコンパイラ、クラウドコンピューティングの内部実装（クラウドという、自分が考える最も価値あるプラットフォームの一つを開発する仕事につながるもの）を学んで深めるもよし、セキュリティを学んでプラットフォームにアドするもよし、NLPやAIなど自分にとって未知の分野で新しい出会いを求めるもよしです。そう書く字面はキラキラしてますが、心身ともにギリギリなのでよい生活習慣、学習スタイルを確立すべくこの一年を過ごします。
資格
ついにCKSも失効し、Kubernetes系、Google Cloud系の資格はすべて失効しました。資格形式でキャッチアップするのが妥当な技術に触れるときは検討します。
執筆
前職の技術ブログを2つ書いたくらいで、ほとんど書いていません。
社内では、design docやdecision recordをたくさん書きました。今年は対外的に発信できることも増えると思います。
技術書
リストの中で読み終わった・読んでる本。
授業で触れる講義・論文や予習用の書物以外の技術書に触れる時間をほとんど確保できていません。それらの情報の咀嚼方法もよくないように感じています。2023年10〜12月ふりかえりと2024年1〜3月OKR 〜諦めよく、よいリズムで生きる〜で1〜3月のOKRに掲げているように学び方を学び直すのもこのタイミングで再投資します。その結果、もう少し流行りや目の前の課題を解決する情報に触れられるようになるとよいですね。
登壇
無登壇。今年はします。
OSS
- Google Go Styleの日本語訳
- Go FAQの日本語訳
- toshi0607/dfcxの開発
- Dialogflow CXのデプロイツールです。公式でいい感じにサポートされていなかったので作りました。
- ent/ent
- 方向性はPR出した意図と変わったけどドキュメント修正です。
- Fix go install instruction for atlas
- bufbuild/protovalidate
- protovalidateを導入するにあたり、CELを利用したカスタムバリデーションの構文チェックが入ってなかったので機能リクエストしました。最近サポートされたっぽいです。
- [Feature Request] Lint cel expression
総括
学業も含め、かなり自分のキャパシティをこえたチャレンジングな一年でした。それでも、特に関心の強いプラットフォームエンジニアリングの分野で、様々な困難を乗り越え自分たちが生み出したと言えるような基盤が動き始めていることは本望です。組織の技術的意思決定を推進するアーキテクトとして、振り返ってみればよりよい選択ができた可能性があるという意味で悔しい思いを繰り返して前進できていることも救いです。各項目で書いているような力不足や開発体験まで手が回っていないことなど課題も多いですが、立場・役割に育てられて得たものも大きいです。
2024年
今年は、プロジェクトを成功させた上で、プラットフォームを利用する社内のエンジニアにとってよい開発体験を持てる状態を目指します。プラットフォームを利用したSoftware Development Life Cycle上の各要素で参照するドキュメントがあり、標準的なサービスは滞りなく開発でき、標準から外れる場合も相談先が明確で、開発上の課題感があってもそれを表明する場があり、課題感の大きいものはおよその改善タイミングがわかるロードマップが示されている状態をもって開発体験がよいとします。
社内的な開発体験向上が最優先ですが、対外的にも胸を張って「これが俺たちのプラットフォームだ」と言っていけるような状態にもしたいです。同じような課題を抱える組織のエンジニアに対しても発信する過程で置かれた状況や課題感を体系的に整理し、フィードバックが得られやすいようにすることで、さらによいプラットフォームに育てていくのが目的です。