認定スクラムマスター(Certified ScrumMaster)の研修受けてきました
はじめまして。アジャイル開発チームのたけやんです。
私がスクラムマスターとなるプロダクトが動き出したため、この度（慌てて）認定スクラムマスターの研修を受けてきました。
本当は「認定スクラムマスター取得しました！」というタイトルにしたかったんですが、忘れないうちに書くことにしました。
研修で、スクラムを導入するにあたって非常～～～に大切なことを学んできましたので、ぜひ共有させてもらえればと思います。
この内容を知らずにスクラムを始めようとしてたと考えると背筋が寒くなるほどです。
なお、丸三日ある濃厚なその内容を全てお伝えすることは難しいため、筆者が独断で選定した内容のみになることをご了承ください。
※既に同じ研修に申し込み済み、またはその予定がある方は読まないことをおススメします。ご自身で体験した方が何倍も為になると思うので、読む時間がきっと無駄です（笑）。
※合格のコツとかはありません。
※スクラムの手法などは説明しません。
認定スクラムマスター(Certified ScrumMaster)って？
スクラムマスターの資格です。
Scrum Alliance® が認定した研修プログラムを受けて、合格すると認定スクラムマスターになることができます。
私は、株式会社Odd-e Japan（オッドイー・ジャパン）が開催する以下の研修を受けてきました。
https://www.odd-e.jp/service_01/
研修の概要
私が受けたコースはこちら。
トレーニングのゴールとしては、参加者がスクラムとは何かを理解し、なぜスクラムを実践するかという事が重要で、そしていかに難しいかを気づいて頂くことです。
上記のように、単純な授業形式の研修とは違います。
ゲームやグループワークなど様々なメソッドを通して問題や解決策を自ら体験し、考え抜く３日間になります。
ホームページ上では研修ではなくトレーニングと呼ばれてますが、まさに脳のトレーニングそのものでした。
講師は、Scrum Alliance®のAlan CymentさんとOdd-e Japanの榎本 明仁さん！
Alanさんはわざわざアルゼンチンから30時間かけて来てくださったそうです。榎本さんはタイムリーにAlanさんの英語を翻訳するだけに留まらず、榎本さんが支援した日本企業の話もして下さりとても為になりました。
またお二人は、「クリエイティブ・コモンズ・ライセンスだと思っていいよ！」と、研修内容の公開を快諾してくださりました。神。
研修内容
さて、研修の内容を抜粋して紹介したいと思います。どれも重要すぎて全部話したい・・・けど我慢(´・ω・｀)
・プロダクト開発シミュレーション
・あなたが取り組む問題の複雑さは？
・成功の数式
・スクラムマスターの役割
プロダクト開発シミュレーション
まずは、4つのグループに分かれて、レゴを使った開発シミュレーションを実施しました。
お題は「99個のブロックを使って売れる鳥のオモチャを作れ」
なぜ99個かというアツイ説明がCEO(だったかな？)役のAlanさんから行われます。
制限時間は約30分。
大人たちが苦心して作り上げたものがこちらです。
・・・え？話聞いてた？（笑）
ええ、全員超真剣に取り組みました。
しかし、全チーム結果は０点。
唯一まともに見える一番手前のチームも含め、なんと全チームが「99個」という簡単な仕様すら満たせなかったのです。
このシミュレーション、もちろんただブロックで遊んだだけではありません。
実際の開発現場で起こりうる仕様追加や納期変更などが行われたのです。
いかにそれを解決しながらまともな成果物を作ることが難しいかを身をもって体験しました。
シミュレーションの意図としては、
「従来の開発手法では失敗した。だからスクラムを使おう！」
ということだったと思うのですが、私がここで特筆すべきと感じたのは、
「メンバーにはスクラム経験者も複数名いたのに失敗した」
ということです。スクラムを理解してその手法を用いていれば、いくらか成果は出せていたでしょう。
スクラムを浸透させ、実践するのがどれほど難しいかを感じた瞬間でした。
あなたが取り組む問題の複雑さは？
鳥のオモチャ１つまともに作れなかった大人たちは、自分たちが普段取り組んでいる問題（開発）の難しさを改めて噛み締めていました。
そこで話があったのは「問題の複雑さ」についてでした。
真ん中の２つ"Complicated"（複雑）と"Complex"（複合的に複雑）に着目してください。
３つの軸がありますが、
・何を作るかが不明確（What）
・どうやって作るかが不明確（How）
・誰が作るかが不明確（Who）
これらが増大すると、Complexな問題になってしまいます。
仕様が明確で技術も既知のもので、ステークホルダーや開発者の体制がしっかりしていればComplicatedな問題として従来の開発手法でも問題ないでしょう。
しかし、シミュレーションした鳥のオモチャ開発はまさにComplexだったわけです。そして、Complexな問題に取り組む際に力を発揮するのがスクラムだということでした。
ここで一番衝撃的だった一言は、、、
「スクラム開発は遅い」
Complexな問題のWhat/How/Whoを常に見直し、立ち止まりながら進めるため開発スピードが上がるものではない、と。
なので、
「スクラムやったら早く開発できるんでしょ？」
という方が周りにいたら全力で否定してください！
この後、Complexな問題に対して従来の手法（例えばウォーターフォール）が取られることの問題点が語られていくのですが、、、既に長くなってるので割愛します。
成功の数式
従来の開発現場では、工数やステップ数といった数字が多く使われているかと思います。
よく「生産性 ＝ 生産高 / 工数」という指標を目にしますよね！それです。
成功したと言われる開発において、「生産性が高いこと」には納得される方も多いのではないでしょうか。
研修でも効率や高生産性のためにマルチタスクが求められることに焦点が当てられました。「なぜ従来の開発ではマルチタスクで実施するのか？」という問いが投げかけられ、「忙しい＝空いてる人がいない＝無駄な工数がない＝成功 と捉えられるからだ」という意見がありました。
しかし、ここでAlanさんは異なる数式を示します。（右側の式）
SUCCESS = OUTCOME / OUTPUT
日本語で書くと、「成功 = 成果 / 生産高」でしょうか。
「作るものは最小限に、（顧客獲得や売り上げなどの）成果を最大限に」することが真の成功だとおっしゃるのです。考えてみれば当たり前のことなのですが、開発を行っているとどうしても作ることが目的になりがちです。頑張って作ったけど誰も使わなかった、というのは意外とよく聞く話だと思います。
なぜ作るのか？作って何を得られるのか？を常に考えたいものです。
この数式を定着させるだけで企業は生まれ変わるんじゃないかという印象すら持ちました。
スクラムマスターの役割
スクラムマスターやプロダクトオーナーといった、スクラムのロールについての話が出たのは研修の最終日だったでしょうか。
研修内容の比重を見ても、ロールやセレモニーなど、スクラム開発の具体的な手法についてはさほど重要ではないことがわかります。
（だから、Odd-e Japanのページにも以下のような記載がありますね）
スクラムを知識として体系的に学習したい方は、本トレーニングはご遠慮いただき、スクラムの概要研修をご相談ください。
もちろんスクラムマスターの研修なので、スクラムマスターは何をするか？もきちんと学ぶことができましたのでご安心を（笑）。
スクラムマスターの役割は、
・ファシリテーター
・メンター
・コーチ
など様々とのことですが、最も大きな役割は、今まで知っていたものとは視点から違っていました。
「スクラムマスターは組織構造の変革エージェント」
スケールでかいよぉ。。。
しかし、これが事実であることは今まで研修を受けてきたのですぐに納得できました。
スクラムを導入するためには、問題の複雑さを理解してもらい、スクラムの必要性を伝えられなければならないでしょう。
その説明が不十分であれば、「スクラムなら開発が早い」「スクラムは仕様変更に強い」といった耳障りのいい情報のみが独り歩きし、間違った解釈から組織から責められる可能性もあります。
開発チームだけではなく組織全体へスクラムの理解を浸透させなければ失敗してしまうことは、先のシミュレーションの通りです。
まとめ
・複雑すぎる現代の問題にはスクラム！
・スクラムは遅い！
・成功 ＝ 成果 / 生産高
・スクラムマスターは組織の改革者たれ！
思った以上にスクラムマスターの役割が重く、意欲がそがれた方もいらっしゃるかもしれませんね。
研修の随所で、
「スクラムマスターは超大変だから、もし研修後にもなりたいと思うクレイジーな奴らは頑張って！」(超意訳）
とも言われておりました。（笑）
クレイジーな私はスクラムマスターとして頑張っていきます！
今後は、未熟な私のスクラム実践編として何かご報告できればと思います。