アギレルゴコンサルティング主催の「認定スクラムデベロッパー研修（CSD）」に参加してきました。
予想してたものと全く違いましたが、とてもよかったですし、なにより楽しかったです！（語彙力）。
コースの内容
CSDでは、スクラムの開発チームメンバーとして必要な知識・スキルを学びます。
HPより。
「スクラムフレームワーク開発者エッセンシャル」では、スクラムフレームワークがどのようにしてより迅速で、よりシンプルなソフトウェア開発を実現するのかを学びます。「デザインパターン開発者エッセンシャル」では、すべての開発者が知っておくべきデザインパターンのコアセットを学べます。そして最後は人気の高い「スクラムソフトウェア開発者エッセンシャル」コースです。テストファースト開発、リファクタリング、および創発的設計を含むエクストリームプログラミング（XP）のプラクティスを使用して、より高品質で欠陥の少ないコードを迅速に書く方法を学びます。また、さまざまなアジャイル問題解決手法も学びます。
研修内容（とメモ）*1
1日目: 講義。プラクティスの概要メイン。デザインパターン・設計についての概要
- 自己紹介
- アジャイルソフトウェア開発宣言、スクラムの基礎、XP
- 受入テスト、ユニットテスト、品質エンジニアテスト
- プランニング・見積もり
- 「ストーリーポイント」はダメだ。著者たちも後悔している
- タスクを4時間ぐらいに分割して、タスク数を数えて見積もる
- "Done, Done, Done": PoC, 実装（ビルドに組み込まれている）、コードがリファクタリングされており、きれいな状態であること
- ユーザーストーリー
- パターンとは何か、パターンがなぜ良いのか
- パターンを単に記憶するのではなく、パターンの「意図」を理解することが重要
- 設計についての原理・原則
2日目: 講義。デザインパターンの説明、設計のワークショップ
- デザインパターン
- さまざま振る舞いをカプセル化する: Strategy, Template Method, State, Bridge
- 異質性のカプセル化: Adapter, Facade
- シーケンスとカーディナリティのカプセル化: Proxy, Decorator, Chain of Responsibility
- 構築のカプセル化: Factory Method, AbstractFactory, Singlton
- DavidはSingltonパターン嫌い
- 設計のワークショップ
- ペアでお題に対して設計を行う。何回か要求変更がでて、設計の変更をする。後で別のペアと設計を交換して、そこに設計変更を加える
3日目: 講義。CICD、TDD、ラボ開始
- アジャイルに開発するための9つのプラクティス: 小さなバッチ、継続的な統合、クリーンなコード、レガシーコードの改善など
- 単一ソースレポジトリ、全てにバージョンをつけること
- ワンクリックビルド
- テストの自動化
- 継続的統合
- 「It's heart beat.」
- ペアプログラミング、バディプログラミング
- 技術的負債、リファクタリング
- リファクタリングの説得方法: 料理をするときに、汚いキッチン、テーブルだったら捗らないでしょう？まず片付けしますよね！それと同じです
- ドキュメント
- 我々の仕事はコードを書くこと！90%の時間はコードを書くようにしよう
- もしコードをみて分からなかったらコードを書き直せ！あとはテストを書くこと
- TDDがなぜ機能するのか、メリット、失敗しがちな点。良いユニットテストとは
- 「TDD gives insights.」
- テストコードを全て書いてから実装するのはTDDではない。テストをしながらコードへの示唆をもらう
- TDDは何をコードとして書くのか考えること
- TDDはQAを置き換えられない、依然としてQAによるテストは必要
- いつ仮実装から実装をするのか？ -> 「When it becomes hard to fake it.」
- テストは「振る舞い」に対して書く（メソッド単位で書かない）
- ラボ（ラボの課題はDavidに提出してOKが出ないと認定がもらえない）
4日目: 講義。午後からラボ
- ソフトウェアの質
- 正確性だけでは足りず、価値があり続けるためには「わかりやすく」、「保守しやすく」、「拡張しやすく」なければならない
- ソフトウェアの総コストの80%以上はリリース後に発生する
- ソフトウェアの質: 凝集性、非冗長、カプセル化、自己表現的、テスト可能、明示的
- コード品質の6つの観点: CREATE
- 凝集性（Cohesive）、非冗長（non-Redundant）、カプセル化（Encapsulated）、自己表現（Assertive）、検証可能（Testable）、明示的（Explicit）
- テスティングの技法: スタブ、シャント、モック
- リファクタリングの方法
- ラボの続き
5日目: ラボ、（感想戦）
- 朝から1日中ラボ。うちのチームはなんとかギリギリ終わったぐらい
6日目: ZoomでDavidによるラップアップ（1時間）
- Davidがコロナの影響で4日目に帰ってしまったので、ラップアップをZoomで行う
- 各チームの簡単なコードレビューと質問タイム
参加してみた感想とか気づき
溢れすぎてまとまりませんでした。
さすが5日間みっちりの研修（さらにラボが終わらないと宿題になる）。
- 「"スクラム"デベロッパー研修」ではない。言うなら、「"アジャイル"デベロッパー研修」
- スクラムの話は5分ぐらいしかしかなかった。「スクラムはテクニカルな話は一切ないからww」とディスるDavidも素敵なんだが、それを「認定スクラムXXX」としてやるのもなかなか皮肉なもんだなと思った
- 内容的にはほぼXP
- 変化を受け容れるために、変化できるスキル（変化を許容できるコードが書ける、もしくは変化したときに安全に壊さず変えられるスキル（リファクタリング））を持つ、そのために訓練が必要なんだろうなと
- 今どきデザインパターンをあまり意識することはほとんどないが、デザインパターンの意図、何をカプセル化したいのかを理解しておくことは大事
- UMLの形が同じでも意図（カプセル化したい部分）によってパターンは異なる
- いくつかのパターンは言語やフレームワークで吸収されているので、あまり開発するときに意識しない
- カプセル化したい部分はソフトウェアでよくあるバリエーションになり得る（ここ変更されやすいよねというのがわかる）
- どのようなコードが変更に強いのかを理解することにもつながる
- 久しぶりにデザインパターンについての話題だったが、理解が足りてなかったことがわかってよかった
- 「Unitテストは振る舞いに対して書く」
- メソッドを切り出していくとついついメソッドに対してテストが書きたくなるので我慢
- 「振る舞い」の単位が難しいなぁと思うけど、これは最初からわかるものではないのでテスト書きながら発見していくしかないのかなと思いつつ、テストが大きくなるのが気になった。きっと「振る舞い」も分割する必要があるけど、ドメインモデルごとぐらいなのかなと思っている
- DavidのTDDラブがすごい
- 「いつもプロジェクトでやってるんですか？」と質問してみたけど、「時々難しいときがある。例えばラズベリーパイのようなものだ。だけどそれもできる方法を見つけたから、大体いつもやっている」と回答された
- 私はTDD厨ではないし、むしろあまり推しな方ではないけど、TDDのスキルは必要だと思っている
- ある程度Java（もしくはC#）が書けないと厳しい
- 内容のコンテキストがそうだし、ペアプロもどちらかでやるので。ある程度デザインパターンの知識があって、ペアプロ、TDDがそれなりにできる3〜5年目ぐらいのスキルがある人が受けるのがいいのではないか
- Youtubeで川口さんが言っていたように年齢の問題ではない
- 普段コード書いていないようなマネージャーとかPMとかは難しいかもしれない
- ちょっとコードがOld fashion感ある（今どき書かないようなコード）
- Enumに実装したくなる
- ラボ（ペアプロの課題）がよくできている
- どこまで作れば良いのか、何を作れば良いのかは明示されている（あまり設計をしなくてもコードが書ける）
- プロジェクトとかで、あー、ここテストしづらいよね、ところが盛り込まれているのでモックやシャントの練習になる
- このタイミングでリファクタリングする、という指示もあるので何をするかはあまり悩まなくて良い。それでも手を止めて考えなければならないところはちゃんと残っている
- 感想戦がとても楽しかった
- 最終日の懇親会のときに、みんなのコードみたいという話から、たまたま始まった
- 同じ課題をやっていて、実装しなければならないことも明確なのに、これほどコードが違うとは思わなかった
- だいたい悩むポイントも同じなので、あー、そこはそういう風にしたんだね、とかここテストどうしたの？とか、ここの実装は気持ち悪いとか、テストの書き方のフィードバックとか、有意義な議論がたくさんあった気がする（ただし半分酔っていた）
- 1回目の参加者の人たちとも交流感想戦やりたい
- 研修を通して、改めて、ソフトウェア開発というか、コード書くの好きなんだなぁと思った。きっと、Davidの熱量に当てられたに違いない
- 研修終わったあと、押入れから昔の本を引っ張り出して読んだり、本を買い漁ったりして妙にやる気がでていた
さいごに
とにかく私にとってはとても価値のある研修だったのですが、なぜ良かったのかなとふりかえってみると、デベロッパーは「How」の人間なので、原理・原則も説明したうえで、じゃあどうやってやのか（How）をDavidの経験や知見をもとに教えてもらえるところだったのかなと思いました。また、逆にHowは知っていても、原理・原則（Why）の理解が曖昧だったところもあって、そこに立ち戻れるのも良かったんだろうと思います。
なかなか、こうした研修でOOPのデザイン、コード品質、テストの仕方、ペアプロ、TDDでコード書くところまでセットで学べる機会があまりないので、チーム内で勉強会やるのも良いけど、これに参加してしまうのが手っ取り早いと感じました。
とても楽しかったですし、なによりコードを1番に褒められてとてもいい気分ですw（パートナーが優秀すぎた）
ちなみに、無事認定もらえました。やったね。
*1:みっちりすぎて日をまたいでるものもあります。順番が入れ替わってたりするのもあるかもしれません。内容としては合ってるはず
