プロダクトマネジメントの「モード」のズレによって起こる負の連鎖

このところ、いくつかのSaasのプロダクトマネジメントに関わっていますが、サービスの内容を問わず、共通する問題があります。それは、「PdM、営業、CS、開発」 （マーケティングが入ることもある）という、各業務単位の認識やモード（気分）のズレによって、プロダクトマネジメントのツジツマが合わなくなり、チームが疲弊したり、単位間の関係が悪くなってしまったりするというものです。この認識やモード（気分）のズレによって起こる問題を、ドラゴンクエストとサッカーを例にとって考えてみました。

モードとは

モードという言葉を、ここでは「作戦というほど緻密には考えていない気分」という意味で使うことを了承ください。気分には「こうしたい」という希望を内包しており、それはいっしょに働く他者、チームメンバーへの顕在・潜在的な要求となって現れます。このモードにはいくつか種類があり、その種類を説明するためにドラゴンクエストの言葉を借りることにします。

ドラゴンクエストには、「作戦コマンド」という、仲間の行動をコンピューターに任せることのできる機能があります。作戦コマンドには以下のような種類があります。

• ガンガンいこうぜ

• いろいろやろうぜ

• バッチリがんばれ

• じゅもんつかうな

• いのちだいじに

• テンションためろ

• おれにまかせろ

各コマンドの詳細を伝えることはこのnoteの趣旨ではないので、詳細はこちらの記事をご覧頂くとして、あくまでプロダクトマネジメントにおけるモードを説明するための道具とします。

プロダクトマネジメントにおける業務単位間のモードのズレと意味をドラゴンクエストのコマンドを使って説明すると、例えばこんな感じになります。

PdMが「いろいろやろうぜ」。営業とCSが「ガンガンいこうぜ」。開発は「いのちだいじに」というふうに業務単位間でズレている、とします。それぞれの意味は、「いろいろやろうぜ」は、「自社サービスがハマる色んな業界をあたる。色んなニーズに対応する」。 「ガンガンいこうぜ」は営業なら「機能開発を条件に受注」し、CSなら「機能開発を条件に契約更新」する。「いのちだいじに」は「保守運用に力を入れる」といった意味になります。このあたりの意味は色々な解釈が成り立って面白いですが、それもこのnoteの本題ではないので、先に進みます。

ドラゴンクエストではプレイヤーが作戦コマンドを決定すれば、パーティの仲間がそのコマンド内容に合わせて振舞ってくれますが、現実のプロダクトマネジメントのメンバーはコンピューターではない生身の人間です。生身の人間は、一人一人がモードを持っています。PdMがプレイヤーだったとしても、PdMが望むようには考え、動いてくれません。

このモードのズレとそれによって起こる問題をプ譜を使って図解してみます。ここで取り上げるのは架空のSaasを提供する組織であり、リソースは潤沢ではないが、 「シード期で、PMFはまだ見つかっていないものの、色々な業界、業務にプロダクトが活用されている」状況にあると仮定します。

モードのズレによる負の連鎖

PdMのモードは「バッチリがんばれ」。これはドラクエでは「攻撃と守備をバランスよく行う作戦です。ニュアンスとしては「各自最善と思われる行動を取れ」ですが、悪く言えばあいまいです。方針の徹底をしていません。
このあいまいさが影響して、営業は「がんがんいこーぜ」モードで、自社プロダクトにまだない機能開発を条件に色々な業界から受注してきます。この行動はCSや開発に影響を与えます。その機能を開発しないと、自社プロダクトが顧客の課題解決にフィットしなかったり、顧客の業務フローに組み込まれにくかったりすると、所定の契約期間内で成果を出すことができない可能性が高くなります。そうすると契約更新が危ぶまれす。成果が出ていないなか、契約更新してもらうためにさらなる機能開発を条件に更新しようとしたり、特別な見積を出したりします。
こうした開発を条件にした「ガンガンいこうぜ受注」が増えると、開発リストがどんどん増えていきます。Saasとしてどんなインパクトを社会に与えたいかとか、そのSaasを使うユーザーの業務がどのようにあるべきかといった“遠い”プロダクトビジョンは蜃気楼のようにおぼろげになり、金額の大きい顧客から対応するとか、契約更新時期が近い顧客から対応するといった目下の“近い”状況に対応することになってしまいます。開発チームはメニューにない新しい料理を開発するシェフよろしく、よくよく素材を吟味したり、調理法を研究したり、味見をする余裕のないまま、それなりの料理＝機能をリリースします。
しかしそのようにリリースし、顧客に提供した機能はバグ・不具合が必ず出る。営業やCSの顧客要望のヒアリングや顧客の業務・事情の理解が不十分だったり、要望の整理と合意ができていなかったりするせいで、顧客から「社内リリースしたけど、この部署からもっとこうしてほしいという要望が出てきた」という新しい要望が出てきます。そうした不具合や新しい要望をCSが対応する場合、CSの時間をサクセスではなくサポートに割くことしかできなくなる。このときのモードはさしずめ「おれにまかせろ（敵にダメージを与える行動を一切取らなくなり、防御や回復呪文、補助呪文などでサポートに回る）といったところでしょう。
CS自身が経験していいない問合せは、顧客側で起きている事象への理解・共感が不足しており問題への対応を難しくさせます。問題の把握に時間がかかったり、自分で問題の事象を確かめるといったことをしていると、どんどん認知負荷が高まっていきます。これはドラクエでいけばHP（体力）ではなくMPに相当するものと思いますが、これが減っていくと、一回確認すればいいことでも、「あれも聞いておけばよかった」などと思い出して、二回三回と余計なやり取りを顧客と重ねたりすることになります。また、普段なら問題の事象について詳しく顧客にヒアリングした上で開発に質問することを、少なく浅い情報だけで開発に質問を投げてしまうといったことをしてしまいます。これは開発に悪い影響を与えます。開発は少ない情報で問題を特定せねばならず、開発からCSに対して顧客に確認してほしいことを再度依頼するといった、コミュニケーションコストが増えていきます。このように「十分にテスト・シミュレーションしていれば起きなかった（かもしれない）問題」が増えていくと、CS・開発の仕事の品質が落ちていきます。

こうしたズレによって起こる問題を未然に防ぐのがPdMの仕事です。続けてその方法について書きたいのですが、架空のSaasを題材に書くには私の経験・筆力が足りないのと、単に1996年アトランタ五輪サッカー日本代表を題材にしたいので、続きは下記よりご覧下さい。

なお、プロダクトマネジメントの組織づくり、分業体制のあり方は、プ譜を使うと考えやすいので、よろしければ参考にしてください。