こんにちは。2025年9月に開催されたPlatform Engineering Kaigi 2025にて、組織的センシングの事例を紹介しました。
登壇内容を1スライドでまとめると以下のような内容ですね。
いただいた質問に対する回答
Q: PoCとドッグフーディングのサイクルですが、1サイクルあたりどれくらいの期間で実施されましたか？また、FBの対応の優先度決めはどのように決めてましたか？
PlatformのPoCやドッグフーディングの対象によってまちまち、というのが正直なところです。ただ現実的には1-3ヶ月に収まる範囲で評価していることが多いと思います。FB対応の優先度決めは、FBを受け取るプラットフォーム側に一任しています。もちろんその際の必要な背景情報などは添付していますが、プラットフォーム側の優先度判断までは口出さないようにしていますね。
Q: 成果あるエキスパートとは言え、チームによってはファシリテーションのような短期の参加では信頼を得るに至らず、うまく機能できないこともあるのではと思いますがどうなのでしょうか。そのための工夫はあるのでしょうか
これは逆説的に考えて欲しくて、短期間のコミュニケーションでも信頼できる人はどういう人かというと、例えばチームの窓口になっているようなリーダーやマネージャーだったりするわけです。この取り組み自体、次期リーダー候補の育成も狙いですので、機能するように何度も試行錯誤を各メンバーで重ねるという回答になります。ただ現実には、チームに対してすでに信頼貯金のようなものがある状況からスタートしていたり、最初の会議で期待値のすり合わせをすることが効果的ではありますね。
Q: Enablingについて、2-4週間で展開から課題解決までするのでしょうか？どこまでサポートするのか気になりました
私たちの課題の多くは短期間で解決して終わりになることは少ないため、自分たちで今後も改善するためのシステム(SLOレビューの定例会議など)を組んで回すところまでをやっています。ただ、短期間で携わった後に手離れするという期待値をすり合わせた上で始めるようにしています。ただ、すっぱり終わりではなくて、アフターケアのような形で気にかけてはいますね。
Q: 独特な文化だとおっしゃられていましたが、この文化に至った考え方はチームトポロジー以外では何か影響を受けたものはありますか？
チームトポロジーはこういう場で話すための共通言語として使っているだけで、私たちの経験的や感覚的に行なっていたやり方を整理すると、こうなるのが自然だったという感じが近いです。その経験についていうと、前職でプラットフォームを持っていた時に、プラットフォームをデザイン通りに使うことによるメリット、デザインに背いてハックして使うことによるデメリット(コスト)などを体感していたことがあるので、正しく利用者に理解して使ってもらうことの重要さを考えてのことだったと思います。
他の登壇者のセッション
私の登壇がタイムテーブルの最後だったということもあって、他の登壇は当日ちゃんと聞けておらず、後から資料を見たり動画を拝見したりしています。一部、興味深かったものを抜粋しますと
内容を私なりに要約すると下記の通りです。
認知負荷理論の観点から、負荷について整理し、どの負荷に対してどういったアプローチをするべきかを整理した
その実践例の紹介
所管
前半パートは認知負荷に関する記事などでもよく説明されているものですが、改めてそれを実践と結びつけている点はすごいと思いました
ただ、認知負荷と学習において個人単位での話とチーム単位の話はまた別にあると思うので、その点は意見交換できる場があると嬉しいなと思っています
リソース効率を最大化する場合、同種のタスクは1人に集中させた方が転移による低い認知負荷からの効率は最大化できるみたいな
そういう点を考慮すると、戦略が2つか3つくらいあるはず(思いつきだが...)
あるタイムスタンプにおいて、チーム全体の課題内在的負荷の総和を最小化すること(得意なタスクを得意な人にアサインする)戦略
あるタイムスタンプにおいて、チームのうち最もしんどい人の負荷を最小化すること(得意なタスクを順にアサインしていくと、余り物がかなりしんどくなるのでそれも考慮する)戦略
ある期間において、チーム全体の課題内在的負荷の総負荷最小化(学習によって今後得意を増やすことも見込んだアサインをする)戦略
内容を私なりに要約すると下記の通りです。
生産性指標のFour Keysが"Low"から"High"まで改善したが、ビジネス的な成果に結び付かなかった
ビジネス的な成果を近似する機能リリース数を指標に改善をしたところ、ビジネス的な成果に結びついた
所管
計測・改善・再考の流れを教科書通りに行なっていて、本当にすごいと思いました
DORAやSpaceがボトルネックではなく、Flow Metricsが適していたという事例かなという気がしてます
機能リリース数は、それはそれでビルドトラップなどのアンチパターンがあるので、それへの向き合い方などは気になります
内容を私なりに要約すると下記の通りです。
SREとPlatform Engineeringにtoilという交差点があることに気がついた
SREとPEそれぞれのプラクティスを参考にしながら、1人SREでも改善を進められた
一人の限界はあるが、AIによるサポートという新しい武器も増えている
所管
一人でできる範囲、でも着実に効果があることを積み上げて信頼を重ねている境遇に非常に共感しました
AIの武器については、Capability不足とResource不足の区別&どちらに対して武器になるのか意見交換してみたいなって気持ちになりました
最後に
運営に携わってくださったスタッフのみなさま、他の登壇者のみなさま、参加者のみなさま、ありがとうございました。