スクラムマスターとは？役割と、結果より「プロセス」を見るべき理由

先に結論から書きます。2020年版のスクラムガイドでは、スクラムマスターは「スクラムガイドで定義されたとおりにスクラムを確立すること」と「スクラムチームの有効性」に責任を持つとされています。具体的には、開発者、プロダクトオーナー、そして組織全体を支援する役割です。チームが自己管理できるようにコーチし、進捗を妨げる障害物の除去に働きかけ、スクラムイベントがきちんと開催され、生産的に、タイムボックス内で行われるようにする。逆に、作業を割り振ることや、チームに結果を催促することは、ガイドのどこにも書かれていません。この記事で書きたいのは、その違いの話です。

これまで参加した中で一番ひどかったレトロスペクティブは、どれも同じ形をしていました。スプリントゴールを外した結果、1時間まるごと「なぜ達成できなかったのか」の査問会になるパターンです。逆に一番良かった回は、ゴールの話がほとんど出ませんでした。どう働いたか、何が邪魔だったか、次に何を試すか。その違いこそが「結果に依存しないマインドセット」と呼ばれるものです。自分でもしばらくスプリントを回してきて、これはスクラムマスターにとって一番大事な姿勢だと思うようになりました。

念のため言っておくと、結果はもちろん大事です。立派なプロセスだけあって何もリリースしないチームに給料は出ません。ただ、スプリントを完了させるのはチームの仕事です。スクラムマスターの仕事は、スプリントを生み出す「機械」そのものを改善すること。この2つは別の仕事で、混同したところから、私が見てきたスクラムの機能不全の大半が始まっています。

スクラムマスターとプロジェクトマネージャーの違い

#

この2つの役割はよく混同されます。一人に両方を任せる会社が多いのも一因です。主な違いはこうです。

スクラムには、そもそもプロジェクトマネージャーという役割がありません。プロジェクトマネージャーが普段担う仕事の多くは、何をどの順番で作るかを決めるプロダクトオーナーと、それをどう作るかを計画する開発者に分かれています。

結果への執着を手放すと何が変わるか

#

まず、チームが本当の意味でオーナーシップを持てるようになります。スクラムは自己組織化チームが前提のはずですが、結果に一喜一憂するスクラムマスターは、気づけば意思決定に手を突っ込んでいます。するとチームは「決めるのは自分たちじゃない」とすぐに学習します。プロセスに軸足を置けば、メンバーに実験させ、たまには間違った判断もさせて、そこから学んでもらえます。オーナーシップはそうやってしか育ちません。

レトロスペクティブも正直になります。部屋の問いが「なぜ数字を外したのか」だと、本当の答えは隠れてしまいます。「何が足を引っ張ったか、次は何を試すか」なら、みんな話してくれます。スプリント中の障害への対応も同じです。結果に執着するスクラムマスターは締め切りの心配でパニックになりますが、プロセスに集中している人は、淡々とブロッカーを取り除きにかかります。まだ誰もよくわかっていないことが障害になっているなら、タイムボックスを切ったスパイクを提案します。

ステークホルダーとの関係も落ち着きます。語れるストーリーがバーンダウンチャートだけだと、ちょっとしたブレがすべて失敗に見えます。チームが何を学び、どう適応してきたかも語れるなら、期待値はもっと現実的になりますし、スプリントの途中でチームに降ってくるはずだったプレッシャーの多くを、外で受け止められるようになります。

すでに何かの結果に固執してしまっているなら

#

言うは易し、というのはわかります。特定の結果に深く入れ込んでいるときに「プロセスに集中しよう」と言われても、標語にしか聞こえません。

実際に効いたことをいくつか。まず、結果を気にする自分を責めないこと。何かを望むのは普通のことで、そうでないふりをしても続きません。次に、結果目標を自分でコントロールできるプロセス目標に翻訳すること。「大会で勝つ」ではなく「毎日30分練習する」。リリースがウケるかどうかは制御できませんが、レビューとテストを済ませて早めにデモしたかどうかは制御できます。それから、執着に燃料を与えているものに気づくこと。ダッシュボードや株価を1日に10回リロードしているなら、チェックする時間を決めて、それ以外は見ない。途中の小さな勝利もちゃんと祝ってください。放っておくと、遠くのゴールが注意力を全部食べてしまいます。もし固執のせいで眠れないとか日常生活に支障が出ているなら、専門家に相談する価値があります。恥ずかしいことでは全くありません。

結果は今でも大事です。ただ、結果を安定して出しているチームには、「何を」だけでなく「どうやって」の面倒を見ている人が必ずいました。