TDD.NET

　機械、 たとえば自動車を作るとしましょう。
　最初に新しい自動車のスペック (要件) を決めます。 自動車メーカーで量産車を開発する場合、 この時点でそのスペックのテストケースも決まっています。 たとえばスペック一覧に 「最高速度は 200km/h」 としか書かれていなくても、 それはたとえば 「1名乗車・光電管式速度計測装置搭載・燃料はタンクの××%・スペアタイヤ標準工具等搭載・谷田部の周回コースで同一周回中の直線2箇所での計測値の平均を取る…」 といった詳細なテスト方法を前提としたテストケースなのです。
　次に、 一台の自動車の設計をモジュールやアセンブリーといったいわばサブシステムに分解していきます。 量産車の場合はアーキテクチャはほとんど決まっていますので、 ここでの苦心は主にサブシステムが上手く物理的に収まるかどうかという、 物理法則に支配される機械設計ならではのものになります。 なお、 分解していくときに、 テストケースもサブシステム単位に分解し詳細化していきます。
　サブシステムはまた分解されていき、 最終的に部品単位のスペック (テストケース含む) まで分解されます。 そうしてようやく部品ごとに図面を描くわけです。 プログラムではコーディング作業にあたります。
　図面が描き上がると、 計算書などとともに上位者がチェックをし (詳細設計書とコードのレビュー)、 試作部門や製造メーカーに図面を渡して実際に部品を作ってもらいます。 部品が出来上がってくると、 個別に単体テストを実施するかたわら、 自動車として組み立てていきます (ビルド)。 組みあがったら (完成車と呼ぶ)、 簡単なテストから順番に完成車テストを実施していきます。
　ここまでが開発の 1段階、 プログラム開発で言うと 1イテレーション。 量産車開発の場合、 これを数回繰り返します。 また、 繰り返しごとにバリエーション (ボディタイプ・エンジン排気量・輸出先など) を増やしていきます。 インクリメンタル&イテレーティブなわけです。
　ちなみに、 イテレーション中に不具合が出ることがあります。 完成車テストを実施できないような不具合は、 もちろんイテレーション内で修正することになります。 図面通りに部品が作れない (コンパイルエラーのレベル)・完成車に組み立てられない (ビルドエラー) といった場合は、 大急ぎで図面を直して試作のやり直しを平身低頭お願いしにいくわけです。

　ざっくりと量産車開発の例を説明しました。 開発の初めからテストケースファースト (テストケースを先に作る) になっていることを強調しました。 テストケースが無いとネジのサイズひとつさえ決められないので、 機械設計ではあたりまえのことなのです。

　昔から 「ソフトウェア産業は製造業に学べ!」 というスローガンを叫ぶ人が後を絶ちませんが、 それで学びに行く先が自動車の組み立て工場というのはいかがなものかと思います。 自動車を組み立てる部分は、 ソフトウェア産業ではコンパイル・ビルドに当たりますから、 製造業より遥かに先んじて完全自動化とコスト低減を実現できているところです。
　それよりも、 新型車の開発において、 前述したようにテストケースファーストでやってるところとか、 現場・現物主義 (実際の環境で実際に動くプログラムが大事) だとかを見習うべきでしょう。

　さて。 製造業はテストケースファーストでやっています。
　しかし、 図面を描いて (コーディングして) から出来上がった部品をテストするまでには時間が掛かります。 ごく簡単な部品を自社の試作部門に手続きをすっ飛ばしてムリにお願いしても数時間、 通常の手順で試作メーカーに作ってもらうと、 数週間から数ヶ月にもなります。 これだけ時間が掛かるのでは、 テストケースをひとつ図面に反映させるたびに試作してみるなんて、 いくらやりたくたって出来ません。
　ひるがえってプログラム開発ではどうでしょう? 実際のモノ作り (コンパイル・ビルド) は、 完全自動化できている上に、 今やごく短時間で終わります。 テストケースをひとつコードに反映させるたびに、 製造してみて、 そのテストケースに合格するかどうか試してみることが出来るのです。 すなわち、 テスト駆動開発 (TDD) ですね。

　製造業出身の僕は、 製造業に居たときはやりたくても出来なかったので、 TDD に魅せられてしまったようです。