はじめに - CSMの概要 と 受けたきっかけ
2020.02.06 から2020.02.08 から3日間、 https://www.odd-e.jp/ja/service_csm/ の CSM研修 を受けてきました。研修を行っているのは、 odd-e ですが、資格を発行・認定するのは Scrum Aliance という会社です。
私が受けた会の講師は江端一将（ ebacky ）さんで、日本人唯一のCST （スクラムを教えられる認定コーチ）です。
ebacky さんいわく「参加者のレベルや状況によって内容をその場その場でアレンジしている」とのことなので、同じ研修でも会によって全然内容が異なります。この記事を読んでも「全然違う研修だった」ということもあると思います。
研修の流れですが、
以上の2プロセスにより、認定スクラムマスターになれます。認定スクラムマスターになって初めて受けられるアドバンスドな研修やイベント等もあるようなので、まずはここを目指すと良いのかなと思います。
認定の期間は2年間です。更新手続きもありますが、それは別途そのときに書こうかなと思います。
受講経緯
CSM の存在は、社内の過去の参加者のLT会等でも知ってましたし、界隈で有名だったので知ってました。 書籍だと kaizen journey 等でスクラムが取り上げられていたり、自社でも過去にodd-e の方をスクラムコーチとして呼んでいたこともあります。（私はその当時そのチームには居ませんでしたが…）
個人的なモチベーションとしては、個人の力の限界をひしひしと感じておりました。いくら一人が技術的・仕事的にスキルアップしても、一人の力はたかがしてれます。 当時は「組織として製品を作る」という経験が乏しいと感じていたので、そのための組織論であったり方法論であったりを深めたいというモチベーションがありました。
また、当時所属していたチームは完全な縦割りで、何かしらコミュニケーションを加速させる役割の人が必要だなとも思っていたので、そのための一歩として申し出て受けました。
研修を受けるにあたっての心構え・前準備
本研修は、スクラムに関する知識を体系的に学習するための講義ではない です。 （体系的な知識は、基本的に事前資料であったり、 Core Scrum を読む必要があります）
「スクラムマスターならどう考え、どう行動（改善）するか」 という トレーニングが主目的です。
受け身の座学の部分も多少はありますが、基本的に自発的な参加を求められる「ディスカッション」や「ワーク」などの時間が最も多いです。曰く
「スクラムマスターって言うのを雇うと良いって聞いたんやけど、実際何がええん？？」と言う問いに答えられなければなりません。また、「スクラムマスターを雇ってよかったわ。ありがとな！」と言われるような行動を示さなければなりません。
また、この記事をリライトする前に、スクラム 仕事が４倍速くなる“世界標準”のチーム戦術 | ジェフ・サザーランド, 石垣賀子 |本 | 通販 | Amazon を読みました。スクラム創始者の一人、「ジェフ・サザーランド」さんの書籍です。事前に読んでおくと良かったと思う一冊ですが、研修を受けてから読んで理解した部分も多いので、教科書的に何度も読み返す事をして良い本だと思います。
スクラムに関する知識とか
言葉の定義など
グラウンドルールとしての、言葉の定義
本来の定義というよりは、「この場ではこういう意味で扱います」という意味で共有されたもの
- 研修 : 一方的な情報伝達
- トレーニング : 自らの努力などの働きかけによって自らのスキルを伸ばす
スクラム関連の言葉の定義
- チーム
- 7±2 人で構成された組織。それ以上でもそれ以下でも定義に反するのでチームと呼ばない
- プロジェクト
- 現状と目的の差を埋めるための活動。（※ 現状と目的との差分の明確度や、個数などは問わない
- プロダクト
- 「価値」だと考えられるもの（難しいが、「価値そのもの」ではない。価値だと「考えられる」。お金でも無い）
- 一つの「プロダクト」に複数の種類の価値が発生することもある
- スクラム
- 「プロジェクト」の現状を把握するための「方法論」の一つ
- スクラムチーム
- プロダクトオーナー（以下PO）, スクラムマスター(以下SM), チーム で構成された組織
方法論とプラクティスの違い
方法論とは
- 学問に基づいて理論立てて構成されたもの
- いかなる条件や環境でも有効に働く
- 目標に対して、直接的には寄与しない
プラクティスとは
- それまでの習慣や、感覚的に「良さそう」と思われているもの
- 特定の条件や環境の中でのみ有効に働く
- 直接的に、目標に寄与する
先述の「スクラム」の定義によると、スクラムは「方法論」なので、具体的なプラクティスは厳密にはスクラムではない。 あくまで、「スクラム」という「方法論」があって、それを肉付けするのが「プラクティス」（具体的に日々やってたりやってなかったりすること）
スクラムは、基本的に「組織学」と「集団心理学」に基づいて構築された「方法論」なので、それらの分野に精通するとよりスクラムへの理解が深まる。
中央集権的組織 vs チーム中心主義的組織
中央集権的組織とは
- いわゆる「トップダウン型」「三角形のピラミッド型」の構造を持った組織
- 統制・統治する ことが最大目的の組織構造
- ピラミッドの最も上に居る人から、末端にかけて「指示・司令」を出して行き組織のコントロールを生み出す。
チーム中心主義的組織とは
- 「ボトムアップ型」「相互作用型」という形の構造を持った組織
- より良い成果を出す ことが最大目的の組織構造
- 中央集権型組織と異なり、「司令塔」のような存在は無く、各々が各々の「役割」を果たすことで最大の成果を生み出す。
スクラムチームは「チーム」の一種であるのが、スクラムチーム以外にも「チーム中心主義的組織」を生み出すことは可能。（スクラムじゃないから、研修では扱わないとのこと）
日本の企業はほぼみんな「中央集権的組織」になるが、開発で「スクラムチーム（チーム中心主義的組織）」を採用しようとすると、スクラムチームの中と外でどうしても構造上の歪が生まれてしまう。 特に、歪の渦中に飲まれやすいのは、人事評価する評価者（上司とか社長とか）であったり、スクラムチーム外とのやり取りが多い役割の人物であったり、スクラムマスターであったりする。
逆に言うと、これらの人はスクラムチームに余計なノイズが入ってこないように努力する必要がある。
スクラムチームの定義
PO(1人), SM(1人), チーム(5-9人) で構成された組織。
プロダクトオーナーの責務
どんなプロジェクトにも「予算」は必ず存在する。ROI（投資対効果）を最大にするのがPOの責務。 ここで言う「予算」とは「お金」「人」「時間」など。
ROI を最大化するために、顧客に提供する価値を記述したプロダクトバックログを作成したり、それらの優先順位をつける。
チーム
一方、チームには生産性を最大化する責務がある。ここで言う生産性とは「プロダクト」に対する生産性である。「プロダクト」とは製品の製造だけでなく、関わるドキュメントの作成、メンバーのスキル、文化、なども「プロダクト」になる。何をプロダクトと捉えるかは、プロジェクトで決定される。
「プロダクト」を分解したものが「ストーリー」であり、「ストーリー」を数値化したものが「ストーリーポイント」である。 つまり、ストーリーポイント/スプリント = ベロシティ を最大化することがチームの責務になる。
「ストーリー」に紐付かない作業はすべて「タスク」として分類される。タスクは「ストーリー」ではないので、いくつクリアしてもストーリーポイントは0。つまり、ベロシティに貢献しない
スクラムマスター
上2つのロールと異なり、スクラムマスターは、実際に手を動かしたり、実際にプロジェクトに関わる意思決定をすることができない。 あくまで「成果を高めるための活動を見直す」ことに注力する。
例えば、チームの稼働時間のうち「タスク」に割いている時間の割合が多く、ベロシティに寄与していないと考えたのであれば「タスク」が多く積まれてしまっている原因はなにか、解決するためにはどうしたら良いのか、課題を発見し改善する方法を「提案する」
提案されたプランを採用するのは、PO あるいは チーム あるいは組織外の人の裁量によって行われる。つまり、良いスクラムマスターは自分の出したプランが、チームに採用される確率が高い。
提案したプランを実際に実行して効果が出るかどうか。より効果が期待できるプランを提案する必要があるし、一度提案したプランを見直し、更に良い状態にするための提案を繰り返し行う必要がある。
スクラムの構造
- 学問
- 集団心理学
- 組織学
- 状態
- Transparency
- Inspect
- Adapt
- ルール
- Role
- Event / Celemony
- Artifact
- Time
これらの要素が一つでも欠けていればスクラムではない。
学問
集団心理学、あるいは組織学に基づいて論理的に証明されたことをベースに組み立てられている。 なので、スクラムのルールに追加・変更がある場合は、基本的にそれらの学問において新たな論文が採択される時である。
状態
以下の３つの状態を満たしていなければ、スクラムではない。
- Transparency
- 正しい情報が、一箇所に集められており、次の行動が誘発され続けている状態
- Inspect
- 目的と現状の差分を把握し続けている状態
- Adapt
- 目的と現状の差分を埋めるための活動を続けている状態
Transparency について。「正しい情報」とは
- 過去の情報ではなく、「現在どうあるか」という現在の情報であり、
- 誰が見てもどう見ても、一意に同じ解釈ができるもの
つまり、チームの中で一人しか把握していなかったりすることは「正しい情報」ではない。 最初は一人しか把握していなかったことを、チーム全員に共有する（あるいはいつでも見れるようにドキュメント化するなど）をして初めて「正しい情報」になる。
次の行動が誘発され続けている状態とは、↑を見聞きして、「じゃぁ次これをやる必要があるな」と各々が判断できる状態のこと。
Incpect について。「目的と現状の差分を把握し続けている状態」を行うために「カンバン」などのツールを適宜利用する。ツールの運用等に関しては「方法論」ではなく「プラクティス」の領域なので講習の対象外
Adapt について。 これは単純に「ゴールに向けて頑張ろう」という意味だけではない。「このベロシティではこのゴールにたどり着けない」や「そもそも本当に価値のあるものではなくなった」など、変化に対して柔軟に差分を埋める活動を行う。つまり、「目的」さえも変化の対象になりうる。「Transparency」を満たすことが大事
ルール
- Role
- 先述の通り、PO(ROI), SM(成功確率), チーム(生産性)、の３つの役割がある。
- 基本的に兼任は良くないとされているが、あくまで役割なので多少は崩しても良い
- が、それは熟練したスクラムチームでも難しいので、あくまで欠員が出たとか緊急時のみに留めたほうがいいとの事
- Event / Ceremony
- やることが「Must」なこと。これらをやらないとスクラムは成立しない。上からスパンが長い順に並べてる
- Product Backlog Refinement
- 要するに優先順位付け
- プロダクトバックログアイテムの洗い出しや、それらの価値の推定。優先順位決定を行う。
- 中長期スパンで行う
- Sprint Planning
- そのスプリントで何をするかを決める。
- ここで大事なのは 「何をどうすれば完了になるのかをチーム全員が把握している状態」 がゴールであること
- スクラム初めてのチームは、スプリントプランニングだけで数日使うこともザラにある
- （ebacky 先生曰く、最初は全部のチケットが同一ポイントになるよう分解すると、わかりやすいとのこと）
- Sprint Review
- スプリントの振り返りを行う
- できた。できなかった、ベロシティの計測は基本。
- スプリントプランニングで見積もったポイント数と、実際にやってみたポイント数の大きさの誤差を必ず記録する
- ↑をやらないとどれだけスプリントを回しても見積もり精度が向上しない
- Sprint Retrospective
- Daily Scrum
- 毎日やる
- スプリントプランニングで決定した「やること」「ゴール」に対して、今どのあたりにいるかを全員で共有し、再計画する
- DS は ただの日報共有になりがちだが、目的は「スプリントの再計画」なので、積極的に課題を共有したりしないと意味がない。
- ここもガチでやるとかなり難しい。
- Artifact
- Artifact とは、製作物・遺作物 とでも翻訳される。下手に日本語にしたほうが難しいのでアーティファクトという概念で覚えたほうが良い
- スクラムプロジェクトの過程で必ず生まれる物
- Product Backlog
- Sprint Backlog
- 一方、スプリントバックログは、チームのタスクリスト。具体的な実装など、当面の作業計画を示すもの。
- ここで列挙される「Aを実装する」などということは「タスク」という概念で表される。
- タスクはストーリーではないので、ストーリーポイントは付かない。 あえて付けるなら0
- タスクは、ストーリーと違い、完了の定義が明確に存在する。 = 誰が見ても「これはdone にしてOKだね」といえる状態でないといけない。
- Increment List
- リリース判断可能な単位のことを「インクリメント」と呼ぶ。
- 複数のタスクの集合。「これらのタスクが全部done なら この機能に関してはリリースしてOKだね」と呼べる単位。
- 実際には、複数のインクリメントの集合をどかんと一つのリリースとして出すことがあるが、「切り分けられるか」という意味で
- Done / Undone
- チームの視点を持ってして（つまりタスクとして） 完了しているかどうかの定義。
- 「実装したけどセキュリティリスクがある」とかは「Done」ではない。
- Done の定義をチーム全員で共有していることが大事
- Acceptance
- プロダクトオーナーの視点をもってして、「プロダクトバックログアイテム」が成立しているかの判断基準。
- Done を満たすこと、Acceptance を満たすこと。両方を持ってはじめて価値として提供することが出来る。
- Rapidly Shippable Product
- Increment List が「タスクの集合」であるのに対し、こちらは、「プロダクトバックログアイテム」として成立しているかどうか。
- より早く価値を提供するには、ストーリーを完成させる必要がある。インクリメントとストーリーが近いほど、高速な出荷（リリース）が可能になる。
- Time
ごちゃあっと書いたけど、これらをすべて満たしていないとスクラムではない。 例えば、スプリントリファインメントを行わないスクラムチームはスクラムではないし、PO, SM のいずれかが不在でもスクラムではないし、チームの人数が多すぎても少なすぎてもスクラムではない。
余談だが、 ebacky 先生は新たなルールとして「Working Agreement」を提唱している。
スクラムマスターの役割と、求められるスキル
スクラムマスターは、スクラムの専門知識をもってスクラムを回すのをサポートするが、スクラムを成立させることが最大目的ではない。
中央集権的組織の最大目的は、統治すること。つまり、関心が「人をどうするか」にある。 = Controll 一方、チーム中心主義の最大目的は、結果を手に入れること。つまり、関心が「事をどうするか」にある = Manage
Manage は、管理するとか訳されるけど、ニュアンスとしては、「（方法を問わず）いい感じにする」が近い。
スクラムマスターに求められる役割は、「価値を提供するための手段をスクラムチームに提案する」こと。 色々な選択肢の中から、より成功確率（よりユーザーに価値を届けられるかどうか）の確度が高い手段・方法をPO・チーム・その他の関係者に提案することがスクラムマスターの介在価値になる。
必要なスキルとして以下の４つを定義している
- Facilitation（to be が明確なとき、to beまで導くことが目的）
- Teaching（to beが明確なとき、as is から一歩踏み出させることが目的）
- Mentoring（to be が明確ではないとき、 よりto be に近い方向に軌道を修正することが目的）
- Coaching（to be が明確ではあるが、よりよい to be を提案することが目的）
これらは似たように聞こえるし実際似たようなことをやることもあるが、それぞれ目的が異なる。
更に、これらに加えて、Situationing（２つの事実の因果関係を見出す能力）が求められる。
体験編
講義中にワークショップとして、「1日目の講義を振り返ってスクラムマスターとして改善点を述べよ」や「←のアイデアを1位〜30位に順列をつけろ」などのワークショップがある。スクラムの知識が必要というよりは、論理的思考が求められる。
徹底した論理的思考、あるいは議論が求められる。「とりあえず締切が決まってるから締め切りまでになんんとか適当なアイデアを出そう」は決して許されない。それはスクラムの原理に思いっきり反しているから。しかし、それがわかっていたとしても、実際に実行するのは非常に難しい。
参加した感想とか
実際に参加した感想としては、思ったよりSIer 企業からの参加が多かった（ウェブ系ばっかりだと思ってた）。参加者のレベルによってクラスのレベルも変わるらしい。「これからスクラムをやるぞ」というよりは、「スクラムやってるけど理解が足りない」という人のほうが向いていると思う。ただ、これは講師の特性もあると思っていて、ebacky さんじゃないクラスのほうは、「はじめてスクラムやるぞ」という人向けなのかもしれない。
内容としては、自分が全然理解していなかったことが多かったので、その穴埋めが出来て非常に良かったと思う。一方、自分が所属するチームの開発手法はスクラムとはかなり乖離しており、自分が所属するチームをスクラムに持っていくのか持っていかないのかの議論から出発しないと行けない。「スクラムとしてやっていくぞ」という方向になれば、SMとしてスクラムの知識を回していきたい所存
