こんにちは、Platform Engineering Unit Application Platformグループの辻田です。
App Platformグループで3日間の開発合宿を実施しました。
アプリケーション基盤 Orbit*1 の運用改善や開発者体験の底上げにまとまった時間を投下し、チームとしての目線合わせと、具体的な改善を一気に進めることが目的です。
この記事では、合宿で何をやったか／何が前に進んだかを、できるだけ実務目線でまとめます。
目的・背景
今回の合宿の狙いは大きく2つです。
開発者体験のボトルネックを短いサイクルで潰す
ユーザー（開発チーム）からのフィードバックを起点に、議論→実装→検証を短いループで回します。
チームとしての目線（ゴール・役割・進め方）を揃える
App PlatformグループにはSRE TeamとPlatform Teamが存在します。それぞれの役割や関係を整理し、意思決定が速くなる“共通認識”を作りました。
3日間のざっくりタイムテーブル
- Day1（4/1）
- 全員集合・顔合わせ
- 採用計画の見直し
- チームラーニング
- ユーザーFB起点の改善タスクに着手
- Day2（4/2）
- 朝会
- SREの方向性のすり合わせ（各プロダクトとその先のゴール）
- SRE/Platformの役割の言語化
- 引き続きユーザーFBタスクを進行
- Day3（4/3）
- 朝会
- ユーザーFBタスクの仕上げ、持ち帰り事項の整理
- 片付け・解散
合宿でやったこと
1) Observabilityの整備
- GKE上のサービスに関するメトリクスの可視化（Namespaceごとにダッシュボードを生成する仕組み）
- ログベースメトリクスの検証・整理
狙い：サービスの状態把握を、属人性を下げて再現性高く行える。
2) 性能・スケーラビリティ検証のための仕組みづくり
- 負荷試験を回しやすくするための基盤整備
- 継続的に検証できる形を意識した改善
狙い：性能やスケールの検証を“いつでも回せる”状態を用意する。
3) アラート運用方針の検討
- アラート運用方針の見直し（ノイズ削減／対応判断の迷いを減らす）
狙い：対応が必要なアラートだけが鳴る状態を作り、運用負荷を下げる。
4) KEDA HTTP Add-Onの検証
- scale to 0の実現に向けてHTTP Add-Onの検証
- どうやって既存のHelm Chartに組み込むかの検討
狙い：アイドル時のPodの0スケールによるコスト削減、CPU/Memory以外のプロダクトの要件に応じた動的スケーリング。
5) 段階的ロールアウトの導入
- チームとして方針を決定、各ツールの調査
- タスク分解
狙い：Orbit利用者が標準的なリリース戦略（Canary, Blue/Green 等）を利用し、安心安全な環境でデプロイできる。
6) コストの可視化
- コストに関するダッシュボード／可視化の整備
狙い：Namespaceごとに按分されたコストをユーザーが簡単に参照できる。
合宿で得た学び
学び1：改善は“まとまった時間”があると指数関数的に進む
細切れの時間だと、調査→実装→検証の間にコンテキストが落ちます。
合宿ではこの切れ目を減らしたことで、前に進むスピードが上がりました。
学び2：チームとして重要な認識合わせは、顔を合わせて行うほうが体験が良い
オンラインだと、どうしてもリアクション待ちの時間や発言のタイミングの探り合いが発生し、会話のテンポが削がれてしまいがちです。
オフラインで集まっているからこそ、議論の密度と意思決定の速度が上がったと感じています。
次にやること
合宿はスタート地点なので、持ち帰りの仕上げを進めます。
- 合宿で作ったproposalの実行
- 各ダッシュボードや運用方針をチームに展開し、運用に組み込む
- 負荷試験やHTTP Add-Onの導入をやり切る
合宿の様子
おわりに
今回の合宿は、単に作業時間を増やすというより、チームの目線合わせと、今後の運用改善を支える土台づくりに大きな価値がありました。
引き続き、ユーザーFB起点の改善と、運用負債を減らす取り組みを継続していきます。
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
