TDDで「Red-Green-Refactoring」のエビデンスが必要ない理由

はじめに

コミュニティーや業務でテスト駆動開発(TDD)に関わる技術支援をする中で、

• 「開発者のローカル環境でのテスト結果を取得し、TDDのレッドとグリーンのサイクルをエビデンスとして記録したい」
• 「ToDoリストの進捗状況をTDDで記述するソースコード上のリビジョンと関連付けて残したい」

などの相談を受ける場合があります。

自分の素直な感情としては

「そういうこと、やりたい？」

というのがあるのですが、その感情の背景となるものをまとめたのがこのエントリーです。

チームのタスク管理と個人のタスク管理

ソフトウェア開発の現場でタスク管理を考える上では、「チームのタスクを管理する」という視点と、「個人のタスクを管理する」という二つの視点を統合することが必要です。

チームのタスクは、最終的にデリバリーする成果物を生み出すために、チームはどのように行動し、そこの中で発生するタスクをどのようにチームメンバーにアサインするかという観点で管理されるべきですし、場合によってエビデンスの提出や作業にかかった時間の記録などの作業が発生します。

それに対して、チームメンバーが作業を進める上での、チームのタスクより粒度が小さい、細かいリファクタリングや実装面での設計の検討など、個人がチームに対してアウトプットを提供するためのタスクは個人が管理の主体となるため、作業の進捗を促進できるよう、より軽量な手法が求められます。

チームとしてタスクを管理することにフォーカスし、個人に最大限権限を委譲するマネジメント手法の代表例がサーバントリーダーシップです。

それに対して、チームのタスクを管理することと個人がどのように作業を進めることを密に結びつけて管理しようとするのはマイクロマネジメントということになります。

ここでは、両者の優劣について論じることはしません。主にプラクティスを習得させるための教育のフェーズや、作業としての正確性が求められる局面で、作業手順書にしたがって作業させるためのダブルチェックなどの管理など、マイクロマネジメントが有効な局面もあります。

その中で注意すべきなのは、TDDはプログラミング手法として、個人を管理するプロセスであるとともに、テスト自動化を実現する方策としてのチームのプロセスでもある、ということです。

一ついえるのは、個人のやり方を統制しようとすればするほど、プロセスは柔軟性を失い、チームが取れる選択肢は狭まっていくということです。

コンウェイの法則を持ち出すまでもなく、組織としての作業単位の柔軟性のなさと、生み出されるソフトウェアのアーキテクチャーの柔軟性のなさは表裏一体の関係にあります。

TDDは、red-green-refactoringのサークルを、可能な限り小さなステップで、可能な限り素早く進めることを目指しています。

TDDで「仮実装」という茶番が存在する理由は、失敗しているテストを成功させるために、最短距離になる実装を目指した結果そのようなプロセスになっているのであり、TDDの実践者が禁欲的であるためではありません。

冒頭にあげたTDDのプロセスを管理しようとする試みは、そこにブレーキをかけることになります。

TDDは何を実現しようとしたか

「エクストリームプログラミング」に、以下の様な一節があります。

技術力は信頼関係につながる。作業を正確に見積もり、最初から品質の高いものを届け、高速なフィードバックループを構築すれば、あなたは信頼されるパートナーになれる。

エクストリームプログラミング

エクストリームプログラミングは主要なプラクティスとして「テストファーストプログラミング」を掲げています。「テスト駆動開発」ではこれを受けて、TDDが生み出す、「動作するきれいなコード」がもたらす価値の一つとして、

チームメイトはあなたを信頼し、あなたもまたチームメイトを信頼する。

ということをあげています。

テスト駆動開発

以上のことを踏まえれば、TDDを推進する上で必要なのは、TDDのプロセスが守られているかを統制的に管理することではなく、ステークホルダー相互の信頼を生み出すに足りる関係資本(Social Capital)をどのように生み出すことができるか、という点に着地します。

そのために必要なのは、組織として標準的に「TDDのプロセス」のようなものを定めることではありません。多様なスキルやバックグラウンドを持つチームメンバーの中で、多様性の混沌の中から最小限の合意を生み出そうとする営みが関係資本を生み出すのであり、TDDが小さいステップを繰り返すことでフィードバックループを生み出すスタイルをとっているのはそのこと近似性を持っています。