More Related Content Similar to Why do we use Scrum? ユーザ企業のスクラム導入事例 ~失敗体験から学んだスクラムの本質~
Similar to Why do we use Scrum? ユーザ企業のスクラム導入事例 ~失敗体験から学んだスクラムの本質~ (20) 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.
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.
10. スクラムは登山に似てい
る
Copyright © 2008 Team Reaches Mt. McKinley Glacier Strip! by Air Force2013 DeNA Co.,Ltd. All Rightson Flickr
Copyright (C) 7 Summits Challenge, 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.
16. How to be a Sheep dog?
License Some rights reserved by Hitchster
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.
28. 1. 悩める Sheep dog
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.
46. 3. 巻き返す Dog !
Some rights reserved by rawlands
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.
Editor's Notes 1分。変化に対応するために我々自身が変化しなければチャンスはつかめない的な話をする。
30秒。世の中がどう変わってきたか話す。顧客のニーズが高度化、多様化する現在は、作れば売れる時代ではなくなった。我々の主力ビジネスであるソーシャルゲーム業界でも同じことが言える。
1分。そんな世の中でどのようにして我々がチャンスを掴むのか。
経営陣が答えをしっていてスピーディに指示を遂行すれば良い体制から、
顧客が答えを知っているとすると、顧客に近い現場を支援する体制に変わる必要がでてきているのが今の状況。
1分。ここまでで3分半。そんななかで自分はどのようにして会社に貢献し、顧客に価値を届けるのか考えた。
1分半。ここまでで5分。
武道や茶道などで言われている守破離に似た戦略でスクラムを実践してきてた。本で書かれていることや研修で教えられたことを忠実に守る、「守」から始まって、我々の組織やプロジェクトにあった、よりよいと思われるやり方に変える、型を破る、「破」、我々のスクラムを理解した上で型から離れる「離」。
・それぞれ経験を積みながらやっていることにも触れる(いきなり応用から入ると危険)
・業務委託について次スライドで説明する
1分。スプリント0が大事な話。
1分。ここまでで7分。スプリント開始以降の話。
30秒。契約のまとめ。
1分。エベレスト登頂がゴールでも、まずは身近な山からトレーニングを。
登る山に応じて戦略・戦術も変える必要があるが、まずは基本から。
天候やチームの状況によっては再計画や中断も。
30秒。そんななかで自分はどのようにして会社に貢献し、顧客に価値を届けるのか考えた。
30秒。ここまでで9分半。
知花さんにつなぐ
自己紹介一通り
今年からゲーム第一本部というゲームの内製開発を行っている部署で
組織改善やスクラムマスターとしての仕事を担当しています。
もともと営業畑でして、DeNA入社してからは広告部で営業したり、広告の運用の仕事を
していたため、製品の企画をしたことや、エンジニアの経験もありませんが
縁があってこの世界へ飛び込むことになりました。
ちょうど半年前ぐらいになります。
皆さんの中で
・スクラムマスターの方
・導入を考えられている方
・役職が付いている方
↓
色々な方がいらっしゃるということですが、
本題に入る前にみなさんに一つ質問させてください
スクラムマスターはよくあるものに例えられますが
何に例えられるか知ってますか?
(なかなかあがらないようなので私から答えをいってしまいますと)
みなさんSheepdogと言葉は
ご存知でしょうか?スクラムでよく出てくる言葉ですが
本題に入る前に、SheepDogについて説明させていただくと
日本語では牧羊犬と訳されていて、
あっちにいったりこっちにいったりする羊たちの群れの見張り、誘導して
外敵から守るという役割を担う犬のことです。
私は日々どうやってSheepdogになれるのかを考えてスクラムを
勉強してきました。
では、私達はどうすればsheep dogの役割を果たせるようになるのか?
どのようなスキルや、マインドセットが必要なのか?
ースクラムの基礎知識は大前提として
ーファシリテーションスキル、コーチングスキル、とかいろいろあると思います
私が経験してわかったことは、本よりも何よりも、
自分自身の仮説と検証による体験と学びが一番大事だということに気づきました
なので今日は実際の体験談、主に失敗したことをベースにお話したいと思います。
私は
従来の支持型の組織運営しかしらなかったんで
スクラムマスターとして組織の中で動くことになってから、
まあたくさんの、失敗をしてきたわけなんです
なんでこんな恥ずかしいことをわざわざさらけだすか?
成功事例は、その事例がもつ様々な環境やタイミング、
などが複雑に影響している可能性もあり
必ずしも「これをやったら誰でも同じように成功する」とはなりにくいと思っています。
一方で、失敗は「少なくともやらないほうがよさそう」「やるときは気をつけよう」という
意識がでることで、みなさんの成功確率が高まることに繋がると思うからです。
30,40分の短い時間ではありますが、
皆さんと一緒に、この時間を使って「失敗から何を学んだのか?何が学べるのか?」ということを考えていきたいと思います。
失敗談を皆さんにイメージしてもらいやすいように、
4ヶ月間のモチベーション曲線をつくってみました。
横軸が時期、縦軸がモチベーションの度合いです
かなり乱高下した4ヶ月間でした
このモチベーション曲線・・・(説明と名前の由来の説明)
いろいろしゃべりたいことたくさんあるのですが、今日はこの期間を3つの時期
に分けて、お話します。
というわけで、今回のアジェンダはこうなります。
まず初めに、プロローグとして、私がスクラムに対して抱いた印象をお話します。
次にこの「広告部とは?」では私が初めてスクラムマスターを担当した広告部について
チームの役割とスクラム導入背景をご説明します。
次の2〜4は先ほど説明したフェーズについての話をします
最後にエピローグとして全体を通したメッセージをお伝えします。
では、プロローグについてです。
この数字は何か想像できますか?
異動〜配属1週間までにとりあえず得た知識
本3冊
スクラム概要説明会1回参加(1時間)
全くの知見がない中でのスタートでした
・私はこの説明会を聞いた時は、ちょうど派遣や契約社員の
労務管理、広告運用に関する、審査基準を作ったり、売上貢献のための業務改善を
どうするか、ということを考えたりするのが仕事でした
・基本的に気持ちとしてはスタッフに意見を求めて自律的になってほしいと
思ってはいたものの、すぐに答えをだしてしまうなど結果支持型で動かしていたのもあって
今のやり方に限界を感じ始めていた
すごく純粋に感動したわけですが、
でもこの気持ちが後々苦しむことになるんです
次に、私が初めて担当したスクラムチームがあった、広告部の説明を少しお話します。
広告部は、Mobageの各ページ上に、
アフィリエイトや純広告、企業とのタイアップ、それと最近だと
ゲーム開発のデベロッパーさま向けのプロモーション商品
などを掲載させることで顧客の価値を最大化させるとともに、
そこから得る収益を最大化させることをミッションに持つ部です。
これは少し昔の資料になりますが、みてお分かりのように、
インターネット広告が広告市場の中で急速に加速する一方で、
弊社の広告事業は厳しい状況が続いていました。
営業以外に、各商品の企画を行うチーム・既存商品から離れたアライアンスなどをつうじた新規広告事業を行うチーム・
開発チームと運用チームがありました。
(スライドは読まない!)
先ほどの資料からもわかるように、
部の状況は売上やコスト意識に非常に過敏になっている一方で、
自律的なチームを作り、協働をし、PDCAサイクルをまわしたいという
願望がありました。
さあ、このチームのサポートを通じて、
私が失敗とそこから学んだことを中心にこれからお話していきたいと思います。
それでは実際に1つずつのフェーズについて、
エピソードをお話していきたいと思います。
最初は、悩めるSheepDogについて、です。(ここです)
と言われたので、スクラムを導入しようとなりました。
新規のチームはチームリーダーの他に企画2名で構成されている
少数の企画メンバーチームでした。
・チームリーダーは進捗確認で時間を使ってしまう割に、進んでいないことも多々ある
・知見がバラバラだから働き方のPDCAサイクルをまわしてみたいという思いがあったようです。
いざチームとしてどのように進めていくか、を考えると
とたんに困ってしまいました
--------
・1ヶ月のSprintにしたい
・1周間のさいくるのほうがよさそう
・やってみたけどやっぱりこれがいい、あれがいい-----------
何に失敗したかというと、単純にチームを促してファシリテートすることができなかったことです
知識も知見も軸もないので、こういう本に書いていないような、
イレギュラーの小さな質問や状況についていけないわけです
一緒に困っちゃった。もうどうしよう、と。
迷った私は先輩に「最適なサイクルを決める時はどうしたらいいのか」相談すると
こう言われました。
「何のためにチームはスクラム入れてやってるの?」
と言われました。そこではっっっと気づきました。
そうだ!このチームは働き方が見直せればいいわけだから、最初は決めでもいい
とりあえず2週間でも1週間でもやってみて、何かそのサイクルがどうしてもだめなら
また変えればいい。ただ不便でもできるだけ固定しつづけるように説明してみよう
やっているうちに、チームが陥りこみやすい事象がでてきた
お客さんのアポがとれないと次の作業が進められない
チーム外のMTGや作業が多すぎる
未知のことを行っているから、計画漏れしている想定外のタスクが実はたくさんあった
これからやっていく仕事の全体像が見える形にするにはどうすればいいか(一呼吸おいて次のスライドへ)
ここで、ひとつ、私の最初の失敗から、気をつけるべきことをお伝えします。
スクラムを始めたいと、チームはわりと気軽に考えて話してきます。
新しい手法があるなら試してみたい、と。
↓
ただ実際初めてみて困った時、スクラムマスターやチームも含め
何を一番改善したいのか?と立ち返ったほうがいいと思います。
このチームは「働き方のPDCAを行い、ナレッジとしてためたい」
ということでした。
なので、「働き方をもっと工夫することで、少しでもよくなる方法はないか?」と
問いかけることで、
自分たちが思うように進められないことのブロッカーになっている
ものを見つけ、解決していくように徐々になっていきました。
そもそも何のために計画するのか?なんのためにスクラムやるのか?
を考えないうちから、導入や計画作業にいきなり入ることは
やめたほうがいいということをお伝えしておきます。
それでは、2つ目のエピソードについてお話します
ここの時期のお話は、既存商品の売上最大化を考えるチームのお話です
既存チームは企画メンバーと開発メンバーが
1つのチームになってスクラムを使って仕事をしていました。
ただ、このチームはPOに一点心配な部分がありました。
POは実は広告部長との兼務でかなりの激務の中PO業務をしていました。
また、スクラムも初心者でした。
計画作業やプロダクトバックログという要件リストの手入れを行うタイミング
があると、POはよくこんな発言を繰り返していました
(吹き出し読み上げる)
POは本来は、プロダクトのROIを考える人で、優先順位をきめる役割のはずなのに、
PO自身が、優先順位を考えられない=プロダクトの未来像がないのか?
と思ってしまうような発言が多く、私は、
どうしたものかなー。
役割があいまいになると、チームとしての方向性がぶれるな、、と思っていました
私は、メールや、口頭で
とにかく「POのあるべき姿、振る舞いはこうすべき」「POの実作業でやらなければいけないこと」
を伝え続けました。
ここで、何が失敗だったかというと、
伝えつつづけたというところです。
コミュニケーションが一方通行なんです。
当時のメールを読み返すと、私のかなり長いメールにたいして
POの返事は「わかった!」と一言二言ぐらいのものでした。
私はここで自分の仕事は
「スクラムマスターはスクラムルールを伝えるものなのだ」と勘違いしていました。
伝え続けても、実際の状況はなかなか変化がおきず、
POの役割がきちんと果たされていない状態が続いて
私が当初から懸念していた「POとチームの間の役割分担」の境界線はが崩れていくいっぽうです・
崩れていくと、こういうことがチーム内で叫ばれるようになってきます
当時私は何でPO何もし言わないの?何でもチームにきいてそのまま従っちゃうの!?と思っていましたが、
(クリックして☓をだす)これ、違いますよね。
おそらく、伝えても、伝わっていない、行動に移されないということは
なにか理由があるはずで、
それが忙しすぎるのか
役割を勘違いしているとか納得できないとか
なんか相手にも理由や状況があるはずなんですけど
その理由を私はさがしてなかった。
ここで気をつけること2こめです
あるべき論だけが先行してしまってはだめということです
「だって私はスクラムがちゃんと遂行されることに責任があるんだから」
ということだけに必死で、ぐいぐい杓子定規に指摘をするよりも、
状況をきいて、一緒に悩んで、考えて提案してみたり、示唆することも
時に必要なんです。
それに気づいたわたしはPOに、その時の状況を話してみて、どう思っているのかきいてみたら、
「売上がでるような企画の大枠は理解ができるけど、それ以外の小さい要件や
開発の改善系要件は内容がわからない。」
という状況であることが新たにわかりました。
ここで私がサポートした内容をご説明します
私は1つ仮説を立ててみました。
この状況が生まれるのは、POもチームも目指しているゴールまでの
マイルストンとか優先順位が、実はみんな見えていないから?
見えてるとしても、統一されてはないのではないか?
と考えてみたわけです。
①優先順位の妥当性を一つ一つチームで議論すると時間がかかりすぎる
②だからといって自分がPOに一つ一つ聞きながら整理したりするよりは、
みんなでブラッシュアップしていく形のほうがコミュニケーションが生まれるし
わかりやすそう
そこで、POとチームに、ゴールまでのマイルストンを可視化してみよう。
POもチームも一緒にこの作業をしてみようと提案しました。
GROWモデル知ってる人?→説明
ビジョンツリー説明
いざ始めてみると、やっぱり混乱しました。チーム内でビジョンは合意されていなかったんです。
「チームのビジョンの方ですか?プロダクトのビジョンか?」
「数字はどこにおくか?」
「数字も目標と必達があるけど・・」
という、理想状態をどこに置くのか?で皆で議論になってしまいました。
ゴールは数字だと思っている人、数字は結果だと思っている人、
もっと目線高くもってほしいPOの意見や思惑が入り乱れるので、
ゴールの合意はすごく大変でした。
というわけで、気をつけること、3つめは、ビジョン合意なくしてチーム運営を始めない。
チームが始まる時は、ビジョン共有は最初からやっておいたほうがいい、ということです。
工夫として、ビジョンの意識統一をする時は言語統一からするなどして、
サポートするといいかもしれません
コーチングの世界でよく言われている、ビジョンの定義をひっぱり、
2回目以降はこれを基準にして進めました。
ただ、ゴールをどこに置くかは事前にPOと握っておいてもいいかもしれません。
はい。続いて最後のエピソードである「まきかえすDog」です
巻き返す前に私は大きな失敗をしてしまいます。
一番の失敗ってどのような失敗だったか、予想がつく方
いらっしゃいますでしょうか?
これです。チームをこんな状態にさせてしまいました
最初のイントロの時に少し触れた、私の初期のスクラムに対する印象が
ここで炸裂するわけですが、
スクラム=素晴らしい!という思い込み、信念を強く持ちすぎていました
そもそもスクラムやったら必ず成功するか、といったらそうではないのに。
一人のメンバーが他メンバー全員のタスクを動かすという挙動をし始めました
2日続いたので、さすがに、とおもってそのメンバーに
「チームが能動的な思考がストップしてしまうので、メンバーそれぞれの
タスクは、その人たち自身で動かしてもらえないだろうか」
「スピード重視なんで、そうやっているだけです。POとも合意していますし」
と言われてしまいました。ここで、「じゃあPOにも聞いてみる」とか何とかいって
お持ち帰りしておけばいいものを、
そして私は禁断の一句を言ってしまったのです
このことを言ってしまうと、
最初のほうのスライドで申し上げた、「そもそも何を解決したいのか?」に
フォーカスがあたらずに、
「スクラム自体」にフォーカスがあたってしまいます
この人はこのやり方自体にネガティブな印象をもってしまいました
私はスクラムやりたいだけなのか?
自分のスクラムに対する知識や理解が弱いから、
言い負かされそうでそれしか言えなかったんじゃないか?
(ここのセレモニーやツールは意味が必ず意味があるのに
理解してもらう方法もきっとたくさんあったはずなのに)
ここのエピソードで強く申し上げたい
気をつけること④つめは「スクラム屋さんにならないことです」
①課題や解決したいことをすべてスクラムありきで考えると
押し付けになってしまいがちになります。(少なくとも私は)
そうなると「この人スクラムやりたいだけか」、と思われてしまってと相談もこなくなるし、
信頼関係もなくなってしまいました。(自分の知らないところで、働き方の再定義が始まっていたりした)
②促す相手に、伝え方や促し方を誤ると、おかしなことになります
タイミングや伝え方って大事だなと思いました、
後悔していてもしょうがない、頑張らなければ、と思い巻き返しにかかります。
スクラムから一歩抜けだして、
仕切り直しを行いました。
なぜスクラムではだめなのか?にフォーカスするのではなく、
どういったサイクルがチームには必要なのか?という切り口から始めました
ここで目指した状態は
プロジェクト成功のために、安定したワークサイクルが何かしら作られて、
腹落ちして合意できること。というところだけ自分の中で決めました。
あとはとにかくヒアリングをすることを心がけました
よくよく聞いてみると意外と皆いろんな意見をもっていました。
ガントチャートがほしい
→属人化タスクが多く、解消には時間がかかる、誰がどのように動けばいいかシミュレーションがしたい
広告業界ではスクラムが合わない
→スクラムの2週間まわしがサービスリリース日とうまく咬み合わない
→レビューは都度しつつ・1週間にすればいいのでは?
作業期間固定にしたくない
→中長期の目標やコミットをする際に、何を元にするのか?
各スプリントの差がわかってよくない?
振り返りは絶対したい、タスク分解もやったほうがいい、など
このような議論をチームはしながら、結局は
スクラムは継続して行い、スプリントを1週間にしてみて、検証しようということになりました。
チームの意思をもって進めるというリスタートが切れた瞬間でした
その後何スプリントかが続いたあと、初めてバーンダウンをしました。
ビジョンツリーもしょこしょこ続けていたこともあり変化が見られました
・企画側があるべき姿が描けていなかたことがわかり
・改善系タスクも、売上を最大化させることに
つながると気づけた
・プロダクトバックログに落とし込みやすくなった
・エンジニアも企画側の分野に興味をもって一緒に考えるようになった
ここまでが私のスクラムマスターとしての失敗談のエピソードでした。
ここで気をつけたいポイントを総括してお話します。
・1つ目は何が解決したいのか?
・2つ目はScrumのルール以外でも困っているところは一緒に悩んでサポートする
・3つ目はビジョンはしっかり合意する
・4つ目は、スクラムマスターはスクラムの奴隷にならない
全体としてのメッセージとして、「Stay Humble」
というキーワードをお伝えします。
謙虚ね、ふーんと思うかもしれませんが
どういうことなのかが、私は最近ようやくわかった気がしました。
PJTの進行がなんとかうまくいったり、
目の前の課題が解決されたりすると、お礼を言われるようになりました
でも私は純粋にそれをプレッシャーに感じるようになりました
私達は直接売上に貢献するわけでもないし、
手をうごかすわけでもないからです。
すべてはチームの中に眠っていたものを
チームが気づいてチームで動いて改善していったからです
謙虚になるというのは、なろうとおもってなるものではなく、
己の小ささを理解することから始まるのだと思っています。
Sheep DogになるためのHw to本も正解もありません
正直難しいです。なので仮説と検証をくりかえして知見をためてスキルをみがくことと、
答えはちーむが持っていると信じ、スクラムの押し付けだけはしないこと
まずはここをしっかり意識することを今後も自分はしていきたいと思ってますし、
皆さんにもメッセージとしてお伝えしたいと思います。
以上で私の発表を終わらせていただきます。ありがとうございました。
さて、最後にこういう経験談や思いを共有してお互いを磨き合う機会を作りたい人は
いらっしゃいませんか?ひとつ告知があります!