Sansan Builders Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

開発チームでデリゲーションポーカーをやってみた

Sansan事業部 プロダクト開発部のエンジニアの岡野です。

先日、開発チーム内でデリゲーションポーカーを実施したので、そのときのお話を紹介したいと思います。

デリゲーションポーカーとは?

担当するタスク(テーマ)において、誰がどのレベルの責任を負うのかを7枚のカードを使用してすり合わせ(権限移譲)を行います。
例えば、有給休暇を取得する際にチームリーダー(管理者)とどのように相談し決めているか等のテーマを決めて話し合います。

実際に使用したカードは以下になります。

f:id:orange-33:20191201233126j:plain

  • レベル1. 命令する : 私が彼らに決定を伝える
  • レベル2. 説得する : 私が彼らに売り込む
  • レベル3. 相談する : 彼らに相談し私が決める
  • レベル4. 同意する : 私が彼らと合意して決める
  • レベル5. 助言する : 私は助言するが彼らが決める
  • レベル6. 尋ねる : 彼らが決めた後で私が尋ねる
  • レベル7. 委任する : 私は彼らに完全に委ねる

レベル1に近づくほどチームリーダー(管理者)が決定することを意味し、レベル7に近づくほどチームメンバーが決定する裁量があることを意味します。

デリゲーションポーカーの流れ

  1. 話し合いたいテーマを決める
  2. テーマに応じて、各参加メンバーが理想と考えている権限の状態(レベル)のカードを選択する
  3. 各参加メンバーが選択したカードの理由をそれぞれ説明する
  4. 3. で説明された理由を踏まえて、チームとしてどのレベルの権限移譲を定義するのか話し合い決める

今回実施したデリゲーションポーカーでは、オリジナル要素が一つあります。
Sansan事業部 プロダクト開発部のPMの加藤に教えてもらった手法です。

デリゲーションポーカーの流れ自体は変わらないのですが、As-is(現状)、To-be(理想)の2パターンを整理する以下の流れで実施しました。

  1. As-is : チームの現状のレベルのすり合わせを行う
  2. To-be : As-is を考慮したうえで理想とするレベルのすり合わせを行う

今回は、開発チームのチームリーダーとチームメンバーでのタスクに関する権限についてのすり合わせを行いました。私は、開発メンバーとしての参加です。

デリゲーションポーカーを実施した目的

今回実施した目的は以下の3つです。

  • チームリーダーの負荷があがっているのでチームメンバーに権限移譲できることはないか整理する
  • チームに新メンバーが参画したため、チームの現在の権限状況について整理する
  • 開発プロジェクトの状況に応じて流動的に人の異動があるため、属人化しない状況にする

実際にデリゲーションポーカーをやってみた

今回は、チームリーダー1人、チームメンバー5人という構成です。
f:id:orange-33:20191202092329j:plain

デリゲーションポーカーを行う場で取り上げるテーマを洗い出すと時間が足りないため、予め話し合いたいことをチームですり合わせてから臨みました。

選択したテーマは以下の7つで、テーマ毎にAs-is、To-beをそれぞれ1回ずつの2回実施しました。

  • 開発プロジェクトのスコープの判断
  • 開発メンバーの次に担当する開発プロジェクトのタスクを決める
  • 開発プロジェクト以外の差し込みタスクの優先順位を決める
  • 開発プロジェクト内でプロダクト開発部外の他部署との相談
  • 開発プロジェクト内でプロダクト開発部内の他チームとの相談
  • インシデント対応の進め方や対応方針
  • 開発プロジェクトのリリース日判断

実施した結果は以下になります。
f:id:orange-33:20191202020505j:plainf:id:orange-33:20191202020527j:plain

予想はしていたのですが実際に実施してみると、
As-is ではレベル1~3が多く、To-beではレベル4~7へ権限委譲を進める方針するという結果になりました。

6人のメンバーが一人ずつ選択した理由について話すので、1つのテーマにつき、20分程の時間がかかっています。
7テーマについて話し合った時間の合計は2時間ほどです。

話し合ったうちの1テーマについての紹介

「開発プロジェクト以外の差し込みタスクの優先順位を決める」のテーマで話し合った結果を1例として紹介します。

エンハンス開発と運用/保守の両方を担当している開発チームでは、差し込みタスクが発生するのはよくある話だと思います。
今回は、緊急度の高い差込タスクという前提です。具体的には以下のようなタスクを指しています。

  • 日々の運用チェックで発覚した問題(エラーなど)の深堀や原因調査
  • 他部署からのプロダクトに関する問い合わせ対応(顧客からの問い合わせやイレギュラー対応の依頼等)

まず、As-is では「レベル1.命令する 」という結果でした。
チームリーダーは色々な問い合わせ窓口を担っており、各所から問い合わせを受けた結果、差込タスクの優先度とチームメンバーが現在持っているタスクの優先度を比較して総合的な優先順位を判断し指示することが多いため、レベル1としています。

次の To-be では「レベル5.助言する 」という結果でした。
チームリーダーの負荷を軽減したい、自立的に動けるチームにしていきたい、というチームの思いがあり、レベル5となりました。

To-be の実現に向け、現状を改善するためにまず取りかかることになったタスクは以下のものです。

  • チームリーダーが担当している問い合わせ窓口をチームメンバーに移譲する
  • チームが担当しているプロダクトの機能について、チームリーダーが一番詳しい状態からメンバーも同等の知識を持った状態になるようノウハウを引き継ぐ

現在は、問い合わせ窓口をチームメンバーに引き継ぐところから徐々に進めています。

終わりに

実際にやってみるとチームリーダーと開発メンバーでの認識が異なるだけでなく、開発メンバー間でも認識が異なることがありました。
チーム立ち上げ時や新メンバーがチームに参画した際に実施すると、チームの現状が洗い出される、かつ、権限委譲することでチームをどのように成長させていきたいかという方向性を決めることに効果があると思います。

今後、チームでタスクをこなす際の判断軸が定まり、効率よくタスクをこなせるきっかけになるのではないでしょうか。
ぜひ、一度お試しください。

参考

Management3.0のデリゲーションポーカーについて
https://management30.com/product/delegation-poker/

© Sansan, Inc.