Technical Product Managerとしての1年の振り返り

まえがき

アップデートできてませんでしたが、約1年くらいTechnical Product Manager(以降 TPM)のRoleを担当しているので、その振り返りです。 ちなみに今回はRole変更エントリではなく、まだ引続きこのRoleを続ける予定です。

What is TPM

JDが公開されているので、まずはこちらを御覧ください

Why TPM

きっかけは 「TPMの組織を作ろうと思うので来てくれませんか？」と現在 Smartnewwsで活躍する @tairoに誘われ、「TPMってどういう仕事ですか？ というかPMとの違いは？」という俺の問に対して「まさに僕みたいな人のイメージです！」と説明されて、とてもすんなり合点がいき、それならばやってみたいと思ったのがきっかけです。

When,Where TPM

いつからという意味では、冒頭にも書いた通り、現在で1年とちょっと経ったくらい。 どこの領域という点に関しては、過去に記事にもなっていたこのあたりです。

mercan.mercari.com

How TPM

これは社内でも話題に挙がる項目でもあり、社内向けにも説明用ドキュメントが作られたりしているが、一言で表現するとまんま「Technical knowledgeを持ち、それを用いてProductを成功させるProduct Manager」となる。 これだけ書くと、PMの上位互換のように感じるが、それはある意味正しくて、ある意味正しくない。というのも、plain なPMという定義がもはや難しいと思っているからだ。

note.com

上記記事がとても参考になるように、PMに求められるスキルが高度・多様化する中で、何かしらの専門性を持つPMというのは増えているし、今後も増えていくと思う。数あるその方向性の一つの亜種に過ぎないと思っている。エンジニア向けに説明するなら、PMというのが「Software Engineer」と同じくらいplainなものを指していると思うと良さそう。

これだけでたくさんのことが書けてしまうし、議論ができてしまうが、この記事のメインはそこではないので、細かい定義はここまでにしておく。

現状課題

という訳で、仮にもPMの端くれなので、やることはProduct Managementになる。ここが大事で、Project Managementではないということだ。 両者の違いも難しいが、ProductにはLifecyleがあり、それはProjectのように一直線のものではないのが一つ差かなと捉えている。

  1. Product Concept
  2. Product Design
  3. Product Development
  4. Product Delivery
  5. Product Maintenance
  6. Back to Concept(= Step1)

これも様々なフェーズ分けの定義があって、上記は一例だけど、要は開発して終わり、リリースして終わりではない、ということだ。 このサイクルと自身の作業との振り返り比較で言うと、ようやくサイクルを1周できそうかどうかというレベル。この 1年かけてようやく というスピード感と経験の薄さが現状の最も大きな課題と感じている。 もちろん開発やリリースするのに色々な課題がある。リソースがなかったり、逆にブロッカーがあったり、などなど。 とはいえ、その辺を解決しつつ進めることこそが仕事であり、逆に進めることで成果を出すことがProductの改善につながると思う。 本当であれば、1つのCycleとして振り返り、何をやってどうなったから、次にどうするのか、ということがここで述べられるのがベストなのだが、そこまでには至っておらず、現状における成果をこれ以上に書けないのがとても悔しい。

Technical というPrefixに関しては、メルカリにおけるEngineering経験を活かすっていうことはできている部分があると思う。具体的にはコードやアーキテクチャを知っていることでできる設計の部分などだ。一方で、それは汎用的なTechnical knowledgeではなくドメイン知識だと思っていて、他の環境で同じことができるとはまだ思えないのが正直なところ。 これも大きな課題で、 ただのEngineerがPMの真似事しているな と見られてもおかしくないようなことしかできておらず、PMとしての専門性はまだ全然だと思うのは前述のサイクルを回しきれていない点が物語っている。

Individual Contributor との違い

EngineerからPMというRole変更は以下の資料における振り子を振った状態にあると思っている。

speakerdeck.com

まず、どうして振り子を振ったか、という点であるが、PMの良さとして、Productの What（何をするか） にフォーカスできる点が挙げられる。対してEngineerは How(どうやるか) についてフォーカスできる。（もちろん両方とも「フォーカス」であって、それしかやらない訳ではない。）

Backend(サーバーサイド)領域を抽象度を上げて表現すると、「RDBにデータを出し入れしてレスポンスを返す機能」という1つの大きなHowで括ることができるとして、この1括りのHowで解決しなければいけないWhatは山程ある。

おそらくこれを「1括りのHow」とするのに多くの意見があって、

  • 言語の種類やその性質による開発スピード、規模、パフォーマンスなどの違い
  • インフラ設備の違いによるコスト、Availability,Mutabilityなどの違い
  • NetworkやSecurityなど環境によるコストや制約などの違い

など他にも挙げきれないような多くの差異要素があることはもちろん知っているつもりだ。しかし、それらの要素は全て何らかの課題を解決するための手段として存在・提供しているものだ。 それぞれの要素の特徴や差異の意味を全て詳細に把握はできなくとも理解できるのならば、それを1つの大きなHowとして、多くのWhatの解決に向き合うのは良い経験になるのではと思ったのが振り子を振った理由だ。

逆に、自分の中で勉強不足で全くピンと来ていなくて括りの外にあるのが、例えば機械学習分野。RDBからSelectする代わりにそれと同じような感覚で機械学習モデルからデータを引くようになったとして、そのシステムの当たり前さをどれだけ咀嚼できているかは今時点ではさっぱりだ。この不透明さによってWhatにフォーカスできなくなるようなら、それが振り子を戻す時かもしれない。

まぁ、でもここまで書いて、完全に逆もまた然りだなと思った。 「顧客の求めるサービスを提供する」というのを1つのWhatという括りにするなら、それを解決できるHowも山程ある。その山を自身の中に積み上げる目的で、エンジニアとして技術力を磨く、というのも全く成り立つし、とても良い経験になると思う。

EMとの違い

一応、かつてEngineering Managerをやっていたので、それとの比較も書いておく。

個人的な経験だけでもの凄い簡単に言うと、

  • 人のために人にアプローチするのがEngineering Manager
  • Productのために人にアプローチするのが Product Manager

だと感じている。結局どちらも人にアプローチするのは一緒、というのがまず大事なところ。

この時、アプローチに行き詰まった際に、突き詰める先としてEMの場合「あなた」というベクトルに対して突き詰める訳だけど、ここが個人的に難しかったポイントだと思う。 「あなたのことを考えに考えて、○○したいんです」というのは、恩着せがましいというか、おこがましいというか、それってなぜ自分がやらないといけないんだっけ、と思って躊躇うことが多かった。

一方PMの場合は、「Product」へのベクトルを突き詰めれば良い、具体的にはプロダクト開発をしたいためにエンジニアにアプローチして、それが合意されない場合おそらくQCDのどこかに問題があり、それぞれについて突き詰めることになる。 Qualityを上げるのか、Costを下げるのか、Deliveryを遅らせるのか、とかを検討できれば合意できるケースが多いのではないか。もちろん例外もあるだろうし、QCDのどれかがUncontrollableであることも往々にしてあるだろうが・・ それらがControllableであるならば、QCDへのアプローチがReasonableかつLogicalであればあるほどその分だけ合意に近づけやすい。またReasonableかつLogicalにやるっていうのはエンジニア脳を使えて、やりやすくて良い。

そういう意味では、今の環境がQCDがControllableなので、恵まれているのかもしれない。。より厳しい環境でPMをやった上でのEMとの比較が必要かもしれない。

・・・と、ここまで書いて思ったが、QCDというのは実は浅い課題で、深い行き詰まりだとProductのMission/Vision などへの不合意になるのではないか。これらを突き詰めてエンジニアにアプローチする際には、Logicalに、だけでは成功しない。Logicの積み上げだけでVisionには到達しないからだ。むしろある種の熱意を持ってアプローチする必要があり、それは俺のめちゃめちゃ苦手な分野に該当する。PMだからLogicalで簡単というのはおお大きな誤りということになる。

しかも、もしMission/Visionが語れるのならば、EMとしてももっとできることがあったかも、とも振り返れる。多分

  • 人のために人にアプローチするのがEngineering Manager

この前提自体が違っていて、あるべきは『組織のために人にアプローチするのがEngineering Manager』だ。 思い返せば、EM時代もMission/Visionをマトモに考えられたことはなかった。どういう組織（これはEngineering Division全体もそうだし、自チームもそう）にしたい、という明確なモノは持っていなかった。当時、人に翻弄されているように感じたのは、指し示すものがない中で彷徨っていた感があったかもしれない。暗中模索という言葉がまさにしっくり来る。

つまり、結局Roleは変わっても自分の突き当たるべい苦手分野は一緒で、それは克服はできていないのでは、と思い始めてきた。

何が言いたかったか

それなりの理由を持って、TPMに取り組もうと思ったのでその背景整理をしつつ、現状課題というこの1年の整理を書き残すのが当初の目的だったが、Enginner及びEMとの違いを補足で書くつもりが、実は大して違わないし、課題は同じだった、ということを書きながら思ったのが自分自身の収穫になったというオチ。

書いてみたら、小さいもの課題として捉えてた反省が見つかった。いや、小さくはないか、基本的な事で事実自分には足りていないものだが、それよりもっと大きな根本的な課題があるのがわかったという学びか。

おまけ

再掲ですが、ちょうど最近OpenになっているJob Descriptionはこちらです。 ご興味のある方は、カジュアルにでも構わないので、ご連絡ください。