「スクラムに詳しい開発メンバー」ではスクラムマスターは務まらない
書いた人
- スクラムに詳しい開発メンバーから専任スクラムマスターになった人
- コンサル向けの本が嫌い。今でも好きじゃない
スクラムに詳しい開発メンバーとはなにか
私のイメージしている開発メンバー像はこちらです。
- スクラムに関しての知識はある
- スクラムの勉強会によく出ているクラスからエッセンシャルスクラムやスクラムマスターThe Bookを読破した本格派まで想定
- 認定スクラムマスターの資格持ちも含む
- マネージャー経験はない
- 開発者としての経験はある
- 年単位の経験がありコードは普通に書ける
ここでいうスクラムマスターとは何なのか
- 専任（開発者との兼任ではない）
- 1人目のスクラムマスター
務まらないスクラムマスターを雇うとどうなるのか
中途半端なスクラムが定着してしまいます。
中途半端なスクラムは無駄に会議が多くリソース効率が悪い（さらにフロー効率がいいわけでもない）割に、恩恵を得ていると言う実感が得られません。
締切前の爆発力もないので、外から見ればダラダラ開発しているように見えるでしょう。
短期的には半年〜1年程度で「スクラムを始めたはずだがスクラムの恩恵が得られない」という話になります。多くの組織では「恩恵を得るためにスクラムをカスタムしてより効率のいい開発にしよう」と言う結論になるでしょう。
スクラムに詳しいメンバーの何が問題なのか
スクラムに詳しい開発メンバーがなにか分かったところで、なぜスクラムマスターは務まらないのかを説明していきます。
開発者としてキャリアを積んできた人間がスクラムマスターをやると主に3つの問題が出ると考えています。
EM的な動きができない
1つはEM的な動きができない点です。
スクラムマスターにはEM的な動きが求められます。
つまり思っていることと口に出していることが違うことも当然あるわけです。
EM的な動きができるスクラムマスターならチームのTRYを見てこう思うわけです。
「この試みはスジが悪い。おそらく問題をある程度把握できているがアプローチすべき対象を見誤っている。この問題に気づかせるために一度TRYを失敗させ、それをチームに自覚させてみよう」
あるいはしれっとスプリントレトロスペクティブでこう動くわけです。
「今日のふりかえりはxxという話題を中心に話してみましょう」
そして出てきた付箋を見てこう言うわけです。
「発見した課題に対して解決した課題のレートが増えてきているのはいい傾向ですね。ところでxxという課題が発見されたのに解決されていないまま多く残っていますね。TRYを考える前にここを深掘ってみませんか？」
課題を発見するのもチーム、課題を明確化するのもチーム、解決策を考えるのもチーム。
それをスクラムマスターはしれっと誘導するわけです。
チームの内外で見せる顔が違うこともしばしばよくあることです。
チームのふりかえりでは「みなさん今週のふせん見てください。確実に我々は前進していますね！」とニコニコ顔で言うのに、1時間後のマネージャー会議では「チームの成長、このペースだとだいぶキッツいですねぇ。要求する目標が高すぎました。もう少し長い目で考えてみますか」と眉間に皺を寄せて言ったりします。
HOWから考え始めてしまう
もう1つはソリューションをHOWから考え始めてしまう点です。
そんな未熟なスクラムマスターがよく言う言葉はこれです。
「xxできていないことが問題だ。なぜならばxxの目的であるxxが機能していないからだ。解決策はxxを始めることだ」
問題を構造化して把握できていないこと、また開発者の経験からHOWに固執しHOWから問題を考え始めてしまうわけです。
経験を積んだスクラムマスターは問題を構造化することで、正しく問題を把握しようとします。そうすることで問題に対してソリューションが有効打を与える打率と得点率をあげようとします。
自分でやるのか、他人に任せるのか
最後の問題は半端に自分でやってしまう点です。
スクラムマスターはチームの気づきを促すべきです。
しかし何でもかんでもチームにやらせようとすべきではありません。
つまり問題に対して「チームに解決策を実行させること」と「自分で解決策を実行すること」があるわけです。
経験未熟なスクラムマスターはこれらを取り違えがちで、ともすれば「俺は正解を知っている。俺の言う通りにお前らがやれ」とやりがちです。
これはアンチパターンだと私は考えます。
スクラムマスター経験者は何ができればいいのか
- 担当範囲は名前のない仕事
- 名前があるならそれは仕事の正体と問題がわかっているわけで、スクラムマスターの仕事でなくてもいい
- 名前のない問題に名前をつけて解決する
- 構造的に問題を把握し、問題を脅威度や重要度ごとに並べる
- 問題にあった解決策を考え、解決策に対して適切な方法で実行する
- チームの問題を構造化して把握し、優先順位をつけ、どの順番で解決すべきかを決定できる
- プロダクトバックログのような形でチームの問題を扱っていきます
- ここでイメージされているスクラムマスターは専任なので、自分自身のコストに対するリターンを役員級以上に対して説明する説明責任も持ちます
- スクラムマスターとは組織の運営に関するプロダクトオーナーとしての動きも必要になります
- スクラムチームに対して気づきを促し、ときには助言を与える
- スクラムチームに対してコーチングやティーチングを行うこともスクラムマスターの仕事です
ではコンサル出身者を連れてくればいいのか
コンサルはたしかに問題を構造化して解決することが得意ですし、チームの内外で見せる顔も違います。EM的に動くこともできそうです。
ですが適任ではないと思います。
スクラムマスターに必要なことは現場チームの観察です。
観察した上で変化を促す、助言や気づきを与えることがスクラムマスターには必要ですが、コンサル出身者なら誰でもできる、というわけではありません。
またコンサル出身者なら問題を構造的に捉えた上でロジカルに解決策を立案する、という行為はできるでしょうが、開発チームに密着して問題を正しく理解するには開発チームの知識と経験が必要です。
それは「開発スケジュールの管理」より目が細かい経験が必要でしょう。
その経験を持つコンサル出身者は稀です。
ではスクラムマスター経験者を雇えばいいのか
それがベストです。
しかし相当難易度が高いでしょう。
転職市場にいるスクラムマスター経験者は確かにいます。
しかし経験者と言いつつ上記のスキルがない人間も多いです。
これはスクラムマスターの仕事が定義しづらいものである点も影響しています。
また1人目のスクラムマスターはそれ自体が特別なポストです。
「1人目のスクラムマスター」と「2人目以降のスクラムマスター」はCTOとEMくらい違います。
1人目のスクラムマスターとなると役員級の能力が必要になるケースもあります。
なぜならスクラムマスターが問題をいくつも取り扱う時、問題を抽象化していくといずれかは組織の問題に必ず辿り着きます。
このとき組織の問題を扱うには役員級の権限が必要であり、その権限を任せるに足る能力がないと不満を抱えて辞めるか、機能不全を起こすかという結果になりがちです。
1人目のスクラムマスターとしてどう言う人間を雇えばいいのか
本気でスクラムをやりたいとき、1人目のスクラムマスターとしてメンバー級を雇おうという発想が誤りだと私は考えています。
1人目のスクラムマスターは組織を大きく作り変える権限を与え、その仕事をやり切ってもらわないと会社は十分に機能するスクラムは得られません。
半端なスキルしかないスクラムマスターを雇って半端な恩恵を得る程度で満足できるならそれもいいでしょうが、恩恵についての期待値を見誤ると多くの人にとって不幸な結果になるでしょう。
Discussion