プロダクトセンスとは 〜帰納的思考と演繹的思考〜

本当はおすすめのスーパー書きたかったんだけど、写真ないと楽しくないな、と思ったのでまた真面目なことを書くことにしました。
プロダクトチームに移籍して約1年、アメリカ来てから4ヶ月以上が経って少しずつ「プロダクトマネージャー」という仕事が見えてきたのでその話をしようと思います。

プロダクトマネージャーの役割

プロダクトマネージャーという仕事は、名前は聞いたことがあっても実はどういう仕事か分からない、という人も多いんじゃないでしょうか。工数管理？ガントチャート？みたいなイメージの方もいることでしょう。
一言で言ってしまうと、プロダクトマネージャー＝エンジニアとビジネスを繋ぐ橋、だと僕は思います。

自社のプロダクトを持つようなIT企業であれば、そのプロダクトを売ることで生計を立てているわけなので、売れるプロダクトを作らなければなりません。でも例えば技術的な難易度、実現性などを無視してしまうとどうなるでしょうか？ドラえもん作ったら売れるんじゃね？とかそういうことになりかねないのです。

では逆に技術的なすごさだけを考えてしまうとどうなるでしょうか？誰が買うだこんなもん、みたいなものが出来上がってくるかもしれません。

そこで両方の世界に少しずつ足を踏み入れている人、プロダクトマネージャーの登場です。（誰が器用貧乏じゃ）プロダクトマネージャーの役割とは大きく2つに分かれます。

1.  何を、どういう優先度で作るのかを決める（ビジネス寄り）
2. 実際にどのような仕様で作るのかを決めて開発側に渡す（エンジニア寄り）

つまり、ビジネス＋エンジニアリングの最大化、が仕事になります。これは時にはビジネスだけ、エンジニアリングだけを見ると妥協点を探すことと同値だったりするので、あくまで両方合わせた最大化を目指さなければなりません。

プロダクトマネージャーに必要なもの

一言で言ってしまえば、ビジネスサイドともエンジニアサイドとも、共通の言語で話せること、だと思います。

ビジネスサイドの知識やスキルを定量化するのは非常に難しいので、ここはなんとも言えませんが、恐らくマーケティング、営業、渉外などのスキルは活きることでしょう。僕も自分で会社をやったり、広告の運用と営業をやったりした経験は非常に活きています。

エンジニアリングの知識としては、僕は個人的には書けないけど読める、くらいが妥当な気がします。コードそのものの読み書きよりも、よりハイレベルな部分で仕組みや動作の原理が分かっていることが重要です。

キャリアとして考えたときに、ビジネス→エンジニアか、エンジニア→ビジネスか、がありますが、僕の周りではエンジニア→ビジネスが多く見受けられます。

プロダクトマネージャーの普段の仕事

プロダクトも多様なので、ここからは基本的に僕が普段やっている仕事をベースに書いていきたいと思います。
プロダクトマネージャーの仕事は大きく2種類に分かれます。

1. プラスを作り出す仕事
2. マイナスを0にする仕事

そして、惜しむらくは多くの場合、2が80％くらいになるのではないでしょうか。つまり、とても地味で根気のいる仕事だと、ここに包み隠さず言っておきます。

エンジニアならばOSSのコミッタになって世界的に有名になる、とか営業なら営業成績1番になってうぇーいする（偏見）、とかあるかもしれませんが、表に出るような仕事はほとんどないです。まぁこれは扱っているプロダクトに依っても全然違うとは思いますが。しかしとりあえず自分の性格にはよく合っていて、全然嫌いじゃないので、似たような人がいたらプロダクトマネージャーを目指しましょう。

プラスを作り出す仕事

まず派手な方から。プラスを作り出す仕事とは何か。今のプロダクトはアプリの広告マネタイズのメディエーションSDKなので、究極的なゴールは媒体さんの利益をより増やすこと、になります。そのためには

- 新機能の追加
- プロダクト自体の動作の最適化
- サポートするネットワークの追加

などがこれに当たります。特にプロダクト自体の動作の最適化、では、ほぼハックや裏技に近いような発想が必要なことも多く、僕はこの部分が一番好きです。新機能の開発にしてもクリエイティブな考え方が必要ですし、楽しいことが多いですね。

マイナスを0にする仕事

では地味な方はどんな仕事でしょう？これは期待しているゴールに届いていないものを「見つけ」「調査し」「改善する」仕事になります。つまりおかしいものやバグを見つけては直していくやつです。

発見: 自分でデータを眺めて発見、クライアントからの問い合わせ
調査: 自分で再現・検証、エンジニアに依頼
改善: エンジニア・ビジネスチーム・パートナー会社のプロダクトチームなどに依頼

よく見たら、依頼、の文字が2回も出てくるんですが、こちらの仕事は病院のトリアージのようなもので、状況を素早く正確に把握し、しかるべきチームにエスカレートして解決する、という全チームのハブになる仕事になります。

エラーやバグのないシステムはないですし、他社のSDKを内包しているプロダクト特性上、毎日のように異常が検知されます。それを適切に処理していくことでクライアントの利益やエンドユーザーのUXを損ねないようにする、そういうお仕事です。

帰納的思考と演繹的思考

そんな中で比較的よく使う思考方法があるので、それを紹介します。それは帰納的思考です。この分類やネーミングは僕が独自に考えて使っているものなのでオフィシャルにそういった言葉があるかは分かりません。

演繹的思考というのは、何かルールや規則がある場合に、A→B、B→Cという風に思考していく思考で、一般に「ロジック」と言われているものがこれになります。

一方で、帰納的思考というのは何かというと、AがBになって、CがDになっている、という結果があるときに、じゃあルールはなんなんだ、と考える思考法です。言い換えれば「仮説」を立てるような思考になります。こちらは一般にはロジックだと思われてない気がするんですが、僕はこれもロジックの一部だと考えています。

この帰納的思考がプロダクトマネージャーに限らず、様々な状況で重要なんですが、残念ながら理系の大学院くらいまで行かないと学ぶ機会がないので、意識して習得しないと出来るようにはなりません。

プロダクトマネージャーをしていると、帰納的思考で仮説を立て、演繹的思考でそれを検証する、ということをとにかくやり続けることになります。

わかりやすい例え（になっていればいいですが）をしましょう。ある日あなたの友達から一本の電話がかかってきます。

「パソコンが壊れた」

パ ソ コ ン が 壊 れ た。。。！！！
誇張に思えるかもしれませんが、エラーやバグに対する一次情報なんて大体こんなもんです。さぁ、どうしましょうか。恐らくあなたは質問を色々とすることでしょう。

- コンセントはささっているか
- 電源は入るか
- Macのロゴは表示されるか
- 起動したらどういう画面になるのか

などなど、「壊れた」状況を明らかにしようとします。これが調査のフェーズです。そして最終的にあなたは1つの仮説を導き出します。

「ハードディスクがいっぱいなんじゃない？」
「システム環境設定からディスクユーティリティを見てみて、空き、いくらになってる？」

これが仮説の検証フェーズです。あとはさらにその直接の原因を探るのに再度仮説を立て、検証して、でかいファイルを消すなりなんなりアドバイスをすることでしょう。

入り口が「広告が表示されない」とか「impががくんと落ちた」とかなだけで僕がやっていることも同じです。この仮説を立てる部分がとても重要だと僕は考えています。仮説を立ててそれが言語化されることで、無機的な情報が初めて有機的な情報になります。そして有機的な情報こそがビジネスサイドの思考に繋がる鍵になると思うからです。

センスとは

ビジネスセンスであるとかプロダクトのセンスであるとか、「センス」という言葉について最近深く考えたので、最後にそれを書きます。

センスとは無意識にまで落ちたロジックである、と僕は定義づけています。帰納的思考にしろ、演繹的思考にしろ、数をこなしていけば同じようなケースにあたることがあって、そのときは考えるまでもなく答えが出るはずです。その考えるまでもないケースの数が多いことをセンスがある、と言うんじゃないでしょうか。運動神経とかはまた別だと思いますが。

なので基本的にはプロダクトセンスだろうがビジネスセンスだろうが一部の超天才たちの域は無理でもかなり高いレベルまでトレーニングで身につくものだと僕は思っています。

よく考えたら、マイナスを0にするほうの仕事はほぼ僕が一人でやっているので、地味なプロダクトマネージャーの仕事に興味ある人がいたら連絡お待ちしてます。