アジャイル失敗のススメ

スクラムを導入したチームが
成果をなかなか出せなかったので
スクラムを廃止してみたらうまくいった話

Transcript

1. アジャイル失敗のススメ 井⽥ 献⼀朗 株式会社ナビタイムジャパン
2. ⾃⼰紹介 井⽥ 献⼀朗 https://github.com/rinatz Python, Rust 主な業務 時刻表、路線図表⽰などのサービス開発 マネージメント アジャイルの推進 技術系の教育 2
3. 話すこと スクラムを導⼊したチームが 成果をなかなか出せなかったので スクラムを廃⽌してみたらうまくいった話 3
4. 現在のチームの働き⽅ Slack: ほとんど会話しない プルリク: コメントが付かずにクローズ 課題管理: JIRA などを使⽤することはほとんどない これだけ⾒るとずさんなチームに思える 4
5. しかしプロダクトの機能追加は 継続的に⾏えている 5
6. なぜスクラムの廃⽌が かえっていい結果を⽣んだのか︖ 6
7. スクラムをやっていた頃 プロダクトオーナーとスクラムマスターを任命 バックログを作成 スプリントを実施 朝会を実施 振り返りを実施 スクラムでやるべきことはやっていた でも開発はだいぶ遅れ気味（休出する⼈もいた） 7
8. うまくいっていない原因 1. ステレオタイプなスクラムを忠実に守り続けることに徹している ルールやノウハウへの忠誠⼼が強すぎて⾏動指針をマニュアル化 結果、⾃分たちで改善策を考えようとしない 2. 成果責任と権限委譲ができていない ⽬的を達成するための戦略をメンバが検討できていない 疑問を持ちつつも『⽅針が決まっているから』という気持ちで開発 3. 動くソフトウェアを継続的に作るという意識が低い 反復型開発の本質を分かっていない 8
9. うまくいっていない原因 1. ステレオタイプなスクラムを忠実に守り続けることに徹している ルールやノウハウへの忠誠⼼が強すぎて⾏動指針をマニュアル化 結果、⾃分たちで改善策を考えようとしない 2. 成果責任と権限委譲ができていない ⽬的を達成するための戦略をメンバが検討できていない 疑問を持ちつつも『⽅針が決まっているから』という気持ちで開発 3. 動くソフトウェアを継続的に作るという意識が低い 反復型開発の本質を分かっていない 9
10. うまくいっていない原因 1. ステレオタイプなスクラムを忠実に守り続けることに徹している ルールやノウハウへの忠誠⼼が強すぎて⾏動指針をマニュアル化 結果、⾃分たちで改善策を考えようとしない 2. 成果責任と権限委譲ができていない ⽬的を達成するための戦略をメンバが検討できていない 疑問を持ちつつも『⽅針が決まっているから』という気持ちで開発 3. 動くソフトウェアを継続的に作るという意識が低い 反復型開発の本質を分かっていない 10
11. 解決したいこと 1. ステレオタイプなスクラムを忠実に守り続けることに徹している スクラムへの偏⾒をなくす 2. 成果責任と権限委譲ができていない ⾃⼰組織化を促す 3. 動くソフトウェアを継続的に作るという意識が低い 理想の反復型開発を知る 11
12. 1. スクラムへの偏⾒をなくす 12
13. スクラムを廃⽌ 代わりに モブプログラミング を導⼊ モブプログラミングとはチームのメンバ全員を ミーティングスペースに集めて⼀緒に開発をする開発スタイルのこと 13
14. スクラムを廃⽌ 全員未経験なので、みんなが⼿探り状態 効果を試すため、思い切って1⽇5時間くらいは集まることにした 14
15. 効果 1⽇中 コーディング、レビュー、進捗共有、情報共有 を同時にやっているような感覚 15
16. 効果 1⽇が終わると相当な達成感と疲労感があった 雑談しながら開発できるので、疲れるがとても楽しい 16
17. 効果 問題解決のためには、プロセスやツールを検討するより 対話をしたほうが効果的だとメンバが感じるようになった 情報を伝えるもっとも効率的で効果的な⽅法は フェイス・トゥ・フェイスで話をすることです。 『アジャイル宣⾔の背後にある原則』より “ “ 『アジャイル宣⾔の背後にある原則』http://agilemanifesto.org/iso/ja/principles.html 17
18. 効果 その結果 Slack での会話はほぼなし プルリクでのレビューはほぼなし JIRA による課題管理はほぼなし やり⽅が分からないアプローチをあえて取ることで 偏⾒を持たず、⾃分たちで改善策を⾒出すのだという アジャイルの本質を理解してもらえた 18
19. 2. ⾃⼰組織化を促す 19
20. ⾃⼰組織化 ⾃⼰組織化 マネージャーはゴールだけを⽰し 戦略はメンバが⾃主的に検討できるように作られたチームのこと ⾃⼰組織化を促すためにやったこと クロスファンクショナルチームの形成 進捗報告の仕⽅を変える 20
21. ⾃⼰組織化 クロスファンクショナル（職能横断型）チーム 1つのタスクに1⼈を割り当てるようなことはしない 横断的にタスクをこなしてもらう その際、メンバが苦⼿なことをうまくマネージメントする 得意な作業は積極的に実施してもらう 苦⼿な作業はそれが得意な⼈を探す努⼒をしてもらう 21
22. ⾃⼰組織化 進捗報告の仕⽅を変える かつては⼝頭や⽂章・スライドなどで伝えてもらっていた しかしそれだと上⼿に ウソ がつけてしまう 22
23. ⾃⼰組織化 進捗報告は動くプログラムでデモをやってもらう 動くプログラムを⾒せることで ⾃分の作ったものを必要としてくれる⼈がいることを知れる デモに失敗したら、ちゃんと動かせるように気を使うようになる ⾃⼰組織化が促進される 23
24. 3. 理想の反復型開発を知る 24
25. 反復型開発がよく分かる画像と動画 画像 How to build a minimum viable product TED の動画 トム・ウージェック︓塔を建て、チームを作る チームのメンバ全員に⾒てもらった 25
26. How to build a minimum viable product 夢は⼤きく、⽬標は⼩さく 部品を作るのではなく、 同じコンセプト を持つものを作り続ける 画像引⽤: https://medium.com/@heyjudesue/what-does-it-take-to-design-a-minimum-viable-product-5175e554fa3a 26
27. 塔を建て、チームを作る マシュマロ・チャレンジ スパゲッティの麺で⾃⽴式の塔を建て 塔の⼀番⾼いところにマシュマロを置いたチームが勝ちというゲーム 組み⽴て⽅をじっくり議論するより 早く実践に移るチームの⽅が勝ちやすい という結果に トム・ウージェック︓塔を建て、チームを作る 動画引⽤: https://www.ted.com/talks/tom_wujec_build_a_tower 27
28. まとめ 1. チームの働き⽅は 継続的 に⾒直す必要がある 2. ソフトウェアは 継続的 に動くものを作る必要がある 3. アジャイルにおける 失敗は終わりではなく始まり アジャイルは 継続的な失敗駆動開発 である 28
29. Thank You! 29