プロダクトを成功させるチーム構築のためにPMがすべきこととは？

プロダクトマネジメントの基本を学ぼう 第8回

　前回、プロダクトマネージャーのスキルの全体像とその中に含まれるTeam & Collaborationのうち、主に個人として持つべきスキルを紹介した。今回は、前回の記事で紹介したプロダクトの強い軸で「Cooperation」と説明している、チームを率い、社内外の関係者と協力関係を構築していく部分について解説しよう。これはプロダクトマネージャーの役割の1つとなる。筆者らは、プロダクトマネージャー向けの研修などを通じて、多くのプロダクトマネージャーの方々と対話をする機会があり、皆さんがこの「Cooperation」の部分で非常に苦労されていることを理解した。今回の記事が皆さんの日々の業務に少しでも参考になれば幸いだ。

前回記事

第7回「プロダクトマネージャーに必要な能力とは何か？ スキルセットの全体像を解説」

プロダクトチームのあり方とプロダクトマネージャーの役割

　さて、この連載ではプロダクトマネージャーが担うべき役割の範囲は幅広く、プロダクトのライフサイクルによって別の振る舞いをしなければいけないとも書いてきた。もしかすると、これからプロダクトマネージャーに挑戦する読者の中には、学ぶべき領域があまりに多く、「自分には難しいのではないか？」と思われてしまった方もいるかもしれない。

　しかし、心配することはない。CEOがすべての要素には精通していないのと同じように、プロダクトマネージャーも、チームで要素を分担すればよいのである。プロダクトマネージャーがすべてを一人で背負い込むのではない。そして、プロダクトマネージャーにはそのチームをまとめ、リードすることが求められている。

　このチームのことを「プロダクトチーム」と呼ぶ。プロダクトチームにはプロダクトを作り上げるために必要な役割がすべてそろっている。例えば、ソフトウェア（IT）を主体とするプロダクトの場合には、（ソフトウェア）エンジニアやデザイナー、QA担当者などが中心となるが、マーケティングや広報、サポートなど、複数の組織からのメンバーにより構成される。

　そして、チームで開発を行うことはとても難しい。また、プロダクトマネージャーは一般的には人事権を持たないとされているためプロダクトチームのメンバーを選ぶことができないだろう。プロダクトマネージャーは、プロダクトの成功のためにどう振る舞うべきかを考えなければならないため、特に次の3点を意識する必要がある。

1. ビジョンを達成する「プロダクトの強い軸」を明確にすること
2. 誰が何に責任を持つのか、役割を整理して可視化すること
3. マイルストーンを可視化すること

　1つ目の「プロダクトの強い軸」はこの連載の第6回でも紹介したものだ。詳しくは第6回を再度お読みいただきたいが、このCore、Input、Outputのどれかだけでなく、すべてをチームに共有し、議論のベースとすることで、メンバー全員の意識が統一され、進む方向が定まる。プロダクトチームはプロダクトの成功のために組織化されたものなので、このプロダクトの強い軸はプロダクトチームにとっても軸となるものだ。

　2つ目の責任範囲の明確化について紹介しよう。チームメンバーの役割や責任範囲を明確にするには、社内であっても各職能のJob Description（職務記述書）を明確にするのが望ましい。もし、その職能の担当者を新しく採用する場合にはどのような採用要件で募集をするのかを記載することで、期待される役割の認識をそろえることができる。各メンバーがどのような職能を持ち、それを生かし、どのような役割を全うすることになっているのかをJob Descriptionは語っているはずだ。

　会社によっては全社員がジェネラリストとして特定の職種を志向していないこともあるかもしれないが、その場合にはその社員に求めるJob Descriptionとは別に、お互いの役割を明確化する目的で、担当職務のJob Descriptionを作成しよう。ジェネラリストとして採用されていても、そのチームにおいて期待される専門はあるはずだ。それをまずは明確にすることで、お互いの役割を可視化することができる。

　さらに、メンバーの責任分担を明確にするために、RACIという手法が存在する。これは、タスクごとに、実行責任者（Responsible）、説明責任者（Accountable）、協業先（Consulted）、報告先（Informed）を決めておく手法だ。一般的なアジャイル開発での役割分担を整理した場合、次の表のようなマトリックス表として整理することができる。

	PM	PjM	エンジニア	QA担当者
バックログの作成	R	A	C	I
工数見積	I	A	R	C
イテレーション（スプリント）計画	A	R	C	C
朝会の開催	A	R	C	C
個別工数見積	I	A	R	C
振り返り実施	A	R	C	C
テストプラン策定	I	A	C	R
ステークホルダーとの交渉	R	A	I	I
ロードマップとのすり合わせ	R	A	I	I

　このRACIにはいくつもの派生物があり、実行責任者（Responsible）に加えて、実際の作業担当を行うサポート（Support）を追加したものや、スクラム開発手法を用いる場合にスクラムマスターの役割を想定したファシリテーター（Facilitator）を追加したものなどがある。

　3つ目のマイルストーンの可視化も重要だ。チームを持つということは大小の差はあるが、メンバーに権限を委譲することでもある。意思決定が分散した状態で各々が正しい意思決定をするために、長期的な計画を知っておくことは必須である。ビジョンを達成するためにどのタイミングで何をしなければいけないのか、そして、どの順番で実施するのかを周知しておくことで、時間軸に沿った意思決定をすることができる。

　プロダクトのステージとフェーズのうち、プロダクトマネージャーが一度に見なければならない範囲はとても広い。なぜなら目の前のフェーズに取り掛かりながら、常にチームより一歩先の未来のことも考えなければならないからだ。しかしながら、プロダクトマネージャーだけが未来を見据えて物事を考え、他のメンバーは目の前の目標に集中しているのは健全だろうか。もちろん、プロダクトチームが目の前の目標に集中できる環境を整えることもプロダクトマネージャーの役割の1つではあるが、関わるチームメンバー全員がプロダクトの長期的な方針を念頭に置きながら動いている組織は、細部の意思決定にまで長期的な目標が反映される、とても強い組織だと言えるだろう。そのため、プロダクトチームが長期的な視点を持つ機会を提供することも必要だ。