第14章 より効果的なアジャイル : 要求の優先順位付け
有能なプロダクトオーナーは、特定の環境にふさわしい要求を定義するのに必要なレベルおよび種類の詳細を理解している(ビジネスシステムの要求と医療機器とでは、必要な詳細のレベルは異なる)。
これ本当にそう思う。。。そして一般的なWebアプリですらそれができない人たちってたくさんいて、日本ではPOの要求に関するまとめとか言語化とか論理的な整理のスキルをトレーニングするのが結構もとめられていそうだなっておもったり。プロダクトマネジメントの各種ツールとかメソッドも大事なんだけど。具体的な要求の整理とか詳細化とかセルフチェックのトレーニングのほうが足りていない気がするっていうか。
p176 2. トップレベルのエピックをステップまたはテーマに分解する。
今のチームでは、エピック の直下をストーリーに分割する方法をとっていて、ストーリーの中にタスクが存在するよ うな粒度の分け方になっている。ただストーリーが大きくて、完了までに数スプリントかかってしまうことがあるので、間の階層をステップやテーマとして扱い、最小単位をストーリーにするともう少し細かくPBIを運用できそう。
ストーリー粒度の観点
スケールの段階性(1くらいの大きさのものが1こ、0.3くらいの大きさのものが3こ ~ 0.1くらいのおおきさのものが10こ)
ユーザーがフィードバックしやすい仮説のサイズ
スウォーミングのしやすさ
Tシャツサイズの見積りは楽でいいなって思うんだけど、ビジネス価値と開発コストの2つで見積もるのは結構ミスリードが起きがちなので、期待値の表現としては 狩野モデル での表現の方が好きだなー。「ちょっとだけで十分に効果があるもの」なのか「たくさん実装されてほしいし効果がたくさんある」のかで、かけられる開発コストもかわるっていう。Tシャツサイズ見積もりをケース別にするためにストーリーを分解するのであれば、それでいいけど。つまり次の4つのどれかをよくやっている。 狩野モデル で期待値調整してから Tシャツサイズかフィボナッチ数見積り ケース別でのTシャツサイズ見積り
フィボナッチ数を使ってある程度収束するようにコストの見積り
1,2,3,5,8,13,21,100
フィボナッチ数をつかったコストの2点見積り
50%の確率で完成するコスト、90%の確率で完成するコストを各ストーリー毎に出して、標準偏差を使って出す。
長期間の見積がほしいときにつかうかなー。
ここのストーリーマッピングの「主要な機能を付箋紙に記入し、優先順位の高いものから順に左から右に貼り付けていく。」は間違いな気がする。ストーリーマッピングの左右はペルソナのタイムラインであって、優先順位ではないはず。参照先もJeff Pattonのやつなんだけど。
なんとなく読み進めてスルーしちゃいましたが、kyonさんの説明に納得です!
そもそもPBIの分割をストーリーマッピングで表現したことがなかったので、早速次のプロジェクトで導入してみよう!
検査
■チームのプロダクトオーナーの割り当てを再検討する。この重大な役割を担っている人々はどれくらい有能だろうか。彼らはチームの効果性に貢献しているだろうか。それとも弱点となっているだろうか。
どっちのこともあったなーっておもう。
■チームが要求の優先順位付けに利用している手法を調べる。その手法はROIの順序に基づく実装を支援するだろうか。
大まかにはそうなっていた。ROIを具体的に金額でだしているケースもあった。もうすこしライトウェイトにするか素早くできるとよかったなーとは思う。あまりできていないケースでは結構思いつきみたいなところがあって、せめて顧客インタビューの結果とかであってほしいなーっておもった。
■チームが全体像をまったく考慮せず、細かなビジネス価値に基づいて価値の高いものから順に機能を実装しているかどうかを調べる。
調べたことはないけど、全体のKGIとかKPIのどれを改善するのかを明確に回答できない時には、この例に当てはまっているということだなって思っている。
適応
■プロダクトオーナーの能力に問題がある場合は、育成するか更迭する。
基本は育成している。ただしうまく育成できたことはない。これからもっと自分も学ばなければなーってなっている。
更迭する場合には、POチームの一員になってもらう形を想定する。
■Tシャツのサイズ分けやストーリーマッピングなど、プロダクトバックログアイテムに優先順位を付けるための手法を導入するようにチームに働きかける。
エッセンシャルスクラムで提案されているような内容は基本的にはなんらかいれている。いれていないときに、コーチとしてのアドバイスも難しくなりがちなのもあって。(言葉が合わなかったり、考え方が整理できていないチームだとアドバイスが何を意図しているのか理解するのに時間がかかってしまう
■機能を首尾一貫したパッケージにまとめることを目的としてストーリーマッピングの実践をチームに働きかける。
これはたまにやる。半年とか1年とかたってWhyを忘れがちなチームはよくみかけていて、全体像を再度認識し直すためにもやったり。
2回目(2022/04/11)
14.1|プロダクトオーナー
無能なプロダクトオーナー(p171)
グハッ…(クリティカルダメージ)
有能なプロダクトオーナーは、アプリケーション、業界、それらのアプリケーションを使用する顧客についてのエキスパートである。(p172)
死体撃ちされた
本当にこれ・・・
ファシリテーションスキル(p172)
HPが1回復した
勇敢さ 有能なプロダクトオーナーは折々に決断を迫られる。有能なプロダクトオーナーは独裁者ではなく、「決定権者が決める」ときと「グループが決める」ときを心得ている。(p172)
ハッとした、帽子の被りわけみたいなのがここでも必要なのか…。割と自然にこれが無意識的にある程度できてた説もあるけど、意識的にやってみたい。(というかスクラムマスターだし、これをPOに伝えたいに近い)
わかりみのかたまり
ほとんどの場合においてグループ(チーム)に主体的に決めてもらいたいと考えていますが、適切に意思決定ができているかはわからない...
個人の効果性 有能なプロダクトオーナーは個人に求められる効果性の特性全般も備えている。たとえば、非常にエネルギッシュで、バックログリファインメントに積極的に取り組み、ミーティングを効果的に進行させ、一貫して最後までやりとげる
進行などはスクラムマスターに任せがちなイメージ。
わかる
常にしゃべって進行もして板書もするPO。もうこいつだけでいいのでは的な
逆にPOがバックログリファインメントに積極的に取り組まない状態ってどんな感じだろう。
たしかに、あまり想像できない
わかりみ。
責務を果たせないならやめればええねん > そんな簡単にできない問題
次がマシとは限らない・・・
14.2|Tシャツのサイズ分け
この並び替えの図がすごいわかりやすい。
コスパ的な値でざっくり並び替えて、そのあと一つ一つ比較していく
このように定義すると、「ストーリーBの価値はSしかないので、開発コストがKなら必要ない」といった判断を下せるようになる(p173)
めちゃくちゃいい。今年度のenPiTに是非導入したい。一軸の判断じゃなくて二軸の判断できたのか…見積もり(開発コスト)だけで優先順位を決めていた…。というか、ワークの途中まではビジネス価値的なものも考えていたのに、いざ優先順位が一意になるようにするってところで、それが抜け落ちていた…。
ソフトウェアでは「ノー」と即断することに高い価値がある。(p174)
なるほど感。たしかにやらないことを決められずにいたらゴミが増えていくし、ゴミ箱にゴミが溜まっていく…。そしてこれはPOしかできないって話を思い出したりもした。
わかりみのかまたり
全方向にいい顔したがるとメタボなプロダクトになる
汎用型の全部乗せ=大重量=小回りが効かない
大型トラックはコンビニに寄ってトイレ借りれないんですよ
3t半なら借りれる
3t半複数だとドライバーの数が必要。大型トラックは効率はいい。まっすぐ走るだけなら。
表14-2(p174)
めちゃくちゃいい、数値化の答えがある感じ。(100%の答えじゃなくてもめちゃくちゃ助かる)
正味のビジネス価値は大まかな値であるため、よく調べてみると「値が1のストーリーのほうが2のストーリーよりもよいアイデアである」ことが判明することもある。(p175)
さらっと書いてあるけどめっちゃ大事な気がする。気をつけよう!
本当に大事。
14.3|ストーリーマッピング
エピック > ステップ/テーマ > ストーリー の分解の流れいちばんしっくりくる
エピック、ステップ、テーマ、ストーリー、用語がわからなさすぎたので誰か少し教えてほしい
p179の色々なワードも同じだ、MVPの線とかどういう意味なんだ…?
オライリーのユーザーストーリーマッピングを読んでいる途中ですが、業務で使ったことないのでなかなかイメージ湧かないです
実物みたいであります
14.4|その他の検討課題
ドット投票
MoSCoW
独裁者に俺の思う通りにしろオラー!を抑制させる仕組みに見える
あるいは全員から意見を絞り出す仕組み
あと開発サイズを抑える。あるいは「やらないこと」を決めるためにWon't Haveがある感じか
MVE
Experimentなんですね
MVPの代わりになるもの
これ大事。分解しづらいものはある
14.5|推奨リーダーシップアクション
検査
チームのプロダクトオーナーの割り当てを再検討する
たしかにやってみたらこの人ダメだわ的なのはある。
顧客がPOだった時は、オーナーシップがない(全部誰かに判断してもらおうとして自分の意見は言わない)パターンが一番きつかった
風見鶏や伝書鳩はPOしてほしくないですね。
育成も無理ならそれこそ更迭しかないです・・・
「本に書かれてた」といえば険悪にならないかな…?
本当に必要なのはドメイン特化じゃなくて営業もわかる人だった、とか
もっと言うと営業の偉い人のゴルフ仲間
優先順位付に使っている手法、ROI順序に基づく実装を支援している?
PdM以外あんまりROIについて語れない、なんならPdMもようけ分かってないケースもある。
「これやると営業チームが「売上がブワーっと伸びる」と言っているのでこれは優先順位最高ですね!」
おめーは営業の伝書鳩か?みたいな
これ、自分も含めて口では考えられてそうで個人の感想レベルになってしまっているときが多くてなかなか厳しい
事業部全体を観察していると、プロダクトバックログ外の優先順位に目を向ける必要がありすぎる
そもそも論なんですけど、モノリスプロダクトの場合、エンジニアが複数の営業チームのコンテクストまで理解しないといけないことになるケースが多いんですよね。
集団勉強会とかやるしかない感じか
守備範囲を決められるマイクロサービスはこの点優秀になる???ほんまか?
やれてないなあ
チームが全体像を全く考慮せず、細かなビジネス価値に基づいて価値の高いものから順に機能を実装しているかどうかを調べる
おれはしんだ
全体像を意識しているかどうかを常に意識できる状態に導くのがスクラムマスターなのかな。
ビジネス職なステークホルダーが「俺が俺が」してくると全体像が考えられなくなる
特に営業の複数の事業部がそれぞれの要求をぶっ込んでくる場合。営業の目標数値がかかっているので近視眼的になりがち
これって全体像を考慮して、ビジネス価値だけじゃなく開発コストも考えるべきだって理解でいいかな?だとしたら、ビジネス価値をユーザーの体験価値と見て結構やってるかも…?
適応
プロダクトオーナーの能力に問題がある場合は育成するか更迭する
だいたいは育成ですね……
ただ追いつかない場合がある
育成しかやったことない
「PdMチームの長のXXの御大(役員)にご降臨いただくほかない」「まじかよ・・・」「しかし全体を理解できる人がいない」「ぜひもなし」パターンはありました
スクラムマスターとプロダクトオーナーで毎週1on1やってます
「育成するか?さもなければ飛ばせ」に近い何かを感じる
あるやり方に適応できない人はいるんですよ。アジャイルに限らず……
他の仕事なら普通にできるはずなので、お互いの利益のために飛ばすべき
プロダクトバックログアイテムに優先順位付をするための手法を導入するようチームに働きかける
これは大事
なんとなーく、とかPdMがそう言っているからこれは上!みたいなケースは多い。
方法さえわかれば自分で考えてくれる人もいる(教えても考えない人もいる)
というか「教えても考えない人、理解しようとしない人」がチームにいる場合更迭するしかないです。これはNo!と言うことと同レベルで重要だと考えています
ぜひやりたい
これはプロダクトチームだけでなく、営業やCSからの要求の際にも意識してもらうことが大事
「数字で判断したい」「判断できる数値がない。だって営業やCSがシステムに入力しないから」「は?」みたいなケースは割とあったりしますね。入れる文化を作るだけで1年かかる
権限がないと3年かけたって入力されない。
数字がないと声の大きい人や偉い人の鶴の一声任せになる。
これはやろうと思った
機能を守備一貫したパッケージにまとめることを目的としてストーリーマッピングの実践をチームに働きかける
やってみたい
14.6|参考文献