読書メモ「プロフェッショナルプロダクトオーナー」
表記本を読んだので感想を記載します。
前に仕事でご一緒していたたくぼんさんに献本いただきました。POとして悩んでいる所でしたので、ちょうど良いタイミングでありがとうございました。スクラムの本やプロダクトマネージメントの本は色々ありますが、スクラムの中でPOが何をするのか？という事を書いた本はあまりないため、とても貴重だと思います。幅広い内容が書かれている中で自身の強みや弱みと向き合うためにも有効ですし、PO以外の人もスクラムやる方は意義のある本でした。また、所々で著者のエピソードを入れてくれていていたのもとても良かったです。(ただ、一定スクラムの経験がある人が読まないと初心者には厳しい感覚は受けましたので注意。)
気になったところ
真のプロダクトマネジメントとは、トップからボトムまでの組織全体の至る所でアジリティを実現し、プロダクトマネジメントのすきまを埋めることです。上手くやれば、真の競争優位を作り出せます。
すきまを正しい方法で埋めるために、3つのＶを使います。( 中略）
ビジョン（Vision）
価値（Value）
検証（Validation）
⇒３つのVとしてビジョンからの駆動で検証する価値を定義しながら、進めて行き隙間を埋めることが重要と書いています。すきまは掘っておくと膨大なタスク管理で埋められてしまうので３つのVで埋めることが大事という話は大事だなと感じました。
起業家は、究極のプロダクトオーナーです。(中略)多くの組織にとって、これは現実的な状況ではないかもしれません。しかし、起業家的な考え方はプロダクトオーナーに求められるものです。
⇒いくつかのプロダクトオーナーのタイプをまとめていて(下記表)、成長方針について明言されています。ビジネスと開発と両方の責任を強く求めているのが特徴となっています
免責事項：プロダクトビジョンについてしつこく話していると、チームやステークホルダーを苛立たせる。うんざりされるんだよ。みんなにね。でも、そのことを悪く捉えないようになり、今では自身を持ってやってるよ。ビジョンをみんなの心の中に留めておくためには必要なことなんだ。親が安全や成績、掃除などについて同じことを繰り返して伝えているのと同じだと思っている。
⇒アジャイルコーチ的にあるあるなんだろうなー。ただPOとしても少なくとも20回程度はMVV関係の説明はしないといけないなと思っています。作る事よりも語ってストーリーを作り上げることが重要と感じています。
エビデンスベースドマネジメントガイドより
現在の価値は、市場における組織の実際の価値を明らかにするものである。現在の価値は、組織の現在の状態を証明するものであるが、将来にわたって価値を持続させる組織の能力とは何の関係もない
⇒EBMについていくつか書かれています。本書では基本的なレベルでの記載だけとなっていますが、自分自身この辺の知識やこの後出てくる検証の知識が少ないと感じました、POとして全般的に必要な事が書かれているので、自分がこの辺弱いなーといった気付きを得ながら読めるのは良いと思いました。
MVPのパターン
・プロポーション型MVP(ビデオ、UIモックアップ、バイラルキャンペーンなど、みんながあなたのプロダクトについて話し、あわよくば資金調達できるようなものが含まれます)
・マイニング型MVP(調査や概念検証(Proof of Concept)、潜在的な市場に関するデータを収集してビジネスモデルを検証するものが含まれます
・ランディングページ型MVP(ステークホルダーに進捗を確認できる場所を適用します。また、ランディングページを活用して、アクセス数等のデータを収集したり、行動するきっかけを作ることができます)
・オズの魔法使い型MVP(顧客からは完成しているように見えるものの、裏側では人手で全ての作業を行っています)
・シングルフィーチャー型MVP(一度、市場にプロダクトを出してしまい、これを実験の土台として使い始めることが出来ます)
⇒MVPといった時に人によって色々なイメージをするなと課題に感じていたので、いくつかのパターンで言語化されていてこれは使えるなと思いました。
プロダクトの「マネジメント」には、基本的に2つのアプローチがあります。どちらのアプローチを選択するかは、あなたが作り出すものがどの程度予測可能なのかによります。秩序があるよう域(明白と煩雑)と秩序がない領域(複雑と混沌)です。
⇒ちなみに本書では複雑性に対する対策と方針についてステイシーマトリックスとクネビンフレームワーク両方使って説明していました。
本当に避けなければならないのは、プロダクトオーナーから開発チームへの要件の受け渡しです。開発チームがフィーチャーとその洗練に密接に関われば関わるほど、プロダクトバックログアイテムは開発チームのものとなります。これが、成功を収めるための重要なステップである、更なるオーナーシップ、強いエンゲージメント、プライドをもたらします。
⇒この一文は大事だなと思うとともに、プロダクトオーナーとして、価値を開発チームとどれだけ話すが重要かという事を改めて気づかされました。
ここで、よくある受け入れ基準の書き方を３つ紹介します。
テストは…
各受け入れ基準を「テストは…」という言葉で始めます。これが、即座に人をテストマインドにさせます。プロダクトバックログアイテムごとに「完成」の確認をするために何をテストしようか？という具合です。
デモは…
各受け入れ基準を「デモは…」という言葉で始めます。これが、価値を実証するためにステークホルダーに見せたいことや、スプリントレビューについて考えさせます。ある意味、スクラムチームはスプリントレビューの台本を書いているとも言えます。スプリントレビューで受け入れ基準のリストを配り、１つずつ確認できます。
Given-When-Then(Gherkin記法)
Given＜前提条件＞、When＜ユーザーがアクションした時＞、Then＜期待する結果＞
受け入れ基準の書き方としてとても良いなーと思いました。特に「デモは」についてはもっと意識したいと思います。
「準備完了」の定義についての注意。「準備完了」の定義を満たしていないプロダクトバックログアイテムをスプリントに入れるのを拒否する開発チームと一緒に仕事をしたことがある。初めは合理的に思えたけど、これが、開発チームのマインドセットをアジャイルから遠ざけるフェーズゲートや、あろうことか契約になり始めることに気付いた。
アジャイルソフトウェア開発宣言の3つ目の価値「契約交渉よりも顧客との協調を」を思い出そう。「準備完了」の定義は契約として使えるものではない。もし、プロダクトオーナーがスプリントプランニングの前の晩にこれまでにない素晴らしいアイデアをひらめいて目覚めたとしたら？翌日、開発チームの所へ持っていき、次のスプリントのために検討できるようにすべきではないだろうか。たとえそれが「準備完了」の定義を十分に満たしていなかったとしてもだ。この注意は、「準備完了」はガイドラインとして扱われるべきで、本当の意味でのコラボレーションを害するような具体的な契約として扱ってはいけないという事だ。
⇒このバックログ着手における準備の内容ついてはとても気づきがある内容でした。どちらの考え方もあっているため、どちらかに振れすぎないように進めていく感覚が大事だなと感じています。
プロダクトオーナーはCRACKであり続ける。
・協力的である(Collaborative)
開発チームやステークホルダーと密接に協力する。彼らと知り合いになる。自分の携帯電話番号を手渡す。いつでもメールや電話をしてくれるようにお願いする。スプリント期間中に関与する。フィードバックをするために最後まで待たない。自分もチームの一員であると考える
・顧客の意思を代表する(Representative)
ステークホルダーや顧客との共感を築く。彼らがいないときは彼らの声になる。彼らのニーズを正確に反映したプロダクトビジョンを確立し、それを伝える。また、スクラムチームの代表として、出荷へのプレッシャーを強める経営陣に立ち向かう
・権限を持っている(Authorized)
スコープ、スケジュール、予算などプロダクトに関連するあらゆる決定を下す権限を持つ。ステークホルダーが合意に至らない場合は最終的な決断を下す。ただし、後で詳しい情報を知ったときに、自分の進路を調整できるという大胆さを持つ。
・献身的である(Committede)
プロダクトオーナーシップはフルタイムの仕事だ。プロダクト、開発チーム、ステークホルダー、品質にコミットし続ける。ビジョン、価値、検証(3つのV)、そしてスクラムという経験的なプロセスに忠実である、何事にも道を踏み外さないようにする
・知識を持っている(Knowledgeable)
自分のドメインを知り、学ぶことを止めない。ユーザーや専門家と緊密に連携し、知識のギャップを埋める。最新の技術動向を常に把握する。市場や競合他社を調査し、常に一歩先を行く
⇒CRACKは聞いた事はあったかもしれないですが、覚えてなかったため、POであればちゃんと心にとめて言えるようにしたいと思いました。どれも良いなーと思いました。
感想
POであれは一読すべきですし、スクラムマスターや開発者にとっても良い気付きがある本だなと思いました。ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？