トップ > Organization > あれから 1 年、Platform チームのその後

あれから 1 年、Platform チームのその後

Organization

はじめに

こんにちは。Platform チームの飯迫 (@minato128) です。

2021 年 7 月 1 日に CADDi で初めての Tech 組織横断チームとして、山田(@kei711_) と一緒に Platform チームを立ち上げ、約 1 年 3 ヶ月が経過しました。今回は、我々が立ち上げからこれまで取り組んできたことや Platform チームのアップデートなどを紹介したいと思います。

  • CADDi の Platform チームとは
  • 立ち上げからこれまで
  • 課題と今後

CADDi の Platform チームとは

前提として

前回紹介した組織体制に大きな変更はありませんが、現在は、各開発チームにひとり以上 Embedded SRE Role をアサインしています。Role の定義は下記のようになっています。

Embedded SRE はシステムの信頼性を高めるために、インフラや非機能要件、可観測性の向上に責任を持つ役割です。
システムの信頼性を高めることで、開発チームのアウトプットの質を高めます。

- 開発チームが非機能要件や可観測性の向上に取り組むことに対して責任を持ちます
- システムの信頼性向上に関する課題に率先して取り組みます
  - 課題解決が困難な場合はプラットフォームチームと共同で問題解決を行います
- プラットフォームチームから提供される部門共通のポリシーやガイドラインを理解し、開発チーム内の理解を高めます

※ Embedded SRE が全ての実現に取り組むのではなく、プロダクトの運用責任を持つ 「開発チーム」 で取り組むことが前提です。

※抽象化した図なのでチーム数やプロダクト数は実際とは異なります

  • 開発チーム
    • それぞれのプロダクトの開発運用に責任をもつ
    • Embedded SRE が、チーム内のプロダクトの Reliability の責務を持つ
      • Embedded SRE は、Role のひとつであり、専任の SRE ではない
  • Platform チーム
    • 全社共通プロダクトの開発運用に責任をもつ
    • 開発チームと協調して、プロダクトに閉じない課題を解決する

CADDi の Platform チームの役割

現時点でのチームの役割は下記のようになっています。また、こちらには記載できませんが、社内向けにはより細かい責務分割ラインを定義して運用しています。

  • Platform チームの基本的な役割の考え方は、チームトポロジーの定義と同じです
    • Stream aligned team が自律的に仕事を届けられるようにするのが目的です
  • Platform チームは、開発チームが管理しているプロダクトのReliability の責務は持ちません
    • Embeded SRE が、プロダクトごとの Reliability の責務を持ち、特定ドメインの運用課題は開発チーム内で解決します
  • Platform チームは、横断的な技術課題の解決に重点を置いています
    • 課題を解決するためなら、手段は問いません
      • インフラという領域にとらわれず、既存機能開発や新規アプリケーション開発も必要なら実施します
        • SRE も Software Engineer ですが、Platform チームでは課題解決のためにより深い実装力を求められます
    • 具体的な How のひとつとして、SRE プラクティスを組織横断で適用する場面は多々あります

CADDi のミッションは「モノづくり産業のポテンシャルを解放する」ことです。製造業のバリューチェーンは長く、データだけでなく実際のモノを扱っています。課題を解決するためなら、クラウドインフラだけでなく IoT デバイスやオンプレミスを扱わないといけない場面も出てくるかもしれません。そのあたりも Web 完結型ではない事業をやっている CADDi の Platform エンジニアならではのおもしろさだと考えています。

CADDi の Platform チームの MVV

チーム立ち上げ時点では行動指針を定義していましたが、チームで話し合って決めた MVV はこのようになりました。

  • Mission
    • 開発組織のポテンシャルを解放する
  • Vision
    • 開発チームが自律的にユーザーへの価値提供に集中できる状態
  • Value
    • More proactive
      • 不確実性を先回りして解決し、開発体験を最大化する
    • Observability driven
      • 観測可能にしておくことを大前提とし、観測結果にもとづいて施策決定と効果判定を繰り返す
    • Leveraging standardization for further growth
      • 仕組み化でレバレッジを効かせて、よりスケールさせる
    • Learning and Unlearning
      • 必要ならなんでも学ぶ
      • 過去の成功体験、固定観念に縛られない
        • 状況は常に変化するため、再現性があるか、今やることに価値があるかを見極める
    • Have Backbone; Disagree and Commit
      • 信念を持ち、正しいと考えていることを言い続ける
      • 決まったことにはコミットする

立ち上げからこれまで

サマリー

時系列でチームの変化の概要をまとめるとこんな感じです。

やってきたことの紹介

すべては書けないのでかなり端折っての紹介になりますが、雰囲気だけでも伝わればと幸いです。

2021/07~09

2 人で課題を洗い出し優先度を決めて進めていましたが、同時に大きな新プロダクトの立ち上げも始まり、なかなか大きなタスクに着手できず、とにかく手が足りないという状況でした。最初にチームの方向性をしっかり定義・認識合わせできていたことは今振り返ってもよかったと感じています。

  • チームとして
    • 目的を整理して社内に共有
    • 今後スケールしていくための言語化
  • 優先順位を下げていた目前の課題に着手
    • 各種申請フロー整備
      • 共通で管理したほうがよいものを巻取り
    • ArgoCD への CD 移行
      • 新しいプロダクトでうまくいっていたので、既存プロダクトに横展開
    • コスト管理
    • 社内ドキュメントサーバー構築、標準化
      • チーム/プロダクト間で API 連携が増えてきていたため
  • CADDi DRAWER の立ち上げ
    • インフラ構築
    • ISMS 対応

2021/10~12

Tech 組織の大幅なスケールに備え、開発に必要なツールやクラウドインフラ・セキュリティのガイドラインを明文化しました。また、それまで性善説で運用されていた開発者の Google Cloud IAM を見直し、あるべき姿を設計・移行しました。

  • 標準化、ドキュメント整備
  • その他
    • 社内向けプロダクト用 GKE のキャパシティ見直し
    • Redash を SaaS から Self-Host へ移行
    • 認可基盤の管理画面構築

2022/01~03

Tech 組織や新規プロダクトがさらに増え、積み上げてきた Platform の運用コストも上がってきていたので、再度チーム内で取り組み方について話し合い明文化しました。また、AI Lab 発案で Embedded SRE Role の運用が始まりました。定例会では、Platform チームから Embedded SRE にナレッジシェアをしたり、Embedded SRE に Platform チームの施策をレビューしてもらったり、Embedded SRE から Platform チームに開発チーム内の課題共有をすることで、より全体最適化を進めやすくなりました。

  • 標準化、ドキュメント整備
    • すべての Terraform Version を Upgrade し、 tflint / tfsec / tfcmt を導入
      • Terraform や Provider の最新に追従できるようになり、定期的に最新化を実施
    • Production Readiness Checklist を整備
  • Embedded SRE Role の誕生
    • 各開発チームにひとり以上アサイン
    • 隔週で Embedded SRE 定例を実施し、施策や課題の共有
  • Platform チーム内運用のルール化
    • Platform チームへの相談依頼を日次当番化
      • 新規プロダクトが多く、レビュー・壁打ちが多かったため
      • 相談依頼によるコンテクストスイッチでベロシティが下がっていた
    • 通常タスクと運用タスクの割合を 8:2 とすることを明文化
      • 運用タスクが劣後しがちになっていた
  • CADDi DRAWER
    • 一部機能の設計・実装・運用整備

2022/04~06

人数が 6 人に増えチーム運営が安定してきたので、これまでよりも大きな技術的投資ができるようになりました。また、メンバーの多様性が増したことで、技術的課題を解くための How もさらに広がってきました。

  • 技術的投資
    • 社外向けプロダクト用 GKE への ServiceMesh/OpenTelemetry 導入
    • Sentry の運用設計と展開
  • プロダクトの安定運用のための土台作り
    • SLI/SLO の導入
    • 監視基盤のベストプラクティス明文化と啓蒙
    • Log Format, Tracing, バックアップ方式の標準化

2022/07~10

引き続き技術的投資や標準化を推進しつつ、中期的に今後どうなっていくべきかを自分たちで定義しました。

  • チーム
    • 中期チーム構成や施策の検討
  • 技術的投資
    • 新認証認可基盤の設計
    • 社内向けプロダクト用 GKE への ServiceMesh/OpenTelemetry 導入
  • 標準化、自動化
    • 全 SaaS 開発者アカウントの IaC 化・自動化
    • Google Cloud サービスアカウントの IAM Policy 標準化
    • Google Cloud への一時的な権限付与のためのアプリケーション構築

常にやっていること

  • 構築した（提供中の）プラットフォームの運用
    • ドキュメント
    • ミドルウェアやツールのアップグレード(Renovate)
      • ArgoCD, ESO, Datadog, ASM など
    • 提供しているインフラやアプリケーション、SaaS、共通モジュール
  • チーム内の働き方の明文化やそのブラッシュアップ
    • Working Agreement
    • オンボーディング資料
    • 運用系の定期イベント
  • CADDi DRAWER の支援
    • 非機能要件や技術的な支援
    • 将来的には開発チーム内で完結する想定だが、事業優先度が高いかつ人が足りていないため

課題と今後

現状の課題

現状このような課題があります。

  • Platform チームでカバーしている範囲が広いため、認知負荷がそれなりに高い
    • 求められるスキルの範囲もそれなりに広い
  • 強制力がない標準化施策に関しては、開発チームへの導入速度は緩やか
    • Embedded SRE Role を持つ人も開発チームメンバーも基本的に協力的なので徐々には浸透している
    • 専任で取り組む人はいないため、スピードは出ない

これらを解決するため、また、中期チーム構成の過程として、次の四半期から Platform チームを分割し、Enabling と Platform の 2 つのチーム体制にする予定です。

  • Enabling チームは、チームトポロジーの定義通り、特定のテクニカルドメインスペシャリストで構成され、複数の Stream aligned team の能力ギャップを埋めるのを助けます
  • Enabling チームは、開発チームへの標準化施策の導入責務を持ち、その速度を加速させます
    • 現在の Platform チームは、課題の解決に重点を置いているため、場合によっては開発チームへの標準化施策の導入サポートを行っていますが、それをスコープアウトします
    • 分割後の Platform チームは、開発チームへの標準化施策の導入サポートを Enabling チームに任せることで、高度化や技術的投資に集中します

3 年後の妄想

現在、開発組織は約 70 名に対して、Platform チームは 6 名です。3 年後、開発組織が今の何倍になっていたとしても Platform チームの人数比率的には今と同じくらいが（個人的には）理想だと考えています。ただし、その過程ではもっと人を増やして、よりレバレッジの効く施策を積み上げていくことが前提です。そして最終的には、Platform チームから開発チームへ Embedded SRE や開発メンバーとして異動して、また必要最低限の人数でさらに成長して増えたプロダクト群を Platform で支えていくことができればよいと思います。同じことばかりやっていると飽きてしまうし、成長機会も減ってしまうので、本人の Will が一致すれば、再び Platform チームにも戻れたり、全く違う目的をもった新しいチームを作ったりできるとより楽しそうです。

3 年後の Platform チームは、Platform グループになり、仮に 30 名だったとしましょう。グループの中には、複数のチームが存在し、チームのミッションもそれぞれ異なります。役割もチームごとに分割され、認知負荷が減り、特定分野に特化したスペシャリストも活躍しやすくなっています。モノを扱いやすくするための IoT デバイスや物流拠点で利用するオンプレミスのシステムが必要になっていて、それを設計したり維持管理したりするチームもあるかもしれません。グループ全体では、より安定的で強固な Platform を提供しながら、さらに大きな課題や技術投資にチャレンジします。

また、現在の CADDi では組織拡大だけでなくグローバル化も進んでいます。開発組織向けの資料は、すでに英語を併記し始めていますが、まだ Platform チームに英語話者はいません。3 年以内なのか以降なのかはわかりませんが、Platform チームも英語話者を受け入れていくことになるでしょう。英語話者だけのチームやタイムゾーンの異なる国外のチームとも一緒に働くことになり、コミュニケーションの課題が全くなくなるということはないかもしれませんが、対チームや対開発組織でのプロセスは型化され、大きな問題はなく業務が遂行できるようになっていることでしょう。

この妄想を現実に変えるために、例えばこんな人に来てほしいです。

  • 会社のグローバル化とともに、徐々に英語を習得しながら働きたい人
  • プロダクトの Platform を支え、技術的課題を解決し続けることで大きなミッションを達成したい人
  • 人や組織面を中心にグループを支える Engineering Manager
  • 一緒に未来を描ける Technical Product Manager
  • ソフトウェア開発ライフサイクルを改善し続けて、グループのアウトカムを最大化できる Scrum Master
  • より強固な Platform を設計したい Security Engineer
  • より安定的な Platform を設計したい Site Reliability Engineer
  • 標準化や自動化や高度化が好きな Cloud Platform Engineer
  • 手段にこだわらないが軸がぶれない Software Architect
  • 認証認可基盤などの組織横断プロダクトを開発したい Software Engineer

おわりに

最後まで読んでいただきありがとうございました。少しでも CADDi の Platform チームが、どんなチームで何をやってきたか伝わっていたら嬉しいです。もし興味を持っていただけたら、気軽にお声がけいただければと思います！

CADDiでは、現在積極的に採用を行っています。 まずはカジュアルにお話を聞いてみたい！という方は、ぜひこちらより面談をお申し込みください。 また、Tech Blogや勉強会等のイベントについてはSNSで随時発信しておりますので、Twitterのフォローや、connpassのメンバー登録をぜひよろしくお願いします。