この記事は カオナビ Advent Calendar 2021 13日目です。
はじめに
先日、認定スクラムデベロッパー（以下、CSD）研修なるものに参加しました。
当初予想していた内容と全然違って面白かったので、その備忘録です。
コースの内容
CSD研修では、スクラムの開発チームメンバーとして恊働するのに必要な知識・スキルを学びます。
今回の研修はオンラインで3日間行いました。
スクラムの開発チームメンバーとして、正しくかつ効率的に恊働できる人材育成を目的として Scrum Alliance® により作られた、体系的ソフトウェア開発者の教育・認定プログラム。スクラムの原理原則を理解して、実際に恊働できる能力が Scrum Alliance® が規定した水準を満たしている事を証明します。スクラムの開発チームメンバーとして必要かつ効率的なコミュニケーション、技術力が Scrum Alliance® の水準を満たしている事を評価します。
どんなことをやったのか
スクラムの研修ですが、内容としてはエクストリームプログラミング（XP）が中心でした。
取り上げられた主な内容としては、以下の通りです。
- テスト駆動開発（TDD）
- 良いテストコードとは
- リファクタリング
- 受入駆動開発（ATDD）
- シンプルな設計
- 継続的インテグレーション（CI）
かなり実践重視な研修となっており、半分以上はペアプロで上記の内容を実践する時間でした。
研修内容メモ
1日目
始める前に
研修を通して、意識してほしいこと
ウォーターフォール的な習慣や考え方はそのままでよいのか？
- ウォーターフォールは完璧だが、唯一の弱点は人が行うこと
- 自分が想像できることの外に、リスクが広がっている（計画したものを完璧と考えるのか？）
- XPのプラクティスは人間の弱さを受け入れるものが選ばれている
テスト駆動開発（TDD）
- 3つサイクルですすめる
- Red（テスト書いて失敗する）
- Green（コードを書いてテストをPASSする）
- Refactoring（必要な量リファクタリングする）
- 上記を短いサイクルで繰り返してすすめる
- 石橋を叩くくらい小さなステップで進める
- 具体的なテスト、例を積み上げるほど、実装が一般化する
- テストは具体例
- 具体例が増えるほどコードは頭が良くなる
よいテストコードとは
- テストコードは実行可能な仕様書である
- 3A（Given,When,Then）
- Given: 準備
- When: どういう操作
- Then: そういう結果
- 構造化するときには上記の3Aを意識すると◎
- Assertの対象について
- 状態を見るか
- 中身を知りすぎて付き合いづらいテストになっていないか？
- 振る舞いを見るか
- テストが落ちた時にデバッグしないと行けないようなアサートになっていないか？
- 判断基準としては「メソッド内でのロジックがどれくらいあるのか」
- ただ、基本的には振る舞いを見るほうがいい
- 状態を見るか
2日目
リファクタリング
- 外部からの動作を変えずに内部構造を変えるための統制を取れた手法
- リファクタリング = コードをクリーンアップする ではない
- あくまでコードベースの状態を改善するための1つの手法
- 参考： https://refactoring.com
- コードの不吉な匂い（Code Smells）を感じる
- 新しい橋が開通する前に古い橋を壊すな
- 両立する状態を作って使わなくなったら消すスタイル
- 駄目だった時に戻ってきやすい
受入駆動開発（ATDD）
- TDDとは全くの別物
- 下記手順で進める
- シナリオのテストを作ってみる
- 薄いスライスで “Walking Skeleton“ を最初に作る
- そのテストを満たすためにTDDで実装してみる
- シナリオのテストを作ってみる
- 具体例を用いて仕様を定義する
- シナリオベースでの仕様書
- それを共通認識として進める
- 偶像的に具体例がぶれてしまうことを防ぐ
3日目
シンプルな設計
- リファクタリングする上でシンプルな設計を意識して向かっていく
- なぜXPの人は分散している選択肢をとっているのか？
- 人やチーム、システムの知識は時間とともに増えていく
- 時間が経つことで知識が増えるのであとから設計したほうが良いものになりやすい
- 柔軟性を予測ではなく、シンプル設計で表現する
- 4つのルール（数字は重要度順）
-
- All Test Passed
-
- No Duplication
-
- Naming
-
- Few Element
-
継続的インテグレーション（CI）
- CIは開発者の習慣である
- 人がどういう風に活動しているかであり、システムではない
- 1つのブランチで運用する
- 全員がすぐにpushしてコンフリクトする
- 常にぶつかることで早めに知識が高まる
- 早めに知れることでリスクを減らせる
- 問題が早く分かることがいいことというメンタルをいかに持てるか
- そこには練習が必要（痛みを伴うこともある）
- ブランチをたくさんやっている場合の最初の一歩としてShip/Show/Ask
- 自分たちのタスクでレビューは本当に必要か考えてみる
- 参考： https://martinfowler.com/articles/ship-show-ask.html
推薦図書
おすすめされた本はこの数倍あったのですが、あまりにも多いので抜粋して上げておきます。
（アフィリエイトリンクではないので、ご安心ください）
感想や気付いたこと
よかったこと
色々相談、実験しながら開発できるのが良かった
- 普段開発をしていると、なかなか「人と相談しながら実験」というものが出来ない
- ペアプロしながらの実践が多かったので、実際にやってみての辛みが研修中に発見できた
- その場で講師の方に質問できたし、他のペアの気付きを吸収することも出来たので、効率的だなと思った
プロダクト開発での新たな問題点が見えた
- 当たり前にやっていたことを否定するような話（masterブランチだけで開発する etc.）が出てきた
- 今まで知らなかった世界を知ることで、現状の開発体制に対する新たな問題点を見出すことが出来た
3A（Given,When,Then）で受入条件を書くのは気軽に取り入れやすそうだった
- 前提要素がなくても、ひとまず取り入れることが出来そうに感じた
- 実際に社内に持ち帰って話したところ、他の方に試してもらえたりした
気をつけたほうがいいこと
スクラム開発の経験がないと理解が大変
- 研修ではほぼスクラムについて説明されないが、用語などがバンバン出てくるので経験がないと厳しそうに感じた
- 逆に経験があると、話がすんなり入ってきて理解しやすかった
TDDの習得は3日じゃ足りない
- 原理としては理解できるが、実際にコードを書いてみると設計が難しかった
- どうしても普段通り先にプロダクトコードを書いているときよりも微妙な感じになってしまう
- 講師の方も、3ヶ月練習して少し分かってきたくらいだったらしい
- ここは鍛錬あるのみ
- でも、最終日にはテストがAll Greenにならないとソワソワするくらいにはなれた
- 意識的な部分は短期間でも少し変わった実感があった
コードの内部品質的な話は少ない
- テストコードについては、多くの時間を割いていた
- しかし、プロダクトコードの品質についてはほぼ話がなかった
- デザインパターン
- SOLID原則
- CREATE
- etc.
- 講習が５日あるとこのへんまでやるのかもしれない
はっとした話
世界中の人がいいなと思うものはかなり多様性のあるもの
- 他の人の成功体験をそのまま持ち込もうとしても、自分のチームには合わないことが多い
- XPも一緒で、ここで学んだことが全部完璧なものではないし、これをやれば絶対上手くいくという保証はない
- 試す→振り返る を繰り返しして、チームに合った形にローカライズすることが大切
説明責任は理解している人側にある
- 学んだことをすぐやりたい気持ちは分かる
- 説明する相手より３日分進んでいるので、同じ温度感で進んでくれるとは限らない
さいごに
無事認定もらえました。ほっとひと安心。