2チームのスクラムマスターとして意識したこと
はじめに
私は普段UXデザイナーとして、業務システムやWebサイトのサービスデザインに携わっています。一方でアジャイルコーチやスクラムマスターとして、アジャイルの現場支援もします。最近A-CSMを取得しました。
今回は、この半年間スクラムマスターをやっているSaaSプロダクトの2チームスクラムの話です。開発者16名中、半数以上がスクラム未経験で、いきなり2チームではじめるとき、スクラムマスターとして何を意識していたのかを共有します。
基本方針
LeSS、Scrum@Scale、Nexus、SAFeなど、スクラムチームをスケーリングする手法はたくさん存在します。けれども、今回は16名からなる”たった2チーム”のスクラムです。
なので、そこまで大げさに考えず、あくまでも大きな1つのスクラムチームとして捉えて、これらのフレームワークを採用せずにスケーリングしました。
まず2チームでスクラムをやるにあたって、5つの基本方針を設けました。
フラットなチームにし、上下関係や階層構造はつくらない
全員が全体に責任をもち、担当領域や責任範囲をつくらない
オールラウンダーになり、スペシャリストをつくらない
透明性を高く保ち、密室をつくらない
シンプルさを保ち、複雑な仕組みはつくらない
フラットなチームにし、上下関係や階層構造はつくらない
2チームにスケールするときに、まず対処しなきゃいけないのはコミュニケーションの課題。スケーリング手法のなかには、「複数チームを統括する上位レイヤーを設置して、トップダウンな管理をする」「また各チームから代表者を立てて代表者同士で話し合う場をつくる」といった方法で、コミュニケーションを一部の人々で統制するものがあります。
どちらも自己管理チームを生み出すのを阻害し、透明性を下げてしまうリスクが伴います。もちろんチーム数が4チーム、8チーム、16チームと大規模になれば必要になるかもしれませんが、今回はたったの2チームです。
1チームが2チームになった瞬間に、そういった手法を使うのはメリットよりもデメリットのほうが大きいので妥当とは思えません。したがって、PO1名、SM1名、DEV8名(Team A)、DEV8名(Team B)の構成だけでやってみることにしました。
開発メンバーにも「POやSMは両チームの橋渡し役ではないし、そういう役割は置きません。もし、チーム間で解決する必要がある事象があれば、必要なメンバーで直接話し合ってね。」と伝えました。
全員が全体に責任をもち、担当領域や責任範囲をつくらない
2チームにスケールするときに、次に対処しなきゃいけないのは責任範囲の課題。各チームがどの領域に責任を持つか、という話です。チームの担当領域を疎結合にして、責任範囲を分割するテクニックはいろいろあります。
けれども、今回は「あくまでも大きな1つのスクラムチーム」を前提にしているため、これらのテクニックの採用を見送りました。そもそも担当領域や責任範囲といったアイデアは1チームのときには好まれません。そのうえ事前に疎結合な領域分割を検討しなきゃいけないし、階層構造やチーム間の透明性を下げるリスクが伴います。
全員がプロダクト全体を見渡し、その都度最善手を打ち続けるためには、担当領域や責任範囲といった境界線は高い障壁にもなります。また次の方針とも関係しているため、得意領域に閉じ籠もれないようにしました。
オールラウンダーになり、スペシャリストをつくらない
チームが集められた当初、各メンバーには肩書がありました。例えばデザイナー、アーキテクト、SRE、QE、フロントエンドエンジニア、サーバーサイドエンジニアなどなど。私もUXデザイナーとして召集されていました。
各々が自分の得意分野、スペシャリティがあるのはとても素晴らしいことです。けれども、アジャイルな開発において、いつ、どのリソースがどれぐらい必要なのかは予測できないし、各分野のタスク量は均一ではありません。
したがって、状況によっては暇になるし、緊急性が高いタスクが積まれていても、自分の専門分野でなければ優先度が低いタスクに取り組むことになります。それではチームとしての高いパフォーマンスは発揮できません。
チームが不確実性のある要求に対して、柔軟性のあるリソースとして振る舞うためには、個々人が得意分野を越境してスキルを身に着け、オールラウンダーとして振る舞う必要があります。
透明性を高く保ち、密室をつくらない
透明性はスクラムの三本柱の1つ。個人的には三本柱の中で、最も重要視しているのが透明性。
透明性はスクラムの初歩であり、特効薬でもあります。透明性だけ考えておけば、万事解決すると言っても過言ではないです。あらゆる課題は、透明性の低さから発生します。例えば、以下の5つはよく見受けられるケース。
ヒエラルキーを発生させる。情報格差で優位性をつくる人が出てくる。
手戻りを発生させる。知らないところで仕様が変わってバグの原因に。
ごまかしを発生させる。言いづらいことを隠し通せる。
サイロを発生させる。特定領域は、特定の人しか知らないから任せる。
伝書鳩を発生させる。情報仲介役、橋渡し役といった中間人材が増える。
これらの課題を避けるために、情報共有やコミュニケーションはデフォルトオープンを原則にしました。チャットツールのDM、プライベートチャネルを非推奨とし、できるかぎりオープンなチャネルで会話することに。
シンプルさを保ち、複雑な仕組みはつくらない
最後に、これらの基本方針をどう実践するか。それには覚えやすく、行動に移しやすい、シンプルな仕組みにすることが大事です。多くのルールや複雑な仕組みを制定し、マニュアル文書化し、遵守させるような戦略はNGです。
UXデザイナーとしての経験則からいうと、作業者の認知負荷が高ければ高いほど、ルールは守られず、複雑な仕組みはハックされます。たとえワーキングアグリーメントで合意形成をしても、いざ実践をするときには、ずるをする方向に走ってしまいます。
そしてルールを破り、抜け穴を経験した作業者は、どんどんモラルの閾値が下がります。またこの行為を他のメンバーが認識し、見過ごされれば、伝播していき、チームが崩壊します。
つまり、多くのルールを制定し、複雑な仕組みを導入することは、行動に移されにくいだけでなく、チームを弱くする悪循環を生みます。逆に、シンプルさを保つことで、成功体験を重ねることができ、好循環を作り出せます。
基本方針を浸透させるためには、ルールをつくるのではなく、習慣化させることがポイント。基本方針を体現する行動を1つずつ習慣づけていきます。習慣は無意識にやってしまうものであり、チームのベースラインになります。
スプリントの流れ
スプリントは2週間のタイムボックス。2チームでどうやってスプリントを過ごしていたのかを、イベントごとに共有します。
スプリントプランニング
30min : チーム全体
プロダクトバックログの一番上から、アイテムを各チームに振り分ける
PO, DEVの全員が参加する
90min : チーム個別
各チームでアイテムを詳細に確認して、実装方法や担当者を決める
POは不参加でもよいが、連絡があればすぐ反応できるようにする
スプリントが始まるギリギリまで、プロダクトバックログアイテムをどちらのチームにアサインするかは決めません。そうすることで、全員が全体を意識するようになり、他チームとの協調をしやすくなります。
デイリースクラム
15min + 15min : Team A + Team B
同時並行で行わず、Team A→Team Bと順番に実施する
他チームのデイリースクラムに、オブザーバー参加を推奨する
ファシリテーターは日替わりで交代する
あくまでも大きな1つのスクラムチームとして機能させるために、デイリースクラムは直列つなぎ。全員が全体を意識するために、他チームの状況把握を推奨しています。もちろん忙しければ不参加でも、裏で作業するのもOK。
バックログリファインメント
60min :Team X, TeamY
チーム混合のリファインメント専用チームつくり、同時並行で実施
2つずつに分けて、A1, A2, B1, B2とする
Team X = Team A1 + Team B1
Team Y = Team A2 + Team B2
Team Xは、プロダクトバックログの一番上から見直す
Team Yは、Readyなプロダクトバックログが3スプリント分確保する
チーム間のサイロ化を防ぐために、バックログリファインメントでは混合チームを毎回ランダムに形成。次スプリントのバックログを見直すTeam X、新しくReadyなバックログを生み出すTeam Yと分担をしてリファインメント。
スプリントレビュー
60min : スクラムチームとステークホルダーが参加
POが完成したプロダクトを見せる
フィードバックをもらい、プロダクトバックログを更新する
ビジネスプランやマーケティング、ブランディングの要素も共有する
POがステークホルダーに、スプリントで追加された機能を含めたプロダクトを紹介する。またスクラムチーム以外のセールスやブランディング要素の共有も行い、ビジネスと開発の垣根を低くします。
スプリントレトロスペクティブ
60min : チーム個別
チーム内に関する振り返りをする
チーム全体の要素が出てきた場合は、次のフェーズに持っていく
30min : チーム全体
チーム全体の振り返りをする
Good, Bad, Tryの方式（KPTと同じですね）で、まず各チームで振り返りを行う。チーム全体では、各チームの振り返り内容を軽く共有し、チーム全体としてのTryを検討する。
その他のイベント
なし。他の定期イベントや会議は用意していません。余計なイベントを用意すれば、そのイベントで解決する意識が働き、情報共有や問題解決が滞りやすくなります。
フローが妨げられてしまうことを防ぐため、何か課題が発生すれば、その場ですぐ解決することを推奨しています。
スクラムマスターの活動
SMになったけど、長くやるつもりはありません。みなさんにスクラムを浸透させて、SM不要の2チームスクラムを実現させたら、DEVになります。
SMの最終目標は、自分自身をクビにすること。SM不在でもスクラムチームが自己管理して活動し続けられること。SMがスクラムチームに長居しているのって、スクラムを浸透させられてない証拠だと、個人的に思ってます。
チームに「SMはいなくなる存在」「SMはチームの管理者ではなく指導者」「最終的には、自分たちだけで運営できるようになること」ということを最初に認識してもらいました。
ちょっと補足すると、スクラムチームを離れても、組織にアプローチするフェーズに入るので、本当にSMを引退できるのは先のお話ですけどね。
DEV、POの手本として行動する
SMが率先して、スクラムを体現し、基本方針を実践することが何よりも大事なこと。スクラムが理想論ではなく、実際にできることを示す必要があります。
「何を言うか」ではなく「何をするか」で自分自身そして価値観を示すし、周囲は行動で判断します。たとえ完璧にはなれなくても、向上させる姿勢を示すことで、周囲はついてきてくれます。
逆に言えば、口だけで行動しない人にはついてきません。例えば、スクラムを掲げているけど、透明性がない人。デザインを掲げているけど、資料が読みづらい人。メンバーが見れば「ああ、スクラムやデザインっていうのは建前なのね。頑張らなくていいのね。」となってしまう。
1ヶ月間、DEVとしてバックログを担当したり、POとペアリングでバックログを書いたりと、DEVやPOがどう振る舞うと良いのか行動で示しました。
手本を示し終えたら、見守る
一通り、手本を示し終えたら、次は見守りモードです。メンバーがスクラムを理解し、基本方針を実践できるかをじっくり見守ります。このときSMとして意識したのは次の3つ。
褒める。ひたすら褒める。
良い行動とは何かを、ほめることで示す。
強化すべき習慣を強調する。
できていないことは叱らない。問題が起きた時に一緒に振り返る。
待つ。ぎりぎりまで待つ。
失敗と成長の機会を奪わないように待つ。
基本的には、口出しをしないで見守る。
本当にヤバくなるギリギリまで我慢する。
訊く。客観的に訊く。
答えや指示は出さずに、適切な質問によってチームに働きかける。
チームが客観的に自分たちの状況を把握できる鏡のような存在に。
マネージャー化しないために、自分ではなくチームの視点で訊く。
ここがSMとしての正念場でした。間違った方向に進む予兆があっても、安易に口出しはできない。かといって、大事故だけは防がねばなりません。常にはやる気持ちを抑え、リスク評価をし、失敗と成長の機会を確保しました。
ファシリテーションを委譲する
スクラムイベントのファシリテーションをDEVとPOに委譲していきます。すべてのイベントをSM不在で運営できるようになれば、SMはスクラムチームから離れられます。委譲するイベントの優先順位は次のとおり。
デイリースクラム
レトロスペクティブ
バックログリファインメント
スプリントプランニング
スプリントレビュー
デイリースクラムは、1週間だけSMが担当し、2週目からDEVの交代制に。レトロスペクティブ、バックログリファインメントは2回だけ担当して、DEVに委譲しました。
3ヶ月の経過報告
基本方針とファシリテーションの委譲の観点で、2チームスクラムがどこまで成熟したか共有します。
フラットなチームにし、上下関係や階層構造はつくらない
最初から現在まで、上下関係や階層構造が発生する事象はなく、フラットなチームを維持できている。PO, SM, DEV以外の肩書や代表者だけの会議体を用意しないので、まず仕組みとして防げているように思います。
また複数チームという概念も薄く、大きな1チームとして行動しています。他チームとの協働が多く、チームの独立性や疎結合を求めるよりも、依存関係を受け入れて、チームの垣根を越えて課題解決する姿勢があります。
各役割の振る舞いとしては、POはDEVを使役することなく、実装方法含めDEVの意見を尊重している。DEVはスクラムイベントの運営権を持ち、HowだけでなくWhyやWhatにも意見を出している。SMはマネージャーになることなく、指導者に徹しています。
全員が全体に責任をもち、担当領域や責任範囲をつくらない
お互いのデイリースクラムに参加したり、リファインメントを混合にしたり、バックログをぎりぎりまでチームに割り当てなかったりと、全体を意識せざるを得ない仕組みがうまく効いています。
またバックログを技術レイヤーで分割していないので、自ずと担当領域や責任範囲が広くなるようになっている。スキルが低い人も、周囲が領域を伸ばすのをみて、新しい領域にチャレンジするという伝播が生まれています。
バグが発生しても「犯人探しをして、その人に直してもらう」という事象もなく、見つけた人や手の空いている人が片付ける文化になっています。「すべての課題は個人ではなくチームの課題」が浸透しています。
オールラウンダーになり、スペシャリストをつくらない
スプリント1~3ぐらいまでは、開発生産性を求めず、DEVのスキル向上にフォーカス。少なくともフロントエンドとバックエンドを1人で担当できるように、勉強会やペアリングを中心に過ごしていました。
そもそも各自のスキルに合わせてバックログを用意していないので、バックログに合わせてスキルを改善する必要があります。そのために勉強会やペアリングを依頼することは推奨されていて、POも投資だと判断しています。
また誰かがボトルネックになったとき、次スプリントまでには勉強会やペアリングが行われ、属人化が迅速に排除されています。これを繰り返すことで各々がオールラウンダーに着実に近づいています。
透明性を高く保ち、密室をつくらない
透明性はどのメンバーもあまり慣れておらず、ハードルがありましたが、根強く働きかけることで、2ヶ月ぐらいからクリアになってきました。
まずDMとプライベートチャネルを非推奨にして、会議をチャットツール上のものを利用します。チャットツール上の会議は、その存在と参加者がわかるので、zoomやwebexといったビデオ会議ツールよりも透明性が高いです。
重要な情報はWiki化を推奨し、私はデザイナーとして整理をしました。新規メンバーが1人で情報を探索できるような分類（特にオブジェクト指向なカテゴライズ）をして、階層が深くなりすぎないように促しました。
シンプルさを保ち、複雑な仕組みはつくらない
上記の4つの基本方針を浸透させる方法はシンプルで、複雑な仕組みはつくっていません。そもそもスクラムガイドを遵守することを意識しているので、あつ1つのルールが複数の要素に、影響を与えています。
どう転んでも「フラットなチームにしかならない」「全体を意識せざるをえない」「オールラウンダーになってしまう」「隠し事ができず、透明性が高くなっちゃう」そういうルールだけを残して、他は自由な取り組みにしています。
必ず守るべきものを必要最低限に留めて、それさえあれば大丈夫なようにする。より高度なパフォーマンスを求めるときは、自由に試してもいい。ただしそれは全員に強制するものではなく、個人の意志で自由に取り入れて良いことにしています。ルールは少ないほうが遵守しやすいのです。
スクラムイベントのファシリテーションをDEVとPOに委譲していきます。すべてのイベントをSM不在で運営できるようになれば、SMはスクラムチームから離れられます。
現在、すべてのスクラムイベントはDEV, POだけで運営できています。実際に私がA-CSM研修で5日間留守にしているとき、SM不在でも問題は何も起きませんでした。
どのスクラムイベントでもタイムボックスを超えることはなく、むしろ時間が余ることが多くなってます。その理由は、普段からコミュニケーションを密にとったり、情報の透明性が高いため、認識齟齬が少ないからです。
またデイリースクラムは進捗共有よりもスプリントの再計画に時間を費やして、いかにスプリントバックログを完了させ、仕掛品を少なくするかを考えられています。しかも他チームの状況も加味して、フォローし合っている。
さいごに
2チームスクラムは大きな1チームスクラム
LeSS、Scrum@Scale、Nexus、SAFeなど、スクラムチームをスケーリングする手法はたくさん存在します。けれども、今回は16名からなる”たった2チーム”のスクラムです。
なので、そこまで大げさに考えず、あくまでも大きな1つのスクラムチームとして捉えて、これらのフレームワークを採用せずにスケーリングしました。
今回、スケーリングフレームワークを採用せず、スクラムガイドに書かれている理論を忠実に守ることに徹しました。肩書を増やさず、各イベントのタイムボックスも拡張することなく、シンプルさを維持した結果、十分に自己管理ができるチームになりました。
もちろん3チーム、4チーム、8チームになった場合、この方針が有効なのかはわかりません。個人的な感覚では3チームはまだいける、4チームはギリギリ、8チームはスケーリングフレームワークが必要かなと思います。
少なくとも2チーム、16名でスクラムをするなら、スケーリングフレームワークを採用する理由は見当たりません。厳密に言えば、これらのフレームワークはスクラムの原理原則から外れるので、デメリットのリスクもあります。
私たちにとって2チームの意義は「所属するチームを優先的にフォローしよう」ぐらいで、疎結合にしようとか、依存関係。自チームが安定していれば、他チームを助けるという方針。
2チームスクラムは大きな1チームスクラムの前提で進めることで、スクラムの原理原則から外れることなく、スクラムのメリットを最大限に享受できるようになるので、今後も続けていきたいと思います。
SMとして大事なのは、自ら実践してみせるスタイル
やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。やっている、姿を感謝で見守って、信頼せねば、人は実らず。
私のスクラムマスターとしてのスタイルは、山本五十六との影響を強く受けています。まず実践して見せること、そのあとに後ろで見守ることです。
理想論を語るだけでなく、自らやってみせて、メンバーに価値を実感してもらうのがポイントですね。いろいろなスタイルがあると思いますが、参考になれば幸いです。ではでは。
Appendix
社内の勉強会でこの話をしたときに、こんなことを聞かれましたので共有。
Q. それぞれが肩書を捨ててDEVになることへの反応は？
あまり好意的ではなかったです。誰しも肩書を捨てること不安があるのでしょうがない。私が取った行動は、エンジニアの作業、つまり実装をすることでした。
「僕はデザイナーの肩書を捨てて、機能の実装したよ。」と、まず自分が行動して示しました。誰かに何かを提唱するなら、まず自分自身がそれをやってみせることが大切だと信じています。
Q. 正直デザイナーやりたいの？スクラムマスターやりたいの？
どっちでもない。僕は、プロダクトに忠誠を誓うようにしているから肩書は気にしてない。肩書とか関係なく、プロダクトを成功させるために行動することが正義。
そのときにスクラムマスターの側面が必要ならそれを発揮するし、デザイナーの側面が必要ならそれを発揮する。そして誰もそのスキルを持っていないなら、それを学びに行くだけですね。
参考書籍
本記事は、NSSOL Advent Calendar 2021 Advent Calendar 2021の12/10(金)の担当分です。NSSOLでは、システム開発、データ分析、機械学習、UI/UXデザイン、etc…と幅広い分野の記事を投稿しています。
ぜひ覗いてみてください！
最後まで読んでいただき、ありがとうございました。もらったサポートは次の書籍代にあてます！