第２回　大プロジェクト・マネジメントの経験を通じて

幸いにも多くの大規模プロジェクトを経験した者にとって、プロジェクト・マネジメントは理論よりも実体験の方が興味深いと感じている読者が多いと思う。本に書かれた方法論や手法を試みても、現実にはその通りにならない事が遥かに多い。特に大規模（多人数）システムになればなるほど事は思い通りに進まないものである。大規模プロジェクトを実体験した人にとっては、実際に体験して成功した手法だけが役に立つ方法論・手法であると手応えを感じているようである。それを他人がそっくり真似しても上手く出来ないことが多い。筆者も書物で多少勉強したが、自分で仮説を立て検証実験を繰り返しながら苦しんだ末に成功した方法や手法だけが、実践で使える有効な方法・手法として記憶として残っていった。しかも、あるプロジェクトで成功した手法が別のプロジェクトで成功するとは限らなかった。従って、プロジェクト毎に方法・手法を変えた事もかなりあった。こうした経験からプロジェクト・マネジメントについて、筆者の考えや思いを述べていきたい。

筆者は、当初の実現したい機能が曖昧（抽象的な表現）なために、詳細化とともに実現したい機能の規模が大幅に膨張したり（結果的に費用・納期・品質に影響）、開発途中にユーザ要件が急変（負荷が急増）したために実現方式を設計からやり直した経験が多かった。また、進捗管理や品質管理を当初からキッチリ実行していても、思わぬ進捗遅れや品質不良を経験したことも多かった。筆者は、大規模プロジェクトにおいては、プロジェクト当初の検討が不十分、先の予測が甘い、管理の仕組みが不十分というな問題と捕らえるのではなく、「大まかな目標設定のプロジェクトをリスクの多い環境条件で当初の計画通りに確実に成功させる方法論などは有り得ない」と思うべきであり、「当初の大まかなプロジェクト目標に出来る限り近づけて実現することがプロジェクト・マネジメント」であると考えるようになった。今では、「大きな問題を発生させずにプロジェクトを完了させれば成功」であると考えている。

消極的な言い方だが「失点を少なくすることがプロジェクト・マネジメントである。」という考え方である。どんなことでも同じだが、多くの人から成功と呼ばれるには何らかの「幸運」が必要である。環境変化の大きい現在、納期、費用、実現した機能総量、品質などのプロジェクトにおける重要項目間のトレード・オフを誰から見ても成功と思われるようにバランス良く解決することは難問であるし、そのプロジェクトの環境やステークホルダーの考え方によっても満足度は異なる。そのような条件において成功と評価されるには「幸運」が無ければ極めて難しい。厳しい環境条件の中で工夫と努力をして、納期を守ったプロジェクトでも費用が若干超過したために、失敗と評価されたプロジェクトもあったし、一方、費用面で好条件のプロジェクトが費用超過しても、成功と評価されたこともあった。同じプロジェクトの結果でも、或る人は成功と評価し、別の人は失敗と評価したプロジェクトも存在した。今だもって、プロジェクト成功の普遍的尺度は存在しないのと思われる。

それ故に、全てのプロジェクトを成功するためのプロジェクト・マネジメントの方法論よりも、失点を最小限に抑えることを中心にプロジェクト・マネジメントを述べることにする。失点を最小限にするためには、全方位的に全てのステークホルダーに対して、失点を少なくし、満足度を高くすることは有効では無い。お客様の責任者（ＩＴ部門の責任者または利用部門の責任者）に重点を絞るのが自然である。しかし、客様側に重点絞ると、受注部門の立場の方には難問が降りかかってくる。発注側の立場と受注側の立場では相反する課題（特に実現機能、費用、納期、品質に関しては）が多いからである。そういう場合に、筆者は当ＩＴシステム利用部門にとって最善となるように課題を解決していくことを選択した。困った時は、「システムの利用部門にとって最善となるシステムを構築する」という原点に戻ったのである。このことを「システムに愛を持つこと」と表現する人もいた。受注側の企業に属する人は、短期的には自企業の利益や思惑に反する行動をせざるを得ない場合があるので、そういう場合には事前に自社内を説得しておく配慮が必要であることは言うまでもない。

筆者が最初に経験した大規模プロジェクトは、まさに勘、度胸、運頼りでプロジェクトのマネジメントを遂行しながら、失敗や反省を積み重ねつつ「問題発生を予防する方法」や「問題発生しても影響を最小限する対策」を学習したプロジェクトであった。その後、数回の大規模プロジェクトを体験したが、大規模プロジェクトを経験するたびにプロジェクト・マネジメントの新しい課題に遭遇し、学習を繰り返した。このような学習体験を通して、プロジェクト・マネジメントに有効かつ共通的な幾つかの手法や配慮すべき事項を整理してみた。また、恥ずかしながらも若干かじった経営学や行動心理学の話を自分の体験に照らし合せて、プロジェクト・マネジメントにとって有効と感じた部分を織り込んで述べていきたい。

以上のことを、筆者の体験順にプロジェクト・マネジメントの物語風に、述べていくことにする。

最初の大規模プロジェクト（約３，０００人月）のリーダーの時に、我流に実行計画を立案し、実行した結果とそこで学習したこと。
数回の大規模プロジェクト（１万人月以上のプロジェクト３回あり）を体験して、分かったプロジェクトの失敗過程・失敗要因とその予防策および学習したこと。
経営学や行動心理学および成功企業の事例と対比して、プロジェクト・マネジメントに活用すべきこと。
スーパーＳＥ型マネジメントとチーム総合力型マネジメントの比較。（簡単に言うと、スター中心軍団ｖｓ雑草一丸軍団）
最新のマネジメント理論の動向とプロジェクト・マネジメントへの応用研究。
この話は、敢えて繰り返して言いますが、「成功する方法論」ではなく、「失点を最小限に抑える方法」です。言わば「大規模プロジェクトに潜在する問題の予防策と発生した場合の対策」であり、最近の用語では「リスク管理」のようなものです。

プロジェクトが終わった時に「成功と評価」するか「失敗と評価」するかは、各人の考え方やそのプロジェクトへの関わる立場によって異なります。筆者は、プロジェクト開始時に、そのプロジェクトのステークホルダーが集まってプロジェクトの成功の定義（重要項目の総合点方式）および評価方法を公式に合意して、終了時に合意した評価方法に基づいて評価すべきだと思います。少なくとも筆者は「成功の定義」をそのように考えています。そのような評価の仕組みが一般化されていない現時点では、「失点を最小限に抑える方法」としか言えないと思っています。
以上をご理解のうえで、お読み下さい。