プロダクトバックログで学ぶリアルオプション入門

RSGT2026発表資料

Transcript

1. プロダクトバックログで学ぶ リアルオプション入門 原田騎郎 株式会社アトラクタ
2. 講師紹介 原田騎郎 / HARADA KIRO ▸ アジャイルコーチ、ドメインモデラ、サプライチェーンコンサルタント。 認定スクラムトレイナー。 外資系消費財メーカーの研究開発を経て、2004年 よりスクラムによる開発を実践。ソフトウェアのユーザーの業務、ソフトウェア 開発・運用の業務の両方を、より楽に安全にする改善に取り組んでいる 2
3. プロダクトバックログ ✤ 説明しないよ(Advancedセッションだからね) ✤ プロダクトゴール ✤ 順位づけられたプロダクトバックログアイテム ✤ 優先度じゃないよ ✤ 優先順位でもないよ ✤ その順位はどうやって決めたらいいんだ？ 3
4. リアルオプション ✤ オプションをリアル(現実世界に適用したもの) ✤ オプションってなに？ 4
5. オプション ✤ コマンドのオプション ✤ オプショナルツアー ✤ 車のオプション ✤ あなたが決められるということ(あなたが決める権利のこと) 5
6. オプション ✤ 金融工学から来た手法(価値をなんでも値段にして考える) ✤ 後から決める(今決めなくてもよい)ことに価値(値段)をつける ✤ 為替オプション(為替予約)など ✤ 先物取引 ✤ 現物の取引ではなく、将来一定の条件で取引する権利を取引する ✤ デリバティブの1種 6
7. オプション ✤ コールオプション(買う権利) ✤ プットオプション(売る権利) ✤ 権利行使価格(と量) ✤ 満期日(いつまで使える / いつ使える) ✤ プレミアム(オプションの価格) ✤ オプションは行使したら価値はなくなる ✤ オプションの価値は変動する 7
8. オプションの価値(プレミアム) ✤ 価格のブレ(リスク)が大きいほど高くなる ✤ 期間が長くなる(満期日が先)の方が高くなる ✤ ブラックショールズ方程式 ✤ (数式は書かないよ) ✤ 1997年ノーベル経済学賞 8
9. リアルオプション ✤ オプションの考え方を現実の判断に利用するやり方 ✤ ある決定を後で下す権利に価値があると認識する ✤ すでに使われている例を知っているはず ✤ 飛行機の運賃 ✤ ホテルの料金(ダイナミックプライシング) 9
10. 10
11. 32,800円 - 10,690円 = 22,110円 22,110円ってなに？ 11
12. ￥32,800（フレックス運賃) = ￥10,690（スーパーバリュー運賃) + ￥21,110(プットオプション価格) ￥21,110 = 航空会社が特定日の特定便のチケットをあなたに売りつける権利の値段 = あなたがチケットの区間・日程を変更する権利を放棄する値段 12
13. 仕訳 ✤ フレックス 32,800円 のチケットを販売 ✤ 現金 32,800円 短期負債・前受金 32,800円 ✤ スーパーバリュー 10,690円 のチケットを販売 ✤ 現金 10,690円 売上高 10,690円 13
14. ソフトウェア開発・プロダクト開発におけるオプションとは？ ✤ オプションがない開発？ ✤ 最初にすべてのオプションを行使してしまう ✤ いつ何を作るか最初に全部決める 14
15. ウォーターフォール開発 ✤ 一括請負契約 ✤ オプションを使わない(だから請負が可能) ✤ 全て完成させることを最初の時点で決めて契約してしまう ✤ 一回依頼したものは原則キャンセルできない ✤ 納品までの責任 ✤ 後で変更する権利を放棄してもらうことで成立している 15
16. 16
17. ところでソフトウェアって ✤ 作った20%くらいの機能しか実際には使われていない ✤ 作られた量に比例して保守費用がかかり続ける(開発費のX倍) ✤ ソフトウェアを小さくするのは大きくするより難しい ✤ 機能追加 < 機能拡張 < 機能変更 < 機能削除 ✤ 扱う相手は複雑系になってきた(やってみないとわからん) ✤ 不確実性コーン、クネビンフレームワーク 17
18. システムの機能の利用割合 いつも使う 7% よく使う 16% たまに使う 13% ほとんど使わない 19% まったく使わない 45% 64% の機能はほとんど、もしくは まったく使われていない。PC のプレインストールソフトウェ アなどを考えると想像がつく The Standish Group “Chaos” report 2002 18
19. ✤ 2002年の調査って流石に古すぎるでしょ 19
20. 20 ▸ 2019年Pendoの調査 12% 8% まったく使わない 24% ▸ Pendoはプロダクトマネジメント関連のSaaS企業 ▸ 24%の機能はまったく使われない ▸ 80%の機能はほとんど/まったく使われない ▸ 昔と状況は変わっていない ほとんど使わない 56% まったく使わない いつも使う ほとんど使わない よく使う 出典 https://www.pendo.io/resources/the-2019-feature-adoption-report/
21. ✤ アジャイル開発が役に立っていない！ 21
22. Agile Manifesto Simplicity̶the art of maximizing the amount of work not done̶is essential. シンプルさ̶作らずに済ます量を最大にする技̶は必須である 22
23. 作らないことの価値を見積もってみる ✤ 使われる機能の割合を25％とする。使われる機能だけ開発できたとすると、 ✤ 開発コストは1/4に、開発期間も1/4に、保守費用も1/4に ✤ 稼働開始を早められるので機会損失も減らせる ✤ 開発期間の資本コストも節約できる 23
24. ソフトウェア開発の夢 無駄なものを一切作らずに 価値のあるものだけ作りたい 24
25. 人間には無理だった 25
26. 現実的な対応策 なるべく無駄なもの作らずに 価値のあるものだけ作りたい なるべく小さく作って無駄じゃないか早く確かめて 残りを作るかどうかの判断は先延ばしにしたい 26
27. オプションをどう使える？ ✤ プロダクト開発における価値の高いオプションは何か？ ✤ どんなオプションがあれば、プロダクトの価値が高められる(確率が上げられる)？ 27
28. どうする ✤ 何を作るか、作るかどうかの判断をなるべく先延ばしにしたい ✤ 判断にかかるコストも小さくしたい ✤ 実際に使う人・受益者から判断に必要な情報を得たい ✤ 価値があるとわかったものは早くリリースしたい ✤ Time to Marketの短縮 ✤ 判断に関わる情報を得られるできるだけ小さな単位でPBIを準備する 28
29. ✤ 判断を先延ばしにする ✤ リードタイムを短くする 29
30. プロダクトバックログとプロダクトバックログアイテム ✤ PBIはなるべく小さくする(価値に関わる情報が得られる単位で->完成の定義) ✤ 他のPBIの価値評価に関わる情報を得られるものは早めに実施する ✤ 価値があるとわかったものはなるべく早くリリースする ✤ 価値があるか確信の持てないPBIは、なるべく後回しにする ✤ 価値がないとわかったものは(できれば作る前に)さっさと廃棄する 30
31. シナリオプランニング ✤ PBIの完成によって得られた情報によってシナリオが分岐する ✤ どっちのPBIをやるか、それとも両方やらないか ✤ 別のPBIが生まれることもある 31
32. 32
33. 3 1 2 4 33
34. PBIの依存関係 ✤ PBIの依存関係(時系列) ✤ PBIを完成させることが可能な順番 ✤ 部屋の予約をできる前に、部屋の予約のキャンセルはできない 34
35. PBIの依存関係 ✤ PBIの依存関係(時系列) ✤ PBIを完成させることで得られる情報がどう影響するか ✤ あんまり先のことは読めない ✤ 35
36. 36
38. PBIのシリーズ ✤ だいたい一直線 ✤ いくつかの分岐 ✤ 試行錯誤 ✤ カオス ✤ 止めるための実験が必要 38
39. だいたい一直線 39
40. いくつかの分岐 40 40
41. 試行錯誤 41
42. カオス 42
43. 全部やらないといけないんで 43
44. 色々なPBI ✤ プロダクトを殺せるPBI ✤ 不要な投資を大きく削減できる可能性 ✤ プロダクト撤退のPBI ✤ 撤退判断にかかる時間を削減できる ✤ リファクタリング ✤ 他のPBIのリリースリードタイムを短縮できる ✤ 次のプロダクトの調査 ✤ 次の主要開発エリアを探す 44
45. リアルオプションそのままは扱いにくい ✤ 分岐も含めて実施しそうな順序に一列に並べる ✤ シナリオの分岐を含めた実行順序を全部まとめて一列に並べたものがプロダクト バックログ ✤ 優先順位で並んでいるわけではない ✤ 実行(するつもりの)順序で並んでいる。 ✤ プロダクトバックログ全体の価値評価が最大になるように 45
46. ❌ 価値の大きいものから並べる ⭕ 価値が大きくなる順序に並べる(もちろん実行可能でなければならない) 46
47. プロダクトバックログ ✤ プロダクトバックログは、プロダクトを完成させるためのやることリストではない ✤ プロダクトゴールは経過地点にすぎない ✤ プロダクトバックロは、プロダクトを成功させるための現時点の想定シナリオである 47
48. PBIの生きる道 ✤ そのまま実施される->ない ✤ いきなり廃棄される ✤ だんだん分割されていく ✤ 分割される途中で廃棄される ✤ 分割された後で廃棄される ✤ 分割された後で開発されて完成する ✤ 利用される ✤ 開発されたけれど廃棄される 48
49. いつかのケース 49
50. 改造累積フローダイアグラム ✤ PBIの完成までのフローを可視化する ✤ 廃棄したPBI、リリースしたけれども使わなくなって削除したPBI相当分をX軸の下側 にプロットする ✤ PBIの50%以上は廃棄されることになる ✤ プロダクトバックログに関わるメトリクスである、決して目標にしてはならない 50
51. Backlog WIP Done Abandoned Deleted 51
52. PBIの生きる道は厳しい ✤ だんだん小さく分割されていく ✤ 多くのものは廃棄される ✤ 開発されるものを少なく保つ ✤ プロダクトバックログリファインメントはそのためにある(精錬) 52
53. Scaling Scrum ✤ ここまでやって、それでもチームの開発能力がボトルネックになっていることに確証 を持てたなら、そろそろスクラムのスケーリングの検討を始めてもよい 53
54. まとめ ✤ オプション価値を考慮することにより、よりプロダクトが成功しやすいようにプロダク トバックログアイテムの順序づけができる ✤ 得られた情報をもとに、さらに価値が高められるように順序を見直し続ける 54
55. それでも ✤ リアルオプションによる価値評価を使ったプロダクトバックログ順位の決定の原則に 従うと、最初からそして継続的に行わなければならない活動がある ✤ PBIを価値判断可能な形に小さく分割できること ✤ PBIを確実にインクリメントにできること ✤ PBIをリードタイム短くインクリメントにできること 55
56. チーム能力獲得・向上に継続投資すること 56
57. https://www.attractor.co.jp/service/scrum-deep-dive/

Comment

No comments...