« TDD Advent Calendar 2011 | トップページ | [イベント] 告知 - わんくま同盟 勉強会 #20 「テスト & TDD ワークショップ」 (1/14, 名古屋) »

2011年12月25日 (日)

[TDD Advent Calendar jp: 2011] TDD とアジャイルを支えるバックボーン #TddAdventJp

このエントリは、TDD Advent Calendar jp: 2011の12/25 最終日のエントリーです。

前日は @aoki1210 さんのエントリ 「TDDに関する記事のリンク集」 です。
初日は @setoazusa さんの 「#tddbc の作り方」 でした。
全記事の一覧は、 ATND の募集ページ にあります。


はじめに、 ちょっと全体の感想やイキサツなどを。

こんな素晴らしい Advent Calendar になるなんて、 夢のようです。 取りまとめ役をやらせてもらった幸運に感謝、 です。
良記事ばかりですが、 その中であえてひとつ選ぶとするなら、 TDD する / しない (テストファーストする / しない)、 あるいは、 やるならどこまでやるか、 といったことをパターン化しようという @kyon_mm さんの試み 「TDD戦略 -TDDを導入し進化させる方法-」(12/23) を挙げたいです。 私にはまったくなかった発想なので。 (TDD の定義が Kent Beck のと違っている点は難ですが。)

さて、 そんな素晴らしい TDD Advent Calendar jp: 2011 ですが…

そもそもの発端は bleis 伯爵にダマされたんですよね~w

bleis: @aoo_niku TDD Advent Calendar?
posted at 2011/11/11 13:44:13
bleis: @linerlock んじゃぁ立てますか
posted at 2011/11/11 13:56:53
biac: で、これはどこ? w QT @gab_km: RT @bleis: @aoo_niku TDD Advent Calendar?
posted at 2011/11/11 20:11:43

てっきり bleis さんが立ち上げてくれてると信じたのに~~~ f(^^;


昨日までの記事で TDD の中身に関しては語りつくされた感もあるので、 最終日にあたるこの記事では、 TDD を支えるバックボーンの話をしてみたいと思います。

TDD は (それとアジャイルソフトウェア開発プロセスも)、 ソフトウェアの開発に特有の技法です。
ハードウェアの開発 (機械、 電子機器、 建築など) では、 できません。

なぜか?
それを知るためには、 少しハードウェアの開発プロセスを見る必要があります。

ハードウェアも、 ソフトウェアと同様で、 複雑なものをいっぺんに作ることはムリなので、 最初は大雑把に考えてそれからだんだんと詳細を詰めていって、 最後に個々の部品の設計へと落とし込んでいきます。 代表的なハードウェアとして自動車の製品開発プロセスを取り上げると、 次の図のような流れでやっています。

20110920_automobile_development_pro ※ この図は、 論文 「自動車製品開発のプロセスと組織(1)~1980 年代における国際比較分析」(東京大学藤本隆宏) 掲載の図1.1 「情報処理システムとしての製品開発」 に、 ソフトウェア開発と対比する注釈を付けたもの。

最初に 「1. コンセプト創造」 フェーズで、 「こんなモノが欲しいなぁ」 という概念を固めます。 ここではまだコンセプト (概念) ですから、 その表現はテスト可能だとは限りません。

次の 「2. 製品基本計画」 は、 ソフトウェア開発での要件定義~概要設計 (いわゆる外部設計) に相当するフェーズです。 コンセプトを実現するための外観 (クレイモデル)、 内部構造 (レイアウト)、 その他の要求仕様や目標値、 あるいは利用する要素技術の選択などをします。
ソフトウェア開発に当てはめると、 外観 = 画面設計、 内部構造 = アーキテクチャ、 要求仕様や目標値 = 機能仕様/非機能仕様、 利用する要素技術の選択 = フレームワークやサードパーティ製の部品の選定、 ということになります。

そして 「3. 製品エンジニアリング」 フェーズが、 ソフトウェア開発での詳細設計~実装~テストに相当します。
詳細設計では、 それぞれの部品のスペックを決め、 それをぎりぎりクリアできる部品の構造を考えて図面を描きます。 ソフトウェアでは、 クラスやメソッドの外部設計 (仕様) を決め、 実際にコーディングすることに当たります。
試作では、 実際に部品を製造し、 自動車を組み立てます (製品や量産車とは言わずに、 「試作車」 と呼ぶ)。 ソフトウェアではコンパイル・ビルドに当たります。
実験・評価では、 部品と試作車をテストし、 また、 実際の試作車を見て・使ってみてコンセプトや製品基本計画の妥当性を評価します。 ソフトウェアでは、 実験はテストに当たります。 評価は、 該当する言葉が無いかもしれません (プロジェクトオーナーやプロダクトオーナーが開発中のソフトを使ってみること自体が、 そもそも珍しい)。

ここまでの大まかな流れは、 ソフトウェアとわりと良く似ています。 しかし、 大きな違いも 2つ挙げられます。
ひとつめは、 「3. 製品エンジニアリング」 フェーズは、 何回か繰り返すということです。 機械設計は複雑な作業ですから、 一回で上手く行くとは (製造業では) 誰も考えていないのです。 最初から、 このループを5回とか3回とか、繰り返すことを計画します。 ソフトウェア開発では、 同じものを繰り返し設計~実装~テストするループを定義していることは稀です (純粋なイテレーティブプロセスが該当)。
ふたつめは、 部品詳細図面を描く前に、 詳細設計で必ず部品のスペックを決めること。 決めるのは、 一般的に設計者の役割です。 スペック (仕様) は、 テスト可能な要求の表現です (テストできない表現は、 コンセプト (概念) です)。 テスト可能なスペックを決めない限り、 機械部品のカタチや材質や表面処理方法などは決められないからです。 ソフトウェア開発では、 クラスやメソッドをコーディングする前に、 クラスやメソッドのスペックを決めることは稀です (Wモデルや TDD が該当)。

2つの相違点のうち、 後者は TDD が手本とするところです。 先にスペックを (自動テストという形で) 決めてからコーディングをしよう、 と。
※ 実際に Kent Beck がそのように発想したかどうかは分かりません。 おそらくは違うでしょう。

さて、 前者はどうでしょう。
「3. 製品エンジニアリング」 フェーズ (ソフトウェア開発では、 設計~実装~テスト) のループには、 ハードウェアとソフトウェアでは大きく異なる条件が存在するのです。

製造業では、 必要だと認識してやっている 「3. 製品エンジニアリング」 フェーズの繰り返しを、 なんとか減らそうと努力しています。 なぜか? それは、 試作もテストも、 コストと時間が掛かるからです。
3D CAD や、 それと連動する CAM の導入などで試作の自動化を進めています。 テストも可能な限り自動化しようと工夫してきています。 それでも全自動には程遠く、 また試作に掛かる時間も秒単位などには出来っこありません。 日単位、 週単位の時間が掛かります。 そこでなんとか繰り返しの回数を減らそうと、 製造業では物理シミュレーション技術や仮想化技術の導入を進めています。 バーチャルに試作とテストをこなせるようにしよう、 というわけです。

比べるにソフトウェアはどうでしょう?
製造業の試作に相当するコンパイル・ビルドは、 前世紀から自動化が進んでいます。 コンパイルは 100%、 ビルドも CI (継続的インテグレーション) をやっているところでは 100% 自動化されています。 しかも、 1回に掛かる時間は数秒からせいぜい数分程度と、 製造業に比べるととんでもなく短時間で終わります。
テストはというと、 これも自動化が実用になってきました。 CI をやっているチームでは、 少なくともロジック部分のテストは自動化できていて当たり前になっているでしょう。 UI を含めたテストの自動化も、 Web アプリケーションでの回帰テストや負荷テストは当たり前になってきています。 掛かる時間も、 ほとんどのテストで数秒からせいぜい数分程度です。

ようするに、 製造業の製品開発における 「3. 製品エンジニアリング」 フェーズはコストと時間が掛かるが、 相当するソフトウェア開発のフェーズでは設計以外の製造 (コンパイル・ビルド) とテストに掛かるコストと時間は (製造業と比べると) 極端に小さいのです。 ソフトウェア開発の設計~実装~テストは、 製造業とは違ってどれだけ繰り返しても (設計以外は) 苦にならない、 そういう特徴があるのです。 あるいは、 製造業のようにループの回数や時期をきちんと計画しておく必要も無いのです。

この特徴、 すなわち、 繰り返しを増やしても苦にならないことを、 開発プロセス全体に応用すると、 アジャイルソフトウェア開発プロセスが実現できます。 アプリケーション全体を多数のフィーチャー (あるいはユーザーストーリー) に分割し、 それぞれごとに設計~実装~テストを行っても、 繰り返しによるコストや期間の増大は発生しません。 (理屈の上では同じ作業はいっぺんにやったほうが効率が良いはずだが、 素早いフィードバックを受けて細かく軌道修正し大きな手戻りを減らして補っているとも考えられる。)

同様に、 クラスやメソッドといった製造業での部品に相当する部分でも、 クラスやメソッドのスペックを自動化テストとして記述~製品コードの実装~自動テストをちょっとずつ何度も繰り返す TDD が、 試作 (コンパイル・ビルド) とテストの繰り返しが苦にならないことによって、 成立しています。
これは逆の状態を考えると、 納得できるでしょう。 昔のようにコンパイルするのに何時間も待たされ、 テストのジョブを流すのにまた何時間もまたされるという状況だったとしたら、 TDD は可能でしょうか?

さて結論です。
TDD は (アジャイルソフトウェア開発プロセスも)、 ビルドとテストの自動化に支えられています。
ビルドとテストの自動化は、 そのためのソフトウェアが進化してきたこともありますが、 もっと根本的にはコンピューターの処理能力の増大に拠っています。 いくら優れた自動化ツールがあっても、 処理能力が足らずに何時間も待たされたのでは、 TDD もアジャイルもやってられません。 すなわち、 TDD とアジャイルを支えるバックボーンは、 コンピューターリソースなのです。

コンピューターの処理能力を生かす形で、 TDD (それとアジャイル) は登場しました。 これが真に正しい方向なのかは措くとしても、 コンピューターの処理能力が低い時代に生まれた手法に比べれば時代に即しているということだけは言えるでしょう。

最後に、 製造業出身の私から見たソフトウェア業界の感想を。
「製造業を見倣おうとするのはいいけれど、 製造業には出来ないことや製造業より進んでいるやり方を誇らないのは、 おかしい。」
その諸悪の根源は、 「コーディング = 製造」 だから 「製造は品質管理で不良0に出来るはず」 という妄執に囚われていることのように思えてなりません。 「コーディング = 設計」 であることを明確にし、 製造業の (量産ラインからではなく) 製品開発プロセスから優れている点は学び、 逆にソフトウェア開発の優れたやり方は誇ろうではありませんか。


余談、 というか宣伝 f(^^;

以上をネタにした短編小説が、 同人誌に掲載されます! (予定)

アジャイルマインド勉強会〜同人誌執筆者募集!

・ タイトル: 「アジャイルマインド」(仮)
・ 発行時期: 2012年3月予定

女子大生の愛瀰(えみ)ちゃんと年下のカレシが過ごす一夜、 はたして二人はアジャイルに辿り着けるのか!?

乞う御期待!!

|

« TDD Advent Calendar 2011 | トップページ | [イベント] 告知 - わんくま同盟 勉強会 #20 「テスト & TDD ワークショップ」 (1/14, 名古屋) »

*コラム」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: [TDD Advent Calendar jp: 2011] TDD とアジャイルを支えるバックボーン #TddAdventJp:

« TDD Advent Calendar 2011 | トップページ | [イベント] 告知 - わんくま同盟 勉強会 #20 「テスト & TDD ワークショップ」 (1/14, 名古屋) »