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

ＰＭＢＯＫの概念の中にプロジェクトの「前提条件」というのがある。たとえば、

・プロジェクト計画書に定義されてる通りにプロジェクト組織が構成される
・顧客はプロジェクトの遂行に協力する
・組織や顧客に関する課題解決はタイムリーに行われる

といったものだ。実はこれらは、誰もが疑おうとしないが、多くのプロジェクトで成立していない前提条件である。最近ではだいぶ知恵がついてきたので、これらをリスクとして扱うことが多い。前提条件の崩壊というのはそれこそ、プロジェクトを崩壊するリスクになりかねない。

多くの場合、前提条件というのはプロジェクトマネジャーは無関係なところで構成される話だ。従って、成り立つかどうかも、ある意味でプロジェクトマネジャーはコントロールできないことが多い。せいぜい、リスク要因としてあげて、監視しておくことが精一杯であるが、監視したところでコントロールできないのだから、どうにかなるものでもない。

では、かくも重要なプロジェクトの前提条件に対してもっとも影響を与える人は誰か。上の例を見てもらうとわかると思うが、上位管理者、顧客、および、ステークホルダである。

さて、逆の視点でみてみよう。プロジェクトをうまく進めるためには、「常識的に考えて必要な前提条件」というのがある。例えば、「プロジェクト要員は必要に応じて確保できる」という前提条件がある。これもなかなか、成立が難しい前提条件の一つだが、このような前提条件が崩れてしまうと、ＰＭＢＯＫというプロジェクトマネジメントの手法そのものの有効性が崩れてしまう。

そんなことはない。リスクとして考えておくべきだという意見もあるだろう。確かに、「十分なスキルを持った要員が必要に応じて確保できる」ということを前提条件にするのであればそれは前提条件が成立しないことをリスクとして考えておくべきだ。しかし、上の例は、前提条件の不成立を受け入れるということはプロジェクトマネジメントをしないということに他ならない。

言い換えると、目標を設定し、目標を達成するためのマネジメントが機能するためには一定の条件がある。実は、一番の前提条件は、「目標が達成可能である」ということなのだ。ここすら前提条件になっていないプロジェクトがときどきある。この議論を見積もりの議論だと思うと間違いだ。背景にある程度の見積もりがあることは間違いないが、見積もりというのは所詮「過去の実績に基づく推定」に過ぎない。従って、目標が達成できるかどうかと、見積もり上のつじつまがあうかどうかはそんなに一致しているものではない。「一致しないのでプロジェクトだ」という言い方もできる。むしろ、重要なのは、できそうだという点について主要ステークホルダの合意があることだ。これが「目標が達成可能」という状態の他ならない。

そのような意味で目標を捉えたときに、「目標が達成可能である」は不可欠の前提条件である。

これ以外の前提条件は、むしろ、不成立があったときにカバーすべき条件だといえなくもないが、ただ、プロジェクトマネジメントではやはり、前提にしているものがある。例えば、
　「計画書は実行されるようにメンバーも含むすべてのステークホルダが努力する」
　「計画通りに実行されればプロジェクトは企業に利益をもたらす」
といった前提条件がある。これが成り立たなければ、ＰＭＢＯＫ流のプロジェクトマネジメントなど成り立たない。こういうのがマネジメントが機能するための一定の条件であり、マネジメントが機能しないというのはリスク以前の問題だ。

そのように考えると、このような前提条件のかなりの当事者は「プロジェクトスポンサー」や「組織の上位管理者」である。交渉責任や指導責任までを入れると、ほぼ、すべてについて責任を持つべきなのはこの２者になるだろう。例えば、ＳＩの受注プロジェクトで当初から顧客に全く協力の意志がないとすればこれはプロジェクトマネジャーの責任とはいえない。受注をしてきた組織の上位管理者の責任である。

このようにマネジメント上、不可欠だと思われる前提条件をクリアするのがプロジェクト環境創りである。ここをしっかりとやっていくようなプロジェクト支援体制を作ることが急務である。

拓真さん（２９歳）から戦略ノート５５回にメッセージを戴いた。以下に、引用させていただく。

===
先日、とあるセミナーを聴講した際、講師の方がこんなことを言っておりました。
「失敗から学ぶようでは二流。一流は成功から学ぶ」と。
===

※　戦略ノート５５回「失敗は繰り返す」
　　　　http://www.pmos.jp/honpo/note/note55.htm

この違いだと思う。拓真さんが話を聞かれた講師さんの言われていることに賛成である。失敗から学んでいる限り、一流にはなれないと思う。失敗をしなくなるだけだ。それだけでは一流とはいえない。

僕は、１０のプロジェクトを全部失敗しないでできる（期待どおりにできる）プロジェクトマネジャーは、高く評価すべきだと思うが、一流だとは思わない。このような人は、たぶん、永久に期待を上回る成果を結果を残すことはないだろう。失敗しない方法は知っていても、成功する方法はしらないからだ。

１０のうち、９つ失敗してもいいので、ひとつだけでも、意図して期待をはるかに上回る結果を出せる人こそ、一流だと思う。成功する方法を知っているからだ。組織は必ずしも成功を求めていないので、評価はされないだろうが、、、

ただし、ひとつ、付け加えたい。自身の失敗から学ばないのは三流以下だ。

さて、メルマガで、管理とマネジメントの違いという議論をずいぶんしてきた。最近、しなくなったのは、僕なりに結論にたどり着いたと思ったからだ。

　　管理は失敗から学ぶ。マネジメントは成功から学ぶ。

プロジェクトマネジャーで、組織、あるいはリソースマネジャーからの要員の供給に不満を持っていない人は珍しいだろう。プロジェクトマネジャーにインタビューすれば、大抵はここに不満を持っている。

しかし、突き詰めて考えれば、チームマネジメントのスタートは要員の獲得から始まるのだ。どれだけいい人材が取れるかはどう考えても競争だろう。

組織から供給されるメンバーは制約条件である。というのは、どう考えてもおかしい。制約条件であってはならない。他のプロジェクトに負けないように、必要な人材を奪いとってくる。これが普通の感覚ではないかと思う。

ただ、この人材獲得競争にはとてつもないエネルギーが必要だ。だから、人材は与えられるものだと考えたくなっているのではないか。こんな覚悟でプロジェクトをやっても、成功するとは思えない。

覚悟をし、まずは人材獲得競争に勝つ。これはプロジェクトマネジャーの真っ先にすべきことである。

「そんなことをしたら他のプロジェクトが困るんじゃないか」と思う人もいるだろう。それはあなたの考えることではない。組織の中でそのような発想をするのはある意味で偽善である。あなたの考えるべきことは、自分のプロジェクトを成功させることである。

そのためには、他のプロジェクトは頓挫してもよいので、自分のプロジェクトに必要な人材を獲ってくることだ。

７月７日に名古屋工業大学の公開講座「プロジェクトマネジメント：構想から実現へのロードマップ」でＮＨＫのプロデューサの方の講義「プロジェクト大河ドラマ」でプロジェクトマネジメントの原点を再認識するような話を聞くことができた。ちなみに、来年の大河ドラマは「篤姫」だそうだ。

ドラマ制作のプロジェクトでは、

　セット＞照明＞かつら、メイク、衣装＞出演者スケジュール

という優先順位があるそうだ。今まで、なんとなくだが、ドラマは人（出演者）の都合を中心に作られるのだろうというイメージを持っていた。ところが全然違った。

この順位に従うということは、話の流れの通りにシーン撮影を行うわけではない。セットを組んでしまうと、話の流れや回に関係なく、そのシーンで撮れるものをすべてとるという。

役者のメンタリティというのはよくわからないが、こんなやり方でよく演技ができるなと疑問に思い、講座の後の懇親会で聞いたところ、「記録」という役がいるらしい。そして、各シーンで演技の状況だとか、ニュアンスだとかをきちんと記録して、関連シーンを撮る際に役者に伝えるのだという。

さらに、監督（ディレクター）は一人ではなく、１回１監督というわけでもないらしい。複数の監督が存在しており、シーンごとに監督が変わってもかまわないようなシステムになているらしい。恐ろしく合理化されている。過去の血がにじむようなスケジュール短縮＆コストダウンの賜物だそうだ。

このように管理はプロジェクトというより、どちらかというとラインのイメージに近い。ところが作業そのものはこの上なく創造的なのだ。マネジメントを人の都合に合わせれば合わせるほど、合理性は小さくなる。なぜ、人の都合に合わせなくてはならないかというと、作業者がプロフェッショナルではないからだ。

なんとなく、テーラーの科学的管理の話を連想させる部分があるのだが、テーラーの話は管理される人間はノンプロフェッショナルである。プロフェッショナルとノンプロフェッショナルの違いは、内発的動機付けができるかどうかだと思う。ドラマようなマネジメントの中で仕事をするには、相当な内発的動機が必要だろう。

役者だけではなく、ディレクターも同じではないかと思える。

このシステムには、このプロフェッショナリズム以外に、もうひとつポイントがある。記録係の存在だ。ここが機能しないとこのシステムは成り立たない。これはプロジェクトでいえばＰＭＯである。この両方が揃って初めて合理的なプロジェクトの運営ができる。

実は、このシステムにはもうひとつのポイントがある。マネジメントのツールである。この世界では、このマネジメントを１枚の紙でやるツールがある。「香盤」と呼ばれるシステムである。これについてはまた、別の機会にご紹介する。

６月８日に

問題はなかったことにしよう

という記事を書いた。この続き。

ぼくが仕組み作りの相談を受けるような企業はプロジェクトが、そうそう、うまく行くとは誰も思っていない。ところが、この現実に対する組織（マネジメント）の反応は微妙な温度差がある。

典型的な反応は、

「本来、問題はあってはならない」

という反応である。たとえば、スケジュールが遅れていることを問題視する、コストがオーバーすることを問題視する。要するに見たくない、聞きたくない。だから、一時も早く、何とかしろということになる。管理はするが、マネジメントをしないマネジャーの典型的な反応である。

これで、話が収まればよいのだが、残念ながらそうはならない。

問題があることを心情的に認めない。だから、根本的な対応を嫌がる。とりあえず、応急処置で問題を見えなくする。スケジュールが遅れれば、どの作業が遅れているかを分析し、人を投入する、スコープが膨らめば、どのくらい必要かを分析し、予算を増やすように努力する。つまり、現象を分析し、応急処置をする。これがマネジャーの仕事だと思っている。

ここまででも十分な考え違いだが、もっとまずいことがある。問題など見たくもないので、とりあえず、応急処置をすれば、その問題は片付いたとことにする。フォローすらしない。
この影響は他にも出てくる。プロジェクトマネジャーがマネジャーに報告しても、いい顔をされない。じゃあ、報告しないでおこうとなる。すると、プロジェクトマネジャー自身も問題はないと思いたくなる。リーダーの報告に耳を傾けない。なにか言ってきたら、リーダーなんだから責任を持って解決をしてくれと逃げてしまう。この構図がプロジェクトマネジャーからリーダー、リーダーからメンバーと下達され、結局、実作業をしているメンバーが全てのしわ寄せを受ける。

こうなると最悪である。

これに対して、少数派ではあるが、プロジェクトには問題があるものだと思っている組織もある。問題を解決しながら、目標を達成するのがプロジェクトであると思っている。このように考える組織やマネジャーは決して応急処置をしない。スケジュールが遅れれば、現象の分析に留まらず、その原因を考える。そして、原因に対して可能な限りの手を打とうとする。

この２つの対応は初期段階ではたいした違いはない。ものの見方、考え方程度の違いかもしれない。実際に、問題に対して、応急処置と根本原因の解決策はあまり変わらない場合も多い。しかし、結果が大きく違う。

ものの見方、考え方が違うから結果に大きな違いがでてくるのだと考えるべきだろう。

プロジェクトは有期である。ものごとの先送りはダメ。プロアクティブに取り組みなさい

プロジェクトマネジメントの教科書にもこのようなことが書いてある。できているかどうかは別にして、いまや、常識になっているといってもよいだろう。さらには、

分からないこと、決まらないことがあれば、仮説を作って進めていきなさい。

といったことを書いている本も少なくない。

昨日のＰＭ養成マガジン戦略ノートに「プロジェクトにおける投機と延期」について書いた。この視点でいえば、プロジェクトマネジメントはできるだけ投機的にやりなさいということになる。これは本当に正しいのだろうか？これがこの記事のテーマ。

ただし、裏記事。表記事は、来週の戦略ノートで書く。

プロジェクトマネジメントには２つの顔（視点）がある。ひとつはガバナンスマネジメントであり、もうひとつはチームマネジメントである。

プロジェクトマネジメントは投機的であるべきだというのは、ガバナンスマネジメントの視点から発想である。ガバナンスマネジメントを中心にプロジェクトマネジメントを捉えると、アカウンタビリティの実行がもっとも重要になる。

アカウンタビリティは事後報告では達成できない。アカウンタビリティの実行は手が打てるうちに報告する場合にはじめて意味を持つ。従って、報告も含めて、すべてのプロジェクトマネジメントアクティビティをプロアクティブに実行することが非常に重要になる。

プロジェクトは有期である。ものごとの先送りはダメ。プロアクティブに取り組みなさい

つまり、これは、ガバナンスマネジメントを前提にしたものである。また、仮説は、リスクとして管理できるので、

分からないこと、決まらないことがあれば、仮説を作って進めていきなさい。

という話になる。

しかし、チームマネジメントの視点からいえば、延期が正しい選択であることは十分に考えられる。その典型的なケースが、戦略ノートで書いている顧客のニーズを中心にプロジェクトを進めていく場合である。この場合には、延期戦略をとり、段階的な詳細化を行っていくことが望ましい。

「段階的詳細化はプロジェクトマネジメントの基本じゃないか」と思われた方も多いだろう。段階的詳細化というのは、投機戦略の苦肉の策である。しかし、ここで言いたいのは、延期戦略としての段階的詳細化、つまり、詳細化を意図的に遅らせるというプロジェクトマネジメントである。

一般的な段階的詳細化は戦略的ではない。しかし、詳細化を意図的に遅らせることは戦略的である。

別の言い方をすると、決めないことにより、スコープに対する自由度が上がる。これがプロジェクトにおける延期の意味である。

ガバナンスを重視するか、チームを重視するかによって、延期戦略の是非は変わるのだ。

マクドナルドが地域別の販売価格の導入をする。

改めて説明をするまでもないと思うが、マクドナルドは標準化をコアコンピテンシーにする企業である。ぼくは仕事柄、あちこちに行くが、マクドナルドほど均質なサービスを提供している外食チェーンやファーストフードはないと思う。特に、カウンターでの対応と、デリバリーの時間の均質さは凄いと思う。

そのマクドナルドが自ら標準を破った。表向きの理由は、コストの違いだという。店舗の維持費、労働コストなどが都会と地方では違うので、変えるとのこと。まあ、こういう言い方がもっとも当たり障りがないのだろう。

標準もある程度成熟してくると、高度化させていく必要がある。最初は、材料であり、プロセスであり、デリバリ時間であり、価格であり、コストであった。しかし、これらはいずれも内部要因に起因するものであるので、自分たちは標準的だと思っていても、外からはそうは見えないケースが多い。

プロセスの標準化をみているとすぐに分かるが、プロセスの標準化を阻害するものは外部要因である。ビジネスプロセスであれば、顧客、地域、調達などが問題になることが多い。しかし、これを公式に扱うことは非常に難しい。それゆえに、各部門で実情に併せて、カスタマイズして使ってくれという話になる。標準化という名をとって、実を捨てた格好になる。

なぜ、難しいのだろうか？標準から外してよいものと、残すものが分からないのだ。

標準化が一定の浸透をしてきた際には標準化されるべきものが変わる。最初は外面的、具体的なものであるが、それがだんだん、内面的、抽象的なものに変わって行く。これがプロセスが成熟するという意味だが、新たに標準化すべき対象を見つけるのが難しいのだ。

このマクドナルドの動きを見ていると、さすがに標準化のチャンピオンといった感じを受けた。

マクドナルドが標準として残しているものは、顧客とっての価値の標準化ではないかと思う。今回の地域別価格でそれがすべて実現できるかどうかは微妙だ。むしろ、テスト的な意味合いがあるのだと思うが、価格といった外形的なものではなく、顧客にとっての価値という抽象的なものを標準化するという発想は素晴らしいと思う。

もっとも、今までもマクドナルドは、「スマイル０円」という価値の標準に先鞭をつけていた。これは、ウィットだと捉えられていたと思うが、今度はいよいよ、価値の問題の本丸に手をつけた。成功するかどうか、見ものである。

さて、我々のビジネスに戻るが、カスタマイズというのは本来、部門に任せるものではない。マクドナルドでも、地域別にするというのだけを決めて、価格は地域で決めてくれというと大混乱が起るだろう。

標準に対するオーナーシップは、標準を策定する部門が持ち続ける必要がある。その中で、ユーザにとっての価値のメトリクスを導入し、そのメトリクスが、フェアになるようにカスタマイズを仕切っていくことが重要である。

チームをマネジメントするとはどういうこと？

の中で、僕自身、このテーマは後で書くといったことをすっかり忘れていた。コメントを貰って思い出した。ありがとうございました。

この話は本質的な解決というのはないと思っている。それは多くの人が感じていることだろう。ぼくが言いたいのは、パラダイム（ものの見方）を変えようということだ。

たまたま、昨日、「問題はなかったことにしよう」という記事を書いたが、実は、メンバーのスキルの問題もここから始まる。多くの人がプロジェクトには問題がないと思いたい。だから、スキルの低いメンバーなどいるはずはないし、いたとしてもそれは一時的なことであって、変わっていくと考えたい。こういう話になる。

このような問題を直面しないままにこの問題を考えてみても、解決策はおろか、問題への応急処置をして前に進んでいくことすら難しくなる。

まず、最初にすべきことは、それを問題としてみるのではなく、現実として認識することである。その人はそれだけのスキルかないと認め、スキルそのものを想定に近づけようとは思わないことだ。

つまり、想定している生産性で仕事が進むことなどありえないと考える。ここが受け入れられるかどうかが最大のポイント。そして、育成は別の問題だと考える。

これがパラダイム転換。

念のために言っておくが、想定納期ではできないとステークホルダに対して開き直れといっているわけではない。この現実を認めた瞬間に、想定納期は「ストレッチされた目標」になる。これをスキルの低い人に責任をおっかぶせるではなく、チームとして計画的に対処する方法を考える。これがマネジメント。

すると、仕事の進め方が変わってくる。ＰＭＢＯＫで、ＷＢＳとＯＢＳでフォーメーションを設計し、ＲＡＭで統制するという考え方はリソースの能力が均質で、スキルセットが揃っていることが前提になっている。ゆえに、スキルセットが揃っていなかったり、能力にでこぼこがあるとすれば、このようなスキームは使えない。

工数見積もり（生産性の調整）でカバーできると思う人がいると思うが、もし、できるならそれでＯＫ。パフォーマンスの違いは生産性で調整できても、スキルセットのギャップは調整できないケースが多いので、みんなが頭を悩ましている。

スキルの低い人がいることを前提として考えると、仕事の分解の際に仕事そのものにグレードをつける必要がある。例えば、スキルレベルをＡ、Ｂ、Ｃとすれば、生産性ではなく、仕事の内容で、Ａランクの仕事、Ｂランクの仕事、Ｃランクの仕事とする。

ＩＴであれば、テスト、コーディング、プログラム設計、システム設計といった業務セグメントの難易度ランクはすでにあり、この範囲ではスキルレベルを調整している（現実には人手不足でできていないとしても、そういう考え方になっている）。

ここでさらに、それぞれの仕事の中を分解して、グレードをつける。例えば、テストであれば、テストのロジック設計をする人、テストのドキュメントを書く人、実際のテストをする人、環境設定をする人といったグレーディングをする。そして、グレードにあった人を割り振っていく。スキルレベルが揃っていれば縦割りの分担をするが、それを横割りにして分担をする。

こういう風に仕事を分解すると、実は、技術的な意味での専門性が必要になるのは、各セグメントでトップ、あるいは、２番目くらいまでのグレードである。それ以下のグレードは、技術的な専門性よりも、ドキュメントを書けるとか、正確に仕事をできるとかいったコンピテンシーの方が重要である。

ということは、セグメントに横断的に人材を活用できる。これにより、Ｂランクや、Ｃランクの仕事の一部を経験しながら、いろいろな仕事を見ることができる。これがひとつ、育成的視点からは重要なところだ。単に技術を覚えさせるだけではなく、仕事をするというのがどういうことかについて多様な経験をする機会になる。

技術的なスキルについては、そのような仕事をしながら、アシスタント的な仕事をする中で覚えさせればよい。これを下手に、専門性などで担当を決めて、設計者の仕事は設計をすることであって、ドキュメントを作ったりすることではないなどとやっていると、ロクな人材が育たない。下積みとして、自分の仕事に関連することを全て経験するというのは、日本型経営の優れた点だと思うし、今後も維持し続けるべき点だと思う。

こういう工夫をしているプロジェクトは結構ある。うまく行っているところも多い。繰り替えになるが、日本の組織というのはかつてはこういうやり方をしていたのだ。それをもう一度、プロジェクトマネジメントの枠組みを使って、体系的に実行してみようという話だ。

毎日、ニュースや報道バラエティで年金問題をやっている。

自民党の議員や民主党の議員がいろいろと説明している。自民党は節操のない方針変更はともかくとして、一貫して、細かいことよりは「とにかく大丈夫だ、任せてくれ。民主党さん、不安をあおるのはやめてくれ」と一貫していっている。これに対して民主党はあくまでも論理的に整合しないと国民は納得しないだろうというスタンスを貫いている。

両政党の政治的に立脚するところの違いか、単なる選挙のためのスタンスかは分からないが、結果としてどちらの言い分が通るかは非常に興味深い。

確かに、民主党のいうように、倫理的に整理しないと納得しない層が一定の割合でいる。この問題の、もう一人のプレイヤーであるマスコミは、今のところ、ここにフォーカスして報道しているように見える。

しかし、問題をなかったことにしたいと思っている人たちがいることも間違いない。当事者であることが分かっていないわけではない。当然、年金制度が破綻すれば自分たちが困ることはよく理解している。しかし、どういう問題が起っているかを知りたくない。できれば知らないままで、丸く収まってくれれば、ありがたい。万一、税金の投入でもしないと収まらないとしても、仕方ないと思うことにしよう。こんなマインドの人は、きっと論理的に納得したい人に匹敵するくらいいると思う。

これを単に当事者意識がないと批判するのは短絡過ぎる。

「日本沈没」という小説があったが、その中で、日本列島が沈み始めたときに、何もしないで日本列島と一緒に沈んでいくことを選ぶ意見を持つ有識者たちがいるという話が出てきた。これも本質的に同じ話しだ。このようなことを書ききった小松左京の人間観は興味深い。

ちょっと前に、宮崎県の裏金発覚で、「知らなかったことにしてくれ」といった定年を控えた出先機関のトップがいた。どんなタイプの人か分からないので、なんともいえないが、ひょっとすると、このトップも自分からは間違っても言わないが、誰かがリークし、それが自分の身に降りかかってくるのは運命だと思うある種の潔さは持っているかもしれない。このマインドはおそらく日本人に染み付いているマインドだと思う。

別に、役所に限ったことではない。組織の中でもこんな話はいくらでもある。感覚であるが、民間企業の管理職の半分以上はこのタイプではないかと思う。

また、必ずしも、上の人間に限ったことではない。実は下の人間も「これは知らせるべきことではない、知りたくもないだろう」といった調子でこのマインドを持ち合わせている。日本組織のアカウンタビリティが低い背後には、この不思議な利害関係の一致があるのだ。

これは、ある企業でシニアマネジャー（部長）から聞いた話。プロジェクトマネジメントの導入ステップが進み、リスクマネジメントの導入をする段になって、リスク分析などいらないと本気で言い出した。いわく

「リスク分析などすると、自分が知らなかったではすまなくなる。リスクがあるのは分かっている。でも、それも含めて、プロマネに飲み込んで欲しい。プロマネの骨は拾うし、まあ、そうなると自分の骨もまた、上の人に拾ってもらうことになるだろう」

半分くらいはプロジェクトを失敗したところで個人的に責任追及されるはずがないと高をくくっていっているのは間違いないが、半分くらいは本音ではないかと思う。注目したいのは、この部長、社内でも結構切れ者で通っているらしいが、この発言からも分かるようにリスクマネジメントの本質を実に的確に理解していることだ。その上で、言っているのだ。

実際に、このマネジャーが主催するプロジェクトレビューのミーティングに参加したことがあるが、見事なものでこの本音を地でいっている。

通常のレビューミーティングはプロジェクトには少なからず問題があるという前提でやるが、このマネジャーは問題がないという前提でレビューミーティングをしている。

例えば、こんな感じだ。

スケジュールが遅れているとしよう。これ自体は誰がみても問題である。このマネジャーもこれを否定するわけではない。予実を目の前にして、これは遅れていないことにしようと言い出すわけではない。

ところが、彼の頭の中では、「プロジェクトには問題はない」と思っている（思いたい）ので、目の前の問題を潰すことに意識を集中する。

ここで、プロマネがひと言、本質を突いた原因を言えばいいのだが、上の利害関係一致の構図で、「どうも、見積もりが甘かったみたいです」と何の根拠のない原因を語った上で、「すみません。もう１人メンバーを追加してもらえないですか」と来る。

これで件のマネジャーの顔は立つ。喜んで（というか、渋い顔をしながら、内心ほっとして）プロジェクトにもう一人、リソースを工面する。

かくして、プロジェクトマネジャーとマネジャー（スポンサー）の見事な一致協力で、問題はなかったことになる。

もっといえば、多くの場合、そのプロジェクトで問題が再発する（笑）。そんなプロジェクトは、「問題対応も適切にしたし、君はよくやったよ。いい経験したね」とシニアマネジャーからプロマネへのひと言の振返りとともに終結する。

これですべてが丸く収まる。このシニアマネジャーはプロマネの人事考課者なのだ。

最初はよそ事だと思っていた人もここまでくれば、相当な確率で思い当たる部分があるのではないだろうか？

「問題をなかったことにしていないか」を一度、点検してみてほしい。

昨日のメルマガの編集後記に技術屋と技術者（エンジニア）の違いを書いた。

技術屋と技術者（エンジニア）の違いは、技術に対するスタンスの違いではなく、経
営に対するスタンスの違いです。

　技術屋は技術に貢献します
　技術者は事業に貢献します
　これはいずれも、最終的には経営に貢献します

技術畑ではない人は、業務という言葉で置き換えてください。開発、企画、マーケテ
ィング、総務、人事など、なんでも結構です。

というフレーズだ。数通、個人的なご意見を戴いたので、ブログで再度、コメントしておく。

メルマガでははっきり書かなかったのだが、この後記で書きたかったのは、技術者のことではなく、プロジェクトマネジャーに対すること。

最近、気になっているのがプロマネ屋というのができつつあるのではないかということだ。上の言い方をすれば、

　プロジェクトマネジャーは事業に貢献します
　プロマネ屋はプロジェクトマネジメントに貢献します

という感じである。ただし、プロマネ屋は経営には貢献しない。ここが問題。

もちろん、全面的に否定しているわけではない。いまだに、プロジェクトマネジメントというのものに興味を示さない人も多く、その人たちと較べるとプロジェクトマネジメントという点からは進化している人たちだ。ただ、一皮、むけて欲しいなと思っており、そういうニュアンスのコメントです。

このブログでは、何度か、「隠すというスタイル」について書いてきた。その中でも書いたが、プロジェクトの情報をプロジェクトスポンサーやその代理人であるＰＭＯにすべて開示すると、プロジェクトの進行に影響が出てくる。干渉されることもある。従って、隠すことは必要だという考えは一定の合理性があるようにも思える。

こういうプロジェクトマネジャーが「プロマネ屋」である。

昨日の編集後記に対して、技術屋では経営に貢献できないのではないかという意見を戴いた方がいる。これは微妙なところがあるが、僕自身は貢献できると思う。企業が持つ技術ポテンシャルを大きくすることは、かりにそれが戦略との整合性がないとしても貢献だと思う。それは技術というものの性格によるものであり、技術というのはお金（事業）や人材と同じくらい普遍的な資産であると思うし、現に、経営戦略と無関係に、企業の資産価値を高めているからだ。

要するに経営というのは、出資者から集めた資金、あるいは、その組織が持っている資源を活用して如何に収益を上げるかという活動であるが、その資源のひとつが技術であり、それゆえに技術屋は資源を増やすという意味で経営に貢献している。

ただし、これは原則的な議論であって、現実の経営ではここに評価期間の議論が絡んでくる。従って、最近の経営のように、顧客価値より、株主価値を重視して考え、四半期ごとに収益を重視するような戦略の中では、技術のようにキャッシュサイクルが長いものは低い評価をされる傾向がある。ただ、これも企業価値という議論においては、さほど、本質的な話しではない。企業価値の評価の中では、株主（ステークホルダ）の評価もされるからである。

さて前置きが長くなったが、問題のプロマネ屋。プロマネ屋は技術屋のように経営に貢献できない。プロマネ屋は、自らのプロジェクトの目標を達成するために全力を尽くす。それはいいのだが、アカウンタビリティを考えないのがプロマネ屋の特徴だ。

こうなってくると、プロマネ屋は百害あって一利なしだ。プロマネ屋というのはスタンスの問題である。だから、技術屋がプロジェクトマネジメントに「はまる」とプロマネ屋になる傾向があるようだ。

プロマネ屋のプロジェクトマネジメントスキルは高いことが多い。そのスキルをプロジェクトマネジャーとして活かすことで、どれだけ経営にとって貴重な存在になるか。プロマネ屋になっている人は、ぜひ、早くこのことに気がついてほしい。

もっと現実的に言えば、プロジェクトで業績を残した人が、ラインマネジャーとして出世できるかどうかはこの点にかかっているといっても過言ではない。まあ、これは別の議論だが。。。

最後に、ひとつ。僕は技術コンサルティングをやっていた時期に、マネジメントチームを作って、何度か、数億～数十億規模のＳＩプロジェクトの「雇われ」プロマネをやった経験がある。これは純然たるプロマネ屋仕事だ。要するに、自分の任されたプロジェクトが成功すればよいのだ。当然だが、組織の中に入り込み、人脈を使い、結構、えげつないリソースの取り込みとかをするし、ベンダーもその組織の付き合いとは関係なしに決める。当然だが、覚悟が要る。この覚悟ができるのであれば、プロマネ屋で生きていくというのもひとつの選択だとは思う。

当時、ある人に、プロジェクトマネジメントという刀一本で組織に切り込んでいくといわれたことがあるが、母体組織も含めて力で動かすしかないわけで、まあ、しんどい。ちなみに、５年くらいこういう仕事をしていた。プロジェクト予算の１０％程度で契約するので、それなりに儲かるが、それ以上続けようとはおもいませんでした。経験談。