2021-05-23

プロダクトオーナーという仕事

俺はITエンジニアをしていて、ベンチャーSIerなどで自社、顧客企業を問わず今まで多くのWebシステムを作る案件に関わってきた。

そして多くの上手くいかないプロジェクトを見てきた。

今日は俺が得た示唆を共有したいと思う。

結論から言うとプロダクトオーナーが一番大事だ。

プロダクトが上手くいくもいかないも、プロダクトオーナーが全てだ。

特にWebサービス場合ビジネスサイド、ITエンジニアデザイナーという3つの職種がチームを作ってプロダクトを開発していくことになる。

その場合プロダクトオーナービジネスサイドが務め、テックリードがPdM補佐のような形になるだろう。

SIer場合は、顧客企業の窓口となる人がPOを努め、開発会社マネージャーテクノロジーを統括することになる。

そして大抵の場合ビジネスサイドの人間POを務めると、「声のデカステークホルダー」となり、チームを引っ掻き回し、プロダクトを迷走させ、モチベーションを下げさせるのだ。

だってそうでしょう!?プログラミングも、DBでのデータの持ち方も、他社のAPIの使い方も、UIデザインも、いくつかあるUI選択肢とそれを実現する工数も、何も分かってないんだから。そんな人間が最終意思決定者をやるんだから、上手くいくはずない。

だいたいMVPにはふさわしくないリッチUI要求してきたり、難しい実装工数のかかる機能要求してくるのだ。そしてその実装工数がかかるのは、エンジニアの怠慢、スキル不足だと考えている。

本来であれば、機能の過不足については、ユーザーがやりたいこと、こちらがやらせたいことが実現できているかどうかだけを考えるべきなのだ。それがどういう形のUI提供されているか。別ページなのか、モーダルなのか。ボタン押下で動作するのか、JavaScriptインタラクティブ操作ができるようにするのか、ビジネスサイドがこだわり主張するべき所ではない。

そもそもエンジニアは1+1=2になる世界で生きているが、営業というのは顧客口説いて意思変容させるのがミッションだ。現実を歪めるのが職務なのであるエンジニアエンジニア工数は変えられないものだと理解しているが、営業はそれも「なんとかできるはず」と考えてしまうのだ。

仕事には内部に向けるエネルギーと、外部に向けるエネルギーの2つがある。そして、外部に向けるエネルギーをどれだけ大きく出来るかがビジネス成功に繋がる。

ビジネスサイドの何もシステムの専門知識の無い人間POをやると、思いつきで「あれはどうなの」「こうしたらどうなの」って言って、エンジニアデザイナーという専門家が「それは難しいです。なぜなら技術的に…工数的に…タイミング的に…」という話をして、仕事に使えるエネルギーモチベーション時間も、POを説得するという「内部に向けるエネルギー」に消費してしまうことになるのだ。

色んな専門家が集まって、それぞれの専門領域を発揮し、お客様価値を与えるプロダクトを作り、金を稼ぎたい。だからこの仕事をやっているのに、なんで何も分かってないPO自分存在意義を発揮するためのだけのオ◯ニープレイを説得することに毎日忙殺されているんだろう。馬鹿じゃないかしら。

そういうPOを補佐するために有能なPO補佐がいるんですよという話もあるが、どうせ人の話を聞かないんだからPO補佐がいたって意味ないです。

そしてそれができるバランス感覚説得力を持った有能なPO補佐がいるんだったら、その人がPOをすべきだ。お前じゃない。

過去会ったことのあるPOには、エンジニア出身ダメなやつもいた。この現代において生PHPStruts時代で止まった知識を振りかざし、自分知識があると勘違いした痛いやつが。もっとも彼は元エンジニアであって、エンジニア辞めた後はかなりの年数を営業としてやっている人間だったが。

から俺は、POは現役エンジニアがやるべきだと思う。技術オタクCTOというよりは、VPoEの立場の人がやるのが一番いいかな。顧客無視したエンジニアリングオ◯ニープレイをしない、ちゃんカスタマーサクセスUXへの費用対効果を考えられるエンジニアだ。

そして営業/マーケターはサービスを売りつつ、顧客の声を聞き、顧客の抱えてる課題発見し、それをチームに伝えてくれたら良い。ソリューションエンジニアデザイナーが考えるので。

ある程度会社が大きければ、エンジニアプロダクト開発のトップに据える、そういう責任移譲もできるだろう。

しか問題ベンチャーである

ベンチャーあるあるとして、ビジネスモデルは考えられるけどプロダクトモデルを考えられない営業人間起業して、「俺の考えたビジネスモデルを実現するに協力してくれるエンジニア募集!」とか言ってチームを作り、社長POを務めることが多い。

でもその社長に、POとしての職責が果たせるかどうか、スキルがあるかは別な話である。というか大抵の場合、無い。

声のデカワンマン社長の言うことを聞いて、クソなものをクソだと思いながら作り、社長VCプレゼンして調達したお金を啜って生きていくのがベンチャーでのエンジニアライフである。オワリです。

ベンチャーで上手くいくのは、エンジニアでありながら希なプレゼン能力コミュ力を持った、エンジニア社長がいる会社しか見込みがない。

これを読んでるあなたがもしビジネスサイド出身社長さんであれば、あなた仕事プロダクト開発にズカズカと踏み込んでいって、思いつきで喋って、自分のこだわりを入れるように怒鳴り散らすことではありません。

課題は無いか耳を傾け、解決できそうな人を連れてきて、お金を出すだけに徹するように下さい。

それができないのであれば、あなたWebシステムという無限拡張性があるものからお金を得ることはできません。愚直な営業と手作業バリューを出すという、労働集約型の仕事を一生全うしてください。

そしてこれを読んでるあなたがもしエンジニアであれば、ビジネスサイドにプロダクトの決定権を握られている状況ではエンジニア幸せになれることは決して無いので、ビジネスの作り方やマーケティングを学んで、エンジニアビジネスを握っていこう。プログラミングを修得するのに費やした時間努力ビジネスサイドにも発揮すれば同じように身につけられるはずであるビジネスサイドに顎で使われる存在から抜け出していこう。

星野リゾートの例

星野リゾートではどのようにして旅館現場出身者をIT人材へ育成したのか?【デブサミ2021】 (1/3):CodeZineコードジンhttps://codezine.jp/article/detail/14017

これはすごいですね。非エンジニア出身POでありながら、ちゃんプロダクトを成功へ導いている。

ここでの例では2例あって、社内システムと、社外のお客様向けのシステムだ。

社内システムはノーコード活用して、自分たちで作って自分たちで運用するようにした。いいですね。非エンジニアの思いつきをエンジニアに作らせる、という動きにはなっていない。自分の思いつきのケツはちゃん自分で拭け、他人迷惑をかけて対処しようとするな、ということだ。

社外向けのシステムを作るに当たっては、ちゃん自分たちをIT人材に変化させていくための勉強ちゃんとしている。エンジニアと同じ目線に立って同じレベルで話ができるようになっている。これだといいですね。

やっぱり、Webシステムを作るPOは、営業出身ならめっちゃITのこと勉強すべきだし、それが嫌ならITで金儲けしようということからは降りるべき。

  • 単純にビジネスもプロダクト(技術)もわかる人が必要というだけでは?

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん