プロダクトマネージャーの所属する組織パターンを整理してみる

## この記事は何
僕は普段Qiitaのプロダクトマネジメントを行なっています。
周りの方に聞いていると、プロダクトマネージャーのポジションだったり組織での立ち位置などが状況によって結構違いそうです。
そこで、この記事では改めてプロダクトマネージャーの所属する組織パターンについて整理、考察をしてみようと思います。

:::note warn
この記事の中では「この形がベストだと思う」みたいな主張はしません。
組織のあり方は事業のフェーズや状況によって変わるものだと思うので、あくまで「こういうパターンもあるんだな」くらいの認識で読んでもらえるとありがたいです。
:::

## 組織パターンを考える上での観点
プロダクトマネージャーの所属する組織パターンを考察する上で重要になる観点は「パワーバランス」だと思っています。
権限がなさすぎても、逆に特定の領域の権限のみ強すぎてもプロダクトマネジメントを推し進めていく上ではリスクになる可能性があります。
この後紹介していく組織パターンでは、それぞれの体制だとどのようなメリットがあり、パワーバランスの観点でどのような気をつけた方が良さそうな点があるかをまとめていきます。

## 組織パターン
組織パターンのメリットデメリットをそれぞれ考察していきます。
なお、今回は組織のイメージを考える上で考察をシンプルにするため、事業は一つの場合を考えています。
実際には複数のプロダクトを扱ったり、組織の体制として職能別組織か事業部制組織かなどでよりパターンは枝分かれしていくと思います。

### プロダクトマネージャーがプロダクト開発組織の総括を兼任する

#### 組織イメージ
プロダクトマネージャーがプロダクト開発組織の総括を兼任するパターンです。
プロダクトマネージャーがプロダクトの成長に対してのコミットメントを行う、という役割と捉えると、わりかし想像しやすいパターンなんじゃないかと思います。
図にすると以下のようなイメージです。

```mermaid
graph TD
    B[エンジニア] --> BB[エンジニアリンググループ]
    BR[エンジニアリンググループリーダー] --> BB
    C[デザイナー] --> CC[デザイングループ]
    CR[デザイングループリーダー] --> CC
    BB --> AA[プロダクト開発部]
    A[プロダクトマネージャー] --> AA
    CC --> AA
```

#### メリット
メリットとしては以下のような部分があるかなと考えています。

- 職能として誰がプロダクトマネジメントをしているかがわかりやすい
- 特定の職能組織に属さないため、判断やアクションにバイアスがかかりにくい
- プロダクト開発統括として、各組織連携した取り組みを行いやすい

#### 気をつけたほうが良さそうな点

- 各組織のメンバーとのコミュニケーションが疎になる可能性がある
    - 例
        - 各組織のリーダーとは話せているが、メンバーには意図が伝わらない状態でプロダクト開発が進んでしまう
- 複数の組織の連携をうまく回しながらプロダクトづくりを行う必要があるため、シンプルなマネジメントの難易度が高い
    - 各組織のリーダーの能力や信頼関係によってプロダクト作りのスムーズさが大きく変わってくる

### 特定の組織のリーダーがプロダクトマネージャーを兼任する
前項はプロダクトマネージャーがプロダクト開発統括という形で独立した形でしたが、次は組織のリーダーがプロダクトマネージャーを兼任するパターンを考えてみます。
組織として「プロダクトマネジメントをやっていこう」となった時にスタートとしてこのパターンになる場合も多いと思います。

図にすると以下のようなイメージです。

```mermaid
graph TD
    B[エンジニア] --> BB[エンジニアリンググループ]
    BR[エンジニアリンググループリーダー（プロダクトマネージャー兼任）] --> BB
    C[デザイナー] --> CC[デザイングループ]
    CR[デザイングループリーダー] --> CC
```

#### メリット
メリットとしては以下のような部分があるかなと考えています。

- メンバーのマネジメントとプロダクトマネジメントを兼任することで、チーム全体の動きがコントロールしやすい
    - 例
        - プロダクトマネジメントの取り組みにメンバーを巻き込む
        - プロダクトマネジメントの思考で議論する
- メンバーのプロダクト理解度を高められやすい

#### 気をつけたほうが良さそうな点

- プロダクトマネジメントにバイアスがかかる可能性がある
    - 例えばエンジニア組織のリーダーがプロダクトマネジメントをすると、技術頼りのソリューションになりやすい、など
- その他の組織との連携はまた一工夫必要になる
    - どのように他組織のメンバーをプロダクトマネジメントに巻き込むか
    - どのように他組織のメンバーのプロダクトの理解度を高めていくか
    - どのように開発するものの連携をしていくか
    - etc

### 複数の組織のリーダーがプロダクトマネージャーを兼任する
最後は複数の組織のリーダーがプロダクトマネージャーを兼任するパターンです。
前項はプロダクトマネージャーが一人だったのに対し、各組織のリーダーがプロダクトマネージャーも兼任し、それぞれが連携しながら各組織でプロダクトマネジメント進めていくパターンです。
現在のQiitaもこれに近いパターンで現在プロダクトマネジメントを行なっています。

図にすると以下のようなイメージです。

```mermaid
graph TD
    B[エンジニア] --> BB[エンジニアリンググループ]
    BR[エンジニアリンググループリーダー（プロダクトマネージャー兼任）] --> BB
    C[デザイナー] --> CC[デザイングループ]
    CR[デザイングループリーダー（プロダクトマネージャー兼任）] --> CC
```

#### メリット
メリットとしては以下のような部分があるかなと考えています。

- 前項の懸念点だった「他組織との連携」部分の課題が解決される
    - どの組織もプロダクト思考を持って開発を進めやすくなる
- 特定の組織の人間による知識バイアスの課題も防ぎやすい

#### 気をつけたほうが良さそうな点

- プロダクトマネジメントのスピードが落ちる可能性がある
    - 各組織のプロダクトマネージャーが連携・調整しながらアクションを決めていくことになるので、そこの連携が悪いと各組織の動きが悪くなる
- 各組織で取り組んだことのナレッジの共有
    - 各組織が得た学びなどをうまく共有し、全体知識化していかないと情報の非対称性が生まれる

## 終わりに
今回は三つの組織パターンについて考えてみました。
プロダクトマネジメントはプラクティスは色々あるものの、ベストプラクティスと呼べるほどの正解はなかなか存在しないことが多いと思っています。
組織パターンもベストプラクティスが存在しないものの一つなんじゃないかなと感じています。
同じ会社、プロダクトでもフェーズが変わればフィットするやり方も変わります。
ぜひ「うちはこんな感じでプロダクトマネージャーが組織に関わっているよ」という知見があれば教えていただけると嬉しいです。