プロダクトマネージャーとしての学び
Pivotal Labs で働いて4年が経とうとしています。本題に入る前に、Pivotal Labs という会社を知らない人が大半だと思うので、弊社のこちらのブログ記事に詳しく書かれていますので、ご参考ください！
Pivotal Labs はクライアントから依頼を受けて、ソフトウェアを開発しています。しかし、受託開発を行っているわけではありません。私達のゴールは、案件終了時にはクライアントが自分たちのみで持続的に良いプロダクト開発のプロセスを継続することができ、かつ新しいメンバーにその手法を教えることができる状態になっていることです。
Pivotal Labs のプロダクトマネージャーとしての経験は非常に貴重で、今後の自分のプロダクト開発との向き合い方を改めてくれたような気がします。この学びをプロダクト開発に携わる、主にプロダクトマネージャーのみなさんにご紹介したいと思い、この記事を書いています。この会社に入った当初は働き方含めてすべてが新しくて、軽いパニックになっていたのですが、その中でもとびっきりの学びをひとつだけ。それは「何を作るかよりも、何を作るべきではないのか、という視点に比重を置いてプロダクトを開発すること」です。
計画は信頼できなくなる
VUCA ー Volatility（変動性・不安定さ）、Uncertainty（不確実性・不確定さ）、Complexity（複雑性）、Ambiguity（曖昧性・不明確さ）時代の到来とよく言われています。様々な業界、業種、組織、文化をお持ちのクライアントとお仕事をさせていただいていると、本当にその通りかもしれないと実感することが多々あります。同僚とも話していて感じたのは、これまでの経営哲学は結果を予測可能にするために計画とコントロールを重視してきたが、変化の早さが最大の脅威となったとき、計画や予測は信頼しにくくなる、ということです。それはとても身近な問題として、表面化してきているように思えます。現に、PDCA について指摘されているこちらの記事はとても腹落ちしました。
PDCAが前提としているのは、あくまで “想定外のことが起きない” 世界。つまり、「常に安定しており、かつ心理や感情など人間的要素が関わらない環境」の中で継続的に改善を繰り返して品質を高めていくというシーンで使うのであれば、確かに有効なのです。しかし、“いつも想定外のことが起きる” “昨日と今日で状況が変わる” といった「先がまったく読めない」環境では、そもそも最初の「P（計画）」の立てようがありません。そこでPDCAにこだわりすぎると、かえって物事が前に進まなくなる原因にもなり得るのです。
そのため、新規事業であれ、新しい機能開発であれ、プロジェクトの上流で市場調査やユーザー調査の結果をもとにした要件定義に膨大なコスト（時間や予算）をかける傾向にあります。なぜなら、失敗するリスクを避けるためです。
ところが、時間の経過と共に変化の早さに対応することが困難となるため、後工程にしわ寄せが生じてしまい、プロダクト開発そのものがコントロール不能となってしまうという別のリスクが姿を現します。そのため、「この先の全体像が見えなくて不安」「どんなモノがいつできるかわからない」と言った心配が絶えなくなります。
プロダクト開発は賭けである
プロダクト開発は賭けのようなものです。それは避けられません。なぜなら、世に出さないとわからないことが多いからです。できることは、賭けを小さくして失敗するリスクを可能な限り低くすることです。
多少編集しましたが、ぼくが尊敬する上司の言葉です。ここで記載の失敗するリスクとは、ものを作るまでの時間に対して間違ってしまうものを作ってしまい、結果としてユーザーに使ってもらえないリスクのことを指します。小さな賭けで、小さな成功を積み重ねることが、現代のプロダクトにおける生存戦略なのかもしれません。
Pivotal Labs は、Lean XP という開発手法を用いて上記の実現をサポートしている会社です。そのような働き方を4年も続けていると、自分の中でプロダクト開発に対する価値観が変わっていることがわかりました。これまでは、誰に何をどのようにプロダクトやサービスを届けるべきなのかを強く自問しながらプロダクトデザインやプロダクト開発に携わってきました。
ところが、Pivotal Labs のミッションである『Transforming How the World Builds Software（世界中のソフトウェア開発そのものを変革する）』を体現するためのアプローチや手法を学んでいく中で、徐々に自分のとってのプロダクトマネジメント論が確立されていきました。
ぼくが考えるプロダクトマネジメントとは、仮設検証という小さな賭けを繰り返しすることで「つくるべきではないもの」は何かという学びを最大化し、失敗による被害を最小限に留めてプロダクトを成功させること。そして、実現に向けてチームの強みを活かしながら、ユーザーに価値を提供し続けることができるような組織文化を浸透させること。
プロダクトマネージャーの Job Description（職務内容）は様々で十人十色ですが、ぼくが大切にしているプロダクトマネジメントはこの通りです。今の会社には、本当に感謝しています。
何を作るべきではないのかを考える
話を戻しますが、Lean XP の実践的なアプローチやマインドセットはこれまでのブログ記事などでもご紹介していきましたが、本質にあるのは「何を作るかよりも、何を作るべきではないのかに比重を置いてプロダクトを開発すること」です。世の中的にみても、同じ思考に傾いてきている気がしなくもないです。
当時話題になった、Microsoft Word 2000 の UI
よくあるプロジェクトのケースだと、要件をできるだけ盛り込み、完成形と呼ばれるアウトプットが始めに描かれることが多く、あとはその実現に向けて「どう作るか」という思考のみが働き、約束という名の計画が練り上げられていくことが多いようです。
ここでの落とし穴は2つあります。
- 一度決めたアウトプットに対して疑いを持たなくなること（持つことができないこと）
- 計画通りに行かないとコントロール不能になり炎上すること
Lean XP ではこの落とし穴にはまらないように、開発をしながら先行してユーザー調査を繰り返し、想定されるアウトプットに対しての評価を元につくるべきではないもの（機能含む）を特定し、排除すること＆新たなる課題やソリューションの種を拾いながら検証済みのモノを開発します。結果として、より良いモノが生まれやすくもなります。
下記のアーミーナイフの図がとてもわかりやすいです。右が必要だと考えている最終形のアウトプット、左は実際にユーザーが求めている理想的なモノの対比です。
Copyright (c) Anton Nikolov 2017
つまり、先に作る予定のモノは、必要であることがわかっている物のみに絞られていきます。これを次々と繰り返すことで、何を作るべきか、必要なもののみを積み上げた理想形に近づけることができます。
どう作るかにプロダクトの運命を委ねない
完成形は存在しないと思っています。それは、サービス提供者側が勝手に考えたアウトプットにしか過ぎません。重要なのは、ユーザーが頭に描いているアウトプットなのではないでしょうか。
生活様式が変わったり新しいサービスが次々と登場する世の中において、変化が早いのは当然だと思っています。そして、計画や予測は信頼しにくくなるのは当たり前だと思っています。だからこそ、賭けに出る姿勢（アプローチ）が必要なのです。
Lean XP は奥が深く、現代に求められている開発手法だとは思いますが、他の開発手法と比べて最も優れているとは思っていません。そう言ってしまってはもともこうもありませんが、プロダクトの運命を「どう作るか」に委ねるのではなく、「何を作らないで、何を作るべきか」に全ては掛かっているのです。
最後に…Pivotal Labs Tokyo ではプロダクトマネージャーを募集しています（2020年8月時点）もしご興味があれば以下のリンクよりご応募いただくか、このサイトのコンタクトフォーム経由でぼくの方までご相談ください！お待ちしてます。
Product Manager: Pivotal Labs (VMware Tanzu) in Tokyo, Japan | main
プロダクトマネージャー Product Manager (Pivotal Labs) VMware Pivotal Labsについて1989年に設立されたPivotal Labsは、数々の大手企業に対してアジャイル型ソフトウェア開発のコンサルテーションを提供してきました。2019年にはVMwareの一部となり、今後はそのビジネスをさらに拡大、加速させていきます。 求める人材 …
