1. 価値をすばやく届けるための改善 2023/3/3 吉羽龍太郎（@ryuzee）
2. 吉羽龍太郎 / Yoshiba Ryutaro アジャイル開発、DevOps、クラウドコンピューティング、インフラ構築自 動化、、組織改革を中心にオンサイトでのコンサルティングとトレーニン グを提供。Scrum Alliance認定スクラムトレーナー(Regional, CST-R) チームコーチ(CTC) / 認定スクラムプロフェショナル(CSP) / 認定スク ラムマスター(CSM) / 認定スクラムプロダクトオーナー(CSPO) 2
4. 株式会社アトラクタについて ✤ 社名：株式会社アトラクタ 英文表記：Attractor Inc. / https:// www.attractor.co.jp ✤ 設立：2016年12月 ✤ 所在：東京都港区 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデ リングなどが専門領域 4
5. 技術顧問やアジャイルコーチングのご相談は お気軽にご連絡ください！ 「株式会社アトラクタ」で検索
6. アウトプット/アウトカム/インパクト ✤ ✤ ✤ 開発、リリースしたプ ロダクトの機能 こなしたタスク 書いたコードの量… ✤ ✤ 顧客が抱える問題の解決 行動の変容… ✤ それによって組織に与え た影響（金銭的な）… 図は https://blog.crisp.se/2019/10/16/christopheachouiantz/output-vs-outcome-vs-impact より引用 6
7. アウトプット/アウトカム/インパクト アウトプットが最重要なわけではない ✤ ✤ ✤ 開発、リリースしたプ ロダクトの機能 こなしたタスク 書いたコードの量… ✤ ✤ 顧客が抱える問題の解決 行動の変容… ✤ それによって組織に与え た影響（金銭的な）… 図は https://blog.crisp.se/2019/10/16/christopheachouiantz/output-vs-outcome-vs-impact より引用 7
8. 価値交換システム $$$ ✤ 顧客やユーザーにとっての価値は、問題を解決したり要望やニーズを叶えること（アウトカム） ✤ 本質的に、プロダクトやサービスそのものに価値があるわけではない ✤ ビジネスにとっての価値は、お金、データを始めとしたビジネスを活性化するもの ✤ この価値交換を継続しなければいけない 図は『プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける』（オライリー）より引用 8
11. アウトカムを決める要素 問題設定力 開発力 チーム力 ✤ 適切な問題設定 ✤ ドメイン知識 ✤ 開発プロセス習熟 ✤ 明確なビジョン ✤ アーキテクチャ設計力 ✤ 心理的安全性 ✤ マーケットの理解 ✤ 開発言語 ✤ 透明性 ✤ 取捨選択 ✤ 性能 ✤ 検査と適応 ✤ 良いプロダクトバックログ ✤ セキュリティ ✤ ムダをなくす ✤ 優先順位付け ✤ インフラストラクチャー ✤ 学習 ✤ ステークホルダー管理 ✤ 自動化 ✤ リーダーシップ ✤ リスク・コスト管理 ✤ 品質・テスト ✤ オーナーシップ ✤ … ✤ … ✤ … 11
12. 個々の領域への着目度合いのバランス 問題設定力 開発力 チームとしては楽しくは感じるかもしれない。 だが、ステークホルダーから見るとどう見える？ => 部分最適 チーム力 100% 12
13. 個々の領域への着目度合いのバランス 問題設定力 開発力 チーム力 50% 50% そこそこ良いチームがそこそこいい感じに進められるが、アウトカムはどう？ => 部分最適 13
14. 個々の領域への着目度合いのバランス 問題設定力 開発力 チーム力 いまどこに着目すべきかの強弱をつけながら、全ての領域を考えていく 14
15. アウトカムに着目した改善 ✤ なにを改善する必要があるのか？ ✤ なぜその改善は必要なのか？ ✤ 具体的に何をするのか？ ✤ 改善の結果をどう測るのか？ ✤ その改善はどうアウトカムに結びつくのか？ ✤ なぜ今なのか？ これってプロダクトバックログと 同じじゃない？ 目先の小さな改善ばっか り追いかけると部分最適にしかな らない 15
16. 改善を持続可能なペースで続ける ✤ 強制的に立ち止まれる仕掛を入れる ✤ たとえばスクラムではスプリントレトロスペクティブは改善点を見つけるイベントであ ると同時に強制停止のイベントでもある ✤ 人間は止まるのがそもそも苦手なので、機械的に停止させる 16
18. プロダクト開発の流れに共通する考え方 課題を設定しなおす ① 解決したい課題を 見つける 繰り返す ② 課題とソリューション の仮説を評価する ③ ソリューションを 作る ④ ソリューションを 評価する ⑤ スケールする 繰り返す ソリューションを設定しなおす デザイン思考など リーンスタートアップなど アジャイル開発 少人数 安価 大人数 高価 18
19. 注力しがちな領域 課題を設定しなおす ① 解決したい課題を 見つける 繰り返す ② 課題とソリューション の仮説を評価する 注力しがちな領域 ③ ソリューションを 作る ④ ソリューションを 評価する ⑤ スケールする 繰り返す ソリューションを設定しなおす デザイン思考など リーンスタートアップなど アジャイル開発 少人数 安価 大人数 高価 19
20. 結果的にムダなものを大量に作ることになる いつも使う 7% よく使う 16% ✤ ✤ まったく使わない 45% ✤ たまに使う 13% ほとんど使わない 19% 2002年米国スタンディッシュグループの調査 2019年にPendoが行った調査 ✤ ✤ 64%の機能はほとんど、もしくはまったく使わ れない 80%の機能はほとんど、もしくはまったく使わ れない いわゆるビルドトラップ 20
21. https://twitter.com/lukehannontv/status/794581557357015040 21
22. 機能が増えるとユーザー満足度は下がる Creating Passionate Users, Kathy Sierra, https://headrush.typepad.com/ 22
23. 本当に重要なのはどこ？ 課題を設定しなおす ① 解決したい課題を 見つける 繰り返す ② 課題とソリューション の仮説を評価する ③ ソリューションを 作る ④ ソリューションを 評価する ⑤ スケールする 繰り返す ソリューションを設定しなおす デザイン思考など リーンスタートアップなど アジャイル開発 少人数 安価 大人数 高価 23
24. 実験を繰り返し、失敗を受け入れる ✤ 「実験はその性質からしても失敗しやすいものですが、それでもやる べきだと思います。何十回も失敗するかもしれませんが、一つ大きな 成功をすれば十分取り返せるのですから」 ✤ 「継続して実験を行わない会社や、失敗を許容しない会社は、最終的 には絶望的な状況に追い込まれます。(略)一方、常に賭け続けてむし ろ賭け金を引き上げていくような会社は、実は社運そのものを賭ける ようなことはしないので、勝ち残ります」 ✤ 「失敗は、当社が他社と一線を画している分野だと思います。当社は、 おそらく世界一失敗に適した場所です。(略)失敗と革新は対の関係に あり、切り離すことはできません」 24
25. Googleが終了したサービス 出典: https://killedbygoogle.com/ 25
26. 実際のプロダクト開発はコストがかかる ✤ そもそも必要とされていないプロダクトをお金と時間と労力をかけて作るのは無駄 ✤ かといって長大な計画を練っても当たらない ✤ アイディアだけでは評価できない（動作するソフトウェアが価値） ✤ できるだけコストをかけずに素早くアイディアを検証したい ✤ ”芽があること”を確認してから作り込んでいきたい 26
27. 課題 ソリュ 圧倒的 ソリュ 圧倒的 ーショ ン な優位 性 ーショ ン な優位 性 主要指 標 独自の 価値提 案 コスト構造 課題 ソリュ ーショ ン 主要指 標 収益の流れ 独自の 価値提 案 コスト構造 課題 ソリュ ーショ ン 主要指 標 課題 主要指 標 コスト構造 圧倒的 な優位 性 チャネ ル 顧客セ グメン ト 収益の流れ 独自の 価値提 案 コスト構造 ソリュ ーショ ン チャネ ル 顧客セ グメン ト 圧倒的 な優位 性 チャネ ル 課題 主要指 標 独自の 価値提 案 コスト構造 ソリュ ーショ ン 課題 主要指 標 チャネ ル 顧客セ グメン ト 収益の流れ 独自の 価値提 案 コスト構造 圧倒的 な優位 性 チャネ ル ソリュ ーショ ン 課題 主要指 標 独自の 価値提 案 コスト構造 顧客セ グメン ト 圧倒的 な優位 性 チャネ ル 顧客セ グメン ト 収益の流れ 一発一中にはならないので、 複数のプランを作り評価を繰り返す。 収益の流れ 評価の結果いけそうなら作る。 やってみた結果、やっぱり”芽がない”なら 早く止めなければいけない 顧客セ グメン ト 収益の流れ 独自の 価値提 案 圧倒的 な優位 性 チャネ ル 顧客セ グメン ト 収益の流れ 課題 ソリュ ーショ ン 主要指 標 コスト構造 独自の 価値提 案 圧倒的 な優位 性 チャネ ル 顧客セ グメン ト 収益の流れ 課題 ソリュ ーショ ン 主要指 標 コスト構造 独自の 価値提 案 圧倒的 な優位 性 チャネ ル 顧客セ グメン ト 収益の流れ 課題 ソリュ ーショ ン 主要指 標 コスト構造 独自の 価値提 案 圧倒的 な優位 性 チャネ ル 顧客セ グメン ト 収益の流れ
28. うまくたくさん作ることが最重要なわけではない ✤ アウトカム（成果）の方が重要 ✤ アウトカムと生産性を比べてみると (生産性 = 生産量 / 投下時間 つまりベロシティ) ✤ アウトカムはでないが生産性は高い = ゴミの高速生産 ✤ アウトカムはでてるが生産性は低い = なにか問題でも？ ✤ アウトカムはでてないし生産性も低い = つらい人生… ✤ もっと全員がアウトカムにフォーカスする必要性 ✤ そのためにはフィードバックが何よりも重要 28
29. 問題設定力の領域での改善 ✤ たくさん作ること（アウトプット）を目的化するのをやめる ✤ 解決すべき重要な課題（の仮説）にフォーカスする ✤ 作ることはコストがかかるので、作る前に仮説を検証する ✤ 作ったものは効果を計測する ✤ 失敗したり役に立たなかったりしたものは潔く捨てる 29
31. 開発力の観点 ✤ よいアイデアがあっても、実現できないと話にならない ✤ アイデアがよくなくて、開発力があるとプロダクトアウトのできあがり ✤ 開発に時間がかかってしまうと、競争に負けるかもしれない ✤ 開発力がなければ、アイデアの実現にお金もたくさんかかってしまうかもしれない ✤ 品質が低ければ、持続的にプロダクトを成長させられないかもしれない ✤ 当然の帰結として、開発力は重要 ✤ 実は開発力に課題のあるチームは結構多い 31
32. 短い間隔で安定して価値を届けるには？ ✤ 短い期間に区切って繰り返す（最近は1週間スプリント/イテレーションが多い） ✤ 短い期間の中で設計・開発・テストを終わらせる必要 ✤ 短い期間のなかで変更が加えられるような構造が必要 ✤ 短い期間のなかで意味のあるものを生み出せるだけの開発力（基礎体力）が必要 ✤ 過去に作ったものを壊していないことも担保しなければいけない 32
33. テスト自動化の必要性 ✤ 手作業で確認するのは時間がかかりすぎる（何度もやれば余計に） ✤ 手作業で確認すると、手順を間違えたり、結果の判断を間違える ✤ プロダクトが成長するにつれて、手作業は重荷になってしまう ✤ （全てのプロダクトで初期からテスト自動化が必須なわけではない） ✤ チームにもっと価値の高いところに集中してもらう ✤ 「生きたドキュメント」になる。テストが仕様を表す ✤ 何度でも実行できるし、実行に時間もかからないので、テストの障壁が下がる 33
34. 品質や速度低下の兆候を見つけたら継続的に対処する ✤ テストの所要時間の増加 ✤ バグの増加 ✤ リリースの延期 ✤ コードの重複 ✤ カバレッジの低下 ✤ 可読性の低いコード ✤ 技術選択の誤り ✤ ハック こういう兆候に対処していく。 借金するなら計画的に 機能開発に常に目一杯の時間 使ったらどうなる？ 34
35. スキル領域の制約によるボトルネックの発生 フロントエンド設計 フロントエンド開発 スプリント内 ミニウォーターフォール の危険 バックエンド設計 バックエンド開発 結合・テスト IOS設計 IOS開発 フロントエンドしかできない（しない）、サーバーサイドしかできない、iOSしかできない、 テストしかできない人で開発チームを組むとどうなるか？ 35
36. クロスファンクショナルでないと待ちが増える ✤ 開発チーム全体として、プロダクトを完成できる能力を持つ必要があるのは前提 ✤ その中でもボトルネック、依存関係を減らさないと待ちが増える ✤ 開発チーム内で分業が進むと、見積りに対して関心が持てなくなる ✤ T字型のスキルセット、TT字型のスキルセットに変えていく 36
37. 改善促進効果の高いケイパビリティ24個 継続的デリバリ アーキテクチャ リーン指向の管理と監視 組織文化 バージョン管理 疎結合アーキテクチャ 変更承認プロセス 創造的な組織文化 デプロイの自動化 チームへの権限付与 監視 学びの支援 継続的インテグレーション 製品とプロセス プロアクティブ通知 チーム間の協働 トランクベース開発 顧客フィードバック WIP制限 職務満足度 テスト自動化 業務プロセス可視化 作業の可視化 改善を推進するLS テストデータ管理 作業の細分化 情報セキュリティシフトレフト チームによる実験 継続的デリバリー LeanとDevOpsの科学より 37
38. 開発力の領域での改善 ✤ 技術に向き合う。技術がなければ、素早い変化には対応できない ✤ 作る量を減らしてでも、安定したパフォーマンスを出せるような投資をする ✤ ペアプロ、モブプロ、技術メンターなど ✤ トレーニングや個人学習の時間 ✤ 練習しないとうまくならない ✤ 継続的にテストできるようにする（テスト自動化や探索的テスト） ✤ 速度や品質低下の兆候には継続的に対処する ✤ クロスファンクショナルを実現する 38
40. プロセスの話 ✤ みんな大好き開発プロセス ✤ 地道に繰り返し改善していけばよい（ので今日は割愛） 40
41. ff E ective DevOps ―4本柱による持続可能な組織文化の育て方 41
42. 機能しないチームでは話にならない ⑤結果への 無関心 ④説明責任の 回避 ③責任感の不足 ②衝突への恐怖 ①信頼の欠如 42
44. 意見を言えて、改善や実験（と失敗）を繰り返せる安全性が ハイパフォーマンスにつながる 44
45. コミュニケーションの複雑性を抑える ✤ ✤ 1チームは10人程度までが適正 ✤ 人数が増えるとコミュニケーションのオー バーヘッドが増える ✤ ダンバー数（5人まで、15人まで……） チーム同士のコミュニケーションも、対象の チームが増えると複雑になり、動きがどんどん 遅くなる ✤ プロジェクトの規模を小さくする必要 ✤ チーム間を疎結合にする必要 fl 出典 https://stackover ow.com/questions/984885/how-do-i-explain-the-overhead-of-communication-between-developers-in-a-team 45
46. The API Mandate (ジェフ・ベゾス) 1. すべてのチームは、今後、サービス・インターフェースを通じてデータや機能を公開する 2. 各チームはこれらのインターフェイスを通じて相互に通信しなければいけない 3. 他の形式のプロセス間通信は一切認めない。ダイレクトリンク、他のチームのデータストアの直接 読み込み、共有メモリモデル、バックドアなどは一切認めない。唯一許される通信は、ネットワーク を介したサービス・インターフェース・コールによるものとする 4. どのような技術を使用するかは問わない。HTTP、Corba、PubSub、カスタムプロトコルなど、何でも 構わない 5. すべてのサービスインターフェースは、例外なく、外部化可能なように一から設計しなければいけ ない。つまり、チームは、外部の開発者にインターフェイスを公開できるように計画・設計しなけれ ばいけない。例外はない 6. これに従わない人は解雇する 出典: https://api-university.com/blog/the-api-mandate/ 46
47. チームの認知負荷を考慮する ✤ 人間が脳にとどめておける情報の量には限りがある ✤ 同じことはチームにも言える ✤ チームの責任範囲や担当範囲が広がりすぎると…… ✤ コンテキストスイッチが大きくなる ✤ 優先順位がつけられなくなる ✤ 結果としてモチベーションも低下する 47
48. 認知負荷に合うように責任範囲を制限する ✤ チームが扱うソフトウェアの(サブシステムの)サイズを制限する ✤ チームの認知負荷にあわせてソフトウェア境界を選ぶ ✤ ソフトウェアの認知負荷の計測には、ドメイン複雑度に特に注目する（それだけではない） ✤ チームが扱うドメインの種類を制限する ✤ シンプル（これは1チームで複数担当できることもある） ✤ 煩雑（これに該当する複数ドメインに大きなチームで取り組むより、チームを分割する） ✤ 複雑（このドメインは集中して取り組む必要がある） 48
49. 複数プロジェクト兼任は悪影響しかない プロジェクト数 1プロジェクトあたりの稼働可能時間 コンテキストスイッチによるロス 1 100% 0% 2 40% 20% 3 20% 40% 4 10% 60% 5 5% 75% Weinberg, Gerald M. (1992) Quality Software Management: Systems Thinking. Dorset House, p. 284. 49
50. これらを踏まえてチームを構成する ✤ ✤ これらを踏まえてチームを構成する ✤ ただし組織構造をいじるのは、ほかの改善のあとの方がよいかも ✤ そうしないとムダなものを大量に作りやすい構造になってしまう どうやって？ ✤ 価値の流れを中心に置く ✤ コンウェイの法則を踏まえる 50
51. 4つのチームタイプ ✤ 多くの組織にはさまざまな種類のチームがある ✤ ✤ ✤ チームの役割を無計画に拡張して、誰も全体がわからない チームの種類を4つに絞ることでこの課題に対処する ✤ ストリームアラインドチーム ✤ プラットフォームチーム ✤ イネイブリングチーム ✤ コンプリケイテッド・サブシステムチーム チームタイプに応じた目的、役割、責任を担う 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p.xv） 51
52. 3つのインタラクションモード ✤ チーム間の関係性において、相手とコラボレーションするか、サービス・プロバイダーとして使 うかが判断の分かれ道 ✤ ✤ すべてのチームが他の全チームとやりとりするのは避けなければいけない チームがインタラクションする3つの基本的なモード ✤ コラボレーション ✤ X-as-a-Service ✤ ファシリテーション 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p164） 52
53. チーム構成の例 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p165、p177） 53
54. 機能しているチームを長く保つ “ ハイパフォーマンスなチームを解散する のは、単なる破壊行為では済まない。企業 レベルのサイコパスと呼ぶべきものだ アラン・ケリー 『Project Myopia』 ” 54
55. チーム力の領域での改善 ✤ 非難文化から脱却する ✤ ✤ コミュニケーションの複雑性を抑える ✤ ✤ とても難しいが、これができないとどんな手もムダ そのためにチームを小さく保ち、チーム間のインターフェースを規定する チームの認知負荷を考慮して、チームが担当する仕事を決める ✤ 複数プロジェクト/プロダクトの兼任はやめる（人間は小数点では表せない） ✤ 本当に必要なら、価値の流れを踏まえたチーム構造に作り変える ✤ ハイパフォーマンスチームは解体しない 55
56. まとめ ✤ アウトカムに注目して改善する ✤ プロセス改善だけでは無意味 ✤ 複数の領域で改善していく（以下はあくまでも例） ✤ 問題設定力 ✤ ✤ 開発力 ✤ ✤ たくさん作ることを目的にしない、課題にフォーカス、仮説検証、計測、捨てる…… 技術に向き合う、練習、継続的なテスト、問題の兆候に継続的に対処、機能横断…… チーム力 ✤ 非難文化からの脱却、コミュニケーションの複雑性や認知負荷を抑える、ハイパフォーマンス チームを壊さない、本当に必要なら価値の流れに沿ったチームにする…… 56
