by ·0件のコメント

2025年は、2024年に着手していたプラットフォームの大規模な移行をみんなでやり遂げました。不退転の覚悟で臨んだマルチリージョン・マルチプロダクト対応を完遂し、アプリケーションプラットフォーム（Akupara）を次のステージに進められた1年でした。

昨年末に立てた2025年の目標は以下です。

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

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

チーム構造の話はAkuparaが2チームにまたがっていたり、自分自身が組織構造に責任をもつロールを担っているわけではないので難しい側面があります。その中で両チームのマネージャーは最大限思いをくみ、組織構造や日々の運用で形にしてくださっていてありがたいかぎりです。

他の項目は6年目にチーム・個人でやったこととして振り返っていきます。

過去分

2025年

6年目にやったこと

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

僕たちのアプリケーションプラットフォームの起源は、2024年にリリースしたプロダクトの立ち上げを支えるものでした。1年で一からリリースするにあたり、インフラを中心としたプラットフォームがボトルネックとならないよう、50を超えるサービスを構築するためのアプリケーションテンプレート、Protobufスキーマ管理、CI/CD、テナント系リソースや個別のユースケースのためのTerraformモジュールを開発ライフサイクルの手前から順に提供していきました。

その過程で自覚的に積んだ技術的負債があり、事業展開を考えるとどうしても見過ごせませんでした。そのままの構造では想像し得るプラットフォームの改善や機能が積み上がらず、ROIが著しく損なわれます。それを踏まえ、当該プロダクトのUS展開のインフラ面のリードに名乗りを上げました。大げさですが、自身の進退もかけていました。

想像通りの大変なプロジェクトでした。僕のプロジェクトマネジメントが至らず多方面に迷惑をかけてしまったり、2〜3月に過去最長の労働時間を更新したりしてしまいました。それでも、その時点で実現したい状態にはたどり着けました。

Cloud Next Tokyo 2025とPlatform Engineering Kaigi 2025に採択いただき、それぞれ技術的側面・プロジェクトマネジメント的側面から振り返りを共有しています。


オンボーディング

構造としてマルチプロダクト・マルチプラットフォームを実現できるようになっても、実際に利用するに値するか、利用できる状態か、利用する・しないの意思決定の中で俎上に載せてもらえるかは別問題です。

これまでの登壇の中で「マルチプロダクト」を語る中ではふんわりとしか言及できませんでしたが、具体的な形を対外的に示し始めており、アプリケーションプラットフォームも無関係ではありません。利用を開始してもらうにあたり、話の進み具合に応じてそのプロダクトをどこまでサポートできるか、コンセプトをどう伝えるか、どうオンボーディングするかなどを議論していました。

何も制約や選択肢がない組織において、デフォルトでは即個別最適化が始まります。そうでなくても、プロダクトの規模やフェーズは問わず、どのタイミングでコミュニケーションを開始できるか、どういう時間軸で役立つプロダクトを提供できるか（事業の立ち上げフェーズに即効性があるか）次第でできることが変わっていくのを実感した数ヶ月でした。

Platform as a product

Akuparaはある時点の要件を満たすよう作ったら終わりの共通基盤プロジェクトではなく、プロダクトとして継続的に育てていく"Platform as a product"を掲げています。

これまでは不便なところが多くとも、インフラにとどまらずゴールデンパスを一通り満たす枠組み作りを優先してきました。アプリケーションテンプレート、ライブラリ、スキーマ管理、CI/CD、オブザーバビリティツールキットの機能自体と、それを置く場所や提供方法、インターフェースがなければ始まりません。ここをおさえなければアドホックなツールや実装があふれていき、いびつな依存関係の中で移行や導入だけで日が暮れます。

課題収集のしくみ

ここからはより使いやすく、愛されるプラットフォームにするべくボトルネックの解消にも務めます。これまでのサポート窓口とは別に、Akupara issuesという場所を設けました。

プラットフォームでの機能実装にあたっては制約も多く、要望として出てくるhowをそのまま実現できるわけではありません。そのため、あえてfeature requestを募るのではなく、以下を書いてもらう形式にしています。

  • 課題
  • 現状のワークアラウンド
  • 理想的とする状態
  • 補足的に「ほしいもの」

issueは多く存在しているので、基準を設けて隔週で議論・優先度付けしています。Akuparaを開発・運用する両チームのマネージャーやサブチームのリードがいる場で読み合わせることで、課題の存在を広く認識し、いざアサインする際の実効性を担保するのが狙いです。

ヒアリングからの発見

課題の収集に加え、既存プロダクトを中心に開発ライフサイクル上のヒアリングを実施しました。その結果、デプロイ・リリースにまつわるペインが大きなウェイトを占めることがわかりました。短期かつ効果の大きいトイル削減的な施策でペインを緩和する一方で、より根本的な課題解決にプロダクトチームの一員としても取り組んでいます。

Google Cloud Community Tech Surge 2026 presented by Jagu'e'rに出していたGKEを中心としたマルチプロダクト・マルチリージョン対応アプリケーションプラットフォームの継続的改善のプロポーザルを採択いただいたので、その頃にはまとまったお話ができるように進めます。

AIレビューの導入

最近では、issuesをきっかけにインフラリポジトリの中でAIレビューを開始しました。新しいスキーマ管理リポジトリ内の一部で組織の規約を徹底するためにAIエージェントを導入したのを受け、インフラリポジトリでも採用しました。

現状はNotionに多いガイドラインをマークダウン形式に変換して同期し、段階的に進化させてきました。直近はAgent Skills方式をサポートしています。

目の前のトイル削減、中長期的な課題解決、前提を覆すような事態への適応・先取りへの配分は不確定要素を多く含みますが、全社方針やプラットフォームのビジョンを羅針盤に進めていきます。

複業

書籍販売の維持で終わりました。TechTrainでメンターになったものの、まだ動けていません。

プライベートOKR

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

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

学業

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

学業反省文で言及している効果的な学習は、学業にとどまらず新しいスキルを身に着け実践していく上での汎用スキルです。次の学期で大学院を卒業できたとしても、5ヶ月弱は可処分時間のほとんどを割くことになるので仕事にも大いに活かしたいです。

資格・認定

今年で8度目の受賞のMicrosoft MVPに加え、Google Developer Expertsに認定いただきました。

登壇・執筆

昨年はプロポーザルを出しても通らないことの方が多かったですが、今年は様々な局面で登壇に言及いただけることが増えてきました。アウトプットに対するフィードバックを通じた次のアウトプットの質向上や、日々助けられているコミュニティへの還元を目指して来年も取り組んでいきます。

Google Cloud Next Tokyo 25

リーガルテックのグローバル展開を実現する GKE を活用したアプリケーション プラットフォームへの進化

Platform Engineering Kaigi 2025

組織を巻き込む大規模プラットフォーム移行戦略　〜50+サービスのマルチリージョン・マルチプロダクト化で学んだステークホルダー協働の実践〜

LegalOn Now

Platform Engineering Kaigi 2025 に登壇してきました！

maguro.dev #2 社会人になってからの学び直し

TechTrainインタビュー

大手SIer営業からエンジニアへ！toshi0607さんの圧倒的成長の秘訣を大公開

OSS

なし！mirrordを検証するにあたってissueでやりとりしたくらいでした。

2026年

来年も開発者の認知負荷を下げ、自律的に開発・運用できるようにするという原則は変わりません。

しかし、プラットフォームの顧客としての開発者は、これまで以上に二面性を強く持ちます。

  • AI Agentを利用する開発者
  • AI Agentそのもの

プロダクトも、従来の手法で構築されたものとAI Agentで一から立ち上げるものが混在していきます。混在期を経て開発の実行者はよりAI Agentに重きが置かれ、開発対象は刷新したい欲望に駆られながらも機能開発との折り合いをつけて漸進的に改善されていくのでしょう。

その中で、プラットフォームはどう支えていくとよいでしょうか？AI Agentが自律的に開発しやすくするための手段の進化は日進月歩ですが、大枠は以下を担保したいです。

  • コンテキストをいかに渡すか
  • 環境をいかに守るか
  • 開発と運用をいかにつなぐか

コンテキストをいかに渡すか

言語モデルやLLMがこれまでも長らくたどってきたように、コンテキストエンジニアリングは継続して課題です。開発で日常的に触れるAI Agentの機能としても、SkillsやMCPサーバーの動的読み込みなどを通じ、より細かい粒度で当意即妙な情報を過不足渡すための試みは生まれ続けています。

開発・運用に必要な情報は多岐にわたります。

  • 選択したプラクティスやスタイル
  • 散在していたり暗黙的だったりする組織固有のルール
  • プロダクト要件
  • ローカル環境のテストやソフトウェア動作時のフィードバック
  • 顧客提供環境でのメトリクスやログ
  • ユーザーの反応

これらの静的・動的な情報の選別や伝搬を、AI Agent自体の機能拡張のみで支えきるのは難しいでしょう。ソフトウェア開発ライフサイクル（SDLC）各所の課題解決に適したこれまでのソリューションがユースケースやコスト面で採用されてこなかったのを考えると、コンテキストエンジニアリングまわりの銀の弾丸ソリューションが突然現れ、採用されることも考えづらいです。

有力AIベンダーが発明し、移行もしくは新規採用できるなら喜んで委ねたいと思います。それまではAIの認知負荷を下げるためにも、渡す情報の準備、方法、管理面でのゴールデンパスを整備し続けます。

環境をいかに守るか

開発の主体や開発対象の成り立ちが変われど、エンドユーザーから見たら一企業が提供するサービスであることもエンドユーザーを守るために存在する規制も変わりません。むしろ規制は増えるでしょう。

それらや非機能要件に準拠しながら、AI Agentが自由に動ける環境を整備する必要があります。人間が主体だったときも必要だったガードレールをベースに、より高度なソフトウェアエンジニアリングが必要になる分野です。

具体的には以下のアプローチを採ります。

  • 外形的に守るべきところは、決定論的なポリシーの適用範囲を拡大し、AIで補う
  • 壊れては困るデータや環境を守るため、実行環境を分離・サンドボックス化する

開発効率とガバナンスは日常的に直面するトレードオフで、今回も例外ではありません。AI Agentに特化したソリューションが現れたとしても、超えなければならないハードルです。

開発と運用をいかにつなぐか

攻めと守りの開発も、AIエージェントの利用に適したSDLCを経て非本番環境から本番環境へとデプロイし、運用とシームレスでないといけません。

デプロイ自体に決定的な変化は観測・予測できていないだけに、これまで通りなるべく自動で安心して迅速にロールアウト・ロールバックできる状態を目指します。デプロイ自体よりも、アプリケーションのアーキテクチャをAIフレンドリーかつデプロイしやすいようにしていくべきかもしれません。

これらを効率的に実現していくために、依然としてプラットフォームをプロダクトと捉えた上でのプロダクトマネジメントでwhatとwhyを整理し、ツールやプラットフォーム実装やその再利用期間の時間軸短期化に向き合っていきます。