【プロジェクトマネジメントをコンセプチュアルにしよう！】第２回 ＰＭＢＯＫ（Ｒ）とコンセプチュアルスキル
バックナンバーはこちら https://mat.lekumo.biz/ppf/conceptual_pm/━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆はじめに
前回、
コンセプチュアルスキルがプロジェクトマネジメントにどのように役立つか
という問いについて
（１）ＰＭＢＯＫ（Ｒ）を実行するにはコンセプチュアルスキルが不可欠
（２）プロジェクトで起こりそうな問題を予測する
（３）実行できる計画を作る
（４）プロマネやエンジニアとしての過去の経験を活かす
（５）トラブル発生時の厳しい制約の中で、創造性に富んだリカバリーのアイデアを出す
（６）コミュニケーションを向上させる
（７）プロジェクトのインパクトを大きくする
の７つのポイントを上げた。今回から何回かに分けて、それぞれについて詳しく検討していこう。まず、今回は（１）のＰＭＢＯＫ（Ｒ）の実行について。
◆ＰＭＢＯＫ（Ｒ）に対するＩＴ企業の反応
日本の企業がＰＭＢＯＫ（Ｒ）が本格的に導入し始めたのは、２０００年版（第２版）で、十数年前である。中心になったのはＩＴ企業である。
ＰＭＢＯＫ（Ｒ）については米国発の標準であるとか、ＰＭＰ（Ｒ）を資格がないとグローバルなプロジェクトは仕切れないといった理由で関心は高かったが、一方で、自社には合わないとか、書かれていることがあいまいで何を書いてあるのかわからないといった否定的な意見も少なくなかった。
僕は当時からＩＴ人材に対して、非常に本質的なスキルに欠ける人材が多いと思っていたので、そんなに意外な反応ではなかった。おそらくそういう反応をするだろうと思っていた。ちなみに弊社のクライアントは技術開発系の製造業とＩＴ企業で、製造業でも少し遅れてＰＭＢＯＫ（Ｒ）に関心を持つ企業が増えたが、上のような反応はあまり見られなかった。
ＩＴ人材に欠けているスキルというのがコンセプチュアルスキルである。彼らが仕事で取り扱っていることは非常に概念的な世界なのでちょっと意外な気がするかもしれないが、おそらく間違っていない。
◆ＩＴ人材がコンセプチュアルスキルに欠ける理由（その１）
そのようになった理由は２つあるように思う。一つは、日本のＩＴは自分たちでは何も新しいものを生み出さないにも関わらず、パッケージを受け入れてこなかった歴史がある。パッケージに自社の業務を併せるという発想がなく、自社の業務にパッケージを併せろとか、パッケージでは使えないのでスクラッチ開発だとやってきた。このような発想が今、イノベーションの文脈で問題になっているベンダーによるシステム開発という独特のビジネスの慣行を作ってきたわけだが、これこそ、ＩＴ人材のコンセプチュアルスキルの欠如という問題を起こした根本原因である。
ＩＴ人材の多数を占めるベンダーの人材は（顧客の）戦略やビジネスを具体的なシステムに落としたり、その逆にシステムでできることから戦略を考えたりする機会がほとんどないからだ。
◆ＩＴ人材がコンセプチュアルスキルに欠ける理由（その２）
もう一つは、ツールである。（米国の）ＩＴ業界はツールが好きだ。たとえば、要求モデリングを行うツールなんていうのは叡智の塊だと思う。
このようなツールが米国で発達したのには理由があり、それはよく知られているように米国ではＩＴ人材の多くが一般企業に勤務していることだ。これが何を意味するかというと、自分はＩＴエンジニアだからといって技術だけやっていればいいというのではすまされないことだ。
日本でも一般企業のシステム部門は技術オタクでは済まない。自社の業務に対する知識と、その上には事業や戦略に対する知識が必要であり、その中で自分の仕事を理解することが必要である。
Π型の人材モデルというのがあるが、少なくとも技術とビジネスに対して熟知しなくてはならない。すると時間がない。そこで技術についてツールが重宝するのだ。
ツールを使っていても、ビジネスと自分たちの業務との関連付けをしなくてはならなければ、思考停止を起こすことはない。しかし、システムを作るためだけにツールを使っていると、思考停止を起こしまい、ツールを使ってやっていることが何かが分からなくなってしまう。言い換えるとツールを使うこと自体が具体的なアクションとなり、抽象的なレベルの意味を考えることがなくなる。なので、業務経験を積んでもコンセプチュアルスキルが低いままになる。
◆コンセプチュアルスキルの低い人材にＰＭＢＯＫ（Ｒ）を使わせる方法
話が脱線しすぎたが、以上の２つの理由でＩＴ人材には抽象的な仕事をしているにも関わらず、コンセプチュアルスキルが低いままである。ちなみに、ＩＴ業界の現場主義というのは製造業から来ていると思うが、エクセレントな製造業企業の現場主義は、コンセプチュアルである。つまり、現場でやっている泥臭い仕事の概念的な意味をよく理解している。
コンセプチュアルスキルが低い人がＰＭＢＯＫ（Ｒ）を見ると、抽象的だの、あいまいだのという話になるのは同然だ。ガイドとして作られたものであり、マニュアルとして作られたものではないからだ。
そこで、多くのＩＴ企業がやったことは、ガイドをベースにして自社に適したマニュアル（プロセス）を作ることである。そこにドキュメントの書式や、分析ツールを加えれば、ほぼ考えなくても実行できる。
加えて、ＰＭＢＯＫ（Ｒ）はカスタマイズしてもいいといった間違った情報が出回り、自社の状況に合わせたプロセスにしている企業も少なくない。ＰＭＢＯＫ（Ｒ）ガイドは全体性があり、抜く分には全体性が失われないようによく考えられている。ところが加えてしまうと全体性は失われ、うまく行く確率が小さくなる。
◆具体化するのではなく、ＰＭの概念化スキルを上げる
ここで、冒頭の問題に戻る。
以前から持論として申し上げているが、優れたプロジェクトマネジメントの実践方法には２つの方法がある。一つはマニュアルを徹底すること。つまり、プロセスに曖昧性が残らないように徹底的にプロセスを具体化すること。
もう一つはプロジェクトマネジャーがうまく育つこと。プロジェクトマネジャーが育つという意味は、ＰＭＢＯＫ（Ｒ）の話でいえば、抽象的な表現がされているＰＭＢＯＫ（Ｒ）ガイドを試行錯誤して具体的な行動にできるような実行能力を身につけることだ。この実行力になるのはいわゆるＰＭコンピテンシーであるが、ＰＭコンピテンシーを発揮できるようになるには、ＰＭＢＯＫ（Ｒ）の優れた解釈が必要なのだ。
つまり、コンセプチュアルスキルこそが、プロジェクトマネジメントの実行力のカギを握っているといえる。
| | 
コメント