認定スクラムデベロッパー（CSD）研修を受講してきました
4/15〜4/19に行われた認定スクラムデベロッパー研修を受講してきたので、その内容をご紹介します。
講師はTo Be Agileでアジャイル開発者のトレーニングをされているDavid Bernsteinさんでした。スクラムの研修ではありますが、内容はエクストリームプログラミング（XP）とオブジェクト指向プログラミング（OOP）が中心でした。主に取り上げた内容を次に列挙します。
- ユーザーストーリー
- 受け入れ条件
- デザインパターン
- SOLID原則
- CREATE（コードの内部品質について）
- テスト駆動開発（TDD）
- ユニットテストのテクニック
また、座学での講義だけでなく、次のような実践的なワークも行いました
- 顧客の要求を元にユーザーストーリーと受け入れ条件を作成する
- 次々に変化していく顧客の要求から、デザインパターンを使いながらクラス設計を行う（それによって変更を受け入れやすい設計を実感する）
- ペアプログラミングでTDDをしながら、複数の連続したユーザーストーリーを実装していく
特に３つ目のTDDのワークはもっともボリュームがあり、全体の４割弱には達していたかと思います。細かい内容を逐一説明することはできないので、私が特に印象に残った内容や気づいたことを中心にご説明していきたいと思います。
TDD
ユニットテストの「ユニット」とは
一番印象に残った内容は、TDDにおけるユニットテストの「ユニット」とは何か？という話です。
もともと私は、ユニットテストはクラスに対して書くものであり、TDDは全てのクラスに対するユニットテストを先に書いていくプラクティスだと思っていました。そのため、クラスを小さく分割しモジュール化していくほどユニットテストも単純なロジックだけをテストすることになり、意味のないテストになっていくのではないかと感じていました。
しかし、今回の研修の中でDavidは、「ユニット」とは「振る舞い」の単位である、と説明していました。実際TDDのワーク中、ユニットテストはユーザーストーリーで定義された受け入れ条件に対して書いていきました。このやり方をしていくことで感じたメリットが、「リファクタリングをするときの方が、自由にプログラムを書くことができる」というものでした
リファクタリングの方が自由にプログラムできる
TDDを実践すると、上記「振る舞い」のインターフェース、メソッドシグネチャを決めるところに一番気を使います。そして、受け入れ条件の複数のパターンについて、RedとGreenを慎重に繰り返していくことで実装を形作っていきます。
そんな中、モジュール化やデザインパターンを適用してリファクタリングしていく場面では、開発者の自由度が高くなっています。もちろん事前にGreenにしたテストがあるので、安心感もあります。そこが、TDDをしていて一番気持ちのいいところだと感じました。
リファクタリングのタイミング
TDDはよくRed -> Green -> Refactoringの順で説明されます。しかし、今回TDDのワークをしていて、リファクタリングを行うのは新しいユーザーストーリーの実装に取りかかる前がよいということを感じました。
今までのユーザーストーリーでは必要のなかった概念を取り込むためには、その余地を作る必要があります。その余地を作るために先にリファクタリングをして、そこに新しい概念をシンプルに実装する、というのがよりよい設計を見つけていく道なのかな、と感じました。
デザインパターン
研修の２日目は、ほぼ１日デザインパターンについての話でした。パターンとは何かという話に始まり、12のデザインパターンの意図を解説、最後にパターンを使った設計のワークショップを行いました。その中で印象的だったことをいくつか紹介します
パターンは共通言語
なぜデザインパターンを学ぶのか、という理由の一つとして、Davidは共通言語、ということを挙げていました。
パターンには、どんな問題に対してどんな意図で適用するのか、という情報が集約されています。開発者同士がパターンを知ることで、「ここはStrategyパターンを使ったほうがいいと思うよ」など、一言により多くの情報を込め、より意図を正確に伝えあうことができる、という説明がされていました。
これをさらに考えていくと、GoFなど一般に知られたデザインパターンだけでなく、それぞれのチームで出てくる「よくあるやり方」をパターンとして名付けし、共通理解を育てていくのもよいプラクティスになるのでは、と思いました。
デザインパターンは意図
研修のなかで、Davidは「デザインパターンの本質は意図である」と繰り返し述べていたのが印象に残っています。
よくデザインパターンはクラス図で表現されることが多いですが、クラスの関係性は本質ではなく、意図を表現した結果に過ぎない、と話していました。パターンを使う際は、どんな問題を解決するために、何をカプセル化しようとしているのか、という意図を基準に考えなくてはならない、ということです。
コードの内部品質
コードの利用者はだれか
印象に残った問いとして、開発者の書くコードにとって「ユーザー」は誰なのか、というものがありました。ソフトウェアのエンドユーザーとは別に、コード自体の直接のユーザーは開発者自身である、という話でした。
この表現は個人的にとてもしっくりくるものでした。ユーザーの一つとして開発者を想定することで、内部品質（保守性）とエンドユーザーに向けた外部品質（機能性など）を同じ土俵で考えていくきっかけになるのではないかと感じました。
CREATE
その内部品質の指標として講師のDavidは次の６つの要素をあげていました。
- 凝集性（Cohesive）
- 非冗長（non-Redundant）
- カプセル化（Encapsulated）
- 自己表現的（Assertive）
- テスト可能（Testable）
- 明示的（Explicit）
それぞれの頭文字をとって「CREATE」と呼んでいます。この中から自分が大切にする2 ~ 3の指標を選んで意識するといいよ、という話でした。
David自身は、特にTestableが第一原理である、と話していました。テスト可能であることが、他の５つを高めていくためにリファクタリングする足がかりとなるからです。
カプセル化
私は、CREATEのなかで、「カプセル化」が重要な一つであると考えています 今回の研修でも、いたるところで「カプセル化」という表現が使われていました。
クラスの凝集性を高めるために関連する情報をカプセル化する。まだ決められないことをカプセル化することで、取り替え可能にして決定を遅延させる デザインパターンの説明においても、各パターンの意図として「カプセル化」、という表現が使われていました。
例えば、Strategyの「バリエーションのカプセル化」、Factory Methodの「オブジェクト生成のカプセル化」などです。適切なレベルで詳細をカプセル化し、それぞれの部品の抽象度を揃えてコントロールしていくことが、内部品質を高めることに繋がっていくのだろう、と感じました
最後に
最終日に、スクラムデベロッパーとしての認定を受けるにあたって、以下のような内容に同意を求められました。
「認定はゴールではない スタートである 認定開発者としてこれからも精進し、よりよいソフトウェアの開発に力を尽くす」
正確には覚えていませんが、だいたいこのような内容であったと思います このことを忘れず、これからも認定開発者としてさらに高みを目指していきたいと思います。
参考書籍
最後になりましたが、今回の研修の中でDavidが何度か言及していた本がありますので、それらをご紹介して終わりにしたいと思います。Beyond Legacy CodeはDavid自身の書いた本で、日本語訳が今夏に発売されるそうです。
