テストの速さはどれくらい
Speed of Test
｢それゆえ暗闇の速度は光の速度より早いかもしれない｡光のまわりにいつも暗闇があるのであれば､暗闇は光の先へ先へと進んでいかなければならない｣
――エリザベス・ムーン著, 小尾芙佐訳｢くらやみの速さはどれくらい｣
はじめに
こちらは､ウイングアークAgile and DevOps Stories のAdvent Calendar 2020、第7弾（12月09日）の投稿となります｡
今年も去年同様､部門を飛び越えて､ウイングアーククラウド技術統括部MotionBoard Cloud技術部所属の中村が参加･投稿させていただきます｡よろしくお願いいたします｡
今回は､こちらSPQI部のご厚意でアギレルゴコンサルティング株式会社さま開催オンライン認定スクラムデベロッパー研修に､ Kentaro Arakawaさんとご一緒させていただくことができましたので､そのご報告も兼ねてStoryを書かせていただきたいと思います｡
オンライン認定スクラムデベロッパー研修とは
スクラムをうまく活用できる開発者になるための､アギレルゴコンサルティング株式会社さま開催のオンラインの研修になります｡今回は平日の朝8時から12時までの4時間を10日間にわたって､計40時間の研修でした｡
以下の記事でも取り上げさせていただいた｢レガシーコードからの脱却｣を著されたDavid Bernsteinさんを講師に､Zoomの同時通訳機能を用いての非常に濃密な研修となっています｡
実際の研修では
タイトルに｢スクラム｣の名を冠しているとおり､もちろん最初の数日間はスクラムでの開発についての話がメインとなります｡ウォーターフォール開発の問題点を洗い出し､対比させながら､スクラム開発における考え方のフレームワークや実践方法を学んでいきます｡
今回はオンラインでの開催であることや時間的にも限られているということで､これらスクラム開発に関する前半の講義は詰め込み形式が主でしたが､チームに分かれてのユーザーストーリーと受け入れ条件の設定等一通りの実践形式でのワークも行いながら､徐々に開発者向けのエクストリーム・プログラミングやオブジェクト指向プログラミングの実践へと入っていくような流れとなっていました｡¹
1: 途中から資料のスライドの”スクラム”の部分にバツ印がつくほどです
スクラムからオブジェクト指向プログラミング､そしてデザインパターンへ
先ほども出てきたウォーターフォール開発においては要求の変更は不可能､もしくは多大なるコストがかかってしまうのでした｡これはフレデリック・P・ブルックス Jr.がその著書「デザインのためのデザイン」でも看破しているとおり､｢人間の『罪』に起因｣するものであったり²､われわれ開発者の仕事がいままでにないものを作るという点においては発明でありほぼすべてが予測不可能であるためであって､結果として｢早すぎる段階で目標,要求,制約を確定することを強制され｣たり³､予測とは異なる出来事が起こり､結果としてその多大なるコストを支払うことになってしまいます｡
ただ､スクラム開発においてはそうした変更は最後の最後でも適用することができる､つまり重要な意思決定を最後にとどめておくことができるため､同じような抽象構造を持つことのできるオブジェクト指向プログラミングと相性がとても良いのです｡
そこで､この研修では､スクラム開発の講義から一歩進め､より開発者に向けたオブジェクト指向プログラミング､そしてデザインパターンの講義へと歩みを進めていきます｡
もちろんデザインパターンも銀の弾丸ではなく､必要ないほどパターンを適用してしまうと壊れやすくなってしまいます｡ですので､シニアアーキテクチャであるDavidが持っているそのトレードオフの感覚をもとに､デザインパターンの原則を学びながら一つ一つのデザインパターンを詳細に見ていきます｡
2: ｢一言で言えば,その答えは,傲慢,強欲,怠惰など,私たちの持つ「罪」に起因する。｣
3: ｢早すぎる段階で目標,要求,制約を確定することを強制される原因は,明らかに,組織内であれ組織間であれ契約が必要であるからだ。｣
ペアプログラミング､TDD､イテレーション
エクストリーム・プログラミングのプラクティスであるペアプロやTDDも､今回の研修ではふんだんに取り入れられています｡一通り座学によってこれらの説明を受けたのち､後半から始まる演習､研修内で｢ラボ｣と呼ばれているものでは､実際にペアプログラミングとTDDを用いた開発を､小さいイテレーション単位でこなしていくことになります｡
もちろんわれわれ開発者は普段の業務でもテストを書きます｡ただしそれはあとに書くのであって､そのようなテストは暗闇を進むような不安に抗うためのテストでしかありえません｡結局は暗闇のほうが先に存在するため､暗闇よりも遅い速度でテストを､しかも過剰なまでの臆病なテストを書くことしかできないのです｡
ここでのパラダイムは､そうではなく先にテストを書くことで､われわれに活力と自信を与えることになるというものです｡そうすることによって､適切なタイミングで､分割されたタスクを､すばやく実装していくことができます｡Kent Beckはその著書｢テスト駆動開発｣でTDDを井戸の歯車に例えていましたが､わたしにとっては緑色の光が不安の暗闇を超える速度であたりを照らしてゆくようになる､そのように感じ取れました｡
ここでは光はいつも暗闇より速い､暗闇の速さは問題にはならない｡
――エリザベス・ムーン著, 小尾芙佐訳｢くらやみの速さはどれくらい｣
……で､実際にどうなの?
非常に難しいです｡今回の募集要項には｢JavaまたはC#で簡単なプログラムを書く能力を必要とします。｣とあったのですが､ある種半端な開発を経験していないほうがこのパラダイムシフトにはうまくついていけるのかもしれません｡われわれ開発者というのは実装を考えることを生活の糧としているため､研修の最初の方では先に実装を書く､もしくは実装を見越したテストを書きがちになってしまいました｡
もちろんわたしも(先のDavidの｢レガシーコードからの脱却｣もそうですが)上述したKent Beckの｢テスト駆動開発｣など物の本は読んだことがあります｡ですが､読むのとやるのではまったく違うもの｡こうしたメンタルモデルのパラダイムシフトに追いつかずついつい講師のDavidに指導を受けるようなコードの書き方をしてしまうことも多かったです｡
また､ペアプログラミングについても同様で､今回はせっかくなので同じくウイングアークから参加していた Kentaro Arakawaさんとタッグを組んだのですが､自分が考えて自分がキーボードを叩くという､いままで当たり前だったメンタルモデルからの脱却は非常に困難でした｡
そして､今回この研修を受講させていただいた最大のメリットはまさにここにあるのだと思います｡やはり机上ではわからない､理解ではない体験を､実際のプロの開発者に見てもらいながら実践することができる､テスト駆動開発やペアプログラミングのサイクル､そのリズムを体感しながら添削していただけるというのは､本だけ､一人だけでは学べない貴重な経験でした｡
先ほども出てきたフレデリック・P・ブルックス Jr.の著書｢人月の神話｣でも自分自身の本を｢バイブル｣だと皮肉げに語っていましたが⁴､本を読むことと実践することの間には乖離があると思います｡わたしのように､本を読んだこと自体はあるが実際にそれらの原則やプラクティスを体験･体感したことがないという方はぜひとも参加していただき､それらが本当は何を語っていたのかを真に自分のものにしていただきたいです｡
4: ｢この本は『ソフトウェア工学のバイブル』と呼ばれている。なぜなら、誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである。｣
終わりに､でも終わらない
この研修の最後､スクラムデベロッパーとして認定を受けるための同意書のなかにこうありました｡
I realize Certification is the beginning of a journey, not the end.
この研修が旅の始まりであって終わりではないことを噛み締めながら､開発者としてさらに力をつけてゆき､微力ながらも緑色の光でみなさまを照らしてゆけたらと思います｡
あらためて今回このような貴重な研修に送り出していただいたSPQI部やMBC技術部のみなさまありがとうございました｡
いざアサートせよ 緑色の光あれ 我らJavaの騎士
――Jeff Langr, Andy Hunt, Dave Thomas著, 牧野 聡訳｢実践 JUnit｣
