リアルタイム プロジェクト マネジメント ～ Visual Studio ソリューションシナリオ
<< ”Visual Studio 2012 ソリューションシナリオ" では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>
ソフトウェア開発は顧客との共同作業であるとともに、開発チームのメンバー同士の共同作業でもあります。
要件を細分化し、各開発者にそれぞれのタスクを割り振る場合であっても、最終的なゴールである「顧客の喜び(Customer Delight)」を実現するためには開発者同士の協力が重要です。また、近年では「コードの共同所有」がより一般的になり、チームメンバー全員がコード全体に責任を持ち、自分が主担当でないコードに関しても臨機応変に変更、修正を行う体制が求められています。
今回のソリューションシナリオでは、顧客の要求に対してより柔軟に素早く対応できる理想的なチーム開発を目指すさいに重要となるプロジェクト マネジメントの取り組みにおいて、Visual Studio が提供するプロジェクト状況の可視化機能を活用し、リアルタイム プロジェクト マネジメントを実践するための方法を紹介します。
チーム開発においてよりよいプロジェクト マネジメントを行おうと思った際に、以下のような課題があります。
- 開発者に割り振ったタスクとその見積もりが適切な分量であったかが判断しづらい
- チーム全体の進捗を可視化しようと情報を集めようとすると、メンバー個々人に大きな負荷がかかるうえに、個々人の判断基準が統一されていないために集まった情報の信頼性が十分に確保できない。
- 開発プロジェクトの途中でリソース見直しの一環としてチームメンバーの配置変更を行いたい場合に、プロジェクトマネージャーとチームリーダーの勘に頼りがちになってしまう。
プロジェクトマネージャーは、開発者の貴重な時間を「コード開発」に充て開発を進めたい一方で、より正確な「プロジェクト状況の可視化」のために報告作業を詳細に行わせたい、という２つの異なる作業のバランスを取りながらプロジェクト運営を行うことが求められます。
よりよいプロジェクトマネジメントの実践のために、以下のことを心掛けましょう。
開発の速度を早期に把握し、タスクの見積もりやリリース計画を見直そう
「見積もり」は開発プロジェクトの中でも非常に困難な作業の一つです。
見積もりの精度を上げる手法としては、実施すべき作業を予測可能なサイズまで細分化する、プランニング ポーカーや壁の見積もりを使用しチーム メンバー全員の知識や経験を活用しながら見積もる、といった方法があります（プランニング ポーカーや壁の見積もりに関しては「見積もり」を参照ください）
開発プロジェクトが開始されると、さらに現在のメンバーの「見積もりの癖」（過大に見積もる傾向があるのか、過少に見積もる傾向にあるのか）や、実測値としての開発速度を知ることができるようになります。
プロジェクト マネージャーは、早期にこれらの情報を把握し、プロジェクト運営に変更の必要がある場合にはより早く対応を行うことを心がけましょう。
顧客の価値を中心に、シンプルで統一された報告基準を定めよう
進捗確認のための負荷が大きすぎて、開発作業に支障があるようではよりよいプロジェクトマネジメントは実現できません。一方で、進捗確認の負荷が小さくても、開発者個々人で報告基準が異なっていると、プロジェクトマネージャーが正確に状況を把握することはできません。
コードの行数は一つの目安にはなりますが、「顧客への価値提供」を重視する近年の開発では、”顧客要件” あるいは “プロダクト バックログ” や “顧客視点で定められたテスト項目” 等をプロジェクト進捗の基準とするのがよいでしょう。
プロジェクトマネージャーは、こららの視点で開発者がよりシンプルに進捗報告ができる仕組みを考え、提供しましょう。
開発プロジェクトにおける各工程の状況を把握しリソース配分を行おう。
開発プロジェクトにおける見積もりの難しさは先に述べましたが、見積もりが難しいことからも、プロジェクト マネジメントにおいてリソースの見直し（チームメンバーの配置変更）は必須の作業となります。
個々のタスクの見積もりの精度が高く、作業進捗の透明性も高い開発プロジェクトでは、各工程の状況をより正確に把握することが可能になりますので、それをもとに納得性の高いリソース配分を行うことが可能です。
Visual Studio 2012 では開発チームがこれらのプラクティス実践をスムーズに行えるように、様々な支援機能を提供しています。
プラクティス１：開発の速度を早期に把握し、タスクの見積もりやリリース計画を見直そう
Visual Studio 2012 を利用すると、開発プロジェクトにおいて行うべき作業を階層化しながら共有することが可能です。
例えば開発プロジェクトをスクラム方法論で行う場合、Team Foundation Server においてチームプロジェクトを作成する際にスクラムのプロセステンプレートを選択することで、”プロダクト バックログ” 単位での作業の階層かが可能です（Team Foundation Server には、スクラムの他に “アジャイル” および “CMMI” のプロセステンプレートがあります）。
下記の画面は、Team Foundation Server においてプロダクトバックログ単位での作業分割を行い、また把握可能なレベルでの作業細分化という観点でおよそ１日から２日の作業にて実施可能なレベルまで分割を行ったところを示しています。
プロジェクト開始前の見積もりで 100% 正確な見積もりが可能であれば、プロジェクトマネジメントにとってこれほど楽なことはありませんが、実際にはそのようなことはありません。
Team Foundation Server では各作業に関して終了時の実績値を記録したり、全体の傾向としての作業の進捗具合をレポートとして出力することが可能です。
作業進捗のレポートは中長期的な観点で出力することも可能です。下記は、スクラムにおける “スプリント” (多くの場合２週間から４週間程度の区切り）を単位に、６回分のスプリントにおける作業進捗の実績値と、その平均を Team Foundation Server から出力したものです。
プロジェクト マネージャーはこれらのデータを活用することで、開発の速度を早期に把握し、タスクの見積もりやリリース計画をより適切なものに調整を行いましょう。
プラクティス２：顧客の価値を中心に、シンプルで統一された報告基準を定めよう
開発者は Visual Studio 2012 を使用することで割り当てられた作業を完了した際に、併せて作業の完了を報告することが可能です。
例えばUMLユースケースの作成が完了した際に、その成果物を Team Foundation Server へチェックインする際に、タスク 18 番の「UML ユースケース図をまとめる」という作業のステータスを Visual Studio から ”解決” した（完了した）、というステータスに変更可能です。
このように開発者はプロジェクトマネジメント用のツールを別途立ち上げる（あるいは管理用のエクセルを開く）のではなく、Visual Studio から作業の完了を報告することが可能になります。
また Team Foundation Server はこれらの情報に基づき、プロジェクトマネージャーに対してこれらの作業進捗情報を、顧客の価値（スクラムの場合であれば “プロダクト バックログ”、CMMI 等の場合は “要件”)の観点で報告します。
また、プロジェクトマネージャーは顧客の価値の実現度合いを「テスト」によって測定することでい、より高い信頼性と透明性を持った進捗度合いの把握が可能です。例えば下記は顧客の価値（“ユーザーストーリー”）に対するテストの実装状況と実施結果をレポートしたもので、個々の顧客価値の実現状況が把握できます。
またテスト状況を時系列に表示することで、プロジェクト全体としての進捗を測定できます。
Team Foundaiton Server では自動化を行ったテストを、Team Foundation Server のビルドプロセスにおいて実行するように設定することが可能です。例えば、毎日深夜１２時になると最新のコードをビルドし、自動化されたテストを実施し、その実施結果を報告する、といった作業を自動化できます。 これにより、繰り返し可能で信頼性の高いプロジェクトの進捗状況の報告を定期的に行うことが可能になります。
Team Foundation Server のこのような特徴を利用することで、開発者が報告のための手間をかけることなく日々の業務の中で進捗情報を共有し、またプロジェクトマネージャーやプロジェクトの関係者は、顧客価値の観点で進捗状況を把握することが可能になります。
プラクティス３：開発プロジェクトにおける各工程の状況を把握しリソース配分を行おう。
Team Foudation Server では各種のレポートを提供しています。
それらレポートの一つである「残存作業レポート」を活用すると、以下のように実施すべき作業の状態が、「アクティブ」から「解決済み」そして「終了」のステータスに遷移する様子を確認することができます。
これらのステータスは、「アクティブ」なステータスとは開発者が実装を行っている状態、「解決済み」が実装が終了しコードの品質確認とテストを行っている状態、「終了」がコードの品質確認とテストが終了し、該当する作業が実際に完了した状態、を意味しています。
このグラフを縦軸に注目して確認すると、ある日付時点における終了した作業、解決済みの作業、アクティブな作業の分量がわかります。
また、このグラフにはもう一つ別な見方があり、横軸に注目することで、作業が仕掛中（Work in Progress)になっている期間を確認することが可能です。
例えば、上記のグラフでは、7/22 ごろに「解決済み」になった作業はその後およそ10日程度でテストを終了し、「終了」のステータスに遷移していることがわかります。また、8/22ごろに「解決済み」となった作業はおよそ13日程度でテストが終了していることがわかります。
残存作業のグラフにおいて、仕掛中の期間の差異がこれよりも広がってしまった場合、例えば下記のようにプロジェクト前半における仕掛中の期間と、後半における仕掛中の期間に大きな差異がある場合には、(1) 実装の品質が低くテストの工程で手間がかかっている、(2)実装を行っている作業者（リソース）に比べテストを行っている作業者が少なく、テスト工程がボトルネックになっている、といったことが考えられますので、それらを考慮したうえでリソースの再分配を行い、全体としての最適化を図ることが可能になります。
今回はリアルタイムマネジメントを実践するためのプラクティスと、Visual Studio 2012 の支援機能を紹介しました。
ソリューションシナリオには、以下のシナリオがあります。
それでは！
（岩出）