ITプロジェクトの定量的モニタリングをどうするか


昨日書いたPRONCE2の概要でとっても気になったのが「Manage by exception」です。日本語に訳せば「例外の管理」ですね。昨日のPRINCE2の概要のManage by exceptionのページに何が書いてあるかと言うと、

Manage of exception
A PRINCE2 project has defined tolerances for each project objective to establish limits of delegated authority.

tolerances

  • Time
  • Cost
  • Quality
  • Scope
  • Risk
  • Benefit


訳すとこんな感じですか。

「限定されて委譲された権限に対し、それぞれのプロジェクトの目的を確立するために、プロジェクトは許容度(tolerances)を定義する。」


言い換えると、

「列挙するプロジェクトの評価項目に対して指標値を設ける。」


と言うことですね。何を言っているかと言うと、プロジェクトの価値、それはプロジェクトをやると判断するときや途中で継続するかとかそうした意思決定意をするときにそのプロジェクトをすることでどのような利益を得られるかを定量的に示すもので、

「その評価項目ごとに指標値を定義し、閾値を超えたら上位層へ報告しなさい。」


というものです。一つのポイントは、評価項目を明示していることですね。評価項目の中で注目したのは、Quality、Scope、Riskです。


Time(工期)は、マスタースケジュール、WBSなどで計測単位を決められるし、測定できるし。同じように、CostとBenefitは費用と収益なので計測単位を決められるし、測定できる。

  • Time −工期
  • Cost  −費用
  • Quality −品質
  • Scope −範囲
  • Risk −危機
  • Benefit −利益


では、Qualityはどうするか。これは普通に品ひつ管理プロセスを定義して回せばいいですね。ただ、閾値となる指標値を定義できるかどうかがその組織のメトリクスの収集が定常的に回っているかどうか組織の成熟度が試されると思います。


Scopeはどうか。作業範囲を定量的に定義して、指標値を設けモニタリングしないといけない。どんぶり勘定のスコープの曖昧な契約ではこれが定義できないし、指標値を定められない。こうしたところにPRINCE2では、発注者側に見積もるための仕様を明示的に出させて受注者側にリスクを負わせ過ぎないように工夫した点が現れていますね。


Riskもどうするか。見積もり時のリスク識別からエクスボージャを求めて、指標値を定めないといけないわけです。見積もり時にリスク評価が出来ているなら、エクスボージャは求められるけれど、閾値はどうするか。このあたりも組織がメトリクスを収集するなどある程度の成熟度が求められそうです。


閾値と指標値
海外ではメジャメントだけに特化した書籍も出ているらしいです。組織の中でメトリクスを収集する体力がなければそうした外部データを使うことも一つの手でしょう。ソフトウェアの生産性の指標ではCapers Jonesが有名ですね。ただ、欲しいメトリクスがあるかどうかもあるし、フィットするかどうかもあるので、継続していると組織が自助努力でメトリクスを収集する方に向かうのではないかと思います。


あともう一つ。閾値を設けるとき、何をもとに閾値として決定するか、ですね。ここは悩みどころだと思いますが、何でもやってみないとわからないので(仮)で決めて定期的に見直すことを続けるほかないと思います。まぁ、試行錯誤ですね。コワイのが指標値が離れすぎていて指標値の内側でもプロジェクトのインパクトを与えることがある、ということを認識しておくことでしょうか。なので、最初は閾値を厳しめにして組織のプロジェクトのコントロールの成熟度と歩調を合わせて緩めていく方がいいかもしれません。