PMと開発チーム（PL）との間のデリゲーションポーカーをやってみて

どうも、大曲です。 最近、冷やし中華が美味しく出来ました。嫁が喜んでくれました。嬉しかったです（笑）。

１年ほど前からいくつかのロールでデリゲーションポーカーをやってきました。 その中でもPMと開発チーム（PL）間でのデリゲーションポーカーを一番活用しています。
内容や実施してみてどう感じたかをまとめます。

前提情報

役割の説明

役割名	説明
PM（プロダクトマネージャー）	事業責任者と連携し、プロダクトの方針を明確化する プロダクトで何を作るかを決定し、プロダクトの成長に責任を持つ スクラムではPO（プロダクトオーナー）に該当する役割になる
PL（プロジェクトリーダー）	ステークホルダーと連携を取りながら、無理なく遅延なくチームOKRを達成に責任を持つ
UM（ユニットマネージャー）	弊社の役職の1つでアドテクDivではスクラムマスターであり、ピープルマネジメントの責任を持つ
ディレクター	プロダクト・プロジェクトにおける社内外調整を行いながら、円滑なプロジェクト進行に責任を持つ
サービス責任者	サービス全体の品質に影響するアーキテクチャの変更や障害対応（監視の最適化）などに責任がある

チームの状況

チームは全部で４チームで、それぞれ抱えている案件が違うためOKRやPMの関わり方などが違います。
また、チームによってスクラムにおけるPO（プロダクトオーナー）に該当する役割が異なっている状態です。

チーム名	案件の種類	チームのObjective
チームA	新規価値	価値のある機能を展開し、事業に貢献する
チームB	社内効率化	分析または計画により価値を的確に評価し、体験価値向上を推進する
チームC	技術改善	Opsから価値を生み出す
チームD	機械学習	将来的に売り上げ平均1.25倍達成できるような準備をする

案件の種類はリリーストレインによって決めています。

チームA(新規価値)

プロダクトの新機能を開発のみだけでなく、リリース後の分析もチームで担当しています。 PMがスプリントレビューでステークホルダーを巻き込んで、MVPの判断や分析の議論をファシリテートしたりしています。
ただ、PMがチームDと兼務しているため、プランニングなどは参加していますが、レトロスペクティブには参加できていないです。
このブログを書きながら、兼務しているとはいえレトロスペクティブには参加した方がいいなと思い始めました。。。

スプリントイベント参加状況

役割	スプリントプランニング	デイリースクラム	スプリントレビュー	スプリントレトロスペクティブ	リファインメント
PM	○	×	○	×	○
開発チーム（PL）	○	○	○	○	○
UM	○	○	○	○	○
ディレクター	○	×	○	×	○

チームB(社内効率化)

社内の効率化の開発を行っており、POとしては社内のユーザーインタビューやプロトタイプ作成などをしているUXデザイナーの方に譲渡しています。
サービス全体を管理しているPMは別にいます。「サービス全体を見ているPM」から「PMを兼務しているUXデザイナー」へ権限が譲渡されており、
効率化の全体戦略やターゲットなどは両者が合意をしてゴールを決めています。

PLの専任はおらず、チーム全体でカバーしあえるような体制にしています。
チーム全体が自己組織化を目指した結果と言えます。上司として誇らしいです。素晴らしい！！

スプリントイベント参加状況

役割	スプリントプランニング	デイリースクラム	スプリントレビュー	スプリントレトロスペクティブ	リファインメント
PM	○	○	○	○	○
開発チーム（PL）	○	○	○	○	○
UM	○	○	○	○	○
ディレクター	○	×	○	×	○

チームC(技術改善)

技術改善がメインですので、PMはあまり関わっていません。
実質、PLがPOとして活動してもらっています。PLはテクニカルマネージャーですので技術の価値や改善の方向性を立案できる人材だからこそ成り立つ形であると思います。

技術改善ですが、分析も行っています。
例：高速化に伴う事業影響や開発プロセスのメトリクスの分析..etc

スプリントイベント参加状況

役割	スプリントプランニング	デイリースクラム	スプリントレビュー	スプリントレトロスペクティブ	リファインメント
PM	-	-	-	-	-
開発チーム（PL）	○	○	○	○	○
UM	○	○	○	○	○
ディレクター	○	×	○	×	○

チームD(機械学習)

最近できた機械学習をメインとしたチームです。
研究開発に近しい動きで状況に応じて変化が激しいのでPMが開発チームとして一緒にすべてのイベントに深く関わっています。
チームAとは違い、あまりステークホルダーを巻き込んでおらず開発チームとPMが数字とにらめっこしています。
（あまりにも機械学習のコアな話になったりするので巻き込みづらいのが状況です）

ディレクターは不在ですが、その役割はPMやPLがカバーしています。

スプリントイベント参加状況

役割	スプリントプランニング	デイリースクラム	スプリントレビュー	スプリントレトロスペクティブ	リファインメント
PM	○	○	○	○	○
開発チーム（PL）	○	○	○	○	○
UM	○	○	○	○	○
ディレクター	-	-	-	-	-

PM → PL デリゲーションポーカーの内容説明

方針

デリゲーションポーカーの方針としては以下のような内容を考えています。

エンジニア主導で仮説検証のサイクルを回せるようになり、主体的にプロダクト貢献できるような体制を作る。  
プロジェクトの方針と戦略が主にPM側の責任範囲で、戦術・遂行・管理が主なPLの責任範囲である。  
開発領域に関してはエンジニア側で裁量を持って判断できるように権限を移譲する。  
分析の領域に関しては、PMとディレクターとPLで一緒に体制を考えていく。

各項目の内容と各チームでの結果

実際に各チームとの結果は以下の通りです。 項目は、複数チーム共通で利用することを意識して、行動よりも責任を明確にしています。

○＝基準としているもの
A、B、C、D＝各チームの項目

実際にやってみてどうだったか？

組織の変化の状況が一目でわかる

１年間程続けたからこそなのですが、案件やチームの状況に応じて項目毎で変化が大きいのでチームの状態や時系列で比較すると差分が明確になります。
自分は複数チームを管理している立場になりますが、各チームの細かな違いや変化もデリゲーションポーカーを通すことで圧倒的に把握しやすくなりました。
当事者同士の認識合わせとしてだけで無く、全体を管理する者のメリットが大きい事は意外でした。

また、デリゲーションポーカーを実施している会議に自分が参加しています。 そのため、複数チームの状況を元に意見を言えることがあり、チームに対しても新たな観点を与えるきっかけにもなるのでやってみていない方は是非やってみてください。 「あのチームはこういった行動していたから聞いてみるといいよ」..etc

普段は隠れている意見が出やすい

チームとして成熟しているチームでも「実はこう考えているんですよ」という場面が多いです。

こういった場面の背景は、何パターンかあります。

• 実は我慢していたことがあって...
• 改めて考えると別の意見を思いついた...
• 現状はそうだけど、実は理想としてはこうしたいんだ...

デリゲーションポーカーはチーム編成や役割変更後にすぐには実施はしません。
チームとして慣れてきた場面（新しいチームになって2~3週間経過している）時に行うため、こういったことが多く遭遇する気がします。 チーム変更と案件変更は3ヶ月毎で行っています。
毎回、全メンバーがリセットされるわけではないですので引継ぎされる部分も、そのタイミングで更新していますのでちょうど良いサイクルだなと思っています。

項目だけで無く、当事者同士が認識している行動まで押さえておくべき

デリゲーションポーカーの項目だけでは、責任や行動をある程度記載できます。 ただ、チーム毎で状況が違うため共通の内容だけで無くそのチーム独自の内容まで書いた方が良いです。

そうすることで、当事者が認識している行動をすり合わせが効率よくできるからです。

実際の「案件優先度の判断」での各チームの補足内容

チーム名	譲渡レベル	補足内容
チームA	同意する	今まではPMが会議で決定して降ろしていたが、持ち帰ってPLと相談するようにする。 持ち帰り方次第で結局、説得する流れになる場合があるためそれは都度気にするようにする。 PMが説明する時にPLが「それ、説得のスタンスですよね？」と言えばデリゲーションポーカー通りではない。危険信号のキーワードになる。 また、同意になるので決断のためのリードタイムが長くなるのは重要視しない方向にする。あくまで譲渡する方向を優先する。 リリーストレインの優先度とかもチームからの意見を受け止める。 例：「分析は集中させた方がいいですよね。なのでこの週で一気にやりましょう」→分析の優先度変更が行われる
チームB	相談する	体験向上の全体である目標、スケジュール、ターゲットはサービス全体を管理しているPMが責任を持つがリリーストレインに関わる内容はPM兼UXデザイナーが担当している。 現状はリリーストレインの内容は既にフォーカスが決まっているので5月までのリリーストレインでは大きな変化はない認識。あればサービス全体を管理しているPMに相談する予定。 叩き台はPM兼UXデザイナーが考えるがそれを元に開発チームに相談する動きになっている
チームC	尋ねる	エンジニア発信の改善を混ぜ込んだリリーストレインに今回はなる リリーストレインのレビューはして欲しい（Div全体で見た時に他チームとの依存、連携、効果を見る） 進捗が進むにつれて、優先度の変化が発生した時に、最終的にチームのOに影響ある動きができているのかPMが見る 費用対効果が低いものに対して優先度を上げていた場合もある（あまりないとは思うが）
チームD	同意する	機械学習関連でやりたいこととか調査したい技術をPL発信で進めていきたいから。 リリーストレインの結果がOKRに紐づくだったり、プロダクトゴールにズレは無いかはPMが判断する。

このような補足が各項目で必要に応じて記載されています。

まとめ

単純にスクラムと言ってもチームや案件の状況に応じて色々なスタンスがあります。
特にメンバーが成熟していけばいくほど、組織として柔軟性を求めてたり、暗黙の了解も増えていくと考えています。
「親しき仲にも礼儀あり」という言葉と似たように「親しき仲にもデリゲーションポーカーあり」かなと改めて実感しました。