freee 権限管理基盤を開発するチームの今を語ろう！

この記事はfreee 基盤チーム Advent Calendar 2023 の2日目の記事です。

こんにちは、freee の権限管理基盤マイクロサービスを開発するチームでエンジニアリングマネージャーを務めている sentokun と申します。今回はその権限管理基盤チームの体制について語っていこうと思います。チームビルディング的な話としてお役に立てれば幸いです。

長い記事となったので、5日目との前後編でお送りさせていただきます。後編はこちらで公開予定。

チーム体制はざっくり以下の図のように立ち上げ期、探索期、構築期を経て現在に至っており、この記事では現在について記載していきます。後編では現在に至るまでの話を記載します。

権限管理基盤とは？の記事: developers.freee.co.jp

また、この記事ではユーザー = 基盤を利用する freee プロダクトとして記載しています。

現在の体制〜導かれし者たち

この章では、基盤に導かれたメンバーによる現在の体制について記載します。

権限管理基盤チームでは、以下の役割を持ったチームが集まり権限管理基盤を開発しています。

プロダクトマネージャー(以下 PdM と記載)
- 権限管理基盤の価値を高めるための新機能を企画する役割
コア開発チーム
- 権限管理基盤の価値を高めるための新機能を開発する役割
Enabling チーム
- 権限管理基盤の価値を届けるために導入・改善を行う役割
基盤 QA チーム
- 権限管理基盤の品質を担保する役割

価値を高める新機能を作るプロダクトマネージャー (PdM) とコア開発チーム

権限管理基盤は freee の中でも比較的新しい基盤であるため、基盤として価値を高めるためにどんどん機能拡張を続けていく必要があります。

PdM は、どんな新機能を提供すればユーザーが求める価値につながるのかを把握し、新機能の企画・検討・要望の具体化を行います。

コア開発チームは、技術的な実現性も加味した上でユーザー価値を考え、 PdM と議論を交わしながら新機能を実現していきます。

ユーザーに価値を届けきる Enabling チーム

PdM とコア開発チームによって作られた新機能は、Enabling チームによってユーザーに提供されます。

freee はユーザーに価値のあるものを届け切るマジ価値という文化を大切にしています。そのため、ユーザーに価値を届ける Enabling チームの役割は重要なものとなっています。

コア開発チームと比較すると、以下のような役割の違いがあります。権限管理基盤は freee にとっての社内 SaaS を目指しているので、一般的な SaaS だった場合で例えています

コア開発チーム
- SaaS 本体の機能開発をする。いうなればプロダクトオーナー率いるプロダクトを成長させるチーム
Enablingチーム
- SaaS の機能をユーザーに届け、ユーザーの課題を解決する方法を提示する。いうなればソリューションアーキテクト率いるユーザーへマジ価値を届け切るチーム
  - 導入のためのプロセスやツール作成、 PoC 開発を通して機能が価値提供につながるかを検証する
- それだけでなく、FB 対応や機能改善により、ユーザー体験を向上させるための開発も行う

価値に対する品質を担保する基盤QA

基盤 QA は、基盤の品質を担保するチームです。権限管理基盤はマイクロサービスであるため、画面ではなく API レベルでの E2E (End To End) テストを作成し、リグレッションテストを回して品質を担保します。

世の中でよく行われている E2E テストは、画面ベースのものが多いと思います。 freee でよく行われている E2E テストも画面ベースであり、API テストは拡充していこうとしている分野になります (QA 全体の取り組みは freeeの自動テストの全体構成 - freee Developers Hub などを参照ください)。

そのため、基盤 QA では API の E2E テストを実現するためのテスト構造を日々試行錯誤しつつ作っています。現在は runn を使った API レベルでの E2E テストコードを実装しています。
(このあたりの取り組みもそのうち記事にできたらいいなーと基盤 QA チームと話したりしています)

価値を提供するための理想のリリースフェーズ

権限管理基盤チームの各役割は、価値を提供するために定義された以下の理想のリリースフェーズを実現するために割り当てられました。

新機能が PdM によって企画されると、まずは新機能探索フェーズで新機能の開発を集中して行い、機能面での価値に向き合います。このフェーズはコア開発チームが担当します。

その後、導入・探索フェーズで Enabling チームにより導入・運用の観点で価値を届けられる状態にアップデートし、最終的にプロダクトに導入をして正式リリースとなります。また、この導入・探索フェーズで基盤 QA チームによりリリースレベルの品質が担保されます。

リリースされた機能は、Enabling チームによりユーザーへ提供され、フィードバックを受けながら改善を繰り返し質を高めていきます。

これから〜そしてマジ価値へ…

この章では、これからどうチームを成長させていくかについて記載します。進め方としては、目指す理想の姿について考え、その理想を目指すための状態を段階的に定義して目標を立てる形をとっています。

各チームの理想像と、そのために求められるスキルはざっくり以下のような形となります。(理想の姿なので、水準は高いと思います)

コア開発チーム
- ユーザーにとって価値のある権限管理基盤の機能を開発し、基盤としての思想を担保しながら機能を成長させていく
  - 求められるスキル
    - ユーザーの性質や価値を考えつつ、高品質の開発を行うテクニカルスキル
    - コアなドメイン、データモデルを作り、最適化していく能力
Enabling チーム
- 権限管理基盤を一般的な SaaS プロダクトのように、安全・簡単にユーザーが利用できる状態にする
  - 求められるスキル
    - ユーザーの課題を解決する能力
    - 運用を意識して安心安全な導入プロセスを確立させるプロジェクトマネジメントスキル
    - 導入ツールや改善開発を行えるテクニカルスキル
基盤 QA チーム
- 開発された機能を QA するだけではなく、QA プロセスを改善し、品質を担保したまま開発スピードの向上にも貢献する
  - 求められるスキル
    - 開発の要件定義・設計段階から品質観点を取り入れた指摘ができる能力
    - CI/CD など品質を担保するための構造を構築するテクニカルスキル

理想系を目指すための状態目標は、インセプションデッキの 期間を見極める をベースに考えます。(インセプションデッキはアジャイルサムライのアジャイルインセプションデッキのテンプレートを参考にしています)

権限管理基盤の理想に辿り着くためにはチームと基盤がどんな状態になるといいのか？について考え、それを元に半年後、一年後、三年後でのチームと基盤の状態をそれぞれ定義します。

例えば2023年7月時点では、目指すチームの状態を以下に定義をしました。

半年後
- Enabling チームが機能し、コア開発チームが新機能開発のテーマに集中できるようになる
- 定義したリリースフェーズを一部簡略化して運用開始される
1年後
- 正式にリリースフェーズが導入され、各チームがフェーズで求められる期待値に応えられるようになる
3年後
- リリースフェーズが(一部)自動化され、導入担当者は SaaS プロダクトを提供しているような最小限のコミュニケーションで導入対応を実施することができる

3年後の状態は、Team Topology でいうところの X-as-a-Service インタラクションモードで機能する状態です。要は XaaS のように機能を利用してもらうためのツールやドキュメントを提供し、ユーザーが不便なく基盤を利用できる状態を目指していきます。

その他にも細かな野望がいろいろあるので、 freee 全体にとってマジ価値となるよう頑張っていきます！