 |
Insider's Eyeソフトウェア開発における“見える化”の活用方法とは？――アジャイル開発プロセスとTeam Foundation Serverの関係―― デジタルアドバンテージ 一色 政彦 |
|
|
先々月の8月末、ITプロ＆開発者向けカンファレンス「Microsoft Tech・Ed 2006 Yokohama」が開催された。その中で、主に.NET分野のアジャイル・コミュニティに所属するMVPを対象にした、アジャイル開発およびMSF（Microsoft Solution Framework）の開発プロセスに関する意見交換会（ラウンド・テーブル）が開かれた。
ゲストとして招かれたのは、米国マイクロソフトでMSFのプロセス・アーキテクトを務めるDavid J. Anderson氏だ。氏は書籍『アジャイルソフトウェアマネジメント』の著者でもある。本稿では、そこで交わされた質疑応答のいくつかをピックアップし、その内容を要約してご紹介しよう。
●アジャイル開発プロセスをマネジメントしていくうえで大切なことは？
プロセス管理を行ううえで、見える化（＝Visual Control）、つまりプロジェクトの進行状況をビジュアルにチェックするための仕組みは重要である。
その見える化を実践するのに、ホワイトボードを使うことはもちろん悪くはない。しかしチームが大人数になってくると、チームのみんながホワイトボードを見られるような大部屋を用意することは難しくなってくる。そこで電子化が必要になる。電子化された見える化の仕組みを自ら作り上げることも不可能ではないが、コスト面からいってマイクロソフトにライセンスを支払ってでもTeam Foundation Server（以降、TFS）を活用した方がお得であると私は思う。
●アジャイル開発においては、Visual Studio Team System（以降、VSTS）＋TFSよりも、NUnit＋CruiseControl.NETなどのオープンソース・ツールの方が使い勝手が良いように感じるが……？
アジャイル開発であっても、VSTSとTFSを組み合わせて利用することはとてもメリットが大きい。
例えばTFSならば、ビルド・システム、バージョン管理システム、自動テスト・システム、バグ・トラッキング・システムなど、さまざまな個所からの情報を網羅して1つのグラフに統合できる。コード・カバレッジのグラフ、アクティブなバグ数のグラフ、残存作業のグラフなどなど、TFSが提供する見える化の仕組みは、アジャイル開発プロセスのマネジメントで欠かせないものだ。
●それでは、実際にどのようにグラフを活用すればよいのか？ 何か具体的な例を教えてほしい。
例えば、次のようなグラフを利用することでリード・タイム（Lead Time。詳細後述）の予測ができるようになる（グラフの意味はグラフの下の説明を参照すること）。
 |
| リード・タイムを予測するためのグラフの例 |
| 縦軸は作業項目数の累積で、横軸が作業開始日から経過した週数である。「要求」はプロジェクトの全作業項目、「作業中」は現在、開発およびテスト中の項目、「完了」は単体テストとコード・レビューまでが終わった項目を示している。「リード・タイム」とは、「作業中」と同じ数の「完了」が達成さるまでの間隔を表す。TFSでは「残存作業」（Remaining Works）のレポートを活用することで、リード・タイムを測ることができるだろう。 |
このリード・タイムという考え方は、品質を確保するためには非常に重要である。
「リード・タイムが2週間を超えてしまうと、そのプロジェクトの製品には品質に問題があることが多い」ということを、わたしは発見した。例えば実際に、わたしは2004年ごろ、2つの開発プロジェクトにかかわったが（両者とも同じような開発規模と開発内容とチーム構成で、フィーチャ駆動型開発を採用したプロジェクト）、一方のチームはリード・タイムが1〜2週間、もう一方は3カ月だった。この2つのプロジェクトの成果物の品質（バグ率）を比べてみると、何と30倍もの差があったのだ（当然ながら後者の方が30倍品質が悪かった。具体的には、前者が100個のフィーチャ当たり3つのバグであったが、後者は100個のフィーチャ当たり100個以上のバグが発見されたのである）。
このこと（リード・タイムが1〜2週間であること）は、XP（Extreme Programming）の創始者であるKent Beck氏が提案している「イテレーションは2週間がいい」という内容（つまり、たくさんの作業項目を同時進行で開始してそのほとんどが長期間完了しないような状態にはせずに、2週間程度で開発が完了するような分量で徐々に開発を進めていく方がよいということ）と合致しているのではないだろうか（＝2週間のイテレーションで作業項目をちゃんと完了させられれば、リード・タイムは2週間ということになる）。なお現時点ではわたしは、「最良の品質を得るにはリード・タイムは1週間が望ましい」と考えている。
TFSなどの見える化の仕組み（グラフなど）を活用して適切な対応を取ることで（例えばリード・タイムを認識してそれを縮める努力をすることで）、プロジェクトを成功させ、成果物の品質を高められるようになるだろう。
■
今回のラウンドテーブルは通訳を介したため時間がかかり、残念ながらあまり多くの質疑応答が行われなかった。しかし、TFSが生成するグラフをどうやって活用すればよいのかが少し分かってきたことは、筆者にとって収穫だった。開発プロジェクトをマネジメントしてソフトウェア開発を成功に導くために、読者諸氏もTFSなどが生成するグラフを活用することを考えてみてはいかがだろうか。
 |
Insider's Eye |
- 第2回 簡潔なコーディングのために （2017/7/26）
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21）
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために （2017/7/19）
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator （2017/7/18）
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
