テスト駆動開発とかんばんは似ている、とケント・ベック氏
コードを書くときにまずテストから書き始め、そのテストが通るようにコードを書くことで開発を進めていく「テスト駆動開発」。テストファーストとも呼ばれますが、この開発手法と、「かんばん」と呼ばれる、現場の進捗状況をかんばんによって見える化することで、開発プロセス全体の無駄をとり、価値の流れを作り出す手法には共通点が多い、というエントリ「TDD is Kanban for Code」をブログにポストしたのは、エクストリーム・プログラミング (XP) の考案者でアジャイルソフトウェア開発宣言の起草者の一人でもあるケント・ベック氏。
この2つにどのような共通点があるのでしょうか？
かんばんとテスト駆動開発
「かんばんの目的は、開発プロセスの中で価値の流れを最大化することだ」とケント・ベック氏。簡単にまとめると、かんばんでは看板を使って各工程を見える化することで、下流工程から上流工程に要求が伝わり、仕掛かりを最小化するといったことです。
かんばんについてはこれまでPublickeyの記事で何度か触れていますので、以下の記事を参考にしてみてください。
一方のテスト駆動開発は、次のような工程からなるとケント・ベック氏は説明しています。
- 新たなテストを書く
- テストに該当する中身のないコードを書き、まずテストを走らせ、失敗する。
- 実装していく
- テストに通る
- リファクタリングする
そして「もしもテスト駆動開発が、コーディングにおけるかんばんだったら？」と仮定し、次の質問を投げかけています。
- 製品にあたるものはなにか？
- （見える化するための道具としての）看板にあたるものはなにか？
- 生産工程とは？
- 製品の流れと、その逆方向になる要求の流れにあたるものはなにか？
- フィードバックループはなににあたるか？
看板にあたるのがテスト
ケント・ベック氏の答えはこうです。
- 製品にあたるのは、（プログラムの）振る舞いや機能である
- 看板にあたるのはテストである。
- 生産工程にあたるのは、コーディングとリファクタリングである
- フィードバックにあたるのは、テスト結果と努力である
コーディングにおける製品にあたるのが、プログラムの振る舞いや機能（原文ではbehavior and options）というのは、直感的に分かります。
看板にあたるのがテストであるとは、ケント・ベック氏は次のように説明しています。
The tests are the kanban cards in this system. Each one is a request for a change of behavior.
テストが看板にあたる。それぞれのテストがプログラムの振る舞いの変更を求めるからだ。
生産現場の看板が下流工程に上流工程からの要求を伝えているように、テストもその結果によって上流工程にフィードバックを提供していると理解できると。
In TDD, the programmer gets feedback in seconds about whether the logic implied by the test is the logic he writes.
テスト駆動開発では、プログラマはテストによってロジックがいいかどうかすぐにフィードバックを得ることができる。
ただし、かんばんにあたはまらないテスト駆動開発の要素もあるとも指摘しています。それは、テストが通ったあとのリファクタリング。テスト駆動開発をしているプログラマは誰でも、テストが通った後でもさらにリファクタリングをしてコードをきれいにしますが、それはかんばんの視点から見ると「仕掛かりを増やしている」ことになるだろうと。
From the kanban perspective, though, post-success refactoring is over-production,
「テスト駆動開発についての理解がまだ途上だからなのか、それともかんばんでの改善余地がまだあるのかは議論の余地が残る」としながらも、おおむねテスト駆動開発はかんばんにあてはまるとケント・ベック氏は結論づけています。
あわせて読みたい
