🌐
真のプラットフォームを目指すためにはじめた「Platform Backlog Refinement」

かわうそ
2024/09/24に公開
 はじめにこんにちは、レバテックCTO室でテックリードを担当しているかわうそです。
今回は、レバテックにおけるプラットフォームのあるべき姿、目指す方向性、そこに向けてなにをしているのかについて記事にまとめてみました。
最近、プラットフォームに関する様々な情報や記事が出回っています。

ですが、プラットフォームに正解の形はないと思っています。事業やプロダクト、開発組織、技術スタックなど様々な変数によって理想が見えてくるものだと思います。
そこで、レバテックのプラットフォームが理想に向かっていく過程を少しだけご紹介できればなと思います。
（どうしたらいいのかわからんみたいなこともあるので、コメントいただけると嬉しいですw）

 この記事で話すこと今までのプラットフォームチームがなぜ上手く機能できなかったのか
これからのプラットフォームチームがストリームアラインドチームに貢献できるようになるまでの取り組み
新しい取り組みとして「Platform Backlog Refinement」というものをはじめてみた

 今までのプラットフォームこちらは、弊社のプラットフォームチームのリーダーを担当していたt_kosaさんがPlatform Engineering Kaigi 2024で登壇した資料があるので、こちらを参照してもらればと思います。
https://speakerdeck.com/leveragestech/ituplatform-engineeringwoshi-merubekika-rebatetukunokesusutadei-platform-engineering-kaigi-2024
以下に簡単にまとめます。
レバテックにおける”今までのプラットフォーム”
基盤システム（グループ）
近頃のPlatform Engineeringと全然違う
「基幹システムの分割」と「共通機能の提供」という2軸


ストリームアラインドチームに貢献できていなかった
本質的なアプローチにならなかった


チーム・システムを再編成
「業務ドメイン」と「機能軸」に分類して移行

今までのプラットフォームは ストリームアラインドチームに貢献できていなかった のです。
ストリームアラインドチームに貢献できていなかったら、なんのためのプラットフォームやねんって思いますよね。でも意外と目的なくプラットフォームを作ってしまうとこんなことはよく起きるのではないかと思っています笑
そこで取った手段として、「業務ドメイン」をストリームアラインドチームとして活動できるようにしよう、そこで直接、価値貢献できる状態にしよう、になりました。
なので、弊社のプラットフォームのリーダーをやっていたt_kosaさんは、このチームを含めた「業務ドメイン」を扱うチームのリーダーとなりました。
じゃあ、残された「機能軸」はどうなったのか。そう、ここが今回の本題になります。
ここでいう「機能軸」にはこんな機能がありました。
ID基盤
通知マイクロサービス
行動ログ分析基盤
社内共通ライブラリ
...
そして、これらの「機能軸」とともに宙に浮いてしまったのが、以下の組織です。
SRE
開発生産性改善
デザインシステム（VoLT）
...
そこで生まれた疑問が「残ったプラットフォームたちはどうする？？」「そもそも、レバテックにおけるプラットフォームどうする？？」です。
こんな疑問を抱えながら次のフェーズへと向かいます。

 現在のプラットフォームここで、t_kosaがPlatform Engineering Kaigi 2024で登壇した資料で「示唆を得られるかもしれない4つの問い」というのを紹介しており、問いに答えてみます。
Q1. ストリームアラインドチームは今、どんな課題を抱えていますか？
A1. プラットフォームから見たらぶっちゃけわからんw

Q2. その課題は、Platform Engineeringによって解決できますか？
A2. 課題がわからないから解決できるかもわからない...

Q3. その課題を解決すると、事業や会社にどんな影響を与えられそうですか？
A3. きっと良い未来が来るんでしょう。笑

Q4. Platform Engineering専門のチームが必要ですか？SREに含めたり、チームを組閣せずともできることがありませんか？
A4. なにかしらできることはありそう。
（まじでどうしよう、いっそのこと、プラットフォームを解体するか？ってことも考えました笑）
ここで気になったのが、「ストリームアラインドチームは今、どんな課題を抱えていますか？」 という問いに答えられないプラットフォームは、”真のプラットフォーム”ではないのではないか、という点です。
なので、改めてプラットフォームが「どんなどころを目指したいのか？」から考え直しました。

（あくまで”非”ストリームアラインドチーム目線において）
最も重要なことはなにか？

事業・顧客への価値貢献を拡大
つまり、ストリームアラインドチームの価値貢献を拡大


価値貢献を拡大するために必要なことはなにか？
チーム・組織のパフォーマンスを向上させること

組織のパフォーマンスを向上するために必要なことはなにか？
...

組織のパフォーマンスを向上するための手段として思いついたのが 「DevOps」 でした。

もしかしたら、DevOpsを実現・推進することで価値を発揮できるプラットフォームになれるかもしれない。
そこで、DevOpsのパフォーマンスを測定するためのフレームワークであるDORA Core Modelを眺めてみます。



DORA Core Model
DORA Core Modelでは、ケイパビリティから予測されるのがパフォーマンスで、パフォーマンスから予測されるのがアウトカム（成果）だと紹介しています。
つまり、ケイパビリティを強化し、パフォーマンスを向上させることで、アウトカム（成果）を拡大できるということになります。
なので、レバテックのプラットフォームは以下の目標を目指すことにしました。
目標
「組織パフォーマンスを最大化し、事業・顧客への価値貢献を拡大する」

そのために
「組織に不足しているケイパビリティの強化」

その手段として
プラットフォーム
SRE
開発生産性改善
デザインシステム（VoLT）
...

あくまでプラットフォームはこの目標を満たすための手段の1つに過ぎない、

目指すのはDevOpsの実現による事業・顧客への価値貢献拡大、

ということで「プラットフォームチーム」を改め「DevOps推進グループ」という組織を立ち上げました。

 これからのプラットフォーム→DevOps推進グループプラットフォームとしての目指す先が見えてきたので、やることもなんとなく見えてきました。
早速「組織に不足しているケイパビリティの強化」を行っていきたいところですが、足りないケイパビリティを強化すれば良いのかというと、そう単純な話ではありません。
ここで今までのやり方を思い返してみます。

 全体を俯瞰して"必要そうな"ことを考えて実行してきた今まではプラットフォームが主語となり、全体を俯瞰して"必要そうな"ことを考えて実行してきました。

でもやりたいことはこれじゃないんです。

これだと、ストリームアラインドチームの課題を"解決できていない" かもしれないのです。
ストリームアラインドチームが価値貢献において困っている課題を解決するべきなのです。

つまり、プラットフォームチームから見た課題を解決するのではないということです。

 ストリームアラインドチームに不足したケイパビリティの獲得を支援そこで、必要だと考えたのが以下の仕組みです。
ストリームアラインドチームが不足しているケイパビリティを自己診断
その課題を言語化し、プラットフォームチームに連携
プラットフォームチームがケイパビリティ獲得に向けて支援
まずはストリームアラインドチームが自チームに不足しているケイパビリティを自己診断して、なにが課題かを分析する。

課題がなにかわかったところで、言語化を行い、プラットフォームチームに連携します。

ここで初めてケイパビリティ獲得に向けて支援を行うという仕組みです。

この辺の話はタイミーの赤澤さんの資料がとても参考になります。

https://speakerdeck.com/go0517go/practical-team-topologies-in-timee

 不足しているケイパビリティの自己診断は簡単ではない上記の仕組み化ができるのなら、そう苦労はしません。

簡単ではない理由として大きく３つあると考えています。
ケイパビリティ不足なのかリソース不足なのかの判断が難しい
「自己診断」＝「分析」と「考察」に必要な観点はたくさんある
「分析」と「考察」を行うためにまずは「計測」と「可視化」が必要
まず１つが、ケイパビリティ不足なのかリソース不足の判断が難しいところです。

たしかに、人を増やせば解決するケイパビリティもあるかもしれません。

しかし、人が増えてもケイパビリティが獲得できているとは限りません。
なぜかって話は人が増えても速くならない～変化を抱擁せよ～をぜひ読んでほしいですが、

そもそもプラットフォームはリソース不足を埋めるための手段ではなく、ケイパビリティ不足の解消であったり、生産性を向上させるための手段なので、そこだけは誤解がないようにしないといけません。
次に「自己診断」＝「分析」と「考察」に必要な観点がたくさんあるということです。

DORA Core Modelからもわかる通り、自己診断するための情報はたくさんあります。

この情報の中から自分たちに足りないケイパビリティ、優先的に不足を解消する必要があるケイパビリティを見極めないといけません。
さらに「分析」と「考察」を行うためには「計測」と「可視化」が必要であり、「計測」と「可視化」を行うための基盤も必要です。
これらをストリームアラインドチームが実現するのは簡単ではありません。

 そのためにもDevOps推進グループが仕組み化から行う自己診断→言語化→連携→支援までの仕組みをストリームアラインドチームが構築するのは難しいです。
ストリームアラインドチームは日々機能開発で追われていることが多く、「ケイパビリティを自己診断して言語化して...」なんてことをやっている暇もないし、ここにリソースを割く余裕もありません。
なので、自己診断→言語化→連携→支援までを仕組み化するための基盤の提供と基盤を使えるようにするための支援が必要だと考えました。

チームトポロジー的に言うと、プラットフォーム性とイネーブリング性が必要ということです。
例として、SLI/SLOを導入していく際も同様な仕組み化が必要になります。
プラットフォーム性
ストリームアラインドチームがSLI/SLOを運用・メンテナンスできる基盤を提供。

イネーブリング性
SLI/SLOを観測可能にして、ストリームアラインドチームが自ら判断や議論を行えるようSLOの定義などを支援。


 非機能要件にもDevOps推進グループが立ち向かうDORA Core Modelにおいて手に入れるべきケイパビリティとして非機能要件も含んでいます。
これもまたストリームアラインドチームがなかなか向き合えないことの1つです。

機能要件を満たすためだけでもかなりのリソースを取られてしまいます。
また「非機能要件はいつから向き合えば良いですか？」みたいな疑問や質問はよく見かけます。

基本的には非機能要件は早くからやればやるほど、持続可能な成長と競争力維持に繋がります。

（特にスケーラビリティ、パフォーマンス、セキュリティ、保守性など）
そのためにも、DevOps推進グループがプラットフォーム性とイネーブリング性を活用して、非機能要件においても貢献できるようになる必要があります。
この辺の話はログラスの龍島さんの記事が参考になります。

https://prd-blog.loglass.co.jp/entry/2024/07/05/140526

 どうやってこの仕組み化を実現していくのか？まず前提として以下の「計測」と「可視化」はどんどん進めています。
開発パフォーマンス（Four Keys）
システムのオブザーバビリティ
障害対応コスト
エンゲージメント（開発者体験や成長環境など）
開発習慣（テスト自動化、CI/CD、開発の阻害要因など）
Autifyの活用（QAの推進）
デザインシステム（VoLT）の活用
...
その上で「計測」と「可視化」した情報から「分析」と「考察」を行うための仕組みが必要となります。
価値貢献とはなにか？（信頼性なども含む）
価値貢献を阻害している要因はなにか？
阻害している要因に紐づくケイパビリティはなにか？
これらの情報を取得するためにレバテックとして行うことにしたのが、

”Platform” Backlog Refinement（PBR） です（造語ですw）

 ”Platform” Backlog Refinement（PBR）”Platform” Backlog Refinement（PBR）の流れは以下のようになります。
ストリームアラインドチームがPBI（Item）を起票
※ ケイパビリティの改善に関わることならOK
※ 課題解決のための手段は記入しなくてOK

DevOps推進グループで起票されたPBI（Item）を確認
起票したメンバーをPBRに招待
どんなケイパビリティを改善したいのかヒアリング
開催タイミングは起票されるたびに都度実施

緊急度・重要度が高いものから対応
※ 優先度の判断が難しい場合はCTO室が判断
※ DevOps推進グループでの対応が困難な場合、CTO室に相談



起票する際に利用するフォームと実際に起票されたItemの例
また、”Platform” Backlog Refinement（PBR）を実施する上で以下に気をつけています。
プラットフォームが必要なのか？イネーブリングが必要なのか？
※ イネーブリングに比重を置く
プラットフォームを作る必要がないケースもあるため
一番の失敗は「作るものを間違えること」


リソース不足の観点でPBI（Item）が起票されていないか？
PBRのタイミングでヒアリングを通して内容を確認

リードタイムをどれだけ小さくできるか
プラットフォームに依頼が発生する課題は、複雑なものが多く短期で終わることはほぼない
完了までのリードタイムが長くなりやすい
課題をできる限り小さくして、仮説検証も早く行えるようにする

（対策としてまじで悩み中...だれかアドバイスくださいw）



 なんでも屋になるわけではないこれもプラットフォームあるあるの1つかもしれませんが、

ストリームアラインドチームの支援となったときになんでも屋に見えてしまうことがあります。
あくまで、「ストリームアラインドチームの手が回らない領域」を支援する。

つまり、「本来はストリームアラインドチームがやるべき領域」 でもあるのです。
そのため、なんでもかんでも支援するのではなく、緊急度と重要度が高いものに絞って支援を行います。
ただし、ストリームアラインドチームから見えている緊急度と重要度だけで設定してしまうと、他チームと比較したときに優先度の比較が難しくなってしまいます。

そこで“開発におけるツラミの減少”を目的に、「開発に集中できる環境を阻害しているか」を基準に優先度を設定しています。
つまり、重要度を設定する際にDevOps推進グループ（プラットフォーム）から見たときに、「開発に集中できる環境をどれだけ阻害しているか」、「改善したらどれだけ開発に集中できるようになるか」のような観点を見ています。
この判断軸を採用している背景には、社内で行っているエンゲージメントサーベイの結果があります。サーベイによると「開発に集中できる環境」が開発者体験に強く相関しており、重要度が高くなっています。
なので、実際に対応していくなかでこのエンゲージメントサーベイの指標を追いかけながら改善していくということです。
（こういったところでも「計測」と「可視化」した情報を活用できるので、やっぱり大事ですね）

 まとめこれまでのプラットフォーム

ストリームアラインドチームに貢献できていなかった
“プラットフォームチーム”が全体を俯瞰して必要そうなことを考えて実行


現在のプラットフォーム
目指すのはDevOpsの実現による事業・顧客への価値貢献拡大

これからのプラットフォーム→DevOps推進グループ
“ストリームアラインドチーム”が困っている課題を解決
そのためには以下の仕組み化が必要
ストリームアラインドチームがケイパビリティを自己診断
ストリームアラインドチームが言語化
DevOps推進グループが獲得に向けて支援

仕組み化を実現するためにプラットフォーム性とイネーブリング性を活用
プラットフォーム性：仕組み化するための基盤の提供
イネーブリング性：基盤を使えるようにするための支援

これらの仕組み化の一環として ”Platform” Backlog Refinement（PBR） を実施


 さいごにDevOps推進グループの目標を決めてから、グループ内のメンバーがいろんなところで発信や登壇してくれるようになりました。

やっぱり、目標や目指す先を明確にすることは大事なことなんだなと改めて感じました。
https://speakerdeck.com/leveragestech/bizinesugong-xian-womu-zhi-site-kai-fa-zhe-ti-yan-karashi-merukai-fa-sheng-chan-xing-xiang-shang

https://speakerdeck.com/leveragestech/sregaqiang-hua-surubekizu-zhi-nokeipabiritei