アート・オブ・プロジェクトマネジメント(15)

Book

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)


15章 終盤の戦略


目先のマイルストーンを守らせようとチームにプレッシャをかけすぎると，思わぬリスクが発生することがあります．下図のマイルストーン1に間に合わせようとメンバーの尻をたたく事で，マイルストーン2に向けた作業は不利なスタートを切ることになるのです．

さらに悪いことに，マイルストーン1のために先取りしてきた工数には利息がついてしまうのです．電車に乗り遅れまいと20秒ダッシュすると，息が元通りになるまでに1分ほどかかるのと同じです．

収束に向かうアプローチ

プロジェクトが一定の進捗率を守り続ければ，理想的な直線で予定通りにものごとは完了するわけですが，現実にはそんなことはありません．

そして，以下のような理由によって，ものごとは悪化し，

  • 人は自らのやりたくないことを避ける傾向がある
  • 疲れてくると，パフォーマンスが低下する
  • 難易度が高く，責任の所在が曖昧なバグはたらい回しにされる
  • 終盤のバグは，発見にも修正にも時間がかかる

たいてい，プロジェクトの期限に向かうアプローチは，このような漸近線となるのです．

有益なバグ指標

バグトラッキングでは，アクティブなバグ数，発生したバグ数，修正済みのバグ数の推移をグラフ化するのはごく一般的ですが，それ以外の指標が書かれているので抜粋しておきます．

  • バグ修正のペース
  • 発生したバグの数と承認(トリアージ)されたバグの数の比率
  • バグがアクティブとなっている時間
  • 開発者あたりのバグ数
  • 欠陥フィードバック率 (レグレッション率，エンバグ率)

その他，僕がよく使うの指標は以下です．

  • 機能別のバグ分布と推移
  • モジュール別のバグ分布と推移
  • 平均バグ発見間隔 (MTBF)

また，テストを始める前に，バグ予測カーブを作成し，実際のバグカーブのトレース結果との差分を検証していくのも重要ですね．

トリアージ

トリアージとは，救急医療において，多数の傷病者を緊急度と重症度によって分類し，優先順位を決定することです．

  1. サニタイズ ： 再現性確認，既知問題の判別など
  2. 調査 ： 本当に修正すべき問題なのか？
  3. 優先順位付け ：

トリアージには，日次のトリアージと方向性を持ったトリアージがあります．日次のトリアージは，新たに発生したバグやアクティブなバグを扱うルーチンプロセスです．方向性をもったトリアージとは，プロジェクトレベルにおけるコントロールの1つで，具体的な目標を達成するためにプロジェクトの方向付けを行うようなプロセスです．以下のような状態のときに行われます．

  • トリアージされたバグの数とアクティブなバグの総数の比が小さい場合 (未トリアージのバグが多数ある場合)
  • 終了条件が変更になった場合
  • クローズされていないバグの数が多い場合

特に1つ目の場合は，要注意ですね．僕の経験上，たいてい同根問題によるさまざまな症状が爆発しているか，未実装が発覚したか，どちらか多いのですが，そうでない場合は，プロジェクトレベルでの慎重な対策が必要になります．こういった場合，何よりもメンバーの混乱を避けることが先決です．サニタイズする要員を増やす，いったんテストを停止する，テストは続けるがバグを別のデータベースに一時保管する，などが考えられると思います．

また，プロジェクトレベルでのミスとしては，リソース不足の放置，テスト開始時期のミスジャッジ，なんらかの重要なプロセスを飛ばした，などが考えられます．

ウォーチーム

プロジェクトの完了に近付くにつれて，分散した権限を集約することになります．マイクロソフトでは，｢ウォーチーム｣(war team) と呼ぶグループに権限を集約するそうです．(これは｢作戦司令室｣(war room)という軍事用語に由来するそうです)

ウォーチームは，変更要求や懸案事項，バグのトリアージといったものに対する意思決定を行っていくわけですが，重要なのは，ウォーチームが関与するタイミングとその権限の及ぶ範囲について，メンバーにしっかりと知らされていることであると述べています．

参考文献