思考の縁

プロダクトマネジャーはミニCEOではないが、そう思うことが大切だ

仕事として「PM」という略語を見ると何を思い浮かべるだろうか。 恐らく伝統的な企業に在籍している方はプロジェクトマネジャーだと思うだろうし、Webやスタートアップの経験がある方はプロダクトマネジャーしか思い浮かばないだろう。

プロジェクトマネジャーをPMと呼ぶ組織では、プロダクトマネジャーのことをPdMと略す。 一方、そうでない組織では、プロジェクトマネジャーの方をPjMと略す傾向にある。

さて、私が富士通に入社した2003年当時、PMと言えばプロジェクトマネジャーを意味していた。IT業界では、受託開発のリーダーとしてプロジェクトの計画から課題解決、稼働の責任を負う立場である。ある意味で、SE職が目指すキャリアの先にあるものだった。

一方、私が配属された部署では、完全な受託でなく、特定の市場に特化したERPプロダクトの開発をしていた。サービスの一環として受託もするのだが、中心にあったのはプロダクトであるアプリケーション開発だった。その投資回収プランを策定して企画としてまとめ、計画を立てて開発し、そのメンテナンスやエンハンスを行う職場だった。開発だけでなく、プロモーションや商談対応も行っていた。

これらの仕事をひっくるめて「アプリケーション開発SE」という名前がついていたのだが、今考えても随分幅広い仕事だった。現代でいうプロダクトマネジャーとプリセールスを組み合わせたような仕事だった。

担当していたプロダクトは市場で黎明期にあり、私のような若手にもプロダクトマネジャーをするチャンスがあった。これは今考えても幸運なことで、新卒3年目には先輩から引き継いでプロダクトマネジャーとなり、その1年後には並行してプリセールスを行うようになった。

ただし、そうした時期というのは開発リソースが不足するものであり、開発規模に比べて実にコンパクトなチームだった。

あるとき、有力なパートナー企業と提携したことがあった。開発力と販売力を備えた会社だったのだが、開発元に「ものを言う」ことで知られていた会社だった。案の定、初回のミーティングから要望の嵐で防戦一方となっていたのだが、オフィスにお連れして私のチームを紹介したら「こんな人数でやっているのですか……」と絶句されたのを憶えている。

bearblog (1)

プロダクトマネジャーの仕事は多彩で、単に開発をマネジメントするという言葉からは想像できない部分が多い。そして最も重要な点は、受託開発のPMとは全く異なるスキルやマインドセットを必要とすることだ。

私がその職を手放したとき、この仕事を引き継ぐであろう誰かに向けて次のようなメモを渡した。

プロダクトマネジャーに求められる役割は、単に技術力があるとか、業務を知っているとか、チームをマネジメントできるというものではない。一言で言えば、担当するプロダクトのビジネスそのものを背負う責務を負うのである。

そのメモは手元にないので思い出しながら書いてみたが、今でもそれをはっきりと覚えている。プロダクトマネジャーとして色濃い経験をした5年間を凝縮した言葉だったからだ。

会社からみれば管理職でもない一般社員だったが、そのくらい入れ込んでいた仕事だった。ただ、私だけでなく、同じフロアにいたプロダクトマネジャーは、皆このようなマインドを持っていたように思う。

プロダクトの売上・粗利はもとより、投資に対する回収の責任を負う。そして何より、プロダクトを利用いただいている顧客が安定して利用できるように日々活動し、その上でまだ見ぬ顧客を開発するために頭を絞る。

この仕事をすると、必然的にマーケティングや管理会計の勉強をすることになるし、投資回収を考える上でファイナンスのロジックも知らなくてはならない。その上で、プロダクトの技術と業務ドメインの両方に精通している必要がある。PEST的な観点で世の中の動向を見て一手先を打つことも求められる。

まさにミニCEOのような仕事だ。

しかし、一般にプロダクトマネジャーをミニCEOというべきではないという風潮がある。 その理由は、プロダクトマネジャーはメンバーに対する人事権や、予算の執行権限を持たないことに由来している。

多くの場合、プロダクトマネジャーは非管理職であり、チームメンバーの上司ではない。

こういうと「リーダーがチームをマネジメントするのと何が違うの」という質問をいただいたことがあるが、その差は歴然としている。これはプロジェクトマネジャーでも同じことだ。

管理職たるミドルマネジャーの責務は自分が管理しているチーム全体で成果を上げることだ。それを達成する上で、プロダクトの開発は部分にすぎない。人を雇い、育て、エンゲージメントを高める必要があるし、会社内からの様々な政治的な圧力と戦いながら予算を確保する仕事もある。

プロダクトマネジャーのタスクにもその片鱗があるが、それは部長やマネジャーがいろいろと調整した後の何かを見ているというのが正確なところだろう。

プロダクトマネジャーには、CEOのように命令する権限ではなく、他者を動かす影響力が求められる。あるいは、そうした権限を持たない中でチームをまとめあげて成果を出すことが期待されるのである。

したがって、プロダクトマネジャーは厳密に言えばミニCEOではない。自らを組織のボスと考えて振る舞うと痛い目にあうことになるだろう。

しかし、それでもなお、私はプロダクトマネジャーはミニCEOの視点とマインドを持つことが大切だと考えている。

それは、プロダクトマネジャーはプロダクトが顧客価値を生み、かつ事業として成立することに責任を持つからだ。顧客価値と事業性の両方に目を向けるというのは、経営者に求められる基本的な観点だと思う。

例えば、顧客価値だけに目を向けて事業性に関心がないというのはどういう状態だろう。

お客様の言うことが正しいと考えてできない企画を立ててしまう、あるいは、収益性を考えないで売れる値付けをしてしまう、ということがありそうだ。

また、プロダクトマネジャーがプロダクトでなくプロジェクト的な視点を強く持つのもよくないことがある。

例えば、ある大口顧客からの個別性の高い要望を取り入れてプロダクトを改善したとしよう。それが市場全体のことを考えて意思決定していればよいが、そうでなく「顧客要望は絶対」というSI的なマインドで決めていたらどうなるか。

もしそれが市場全体にとってよい要望対応であればいいが、そうでないなら他の顧客やこれからの顧客にとって無用どころかマイナスになるかもしれない。

上にあげた悩ましい問題に対処するには、プロダクトマネジャーが顧客価値と事業の両方に責任をもっていなくてはならない。そして、開発リソースは有限であり、何かをやるなら何かを捨てる意思決定をしなくてはならないのだ。

この意思決定をまず自分自身でできるかどうかが、プロダクトマネジャーの力量を測るものとなるだろう。

手元のリソースで今何をやるか。今はできないが次の四半期でやるとしたらどの開発をするか。あるいは、ビジネスの規模を今の5倍にするとしたら市場のどの部分にリーチすべきなのか。そもそも、今私たちはキャズムを超えられているのか――。

では、この悩ましくもやりがいのある意思決定には何が必要になるのだろう。

ここで、私が初めて意思決定したときの場面を思い出してみたい。

それは要望でなく障害対応のプランニングだった。 私がプロダクトマネジャーになった時、開発リソースではとても足りない量のタスクを抱えることになった。当然ながら日々火事場にいるような状態で、火を消しながら延焼を防ぐ必要があった。

このようなときにFIFO（First In, First Out）で対応していたのではよくないことになる。といっても、重要というラベルの付いたタスクは山のようにあり、簡単に優先度を付けられない。なので、自分の中で判断基準を作った。それはこういうものだ。

これは頭の中にあったものを思い出しながら言語化したものだ。どうだろうか。読んでみればコンサバなごく普通のやり方に見える。

しかし、これを貫くのはとても勇気がいるものだ。

なぜなら、落ち着くまですべての要望を「切る」などドライな対応だったからだ。この対象には組織活動のアレコレも含まれており、オフィスの中で浮いていたことは否めない。

しかし、火事場には火事場の対応が必要だというポリシーを貫き、野武士のようなチームで日々立ち回っていた。残業は常態化し、ランチの時間も惜しく、トイレやコーヒーを買うときにはフロアを速足で進んでいた。

帰宅してからもずっと頭の中で計画や設計をしていて、シャワーを浴びながら思いついたことを後から手帳にメモしたことも数知れない。

このようなワークスタイルだったので、当時の私は今の姿からは想像できないくらい組織内では攻撃的だったと思う。当時の上司たちは、こうした状況や私の意図することをくみ取って辛抱強く見守ってくれていた。本当にありがたい話だ。

この時期に考えていたのは「どうやって問題を解決し、顧客に迷惑をかけないで済むか」という一点だった。

受け取ったバトンの重さと責任を感じてのことだったが、そういうマインドを育てたのは上司だった。私が右往左往したり、トラブルでしょげたりするたびに

お前はどうしたい？
俺たちはプロダクトを背負ってるんだよ。
君がどのような思いをプロダクトに入れるかだよ。

という言葉があった。そのたびに自分はどのようなプロダクトを世に送りたいのかを考えることになった。

あるとき、残業をし過ぎて上級幹部に呼び出されたことがあった。健康を心配されての面談だったが、元気だったのでその時間も惜しいと思っていたほどだった。

その場では、その幹部の方が私の置かれた状況や仕事のことを丁寧に聴いてくださったのだが、その最後にこのような助言があった。

大変な状況なのはわかった。
でも、お客様や現場のSEはもっと大変だということだね。
君はこのビジネスを最後まで見た方がいいだろう。
最後までやってみなさい。

私は生涯この短いやり取りを忘れることはないだろう。

自分がリアルなプロダクトマネジャーになったのは、この瞬間だと思っている。

つまり、プロダクトマネジャーへの第一の道は、そのプロダクトの価値とビジネスの両方の責任を、自分自身の問題として引き受けることなのだと思う。

こうして、プロダクトマネジャーとして腹をくくり直してみると、自分の視野がいかに狭かったかに気づかされた。問題解決にばかり目を向けていたからだ。価値を作ることにシフトする時期だった。

とはいえ、決意を固めたからといって、問題がなくなるわけでも急にリソースが増えるわけでもない。

そこで考えたのは「数少ない開発機会に、将来を先取りした機能を入れる」という作戦だった。そのプロダクトが対象としている業務課題や、それを取り巻く市場の変化を常に考えてネタをためておき、隙間ができたときに一気呵成にねじ込むというもの。

これをやるためには何を「先取りした機能」とするかを考える必要があるが、正直にいって自分の頭で考えてもわからなかった。かといって、オフィスのフロアには、このプロダクトの将来を語れる人はいなかった。コトラーのマーケティングを読んでも、当時の私にはBtoBの業務アプリケーションにうまく引き寄せて考えることができず、堂々巡りに陥った。

このように悶々としていたころに、プリセールス活動が始まった。開発しているプロダクトのプロモーションや商談に同行し、顧客課題とのフィッティングを行う仕事である。

こうした活動をしていると、同じ市場の潜在顧客でも関心の置き所が違うことに気づく。また、自分の説明が刺さらないことも多くあった。

こうしたギャップを抱えて、あるベテランSEと会話したときに、こんなコメントをいただいた。

業務効率化だけじゃなくてさ。
いかにして労務管理を達成するかみたいな、マネジメントの視点もいるんじゃないの？
ERPって電子化とか効率だけで買うとは限らないよ。

これは目から鱗だった。それまでの私は、このプロダクトの価値を「手作業をシステム化し、業務を効率化すること」としか捉えていなかったからだ。

そこから、日々考えることがこのように変わった。

こうした問いをもってプリセールスの現場に行くと、違った風景が見えてきた。また、パートナー企業や現場SE、開発メンバーとの会話に「次の一手につながる兆し」があることにも気づいた。

そのようにして、二つの方向性を考えた。

まず考えたのはUXの改善だった。それは機能をメニューから選ぶ仕組みでなく、日常的に業務で使っているところから自然に選択できる体験の開発だ。これは今のSaaSやプロダクトでは当たり前の話だろう。

そして、もう一つ取り組んだのは、統計的な視点でデータを活かすことだった。ある顧客がExcelでデータを集計しているという話を耳にし、システムに溜まったデータを使って付加価値を付けるアイデアを思い付いた。まだ世の中にビッグデータという言葉もなく、ビジネスに機械学習が入り込んでいない時代だったが、これは重要になると直観した。

これらのアイデアは、当時の市場環境の中では語られていないことだったし、手持ちのバックログにも入っていなかった。

しかし、数年先を見据え、ここで出てきたアイデアの一部を実行した。それは実に勇気のいる意思決定だったが、少なくとも、その後の市場の変化を見る限り、方向として大きく外してはいなかったと思う。

何より、そういった前向きな施策に取り組めたことで、自分も含めてチームのモチベーションも高まることとなった。限られた権限とリソースの中で、顧客価値を生みながらチームの向かう方向を変えていく。振り返ってみると、これもまた経営の一部なのだと思う。

プロダクトマネジャーは厳密にはミニCEOではない。人を雇う権限も、会社の資本を自由に動かす権限もないからだ。

しかし、CEOとプロダクトマネジャーでは持っている権限や手段は違っても、向き合う問いには重なるところがある。

顧客にどのような価値を届けるのか。それをどうやって事業として持続させるのか。

限られたリソースをどこに使い、何をやらないのか。

今プロダクトを利用していただいている顧客と、まだ見ぬ将来の顧客のために何ができるのか。

その競争環境は何の影響を受け、どう変わっていくのか。

プロダクトマネジャーは、こうした問いに自分で答え、自ら試し、軌道修正しながらキャズムを乗り越えていく。その意味で、プロダクトマネジャーは、ミニCEOのマインドを持つべきだ。