Sansan プロダクト開発部のPMO*1の尾部です。
少し前に新部長の旗振りのもと、プロダクトバックログ（以下Backlog）の一本化と、諸々のことをドラスティックに変えました。他社B2Bプロダクトマネージャーと話すと「うちも一本化すべきだと思ってはいるんだけど…」「詳しく教えて」と興味があるようでした。特に大企業にとっては、変化に伴う痛みが大きくて実現できずにいるとのことです。
試したい方もいると思うので紹介します。
3ヶ月踏ん張ればできる一本化
今やっていることはとてもシンプルで、
- 一本化したBacklog上で優先順位を決める
- エンジニア約3名で構成されたチームごとに、優先度Highの各種Issueから順に開発し、クオーター内に開発完了を目指す
ただこれだけです。
以下、「なぜ変えたか」「変えた結果どうだったか」「一本化するだけでは駄目」という話をします。
Backlog一本化とは？ 一本化したのはなぜ？
当社もそうでしたが、特定のセグメント、例えば機能やOKRごとにプロダクトマネージャーとエンジニア（+デザイナーが入ったり入らなかったり）の7人前後のチームを設け、そのセグメントごとに個別のBacklogを持つ会社が多いようです。
メリットは、特定のセグメントを任されたチームで意思決定と改善が即座にできること。デメリットは、部門全体の優先順位と開発着手順がアンバランスになること。
ご存知無い方向けにデメリットを補足させてもらうと、例えば機能AとBにチームを分けてそれぞれにBacklogを持っている場合、時間が経つとチームAには課題が山積み、一方のチームBの課題は全て消化された状態になったりします。部門全体から見るとチームAのBacklogには優先度が高い課題が残り、チームBには優先度が高い課題がもう無いと。
チームBのリソースが浮くので、その後どうなるかというと、
- Backlogの中で優先度が次点の機能Bを消化する
- チームをそのつど再構成する（チームを解体してA'チームを作るなど）
のどちらかになることが多く、それぞれの問題は、
- 次点の開発を続けると、部門的には優先度の低い機能Bにリソースを投下する
- 都度都度チーム再構成すると、マネジメント側の体制の再構成のコスト（+ メンバー側の学習コスト）を投下する
というモッタイナイが発生します。
私達にとって顕著な1の問題を解決すべく、一つのBacklog上で部全体の開発優先順位を決めたいよね、と「Backlog一本化」と名付けて体制を変えました。
Backlog一本化で「得たもの」「支払ったもの」「お釣り」
変化には痛みが付きものとはいえ、今回はお釣りがあったと思います。
得たもの
Backlog一本化の最大の目的であった、部全体の優先順位通りに開発することができるようになりました。
支払ったもの
優先度確定の議論に100時間以上使ってしまった
優先順位を確定すべく、複数のプロダクトマネージャーやステークホルダーとの会議を設けねばならなくなりました。また、複数のプロダクトマネージャーが持ち寄った渾身のWhyとWhatも、優先順位の議論で蹴落とされることも多々あり、あの時間は何だったんだ…と遠い目になります。
学習コストが重なった
これまで担当していた領域以外を開発することになったため、学習コストが大きく、見積もり工数を大幅に超えたプロジェクトもありました。
チームメンバーだけで意思決定できなくなった
チームが改善点を見つけても、基本的には一本化されたBacklogの上で優先順位が合議されることになったため、以前のようにチームに閉じて即座に改善することを難しく感じるメンバーもいました。
お釣り（付加価値）
「なぜやるか」が、よりシャープになった
過去はチームのプロダクトマネージャー1名に判断を委ねられていましたが、各方面から「本当にそう？」「こっちの方が大事では？」と激しくツッコミが入るようになり、WhyとWhatが洗練されました。
それに伴うメンバーの納得感
過去は「機能Bより機能Aの方を優先しなくていいの？」という他チームメンバーの指摘もあったが、今は全体的に「その順番だよね」と納得感を得られているように感じます。Backlogそのものが、チームではなく、部の方向性を感じられるものになってきました。
エンジニア・デザイナー・プロダクトマネージャーが特定セグメントに縛られずチャレンジできるようになった
せっかく大規模なプロダクト（スキャナの筐体が触れるプロダクトなんてなかなか無いですよね）であれば、色々やってみたいですよね。Backologにはいろんな種類のIssueが積まれているので、時には専門外のセグメントにもトライできるようになりました。
実は大して失ってはいない
先程、支払ったと書きましたが、大損したとは考えていません。
優先度確定の議論に100時間以上使ってしまった
優先度の高くない開発に100時間（約1人月）かけるより断然お買い得でした。
学習コストが重なった
時が解決する成長痛であり、組織やメンバーの柔軟性を養う先行投資だと考えています。
チームメンバーだけで意思決定できなくなった
ユーザに直接影響がある仕様でなくて2~3日で終わるものなら運用時間に自分らの裁量でやれば良く、それ以外であれば正当に優先度判断のテーブルに上げられるのが本来のあり方ではないでしょうか。
Backlog一本化だけではない変化
単純にBacklogを一本化するだけでは上手くいかなかったとは思います。補完するような変化も色々ありました。新部長が立ったからには一気にやろうと、それはドラスティックに変えました。一部紹介すると以下のとおりです。
- プロダクトマネージャー・エンジニア・デザイナー三位一体のチームを解体した
- プロダクトマネージャーはSansanプロダクト開発部エンジニア出身者を中心にした
- プロジェクトマネジメントオフィス(PMO)を設置し、エンジニア未経験のプロダクトマネージャーはそこに就けた
- 開発プロセスを再構築した
- 新たなツールを導入した
いずれも痛みを伴う変化です。それぞれの具体的な内容は後日紹介したいと思っています。
変化に伴う迷いや心の痛みをフォローするために
変化への「支払い」の中には、メンバーの判断の拠り所が揺らいだり、精神的な負担もあります。これは慎重に配慮しました。
過渡期ゆえ未決定なことへの迷い
なにせ100人規模の開発部門です。迷いもコストになるので、判断に困ることはすぐさま察知して、方針を決めるようにしました。
- 体制変更に関する課題は週次で改善する
- 決まりごとはドキュメントに残しておく（情報が口伝で一人歩きしないよう）
今までと違うことに対する違和感、心の痛み
変化を苦に思うメンバーもいれば、この変化が自身の理想とは違うと感じたメンバーもいたはずです。モヤりを受け止められるような体制作りも合わせて行いました。
一つは、組織デザイングループを新設したこと。部の組織構造やメンバーのキャリアを考えるグループで、つらくなったメンバーがいないか？みんなに楽しくやりがいもって働くにはどうしたらいいか？など心理的安全性を担保する取組みをしています。
2つ目は、モヤモヤをぶつけるラインを多様化したこと。新部長によるプロダクトマネージャーとの1on1、キャリアマネージャーによるメンバーとの1on1、各リーダーから部長・副部長へのQ&A、各チームからプロダクトマネージャーへのQ&Aの場を設けるなど、縦横斜めにコミュニケーションを取れるようにしました。
最後に
私自身もこの変化に大して、仕事人としては肯定的、一個人としては悲観的だったのが正直なところです。今となっては結果はプラスに働いているので良かったなと思います。
私以外のメンバーもそれぞれが仕事人として、そして一個人として葛藤し、いろんなチャレンジがあったからこそ得られたものなので、本当はもっといろんなことを書きたかったのですが、長くなるのでまたいつか書くことにします。
*1:Project Management Office
