プロダクトの「死の谷」を越えるため「組織の形」という視野をもって、プロダクトマネージャーの役割を考える

立ち上げたプロダクトが開発着手から2年、サービスインから1年経ちました。
PMF（プロダクトマーケットフィット）にはまだまだな状態ではありますが、徐々にその手応えは得られるプロダクトとしては成長するまでになってきました。
PM（プロダクトマネージャー）としては今が1番面白くも苦しい時期でもあったりします。まさに新規プロダクト開発における死の谷（デスバレー）の真っ只中です。


死の谷（デスバレー）とは、セールス段階に入ったプロダクトがさまざまなユーザーからの要望における課題に直面している状態です。この難所を乗り越えるには、ユーザー対応に向けて多角的な対応が必要となり全社的な協力体制で支援していく必要があると言われています。開発コストだけでなく、さまざまな人財資源としてのコストが一気に膨れ上がり、新規事業やスタートアップでは資金がショートしてしまうフェーズとなるため、このように呼ばれています。

組織の形をまずは知ろう

プロダクトが成長・拡大していくにつれてマーケティング、セールス、サクセス、サポート、プロダクト運用、、、、「必要な役割」はどんどん増えていきます。
その中で、PM（プロダクトマネージャー）チームでは、経営層に向けて開発チーム以外の面でも組織的な役割への提案をしていくことを行なっていました。「組織体制をこういう形ですすめたい」という話なのですが、平たくいうと「人手が足りません」ということですね。
プロダクトをサービスとして考えた場合に「どのような役割が必要で何をおこなってもらうか」を話し合っていましたが、経営陣からいただくフィードバックでは、毎回、同じセリフをいただいていたことをよく覚えています。

「組織の形をいくつ知っていますか？」

死の谷（デスバレー）の真っ只中にいる今だから、改めて、そのフィードバックを思い出しながら「組織の形」という視点でプロダクト開発がどういう組織体制だったのか振り返り、今の自分たちPM（プロダクトマネージャー）の役割を考えてみたいなと思います。

プロダクトの立ち上げ期は、マトリクス組織の中でのプロジェクトチーム

PLAN-Bの開発組織は、マトリックス組織の形態をとっています。
事業推進が目的となる各チームがある組織体制と、デザインや設計・開発といった職能別の組織体制です。

ざっくりとPLAN-Bでの開発体制を表すと以下の形でイメージができます。

SEARCH WRITEの開発は、この組織体制の中で、プロダクトマネジャー（PM）をプロジェクトリーダーとして１つのプロジェクト型のチーム構成をとりすすめていきました。

さて、このマトリクス組織ですが、プロジェクトを進めていく中では、この体制でのメリット・デメリットを経験することになりました。
そのメリット・デメリットを経験をもとに振り返ってみたいと思います。

マトリクス組織でおきるメリット

１：目標を統一した同じ方向を向きながらプロジェクトを進めることができる

私がプロジェクトリーダーとして意識したことは、「SEARCH WRITE」というプロダクトはいけるな！っていう感覚をチームで切らさないこと。
新しいプロダクトの立ち上げの頃は新鮮なのでどうしてもモチベーション高く仕事できたりしますが、やはり行き先は不安な新規事業。ローンチ直後でもどんどん新しい機能の開発は進んでいく中で、このまま進んで大丈夫かなという感覚はどうしても付きまとうものだと思います。
ですので、開発チームには、契約者数の推移・売上目標などの期待感をもってもらうようには意識していました。しっかりと売上と開発コストのバランスもみんなで共有しながら、「時間はかかりそうだがなんか行けそう感」をもってもらうこと、徐々に狙っている市場での存在価値を獲得できつつあるという実感をもってもらうことを特に意識してたかなと。
さらに、セールス側から届く声やサポートを自身でも対応したりとユーザーの反応を開発チームに伝えることも大事にしていました。

そのためには、自分が先頭に立ちながらプロジェクトを進めて１つの目標を追いかけていくというこの体制は非常にやりやすかったかと思います。
プロジェクトを成功させるためにいろんな職種別のメンバーを集めて１つのチームにするには、やはり共通の目標が必要です。
組織としては個人の能力アップや成長を推進してくれるので、個人の能力的な成長は意識せずに、プロダクトの成長にだけコミットできる。プロダクトマネージャーとしても非常にやりやすい形でした。

２：部署間での壁がなく、組織的な上下バイアスもかからない職能メンバーで新しい取り組みを試せる機動力がある

プロジェクトとしてまとまった形チームなので様々な調整は容易になりました。
良い意味でプロジェクトチームには「上下」という関係がないからです。 組織上の意思決定や評価、簡単にいうと「えらい・えらくない」がないフラットな形でプロジェクトを進めることができました。
プロダクトマネージャーだったとしても、デザイナー・エンジニアといったプロダクト開発チームの上司でもないフラットな関係です。 そういう関係なので、新しい取り組みはどんどんチャレンジしていきました。 ある意味、上司のお伺いを立てずに、勝手にできるというかなんというか（笑
取り組みの全てがうまくいったわけではないですが、積極的に進めていった結果、個々の能力・経験値がアップしながら開発チームとしても醸成されたように思います。
今でも、開発する中で行った取り組みは、最適化されながらも継続しており、PLAN-Bでの開発文化として定着していきました。

関連記事：
・先輩に本音を言えてますか？遠慮があったら始まらない「ドラッカー風エクササイズ」で作る良いチーム
・Metabaseを使って成果の可視化でチームの心を1つにしよう！ツール選定と実際の手順をご紹介！
・チームのふりかえりで大事なことを社内で発表した話
・Storybookを使ってプロダクトのデザイン管理をやってみた
・個人からチームへ。アジャイル開発への最初の半年間の取り組み

３：プロジェクト毎に人事異動や新規採用といったことがなく経営資源の効率が良い

1名の人が複数のプロジェクトへ同時にアサインされることも可能となるため、スポットでの職能がどうしても必要という場合や、この2ヶ月で一気に作ってリリースまで持っていきたいからエンジニアを増員したい！！といった柔軟さは非常にあります。
また全体的な状況を把握しながらのリソース調整となるためギリギリのリソース状況をどうまわしていくかの難易度はあがりますが、経営資源としてのリソースの無駄は限りなく少ない状態になります。

必要だから採用や異動をしてもらったにもかかわらず、デザイナーさんやエンジニアさんに対して継続的な仕事や成長の機会を与えることができなかったり、リソースに余力がある手前、「これは誰のための機能？」といった少し無駄になってしまう開発が増えるといった点は、最小限におさえられるのではないでしょうか。

「事業部制組織」でおきる、あっちの部署にもデザイナーさん、こっちの部署にもデザイナーさんという点での「ヒト」であったり、別々の部署で全く同じような開発をすすめてしまったりする「モノ」の重複、そして労務費といった「カネ」という、経営資源としての組織上での無駄がおきにくく、経営効率が良い点も大きなメリットです。

マトリクス組織でおきるデメリット

１：組織体制としては2つの指示系統が存在してしまう形となる

マトリクス型の最大のデメリットは、縦と横の組織が存在する形のために、組織上のマネージャーとプロジェクトを推進するマネージャーのどちらの意思決定に従っていくべきか、チームメンバーは混乱する場合が生まれてしまうという点です。
またメンバーをどのように評価していくのかも、検討が必要なところです。

PLAN-Bでは、能力的な向上を職能型組織側が評価し、数字面やリリースに対するプロダクト側へのインパクトを事業側組織が評価するというクロスの評価を設計していくことで解消しました。

またプロジェクトチーム内でもフラットな関係な手前、意志決定に時間がかかってしまう場合もあります。
フラットさは時に「権限と責任」が曖昧になりがちなのです。
「職種別組織」の意思決定を重要視すると慎重・丁寧さを優先するあまりにどうしてもスピードがでなくなってしまったり、「事業推進」を重視すると見た目上は動いているがメンテナンスにすごく時間がかかってしまうプロダクトになってしまったり、この辺りのバランス感覚を持ちながら意思決定をする際には、誰が決めるの？っていうことになりがちだったのです。

この点を解消するには両組織のマネージャーの「権限と責任」の明確化を行う必要があります。
さらにはプロジェクトチーム内での「権限と責任」を明確にする方がより重要です。
「意思決定」のお見合い状態で物事が進まないことを避けるためには、結局はコミュニケーションなのですが、「RACIチャート」を用いながら役割を話し合うことで解消していきました。

関連記事：
個人からチームへ。アジャイル開発への最初の半年間の取り組み

ここ最近では、両マネージャーにてフラットに話す場を設けて、週に1回の「1on1」を行い、情報交換やお互いの考え方などをしっかり伝え合うことも行なっていたりします。

２：リソース配分の調整が難航する

複数のプロジェクトが同時進行していく中で、ヒト・モノ・カネの配分、プロダクト開発ではほとんどが「ヒト＝リソース」となりますが、その分配をどのように進めていくべきかは大きな課題です。
「職種別組織」では、1人1人の能力と経験値をあげるためにローテーションの形でプロジェクトを進めていきたいですが、「事業を推進する側」としてはなるべく固定メンバーで事業の理解を深めてもらいプロジェクトチームを醸成していきたい思いが強いです。

このバランスは本当に何が正解というわけでもないのですが、実際の組織戦略（全員が成長のフェーズなのか、ある程度の自走できる状態なのかという点）や、どのプロジェクトをブーストしていくべきなのか、企業自体の事業戦略にも大きく影響するため経営判断として行なっていくという視点で調整をすべきだと思います。

プロジェクトごとでのコミュニケーションを増やしてなんとか調整する的なこともありますが、リソースの分配状況を経営層としっかりとコミュニケーションを行うことが重要と考えています。ヒト・モノ・カネを、会社視点で考えると経営資源として、どのように投資していくのかということになります。

• どのプロジェクトに何名ぐらいがアサインされているか
• コストがどれぐらいかかっているのか

この点を中心に経営側につたえることがなによりも大事です。プロダクトマネージャーの役割としても重要ですよね。
もちろん、それでもなんとかしてって言われるのも、これまた経営視点からのフィードバックということも多々あります。
そんな経験をしたことが多い方も世の中にたくさんいらっしゃるのではないでしょうか（笑

３：プロジェクトリーダーに組織上の役割ではない負荷がかかってしまう

マトリクス組織にもさらに３つの型があります。ウィーク型（各自の責任のもと自らが判断して進める）、バランス型（プロジェクトチームから責任者おいて進める）、ストロング型（組織内にプロジェクトマネジメントに特化した部門をつくり専任をおく）という３つの型です。

SEARCH WRITEの開発では、ストロング型にてプロダクトマネージャー（PM）の組織がマネジメントの役目を担いました。
プロダクトのWhy（なぜ）→Who（だれに）→What（なにを）を考えるため、明確にプロジェクトチームへの意思決定を伝える役割でもありますので、プロジェクトリーダーとしては適任ではないでしょうか。

その代わりに負荷は大きくなります。
プロダクト自体の成功への責任を担うことになりますので、責任は重たいですよね。
（ステイクホルダーとの調整や各所での意思決定、メンバーモチベーション、プロダクトコンセプトの体現、UX視点の構築、セールス側との調整、ユーザーサポート、あげればキリなさそうですね、、）

この辺りはプロダクトマネジャーとしての責任と役割にもマッチする部分ではありますが、そこをやり切るためのスキルセットの話などはこちらの記事も参考にしていただければと思います。

関連記事：
プロダクトマネージャー（PM）のチーム立ち上げ時に参考となった考えや実務を行う上での必要なスキルセットについて

いよいよ「死の谷」に突入。本格的に事業として進めていくフェーズへ

これまでは開発組織でプロダクトを作ることにフォーカスしていましたが、次はいよいよ「０→１０」「１０→１００」というプロダクトが事業として成長していく際での話になります。

まず大きな変化としては開発組織側の職能別組織から「運用」チームを事業推進側に組織化してチームの目的を変化させました。
SEARCH WRITEはSaaSビジネスですので、どうしてもユーザーへのテクニカル面のサポートも必要になってきます。
またプロダクトがしっかりと稼働できているかどうかの状態も把握しながらのサポートとなりますので、「システム運用」のチームから「プロダクトオペレーション」というチームを立ち上げました。

次にプロダクトを販売し、サービスとして運用していく事業側の側面にも変化がありました。

PLAN-Bの事業はデジタルマーケティング市場においての代理事業を主幹事業としている会社です。既存のビジネスモデルを事業として行いながらも、1年ほどをかけて「マーケ」「インサイドセールス」「サクセス」というプロダクトまわりへの役割を増やしていき、いよいよSEARCH WRITEというプロダクトを事業として推進していく体制になっていきました。
最終的には、各役割のチームを1つの形に集約した組織が「事業部制組織」として再編されました。

さて、ここまでくるといよいよ「死の谷（デスバレー）」を越える準備・体制はととのったのです。プロダクトのフェーズをより加速し、この難所を乗り越えていくには、「事業部制組織」と「マトリクス組織」の両輪でプロダクトを成長させていくことが必要になってきます。
そこで両組織が強い関係でプロダクトを前に進めるには、やはり結節点が重要です。この点でも開発組織の「マトリクス組織」が生きてくる形で機能していくようになります。 事業部側へも横軸で推進とサポートを行なっていくことができるからです。

PM（プロダクトマネージャー）は事業部長と事業戦略・プロダクト戦略の一体化を進めることができ、オペレーションチームはカスタマーサクセスとサポート面でのユーザー情報の共有や運用を進め、PMO（プロジェクトマネジメントオフィス）とData &IP（データ駆動担当）はマーケやセールスへのデータマネジメントの体制構築を支援していくという形です。

PLAN-Bでは、今まさにこの組織体制でいよいよ「死の谷」を越えることにチャレンジしています。
その中では、マトリクス組織でのメリット・デメリットが起きる場合もありますが、開発中で得た経験をもとに、その課題は最小限で進めていければと思っています。

さいごに

今回はPLAN-Bでのプロダクト開発を組織体制の視点で振り返ってみました。

今回は紹介しておりませんが、上下関係がなく意思決定権が分散され各メンバー自身が自身の責任で進めていく「ホラクラシー組織」や、組織フェーズを5段階の色として分けて１つの組織を生命体として扱う「ティール組織」などは、最近注目されているので、組織の形としては話題にあがることがあるのではないでしょうか。

組織の形にどれが正解だということはないと言われます。

その都度でおきる組織課題をどういうフォーメーションで解消していくのかによって最適なものを選択すれば良いからです。
組織の話をすると、今の組織体制は古い、動きにくいなんて話が起こりがちですが、１つ言えるのは経営視点での戦略がどのように切られているのかを意識すること、またどのような組織的な課題があるのかを意識すること。
その上で、今回のような「組織の形のインプットとアウトプット」をしてみると、考え方やまた少し違った見え方ができるのかもしれません。

「みなさんは、組織の形をいくつ知っているでしょうか？」

新規事業での「死の谷」を越えるために、組織という視点・コストという視点・開発という視点、いろいろな視点とそして広い視野をもって取り組んでいければとおもいます。
この難局を超えると、次はいよいよ「ダーウィンの海」がまちかまえます。
さー楽しくなってきましたね。