見出し画像

認定スクラム開発者研修(CSD)にいってきました

認定スクラム開発者研修(CSD)なるものにいってきました。名前の通りスクラムが関わるのですが、スクラム自体の知識の研修はほぼなく、実際に本当の意味でのスクラムを体験してみようというのが本研修の内容です。

なので実際に講師の方々がPO役やスクラムマスター役を担い、プランニングからレトロスペクティブまでを行います。また、内容はスクラムだけではなく、スクラムと親和性の高い開発手法 ATDD, TDD, masterブランチ一本開発などについても体験できるようになっています。

この記事ではそんなCSD研修についての振り返りを書いていきます。

ちなみに研修のページはこちら。(回し者ではございません)
https://www.odd-e.jp/ja/service_01/index.html

想定読者

- 未来の俺。

最初は「CSD研修の内容が気になる方」というターゲット設定で書き始めてみたところまとまる気がしなかったので、私のポエムをひたすら徒然なるままに書いていくこととします。

免責

※ スクラムの知識がないと読みづらい部分が多々あります。
※ 途中からメモ書きを修正するのがめんどくさかったので、文体が急に敬語じゃなくなってたりしますがご容赦ください。
※ 長文です。

研修の全体感

こんな感じ。

事前研修

研修自体は5日間で行われるのですが、ある程度スクラムの基礎知識があることを前提としているため、他のCSMなどの資格を持っていない人は事前研修に参加する必要がありました。

一応私が所属している組織では今年の夏からスクラムを取り入れており、ちゃんと実行できていなくとも知識だけはあるのですが、大元の部分が再確認できたので行ってよかったなと感じています。

新しく学んだことサマリ

- スクラムは「現状把握」のためのツールである
    - 現状把握の対象はプロダクトとチーム
- スクラムマスターの責務
    - スクラムのinspect, adapt, transparencyが担保されていること
    - チームだけで解決できない組織の課題
    - また、課題だけでなくチームの改善余地を見出して行くのが責務

へーと思ったこと

### チームの現状把握と改善
「改善」の対象には当然のことながらプロダクトのみならずチームも含まれている。

この文脈で、プロダクトに関してはある程度組織で目標としてビジョンなどを設定し、実際にそれとのギャップをユーザに当てながら価値を高めていけると思うのだが、いかんせんチームに関してはビジョンが描きづらいなと思った。

実際にレトロスペクティブやってても基本的に事実に基づく課題ベースの改善のみで、それはそれでやるべきだが「こうしたらよくなる」という純粋な改善余地を見つけていく努力も必要だろう。なぜならプロダクトと比較して、他の世にあるチームと比較して「あ、そんなやり方もあるのね!」といった改善がしやすいからだ。

となるとプロダクト同様、チームの在り方についてもビジョンがあるといいのだが、これがどう描いたらいいのか分からない。プロダクトのビジョンを達成するようなチームはこんなチームと逆算して考えるのか、はたまた他社さんのいいチーム事例をたくさん調べて想定モデルケースを探すのがよいのか。

ちなみに、こうした改善余地を見つけていくのはスクラムマスターという役割に寄るところが多いらしい。頑張ってくれ、スクラムマスター。

1日目

やったこと

Refinementが主。まず最初にこの研修で作るプロダクトに関する説明がある。それからどんな機能を追加したいかの説明がPOから行われる。その機能に対して受け入れ基準が握れるぐらいに具体化をこの段階で行なっていた。

一通りの機能に対して具体化ができたら見積もりを行う。見積もりは相対見積もりで、そんなに時間がかからなそうなものを基準に「1、2、3、5・・・」とタスクの大きさを順繰りにつけていく。要するにプランニングポーカーと呼ばれるアレをちょっとアレンジしたもの。

それから3チームに分かれて、俗に呼ばれるプランニング2を行った。タスクを分解して、POにスプリント中に完成できそうかどうかを伝えてこの日は終了。

新しく学んだことメモ

### Refinementのこつ
- Split - 要件が大きすぎる場合に分割
- Detailing
    - Specification by Example
- Scopeを狭める

### 要件のライフタイム
1. Business Goal
2. Scope
3. Key Example
4. Specification by Example
5. Executable
6. Living Document
このうち1 ~ 4までをRefinementの中で行う。

思ったこと

### Refinementのコツ
要件の詳細化に関してのフレームワークはいろいろ流用できそうだと思った。弊チームは現状Refinementをやらないことになっているが、大き過ぎるPBIというのはたくさん存在しているので、それを分解する作業は依然として必要。

### ステークホルダーがすぐそこにいること
今回研修でのRefinementをやって一番差を感じたのがそのスピード感である。チームごとにワークショップライクに要件の具体化を行なっていたのだが、その最中にPOがぐるぐる各チームを回っていて、すぐにスコープの確認が行えたのが大きかったと思う。POに限らずステークホルダーがすぐそこにいるというのはプランニングのスピード感に影響を与えるし、余計なことをやり過ぎたり要求を十分に満たせないものを作ることを抑制してくれるので重要だなと感じた。

### PBIの文言はわざと雑に止める
理由としてはコミュニケーションを必ず発生するため。一番認識の誤差を少なくできるコミュニケーションの方法はFace to Faceである。PBIがもし詳細まできっちり書かれている場合、チームがその内容で十分と判断しコミュニケーションが発生しない可能性がある。なのであえてフワッとした表現で止めておき、チームが必ずステークホルダーに確認しなければならない状況を作るのだそうだ。

これに対しては「なるほどな〜」という思いと「書けるものはなるべく書いた方が効率的なのでは?」という思いが混在した。解決したい課題が「コミュニケーションが発生しないことによって認識の齟齬が生まれること」であれば別の解決策がある感がする。そもそもPBIがあってそれをステークホルダーに確認せずチームが取り組んでしまうことが問題なのでは?あーでもそれ解決したいなら結構シンプルでいいソリューションな気がしてきた。

### チーム間は依存度を高める方がいい
複数チームでスクラムをやる場合(Lessに取り組む場合)にはチーム間の依存度は高めた方がいいというのが直感からは反する言葉だったので少し驚きがあった。後述するがFeature チームという考えがあり、これをベースに仕事していくと必ず同じ技術的なコンポーネントを複数チームで触ることになる。この時チーム間の依存度が低いと無駄にコミュニーケーションのハードルが高く生産性は低くなる。

そうではなく、依存度を高め有機的に連携しあえる状態を作ることがLessの理想形なのだろう。ということを言いたかったのではと思っているが、もし間違っていたらすまん。

2日め

やったこと

この日はまず開発環境の理解から入った。また、それに伴いTDDとATDDに関するレクチャーがある。

新しく学んだことメモ

### TDDについて
- 1サイクル5分以内
- Greenは2/3がいい

### 共有されたコードベース
- ブランチ必要ない論について
- 全ての人が権限を持っているはずなのだから、PRっておかしくね?

### チームについて
- Autonomous Team
    - 制約 (Definition of Done, Working Agreement, Scrum)
- Fixed Team
- not Project志向 but Product志向

思ったこと

### E2Eとテスト駆動
まず思ったのが「やっぱE2E長え」ということ。これはテスト駆動というより、やはり仕様を上位レイヤーで担保することを目的に制限した方がいい。ただユニットテストでテストしたいと思った箇所がE2Eの方で確認できるというシーンはちょくちょくあったので、「何を確認したいのか」と「どんなテスト種で何を確認したいのか」を言語化しないと粒度がバラバラになってしまうかもと印象を受けた。

というか先ほど述べたことに関しては観点がたまたま重複してしまっても両方書くべきかもと思う。ユニットテストはそのモジュールの振る舞いを担保し、リファクタリングしやすくするようにするのが目的なので、E2Eでたまたまその振る舞いが担保されていようと、ユニットテスト自体は書いてあった方がいい。異なるテスト種間の重複はある程度仕方ないと割り切り、それぞれで守りたいことをちゃんと守ることにフォーカスするのがよいのだろう。

### ペアプロ/モブプロによる品質チェックに関して
今回共有されたコードベースで開発を行うにあたって、ペアプロによる品質チェックが行われていることを前提としている。これは新郷重夫さんという方の考えにインスパイアされているそうだ。

ただ、これは賛否両論あると思っていて、よく「ペアプロあったらレビューいらない」の反論として「ペアプロでやっていると同じ落とし穴にハマっている可能性があるので、コンテキストを共有してない人のレビューは依然有用」というものがある。私自身この主張は共感できて、そういったプロセスを経た方がベターなコードになるのではと感じている。

ただ、この主張の問題点は論理的に証明することが難しいことである。なので結局はチームとしてコードの品質に対して「どこで割り切るか」を決める必要がある。

ただ一回決めたらそれでずっと変えられないという訳ではなく、ペア/モブプロだけだと品質が低いという課題が出てきたら、それに対する打ち手としてコードレビューを導入するなど柔軟に変えていけばよいものだと思う。ただ検証できない形で不安だからという理由であれもこれもとやってしまうのはアンチパターンなのだろう。この辺りは柔軟にワーキングアグリーメント調整していきたい。

### TDDで書くテストコード自体のメンテナビリティ

これは研修自体というより、一緒に参加したテストエンジニアの方との話から「なるほどぉ」と思ったことなのだが

例えばFizzBuzzで次のようなテストを書いたとする。

// -1 の時 -1 を返すテスト
// 1 の時 1 を返すテスト
// 2 の時 2 を返すテスト

-1は負の数を確認したいんだなと意図を読み取れる。ただ、1と2のテストケースたちに関しては「3か5の倍数以外の数が入力されたらその数を返す」という仕様を表現するためのテストなのだが、それが仕様を知らない状態だと読み取れない。要は「2にも特殊な意図があるのか?」と考えてしまう。正直FizzBuzzくらいの仕様が明確なものなら大して問題にはならないが実際のプロダクトでは「このテストは何を確認したいんだ?」となる状況は発生しうるだろう。

TDDでテスト書いていくと、自分の中ではある特定の仕様を表現しているつもりでも、それがテストコードから読み取れないように書いてしまっている場合がある。

解決策の一例で言うと、今回はテストをdescribe的なやつでくくってあげればいい。

// -1 の時 -1 を返すテスト
describe(数が入力されたらその数を返す) {
    // 1 の時 1 を返すテスト
    // 2 の時 2 を返すテスト
}

TDDのテストコード自体のメンテナンスはテスト業界でも話題らしい。

### Fixed Teamの重要性

なんでもチームが最大の生産性を発揮するようになるまで2〜3年かかるんだそうな。なのでプロジェクトベースで考えてプロジェクト毎に"最適"な人たちを集めるのではなく、プロダクトに対してチームを作ることが重要。

というのは理解しつつ、現実問題としてエンジニアだったら2~3年で転職するの割と普通な気がするので、それを前提としてメンバーが入ったり抜けても生産性を上げられる仕組みなり技法が作れれば結構価値あるんじゃないかと思った。

海外ではもっと出入り激しいと思うんだけど、プロダクトチームを作っているところでの取り組みとか、もしくはプロジェクトチームでも高い生産性を発揮している事例なんかは調べてみたい。

3日目

やったこと

2日目はひたすらATDDのテストコードを書いて終わったので、この日からプロダクト自体のコードを書いていく。

新しく学んだことメモ

### テストの書き方
- テストの中で分岐しない(テストをスマートにしてはいけない)
- shallow promise
    - でもこれrandomな値を返すことってあると思うんだけどそういう場合は仕方なくないか?
- 必ずユースケースから、依存ツリーの上からテストを書いて行く

### 自働化 と 自動化
- 前者はstop and fix
    - Toyotaでは全員が不具合を検知したらラインを止める権利を持っているらしい
    - それと一緒でCIで不具合が見つかったらすぐに検知するようにし、必ず直してからpushする

### ペアプロ/モブプロ
- 利点
    - 変更のコストを上げないことがキモ
    - メンバー全員がコード・設計への理解を共有しているのでバラツキが出ない
    - as Productive as Yesterday

### コンポーネントチームとFeature チーム
システム的なコンポーネントに対してチームを作るか、職能横断なチームにするか。

へーと思ったこと

### as Productive as Yesterday 
これはモブプロの利点の説明として今までで一番得心いった。モブプロではコードの書き方、設計について共通の理解が持てる。実際現在複数チームで書いていて、書き方の違いなどはチラホラ出てしまっている。このバラツキがコードの予測可能性を下げ、変更を難していく。

一方で全員が書き方のコンテキストを共有できているなら、この利点は薄れるので、モブプロのメリットも薄れるのでないかと思う。仮にペアプロ2チームとモブプロ4人でやるとすると、単純な生産量で言えば前者の方が上だろう。

なのでモブプロが「万能のソリューションで常にすべきもの」という訳ではなく、チームの成熟度やスキル差を鑑みて選択していくとものなのだと思う。

###「 獅子は我が子を千尋の谷に落とす」メソッド vs. モブプロ
モブプロには上記のようなメリット以外に教育の観点も含まれていると思う。これに関して私は他に「大きく失敗させて、あとで一緒にリファクタしたり書き直ししたりする」という方法の方が教育観点ではいいのでは?という思いがある。

そもそも私は人を育てた経験がないので自分しかモデルケースが存在しない。それで、私がそれなりに成長できた理由としては「とにかく失敗しまくった」ことに尽きると思う。前職では新規サービスの開発に携わりフロントエンドのコードは全て私一人で書ききった。初めての開発だったし、レビューしてくれる人もいなかったので、大量のクソコードを生み出したしバグもたくさん出してしまった。会社にとってはたまったものではないと思うが、こうした痛みを体感して頭を捻ったのが自分の成長に一番寄与しているのは間違い無いと思う。

なので、人の成長を考えるときに私が言えることは

- とにかく量をこなせ
- たくさん、そして大きな失敗をしろ
- 自分の頭で考えろ、常に設計の意図を自分の言葉で説明できるようにしろ

というブラックチックなことしか言えない。

そしてモブプロでは上記が満たせるのかが分からない。多分それなりにスキルのある人の考えを盗めるなどメリットは多々あることは想像できる。しかし、それで本当に自分の頭で考えられるようになっているのかという点に関してはけっこう個人の意識に寄るところが大きくなるのではという予感がしている。

だが「俺はこうだったからこうしろ」というのも老害感が溢れているので、「コードの変更容易性」「成長スピード x 成長してほしい人の数」「かかる時間」の観点で評価して考えていく必要があるのだろう。この辺はモブプロ実際に導入してみて教育観点ではどうだったかみたいな事例は探してみたい。

### 必ずユースケースから、依存ツリーの上からテストを書いて行く
例えばControllerがあって、それが参照するModelがあるとする。そしてあるユースケースを実装する時にそのユースケースのテストから書かずに、Modelのユニットテストから書いてしまったとする。この時Modelのユニットテストは何を基準に書いているのだろうか?

答えは「自分の頭の中にある設計に対して」である。ユースケースの仕様を確認して「多分Modelにはこんな振る舞いが必要だろう」と思いを馳せ、それに対してのテストを書いてしまっているのだ。それでうまく行くこともあるかもしれないが、実際のユースケースを実装した時に想定した使われ方と違うということもあり得るだろう。そうなると先んじて書いたModelのテストと実装は無駄なものとなる。なので、下から書いて行くのではなく、あくまで上から書いていって必要な実装をして行く方が効率がよくなる。

という学びを得ました。

### Featureチーム
前述した「チーム間は依存度を高める方がいい」はこれが理由で、コンポーネントチームでは複数コンポーネントにまたがる機能開発をする時にプロジェクトマネージメントが必要になる。また、状況によってはあるコンポーネントが暇になったりして、そうなるとプロジェクトベースで人を動かしたりするようになるのでFixedチームが作れない。なので職能横断であるFeatureチームを作ることが鍵となる。

というのはとてもよく分かるのだが、世のマイクロサービスでコンポーネントでチーム切って上手くいっている事例があるのかは気になった。またGoogle並みに規模の大きいサービスでは職能横断がそもそも不可能でコンポーネントで切るしかない、みたいな転換点はあったりするのかなとかも気になった。あとは技術力自体が競争優位性の場合もコンポーネントチームの方がメリット大きいこともあると思うので、基本的には事業やってたらFeaturetチームの方がメリット大きそうだけど盲信はダメそう。

4日目

やったこと

今日も変わらずコーディング。あとオフィスアワー的なものがあって、気になっていることが質問できた。

新しく学んだことメモ

### 見積もりについて
- Communication
相対見積もりで行う。そんな大した精度にはならない。
見積もりをするときは具体的なHowは考えない。
なるべく全員でやる

### 質問
- いい質問 -> 考えを広げさせるもの
- 悪い質問 -> 自分の中の仮説を確認するためのもの

### いいコード
- 遺言はHigh Cohesion, Loose coupling

### 2nd Project Syndrome
できなかったことに注力するのでなく「今、ココ」に注力するのだ。

へーと思ったこと

### 見積もりの目的

見積もりはなんのために行うのか。見積もりの過程でタスクを分割し、予測可能性を上げるためだと思っていたが、どうやらそうではないらしい。

そもそもエンジニアの見積もりというのは恐ろしいほど外れる。昔読んだソフトウェア見積もりという本に(たしか)書いてあったが、当初見積もりの4倍の偏差が発生しうるそうだ。要するに「半年で完成」と見積もったら最小1.5ヶ月、最大「2年」かかりうる。

実際の業務でも簡単だと思って変更が思わぬバグ踏んで1日2日潰すことはザラにあるだろう。このため、確かにタスクの分解などやかかる時間の見積もりは働き方の振り返りに使えるなど別の目的に使えたとしても、それがメインの目的にはなり得ない。

またPOの判断材料として時間としてのInvestを示すこともメインの目的ではないらしい。そもそもそのPBIが重要であるならば、Investが大きかろうと優先順位が変わることはあまりないと。まあ、確かに私が覚えている範囲では、この過去3ヶ月で言えばそんなシーンは一度もなかった気がする(あったらごめん)。

では何が目的なのかと言うと「会話を発生させること」なのだそうだ。見積もりを行う時にはそれぞれのメンバーが「どのくらいかかりそうか」を提示する。この時提示する数値に差がある場合、それは足りない観点を補完できるチャンスとなる。

例えばあるメンバーはとても難しいという印象を持っていても、他の人はライブラリを知っているためすぐに終わると思っているかもしれない。そのようなHowに関する話だけでなく、要求に対してすごくスコープを広げて捉えている人と「これだけやればいいんでしょ?」とそもそものWhatに対して違う認識を持っている可能性もある。

こういった違いを浮き彫りにする会話を発生させられるプロセスが見積もりなのだそうだ。

### "いい"受け入れ基準作りのタイミング
今回の研修の進め方では、スプリントの最初にRefinementをやっていて、その中でほぼ受け入れ基準と読んでいいような内容が出てきていた。一方我々のチームではプランニング1の段階では具体化した要件は出てきておらず、2の段階で何度かチーム内で揉んだ内容をPOとラリーして受け入れ基準を作っている。なので、前者の内容の方が効果高いのではと思い、受け入れ基準はどのタイミングでできているのがいいのかと質問した。

まず答えとしては「チームによって異なる」。そして、もし「一つのチーム」で「技術力もビジネスドメインに対してもエキスパートである集団」なら「やる前」に決めるのが一番いいそうだ。

これは「在庫」という捉え方をすると理解しやすい。

受け入れ基準を決めた要件が溜まるということは、ある意味PBIの在庫が増えるわけだ。在庫が増えると実際に着手するまでに期間が空く。そうなると取り組む頃には状況が変わってrefinementが必要になったり、そもそもうろ覚えになって捉え直しが必要になったりする。このため、なるべく在庫は少ない方がよく、なので「やる前」が一番いい。

ただ複数チームで取り組む場合は様子が違ってきて、在庫が全くない状況はコミュニケーションコストが増えて、返って全体の生産性を下げることになる、らしい。おそらく、ある程度プランニング・refinementの時点で全チームで受け入れ基準が作れるくらいに煮詰めておかないと、PBIの優先度組み替えなどが起きた場合個々のチームで調整が発生したりするということなのだろう(この認識はもしかしたら間違ってるかも)。なので複数チームの場合はプランニング時にやるのが安牌。

5日目

最終日。スプリントレビューが始めるまではできるところまで頑張る。

へーと思ったこと

### POとしての言葉づかいに気をつける
どういうことかと言うと「なぜ遅れているのか」と聞いたり「スプリント最終日だ、急げ」とかいったりしないようにしているとのこと。これは一つにソフトウェア開発というのは見積もりからずれることが往往にしてあることを理解しているから、またチームが生産性を自律的に上げてくれるだろうと信頼しているからだという。

また、それとは別に過去の研修で発破かけたところ、今まで教えたATDDなどを忘れてコンフォートゾーンに行ってとにかくスピード優先にしてしまったことがあったとのこと。

事業判断として「早期リリースを優先しDoneの定義をあえて破る」ことは現実としては起こりえると思うが基本はチームを信頼し、「なぜできなかったのか」には注目しないのが基本スタンスだそう。

###とにかく観察する
スクラムマスター役の人にどうやってヘルプのタイミングとか見極めているのか聞いたところ「とにかく観察すること」なのだそうだ。

議論がヒートアップしているなーとか、行き詰まっているなーみたいなのを感じとったり、あとは後ろから書いているコードを眺めて、ワーキングアグリーメントに定義されている開発手法の中でうまいこと進めているかを見ているのだそう。

結構職人芸感ある。頑張ってくれ、スクラムマスター。

### エンジニアの"練習"
エンジニアにも練習が必要である。「アマチュアのサッカー選手は人と集まった時に"試合"をする。なぜならそれが楽しいからだ。だが、プロのサッカー選手は"練習"をする。お前らはプロか?練習してんのか?」的なことを言われ、「おお、うまい例え話だ…と思った」。

楽しいことだけやってて生きていければいいのだが、そうもいかないのが世の宿命だろう。思えばエディタのショートカットとかあんま課題に感じなかったのでこだわってこなかった。エンジニアの三大美徳とは程遠いマインドセットをしていたので、これは少し反省した。

では練習とは具体的に何をやっていけばよいのか。
まず練習の目的は「エンジニアとしてのアウトプットの質・量を上げること」と定義する。それで、「エンジニアとしてのアウトプット」とはなんぞやという話だが、形になるものでいうと次の3種類あたりになると思う。

1. コード
2. テスト
3. ドキュメント

実際には「質」に関しては上記を作った上でどんな価値を生んだかが焦点になるので不十分な定義なのだが、一旦技術的な観点からの質についてのみ考えたい。これらを生み出す際には「純粋に書くという行為」「書いたものの質が高い」「長期的にメンテナンス可能なワークフローになっている」の観点で考えられる。というところまで考えたところでこれ普通に一つの記事にできる内容だなと思ったのでまた今度考えを整理して記事を書きたい。

まとめ

長々と書いてきたが、ここで書いたような知識だけならわざわざ高い研修費払わずとも頑張れば集められると思う。

この研修のキモは実際のスクラムを肌で感じることにあり、実際に長年の経験があるスクラムマスターやPOがいてスピード感を伴って進んで行くのは、スクラムやったことない人だけで再現するのはかなり時間がかかるだろう。

フリーザ様の戦闘力のようなお値段の研修費をサポートいただいた弊社に感謝。

この記事が気に入ったらサポートをしてみませんか?