ワーパパエンジニアの学び手帳

ワーパパエンジニアの業務外での学びとかガジェットネタとか

認定ScrumMaster研修を受けました

先日、認定スクラムマスターの研修を受講したので、その内容を記事にしたいと思います。 ※記事の内容はあくまで個人の感想であり、研修の内容を保証するものではありません。

目次

認定スクラムマスター研修について

認定スクラムトレーナーによって開催されるScrum Alliance認定研修です。
認定スクラムトレーナーは世界で250人ほどいるそうですが、日本人は江端一将さんただ一人ということです。
江端一将|Kazumasa Ebacky Ebata|チーム|株式会社 Odd-e Japan
なお、公開で参加者を募っているもの(パブリック研修)と企業内で開催するもの(プライベート研修)があるようです。
今回私が参加したのは所属会社で開催したものです。
そのため受講した日程などは伏せさせていただきます。

研修を受講し、研修中の評価を元にオンライン試験の受験資格が与えられます。
これをクリアすると晴れて認定スクラムマスターとなります。
(私も無事資格取得できました。)

筆者のスクラム経験

全くのゼロです。アジャイル自体経験なし、これまでの経験は全てウォーターフォール
今回研修を受講したのは、こういった現状を打破したい、これまでと違う案件へのアサインを自身で選択するために必要な知識を習得しようという意図があってのものです。

研修の内容

江端さんから出された課題に答えていくという形式。 研修を作り上げるのは受講者で、上記以外の研修の進め方や時間の使い方など全て受講者に任される。 受け身ではなく限られた時間で多くのものを得ようという姿勢が求められる。 色々教えてもらう体で参加するといきなり背筋を伸ばされる感じです。

実際のところ、私が参加したクラスでは最初に出された課題の答えに3日間かけてもたどり着くことができませんでした。
それはスクラムに必要な考え方、ベーススキルが全体として不足していたということだと思いますが、
かと言って何も学べなかったわけではなく、課題の取り組み方に対するコメントやスクラムと関連付けた考え方を聞くことができ、
スクラムにおけるやり方、考え方も学ぶことができました。

とはいえ3日間考えても最終的に答えにたどり着かなかったのはかなり精神的にしんどいものです。苦笑
研修が終わっても、「こうやったら上手く行っただろうか」などと考えてしまい、しばらくは夢に出てくるほど悶々とした日々を過ごしました。。
きっと実践する際にもやり方を試行錯誤して悶々とする日々なんだろうなぁ、なんて想像しました。うーんツラい。

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

学んだこと

マインドセット

世に出ている書籍はスクラムフレームワークとして定義されているものだけでなく、著者の経験などから現場で役に立つツールや方法論などが追加されて書かれています。
明確に区別している本であればよいのですが、多くの本はそれらをスクラムの一部であるかのように書かれています。
その結果、スクラムのココロを理解せず、「プランニングポーカーやってるからスクラムだ~」みたいな、やり方だけなぞった似非スクラムが横行しています。
この研修では手法的なところや教科書的なところはほとんど触れず、スクラムのココロに主にフォーカスして進められました。

組織論

中央集権型とチーム中心型の衝突、他にも組織論における組織のパターンは全て押さえておく必要がある。
 ⇒スクラムマスターはスクラムを無理矢理適用するのではなく、スクラムが適さない場合に別の選択を提示する
 ⇒チーム中心型:論理的優位性が全て。権威者の考えが通るのではなく、論理的に優位な考えが正しい。論理的矛盾がある考え方を無理に通す、許す、とすると、途端にチームは考えなくなる。
 ⇒スクラムマスターはチームの障害となるものからチームを守る必要がある。会社組織は中央集権型組織が殆ど。チーム中心型との間で生じる衝突からチームを守るために、どういった衝突が発生しやすいか、衝突発生時にどう対処するかを考える上で組織論に精通している必要がある。

問いかけ、質問の効果

問いかけや質問を繰り返すことで、本人が気づいていない課題に気づくことができたり、論理的矛盾を正していくことができる。
しかし、実はこれらはスクラムマスターが最もやってはいけないこととのこと。
スクラムマスターはスクラムの「促進」と「支援」に責任を持ち、チームは「自律的」であることが求められます。
問いかけや質問で介入することで、チームが「自律的」であることを阻害してはならない、というわけです。
スクラムマスターは、目の前でチームが問題を抱えていても、助けを求められない限り自分から動いてはいけないという、「忍耐力」が求められるとも。

スクラムの手法の勘違い的な

例えば、デイリースクラム。3つの問いかけ「昨日やったこと、今日やること、気になっていること」から進捗確認が主目的と考える人がいる。 3つの問いかけで最も重要なのは「気になっていること」。 チームは「生産性を上げること」に責任を持つ。生産性を上げるために障壁となること、改善できそうなことを挙げ、必要に応じて改善策を打っていくことがデイリースクラムの主目的である。
ここで「気になっていることはありません」というのは、チームの責任を放棄していることと同義。ここでも、スクラムマスターは例えこの状況を目の当たりにしても自分からは「ほんとに無いの?」的なことを聞いたりすることはNG。。チームが自律的に現状を打破していくことが求められる。

アンチパターン

手法だけをなぞっているとアンチパターンにものの見事にハマります。「スクラムやってます」という人でもアンチパターンをまんま実行しているということが多々あるとのこと。
今回の研修におけるディスカッションでも見事にアンチパターンにハマりまくってました。。

製品品質(付加価値的なもの)と技術品質(最低限満たすべきもの)

プロジェクトでは技術品質を後回しにして製品品質を満たすことを先にしようとするが、これはNG。
スクラムでは、プロダクトは常にリリース可能な状態であることが求められる。つまり、技術品質は常に満たしている必要がある。

アジャイルは「とりあえず回す」?

アジャイルは「とりあえず回す」みたいにイメージを持たれるが、スクラム(に限った話ではないと思いますが)の考え方としては「評価基準(≒受入基準 acceptance criteria)を明確に定め、その基準を満たす(であろう)方法で進める」。
最大の効果が得られるか分からないが、効果があるかどうかは評価をしたうえで手法を選択する。
本来の考え方はこれですが、いつの間にやら「基準だけ用意し、ひとまず始めて後で評価する」「基準も用意せずとりあえず始める」となってしまうことは本当によくある、とのこと。

総括

冒頭にも書きましたが、3日間ずっと頭使いっぱなし、しかも1人でではなくディスカッションしてクラスで答えを作り上げていくというプロセスはなかなかハードなものでした。
スクラムの研修ではありますが、それ以外の面でも勉強になった面が多々。
今回スクラムの経験が全くない状態で研修を受講し、スクラムの考え方の理解も進みましたがそれよりもスクラムのハードさを思い知らされたという方が強いかもしれません。。
ただ、学んだだけでは面白くないので、実際にスクラムでプロジェクトを進めたり、それ以外でも今回学んだ考え方を色んな場面に適用していきます、という宣言。
がんばろう。

なお、今回研修受講にあたって「カイゼン・ジャーニー」を事前に読みました。考え方や手法の適用方法をイメージするのにいい本だと思います。
もっと前には「アジャイル・サムライ」も読んでたけど、内容忘れてるので読み返して研修の内容と照らし合わせたいなと。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−