スタートアップでプロダクト開発する価値は速い馬をつくらなくてよいこと
プロダクト開発の現場
プロダクト開発ではユーザーとの協力関係ができてないと、速い馬をつくることが求められる。速い馬をひたすら効率よくつくることが正義になる。
そういうイージーな開発は短期的にはみんなに喜ばれるが当然すぐに行き詰まる。
速い馬とは
受託開発でありがち
ユーザーは自分が欲しいものをうまく言葉にすることはできない。だからそれを言語化して解決するスキルを持った人や企業が価値を持つし事業として成り立つ。
しかし、世の中には速い馬をつくるのが正解だと思ってる営業や開発責任者がけっこうな割合で存在する。
というか場合によっては契約の問題上で本質的なニーズを探索することが不可能なことがある。とくに受託で且つマルチベンダーになると開発の難易度が果てしなく上がる。
（※受託開発は発注する会社、受注するSIerごとに世界が違うので一概に語れるものではありません。ここで言いたいのは、本質的なニーズと解決すべき課題を探索するにはユーザーやプロダクトチーム全員との協力関係が必要だと言うことです）
事業会社でもありがち
しかしこれは事業会社で内製で開発していても起きる問題である。
部署間の縦割りや力関係などで如何様にも役割は固定化されて速い馬を生産することが正義になりうる。
本質的なニーズを探るよりもとりあえず速い馬を作って出してしまった方が考えることも少なくて簡単にできるからトラップだと思っても誘惑に逆らうのが難しい場面もある。
速い馬トラップをどう避けるか
そのトラップを避けられることがスタートアップでプロダクト開発する大きな価値の一つである。もしそれができてないのならスタートアップである意味がない(と自分は思う)。
これはプロダクトを開発して運用するチームのメンバー全員が持つべき態度であり姿勢である。
一部のリサーチャーやデザイナーやPdMだけがやればよい問題では決してない。
と言うか、速い馬をいかにプロダクトやサービスとして価値を持たせる方向に再定義するか、その解くべき課題の問の形を整えることこそ、プロダクト開発の一番の醍醐味ではなかろうか。
幸い、現職のリーナーでは職種を超えたプロダクト開発ができて助かっている。
とりあえず試作品を作って素早く仮説検証することは悪いことではない
速い馬トラップを避けるために本質的なニーズをユーザーの協力を得ながらチーム全員で探索する必要がある。その探索のために敢えて雑な状態でリリースしてユーザーに使ってもらうことはよくある。それはそれ。重要なのはユーザーとプロダクトチームの全員がお互いに期待値を丁寧にコントールすること。そしてそのための信頼関係を育むこと。
それを追求することが自分の仕事である。
Discussion