開発プロセス再入門（10） page1 page2 page3
課題駆動型開発を提案します！

豆蔵 津田義史
2005/2/9

　実際にソフトウェア開発をマネージするときには、非常に多くの側面に注目しながら、プロジェクトの現在の状態を監視していかなくてはなりません。本連載では、特にビルドと不具合の追跡という側面に焦点を当て、なるべく具体的なプロセスを解説するように努めましたが、いかがだったでしょうか。今回は、ここまでに解説してきたプロセスを簡単にまとめ、皆さんが開発プロセスを改善するための具体的なアプローチを紹介します。

◆ 課題駆動型開発

　各ビルドのライフサイクルを、横軸に時間を取って図に表すと、次のようになります。

図1 各ビルドのライフサイクル

　 最初のビルド（Build #1）では、QAによるテストが行えるまでの品質に到達できないことが多いでしょう。図1では、便宜上プロジェクトが定期的にビルドをリリースできる状態になっていると考えてください。

　これは、毎週ビルドをQAチームにリリースしながら、ソフトウェアを開発するときの、各ビルド間の時間的な関係を示しています。このとき、1つのビルドの寿命は（1週間ではなく）2週間となります。例えば、第2週目では、開発チームはBuild#2を開発し、これと並行してQAチームはBuild#1をテストします。また、第3週目では開発チームはBuild#3を開発し、これと並行してQAチームはBuild#2をテストします。

　図1における横の矢印は、ビルドのライフサイクルを示しています。ビルドのライフサイクルについては第2回「反復開発の“反復”とは何をどのように反復するのか」で詳しく説明しています。図1は、第2回に示した図を略記したものです（第2回で示した図の［リリース前］が上図の［開発中］に、第2回で示した図の［リリース済み］が上図の［テスト中］に対応します）。

図2 第2回で示した図

　図1における縦の矢印は、QAが前のビルドを評価し、その結果を次のビルドの開発にフィードバックする様子を模式的に表しています。第8回「ソフトウェアの不具合を追跡するには」で紹介した、不具合（解決すべき課題）報告書のライフサイクルと対応するものと考えてください（ただし、不具合は解決されたと報告されたビルドで、QAがその解決を確認しなければなりませんので、上図の縦の矢印と、第8回で紹介した不具合報告書のライフサイクルは完全には対応しません）。

　このように、各ビルドをインプットとして解決すべき課題を発見し、これらの課題をこの後のビルド（＝実行可能なソフトウェア）で解決していくことによって、ソフトウェア開発を駆動するアプローチを、私は課題駆動型開発（Issue Driven Development：IDD）と呼んでいます。一口に「課題」といっても、いろいろな種類のものがあります。不具合報告書、リスク、ユースケース、テストケース、要求変更、機能、仕様などは、すべて課題の1つです。例えば、あるべき（なのに、いまは実装されていない）仕様を発見したら、この後のビルドでそれを実装するという形で解決しなければなりません。

　課題駆動型の開発におけるスタンスは、アーキテクチャ駆動の開発におけるそれとはだいぶ趣を異にしています。つまり、ソフトウェアの構造が美しいとか醜いとか、そういうことは関心の外にあります。ソフトウェアは動けばいいという立場で、すべての課題の解決を実行可能なソフトウェアで確認しながら開発を駆動します。いくらアーキテクチャが美しくても（そう主張したとしても）、動くものでなければソフトウェアとしての価値はまったくないからです。

　ただし、ソフトウェアの構造に注意を払う必要はない、というわけでは決してありません。課題駆動型の開発を導入したときでも、ソフトウェアの設計情報をチームでうまく共有するための工夫や、各画面を同じやり方で作成するためのソフトウェア構造の規格化・統一化のための作業が必要です。また、作った後に直すより、最初から正しいものを作る方が、安いコストでできるとはよくいわれることです。

　つまり、ソフトウェアの開発プロジェクトを構成する要素には、縦糸や横糸などの複数の軸が必要で、課題駆動型開発が注目する方向の糸だけでは、完全なソフトウェア開発の方法論を編み上げることはできません。といって、複数の方向の糸を同時に処理しようとしたり、学習しようとしては失敗します。ある立場に立って、ある側面から、1つの方向の糸に注目していかなければ、プロジェクトは絡まり、もつれ、混乱するばかりです。プロジェクトを多面的にとらえ、それぞれの側面を切り離したうえで、各側面の効率を向上させていくような視点を持つとよいでしょう（これはExtreme Programming的な考え方ですね）。課題駆動型開発のアプローチは、ソフトウェア開発の方法論を工学的に編み上げるうえで重要な軸を提供します。

1/3

INDEX
開発プロセス再入門（10） 課題駆動型開発を提案します！
	Page1 課題駆動型開発
	Page2 文書による、プロジェクトの状態のモデル化
	Page3 課題駆動型開発における文書のモデル

IT Architect 連載記事一覧

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）