【翻訳記事】TDD: 目的と実践

目次

はじめに

今回は著者本人の許可をもらった上で、TDD: 目的と実践(原題は「TDD: Purposes and Practices」)を翻訳したので紹介します。

www.industriallogic.com

この記事はIndustrial Logic社のTim Ottingerが書いた記事です。Tim OttingerはClean Codeの執筆にも関わっています。

また、Industrial Logic社はAgileなどに関するコーチングやトレーニングを行なっている会社です。そのため、記事の中ではIndustrial Logic社のe-learningのコースの多くがリンクされていますが、それらの宣伝を抜きにしても、非常に良い記事だと思います。

これ以降は元記事を翻訳したものになります。


TDD: 目的と実践

テスト駆動開発(TDD)は、無駄な争い、遅延、動揺を招く方法と誤解されることがよくあります。

誤解や不正確な説明は非常に苦痛であり、開発者はフラストレーションを溜めて、時には実践全体が有害で無意味であり、「死んだ」と宣言することもありました。

f:id:nihonbuson:20201109091043p:plain
悪いTDDは死んだ。

おそらく、人々がこの重要な実践をより健康的で生産的な形で理解してもらうことができるでしょう。

TDDとは何ですか?

機械的には、TDDは非常に単純です。

f:id:nihonbuson:20201109092012p:plain
下の文章で説明したTDDの4段階の図

  1. テストで期待される動作をコードで実装していないために失敗する(マイクロ)テストを記述します。
  2. テストが成功するコードをすぐに記述します。図で示した赤​​い矢印に注意してください。失敗したテストがある場合、たとえ多くの変更を元に戻すことを意味しても、プログラマーの唯一の仕事はすべてのテストに成功することです。
  3. コードがこれまでの意図した機能を満たしていることを証明することで大胆になります。それによって、新しい機能が明確、意図的、明白な方法でコードに適切になるように、コードとテストを修正します。
  4. コードがきめ細かく動作し、すべてのテストが成功したので、コードをソース管理システムにコミットし、他の開発者が行った変更を取得します。すべてのテストはまだ成功しています。

TDDは単純な4ステップのプロセスであるため、ほとんどの人は必要なスキルとテクニックを過小評価していました。

  • リファクタリングをサポートするテストを書くことは、いくつかのテクニックを含むスキルです。
  • テストが成功するために必要なコードのみを書くには、かなりの自制心が必要です。
  • リファクタリングでは、コードの構造を変えながら常にテストが成功し続けるために、多くの技術スキルとコード構造のある程度の認識が必要です。
  • 他の開発者と継続的に統一するには、一種の社会契約が必要です。私たちは皆、他の人のコードがうまく書かれていて、すべてのテストが成功していることを当てにしています。

TDDの意図

TDDはプログラミングを衛生的に保つ仕組みです。継続的インテグレーションによるインクリメンタルでイテレーティブな開発をサポートしながら、コードを整然と保ちます。

ここでの整然としたという言葉は、乱雑さ、混乱、ちらかっていることがないことを示唆しています。

整然としたコードは、コードの臭い(Code smells)がないと表現でき、完全に間違っているわけではないでしょう。

コードの臭いとその改善方法を学ぶことで、大きな進歩を遂げることができます。私たちのCode smells albumと無料のcode-smells-to-refactoringsのチートシートは、あなたを良い方向に導くのに役立ちます。

コードの臭いだけに焦点を当てても、プログラマーが整然としたコードを書くことを理解することはできません。他にも必要なスキルがあります。

整然としたコードは、理解と修正が容易なコード(柔軟であり、さらなる開発を妨げないコード)として説明することを好むかもしれません。

今後のブログ記事では、良いコード編成とソースコードの信号雑音比(signal-to-noise ratio、SN比)に関するアイデアの組み合わせについて議論します。ここでは他にも取り上げたいことがあります。

インクリメンタル開発とは、定義されたすべての機能を完成させ、1つのパスまたはセッションですべての制約を収めようとするのではなく、一度に少しずつコードに機能や動作を追加することです。

機能を追加するたびに、チームにインクリメンタル開発を依頼します。アジャイルチームでは、できるだけ頻繁に新たなものを出すように計画しています。

イテレーティブ開発とは、既存のコードを見直し、必要に応じて手直したり、手を加えたりして、全体の設計を改善することです。

これらの再検討は、やり直すといった無駄ではなく、むしろ衛生的な無駄の削減です。私たちは学んだことを取り入れて適用し、すべての機能を考慮してコードが「最初から何をしていたかを分かっているように見える (Ward Cunningham氏の言葉を引用)」ようにします。これは、最初のバージョンが書かれて以来、追加または複雑化したもの、ドメイン知識を得られたものです。

継続的インテグレーションに任せることで、ソフトウェアの変更は、できるだけ早く(可能であれば1日に何回も)他の開発者と共有されます。

他の開発者とコードを共有するには、1日に何度も「安全」かつ「完成」(「完成」の値が小さい場合)である必要があります。そのためには、よりインクリメンタルなアプローチと、高速なテストによって提供される安全性が必要です。

自信を持って頻繁に見直し、修正、機能の追加をして、コードを共有することを安全に行えるような実践(作業衛生)がない限り、これらのふるまいはすべて危険になるでしょう。

これがTDDを行う理由です。TDDはこれらの開発者の行動に安全性をもたらします。

TDDはTestingですか?

一部の人々は、TDDはテスターが行うTesting手法だと思っている人もいます。

TDDは、ソフトウェア開発者がリファクタリング継続的インテグレーションを成功させるために使用する、ソフトウェア開発作業を衛生的に保つ仕組みです。

例に基づいたテスト分野がいくつかありますが、これらはすべて、意図したとおりに使われている良いものです。ATDDとBDDは、テスターを要件と設計の実践にシフトレフトして実行するのが最適かもしれません。リファクタリングをサポートする例に基づいた実践は、マイクロテストユニットテスト、場合によってはストーリーテストなど、最も詳細になる傾向があります。

純化しすぎではありますが、Testingは、製品の使用に対する適合性を評価または確認しようとする活動であると考えてください。それがTestingの場合、TDDはTestingではありません。

TDDは、システムが動いていること、または機能が明確に満たされていることを証明しません。TDDは、主にリファクタリングの条件を作るために存在します。そのためにテスト(マイクロテスト)を使っているからといって、それがTestingの実践になるわけではありません。

TDDの目標は、迅速なリファクタリングの環境を作り出すことであり、より高レベルのテストのほとんどは、実行が遅すぎてこの目的には役立ちません。

TDDサイクルは高速です。1時間に少なくとも12回サイクルを完了できなければ、TDDサイクルを使用する余裕がなくなるまで、作業の速度が低下することになります。私たちはそれを素早く行うか、(最終的には)まったくやらないかのどちらかになります。

UIレベルのテストは良いのですが、UIレベルのテストを実行するためには、アプリケーションのインスタンスとそのすべてのサポートサービスを立ち上げる必要があり、これらのテストは画面またはページの更新を待たなければなりません。これには長い時間がかかり、開発者が生産性を維持しながら1時間に6〜12回実行することはできません。

ストーリーテストやシステムテストはあまりにも多くのセットアップやサポートが必要になるため、2分またはコードの2,3行に1回実行できないという考えがあります。

つまり、TDDはプログラムが書かれた後にテスターができるものではなく、テスターの目的には適していないということです。しかし、テスターが発見する欠陥の数を減らすことができ、テスターがより大きな問題に集中することができます。

TDDはユニットテストを書くことですか?

TDDの目的はユニットテストを作ることであり、もちろん、ユニットテストの密度はコードカバレッジのパーセンテージで測定できると考える人もいます。これは誤りです。

ユニットテストを作成し、ソースコードのテストカバレッジを増やす方法はたくさんあり、そのうちの1つがTDDというだけです。

確かに、少しのコードを書いて、そのコードを通るすべてのパスをカバーするユニットテストを書くことによって、非常に良いテストカバレッジを得ることができ、多くの素晴らしいユニットテストを生成することができます。これらのテストは、コードが作成された後に書くことができます。なぜ違うのでしょうか?

実際、コードの完成後にテストを作成する(コードの検証に必要な一連のテストを正確に作成する)方が効率的かもしれません。TDD経由でコードを完成させ、TDDでは考慮しなかった状況をカバーするテストを追加していることが分かります。

ただし、TDDの目的は、ユニットテストを作成してテストカバレッジを増やすことではありません。これは起こりますが、それは付随的な作用でもあります。

ユニットテストを行うことは良いことであり(さらに高レベルのテストは素晴らしいことです)、チームから回避された欠陥を減らすことができますが、ここでの本当の目標は、コードをリファクタリングするための環境をすばやく作成することです。

TDDだけで良いのでしょうか?

システムが動くことを証明するには不十分であるため、TDDは役に立たないと主張する人もいます。TDDは小さな部品が確実に動くようにするには役立つようですが、組み立てられたシステムが正しく動作することを証明するには、ほとんど(またはまったく)役に立ちません。

彼らの言うことは正しいです。それがTDDの目的ではありません。

しかし、この論理を使えば、抗生物質線維筋痛症を治さないため、役に立たないと言うこともできます。同様に、ツーリング用の自動車も、道路があるところにしか乗れないので、無価値になります。

TDDがソフトウェア品質に対して完全に十分ではないと主張することは、ポイントを外しています。重要なのは、TDDは(うまくやれば)目的には容易に十分になりますが、その目的はシステムの十分性や正確性を証明することではないということです。

システムが正常に動くことを確認したい場合は、Testingが必要です。目的や原動力が異なるため、TDDとは異なります。

上記のTDDはTestingではないという議論を参照してください。

TDDは良い設計を強要しません

はい。TDDでアサーションが進むことについては納得しますが、優れた設計を強要することはTDDの目的ではありません。

TDDでうまく動けば、迅速なフィードバックで設計を修正できます。イテレーティブな作業およびインクリメンタルな作業は簡単に可能であり、粗悪な設計も短期間ではるかに優れた設計にリファクタリングできます。

TDDでは設計を行いませんが、設計を改善するための多くの機会を提供します。

実際、TDDサイクルのすべてのループには、リファクタリングのための時間が明示的に提供されています。その時間を利用しないと、リファクタリングが必要なのにリファクタリングされていないコードになってしまう可能性が高いのです。

TDDループを使い始めたからといって自動的にリファクタリングの使い手になるわけではありませんが、TDDプロセスは、これらのスキルを学ぶ機会を提供します(Refactoring albumでも説明しています)。

悪いテストはリファクタリングを妨げます

繰り返しますが、ここは完全に合意します。

悪いテストがあることは、テストがないことよりも悪い場合があります。

TDDサイクルを無意識にループすることで、すべてのテストとすべてのコードが完璧になるとしたら、それは素晴らしいです。私は初心者の前にTDDの図を投げて、立ち去ることができたら嬉しいでしょう。

しかし、TDDは一連のスキルと態度です。これらのスキルと態度は、実践と情報を通じて開発されなければなりません。

TDDを行う私たちのほとんどは、これらのスキルとテクニックをしばらくの間、勉強しなければなりませんでした。これらは明白で簡単なものではありません。TDDをどのように行うべきかについては、さまざまな陣営に分かれています。

我々はTDDにおける、いわゆる「アンチパターン」と失敗の方法を文書化しました。

ただし、TDDサイクルの中にはリファクタリングフェーズが含まれています。リファクタリングフェーズでは、テストと設計をリファクタリングできるため、長いセットアップ手順と脆弱なタイミングでの酷いテストに耐える必要がなくなります。

また、TDDは「テストを持つ」ことではなく、コードの変更や追加を迅速かつ簡単にするために必要なことを行うことを目的としています。

テストによって気分を害したら、切り捨てましょう。テストは、小さく、安価で、高速で、簡単に破棄できる必要があります。マイクロテストの書き方を学ぶことは、学ぶ必要のあるテクニックの1つです。これは、Microtesting albumで教えているテクニックです。

Twitter上のある批評家は、TDDはモックとフェイクに依存しているため、テストを数十回(場合によっては数百回)書き直さないとコードを安全にリファクタリングできないと指摘しています。もしそうであれば、TDDが必要とする方法でリファクタリングをサポートするために、フェイクやモックを使う手法を学ぶことをお勧めします。この手法は、さまざまなソースから学ぶことができます。もちろん、Faking and Mocking albumで教えています。

なぜ悪評が多いのですか?

悪評は主に正当に苦労した人々からのものです。彼らはブログやソーシャルメディアを利用して、どのように苦労したか、そしてなぜ彼らが気になる困難なことをやめたのかを説明します。彼らは他の人に警告することで、イライラする無駄な時間から救います。

これは私が同意する行動です。私は、酷いTDDをしたり、意図しない理由でTDDをするよりも、TDDをしない方がいいと思います。ひどいTDDをして、それが提供しない利益を期待しますか?酷そうですね。

TDDを上手に行うことを学ぶための素晴らしいリソースはたくさんあります。多くのブログ記事があります。Kent Beck, Jeff Langr, James Grenningなどの専門家によって書かれた、TDDを教える素晴らしい本がいくつかあります。また、youtubeやオンライントレーニング会社のビデオもたくさんあります。

さらに、Industrial Logicでは、レガシーコードを扱うためのヘルプを含む「The Testing And Refactoring Box Set」と呼ばれるボックスセットに、(上記のアルバムを含む)最高の学習の多くを収集しました。また、これらのリソースは、ライブのTesting and Refactoring Workshopsでも活用しています。

TDDがうまくいけば、リファクタリングをサポートし、継続的インテグレーションによるインクリメンタルかつイテレーティブな開発を可能にします。あなたがしていることがこれらの働き方を可能にできず、サポートしない場合は、自身やあなたのバージョンのプロセスを非難するのではなく、それを動かすテクニックを勉強することを検討してください。

TDDは作業衛生です。それは学ばなければならない多くのテクニックを含む包括的な練習です。それをうまくやることに投資すれば、配当を受けることができます。

初期のレビュアーであるJesusVega、Josh Kerievsky、Mike Rieser、Jeff Langr、John Borys、JennyTarwaterに特に感謝します。

今年もJaSST Reviewを開催します! #jasstreview

一昨年から始まりましたJaSST Reviewを今年も開催します。3回目の開催です!

本記事では今回の発表内容をざっと紹介していきます。読んだ上で興味がある発表がありましたら、ぜひイベントに参加登録をお願いします!

www.jasst.jp

目次

JaSST Reviewとは何か

JaSSTとはソフトウェアテストシンポジウム(JaSST)のことで、2003年から全国各地で開催されているテストのイベントです。全国で年間10回以上開催されています。

そしてJaSST ReviewはJaSSTの一つで、ソフトウェアレビューに特化したイベントです。

詳しくは以前書いた下記記事を参照してください。

nihonbuson.hatenadiary.jp

今回のJaSST Reviewのテーマ

今回のテーマは「レビュー対象へのアプローチ方法」です。

以下、JaSST Review'20のページから抜粋。

   「多くの気になることのうち、なぜその内容を指摘しようと考えたのか?」

   「気になることって、そもそもどのようにして出てくるのか?」

   「レビュー対象の中から、作成者に最初に質問した部分はどのように選択されているのか?」

このような質問をレビュアーにしたとしても、「なんとなく」と答えてしまう方が多いかもしれません。

一方で、明確な言語化はしていないものの、自分自身の頭の中では決まった方針があって、それをもとにレビュー対象にアプローチしているレビュアーもいると考えています。

このような、「レビュー対象へのアプローチ方法」「レビュー対象を探る際の狙い」について、今回は議論したいと思っています。

自分たちがとったレビューでの言動がどんな意図を持っているのか、改めて考えられるようなコンテンツになっていると思います。

以降、どのようなコンテンツがあるのか紹介していきます。(主に予稿集の原稿を読んだ感想)

講演1 : 専門書が出版されるまでの編集者の思考と行動 ~編集者はどのように校正・校閲しているか~

1つ目の講演は日科技連出版社の鈴木兄宏さんによる講演です。

鈴木さんは、JaSST Review実行委員の安達さんが書かれた『ソフトウェアプロセス改善手法SaPID入門』などの書籍の編集を担当した方です。

発表当日は、当時の安達さんとのレビューのやり取りも紹介してくれる予定です。

安達さんによる講演の紹介はこちら。

予稿集では「講演当日までお楽しみ」という内容が多くありますが、そのスライドページのタイトルを見ただけでもワクワクするものがいっぱいあります。

また、鈴木さんは「狩野モデル」で有名な狩野紀昭先生の下で論文を書かれています。その当時の狩野先生の言葉なども発表の中で出てくる予定です。

書籍出版という他業種の内容とはいえ、文章に拘りを持つ分野の具体的な例を持ったレビューのやり取りは、参考になるのではないでしょうか?

講演2 : ソフトウェア設計における意思決定とそのレビューの秘訣

2つ目の講演はウルフチーフの川島義隆さんによる講演です。

川島さんは、現在個人事業主として株式会社ウルフチーフを設立し、ソフトウェアアーキテクチャ設計に関する支援を行なっている方です。

また、JJUG等でも多く登壇されています。

有名なスライドでいうと、リクルートさんで行なっていた新卒研修の資料「現代的システム開発概論」やJJUG CCC 2018 Fallでの発表資料「思考停止しないアーキテクチャ設計」などがあります。

speakerdeck.com

www.slideshare.net

今回の発表では、垂直思考、水平思考といった人間の思考の話や、レビュー時によく出てくる事象とその対策について話していただきます。

川島さん本人からもこんな予告が。

以下のページの内容も事前に読んでおくと、より当日が楽しめるかもしれません。

scrapbox.io

事例紹介1 : 刺激語カードを用いたソフトウェアレビューの実践について ~アイデアを刺激し意識外から観点を得る

今回から新たな取り組みとして事例募集をしました。(本ブログでも、事例募集に関する記事を書きました

結果、多数の応募の中から2名の方に発表していただくことになりました。

1人目の発表は、エムスリーの中塚裕美子さんによる講演です。

今回の発表では「刺激語カード」を用いて、観点を得ていくやり方での事例を紹介していただきます。

刺激語カード自体は、レビューやソフトウェアテスト以外の分野から持ってきたアイデアのようですので、どのようにレビューに応用して使っているのかなども発表されるのかなと期待しています。

また、この発表については既に紹介記事がありますので、そちらも参考にしてください。

www.m3tech.blog

事例紹介2 : レビューイの力を引き出すフィードバックのチューニング~チーム外からの支援で見えてきた、成熟度に応じた「問いかけ」の調整方法と各種レビューへの適用可能性

2人目の発表は、グロース・アーキテクチャ&チームスの常盤香央里さんによる講演です。

今回の発表では、チームの成熟度によって問いかけの方法を変えていくという事例を紹介していただきます。

レビューの時はもちろん、普段のチーム内の会話でも活かすことができる、問いかけ方法の考え方かなと思いました。

常盤さん本人による講演の紹介はこちら。

事例紹介のお二方は事例投稿募集なので、講演内容の依頼まではしていませんでしたが、今回のJaSST Reviewでのテーマである「レビュー対象へのアプローチ方法」に沿った内容になっているようで大変嬉しいです!

おわりに

今回のJaSST Reviewでは以上の4名の方の発表をお届けします。

またイベントの最後では、鈴木さん、川島さん、私の3人がパネリストになってパネルディスカッションをすることで、さらにレビューについて深掘りしていきたいと思います。

まだまだ参加登録募集中です。気になる方がいましたら、参加申し込みをお願いします!

www.jasst.jp

#RSGT2021 では開発にテスト活動を浸透させる話を発表したい!

現在の会社に転職してから、QAと開発の在り方について今まで以上に考えるようになりました。

また、今年に入ってからは、その考えを社外でも発表するようになりました。

2月にあったDevelopers Summit 2020では、「テストコードを書き始める前に考えるべきテストの話」と題して発表しました。この発表では、開発者自身がどのようにテストを考えていくべきかの基礎的な部分をお伝えしました。

結果、たくさんの反響をいただき、また何社の方から講演のお声がけもいただきました。

6月にあったScrum Fest Osaka 2020では「Agile Testingのエッセンス」と題して発表しました。この発表では、開発者とQAがどのようにコラボしていくのか、事例を含めてお伝えしました。

発表後には、複数の現場から「実例マッピングを使ってるよ!」という声をいただくようになりました。

今月あったD3QAでは「テスト活動の納得感を持ってテストケースを激減させた話」と題して発表しました。この発表では、QAがテスト技術を用いつつ、どのようにして開発チームに近づいていったかという話をしました。

結果、配信していたYoutube liveでは数百人の方に視聴していただき、たくさんのポジティブなフィードバックもいただきました。

そして、ここまでの発表を踏まえて、私は来年1月にあるRSGT2021のプロポーザルを提出することにしました。

発表タイトルは「Scrumチームに「テストは活動だ」という意識を浸透させるまでの物語」です。

ここまでの発表では、開発者自身のテストの話、開発者とQAのコラボの話、QAチームの話をしてきましたが、そのどれとも違う視点での話になります。

「テスト=TDD」というような認識を伝えたいのでも、テストを作業としてこなすやり方を伝えたいのでもありません。

創造的な活動としてテストを考えることで、開発実装前から、設計よりも前からテストの活動を行うことができます。それにより、以前よりも品質の良い&コストのかからない製品を作り出すことができます。

今回はそのようなやり方を紹介するだけでなく、どのようにその考え方を開発者に染み込ませていったか話す予定です。(ちなみに、「伝えた」のではなく「染み込ませた」のがポイントです)

この発表が気になる方は、下記プロポーザルのページへ行き、タイトルの下にあるハートボタンを押していただけると嬉しいです!

confengine.com

9月末までの投票となっておりますが、よろしくお願いします!

レビュー時のアプローチを考えてみませんか? #jasstreview

今年もJaSST Reviewを開催します!

jasst.jp

今年のテーマは「レビュー対象へのアプローチ方法」です。

この「アプローチ」についてもう少し考えてみましょう。

アプローチとは何か?

weblio国語辞典には以下のように書かれています。

①ある目的のために人に近づくこと。親しくなろうとすること。

②学問・研究などの、対象に接近すること。また、接近のしかた。研究法。 「歴史的な観点から-する」

レビューについて言えば、「どのように問題点に近づいていくか」を考えることかなと思っています。「問題点に対してすぐに指摘できる」ではありません。

歯医者を例に考える

歯医者さんとのやり取りは、問題へのアプローチそのものだと思っています。

歯が痛くて歯科医院に行った時、歯科医院に着いてすぐに歯を抜くことはありません。

以下のようなプロセスを踏むと思います。

  1. 患者に現在どこが痛むのか聞く
  2. 全体的に歯を見て、どこに虫歯があるのか見つける
  3. 今後の方針を患者と相談して、治療する順番を決める(複数の虫歯があった場合)
  4. 歯のレントゲンを取り、虫歯が神経まで届いているのか確認する
  5. 患者の反応を見ながら虫歯の治療を行う

f:id:nihonbuson:20200722190236p:plain

これにより、32本の歯から徐々に対象の歯を絞っていき、虫歯の状態をだんだん明確にしています。

その際には患者とのコミュニケーションを取ることで、治療の優先順位も決定しています。

これはまさに問題(虫歯)に対して近づいていく(アプローチする)行動そのものです。

このアプローチでは、現在の歯のレントゲンというデータだけでなく、どの部分で患者が痛みを感じているのかなどの反応を見つつ、麻酔が必要かなどを判断していることが分かります。

レビューの場合に当てはめて考える

レビューの場合でも、たくさんのレビュー対象から問題がありそうな部分を絞っていき、問題点をだんだん明確にします。

もちろん、レビュー対象物だけでなく、レビュー対象物の作成者とコミュニケーションを取ることで、解決すべき問題点を見つけたり、優先的に伝えるべき内容を探っていきます。

ただし、歯科医院の場合と違い、どのようなアプローチで問題点を見つけるのか、レビュー対象物の作成者とどのような会話をするのかなどは定かではありません。

このJaSST Reviewというシンポジウムを通じて、レビュー対象へのアプローチ方法について考えていきたいと思っています。

JaSST Reviewでは事例募集をしています!

この「レビュー対象へのアプローチ方法」という話は、まだまだ未開拓の地だと感じています。その一方で、多くの現場ではレビューを行なっていると思います。

そこで、皆さんの現場で行なっている、レビュー対象へのアプローチ方法について事例募集をすることにしました!

締め切りは今月末となります。

参加者の方々と共有して、レビューについて改めて考えてみませんか?

「そんなに新しいことやってないし…」と思っている人へ

大丈夫です。この部分は未開拓の地なので、事例発表をする人なりの言葉で語ってもらえれば、それは他の人にも発見が多いと考えています。

つまり、すでに色々な考え方や技法があるテストや開発の分野に比べて、すぐに新規性のある発表になります!

「事例発表をしたいけど、まだ発表内容が固まってない…」という人へ

まずは「事例発表したいと思っている」と言ってもらえる(ツイート、DM、直接口頭でこっそり教える)と助かります!*1

また、何回も応募して内容をどんどんブラッシュアップして頂いても構いません。

皆様からのご応募をお待ちしております!

*1:運営は「何人応募してくれるのかな…?」と不安でいっぱいです

「テスト駆動開発の『駆動』は誤訳なんじゃないか」と言われて改めて考えた話

先日、社内のSlackでこんなことを言われました。

f:id:nihonbuson:20200628162510p:plain

TDDとかのdrivenを駆動って訳すの誤訳じゃないのかと思うんですけど、どう思いますか?

意味合いは駆動より操縦とか運転なんだと思うんですが

そこで「駆動」の意味を改めて考えてみました。

辞書で調べてみる

goo辞書では以下のように書かれています。

[名](スル)動力を伝えて動かすこと。「四輪駆動」「駆動輪」

書籍から考える

書籍『エクストリームプログラミング』の第2章には以下のように書かれています。

「運転というのはね、車を正しい方向に走らせることじゃないの。常に注意を払って、こっちに行ったら少し戻して、あっちに行ったら少し戻して、そうやって軌道修正していくものよ」

これがXPのパラダイムだ。注意して、適応して、変更する。

なぜ「駆動」が誤訳だと感じてしまったのか

テスト駆動開発(TDD)は「test-driven development」の略であるように、直訳すると「運転」が当てはまる気がします。

書籍『エクストリームプログラミング』の話にあるように、ここでの「driven」は微調整を繰り返すことこそが重要に感じられます。*1

一方で「駆動」だと、「動かす」というニュアンスが強くなり、「微調整を繰り返す」という意味合いが薄くなっているように思えます。

もしかしてリファクタリングが蔑ろにされる理由の1つ?

さらに最近では「テスト駆動開発=テストをきっかけとして開発を行う」という認識の人も出てきているように感じます。*2

昨年のSelenium Confでのt_wadaさんの講演では、リファクタリングが行われなくなってくる理由について、次のように語っていました。(t-wadaのブログより引用)

黄金の回転を構成するひとつひとつの矢印が、単一の目的を持ち、十分な長さを持ち、 きちんとした軌跡を描いて回転している限りは、テスト駆動開発は大きなパワーを発揮し続けます。

しかしテスト駆動開発の回転がもたらすパワーは、矢印のどれかが傷つき短くなっていくことによって、だんだん減っていきます。

では、3つの矢印のうちで、最も打たれ弱く傷つきやすい矢印はどれでしょうか。みなさんは、どう思いますか?

一番弱く傷つきやすいのは、リファクタリングの矢印です。

(中略)

外発的であれ内発的であれ「きれいにしている時間はない」「リファクタリングしている時間はない」などと焦燥感に駆り立てられると、 リファクタリングの時間が短くなったり、リファクタリングが先送りにされ始めます。 リファクタリングの矢印は弱く、折れたり短くなったりしやすいのです。

f:id:nihonbuson:20200706183413p:plain

もちろん、焦燥感によってリファクタリングが行われなくなることは十分ありえます。

ただそれだけなく、「テスト駆動開発」という言葉自体が、リファクタリングという微調整を繰り返す意味を無くしてしまっていることも原因のように思えます。*3

都合の良いように解釈しているだけ?

いや、ちょっと待ってください。

もしかしたら「微調整を繰り返す」という意味を「駆動」という言葉から無くしているのは、都合の良いように解釈しているからかもしれません。

「駆動」の元々の意味は、最初に書いたように「動力を伝えて動かすこと」です。これは「微調整」や「きっかけ」などの場面に限定した意味ではないはずです。

とするならば、いつからか「テスト駆動開発=テストをきっかけとして開発すること」と認識してしまい、そこから逆算的に「駆動=きっかけ」という本来の意味とは少し異なる考えに至ってしまったのかもしれないです。

改めて「テスト駆動開発」の意味を考えてみよう(+宣伝)

私はこの一件で、改めて「テスト駆動開発」というものを意味から考え直すことができました。

皆さんも「テスト駆動開発」とは何か、改めて考えてみませんか?

そもそも「テスト駆動開発」を知らない、やったことないという人は、8/1にTDD Boot Campが久々に開催されるので、そちらに参加して体験してみてはいかがでしょうか?*4

peatix.com

追記

記事を公開したら早くもフィードバックが!ありがたやー。

確かに「driven」と受動態になっている以上、「テストに駆動される開発」と考えた方が良さそうですね。

ただその解釈であっても、「駆動される」タイミングが新しいテストを書き始めた時だけの認識になり、リファクタリングのような微調整を伴う時の認識が薄れているなーという思いは変わりません。*5

確かにそうですね。「誤認の可能性がある」という方が納得感があります。

ただ、発端となった社内の人の発言は「誤訳」なので、記事のタイトルはこのままでいきます。

*1:書籍の例はXPの話であり、TDDに限定した話を示したわけではないですが、TDDにも通じる話のように思ってます

*2:「テストをきっかけとして開発を行う」はテストファーストな開発ではありますが、テスト駆動開発ではないのでは?というのが私の考えです。

*3:「誤訳」ではないが「誤認をしてしまう恐れがある」といったところでしょうか

*4:自分が参加した時のレポートこちら

nihonbuson.hatenadiary.jp

*5:認識が薄れている理由が「駆動」という単語のチョイスではなく、都合の良いように解釈した結果であることは、元の文章でも書いた通りです。

銀の弾丸には時間軸も存在する

最近、周りで銀の弾丸を提供しようとしている人が散見されたので、思ったことをつらつらと。

銀の弾丸を求めるな」というのは、「どんな場合でも活用できる万能なプラクティスなんて無いんだよ」という話だけではないと思ってます。

普段から同じプラクティスを使っている場合に、「本当にそのプラクティスが適切か常に見つめ直す必要があるんだよ」ということを伝えてるような気もしてます。つまり、「昔も今も未来も同じプラクティスを当てはめている=銀の弾丸」となっていないかと見つめ直すことも大事なのでは?という主張です。

『人月の神話』より

書籍『人月の神話』の第16章「銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項」の一節

現代のソフトウェアシステムでこれ以上還元することができない基本的要素に含まれる固有の性質

の1つとして、可変性が挙げられています。

ソフトウェア実体は、つねに変更という圧力にさらされている。

(中略)

大当たりしたソフトウェアはまずたいてい、すべて変更される。行われる作業は2つの工程である。あるソフトウェア製品が役立つと分かると、人々はもともと処理対象としていた領域ぎりぎりもしくはその領域を超えるような新しい使い方を試してみようとする。主として、拡張機能のために変更してほしいという圧力は、基本機能が気に入っていて新しい使い方を考え出す利用者から出される

次に、大当たりしたソフトウェアは最初に書かれた対象である機械機器(媒体)の通常の寿命よりも長く使用され続ける。新しいコンピュータが出てこないとしても、新しいディスクや新しいディスプレイ、新しいプリンタが出てくれば、ソフトウェアは成功する見込みのある新しい機器(媒体)に順応しなければならない。

要するに、ソフトウェア製品はアプリケーションや利用者、慣習および機械機器(媒体)といった文化的マトリックスにすっかりはめ込まれているのだ。そしてそれらは絶えず変化し続けるものであり、その変化がソフトウェア製品に容赦なく変更を強制するのである。

ソフトウェア以外のプラクティスでも同様のことが言える

『人月の神話』ではソフトウェアについて話していますが、それだけでなく常日頃行なっている様々なプラクティスに対しても同様のことが言えると思ってます。

例えば、Daily Scrum。

「前回のデイリースクラムから行ったこと・次回のデイリースクラムまでに行うこと・問題点を15分以内で話し合う」という風に言われてるけど、それって本当に適切なのかな?と疑問を持って良いはずです。*1

例えば、レトロスペクティブ。

「今までKPTでやってました。KPTを導入してみたら我々のチームではうまく行きそうだったのでKPTでやり続けてます。」と言ってたりするけど、それって本当に今でも適切なのかな?と疑問を持って良いはずです。

やっているScrumイベントや、構成しているチームメンバーが変わっていないとしても、適切なラクティスは日々刻々と変わるはずです。

それを無視して「それだったらこのプラクティスを使えば良いよ」と案にプラクティスを薦めるようなAgileコーチがいるとしたら、それはどうなのかなと思ってます。

病院での検診の例

例えば、病院での検診で考えてみましょう。

「どんな人が来ても、腹痛を訴えてきたら痛み止めを処方して終了」という医者は信用できないですよね?

ただそれだけでなく、「Aさんが来たら、腹痛を訴えた時には痛み止めを処方して終了」という医者も信用できないはずです。

同じ人が訴えているいつも通りの腹痛とは思ってたけど、ちゃんと調べたら実はガンだった、かもしれません。

「いつも通り」という思考停止

変化を見極めず、いつも通りというプラクティス*2を提供するような人は、医者でもアドバイザーでも信用できないと思ってます。 ただし、プラクティスではなく本質的な考え方はあまり変化せずに当てはまることが多いので、その部分は引き続き大切に持ち続けたいものです。(自戒を込めて)

*1:現に、2013年度版のスクラムガイドでは質問内容が改められ、2017年版のスクラムガイドではDaily Scrum実施時のオプションであり、別の方法でやっても良いとなっているようです。参考:スクラムで削除された5つのトピック

*2:思考停止の分類の中の「無意識の思考停止」に当てはまるのかも

Scrum Fest Osaka @Online 開催終了?しました #scrumosaka

6/26,27にScrum Fest Osaka@Onlineが開催されました。

www.scrumosaka.org

イベントは本番前から始まっていた…!

本イベントは開催前からdiscordを用いて運営の話し合いをオープンに公開していました。

そんなdiscordの場で私は、実行委員ではないにも関わらず無邪気に色々と絡ませてもらいました。

具体的には、新潟トラックのトラックオーナーとしてコンテンツ作成に携わった他、「フェスフェス」や「仕事してる」といったリアクションの絵文字を作成したりしてました。

f:id:nihonbuson:20200628154631p:plain
フェスフェス誕生の瞬間

少しでもイベントの盛り上がりに貢献できたのならば嬉しいです。

イベント開催、そして発表

イベント当日には、パネルディスカッションの登壇の他、発表も行いました。

発表資料は既にアップロードしてます。

speakerdeck.com

書籍『Agile Testing Condensed』の中で、特に伝えた方が良いなと感じた部分を中心に紹介しました。

また、以前にこのブログでも書いた「実例マッピング*1を実際に使った事例を、当時の会話込みでお伝えしました。

発表の聴講者からは「良かった」という感想を多くいただき嬉しい限りです!

イベントは終了した…のか?

イベント自体は6/26,27で、この記事を書いている時点ではすべての発表が終了しました。ですが、discordはまだ残っており、引き続き会話が行われてます。そして、講演の内容は動画に収められており、参加登録した方々はイベント終了後もその動画を見ることができます。*2

すべての発表が終わったにも関わらず、イベントが終了した感じになっていないのは独特な感じがします。

この余韻も含めて、Scrum Fest Osaka@Onlineはこれからのオンラインイベントの見本になるような気がしました。

とまあ色々と感じたことを書きましたが、このイベントの感想を一言で言うと「いやー、楽しかったーー!!」でした。

*1:実例マッピングの記事はこちらnihonbuson.hatenadiary.jp

*2:もちろん私の講演動画もあります!