技術スタックとかアーキテクチャ、設計論、そういうことを多く考えてい気がするんですが、2023年から新規事業開発を担うようになって、それだけじゃダメだって気づかされました。
でも、喉元過ぎれば色々忘れる。あの頃は「せやな」って思ってたんですが、いつの間にか忘れてしまう。 基本に立ち返るのは大事だなと。この手のヤツは自分でゼロから考えるものではないし、それで手に取ったのが、Marty Caganの『INSPIRED熱狂させる製品を生み出すプロダクトマネジメント』です。
この本が何を教えてくれるのか
『INSPIRED』は、シリコンバレーの現場で培われたプロダクトマネジメントの知見をまとめた本です。ノウハウ本じゃなくて、「なんで多くの会社は良いプロダクトを作れないの？」っていう、根本的なことを掘り下げてます。
あるある話として、「アジャイルやってます」って言ってる会社でも、イノベーションが起きない。MVPに何ヶ月もかかる。アジャイルって言いながら、実は昔ながらのウォーターフォール的な考え方がそのまま残って終わる。
じゃあどうすればいいのか。この本は3つの原則を提示しています。1つ目は、リスクには最後じゃなくて最初に取り組むこと。価値、使いやすさ、実現可能性、ビジネス的な実現性っていう4つのリスクを早めに検証しようって話。2つ目は、プロダクト定義とデザインを同時並行でやること。プロダクトマネジャー、デザイナー、エンジニアが一緒に働く。3つ目は、アウトプットじゃなくてアウトカムを見ること。機能を実装することじゃなくて、ビジネスの成果を出すことが目標だよねってです。
開発チームが「傭兵」になると何が起きるか
伝道師チームと傭兵チーム
一番グッときたのが、シリコンバレーのベンチャーキャピタリスト、ジョン・ドーアのこの言葉です。
「私たちが求めているのは伝道師のチームだ。傭兵のチームではない」
伝道師のチームっていうのは、ビジョンを信じて、顧客のために問題を解決しようと本気で取り組むチームのこと。使命感があって、大企業でもスタートアップみたいに動ける。自発的にやってる。 一方で傭兵のチームは、お金のために、「言われたもの」を何でも作るチーム。「なぜ」を問わない。創造性や判断を期待されない。
なんで傭兵チームが生まれるのか。営業チームとかステークホルダー、顧客からのアイデアを、プロダクトマネジャーが集めて文書化して、エンジニアに渡す。エンジニアは「言われた通りに実装する」。一見すると、顧客の声に耳を傾ける良いプロセスに見えるけど、でも、この構造だと開発チームに権限が渡らない。
わかるわ。エンジニアとして「要件書いて」ってプロダクトマネージャーに言ってたことあるわ。プロダクトマネージャーとして、「これ作って」って言ってるわ。開発チームに「これ作ってください」って渡すとき、「なぜこれが必要なのか」「どんなアウトカムを目指すのか」をちゃんと説明できてなかった。「たぶんこんなものが必要だから」で済ませて、実装してもらって、リリースして、使われない。アウトプットを出すことが目的になって、アウトカムから目を逸らすんだよね。自分としても、周りからも、「やった感」は出せるから。
権限がないと創造性も死ぬ
本に書かれているように、エンジニアとデザイナーこそがイノベーションの源になる。技術的に何ができるかを一番わかってるのはエンジニアだし、ユーザーの行動や心理を深く理解してるのはデザイナーになる。少なくともべき論としては。でも、傭兵として扱われると、その創造性が封じ込められてしまう。
傭兵文化が壊すものは、モチベーション、創造性、責任感など。「要件通りに作った（から、うまくいかなくてもおれのせいじゃない）」「どうせ提案しても意味がない（wikipedia:学習性無力感）」「失敗しても自分のせいじゃない」。こういうマインドが組織に広がると、優秀な人から辞めていく。そして、「何を作るべきか」を考えるプロダクトマネジメントが失われて、「どう作るか」「いつまでに作るか」を管理するマネジメントだけが残される。本来は両方必要なのに。
「このモデルでの役割は、エンジニアのために要求事項を集めて文書化することが中心になっている。この点において、現代のITプロダクトマネジメントの実像とは180度違っていると言わざるを得ない」
振り返ってみると、僕も「豚に口紅」的な開発やっていたのかもしれません。ユーザーと何度も話して、観察して、本質的な問題を理解しないと、良いプロダクトなんて作れない。そうなんだよな、たしかにな。
ロードマップ駆動開発の罠
もう1つ、この本がバッサリ切るのはロードマップ駆動の開発プロセス。 リーダーがアイデア出して、ロードマップ作って、各アイデアのビジネスケース作る。どれくらい儲かるか、どれくらい時間とお金がかかるか。優先順位つけて、開発チームに「これ作って」って依頼する。開発チームはアジャイルで素早く実装する。
パッと見は現代的に見えるこのプロセス、全体で見たら旧来のウォーターフォールだと切られる。
「公正を期して言うが、エンジニアの多くは、設定された大きなウォーターフォールプロセスの中でできるだけ素早く仕事をしようとしている」
エンジニアは「アジャイルで素早く開発」してるけど、何を作るかはもうロードマップで決まってる。開発してる途中で「あれ、これって顧客にとって価値ないんじゃない？」って気づいても、ロードマップを変えるのは難しい。結局、環境に適応することなく「素早く、もう無駄なものを作る」ことになる。
もっと困るのが、製品開発で「利益」と「費用」を事前に正確に予測するなんて、めちゃくちゃ難しいということで。顧客が本当にそれを使うかは、リリースしてみないとわからない。技術的にどれくらい大変かも、実装始めないとわからない。「3ヶ月で完成、売上10％アップ」って計画が、「6ヶ月かかって、売上1％しか上がらなかった」になる。そういう巨大な不確実性を内在した状態でロードマップを作って良いのか、が問われる。
ロードマップは「約束」になってしまう
ロードマップにはもう1つ問題があって、免責事項をいくら書いても、ロードマップが「約束」として受け取られちゃう問題。ステークホルダーはロードマップ見て予算確保するし、営業は顧客にリリース時期を伝えるし、他のチームもそれに合わせて計画立てる。こうなると、途中で「これって価値ないよね」って気づいても、もう引き返せない。
開発チームは、機能を実装する責任は問われるけど、その機能がビジネスの成果を出すかどうかの責任は問われない。この非対称性が、アウトプット志向を生み出してしまう。
僕も「作ったけど使われない」機能をいくつも経験してきましたが、それでも「仕様通りに実装したんで」って言い訳をしているし、それで世の中は回っている。でも本当に問われるべきは、「その機能、ユーザーの問題を解決したの？」ってことです。これから取り組むべきは、問題を理解してソリューションを開発し、ユーザーに届けること。
他にも印象的だった話
本書には他にも重要な話がたくさん詰まってます。
エンタープライズ企業がどうやってイノベーションを失っていくのかって話も興味深かったです。ビジョンがなくなって、権限委譲されなくなって、ステークホルダーが抵抗する。この3つが絡み合って、組織がじわじわ硬直化していく。で、買収したり「イノベーション組織」作ったりするけど、それって対症療法で根本的な解決にはならない。この悪循環から抜け出すには、さっき話した3原則、つまりリスクファースト、協調的開発、アウトカム志向を組織に根付かせないとダメという話。
この本から学んだこと、これからやること
この本を読むと、自分がどれだけアウトプット志向に陥ってたかを痛感します。「これ作れば成果が上がる」っていう仮説を、検証もせずに信じ込みがち。
具体的には、「なんでこれを作るの？」って常に問うこと、それに対する仮説を作ること。素早く検証して、失敗から学ぶこと。ロードマップを「約束」じゃなくて「今の時点での仮説」として扱うこと。そして何より、アウトカムにフォーカスすること。
伝道師のチームは、簡単には作れません。権限委譲には信頼が必要だし、失敗を許容する文化も必要。でも、基本的な考え方を理解してないと、その第一歩すら踏み出せない。『INSPIRED』は、その基本を教えてくれる本だと思います。
