2024年プラットフォームエンジニア5年目のふりかえり

by ·0件のコメント
Tweet
Share
0 Shares

2024年は、2023年から取り組んでいた新プラットフォームを利用した新プロダクトのリリースをみんなでやりきりました。そこからは、より遠大な組織目標達成のための課題整理、プラットフォームのビジョン策定、具体的な設計を行い、大規模な移行プロジェクトに着手した1年になりました。

昨年立てた2024年の目標は以下でした。

今年は、プロジェクトを成功させた上で、プラットフォームを利用する社内のエンジニアにとってよい開発体験を持てる状態を目指します。プラットフォームを利用したSoftware Development Life Cycle上の各要素で参照するドキュメントがあり、標準的なサービスは滞りなく開発でき、標準から外れる場合も相談先が明確で、開発上の課題感があってもそれを表明する場があり、課題感の大きいものはおよその改善タイミングがわかるロードマップが示されている状態をもって開発体験がよいとします。

社内的な開発体験向上が最優先ですが、対外的にも胸を張って「これが俺たちのプラットフォームだ」と言っていけるような状態にもしたいです。同じような課題を抱える組織のエンジニアに対しても発信する過程で置かれた状況や課題感を体系的に整理し、フィードバックが得られやすいようにすることで、さらによいプラットフォームに育てていくのが目的です。

達成はできていません。しかし、「プロジェクトの成功」の見通しも立っていない状況での目標ながら、プラットフォームの開発体験を高めていくための土台作りや、中長期目線でよりリターンの大きい施策に取り組めています。書けないことも多いですが、できる限り具体的に振り返っていきます。

過去分

2024年

5年目にやったこと

LegalOn Cloudリリース

2023年4月にジョインしたときからずっと取り組んでいた新プロダクトを4月にリリースしました。一人目プラットフォームエンジニア、アーキテクト、インフラまわりのリードなど、時期によって立ち回りを変えながら技術選定、種々の基盤整備、交通整理、開発テンプレート実装で下回りを支えました。

リリースに向けた工夫は、テックブログの前半記事やGoolge Cloudさんのインタビュー記事にもまとまっています。

記事にない部分では、IaCやCI/CDまわりのとりくみがあります。

リリース直前には、Kuberentes manifestの記法統一のための破壊的変更を行いました。GKE上の各マイクロサービスのリソースは、TerraformとKustomizeで管理しています。規約を定めずにSRE内で分担して構築したため、思った以上に多様な記法になりました。管理していく上では、統一されていてほしい項目もあります。そこで、リリース後に停止を伴わず変更を行いづらいものを中心に、一気に統一しました。ラベル、ポート番号、ポート名などが対象です。いい感じに一括置換するのは不可能だったので、サービス開発に差し障らないように短期間で50以上のサービスを一つ一つ変更しました。ここで、サービス間でどういう項目が異なるかや、バリエーションは許容しながらも統一したい構造などの知見が得られました。記法の統一による認知負荷低減と運用効率向上以外では、Terraformで作成しているテナント系リソースのモジュール化、リリースに必須の設定項目を定めるproduction readiness checkのドキュメント整備、ポリシーのコード化などに取り組みました。

メインのワークロードのCDには、Argo CDを採用しています。Argo CDは、Syncのライフサイクル外のJob実行をサポートしていません。そのため、単発のJobはArgo CD用フォルダと分けてmanifest管理をし、手動apply（次のstepはGitHub Actionsでapply）しています。実行毎に追加するmanifestは、スクリプトにパラメタを与えて生成する形式にしています。現時点では、CUEなどで抽象化するのではなく生成するアプローチがよさそうなので、その検証も兼ねています。

SREによるTerraformやKubernetes manifest管理からプロダクトチームによるセルフサービスに切り替えていくにあたり、IaCやCI/CDの認知負荷低減は投資したい分野のひとつです。1ヶ月以内にKubernetes manifestの大規模なリファクタリングも計画しています。今後は、Kubernetes manifestの生成対象の拡大など技術的な改善に加え、必要なスキル習得をサポートするトレーニングやオンボーディングも拡大していきます。

アプリケーションプラットフォームのビジョン

アプリケーションプラットフォームのビジョンや開発戦略上の位置づけを定義・明確化し、開発組織全体に周知しました。入社直後にも似たような取り組みを行いはしたものの、プラットフォームが何もない状態で共通の認識をもつことは難しく、デリバリーの期限も厳しかったことから、Proto管理基盤や開発テンプレートなどわかりやすいものを整備しつつ、リポジトリ構造のどうしても譲れない部分を守るような動きをしてリリースを迎えました。しかし、今回リリースしたプロダクトやリージョンをこえてアプリケーションプラットフォームを利用するには構造上の課題があり、目指すべき方向性や実現するための原理原則を定め、様々な施策のよりどころが可視化された状態にする必要がありました。そのため、まずはチーム内で議論した方向性をビジョンのステートメントやフレーズという形で整理し、サポートするスコープやユースケース、アプリケーションプラットフォームの命名やロゴ、戦略を整理しました。その後、CTOや10人以上の関係マネージャーとの1on1でフィードバックを受け、リーダー陣が集まる会議でプレゼンし、各プロジェクトのステークホルダーが参加するキックオフや社内のLT会など草の根活動で認知を拡大するような動きに取り組みました。

どこまで議論して、どこは「思想」を貫くべきか、つぎのステップでは何をすべきか、そもそも自分にどこまで裁量があるのか、早く伝えたいがどこまで具体的な話にした状態でもっていくべきかなど、常に一寸先は闇状態でした。ビジョン策定は毎月・毎年のようなサイクルでやる機会があるものではないかもしれませんが、バージョニングしており事業方針にもアラインしているので、次回はもう少しうまくやれたらと思います。LLMで開発プロセスも大きな影響を受ける中で、アプリケーションプラットフォームのあり方も大きく変わるかもしれません。

ビジョン策定前の流れや具体的内容は、テックブログの後編記事でも言及しています。

アプリケーションプラットフォームのマルチリージョン・マルチプロダクト対応

ビジョン策定の両輪で進めていたのが移行です。新プロダクトのリリースをアプリケーションプラットフォームで支えたものの、他にも提供している国内外向けプロダクトで利用できる状態にもっていきたいです。その対応を行うための設計や調整に多くの時間を費やしました。後編記事でも触れているGoolge Cloud Projectと関連リソースの移行はその取り組みの一つです。形になったらまた発信します。

さらに並行して、アプリケーションプラットフォームをプロダクトとして育てるためのライフサイクルを確立する取り組みも進める予定でしたが、そちらは2025年にゆずることになってしまいました。

複業

書籍販売の維持で終わりました。

プライベートOKR

業務とは別に、プライベートOKRで四半期毎に身につけたいことを決めて取り組みました。取り組みたいことは無限にあるので、「この四半期はこれ以外はやらない」をはっきりさせる意味合いが強いです。

OKRは、各記事でなぜそれが達成したいのかや、どの程度達成したのかなどの振り返りと合わせてまとめています。

学業

大学院の振り返りはnoteに書きました。

Georgia Tech OMSCS 3年目総括

大学院に限らず課題感を持っている「ネガティブケイパビリティの獲得」をテーマにラスト1年やっていきます。

資格

なし！

登壇・執筆

2023年は外に情報が出せない状況でしたが、2024年はプロダクトのリリースをきっかけに登壇や執筆を行いました。CloudNative Days Summer 2024、Platform Engineering Kaigi 2024、builderscon 2024でプロポーザルが不採択になった後、CloudNative Days Winter 2024で採択いただきお話してきました。

先ほど出てきたテックブログは、登壇をそのまま書き起こしたものです。

Goolge Cloudさんにも事例記事にしていただきました。

キャリアインタビューもしていただきました。

※新卒入社当時希望した配属ではありませんでしたが、思い描いていたキャリアも今と異なるので配属ガチャ失敗という表現はしていません。

技術書

Platform Engineerへの闘争🐸

リストに入ってる本はほとんど読み進められていないですが、以下は読み直しました。

文字を読むのに充てられる時間は、授業に出てくる論文や課題、テスト勉強で精一杯でした。

OSS

なし！

Go-FAQ-Japanese-Editionについては、差分追従のしくみをメンテし、少し追従させました。

2025年

アプリケーションプラットフォームのビジョン実現に向けて歩みを進めていきます。

  • マルチリージョン・マルチプロダクトを支えられるアプリケーションプラットフォーム構造にする
  • デベロッパーサーベイからニュースリリースまで、アプリケーションプラットフォームのプロダクトマネジメントプロセスを確立する
  • ビジョンを実現するのに適したチーム構造にする
  • インフラ（Terraform/Kubernetes manifest）以外の領域のプラットフォームコンポーネント管理やプロジェクトの成果物を利用可能な状態にする（Feature flagやスキーマ管理機構など）

自分の能力や権限だけでできないことがほとんどです。チーム横断的なプロジェクトへの協力を仰いだり、適切な権限をもつ人へ提案したり、自身の権限を拡大できないか相談したりすることになると思います。

他には、来年振り返るときに各論を書かないで良い程度に登壇や記事化できたらよいなと思います。2025年は、Google Cloudさんにより多くの登壇や情報発信の機会をいただける予定です。そういった機会を通じてコミュニティに貢献し、社外からのフィードバックも踏まえてブラッシュアップしていきます。

Tweet
Share
0 Shares

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です