« 【ブックレビュー】君に友だちはいらない | メイン | 【ブックレビュー】オーケストラ・モデル 多様な個性から組織の調和を創るマネジメント »

2014年6月16日 (月)

【プロジェクトマネジメントをコンセプチュアルにしよう!】第2回 PMBOK(R)とコンセプチュアルスキル 

バックナンバーはこちら http://mat.lekumo.biz/ppf/conceptual_pm/━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆はじめに

Cpm_3

前回

コンセプチュアルスキルがプロジェクトマネジメントにどのように役立つか

という問いについて


(1)PMBOK(R)を実行するにはコンセプチュアルスキルが不可欠
(2)プロジェクトで起こりそうな問題を予測する
(3)実行できる計画を作る
(4)プロマネやエンジニアとしての過去の経験を活かす
(5)トラブル発生時の厳しい制約の中で、創造性に富んだリカバリーのアイデアを出す
(6)コミュニケーションを向上させる
(7)プロジェクトのインパクトを大きくする

の7つのポイントを上げた。今回から何回かに分けて、それぞれについて詳しく検討していこう。まず、今回は(1)のPMBOK(R)の実行について。

◆PMBOK(R)に対するIT企業の反応

日本の企業がPMBOK(R)が本格的に導入し始めたのは、2000年版(第2版)で、十数年前である。中心になったのはIT企業である。

PMBOK(R)については米国発の標準であるとか、PMP(R)を資格がないとグローバルなプロジェクトは仕切れないといった理由で関心は高かったが、一方で、自社には合わないとか、書かれていることがあいまいで何を書いてあるのかわからないといった否定的な意見も少なくなかった。

僕は当時からIT人材に対して、非常に本質的なスキルに欠ける人材が多いと思っていたので、そんなに意外な反応ではなかった。おそらくそういう反応をするだろうと思っていた。ちなみに弊社のクライアントは技術開発系の製造業とIT企業で、製造業でも少し遅れてPMBOK(R)に関心を持つ企業が増えたが、上のような反応はあまり見られなかった。

IT人材に欠けているスキルというのがコンセプチュアルスキルである。彼らが仕事で取り扱っていることは非常に概念的な世界なのでちょっと意外な気がするかもしれないが、おそらく間違っていない。


◆IT人材がコンセプチュアルスキルに欠ける理由(その1)

そのようになった理由は2つあるように思う。一つは、日本のITは自分たちでは何も新しいものを生み出さないにも関わらず、パッケージを受け入れてこなかった歴史がある。パッケージに自社の業務を併せるという発想がなく、自社の業務にパッケージを併せろとか、パッケージでは使えないのでスクラッチ開発だとやってきた。このような発想が今、イノベーションの文脈で問題になっているベンダーによるシステム開発という独特のビジネスの慣行を作ってきたわけだが、これこそ、IT人材のコンセプチュアルスキルの欠如という問題を起こした根本原因である。

IT人材の多数を占めるベンダーの人材は(顧客の)戦略やビジネスを具体的なシステムに落としたり、その逆にシステムでできることから戦略を考えたりする機会がほとんどないからだ。


◆IT人材がコンセプチュアルスキルに欠ける理由(その2)

もう一つは、ツールである。(米国の)IT業界はツールが好きだ。たとえば、要求モデリングを行うツールなんていうのは叡智の塊だと思う。

このようなツールが米国で発達したのには理由があり、それはよく知られているように米国ではIT人材の多くが一般企業に勤務していることだ。これが何を意味するかというと、自分はITエンジニアだからといって技術だけやっていればいいというのではすまされないことだ。

日本でも一般企業のシステム部門は技術オタクでは済まない。自社の業務に対する知識と、その上には事業や戦略に対する知識が必要であり、その中で自分の仕事を理解することが必要である。

Π型の人材モデルというのがあるが、少なくとも技術とビジネスに対して熟知しなくてはならない。すると時間がない。そこで技術についてツールが重宝するのだ。

ツールを使っていても、ビジネスと自分たちの業務との関連付けをしなくてはならなければ、思考停止を起こすことはない。しかし、システムを作るためだけにツールを使っていると、思考停止を起こしまい、ツールを使ってやっていることが何かが分からなくなってしまう。言い換えるとツールを使うこと自体が具体的なアクションとなり、抽象的なレベルの意味を考えることがなくなる。なので、業務経験を積んでもコンセプチュアルスキルが低いままになる。


◆コンセプチュアルスキルの低い人材にPMBOK(R)を使わせる方法

話が脱線しすぎたが、以上の2つの理由でIT人材には抽象的な仕事をしているにも関わらず、コンセプチュアルスキルが低いままである。ちなみに、IT業界の現場主義というのは製造業から来ていると思うが、エクセレントな製造業企業の現場主義は、コンセプチュアルである。つまり、現場でやっている泥臭い仕事の概念的な意味をよく理解している。

コンセプチュアルスキルが低い人がPMBOK(R)を見ると、抽象的だの、あいまいだのという話になるのは同然だ。ガイドとして作られたものであり、マニュアルとして作られたものではないからだ。

そこで、多くのIT企業がやったことは、ガイドをベースにして自社に適したマニュアル(プロセス)を作ることである。そこにドキュメントの書式や、分析ツールを加えれば、ほぼ考えなくても実行できる。

加えて、PMBOK(R)はカスタマイズしてもいいといった間違った情報が出回り、自社の状況に合わせたプロセスにしている企業も少なくない。PMBOK(R)ガイドは全体性があり、抜く分には全体性が失われないようによく考えられている。ところが加えてしまうと全体性は失われ、うまく行く確率が小さくなる。


◆具体化するのではなく、PMの概念化スキルを上げる

ここで、冒頭の問題に戻る。

以前から持論として申し上げているが、優れたプロジェクトマネジメントの実践方法には2つの方法がある。一つはマニュアルを徹底すること。つまり、プロセスに曖昧性が残らないように徹底的にプロセスを具体化すること。

もう一つはプロジェクトマネジャーがうまく育つこと。プロジェクトマネジャーが育つという意味は、PMBOK(R)の話でいえば、抽象的な表現がされているPMBOK(R)ガイドを試行錯誤して具体的な行動にできるような実行能力を身につけることだ。この実行力になるのはいわゆるPMコンピテンシーであるが、PMコンピテンシーを発揮できるようになるには、PMBOK(R)の優れた解釈が必要なのだ。

つまり、コンセプチュアルスキルこそが、プロジェクトマネジメントの実行力のカギを握っているといえる。

コメント

コメントを投稿

PMstyle 9月~19年3月公開講座(★:開催決定)

PMstyle facebook

Twitterアカウント(PMstyle)

カテゴリ

Googleメニュー

  • スポンサーリンク
  • サイト内検索
    Google

最近のトラックバック

Powered by Six Apart

プロフィール

フォトアルバム

好川哲人

技術士&MBA 技術経営のコンサルタントとして、数々の新規事業開発や商品開発プロジェクトを支援、イノベーティブリーダーのトレーニングを手掛ける。「自分に適したマネジメントスタイルの確立」をコンセプトにしたサービスブランド「PMstyle」を立上げ、「本質を学ぶ」を売りにしたトレーニングの提供をしている。