こんにちは。kintone開発チームでスクラムマスターをしている「とうま」（@toma_cy）です。
サイボウズでは、スクラムマスターの役割や日々の業務をより多くの方々に知ってもらうために、リレーブログ企画を開催しています。 本記事では、スクラムはあくまで手段でありスクラムマスターは価値に向き合うことが大事だという話をします。
スクラムマスターに求められること
スクラムガイドでは、スクラムマスターについて以下のように定義されています。
スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。
「スクラムを確立」とはどういうことでしょうか？
スクラムガイドに書かれているものを絶対として厳守せよと読み取る方もいるかもしれません。 ただ、個人的には「スクラム（が大事にしている価値）を確立」することが重要であると考えます。
つまりスクラムを厳守する必要はなく、より良い手法があるならそれを採用すべきです。
スクラムの目的化
突然ですが、scrum slave（スクラムの奴隷）という言葉をご存知でしょうか。
スクラムガイドに書かれていることだけを見て、忠実に守ることだけに躍起になっている状態のことを示した言葉です。
近くにいるスクラムマスターが忠実にスクラムを遂行することに躍起になっていたとしたらscrum slaveの状態に陥っているのかもしれません。
その状態を言い換えるならば、スクラムをやることを目的としていると言えます。 そうなるとメンバーから見たスクラムマスターの印象は「ただスクラムをやりたいだけの人」となります。
スクラムで開発することですべての問題が解決できるのであればそれで良いですが、そんなことはありえません。 そもそもスクラムは不完全なものであり、足りない部分は補っていく必要があります。
そのためには、スクラムを守ることに終始せず、チームが目指すべき理想へ支援やチームの課題に向き合うなど、チームに寄り添った活動が重要です。
事例紹介
スクラムは万能ではないため、スクラムが適していない場合もあります。 スクラムマスターとしては、頑なにスクラムを守るのではなく、チームやその他の状況を鑑みてスクラムをやめることを検討することもあります。
実際、私が所属しているチームでは一時的にスクラムをやめていた時期があるのですが、その事例を紹介します。
スクラムをやめた事例
私達のチームの進め方としては、比較的教科書通りのスクラムを回していました。
しかし、ある時期にプロダクト開発を一時的に止めてでも、様々なプロジェクトを進める必要性が出てきました。 プロジェクトを進めるに当たって、意図せずチームのやり方がスクラムの型から外れるようになってきました。
私は徐々に崩れていくスクラムを横目に見ながら、それを守るべきかそのままやめるか悩んでいました。 その中で、チームの動きを見ている中で、スクラムを一時的にやめても良いだろうという考えに至りました。
元々LeSS（Large-Scale Scrum）を適用して他チームと1週間スプリントで同期していました。 しかし、チームの動き方としては1週間よりも短いスパンかつ必要になった都度ステークホルダーとやり取りを行っていました。
そういった流動的な動きが求められるような状況、さらには仮説検証をメインに行うような複雑性が高いものは、 スクラムなどの一定の型にはめないほうが柔軟性が増し、臨機応変に対応したほうが効果的であると判断しました。
結果的にチームとしては刻一刻と変わる状況に対応することができたように思います。 スクラムを継続していたならば、目まぐるしく変わる状況の中でスクラムイベントが重くなりすぎてしまい、素早い対応ができなくうまくいかなかったかもしれません。
スクラムをやめる際に重要なことは、まずスクラムの原理原則や狙いを理解しておくことです。 スクラムをやめる、もしくはその型から外れる場合、スクラムが本来目指している狙いが得られない可能性があることを念頭に置くべきです。
その上で、意図的に別の方法を選択するので良いと思います。 しかし、十分に理解せずにやめてしまうと、気づかないうちに悪い結果を招く可能性があります。
その後のスクラムマスターの役割
スクラムをやめたのであればスクラムマスターは不要なのでは？と思われた方もいるかもしれませんが、そんなことはありません。
スクラムマスターは、スクラムやアジャイルに関する知識や経験、リーダーシップ、ファシリテーションなどを活用してチームを支援することができます。
チームの理想像の共通認識を揃える
実際に私が支援した内容例を挙げると、チームとしての理想を考える場を用意しました。
この会は、理想のチームとはどういうものかを挙げてもらい、現実とのギャップを認識しアクションを出すという会です。
そのような会を開いたきっかけは、各人それぞれがプロジェクトを進めていたという背景もあり、チームとしての一体感が失われつつあったからです。
プロジェクトは一時的なものであり、終わりがあります。その後は、プロダクト的にチームで進める必要性がでてきます。
あらかじめ理想のチームというものを認識してもらうことで、チーム活動の再開をスムーズにできるようにする狙いがありました。 （もちろん理想のチームを考えることで、それに近づけていく効果を狙ってのものでもあります）
透明性の低下への対応
スクラムには「透明性」、「検査」、「適応」の三本柱があります。 うまくスクラムで開発することで透明性が担保され、検査、適応へとつながっていきます。
しかしスクラムをやめてしまうと、やり方次第では途端に透明性が失われてしまい改善へと繋がらなくなってしまいます。
例えばチーム外によるマネージャーからすると、そのチームが何をやっているのか途端に見えにくくなってしまいます。 場合によっては、別途進捗報告を求めたくなるかもしれませんが、それはあまり良い傾向とは言えません。
スクラムマスターとしては、スクラムをやっていないチームであったとしてもチームの透明性を担保するような努力が求められます。 例えば振り返りや1 on 1などで内省する場をつくり、透明性を向上させるような改善につなげる必要があるかもしれません。
スクラムイベントがないと、なかなかスクラムマスターとしても、観察や介入の仕方が難しい面があると思います。 振り返りや 1 on 1 などの場を用意すれば、チームを支援しつつチームを支援する材料を得るための効果的なプラクティスになると思います。
スクラムマスターって何をするの？に対する私なりの答え
"スクラムマスター"はスクラムと付いているので、どうしてもスクラムを推進するようなイメージもあります。しかし、スクラムはあくまで手段です。
私が考えるスクラムマスターは「価値に向き合い続ける人」なのではないかなと思います。
価値に向き合い続ける人である以上、方法論は二の次。
スクラムではない方法が適しているのであれば、それを推進すべきです。 とはいえスクラムマスターである以上、スクラムに熟達し、スクラムを活用しながらチームを支援するというのに間違いはありません。
スクラムに限らず、忙しい日々に追われていると方法が目的化してしまうのはよくあることです。
本当に大事なものは何なのか。 それを常に考えながら活動していくことが大切です。