お久しぶりです。かとじゅん(@j5ik2o)です。
今回、会社の業務時間を使ってScrum Allianceの研修をいくつか受けてきたので、感想を簡単にまとめてみたいと思います*1。
受けた研修は以下です。
| 日程 | 研修 | 講師 | 主催 |
|---|---|---|---|
| 1/17-20 | A-CSM | Zuzi Sochova | アギレルゴコンサルティング株式会社 |
| 2/3 - 4 | CSPO | Joe Justice | アジャイル ビジネス インスティテュート株式会社 |
| 2/7 - 10 | CSD | David Bernstein | アギレルゴコンサルティング株式会社 |
受講の動機
まず受講の動機。「有識者と共に学びを深めて、スクラムを実践に生かすきっかけを作る」を目的にしました。自分だけで学びを深める方法もありますが、今回は有識者と実践者の方々と共に学びを深めることを重視しました。あくまで受講は学びと実践の出発地点ということで。
A-CSM(アドバンスド認定スクラムマスター)
CSM(認定スクラムマスター)はすでに持っていたので、今回はA-CSM(アドバンスド認定スクラムマスター)を受講しました。
スクラムマスターとは
スクラムマスターの定義は以下。
スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。
講師
講師は『Scrum Master The Book』の著者でもあるZuzi Sochovaさん。
受講の感想
- Zuziさんの講義は、ティーチングではなくコーチングが主軸。基本的なメッセージや考え方を示した後、グループで議論
- 講義のスタイル自体がコーチングスタイルなので、スクラムマスターとしてどうあるべきかを考えさせられた。講義資料も面白くて自分で考えた答えを書き込む場所がある
- コーチングの難しさと大切を理解することができた。障害を取り除くために自ら解決するスクラムマスターもいるが、本来はよい問いを立ててチームが作った答えが自走できるようにすることが理想だと思った(もちろん自走できない初見では補助輪的にティーチングが必要になるので、うまく使い分ける必要がある)
CSPO(認定スクラムプロダクトオーナー)
プロダクトオーナーとは
プロダクトオーナーの定義は以下。
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。組織・スクラムチーム・個⼈によって、その⽅法はさまざまである。
講師
CSPOの講師はJoe Justiceさん。CSMのときはJoeさんが講師でした。Joe Justiceさんどんな人かは、以下のTEDの動画(日本語字幕付き)をみてください。Wikispeedという自動車メーカでもスクラムをやってる人です。
受講の感想
- プロダクトオーナーの基礎について学んだ。講義を聴くだけではなくチームで議論してアウトプットするのが中心。
- スクラムマスターサイクルとプロダクトオーナーサイクルを学び直し。以下のように、Scurm＠Scaleでも同様の概念がある。Joeさんの講義ではより実践的な内容だった。中でもよいユーザーストーリーを書くにはペルソナが必要だし、ペルソナの前にプロダクトビジョンは何かみたいな話になるというのはわかりやすかった。
Scrum@Scaleガイド - Scrum Inc. Japan #TeamworkMakesTheDreamWork
余談ですが、Scrum＠Scaleを取り入れてチームをいくつか動かしています。興味がある方はこちらの記事も読んでみてください。
CSD(認定スクラムデベロッパー)
CSDの講師は『レガシーコードからの脱却』の著者でもあるDavid Bernsteinさん。この研修は辻さんと一緒になりました。辻さんの感想・意見も一緒に掲載します。
受講の感想
加藤の感想
- CSDにA-CSDが追加されて実践はA-CSDに移行した模様。時間の関係上座学がメインとなった
- 前半はスクラムの基本的な概念を説明。開発者視点というのがわかりやすかった。例えば、ユーザストーリの見積もりは数字でなくチームメンバー間の合意が本質などが印象的だった
- 後半はデザインパターンについて。「いまさらデザインパターンかよ」と思ったがそうではなかった。デザインパターンが対象とする問題や解決の考え方は今でも有用なものだった
辻の感想
- プロセスやプラクティスは、その目的や意図を理解して実践しないと、カタチだけ真似ても期待した効果が得られないと改めて学んだ
- TDD(Test-Driven Development)は品質保証のために行うのではなく、テストを通じて利用者視点でより良い設計をするために行う、と言うのが目からウロコだった
- ユーザーストーリーを書くときは What に集中して、誰のどんな課題を解決したいのかを考え抜く。わかっていてもつい How を考えてしまいがちなので注意しないと
- ワークショップで、ユーザー要件を自分たちで勝手にエスパーしてしまってユーザーに質問すると言う発想が出てこなかった。これは実務でもたびたびあるなと思った
- プログラム設計でも What に注目することで、細かい中身の計算ロジックよりもまず責務をどう分割するかを決めることができる。モブプログラミングなどでも特に What について議論すると良さそう
まとめ
今回の研修で学んだことはこれまで自己学習や業務での実践を通して経験してきたことです。これまで学んできた知識を捨て、新しく学び直すことを「アンラーニング」と言いますが、まさにそういう機会になったと思います。講師からの学び機会だけでなく、グループワークを通して実践者の方々とコミュニケーションできたのもよい学びの機会になりました。
経験と共に獲得した知識は自分の思い込みと共に最適化*2されているので、基礎的な知識であっても偏った考え方になっていることもあります。例えば「デザインパターンなんて無意味だ」のように無意識に思い込んでいたりします。仮にこれが正しいとしてももう少し解像度を高めた主張を作らなければ組織活動では有益とは思えません。このような偏った主張の文字間に隠れている暗黙的なロジックを掘り起こす意義が「アンラーニング」にはあると思います。
初見ではテクニックやプラクティスをインプットするとHowに気が取られますが、アンラーニング時はWhyにフォーカスすることができるので本質的な学びが得られると改めて思いました。アンラーニングで発見したこと・学んだことを現場の活動に生かせようにしていきたいと思います。運営の方々、ありがとうございましたm( )m
