HOME (Archive) > 重量級プロダクトマネージャー
« Microsoft の『Bing』、早くも問題点が浮上 | ネイバージャパン、新検索サービス「NAVER」を6月15日に限定公開 »
« Microsoft の『Bing』、早くも問題点が浮上 | ネイバージャパン、新検索サービス「NAVER」を6月15日に限定公開 »
June 06, 2009
重量級プロダクトマネージャー
なんかいろいろ思うことがあるのでビジネス論というか、自己流だけどちょっと書いてみようと思う。元ネタはプロダクトマネジャーの道具箱より。
ひところ自分の仕事の説明が、特に業界関係じゃない人にはわかりにくいので「企画です」とか「開発です」という言葉をよく使ってました。
でも本業はプロダクトマネージャーだと思ってます。
じゃあプロダクトマネージャーってなに?って言われると結構難しいんですよね。特にインターネット(広告)業界だったりすると。
あくまで自分流の解釈ですが、プロダクトマネージャー(以下PM)っていわゆる自分の担当商品に対してはある意味で王様だと思ってます。
元ネタの文章を借りると
これに対して、自動車業界では、藤本先生たちが、日本企業の競争優位源泉だと指摘している重量級プロダクトマネジャー(重量級プロジェクトマネジャー)という制度がある。この制度は基本的にはコンセプトプロポーザルから開発後のマーケティングにまでをプロダクトマネジメントの範囲とし、1人のプロダクトマネジャーがレスポンシビリティを持つ。
この認識が一番強いです。
まずコンセプトプロポーザルを固めるために市場調査を行う。ここでいう市場とは社内のプロセスとかそういうものも含めて考えてください。要は何が必要とされるか、何を作れば売れるか、というアイデアを固めること。
この場合市場調査を行っていろいろな数字や意見が出てくるでしょうが、当然の如くすべてがすべて同じ意見でないことの方が多いわけです。自社の営業チーム内でも現場営業同士意見が違うこと、あるでしょ?
そういうときに必要なことが絶対的な業界知識。競合の状況、自社の状況、技術のトレンド、市場の流れ・政治などなどを自分の脳みそで把握し、自分の言葉でまとめられる力がないと、コンセプトを固められないんですよ。
前職の最後の方でやったプロジェクトなんかその典型ですね。
コンセプトプロポーザルができたら社内でのコンセンサスをとる。無論根回しとかある種の政治力も必要(必要ないに越したことはないが)。
コンセンサスが取れたら、今度は社内のリソースを確保。
んでここで意見が分かれるところだけどリソースつっても開発リソースだけじゃだめで、作りたいのは商品じゃなくてサービスなので営業、マーケなどフロントの人間も当然含まれるし、場合によっては経理だとか法務だとかも必要になります。
ここで開発リソースだけしか見ないと作られた結果まったく売れないものとか、システム的には動くけど商品的には満足じゃなかったりとか、そういう問題に陥る危険性がある。
そしていよいよプロダクト開発のスタート。ここで一番大事なのは、以前も書いたけれど
個人的に思うのは、有機的なチームプレーによる開発の第一歩ってのがあって、PMというか、そのチーム内での親方がVisionというか哲学というか、今回俺たちが作るものはこういうものなんだ!っていう意識をチームみんなに浸透させることが第一歩で、なおかつ一番大事。
これが浸透できていれば、開発プロセスの8割はできたも同じ。逆にそれができないと、チームはがたがたになっちゃう。
これですな。
特にエンジニアの場合、分業でコードを書いたりすることになることもあると思うけど、特にそういうときに、このVisionとか哲学みたいなものがないと、なんでこれやってんだっけ?みたいな感じになりがちだし、さらに自ら考えて「こうした方がいいじゃん!」みたいなことができなかったりする。
プロダクトを開発することだけに主眼を置くとそこがおろそかになりがちだけど、サービスを開発するという観点に立てばチームが一丸となってサービスをリリースするのだ!という情熱を持って動くことができるようになる。
そのためのVisionであり哲学であり、この商品でもって、これだけ世の中が幸せになるんだ!という絵が最終的な土壇場での求心力になる。
商品である以上売り上げ目標は当然あるし、それを達成しないといけないのだけれど、それは結果であって目的ではない、目的はもっと高邁な理想であるべきだと思ってます。
(ここらへん、相変わらず甘いなあと思わんこともないが、正直そう思う)
そのVisionや哲学を説得力をもって語るためにも
そういうときに必要なことが絶対的な業界知識。競合の状況、自社の状況、技術のトレンド、市場の流れ・政治などなどを自分の脳みそで把握し、自分の言葉でまとめられる力がないと、コンセプトを固められないんですよ。
ここがないとだめなんだと思ってます。
よくある営業と開発のいざこざって、実は8割ぐらいはここに原因があるんだと思ってます。
逆にこういう問題が起こるのであればそれは技術が悪いのではなく、営業が悪いのでもなく、PMが悪いんだと思います。
つまりね、開発はシステム的に動くことをゴールにする、そして営業は売ることをゴールにする、ってなるとサービスとして統一された動きが取れなくなるんですよ。
開発はシステム的に動くことではなくて商品として通用するクオリティのものを作らないといけないし、営業はその商品が最大級の賛辞を業界内で得て、顧客が満足してくれるために営業しないといけない。開発と営業ってのは二つの欠けてはいけない歯車であってそれをつなぐ軸がPMなんだと思うんですよ。
自分たちが提供しようとしているサービスがどういうもので、どんな思想があって、何を目標としているのか、という意思統一ができていれば、多少の齟齬はあってもサービスとして完成度は高いものになります。
どうしても昨今の風潮を見るに、ここら辺が見えてこないなあと思うわけです。
どうも開発はコードを書いてプログラム的・システム的に動くことで自分の仕事が終わって(往々にしてPMもこれだけが仕事と思っていたりする)、営業は作ったものを売るだけという動きですね。
そうなると開発側は将来的な商品の進化もできないし、営業も付加価値をつけられないような、しょーもないサービスで終わってしまうことが多いなあと。そしてお互いがお互いをけなして、PMは素知らぬそぶりで次の仕事をする、みたいな。
そうなったら、つまんないよねえ。
半分自戒を込めて、Postしておきます。
Comments
No comments yet
検索エンジンマーケティング関連書籍 by Amazon