1. スクラムチームは改善する問題を 正しく選んでいますか？ 2019年2月23日 株式会社アトラクタ 吉羽龍太郎 (@ryuzee)
2. ✤ 株式会社アトラクタ ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / 改善 / 自動化 / チーム育成 / クラウドコンピューティング / DevOps / ドメインモデリングなどが専門領域 ✤ https://www.attractor.co.jp/
3. WE ARE HIRING!! 5番目のメンバーを募集しております!
4. 自己紹介 ✤ 吉羽龍太郎 (@ryuzee) ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ 野村総合研究所、Amazon Web Servicesなどを経てアトラクタを創業 ✤ 青山学院大学非常勤講師 ✤ アジャイル開発/DevOps/クラウドコンピューティングが得意領域 ✤ Scrum Alliance Certified Team Coach (CTC)
6. “実際のところ、ソフトウェア開発上の問題の多くは、 技術的というより社会学的なものである” –トム・デマルコ/ティモシー・リスター「ピープルウェア」より引用
7. “社会学（しゃかいがく、英: sociology）は、社会現象の実態や、現象の起こ る原因に関するメカニズム（因果関係）を統計・データなどを用いて分析す ることで解明する学問である。その研究対象は、行為、行動、相互作用と いったミクロレベルのものから、家族、コミュニティなどの集団、組織、さら には、社会構造やその変動（社会変動）などマクロレベルに及ぶものまで さまざまである。” Wikipedia（日本語版）より
8. 昨今よく登場する話題 ✤ 組織論の話が、この業界でも多数取り上げられるようになっている ✤ 2019年の「ITエンジニア本」の大賞も、組織論に関する本だった ✤ 2018年に自分が監訳した『Effective DevOps』も組織の本だった
9. プロジェクトアリストテレス ✤ Googleが2012年に開始した労働生産性向上計画プロジェクト ✤ 生産性の高いチームの共通点の洗い出しと成功要因の分析を実施 ✤ 結果や知見をre:Workで公開（https://rework.withgoogle.com/） ✤ NewYork Timesなどでも記事が
11. うまくいっているチームに共通する要素の仮説 ✤ 仕事以外のプライベートでも親しい ✤ 頻繁に飲食をともにしている ✤ 内向的な人同士や外向的な人同士など似た特性の人でチームを構成している ✤ 興味や関心が似ている ✤ 圧倒的なリーダーシップやカリスマ性がある ✤ ボーナスや報酬によるモチベーション ✤ 共通の趣味 ✤ 共通の学歴
13. チームのルールやふるまいに注目 ✤ 個人の能力の合計とチームの能力はイコールではなかった ✤ 個々に対するアプローチより集団に対するアプローチが効果がある ✤ 成果を出したチームにほかのことをやらせても成功するが、失敗するチームは何を やっても失敗する現象 ✤ よい集団規範の有無が及ぼす影響が大きい ✤ ✤ 不文律・習慣・行動基準（明文化の有無は関係ない） 均等な発言機会と共感力・他者理解力があると成功しやすかった ✤ ＝心理的安全性
14. モダンアジャイル https://www.industriallogic.com/blog/modern-agile/
17. ところで・・・ ✤ なぜみなさんはプロダクトの開発をしてい るのでしょうか？
18. プロダクトの提供主体 ✤ プロダクトの開発主体は企業（個人であることもあるが今回は対象外） ✤ 企業でいちばん多いのは株式会社 ✤ 株式会社（かぶしきがいしゃ）とは、細分化された社員権（株式）を有する株主から有 限責任の下に資金を調達して株主から委任を受けた経営者が事業を行い、利益を株 主に配当する、『法人格』を有する会社形態であり、営利を目的とする社団法人である （Wikipediaより） ✤ つまりプロダクトの提供主体は「儲けないといけない」 ✤ ステージによって投資フェーズと回収フェーズが分かれることはある ✤ もちろん社会的な意義や価値も必要だが、存続のためにお金がいる
19. プロダクト・プロジェクトの種類 ✤ ✤ いろいろな分け方があるが、金銭に着目すると以下のように分類できる ✤ 直接的営利 （そこから金銭的な効果を得る） ✤ 研究開発 （この結果を将来の製品などに応用する） ✤ 非営利 （企業として見返りを求めない） いちばん割合が多いのは直接的な営利を目指すもの ✤ ✤ 今日の話のスコープはここ （受託開発はいったん除外しておきます）
21. このプロダクトにはこんなにたくさんの機能があります。 チームは最高で、バグも少なくコードも綺麗です 顧客はいないけど http://www.flickr.com/photos/untitlism/2603959306/
22. 儲からないプロダクトを良い方法論・良いチームで作っても 儲からないことには変わりない http://www.flickr.com/photos/mobilestreetlife/6898757499/
23. 実際のところ儲けるのは難しい… ✤ 失敗の確率（スタートアップの場合） ✤ 投資がすべて水の泡になる => 30-40% ✤ 期待したROIを達成できなかった => 70-80% ✤ 宣言どおりの結果がでなかった => 90-95% 90%!? failure defined as return on investment Why Companies Fail--and How Their Founders Can Bounce Back (http://hbswk.hbs.edu/item/6591.html)
24. スタートアップ失敗の理由 ニーズがない 資金が尽きた 適切じゃないチーム 競合に負けた 価格・コスト 不親切な製品 ビジネスモデル欠如 稚拙なマーケティング 顧客無視 時期を逸した フォーカスの欠如 チームと投資家の不仲 ピボットが裏目 情熱の欠如 地理的拡大の失敗 投資家の関心が得られない 法律面での課題 ネットワークの未活用 燃え尽き ピボット失敗 23% 42% 29% 19% 18% 17% 17% 14% 14% 13% 最大の問題はニーズのないものを作ること 13% 13% 10% 9% 9% 8% 8% 8% https://www.cbinsights.com/research/startup-failure-reasons-top/ 8% 7% 0% 12.5% 25% 37.5% 50%
25. 新しいプロダクトは高い確率で失敗する ✤ ハーバードビジネススクールのクレイトン・クリステンセン氏によると、毎年30,000 ものプロダクトが生み出されて、95%は失敗する ✤ トロント大学のブラックバーン氏によると、食料雑貨店での新プロダクトの失敗率は 70-80%になる ✤ 業種に関係なく、新しいプロダクトは高い失敗率 ✤ ガリガリ君ナポリタン味は3億円の損失
26. 新規ビジネスビッグバン一発勝負(でいいのか？) 収益 リリース 期間は長い 回収できるか分からない 時間 0 累積損失額(投資額) ？ ？ 最初に使うお金が大きい ？
27. 実際のプロダクト開発はコストがかかる ✤ そもそも必要とされていないプロダクトをお金と時間と労力をかけて作るのは無駄 ✤ かといって長大な計画を練っても当たらない ✤ アイディアだけでは評価できない（動作するソフトウェアが価値） ✤ できるだけコストをかけずに素早くアイディアを検証したい ✤ ”芽があること”を確認してから作り込んでいきたい
28. 課題 ソリュ ーショ ン 独自の 価値提 案 主要指 標 コスト構造 課題 ソリュ ーショ ン 課題 ソリュ ーショ ン 課題 ソリュ ーショ ン 主要指 標 コスト構造 課題 独自の 価値提 案 圧倒的 な優位 性 顧客セ グメン ト 課題 圧倒的 な優位 性 顧客セ グメン ト 独自の 価値提 案 コスト構造 圧倒的 な優位 性 コスト構造 顧客セ グメン ト チャネ ル チャネ ル 収益の流れ 顧客セ グメン ト 圧倒的 な優位 性 顧客セ グメン ト チャネ ル 収益の流れ 一発一中にはならないので、 複数のプランを作り評価を繰り返す。 評価の結果いけそうなら作る。 やってみた結果、やっぱり”芽がない”なら 早く止めなければいけない 顧客セ グメン ト 収益の流れ 圧倒的 な優位 性 独自の 価値提 案 収益の流れ チャネ ル 独自の 価値提 案 ソリュ ーショ ン 主要指 標 収益の流れ ソリュ ーショ ン 課題 チャネ ル 主要指 標 収益の流れ 圧倒的 な優位 性 独自の 価値提 案 主要指 標 チャネ ル 独自の 価値提 案 ソリュ ーショ ン コスト構造 収益の流れ 主要指 標 コスト構造 顧客セ グメン ト チャネ ル 主要指 標 コスト構造 圧倒的 な優位 性 課題 ソリュ ーショ ン 主要指 標 コスト構造 独自の 価値提 案 圧倒的 な優位 性 チャネ ル 収益の流れ 顧客セ グメン ト 課題 ソリュ ーショ ン 主要指 標 コスト構造 独自の 価値提 案 圧倒的 な優位 性 チャネ ル 収益の流れ 顧客セ グメン ト 課題 ソリュ ーショ ン 主要指 標 コスト構造 独自の 価値提 案 圧倒的 な優位 性 チャネ ル 収益の流れ 顧客セ グメン ト
29. うまくたくさん作ることが最重要なわけではない ✤ Outcome (成果)の方が重要 ✤ 成果と生産性を比べてみると (生産性 = 生産量 / 投下時間 つまりベロシティ) ✤ ✤ 成果はでないが生産性は高い = ゴミの高速生産 ✤ 成果はでてるが生産性は低い = なにか問題でも？ ✤ 成果はでてないし生産性も低い = つらい人生… もっとスクラムチーム全体が成果にフォーカスする必要性
31. ところで、アジャイルでの成功率はどうなってる？ 11th Annual State of Agile Reportより 98% 顧客やユーザの満足 時間どおりのデリバリ なんと、98%の回答者が組織でのア ジャイルは成功していて、74%は半分 以上のプロジェクトがうまく行っている と回答している （本当？という数字。もちろん回答者バ イアスはある…） ビジネス価値 品質 生産性 予測性 透明性 プロセス改善 スコープ達成 11% 分からない 0% 15% 31% 29% 26% 25% 20% 30% 57% 55% 53% 47% 45% 60%
32. 【重要】 スクラムでの成果を決める要素 問題設定力 開発力 チーム力 ✤ 適切な問題設定 ✤ ドメイン知識 ✤ 開発プロセス習熟 ✤ 明確なビジョン ✤ アーキテクチャ設計力 ✤ 心理的安全性 ✤ マーケットの理解 ✤ 開発言語 ✤ 透明性 ✤ 取捨選択 ✤ 性能 ✤ 検査と適応 ✤ 良いプロダクトバックログ ✤ セキュリティ ✤ ムダをなくす ✤ 優先順位付け ✤ インフラストラクチャー ✤ 学習 ✤ ステークホルダー管理 ✤ 自動化 ✤ リーダーシップ ✤ リスク・コスト管理 ✤ 品質・テスト ✤ オーナーシップ ✤ … ✤ … ✤ …
33. 個々の領域への着目度合いのバランス 問題設定力 開発力 スクラムチームとしては楽しくは感じるかもしれない。 だが、ステークホルダーから見るとどう見える？ => 部分最適 チーム力 100%
34. 個々の領域への着目度合いのバランス 問題設定力 開発力 チーム力 50% 50% そこそこ良いチームがそこそこいい感じに進められるが、成果はどう？ => 部分最適
35. 個々の領域への着目度合いのバランス 問題設定力 開発力 チーム力 いまどこに着目すべきかの強弱をつけながら、全ての領域を考えていく
36. DISCOVERY LOOP OPTIONS PIVOT DELIVERY LOOP ディスカバリーループ オプションピボット デリバリーループ MOBIUS LOOP
37. スクラムでの改善イベント ✤ ✤ 問題設定に対する改善 ✤ スプリントレビュー ✤ プロダクトバックログリファインメント 開発力やチーム力に対する改善 ✤ ✤ スプリントレトロスペクティブ もちろんイベントを待たずに随時改善をしていって構わない ✤ というかそうすべき
38. よくある問題 ✤ 残念ながら、うまくたくさん作ることにフォーカスするスクラムチームが多い ✤ プロダクトオーナー1人に対して、開発チームの人数が多いので、そうなりがち ✤ あなた考える人、私たち作る人という構造 ✤ プロダクトオーナーが用意したReadyなプロダクトバックログアイテムを形に 変えるだけのマシーン ✤ これは本当に良いのか？ ✤ いちばん改善しないといけないポイントは、成果に着目する考え方の醸成
39. 成果に着目した改善 ✤ なにを改善する必要があるのか？ ✤ なぜその改善は必要なのか？ ✤ 具体的に何をするのか？ ✤ 改善の結果をどう測るのか？ ✤ その改善はどう成果に結びつくのか？ ✤ なぜ今なのか？ これってプロダクトバックログ と同じじゃない？ 目先の小さな改善ばっ かり追いかけると部分最適にし かならない
40. 健全性チェック ✤ 以下のような会話がスクラムチーム内で出てれば健全 ✤ このプロダクト売れるの？価値あるの？ ✤ このプロダクトバックログアイテムを実現する意味は何？ ✤ この機能誰が使うの？ ✤ こんなにたくさんの機能いるの？ この機能廃止した方がいいんじゃない？ ✤ それ作るとあとで辛いから止めたほうがいいんじゃない？ ✤ これ成果をどうやって測るの？ ✤ プロダクトオーナーはステークホルダーに「No」って言ってきて！
41. 次のポイント ✤ 忘れちゃいけない話がまだあります
42. 開発力の観点 ✤ よいアイデアがあっても、実現できないと話にならない ✤ アイデアがなくて、開発力があるとプロダクトアウトのできあがり ✤ 開発に時間がかかってしまうと、競争に負けるかもしれない ✤ 開発力がなければ、アイデアの実現にお金もたくさんかかってしまうかもしれない ✤ 品質が低ければ、持続的にプロダクトを成長させられないかもしれない ✤ 当然の帰結として、開発力は重要 ✤ 一部を除けば開発力に課題のあるチームは多い ✤ チームの関係性以前にこっちが課題なのでは？
43. スプリントでの成果を安定させるには？ ✤ スプリントは4週間までの固定の長さ。最近は1週間にすることが多い ✤ スプリントの中で設計・開発・テストを終わらせる必要 ✤ 過去に作ったものを壊していないことも担保しなければいけない ✤ テストのやり方に工夫が必要 ✤ 全てのプロダクトで初期からテスト自動化が必須なわけではない ✤ だが、プロダクトの芽があることが分かって投資を続けるのであれば、そのタイミン グでは自動化または仕掛け化されていないと苦しくなっていく ✤ テストしやすいコードやアーキテクチャ、探索的テストの能力なども必要 ✤ 多種多様な技術スタックを乗りこなす必要
44. 例： Twelve Factor App ✤ コードベース => バージョン管理されている1つのコードベースと複数のデプロイ ✤ 依存関係 => 依存関係を明示的に宣言し分離する ✤ 設定 => 設定を環境変数に格納する ✤ バックエンドサービス => バックエンドサービスをアタッチされたリソースとして扱う ✤ ビルド、リリース、実行 => ビルド、リリース、実行の3つのステージを厳密に分離する ✤ プロセス => アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する ✤ ポートバインディング => ポートバインディングを通してサービスを公開する ✤ 並行性 => プロセスモデルによってスケールアウトする ✤ 廃棄容易性 => 高速な起動とグレースフルシャットダウンで堅牢性を最大化する ✤ 開発/本番一致 => 開発、ステージング、本番環境をできるだけ一致させた状態を保つ ✤ ログ => ログをイベントストリームとして扱う ✤ 管理プロセス => 管理タスクを1回限りのプロセスとして実行する https://12factor.net/ja/
46. 機能実装の実現に精一杯でいいのか？ ✤ 開発力がないと、プロダクトバックログ項目の実現だけで精一杯になってしまう ✤ いつも余力のない状態で走り続けるのは困難（ずっと楽にならない） ✤ 改善は余裕のないところには生まれない ✤ やるべきことは、作る量を減らしてでも、開発チームとして安定したパフォーマンス を出せるような投資をすること（学習への投資） ✤ ✤ ペアプロ、モブプロ、技術メンターなど ✤ トレーニングや個人学習の時間 練習しないとうまくならない
47. 技術的負債の兆候 ✤ テストの所要時間の増加 ✤ バグの増加 ✤ リリースの延期 ✤ コードの重複 ✤ カバレッジの低下 ✤ 可読性の低いコード ✤ 技術選択の誤り ✤ ハック こういう兆候に対処していく。 借金するなら計画的に 機能開発に常に目一杯の時間 使ったらどうなる？
48. 改善促進効果の高いケイパビリティ24個 継続的デリバリ アーキテクチャ リーン指向の管理と監視 組織文化 バージョン管理 疎結合アーキテクチャ 変更承認プロセス 創造的な組織文化 デプロイの自動化 チームへの権限付与 監視 学びの支援 継続的インテグレーション 製品とプロセス プロアクティブ通知 チーム間の協働 トランクベース開発 顧客フィードバック WIP制限 職務満足度 テスト自動化 業務プロセス可視化 作業の可視化 改善を推進するLS テストデータ管理 作業の細分化 情報セキュリティシフトレフト チームによる実験 継続的デリバリー LeanとDevOpsの科学より
49. スキル領域の制約によるボトルネックの発生 フロントエンド設計 フロントエンド開発 スプリント内 ミニウォーターフォール の危険 バックエンド設計 バックエンド開発 結合・テスト IOS設計 IOS開発 フロントエンドしかできない（しない）、サーバーサイドしかできない、iOSしかできない、 テストしかできない人で開発チームを組むとどうなるか？
50. クロスファンクショナルでないと待ちが増える ✤ 開発チーム全体として、プロダクトを完成できる能力を持つ必要があるのは前提 ✤ その中でもボトルネック、依存関係を減らさないと待ちが増える ✤ 開発チーム内で分業が進むと、見積りに対して関心が持てなくなる ✤ T字型のスキルセット、TT字型のスキルセットに変えていく
51. 今日お伝えしたかったこと ✤ プロダクトを作るのは儲けるため（であることがほとんど） ✤ 「うまく作る・たくさん作る」ことよりも「成果を出す」ことにフォーカスすべき ✤ 成果を形にするには、開発力が必要 ✤ 開発力をあげようと思ったら、継続的な投資と学習が必要 ✤ 社会学的な話も重要だが、現状では言い訳としても使われていることも多い。 安易に逃げ込まないで、本当の問題を直すべき ✤ 以上を踏まえてバランスをとって改善していく
