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

◆プロジェクトイニシエータとは

ＰＭＢＯＫの５つのプロセスの最初「立上げプロセス群」と呼ばれるプロセスの英語名称は「initiating process」である。そして、プロジェクトを立ち上げる人をプロジェクトイニシエータと呼ぶ。

プロジェクトマネジメント的な説明としては、

（プロジェクト憲章を）プロジェクトのイニシエーターまたはスポンサーが承認し発行することで、プロジェクト・マネジャーは、人・モノ・金の資源をプロジェクトのために使う権限を持つことができる。

という話になる。プロジェクトマネジメントは現場を中心にものを見ているのでこの表現は間違いではないし、ガバナンス的にも大方の組織（大企業）ではこのような仕組みになっている。少なくともプロジェクトマネジメントの中ではあまり重視されておらず、スポットも当たっていない。

◆スター主義経営

数年前に

ジェイ・ロッシュ、トーマス・ティアニー（山本 真司 , 大原 聡訳）「スター主義経営―プロフェッショナルサービス・ファームの戦略・組織・文化」、東洋経済新報社 （2007）

という本が出版された。プロフェッショナルサービスファームには、「スター」として「個」の力を引き出し「組織」の力に結集させる経営が必要だという趣旨の本だ。

スターという言葉は、昔はよく使われていたが、今はあまり使われない。むしろ、スター「にきしの」といった感じで、ギャグ的に使われる言葉になってきているような感すらある。

ジェイ・ロッシュの本で定義されているスターというのは、「優秀かつ長期的に組織に価値をもたらす従業員」であり、「卓越した個人の能力を持ちながら、チームワークを重視し、企業の利益を最優先で考えるという行動特性を持つ存在」である。ビジネススターとでもいうべき存在だ。

◆自分たちは特別である

今回はちょっと毛色の変わった話題を。以前から、一度、整理してみたいと思っていたこと。

プロジェクトマネジメントの導入で常に議論になるが、

欧米ｖｓ日本
世間ｖｓ自社

といった環境の違いである。要するに、自分たちには自分たちの特殊事情があり、ゆえにそのまま持ってきても適合しないという話だ。

これは、プロジェクトマネジメントに始まったことではなく、１９８０年代に、いま、考えてみると信じられないようなＩＴパッケージ・パッシングがあったメイン。フレームコンピュータを導入し、その上で自前で業務用のアプリケーションを作っていたところに、欧米でパッケージソフトが登場した。これに対して、多くの企業は、ビジネスシステムが違うのだから、そんなものは使えるわけがないと抵抗した。この構図と同じ構図だ。

この背景にあるのが、「自分たちは特殊である」という思いである。

◆主体性を期待する部課長と、補佐意識の主任・係長のギャップ

濱田秀彦さんという方の書かれた「主任・係長の教科書」という本を読んでいたら、面白いことが書いてあった。係長・主任とその上司である課長や部長との間には、いくつかの意識のギャップがあるという。

一つ目のギャップは、主任・係長は「上司をフォローし」というが、上司は「リーダーとして先頭に立ち、周囲を引っ張る」ことを期待している。

二つ目のギャップは、主任・係長は「期待に応えて」というが、上司は「自ら問題を発見する」ことを期待していること。

三つ目のギャップは、主任・係長は「育成をサポートする」というが、上司は「指導者として育成する」ことを期待している。

一言でいえば、上司は主体性を期待しているのに、主任・係長は上司の補佐で動く役割になろうとしている。

◆プロジェクトライフサイクルとは何か

プロジェクトライフサイクルという言葉がある。フィージビリティから、ハンドオーバー（引き渡し）くらいまでを指す言葉で、一般的には

（１）フィージビリティ
（２）プロジェクトデザイン
（３）プロジェクト実行
（４）ハンドオーバー

のようなライフサイクルである。たとえば、ＰＭＢＯＫ（Ｒ）が想定しているプロジェクトライフサイクルは

（１）プロジェクト立上げ
（２）体系的な準備
（３）作業の実行
（４）プロジェクトの終結

という対応になっている。

◆「プロジェクトのさまざまな要素」の調和を取る

ＰＭＢＯＫに統合マネジメントという概念がある。

プロジェクトのさまざまな要素を調和の取れた形に統合するのに必要なプロセス

と定義される。この表現は深い表現で、「プロジェクトのさまざまな要素」には、作業もあれば、ベースライン計画もある。さらには、プロジェクトの目標もあれば、プロジェクトの目的もある。多少、拡大解釈をすれば、そのプロジェクトの実行の背景になっている事業戦略や経営戦略も含まれるという解釈もできなくはない。

統合マネジメントの重要な活動の一つに統合変更管理がある。ベースライン計画を変更せざるを得なくなったときに、統合的に変更を考える。たとえば、自発的な理由でスケジュールが遅れてきたときに、スケジュールを間に合わせるように要員の追加をする。それに伴ってコストが増加する。これは統合変更管理ではない。ベースラインのレベルで考えると、スケジュール、コスト、スコープ、要員の４つの要素を総合的にみて、「調和（バランス）」をとる。これが統合変更管理である。

◆３つのプロジェクトコミュニケーション

プロジェクトマネジャーのもっとも重要な役割を一つだけあげるとすれば、コミュニケーションマネジメントである。この持論はもう５年くらい変わらない。

プロジェクトのコミュニケーションには３のタイプある。

一つは、作業上必要なコミュニケーションである。これを手段的コミュニケーションという。要求や仕様に関するコミュニケーション、作業進捗に関するコミュニケーション、問題やリスクに関するコミュニケーションなどがこれに該当する。この種のコミュニケーションは一般にはホウレンソウと呼ばれ、プロジェクトコミュニケーションというと、これを思い浮かべる人が多い。

二つ目は、動機づけやチームビルディングを目的にしたコミュニケーションである。これは充足的コミュニケーションという。ホウレンソウがコミュニケーションが手段であるのに対して、このタイプのコミュニケーションはコミュニケーション自体が目的であるところに特徴がある。

三つ目は、組織的なコミュニケーションである。たとえば、プロジェクトの背景、戦略、戦略ゴール、あるいは、プロジェクトの目的、顧客の想いなど、メンバーが意識しなくてはならないプロジェクト目標の背景にあるものに関するコミュニケーションである。

このタイプのコミュニケーションは行われているといえば、行われている。たとえば、キックオフミーティングで、これらのことは一式まとめて話をするプロジェクトは少なくない。しかし、戦略ゴールやプロジェクト目的などは、そもそも、形式的に表現されたものを聞いてもそれで理解したということにはならない。それらがプロジェクトのメンバーの活動と結びつき、腹に落ちてはじめて理解できたといえる。

◆マネジャーの３つのスキル

ハーバード大学教授のロバート・カッツは、マネジャーの能力を

（１）テクニカル・スキル、
（２）ヒューマン・スキル
（３）コンセプチュアル・スキル

の３つに体系化した。

テクニカルスキルは業務スキルで、プロジェクトマネジャーであれば、ＰＭＢＯＫのようなものだ。ヒューマンスキルは、コミュニケーションスキル、交渉スキル、モチベーションスキルなど、人間力に相当するものだ。コンセプチュアルスキルは概念化スキルとも呼ばれ、物事を概念化して捉えたり、抽象的に物事を考えたりする能力のことである。

◆アクティブ・ノンアクションとは

アクティブ・ノンアクションという概念がある。２年くらい前に、プロジェクトの補助線ブログにこんな記事を書いたことがある。

アクティブ・ノンアクションという問題

簡単にいえば、「忙しいけど、忙しさに見合う成果がでない」現象をいう。スマントラ・ゴシャール先生が著書『意志力革命』で言及し、目的を伴う意識的行動をとっていないことがその原因だと指摘している

確かに、このような現象の原因に目的意識の欠如があるというのはその通りだと思うが、では、目的意識の欠如を引き起こす原因はなんだろうか。

◆エンジニアの一流と超一流の違い

エンジニアは「ものごとを具体的にモノで考えてナンボ」という商売である

と思われている。機械のエンジニア、プラントのエンジニア、ケミカルのエンジニア、ＩＴのエンジニアなど、一流のエンジニアはすべてものごとを具体的に考える能力にたけている。

しかし、具体的に考えるだけでは、「超一流」のエンジニアにはなれない。あなたの周囲にもし、超一流のエンジニアだと思われる人がいれば、観察してみてほしい。必ず、ものごとを概念的に考えている。概念的に考えた上で、具体的な設計に落としている。なぜ、概念的に考えるのか？それは、新しいことを考えるには、理論や智慧に立ち返る必要があるからである。理論のレベルで考えて、問題を解決し、それを具現化し、具体的なものにしていく。つまり、理論という人類の共通の智慧を活用できない限り、超一流のエンジニアにはなれない。

そもそも、エンジニアの主業務である設計とは概念的な仕事である。にもかかわらず、具体的な思考だけでも優れた設計ができるには、訳がある。知識と呼ぶものである。知識にもいろいろあるが、一番簡単なものは、事例である。設計であれば事例を参考にして設計するので、具体的な思考だけでも設計できる（そこに、特徴をみた事例の選定とか、カスタマイズのところなどに、概念的思考のスパイスを振り掛ければ十分だ）。

ただ、これでは歯が立たないことがある。まったく新しいものの設計だ。いままで、企業では、この部分は超一流のエンジニアが担当していた。そして事例ができれば、一流のエンジニアでもそれを知識として使って設計ができるようになる。

僕がエンジニアだったころにそんなことを考えていた。もちろん、自分ひとりでその境地に達したわけではなく、会社で先輩からいろいろと聞かされたり、本を読んだり、大学の先生との付き合いの中でそんなことを聞いたりした。中でも、人工知能の開発の仕事に従事したときに、頭の整理ができたように思う。

しかし、このような構図はもう通用しなくなった。新しいものがどんどん求められるようになってきた。イノベーションだ。すると、新しいものを設計しなくては一流のエンジニアの地位は危うい。

━━[PR]━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
概念的思考力を身に身につけたい人に！
「プロジェクトリーダーのためのコンセプチャルスキル強化講座」
http://www.pmstyle.biz/smn/conceptual.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━