BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル TDDはOCD(強迫性障害)の一種か?

TDDはOCD(強迫性障害)の一種か?

原文(投稿日:2017/09/15)へのリンク

私はテストを書くつもりはない、それはプログラマの仕事ではないからだ。

これは退職を決めた、ある開発者からの決別の言葉です。彼のチームのリーダが、自身の発見したコード品質に関する重大な問題に対処するため、TDDの採用を発表した2日後のことでした。これは2006年のことで、そのチームリーダとは、著名な開発者でテスタのJeff Langr氏です。Addison Wesleyが出版した書籍“Developer Testing”の序文の中で、氏はこの話を次のように公開しています。

ありがたいことにその後の10年間で、ほとんどの開発者が、自分のコードをテストするのは間違いなく自分の仕事である、ということを学びました。何らかの形式での開発者テストが論じられていないような、そんな職場に求職しようという人はいないでしょう。期待されているのは、ソフトウェア開発のプロフェッショナルとして、高品質な製品開発の一翼を担うことなのです。私はこの10年で、自分のコードをテストする必要がないと考えるような人を雇用する意思はまったくなくなりました。

アジャイル開発とDevOpsの時代にあって、開発者にはこれまで以上に、自身のコードに対してあらゆる面から – 品質からメンテナンス性、デプロイ性、スケーラビリティ、セキュリティに至るまで – 責任を持つことが求められています。“コーディング技術者”としてのプログラマから、顧客に価値を提供する組織の総合的メンバとしてのプログラマへという、この大きな転換の文化的側面を指摘した書籍は枚挙に暇がありません。

今回の記事では、この転換の一面として、テスタとしてのプログラマの心理的影響について取り上げます。

コードを実稼働環境にデプロイ可能にするというのは、開発者の責任のひとつです。これは、テストを実施してコードにある重要な問題を発見し、問題の所在を認めて修正し、共有コードベースに透過的な方法でコミットする、という作業とはまったく別の問題です。

あるいは別の方向から、誰かが“ビルドをブレーク”させた時に大きな画面にアラートを表示したり、さらにはサイレンを鳴らしたりするという、アジャイルチームの一般的なプラクティスを想像してください。このような経験をした開発者が、感情的な影響を受けるのは避けられないことです。

“評価不安”としての開発者テスト

テストは内省的かつ評価的なアクティビティになっています。開発者が定常的に自身の作業成果をテストします。身近な同僚や上司が自身の仕事をテストします。作業の問題を顕在化すべく、定期的なレビューが行なわれます。

もちろんこれまでにも、開発者のアクティビティを評価するQAチームは常に存在していました。しかし彼らは外部から、多くは“ブラックボックステスト”のパラダイムでそれを実施していたのです。また、QAテスタは、少なくとも過去においては、低賃金でレベルの低い従業員として雇用されたり、場合によってはオフショアされていたため、それが批評による影響を低減していました。

組織の食物連鎖のより高い位置にあって、コードを理解している開発者からの批評には、それらよりも相手を傷つける可能性があるのです。

不安は米国における精神疾患の最も一般的な形態であり、人口の18.1パーセントに影響を及ぼしています。その一般的なタイプのひとつが“社会と評価の不安(Social and Evaluation Anxiety)”であり、我が国において3番目に多い心理的障害になっています。これは“他者によって否定的に判断および評価されることへの恐れであり、不適正、恥辱、屈辱、憂鬱といった感情につながる”ものと定義されています。簡単に言えば、失敗に対する恐怖です。不安セラピストのThomas A. Richards氏は、次のように述べています。

‘恐怖に向き合えば解消します’とセラピストが言うならば、それは社会的不安のダイナミズムを理解できていません。私たちは生まれてから常に不安と向き合っていましたが、それにも増して不安な気持ちになっているのです。

テストのプラクティスが本格的な不安障害につながる可能性を示唆している訳ではありません(極端な場合を除けば、ですが)。しかしながら、現代的なアジャイルのテストプラクティスに参画しているプログラマの、大部分とは言わないまでも多くが、このような否定的な社会的評価の不安に直面しているように思われます。

このような不安は、開発者の健康に影響を与え、生産性に悪影響を及ぼし、長期的にはプロフェッショナルな開発を阻害する要因になるのです。

テスト駆動開発: 無意識の防御メカニズム?

アジャイル開発におけるTDDの価値と必要性が話題になっています。TDDは“赤/緑/リファクタ”に代表されるような、厳密なアプローチです。TDDでは、すべてのソフトウェアユニットの開発は、まずそのユニットを検証するテストから始められなくてはなりません。テストは当初失敗するが、機能が実装されることによってパスするようになります。そして、それ以降は、すべてのリファクタリングにおいてテストがパスし続けなければなりません。

2014年になると、TDDは死んだ、という声がよく聞かれるようになりました。TDDに批判的な立場を取るDavid Heinemeier Hansson氏は、TDDはクリアで予測可能なコードという桃源郷を約束してはいるものの、実際には悪影響を及ぼす場面においても開発者に追従を強いる教義になっている、と記しています。

しかしながら、年を追うごとにテストファーストのレトリックは声高で怒りのこもったものになり、ますます狭量になってきました。その原理主義の渦に巻き込まれて、真の福音に従わないことが悪であるかのように感じたこともありました。(...) 私も表向きには、必ずしもテストファーストを行なう必要はないと暗示するのが精いっぱいで、最悪の場合にはそのプラクティスを“正しい方法”としてサポートすることを続けてきました。

今は後悔しています。

自動化された回帰テストの欠如というこの業界の残念な状況を打ち破るために、直感に頼らない方法としてテストファーストを使用する必要はあったかも知れません。(...) しかしながら、私は長い時間をかけて、その設計のドグマを克服してきました。このアプローチがシステム設計の完全性に対して何を行なっているのか、厳しい目で見直すべきだと私は思います (強調は筆者)。

現在の狂信的なTDDエクスペリエンスが、ユニットテストの重視をもたらしています。健全なことだとは思いません。テストファーストのユニットは、中間オブジェクトと間接参照による不要に複雑なWebにつながります。(...) 真に恐ろしい、アーキテクチャの化け物を生み出すのです。サービスオブジェクトとコマンドパターンの密林、さらにそれ以上のものを。

多くの組織がテストパラダイムとしてのTDDに見切りを付けて、振る舞い指向開発(BDD)へと移行しているのは明白です。AtlassianのHeather Krebsbach氏は2016年に、はっきりと書いています。

このテストファーストのアプローチはますます普及して、テスト駆動開発(TDD)を作り上げました。しかし企業はすぐに、システムで最も重要なビジネスケースにおいて必要とされる、可視性やカバレッジが得られないことに気付いたのです。そこから振る舞い駆動開発(BDD)と呼ばれるTDDの亜種が生まれて、技術仕様よりもシステムの振る舞いを重視するようになりました。

“TDDが役に立たない”理由が淡々と説明されていますが、もう少し深く掘り下げてみましょう。David Hansson氏のことばを借りれば“狂信的”な、時に非合理的なプラクティスと、TDDは無益だとするKrebsbach氏の説明の組み合わせは、心理学的概念としての知性化(intellectualization)を連想させます。ウィキペディアによると:

心理学における知性化とは、無意識下の葛藤と、それにまつわる感情的ストレスの対立をブロックするために理由付けが使用される、一種の防御メカニズムです – ここでは感情(feeling)を避けるために思考(thinking)が使用されます。ストレスの高い出来事から自分自身を、感情的に引き離すためのものです。知性化は、不合理な行動の擬似合理的正当化を伴う場合がありますが、それと同じではありません。

コードの1行1行を“徹底的に”テストするプラクティスであるTDDは、コードに対する批判から開発者を防御するための無意識なメカニズムであった、とは言えないでしょうか?

これは厳しい意見であり、それがTDDのすべてであると主張するつもりはありません。しかしながら、TDDという方法論にはこのような感情的な意味が背景にあって、それが妥協のない、独断的な、時に近視眼的なその性質の原因となっているのではないか、と思われるのです。

BDDは感情的に健全なアプローチなのか?

BDDはTDDより優れているのでしょうか?この状況においては、そうかも知れません。振る舞い駆動開発はコードよりもビジネス要件を重視します。形式言語でアジャイルの“ストーリ”を記述して、開発チームがそのストーリをテストできるようにするのがBDDなのです。

これによって私たちは、特定の開発者によって記述されたコードをテストしたり、“ビルドを失敗させた”開発者を追求したりするような行動を離れて、チーム全体のパフォーマンスを評価する広範な活動へと向かうようになります。

結論として、アジャイルチームは、顧客に価値を提供する責任を共有しており、その価値は開発者とテスタ、運用担当者間のチームとしての努力であると言えます。BDDは、コードのユニットではなくストーリをテストすることによって個々の開発者の“感情的な高まり”を取り除き、チームが一体となって行なう“スクラムのレトロスペクティブ”のような、グループとしての内省的な活動へと変えるのです。

TDDとは、少なくとも部分的には、個々の開発者が自身のコードを正当化するための防御のメカニズムであったといえます。BDDはもっと健全なアプローチです。開発者がチームとして作業を評価し、そこで発見された欠陥について責任を共有することによって、評価不安を軽減し、感情的になることなく問題に対処することが可能になるのです。

テストカバレッジのより広い概念に向けて

アジャイルチームのテストカバレッジ向上を目標とするスタートアップのSeaLightsは、今日のアジャイル開発におけるテストメトリクスがしばしば曲解されている、と主張しています(免責事項:筆者はSeaLightsのアドバイザを務めている)。最も望まれるメトリックである“テスト/コードカバレッジ”は、ほとんどの場合において“ユニットテストカバレッジ”と同義として扱われます。これはつまり、ユニットテストがアジャイルテストの主要かつ最も重要な部分であると考えられていた、TDDの時代への退行を表すものに他なりません。

BDDの方法論によってテストはより広範かつ内包的なものになったのですが、テストメトリクスはそれに応じた進化をしていません。自動化UIテストや統合テスト、受入テストの利用は増えたものの、“カバレッジ”の測定には相変わらずユニットテストによってカバーされるコードの比率が使用されているのです。

ユニットテストのカバレッジは、BDDの世界においては、テストスイートの包括性を示す真の尺度でも、マネジメントがテストプログラムの有効性を評価するための指標でもありません。

コードカバレッジをより包括的に計測すると同時に、統合性やUI、受入テストについても考慮する必要があります。コードのすべての行を個別にテストしなければならないという、ある意味で強迫的な理由からではなく、アジャイルチームが担当するすべてのビジネス機能ないし“ストーリ”を確実にテストする、という方向に進むべきなのです。

包括的なカバレッジを計測し、その達成に向けて協力することが、開発者の不安を軽減する真の方法になります。それがコードの不備に向きあう上で、理性的に捉え、防止し、あるいは正当化しようとするよりも有効なのです。

著者について

Gilad David Maayan氏はテクノロジライタとして、先進的なテクノロジブランドが自社製品を新たなユーザに認知させる活動を支援しています。氏はAgile SEOの創設者兼CEOとして、開発者やITリーダシップ、および関連するコンテンツを検索エンジンを通じて収集しています。

この記事に星をつける

おすすめ度
スタイル

BT