システム成長モデル of メトリクス管理


プロジェクト管理ツール＆システムの成長モデル

プロジェクト管理は、スケジュールやその進捗などをマネジャーやメンバーなどの関係者で共有する必要があり、また、役割や立場により様々な視点でプロジェクトの状況を把握する必要があるため、システムやツールの支援が必要不可欠である。ここでは、プロジェクト管理を支援するシステム環境について考えてみたいと思います。

レベル１：オフィスツール利用

Level1.jpg小規模なプロジェクトでは、スケジュール作成や定期的な進捗報告などは Excel やテキストエディタなどの普段使っているツールで作成することが多いようです。しかし、手軽にプロジェクト管理を行うことができる反面、個人が自由な使い方をしているために様々な問題も引き起こします。この場合の特徴と課題は、次のように整理することができます。

特徴

  1. 10 個前後のマイルストーン管理ですむ場合は文字中心のメールやファイルでやりとりすることが多い。
  2. 使い慣れた Excel を使ってガントチャート・スタイルのスケジュールを作成する。
  3. Excel をお絵かきツールのようにして使うことが多い。
  4. Excel のマクロ作成を行ってメンバーの負荷分析などを行うなど、高度な使い方をしているケースもある。

課題

  1. 人によって表現方法やフォーマットが違うため、スケジュールを結合したり分割したりするときに手間がかかる。
  2. わかりやすいように表現を工夫すればするほど修正や更新に手間がかかることになり、オーバーヘッドが増えていく。
  3. 便利なマクロでもマクロ作成者がいなくなると保守ができなくなり、安心して使うことができなくなる。
  4. 個人ファイル扱いとなっているため、関係者間での共有はトラブルが起きやすい。
  5. 作業（タスク）は絵として表現されているだけなので、負荷分析やタスク分析などは別途手作業で行う必要がある。

レベル２：Project スタンダード導入

Level2.jpgExcel などではトラブルやオーバーヘッドが大きくなってきたときや、プロジェクトのメンバーが 10 人から 50 人くらいの中規模になるとき、そして、メンバー間での計画や進捗の共有を強化したいときなどは、MS Project などのプロジェクト管理ツールを導入することが多いようです。ただ、使えるものかどうかを確認する必要があるために、手軽な MS Project スタンダード版を試験的に導入するケースが多いといえます。この場合の特徴と課題は以下の通りです。

特徴

  1. MS Project を使うことでプロジェクト管理技法の基本スキルが身につく。
  2. 関連した作業（タスク）の日程変更などの修正が容易。
  3. プロジェクトの計画と進捗の管理に関する情報がプロジェクトファイルに一元化される。
  4. 様々な見方（ビュー）で計画や進捗を見ることが可能。
  5. リソースの負荷分析やタスクのクリティカルパス分析などが可能。

課題

  1. 人により使い方や記述方法のバラツキが大きい。
  2. 複数プロジェクトの進捗をまとめて見たいときなどプロジェクトを統合するのが難しい。
  3. 組織全体で見たときに誰が過負荷になるかなどのプロジェクト横断的な分析が難しい。
  4. マトリクス体制の場合の進捗分析が困難。

レベル３：Project エンタープライズ導入

Level3.jpgメンバーが 50 人以上の大規模プロジェクトが同時に複数走っているよう場合や、組織レベルでプロジェクト管理ツールを一括運用するような場合は、選択肢の１つとして MS Project のエンタープライズ版を導入することが多いようです。この場合の特徴と課題は以下の通りです。

特徴

  1. 組織全体のプロジェクトを一括して管理できる。
  2. 組織全体のメンバーなどのリソースを一括して管理できる。
  3. 組織全体でプロジェクトのポートフォリオ分析などが可能。

課題

  1. 様々な事前準備や設定が必要となるため、導入の際の手間が大きい。
  2. 組織にあった運用のためにはカスタマイズが必要になることが多く、コストが増大する。
  3. サーバーやネットワークなどのシステム管理が必要になる。
  4. プロジェクト管理のノウハウを組織的に蓄積するのが困難。
  5. 進捗の分析方法などの運用を徐々に高度化する（進化させる）のが困難。

プロジェクト管理の仕組みにおける真の問題

以上、プロジェクト管理のシステム環境について考察しましたが、問題を解決するためにシステム環境をレベルアップしてもまた新たな問題を抱えてしまうと言えます。これは、プロジェクト管理の仕組み全体についても同様です。新しい仕組みを導入しても常に問題を抱えることとなり、現場ではそれに対応するために様々な工夫を行っています。

このような状況下で真の問題となるのは、仕組みの問題に対処する現場での工夫や努力が、何度も繰り返されることです。現場では、プロジェクトの最中でも、プロジェクトが変わっても、部署が変わっても、システムを含めた仕組みの足りないところを、時間と手間をかけて何度も繰り返し補っています。そして、プロジェクトのリーダーやメンバーは、ムダやムリだとわかっているその場限りの対処を何度も繰り返しやらされることにより、疲れ切ってしまうのです。

MS Project の場合であれば、次のような現場の声をよく聞きます。

「もともと適当な日程なのに細かな入力や設定を要求される」
「自動的にタスクが動いたりして、何をやるにしても時間がかかる」
「リリースに合わせるために机上で精緻につじつま合わせしているだけ」
「作ったファイルを結合したり、分割したりするのは手作業で大変なことになる」
「進捗見たいだけなのに覚えることがたくさん」「この部分だけ見たいのに」

現場では繰り返し、システムや仕組みの足りないところを手作業で（仕方なく）補っているのが真の問題です。