見出し画像

テクニカルプロダクトマネージャーとして考えていること#3 「テクニカルプロダクトマネージャーに必要なスキル①」

フルカイテンでテクニカルプロダクトマネージャーを担当しているパンサー師匠です。
今回はテクニカルプロダクトマネージャーに必要なスキルについて語りたいと思います。


前提

テクニカルプロダクトマネージャーに必要なスキルを語る前提として、テクニカルプロダクトマネージャーの役割について、認識を揃えておきたいと思います。なぜなら、同じ「テクニカルプロダクトマネージャー」というポジションでも、組織によってその役割が異なることが想定され、役割が違えば必要なスキルも当然変わってくるためです。
今回は以下に示すこれまでの記事で定義した役割を前提にします。

汎用的なビジネススキル

テクニカルプロダクトマネージャーも組織に所属する一人のビジネスパーソンです。よって、専門スキル以前に、ビジネスパーソンが一般的に求められるビジネススキルは必要です。
本題からそれるため詳細は語りませんが、例として以下のようなスキルが挙げられます。

  • ビジネスマナー

  • コミュニケーション

  • ファシリテーション

  • プレゼンテーション

  • ドキュメンテーション

  • 論理思考

  • チームビルディング

  • IT活用力

テクニカルプロダクトマネージャーの求人票を見ても、こういったスキルは要件になっていないことも多いと思いますが、多くの場合、載せるまでもない大前提だからと考えて差し支えありません。
テクニカルプロダクトマネージャーは何の職業経験も無い人がいきなり担うようなポジションではなく、テクニカルプロダクトマネージャー自体は未経験だとしても、エンジニアなど何かしらの類する経験をそれなりに積んでいる人が担うポジションです。よって、一定のビジネススキルが備わっていることは当然期待されているということです。

コアとなる専門スキル

プロダクト開発を行う組織においてテクニカルプロダクトマネージャーが期待されていることは、技術に軸足を置きながらビジネス寄りの期待も汲み取って、バランスを取りながらプロダクトを成功に導くことです。
その期待に応えるためにコアとなるスキルは以下の3つです。

  • ビジネス要件の理解力

  • ビジネス要件の実現手段を構想するスキル

  • 構想した実現手段を伝えるスキル

1つずつ取り上げて深堀りしてみたいと思います。

ビジネス要件の理解力

プロダクト開発の一連の流れの中で、テクニカルプロダクトマネージャーにとってはビジネス要件が業務の起点となることが多いのではないでしょうか。
そのため、ビジネス要件を理解する能力は当然必要となりますが、重要なのは理解の度合いです。書かれている文章を文字通り受け取るだけではなく、行間も含めた、その本質を理解することが重要です。
では「本質を理解する」とはどういうことでしょうか。私の解釈では以下の通りです。

ビジネス要件がなぜ必要かを、背景を含めて理解し、納得し、共感し、実現したいという意欲が持てている状態

気持ちの問題も大きいですが、ビジネス要件が自分事になるまで消化できていると言い換えても良いかもしれません。

ではなぜ「本質を理解する」ことが重要なのでしょうか。
それは次の工程である「ビジネス要件の実現手段を構想する」際の質に直結するからです。
「本質を理解する」状態まで至っていない状態で実現手段を構想しても、検討が行き詰まったり、真の課題を解決できていない表面的な解決策しか出てこないということになるでしょう。
質の高いアウトプットをするには質の高い検討が必要で、質の高い検討をするには質の高いインプットが必要なのです。

「ビジネス要件の理解力」を培う要素としては以下の3つがあると考えます。

  • ドメイン知識

  • 思考力

  • 熱意

ドメイン知識

テクニカルプロダクトマネージャーにとってドメイン知識がどの程度必要かというのは様々な意見があると思いますが、私は極力高度な知識があった方が良いと考えています。専門家と言えるほどの知識は不要ですが、専門家と専門用語で会話ができる程度は欲しいというイメージでしょうか。
なぜなら、実際に専門家と会話する機会があるでしょうし、プロダクトを使用するユーザーのことや取り巻く環境について知らなければ、ビジネス要件の本質を理解することが難しいと考えるためです。

では、テクニカルプロダクトマネージャーを志す人が、事前に対象プロダクトのドメイン知識を持っている必要はあるのでしょうか。
結論としては、ほとんどのケースで不要と考えます。もちろん無いよりはあった方が良いです。しかしながら、その道の専門家になるわけではないので、多くの場合、職についてから学べば十分なはずです。
テクニカルプロダクトマネージャーの求人票でも求められるケースは少ないでしょう。

思考力

ビジネス要件の本質を理解するには、インプットした情報を基に思考することが必要です。「真の課題は何なのか」「ユーザーはなぜ困っているのか」「ユーザーはどうなると嬉しいのか」「理想的な状態になるのを阻害する障壁は何か」など、本質に迫る「問い」はいろいろあると思います。
ビジネス要件からそれらの「問い」の答えが簡単に分かるようなら良いですが、実際には多くの場合、難しいでしょう。
なぜ難しいのでしょうか。理由は大きく3つあります。

1つ目は、多くの場合、ビジネス要件そのものが単純明快ではないというのが挙げられます。もちろん中には単純明快なものもあると思いますが、もし仮にあるプロダクトのビジネス要件が簡単に理解できるものばかりだとしたら、解決する価値が低い課題を解決しようとしている疑いが強く、プロダクトが成功するか怪しいと思います。
全てとは言いませんが、解決するのが難しい課題ほど本質を理解するのも難しく、だからこそビジネス要件になっていると言えます。

2つ目は、ビジネス要件を担当する側の事情で、質が高いビジネス要件を準備できないことが往々にしてあるということです。
主要なケースとして、担当者のスキル不足に起因するケースと、事業環境起因でとにかく走り出さないといけないケースがあります。
前者は分かりやすいケースかと思います。ありがちなのは手段が目的化してしまうケースでしょうか。
後者はビジネス要件にすべき事項の解像度がそこまで高くはないけど開発に進むという状況なのですが、本来それはやってはいけないことです。価値を提供できるか確信がないのに開発を進めようとしているのですから。しかしながら、現実は理想通りにはなかなかいかないものです。特に新事業でリソースが限られている場合やそもそもリソースが乏しいスタートアップにおいては、ビジネス要件を固めるためにPoCやユーザーインタビューをみっちりやるような余裕はないでしょう。
また新たな市場を生み出そうとしているプロダクトも後者に該当すると思います。参考にできる先駆者がいないため手探りになりますし、ユーザーにとっても未知の世界であるため、ユーザーインタビューをしたところでどこまで核心に迫れるか怪しいものです。手っ取り早いのはとにかく市場に投入してみて、フィードバックを得るということになります。
ビジネス要件にすべき事項の解像度が高くない場合、結果としてビジネス要件の抽象度も高くなり、決して質が高いとは言えないビジネス要件が出来上がるでしょう。

3つ目は、ビジネス要件は前提知識ゼロの人を思考無しで「本質を理解する」状態まで持っていくことを目的としていないからです。
多くの場合、ある程度前提知識がある人を受け手として想定していて、受け手は行間を埋めることを期待されています。
これをビジネス要件を担当する者の怠慢だと言う意見もあるかもしれませんが、現実問題として何もかも言語化するわけにはいきません。
極端な例ですが、高校数学の教科書を作るとして、理解するには算数レベルから中学数学に至る一定の前提知識が必要ですが、それらを一から語るようなことはしません。
「何もかも言語化するわけにはいかない」というのはまさにそういうことであり、ビジネス要件を作る際は一定の前提知識がある人を対象にせざるを得ないのです。リソースが限られていたり、事業の成長スピードを求められている組織であればなおさらです。

いろいろ語りましたが、要は「これさえ読めば誰でも本質を理解できるビジネス要件」なんてものは存在しないし、目指してもいないので、受け手には思考力が必要ということになります。
テクニカルプロダクトマネージャーという立場上、どんなビジネス要件であれ向き合わねばなりません。質が低いほどその本質を捉える難易度が高く、思考力が試されます。あまりに質が低ければ「何が分からないかも分からない」という状態にもなるでしょう。そんな状況でも1つずつ情報を紐解き、ビジネス要件の担当者に確認しながら、解像度を上げていく必要があります。

ビジネス要件を理解する際の思考の要素としては以下のようなものが挙げられます。

  • インプットした情報を整理する

  • 疑問点を洗い出し、問う

  • As is / To beに落とし込む

  • 具体と抽象を行き来しながら解像度を高める

  • 仮説を立てる

ここで挙げたものが全てではありませんし、唯一の正解でもありません。
ある程度経験がある方は自分なりにインプットした情報を処理する手法を身に付けていると思いますが、それで良いのです。
思考法については様々な方法論やフレームワークが存在し、ビジネス書も多く出版されている奥深い分野です。いろいろな手法を試しつつ、自分に合ったやり方を構築し、磨いていくのが良いでしょう。

熱意

熱意については意外に思うかもしれませんが、ビジネス要件を理解する難易度が高いほど重要性が増すと考えています。
では「熱意」とは何でしょうか。
「情熱」「意欲」「執念」とも言い換えられるかもしれません。
平たく言うと「このビジネス要件を何としても理解し、実現するんだ、という強い気持ち」とでも言うのでしょうか。
急に精神論のような話になったため、疑問を持った方もいると思いますが、成果を出すためには間違いなく重要な要素です。何事も最後に結果を左右するのはメンタルというケースは思いのほか多いものです。
理解が難しいビジネス要件を前にして、完全には理解できていないけど途中で諦めるか、腹落ちするまで必死に粘るかで、結果に差が出るものですが、この差はスキルの差というよりメンタルの差です。もっともメンタルのコントロールもスキルの1つと言えなくもないですが。

では、どうすれば熱意を持てるのでしょうか。
特に何もなくても自らモチベートできる人もいるとは思いますし、それはそれで素晴らしいことです。
私が重要な要素と考えているのは、携わっている事業やプロダクトが目指す世界への興味や共感です。人は興味や共感がなければなかなか意欲が湧かないものです。
興味や共感は必須とまでは言いませんが、あると無いとでは大きく違います。「好きこそものの上手なれ」とはよく言ったもので、興味があるからこそ意欲が湧き、意欲があるからこそ自分事となり、成果に繋がり、どんどん楽しくなるという構図はあると思います。

次回へ続く

いかがでしたでしょうか。
今回はテクニカルプロダクトマネージャーに必要なスキルについて語りましたが、長くなりそうなので今回はここまでにし、続きは次回にしたいと思います。
ご期待ください。

いいなと思ったら応援しよう!