はじめに
12/13, 14にScrum Inc. 社の認定スクラムマスター研修(Licensed Scrum Master, LSM)を受講してきました。
有料の研修になりますので、本記事では研修の内容自体は必要最小限に留め、研修の中で気付いたこと、重要だと思うこと、参考になったことを書き留めておきます。
4分の1真面目、残りはポエムです。
気付きポイント
冒頭にある「茶一服の禅理」の寓話がオサレすぎる
冒頭、「スクラム・センスを習得する最初の一歩は忘れること」の節にて紹介された寓話が超クール。
明治時代の禅師・南隠のもとを大学教授が訪れた際のこと。
南隠は教授に茶を振る舞おうとするのだが、茶碗が溢れても茶を注ぎ続け…教授「茶碗がいっぱいです。もう入りませんよ！」
南隠「この茶碗のように、あなたは自分の意見と憶測でいっぱいになっている。」
南隠「茶碗を空にせん限り、禅を教えることはできんぞ？」
南隠さんカッケー！！！！！！！！（これが言いたかっただけです）
アジャイル系の東洋思想の取り入れ方は理知的で好きです。ZENとか守破離とか。とくに守破離って海外じゃShu-Ha-Ri Statesって言うらしくて、Ha Stateとか言われたら普通Ha?ってなるよなって思ってました…すみません…。
そのうちScrum MasterがScrum Senseiになる時代もやってくるのでしょうね…。
単純なルールが自己組織化を生み出す
「単純で明確な目的と原則によって高度で知的な行動が生まれる」
「複雑なルールと規則は単純で愚かな行動を引き起こす」
― Dee Hock, Visa
「シンプルさが本質」。本質を突いたプロセスやシステムは習慣に溶けると僕は思っています。
最終的にはスクラムがどう、なんて言わなくても勝手にチームが動いてる状態、自己組織化されている状態(= Ri State)が理想形。
とするなら、自己矛盾を孕んでいるようですが、スクラムマスターの目標はスクラムをなくすこと、なのかもしれないですね。
スクラムはリーダーシップが価値主導の文化を促進する場合にうまくいく
ボトムアップ的にスクラムの活動が始まることも多いですが、管理者層がスクラムが組織の価値に寄与することを理解していないと文化として根付かないという指摘に見えます。
スクラムでは問題を発見し、障害をひとつずつ取り除いていきます。時には組織にとって耳の痛いことが障害となりうるので、組織全員が問題に対して真摯である必要があるでしょう。
こう思うと、スクラムのフレームワークって生易しい代物ではないですよね。何も変えず言われたことだけやっている方がずっと簡単。
そのマインドセットの変革が出来ていないところにスクラムを持ち込んでも絶対に機能しないので、導入時は特に慎重に行かないとマズいと思います。
(ロクな説明もせず、いきなり全社的にスクラムを導入して瓦解した組織にいたので、このあたりには一家言…ゴホンゴホン)
スクラムの価値基準であるCommitmentは結果へのコミットではない
スクラムの価値基準はOpenness, Respect, Courage, Focus, Commitmentの5つです。この中のCommitmentは結果へのコミットではないことに注意しましょう。
ここでのCommitmentは、「チームとして最善を尽くすということ」に対するコミットです。Commitmentを結果へのコミットと解釈し、結果への責任追及が来るとチームが萎縮してしまいます。絶対にやめてください！！（悲鳴）
ペルソナとユーザーストーリーとワインバーグ
「品質は誰かにとっての価値である」とはGerald M. Weinbergの言葉で、品質が文脈依存であると指摘するものです*(、と僕は解釈しています)。*
これを援用すれば、そのプロダクトで価値を届けたい"誰か"を想起するのがペルソナ、ペルソナから導かれる"価値"の叙述がユーザーストーリーと解釈することもできそうだなとか考えてました。
価値論、品質論はかなり禅問答ライクなので、ペルソナやユーザーストーリーを考えるような何か具体的行為に落としてあげるとわかりやすいかもしれないです。
スウォーミングとモブプログラミング
各人に別のバックログを割り当てるのではなく、全員で一つのバックログに群がるように取り組むのが「スウォーミング」というプラクティスです。
僕はこのプラクティスを研修の中で初めて知って、演習で実際に体験した威力に結構驚きました。
このプラクティスをベースにするとペアプログラミングやモブプログラミング、ドキュメント作成の文脈だとペアレビューといった手法が実は効果的であることが分かります。
もう皆雑にモブプログラミングやっとけばいいんじゃない？とか思います。楽しくて効率も良いって最強ですよね。
ハウスキーピング：見つけたバグは見つけた時点で直す
ハウスキーピングとは**「見つけたバグは見つけた時点で直す」**というプラクティスです。仕事のタスク管理でも同じことが言えて、どうせ最後にはやらないといけないなら到着順でタスク処理したほうが早いんじゃない？という宗派が存在します。
なぜ仕事が早い人は優先順位を無視するか(PRESIDENT WOMAN)
なんで唐突にこんなことを言い出すのかというと、実は僕もこの到着順で仕事を処理するタイプなのです！
なんかベストプラクティスらしいので、お墨付きを得たとテキトーにドヤっていこうと思いました （単に脳のスタックが少ないだけだという指摘は無視します）
幸福指標：幸せだとパフォーマンスが向上する
幸福指標とは自分の役割やチーム、会社について1~5段階で幸福度をスコアリングし、そのデータをもとに個人と会社の改善のバックログを決めるプラクティスです。幸福度はチームのベロシティに相関があるそうな。
幸福であるという状態を数値化して他の人と比較可能にするのは有効な手立てと思いました。
改善は次のスプリントバックログのトップに
レトロスペクティブで上がった改善ポイントは次のスプリントバックログの最優先にするらしいです。
こう決めてしまえば改善に着手しない言い訳はできなくなるのでいいなーと思います。
その他、バックログに入れるもので特徴的だったのは「技術的負債の解決」と「バッファ」です。
バッファに関しては、僕がメンバとして参加している割り込みが尋常じゃないレベルで発生するプロジェクトにて、当初バッファを全く勘案しないプランニングをしていてチームの外人たちがスクラムマスターにブチギレていた光景が思い出されます。南無。
あと技術的負債の方はどうせ返済できないから技術的貧困だ、みたいなことを同期が言っていてゲラゲラ笑いました。
ウォーターフォール型(ないし従来型)組織には、プロジェクトの様子を見てスモールスタートで導入していく
組織のマインドセットが従来型から変わらないことには、ドーンと大きくやり方を変えようとしても抵抗を喰らい無残に大破するのがオチです。まずはプロジェクトの状態の念入りな調査からはじめ、デイリースクラムやふりかえりのような単体で機能するアクティビティから小さく導入していくのがよいでしょう。
僕はスクラムのようなフレームワークは銀の弾丸でも魔法の杖*(こっちの表現の方がメルヘンで好きです)*でもなんでもないが、アジャイルの精神そのものは魔法の杖になりうると割と信じています。
(Be Agile的思想, 「カイゼン・ジャーニー」の市谷さんのこの記事が詳しいです：
プロダクト作りの在り方を探るコラム 第１回「なぜアジャイル開発なのか」｜市谷聡啓)
なので下手な導入をしてしまってスクラムってクソやん、アジャイルってクソやん、となってしまうことは組織にとってもメンバにとっても相当な不幸に思うのです。
そこのマインドチェンジをどう丁寧にコーチングしていくかがスクラムマスターの腕の見せどころなんでしょうね。
自分ができる気はまったくしないので、凄腕スクラムマスターのふるまいが見たいです！！
スクラムマスターは引きの視点で全体を見渡す
これはグループワークをしていたときに講師の方に教えていただいたアドバイス。
*「どこに問題が存在しているか、だれに頼めばその問題は解決しそうか」*くらいの粒度でスクラムボードを眺めるとよい、とのことです。
POがWhatを、SMがプロセスを、チームがHowを司るという原則に基づくと、SMが問題のソリューションまで検討するのはちょっとやりすぎ、という示唆なのかと思います。
スクラム・オブ・スクラム・オブ・スクラム？
Scrum Inc. 社は組織全体へのスクラム導入にも重きを置いているようで、本来であればAppendixに回りそうな組織的フレームワークについてもしっかりと時間を取って解説がありました。
（僕はこういうの好きなんで興味深く聞いてたんですが、スクラムはじめての方々には若干オーバーワークだった気も…？）
スクラム・オブ・スクラムは協力して開発に臨む必要があるチームが集まってスクラムをしていく手法です。
確かにこの手法だと無限にスクラムをスケーリングすることができるんですが、更に スクラム・オブ・スクラム・オブ・スクラムだ！ とか言い出すと、階層構造がどんどん生じてしまってチームの独立性が担保できなくなるような？という疑問も残り。
このへんのスクラムのスケーリング手法は研究の価値ありですね。
と思っていたらいい記事がつい先日あがっていました。→アジャイル開発のスケーリングの方法
SAFe、LeSS、Nexusあたりを押さえておけばよいのかな?
おわりに
2日間の長丁場でしたが、終わってみたらあっという間で、あーもっとやりたいなー、というのが素直な感想です。
これからのソフトウェアQAはアジャイルのマインドセットを持っていることと、スクラムのようなフレームワークを必要に応じて組織に展開できることがひとつの要求ラインになってくると勝手に思っているので、今回改めて系統だててスクラムを学べたのは本当に良い機会だったと思います。
ただ正直に言うとこの研修を受けたらもうスクラム完璧にできます！みたいな、一朝一夕で身につく代物では全くないことも確かです。更なる精進が必要。
調べたら5月にAgile Japan 2020、6月にスクラムフェス大阪といった大規模イベントもあるようなので、ちょっと参加してこようかなーと画策しています。
(RSGT2020は残念ながらチケットSold Outでした…人気すぎ！)
あとはスクラムマスターやアジャイルコーチみたいなキャリアって広義のソフトウェアQAとも言えますし、ソフトウェアQAの上級専門職にもなってくるものだと思うので、テストエンジニアの人がスクラムマスターになったりアジャイルコーチになったりするキャリアパスがもっと一般的になってもいいんじゃないかなーと感じました。
謝辞
ということで長々と書いてきましたが、これで研修レポートという名のただのポエム集ないし怪文書も終了です。
2日間講師をしていただいた荒本さん・木代さん、企画運営をしていただいたみなさま、野暮な私につきあってくださったチームのみなさん、そして禅の真髄を教えていただいた南隠先生にこの場を借りてお礼申し上げます。
スクラム・センス・オブ・ワンダー！