雑感

読んで面白かった本を要約しています。主に事業・プロダクト開発(PdM/UXデザイン/マーケティング)のビジネス書と社会科学(経済学/経営学)・人文科学(哲学/歴史学)の古典。

■要約≪TRANSFORMED 前編≫

 

今回はマーティ・ケーガン氏著の「TRANSFORMED」を要約していきます。著者はプロダクトマネジメントの世界における第一人者で、「INSPIRED」は当該分野のバイブルと名高い本です。本書はプロダクト主導のプロダクトモデルをそもそも組成していく為には何を抑えないといけないのか?・「具体的にどのように移行していくべきなのか?という問いに対する解にフォーカスして体系的に論じた本です。前編の今回はPARTⅠ~PARTⅥまでを要約します。

 

「TRANSFORMED」

TRANSFORMED マーティ・ケーガン(著/文 | 企画/原案) - 日本能率協会マネジメントセンター

■ジャンル:開発管理・組織マネジメント

■読破難易度:低~中(プロダクトモデルの概要・具体的な価値基準・移行プロセスについて体系的に記載されており、用語や世界観の最低限の理解があれば比較的読みやすいです)

■対象者:・イノベーション・業務改革に従事する方全般

     ・プロダクトモデルについて興味関心のある方

     ・テクノロジー・デザイン中心のビジネス形態に従事する方

 

≪参考文献≫

■INSPIRED

■要約≪INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント 前編≫ - 雑感 (hatenablog.com)

■要約≪INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント 後編≫ - 雑感 (hatenablog.com)

 

■チームトポロジー

■要約≪チームトポロジー≫ - 雑感

 

ユニコーン企業のひみつ

■要約≪ユニコーン企業のひみつ≫ - 雑感

 

プロダクトマネジメントの教科書

■要約≪プロダクトマネジメントの教科書 前編≫ - 雑感

■要約≪プロダクトマネジメントの教科書 後編≫ - 雑感

 

【要約】

■トランスフォーメーションの定義

・トランスフォーメーションとは作り方・問題解決の方法・解くべき問題の決定方法の3つを変える営みです。アジャイル開発のような顧客価値を意思決定の中枢に据えて仮説検証・探索型でコトマネジメントしていく体制への変容が必要です。機能部門が専門分化するのではなく、横断型のプロダクトチームを組成して最大限の裁量と権限を付与して顧客価値を中心に意思決定・戦略整合性とビジネス成果を探索するといった具合の変化が必要とされます。

・プロダクトモデルにおいてはプロダクトチームが高いオーナーシップを発揮し、ステークホルダーの利害に振り回されるのではなく、プロダクトビジョンやプロダクト戦略を意思決定の柱にしていく体制になることが大切です。継続的な仮説検証・機能開発における顧客価値測定、整合性に重きを置くことや顧客の世界をどのように変えていくかというロードマップ重視のスタンスが欠かせないとされ、チームトポロジーリーンキャンバスなどの考え方・フレームワークは必須です。

・機能開発はビジネス成果・顧客価値・プロダクト戦略整合性を必ずとらないといけなく、基準を満たさないものを許すようなことをプロダクトチームはやってはいけないです。そのため、プロダクトチームはアウトプットではなくアウトカムに集中することが大切であり、ユーザーストーリーや顧客インサイトに継続的に触れて共感しながら適切なジョブやペインを捉え機能開発・導線設計していくことが必要です。問題の解像度を高める営みに時間を割くべきであり、「その解決策はこのプロダクト・自社が担うことが適切か?」といった問いは常に検証し続けることが大切です。

・モノを作れば売れる時代が終わり、顧客中心主義やジョブ・ペインを捉えないプロダクト・ソリューションは全く価値がないという時代においての思考プロセスは大きく変容する必要があります。この転換にはプロダクト主導組織の構築・高いオーナーシップ・リーダーシップを持つ人材をプロダクト部門の中枢に据える必要があり、テクノロジー部門を受託に外出しするような機能では絶対にダメということです。

 

■プロダクトモデル・コンピテンシー

・職能横断型のプロダクトチームではプロダクトマネージャー・プロダクトデザイナー・エンジニアが連携して問題を解決しアウトカムにコミットメントすることが大切です。プロダクトチームが対処すべきリスクには価値リスク(顧客価値があるか)・事業実現性リスク(自社プロダクトがこのソリューション・事業をやる経済合理性・戦略整合性があるか)・ユーザビリティリスク(顧客が利用でき、価値あるものと認識できるか)・実現可能性リスクの4つであり、プロダクトマネージャーは価値リスクと事業実現性リスクプロダクトデザイナーユーザビリティリスク・エンジニアは実現可能性リスクに責任を負うのが一般的です。

・プロダクトリーダーがプロダクトチームの構築コーチンにより、オンボーディングとケイパビリティUPに責任を持つのが一般的であり、プロダクト組織のマネージャーやテックリード・エンジニアリングマネージャーなどがこの手の業務を担います。上記に加えて、プロダクトマーケティングマネージャーやプロジェクトマネージャーもプロダクトチームの成功に大きく影響を及ぼします。

ステークホルダーではなく、プロダクトマネージャーが価値と事業実現性に対してコミットメントをするというのがトランスフォーメーションのミソです。プロダクトマネージャーは顧客とビジネスについて深い理解を持ち、その上でエンジニア(主にテックリード)とプロダクトデザイナーと建設的な関係でビジネスや顧客の世界を翻訳しながらコラボレーションしてプロダクト戦略の推進とビジネスアウトカムにコミットメントするというタフな役割になります。主要な顧客やステークホルダーと関係性を持ち、プロダクトマネージャーの一人一人がプロダクト組織をリードできるポテンシャルを持っている状態にあるようになっているのが健全な状態であり、プロダクトリーダーには大きな責任が伴います。プロダクトマネージャーは行動や傾向を深く学ぼうとする分析力知的好奇心をもって様々な分野に対しての理解を深めていく姿勢青写真を描き利害関係や専門性の異なるステークホルダーと合意形成していくというソフト面のスキル・マインドセットが成功に大きく関わります。ユーザー・顧客・ビジネスステークホルダー・プロダクトデータにダイレクトにアクセスして仮説検証や推論が出来る状態にあることを担保することがプロダクトマネージャーが活躍するMINの環境条件となります。

・トランスフォーメーション局面のプロダクトデザイナーマーケティングサポートやプロダクトマネージャーの受託のようなスタンスであることは許されないです。プロダクトデザイナープロダクトがどう機能するかプロダクトディスカバリーの2つの論点に対して責任を持つのが推奨される役割です。デザインはビジュアルやグラフィックにだけ責任を持てばよいのではなく、タッチポイントを始めとした顧客体験全般に責任を持つことが求められます。テクノロジーと人がどのようにコミュニケーションするかといったインタラクションデザインはプロダクト体験のデジタル化に伴い、ますます重要になっています。プロダクト体験をどのようにもっていくのが良いのかという継続的な仮説検証・テストを通じてアウトカムにコミットするのが基本の役割であり、その際にはエンジニアやプロダクトマネージャーとのコミュニケーション・ロードマップやプロダクト戦略との整合性などが否応なしに求められます。顧客価値とビジネス成果の両立は勿論、顧客体験設計を通じてプロダクト戦略やロードマップをどのように推進・改変するのかという視点がプロダクトデザイナーには常に求められるのです。

・エンジニアリング組織の中でもテックリードエンジニアリングマネージャーはプロダクトマネージャーやプロダクトデザイナーと連携して、顧客価値やイノベーションに関する議論・探索に関与するべきとされます。エンジニアリング機能は外注するのではなく、自社内で賄い顧客やビジネスの視点に継続的に触れてもらい、実現可能性やインサイトのフィードバックを適切に受け続ける関係性であることが大切になります。一方で、過度なインタラクションが開発生産性を下げるのは事実なので、チームトポロジーのような工夫が必要になります。この視点を行き来するツールとしてユーザーストーリーマッピングがあり、ロードマップやユーザーの視点に共感することを開発者にも要望していくことが良いプロダクト開発に寄与します。

・良いプロダクトチームを形成するにはプロダクトチームの組織設計とコーチンをプロダクトリーダー(管理職層)がコミットすることが必須条件になります。プロダクトビジョンとプロダクト戦略を語り、プロダクトチームを適切な方向にリードするのに加えて、資源獲得交渉や優先順位付けなどをすることもプロダクトリーダーの役目となります。プロダクトチームの責任とオーナーシップを定義づけ、何を目指しているのかという大方針を定義するなど「仕事を定義・評価する」ことを通じて組織を動かすことが大事な役割です。プロダクト主導の組織はプロダクトリーダーが解くべき問題を明確にして戦略整合性を明らかにしていく・継続的なエバンジェリズムを行うことで組織風土や価値基準を統制するといった営みが欠かせないです。

 

■プロダクトモデル・コンセプト

・プロダクトチームの責任はプロダクトディスカバリー(主にプロダクトマネージャーとプロダクトデザイナー)とプロダクトデリバリー(主にテックリード中心のエンジニア組織)の2つにあります。プロダクトディスカバリープロセスでは価値・ユーザビリティ・事業実現性などの観点からリスクを考慮し探索していくのが基本になります。定量・定性両方の観点から顧客インサイトや筋の良さ・費用対効果などをみていくことが大切になります。ユーザーや顧客インサイトに継続的に触れて、時に直接対話して仮説・観点をアップデートし、それでいながら上位戦略との整合性・上位戦略にヒットするようにコトをマネジメントするというバランス感覚がプロダクトディスカバリーのミソです。実験をする際にはレピュテーション・顧客アセットなどのリスクをどれだけ取れるかを慎重に考えて意思決定・実行していくのが良いとされています。

・継続的な機能開発と合わせてテストにて不備がないか・機能開発が既存の機能や顧客体験を棄損しないかの精査というのがプロダクトデリバリープロセスにおいて大事な要素になります。プロダクトの機能は問題解決に寄与し、計測可能なアウトカムが示せることが必須条件になり、どうでもいいプロダクト体験に寄与しない開発はしないという線引きをするのがプロダクトチームには求められます。ビジネスアウトカムにコミットメントしながら、プロダクトビジョンやロードマップ推進・論点精査をするということが基本ラインで、それでありながら技術的負債を継続的に解消する必要もあるというのが現実的な問題の難しさになります。

 

 

【所感】

・本書前半では上記に加えて、プロダクトモデルを実践した企業の事例やプロダクトモデル実践における各部門(営業・プロダクトマーケティング・財務・ステークホルダー・経営幹部)との役割分担、コラボレーションプロセスの要諦などについても深く言及されております。プロダクトマネジメントのコンセプトは理解したものの、どのように導入・移行していくのか(何を良しとする価値基準の組織体制に変革していくのか)というのが難しいと感じていたので、本書の内容はなるほどなと深く感心させられました。

・顧客中心主義とビジネスアウトカムコミットメントをベースに、高いオーナーシップを発揮できるような環境を構築し、組織設計とコーチングにより常に微修正し続けながらやっていくのがプロダクトモデル成功のカギであるということがしっくり腹落ちしました。適切な人をバスに乗せ、成功失敗の価値基準・評価プロセスを明確にして戦略的思考を様々なツールを用いて実働に乗せていくという地道な粘り強さ・強い意志が求められると感じ、だからこそ「最高の人材に最高の機会と報酬を付与する」という極めて資本主義市場的な考え方がテクノロジーの世界にはあるということを再認識しました。

・本書言及内容に関して、デザインやエンジニアリング・マーケティング分野などの理論・知識と往来させながら継続的にインプット・アウトプットを試み、自分も日々の持ち場で実践していきたいと感じた次第です。

 

以上となります!