大企業の契約業務を担うエンタープライズSaaSのプロダクトマネージャー
PMノート マツバラ（以下、PMノート）：まずはご自身の仕事について教えてください。
川瀬：MNTSQ株式会社でPMをしており、それと並行して、エンジニア、デザイナー、他のPMが属するプロダクトチームのメンバーのマネージャも担当しています。
MNTSQ株式会社は、大企業の契約業務を担うSaaSを提供している会社です。具体的には、契約書の審査依頼・作成、管理、廃棄といった契約にまつわる業務のライフサイクルを一気通貫でサポートするCLM（契約ライフサイクルマネジメント）を通じて、業務効率化や高度なリスク管理を実現するプロダクト提供に取り組んでいます。
社会へのインパクトを与えることを目指し、プロダクトマネジメントスキル向上を追求
PMノート：続いて、これまでのキャリアについて教えてください。
川瀬：きっかけは大学時代まで遡ります。当時は政治学の専攻で、コンピューターサイエンスを学んでいなかったのですが、先輩からの誘いでHTMLやCSSを勉強し始めたら楽しくなり、これをスキルアップさせて何かの役に立てたいと考えるようになりました。そこで、WordPressでのサイト構築の仕事を受託し、コーディングだけでなくIllustratorでのデザイン制作にも手を広げるようになりました。
一方、これからの進路を考えたとき、自分がやりたいのはエンジニアリングやデザインを究めるというよりも、プロダクト作りがしたいということに気づき、以後はプロダクトの企画やマネジメントのキャリアを歩むようになりました。
1社目（新卒入社）：サイバーエージェント
プロダクトの企画やマネジメントの道を志すにあたって、ゲーム以外の企画がしたいと考え、それができそうだと思ってサイバーエージェントへ入社しました。はじめは、サイバーエージェントが提供している様々なメディアの改善業務を担当し、入社数ヶ月後にあるプロダクトの企画・マネジメントを任されるようになりました。いきなり1人でプロダクトの企画をすることになり、「アジャイルサムライ」を読みながら愚直にインセプションデッキを書いて、プロダクトのコンセプト設計、エンジニアやデザイナーのアサイン、プロトタイプの開発、アジャイルでのプロジェクト実行、ローンチ、KPIのモニタリングやレポーティングなどを行いました。
僕は新卒入社したばかりでエンジニア経験を持っていなかったのですが、既にアジャイル開発経験を持っていたエンジニアの方とプロダクト開発を進められたので、すごく良い経験になったと感じました。
その後、ひと通りPMとしての業務を経験できたことを機に、今度は医療系か教育系のプロダクト作りを経験したいと思い、色々な会社を調べていたらQuipperという教育テクノロジーの会社を見つけ、転職を決意しました。
2〜3社目：Quipper → リクルート
Quipperでは、PM第1号として入社し、インドネシア、フィリピン、メキシコといった国々の学生・先生向けのオンラインサービスや、アメリカ向けのオンラインチュータリングシステムの展開に従事していました。ここでも、プロダクトのためならなんでもやると言わんばかりにがむしゃらに奮闘し、仕様策定、ユーザーヒアリング、カスタマージャーニーの検討などを行いまいた。
その後Quipperはリクルートに買収され、リクルート側のシステムとQuipperのシステムを統合するプロジェクトが発足した際は、「スタディサプリ」のiOS版・Android版のローンチを担当するPMを務めました。
4社目：LINE
Quipperではずっと少人数でPMを務めてきて、「自分がやっているプロダクトマネジメントって、本当に正しいのだろうか？」と疑問を抱くようになり、もっとPMの層が厚い組織でプロダクトマネジメントを究めたいと考え、LINEへ入社しました。入社してすぐに、期待通り多くのPMがいる組織だと感じました。
LINEでは、チャットボットや、カスタマーサポートへの問い合わせ機能のPMを務めました。それまでは、ワイヤーフレームベースで仕様を考えてエンジニアリングの部分はエンジニアに任せていたのですが、LINEでは、APIやVoIPのようなテクノロジーをがっつり理解した上で仕様策定することが求められ、関連する書籍で勉強しながら、チャットボットや自然言語処理エンジンの繋ぎこみと、それをLINEでどうやって提供すると有益なのかを検討していました。
そんな中、Googleのエージェントから、ユーザーの声をプロダクトやオペレーションに反映することをミッションとした「プロダクトサポートマネージャー」という、プロジェクトマネージャー系の職種を紹介されました。そこで、一度プロダクトマネジメントから離れて、ユーザーの声にがっつり向き合うのも良いなと感じ、また、Googleがやっている世界最高峰のプロダクトマネジメントを経験したいという思いもあったので、オファーを受託し、Googleへ入社しました。
5社目：Google
Googleでは、まずGoogle Pixelのサポートオペレーションを担当し、日本国内と海外主要国のサポートページ検討や、ロジスティクス観点でのトラブル発生時のオペレーション設計に従事していました。Pixelの日本国内ローンチを経験した後は、再びソフトウェア分野に携わりたいと思い、Googleマップのチームに異動しました。そこでは、主に南半球主要国のユーザーインサイトを担当し、地域特有の声をヒアリングしてプロダクトに反映することや、ちょうど東京オリンピックの時期だったため、それに向けたオペレーションの検討を行っていました。また、Googleでも、LINEのときに経験した機械学習を扱い、ユーザーからのプロダクトに対する意味のあるフィードバックを抽出するため、機械学習を導入するという取り組みにも関わっていました。
ある程度Googleでの業務経験を積んだタイミングで、LINE時代に機械学習分野で協業していた、弊社創業メンバーの1人・安野からの誘いを受けて、MNTSQへ転職し、現在に至っています。
PMノート：特定の事業ドメインに対する関心より、ご自身のプロダクトマネジメントスキルを高めることに対する関心が強い印象ですが、いかがでしょうか？
川瀬：そうですね。ただ、根底には社会の役に立ちたいという思いはありました。Quipperに転職したのも、教育分野という社会への貢献度が高いと思われる分野だったからです。ですから、事業ドメインにこだわりは強くないものの、エンタメ系にはあまり興味がなかったです。
一方で、社会の役に立つということを考えたときに、特定の事業ドメインにがっつり向き合うというより、どれだけ社会にインパクトを残していけるかにフォーカスする方が有益だと捉えているため、プロダクトマネジメントスキルを高めることに注力したいと考えています。社会が求めることは変わりゆくものですから、それに対して柔軟に対応できる素養を身に付けたいと考えています。
PMノート：Googleでは、PMの立場とは異なり、ユーザーの声をPM・プロダクトに伝えるという役割を経験されましたが、印象に残っていることはありますか？
川瀬：これまではPMとして、自分が優先度付けや仕様を決める立場だったのですが、それとは逆で、ユーザーのフィードバックを伝える側になったため、重要なフィードバックと思っていてもなかなかPMにうまく伝わらないというもどかしさを感じました。ですが、それに対してネガティブな捉え方はしておらず、PMだけをやっていたら気づけなかった良い経験になったと思っています。
PMノート：様々な業種・規模の会社でtoB/toC問わずプロダクトマネジメントを経験し、良かったと感じた点はありますか？
川瀬：最近だと、PLG（プロダクト・レッド・グロース）の中で言及されている、toCでユーザーに対してやっていたことを企業に対してもやっていこうという動きがあると思いますが、これまでtoCであたり前にやっていたことを、toBで実践してみようというときに、その経験が役に立っているなと感じます。逆に、toBだとtoC以上に仮説検証プロセスが重要視されますが、そこでも、toBで培った経験をtoCに応用できていると実感しています。
プロダクト開発のプロフェッショナル組織を追求
PMノート：所属組織におけるPMのミッションは何でしょうか？
川瀬：プロダクトチームのミッションとして、「社会と現実のギャップを発見し、MNTSQが実現したい契約業務のベストプラクティスを提供するプロダクトを定義する」「顧客要望ではなく顧客が求めていたものを採掘する」ということを掲げています。
さらに、「プロダクト開発のプロフェッショナルとして、コードから顧客体験まで、クオリティに妥協せず、最高のプロダクトを実現するため、リソースを最大限に活用し、非連続的なイノベーションと、連続的な改善を行う組織をリードする」ということを明文化しています。
PMノート：プロダクトマネジメントトライアングルを元に、具体的な業務範囲を教えてください。
川瀬：メインでやっているのは開発者とビジネス（プロジェクトマネジメント、社内外調整/資源獲得、プロダクト仕様）の領域で、そこから派生して、デザインの領域にも関与しています。
顧客とビジネス（マーケティング、パートナーシップ、ビジネスディベロップメント）の領域については別組織が担っていて、マーケティングについてはセールス組織がリードジェネレーションに重きを置いた活動をしており、パートナーシップやビジネスディベロップメントは戦略コンサル出身の方を中心に、コンサルタントという役割のメンバーが担当しています。
したがって、開発者とビジネスに重きを置いたプロダクトマネジメントを行っているものの、このプロダクトを実装すると顧客やビジネスにどう影響するのかということは、意思決定を行うために強く意識しています。弊社の場合、他社の電子署名やクラウドストレージなどのプロダクトとの連携をしていますし、また、顧客の多くが大企業であり、金額のインパクトが非常に大きいため、こうしたパートナーシップに関わる要素はマネジメントやプロダクト仕様検討を行う上で重要視しています。
仮説検証プロセスの強化と組織の透明性確保によってプロダクトの質を高める
PMノート：現在、向き合っているプロダクト課題は何ですか？また、どのように解決しようとしていますか？
川瀬：現在取り組んでいるプロダクトはエンタープライズSaaSであり、求められる必須機能が多く、業務オペレーションが多種多様です。そのため、プロトタイプヒアリングやユーザーヒアリングなどの仮説検証プロセスを重点的に強化しています。toCのノリで進めていくと、手戻りや取り返しのつかないことが発生したり、個社専用のロジックをフラグや分岐処理で制御するというカオスな実装となってしまうため、仮説検証プロセスを強化して、いかに汎用性を持たせるかが重要だと考えています。
また、弊社はエンジニアに対してPMの数が多いのですが、その比率を維持していくことを良しとしています。というのも、エンタープライズSaaSは、toCのようにABテストをしたりローンチ後に改善を検討するというアクションが取りにくいため、できる限りローンチ前の検証をしっかりやって、プロダクトの品質を高めたいと考えているためです。今後も、エンジニアとPMの比率維持とPMの採用には注力したいと考えています。
PMノート：PMはプロダクトカットでアサインされるのでしょうか？
川瀬：その通りです。弊社ではプロダクト単位でPMがアサインされ、クライアント単位でコンサルタントがアサインされます。そのため、PMは複数のコンサルタントと連携しながらプロジェクトを進める局面も発生します。例えば、A社というクライアントから個社対応の要望があった場合、PMは、その機能がB社やC社でも必要なのかをB社やC社を担当するコンサルタントにヒアリングしたり、優先度付けを行っています。
このように、PMは基本的に自身のプロダクトに専念しているのですが、プロダクト間でスキルセットを横展開することは積極的に行っています。例えば、デザインに強いPMはプロダクト横断でFigmaの運用方法検討などを進めていたり、エンジニア出身のPMであればSRE系のタスクをプロダクト横断で進めるということを行っています。
PMノート：仮説検証プロセスの中で特に重視していることは何でしょうか？
川瀬：仕様策定の際に、組織の透明性を作ることを意識しています。誰でもコメントでき、こちらからも意見を言えるように組織の人たちを巻き込んで、しっかりフィードバックを受けた上で意思決定することを心がけています。規模の大きいプロジェクトの場合、現役弁護士でもあるCEOにもレビューしていただき、有意義なフィードバックが得られているため、オープンに意見を交わせる環境を整えることは重要だと実感しています。それに加えて、ユーザーヒアリングやプロトタイプについても積極的に取り組んでいます。
PMノート：PMとして自慢できる実績はありますか？また、得意な領域は何でしょうか？
川瀬：toB/toC問わず色々なプロダクトをローンチしてユーザーを獲得するといったことは得意ですし、その中でもエンタープライズの契約業務というニッチでとっつきにくい分野でもやり抜くことができていると自負しています。
また、プロダクトのためには何でもやるという姿勢で臨み、それに備えて色々なスキルセットを吸収し、プロダクト提供を実現したことは自慢できる実績かと思います。過去に、インドネシアなどのユーザー基盤がない国で、低スペックのインフラや通信環境の中でどうやってプロダクトを提供するのか、決済プラットフォームはどうするか、など、何もわからない中で調査し実装するということも経験しました。直近、MBAも修了し、そこでの学びも含め、プロダクト作りのためになるべく弱みをなくすことに努めています。
迅速な意思決定を実現するために心がけていること
PMノート：大切にしているマイルールを教えてください。
川瀬：とにかく「決める」ということが大事だと思っています。決めるためには自信を持つことが大事で、自分がプロダクトのことをしっかり考えて、色々な情報を集めることで、自信を持って決められるようになります。あとで決めても問題ないものであっても、今決める場合とあとで決めることでどっちがメリットあるのかということを考えた上で、今すぐ決められることはバシバシと決めていくようにしています。そのため、僕はプロダクトデリバリーや実行フェーズに強みを持っているPMだと自負しています。
PMノート：物事を決めていくために色々な情報を関係者から出してもらうということも重要かと思っているのですが、意見が出しやすい雰囲気づくりなど、チーム作りで工夫していることはありますか？
川瀬：雰囲気に緩急をつけるようにしています。会議や意思決定の時はわりと真顔で淡々と進めていて、それ以外の時はわりとゆるゆるな感じだと思います。
特に、意思決定や物事を収束する会議では、事前にアジェンダを用意し、仮説を可視化し、さらに会議の1〜2日前には各メンバーから資料にコメントを追記してもらった上で会議に臨むというスタイルが定着しており、会議は決める場と捉えてスピーディーに意思決定できるように意識しています。一方、発散の会議では、会議前の準備プロセスは同じですが、会議時にもコメントを追記する時間を設けて、わいわいディスカッションを行っています。
なので、会議については目的をはっきりさせることが重要で、そうすることで「この会議は意見を活発に話していいんだな」「この会議は意思決定の場なので、それまでにしっかり備えておく必要があるんだな」という意識を持たせるのに役立つと感じています。
透明性の確保により、質を高め、関係者との期待値調整を行う
PMノート：質の高い企画や課題に対して筋のいい打ち手を生み出すために、意識して取り組まれていることはありますか？
川瀬：透明性の確保は特に意識しています。今、誰がパツパツな状況なのか、この人はうまくいっているのか、などを誰かが知りたい時に知れる状況を作ることで、誰かがまずい状況の時にフォローしやすくなります。そして、人の巻き込みを積極的に行い、レビュー頻度を上げることでプロダクト仕様の確度を高めることに役立っています。
また、透明性の確保をすることは、社内外での期待値調整にも役立ちます。例えば、別のプロジェクトが大変な状況になっているということが可視化されていれば、個社対応を要望されている方たちが「今、その機能が実装されないのは何故なのか」ということにヤキモキせず、それよりも優先順位が高いものは何なのかがわかり、メンバーやお客様含めてみんなが納得感を持てるようになると実感しています。
川瀬さんからのおすすめの本
PMノート：プロダクトマネージャーにおすすめの本がありましたらご紹介お願いします！
川瀬：「ノンデザイナーズデザインブック」は、プレゼンや会議資料だけでなく、LPの制作にも使え、これを押さえておけばプロに引けをとらない感じに仕立てられるので、すごく役に立ちますね。
また、グローバルプロジェクトのマネジメントにおいて、文化の違いによって何を大事にするか、などが書かれている「異文化理解力」という本は参考になりました。
最後に
川瀬さんのお話はいかがでしたか？
感想や得られた気付き、気になったフレーズがありましたら、「#PMノート」を付けてツイートしてみてください〜！
先輩PMにオンライン相談できます！
PMノートでは、先輩PMにオンライン相談ができます！
素敵な先輩PMがたくさんいますので、こちらからぜひご覧ください！
