コンセプチュアル・マネジメント

◆大規模なプロジェクトはヒューマンスキルだけでは乗り切れない

ロバート・カッツはマネジメントのレベルが上がるにつれて、テクニカルスキルから、ヒューマンスキル、ヒューマンスキルからコンセプチャルスキルに重要性が移っていくことを指摘した。

プロジェクトマネジメントにおいても、このパターンはあてはまる。小規模なプロジェクトであればプレイングマネジャーとしてテクニカルスキルがあれば、プロジェクトは回していける。しかし、少し、規模が大きくなると、人を使う可能性が出てくる。すると、リーダーシップと同時に、コミュニケーションスキルが重要になってくる。また、利害関係者も出てくるので、ネゴシエーションのスキルも欠かせない。つまり、ヒューマンスキルが重要になる。さらに、大規模になると、ヒューマンスキルだけでは乗り切れなくなる。

プロジェクトが大規模になると、個別の事象を対象にして、プロジェクトの状況を把握したり、あるいは、プロジェクトの指示をすることは難しくなる。たとえば、スケジュールの状況を把握する。個別のワークパッケージが遅れているか、予定通りか、あるいは、進んでいるかをすべて把握することは困難である。そこで、プロジェクトマネジメント的には、遅れているワークパッケージだけはＰＭＩＳのような仕組みを導入して把握しようということになるのだが、これも特にプロジェクトの状況が悪くなると、百を超えることは珍しくなく、把握は困難である。認知限界を超えている。

そこで、次に何人かでプロジェクトマネジメントをやろうということになる。たとえば、プロジェクトマネジメントチームを構成し、数名のプロジェクトマネジャーを置き、担当を決め、担当範囲については個別に状況把握をしていく。つまり、問題や課題を抽出し、リスト化する。


◆問題／課題リストではプロジェクトの状況を把握しているとは言えない

これで一見問題が解決したように見えるが、落とし穴がある。本当の意味で統合されないままになっていることが多い。つまり、プロジェクトが全体としてどういう状況になるのかということはわからないことが多い。

また、統合を問題リスト、課題リストで行おうとするプロジェクトも少なくない。問題数がいくつあり、未解決がいくつ、課題化したものがいくつというおなじみのやり方だ。

このやり方も一見もっともらしいように見える。実際に品質管理であれば適切な方法である。ただし、品質目標として、品質レベルをクリアするために必要な不適合の発見数が妥当ならだ。プロジェクトでいくつ問題が起こったらあとはプロジェクトがほとんど順調にいくという数字など出せるはずがない。

また、リスクを品質における不適合数に見立てた管理をしている組織があるが、これは効果的だとは思えない。リスクや問題は不適合と異なり、相対的なものだからだ。


◆概念化をして統合する

結局のところ、統合しようとすれば、状況を概念化するしかない。概念化するためには、定量的な判断とは違った判断が求められることが多い。たとえば、ＡとＢとＣの３つの主要成果物があり、Ａに関連する部分では現在２０％のワークパッケージに遅れがみられる。Ｂは２５％、Ｃは１５％、全体では１８％のワークパッケージに遅れが出ているというのでは不十分である。このケースで、概念化をするにあたって必要なことは

（１）Ａ、Ｂ、Ｃでの遅延の傾向
（２）Ａ、Ｂ、Ｃでの重要なワークパッケージとその状況

の２つである。すると、たとえば、

Ａ、Ｂ、Ｃとも遅延の割合は減る傾向にあり、また、Ａ、Ｂ、Ｃの重要ワークパッケージは現在実施中のものもこれまでも遅延していない。この２つの傾向から、今後も重要ワークパッケージは遅延せず進むことが予想され、プロジェクト全体の状況としては遅延はあるが、プロジェクトは順調に進んでいる


といった状況把握が可能になる。ここで、「遅延の傾向」、「重要なワークパッケージ」という概念を導入することによって、プロジェクトの概念的な把握をしているわけだ。


◆概念的に考え、具体的に指示をする

このように大規模プロジェクトになってくると、プロジェクトの状況を概念的に把握することが欠かせない。同時に、概念的に問題解決を行うことが不可欠である。たとえば、上の例で、概念的に状況をとらえていないと、遅れのあるすべてのアクティビティについて、挽回するような指示を出さざるを得ない。これが、前回述べたようにプロジェクトにアクティブ・ノンアクションを引き起こす。

例のような概念的な把握をしていれば、対応は「何もしない」が正解である。せいぜい、プロジェクトが終盤にかかってくるので、重要なワークパッケージのモニタリングサイクルを早くするといったことだろう。

ここで、一つ注意しておいてほしいのは、「重要なワークパッケージのモニタリングサイクルを早くする」という問題解決策を考えたとして、これで指示にならない。この問題解決策に基づいて、指示をするときには、

・どのワークパッケージを
・何日サイクルで
・どのインデックスを

モニタリングすると指示することが重要である。

つまり、プロジェクトマネジャーが概念的に考えるのは、問題解決のプロセスであって、配下のリーダーやメンバーに対する指示は、「具体的に」行わなくてはならない。