連載：Team Foundation Server 2008の下流工程への適用 第1回 チーム開発環境を無理なく導入するには？ アバナード株式会社　安藤 大祐（Microsoft MVP 2008 for Team System） 2008/10/28
Page1 Page2 Page3 Page4

■費用は高額だが、得られる効果は？

　TFSとVSSのどちらを導入するかを検討する際によく耳にするのが、「大規模プロジェクトの場合はTFSで、小規模プロジェクトの場合はVSS」というものである。大規模・小規模の定義の話になってしまうが、もしこれが開発人数のことを指しているのであれば、この判断はあまり正確な表現ではないと思っている。重要なことは、VSSとTFSを比較する場合、VSS＋手動管理や、ほかのツールなども合わせたALM全体のコストとして比較しなければならないことである。

　アプリケーションが「作って終わり」というものでなければ、明示的であれ暗黙的であれライフサイクルのための作業（変更要求管理やリリース管理など）は、どこでも行っているはずである。そしてそのALMに発生するコストは、開発人数というよりもプロジェクトの複雑さに依存する。

　例えば、アジャイル開発のように少人数で繰り返し開発を行う場合、人数は少ないかもしれないがウォーターフォール開発よりもはるかに高度なライフサイクル管理が求められる。また、初めは小規模からのスタートかもしれないが、徐々に発展して最終的にはかなりの大所帯になることもあるだろう。このように、単に人数で決めてしまうのは危険である。

　では、筆者の考えるTFS導入による効果を説明しよう。ALMの中でTFSを導入することにより特に大きく得られる効果を以下の3つの点から説明する。

1. プロジェクトの透明化
2. 並行開発のオーバーヘッドの削減
3. アプリケーションの品質向上

○1. プロジェクトの透明化

【問題】
　 プロジェクトの進行中は常に「プロジェクトは予定どおりに進んでいるか？」「計画を変更する必要はあるか？」「表面化しそうなリスクはあるか？」といった疑問に答えられなければならない。そしてこれらの疑問に答えるためには、日々データ収集や進ちょく管理を行わなければならず、ミーティングの増加や作業者に対する管理作業の負担増など、それに必要な管理コストも少なくない。

　また、情報の正確さという問題もある。後ろめたい報告はどうしても避けようとしてしまうものである。

【TFSにより得られる効果】
　 TFSでは、自動的なデータ収集の機能と収集した情報のレポーティング機能がサポートされている。これにより日々の作業（作業項目やソース・コードのチェックイン、自動ビルドや自動テストなど）がTFSの共通データベースに記録されるため、個々に作業負荷をかけず、かつ正確なデータを収集できる。そしてそれらの情報がTFSにより自動的に分析され、「残存作業」や「プロジェクト速度」、「品質指標」といったレポートをリアルタイムで確認することが可能となる。

図2　TFS導入によるトラッキング作業の変化

　以下は大まかではあるが、前述の仮想チームを基に、TFS導入により期待できる削減コストを示している。上記にかかわる管理コストの割合と人月の単価から計算している。

• マネージャー（人月単価：150万円）
  　 データ収集および進ちょく管理作業が占めていた割合：10％
  　 150万円 × 10％ × 12カ月 ＝ 180万円

• 開発者（人月単価：70万円）
  　 データ収集および進ちょく管理作業が占めていた割合：5％
  　 70万円 × 5％ × 12カ月 × 4人 ＝ 168万円

• 削減コストの合計：348万円

○2. 並行開発のオーバーヘッドの削減

【問題】
　 チームで開発している場合は、多かれ少なかれ並行開発は必ず発生する。大規模なシステム開発の場合は、サブシステムごとにチームが構成されるであろうし、地理的に分散することも珍しくない。また小規模なシステムの場合でも、リリース後は運用作業（例えばバグ改修）と拡張作業（例えば機能追加）は異なるサイクルで発生し、並行で作業する必要が出てくる。このように複数チームが並行して開発を行うような状況では、ソース・コードの管理（チーム間でのコード・ベースの共有、もしくは結合）に非常に大きなオーバーヘッドが発生してしまう。

【TFSにより得られる効果】
　 VSSと比較すると、TFSではより高度な並行開発機能がサポートされる。その1つが、複数ユーザーでの並行作業性の向上である。

　VSSのデフォルト設定では、ファイルをチェックアウトすると排他ロックが掛かってしまい、ほかユーザーの作業がストップしてしまうことが起きていた（マルチ・チェックアウトを有効にするには、プロジェクトごとに手動で設定する必要があった）。しかしTFSでは、デフォルト設定でマルチ・チェックアウトが可能になっており、同一ファイルに対する変更も自動でマージされるようになり、大勢のユーザーでの作業が安全かつ迅速に行えるようになった。

　またVSSの大きな欠点として、ブランチ／マージ機能の貧弱さがあったが（ブランチ処理の実行速度が非常に遅く、かつその後のマージ作業もほぼ手動で実施しなければならない）、TFSでは上述のとおり大部分を自動でマージすることが可能であり、かなり柔軟にブランチ機能を使用できるようになっている。

　また、地理的にチームが分かれて構成されている場合は、TFSはほぼ唯一の選択肢といっても過言ではない。通常このような場合は、VPNなどを経由し共有のリポジトリを利用するか、各ローカルのリポジトリに対して作業し、任意のタイミングでそれらを手動でマージするといった手段が取られる。前者の場合はパフォーマンス、後者の場合は手動マージ作業というリスクが存在し、どちらもリスクの大きさを考えると受け入れ難いものである。

　TFSでは、これらリスクを軽減するためのTFSプロキシと呼ばれる機能（正確にいうとサービス）が提供される。これは前述した2種類の手段を組み合わせた機能で、コード・ベースの共有をパフォーマンスの低下をある程度抑えて実現することが可能である。

図3　TFS導入による分散チーム開発の変化

　以下は先ほどと同様に、この効果で期待できる削減コストを示している（仮想チームは地理的に分散していない小規模チームを想定しているが、もし地理的に分散している大規模チームであれば、削減できるコストはさらに大きくなる）。

• 開発者（人月単価：70万円）
  　 作業の競合による待ち時間及びマージ作業の割合：5％
  　 70万円 × 5％ × 12カ月 × 4人 ＝ 168万円

• 削減コストの合計：168万円

○3. アプリケーションの品質向上

【問題】
　 アプリケーションの品質低下にかかわる問題は、どのプロジェクトでも頭を悩ませる問題である。品質低下の要因としては、プロジェクト内外にさまざまにあると思うが、プロジェクト内部で発生するものに限定して考えると、以下のような問題がある。（プロジェクト外の問題としては、スキルのある人員の確保などの問題が挙げられる）。

• 不透明な作業プロセス
  　 誰が何をどこまで行えばよいのかが明確になっていない、もしくは整合性が取れていない。このようなケースでは、作業者間の誤解や作業漏れが発生してしまい、結果的に品質が低下してしまう。

• 不用意なプログラミングと形骸（けいがい）化するレビュー
  　 ある程度動くプログラムを書くことは簡単だが、パフォーマンスやセキュリティ、保守性などの品質特性を考えたプログラミングは非常に難しい。コード・レビューによるチェックは解決方法として正しいが、きちんと品質特性も踏まえてチェックしなければ意味をなさない。

【VSTS＆TFSにより得られる効果】
　 不透明な作業プロセスに関する問題は、直接TFSで解決することはできない。まずはそのプロジェクト内で実施されるアクティビティ、ロール、成果物を明確化することが重要である。そのうえでそのプロセスを定着化、洗練化するためには、TFSのプロセス・テンプレートをカスタマイズし、定義したプロセスに適合させることができれば非常に効果的なものになる。

マイクロソフトが提供する開発指針「MSF」とは何か？

　プロセス・テンプレートとは、一連の開発作業で使用されるドキュメントのテンプレートや、タスクを管理するための作業項目、レポーティングなどの定義を含んだ開発標準テンプレートであり、チーム・プロジェクト（開発チームごとの管理単位。TFSには複数のチーム・プロジェクトが作成される）は、このプロセス・テンプレートを基に作成される。

　TFSでは、Microsoft Solutions Framework（以下、MSF）をベースとした、MSF for Agile（短期かつ小規模プロジェクトに適切）とMSF for CMMI（長期かつ大規模なプロジェクトに適切）の2種類のプロセス・テンプレートが用意されているが、既存のMSFのテンプレートを修正したり新規に独自のテンプレートを作成することもできる。（カスタマイズ方法の詳細については、MSDN「◆プロセス テンプレートのカスタマイズの概要◆プロセス テンプレートのカスタマイズの概要◆」等を参考にしていただきたい。）

【コラム】自社開発プロセス用のプロセス・テンプレートを作成しませんか？ 　自社で開発プロセスを定義している企業は少なくないと思う。しかし、その中で実際に正しく運用できているプロジェクトはあまり多くないと筆者は思っている。企業で定義される開発プロセスでは、対象としてさまざまな規模・特性のプロジェクトが求められるため、往々にして複雑になりがちである。そのようなプロセスを全体にわたって理解するのは難しく、その結果、目的や整合性を考慮せずに価値の低い成果物を作って、プロジェクトの工期を圧迫してしまう……。なんてことも想像できてしまう。このような状況を解決するために重要なことは、ルールだではなく、ルールに沿った動きに最適化されている“仕組み”を作ることであり、TFSのプロセス・テンプレートはそのような仕組みを構築することができる素晴らしい機能である。自社で開発プロセスを定義している企業は、是非ともプロセス・テンプレートの作成にチャレンジすることをお勧めしたい。

　不用意なプログラミングと形骸化するレビューについては、VSTS Development Editionで提供される静的コード分析機能やコード・メトリックを利用することで、品質に悪影響を与えるプログラムや、複雑すぎて保守性に影響のあるクラスなどを特定できる。これらをTFSのバージョン管理と連動させることにより、チェックイン前に必ず分析を実施しなければならないといった制約（チェックイン・ポリシー）を設けることも可能で、人間のレビューによるチェック漏れのリスクを大きく減らせる。

　この効果により期待できる削減コストを以下に示す。品質向上による間接的コストとして、プロジェクト全体の5％ほどの費用が削減できると想定している。

• マネージャー（人月単価：150万円）
  　 品質向上による改善率：5％
  　 150万円 × 5％ × 12カ月 ＝ 90万円

• 開発者（人月単価：70万円）
  　 品質向上による改善率：5％
  　 70万円 × 5％ × 12カ月 × 4人 ＝ 168万円

• テスター（人月単価：70万円）
  　 品質向上による改善率：5％
  　 70万円 × 5％ × 12カ月 ＝ 42万円

• 削減コストの合計：300万円

　以上がTFS導入による効果予測である。主要な3つのポイントによる改善効果の概算値は計816万円となり、およそ160％のROI（投資回収率）を想定できる。

　もちろん、ここで算出した値は筆者の経験上から導き出したものであって正確なものではない。プロジェクトによってその数字は大きく異なるであろう。ただ常識外れの値を設定したつもりもなく、TFS導入による効果の雰囲気をつかんでもらえたかと思う。

　TFS導入における動機付けの話はここまでにして、次からは、実際に導入するためのノウハウを説明していこう。

INDEX
	[連載] Team Foundation Server 2008の下流工程への適用
	第1回 チーム開発環境を無理なく導入するには？
	1．Team Foundation Serverの実際
	2．Team Foundation Serverの機能概要
	3．費用は高額だが、得られる効果は？
	4．導入へのファースト・ステップ

「Team Foundation Server 2008の下流工程への適用」

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