概要
この記事では著者がScrum Allianceによるスクラムマスター研修に参加し、学んだこと、感じたことなどを紹介します。主に以下のような内容を取り上げて、順番に紹介したいと思います。
- そもそもスクラムとは何か
- スクラムを導入する上で重要な概念
- スクラムマスターの仕事や役割・心構えなど ← この記事のメイントピック
はじめに
概要で説明した通りこの記事ではスクラムマスター研修で学んだ内容+自身の気付きなどをまとめています。
自分が受けた研修はこちらの内容で、Odd-e Japan経由で申し込んだものとなります。
研修はまるまる3日間で、事前に以下の内容を読み込んでおくことが求められていました。
- スクラム入門: https://www.pastoraldog.com/THESCRUMPRIMER_ja.pdf
- アジャイルソフトウェア開発宣言: https://agilemanifesto.org/iso/ja/manifesto.html
- アジャイル宣言の背後にある原則: https://agilemanifesto.org/iso/ja/principles.html
研修自体は講師の方の説明や受講者同士のディスカッションを組み合わせて進められ、スクラム自体に対しての理解に加え、スクラムマスターにとって必要なスキルや心構えを学んでいくことができました。
正直ここ最近受けた研修の中で一番価値が合ったと思うほど良い研修でした1。
以下、この研修で得たものについて紹介していきますが、こちらの記事には著者が研修外で得た知識（書籍や実務）についても含まれる場合があるのでご注意ください。
スクラムとは何か
方法論とプラクティス
スクラムを理解しやすくするため、まずは「方法論」と「プラクティス」の違いについて説明していきます。
世の中の開発方法は大きく「プラクティス」と「方法論」に分けられ、それぞれの違いは以下の通りです。
- 方法論 ... 学問に基づき一定程度正しさが担保された方法
- プラクティス ... ”感覚”としてその方法を用いると多少データが良くなると知られている方法
スクラムは「方法論」にカテゴライズされます。
スクラム
スクラムは「プロジェクトの現状把握をするためのフレームワーク」です。
そのフレームワークの方法論は『Core Scrum』というドキュメントに書かれています。
ベースとなるスクラムの方法に対し、様々な開発現場では状況に合った「プラクティス」を組み合わせてスクラムが活用されています。
スクラムの基本的なルールはシンプルです。（ですが、活用するのは難しいと言われます。）
「目的」、「方法論（基づく理論）」、「3つの柱」、「4つのルールグループ」で理解すると全体像を把握しやすいため、ここの項目に沿ってスクラムの概要を説明します。
スクラムの目的
プロジェクトの現状を把握する
スクラムのベースとなる方法論
スクラムは「組織学」と「集団心理学」に基づく
スクラム3つの柱
以下3つの柱（目指すべき状態）があります。
Scrum Allianceのスクラム解説ページのScrum Theory の項目で説明がなされています。
- 透明性 ... 正しい情報が一箇所に集められており、次の行動が誘発され続けている
- 検査 ... 目的と現状との差分が明確である（何らかの方法で計測できる）
- 適応 ... 目的を実現するために行動し続けていること
スクラムでの4つのルールグループ
スクラムではいくつかのルールがありますが、以下の「Role」、「Event」、「Artifact」、「Time」の4グループでまとめることができます。それぞれのルールの詳細については先ほど紹介した『Core Scrum』を参照してください。
- Role ... どのような役割のメンバーがいるか
- Product Owner
- Development Team
- ScrumMaster
- Event ... どのようなイベントがあるか
- Product backlog refinement
- Sprint planning
- Daily Scrum
- Sprint review
- Sprint retrospective
- Artifact ... どのようなモノを作成するか
- Product increment
- Product backlog
- Sprint backlog
- Time ... どのような期間があるか
- Sprint
上記に書かれていないルールもありますが、その他も上記どれかの4つのグループに属する形になります。これらのシンプルなルールを把握することで「スクラムのルール」については理解していくことができます。
ただし、「なぜそのようなルールになっているのか」、「スクラムを通して何を実現したいのか」といった根本の部分に関してきちんと理解するのかなり大変（かつ重要）だと思います。
こうした根本的な思想の理解には冒頭で紹介したアジャイルソフトウェア開発宣言が役立ちます。
スクラムで重要となる概念
研修で学んだスクラムに関連する概念をいくつか紹介します。
プロジェクトとプロダクト
スクラムは「プロジェクト」の現状を可視化するフレームワークです。
そしてスプリントと呼ばれる反復される2〜4週間ほどの期間の中で、価値ある「プロダクト」を生産していきます。
スクラムのより良い理解のためにプロジェクトとプロダクトの関係について確認しておきます。
まず、スクラムにおけるプロジェクトとはゴールを実現する活動のことです。
このゴールは明確度合いは問われず、期限はあってもなくても良いので、とにかく何らかのゴールが存在してそれを追っていく活動全般をさします。
次に、プロダクトとは対象に提供したら価値を認めてもらえると思われるコト・モノです。
提供対象は何でも良くコトやモノも価値があれば何でも良いです。スクラムではこのプロダクトを生産していきます。
そしてプロジェクトとプロダクトの関係ですが、「プロジェクト⇔プロダクト = 1⇔N」になります。
つまり一つのプロジェクトに対して複数のプロダクトが紐づくと言うことになります。
これら複数のプロダクトをどの順番でどう作っていくかについては、POが戦略に基づいて決定をしていくことになります。
フィードバックの対象2
フィードバックとはもともと様々なビジネスシーンで利用される言葉ですが、スクラムの世界では「活用してプロダクト（チームの活動自体も含む）を改善する」ために用いられます。
ここで注意したいのがその対象で、スクラムでのフィードバックでは「人」と「事象」を分け、発言者は「人」ではなく「起こった事象」のみに対して発言します。
これはフィードバックにおける非常に重要なコミュニケーションのルールです。
フィードバックでは何らかの発言を行う発信者も、それを受ける受信者も正しくフィードバックができるよう意識する必要があります。
以下はフィードバックに失敗しているパターンです。
権利と責任
「果たすべき責任があって権利がある」、または「権利があるので責任がある」という考え方です。
『Core Scrum』中のScrum Valuesの項目にある「Commitment」として出てくる概念と関連するものです3。
Commitmentはどうすべきかを自身で決める権利と引き換えに、成果を果たすという責任を持つという考え方です。
成果に対して責任を持つにも関わらず、どう進めるかをスクラムチームが決める権利がない場合はスクラムの前提として間違っていると言うことになります。
また成果に対して責任を持たないにも関わらずに、どう進めるかの権利を要求すると言うのも同じく前提からして間違っているため注意が必要です。
具体的なシチュエーションとして、製品を作るという状況を考えてみましょう。
権利と責任が担保されている状況は「製品を作ると言う責任がある時にどう作るかを決める権利がある」といった場合です。
製品を作る責任があるにも関わらず、どのように作るかを決める権利がない場合はスクラムがうまくワークしません。
中央集権型組織とチーム中心型組織
組織の形は色々ありますが「中央集権型組織」と「チーム中心型組織」の2つに分けて考えることができます。
従来的な企業は中央集権型組織とやばれる統制を重視した構造になっています。
中央集権型組織ではトップダウンで物事が決まっていき、トップで決めたことを実行するためにチームが存在しています。
一方、チーム中心型組織ではチームで物事が決まっていき、それを周りが支援していくと言う考え方をします。
2つの組織の考え方は噛み合わないことが多く、スクラムはチーム中心型組織を前提とする方法論であるため、スクラム開発を導入する際の一つの障壁となります。
ただし、どちらかに考えを寄せる必要はなく両者の考え方が共存共栄できるような道を模索していくことが重要です。
Definition of "Done" と開発の順番
Definition of Doneはスクラムの中で出てくる非常に重要な用語で、doneとundoneの２つの状態を定義しています。doneは「（サービス提供者として）プロダクトが提供できる状態」を表します。一方プロダクトが提供できない状態はundoneです。
例えば乗り換えアプリなどで乗車駅を入力する機能（From機能）を考えてみます。
この機能の完成はどのような状態でしょうか？入力フォームに文字が入力できることだけではありません。
「セキュリティチェック」、「QAテスト」、「バリデーション」、「統合テスト」などそれらが終わって初めてプロダクトが提供できる状態になります。
実はこうした機能そのもの以外についてはまずはじめに完成させることができ、まずプロダクトをdoneにしてから機能を作るといった方法を用いることができます。
具体的にはTDDなどの方法がありますが、なぜこのようなことをするかというとundoneは溜め込むと指数関数的に増えていくためです。
undoneを積み残して開発を進めるとリリース直前に大量に向き合わなければならず、プロジェクトは往往にして炎上します。
スクラム開発を進める上ではundoneを残して開発を進めるのはアンチパターンとなっています。
スクラムマスター
スクラムの説明が長くなってしまいましたが、ここからは「スクラムマスター」についての説明となります。
私が研修で得た一番の気付きはスクラムマスターの定義です。
研修前はスクラムマスターとはスクラムのフレームで定義された役割と思っていましたが、研修後はスクラムマスターはスクラム”も”活用できる組織による開発を牽引するサーバントリーダーという認識に変わりました。
全ての学びや気付きを共有するのは難しいですが、以下では主にスクラムマスターに関する内容を紹介していこうと思います。
スクラムで定義されるスクラムマスター
『Core Scrum』でもスクラムマスターは定義されており、「スクラムを活用してプロダクトを構築するのを支援」する役割となります。
組織学と集団心理学に精通したサーバントリーダー
ところが、研修を通して、スクラムマスターとは上記の枠におさまらないということが分かりました。
それは、スクラムマスターは組織学と集団心理学の知識を活用してプロダクトの成功を導ける人材であるということです。つまり、目的に応じてスクラムじゃない方法も選択できるということです。
（当然、スクラムを選択する場合はものすごく活用できる必要があります。）
例えば、スクラムをすることを重視するあまり本質的に解決したいことが見えていないような状況に陥ってしまうことをスクラムの奴隷などと言って揶揄されています。
スクラムマスターはこのような状態に陥らないようにチームをサポートする必要がありますし、そのほかスキルや知識に基づいて（スクラムに限らず）チーム開発をサポートしていくという使命を負っています。
スクラムマスターに必要なスキル
スクラムマスター必要なスキルは以下の5項目です4。
- ティーチング ... 相手に行動を変容してもらう力
- ファシリテーティング ... 組織による問題解決を促進させる力
- メンタリング ... 信頼関係を構築し、気づきと助言による自発的・自律的な発達を促す力
- コーチング ... 相手が望むゴールを引き出し、ゴールに向かって自発的に動く手助けをする力
- 状況を分析する力5 ... 状況の構成要素とその関係について理解し活用する力
1〜4のスキルは全てコミュニケーションを手段としているので「コミュニケーションを通して」という前書きがつきます。
上記の5つのスキルの学び方や参考図書などはまた別途紹介できればと思っています。
スクラムマスターの心構えなど
ここでは先ほど紹介したスクラムにおいて重要となる概念とスクラムマスターの関係、またスクラムマスターをする上で重要となる心構えなどを補足していこうと思います。
スクラムマスターはスクラムチームの「権利と責任」を担保する
上記で説明したように、スクラムマスターはスクラムチームの「権利と責任」が果たされる環境を作っていく必要があります。
つまり不当に責任だけを押し付けるような組織の場合は、権利がきちんと担保できるように組織の権力者と掛け合います。またメンバーの責任が果たされていない場合は、成果にコミットするよう促します。
両者が共に存在する環境を実現するために動く必要があります。
スクラムマスターは中央集権型組織とチーム中心型組織を行き来きする
中央集権型組織とチーム中心型組織の2つの組織では、考え方は噛み合わないことが多いため、スクラム開発を導入する際の一つの障壁となりうると言う話をしました。
ただし共存共栄を目指すことが重要で、スクラムマスターはうまく立ち回ることで中央集権型組織の中でうまくチーム中心型組織を機能させるように働きかけます。
この際、スクラムマスターはステークホルダーの考え方に応じてコミュニケーションスタイルを変える必要があり、必要とあれば組織のルール自体を変えるような動きもしていく必要です。
重要なのは複数の組織のモデルを認めること、コミュニケーションを行う際の相手のコンテキストをきちんと理解することです。
スクラムマスターの発言は重い
チーム中心型組織では物事の出発点が「チーム」となります。
そのため、チームから何も依頼されていないにも関わらずスクラムマスター起点でチームに働きかけるのは基本的にNGであり、スクラムマスターからあれこれ働きかけすぎないようにする必要があリます。
チーム中心型組織のモデルでは、チームの要請があってはじめてスクラムマスターは仕事を進めることができます。
そのため、チームメンバーから「相談したい」、「この次も相談しよう」と思ってもらえることが非常に重要となります。
例えば、（このスクラムマスターって人、適当な発言ばっかしやがるな・・・？別にスクラムマスターいらなくない？）と思われたら、スクラムマスターはそこで失職です。
そのため、一つ一つの発言には最新の注意を払っていかなくてはなりませんし、全ての発言には強力な論理性が必要です。
「なぜそれをするのか？」については全て論理的納得性を答られなければならないのは大変ですが、スクラムマスターの重要な態度と言えるかもしれません。
スクラムマスターはチームに対して最も貢献的であるべき
スクラムマスターは誰もが献身的態度を無くしたとしても、最後の一人になってもチームに対して献身的である必要があります。
例えば、開発チームが「もう無理だ。」となっている場合も、なぜそうなのかを明らかにし、チーム状態を改善し、プロダクト開発を支援し続ける必要があります。（そしてこういう自体は良く起きます。）
また、開発チームとプロダクトオーナーの衝突はよくあることだと思いますが、プロダクトオーナーの考えを理解し、開発チームの考えも理解し、両者が一丸となってプロダクトの開発できることを支援しなくてはいけません。
丁寧にコミュニケーションを取るのは骨が折れますが、スクラムマスターとして必要な態度と言えます。
エレガントなスクラム導入
スクラムでは全てのルールに理由があります。
ですのでチームで問題が起こったり話し合う中で良い方法としてスクラムの方法論を取り入れていくことができます。
すると「いつの間にかスクラム開発をしていた」という状況になる場合があるそうです。
こうした気付かないうちにより良い開発スタイルを取り入れていくうちにスクラム開発になっている、というのはとてもエレガントなスクラム開発導入方法です。
レベルの高いスクラムマスターはこういうこともできるらしいです。
スクラムマスター自身のアップデート
そもそもスクラムマスターができないことをチームに対して説得力を持って伝えることはできません。
そのため、振り返りや改善といった基本的な行動は自分自身でもできる必要があり、日頃から心がけていくことが重要です。
おわりに
スクラムやスクラムマスターについて色々書いてきましたが、現実はこんなに理想通りにはできないです。
残念なことに自分は実際の業務で上記の半分もできていないと思います。
しかし、「目指すべきところはここ！」と言うのは非常に大事で、そこに向けて改善をしていくというのはスクラム活動の根本でもあります。
したがって、現状はできてはいないけれども頑張って目指していくというのをこれからも続けていきたいと思います。
-
やや値段は張りますがぜひ受講をおすすめします。 ↩
-
研修の中で出てきたアジャイル開発の文脈での参照元となる資料は見つけられませんでしたが、スクラムではフィードバックを得て改善を行っていくと言うサイクルが重視されます。 ↩
-
研修の中では名言されていなかったので推測を含みます。 ↩
-
こちらも「スクラムマスターに求められる包括的な5つのスキル」について文献を見つけることができませんでしたので、文献になっていない類のものなのかもしれないです。 ↩
-
状況を分析する力についてはなかなかそれっぽい解説に当たることができなかったので、自分はシチュエーションアウェアネスの文脈で理解をしています。この「状況を分析する力」について何か知っている方がいらっしゃいましたら教えていただけると大変助かります。 ↩