1. スクラムの落とし穴 ∼アジャイルコーチが遭遇する よくある問題とその解決方法 ∼ Regional Scrum Gathering Tokyo 2017 Attractor, Inc. Agile Coach / CTO Ryutaro YOSHIBA
2. 吉羽龍太郎 ✤ ✤ アジャイル開発/DevOps/クラウドに関する コンサルティングとトレーニングの専門家 http://www.ryuzee.com @ryuzee
4. 2016年12月 株式会社アトラクタを設立しました アジャイルコーチング・トレーニングのご依頼お待ちしています
5. Disclaimer ✤ 本セッションの内容は過去の経験を整理したものであり、 実在のプロダクト、プロジェクト、会社とどれだけ似ていたと しても関係ありません
7. ! 症状 ✤ スプリント計画会議で選択したPBIの一部または全部がいつも終わらない ✤ スプリントでの成果の量にバラつきが大きい ✤ スプリント後半にいつも慌てる
8. " 原因候補：無理な計画 ✤ 強制されたスコープとデッドライン ✤ 成果がチーム外の誰かによってコミットされている ✤ 実績に基づかない楽観的な見積り ✤ 改善効果の過信
9. 鉄の三角形 ✤ ✤ ✤ スコープ・費用・納期は同時に3つ 固定することはできない 固定できるのは2つまで。アジャイ ル開発では通常費用と納期を固定 する スコープと納期を固定し、費用を可 変にするということは人を増やす ことを意味するが、チームはリニア にはスケールしない
11. " ✤ ✤ ✤ ✤ 原因候補：ReadyでないPBIの投入 準備ができていない(=Readyでない)プロダクトバックログ項目をスプリ ントに入れてしまうと、スプリント中に何度もプロダクトオーナーと仕様 を確認することになってしまう 着手したあとに、想像以上に規模が大きいことが分かってしまうと完了し なくなってしまう プロダクトオーナーに受け入れ確認をしたときに、受け入れられない確率 が高くなってしまい、スプリントの成果の量が安定しなくなる 大きすぎるプロダクトバックログ項目もReadyではない
12. # リファインメントに時間を使う ✤ ✤ ReadyなPBIを投入する には前スプリントで手入 れをしておく必要 スプリント期間の10%程 度は投資する(もちろんこ の時間はキャパシティか ら除外する)
13. # Readyの定義(例) ✤ プロダクトバックログ項目が用意されている ✤ プロダクトバックログ項目の価値が明確である ✤ 開発を進める上での大きな疑問や決定すべき事項がない ✤ 開発チーム全員が何をつくればいいか理解できている ✤ 受け入れ基準が明確である ✤ 他の項目との依存関係が明確である ✤ 見積りができている ✤ 必要ならパフォーマンスなどの非機能要件が明確になっている ✤ デモの手順が明らかになっている
14. " 原因候補：キャパシティ管理をしていない ✤ PBIのサイズが同じだからといって所要時間が同じとは限らない ✤ 推定所要時間はスプリントバックログ項目の合計時間＋バッファ ✤ 運用作業も開発チームで実施していると運用作業や障害対応にも時間をと られる ✤ 会社行事や急な割り込みなども発生する ✤ すなわち計画の精度をあげるためにはキャパシティの管理が必要
15. 1週間40時間すべてをプロジェクトに使える？ ✤ ✤ ✤ ✤ 計画のとき多くの組織は1日を8時 間として計算している。つまり4 時間のタスクが2つ終わることを 想定している 項目 時間 社内全体会議 2 事務手続き・報告・メール 4 でも実際には終わらない 研修 (平均) 2 右の例だと実際に開発に使えるの は65% (平均で50∼70%) 休暇 (平均) 2 スクラムイベント 4 開発作業 26 測定しよう
16. # キャパシティを 決定 スプリントバックログ決定の流れ 対象PBI候補を 決定 スプリントバッ クログを作成 キャパシティ内 かどうか確認 計画終了
17. " 原因候補：役割分担 ✤ 開発チーム内でスキルごとに役割分担している ✤ 1つのPBIを完成させるために色々な人に順番に受渡ししないといけない ✤ ✤ (例) 設計者 => 開発者 => テスター テスターはスプリント前半は暇で後半にまとめて作業が発生するよう なことが起こってしまう ✤ 専門性は発揮しやすいがボトルネックや手待ちのムダが発生しやすい ✤ PBIの完成よりもタスクの完遂にフォーカスしてしまっている場合も
18. 役割分担の影響 役割分担型 10 9 8 7 6 5 4 3 2 1 0 Day1 ✤ Day2 Day3 クロスファンクション型 Day4 Day5 10 9 8 7 6 5 4 3 2 1 0 Day1 Day2 Day3 Day4 Day5 コンポーネントや役割単位で分割すればするほどウォーターフォール型のように なり、なにも完了しないスプリントや追い込み型のスプリントになる
21. ! 症状 ✤ 誰がプロダクトオーナーなのかよくわからない ✤ プロダクトオーナーがなかなかつかまらない ✤ プロダクトオーナーがイベント開催時間の変更をよく要求する ✤ 開発チームやスクラムマスターがプロダクトバックログをメンテナンスしている ✤ プロダクトオーナーがソリューションを指示している ✤ プロダクトオーナーに質問しても答えがなかなか返ってこない ✤ スプリントレビューでステークホルダーからちゃぶ台返しのような発言が頻繁 に出る
22. " 原因候補：片手間のプロダクトオーナー ✤ マネージャーや管理職がプロダクトオーナーを兼任している ✤ プロダクトオーナーが開発者を兼任している ✤ プロダクトオーナーが複数のプロダクトを兼任している ✤ プロダクトオーナーがほかの業務で忙しい
23. # ロールの兼任は難しい ✤ まず、プライマリのロールの責任を果たすことに全力を尽くせ ✤ それを満たした上であれば ✤ ✤ 開発者とスクラムマスターの兼任は可能 ✤ 開発者とプロダクトオーナーの兼任は可能 一方で ✤ ✤ スクラムマスターとプロダクトオーナーの兼任は機能しない 立場が偉い人がプロダクトオーナーになると何がおこるか？
24. " 原因候補：プロダクトオーナーの理解不足 ✤ ✤ ✤ プロダクトオーナーの役割は単にプロダクトバックログの優先順位をつけ るだけではない ステークホルダーマネジメントはプロダクトオーナーの重要な役割 プロダクトオーナーはソリューションを指示するのではなく、解決したい 顧客の課題を提示する
25. プロダクトオーナーの責任 ✤ ビジネス価値を最大化する責任 ✤ プロダクトのビジョンを周りに示し理解させる責任 ✤ プロダクトの結果責任 ✤ プロダクトバックログの管理と優先順位決定の責任 ✤ ステークホルダーをコントロールする責任 ✤ 予算の管理責任 ✤ リリース日を決める責任 ✤ 開発チームをうまく使う責任 ✤ 開発チームの成果物の受け入れ可否を決める責任
28. ! 症状 ✤ 雰囲気が暗い ✤ 発言が特定の人に偏る ✤ 愚痴が多い ✤ 次のふりかえりでもプロセスが変わっていない ✤ 手を打ったはずの問題が再現する
29. " ✤ ✤ ✤ ✤ 原因候補：場の安全性欠如 まずはその場を「安全」にすることが最優先 役職や立場の上下関係などで、本当に思っていることが言えなければ、本 当の「問題」にたどり着かない 安全性こそが透明性を生む したがって必要に応じて参加者の選別やファシリテーターによる宣言が必 要にもなる (POやマネージャーの除外など)
30. # 場の設定 ✤ これから行う作業に集中できるようにする ✤ 参加者に感謝を述べる ✤ まず全員に口を開いてもらう(抱負など)。全員参加が不可欠 ✤ 会議の冒頭に口を開くと主体的参加度があがる傾向 ✤ 進め方を説明する(タイムボックス、目標も含む) ✤ チームの約束を確認する ✤ この時間を端折ったりしない方がよいことが多い
31. " 原因候補：不明確なアクションアイテム ✤ どんなアクションをいつまでにやるのか決めていない ✤ アクションが実行されたか・定着したかをどう追跡するか決めていない ✤ 数が多すぎるアクションアイテム
32. # 問題解決のループを回す Problem (問題) Solution (解決策) 計測 Fact (事実) デプロイ 仮説 Opinion (意見) 設計
33. # カイゼンボード ✤ ✤ ✤ ※アジャイルコーチの道具箱 – 見える化の実例集(Jimmy Janlén 著) より引用 カイゼンの取り組みを見える 化する 誰が着手しているかアバター を使って明らかにする 通常のカンバンと同様にアク ションに優先順位をつける
34. " 原因候補：マンネリ… ✤ いつも同じやり方(KPTなど)をしている ✤ いつも同じ課題や不満がでる繰り返し ✤ 同じ観点ばかりで改善点を探すと見落とすことがある
36. # Token of Appreciation Timeline ※Fun Retrospectivesより いろいろなふりかえり方法 Happiness Radar Star Fish Story of Story WWW
38. ! 症状 ✤ リリースしてみたらバグの連絡がたくさんくる ✤ 本番環境での障害がよく起こる ✤ スプリントレビュー中に動かない機能がある ✤ 完了していないものや作りかけのものを成果として扱っている ✤ 技術や設計面でイケていないと分かっている箇所が放置されている
39. " 原因候補：完了の定義がない・守れない ✤ 完了の定義(Definition of Done)がない ✤ 完了の定義が不足している ✤ 完了の定義が曖昧で守っているかどうかが主観的 ✤ 完了の定義はあるがそれを守らない ✤ 完了の定義はあるがそれを犠牲にしてしまう
40. # 出荷判断を可能にする ✤ 何をもって出荷可能とするかは製品によって異なる ✤ 実際に出荷するかどうかはプロダクトオーナーに意思決定権限がある ✤ Time to Marketの観点からは早く出荷したほうが当然良い ✤ 出荷後の保守やサポートのことも考える ✤ ✤ 金融・医療・携帯向けアプリ・ウェブサイトの全てで要求される品質が同 じなわけではない 社内品質基準と顧客の求める品質基準は一致していないこともある
41. 完了の定義は誰が決めるか？ ✤ プロダクトオーナー＋開発チームで決める。 ✤ その場にスクラムマスターは参加する ✤ ✤ 品質はコストに大きな影響を及ぼすため、プロダクトオーナーによる判断 は必須 ただし品質をいたずらに下げると将来開発チームの負債になり速度が低下 したり要求に応えられなくなるので開発チームも意見を述べる
42. 完了の定義を決めるタイミング ✤ ✤ ✤ スプリント開始前(契約や見積りの前)に大枠が決まっているべきである 品質の基準がなければスプリントでどのようなタスクが必要になるかの計 画(スプリントバックログ)が立てられない 品質は固定パラメータであり、一度定めた基準を下げてはいけない
43. " 原因候補：技術面への投資不足 ✤ テストを自動化していない ✤ 継続的インテグレーションをしていない ✤ コードレビューをしていない ✤ リファクタリングをしていない ✤ デプロイを自動化していない
45. " ✤ ✤ ✤ 原因候補：スコープ達成の圧力 品質に多少妥協してでも選択したPBIを終わらせないといけない、という 力が働くと品質はどんどん下がる これらの多くはリリース後に問題として顕在化し、開発チームのキャパシ ティを奪っていく これが原因の場合、スクラムマスターが機能していない
46. スクラムマスター ✤ スクラムのプロセスがうまくまわるようにする ✤ 妨害の排除 ✤ 支援と奉仕（サーバントリーダーシップ） ✤ 教育、ファシリテート、コーチ、推進役
48. ! 症状 ✤ 時間通りに始まらない ✤ 時間通りに終わらない ✤ スキップされる日がある ✤ 困っていることを誰もいわない ✤ スクラムマスターに向かって喋っている ✤ みんな黙って聞いている ✤ 雰囲気が暗い
49. " 原因候補：時間軽視の文化 ✤ 時間になってから場所を移動するような環境 ✤ 組織全体がそのようなやり方に慣れてしまっている ✤ 終わらなければ時間を延ばせば良いという考え ✤ 整理整頓清掃清潔しつけ(5S)の不足 ✤ 言い換えれば規律がない
50. " 原因候補：安全ではない環境 ✤ 達成への強い圧力 ✤ 困っていることを伝えると自分の評価に影響してしまう ✤ 誤ったメトリクス ✤ スクラムマスターが管理者役となってしまっている（役職が上の人がスク ラムマスターをやると起こりがち）
51. " 原因候補：チームとしての機能不全 ✤ そもそもスクラムの基礎教育が不足 ✤ スクラムマスターがスクラムマスターとして機能していない ✤ 他人への無関心 ✤ 環境への諦め
52. 機能しないチーム ⑤結果への 無関心 ④説明責任の 回避 ③責任感の不足 ②衝突への恐怖 ①信頼の欠如
53. スクラムチームは進化する タックマンモデル 形成期 混乱期 統一期 機能期 解散期 人が集まるがまだ独立 意見を言うようになる 一緒に活動し、異なる よく機能するチームと 目的を果たし、チーム しておりコミュニケー が、一方で自分と違う 意見を受け入れる。目 なる。チームには一体 が解散する時期 ションが少ない 意見に抵抗を示すよう 的や期待値などが一致 感がある。自立性が高 になる する い
55. ! 症状 ✤ WFでは間に合わないのでスクラムでやろう、と言い出す ✤ 「アジャイルなので⃝⃝しない」と頻繁に言っている ✤ ✤ ✤ イベントや成果物の目的をスクラムチームのメンバーに聞くとみんなが違っ た回答をする、もしくは回答できない 新しいメンバーが頻繁に開発チームに追加されてなんとなく作業を始めて いる その他既出の症状全般
56. " 原因候補：トレーニングや準備不足 ✤ 学習していないことをいきなり本番でやることはできない ✤ 関係者全員が共通理解をもっていないと大きなムダが発生する ✤ ✤ ここでいう関係者とはスクラムチームだけに限らず、ステークホルダー、 マネージャーも含む 新メンバーが加わったときにどうしていますか？
57. # ✤ 全員でトレーニングを受ける ✤ ✤ ✤ 一部の人だけ受けるのではなくみんなで受ける 新しい人が作業を開始するのは仕事の進め方を理解したあとにする ✤ ✤ 学習の時間を取ろう 人を追加するなら学習コストを計算してはやめに スクラムマスターがコーチングやトレーニングできないのなら外部の力を 借りるのもよい 仕事時間の一定割合は学習に投資するようにキャパシティを管理
58. 2017年2月22日(水)スクラムトレーニング開催 詳しくは、http://bit.ly/sbc0222
