有能なプロジェクトマネージャを育てるには(3)何かがおかしいIT化の進め方(30)(2/4 ページ)

» 2006年12月26日 12時00分 公開
[公江義隆,@IT]

コントロールの考え方を知ろう

 PMBOKやISOなどをはじめ、プロジェクトマネジメント関連書籍では、管理の対象項目として、予算や進ちょく、品質、人、技術……、などが別々に説明されている。文章では同時に書けないからそうならざるを得ないのだが、これは、「予算がオーバーしそうだからコストを抑えろ!」や「進ちょくが遅れているから急げ!」というような個別にコントロールできる問題ではない。予算オーバーも進ちょく遅れもすべて結果なのだ。

 コントロールの基本的な考え方は、1. まず、進ちょくや予算の消化度……など、種々の状況を測定して、2. これらを総合してプロジェクトの状況を診断し、3. この状況をそのままに放置しておくと、最終結果がどうなるかを予測し、4. この予測と目標値とのズレを見て驚き、5. このズレをなくすためには、いまどんな手を打てばよいかを考え・実行し、6. 打った手が予定の効果を上げているかを監視し、このサイクルを繰り返すことである。

ティータイム

 古い話になるが、人類を初めて月へ送り込んだ米国NASAのアポロプロジェクトでは、その重点管理対象は、構想・設計・製造過程を通じた、宇宙船ロケットの重量とロケットエンジンの推力であった。重量がエンジンの推力を上回るとロケットは飛ばなくなる。


 構想段階では楽観的でありがちなこれらの数値は、設計、製作と作業が進むにつれて現実に引き戻され、実現見込み値は、重量は重くなり、推力の保証値は下がってくる。 構想段階(推定値:データの誤差大)?>設計段階(計算値:誤差減少)?>製作段階(実際の値:誤差0)という作業進ちょくに合わせ、ロケット部品の構成と重量データを段階を追って逐次把握し、完成時点での全体の重量とエンジン推力の予測値が、進ちょくに伴ってどのような傾向で変化しているか、その傾向がどこへ収束していくかを予測するFAME(Forecasts and Appraisals for Management Evaluation)という、コントロールの本質を具現化したシステムがNASAにあった。


 FAMEの説明とFORTRANのプログラムリストからなる、淡いブルー模様の表紙のNASAの2冊の資料の中に「傾向の傾向」という耳慣れない言葉があった。1960年代の話である。


《参考》情報システム開発の進ちょくやコスト管理にこの考え方を応用すれば、問題の早期把握・対策実施に役立つと思う。新しく編成した組織体制の下、新しい仕事の方法や新技術への習熟度、その結果である生産性の変化を進ちょくやコストからどのようにとらえておられるだろうか?


プロジェクト構造の理解を深めよう

 前節で述べた1〜4のステップでプロジェクトの状況をとらえ、「このまま放置すると大変なことになりそうだ」ということまで分かったとして、この後の「それでは、どこに対してどんな手を打てばよいのか?」という5の問題では、プロジェクトの問題構造、つまりプロジェクトを構成しているいろいろな要素間の因果関係を、的確に把握できているか否かが結果を大きく左右する。

 なお、プロジェクトメンバーの性格や能力、モラルなどはプロジェクト構造の重要な要素であり、士気やモチベーションは重要な管理対象である。

 プロジェクトの中では、いろいろな問題が相互に関連し合っている。例えば、多くのシステム開発プロジェクトではコストの中で人件費が高い割合を占める。その人件費は体制と期間で決まる。つまり、体制(人数)を決めれば、毎日決まった費用が発生していることになり、トータルコストは(体制=コスト単価)×(期間)で決まってしまう。(体制)×(期間)は仕事の内容そのもので決まる。自由度はどこにどの程度あるだろうか。

 このように予算管理と進ちょく管理は表裏一体の面がある。進ちょくの遅れも、品質の問題も、多くの場合、構想・計画のミスか、求められている問題と人や技術(つまり体制)とのミスマッチの結果である。ミスマッチによって時間が予定より多くかかり、進ちょくは遅れる。品質が伴わないのでやり直しになる。そしてさらに遅れ、その結果コストが増える。しかしコストの制約で全部のやり直しはできないという話になる。そして「どの範囲をやるのか?」という、もともとはなかった検討作業が発生し、さらに時間とコストを圧迫する、メンバーの士気が下がってくる……。という負の連鎖が発生するのだ。

 困難に直面して、メンバーの士気の状態によって実行可能な問題解決方法は異なってくる。

 優秀なベテランや、経験をうまく活用する人たちは、このようなプロジェクト内部の種々の問題や要素の相互の関係――つまり、プロジェクト構造のモデルを頭の中に持っている。その内容の多くの部分は、いろいろなプロジェクトの経験の中で、いろいろな問題に直面し、それを考える過程で整理されてきたものだと思う。

 さらに、このモデルの周りには、遭遇した詳細・具体的な状況や、解決策を考えたプロセス、その実施結果、そのときの自分や周囲の状況などの記憶が張り付けられている。プロジェクト作業を進めている中で、何らかの刺激や異常を感じると、これらの記憶されている情報から、問題や原因、解決策を探り出す仕組みが、脳の中に記憶のネットワークとして作られているわけである。

 ベテランはこんな経験モデルをうまく使うことで、問題発生を事前に防ぎ、問題が発生しても悪循環に入る前に適切な手を打ち、早期に問題からの脱出を図っているのだ。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ