アジャイル失敗のススメ

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

Transcript

1. アジャイル失敗のススメ
   井⽥ 献⼀朗
   株式会社ナビタイムジャパン
   

   View Slide

2. ⾃⼰紹介
   井⽥ 献⼀朗
   https://github.com/rinatz
   Python, Rust
   主な業務
   時刻表、路線図表⽰などのサービス開発
   マネージメント
   アジャイルの推進
   技術系の教育 2
   

   View Slide

3. 話すこと
   スクラムを導⼊したチームが
   成果をなかなか出せなかったので
   スクラムを廃⽌してみたらうまくいった話
   3
   

   View Slide

4. 現在のチームの働き⽅
   Slack: ほとんど会話しない
   プルリク: コメントが付かずにクローズ
   課題管理: JIRA などを使⽤することはほとんどない
   これだけ⾒るとずさんなチームに思える
   4
   

   View Slide

5. しかしプロダクトの機能追加は
   継続的に⾏えている
   5
   

   View Slide

6. なぜスクラムの廃⽌が
   かえっていい結果を⽣んだのか︖
   6
   

   View Slide

7. スクラムをやっていた頃
   プロダクトオーナーとスクラムマスターを任命
   バックログを作成
   スプリントを実施
   朝会を実施
   振り返りを実施
   スクラムでやるべきことはやっていた
   でも開発はだいぶ遅れ気味（休出する⼈もいた）
   7
   

   View Slide

8. うまくいっていない原因
   1. ステレオタイプなスクラムを忠実に守り続けることに徹している
   ルールやノウハウへの忠誠⼼が強すぎて⾏動指針をマニュアル化
   結果、⾃分たちで改善策を考えようとしない
   2. 成果責任と権限委譲ができていない
   ⽬的を達成するための戦略をメンバが検討できていない
   疑問を持ちつつも『⽅針が決まっているから』という気持ちで開発
   3. 動くソフトウェアを継続的に作るという意識が低い
   反復型開発の本質を分かっていない
   8
   

   View Slide

9. うまくいっていない原因
   1. ステレオタイプなスクラムを忠実に守り続けることに徹している
   ルールやノウハウへの忠誠⼼が強すぎて⾏動指針をマニュアル化
   結果、⾃分たちで改善策を考えようとしない
   2. 成果責任と権限委譲ができていない
   ⽬的を達成するための戦略をメンバが検討できていない
   疑問を持ちつつも『⽅針が決まっているから』という気持ちで開発
   3. 動くソフトウェアを継続的に作るという意識が低い
   反復型開発の本質を分かっていない
   9
   

   View Slide

10. うまくいっていない原因
    1. ステレオタイプなスクラムを忠実に守り続けることに徹している
    ルールやノウハウへの忠誠⼼が強すぎて⾏動指針をマニュアル化
    結果、⾃分たちで改善策を考えようとしない
    2. 成果責任と権限委譲ができていない
    ⽬的を達成するための戦略をメンバが検討できていない
    疑問を持ちつつも『⽅針が決まっているから』という気持ちで開発
    3. 動くソフトウェアを継続的に作るという意識が低い
    反復型開発の本質を分かっていない
    10
    

    View Slide

11. 解決したいこと
    1. ステレオタイプなスクラムを忠実に守り続けることに徹している
    スクラムへの偏⾒をなくす
    2. 成果責任と権限委譲ができていない
    ⾃⼰組織化を促す
    3. 動くソフトウェアを継続的に作るという意識が低い
    理想の反復型開発を知る
    11
    

    View Slide

12. 1. スクラムへの偏⾒をなくす
    12
    

    View Slide

13. スクラムを廃⽌
    代わりに モブプログラミング を導⼊
    モブプログラミングとはチームのメンバ全員を
    ミーティングスペースに集めて⼀緒に開発をする開発スタイルのこと
    13
    

    View Slide

14. スクラムを廃⽌
    全員未経験なので、みんなが⼿探り状態
    効果を試すため、思い切って1⽇5時間くらいは集まることにした
    14
    

    View Slide

15. 効果
    1⽇中 コーディング、レビュー、進捗共有、情報共有
    を同時にやっているような感覚
    15
    

    View Slide

16. 効果
    1⽇が終わると相当な達成感と疲労感があった
    雑談しながら開発できるので、疲れるがとても楽しい
    16
    

    View Slide

17. 効果
    問題解決のためには、プロセスやツールを検討するより
    対話をしたほうが効果的だとメンバが感じるようになった
    情報を伝えるもっとも効率的で効果的な⽅法は
    フェイス・トゥ・フェイスで話をすることです。
    『アジャイル宣⾔の背後にある原則』より
    “
    “
    『アジャイル宣⾔の背後にある原則』http://agilemanifesto.org/iso/ja/principles.html
    17
    

    View Slide

18. 効果
    その結果
    Slack での会話はほぼなし
    プルリクでのレビューはほぼなし
    JIRA による課題管理はほぼなし
    やり⽅が分からないアプローチをあえて取ることで
    偏⾒を持たず、⾃分たちで改善策を⾒出すのだという
    アジャイルの本質を理解してもらえた
    18
    

    View Slide

19. 2. ⾃⼰組織化を促す
    19
    

    View Slide

20. ⾃⼰組織化
    ⾃⼰組織化
    マネージャーはゴールだけを⽰し
    戦略はメンバが⾃主的に検討できるように作られたチームのこと
    ⾃⼰組織化を促すためにやったこと
    クロスファンクショナルチームの形成
    進捗報告の仕⽅を変える
    20
    

    View Slide

21. ⾃⼰組織化
    クロスファンクショナル（職能横断型）チーム
    1つのタスクに1⼈を割り当てるようなことはしない
    横断的にタスクをこなしてもらう
    その際、メンバが苦⼿なことをうまくマネージメントする
    得意な作業は積極的に実施してもらう
    苦⼿な作業はそれが得意な⼈を探す努⼒をしてもらう
    21
    

    View Slide

22. ⾃⼰組織化
    進捗報告の仕⽅を変える
    かつては⼝頭や⽂章・スライドなどで伝えてもらっていた
    しかしそれだと上⼿に ウソ がつけてしまう
    22
    

    View Slide

23. ⾃⼰組織化
    進捗報告は動くプログラムでデモをやってもらう
    動くプログラムを⾒せることで
    ⾃分の作ったものを必要としてくれる⼈がいることを知れる
    デモに失敗したら、ちゃんと動かせるように気を使うようになる
    ⾃⼰組織化が促進される
    23
    

    View Slide

24. 3. 理想の反復型開発を知る
    24
    

    View Slide

25. 反復型開発がよく分かる画像と動画
    画像
    How to build a minimum viable product
    TED の動画
    トム・ウージェック︓塔を建て、チームを作る
    チームのメンバ全員に⾒てもらった
    25
    

    View Slide

26. How to build a minimum viable product
    夢は⼤きく、⽬標は⼩さく
    部品を作るのではなく、 同じコンセプト を持つものを作り続ける
    画像引⽤: https://medium.com/@heyjudesue/what-does-it-take-to-design-a-minimum-viable-product-5175e554fa3a
    26
    

    View Slide

27. 塔を建て、チームを作る
    マシュマロ・チャレンジ
    スパゲッティの麺で⾃⽴式の塔を建て
    塔の⼀番⾼いところにマシュマロを置いたチームが勝ちというゲーム
    組み⽴て⽅をじっくり議論するより
    早く実践に移るチームの⽅が勝ちやすい という結果に
    トム・ウージェック︓塔を建て、チームを作る
    動画引⽤: https://www.ted.com/talks/tom_wujec_build_a_tower
    27
    

    View Slide

28. まとめ
    1. チームの働き⽅は 継続的 に⾒直す必要がある
    2. ソフトウェアは 継続的 に動くものを作る必要がある
    3. アジャイルにおける 失敗は終わりではなく始まり
    アジャイルは 継続的な失敗駆動開発 である
    28
    

    View Slide

29. Thank You!
    29
    

    View Slide