Why do we use Scrum? ユーザ企業のスクラム導入事例 ～失敗体験から学んだスクラムの本質～
•
21 gefällt mir•5,176 views
Regional Scrum Gathering Tokyo 2014で貝瀬・知花が発表に使用したスライドです。文字が少なくてすみません。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Why do we use Scrum? ユーザ企業のスクラム導入事例 ～失敗体験から学んだスクラムの本質～
Ähnlich wie Why do we use Scrum? ユーザ企業のスクラム導入事例 ～失敗体験から学んだスクラムの本質～ (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (8)
Why do we use Scrum? ユーザ企業のスクラム導入事例 ～失敗体験から学んだスクラムの本質～
- 1. Why do we use Scrum? ユーザ企業のスクラム導入事例 失敗体験から学んだ スクラムの本質 January 14, 2014 貝瀬岳志・知花里香 DeNA Co., Ltd. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 2. No Change, No Chance! 2 Copyright © 2008 Change by DeNA Co.,Ltd. All Rightson Flickr Copyright (C) 2013 Wiertz Sébastien, Reserved.
- 3. Where is a Chance? 企業は 成功のヒントを 顧客から学ぶ時代へ Change! 3 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 4. How do we get a Chance? 明確な 明確な 答え 答え 指 指 示 示 ・ ・ 命 命 令 令 マネジメントは 顧客に近い 現場を支援する サーバントリーダー へ Change! 自 自 律 律 ・ ・ 提 提 案 案 経営陣 服 服 従 従 ・ ・ 遵 遵 守 守 ミドルマネジメント 現場 Copyright © 2010 Pyramide du Louvre by Andy Rudorfer, on Flickr 顧客 答えの 答えの ヒント ヒント 現場 ミドルマネジメント 経営陣 支 支 援 援 ・ ・ 奉 奉 仕 仕 Copyright © 2008 Tête en bas by twiga269 ॐ FEMEN, on Flickr Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 5. （私にとって）スクラムは 理想の組織を作るためのフレームワー ク スクラムマスター スクラムマスター チーム チーム ミドルマネジメント ミドルマネジメント ・経営陣 ・経営陣 5 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 6. DeNA スクラムの守破離的歴 11‘ 6 11’ 12 12’史 6 12’ 12 13’ 6 守 13’ 12 （内製）プラットフォームの運用 （内製）プラットフォームの運用 （内製）プラットフォームの （内製）プラットフォームの 新規開発 新規開発 （内製）ソーシャルゲームの （内製）ソーシャルゲームの 新規開発 新規開発 （外注）プラットフォームの新規開 （外注）プラットフォームの新規開 発 発 （外注）プラットフォーム （外注）プラットフォーム の運用 の運用 破 （外注）ソーシャルゲー （外注）ソーシャルゲー ムの新規開発 ムの新規開発 （その他） KAIZEN チームの運営 （その他） KAIZEN チームの運営 （その他）部門間の連携フロー改善 （その他）部門間の連携フロー改善 離 （その他）非スクラムチームの組 （その他）非スクラムチームの組 織改善・業務改善 織改善・業務改善 6 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 7. 外注スクラムのスプリント 0 ＝ 開発準備＋契約締結 スプリント 0 スプリント 1 スプリント 2 スプリント n-1 個別契約 スプリント n 個別契約 基本契約 •• •• •• •• •• •• 役割分担、役務内容の合意 役割分担、役務内容の合意 初期プロダクトバックログの合意 初期プロダクトバックログの合意 Done の定義の合意 Done の定義の合意 全体スケジュールの合意 全体スケジュールの合意 開発手法、コミュニケーション手段の合意 開発手法、コミュニケーション手段の合意 これらを踏まえた契約締結 これらを踏まえた契約締結 7 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 8. 外注スクラムのスプリント 1 〜 n ＝ 定例会議＋日々のコミュニケーション＋契約更新 スプリント 0 スプリント 1 スプリント 2 スプリント n-1 個別契約 スプリント n 個別契約 基本契約 •• •• •• •• •• スプリントごとに定例会議を実施 スプリントごとに定例会議を実施 定例会議でレビューとスプリント計画を実施 定例会議でレビューとスプリント計画を実施 個別契約はスプリント計画で合意した内容で締結 個別契約はスプリント計画で合意した内容で締結 日々のコミュニケーションはチャットツールを活用 日々のコミュニケーションはチャットツールを活用 レビューで受け入れた成果物に対して支払い レビューで受け入れた成果物に対して支払い 8 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 9. 外注スクラムにおける３つのポイント スクラムを可能にするための 漸進的契 約 日々のコミュニケーションを可能にするため の簡便なツールや場 軌道修正しながらゴールを実現するための 定例 会議 9 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 10. スクラムは登山に似てい る Copyright © 2008 Team Reaches Mt. McKinley Glacier Strip! by Air Force2013 DeNA Co.,Ltd. All Rightson Flickr Copyright (C) 7 Summits Challenge, Reserved.
- 11. ゴール・理想を描いたら一歩一歩着実に 。 スモールスタートで本質を理解す る。 11 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 12. DeNA スクラムの守破離的歴 11‘ 6 11’ 12 12’史 6 12’ 12 13’ 6 守 13’ 12 （内製）プラットフォームの運用 （内製）プラットフォームの運用 （内製）プラットフォームの （内製）プラットフォームの 新規開発 新規開発 （内製）ソーシャルゲームの （内製）ソーシャルゲームの 新規開発 新規開発 （外注）プラットフォームの新規開 （外注）プラットフォームの新規開 発 発 （外注）プラットフォーム （外注）プラットフォーム の運用 の運用 破 （外注）ソーシャルゲーム （外注）ソーシャルゲーム の新規開発 の新規開発 （その他） KAIZEN チームの運営 （その他） KAIZEN チームの運営 （その他）部門間の連携フロー改善 （その他）部門間の連携フロー改善 離 （その他）非スクラムチームの組 （その他）非スクラムチームの組 織改善・業務改善 織改善・業務改善 12 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 13. 新人スクラムマスター 失敗の経験から学べ ること January 14, 2014 知花里香 Japan Region 事業本部 ゲーム第一本部 DeNA Co., Ltd. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 14. 自己紹介 知花 里香 （チバナ サトカ） 株式会社ディー・エヌ・エー Japan Region 事業本部 ゲーム第一本部 Certified Scrum Master ・前職は報道機関でニュースコンテンツの営業 ・ DeNA では広告部門でアライアンス〜運用まで広めに経験 ・スクラムには昨年７月に出会いました ・担当したチーム 広告チーム／カスタマーサポート開発チーム／ 新人エンジニアチーム／新規サービス開発チーム・・ etc Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 15. Sheep dog License Some rights reserved by Hitchster Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 16. How to be a Sheep dog? License Some rights reserved by Hitchster Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 17. Priceless 体験と学び！ Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 18. 人のふり見て・・ License Some rights reserved by StockMonkeys.com Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 19. 私のモチベーション曲線 High スクラム最高！ なんとか 解決… !? スクラム「型」守れない・・ ファシリテートって・・ うまくいかない 自分がブレる 悩める ただの Dog Sheep dogチームは 他の SM やコーチに Mid 課題を解決したいの か！？ 巻き返す dog 励まされる やっぱり PO 理解してない 「このストーリー、何でやるの？」 発言 スクラムとの終焉 Low 7 8 9 10 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 20. Agenda 0. プロローグ 1. 広告部とは？ 2. 悩める Sheep dog 〜新規広告企画チームの話〜 3. ぐいぐいすぎる Sheep dog 〜既存広告企画開発チームの話〜 4. ただの dog になりさがる→まきかえす dog 5. エピローグ Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 21. 0. プロローグ ３＋ １ Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 22. 最初に感じたスクラムの イメージ Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 23. なんて素晴らしい フレームワーク！ Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 24. 広告部とは？ Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 25. 広告事業の推移 ディー・エヌ・エー決算資料より http://dena.com/ir/library/presentation.html Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 26. 広告部とは？ 営業 営業 新規企画 新規企画 既存企画 既存企画 運用 運用 開発 開発 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 27. スクラム導入の背景 作りたいものが予定通り作れない PDCA をうまくまわしたい Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 28. 1. 悩める Sheep dog Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 29. チームリーダーからの一言 「新規広告商品企画 の PDCA をうまくまわしたい」 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 30. スプリント期間を決めるとこ ろから、とたんに困る Some rights reserved by rawlands Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 31. ものすごい要望の数々 １ヶ月に １ヶ月に したい したい 僕は１週間 僕は１週間 にしたほうが にしたほうが よさそう よさそう なんとかだー なんとかだー かんとかだー かんとかだー やっぱり やっぱり ２週間にする ２週間にする 企画 NG に 企画 NG に なった・・ なった・・ 再計画だー 再計画だー Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 32. Sheep dog のつもりが、 完全に Sheep へ License Some rights reserved by Martin Pett Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 33. 何のためのスクラム導入 なのかを考えよう Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 34. 気をつけること① 課題の本質を見失わない 安易に Sprint 計画を始めない Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 35. 2. ただの Dog Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 36. PO は現場がわからず自分で判断できない 優先順位教えてー 優先順位教えてー なんとかならないの なんとかならないの MTG の長さ MTG の長さ このストーリ、 このストーリ、 どういうやつだっけ？ どういうやつだっけ？ 終わったんだっけ？あ 終わったんだっけ？あ れ終わってない？ れ終わってない？ 売上優先！ 売上優先！ PO Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 37. 役割が崩れていく・・ License Some rights reserved by Capt' Gorgeous Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 38. PO の仕事が全うされていないと・・ ・企画の仕様わかりにくい → 自分たちで作る！ ・優先順位納得出来ない →順位かえたい ・手戻りがある →責任者を 都度変えよう Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 39. 何故 PO 何も言わない の！？ できない理由をさがすべき。 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 40. 気をつけること② あるべき論だけが先行してし まってはだめ。 一緒に悩んで、解決の道を探る 。 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 41. 自分も頑張る LicensSome rights reserved by NatalieMaynor Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 42. ビジョンツリーを作ってみようと 提案してみた Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 43. ビジョンツリーとは GROW モデルを「木」に見立てたも Will Will の Goal Options Options Reality Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 44. 混 乱！ ゴールの合意は大仕事！ Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 45. 気をつけた方がいい③ ビジョン合意なくしてチーム運営を始めない 目標 ロードマップ Goal 目的 目的 ビジョン Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 46. 3. 巻き返す Dog ！ Some rights reserved by rawlands Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 47. 「スクラムやめたい」 Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 48. あるとき最大の 失敗の訪れが・・・ Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 49. “ スクラム＝素晴らしいフレームワーク ” この思い込みが私を焦らせた （スクラムに沿ってもらわなければ きっと失敗してしまう・・・） Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 50. とある Daily Scrum… Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 51. 私は言いました 「あなた 1 人がメンバー全員を コントロールすると スクラムじゃ なくなります」 と Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 52. 最大の失敗と押し寄せる後悔 私は何でそんなこと言っ てしまったのか ? Some rights reserved by rawlands Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 53. 気をつけること④ 「スクラム屋さ ん」にならない ✖ Scrum Slave ◯ Scrum Master Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 54. License Some rights reserved by Zain A.B Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 55. 将来を考える場を作ろ う！ Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 56. スクラムか他のワークプロセス か？ Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 57. 「なんか合わない」から、 「これにしよう！」へ Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 58. チームを同じベクトルに 向けることが出来た Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 59. 気をつけたほうがいいことまとめ ① 課題の本質を見失わない／安易に Sprint 計画を始めない ② あるべき論だけが先行して しまってはだめ。 ③ ビジョン合意なくしてチーム 運営を始めない ④ 「スクラム屋さん」にならない Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 60. 5. エピローグ Stay Humble Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 61. ご清聴ありがとう ございました！ License Some rights reserved by smalljude Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
- 62. 告知 Scrum masters Night 開催予定！ 参加希望者は Facebook Group を Scrum Masters Night ！ で検索！ Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
Hinweis der Redaktion
- 1分。変化に対応するために我々自身が変化しなければチャンスはつかめない的な話をする。
- 30秒。世の中がどう変わってきたか話す。顧客のニーズが高度化、多様化する現在は、作れば売れる時代ではなくなった。我々の主力ビジネスであるソーシャルゲーム業界でも同じことが言える。
- 1分。そんな世の中でどのようにして我々がチャンスを掴むのか。 経営陣が答えをしっていてスピーディに指示を遂行すれば良い体制から、 顧客が答えを知っているとすると、顧客に近い現場を支援する体制に変わる必要がでてきているのが今の状況。
- 1分。ここまでで3分半。そんななかで自分はどのようにして会社に貢献し、顧客に価値を届けるのか考えた。
- 1分半。ここまでで5分。 武道や茶道などで言われている守破離に似た戦略でスクラムを実践してきてた。本で書かれていることや研修で教えられたことを忠実に守る、「守」から始まって、我々の組織やプロジェクトにあった、よりよいと思われるやり方に変える、型を破る、「破」、我々のスクラムを理解した上で型から離れる「離」。 ・それぞれ経験を積みながらやっていることにも触れる（いきなり応用から入ると危険） ・業務委託について次スライドで説明する
- 1分。スプリント0が大事な話。
- 1分。ここまでで7分。スプリント開始以降の話。
- 30秒。契約のまとめ。
- 1分。エベレスト登頂がゴールでも、まずは身近な山からトレーニングを。 登る山に応じて戦略・戦術も変える必要があるが、まずは基本から。 天候やチームの状況によっては再計画や中断も。
- 30秒。そんななかで自分はどのようにして会社に貢献し、顧客に価値を届けるのか考えた。
- 30秒。ここまでで9分半。 知花さんにつなぐ
- 自己紹介一通り 今年からゲーム第一本部というゲームの内製開発を行っている部署で 組織改善やスクラムマスターとしての仕事を担当しています。 もともと営業畑でして、DeNA入社してからは広告部で営業したり、広告の運用の仕事を していたため、製品の企画をしたことや、エンジニアの経験もありませんが 縁があってこの世界へ飛び込むことになりました。 ちょうど半年前ぐらいになります。 皆さんの中で ・スクラムマスターの方 ・導入を考えられている方 ・役職が付いている方 ↓ 色々な方がいらっしゃるということですが、 本題に入る前にみなさんに一つ質問させてください スクラムマスターはよくあるものに例えられますが 何に例えられるか知ってますか？ （なかなかあがらないようなので私から答えをいってしまいますと）
- みなさんSheepdogと言葉は ご存知でしょうか？スクラムでよく出てくる言葉ですが 本題に入る前に、SheepDogについて説明させていただくと 日本語では牧羊犬と訳されていて、 あっちにいったりこっちにいったりする羊たちの群れの見張り、誘導して 外敵から守るという役割を担う犬のことです。 私は日々どうやってSheepdogになれるのかを考えてスクラムを 勉強してきました。
- では、私達はどうすればsheep dogの役割を果たせるようになるのか？ どのようなスキルや、マインドセットが必要なのか？ ースクラムの基礎知識は大前提として ーファシリテーションスキル、コーチングスキル、とかいろいろあると思います
- 私が経験してわかったことは、本よりも何よりも、 自分自身の仮説と検証による体験と学びが一番大事だということに気づきました
- なので今日は実際の体験談、主に失敗したことをベースにお話したいと思います。 私は 従来の支持型の組織運営しかしらなかったんで スクラムマスターとして組織の中で動くことになってから、 まあたくさんの、失敗をしてきたわけなんです なんでこんな恥ずかしいことをわざわざさらけだすか？ 成功事例は、その事例がもつ様々な環境やタイミング、 などが複雑に影響している可能性もあり 必ずしも「これをやったら誰でも同じように成功する」とはなりにくいと思っています。 一方で、失敗は「少なくともやらないほうがよさそう」「やるときは気をつけよう」という 意識がでることで、みなさんの成功確率が高まることに繋がると思うからです。 ３０，４０分の短い時間ではありますが、 皆さんと一緒に、この時間を使って「失敗から何を学んだのか？何が学べるのか？」ということを考えていきたいと思います。
- 失敗談を皆さんにイメージしてもらいやすいように、 ４ヶ月間のモチベーション曲線をつくってみました。 横軸が時期、縦軸がモチベーションの度合いです かなり乱高下した４ヶ月間でした このモチベーション曲線・・・（説明と名前の由来の説明） いろいろしゃべりたいことたくさんあるのですが、今日はこの期間を３つの時期 に分けて、お話します。
- というわけで、今回のアジェンダはこうなります。 まず初めに、プロローグとして、私がスクラムに対して抱いた印象をお話します。 次にこの「広告部とは？」では私が初めてスクラムマスターを担当した広告部について チームの役割とスクラム導入背景をご説明します。 次の２〜４は先ほど説明したフェーズについての話をします 最後にエピローグとして全体を通したメッセージをお伝えします。
- では、プロローグについてです。 この数字は何か想像できますか？ 異動〜配属１週間までにとりあえず得た知識 本３冊 スクラム概要説明会１回参加（１時間） 全くの知見がない中でのスタートでした
- ・私はこの説明会を聞いた時は、ちょうど派遣や契約社員の 労務管理、広告運用に関する、審査基準を作ったり、売上貢献のための業務改善を どうするか、ということを考えたりするのが仕事でした ・基本的に気持ちとしてはスタッフに意見を求めて自律的になってほしいと 思ってはいたものの、すぐに答えをだしてしまうなど結果支持型で動かしていたのもあって 今のやり方に限界を感じ始めていた すごく純粋に感動したわけですが、 でもこの気持ちが後々苦しむことになるんです
- 次に、私が初めて担当したスクラムチームがあった、広告部の説明を少しお話します。 広告部は、Mobageの各ページ上に、 アフィリエイトや純広告、企業とのタイアップ、それと最近だと ゲーム開発のデベロッパーさま向けのプロモーション商品 などを掲載させることで顧客の価値を最大化させるとともに、 そこから得る収益を最大化させることをミッションに持つ部です。
- これは少し昔の資料になりますが、みてお分かりのように、 インターネット広告が広告市場の中で急速に加速する一方で、 弊社の広告事業は厳しい状況が続いていました。
- 営業以外に、各商品の企画を行うチーム・既存商品から離れたアライアンスなどをつうじた新規広告事業を行うチーム・ 開発チームと運用チームがありました。
- （スライドは読まない！） 先ほどの資料からもわかるように、 部の状況は売上やコスト意識に非常に過敏になっている一方で、 自律的なチームを作り、協働をし、PDCAサイクルをまわしたいという 願望がありました。 さあ、このチームのサポートを通じて、 私が失敗とそこから学んだことを中心にこれからお話していきたいと思います。 それでは実際に１つずつのフェーズについて、 エピソードをお話していきたいと思います。
- 最初は、悩めるSheepDogについて、です。（ここです）
- と言われたので、スクラムを導入しようとなりました。 新規のチームはチームリーダーの他に企画２名で構成されている 少数の企画メンバーチームでした。 ・チームリーダーは進捗確認で時間を使ってしまう割に、進んでいないことも多々ある ・知見がバラバラだから働き方のPDCAサイクルをまわしてみたいという思いがあったようです。
- いざチームとしてどのように進めていくか、を考えると とたんに困ってしまいました
- -------- ・1ヶ月のSprintにしたい ・１周間のさいくるのほうがよさそう ・やってみたけどやっぱりこれがいい、あれがいい----------- 何に失敗したかというと、単純にチームを促してファシリテートすることができなかったことです 知識も知見も軸もないので、こういう本に書いていないような、 イレギュラーの小さな質問や状況についていけないわけです
- 一緒に困っちゃった。もうどうしよう、と。 迷った私は先輩に「最適なサイクルを決める時はどうしたらいいのか」相談すると こう言われました。 「何のためにチームはスクラム入れてやってるの？」 と言われました。そこではっっっと気づきました。
- そうだ！このチームは働き方が見直せればいいわけだから、最初は決めでもいい とりあえず２週間でも１週間でもやってみて、何かそのサイクルがどうしてもだめなら また変えればいい。ただ不便でもできるだけ固定しつづけるように説明してみよう やっているうちに、チームが陥りこみやすい事象がでてきた お客さんのアポがとれないと次の作業が進められない チーム外のMTGや作業が多すぎる 未知のことを行っているから、計画漏れしている想定外のタスクが実はたくさんあった これからやっていく仕事の全体像が見える形にするにはどうすればいいか（一呼吸おいて次のスライドへ）
- ここで、ひとつ、私の最初の失敗から、気をつけるべきことをお伝えします。 スクラムを始めたいと、チームはわりと気軽に考えて話してきます。 新しい手法があるなら試してみたい、と。 ↓ ただ実際初めてみて困った時、スクラムマスターやチームも含め 何を一番改善したいのか？と立ち返ったほうがいいと思います。 このチームは「働き方のPDCAを行い、ナレッジとしてためたい」 ということでした。 なので、「働き方をもっと工夫することで、少しでもよくなる方法はないか？」と 問いかけることで、 自分たちが思うように進められないことのブロッカーになっている ものを見つけ、解決していくように徐々になっていきました。 そもそも何のために計画するのか？なんのためにスクラムやるのか？ を考えないうちから、導入や計画作業にいきなり入ることは やめたほうがいいということをお伝えしておきます。
- それでは、２つ目のエピソードについてお話します ここの時期のお話は、既存商品の売上最大化を考えるチームのお話です
- 既存チームは企画メンバーと開発メンバーが １つのチームになってスクラムを使って仕事をしていました。 ただ、このチームはPOに一点心配な部分がありました。 POは実は広告部長との兼務でかなりの激務の中PO業務をしていました。 また、スクラムも初心者でした。 計画作業やプロダクトバックログという要件リストの手入れを行うタイミング があると、POはよくこんな発言を繰り返していました （吹き出し読み上げる） POは本来は、プロダクトのROIを考える人で、優先順位をきめる役割のはずなのに、 PO自身が、優先順位を考えられない＝プロダクトの未来像がないのか？ と思ってしまうような発言が多く、私は、 どうしたものかなー。 役割があいまいになると、チームとしての方向性がぶれるな、、と思っていました
- 私は、メールや、口頭で とにかく「POのあるべき姿、振る舞いはこうすべき」「POの実作業でやらなければいけないこと」 を伝え続けました。 ここで、何が失敗だったかというと、 伝えつつづけたというところです。 コミュニケーションが一方通行なんです。 当時のメールを読み返すと、私のかなり長いメールにたいして POの返事は「わかった！」と一言二言ぐらいのものでした。 私はここで自分の仕事は 「スクラムマスターはスクラムルールを伝えるものなのだ」と勘違いしていました。 伝え続けても、実際の状況はなかなか変化がおきず、 POの役割がきちんと果たされていない状態が続いて 私が当初から懸念していた「POとチームの間の役割分担」の境界線はが崩れていくいっぽうです・
- 崩れていくと、こういうことがチーム内で叫ばれるようになってきます
- 当時私は何でPO何もし言わないの？何でもチームにきいてそのまま従っちゃうの！？と思っていましたが、 （クリックして☓をだす）これ、違いますよね。 おそらく、伝えても、伝わっていない、行動に移されないということは なにか理由があるはずで、 それが忙しすぎるのか 役割を勘違いしているとか納得できないとか なんか相手にも理由や状況があるはずなんですけど その理由を私はさがしてなかった。
- ここで気をつけること２こめです あるべき論だけが先行してしまってはだめということです 「だって私はスクラムがちゃんと遂行されることに責任があるんだから」 ということだけに必死で、ぐいぐい杓子定規に指摘をするよりも、 状況をきいて、一緒に悩んで、考えて提案してみたり、示唆することも 時に必要なんです。 それに気づいたわたしはPOに、その時の状況を話してみて、どう思っているのかきいてみたら、 「売上がでるような企画の大枠は理解ができるけど、それ以外の小さい要件や 開発の改善系要件は内容がわからない。」 という状況であることが新たにわかりました。
- ここで私がサポートした内容をご説明します
- 私は１つ仮説を立ててみました。 この状況が生まれるのは、POもチームも目指しているゴールまでの マイルストンとか優先順位が、実はみんな見えていないから？ 見えてるとしても、統一されてはないのではないか？ と考えてみたわけです。 ①優先順位の妥当性を一つ一つチームで議論すると時間がかかりすぎる ②だからといって自分がPOに一つ一つ聞きながら整理したりするよりは、 みんなでブラッシュアップしていく形のほうがコミュニケーションが生まれるし わかりやすそう そこで、POとチームに、ゴールまでのマイルストンを可視化してみよう。 POもチームも一緒にこの作業をしてみようと提案しました。
- GROWモデル知ってる人？→説明 ビジョンツリー説明
- いざ始めてみると、やっぱり混乱しました。チーム内でビジョンは合意されていなかったんです。 「チームのビジョンの方ですか？プロダクトのビジョンか？」 「数字はどこにおくか？」 「数字も目標と必達があるけど・・」 という、理想状態をどこに置くのか？で皆で議論になってしまいました。 ゴールは数字だと思っている人、数字は結果だと思っている人、 もっと目線高くもってほしいPOの意見や思惑が入り乱れるので、 ゴールの合意はすごく大変でした。
- というわけで、気をつけること、３つめは、ビジョン合意なくしてチーム運営を始めない。 チームが始まる時は、ビジョン共有は最初からやっておいたほうがいい、ということです。 工夫として、ビジョンの意識統一をする時は言語統一からするなどして、 サポートするといいかもしれません コーチングの世界でよく言われている、ビジョンの定義をひっぱり、 ２回目以降はこれを基準にして進めました。 ただ、ゴールをどこに置くかは事前にPOと握っておいてもいいかもしれません。
- はい。続いて最後のエピソードである「まきかえすDog」です 巻き返す前に私は大きな失敗をしてしまいます。 一番の失敗ってどのような失敗だったか、予想がつく方 いらっしゃいますでしょうか？
- これです。チームをこんな状態にさせてしまいました
- 最初のイントロの時に少し触れた、私の初期のスクラムに対する印象が ここで炸裂するわけですが、 スクラム＝素晴らしい！という思い込み、信念を強く持ちすぎていました そもそもスクラムやったら必ず成功するか、といったらそうではないのに。
- 一人のメンバーが他メンバー全員のタスクを動かすという挙動をし始めました ２日続いたので、さすがに、とおもってそのメンバーに 「チームが能動的な思考がストップしてしまうので、メンバーそれぞれの タスクは、その人たち自身で動かしてもらえないだろうか」 「スピード重視なんで、そうやっているだけです。POとも合意していますし」 と言われてしまいました。ここで、「じゃあPOにも聞いてみる」とか何とかいって お持ち帰りしておけばいいものを、 そして私は禁断の一句を言ってしまったのです
- このことを言ってしまうと、 最初のほうのスライドで申し上げた、「そもそも何を解決したいのか？」に フォーカスがあたらずに、 「スクラム自体」にフォーカスがあたってしまいます この人はこのやり方自体にネガティブな印象をもってしまいました
- 私はスクラムやりたいだけなのか？ 自分のスクラムに対する知識や理解が弱いから、 言い負かされそうでそれしか言えなかったんじゃないか？ （ここのセレモニーやツールは意味が必ず意味があるのに 理解してもらう方法もきっとたくさんあったはずなのに）
- ここのエピソードで強く申し上げたい 気をつけること④つめは「スクラム屋さんにならないことです」 ①課題や解決したいことをすべてスクラムありきで考えると 押し付けになってしまいがちになります。（少なくとも私は） そうなると「この人スクラムやりたいだけか」、と思われてしまってと相談もこなくなるし、 信頼関係もなくなってしまいました。（自分の知らないところで、働き方の再定義が始まっていたりした） ②促す相手に、伝え方や促し方を誤ると、おかしなことになります タイミングや伝え方って大事だなと思いました、
- 後悔していてもしょうがない、頑張らなければ、と思い巻き返しにかかります。
- スクラムから一歩抜けだして、 仕切り直しを行いました。 なぜスクラムではだめなのか？にフォーカスするのではなく、 どういったサイクルがチームには必要なのか？という切り口から始めました ここで目指した状態は プロジェクト成功のために、安定したワークサイクルが何かしら作られて、 腹落ちして合意できること。というところだけ自分の中で決めました。
- あとはとにかくヒアリングをすることを心がけました よくよく聞いてみると意外と皆いろんな意見をもっていました。 ガントチャートがほしい →属人化タスクが多く、解消には時間がかかる、誰がどのように動けばいいかシミュレーションがしたい 広告業界ではスクラムが合わない →スクラムの2週間まわしがサービスリリース日とうまく咬み合わない →レビューは都度しつつ・１週間にすればいいのでは？ 作業期間固定にしたくない →中長期の目標やコミットをする際に、何を元にするのか？ 各スプリントの差がわかってよくない？ 振り返りは絶対したい、タスク分解もやったほうがいい、など このような議論をチームはしながら、結局は スクラムは継続して行い、スプリントを１週間にしてみて、検証しようということになりました。
- チームの意思をもって進めるというリスタートが切れた瞬間でした
- その後何スプリントかが続いたあと、初めてバーンダウンをしました。 ビジョンツリーもしょこしょこ続けていたこともあり変化が見られました ・企画側があるべき姿が描けていなかたことがわかり ・改善系タスクも、売上を最大化させることに つながると気づけた ・プロダクトバックログに落とし込みやすくなった ・エンジニアも企画側の分野に興味をもって一緒に考えるようになった
- ここまでが私のスクラムマスターとしての失敗談のエピソードでした。 ここで気をつけたいポイントを総括してお話します。 ・１つ目は何が解決したいのか？ ・２つ目はScrumのルール以外でも困っているところは一緒に悩んでサポートする ・３つ目はビジョンはしっかり合意する ・４つ目は、スクラムマスターはスクラムの奴隷にならない
- 全体としてのメッセージとして、「Stay Humble」 というキーワードをお伝えします。 謙虚ね、ふーんと思うかもしれませんが どういうことなのかが、私は最近ようやくわかった気がしました。 PJTの進行がなんとかうまくいったり、 目の前の課題が解決されたりすると、お礼を言われるようになりました でも私は純粋にそれをプレッシャーに感じるようになりました 私達は直接売上に貢献するわけでもないし、 手をうごかすわけでもないからです。 すべてはチームの中に眠っていたものを チームが気づいてチームで動いて改善していったからです 謙虚になるというのは、なろうとおもってなるものではなく、 己の小ささを理解することから始まるのだと思っています。 Sheep DogになるためのHw to本も正解もありません 正直難しいです。なので仮説と検証をくりかえして知見をためてスキルをみがくことと、 答えはちーむが持っていると信じ、スクラムの押し付けだけはしないこと まずはここをしっかり意識することを今後も自分はしていきたいと思ってますし、 皆さんにもメッセージとしてお伝えしたいと思います。 以上で私の発表を終わらせていただきます。ありがとうございました。
- さて、最後にこういう経験談や思いを共有してお互いを磨き合う機会を作りたい人は いらっしゃいませんか？ひとつ告知があります！