はじめに
今年チームにスクラムを導入し、今ではチーム全員がスクラムマスターとしてファシリテートできるくらいになりました。
実は、スクラムの導入は初めてでなく、昔やった時は導入に失敗しました。勉強会でも、導入に失敗したという話を聞くことがあります。
そこで、今回の経験や、過去の失敗を元に、「これが導入のコツなんじゃなかろうか？」というものを紹介したいと思います。
導入に失敗した方や、これから導入したいという方に、少しでも参考になればと思います。
経験がベースなので、論理的に違うとか、セオリーと異なる部分もありますが、ご容赦ください。
6つのコツ一覧
- 価値を明確にする。そのスクラムをやる意味は？
- やりたいという気持ちが強い「ファン」を作る
- 1スプリントは1週間で始める
- 「出来ない部分」を決める
- メンバーは「のっかればいい状態」にする
- 「今までと違う！」を肌で感じられるようにする
■価値を明確にする。そのスクラムをやる意味は？
なぜスクラムをやるか、価値を明確にしておくと良いです
頭の中でわかってるというのではなく、実際に言語化して残しておくのをおすすめします
言語化の際に改めて気づきがあった、ということもあります
私が所属するチームの場合、以下のような目的がありました
- 工数、仕事の見える化
- メンバーのモチベーション向上（新しいもの好きが多かったので）
- 開発速度の向上
おすすめな理由
- 新しいことを導入するにはエネルギーが必要です。スクラムの価値を自分が信じていなければ、簡単に心が折れてしまいます
- 周りを巻き込む際に「なぜやるのか」が説明出来ないと、ついてきてくれません
- 価値が明確でないと、そもそもその導入が成功したのか、失敗したのかわかりません。導入後、価値もないのに惰性で続いている仕組みが生まれることを避けましょう。工数だけを奪うことになってしまいます
■ファン（アーリーアダプター）を作る
導入を開始する前に、スクラムをやってみたい！という気持ちを共有するメンバーを作りましょう
新しいもの好きな人や、周りに影響が強い人が特におすすめです
私の場合、影響力が高いメンバー二人をまきこみ、フローの整理や、レビューなど、色々な形で協力していただきました。
おそらく二人がいなかったらここまで上手く導入できなかったと思います。本当に助かりました。
おすすめな理由
- 一人だと、どうしても視野が狭くなりがちです。意見を交換したりするファンがいると、アイデアが広がります
- そもそもファンを作る段階で、その導入が上手くいきそうかどうかがわかります。この際にファンを作れないアイデアを皆に広めるのは難しいです
- サポートしてくれるファンは積極的に新しい仕組みをキャッチアップしてくれます。メンバーにとって、リーダーの説明を実行するよりも、周りのメンバーのやり方を真似する方がハードルが低い場合があります。そこで、積極的に新しい仕組みをキャッチアップしてくれるファンがいることで、周りのメンバーは「リーダーに言われたことをやる」ではなく「他のメンバーを真似する」ことが出来るようになります。
■1スプリントは1週間で始める
スクラムの1スプリントは、1週間から1月くらいが多いです。（私の感覚だと、2週間が一番多い気がします）
1スプリントは、開発アイテムの傾向や、プロダクトの特性によって変更すべきですが、一番最初にあえて1週間にすることはメリットがあると考えています
おすすめな理由
- 1スプリントを早く回すことで、新しい仕組みに慣れやすい。（1週間1スプリントだと、1月に4スプリントも経験できる）
- 1スプリントを大きくすると、開発アイテムを無理やりその形に合わせてしまいやすい。1週間だと、想像がしやすく、工数を無理やり丸めたりしづらい
■「出来ない部分」を決める
スクラムを教科書通りにやろうとした場合、「こうすべき」というルールが非常に多いです。
事業部、営業部との関係性、プロダクトの特性上など、周辺環境が理由で「どうしてもここはやりづらい！」という部分は少なからずあると思います。
出来なそうな部分に関しては「やってみてから考えよう」と伸ばし伸ばしにしがちですが、いっそ「ここは諦める！」と決めた方が良いこともあります。
私が所属するチームの例をあげると、1スプリントで「機能が出来上がる」ということをあえて捨てています。
基本的には、スプリントの最後で目に見える発表物を作らなければいけないのですが、プロダクトの特性上、開発アイテムが大きい、目に見えづらい改善が多いといった課題があったため、ここを明確に出来ない部分と決めています。
おすすめな理由
- 明確に「やらない」と決めることで、精神的負担を減らせる
- やらないことによるデメリットを、あらかじめ想定できるため、デメリット影響を出来る限り減らしやすい
- やることを減らすことで、導入に対するハードルが下がることがある（「これは譲れない」という部分で導入中止を防ぐ）
■メンバーは「のっかればいい状態」にする
メンバーに対して、説明会を一度開いて、やり方のドキュメントをおしまい。このやりかたは危険です
新しい仕組みは多くの場合、新しいタスクが発生します。そのタスクをやってもらうために、出来る限りサポートしましょう
メンバーが非常に積極的な場合をのぞいて、新しい仕組みの導入は「余分な追加コスト」と感じてしまうこともあるはずです
なので、「メンバーが積極的に取り組まないと回らない」ではなく「メンバーは、言われたことをやってればよい。リマインドや、やり方を教えてくれる人がいる」という状態を作ることが重要です
一つの例として、進捗管理の話をあげます。
私が所属するチームではベロシティで工数の見える化をするために、毎日工数やタスクの進捗の入力をお願いしています。
これは個人で任せるのではなく、朝会の際に数分時間をとって、皆で一斉に更新してもらうことで、更新漏れを防いでいます。
おすすめな理由
- メンバーに丸投げした場合、導入が進まない
- 新しい仕組みに対応出来ているメンバーと、対応出来ていないメンバーがいた場合、対応出来ているメンバーまで「やらなくていいか」という状態になりかねない
■「今までと違う！」を肌で感じられるようにする
新しい仕組みを入れた後に「これって意味があったんだろうか？」という疑問が出ないように、ちゃんと結果、効果を伝えましょう
「リーダーだけが良くなったことを知っている」といったことは避け、良かったのか悪かったのか、できれば定量的に伝えられるとベストです
私が所属するチームでは、毎週ベロシティがどれくらい出せたか、どれだけ不測のタスクが入ったか、お互いのヘルプをどれくらい出来たかといったことをグラフ化し、毎週みんなで確認しています。
おすすめな理由
- 結果、効果を知ることで、新しい仕組みの価値が伝わる
- 逆に、それを知らないと「やって意味あったんだろうか」という疑問に繋がってしまう
以上6つのコツでした。
読んでいただきありがとうございます。少しでも参考になることがあれば嬉しいです。