受託脳なシステムエンジニアではプロダクトマネージャには向かない

数年前からリーンやスタートアップが取り上げられるようになってそれを追いかけるようにプロダクトマネージャのタイトルがついたエントリや本がちらほら出てくるようになってきたように感じています。

プロダクトマネージャー制度を導入するにはどうすれば良いのか　をよみながら、日本には製造業があって昔からものづくりの点ではプロダクトマネージャと読んだかどうかは別だけれどそれに相当した人たちはいたんだからその素養を持つ人たちは一定量いるだろうなぁ、と思いつつスクロールするのです。

米国ではPMと略せばプロダクトマネージャだと　Rebuild - Podcast by Tatsuhiko Miyagawa　で聞いたような気がするんだけど本当なのかしら。日本では、プロダクトマネージャという呼称はまだ定着していないと思っているのでPMと略されていると脳内でプロジェクトマネージャと補完されてしまうのでとてもややこしく感じながら読み進めるわけで。個人的には同音異義の場合はフルスペルで書いて欲しいなぁ。

冒頭のブログのリンクとなっていたプジェクトマネージャとプロダクトマネージャのスキルセットは違うと言うところのくだりはとてもよくわかるんですよ。実感したかったら、リーンキャンバスやビジネスモデルキャンバスを１０個くらい書いてみると実感します。だいたい１０個も書けないですよ。

とくに、今の仕事が受託開発で要件を聞いてシステムを実装しているようなプロジェクトの経験しかしていないシステムエンジニアなら。十中八九キャンバスに向かうと手が止まります。キャンバスを書く慣れの部分を考慮して差っ引くとしても書けないんです。

なぜかというと、日頃プロダクトについて考えることしていないから。プロダクトをどのセグメントを狙うのかだとか、そのプロダクトでユーザに価値を体験させるのかとか、ビジネスとしてどう成り立たせるのかとか。一番なのは、プロダクトを実現して世に出したいかとどれだけ思って実現に向けて動いているか、です。

ある機会にワークショップでビジネスモデルキャンバスを書いてもらったら、慣れの部分を差し置いてもほとんどのシステムエンジニアが書けなくて「ワークショップどうしよう…」と思いましたもの。体験的なワークショップでしたが事前に宿題を出しておいてコレですからどれだけ普段「受託脳」に染まっているかと。それはそれでそういったビジネスでは必要なので大事にして欲しいですが、プロダクトマネージャとプロジェクトマネージャと違うように、プロダクトと関わるシステムエンジニアは受託脳ではちょっと問題になるんだろうなぁ、と。

だって受託脳なシステムエンジニアは与えられた課題は解決してくれるけれど、自分たちで製品を開発していくような課題を自分で設定していく経験の機会が圧倒的に少ないから。

それと、システムエンジニアは目の前の課題を技術で実装して解決するのは得意な人が多いです。ワタシは敵わないスキルエリアです。そうしたスキルエリアを得意とするシステムエンジニアは課題＝実装と緋も付くのでプロダクト開発で肝心なプロダクトの優位性であるプロダクトの価値やユーザがそれを利用したいと思うなぜを置き去りにしちゃうんですよね。だから、解決する手段、ツールの名前がキャンバスの中に出てくる。

それってもうユーザが利用して価値を感じることより課題解決をすることでシステムエンジニアが満足するために置き換わっている状態だと思うんです。キャンバスがそうなっていたら危ないですよ。

プロダクトの価値は世の中にある似て非なるプロダクトの中から自分のプロダクトを選んでもらってユーザの不便や面倒臭いを代替したり、興奮を与えることです。その価値を理解できるためにはそれはそれで別のエリアのインプットと訓練が必要かと。