CSM研修を受けてきたのでちゃんと振り返る。

2019年12月19日（木）- 12月21日（土）にかけて、Certified ScrumMaster研修（以下、CSM研修）を受けてきた。
今の仕事場はLeSSでプロダクト開発を行っており、スクラムマスターの指導のもと、僕の所属している開発チームも不確実性と戦える状態になってきている。
プロダクト開発をスクラムで運用することによる効果を僕自身実感したこともあり、ここできちんとスクラムを習得し、世の中に広めることができれば、「新しい飯の種になるかもしれん！」と思ったのが、CSM研修を受けた動機である。
（ちなみにこれを研修中のチームメンバーに説明したら、失笑された）

研修前の僕の知識レベル

僕は今の仕事場を除くと、スクラム開発は過去2回経験しているが、いずれも「なんちゃってスクラム」だった。
なんちゃってスクラムというのは、「スクラムの一部だけを取り入れたあまりメリットを享受できていないスクラム」を指している。
例えば、以下のようなものだ。

• 週ごとにチームレトロスペクティブを行うだけの現場（要はチーム振り返りしてるだけ）
• プランニングで各プロダクトバックログアイテム（以下、PBI）のタスク見積もりを行うが、タスク割当てに偏りがあり、属人化と依存関係が多い現場

研修の内容

研修前にどこまでスクラムについて理解しているかの事前課題を解き、研修開始直後にその答え合わせをチーム内で行う。
その後、スクラムの基礎知識を改めて学習し、ワークショップを通じて、スクラムを体験するつくりになっていた。
ワークショップはチームでボードゲームを1スプリントで作成するもので、なかなか楽しめた。

CSM研修で作り上げたボードゲーム

新しく学んだこと

スクラムの一通りのプロセスは業務で経験していることもあり、目新しい学びはなかったが、各プロセス内の細かい部分で今の仕事場では出来ていない新しい学びをいくつか得ることが出来た。

モブプログラミング＆テスト駆動開発

研修中にモブプログラミングとテスト駆動開発についての言及があった。
モブプログラミングは端的に言えば、「チーム内の開発メンバーが一つの部屋に集まり、その場で機能実装していくこと」である。
これはフロー効率をチームで運用していくために、とても重要な手法である。

スクラムにおいて、機能開発のリリースはチームが責任を持つ。そのため、タスク消化が属人化すればするほどチームの機能開発スピードにボトルネックが発生する。
したがって、そのプロダクトの開発経験が長い古参メンバーを交えてモブプログラミングを行うことで、参加者全員にプロダクトのドメイン知識や設計の歴史的経緯、技術的負債のハマりどころ、などが共有でき、属人化を防ぐことができる。
ジュニアなメンバーがいると、ナビゲーターの負荷が大変だとは思うが、やる価値は大いにあるはずだ。

また、僕の仕事場の開発チームはプランニング2の段階でクラスやコンポーネント設計まで議論するが、その決定事項はesaにまとめることが多かった。
これはテスト開発駆動で予めテストコードでクラスやコンポーネントの振舞いやインターフェースが定義し、PRに出せば、早い段階で認識を合わせることができ、手戻りも減ると思う。

PBIの粒度にもっとこだわる

研修ではPBIの単位はINVESTで考えるべきと教わった。
INVESTとは以下の定義である。

• Independent ... 独立している。先行するストーリーが完了してないと始められない、など他の影響を受けない。
• Negotiable ... 交渉可能である。ストーリーが具体的なタスクに落ちすぎておらず、プロダクトオーナーと実現方法について交渉することができる。
• Valuable ... 価値がある。ストーリー単独で顧客にとっての価値があること。
• Estimable ... 見積もり可能である。ストーリーを実現するのにかかる時間が（他ストーリーとの相対時間として）見積もれるだけ、十分な情報があること。
• Small ... 適切な大きさである（小さい）。チームが開発を回していくにあたって、ストーリーを実現するのに要する時間が長すぎない程度に、適切なサイズに分割されていること。
• Testable ... テスト可能である。そのストーリーが完了したかどうかをテストできること。受け入れ条件が明確になっていること。

現在の仕事場のスクラムでも出来ていないことの一つにPBIの単位がINVESTになっていないことが挙げられる。
なぜ出来ていないのかというと、リリースする機能開発単位が大きくなりがちで、リリース間隔が約1~2ヶ月になってしまうからだ。
各コンポーネントを各メンバーが開発していき、最後に結合してリリースするアプローチはCSM研修ではスクラムと呼ばず、ウォーターフォールと呼ぶ。
不確実性と戦うためには常にPBIは出荷可能な単位で開発し、顧客からのフィードバックを得て改善していくはずである。
しかし、今は開発着手からリリースまでの期間が短くても、1~2ヶ月単位になっており、ただの「マイクロウォーターフォール」になってしまっている。

大事なのは、出荷可能な単位でリリースを行うことが今の開発現場でどれくらい有効であるかを評価することである。
その評価を以て、リリースサイクルを早めるかどうかを決めるべきである。

と、ここまで書いておいてなんだが、今の開発チームはそれ以前の問題がある。
現状、リリース後の顧客からフィードバックを得る機会を開発チームが設けていないため、そもそもリリースした機能が顧客にどのように受け入れられているかを評価できていない。
したがって、まずはこのフィードバックサイクルを構築することが今一番やるべきことだろう。

ちなみに積極的に顧客にフィードバックを貰いに行くのは開発チームの責務です。

チーム内のメンバー評価は難しい

スクラムはチームで不確実性と戦っていくということを研修で習った。
したがって、メンバーのアウトプット量で評価する行為とはすこぶる相性が悪い。

スプリント内の各メンバーのストーリーポイント消化数でメンバー評価を行う現場にいたことがあるが地獄だった。
なぜならば、各メンバーは自分の得意領域のタスクだけにフォーカスするようになってしまい、タスク割り当てに属人化が発生してしまうからだ。
これがさらに進むと、チームは自分たちができるPBIのみ注力するようになり、チームとしてのチャレンジ精神を奪われ、開発チーム全体としても、クロスファンクショナルでなくなってしまう。
（チームの担当責務が限定的になるという点では良いかしれないが、これはいわゆるコンポーネントチームだろう）

ちなみにこの話題の結論はCSM研修ではなかった。

評価に関する僕個人の見解

評価はあくまでチーム単位で行うべきだろう。
その中でチーム内のメンバー間で個人の評価をどうすべきかを話し合うのが良いと思う。
（これはスクラムはあくまでチーム戦なので、チーム内の事柄はあくまでチーム内のコミュニケーションで考えるべきという発想に基づいている。）

所感

研修全体を通しての所感を言うと、受けてよかったとは思う。（研修費、めっちゃ高かったけど...）
個人でお金払って研修を受けてるの僕ぐらいだろうな（みんな会社から研修費出してもらっているんだろうな）と思っていたけど、意外にも、研修内の僕のチームは5人中3人（僕を含む）が自腹で研修を受けに来ていて、みんなすごいなって思った。
（僕が会社員だったら多分、受けに来ない）

今の仕事場で、LeSSを約半年間経験しており、それなりにスクラムの知識に自信があったので、学びが少なかったら、どうしよう...と研修前は心配していたが、仕事先のスクラムの改善点もいくつか提案できそうなので、杞憂だった。
とりあえず、さっさとCSM試験をクリアして、泊をつけるぞ！