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

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

こんにちは、freee の権限管理基盤マイクロサービスを開発するチームでエンジニアリングマネージャーを務めている sentokun と申します。この記事は前後編となっています。前編はこちら。

今回は、権限管理基盤が現在の体制に至るまでの遷移を書いていきます。以下の立ち上げ期、探索期、構築期に関する話となります。

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

チームの遷移〜幻の大地

この章では、現在に至るまでのチームの遷移について記載しています。
(前回に引き続きドラクエ繋がりで、無理があるサブタイトルとともに)

立ち上げ期

プロダクトの協力により実現できた 1st リリース

権限管理基盤マイクロサービスの開発は、2021年某日に TL 中心にスタートし、その後私も参画し4名前後のチームとして立ち上がっていきました。
freee の権限管理基盤マイクロサービスに関する記事で書かれているコンセプトやアーキテクチャは TL によって練られたもので、このコンセプトを元に基盤開発が進められました。

1st リリースができたのは2022年の11月初め。当時は、RBAC による権限制御機能を開発しながら、そのまま開発した機能をターゲットの新規プロダクトへ導入するという進め方をとっていました。そのため、導入プロセスを検討しつつプロダクト側と密に連携してなんとかリリースできた状態でした。

また、品質担保についても基盤側で実施できたのはユニットテストまで。 E2E テストなどがない状態で、結合テストレベルの品質はプロダクトの QA で担保してもらっていました。

1st リリース後は導入・運用面、品質面の改善に集中

1st リリースが終わると、次は足りない機能追加、改善開発に移ります。当時新機能開発も期待されていましたが、このタイミングでは導入・運用のための改善開発がメインとなりました。

例えば、権限管理基盤は設定ファイルを用意し、設定を投入して使う形になります。その設定投入方法については、 1 st リリース時点では機能を利用してもらう際は権限管理基盤の運用者が直接 SQL を実行して変更をかける方針としていました。これは機能開発を優先しており、設定変更もそこまで頻度が高くないと想定していたため投入に関する開発は優先度を低くしていたためです。

しかし、実際運用をはじめてみると、新しい権限の追加はプロダクト側の機能開発と紐づいており、かつその開発サイクルが速いため、高頻度でスクリプトを用意する必要がでてしまいました。結果、基盤の運用がボトルネックになり、基盤側もスクリプトを用意することにリソースを割かれ、新機能の開発に取りかかれない状況となってしまいました。そのため、まずは設定を冪等に投入するツールを用意する開発を行うことが急務でした。

このように、リリース後しばらくは、導入・運用を安定させるため開発に取り組む必要がありました。また、安定した運用を行うためには品質面の改善も同じく急務。ということでまずは以下の改善に集中しました。

設定投入のためのツールを開発し、プロダクトのデプロイ時に設定が投入されるようにする
バックエンド QA の E2E テストを構築・開発し、基盤チームだけで品質を担保できるようにする

使ってもらうことで見えてきた、基盤に求める当たり前品質の高さ

実運用を安定させようと奮起する中で、基盤を使ってもらうには高い水準の当たり前品質が求められることが明確になってきました。

ユーザーは、基盤を利用する際に純粋な機能を求めるだけではなく、導入・運用のための仕組みや環境構築のための手順書・ツールといった簡単に基盤を利用できる状態も必要とします。こういった簡単さが提供できないと、利用ユーザーに不便を感じさせ、本来開発を加速させるはずの基盤が逆に負荷を上げる要因になってしまいます。

XaaS サービスでイメージするとわかりやすいと思います。これから導入していこうという世の中に知見の少ない XaaS サービスがあったとして、そのサービスの機能がいくら充実していたとしても、それを利用するためのツールやドキュメントが整備されていなければ、よし利用しよう！とはならないものです。

小さくはじめるのがアジャイル開発の基本なので、最初から全てが完璧に揃っていない状態でスタートするのは仕方ない面もあるとは思いますが、一方で期待される当たり前の状態・品質を提供できないと基盤を使って良かったと心から思ってもらうことはできません。

そんな基盤に求められる当たり前の基準の高さを実感したのがこの頃でした。

当たり前品質だけじゃない、基盤に求められる多様な期待値

品質だけではなく、更に様々な期待が寄せられるのが基盤開発です。

freee がビジョンとして掲げる統合型経営プラットフォームを実現するため、多くのユーザーに基盤を使ってもらう必要があります。そのためにも、基盤を利用するメリットを感じられるような機能の改善や新機能の拡充をしていくことが重要となります。

また、freee でラインナップを増やしている新規プロダクトからも基盤を利用したいと声をいただいたり、セキュリティ面での期待していただいたりと様々な観点で期待が寄せられています。

もちろん我々基盤開発者自身も、権限管理基盤に対してよりよいユーザー体験が提供できるよう機能を改善、拡充したいという期待を持っています。

このように、様々な期待に応えていくことが、基盤チームには必要とされていました。

探索期

権限管理基盤の理想を明文化する

ある程度期待値が見えてきたので、期待に応えるために我々が提供すべきことを整理していきます。

整理をするにあたり、まずは自分たちを知り向かうべき理想について考えることが必要。というわけで、インセプションデッキを作って理想を可視化するところからはじめました。

まずはアジャイルサムライのアジャイルインセプションデッキのテンプレートを参考に、我々がやりたいことを言語化。
例えばインセプションデッキの我われはなぜここにいるのかを作るため、我われが提供したい価値をメンバー全員で言語化し分類。この時点ではいろいろな観点の価値がボードに現れました。

その内容を元に、最終的に以下のように定義をしました。

複雑な権限管理を誰にとっても簡単にわかりやすく提供する！
- ユーザーにとって
  - どの freee プロダクトでも業務に沿って安全かつ簡単に権限の運用ができる。これによって管理者は安心して業務ができる。
- freee の開発者にとって
  - ユーザーがよく利用する権限管理機能を手軽に安全に導入・運用できる。これによって権限管理機能の実装・導入を最小化することができる。
- freee プロダクトにとって
  - 統合体験を素早くリーズナブルに提供できる。これによって、ユーザーに価値あるプロダクトの創造的な開発にフォーカスできる体制にできる。

上記を言語化するにあたり、我々が大事にしているキーワードがわかりました。それは安全、簡単。こういった大事にしているキーワードが言語化できたことも大きかったです。

その他、俺たちの"Aチーム"を作る際にはマネージャー、PdM、テックリード、スクラムマスターといった役割に対する期待値を言語化・明文化をするなど、順調にインセプションデッキを構築していきました。

目指す世界を実現するため、課題を可視化

インセプションデッキを作る中で詰まったトピックがありました。それは 期間を見極める の部分。

やりたいことを並べることもできたのですが、理想を語るためにはまず多様な期待値に応えられていない状態を改善することが重要。そのためにも、まずは現状の課題に対する言語化を試みました。

当時プロジェクトの振り返りなどで個別に課題出しはできていたので、システム思考の中で用いられるループ図のフレームワークを参考に課題の関係性を整理していきました。

やり方としては、まずは課題をバーっと列挙。私としてはマインドマップで深堀していく形がやりやすかったです。イメージしやすいよう、miro で作ったマインドマップを一部抜粋したものを貼っておきます。

課題が洗い出せたら、ループ図の形で関連性を可視化。やってみると、それぞれの課題が作用しあって入り組んだ構造になってしまっていました。うーん、カオス

中身を見ていくと、多様な期待値に応えるためのスイッチングコスト、コミュニケーションコストが増大し、結果捌ききれないタスクが積み上がってさらにコストが増大するという悪循環が見えてきました。

イメージとしては以下のように多様な期待値に囲まれている状態。

その状態を解決するため、求められる期待値が依存しない疎な関係を作り、スイッチングコストとコミュニケーションコストを下げることが大事と考えました。そのために、期待値を言語化し、期待に応えるために適切な役割を定義し、体制を立てていくことにしました。

また、この方針を考えるにあたり、過去に似たような課題に向き合った SRE のやり方を参考にしました。SRE の取り組みが気になる方は以下記事などを参照ください。

developers.freee.co.jp

構築期

期待値を言語化

まずは基盤に持たれている期待値を以下のように分類しました。

新機能の開発
- プロダクトが新たな価値を出すためのコア機能を開発する
新機能の導入
- できたばかりの権限管理基盤の機能をプロダクトに導入する
- そのための導入プロセスを確定させ、必要なツールを用意する必要がある
リリース済み機能の導入
- 完成している機能をプロダクトに導入する
機能の改善
- 既に利用してくれているプロダクトからフィードバックをもらい、機能を改善する
保守運用・障害対応

イメージがつきにくいと思いますので、1st release で触れた設定ファイルに関する機能を例にとって利用者の期待値を分解してみます。1st release 当時はこの機能は新機能なので、開発と導入に対する期待値があり、具体的には以下のようになります。

期待値の分類	設定ファイルに関する機能での具体例
新機能の開発	設定ファイルに権限の構造を書くだけで、権限制御ができるようになる
新機能の導入	上記機能が使いたい時に使える

新機能の開発に対する期待値を満たすには、この権限制御を行うための機能が提供できればよいことになります。これは 1st リリース時点で提供した機能に含まれています。

一方で、新機能の導入に対する期待値は、言い換えるといつでも気兼ねなく設定が反映できることとなります。これはまさに1st リリース後に行った設定を冪等に投入するツールを用意して反映をいつでもできるようにする状態が求められていた形になります。

上記は現在権限管理基盤のRBAC の仕組み 及び アプリケーションデプロイと同時に設定を更新 で提供しているのですが、それに近いレベルの機能が揃ってはじめて運用にも耐えうる、利用者にとって普通に使える基盤となります。

このように、基盤を使ってもらうレベルにするには、いくつかの期待値を満たす必要があります。

立ち上げ期の開発では、この期待値を意識せずに機能を提供していた状態でした。前述した例のように新機能開発の後に導入に関する期待値を満たしきれていない状態でプロダクトに導入を進め、その結果本来考えるべき導入・運用プロセスに到達するまでプロダクトと一緒に試行錯誤してもらう形になってしまっていた状態でした。