ペイトナーファクタリング事業部でEMをやっている脇田（@shimpeee_）です。
プロダクト組織の拡大に伴い、「これって誰がやるんだっけ？誰が決めるんだっけ？」という疑問が生まれる場面が増えました。そこで、事業内のプロダクト開発における意思決定に関わるメンバーを集め、誰が・いつ・どのように意思決定するかをRACIというフレームワークを使って決めるワークショップを行いました。
ワークショップにより、どんな役割があるのか洗い出され責任範囲が明確化されました。非常にいい時間だったと思いますし、参加した他のメンバーからも同様のフィードバックをいただきました。
この記事が、みなさんにとっても日々の業務を見直すきっかけになれば幸いです。
背景
ペイトナーファクタリングは、事業の中期計画として単に売上だけでなく、プロダクトミッション実現のため複数軸で並行してプロダクトを成長させていく必要があります。
事業成長に伴い、プロダクト組織は過去最大規模になっており、今後さらに拡大予定です。また、人の入れ替わりで中心ポジションの専任が不在となり兼務が多い状況でもあります。その結果、各チームと事業責任者との間でどのように意思決定を行うのかが曖昧な状態になりつつありました。
そんな中、直近ジョインされたメンバーから「事業と開発とのアラインメントがちょっと弱そうですね」と言われることがありました。この一言は、僕が直近抱えているモヤモヤをズバり言い表したものでした。
それからしばらく現状の組織的な課題について考えていましたが、「事業と開発とのアラインメントが弱いこと」にほぼ全ての問題が内包されているとの確信に至りました。この抽象度の高い問題を解決しない限り組織として前進できないと思ったので、この機会に役割＆責任を明確化したいと思い、関係者を招集しました。
参加者
- 事業責任者
- PdM（兼CSマネージャー）
- PdM（副業）
- EM（自分）
- EM
- CTO
当日のアジェンダ
- RACIの理解タイム
- RACIチャートの作成
- 会議体の整理
RACIの理解タイム
RACIのフレームワークに誰も馴染みがなかったので、まずはRACIを理解するための時間を10分設けました。今回は、RACIと合わせてマネジメント3.0に出てくる「デリゲーションポーカー」を組み合わせて権限委譲レベルを可視化しました。
このあたりの整理は、アカツキさんのテックブログ『エンジニア組織の責任範囲の透明性をRACI図で高めてみた - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)』を大変参考にさせていただきました。ありがとうございます。
RACIチャートの作成
ワークショップのメインブロックです。
事前に叩きとなるチャートを作成しておき、それを元に役割の細分化と各役割の責任明確化を1つずつ行いました。
ペイトナーでは、『プロダクトマネジメントのすべて』の思想やエッセンスをプロダクトマネジメントに取り入れています。今回のRACIチャートも、本書に出てくるプロダクトの4階層（仮説のミルフィーユ）をベースに役割を分類しました。
各メンバーに発散的に意見を出してもらい、最終的に誰をR/A/C/Iにするかを合意で決めていきます。
会議体の整理
RACIチャートの作成が終わったら、それぞれの役割について適切に意思決定・実行・相談・共有がされる会議体が整備されているかを確認します。既存の会議体の目的・頻度・参加メンバーを見直し、必要に応じて変更を行いました。この「RACIで役割を明確化するMTG」自体も定期的に開催すべきだよねという結論になり、Qごとに定期開催することに決めました。
よかったこと
やってみてよかったことを、チームと自分個人の観点で挙げてみます。
チームとして
まず箇条書きにすると、以下がよかったポイントです。
- 抽象的な互いへの期待値を初めて伝え合うことができた。
- 未来のあるべき姿についてもある程度認識合わせることができた
- オフラインで発散的な会話をワイワイできて楽しかった
1. 抽象的な互いへの期待値を初めて伝え合うことができた。
最終アウトプットとしてRACIチャートを作成しそれぞれの責任範囲が明確化されたことで、
- 意思決定（A）を多く持つメンバーが、他メンバーにどう動いてほしいかの期待値を明らかにできた
- 実行（R）を多く持つメンバーが、どこまで主体的に動くべきかの期待値を明らかにできた
- RACIチャートとしてアウトプットしたことで、誰に仕事が集中しているかが可視化された
- 現状落ちているボールを洗い出し、新たに役割明確化しボールが落ちづらい体制を作ることができた
といった良いことがあったのはある程度想定内でした。
それだけでなく、今回のワークショップを通じて、抽象的な互いへの期待値を伝えることができたのが非常に良かったです。
職能上の直接的な指揮系統（いわゆる上司-部下）の関係性であっても、上司が最終的な責任を持つとしてもデリゲーションポーカーのどのレベルで部下に委譲されているかは、相互の認識合わせをしっかりやらないとかなり曖昧です。ましてや今回のような職能や役職を超えた関係性における仕事の境界線や責任は非常に曖昧です。
なんとなく全員が「この辺りの仕事はxxさんがやるよね」というふわっとした期待値でよしなに動いている状態でした。組織規模が小さいうちはそれでも回せますが、規模が大きくなってきた今まさに必要な議論だったと思います。
ワークショップ後もどんどん新しい仕事は生まれていますが、RACIチャートを使って適切に役割分担できています。
2. 未来のあるべき姿についてもある程度認識合わせることができた
RACIチャートを作成すると、誰に業務が集中しているかがはっきりと可視化されます。具体的には、実行である「R」をたくさん持っている人は忙しくなりがちです。業務を多く抱えている人の負荷軽減や、より専門性を持った人が必要といった観点で、「ここにこんな人がいるといいよね」という話が自然と生まれます。未来の理想像と現状とのギャップが明確になり、今後の採用方針もより磨かれました。
3. オフラインで発散的な会話をワイワイできて楽しかった
弊社の出社スタイルは、基本リモートで都内のオフィスに通える人は週1〜2出社、遠方に住んでいる方は不定期で交通費会社補助で出社、という形です。出社はチーム内コミュニケーション活性化を主な目的としており、チームごとに出社日を分けています。ゆえに、複数チームのマネージャーレイヤーが一同に介して発散的に会話するような機会が意外と日常ではありませんでした。
「リモート VS 出社」には様々な論争がありますが、出社による人間関係構築のしやすさや偶発的な会話が発生することは、リモートでは得づらい非常に大きなメリットだと感じます。
個人として
- 準備に時間をかけたおかげで、当日は生産性の高いMTGができた
- 自分のチームへの関与方針もRACIで整理するきっかけになった
準備に時間をかけたおかげで、当日は生産性の高いMTGができた
社内で（自分も含めて）誰もRACIに馴染みがなかったこと、扱うテーマが非常に抽象的かつ発散的な議論が展開されることが予想されたので、事前の準備が非常に大事でした。また、今回のようなワークショップを企画＆ファシリテートするのがほぼ初めてだったので、事前準備にはかなりの時間がかかりました。
組織開発アドバイザリーの方と壁打ちしながら、当日のアジェンダや事前準備をどこまでやるか等を詰めました。
当日、RACIチャート作成が終わって小休憩中に「正直、ここまで決まれば僕としてはもう満足です」と言ったところ、参加者の一人から「主催者が満足したなら最高じゃないですか。こういうの、ファシリテーターが一番大変ですからね」と言ってもらえて、準備を含めてやりきって本当によかったと思いました。
自分のチームへの関与方針もRACIで整理するきっかけになった
ワークショップの参加者は事業責任者・各チームのPdM・EM・CTOでした。今は自分が事業全体の開発組織を見ているので、自分と各開発チームとの関わり方についても、RACIで責任範囲を明確化し、参加するMTGも整理しました。
まとめ
RACIフレームワークを使って責任範囲の可視化ができ、仕事がしやすくなってとてもよかった！という話でした。組織スケールに伴う様々な課題が出てきているので、マネージャーとして今後も向き合っていきたいです。
さいごに
最後まで読んでいただきありがとうございました！
ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください！！
現在ペイトナーの開発組織では、以下ポジションを積極採用中です！！！
- Webエンジニア
- エンジニアリングマネージャー
- プロダクトマネージャー
お話聞いてみたいだけの方も大歓迎です。より現場の生の声を聞いてみたい方は、HPのカジュアル面談申し込みフォームからぜひお申し込みください。お待ちしております。
