Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アジャイル失敗のススメ

 アジャイル失敗のススメ

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

NAVITIME JAPAN
PRO

July 02, 2018
Tweet

More Decks by NAVITIME JAPAN

Other Decks in Technology

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