スクラムやる意味ある？を乗り越えるために

初めに

スクラム開発を進める中で「スクラムやる意味あるんけ？」って感じる瞬間が訪れます。僕がスクラムマスターとして参画しているチームもその瞬間が訪れましたが、うまく乗り越えることができたのでその時にやったことや得た知見をまとめてみます。

私は何者か？

• 都内のSaaS開発企業のエンジニア
• 主にバックエンドとフロントエンドの開発をしています
• スクラムマスターもやっていて、チームを自己組織化に向けて支援することをやっています
• 前職はSIerで、要件定義〜テストまで幅広く対応していました

この記事で話すこと

この記事では、僕がスクラムマスターとしてチームと仕事して感じた変化を組織の成長段階を示したモデルであるタックマンモデルに沿って紹介します。まずはタックマンモデルについて簡単に紹介し、その後、成長段階に沿って、チームの状況、僕個人の心境、それぞれの段階で取り組んだこととその成果について紹介します。

タックマンモデルとは？

まずはタックマンモデルとは何かどうかを先にお話しします。タックマンモデルとは、組織の成長を5つの段階に分けたモデルです、プロジェクトが始まり、チームが形成される形成期、メンバーそれぞれが意見をぶつかり合う混乱期、共通の認識が形成され、チームがまとまりだす統一期、チームに一体感が生まれ、成果を生み出す機能期、プロジェクトが完了し、チームが解散する解散期とチームの成熟度によって移り変わります。
これらのモデルを理解することで、今自分たちのチームがどんな状態なのか、チームを次のレベルに引き上げるために何をしたらいいのかが理解できるようになります。

タックマンモデルに沿ったチームの変遷のまとめ

それぞれの段階の詳細を見る前に、まずは全体像をつかんでいきましょう。僕が担当したチームの変遷は以下のようになっています。

-	形成期	混乱期	統一期	機能期
期間	2022/6 ~ 2022/7	2022/8 ~ 2022/10	2022/11 ~ 2023/1	2023/2 ~ 現在
状態	とりあえずスクラムやってみる	スクラムやる意味あるんけ？？	議論の脱線がなくなてスムーズになった！	自己組織化に成功🎉
僕の役割	ティーチング ファシリテーション	ティーチング ファシリテーション	コーチング	委譲

大体2、３ヶ月くらいで次のステージに進んでいることがわかります。また、気持ちい良くらいタックマンモデルに沿ってチームの状態も変わっていることもわかります。

形成期

ここからは、それぞれの段階でチームの状態の詳細、僕の心境と取り組んだことについて紹介します。まずは形成期から。昨年の6月、スクラム開発を採用してチーム開発が始まりました。開発を始める前、僕を含めたチームのメンバーからの声は「スクラムってどうやるんやろう？」とか「初めてやからワクワクするわ」みたいな感じで期待と不安が半々でした。そんな時、ひょんなことからリーダーが僕に「スクラムマスターやってみーひん？」って提案を受け、「やったことないけど挑戦してみよう」と思い、スクラムマスターに挑戦することになりました。
僕の心境は「何したら良いかわからんけどとりあえずスクラムガイドに沿って進めてみたらいいんかな？」でした。ふざけんなって声も上がるかもしれませんが、右も左もわからなかったので、スクラムガイドに頼るしか当時は考えられなかったのです。

形成期でやったこと

スクラムマスターとしてまず初めにやったことは、スクラムガイドの内容を理解し、内容とセレモニーの進め方をNotionにまとめることでした。スクラムマスターに挑戦するまでスクラムに対する理解は薄く、うまく説明できないレベルだったので、まずは僕がスクラムについて理解する必要があるなと考えていました。また、スクラムガイドの内容を理解するためには、Notionにまとめるといい感じになるんじゃないかって思い、社内のNotionに理解した内容とセレモニーの進め方をまとめました。

実際にまとめたのが👆の画像です。こんな調子でNotionにずらずらまとめてチームに共有しました。
この施策はうまくいきませんでした。振り返って、原因だと思っていることはやってることがスクラムガイドに書いていることをただただまとめているだけだったからだと考えています。スクラムガイドはかなり薄い本なので、表面的に理解した気になりやすい本だと思いますが、実際は奥が深い本だと考えています。なので表面的な理解に留まった最初は、なんでスクラムをするのか、それぞれのセレモニーは何のために開催されて、ゴールは何か、などの具体的なところで認識の齟齬が発生し、チームがうまく立ち上がりませんでした。

混乱期

このように形成期の取り組みに四苦八苦していた頃、チームは混乱期に突入しました。スクラムを初めて2ヶ月が経過した頃、チームの中から「セレモニーが多いし長くてしんどい」や「レトロスペクティブでTry考えるけど、どれもピンと来てない」、「スクラムやってから生産性があがった気がしない」という声がよく上がるようになりました。中には「スクラムやる意味あるん？」という辛辣な意見も出てきました。きついなと思ったのは、この辛辣な発言はリーダーからだったことです。このままだと本当にスクラムをやめてしまうのかもしれないという危機感が生まれました。この辺りから、僕の心境が大きく変わりました。何がうまくいかなかったのかを分析し、どうしたらもっとチーム全員が納得してスクラム開発ができるのかを考えるようになりました。

混乱期でやったこと

混乱期を乗り越えるために大切なことは「チーム全員が同じ方向を向いて業務に取り組めるようにする」だと考えました。混乱期が発生する原因が、チームのメンバー間で認識齟齬が多々発生していることだと思ったからです。なので、混乱期を乗り越えるために、僕はどうしたら認識齟齬を減らせるのかをテーマに改善活動を始めました。

リーダーとの協働

まずやったことは、リーダーとの協働です。チームをまとめているリーダーと一緒に今後のスクラムについて考えることで、より効果的にチームにスクラムを浸透させることができると考えたからです。具体的に何をしたのかをざっくりまとめると、まず「何でスクラム開発をするのか」をまとめました。そもそもスクラム開発を何で導入しているかの認識が揃っていないと他の部分でも認識齟齬が出ると思ったので、まずはここの認識を揃えました。その後、セレモニーについて、何でそのセレモニーを開催するのか、セレモニーのゴールは何か、ゴールに向けてセレモニーをどうやって進めるのか、参加者への期待値の認識を揃えました。
この施策は大成功でした。僕とリーダーの間で何でスクラムをやるのか、それぞれのセレモニーが何のためにあるのかを考えることで、二人の間でスクラムに対する共通認識が生まれたので各セレモニーが格段に進めやすくなりました。また、僕にとってはスクラムに対する解像度も上がりました。スクラムガイドに書いていることの上っ面だけを覚えるのではなく、何でこの成果物を作る必要があるのかや、何でこのセレモニーを開催しないといけないのか、どうしたらうまくセレモニーを進めることができるのかを考えた経験は僕にとって大きなことでした。

実際の議事録。お互いが納得できる形で議論したことでスクラムについての解像度も上がったし、大切にすることを基にセレモニーをどう進めたらいいのかがイメージできやすくなりました。

レトロスペクティブの再構築

もう一つ取り組んだことは、レトロスペクティブの再構築です。リーダーとセレモニーについて議論していた時にスクラムのセレモニーの中で、レトロスペクティブが一番重要なのではないかという話が出たからです。チームで、レトロスペクティブの目的はスプリントを振り返り、課題を認識してTryを考えることで持続的に改善をし続けることができることだと定義しました。これができるようになるとどんどんチームをよくするためにどうすればいいかを考えることができるようになり、最終的にチームの理想の姿である自己組織化につながると考えました。なのでレトロスペクティブを改善することは、僕たちにとって大きなテーマでした。
この施策は成功でした。レトロスペクティブのゴールは何か、参加者への期待値の認識を揃えることで、参加者の中で今なんの議論をしているのかやこの議論の終着点は何かを意識して議論に参加するようになり、再構築する前は課題の原因を話している時に具体的な解決策の議論が始まってしまうように議論が脱線することが多かったのですが、これが劇的に少なくなりました。

統一期

リーダーと協働することでスクラムの意図やセレモニーの目的とゴールをチームに浸透させ、レトロスペクティブの再構築をすることで議論の脱線が少なくなってきた頃、チームが次の段階に進みました。チームの中から「目的がはっきりしたから前よりも納得して議論に参加できている」や「スクラムの効果が出てきた気がする」みたいな発言が生まれるようになりました。混乱期を抜け、統一期を迎えることになりました。スクラムマスターが何も言わなくてもスムーズに議論が進むし、課題が発生したらチーム内ですぐに話し合い、どうするのかを決めるなど、主体的に改善活動に取り組んでくれるようになりました。ただし、ここで安心してはいけません。人間は安心すると現状維持を好む生き物です。この状態に安心してしまうと、ここから先にある機能期を迎えることなくチームが解散することになるかもしれません。僕は「もっといいチームになるにはどうしたらいいのか」を考え、施策を考える必要がありました。

統一期でやったこと

統一期から機能期に向かう上で大切だと考えたのはチームを正しい方向に導くことでした。統一期の段階で、チームが一つの方向に向かっている状態になっています。しかし、この向いている方向が誤っていると、成果を出せるチームにはなれません。本当に成果を出すチームになるためには、自分たちが向いているところが正しいのかを考え、誤った方向に進んでいるなら正しい方向に導く必要があります。これを達成するために僕は、チームのメンバー全員がレトロスペクティブのファシリテーターになることを目指しました。ファシリテーターは、議論の全体の流れを把握し、議論が脱線したら元に戻したり、議論が詰まったら突破口を開いたりすることが求められます。全員がファシリテーターを経験することで、議論を客観的に見ることができるようになり、議論を正しい方向に導くことができます。僕自身もファシリテーターを経験してから目的やゴールを先に考える癖がつき、議論だけでなく普段の業務や他部署からの依頼にも活かせるようになりました。この経験から、ファシリテーターを全員が務めることができる状態にしたら、チームを正しい方向に導くことも可能なのではないかと思い、取り組みを始めました。
やったことは、レトロスペクティブでの議論のテンプレートを作成することです。今までは僕がファシリテーターを務めていたので自分なりの議論の型があったのですが、それを明文化することで誰がファシリテーターをやっても同じ流れで議論ができるようになると考えたからです。また、議論のテンプレートを作成することで、今何の話をしているのか認識が揃い、議論が脱線することが少なくなることを期待しました。実際、この取り組みは狙った通りの成果を出すことができました。議論の最初に何でその課題を解消したいのか、解消したらどんな状態になっているのが理想的かを話し合って目的とゴールの認識を揃え、発生した課題を深掘りすることで根本的な原因を探し、効果的かつ持続可能なTryを話し合うという流れをテンプレート化することで、議論が脱線せずにスムーズに進むようになりました　。今までは会議の時間が2時間を超えることが多々あったのですが、Tryの作成までを2時間以内に終えることができるようになりました。また、効果のあるTryを作成できるようになったため、チームのメンバーから「このTry、すごくよかった」という声も出るようになった。さらに、一番大きな成果だと思ったのが、発言の偏りがなくなった。今まではファシリテーターとリーダーが議論で発言し、その意見が通ることが多かったが、チーム全員がファシリテーターを経験してから、メンバーからの発言が多く見られるようになった。みんなが発言できる環境になったことで、ファシリテーターやリーダーに忖度することなく議論ができるようになりました。心理的安全性というバズワードがありましたが、僕らのチームはまさにこの心理的安全性が高いチームになったのだと考えています。

テンプレートを基に実際に議論した時の議事録。議論の流れを先に作っておくことで、議論がやりやすくなりました。

実際に次回のTryを作成した時の議事録。何のためにそのTryをして、どんな効果を期待しているのかを明確にすることで具体的かつみんなが納得できる形でTryを作成できるようになりました。

機能期

チーム全員がファシリテーターを務めることができ、全員が当事者意識を持ってチームに貢献しようと奮闘した結果、僕らのチームは機能期にたどり着くことができました。この頃から、突発的なタスクが発生したときにチーム内でどうするか話し合い、自分たちで優先順位を決めることができるようになりました。また、課題が発生したらその場で話し合い、解決までチーム内で完結できるようになりました。この状態になると、チームのベロシティも安定するようになりました。この状態になると、スクラムマスターとしてやることはほとんどなくなり、社内NEETみたいな状態になりました。CTOから「スクラムマスターのゴールは、スクラムマスターが必要なくなること」だと言われてきた僕としては、この状態はスクラムマスターの役割を全うできた状態であると考えました。僕が旗振りをしなくてもチームの皆が問題解決や優先順位付けを積極的に行い、それらを遂行するために開発以外のメンバーとも積極的にコミュニケーションを取るようになりました。この記事のタイトルにもある「スクラムやる意味ある？」を乗り越えることができました。

スクラムやる意味ある？を乗り越えるために

最後に、僕が思うスクラムやる意味ある？を乗り越えるために必要なことを書いて締め括りたいと思います。段階的よって必要なことは変わるとは思いますが、どの段階にでも共通することは2つだと思っています。
１つ目は、目的・ゴールを自分たちで考え、明確にすることです。スクラムの本やスクラムガイドにも目的は書いてありますが、それは一般論です。チームにとって本当にスクラムが必要なのか、スクラムのセレモニーは何のためにあるのかを自分たちの言葉で明確にすることで本やスクラムガイドに書かれていることが理解できるようになるんだと思っています。実際に僕も、上記を考えることでスクラム開発を何でやるのかの自論を持つことができるようになりました。
２つ目は、チームを信頼することです。スクラムマスターにありがちなのは「俺が何とかしなければ」の状態になりがちなことです。もちろん、チームが発足して初めの頃はティーチングが必要だとは思いますが、過度にチームに干渉してはいけないと思っています。僕はレトロスペクティブのファシリテーターを交代制にしてからこのことに気づきました。それまでは僕がずっとファシリテーターを務めていた、かつ議論をリードしてしまっていたので、僕の意見が通りやすかった時期がありました。しかし、僕はスクラムマスターなのでチームの細かい状況はメンバーの方が詳しいのに僕の意見が通っていました。今思えばこれはスクラムマスターが過干渉になっているなと思いますが、当時はそのようなことは考えていませんでした。ファシリテーターを交代制にしてからメンバーの発言が増えたことで、僕よりもメンバーの方が課題の解像度が高いことを痛感しました。「僕がバンバン意見を出すのではなく、メンバーが意見を言いやすい環境を作り上げた方がチームの成熟度が上がるんやな」って痛感しました。次に新しいチームを持つときは、チームのメンバーを信頼して発言が偏らない環境作りを優先して取り組むことから始めたいなって思っています。

終わりに

長く、拙い文章になってしまいましたが、最後まで見ていただきありがとうございます。これからも技術のことやスクラム開発のことを書いていこうと思うので、読んでいただけると嬉しいです。