【WITブログ(訳)】マイクロソフトの開発部門でのTFSの活用 - 第6章（複数プロジェクトのトラッキング）

  • Article

英語原文:https://blogs.msdn.com/teams_wit_tools/archive/2008/05/06/how-microsoft-devdiv-uses-tfs-chapter-6-tracking-multiple-projects.aspx
※この投稿は、米Microsoftのデベロッパーツール開発部門のブログ（Teams WIT Tools）を長沢流に意訳・変訳したものです。
※英語原文を正とし、この投稿はあくまで理解の一助としてご活用ください。
※翻訳にあたって Teams WIT Tools ブログの執筆者から許可を得ています。

前回の投稿では、電子的なステータス レポートについて書きました。基本的に、我々にとってのステータス レポートは、作業項目上のいくつかのフィールドを埋めることで成立します。

本日は、すべてのプロジェクトの管理を担当するプログラムマネージャ（※日本でいうところの統括PMみたいなものだと思うとわかり易いかと思います）が Team Foundation Server（以下、TFS） を用いて、どのようにいくつものプロジェクトの進捗を一度に追跡しているのか、どういった一連のレポートを扱っているのかについて触れていきましょう。

と、その前に、我々のプロセスについてもう少し触れておきましょう。我々では毎週、マネージャ ミーティングを開催しています。このミーティングの目的は、実施中のいくつものプロジェクトの健全性を追跡することです。

このミーティングでは、プログラムマネージャが下記のようなレポートを見せます。これにより、実施中のすべてのプロジェクト（フィーチャ クルー）の状況を知ることができます。

image

グラフの見方を説明しましょう：

  • Green（緑色） - プロジェクトの全体に対する完了した作業の割合
  • Yellow（黄色） - 最新のレポート期間（概ね1週間）中に完了した作業の割合
  • Red（赤色） - 残作業時間（h）
  • 日付と完了予定のフィーチャ クルーの名前も記載されています。

このレポートをプロジェクターに映しながら、プログラムマネージャは次のような質問をします：

  • 先週に何も進捗がないのはどういうこと？
  • なぜ、あまり進捗が芳しくないの？
  • 残作業が1,457時間もあるけど、計画通りに1月3日に完了することができるの？

プログラムマネージャは、今ではテーブルをこぶしで叩いたり、"Why in the h*** are you not making more progress!" なんていうこともなくなった。プログラムマネージャは、示されたデータと一致しない点について読み上げる形で質問をするのです。

質問に対する回答は、以下のようなものになります：

  • 「データを更新してもらえなかったのです」 －これは容認できない回答です。このデータの可視化をすることがどれだけ重要なことなのかを改める必要があります。ところで、こういった声は、プログラム マネージャからだけではなく、製品担当部門からも挙がります。
  • 「先週には、他の緊急対応に時間を割く必要がありました」－これはとてもよい回答です。しかしながら、よく優先順位の議論になることもあります。マネージャは、緊急対応はプロジェクトと同じくらい重要ではないということをはっきりとさせました。どちらにせよ、マネージャはプロジェクトのよい状態を維持するためのよいアイディアを持ち合わせているものです。
  • 「もしすべてが複雑だったり門外をあったりせず、うまくいくなら、達成できるでしょう」－これは明らかに計画が見合っていると確信している人のコメントです。計画がスリップすると見栄えが悪いのでそうなることを嫌う人たちでしょう。でも本質的なポイントとして彼らにはこう言いたい： 我々は、彼らが適切だと思う確実な日付を知りたいのです。もし、計画をスリップする必要があるならば、それを今この場で知りたいのです。あとで知るより。

皆さんは、これを見て我々のグループで文化の変革が起こったのではないかと思ったかもしれません。透明性（Transparency）は、必須です。このようなオープンな文化においては、マネージャは、「どんなことがあっても、計画を守らなければならない」という考えを捨てる必要があったのです。フィーチャ クルーも「朗報だけをステータス レポートする」または、「悪い情報は隠す」という考えを捨てなければならなかったのです。このように、マネージメント側もプラクティショナー側もその過程で学習することがあった。

長くなったので、この辺でやめておきます。今後の投稿では、我々がリスクや品質ゲートのステータスをどうトラッキングしてきたのかを書きたいと思います。

※この意訳・変訳した投稿に関するお問い合わせは、長沢まで

訳者追伸
すみません！かなり滞留しております。なんとか続けたいと思っていますが、その分余計に変訳や誤り、省略も増えるかもしれません（注意はしていますが・・・）。そのあたりをご了承のうえ、ご覧いただければと思います。
なお、冒頭にも記載させていただいておりますが、あくまで英語原文が主です。この投稿はあくまで一助としてご活用ください.