特集 .NET開発者のための開発プロセス入門（後編） .NET開発でアジャイルを導入するための実践テクニック 福井 厚 ＆ 小井土 亨 2004/12/22
Page1 Page2 Page3 Page4

数名のチームで導入できるローカル・ライトウェイト開発プロセス

　現在のソフトウェア開発では、さまざまな要因で変化が求められることがある。いままでのソフトウェア開発プロセスでは、できるだけこの変化を回避するための努力を繰り返してきた。しかし、変化を完全に予見するためには、予知能力を持つメンバーがチームに必要になる。もし仮に、予知能力を持つメンバーを確保できたとしても、最初から変化を加味したシステムを開発するための予算を確保することはさらに難しい問題である。

　このような状況で、アジャイル開発プロセスが選択した戦略は、変化を回避するために努力することではなく、変化が求められた場合、できるだけ素早く確実に変化に対応するというものである。

　そのためには、いままで忌み嫌っていた変化に対する意識を変えて、積極的に変化を受け入れるという意識改革が必要である。また、変化を予測して、必要とされるかどうか分からない機能をあらかじめ実装しておくということをやめ、その時点で必要とされる機能だけをシンプルに実装するという意識改革も必要となる。

■変化に対応するための戦略としてのプラクティス

　.NETのシステム開発でも、プロジェクトが複数のチームから構成されている場合はよくある。このようなケースでは、各チームが個別のサブシステムを担当することになることが多い。このような形態ならば、変化に対応するためのローカル・ライトウェイト開発プロセスを1つのチーム内だけでも部分的に導入することが可能になる。これを実現するために有効な戦略は、以下のようなプラクティスを導入することである。

1. 計画ゲームと短期イテレーション
　システムをいくつかの機能（タスク）に分割し、2週間から1カ月程度を1イテレーションとしてタスクを割り当てて開発を行う。

2. ペア・プログラミング
　常に、ペアでプログラミングを行う。ペアは、定期的に組み替える。

3. 自動テストと常時結合
　テスト・フレームワークを導入し、自動テストを行う。この自動テストとビルドとを組み合わせて常時結合を行う。

　次に、これらのプラクティスについて、その目的と実際の導入方法について、詳細に解説を行う。

■計画ゲームと短期イテレーションのメリットと実施方法

　ソフトウェア開発で発生する変化で、最も痛手の大きいものの1つは、機能が不要になるというものである。この変化が発生すると、その機能に関する作業のすべてが無駄になってしまうためだ。もし、すべての機能を1回のイテレーションで作成する場合、この変化へのリスクはまったく軽減することができない。

　しかし、機能分割を行い、部分的に作成する戦略を実践して、不要となる機能について作業が開始していないのであれば、ほとんど影響を受けないことになる。さらに、作成する機能の優先順位を開発者の視点ではなく、顧客の視点で決定すれば、必要とされなくなる機能の実装は後回しになり、さらにリスクを軽減することができる。

　このプラクティスを実施する場合、計画にコストを掛けてしまうと本末転倒となる。イテレーションの計画には、以下のようなタスク・カードの導入をお勧めする。

タスク 　 優先度 　 ストーリー 　 見積もり 　 内容 担当者 　 結果

イテレーションの計画に使うタスク・カード

計画にコストを掛けてしまうと本末転倒となる。イテレーションの計画には、このようなタスク・カードの導入をお勧めする。

　計画の策定では、優先度を基準にして、1回のイテレーションで実装するタスク・カードを選択する。選択したタスク・カードの作業量を見積もり、イテレーション期間内に収まるように調整する。直近のイテレーションについて見積もりを行うことで、見積もりがある程度明確で正直なものになる。各イテレーションが終了した時点で、見積もりと実際の結果を比較してその精度を確かめ、その後の見積りに生かす。

　短いイテレーションで少しずつ作ることは、常にシステムに対して変更を加えていることになる。この経験によって、プロジェクトのメンバーが変化に対する経験を積むことができる。この経験がシステムを変化させるときの勇気になり、変化の対応スピードを上げることが可能となる。

■ペア・プログラミング

　チームでペア・プログラミングを導入する場合、プロジェクト管理者やほかのメンバーから反発や冷笑を買う可能性もあるが、そのような場合には変化に柔軟に対応できるようになるペア・プログラミングのさまざまなメリットを開発メンバーに説明すべきだ。以下にそのメリットのいくつかを列挙する。

1.変更しやすいコードになる

　ペアでプログラミングを行うことで、最低でも2人のメンバーはコードを理解できていることになる。2人が理解できれば、ほかのメンバーも理解しやすい可能性が高い。コードを変更するためには、そのコードを理解することが絶対条件であるため、この理解しやすいということは、変更しやすくするための必須要件である。ペア・プログラミングは、特に、トリッキーなコードを排除するのに有効である。なぜなら分かりづらいコードを書こうとしても、パートナーがそのコードを理解しづらい（＝トリッキーだ）と思えば、それを指摘してくれるからである。

2.テスト・ファーストとリファクタリングが確実に実行される

　1人でプログラミングを行っているときには、さまざまなプレッシャーから、テストを先に書かずに、いきなり実装してしまいそうになることがある。しかし、ペア・プログラミングを行っていれば、パートナーの目や手を抜くことに対する指摘があるので、このような誘惑に負けることはない。また、ドライバよりふかんした視点でコードを見ることができるパートナーがいるため、リファクタリングすべき問題部分に気付くことがよくある。これらのメリットによって、プログラムは変更しやすい状態に保たれる。

3.システムに対する理解度が高くなり、リスクが軽減される

　ペアでプログラミングし、ペアを定期的に組み替えることで、チーム・メンバー全員のシステム全体に対する理解度が高まる。また、各部分について、最低でも2名の理解者がいることになる。これによって誰か1人が休暇を取ったとしても、的確にシステムを修正・変更することが可能になる。これは変更に対するリスクを下げることになる。

■自動テストと常時結合

　ここまで、イテレーションを繰り返すことについてのメリットを解説してきたが、デメリットもある。その中でも問題となるのが検査工数の増大である。イテレーションごとに検査を行うことになるので、初期のイテレーションで実装した部分についての検査は、その後のイテレーションの数だけ繰り返す必要がある。これは、大幅な作業工数の増大を意味する。

　そこで、実践しなければならないプラクティスに自動テストがある。自動テストとは、言葉どおり、人の手によるテストではなく、プログラムによるテストである。プログラムによるテストであれば、夜間に自動で実行することも可能であり、何回実行してもそれほどの工数増にはならない。Windows OSには、システム・ツールとして「タスク」という機能があるので、これを利用すれば定期的にプログラムを実行するのは非常に容易である。

　自動テストを行うためには、まず、チーム全員が同じように単体テストを作成する必要がある。単体テストの実装方法がバラバラでは、1つの自動テストにまとめにくいからだ。そこで、テスティング・フレームワークの導入が重要である。フリーのツールであるNUnitは、前述したように、属性ベースのテスティング・フレームワークで、非常に容易に導入できる。また、次期Visual Studio 2005でもユニット・テストの機能が提供される予定だ。

　自動テストを実施できるようになったら、次のステップは常時結合である。常時結合とは、常に最新のコードを基にシステムとテストをビルドして、自動テストを実行し、システムに異常が発生していないか常に監視できる環境を構築することである。

　もし、1日に2度このような監視を行うようにすれば、システムに対して何らかのインパクトを与える作業が行われた場合、その作業期間を半日に限定することができる。半日の作業範囲内であれば、その原因を特定するのにそれほど時間は必要としない。しかし、これが1週間、1カ月となると原因を特定する工数は増大してしまう。修正個所を見つけるのに1日、直すのは5分なんていうことは、よく聞く話である。

　常時結合に有効なフリーのツールにNAntがある。Visual Studio 2005では、MSBuildというビルド・ツールも提供される予定である。これらのツールを利用すれば、比較的簡単に常時結合を実現できる。常時結合が実現できれば、リファクタリングをより日常的に行えるようになる。

　Visual SourceSafeの変更をイベントとしてキャッチしてNAntを起動し、ビルド結果を的確に通知するようにできれば、このプラクティスはさらにスムーズに流れることになる。CruiseControl.NETというフリーのツールを導入すれば、このような環境を容易に実現できる。次の画面は、CruiseControl.NETを実際に実行した結果だ。

CruiseControl.NETのWeb画面でビルド結果を参照したところ

ローカル・ライトウェイト開発プロセスのまとめ

　今回紹介したプラクティスには相関関係がある。これらは同時に行うことで相乗的な効果が得られる。これらのプラクティスは、2人から数名くらいまでであれば、比較的短期間で導入できると思う。

　しかし、これらのプラクティスをすべて導入しなければならないわけではない。今回の内容を参考に部分的に導入したとしても、確実に変化への対応速度を上げることができると思う。

　可能であれば、小さいプロジェクトでテスト導入して実際に効果を体感してほしい。そして、うまくマッチしないプラクティスを変更したり、ほかのプラクティスを追加したりして、ぜひともアジャイル開発を実践していただきたい。

INDEX
	[特集] .NET開発者のための開発プロセス入門（前編）
	1．アジャイル開発プロセスが誕生するまで
	2．アジャイル型開発プロセスとは何か？
	3．.NET開発者がアジャイル開発プロセスを導入できない理由
	4．アジャイル開発プロセスの導入
	[特集] .NET開発者のための開発プロセス入門（後編）
	1．1人からでも導入可能なローカル・ライトウェイト開発プロセス
	2．単体テストの自動化とテスト・ファースト
	3．Mockオブジェクトとリファクタリング
	4．数名のチームで導入できるローカル・ライトウェイト開発プロセス

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）