チームメンバーが増えてきたので、「デリゲーションポーカー」を実施してチームへ権限移譲を行った話
Flyleの荒井です。
2020/02の創業のタイミングではフルタイム4人でスタートした株式会社フライルですが、1年半経過した現在はフルタイムの3人と数名の業務委託のメンバーが加わり、まだまだ小さいですが少しずつ「チーム」と呼べる規模になってきました。
日々新しい課題が生まれるスタートアップにおいて、その時解決すべき課題に応じてメンバーは役割を「いい感じ」に変えながら柔軟に対応する必要があります。
人数が少なければ密にコミュニケーションを取ることで上手く回りますが、一定人数が増えてくると「いい感じ」による曖昧さが原因となり、想定していない方向に物事が進んだり、または必要以上に誰かに確認をしたり、といったケースが増えてきます。特にリモートでのコミュニケーションが当たり前になった現在では、このようなコミュニケーションに関する問題が容易に起こるかと思います。
今回の記事は、上記の課題に対する打ち手として「デリゲーションポーカー」を実施した話です。チーム内で特定の人に権限が集中してしまいボトルネックになってしまっている場合や、権限移譲がなかなか上手く行えていないという課題感がある方の参考になれば嬉しいです。
# 想定読者
・マネージャーとメンバーの権限が曖昧になっているチーム
・チームへの権限移譲を行いたいマネージャー、などなど
事業のフェーズが進むにつれて変わっていく役割
創業のタイミングではプロダクト側の人数は、僕 + エンジニア1名の2名体制でした。当時のミッションはとにかく「顧客にとってもビジネスとしても価値のあるプロダクトを立ち上げること」でした。Flyleというサービスはプロダクトマネジメントという領域に向けたサービスであるため、チームの中で一番ドメイン理解をしていた僕がプロダクトマネージャーとしての役割を担い、開発者としては主にフロントエンド全般の開発を担当していました。
プロダクトが一定立ち上がり、資金調達の目処が立ったタイミングでは、PMや開発以外にも「採用」が大きなミッションとなりました。採用活動を開始すると、面談や会食など差し込みの予定が増え、面談中はSlackのメンションなどにリアルタイムで返信することが難しくなってきます。基本的には各自やるべきタスクは大量にあるため、それによって手が止まってしまうということはありませんが、「荒井が確認しなければ先に進められない」という状態が頻発すると、チームとしての開発スピードは落ちてしまいます。
ある時、チームから「細かな仕様や技術的な意思決定など、どこまで相談すべきか分からないため仕事を進めにくい」というフィードバックを受けました。人数が少なかった時は、仕様や技術的な設計などあらゆる意思決定をしなければ前に進めませんでしたが、チームの人数が増えてきたことで、特定の1人がほぼ全ての意思決定に関わることがチームの生産性を落としてしまっていることに気づきました。
特定の領域において、僕よりも圧倒的に知見のあるメンバーもいるため、その知見を十分に活かすことで個人の経験不足を補い「チームとして最適な意思決定」ができるはずです。その土壌を作るために「デリゲーションポーカー」というワークをプロダクトチーム内で行いました。
「デリゲーションポーカー」は曖昧な権限を明確にするワーク
「デリゲーションポーカー」に関してはweb上にも様々な記事で説明されているためここで深くは説明しませんが、簡単にいうと、ある業務や意思決定において、誰がどの程度（7段階）権限を持つのかをチーム内で明らかにするワークとなります。
デリゲーションポーカーのやり方や事例は以下の記事が参考になります。
1-7の権限レベルはそれぞれ以下のように定義されており、数字が高いほどチームへ移譲されていることになります。
レベル1. 命令する : 私が彼らに決定を伝える
レベル2. 説得する : 私が彼らに売り込む
レベル3. 相談する : 彼らに相談し私が決める
レベル4. 同意する : 私が彼らと合意して決める
レベル5. 助言する : 私は助言するが彼らが決める
レベル6. 尋ねる : 彼らが決めた後で私が尋ねる
レベル7. 委任する : 私は彼らに完全に委ねる
業務内容の洗い出しと権限レベルの認識合わせを行う
フライルのプロダクトチームでは以下のような流れでワークを進めていきました。
参加者：5名（自分、デザイナー1名、エンジニア3名）
1. スプレッドシートに自分の業務を書き出す
2. 他の人の「これも担当してくれている」という業務を他の人の視点から書き足す
3. 話し合いたい業務に関して優先度をつける
4. 優先度が高い業務からデリゲーションポーカーを行う
図にするとこのようなイメージです。
あまり他の記事には書かれていませんが、個人的には業務の洗い出しをする上で「2. 業務を他の人の視点から書き足す」が重要だと思っています。理由としては、自分が無意識に行っている業務でも他の人からの視点によって「Aさんは〇〇をやってくれているけど、それなりに工数がかかっていそう」という業務が明らかになり、チームで負荷を分散させるアクションを取ることが可能になるためです。
また、「3. 話し合いたい業務に関して優先度をつける」に関しては、重要な業務であり、その業務に関する権限が曖昧であるものを優先的に話すと高い効果を得られそうです。
自分たちは、具体的に以下のようなテーマを扱いました。
・起票ルールの徹底やロードマップの編集など、Jira運用のオーナーシップを誰かどの程度持つか
・開発に関わる会議のオーナーシップを誰がどの程度持つか
・機能の仕様はどこまで荒井に確認すべきか
・インフラに関する権限を誰がどの程度持つか
曖昧だった権限がクリアになり、納得感も高まった
デリゲーションポーカーの良いところは Yes / No の2択ではなく、7段階のレベルが用意されている点です。全ての権限をまるっとチームに渡すこともありますが、実際の業務では「まるっとチームに任せたいけど、最終的にどうするかの判断はマネージャーが行いたい」、「マネージャーと相談しながら進めてほしいが、最終的な意思決定はチームに任せたい」など、権限をもつ・もたないの2択では表しにくいケースも取り扱うことができます。
実際にワークをやったことによって、以下のような効果を実感しています。
各権限に対して、チーム内で納得感が生まれた
ワークをやってみると、〇〇という業務に関して「自分はレベル6くらいだと思っていた」、「今はレベル3だけど、レベル5にしてくれたほうがチームとしては動きやすい」といった意見が各メンバーから出てきます。そもそもの認識が異なっている点や、どれくらいの権限を期待しているのかが明らかになります。その後、話し合いの中で最終的な権限レベルを決定するのですが、話し合いを通じて今までモヤモヤを感じていた事も発信することができるため、最終的な権限に対する納得感が生まれました。
自分がやるべきことに集中できるようになった
ワークを実施する前は、あれもこれも自分がやらなければと思っていたところがありました。デリゲーションポーカーのワークを通じて、〇〇に関してはチーム or 特定のメンバーに任せる、という意思決定をした業務もいくつかありました。メンバーが「〇〇に関してはチームにまかせて、荒井さんは△△に注力してほしい」といったやり取りがあったのですが、自分がチームから何を期待されており、何に注力すべきを聞けたため非常にありがたかったです。
ワークを実施したあと、デリゲーションポーカーに対する振り返りも行いましたが、チームからも好評でした。
ワークには数ヶ月前にフライルにジョインしてくれた新しいメンバーもいたのですが、誰がどんな業務を担当しているのか分かった、今までの経験から今後自分は〇〇という業務を担えそう、というフィードバックをいただきました。新たに人が加わった際のオンボーディングの一環としても効果があるかもしれません。
おわりに
今回は「デリゲーションポーカー」というワークに関して、実際にやってみてどうだったかを記事にしてみました。
このワークは前職のチームメンバーが教えてくれて当時のチームでも試してみたのですが、マネージャーとチームの権限がクリアになり、話し合いを通じてチームの共通認識を得ることもできたため、個人的には非常によいアプローチだと思っていました。今回ワークを実施し、改めて効果のある取り組みであることを実感しています。
デリゲーションポーカーは、チームメンバーの役割が変わったタイミングや、チームの人数が増減したタイミングで実施するとよいと言われています。一度決めた権限レベルを見直さずに使い続けることでチームが動きにくくなってしまう場合もあるため、継続的にアップデートをしていく必要があります。
実際にワークをしてみると分かるのですが、一つの業務を切り取っても最終的な権限レベルを決定するまでにそれなりの時間を要するため、スプレッドシートに記載された全ての業務に対して結論を出すことは時間的に厳しかったです。いかにチームとして話し合うトピックを選べるかが肝となりそうです。
顧客フィードバックをプロダクト開発に有効活用するための「Flyle」を開発しております。もし興味があればお問い合わせやトライアル利用をお待ちしております！
この記事が気に入ったらサポートをしてみませんか？