スクラムマスター、「組織を芯からアジャイルにする」ことを暗黙的に求められがち問題

[viviONアドベントカレンダー](https://qiita.com/advent-calendar/2023/vivion)15日目の記事になります。

# お前だれ

こんにちは、viviON開発部基盤ユニットのakkt222です。viviONではGoしか書いていないのですが、Ruby畑の出身です。
こんな記事を書いているのでいかにもスクラムマスターをやっていそうですが、viviONではスクラムマスターはやっておらず、開発者としてマイクロサービスの開発を行なっています。
自分のチームはスクラムで開発していますが、別の方がスクラムマスターをやっていらっしゃいます。
ですので、あくまでviviON入社前の過去のスクラムマスターとしての経験や、同様にスクラムマスターを経験された（されている）方と話して考えたことを基に思考のアウトプットをする形となります。

# TL;DR
スクラムマスターには、稀に組織全体の意思決定や実行のプロセスを根本から変えるという、いち社員には荷が重すぎる責務が（暗黙的に）与えられることがありますが、この問題に対する銀の銃弾[^1]は無さそうです。
この問題について提唱し、銀の銃弾が無いなりにどうしたら良いのか考えるのがこの記事の趣旨になります。

# 理想のスクラムを想像してみる
まず、現実[^2]とのギャップを埋めるため、理想のスクラムというものを想像してみようと思います。

言ってしまえば、スクラムガイドに記されていることが全て出来ていればそれが理想ということになるかと思いますが、あえて具体的な特徴を挙げてみます。

- ベロシティが安定しているし、何なら向上しがち
- レトロでKPTが湯水のように湧いてきて、毎回有用な改善が生み出されがち
  - それによってチームが良くなっていることを誰もが実感でき、各々が高い自己効力感を持っていてポジティブなサイクルが回っている
- アジリティが極めて高い
  - プランニングで積んだアイテムは基本的に全て消化される
  - もしくはスプリントゴールが明確に設定されている上、やることをスプリント内で適宜選択して有意義なインクリメントを生み出し続けることが出来ている
- 自己組織化が進んでおり、何ならスクラムマスターが居なくてもやっていけそう

こんなところでしょうか。これらが当たり前のように出来ていれば何の問題もないのですが、あくまで私の個人的な主観として、この領域にまで到達しているスクラムチームは極々少数だと感じています。

# 何故出来ないのか

出来ない以前に、そもそもそこまで熱心にスクラムに取り組んでいないケースも多々あるかと思いますが、あり得るケースをいくつか挙げてみます。なお、**スクラムマスターを含むチームメンバーの練度や能力は考慮しないものとします。**[^3]

### メンバーがスクラムに価値を感じていない
スクラムを作業練度の低いメンバーのタスク進行をサポートする仕組みだと考えている場合、スクラムがその本来の力を発揮することは難しいと思います。
少数の、極めて練度とモチベーションの高いメンバーのみで構成されたチームであればスクラムやその他の開発手法を何も使わなくてもワークするかもしれませんが、それではスケーラビリティには問題がありそうです。[^4]

### 作っているプロダクトがスクラムに向いていない
以下のような理由で、そもそもプロダクトがスクラムのスウィートスポットではない可能性もあります
- ステークホルダーが多すぎる
- 要件が固まりすぎている
- PMFが全然見えていないなど、スクラムとか言っている場合ではない何らかの差し迫った状況がある

逆に、いわゆるSaaSの開発などの場合、マーケットを高速に理解して適合する必要があるのでスクラムとの相性が良いという話はよく聞きます。

### チームがバックログ消化マシーンになっている
自己組織化が出来て居なければただ単に降りてきた要件のコードを書くだけになってしまい、スクラム本来の力は発揮しづらいです。
また、チーム自体にポテンシャルがあっても、社内の別の部署や、更には顧客や投資家などと開発ロードマップを握ってしまっているが故に融通が効かないということも考えられます。

いずれの場合にも、スクラムマスターの側からすると
- チームの自己組織化
- スクラムの価値の最大化

に対して、大きなブロッカーがあるということになります。
ブロッカーがチーム内にある場合はまだ良いものの、チーム外にある場合、いち社員に出来ることには現実的な限界があるため、苦しい気持ちになると思います。
これが掲題の**スクラムマスター、「組織を芯からアジャイルにする」ことを暗黙的に求められがち問題**です。スクラムチームの自己組織化だけではなく、組織全体のマインドセットややり方を変えることが求められてしまっています。
そして、そのような重責をスクラムマスターに課してしまっていることに誰も気がついていないこともあり得ます。場合によってはスクラムマスター本人ですら違和感を言語化出来ていないかもしれません。

また、スクラムガイドが教条的なガイドラインなので、あまりワークしないと「自分のやっているのはなんちゃってスクラムだ」と自責の念に駆られることもあるかと思います。少なくとも自分はその袋小路に迷い込んでしまい、勝手に追い詰められてしまったことがあります。

# どうすれば良いのか
このような状況において、スクラムマスターとしてどのようなアプローチを取っていけば良いのでしょうか。それぞれのチームで状況は違うはずなのでバシっとした回答は出来ないですし、そもそも銀の銃弾の無い問題だと思ってはいるのですが、「こうすれば良いのでは（良かったのでは）」という自分なりの解釈を書いてみようと思います。

前提として、この問題の難しいところなのですが、一見有効に見える**そもそも組織を変えるくらいの権限がある人がスクラムマスターをやる**もしくは**自分自身が出世して組織を変える**は別の問題を引き起こすと考えています。スクラムマスターがえらい人だと、その人が今スクラムマスターの帽子をかぶっているのかえらい人の帽子をかぶっているのかがメンバーには分からない問題です。一般に、メンバーはえらい人の発話を命令として解釈するため、チームの自己組織化が阻害されます。[^5]

自分のアイデアは、他人を変える系のアプローチと自分を変える系のアプローチに大別されます。
チームと対話することに関してはスクラムマスターとして当たり前なので今回は言及しません。

## 他人を変える系
### アウトプットを発信し続ける
スクラムチーム内での取り組みや、スクラムの考え方をチームの外に向けて発信し続けることで組織全体にスクラムを浸透させるアプローチです。スクラムマスターというのは一種のアクティビストなので、これは突飛なアイデアではないはずです。
社外に向けて発信するのも素晴らしいことですが、社内政治に外圧を使うのは逆効果になる可能性もあるので、社内に対して継続して発信するのが良いと思います。
フォーマットはNotion等でも良いですが、文章よりも視覚的に理解出来るスライドを作る方が効果がありそうです（まずはスクラムに興味を持ってもらう必要があるのですが、人は興味のないことが書かれた長い文章をそもそも読みません）。発表の場があるのであればその場を活用するのも良いと思います。
発信の頻度としては月に一度、もしくは隔月に一度が良いと思います。それ以上だと多すぎるし、四半期に一度程度だと印象に残りません。
大事なのはポジティブな方法で味方を増やしたり、スクラムについて興味を持ってもらうことなので、適切にトーンを調整しましょう。

### エレベーターピッチに備える
上記の方法と近いですが、より飛び道具的なアプローチです。ブロッカーがチーム外にあることをえらい人に伝えるチャンスがやってくることがあります。その時が来たら端的な言葉でえらい人に興味を持ってもらえるように、エレベーターピッチが出来るようになっておきます。
そのために普段から言葉をしっかり磨いておきましょう。

## 自分を変える系
### ある程度諦める
特に専任のスクラムマスターではなく、他のロールとの兼任である場合はある程度諦めるというのはひとつの手だと思います。諦めると表現すると聞こえが悪いですが、戦略的撤退です。
具体的には、チームの外部に働きかけることにエネルギーを使うのはやめてちゃんとチームに向き合うことに集中しようという提案になります。
このアプローチではチーム外から割り当てられるロードマップやノルマは仕方ないものとして受け入れます。その上で自分たちで可能な改善サイクルを地道に回していくのも、別に間違っているわけではないはずです。


### 長大な夢を持つ
目標の達成それ自体よりもそこに向かおうとする意志や足元のプロセスと向き合うことを大事にするモードに切り替えるアプローチです。
ジョジョの奇妙な冒険を読まれたことのない方には全く分からない比喩だと思うのですが、「真実に向かおうとする意志」を忘れないことは重要です。
一世一代で組織を芯からアジャイルにすることは出来ないかもしれませんが、あなたがひたむきに取り組めばその意志を継いでくれる人はきっと居ます。[^6]


# 終わりに
開発者と違って、スクラムマスターは本質的に一人では絶対に成立しないロールです。開発者としてハックを試みたくなる気持ちはよく分かりますし、正直自分もそっちに引っ張られがちなのですが、何より大事なのはサーヴァントリーダーシップを体現し続けることです。それが出来なければ元も子もありませんから、原点を忘れずに着実にやっていきましょう。

# 参考文献
[組織を芯からアジャイルにする](https://amzn.asia/d/6HcsyPT)
[スクラムガイド](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf)
[Q. スクラムチーム内にマネージャー（評価者）がいてもいいですか](https://www.ryuzee.com/faq/0099/) ほか、Ryuzeeさんの記事全般
[ジョジョの奇妙な冒険 59 (ジャンプコミックス)](https://amzn.asia/d/bAnU3bc)

[^1]: 不正確な意味で使いますが、ニュアンスは伝わると思っています
[^2]: ここで言う現実とは、スクラムで陥りがちな罠の全てに引っかかっている仮想のスクラムチームが置かれている状況を指します
[^3]: メンバーの練度・能力はスクラムが上手くいかない場合の最大の問題であり、自分もスクラムマスター、または開発者として反省することしか無いのですが、この記事で扱いたいトピックはそれとは質的に異なると理解しています
[^4]: そもそもチームが10人以上になることをスクラムでは想定していないのはありつつ
[^5]: えらい人だとしても評価者で無ければ問題ないという考え方もあります
[^6]: 当然与えられた責務を投げ出さずに全うすることの方が常に望ましいですし個人的にもそうありたいと思っています

# いつもの
https://hrmos.co/pages/vivion/jobs/0000226