見出し画像

テクニカルプロダクトマネージャーとして考えていること#1「テクニカルプロダクトマネージャーの役割①」

パンサー師匠

フルカイテンでテクニカルプロダクトマネージャーを担当しているパンサー師匠です。
今回は私が考えるテクニカルプロダクトマネージャーの定義を紹介すると共に、役割の1つである「プロダクト開発においてビジネスと技術のバランスを取る」について語りたいと思います。


テクニカルプロダクトマネージャーとは？

テクニカルプロダクトマネージャーという職種は比較的新しい職種かと思います。世間一般でどの程度定着しているかは分かりませんが、「何それ聞いたこと無い！」という方や「プロダクトマネージャーは分かるけどテクニカルプロダクトマネージャーって何？」という方もいるのでは無いでしょうか。
私が考えるテクニカルプロダクトマネージャーの主な役割は以下の2つです。

  • プロダクト開発においてビジネスと技術のバランスを取る

  • ビジネス要件と開発チームの橋渡し役

これらの役割を見て、皆さんはどう思うでしょうか。
「これCTOの役割では？」と思った方や「うちのテクニカルプロダクトマネージャーとは役割が違う」と思った方もいるかもしれません。
実際のところ、組織によって肩書と役割の関係は異なるので、先に挙げた役割をテクニカルプロダクトマネージャーが担当している組織もあれば、別の肩書を持った人が担っている組織もあるかと思います。中には誰も担当していないという組織もあるかもしれません。
重要なのは肩書より役割ですが、テクニカルプロダクトマネージャーを無理矢理定義するなら、以下でどうでしょうか。

プロダクト開発を行う組織における1つのポジションであり、(ビジネス寄りの)プロダクトマネージャーと共にプロダクトの成功に責任を持ち、プロダクト開発においてビジネスと技術のバランスを取りつつ、ビジネス要件と開発チームの橋渡し役を担う者

今回はテクニカルプロダクトマネージャーとは何か？の解像度を上げるために、先に挙げた役割である「プロダクト開発においてビジネスと技術のバランスを取る」について深堀りしてみたいと思います。

ビジネス要件を決めるのは誰か？

多くのプロダクト開発は、動機の起点、つまりなぜ作るのか？というのはビジネス要件ということが多いのではないでしょうか。プロダクトとはその利用を通じてユーザーに何かしらの価値を提供するものです。どのような価値を提供するのかの定義がビジネス要件となります。

ではビジネス要件は誰が決めるのでしょうか。
経営陣がトップダウンで決める組織もあると思いますし、テクニカルプロダクトマネージャーのカウンターパートとなるビジネス寄りのプロダクトマネージャーが決めることもあると思います。ですが、誰が決めるにせよ一つ共通していることがあります。それはプロダクトが扱う領域に精通した人という点です。
「あれ、うちは違うな」と思った方は危険信号です。もしビジネス要件を決める人が、その領域に精通した人では無い場合、そのままではプロダクトが失敗する可能性が高く、プロダクト開発を始める前にそこに目を向けるべきかもしれません。例えば、専門家をチームに加える、ユーザーインタビューにより知識を付ける等、対処のしようはあると思います。

話がそれましたが、ビジネス要件の定義を担当する人は、その領域についての専門知識を持ったビジネスサイドの人であることが多く、技術的な専門知識を持っているケースは少ないのでは無いでしょうか。
なお、ここでは多くは語りませんが例外はあります。例えば、エンジニア向けのプロダクトであれば、エンジニア自身や経験者がビジネス要件を決める立場にあるのが普通ですし、その場合は当然、ビジネス要件を定義する人が技術的な専門知識を持っています。

ビジネス要件はユーザーにとっての理想を定義する

技術的な専門知識を持たない人がビジネス要件を決めるとどうなるでしょうか。当然ながら技術的な実現可能性や費用対効果を考慮していない要件ができあがります。これを聴いて、エンジニアの方は顔をしかめてしまうかもしれません。「うちのビジネスサイドはいつも無茶な要望を挙げてくるんだよな・・・」という記憶と共に。

しかしながら私の考えでは、ビジネス要件を決める時は、技術的な側面は一旦無視して、ユーザーにとっての理想は何か？を徹底的に追求すべきだと考えます。なぜなら、理想を言語化し、組織内での共通認識とする意義はとても大きいからです。組織が一つとなるためには共通の目標が必要です。「ユーザーにとっての理想」は共通の目標としてうってつけでは無いでしょうか。ビジネス要件を考える際に、技術的な実現可能性や費用対効果を考慮してしまうと、理想がぼやけて本質が見えにくくなりますし、ビジネスサイドと開発チームで認識がズレる要因になったりします。

ビジネス要件を定義する人は、最低限のITリテラシーはあってしかるべきですが、技術的な専門知識は無い方がむしろメリットが大きいのでは？と思うこともあります。なぜなら、技術的な専門知識があると、それがユーザーにとっての理想を考える際の足かせとなることがあるためです。無意識のうちに、考える領域が実現方法を想像できるものに閉じてしまうのです。この辺りは分かっていても意識して打ち破るのは困難であり、技術的な専門知識を持たない人がビジネス要件を定義する1つのメリットだと考えています。

プロダクト開発においてビジネスと技術のバランスを取る

ユーザーにとっての理想を徹底的に追求したビジネス要件は、多くの場合、そのままでは実現不可能です。だからこそ、ビジネスと技術のバランスを取る必要があるのです。
一言「ビジネスと技術のバランスを取る」と言っても、いろいろな要素が存在します。例を挙げると以下のような点があるのでは無いでしょうか。

  • 事業計画との整合性

  • 開発期間

  • 開発コスト

  • 運用コスト(インフラコスト含む)

  • システム性能

  • 仕様検討の困難さ

  • 実装の困難さ

  • 実現したい要素同士のトレードオフ

ビジネス要件を踏まえて、上記のような点を考慮しつつ、実際にどんな開発を行うか決めていくことが、テクニカルプロダクトマネージャーの1つの役割になってきます。
考えていく中で、ビジネス要件のうち実現できないことも出てくるはずです。実現はできるけど開発期間がかかりすぎて事業計画と合わないということや、運用コストがかかりすぎて事業として成立しない、ということもあると思います。そういった様々な要素を引っくるめて、何を作るのか・何を作らないのかをビジネスサイドと調整しつつ決めていく。それこそが「プロダクト開発においてビジネスと技術のバランスを取る」という役割になります。

まとめ

いかがでしたでしょうか。
今回は、私が考えるテクニカルプロダクトマネージャーの定義を紹介すると共に、役割の1つである「プロダクト開発においてビジネスと技術のバランスを取る」について深堀りしてみました。
次回は私が考えるもう1つの役割である「ビジネス要件と開発チームの橋渡し役」について語りたいと思います。

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