RSGT2025 Day2 聴講記
株式会社Relic エンジニアの、エイミ/amixedcolorです！
RSGT2025 Day2の各セッションごとの聴講記です。
Day1の聴講記は下記です。
Day1の聴講セッション一覧
The Best Product Engineering Org in the World
スクラム「だけ」を正しくやろうとして価値あるプロダクトになるかな？
アジャイルコーチが事業会社を立ち上げたけど、事業環境が生んでみた視点が広がる
エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢について
「あの人たちが協力的ならうまくいくのに!権限もないから進められない!」トレードオフの連続制御を通して、対立を協力に変えるプロダクトマネジメントチームを実現するぞ
自分のために書いていて読み物としては読みにくいかもしれませんが、各セッションがどんな内容なのか少しなぞりたい人にはちょうど良いかと思います。
フレームワークを生み出すメタフレームワークという考え方 -適応型から生成型へ-
「チームで話そうというのをみなさん大事にされていると思う」
→でも、それが個人の知見のバトルになっていませんか？
意思決定のやり方に一貫性はあるか？
組織だってやれる方法を議論しているか？
周りの人と話す
普段どのような議論をしているか？
議論の妥当性はどのように担保していますか？
普段どのような議論をしているか？
相談を受けてベストプラクティスがある場合はそのまま回答する、トレードオフなら材料を提示したりして考える
チームで何をやるのかを、お互いモチベーションを持ってやれることであればやると決めている
アジャイルコーチなので、少し引いてみていて議論の中に入ることはない
議論の妥当性はどのように担保していますか？
意思決定の根拠は、外部や内部の信頼できる情報源からとっているが、その議論自体が妥当かは担保できていない
コーチングの際に妥当性を担保しようとしても議論者の練度により、担保できるかどうかは議論者次第
議論・意思決定の妥当性について
発言者のスキルに依存していないか？
声の大きさに依存していないか？
例えば技術選定のプロセスは一貫しているか？
全体として良い意思決定ができているかは評価できていない
統合を前提としていない分割は評価が難しい
解決のための手立て：生成型
理論とパタンと適応型
アレグザンダーは1970年台にこの理論を考え出した
考え出したのは、建物がいきいきとしなくなったから
ガラス張りのビルがドーンなど
多くの人が共感し、XPもスクラムもこれをルーツとした
このとき、変化に適応するために短いイテレーションで行った
それが一つアジャイルマニフェストとしてまとまった
しかし
生成型のような長期的で持続可能な価値が反映されないか、蔑ろにされがち
各要素が全体に貢献し、何か一つが常に調和するために生成されてほしいが、適応型では短期的なものとして生まれることが多く調和しにくい
スクラムではプロダクトゴール
リーンスタートアップではリーンキャンバスがある
が、それでは足りない
製品開発における生成型
サイズは様々
「余剰したリソースをいかに使うか」はまるで役に立たない
日本は最も困窮するから、最も実験しやすい
リソースがない中でどう対応するのかの一助が生成型だと信じている
「何か新しいものがあるたびに学ぶ」というのは終わらない
学習し続けることは大事だが、それに一貫性はあるのか？
いかに学び、学習に妥当性はあるのか？
不要なものを学んでいるかもしれないし、足りないものを学んでいないかもしれない
自分が好きなことをやっているだけになってしまっていないか？
この少ないリソースの中でいかに効果的にいきいきと意思決定をできるかにかかっている
数年ごとに新しいものを学ぶだけでなく、常に自分たちにあったものを
メタフレームワーク
自分たちが美しいと思えるものが自然と出来上がるようにした
リーンキャンバスは扱う範囲が広く上のレイヤー・メソッド抽出は扱う範囲が狭く下のレイヤー
挑戦して見えてきたもの（事例）
個人の知見バトルも起こっていた
まとめ
実際にこのフレームワークを使う使い方は？
まず、今まで自分たちがやってきたことを洗い出す
次に、抽象度の高い低いで縦一列に並べる
その後、それをWhy・How・Whatの3つのグループに分ける
Why・How・Whatは何か一般の意味と異なるわけではない
その「やってきたこと」がやり方に近しければHow、やったことそのものに近しければWhat、やってきた理由や背景に近しければWhy
やってきたことが何になるのかはチームによるし、グループに分けるときに配分がどうなるかは書いた人による
47機関での例
Whyが最初ほぼ空欄だった
きょんさんはかけた、POなので
これは何か
ここに現れているのは現場の全体性を高めるための秩序
例えばスクラムガイドはこれを非常に抽象化したものなので、これを作っていてもスクラムガイドのようなものが作れるわけではない
新人マネージャーサバイバルガイド - 使いやすい便利なマネージャーになろう
一番最初に理解すべきこと
自分でやった方が速い・正しいは幻想
いざとなったら自分がやればいい、は遅かれ早かれ詰む
経験からくる知識はあっても、実際のプロダクト・プロジェクトの知識や情報はすぐに古くなる
情報共有にメンバーのリソースを使うと、進捗の邪魔になる
経験からくる知識をどう使ってもらうか？
マネージャーは余裕リソース
不測の事態に備えるためにいる
自分の稼働率が高すぎたら備えられない
例外ハンドラーとしてもマネージャー
仕組みから溢れた、漏れた仕事がマネージャーの仕事
仕組みを改善しないと、詰む
3回繰り返したことはもう例外じゃない
便利なマネージャーになろう
自分の上手い使い方をメンバーに教えよう
どういうふうに使ったらいいか
どんなときに使ったらいいか
悪いニュースを早めに言ってもらう
狼少年を叱らない
助けの呼び方の手本を示すこと
Why/Whatと完了状態を示せ
やり方、やることを指示するな
タスクの名前は完了要件にする
助けとして呼ばれやすくすること
うろうろすること、でも邪魔しないこと
「Management by Walking Around (MBWA)」
「暇そう」って言われがち
雑談する
雑にヘルプを頼む（借りがある状態にしておく）
助けとして呼ばれることで、仕事の状況を知れる
機嫌を良くしておく
機嫌悪い奴に相談したい奴はいない
睡眠時間を削らず、美味しいものを食べる
でもネガティブフィードバックはマネージャーの仕事
それをしない言い訳に心理的安全性を持ち出すな
叱責は機嫌がいいときにだけすること
機嫌が悪いときにしてしまうと、どれだけ正当でも「機嫌が悪いから」と思われてしまう
研修講師をやるといい
自分のスキル獲得の時間・リソースの確保を忘れない
教えることで一番学べる
トレーニングのマテリアルも自分で作る
定期的に、それなりに頻繁に実施してフィードバックを得る
便利で使いやすいマネージャー
情報が集まりやすくなる
不測の事態に備えやすくなる
後継のマネージャーに「騙された、マネージャーの仕事ってもっと楽だと思ってた」と言われたらミッションコンプリート！
もはや新人マネージャーではあるまい
ペインポイント洗い出しワークショップ ～課題を深掘りして価値ある解決策を見つけよう～
ゴール
目標達成に向けた具体的なアクションを可視化する
短時間（決まったタイムボックス）での意思決定をすること
原因分析のループから脱出して行動に移せるようになろう
ワークショップ
フィッシュボーン（因果関係図）で問題特定・原因分析
ゴール・目標を1つ決める
例：１ヶ月以内に55kgから50kgになる
解決策を練る前に評価基準と重みづけを決める
評価基準に基づいてフィッシュボーンの各項目をスコアリングしてランクづけする
SMART分析によるアクションプランの作成
プロダクトマネージャーこそがリーダーだった！？ リーダーシップ論から見るPdMとスクラムのいびつな関係
V&R論文を受けて、PdMに着目し研究を始めた
PO/PdMとスクラムチームのメンバー合計14人にインタビュー
インタビューある程度終わった段階でV&Rの著者に連絡
著者から推薦された論文を読み進める
インタビューで確認できた現象はほぼリーダーシップの概念で説明できそうということがわかった
そもそもPdMとPOの関係って？
Ken Schwaberの記した文献から探る
1995年 "SCRUM Develpment Process"
POもSMもまだ登場しておらず、スクラムのマネジメントはPdMのリードで行うといった記述がある
マネジメントチームを想定するような記述もある
2004年 "Agile Project Management with Scrum"
POが（初めて？）文献に登場
紹介している事例で、あるPdMを「影のPO」とみなしていたという記載がある
2007年 "The Enterprise and Scrum"
POはPdMが担うことを前提とするよな記述
POは従来のPdMとは違い、プロジェクトマネジメントに責任があり、上位のマネージャーに対して説明責任があると説明
2008年 "The Scrum Primer" でも従来のPdMと違い、PjMに判断を委譲しないという趣旨の説明がある
2009年 スクラムガイド初版 公開
しかし
現状PdMとPOは多くの組織で併存
まとめ直すと3つのパターンがあった
POがPdMを兼務
PdMがチーム外にいて、POはチームとPdMとの仲介役
どちらかのロールが実質的に置かれていない
類似の問題：代理PO
事業部長などのPOがPdMに相当
チームの代理POがPOに相当
研究する
PdMとPOの区分けはまちまちなので、POは明確に扱わず、PdMとスクラムチームの関係のみを扱う
PdMはプロダクトマンデートを持つ人物と仮定する
問いと現状
PdMとスクラムチームの関係を構成する要因は何か？
関係モデルの仮説を構築、その検証をしようとしている
その関係はチームとの有効性にどう影響するか？
検証中
仮説：適合性
Congruenceのこと
リーダーとフォロワーがそれぞれ持つ価値観・目標・役割期待などの調和のこと
適合性の例
条件適合理論
価値の一致
例えば、技術的負債への向き合い方や失敗の許容度が、PdMとチームで適合していたり、適合していなかったりする
チーム外にいるPdMとの問題は、適合性に集約されて、チーム外にいても適合性が高ければ問題は解決されるのではないか？
適合性を左右するかもしれない2つの要素
コミュニケーションの質と量
組織における距離（認知的・文化的・社会的）
適合性が低くなりやすい例として、正社員と業務委託がある
距離を縮める手段として学術的に効果が確認されているもの
リフレクション
心理的安全性
フィーチャーファクトリーについて
Cutler の、プロダクトの価値やアウトカムを考えることなく、ただ機能を作り続ける組織の状態のこと
いわゆるビルドトラップとも関連が強い
新機能を作り続ける過度なプレッシャーで、技術的負債にも繋がりやすい
ただし、アジャイルのコミュニティで話題になるときは、チームの状態のことを指していることがある（出典があるとすれば Cagan&Jones の EMPOWERMENT）
チーム外から飛んでくる機能依頼をただこなしているだけのチームの状態
どちらでも、「機能をただ作り続ける」というのは変わらない
フィーチャーファクトリーと適合性
適合しているからといって、フィーチャーファクトリーにならないわけではない
仮説：適合していれば、フィーチャーファクトリーでも有効性の高いチームになるかも？
おわりに
ここまでお読みいただいた方ありがとうございます！
明日はクロージングキーノートだけ書くかもしれません。
それでは、またこんど！