書籍レビュー

「BUILD 真に価値あるものをつくる型破りなガイドブック」レビュー|顧客の意見を聞くほどプロダクトが凡庸になる理由

顧客の声に耳を傾け、ユーザーインタビューを重ねる。しかし、完成した製品は無難な機能の寄せ集めにすぎず、誰の心も打たない。

プロダクト開発の現場に蔓延するこの事象に対し、トニー・ファデル氏の著書「BUILD 真に価値あるものをつくる型破りなガイドブック」は明確な答えを出しています。

トニー・ファデル氏はiPodやiPhoneの開発を率い、Nestを創業しました。

本書は成功者の回顧録ではありません。初期のプロダクト開発に潜む「データ主導」の罠や、プロダクトマネージャー(PM)が負うべき真の責任など、シリコンバレーの最前線で幾多の失敗を重ねた末に抽出された実践的な法則です。

チームが抱える停滞感を打破する鍵が、ここに存在します。

「BUILD」が突きつける「顧客の声」への違和感

顧客が発する声を絶対視する姿勢は、多くのケースでプロダクトを凡庸な製品に貶めます。

多くの開発チームは、ユーザーの要望をすべて満たそうと努めます。

しかし、出来上がるのは誰の切実な課題も解決しない製品です。

「BUILD 真に価値あるものをつくる型破りなガイドブック」は、顧客の声を無批判に受け入れる姿勢を否定します。

真のプロダクト開発は、顧客自身も気づいていないインサイトを掘り当て、作り手の強烈なビジョンを具現化する作業に他なりません。

チームの停滞を打ち破るには、顧客の声に寄りかかる「耳の良さ」ではなく、本質を見抜く「眼の鋭さ」が必要です。

第1世代(V1)は「意見主導」第2世代以降は「データ主導」

新規事業やスタートアップの現場では、データと直感のどちらを重んじるかという論争が絶えません。

ファデル氏はこの対立を完全に切り離します。

まだ世に存在しない第1世代(V1)のプロダクトを生み出す際、顧客に意見を求めても意味はありません。顧客は見たこともないものを想像し、言葉にすることはできないからです。

V1の開発においては、顧客の潜在的な課題を見抜き、作り手自身の直感とビジョンに従う「意見主導(Opinion-driven)」の決断を下します。

しかし、V1を市場に投入し、顧客の反応という現実のデータを獲得した後は反転します。第2世代以降の改善は徹底して「データ主導(Data-driven)」で実行します。

この順序を違え、初期からデータに依存して決断を遅らせる組織は、革新的なプロダクトを生み出す資格を持ちません。

「ビタミン剤」ではなく「鎮痛剤」を作るべき

素晴らしいアイデアとは、便利な機能の追加を意味しません。

ファデル氏は「最高のアイデアは鎮痛剤であり、ビタミン剤ではない」と断定します。

ビタミン剤は健康に良いと分かっていても、飲み忘れて困ることはありません。

一方、激しい頭痛に襲われた人間は、這ってでも鎮痛剤を買い求めます。

開発すべきは、顧客の痛みを消し去る鎮痛剤です。あなたが作ろうとしているプロダクトは、顧客の強烈な痛みを解決しているでしょうか。

「WHY」を追求するストーリーテリングの重要性

優れたアイデアの根底には、強固な「なぜ(WHY)」が存在します。

なぜこのプロダクトが存在しなければならないのか。なぜ顧客はこれを必要とするのか。

ファデル氏は、製品の機能(WHAT)を設計する前に、「WHY」を徹底して言語化し、ストーリーとして語ることを求めます。

優れたストーリーは複雑な技術を単純化し、顧客の理性と感情の両方を撃ち抜きます。

デザイン、機能、パッケージ、カスタマーサポートの対応に至るまで、顧客と接するすべての要素は、プロダクトの物語を構成する部品として機能しなければなりません。

開発前にプレスリリースを書く理由

プロダクトのストーリーを具現化する手法として、ファデル氏は「開発を始める前にプレスリリースを書く」ことを実践しています。

製品が完成した後にマーケティングチームへ広報を委ねる姿勢は誤りです。

作り手自身が最初に、製品の何がニュースであり、世界をどう変えるのかを文字にします。

もし人の心を動かすプレスリリースを書けないのであれば、アイデアはまだ開発に着手する水準に達していません。

プレスリリースは、開発の是非を問う過酷なリトマス試験紙です。

現場が誤解しているプロダクトマネージャーの真の役割

プロダクトマネージャー(PM)という職種は定着しつつありますが、役割の定義は企業によって曖昧です。

バックログの整理や、開発部門と営業部門の調整役に成り下がっている事例は枚挙にいとまがありません。

PMは「顧客の代弁者」であり「プロダクトの管理人」ではない

ファデル氏は、PMの役割を「常に顧客の代弁者であり続けること」と定義します。

エンジニアリング、デザイン、マーケティング、営業、カスタマーサポートの各部門は、往々にして作りやすさや売りやすさといった内向きの論理を優先します。

各部門が自己の都合を優先しそうになった時、「これは顧客にとって真に最善か」と問い、軌道修正を強行するのがPMの絶対的な責務です。

製品の仕様策定、メッセージングの決定、経営陣へのプレゼンテーション、収益性の確認まで、PMの業務範囲は多岐にわたります。

PMは決して言われたものを作る進行管理役ではなく、事業全体を俯瞰し、顧客価値を最大化する「ミニCEO」として君臨します。

失敗例|インサイトを言い訳にして決断から逃げる組織

Fadell氏自身も過去に手痛い失敗を経験しています。

Philipsに在籍していた時代、モバイル専門家を集めたパネル調査に依存しすぎた結果、チームはデータ不足を言い訳にして意思決定を回避し続けました。

市場調査は「誰に向けて作るか」を特定する役割を果たします。

しかし、「どのような機能が必要か」の決定権を顧客に委ねてはなりません。最終的な決断を下し、結果に対する全責任を負うのは、他でもないPMとデザインチームです。

チーム構築とマネジメント|嫌われ役を引き受ける覚悟

優れたプロダクトは個人の力では完成しません。

ファデル氏は、プロダクト開発と同等以上の熱量を、チーム構築とマネジメントに注ぐことを要求します。

「ミッション主導の嫌なやつ(Mission-driven Asshole)」の必要性

組織には様々な人間が属します。ファデル氏は「ミッション主導の嫌なやつ」の存在を不可欠なものとして肯定します。

ミッション主導の嫌なやつは、自己中心的な人物や、権力を乱用する政治的な人物とは本質的に異なります。

彼らはプロダクトの品質に対して狂気じみた情熱を抱き、一切の妥協を許しません。時にチームメンバーへ過酷な要求を突きつけ、激しい軋轢を生み出します。

しかし、彼らの苛烈さは「顧客に最高のものを届ける」という純粋な使命感に根ざしています。

凡庸さを憎み、チームの限界を引き上げるために、進んで嫌われ役を担う情熱的な人材こそが、世界を変革するプロダクトを生み出します。

プレイヤーからマネージャーへの移行期に直面する壁

優秀なプレイヤーがマネージャーに昇格する際、多くの人間が厚い壁に衝突します。

ファデル氏は「マネージャーになった瞬間、あなたを成功に導いた現場の仕事を捨てなければならない」と警告します。

マネージャーの仕事は、自らの手を動かして優れたコードを書き、精緻なデザインを行うことではありません。

コミュニケーションの円滑化、優れた人材の採用、明確な目標設定、政治的な障害の排除など、チームが最高のパフォーマンスを発揮する環境を構築することが新たな責務です。

部下がマネージャーを驚嘆させ、マネージャーの能力を超える成果を出せるよう支援する。これこそがマネージャーとしての真の成功です。

結論|今のあなたに「BUILD」は必要か?

トニー・ファデル氏の書籍「BUILD」は、単なるビジネス書の枠を超え、現場で戦う人間のための過酷で実践的なメンターとして機能します。

キャリア初期・若手エンジニアが得られるもの

社会に出たばかりの若手や若手エンジニアにとって、本書は「何を学ぶべきか」を指し示すキャリアの羅針盤です。

給料の額や役職の高さではなく、情熱を傾けられる課題と、心から尊敬できるメンターを探すこと。

そして、失敗を恐れず挑戦を継続する精神のあり方を学ぶことができます。

新規事業担当者・スタートアップCEOが得られるもの

プロダクトが市場に受け入れられず苦悩する新規事業担当者や、組織の急拡大に伴うマネジメントの壁に直面するスタートアップのCEOにとって、本書は事態を打開する劇薬です。

データと直感の均衡、強烈なストーリーの構築、妥協を排したチームカルチャーの醸成。

シリコンバレーの修羅場を生き抜いたFadell氏の血肉に塗れた教訓は、明日からの意思決定を根底から覆す力を秘めています。

現状の凡庸なプロダクトや停滞したチームを是とせず、真に価値あるものを作りたいと渇望するなら、直ちに本書を開きなさい。

Amazonで「BUILD 真に価値あるものをつくる型破りなガイドブック」をチェックする

  • この記事を書いた人

朝倉卍丸

シングルモルトスコッチなどのお土産を持ってきた人を助けるのが好きです。サービスの分割が重要ですが、昔ながらの方法でやりたいこともありますよね。

よく読まれている記事

条件の0=0は全てが正であるを意味するSQL 1

SQLの条件に0=0のような記述を見かけます。 変わった書き方の条件ですが、これは「全てが正である」事を意味しており、結合条件の場合はCROSS JOINと同じです。 下記の例で言えば、結合するsub ...

DISTINCTを使わないで重複排除を考えるSQL 2

SQLのDISTINCTはEXISTSとかGROUP BYでなんとかする事もできます。 DISTINCTは暗黙的なソートがされますが、何のDBを使うにせよ過去のバージョンならともかく、最近のバージョン ...

RFC 5322に準拠させた正規表現言語別 3

RFC5322で定義されている正規表現を、各言語の正規表現に変化させた形になります。 完全な電子メール正規表現は存在しないので、結局のところ何かの公式基準に従っていたとしても、自分が携わるサービスのル ...

-書籍レビュー