機械学習エンジニアがプロダクトマネージャーになるまで
▲海外でのイベント登壇時の写真
はじめまして。トレジャーデータでプロダクトマネージャー (Product Manager; PdM) を務めている北澤 (@takuti) と申します。
大学院修了後にトレジャーデータに機械学習エンジニアとして入社してから約3年間、データサイエンス・機械学習のプロダクト化および顧客への導入支援・コンサルティング、そして関連分野のエバンジェリズムを担ってきました。
そんな私が社内でPdMに転身したのが2020年2月。
転生しました。https://t.co/pX4ZI56r89
— Takuya Kitazawa (@takuti) February 7, 2020
今回はこれまでの私の経験を踏まえて、機械学習エンジニアやデータサイエンティストのキャリアパスとして、PdMという選択肢の持つ面白さや可能性についてお話できればと思います。
高度な技術と、その実運用の間で
私自身、もともと、ビッグデータ、機械学習、ブロックチェーン、IoTなど、何か全く新しい概念を学ぶことがとても好きな性分です。
一方で、これらの技術を実アプリケーション上でどのように応用するのかは、初学者の私にとっては難しい問題でした。タイタニック号の生存者予測を行うチュートリアルと、実社会で役に立つサービスの設計・開発の間には大きな隔たりがあるはずです。
そのため、大学院時代には、常にどこか漠然とした不安や焦りがありました。それでも「実世界で使われてこその技術である」という信念の下、研究室の外にも学びの機会を求め、論文に書かれた理論と企業の実アプリケーションの間を行ったり来たりの日々を過ごしていました。
「ユーザ中心であれ」という気づき
そのような信念に従って大学院修了後は、トレジャーデータに機械学習エンジニアとして就職し、B2Bのサービスの上でコンサルティング業務から機械学習のプロダクト化まで、多様な経験を積むことができました。
その過程で得た重要な知見のひとつが、どれほど時間と労力を費やしても、どれほど複雑なデータ処理パイプラインや高精度な予測モデルを構築しても、それがユーザに使ってもらえるかどうかは全く別の問題であるという事実です。
私たちが分析結果を伝え、開発したサービスを届ける相手は、必ずしも機械学習の専門家であるとは限りません。ゆえに、ユーザが抱えている問題を正しく理解し、適切なソリューションを正しい形で届ける力こそが、技術から価値を生み出すためには不可欠なのです。
世の中には線形モデルや決定木のような教科書レベルの手法、ひいてはルールベースな手法で解決可能な問題が山ほど存在します。技術は手段に過ぎず、それ自体を目的にしてはならないと強く思います。
ユーザを理解し、解決策を示すのは誰か？
プロダクト開発組織におけるPdMの役割とは、次のようなものであると私は考えます。
- 対象とするユーザ像と彼ら彼女らが抱える問題を深く理解し、
- エンジニアやデザイナーが解決可能な問題に『翻訳』し、
- 適切なソリューションを正しい形で提供することに全責任を負う。
まさに先に挙げた『技術から価値を生み出すための力』を備えた人材です。
既にエンジニアという肩書きの枠を超えて（不格好ながらも）顧客接点の多い仕事を担ってきた私には、「技術や理論以外の側面から機械学習の可能性を探求する」という点について確かな手応えがありました。そのため、PdMへの転身は自分にとって極めて自然な選択肢であったようにも思えます。
PdMのおしごと
では、具体的なPdMの仕事内容はどのようなものなのでしょうか。「機械学習エンジニアでも務められるような役割なの？」「ビジネススクールを卒業してMBAを持っていないといないとダメなんじゃないの？」と気になる点もあるかと思います。
細部は企業・チームの規模や扱うプロダクトの性質によって異なりますが、個人的には大きく分けて2種類の役割があるように思います。
計画を練る
1つ目の役割は、ロードマップや製品開発戦略の策定といった組織レベルでの、進むべき方向性に関する議論や意思決定を行う仕事にあります。
ここでは見込み・既存顧客の調査とニーズの洗い出しに始まり、新規開発や改善が要求される製品領域の絞り込みとその優先順位付け、開発計画の立案といったハイレベルな議論を行います。
プロダクトとはすなわち自社の『売り物』なわけですから、「なんとなく」で開発・販売を行うわけにはいきません。また、開発に割くことのできる人的および金銭的コストも有限です。ビジネスである以上、作られるものの背後には必ず理由や戦略が存在します。
プロジェクトを推進する
究極的には、そのような計画に基づいてプロジェクトを推進し、単一の機能・製品の開発を成功に導くことこそがPdMとしての責務です。
まずはユーザへのヒアリングや蓄積されたデータを元に機能・製品の要件定義を行い、その後エンジニアやデザイナーと協力してプロトタイピング、検証を進めていきます。そして最終的に計画通りに機能がデプロイされ、顧客に届き、満足して使ってもらえるよう、全開発工程において成功に向けた大小様々なコミュニケーションと意思決定を行います。
また、詳細はアジャイルやウォーターフォールといった開発手法に依るところもありますが、リリース後の機能についてフィードバックを得て改善を行うフェーズもこれに含まれます。
『良いPdMの仕事』とは？
以上、2種類の役割に共通して言えることは、PdMの仕事とはユーザ・顧客の理解なしには成り立たないということと、社内外問わず徹底したコミュニケーションが重要であるということです。そこにバックグラウンドは関係ありませんし、MBAも不要です。
プロダクトが誰に使われ、どのような問題を解決するのかが明らかではない状態で「何を作るか」を議論すること、そしてコミュニケーションをおろそかにして「きっと」「おそらく」「たぶん」といった仮説の上でプロジェクトを推進することほど愚かなことはありません。
しかし、残念ながら、世の中には "Good Product Manager/Bad Product Manager" を筆頭に「良きPdMとは何か」を論じた文章が数多く存在し、当たり前にも思えるそのような営みが十分に成されていないのが実情です。自戒の念も込めて、この点は特に強調したいです。
PdMという仕事の難しさ
ここで、私個人のケースをもう少し深堀り、PdMの難しさについてご紹介します。
現職での経験を振り返るに、そこには
- 機械学習をプロダクト化すること
- エンタープライズ企業でPdMの役割を担うこと
- 外資系企業のグローバルな環境下で仕事をすること
に伴う多面的な難しさがあると感じます。
機械学習プロダクトにおけるUI/UXの重要性
機械学習をビジネスに応用する場合、受け手が直感的に理解できないモデル・予測結果は容易には受け入れてもらえません。現実には説得すべき大勢の利害関係者がいて、予測結果ひとつで大きな額のお金が動くこともあるため、「精度は我々が保証するので、黙ってこの結果を信じてください」というわけにはいかないのです。
では、いかにユーザに予測結果を信用してもらい、納得感を持って施策の実行に移ってもらうか。そのためには、モデルそれ自体の外にある『見せ方』に関する議論が不可欠です。
一方で、実際にユーザが目にするグラフや触れるUI/UXを設計するデザイナーも、必ずしも機械学習に理解があるとは限りません。「どのような可視化が効果的なのか」「その見せ方はミスリーディングではないのか？」「ヒューリスティクスの活用をいかにして促すか」といった議論はモデルの理解なしにはできません。どれほどモデルの説明可能性 (Explainable AI) に関する研究が進んだとしても、です。
したがって、機械学習のバックグラウンドをもつPdMは、顧客のAI・データ活用に対する漠然としたニーズを正しく理解し、UI/UX要件に落とし込むことのできる、唯一無二の存在であると言っても過言ではありません。
エンタープライズ製品を届けることの難しさ
「PdMとして、顧客とのファーストコンタクトで最重要視することはなんですか？」と問われれば、迷わず「期待値のすり合わせ」と答えます。
自社データを扱う機械学習エンジニア・データサイエンティストであれば、モデルを状況に応じてチューニングし、最適な形で実アプリケーションに落とし込むことも可能でしょう。しかしB2Bビジネスの現場においては、提供するサービスが規模や業態の異なる複数の顧客のビジネスの併走者となるわけですから、安易に裏側の実装を変えるわけにもいきません。基本的には膨大な顧客ニーズを集約した上で、最大公約数的な落とし所を見つけて、単一機能として実装・リリースすることになります。
しかし、個々の顧客の視点から見れば、当然それぞれのビジネスに応じたKPIが存在し、所有しているデータも異なります。この『プロダクトとして機能レベルで提供できる範囲』と『顧客が真に望む成果』のギャップはそのまま期待値のズレへと直結し、その後のミスコミュニケーションを誘発します。
エンタープライズ製品を提供する者としてその事実を重く受け止め、「AIだし何でもできるんでしょ？」といった過度な期待や、「なんだ、結局大したことできないじゃん」といった過小評価を引き起こさぬよう、細心の注意を払う必要があります。
具体的な方策としては、AutoMLのような『技術』である程度汎用的に解決できる場合もあるでしょうし、時にはカスタマーサクセスチームとの密な連携による『人力』でのピンポイントな対応も必要となります。
国が違えばニーズも違う
先述の通り、プロダクトとして機能レベルでサポートできる範囲とその汎用性には限りがある一方で、ニーズは顧客の数だけ存在します。そして私の経験上、その差異は国境をまたぐことで一層顕著に現れます。背後にはその国・地域で優位な競合企業の存在や、技術的なトレンド、求人市場の特性、文化的背景といった様々な要因があり、PdMには案件に応じた柔軟な対応が要求されます。
また、各国に点在する仲間の価値観や意見も現地のマジョリティにバイアスを受けるため、たとえ社内でのコミュニケーションでも、大きな温度差を感じることも稀ではありません。Aという国ではXという機能がないとサービスが売れないという声が多数上がっている一方で、Bという国でヒアリングするとそんなニーズ聞いたこともないと返ってくる......難しいものです。
しかし、その『多様性』に触れることこそが面白く、この仕事の魅力でもあると思います。北米、南米、ヨーロッパ、東南アジアなど、各国に点在する様々な顧客の多様なビジネス課題とデータに触れることができるという一点において、私は現職での仕事に誇りを持っています。
機械学習エンジニアからPdMに転身してからの10ヶ月間で得たもの
実世界で使われてこその技術であると常に考えてきましたが、使われるために必要な技術以外の要素とは何なのか？ これまでの経験を通して、そんな問いにぼんやりとした答えが見えてきました。
技術と実世界をつなぐのに必要なのはコミュニケーションと顧客理解の徹底
それは、一言で言えば徹底したコミュニケーションと顧客理解に裏付けられた『隙の無さ』です。
セールス、マーケティング、エンジニア、デザイナーといった『役職の差異』、グローバルな環境下での『地理的・文化的な差異』、顧客や社内の仲間との間の『理解・情報の差異』といった、実世界に存在する様々な『差異』を尊重しつつ、プロジェクトを着実に推進していくことが求められるのだと思います。
パズルのピースをはめていくように、理解をズレなくひとつひとつつなぎ合わせ、『仮説』をひとつずつ『事実』へと昇華していき、それを元に着実に完成形を作り上げていく。それこそがPdMの、PdMにしかできない仕事なのではないでしょうか。
地道な積み重ねが大切
ミーティング、ドキュメント執筆、コミュニケーションの交通整理......PdMの仕事とは案外地味です。実際にプロダクションのコードにコミットする立場にはないため、いざというときに無力感にさいなまれることもあるでしょう。エンジニアからの転身であれば尚の事です。
しかし一歩一歩、その『当たり前』の仕事を積み重ねていくことこそが、チームを、プロダクトを、もっとずっと遠くへ連れて行ってくれるのだと信じています。技術という可能性の種を活かすも殺すもPdM次第、と言ってしまってもいいかもしれません。
僕は「世界で闘うプロダクトマネージャー」にはなれない。でも、今この場所での闘いに最善を尽くすことはできる。—『僕は「世界で闘うプロダクトマネージャー」にはなれない。』
機械学習のバックグラウンドを備えたPdMとして
スキルのコモディティ化が急速に進む昨今、仮にあなたがゼロから機械学習を学んでPythonで二値分類器を実装したとしても、残念ながら客観的な評価はあまり期待できません。手を動かしながら新しい技術を学ぶという素晴らしい挑戦を成し遂げたのにも関わらず、です。
しかし、そのコードを業務に応用して顧客の解約予測モデルを構築した上で、『直近で解約のおそれがある顧客リスト』をはじき出したとしたら、どうでしょうか。その後の施策の結果としてわずか数%でも解約率が低下したのであれば、その成果がビジネスに与える影響は決して無視できるものではありません。
さらに、そこにUI/UXが備わったとすれば？ あなたの予測モデルが専門知識を有さないユーザにまで届き、直接手を下さなくても有機的に価値を提供し続けてくれる『プロダクト』として独り立ちするわけです。
よく「0→1をつくる」といった表現をしますが、PdMとしての仕事によっては、その「1」が突然「10」や「100」に化ける可能性だってあるのです。PdMとはそれほど挑戦的で、ポテンシャルを秘めたキャリアパスなのだと私は思います。（もちろん、「1」を作るはずがいつまでも「0」のままだったり、不手際で「−1」の何かを生み出してしまうリスクもありますが。）
また同時に、PdMとは高度な技術の良き理解者でなければなりません。猫も杓子もAI・データ活用に関心を寄せている昨今、機械学習のプロダクト化へのニーズや期待感は高まる一方です。
しかし、純粋な『プロダクトマネジメント力』のみで価値を生み出せるほど、未だこの分野は成熟していません。両者の橋渡し役として、機械学習×プロダクトマネジメントの掛け合わせで機械学習エンジニアがその地位を築き上げ、未来を切り拓いていけたら、なんと素晴らしいことでしょう。