先日、 David Bernstein 氏の 認定スクラムデベロッパー研修に参加し、Certified Scrum Developer（CSD）を取得しました。
５日間に渡る研修で、たくさんのことを学びました！
TL;DR
これでした！
今まで学んできたことが１つのストーリーのもとつながり、明確な目的を得ることができました。 何より、デベロッパーとして生きていく自信と勇気を、その方法と一緒にもらったように感じています！
お急ぎでない方向け：詳細
Agile, Scrum, XP
価値、原則、プラクティスのフラクタル構造
XPにおいて、価値、原則、プラクティスは以下のように説明されます。
価値（values）：達人が良し悪しを判断する高度な感覚。ある状況における好き嫌いの根源にあるもの
プラクティス（practice）：疑う余地のない、簡単に実施できる「良い行動」
原則（principle）：価値とプラクティスのギャップを埋める架け橋
価値とプラクティスの間には、大きな隔たりがある。価値は普遍的である。... 一方、プラクティスは状況によって大きく異なる。
-- Extreme Programming Explained 2nd Edition
目的なくプラクティスだけ実践していると、すぐにあらぬ方向に行ってしまう。 でも、価値は抽象的すぎて理解が難しい...と感じていました。
これを、中間に適度な抽象度の「原則」のレイヤーを置くことで
... このように、双方からより深く理解できるように感じています。
研修で教わったことも、このレイヤーに適応してまとめると自分的にしっくり来たので、冒頭の図が誕生しました。
プラクティスの中でも抽象度のレイヤーがあって、フラクタルを形成している... ような気がしています。
価値：変化に対応する - Agile マインドセット
世の中は複雑(Complex)で、その世の中でソフトウェアで価値を提供し続けるためには、 実験と探索的な活動ーつまり「変化し続けること」ーが必要である... というアイディアがいま自分の根底にあります。
これは Scrum Guide にある経験主義の説明とも合致すると考えています。
経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。
-- Scrum Guide
Agile Manifesto にも、「計画に従うことよりも変化への対応を」とあります。 もちろん他の価値と補完し合いながら、複雑な世の中でソフトウェアが価値を提供し続けるために必要なマインドセットを教わったと考えています。
余談ですが、ボブおじさんも Clean Architecture でソフトウェアの価値について以下のように書いていました。
すべてのソフトウェアシステムは、ステークホルダーに２つの異なる価値を提供する。それは「振る舞い」と「構造」だ。
ソフトウェアはソフトでなければいけない。つまり、簡単に変更できるようになっておくべきだ。
-- Clean Architecture
違うところで同じことを言っている物を見つけると、より真実に近づいているように感じて嬉しくなります。 （彼も Agile Manifesto にサインした１人なので、当然といえば当然なのかもしれません。）
Scrum と XP
懇親会の場で、 David にこんな質問を投げかけてみました。
「スクラム開発者に最も大切なスキルはなんですか？」
間髪入れず、 David はこう教えてくれました。
「XPだよ。」
これは自分にとっては目からウロコでした。
研修中、 David はよく言われる Build(do) the Right Thing と Build(do) the Thing Right を用いて、XPとScrumを以下のように説明してくれました。
- (探索的に) 適切なものを構築する ... Scrum
- (探索的に進めるための) 適切なやり方で構築する ... XP
たしかにいままでプロジェクト的アプローチで、数ヶ月に１度結合して結合試験してリリース...のようなやり方で開発していたチームに、いきなり「今日からスクラムやります！スプリント期間は２週間です！スプリント期間ごとにインクリメントを作ってください！」と武器をなにも与えずに初めても、「じゃあ設計スプリントやろう！」「結合試験スプリントをやってリリースだ！」... みたいになってしまうと思います。私はそんな経験があります...。
これを補完するため、スクラム開発者にはインクリメンタルにソフトウェアを設計・実装するスキルが必要で、その役割を担うのがXPである、と理解しています。
プラクティス：XPプラクィスと設計
TDDやデザインパターンを始め、多くの開発プラクティスを座学と実践によって学びました。
その多くは、今日では広く知られているものだと思います。 自分にとっても知っている/習得していると思っていた（と誤解していた）ものも多かったのですが、各プラクティスに対する解像度を高めることができました。 そして何より、全てのプラクティスをこの研修で定義された「価値」に関連付けられたことが大きな学びでした。
また、５日間の 1/3 ほどの時間をコーディング実習に使ったという点でも、非常に実践的でした。 コーディングはすべてペアプロで行い、ペアと議論しながら進めることで、より理解が深まったと思います。
TDD
よく言われるように、TDDという単語は人によってその意味するところが大きく異なります。 この研修では、TDDは「テストファースト である」ことと定義されました。
コーディング実習はすべて TDD で進めることが義務付けられ、TDDの良さを再認識できました。
TDDについては、以下が印象に残りました。
- TDDはテスト手法 ではなない
- デザイン の手法である
- テストもまたコード
- テストもリファクタ（クリーンアップ）せよ
- Unit とは一つの計測可能な 「振る舞い(Behavior)」
- 振る舞いのための簡単なシナリオ
- 安定なインターフェースとそのテストを手に入れた後は、小さい実装にはテストを付けずリファクタする
Unit Test is MUDA by Cope vs TDD is important practice by David
昨年 Jim Coplien 氏の CSM 研修を受けた際、「Unit Test is ムダ！」と一喝されたことが、強烈に印象に残っています。
「ほとんどのユニットテストは価値に寄与していなく、設計に良い影響を与えているという科学的根拠もない。」
このときは、「これは世の中の多くのデベロッパーが適切なユニットテストを実装するスキルがない、という証拠であって、ユニットテストが価値がないという証拠ではない」ーという具合に考えていました。 そして研修が終わってからも結局、「やっぱり必要だから...」と心の中で言い訳をしながら、同じようなUTを書いてしまっていました。
研修中、アギレルゴの川口(@kawaguti)さんに何気なくその話をしたところ、
「Cope の「ムダ」はTPSの「ムダ」。つまり価値を提供してないすべての作業のこと。これをどうやって減らすかを考えろ、と言っている。」
と教えていただきました。
一方 David からは、 TDD は２つの点で価値を提供していると教わりました。
- 動いていること、 Behavior を保証する
- 変更が容易なソフトウェアをインクリメンタルに、創発的につくる
結局、ユニットテストを書くことを目的にするのではなく、価値を提供するために必要なことに集中しよう、という点で、同じものを違う側面から見ている...のではないかな？ と考えています。
ペア/バディ/モブプログラミング
DevOps Days Tokyo の基調講演でもこの話をしていたと記憶しているのですが、 David に教わった大好きなメタファを紹介します。
マネジャー:「ペアプロ？やめたまえ。」「私のチームのリソースを半分にすることはできない。」
David: 「まず第一に、僕たちはリソースじゃない。」「一人では運べない荷物でも、２人なら運べる。ペアプロは、そういうことをやってるんだ。」
幸運にも、最近自分のまわりでは David の例のようなマネジャーとは遭遇していないのですが、 過去 SIer で働いてた頃は自分で「ペアプロやるとリソース半分になるよなぁ...」とか考えていました。 そんな体験から、このメタファはとても心に刺さりました。
私のチームでは、チームのデフォルトの働き方としてモブプロを採用しています。
martin-lover-se.hatenablog.com
その経験からも、「２人なら重い荷物を運べる」というメタファはとても納得感のあるものでした。
設計 - OOP, Design Pattern
オブジェクト指向完全に理解した、と多分人生５回めくらいに思いました。 そろそろ入り口くらいにはいるでしょうか...。
オブジェクト指向やデザインパターンについて新たな気付きや学びが非常に多くあったのですがとても書ききれません。 特に印象的だったのはこれです。
「デザインパターンは意図。UMLにも、ソースコードにすら現れない。」
研修の後、勧められた「オブジェクト指向のこころ」を読んで、研修で時間が足りなくて理解が浅かったパターンについても補完できました。 著者の Al Shalloway 氏は David 氏の師匠だそうで、この本の内容は研修にも色濃く反映されており、復習＆より理解を進めるのにぴったりでした。
その他感想とか
達人のメタファ
達人はメタファがすごいです。 聞く人を納得させ、かつ解像度を一段高めるような... そして何より、心に響き、心を動かします。
研修のフィードバックを何度か社内でやって、David と同じメタファを説明してみたんですが、全く響きませんでした。 達人は秀逸なメタファを作れることもそうですが、それを納得させるだけの含蓄ある言い回しやそれを支えるバックグラウンドがあってこそなんだな、と気付きました。
デベロッパーとして生きていく勇気
かれこれ１０年以上ソフトウェア開発に携わってきたなかで、プロマネ、エンジニアリングマネジャー、プロダクトオーナー... など、コードを書くこと以外でも様々なロールにチャレンジさせてもらってきたのですが、自分が一番得意なことはやっぱりコードを書くことだと感じています。
かたや年をとって、自分が超絶強いプログラマでも、その器でもないというのも痛感しています。 最も得意なところをせいぜい人より２〜３倍の速さで終わらせるのが関の山かな、という感覚で、コードを書くことだけにフォーカスしているとこれ以上はスケールしません。
ここにずっと後ろめたさというか、デベロッパーとして生きていく踏ん切りのつかなさを感じていました。
今回の研修を終え、自分はもっとデベロッパとして成長できる、という自信とともに、
今回得たような知識を伝えていくことで、自分が書いたコード以上の価値を生み出せるのでは？
チームや会社がうまくいくなら直接自分の手を通してでなくても構わなくて、これも一つのスケールの形なのではないかな？
と考えるようになりました。 同時に、それを実現するために必要なスキルや学ぶべきことも教わりました。
コードを書く時間や量の多寡は状況によって変わると思うのですが、自分はデベロッパーに軸足をおいてやっていくんだ！という勇気をもらったように感じています！
まとめ
今回の研修での最大の収穫は、今まで学んできたことが１つのストーリーのもとつながったことでした。 プラクティスを実践するとき、目的を持って正しい方向へ進んでいるという自信が持て、 また新しいことを学ぶ際にも今何故これを学ぶのか？を価値と原則に照らして判断できるようになり、更に学びの意欲が高まりました！
こうして振り返ってみても、いろいろな角度で自分のソフトウェアエンジニアとしてのキャリアや考え方に大きな影響を与えた研修でした。
当たり前ですが、資格自体には何の価値もありません。 Cope も「認定資格を取ったからといって明日からスクラムマスターになれるわけではない」と言っていたし、今回の研修でも、スクラムデベロッパーとなり、学び続けことを自分で認定しました。 研修で学んだことを咀嚼し、実践し、また学び続けるデベロッパーでありたいと思います！
５日間という長期研修であるためかなり高額なのですが、それを遥かに上回る見返りがありました。 David氏はまた日本でCSD研修をやりたいという旨おっしゃっていたので、また日本で開催されることを期待しています。 ソフトウェアエンジニアリングに軸足をおいてキャリアを積もうと考えている方に、投資先としてもおすすめできます！！
