ビルドトラップからの脱却

お客様向けの講演資料です。過去のスライドをアップデートしたものです

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. ビルドトラップからの脱却 2025/12/12 fi 株式会社アトラクタ / Certi ed Scrum Trainer （CST） 吉羽 龍太郎 （@ryuzee）
2. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー （CST） 認定チームコーチ (CTC) ▸ Microsoft MVP （DevOps） ▸ X（Twitter）: @ryuzee ブログ: https://www.ryuzee.com/ 2
3. 自己紹介 最新書籍紹介（買ってください!!） 3
4. ビルドトラップからの脱却 本日の話 ▸ プロダクトマネジメントでよく陥る「ビルドトラップ」と呼ばれる罠について ▸ 「ビルドトラップ」とは何か？ ▸ 「ビルドトラップ」の症状 ▸ 「ビルドトラップ」のチェックポイント ▸ 「ビルドトラップ」への対応 ▸ を見ていきます 4
5. 会社では『アウトプット』という言葉 がよく使われる……
6. ビルドトラップからの脱却 アウトプットとは？ ▸ 辞書の定義（https://dictionary.cambridge.org/ja/dictionary/english/output） ▸ an amount of something produced by a person, machine, factory, country, etc. ▸ an amount that a person, machine, or organization produces ▸ the amount of goods and services, or waste products, that are produced by a particular economy, industry, company, or worker ▸ アウトプットとは人や機械や組織が作った物の「かたまり」や「量」を示すもの 6
7. ビルドトラップからの脱却 7 アウトプット/アウトカム/インパクト ✤ 開発、リリースしたプ ✤ 顧客が抱える問題の解決 ロダクトの機能 ✤ こなしたタスク ✤ 書いたコードの量… ✤ 行動の変容… ✤ それによって組織に与え た影響（金銭的な）… 図は https://blog.crisp.se/2019/10/16/christopheachouiantz/output-vs-outcome-vs-impact より引用
8. ビルドトラップからの脱却 8 アウトプット/アウトカム/インパクト アウトプットが最重要なわけではない ✤ 開発、リリースしたプ ✤ 顧客が抱える問題の解決 ロダクトの機能 ✤ こなしたタスク ✤ 書いたコードの量… ✤ 行動の変容… ✤ それによって組織に与え た影響（金銭的な）… 図は https://blog.crisp.se/2019/10/16/christopheachouiantz/output-vs-outcome-vs-impact より引用
9. リリース（=アウトプット）はゴールではない
10. ビルドトラップからの脱却 プロダクトの価値はどこで決まるのか？ 価値は提供元のチームや組織の外側で決まる (顧客やユーザーが決める) 10
11. ビルドトラップからの脱却 11 価値交換システム $$$ ▸ 顧客やユーザーにとっての価値は、問題を解決したり要望やニーズを叶えること ▸ 本質的に、プロダクトやサービスそのものに価値があるわけではない ▸ ビジネスにとっての価値は、お金、データを始めとしたビジネスを活性化するもの ▸ この価値交換を継続しなければいけない 図は『プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける』（オライリー）より引用
12. ビルドトラップからの脱却 12 ビルドトラップとは？ ▸ アウトカム はなくアウト ット 成功を計測しようとして、行き詰まっている状況 ▸ 実際に生み出された価値 はなく、機能の開発とリリースに集中してしまっている状況 で で プ で 図は https://blog.crisp.se/2019/10/16/christopheachouiantz/output-vs-outcome-vs-impact より引用
13. ビルドトラップからの脱却 13 【おさらい】 プロダクト開発の流れ 問題を設定しなおす ① 解決したい問題を 見つける 繰り返す ② 問題とソリューション の仮説を評価する ③ ソリューションを 作る ④ ソリューションを 評価する ⑤ スケールする 繰り返す ソリューションを設定しなおす デザイン思考など リーンスタートアップなど アジャイル開発 少人数/安価 大人数/高価
14. ビルドトラップからの脱却 14 注力しがちな領域（ビルドトラップの兆候） 問題を設定しなおす ① 解決したい問題を 見つける 繰り返す ② 問題とソリューション の仮説を評価する ③ ソリューションを 作る ④ ソリューションを 評価する ⑤ スケールする 繰り返す ソリューションを設定しなおす デザイン思考など リーンスタートアップなど アジャイル開発 少人数/安価 大人数/高価
15. ビルドトラップからの脱却 15 多くの機能は使われない ▸ 2019年Pendoの調査 12% 8% まったく使わない 24% ▸ Pendoはプロダクトマネジメント関連のSaaS企業 ▸ 24%の機能はまったく使われない ▸ 80%の機能はほとんど/まったく使われない ▸ 昔と状況は変わっていない ほとんど使わない 56% まったく使わない ほとんど使わない よく使う いつも使う 出典 https://www.pendo.io/resources/the-2019-feature-adoption-report/
16. テキスト Source: https://twitter.com/lukehannontv/status/794581557357015040
17. ビルドトラップからの脱却 機能が増えるとユーザー満足度は下がる Source: Creating Passionate Users, Kathy Sierra, https://headrush.typepad.com/ 17
18. ビルドトラップからの脱却 18 そもそも価値があると思いこんで作ると？ アイデアで盛り 上がる 思った通りの結 果がでない… なんとか頑張っ てリリース 作ろうとすると 課題が山積み ビジネス アイデアを考える 計画をたてる 技術 開発を行う 都合の良い数 字だけ報告 ローンチ!! 年度末の報告
19. ビルドトラップからの脱却 19 (参考) スタートアップ失敗の理由 ニーズがない 資金が尽きた 適切じゃないチーム 競合に負けた 価格・コスト 不親切な製品 ビジネスモデル欠如 稚拙なマーケティング 顧客無視 時期を逸した フォーカスの欠如 チームと投資家の不仲 ピボットが裏目 情熱の欠如 地理的拡大の失敗 投資家の関心が得られない 法律面での課題 ネットワークの未活用 燃え尽き ピボット失敗 23% 42% 29% 19% 18% 17% 17% 14% 14% 13% 最大の問題はニーズのないものを作ること 13% 13% 10% 9% 9% 8% 8% https://www.cbinsights.com/research/startup-failure-reasons-top/ 8% 8% 7% 0% 12.5% 25% 37.5% 50%
20. 人が欲しがるものを作れ Paul Graham（ポール・グレアム） Y-combinator 創業者 写真: CC BY 2.0
21. ビルドトラップからの脱却 21 プロジェクトはプロダクト開発の一部 ▸ プロダクト開発の1要素としてプロジェクトがある ▸ プロダクト価値の最適化を実現するためにプロジェクトを行う ▸ プロダクトはプロダクトの軸で評価 しなければいけない ▸ プロダクトを「プロジェクトの軸」で評価 するとおかしなことになる プロジェクト プロジェクト プロジェクト プロジェクト プロジェクト プロジェクト プロジェクト プロジェクト プロジェクト プロジェクト プロジェクト プロジェクト プロダクト プロジェクト
22. ビルドトラップからの脱却 22 プロダクトとプロジェクトは明確に違う。混同すると問題が起きる プロダクト プロジェクト 予算 チームに予算が割り当てられる 決められたソリューションやスコープを元に 算出する 予算の範囲 全範囲。運用なども含む。 途中でピボットすることも 作り終わるところまで 人の割当 ずっと同じ部門で フェーズごとに違う部門のことも チームの存続期間 プロダクトが続く限りずっと 作り終わったら解散することも 製品価値の検証 継続的に検証 事前に詳細に検証 成功の基準 ビジネス価値の実現 予算と期限とスコープの達成
23. ビルドトラップからの脱却 23 (再掲) ビルドトラップとは？ ▸ アウトカム はなくアウト ット 成功を計測しようとして、行き詰まっている状況 ▸ 実際に生み出された価値 はなく、機能の開発とリリースに集中してしまっている状況 で で プ で 図は https://blog.crisp.se/2019/10/16/christopheachouiantz/output-vs-outcome-vs-impact より引用
24. ビルドトラップ怖いですね……
25. ビルドトラップからの脱却 25 ビルドトラップの兆候 ▸ 根拠なく積まれた売上目標 ▸ 約束されたロードマップ、長すぎるバックログ ▸ 競合他社との機能比較 ▸ 必要性の分からない機能 ▸ 「（開発）生産性」やベロシティといった単語がやたらと使われる ▸ ステークホルダーの干渉 ▸ 権限のないプロダクトチーム、意思のないプロダクトチーム ▸ 利用状況などのメトリクスを取っていない ▸ 役に立たないKPI ▸ ……（思いつくものを是非挙げてください!!） 思い当たるものがないか、 チーム内で話し合ってみましょう！
26. ビルドトラップからの脱却 ▸ ビルドトラップの対処に役立つかもしれない7つの項目を見ていきましょう ▸ 全部やらなければいけないわけではないです ▸ カイゼンは効果の高いところから1つづつやるのが鉄則 26
27. 27 1. 適切なプロダクトマネージャーを据える ▸ ミニCEO、ウェイター、プロジェクトマネージャーではない ▸ プロダクトマネージャーは「なぜ」に責任を持つ。「なぜ」から始める ▸ な これを作るのか? ▸ ▸ うやって顧客に価値を届けるのか? ネス目標を達成する上 う役に立つのか? ▸ 会社のビジョンや目標、ビジネス、マーケットを理解する ▸ ユーザーに対する共感、人に影響を与えるスキル、技術者と会話できる程度の知識…… ど で ぜ ▸ 実験から学習を続けるマインドセット ジ ビ ど ビルドトラップからの脱却
28. 28 プロダクトを成功させる上での重要な質問 プロダクトマネージャーはこういう質問 に答えられなければいけない うやって価値を判断するのか? ▸ ▸ マーケット の ロ クトの成功を のように評価するか? ▸ 適切なものを作っていることを確認するには うしたらよいか? ▸ ロ クトの価格と ッケー は うやって決めるか? ▸ うやって ロ クトをマーケットに投入するか? ▸ 自分たち 作るのとありものを買ってくるの は、 ちら よいか? ▸ サー ーティのソフトウェアと連携するには うすれ よいか? が ば ど ど ど で ど ど ジ ダ パ プ ダ プ で で パ ド 『プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける』（オライリー） p.42より引用 ダ ど プ ど ビルドトラップからの脱却
29. ビルドトラップからの脱却 29 危険の兆候（アジャイルコーチのチェックポイント） ▸ 価値の検証をする前に、作ることが決まっているプロダクトがある ▸ プロダクトの状況（成功しそう、失敗しそう）を早い段階から評価する仕組みが不 十分 ▸ 適切な物を作っているかどうかを直接顧客やユーザーに確認する機会が少ない
30. ビルドトラップからの脱却 スクラムを回すだけにフォーカスしない 30
31. ビルドトラップからの脱却 スクラムを回すだけにフォーカスしない プロダクトマネージャーやプロダクトオーナーは プロダクトバックログ管理・供給マシーンでは不十分 31
32. ビルドトラップからの脱却 32 2. 適切なチーム構成にする ▸ バリューストリームを最適化するようにチームを構成する ▸ 問題発見〜目標の設定〜アイ アの創出〜 リ リーまでの一連の流れ ▸ 顧客への価値の運搬を最適化するには、 んな構成にすれ よいかを考える ▸ コンポーネントチームにしない ▸ 受け渡し（外部依存）の回数が増えれば価値の運搬はどんどん遅くなる ▸ チームの「稼働率」の最適化への関心は、アウトカムが達成できていなければ無意味 ▸ チームは自律的で、自分たちで意思決定できなければいけない ば バ デ ど デ で ▸ 新しいことを試して失敗 きる安全な環境
33. ビルドトラップからの脱却 33 危険の兆候（アジャイルコーチのチェックポイント） ▸ プロダクトの企画組織とプロダクトの開発組織が別組織になっている ▸ それぞれがまったく別の目標設定をしている ▸ 開発組織のメトリクスはアウトプットが中心になっている ▸ プロダクトの成否に関係なく、量を作ったり期日にリリースしたりすることが優 先されている ▸ それらが人事考課に直結している ▸ 全員がアウトカムやインパクトに目が向いているわけではない
34. ビルドトラップからの脱却 34 3. 適切な戦略を組織に行き渡らせる ▸ 戦略とは、詳細な計画のことではない ▸ 詳細な計画にこだわると、ガラクタを大量に作ることになる => ビルドトラップ ▸ 戦略とは、意思決定を助けるフレームワーク ▸ 戦略とは実行可能な意思決定のフレームワーク あり、現在のコンテキストとの整合性を保ちな ら、現在の能力の制約のもと 、望ましいアウトカムを達成するための行動を可能にするもの ある （『The Art of Action』 ） ▸ 毎年ころころ変わるようなものでもない（そうなっているなら単なる計画） ▸ 重要なことは何度でも伝えなければいけない（100回でも1000回でも） が で で で ▸ 相手がわかっていないのは、伝える側の問題
35. ビルドトラップからの脱却 35 危険の兆候（アジャイルコーチのチェックポイント） ▸ プロダクトの価値検証の前に詳細な計画を作っている ▸ プロダクトマネージャーやプロダクトオーナーの「いいからプロダクトバックログ アイテムをたくさん実装して」のようなセリフ ▸ 開発者の「プロダクトバックログアイテムを用意してくれないと作業できない」の ようなセリフ ▸ 開発チームが戦略のことを話しているのを聞く機会が少ない
36. ビルドトラップからの脱却 36 4. ソリューションの前に問題を理解する ▸ 問題を根本的に理解していなけれ 、適切なソリューションは作れない ▸ 人間は基本的にソリューションを考えるほうが得意で、優先しがち ▸ 「機能がない」のは問題か？ ▸ ユーザーはプロダクトが欲しいのではなく、自分の課題やニーズを解決したいだけ ば ▸ 建物の外に出ろ
37. ソリューションではなく 問題に恋をしろ。 そうすれば、 あとのことはついてくる Uri Levine イスラエルの起業家 写真: CC BY 2.0
38. ビルドトラップからの脱却 38 危険の兆候（アジャイルコーチのチェックポイント） ▸ 顧客やユーザーのところに「直接」訪問したり、レビューに招待したりする機会が少 ない ▸ 生の声を聞くのではなく、アンケートや調査会社への委託で済ませている ▸ すなわち、ネガティブなフィードバックを恐れている ▸ そもそも、開発者自身が、ソリューションがイケてないと思っている（のにそのまま 進めている）
39. ビルドトラップからの脱却 5. ソリューションを探索する ▸ 学習のために実験する ▸ 仮説が正しいかどうかを証明するために、なるべく素早く行う ▸ 最終的には作ったものは捨てる（と思っていたほうが実験しやすい） ▸ いろいろな実験方法 ▸ コンシェルジュ（顧客に代わって手作業でやってみる） ▸ オズの魔法使い（裏側に人がいる） ▸ コンセプトテスト（コンセプトをデモしたり、ランディングページを用意したりする） ▸ 生成AIを使うとだいぶ楽に実験できる 39
41. 創業時、本当に靴をオンラインで買ってくれるかを明らかにするため ブログツールを使ってサイトを立ち上げ、 注文のたびに自分で靴を買いに行って発送した（オズの魔法使い）
42. ビルドトラップからの脱却 危険の兆候（アジャイルコーチのチェックポイント） ▸ 実験せずに大掛かりに作っている ▸ 機能自体も仮説にすぎないので外れることがあるが、外れたものを捨てない ▸ そもそも仮説が当たったのか外れたかを検証していない 42
43. ビルドトラップからの脱却 6. 適切な指標を定めて活用する ▸ プロダクトやビジネスの健全性を示す指標を追跡する ▸ ユーザー数、PVなどは虚栄の指標でビジネスの意思決定の役に立たない ▸ 完成した機能の数、ストーリーポイントなども同じ（生産性の指標にはなるかも） ▸ 事実や数字にコンテキストや意味を加える ▸ 海賊指標（AARRR）、HEARTフレームワークなど ▸ プロダクトごとに見るとよい指標は違う ▸ チームが目指す方向を示すNorth Star Metricを決めるとよい ▸ データを計測できるツールを用意しておく 43
44. ビルドトラップからの脱却 44 NORTH STAR METRICの例 ▸ Attention ユーザーがプロダクト上でどれくらい時間を過ごすかが重要なプロダクト ▸ Transaction ユーザーのトランザクション実行量やコンバージョンが重要なプロダクト fl ▸ Productivity ユーザーがどれくらいタスクを実行するか、便利になるかが重要なプロダクト Net ix Attention 月間N時間以上視聴しているユーザーの数 Spotify Attention 有償顧客の月間楽曲再生時間の合計 Amazon Transaction 1プライムユーザーあたりの購入金額の合計 Walmart Transaction 顧客の1回あたりの購入点数 Salesforce Productivity アカウントあたりの平均レコード作成数 Adobe Productivity エンゲージメントが高いサブスク購入者数
45. ビルドトラップからの脱却 危険の兆候（アジャイルコーチのチェックポイント） ▸ ユーザー数やPV数などを目標値にする ▸ 企画と開発側のあいだで、プロダクトのメトリクスを議論する頻度が少ない ▸ 企画と開発側で別々のメトリクスを追っている ▸ 途中で明確な説明がないまま、追跡するメトリクスが変わる ▸ 数字の意味づけまで踏み込んでいない 45
46. ビルドトラップからの脱却 7. 組織をプロダクト主導にする ▸ 顧客中心主義を体現する ▸ プロダクトの成功は実験と学習から。安全に学習できる環境を作る ▸ 実験は究極のリスクマネジメント ▸ アウトカムに着目したコミュニケーション ▸ 古い予算制度からの脱却（投資モデルへ） ▸ 適切な報酬やインセンティブ制度（アウトプットで評価するとビルドトラップ） ▸ とはいえ、現場から変えていくのは難しい ▸ マネージャー層が組織的に働きかけるべき。それこそがマネージャーの仕事 46
47. ビルドトラップからの脱却 失敗を受け入れる ▸ 「実験はその性質からしても失敗しやすいものですが、それでもやるべきだと 思います。何十回も失敗するかもしれませんが、一つ大きな成功をすれば十 分取り返せるのですから」 ▸ 「継続して実験を行わない会社や、失敗を許容しない会社は、最終的には絶望 的な状況に追い込まれます。(略)一方、常に賭け続けてむしろ賭け金を引き上 げていくような会社は、実は社運そのものを賭けるようなことはしないので、 勝ち残ります」 ▸ 「失敗は、当社が他社と一線を画している分野だと思います。当社は、おそらく 世界一失敗に適した場所です。(略)失敗と革新は対の関係にあり、切り離すこ とはできません」 『ベゾス・レター アマゾンに学ぶ14ヵ条の成長原則』（すばる舎）より引用 47
48. ビルドトラップからの脱却 危険の兆候（アジャイルコーチのチェックポイント） ▸ 組織のプロジェクト思考が根強い ▸ 以下を優先している ▸ 期間内に収める、あらかじめ考えた機能を全部作る、予算に収める 48
49. ビルドトラップからの脱却 49 まとめ ▸ ビルドトラップとは機能の開発やリリースに集中し、アウトプットで成功を計測しようとして行き詰まっている状況 ▸ ビルドトラップを回避するためにできることはたくさんある ▸ 適切なプロダクトマネージャー ▸ 適切なチーム構成 ▸ 戦略を組織に行き渡らせる ▸ ソリューションの前に問題を理解する ▸ ソリューションを探索する ▸ 適切な指標を定めて活用する ▸ 組織をプロダクト主導にする

Comment

No comments...