久々に書きます。あまりにも自分にとって衝撃だったので、今後同様のことが発生した場合にうまく対応するため、振り返って改善点を洗い出すことを目的として書いています。自身の経験をもとに書いてはいますが、自身の印象・記憶をもとに書かれているものであるため事実と異なる内容が含まれている可能性がありますのでご了承ください。
こんなスクラムマスターからは逃げよう
結論から先に書きますが、以下の項目に複数該当するような自称スクラムマスターからは逃げましょう。おそらく自身の抱えるタスクのための時間は搾取され、不要な責任を背負うことになります。よほどやっていることに意味を見出していない限りは、可能な限り早くに逃げる決断をおすすめいたします。
- チーム状況について観察・理解・課題発見する前に「スクラムをやりたい」と言い出す
- チームにスクラムを導入するにしてはスクラムマスターとしての知見が乏しく、他にサポートできる人もいない
- スクラムマスターとしてやることよりも、スクラムマスターという役割を理由にやらないことを列挙する
- 技術領域において手を動かさない(障害対応時に他の人が手を動かしているのを見てるだけ)
- 改善を目的としてメンバーのやることを増やすが、減らすことを考えない(○○について考える会を定期的にやりましょうなど)
- 提案される改善策に対して「効果が見込めない」と反論されても「とりあえずやってみましょう」と強行する
細かい点を言い出すときりがないので際立った点のみを上げています。詳細についてつらつらと以下に書いていきます。
背景
自身が所属しているチームについてまずは簡単に説明します。とあるプロダクトを開発・運用しているチームで、プロダクトを構成する3つの要素ごとにグループが分けられているようなチームでした(UI, API, インフラなど)。それぞれのグループにだいたい4,5人のメンバーがおり、プロジェクトマネージャーとチームのリーダーがグループ全体を見ているような構成となります。グループ内の人によっては複数のグループをまたいで担当するような人もいます。
ある日、リーダーが交代になると同時にチームの体制を変えるという話が伝えられた。主な変更内容としては以下の4項目。変更の目的は既存の体制の抱える課題を解消することになります。
- プロジェクトマネージャーの責任負担が大きいので、プロジェクトマネージャーをなくす
- コンポーネントごとに分けたことでグループをまたいだ案件の進行について課題がでてきたため、コンポーネントごとに分けていたものをやめて大きな案件をベースに2つのグループに分ける(各グループに各コンポーネントを見れる人がそれぞれ所属する)
- グループごとに開発サイクルに差があり全体の進捗度合いが見えにくいため、全体でスクラムをベースとした共通の開発サイクルを導入し、プロジェクトマネージャーだった人がスクラムマスターを担当する
- みんながすべてのコンポーネントについて理解を深めプロダクト全体を把握できるメンバーを増やす
体制変更については新リーダーとスクラムマスターの相談によって大枠を決め、この宣言のあと1ヶ月ほどの期間で他のメンバーとの話し合いで詳細を詰めていくとのこと。
このチーム自体は5年近く続いている状態ですが、メンバーの入れ替わりが激しく、最初からチームに所属していたのは前リーダーを含めて2, 3人程度。自分もこのチームに所属したのは約1年前で、ひとつのコンポーネントを運用するにあたり人が足りないから来てほしい、グループの状態を立て直して欲しいという助っ人としての参画でした。参画してからは運用を担当するコンポーネントのグループ内でのコミュニケーションがほとんどだったため、他のグループの状態やチーム全体の状態についてはあまり把握できておらず、上記の課題を伝えられても「知らなかった」という感想と、所属グループの状態がようやく安定してきた時期でもあったので「変更が必要なのか？」という疑問が生じていました。
対話期：課題の深堀りで高まる疑念
体制を変えるという話がされたあと、実際に体制を移行するまでに1ヶ月近い時間があったので、その間にスクラムマスターと新リーダーに体制変更前のチームの課題について詳細を聞いてみた。
Q. プロジェクトマネージャーをなくすとのことだが、責任の所在はどこにいく？
A. メンバー全員が平等に責任を持つ
Q. 各コンポーネントを担当しているグループが担当領域についての責任を持っている状態だったはずだが、プロジェクトマネージャーの責任の負担とは具体的になにか？
A. グループをまたいでの認識を合わせたり優先順位付けがグループによって異なったりしていたので、それによって発生する調整が大変だった
Q. 自分が所属していたグループではそのような課題を認識していないが、自分が気づいていないだけ？
A. 主に他の2グループ間で問題が発生していた
Q. プロジェクトマネージャーがやっていたことは誰が引き継ぐのか
A. 都度メンバーの中から担当者を決める
プロジェクトマネージャーの責任負担が大きいということについて確認したところ、自分が所属していない2グループ間の調整が負担(2つ目の課題に相当する)でありこれをなくしたいというのが本質的なところだった。問題の2グループだけをまとめればよかったのではないかと提案をしたがその後検討されず、プロジェクトマネージャーが大変だからやめたいと言っているだけではないかと聞くと返答は得られなかった。また、プロジェクトマネージャーがやっていた作業もメンバーに振られるとのことで、メンバーの負担が上がることが予見された。
Q. 開発サイクルを揃えるとのことだが、揃えないことによって具体的にどう問題なのか
A. スクラムを導入するにあたって開発サイクルを揃えたほうがやりやすい
Q. どうしてスクラムが良いと言えるのか？
A. 1グループがスクラムのような開発サイクルを実施していて良さそうに見えるので全体でやろうと判断した
明らかに手段が目的になっているケースである。自分が所属するグループはスクラムを採用してはいないが、開発サイクルにおいて特に問題などはなく、むしろ成熟してきた時期でもあったため、チームを再編してスクラムを導入するという点についてメリットがあまりなかった。こういった点から、スクラムマスターはチーム全体を見て判断しているというよりも、自身が見ている範囲のみで改善策を提示しており、方法論についても「よさそう」という曖昧な判断基準で決定していると自分には感じられた
「みんながすべてのコンポーネントについて理解を深めプロダクト全体を把握できるメンバーを増やす」については、長期的に考えれば理想な状態なのだろうということは理解できる。しかし自分は他のコンポーネントに対してあまり興味を持てていない、担当コンポーネントもまだまだ深く知るべきことがあり専念したいと考えていたため、他のコンポーネントに対して知るために時間を取られることが億劫であった。これについては自分自身の身勝手な考えなので、チームとしては学びの時間さえ確保できれば特に問題はないと判断していた。メンバーの入れ替わりが激しい状態が合わせて改善されればより効果は高まるだろう。
スクラムを導入するにあたって、書籍などでは「みんなが同じ立場で遠慮なく発言できるような信頼感が大事である」といったことがよく書かれているが、自分はスクラムマスターや新リーダーに対してこの時点ですでに信頼を失いつつあった
混沌期：スクラムマスターとの衝突とチーム不和
疑念は高まりつつも体制変更実施日を迎えた。あまり話したことのないメンバーとやり取りしつつ、約半年間で実施すべきタスクについて各コンポーネントの情報を出し合っていたのだが、ここで問題が生じる。
全体のスケジュール作成と管理を誰がどうやるのか
これまでは、コンポーネント別の各グループごとにやることをリストアップして予定を作成していた。グループごとにまとめ役となる人がおり、自分もその1人だった。体制変更後はそういったまとめ役はどうする想定なのかとスクラムマスターに聞いてみると
「グループ内で決めてください」
都度決めるというのはこういうことかと初めて理解した。普段から話をあまりしていない人同士、かつ隣のコンポーネントについてはこれから理解していくという段階でもあるため、率先してまとめ役になる人もいなければ他の人を推薦するという人もいない。スケジュールに関することに限らず、細かい決め事をするときは常に「誰がどのように決定するのか」という点で足踏みした。このように、スケジュール管理や決定することといったプロジェクトマネージャーが今まで実施してきたことが宙ぶらりんの状態になるのだ。
スクラムマスターに「このような場合はどうすべきか」と訪ねてみると「グループのメンバーが納得行く形でグループ内で決めてください」という返答のみで、スクラムマスターは静観するのみであった。そういうものなのか？と自分でも疑問に思ったのでスクラムに関する記事や書籍を自分でも読んでみたが、自分が見た範囲ではスクラムマスターと合わせてプロジェクトマネージャーのような立場の人がいるケースがほとんどで、重要な決定やメンバーが判断に迷った場合の決定権に責任を持つ立場の人がいた。スクラムマスターにプロジェクトマネージャーを立てたほうが良いのではないかと相談してみたが、「とりあえずプロジェクトマネージャーは無しでやってみましょう」としか返答がなく自分の提案は棄却され、スケジュール管理の面については自分が「このままだとタスクが進まないので一旦自分の方でまとめます」と消極的な理由で立候補して担当することになった。その後も似たような状況に陥ることは何度もあり、これはマズいと思うものは自分が名乗りを上げて作業することになった。結果として、プロジェクトマネージャーがやるような仕事の一部をコンポーネント管理のヘルプとして参画している自分が実施し、時間を取られてしまうこととなった。
スクラムマスターがスクラムについてどの程度事前知識を得てきたかという点で疑問が湧いたため参考にしている書籍など聞いてみたが「これからみんなと学んでいこうと思っています」という返答のみであり、知識を得ること自体積極的に実施していないことがわかった。さすがにそれはどうなのかと他のメンバーも同席しているミーティングで訴えたところ「スクラムについてチームで学ぶ時間をもうけよう」という提案をされた。共通の参考サイトを事前に見てきて、その場でどうスクラムを導入するのかについて相談するとのこと。すでにチームとして走り出してひと月以上経過している状態でこのような提案が出てくること自体どうかしている。チームの今後に大きな不安を抱いた。そして実際にそのミーティングが開催されたが「読んでは見たものの抽象的な内容が多く具体的にチームに落とし込むことが困難ですね」というまとめになってしまい、「今後も定期的にスクラムをチームに導入するにあたって考える会をやりましょう」という判断となった。このときには自分は、チームの体制の話については極力時間を割かないようにし、担当するコンポーネントの改善に務めることを決めており、この定期的なミーティングに対しても「タスクを消化することを優先するため不参加」と伝えていた。しかしこれが逆に、他のメンバーから「チームの体制改善に対して最初は異議を申し立て荒波を立てたが、最近は積極的ではなくただ荒らしただけ」という評価を受けてしまう。
静寂期：表面上はチームが上手く回る
体制変更直後は荒れたものの、やることを決めてしまえば各自が着々とそれらを進めるのみとなったため、チームの体制について話す機会は少なくなった。この段階になって体制変更によってもたらされたメリットがひとつ見えてきた。
複数のコンポーネントをまたいだ大きめの案件を進めていく中で、以前の体制であればコンポーネント間の確認においてかなり時間が経過してから認識違いが発覚するといった問題が発生していたが、体制を変更してからはコンポーネント間の確認をする機会が多くなり、認識違いをかなり早い段階から検知することができていた。体制変更の目的のひとつでもあった課題解消が目に見える形となって現れたのだ。
自分が担当するものと異なる領域のメンバーと接する機会ができて思うようになったのは、この優れたメンバーがいるからこのチームは現状を保っていられるのだということ。細かい決めごとや以前はプロジェクトマネージャーがやっていたことを、自分だけではなくメンバーが分担してやるようになっていったことで、自身の領域のタスクをこなしながら、チームが上手く回るように尽力していた。
メンバーが尽力している中で、スクラムマスターが積極的にチームのために行動を起こしているのかというと、自分が見える範囲では特に仕事をしているようには見えなかった。スクラムマスターに率直にそのことを聞いてみたところ「自分はあまり関与せずチームが成熟するのを静観しようとしている。自律した組織を目指しているので指示などをすると逆効果と考えている」という返答だった。たしかに、メンバー同士で積極性が出てきているようにも見えるが、プロジェクトマネージャーをなくしたことによって宙に浮いているタスクをメンバーの責任感から取りにいっているだけなので、いわばメンバーは尻拭いをしているのだと自分はとらえていた。チーム体制についてこのタイミングで意見してもチームにとってメリットはないと感じたので「そうですか」と返答しただけで話し合いの席から退いた。
再燃期：スクラムマスター動きます
大きめの案件も終盤に差し掛かり、各コンポーネントの開発が佳境となっている中、スクラムマスターが突如動き出した。
「新しくツールを導入してチーム体制について意見交換しやすいようにしたい」
タスクの整理などでホワイトボードにポストイットを使って状況を整理する手段があるのだが、それをリモートでもできるようなウェブツールの導入を提案してきた。メンバー内でも使用したことのある人はおらず、ツールについての理解から始めないといけない。スクラムマスターとしての自分の役割はチーム全体の支援であると自身で語っていながら、開発が佳境となっているこのタイミングでその提案はチームにとってマイナスではないかと呆れて、「今は何もしてくれるな」とメッセージを投げていた。
これも自分の意見は聞き入れてもらえることはなく、ツールを導入しての相談が実施されたものの、数回行われただけでツールの継続利用は見送りとなった。さすがにこの提案には他のメンバーからも不評だったようだ。自分はその会議には参加していないので、どのような話し合いが実際されたのかは知らない。加えて、スクラムマスターが主に主催する会議では議事録をまともにとっていない状態なので、過去のやり取りがどこまで残されているかも定かではなく、今後同じようなやり取りのための無駄な会議が開かれることもリスクとして存在している。
案件の終盤では部長などの偉い人たちに対して、この案件がこういう形で終わりますので承認してくださいという会議が開かれる。承認が得られなければ指摘された内容に合わせて修正する必要があるため、スケジュールが変更になるという重要な会議。この会議の資料を作成するというタスクがあったのだが、これも今までプロジェクトマネージャーが実施していたので宙に浮いた。過去に同様のタスクを実施した経験があるのは元プロジェクトマネージャーのスクラムマスターのみだったため、スクラムマスターに「みんな開発で大変な状態で他に人もいないので担当できないか」と依頼したが「スクラムマスターの役割ではないのでやらない」という返答だった。せめて雛形だけでも過去のものを参考に用意できないかとこちらから譲歩してみたものの、これに対してもやらないの一点張り。やってもらうために言葉を尽くすことも億劫だったため、しかたなく自分が資料を用意することにした。
スクラムマスターの「自分はやりません」という主張はこれだけに限ったものではなく、技術領域における重要な判断や、グループ内で決まらなかったことの決定など、とにかく本人が思うスクラムマスターの役割ではないものは徹底して手を動かさなかった。
終わりに
いきなり終わりになってしまい戸惑うかもしれないが、まだ自分はこのチームから脱出できておらず、日々スクラムマスターからの悪影響をどのようにしてかわすかということを考えさせられている。当然、チームから抜けることも考えてすでに行動に出てはいるものの、まだしばらく時間が必要といった状態です。それでも3ヶ月以内にはなにがなんでも脱出しておきたい。そうでなければ精神的にやんでしまいそうなので。
スクラムというものについて、おそらく言葉を知っている人の数だけ理解のしかたがあるというほど抽象的なものだと思っている。自分はスクラムというのは「導入するぞ！」と積極的に取り組むものというよりも、2週間程度の開発サイクルを軸として、チームとして繰り返しタスクの洗い出しと担当ぎめ、実施した内容の確認、予定と実績を評価して予定の見直し、振り返りといったことが実施できる状態になっていれば、結果的にスクラムっぽくなっているという考え方でいます。こういった価値観の違いからそもそもこのスクラムマスターに対して批判的であったのではないかと言われると否定はできない。ただ、スクラムマスターを自称する人のアクションについては注意深く見たほうが良いとは思う。その人がどのようにチームを評価し、どういったチームにしたいのかということを事前にしっかりと理解することがうまくやるには必要だ。自分はこの事前の相談が十分に実施できなかったことにより、案件を進ませながら相談するといった時間的にも精神的にも余裕が持てない状況が生まれていた。
ここまで読んでいただきありがとうございます。かなり勢いに任せて書いたものであるため、理解に苦しむ内容も含まれていると思いますが軽く読み流しちゃってください。不要なチームの不和など、自分のコミュニケーション能力の乏しさによって招いた問題というのもあるので、今回の経験をもとに自身の改善に努めたいと思うばかりです。しかしながら、人の考え方を変えるということは非常に困難なので、自分の取れる手段の中で「逃げる」ということもきちんと選択できるように余裕を持った状態にしておきたい。
