Product Managementで意識していること

前職のYahoo! JAPAN時代から始まり、LINEに入ってから今に至るまで、ここ3年程は、いわゆるプロダクトマネージャー（以下、プロマネ）として仕事をすることがほとんどです。プロダクトの立ち上がりから関わることが多く、プロダクトのコンセプトを決めるところから始まり、それを実現するためのチーム、そしてその組織におけるカルチャーも含めて全てを一から作っていく感じです。

3年ほど前、Yahoo! JAPANででIoT事業のプロマネを任されたのが初めてでした。当時は何をどうすれば良いのか全く分からず、とりえあず同じ役割を持つ人に色々と話を聞いてみて回ったりしましたが、結果的にはあまり参考にならず、試行錯誤を経て今に至ります。
参考にならなかった理由は、今になってようやくわかってきたのですが、聞いたノウハウややり方が、その人のスタイルだったからです。
スタイルはその人が実践からこそ活きるわけで、表面的なスタイルだけ真似したところで全くワークしなかった、というオチです。
ただ、当時は理由がわからず、空回りしては自分の能力のなさにを悲観して、よく落ち込んでました。

そして、紆余曲折ありながらも、いくつかの事業でのプロマネを経験を経たことで、自分なりのスタイルがようやくできてきた気がします。上に書いた通り、これは自分のスタイルなので参考ならない気がしますが、こんなスタイルもあるんだねと、いうことを伝えるぐらいの軽い気持ちでマイスタイルを書いてみます。

1. ビジョンが持てるプロダクトしかやらない

一番大事にしている私のポリシーです。プロマネである自分自身がそのプロダクトの可能性を信じて、自分の言葉でビジョンを語れないなぁと思ったら、そもそもプロマネはできないなと思います。プロマネが未来を語れないのに、他の人にビジョンを持つことを期待するのは変ですし、もし他にビジョンを持っている人がいるのであれば、その人がプロマネをやるべきだと思います。

もちろん、実際に何かを始める時には、集められる事実は集めて、なるべく確からしい仮説を立てるのは当然なのですが、最後に成否を決めるのはプロマネのビジョンとパッション次第だと思っています。だから、自分自身の言葉でビジョンを語れるプロダクトしかやるべきではないし、語れないようなプロダクトであれば、周りを不幸にしないためにも、初めからやらない方がいいかなと思ってます。

# 逆の視点では、プロマネの仕事の幅を広げるためには、色んな領域にアンテナを貼って、"やってみたい" "面白そう"の幅を広げることが重要だなと思います。その領域の幅が広がれば広がるほど、プロマネとしてできる仕事の幅は広がるので。

2. 自分の役割を定義しすぎない

ビジョンを実現する上でのプロマネの役割は、一言で言うと”何でも屋”だと思います。"結局何するの？"と聞かれても、"全部"としか答えようななく、これ以上の定義は難しいです。何故なら、その時々に応じて自分自分の役割を変化させるからです。

初めの段階では、ビジョンを決めたりプロダクトのコンセプトを決めたり、最大限に視野を広げることをします。具体的なスペックを決める段階になってくると、本質的な部分にフォーカスするために、本質的な部分以外はNoと言うことが多くなります。プロダクトの形が見えてきたら、よりユーザーの近くに身を置き、その価値検証をします。さらにフェーズが進むと、プロダクトの改善がスムーズに回るように運用の設計をしたりもします。もちろんQAもしますし、必要に応じて対外交渉もします。リリースしたらプロモーションのためにイベントに登壇したりもします。

要はプロダクトの全てに関わるので、そもそも役割を固定することはできませんし、何か不測の事態が置きたら、それが事業的な問題であれ、組織な問題であれ、どうにかして解決しなければなりません。常にその時々の状況に応じて役割を変化させるため、必要以上に役割を定義しすぎない方がよいです。

3. チームの活動を系（システム）としてマネジメントする

これは一番言語化が難しいのですが、構造的に複雑かつ不確実性が高いプロダクトを、私のような凡人がリードするためには、私に取って必須の概念です。例えば、現在携わっているClova事業だと、プロダクトの構造として、デバイス開発に始まり、デバイスに組み込むファームウェア、デバイスを設定するためのモバイルアプリ、要素技術として音声認識、自然言語処理、音声合成、さらには、ディスプレイがついてくるとGUIデザイン、GUIとVUIを統合したマルチモーダルのUX設計と、プロダクトの要素だけでもこれだけありますし、当然、マーケティング、セールス、toBで提供する場合はビジネス開発チームとの連携も必要になってきます。

これだけ複雑になってくると、階層的なチーム管理はとても非効率だと思っています。まず、そもそも、チーム間・役割間の依存関係が複雑で、そもそも階層構造を定義することがとても困難です。無理に作ったとしても、部分最適にしかならないことがほとんどで、ある状況ではうまくいくが、状況が変わるとうまくいかなくなるケースが多いです。また、日々変化が生じる状況を効率的に共有することを考えても、階層構造的な組織は、階層を上下する分、情報の伝達が遅くなり、かつ、チーム間・役割間の壁が作られやすく、横のつながりが薄くなりやすいです。そのため、何か問題がおきたとしても、自律的に問題が解決される可能性が減り、結果としてチーム全体のスループットを下げてしまいます。

このため、階層的な構造を定義したり管理したりすることを初めから諦めます。その代わりに、チーム全体の活動をアプトプットが生まれる"系"として捉え、その系で一番弱いボトルネックとなっているところ、つまり、アウトプットの質と量を決定している部分のみにフォーカスし、その細いパイプを強化することにフォーカスしています。プロマネの役割は、各チームの動きの細部を把握することではなく、チーム全体のアプトプットを強化することなので、ボトルネックの解消にフォーカスすることで、細部を把握しなくとも、効率的に全体のスループットをあげることができます。

ボトルネックを見つける方法は、割と直感なのですが、人と人や、異なる役割間での関係性を見ていると、大体の場合、簡単にボトルネックを発見することができます。個々のメンバーの能力がとても高い組織においては、チーム間の連携不足や、そこからくる認識違いにボトルネックが存在しているケースが多いように思います。

4. 早い段階から各メンバーの役割を定義しない

プロジェクトの初期段階では、そこに関わる人の役割をあえて決めない期間を設けることが多いです。大部分の人には、役割が決まっていない不安定な状況でもやもやさせてしまうのですが、その中でも本来想定される役割を超える動きをする人や、以外な得意領域を持っていて良い意味での想定外のアウトプットを生み出す人が出てくることがあります。

もちろん1on1ミーティングなどで、得意なことをヒアリングする方法もありますが、信頼関係が十分にないと、言葉を通じて根深いところまで理解して、ポテンシャルを引き出すのは自分にはあまりに難しすぎます。ある程度の期間を許容される人材育成と違い、プロダクトの進行はスピードが大きな価値なので、役割を決めない期間を作ることで、短期間で、それぞれの人が持つ能力を把握できるようにします。

ただ、これは言葉で書くと容易いのですが、実践するのは胆力が求められます。なぜなら、なるべく早く役割を定義した方が管理上も楽ですし、また、周囲から、早く役割を明確しろと急かされることは常なので、役割を決めない時期を維持するのは忍耐力を要します。しかし、ここで冷静に堪えられれば、それぞれの人の活動の幅を早く深く理解することができ、変化が必要とさせる場面で柔軟に動けるようになります。特に不確実性が高く、柔軟な動きが求められるプロジェクトではとても重要だと思います。

5. 情報はとにかくオープンにする

前項の"役割を超えられるような人"が現れるためには、情報格差を限りなくゼロにすることが、とても大事だと思います。自分の属する事業、組織の情報だけでなく、自分のアンテナで収集した情報の共有も含めて、なるべく情報はオープンにします。
そして、情報の必要性はなるべく自分でフィルタリングせず、受け取る側に委ねます。情報をオープンにすると、思わぬ人から思わぬフィードバックが帰ってきて、その人の新たな一面に気づくことはよくありますし、その一面が役割を超えることに繋がっていくことが多いです。

また、情報はできるだけ階層的に伝達せずに、ブロードキャストで伝達します。フィードバックもダイレクトに受けるようにします。情報の伝達ルートをなるべく短くすることで、文字だけではない表現しにくい感情を伝えるのも容易になりますし、何より誤解なく正しい情報を伝えることができると思います。

さらに、情報をオープンにする、ということはカルチャーとして根付かせる必要があります。なぜなら、プロマネ自身が情報をオープンにするだけでは不十分で、メンバー間の情報もオープンに共有されるべきです。"なぜオープンにするか"、その背景を伝えカルチャーとして根付かせることで、全体の情報のネットワークは強固になり、それによって情報の伝達をきっかけにした新たなポテンシャルの発見につながる可能性が高まっていきます。

6. Face to Faceのコミュニケーションを大事にする

オンラインツールでコミュニケーションの効率を高めるのは、言うまでもなく重要ですが、一方でFace to Faceで空気を共有するコミュニケーションもとても重要にしています。
そして、Face to Faceで話するテーマは業務課題のような具体的な内容よりも、正解がない問いを議論する方がより効果的だと思います。例えば、仕事を通じて何を成したいかとか、何をしている時が一番楽しいかとか、ほんとは得意なんだけど今全然活かせてないこととか、逆に絶対やりたくないこととか。
つまり、普段の業務上でのやり取りであえて話題しないことを、Face to Faceでやりとりします。Face to Faceのコミュニケーションでは、言語化が難しい思いや、その人自身の哲学も共有することができます。これによって、より深い信頼関係を築き、阿吽の呼吸で業務を進行できる関係性を生み出せるようになると思います。

7. ポジティブであり続ける

プロマネに限らずだと思いますが、ポジティブであることは重要だと思います。ポジティブな姿勢とポジティブな言葉は、チームの文化として根付きます。逆にネガティブな言葉を発し続ければ、それが文化になります。ネガティブであっていいことは何一つもないので、どんな過酷な状況でもポジティブであり続ける必要があると思っています。

とはいえ、ポジティブであり続けることは容易ではありません。表面的なポジティブさは続かないことが多いです。結局のところ、ポジティブさを維持するには、もし失敗したとしても"これだけやってダメだったから、運が悪かったね"と思えるぐらいにハードワークするしかないと思っています。後悔があるとポジティブにはなれません。逆に後悔がなければ、常に前に向かってポジティブになれるように思います。

最後に

事業ドメインとかプロダクトの内容に関わらず、共通的に実践している、実践しようとしていることを文字にしてみました。想像以上に長くなってしまったのですが、もっと体系的にまとめていきたいなーと思ってます。

それにしても、プロダクトマネジメントの観点で、同じようなことを考えている人とあまり出会ったことがないのですが、自分のスタイルが亜流すぎるのか、それとも同じようなクラスタを探すアンテナが低すぎるのか。。。他の人はどうやってノウハウを得ているんだろう。。。