【参加メモ】スクラムガイドを読み解いてみよう #5 Page.7 スクラムマスター～
なぜスクラムガイドを読むのか？
アジャイルのフレームワークの中で、最も利用されているスクラム。
全世界共通のスクラムの手本である「スクラムガイド」を、皆さんはしっかり読んだことはあるでしょうか。
一度読んでみた人でも、きっと、読み直すことで色々な発見があるはずです。
先日このようなオンラインイベントに参加しました。
恥ずかしながら「スクラムガイド」をこのイベント告知があるまでろくに読んでおらず、「これはきちんと読まねばならぬ」と突然思いたち「ブログ書くよ枠」で参加した次第です。
半分書いて「1週間くらい寝かしておこう」と思いつつ2週間が経過してしまいました。が、次イベントのギリギリ前なのでセーフですね！w （私基準）
はじめに、どういう知識レベルのヤツがこの記事を書いているのかQAエンジニアである私のスクラム（アジャイル）との関わりを簡単にご紹介しますと
●2013年当時いた現場にスクラムが導入され、初めてスクラムを知る
●2015年に開催されたAgile Japanの基調講演が『実践アジャイルテスト』共著者であるJanet Gregory氏であることを知り、「これはぜひとも聴かねばならぬ」と思い、参加
●2016年のAgile Japanではたまたま公認レポーターをつとめる
自動車も飛行機もワインも！「スクラムで世界を変えよう」：Agile Japan 2016 レポート(7)
「初めてのアジャイル×リモートアジャイル」で生まれたもの：Agile Japan 2016 レポート(10)
●ISTQB 「Foundation Level Extension シラバス アジャイルテスト担当者」翻訳ワーキンググループ参加
●スクラム開発を導入している現場経験はトータルで約3年半
…こんな感じです。（なお、学び始めの参考書籍は『SCRUM BOOT CAMP THE BOOK』でした！ 最近増補改訂版が出ましたね）
スクラムの中ではQAエンジニアは「ステークホルダー」と定義されていると思いますが、スクラムチームとの関わり方はいつも試行錯誤しながら現場に合う形を探ってきました。今の現場もスクラムは採用しておりませんが、根っこにある思想、立ち戻るべき原点についてはアジャイルソフトウェア開発宣言やスクラムのプラクティスを参照した方が良いと思っていて、勉強を続けています。
私がスクラムに関わり始めた当初はネットを探しても「スクラムの中のQAとしてのふるまい」にヒントになるような記事がなかなかなく、苦労したので同じような立場のみなさんのお役にたてれば幸いです。（現在は飛躍的に情報量が増えましたが…）
…前置きが長くなりました。
このような思いで他の現場の意見を聞く機会があればなるべく参加するようにしています。QAエンジニアもスクラムマスターの気持ちわかる必要あるしね。
スクラムマスターたちと「スクラムマスター」を読む！
今回イベントではスクラムガイドの「スクラムチーム」章における「スクラムマスター」（P7）が対象でした。
スクラムガイド引用①：
スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。スクラムマスターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援することで、その責任を果たす。
まず、「スクラムマスターの役割とは何か？」というテーマです。
その中で次のようにおっしゃっていました。※以降、カギ括弧内はイベント登壇者のセリフです。
「チームを存続させるためのコストをちゃんととれるかどうか（チームによっては、直接利益のでないものをつくる場合がある）」
「説明責任をPOが果たせるようにチームとかスクラムマスターが支援する」
「ちゃんと価値に向かうことが大事」
ここで参加者から質問がありました。
Q.「POと開発チームは対等であるべきと考えますがいかがですか？ 正解を持っちゃってる声の強い人がPOだと、チームが弱くなってスクラムから遠ざかってしまった経験があります」
なるほど、私の実際のスクラム経験ではむしろPOが弱い方が多かったのですが、どちらかの声が強過ぎるとうまくいかなそうだというのはわかります。回答は
A.「POもスクラムマスターも対等」
というものでした。バランス感覚が重要ですね。
「サーバントリーダー消えてくれないかな？」
スクラムガイド引用②：
スクラムマスターは、スクラムチームのサーバントリーダーである(訳注:メンバーが成果を上げるために支援や奉仕をするリーダーのこと)。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと/立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。
ここで、
「サーバントリーダーがちょっとひっかかっている（「サーバンドリーダー」は最近追加された）」
というお話がありました。
「マネジメント3.0ではサーバントリーダーはもうダメだと言っている」
「1.0は産業革命後のトップダウン。
2.0はマネージャが少し配慮はじめる。ここでサーバントリーダーって言葉をつかっていたはず、自信ないけど」
「サーバントリーダーシップって、サーバントリーダーがいちゃう。
その時点でダメ」
…ほうほう。「マネジメント3.0」についてはリンクをはった先に説明があるのでここでは引用を省きますが、私は「組織そのものが有機的に目的が達成できる状態（をつくるひと？）」という解釈をしています。「サーバントリーダーはもうダメ」ということは、ここの「〜（をつくるひと？）」がサーバントリーダーにあたるのかな、これがマネジメント3.0では否定されているということでしょうか。
「サーバントリーダーシップ」とは何か、については、このあたりを参照することにしましょう。
マネジメント3.0ではサーバントリーダーという存在は求めておらず、もっと組織全体としてマネジメントできている状態、という風になるでしょうか。難しいな。
「スクラムのスクラムマスターはロールだからひとに依存している？」
「仕組みを構築し、ファシリテートしていく。
朝会とかいつまでもスクラムマスターが仕切ってたらかっこ悪い。
仕組みつくったらチームにまかせていつのまにかドロンする」
確かに。スクラムマスターのスクラムチームへの関わりは深くなり過ぎるとダメな感じがします。
「”サーバントリーダー”は次のバージョンで消えてくれないかな」
お、おぅ。
現在のスクラムガイドは2017年版なので、改訂があるとすれば次のマネジメント論に変わるのかもしれませんね。
「スクラムマスターのやることが増えている」
続いて、「スクラムマスターはプロダクトオーナーを支援する」の項にはいります。
スクラムガイド引用②：
スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。
• スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるようにする。
• 効果的なプロダクトバックログの管理方法を探す。
• 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
• 経験主義におけるプロダクトプランニングについて理解する。
• 価値を最大化するためのプロダクトバックログの調整方法をプロダクトオーナーに把握してもらう。
• アジャイルを理解・実践している。
• 必要に応じてスクラムイベントをファシリテートする。
スクラムガイド引用③：
スクラムマスターは、さまざまな形で開発チームを支援する。
• 自己組織化・機能横断的な開発チームをコーチする。
• 開発チームが価値の高いプロダクトを作れるように支援する。
• 開発チームの進捗を妨げるものを排除する。
• 必要に応じてスクラムイベントをファシリテートする。
• スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。
スクラムガイド引用④：
スクラムマスターは、さまざまな形で組織を支援する。
• 組織へのスクラムの導入を指導・コーチする。
• 組織へのスクラムの導入方法を計画する。
• スクラムや経験的プロダクト開発を社員やステークホルダーに理解・実施してもらう。
• スクラムチームの生産性を高めるような変化を促す。
• 他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める。
「スクラムマスターのやることが単純に多くなっている」とのことでした。（2016年版と比べて？）
「おもしろいなと思ったのが、〈 • スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする〉のところ。」
「完全に適用されたらスクラムマスターはいらなくなる」
「いらなくなる状態までこれているひと聞いたことないけど（1人いた）」
私も実は“QAのいらない世界（自分たちで品質向上できている状態）”を目指している者ですが、スクラムマスターの支援も「ここで終わり」という領域はないのでしょう、きっと。
スクラムマスターは導入方法を計画する？
参加者から質問です。
Q.〈 • 組織へのスクラムの導入方法を計画する〉これを出来るレベルの人がスクラムマスターをするってことですか?
A.「必要条件でとらえると何もできなくなってしまう。できれば素晴らしいけど。
組織にスクラムがない状態に、これができないひとがスクラムマスターになっても永遠に畑はできてこない。
状況によってはYesなんじゃないかな」
「状況によって」というのは、
「ウォーターフォール的な開発しかやってないときに、最初に持ち込むのはそういうことじゃないかな」
アジャイルをやっていない現場に初めて導入しようとすると、「導入を計画する」という立場になりますね。
「スクラムマスターが上のひとと調整できるひとである必要は必ずしもない」
「他の調整できるひとにやってもらう。それこそひとを巻き込む能力w
情熱をもってアカウンタビリティもっているひとを動かせるならアリ」
「これはできた方がいい。
これできないスクラムマスターって危ういw
これしないとどうやってスクラムはじめるの？
導入方法を計画することができない状態でも良いの？
ガイド的にはできた方がいいってなるけど、できないレベルのひとでもスクラムマスターやってて良いのかな」
「ぼくもけっこう同意。
”動いているところでしか動けない”は怖い。
チームの存続が危うい。良いと思ってもらえてない」
「初心者スクラムマスターに全部やれないとダメだというのはハードル高い。ファシリテーションはできるかな。
全部できる認定試験つくったらそれはそれでおもしろいw」
「アメリカのアドバンスト認定スクラムマスターはアクセンチュアなら受けれるらしい。認定スクラムマスタートレーニングができる」
「ガイドには書かれてないけどスクラムマスター名乗っている人が増えちゃうと
ネガティブイメージが増えちゃう」
「だから昔は認定スクラムマスターの試験って半分くらい落としてたんだな。
大事だと思う、評判とか。ブランディングの1つ」
「資格もってたからすごいとか。もってなくてもすごい人はもちろんいるので。
コーチの資格とかはとるのに2年かかる。会社を半分やめないといけなかったり。
キャリアコーチとかそんな感じ。試験も面接がっつり」
「Yesと答えよう。
そう思ってもらった方がみんな成長する」
導入方法を計画すらできないやつが”スクラムマスターやります”って無理ですよね、って話でした。これは同意。実際に他の誰かが導入計画をたてた後だとしても、”自分ならどうするかな”という思考を持てないひとはスクラムマスターとは呼べないような。
”支援する”リストをすべてできていればOKなのか？
参加者から別の質問です。
Q.「スクラムマスターの支援するリストの中に抜け漏れはないのか？」
スクラムガイドに記載のある”スクラムマスターは〜を支援する”リストの事柄がすべてできていればスクラムマスターといえる？ 他にはない？ という質問です。
A.「いっぱいあるんじゃないかな。
このリストを全部やっていればスクラムマスターとして100点満点なのか？」
「真面目に答えると、これは最低ライン。
抽象的に描かれているものもある」
スクラムガイドに記載されている”スクラムマスターは〜を支援する”をすべてできている状態から始まる、ってことですね。
抽象的に書かれている項目はどう解釈するのか？ については以下のセリフがありました。
「海外で”スクラムマスターチェックリスト”というのがある」
（日本語版）https://scrummasterchecklist.org/pdf/Scrum-Master-Checklist-jp.pdf
「”TDDの支援を知っている”とか”DevOps”とか。やべーなこれ、ってなる。なかなか細かい。
最後に”学習する組織を創造していますか”」
「TDDとかCIは、”開発チームが価値の高いプロダクトをつくることを支援する”に包含している。
そうなると”アジャイルを理解・実践している”とか大体のものが含まれるw」
「実装は時代によって変わってきますもんね。
CI/CDは最近っちゃ最近。TDDも」
「自分ができていないことを知る・認めるは大事だけど、できていないことを探すことは難しい。
自分からいろんなプラクティスを探しにいけるとか」
「できてないことを探すのはしんどい。
自己肯定感にもつながるから」
奥深いです。きちんと支援のリストも噛み砕いて腹落ちしていかないといけないですね。
自分が噛み砕けていない、腹落ちできていないところがきっと弱いところなんだろうな。
まとめ
「スクラムマスターになるひとは、いろんなチームを見た方がいい。
チームワークってみえないものだから、組織もみえているようでみえていない。
組織って概念だから」
経験大事。
…はい、ここまででスクラムガイドの7ページ目1枚を読んだところです。ものすごくじっくり読めました！
昔、テスト仲間と『SQuBOK』の読書会を行なっており、週1で集まって読み切るまでに1年かかったので、似たようなものを感じました。
なお、次回イベントは本日9/13（日）夜間です。
参加枠がいっぱいあって好きな枠を選べるので、毎回違った雰囲気で参加してみるのも楽しいかと思います…！
この記事が気に入ったらサポートをしてみませんか？