スクラムとデッドライン壊れゆくチームをつなぎとめるもの/Scrum and Deadlines

Transcript

1. スクラムとデッドライン 壊れゆくチームをつなぎとめるもの 株式会社カケハシ　IKUOODANAKA 2024.01.11
2. 小田中 育生(おだなか いくお) 2009年に株式会社ナビタイムジャパン入社。研究開発部門に配 属。プロダクトや開発プロセスのカイゼンを推し進め、アジャイ ルとの出会いから社内ではスクラムを積極的に導入し、VP of Engineeringを務める。 2023年10月、エンジニアリングマネージャーとして株式会社カケ ハシにジョイン。テクノロジーとドメインに関する深い知識や経 験をもって高速に仮設検証のサイクルを回すチームづくりとチー ムを起点にした事業価値最大化に確約・集中・公開・尊敬・勇気 している。 著書に『いちばんやさしいアジャイル開発の教本 人気講師が教え るDXを支える開発手法』（2020年、インプレス、共著）がある。 ブログ: dora_e_m｜note
3. © KAKEHASHI Inc. 本セッションのラーニングアウトカム 1. デッドラインとうまく付き合うことができるよ うになる 2. 高負荷な状況でも自分を見失わないスクラム チームになれる
4. デッドライン
5. © KAKEHASHI Inc. デッドライン 絶対に超えら れない期限
6. © KAKEHASHI Inc. 物事には適切な時期がある
7. © KAKEHASHI Inc. デッドラインが生まれるとき 1. 事業に関連する法律の改正があり、施行前にプ ロダクトを法改正対応したい 2. 繁忙期・閑散期が明確なサービスで繁忙期に向 けてビジネスを拡大する機能をリリースしたい 3. その他、ステークホルダー要望などにより定め られた日付にリリースしたい
8. © KAKEHASHI Inc. みなさんおなじみの荒ぶる四天王 Jonathan Rasmusson 著/西村直人・角谷信太郎 監訳/近藤修平・角掛拓未 訳 アジャイルサムライーー達人開発者への道　オーム社 5.4 何を諦めるのかをはっきりさせる より引用
9. © KAKEHASHI Inc. デッドラインは時間の制約 Jonathan Rasmusson 著/西村直人・角谷信太郎 監訳/近藤修平・角掛拓未 訳 アジャイルサムライーー達人開発者への道　オーム社 5.4 何を諦めるのかをはっきりさせる より引用
10. © KAKEHASHI Inc. デッドラインがもたらす効能 1. 優先順位を判断しやすい 2. チームに集中が生まれる 3. 適切な時期にリリースし価値を最大化できる
11. © KAKEHASHI Inc. デッドラインがもたらす課題 1. 期限を優先するあまり品質が犠牲になりうる 2. 期限が厳しいと変更への柔軟性を損なう 3. チームにストレスを与えてしまう
12. © KAKEHASHI Inc. 課題を起こすデッドラインの例 1. とにかく短い期限 2. 非機能要件・運用を考慮せず線が引かれている
13. © KAKEHASHI Inc. Jonathan Rasmusson 著/西村直人・角谷信太郎 監訳/近藤修平・角掛拓未 訳 アジャイルサムライーー達人開発者への道　オーム社 5.4 何を諦めるのかをはっきりさせる より引用 時間だけを見てはいけない
14. 　　　　　　　スクラムチーム
15. © KAKEHASHI Inc. スクラム https://www.servantworks.co.jp/resources/scrum_overview_figures/
16. デッドラインとスクラムチーム
17. © KAKEHASHI Inc. デッドラインは価値貢献を生む 新生活シーズンに間に合ったから・・・ 新社会人の生活をよりよいものにできた！ 法改正に間に合ったから・・・ 安心してお客さんのサポートができる！
18. © KAKEHASHI Inc. スコープと締め切りとリソースと品質 いつも通りのやり方だとデッドラインには間に合わない。どうする？ プロダクト バックログ チームが1スプリントあたり 完成させられるのは2つ デッドライン 3スプリント目に デッドライン到達 11個
19. © KAKEHASHI Inc. 1. スコープを絞る 重要度の高い機能に絞り込みデッドラインにミートさせる プロダクト バックログ チームが1スプリントあたり 完成させられるのは2つ デッドライン 3スプリント目に デッドライン到達 116個
20. © KAKEHASHI Inc. 2. リソース増強 チームのスループットを強化しデッドラインにミートさせる プロダクト バックログ チームが1スプリントあたり 完成させられるのは24つ デッドライン 3スプリント目に デッドライン到達 11個
21. © KAKEHASHI Inc. 3. 品質を落とす そこそこの品質で妥協しデッドラインにミートさせる プロダクト バックログ チームが1スプリントあたり 完成させられるのは2つ デッドライン 3スプリント目に デッドライン到達 11個
22. © KAKEHASHI Inc. あなたならどうしますか？ 1. スコープを絞る 2. リソースを増強する 3. 品質を落とす
23. © KAKEHASHI Inc. スクラムで陥りがちな罠24個より “押し付け型の締切りとリソース： スクラムは現実をベースにしている。もし外部のステークホ ルダーがスコープと締切りを押し付け、チームのリソースが 十分ではなかったら、品質を犠牲にするだろう。これはスク ラムの原則に反している。現実として、誰も未来を見通すこ とはできないし、そのようなことは幻想に過ぎない” https://www.ryuzee.com/contents/blog/4509
24. © KAKEHASHI Inc. Jonathan Rasmusson 著/西村直人・角谷信太郎 監訳/近藤修平・角掛拓未 訳 アジャイルサムライーー達人開発者への道　オーム社 5.4 何を諦めるのかをはっきりさせる より引用 荒ぶる四天王 遵守！ 増やせない！ 減らせない！
25. © KAKEHASHI Inc. ヤツは四天王の中でも最弱 僕が犠牲になろう Jonathan Rasmusson 著/西村直人・角谷信太郎 監訳/近藤修平・角掛拓未 訳 アジャイルサムライーー達人開発者への道　オーム社 5.4 何を諦めるのかをはっきりさせる より引用
26. © KAKEHASHI Inc. 3. 品質を落とす　が選択されてしまう そこそこの品質で妥協しデッドラインにミートさせる プロダクト バックログ チームが1スプリントあたり 完成させられるのは2つ デッドライン 3スプリント目に デッドライン到達 11個
27. © KAKEHASHI Inc. そうなるとスクラムは機能不全を起こす https://www.servantworks.co.jp/resources/scrum_overview_figures/ 実際触ってみると 使い勝手良くない。 次スプリントで カイゼンしない？ 間に合わない から無理！！ リリース前に テスト書いて リファクタもしたいな 間に合わない から無理！！
28. © KAKEHASHI Inc. 守れと言われたスケジュールを守るため 検査と適応を行わず、透明性も持たず、 品質に妥協したプロダクトを開発する 我々はなぜここにいるのか
29. © KAKEHASHI Inc. 守れと言われたスケジュールを守るため 検査と適応を行わず、透明性も持たず、 品質に妥協したプロダクトを開発する そんな開発がやりたかったわけじゃない 我々はなぜここにいるのか
30. © KAKEHASHI Inc. 守るべきデッドラインは守る 透明性、検査、適応も守る 「両方」やらなくちゃあならないってのが 「スクラムチーム」のつらいところだな 我々はなぜここにいるのか
31. © KAKEHASHI Inc. スクラムチームとしてどう動くか
32. © KAKEHASHI Inc. デッドラインのWhyを明らかにする
33. © KAKEHASHI Inc. ステークホルダー、POに直接聞く
34. © KAKEHASHI Inc. こんな聞き方しちゃダメよ このデッドラインって 守る必要あります？ デッドラインを設定した人は守る必要 がある・守ることができるデッドライ ンだと思っているから設定している。 「あるよ」としか返ってこない。
35. © KAKEHASHI Inc. “タイミングが適切かどうかを体 系的に知るためには、「なぜ今 か」と自問してみましょう。〜中 略〜「なぜ今か？」「もう少し 待った場合、何か違いは生まれる だろうか？」「時機を見る場合、 具体的には何を待つのか？」” 意義を問う ガブリエル・ワインバーグ ローレン・マッキャン：著 / 小浜 杳：訳(2020) 超一流が実践する思考法を世界中から集めて一冊にまとめてみた。 SB Creative 第9章「市場支配力」を行使するための 思考法　より引用
36. © KAKEHASHI Inc. Gain/Painに焦点を当てて質問する このタイミングでリリースする ことで狙っている効果を教えて ください！ もし間に合わないと どんな機会損失がありますか？ 期待されている効果が明らかであれば チームのモチベーションにつなげられる
37. © KAKEHASHI Inc. こんなことを言いたくなるかもしれない デッドラインに間に合わせるた めにスコープ削りたいんですけ どいいですか？
38. © KAKEHASHI Inc. この聞き方だと消極的判断のように響く デッドラインに間に合わせるた めにスコープ削りたいんですけ どいいですか？
39. © KAKEHASHI Inc. デッドラインに間に合わせるた めにスコープ削りたいんですけ どいいですか？ こんなことを言われるかもしれない いや全部開発しないと意味ない でしょ。人なら追加するから全 部つくってまにあわせて。それ が君の仕事だよ？
40. © KAKEHASHI Inc. “ソフトウェア構築は、本来シス テム的な作業ー複雑な相互関係に おける作業の遂行ーであり、コ ミュニケーションを図るための労 力は大きく、分担によってもたら された各個人の作業短縮時間をす ぐに上回ってしまう。だから、要 員を追加することが、スケジュー ルを長引かすことはあっても、短 くすることはないのである。” なるほど完璧な作戦っスねーーーっ フレデリック・P・ブルックス,Jr.著 滝沢徹・牧野裕子・富澤昇 訳(2010) 人月の神話　新装版 丸善出版 第2章 人月の神話 より引用
41. © KAKEHASHI Inc. こんな言い方しちゃダメよ 人月の神話って知ってますかw 人増やしても早くならないッスよwww 大事なのは知識の披露ではなく ステークホルダーの約束を守る確度を 高めながらチームとしての健全性を 保つやり方で合意すること
42. © KAKEHASHI Inc. Whyにあわせてスコープ縮小を提案する その狙いであれば、たとえばこ の機能はリリース後、後日追加 で対応するのはどうでしょう Whyが明らかであればプロダクトバック ログの優先順位を更新し、リリースまで のスコープを絞ることができる
43. © KAKEHASHI Inc. 丁寧にステークホルダーマネジメントする
44. © KAKEHASHI Inc. チームでデッドラインと向き合う
45. © KAKEHASHI Inc. トレードオフスライダーどうする？ 時間 予算 品質 スコープ MAX MAX MAX MAX MIN MIN MIN MIN 普段チームが持つトレードオフスライダーとは異なるかもしれない デッドライン遵守が最重要なら時間がMAXになる
46. © KAKEHASHI Inc. トレードオフスライダーこうする 時間 予算 品質 スコープ MAX MAX MAX MAX MIN MIN MIN MIN 品質の妥協はプロダクトの将来価値を毀損する。予算(人員)調整は慎重にしたい。 まず調整することになるのがスコープ。そのことをステークホルダーとも合意する
47. © KAKEHASHI Inc. デッドライン前提で検査と適応を行う https://www.servantworks.co.jp/resources/scrum_overview_figures/ 実際触ってみると 使い勝手良くない。 次スプリントで カイゼンしない？ 積んであるPBIと どっちが顧客にとって 大事だろう? どっちかしかできない 悩ましいけど 積んであるやつは リリース後でいいから カイゼンをやろう
48. © KAKEHASHI Inc. 検査！適応！検査！適応！検査！適応！ 一通り試作 してみよう！ スコープを調整 しなきゃ モブで 一気にやろう いったん運用は 手動で！
49. © KAKEHASHI Inc. 最優先は時間、デッドライン 時間 予算 品質 スコープ MAX MAX MAX MAX MIN MIN MIN MIN デッドラインまでの時間軸では、顧客の体験価値に悪影響を及ぼさない程度の 品質への妥協が発生しうる
50. © KAKEHASHI Inc. 注意:未来の自分たちと約束しておく！ 一通り試作 してみよう！ スコープを調整 しなきゃ モブで一気にや ろう いったん運用は 手動で！ リリース後の借金返済計画を立てる
51. © KAKEHASHI Inc. 日頃のトレードオフスライダーに戻す 時間 予算 品質 スコープ MAX MAX MAX MAX MIN MIN MIN MIN デッドライン遵守のために品質に妥協したのであれば 品質の優先順位については日頃よりも高い位置につけ負債解消を急務とする
52. © KAKEHASHI Inc. 無事にデッドラインに間に合った！ デッドラインを　やっつけた！
53. © KAKEHASHI Inc. と思いきや デッドラインがあらわれた！
54. © KAKEHASHI Inc. あわわわわわわわわわわわ デッドラインがあらわれた！ デッドラインは　なかまをよんだ！ デッドラインBがあらわれた！ デッドラインCがあらわれた！ デッドラインDがあらわれた！
55. デッドラインとデッドラインと デッドラインとスクラムチーム
56. © KAKEHASHI Inc. デッドラインの例（再掲） 1. 事業に関連する法律の改正があり、施行前にプ ロダクトを法改正対応したい 2. 繁忙期・閑散期が明確なサービスで繁忙期に向 けてビジネスを拡大する機能をリリースしたい 3. その他、ステークホルダー要望などにより定め られた日付にリリースしたい
57. © KAKEHASHI Inc. 要望は複数ステークホルダーからくる チーム ステーク ホルダーA ステーク ホルダーB ステーク ホルダーC ステーク ホルダーD 法改正にせよ季節要因にせよ、それぞれのステークホルダーにとっては重要な期限 タイミングによってはそれが同時にやってくる
58. © KAKEHASHI Inc. 同時に複数のデッドラインが設定された 自分たちのケイパビリティでは全てのデッドラインを守ることは難しい どうする？スクラムチーム。 プロダクト バックログ A B C D デッドライン チームが1スプリントあたり 完成させられるのは2つ どうしても この日までに 必要なの！
59. © KAKEHASHI Inc. さあ優先順位を決めよう どれが一番 大事ですか
60. © KAKEHASHI Inc. うちが一番大事 どれが一番 大事ですか うち！ うち！ うち！ うち！
61. © KAKEHASHI Inc. そこをなんとか・・・ 全部は ちょっと… 書き入れ時 なんだよ！ うちを大事 にして？ ファイト！ 君なら 出来る！
62. © KAKEHASHI Inc. 公平にやろうとする どれもデッドラインに間に合わない プロダクト バックログ A B C D デッドライン チームが1スプリントあたり 完成させられるのは2つ どうしても この日までに 必要なの！
63. © KAKEHASHI Inc. ひとつずつやっていく？ AとBは完成させられる。CとDは間に合わない プロダクト バックログ A B C D デッドライン チームが1スプリントあたり 完成させられるのは2つ どうしても この日までに 必要なの！
64. © KAKEHASHI Inc. こうなる これでどう？ いいよ！ いいよ！ ダメです ダメです
65. © KAKEHASHI Inc. そしてこうなる だからさぁ、全部間に合わせてよ
66. © KAKEHASHI Inc. ええい分業だ チーム ステーク ホルダーA ステーク ホルダーB ステーク ホルダーC ステーク ホルダーD こうなったら仕方がない。普段はペアやモブでやってるけど分業しよう。 コードレビュー？動いてるならあとでいいよ。 分担すればなんとかなるはず！ やってみますよ！
67. © KAKEHASHI Inc. かんぺきなけいかく すべての時間を開発にあてる！一人ひとつ！最高速度を叩き出せ！ プロダクト バックログ A B C D デッドライン 無理（残業、品質を犠牲に） すれば間に合うはず！ どうしても この日までに 必要なの！
68. © KAKEHASHI Inc. チームに何が起こる? https://www.servantworks.co.jp/resources/scrum_overview_figures/
69. © KAKEHASHI Inc. プランニング それぞれ独立したアイテムに着目しているので対話が発生しない A B C D
70. © KAKEHASHI Inc. デイリースタンダップ 一応、それぞれがやってることを共有する。 別のことをやっているので互いが順調なのか遅れているのか困っているのか 全然わからない ToDo Doing Done
71. © KAKEHASHI Inc. レビュー 間に合いそうかどうかしか見ない 進んでそうだから ヨシ！！！！
72. © KAKEHASHI Inc. ふりかえり スプリント内の活動をふりかえるのだが、それぞれ別の開発を行っているので 共通の学びが得られづらい。「お互い大変だね」とねぎらう場になる。 （それはそれで大事） タイムライン
73. © KAKEHASHI Inc. スクラムイベントは機能不全を起こす https://www.servantworks.co.jp/resources/scrum_overview_figures/
74. © KAKEHASHI Inc. 集まる意味がないならやめよう、となる 朝会もふりかえりも効果がないからやめよう、開発に集中しよう、となる それでなくても別々に開発をしてコミュニケーション量が減っていたが この決定でついにコミュニケーション量はゼロに限りなく近づく
75. © KAKEHASHI Inc. 無事にデッドラインに間に合った！ デッドラインAを　やっつけた！ デッドラインBを　やっつけた！ デッドラインCを　やっつけた！ デッドラインDを　やっつけた！
76. © KAKEHASHI Inc. チームはバラバラになってしまった なんとかデッドラインには間に合っても、バラバラに仕事を進めてしまったチーム をもとに戻すことは簡単ではない
77. © KAKEHASHI Inc. そもそもデッドラインに間に合うか怪しい 得意分野をかけあわせていたチームをバラバラにするのは強みを奪う行為。 人月計算では間に合うように見えても本当に間に合うかは怪しい。 フロントエンド まかせて！ CI/CDまわりは 得意！ モバイルは 僕にきいて！ バックエンドと インフラはプロ
78. © KAKEHASHI Inc. WORK IS DEAD, TEAM IS DEAD デッドラインたいおう　は　しんでしまった！ チーム　は　しんでしまった！
79. 確　集　公　尊　勇 約　中　開　敬　気
80. 確　集　公　尊　勇 約　中　開　敬　気
81. 確　集　公　尊　勇 約　中　開　敬　気
82. © KAKEHASHI Inc. 僕たちはスクラムチームだ 自分たちが一番パフォーマンスを出せるやり方は、自分たちが一番知っている。 ケイパビリティ以上のアウトプットは出せないし、無理に出すとチームは壊れる。 勇気をもってチームのやり方を貫き、デッドラインに集中し、やり遂げたい。
83. © KAKEHASHI Inc. あらためてステークホルダーと向き合う ちょっと いいですか？
84. © KAKEHASHI Inc. 質問の仕方は単一デッドラインと同じ このタイミングでリリースする ことで狙っている効果を教えて ください！ もし間に合わないと どんな機会損失がありますか？ 期待されている効果が明らかであれば チームのモチベーションにつなげられる
85. © KAKEHASHI Inc. プロダクトバックログを更新する プロダクト バックログ ステークホルダーより得た情報から優先順位を更新し、 自分たちのケイパビリティをもとにコミットメントする コミットメント
86. © KAKEHASHI Inc. プロダクトバックログを公開する 何をデッドラインまでに完成させ、何を諦めるか明確にする そのステークホルダーが関わらないタスクも含め公開する プロダクト バックログ コミットメント
87. © KAKEHASHI Inc. まるまる落とすものにはケアを コミットメント対象から外す≠大事じゃないと思っている ということをちゃんとわかってもらう ステークホルダーとの関係は良好に保とう プロダクト バックログ コミットメント 今回はステークホルダーCの 要望をまるっと落とす
88. © KAKEHASHI Inc. このやり方が最善だとわかってもらう ひとつひとつ集中してやるやり方がチームの最善だとわかってもらう 過去の実績などを示して理解してもらう プロダクト バックログ コミットメント
89. © KAKEHASHI Inc. とはいえ 間に合わなそうで怖いよ。 他のチームは個別でやってるよ？
90. © KAKEHASHI Inc. スプリント1でやれるところを見せる プロダクト バックログ 理想はこうなるまえに、普段からチームのやり方をみておいてもらうこと
91. © KAKEHASHI Inc. ちなみに デッドライン多発時期が定期的で予測できるなら、 前もってチームを強化しておくという手段も有効 プロダクト バックログ チームが1スプリントあたり 完成させられるのは24つ デッドライン 3スプリント目に デッドライン到達 11個
92. © KAKEHASHI Inc. ここまできたらやることは一緒 https://www.servantworks.co.jp/resources/scrum_overview_figures/ 実際触ってみると 使い勝手良くない。 次スプリントで カイゼンしない？ 積んであるPBIと どっちが顧客にとって 大事だろう? どっちかしかできない 悩ましいけど 積んであるやつは リリース後でいいから カイゼンをやろう
93. © KAKEHASHI Inc. 無事にデッドラインに間に合った！ デッドラインAを　やっつけた！ デッドラインBを　やっつけた！ デッドラインDを　やっつけた！
94. ケーススタディ1 ナビゲーションアプリ
95. © KAKEHASHI Inc. 人流の復活による機会増大 コロナ禍を経て人流が復活、サービスへのニーズも急増。 季節にあわせた機能開発、法改正対応が同じタイミングで発生 法改正 季節要因
96. © KAKEHASHI Inc. チームが持つ失敗の記憶 繁忙期に分業体制を採った結果、レビューコストの増大などで思ったほど スピードが出なかった。そして属人化が発生してしまった。
97. © KAKEHASHI Inc. ステークホルダーひとりひとりと話した このタイミングでリリースする ことで狙っている効果を教えて ください！ もし間に合わないと どんな機会損失がありますか？
98. © KAKEHASHI Inc. 経営レベルの判断もあおいだ
99. © KAKEHASHI Inc. 実は認識に齟齬があったことに気づいた 余裕があるなら この時期にやりたい マスト！
100. © KAKEHASHI Inc. 落ち着いてひとつひとつ まさにこの資料で紹介したように、いつものやり方で粛々と完成させていった デッドラインを守るために手の運用が残る部分があったなど課題はあったが チームを壊さず、ステークホルダーを適切に期待マネジメントし、やりきった プロダクト バックログ コミットメント
101. ケーススタディ2 ヘルステック
102. © KAKEHASHI Inc. 新規事業プロダクト開発チーム 10月からカケハシにジョイン。 新規事業プロダクト開発チームでEMを担う。 Product Manager Engineer Engineering Manager 私のロール
103. © KAKEHASHI Inc. 他チームからヘルプの要請 突発的にデッドラインが発生したが自分たちでの対応が 難しいと判断したチームから、エンジニアヘルプの要請がきた Product Manager Engineer Engineering Manager 私のロール HELP!
104. © KAKEHASHI Inc. 当初のヘルプ想定 そのチームに在籍していた経験のあるエンジニア1名に ヘルプにいってもらう Product Manager Engineer Engineering Manager 私のロール HELP!
105. © KAKEHASHI Inc. あるメンバーが言った Cばさん(仮名) 会社としての全体最適を考え、 そうするべきだということだと 思うので、ヘルプは賛成です。 でも、一人で行くのではなく チームでヘルプに行きたい。
106. © KAKEHASHI Inc. ほかのメンバーも言った 会社としての全体最適を考え、 そうするべきだということだと 思うので、ヘルプは賛成です。 でも、一人で行くのではなく チームでヘルプに行きたい。 一人でいくと 属人化しますからね。 賛成です。 僕たちの知識・スキル獲得 にもつながる。いいですね！
107. © KAKEHASHI Inc. 僕は悩んでいた プロダクト バックログ A B C D チームが1スプリントあたり 完成させられるのは2つ プロダクト バックログ チームでヘルプするということはプロダクトバックログの最上 位に他チームのPBIを積むということ
108. © KAKEHASHI Inc. チームがもつプロダクトの開発が止まる プロダクト バックログ A B C D デッドライン チームが1スプリントあたり 完成させられるのは2つ 4スプリント、1ヶ月は止まる。PMF前のプロダクトでそんなに 止めていいのか？
109. © KAKEHASHI Inc. じゃあヘルプ1人ならスピードは出るか? 何もやらないよりは出る。でも復帰後のキャッチアップには時間がかかる。 そしてヘルプ担当の負担が大きくなる プロダクト バックログ A B C D デッドライン
110. © KAKEHASHI Inc. チームが分断してしまう チームは2023年4月に立ち上がったばかりで、絶賛成長中 せっかく醸成されつつあるチームワークがなくなってしまうリスクがある
111. © KAKEHASHI Inc. とはいえPdMは許容できるの？ 頭の中のPdM ヘルプ先
112. © KAKEHASHI Inc. とはいえPdMは許容できるの？ 頭の中のPdM ヘルプ先 なんとか両立してよ （って言われると想像してる自分）
113. © KAKEHASHI Inc. 直接、PdMと話した 開発は止まってしまいますが チームでヘルプに行くのが 最善だと考えています
114. © KAKEHASHI Inc. なんと一発で理解が得られた それがチームの最速って ことですよね。いいですよ。 開発は止まってしまいますが チームでヘルプに行くのが 最善だと考えています
115. © KAKEHASHI Inc. そうか、先人たちのおかげか RSGT2024 Badプラクティスを選んで失敗しながら進めた新規プロダクト開発(湯前、椎葉)より
116. © KAKEHASHI Inc. 蓋をあけてみると、1人のヘルプではとても終わらないボリュームだった そういう意味でもチームで入ってよかった！ 4スプリント、チームでヘルプを実施 デッドライン 始める前の 見立て デッドライン 実際の動き まず見通し をつけた 一通り 動くものが できた FBを受けて 改修しつつ QA通した リリース！
117. © KAKEHASHI Inc. PdMと話した 実際、4スプリントも止めて 不安はなかったですか?
118. © KAKEHASHI Inc. 神だった 実際、4スプリントも止めて 不安はなかったですか? むしろ早く帰ってきたくらい に思ってます！止まってる間 にいろいろインサイトできた し、結果的によかったかな。
119. © KAKEHASHI Inc. あのとき、もし断っていたら 会社として守るべきデッドラインが守れず、会社のビジネスに 影響を与えていた。 Product Manager Engineer Engineering Manager 私のロール HELP!
120. © KAKEHASHI Inc. あのとき、一人でヘルプにいっていたら デッドラインは守れたのだろうか？守れたとして、 チームのナレッジの分断は避けられなかっただろう Product Manager Engineer Engineering Manager 私のロール HELP!
121. © KAKEHASHI Inc. あるメンバーに、PdMに、みんなに感謝。 Cばさん(仮名) PdM
122. © KAKEHASHI Inc. チームがチームでありつづけられた チームワークを損なうどころか、ヘルプ業務を通して相互理解・相互作用が進んだ いつか自分たちのプロダクトにデッドラインが引かれたとき、この経験は力になる。
123. © KAKEHASHI Inc. ふたつのケーススタディからの学び • 守るべきデッドラインは存在する • けれどケイパビリティを超えて開発することはできない • そういうときに個別対応への誘惑がある • でも、チームがいつものやり方でやれば結果的にパフォー マンスが出る。だって一番慣れているやり方だから • だから、必要なら勇気をもってステークホルダーと調整し よう。時には何かを止めることを提案する必要がある
124. まとめ
125. © KAKEHASHI Inc. デッドラインは価値貢献を生む 新生活シーズンに間に合ったから・・・ 新社会人の生活をよりよいものにできた！ 法改正に間に合ったから・・・ 安心してお客さんのサポートができる！
126. © KAKEHASHI Inc. だが、時にスクラムを壊す https://www.servantworks.co.jp/resources/scrum_overview_figures/ 実際触ってみると 使い勝手良くない。 次スプリントで カイゼンしない？ 間に合わない から無理！！ リリース前に テスト書いて リファクタもしたいな 間に合わない から無理！！
127. © KAKEHASHI Inc. 時にチームを壊す
128. © KAKEHASHI Inc. 僕たちはスクラムチームだ 自分たちのいつものやり方が、いちばんパフォーマンスを出せる。 勇気をもってそれをやり抜こう。
129. © KAKEHASHI Inc. ステークホルダーと向き合おう
130. © KAKEHASHI Inc. やれるところを見せて信頼してもらおう プロダクト バックログ
131. © KAKEHASHI Inc. 検査！適応！検査！適応！検査！適応！ 一通り試作 してみよう！ スコープを調整 しなきゃ モブで 一気にやろう いったん運用は 手動で！
132. © KAKEHASHI Inc. 守るべきデッドラインは守る 透明性、検査、適応も守る 「両方」やらなくちゃあならないってのが 「スクラムチーム」のつらいところだな
133. でも、やるんだよ。
134. THANKS!