こちらを読了したので、気に入った用語をピックアップして説明したあと、雑多なメモを残す。
前作INSPIREDの続編で、主にプロダクトリーダー（プロダクト開発に携わる管理職）を対象とした本。プロダクトマネージャーの管理職を例に書かれているため、プロダクトマネージャーについても理解が深まる。
ハイインテグリティーコミットメント
チームが設定する目標には、絶対に守るべき約束を目標に掲げなければならない場合がある。これを「ハイインテグリティーコミットメント」という。事業を経営するなら多少のこのコミットメントは必要となる。
ハイインテグリティーコミットメントを設定するためには、チームが主体となってスケジュールを提示し、納品物を提示する必要がある。チームは通常数日程度でプロダクトディスカバリーを行い、スケジュールを設定する。これはロードマップ時代の誠実性の低いスケジュール（これは、コミットされている内容を現場がほとんど知らないためであった）ではなく、リーダーが当てにできるスケジュールとなる。
こうした日程に縛られるコミットメントが多すぎる場合にはもっと重大な問題の兆候である可能性が高いが、通常は多少のハイインテグリティーコミットメントは必要となる。
ハイインテグリティーコミットメントは、コミットメントに含まれる実際の納品物を、KRとは独立して注視し、追跡しなければならない。またこの目標は原則ではなく例外としなければならない。
ナラティブ
プロダクト担当者、特にプロダクトマネジャーは、絶えずさまざまな主張を行う必要がある。些細なことについてはそうでもないが、大規模な機能やプロジェクト、そして特に新たな取り組みなどには、仕事に疑問を抱き、異議を唱える人も自然と多くなる。異議の多くは経営幹部から伝えられるが、チーム内からも上がってくることがある。
このテクニックは、自分の主張と推奨事項を説明するためのナラティブを書くと言うものである。
ナラティブは仕様書（内容を詳しく記述したもの）ではなく、解決しようとしている問題、その問題を解決することが顧客と自社に価値をもたらす理由、そして解決するための戦略をストーリー仕立てで綴る、約６ページの文書である。その後にFAQを載せる構成にするのが良いだろう。
ナラティブを読めば、作者が真の意味で議題をわかっているか、様々な観点と制約について検討し、対応しているかが明らかとなる。
Amazonではミーティングでパワーポイントではなくナラティブを使用して会議を行うことが知られている。
メモ
- エンパワーされたプロダクトチームを作ることが大切
- プロダクトマネージャーの主な職責はプロダクトの発見である
- 一般的にプロダクトマネージャーのオンボーディングの一環として、少なくとも15人の顧客訪問を進めている
- 競合分析ではプロダクトマネージャーに市場で競合する企業を3社から5社あげてもらい、各社の強みと弱みを比較して対照させるナラティブを書く
- プロダクトマネージャーはCSPO（認定スクラムプロダクトオーナー）コースの受講が推奨されるが、プロダクトオーナーとしての職責は重要であるものの、プロダクトマネージャーの職責のうちごく僅かな一部に過ぎない。
- 強力で説得力に富む議論を行うために、ナラティブの作成がおすすめ
- どのような職種からもプロダクトマネージャーへなることはできるが、デザイナーとエンジニアは多くの制約を抱えた問題の解決に長けているため適任である。
- プロトタイプやストーリーマップを作成し、それをもとに打ち合わせると言う行為自体が真のコラボレーションを促進する
- プロダクト担当者が実際にお金を払う顧客だけでなく、ステークホルダーを顧客と考えるのは、テクノロジーが「中核事業に奉仕する」と言う旧来の役割の遺物。この考え方が真の顧客が持つ役割を著しく薄めてしまう。
- 顧客と少なくとも週３回以上、１時間のやり取りをすること
- 新人のプロダクト担当者の中で、誠実かつ一貫性のある顧客中心主義が育つには約1年かそれ以上かかる
- プロダクトチームが、プロダクトディスカバリーを十分に実施して４つのリスク（価値、ユーザービリティー、実現可能性、事業実現性）を適切に検討するまで約束をしないこと
- プロジェクトマネージャーは締切の設定に多様ることが多いが、エンパワーされた伝道師のチームを編成したいのであれば、プロダクトマネージャーは締切の代わりに仕事の総合的な目的を共有する必要がある
- 意思決定の透明性はチームやリーダーの理解を経るために重症である。あまり重要でない意思決定については、意思決定を行った理由をメモの形で明確かつシンプルに説明するだけで十分な場合も多い。重要な意思決定についてはナラティブが推奨。懸念される異論や懸念を挙げて対応するFAQがあるとなお良い
- リモートワークでは成果物を順々に渡すというウォーターフォールのようなプロセスに逆戻し、議論全体がアウトカムではなくアプトプットに戻ってしまう傾向があり、注意が必要。プロダクトディスカバリーの間の成果物はプロトタイプであるべきだ。
- プロダクトビジョンを伝えるためにビジョンタイプ(ハリボテだが忠実度の高いユーザープロトタイプ)を作成する。ビジョンタイプはビジョンが現実になった時の世界を描写する。それは3年から10年先の未来かもしれない。プロダクトビジョンを伝えるもう一つの方法はストーリーボードで映画のあらすじを共有する手法によく似ている
- エンパワーされたプロダクトチームに適切なスキルと十分な時間を持たせればほとんどのプロダクトビジョンは実現できる。ビジョンピボットが最も重要になるのは、インサイトがより大きなチャンスに繋がる時である。問題が思ったより難しかった時（それはだいたい常にそうだ）ではない
- OKR
- 成功している企業はOKRを採用しているから成功しているわけではない。エンパワーされたプロダクトチームのモデルを活用できるように設計されているからOKRを活用している。
- OKRでは定量的指標としての実際の値（KR: Key Result）はチームが発案しなければならない。チームは時に最も有意義な指標ではなく最も計測しやすい指標を定義する疑惑に駆られる。
- ハイインテグリティーコミットメント
- ハイインテグリティーコミットメントに関してはコミットメントに含まれる実際の納品物を、KRとは独立して注視し、追跡しなければならない。
- ハイインテグリティーコミットメントとその納品物は原則ではなく例外としなければならない。そうしなければ目標が納品物の一覧、ロードマップと変わらないものとなってしまう。
- 会社の目標は通常年間目標であるのに対し、プロダクトチームの目標は四半期目標である。プロダクトチームは進捗、遭遇した障害、新たな学びとインサイト、新たに見つかったチャンスに基づいて軌道を修正できる。
感想
エンパワーされたチームを作る上で大事なことがいくつも書かれおり、中には実践的なものもあった。ナラティブの作成、ハイインテグリティーコミットメントの概念の導入はすぐにも使えそう。実際の開発現場ではハイインテグリティーコミットメントばかりのところも多いのではないか。
プロダクトチームの目標と組織の目標が対立してしまう場合があるため注意せよ、メンバーはプロダクトチームの目標に集中できるようにせよと書いてあったが、実際にどうやればいいのかについては言及はなかった。実際私の職場でも同様の軋轢は起きていてうまい解決方法は見つからない。組織の管理職としては彼らの目標を達成するために部下に指示を出すことができるわけだから、どういうインセンティブ設計をしたら良いのだろうか。
プロダクトリーダー（管理職）の仕事について書かれているため、管理職に就いた場合にはもう一度読み返したい一冊でもある。
コメント