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

◆プレミアムとは

先日、パソナテック様のＩＴプレミアムという事業のオープニングのセミナーの講師をした。事業内容はパソナテックのホームページを見て戴きたいのだが、こういう分野にプレミアムという概念が持ち込まれるようになったかと思い、多少、驚いた。

ベンツに乗って９９円ショップに行くという比喩ではないが、最近の消費財（ＢｔｏＣ）の市場傾向として、二極化と、高級（プレミアム）と低級の使い分けという消費者行動が見られるようになってきたという指摘がよくされる。その中で中級だけが苦戦している。

この市場傾向はしばらく続くと思われるが、問題はプレミアム市場で日本企業はまったくの無力だということだ。プレミアム市場を圧巻しているのは海外企業で、ついでにいえば低級品市場ではもう中国にかなわない。そんな市場構造の中で、中級品のニーズがある海外市場で好況感がでているというのが今の日本企業だろう。

そんな中で、昨年、ローランド・ベルガー会長と早稲田大学教授という二足のわらじをはく遠藤功さんが、「では、どうすれば日本発のプレミアム商品を作れるのか?」をテーマに「プレミアム戦略」という本を書かれた。

「プレミアム戦略」

この本の中で遠藤氏はプレミアムを

　「プレミアム」=「機能的価値」+「情緒的価値」

と定義している。

◆プレミアム商品の作り方

そして、海外のプレミアムブランドは、「物語」や「ストーリー」などを駆使し、情緒的価値を作り上げているのに対して、日本のブランドには情緒的価値が希薄であると指摘している。

これまで、中級市場をメインにやってきた企業がプレミアム市場で成功するのは至難の業であるが、今後はなんとかやりきらなくてはならないのだろう。最近の取組で、このような取り組みで最も目につくのはやはり、レクサスである。海外では中級ブランドとして成功を収めているLexusを２００５年に日本ではプレミアムブランドとしての展開を始めた。競合ターゲットは、ＢＭＷ、メルセデス、アウディといったところだ。この取り組みの中では、立派なショールームを作り、きちんとした対応をするととにも、従来にはないメンテナンスサービスを提供遠藤氏の指摘する物語を重視している。

さて、ここで注目したいのは、この情緒的価値は消費材に限ったことかという話だ。

◆生産財におけるプレミアム

生産財では、当然ながら、機能的な価値を徹底的に追及する。機能的価値がその商品を使う顧客のビジネスの生産性に直結するためだ。ところが情緒的価値がないかというと決してそんなことはない。たとえば、信用である。

みなさんの会社にもいると思うが、顧客からの指名されるプロジェクトマネジャーというのは必ずいる。これは機能的価値が評価されているようにも思えるが、マネジメントは技術と比べると複雑であり、技術者が指名されるよりははるかに情緒的価値が高い。

ある企業が、この点に注目をし、指名されるプロジェクトマネジャーのコンピテンシーやスキルに着目し、プロジェクトマネジメント標準の中にプロセス、および、コンピテンシーとして含めたところ、要件定義の問題が発生したプロジェクトが当初の７０％から、２０％まで削減できたという事例がある。

これこそ、プレミアムである。このシリーズでずっと述べてきているディライトとプレミアムというのは強い関係がある。

ディライトを提供できるのはプレミアムはプロジェクトなのだ。

◆３つのマネジメントの重要性

ミドルマネジメントは、トップマネジメントが示した経営方針や経営目標に対して、自部門の目標を設定し、ロワーマネジメント（現場管理者層）を通じて一般社員に実行させる役割を持つマネジメントである。

欧米では、マネジメントの重要性として

（１）トップマネジメント
（２）ロワーマネジメント
（３）ミドルマネジメント

の順になっている企業が多い。これに対して、日本企業は

（１）ミドルマネジメント
（２）ロワーマネジメント
（３）トップマネジメント

の順になっている企業が多い。

◆連結ピンとしてのミドルマネジメント

特に、ミドルマネジメントはリカートのいう「連結ピン」として機能することにより、全体のパフォーマンスが高くするという重要な任務を果たしていると考えられていた。

これは経営制度や価値観の違いによるところが大きい。欧米はトップマネジメントが比較的細かな目標設定までするに対して、日本ではトップにそのような役割が求められて来なかった。その一つの理由に年功序列があると思われる。欧米の大企業のトップとしてバリバリに仕事をしているのは４０代が多い。４０代はおそらく総合的な意味での人間の情報処理能力が最も高く、経営細部にわたるマネジメントが可能だったと思われる。また、それを補佐する経営チームの導入も進んでいた。

これに対して、日本ではバブル前までは大企業のトップは５０代～６０代であり、７０代のトップなども結構いた。いくら経営スタッフをつけてもこの年代のトップマネジャーに経営細部にわたる判断をするのは難しく、おのずとミドルマネジャーにその役割が移っていたのではないかと思われる。

◆ミドルの崩壊

ところが、バブル期を経て、右上がりの成長が止まるとこの状況が一変した。作っても売れなくなった。そこで、当時の経営トップはどういう行動に出たか？多くの企業は自分たちの立場は変えないために、成果主義を導入した。成果主義では、基本的に中間層は必要ない。トップマネジメントとロワーマネジメントさえしっかりしていれば、成り立つ制度である。

これに加えて、情報化の進展が重なり、急激に中抜き経営が進んでいった。ミドルマネジメントが崩壊していったのだ。つまり、マネジメントの重要性は米国と同じく、

（１）トップマネジメント
（２）ロワーマネジメント
（３）ミドルマネジメント

となってきたわけだ。

結果、何が起こったか？日本の強みであったはずの現場の崩壊であり、それによる経営そのものの弱体化である。現場力で勝ってきた企業は瞬く間に崩れ去っていった。

◆グローバル化か、ミドルマネジメントの再構築か

これらの企業がこれから２つのオプションを選ぶことになる。ひとつはグローバル化による経営の強化である。もう一つは、現場の再構築である。前者の典型例はソニーだろう。特に動きの激しい電子・情報の業界を中心にこれからもこの方向性を持つ企業は増えていくと思われる。問題は後者である。

社名を上げるのは控えるが、かなりの割合の企業が現場の再構築に取り組んでいる。開発力の再構築だったり、技術力の再構築だったりする。ところがあまりうまくいっているようには見えない。

これはそのような戦略を取るある大手メーカの役員に聞いた話だが、なかなかうまくいかなということと同時に、時代に逆行しているような感覚があると言っていた。

これはある意味で当り前である。ミドルマネジメントが機能し、現場も強かった時代とは経営環境が一変しているからだ。現場の再構築といっても、少なくともこの時代に戻すという選択肢はない。トップマネジメントが機能しないと方向性を見失ったままで、沈没してしまうような時代なのだ。ただ、この点は変わりつつあるといってよいだろう。

◆現場の再構築にはミドルマネジメントの再構築が不可欠

問題は現場を再構築するにはどうすればよいかということだ。これには、短絡的にロワーマネジメントに手を入れるのではなく、成果主義で失われたミドルマネジメントを再構築することが先決ではないかと思う。過去に現場が強かったのは、技術力とか、開発力とかいった力だけではなく、ミドルマネジャーのトップと現場の調整機能、部門間の調整機能や、これらを基盤にしたロワーマネジメントに対するリーダーシップなどの存在があったからに他ならない。

少しずつ変わりつつあるトップマネジメントに対応できるミドルマネジメントを再構築する必要がある。

このようなミドルマネジメントでキーになるのがプログラムマネジメントではないかと思う。特に、ロワーマネジメントにプロジェクトマネジメントが導入されているときには、プログラムマネジメントは強力なミドルマネジメントのツールになるはずだ。

◆おわりに

今回の話はここまでにして、最後にプログラムマネジメントの位置づけに対してコメントをしておく。ＰＭＩの標準ではプログラムマネジメントはロワーマネジメントとして位置づけられ、トップマネジメントとしてのポートフォリオマネジメントがあり、整合させるような構図になっている。これに対して、日本のＰ２Ｍではプログラムマネジメントをミドルマネジメントと位置付けている。この標準の位置づけを見ても、日米のミドルマネジメントの重要性の認識が違うのが分かる。

　自身が権限を持たないので、できることしかできない

というプロマネがたくさんいる。これはある意味で真実だ。これから内部統制も厳しくなっていく中で、ここをはずすことはできない。

ただ、ひとつ考えてほしいことがある。

みなさんは、部下に任せるということは普通にやっていると思う。では

　なぜ、上司やステークホルダに任せないのか？

部下に任せることと、上司に任せることの間には２つの決定的な違いがある。ひとつは、部下に任せる多くのことはプロマネ自身が実行することもできる。しかし、上司に任せることの多くは上司にしかできないことだ。

上司にしかできない理由は、まれに業務遂行能力、スキルなどに依存するが、ほとんどのケースは権限の問題である。つまり、業務そのものはできるのに、権限がないからできない。これがプロマネが権限にこだわるひとつの理由にもなっている。

もう一つの違いは、部下には程度の差こそあれば、命令、あるいは指示、あるいは指導ができる。しかし、上に任せる場合にはこれはできない。どのようにやるかは上司の判断に任せる必要があるし、結果の是非についてもある程度上司に任せざるを得ない。

整理すると、上司に任せる場合には

（１）自身はできないことを任せる
（２）判断そのものを任せる

の２つが求められる。

こうなってくると、「お山の大将」的なリーダーは到底、任せようなどとは思わない。結果、何をするかといえば

（１）できる範囲でやる
（２）あなたの責任でやってくれと投げ出す

である。いずれも箱からでないでできることだ。これでは話にならない。

では、どうすればよいか？答えは簡単だ。

プロマネ（自身）が考えているとおりに、上司が「自発的に」動くようにする

ことだ。これには２つの問題がある。ひとつは、上司にそのように動こうと思わせるにはどうしたらよいかだ。もう一つは、上司が考えたことが本当にできるかどうかだ。

後者についてはある意味で、メンバーに任せるよりは簡単だ。プロマネの上司といえばおおよそ課長級で、課長級となるとそれなりに能力がないとなれないからだ。

ここで、プロマネの中には、上司の「無能さ」を批判する人も少なくないが、フェアな立場できいていると、だいたい、前者がきちんとできていない。したがって、思った通りには動いてくれず、その不満を言っている人が多い（もちろん、中にはピーターの法則を絵に描いたようなマネジャーもいるけど）。

ということで、上司に任せるための問題は、

上司をどのように動かすか

にかかっている。このときに、正論を言えば動く（べきだ）と思っているようでは、永久に動かすことはできないだろう。つまり、説得などの何の役にも立たない。上司には上司のキャリアがある。上司だってあなたと心中したいとは思っていないのだ。

そこで出てくるキーワードが「影響力」である。影響力が発揮できれば、上司は動く。もちろん、上司以外のステークホルダにもこれまで述べてきたことはすべて当てはまる。

上司に任せるために影響力を身につけよう！これも一種にリーダーシップである。

ミーティングマネジメント本などにもあまり書いていないが、ミーティングによる意思決定をする際にアジェンダマネジメントというのは極めて大切である。

分かりやすいのが、今、国会でやっている道路特定財源の協議だ。新聞の世論調査結果などを見ると、入口でもたもたしていることに対する批判が多いようだが、たぶん、ここが大切なのだ。「暫定税率をなくすかどうか」という協議をするのと、「暫定税率を何％にするか」という協議をするのでは、論点が全く異なる。自民党のいうように、確かに数字上でいえば、％の協議をする中で０％という選択もあるということになるが、存続を「前提」にしているのだから極論として扱われ、まず、この意見が影響を与えることはないだろう。だから、民主党は拘る。

柔道でいえば、組み手のようなものだ。組み手によってそのあと、出せる技が異なってくる。

プロジェクトの中でもミーティングアジェンダの設定が、その後のプロジェクトの流れを決めることは少なくない。にも関わらず、ほとんど無意識のままで進んでいるのが怖いところだ。

以前はミーティングの達人の話を聞くと、例外なく、ミーティングは会議の設定がされた時点でほとんど終わっているといっていた。今は、違う。ファシリテーションをうまくして、多くの意見を引き出し、よい結論を生み出すことこそが重要だという。

もうお分かりだろう？ファシリテーションをいくら上手にやってみたところで、アジェンダの中での話だ。もし、アジェンダを無視した議論をしたとすれば、仮にそれでいくらよい議論が得られたとしてもそれはビジネスとしてルール違反である。

たとえば、スケジュールが遅れてきたときのミーティング。「このあとどうするか」というアジェンダを設定するのと、「遅れてきたスケジュールを如何に回復するか」というアジェンダの設定をするのでは内容も意味あいもまったく異なる会議になることは容易におわかりいただけるだろう。

さすがに、「とりあえず集まろう」という会議は少なくなってきた。これだけでも進歩だと思うが、もう一歩、踏み込んでアジェンダマネジメントをきちんとやるようにすれば、もう少し、プロジェクトの統制ができるようになる。

プロジェクトをコントロールする手段はミーティングしかない。これはミーティングの中でのコミュニケーションでメンバーに指示をしたり、依頼したり、影響を与えたりすることが一つの方法だ。しかし、これ以上に重要なのはアジェンダとマネジメントして、プロジェクトの進め方をしっかりとコントロールしていくことだ。

知り合いのプロジェクトマネジャーに、シナリオを作るときにターニングポイントになるとことではミーティングを想定し、ミーティングアジェンダをだいたい設定してしまうという人がいる。その人のコミュニケーションログを見せてもらったことがあるが、確かに、ミーティングアジェンダを並べてみると、大体、プロジェクトの流れが分かるので大したものだ。

もっとアジェンダの設定にこだわろう！

◆顧客が満足するには対話が必要

「顧客が満足する」にはどうすればよいか？プロジェクト要求定義をしっかりとして、顧客の要求を適切に把握するといったところにすぐに行きつくかもしれない。しかし、これは「顧客を満足させる」ための方法にすぎない。

顧客が満足するには、「対話」が必要だ。

対話とは何か？「コミュニケーション」だと答える人もいると思うが、一般的な意味でのコミュニケーションではない。古代ギリシア時代に多くの哲学者により、弁証法という方法が考えられた。弁証法は、テーゼ（正）、アンチテーゼ（反）、および、それらを本質的に統合したジンテーゼ（合）の３つで思考を深めていく思考方法である。

手軽に弁証法のことを知りたい人は、僕が大ファンである仲正昌樹先生の

仲正昌樹「知識だけあるバカになるな!」、大和書房（2008）

をお勧めしておく。

◆弁証法とディライト

弁証法と顧客が満足するディライトはどう関係があるのか？特に、ディライトという場合、ベンダーが画期的なことを考えて顧客が感動を生めばよいのではないかと思いがちである。

ちょっと脱線するが、リッツカールトンはなぜ、あんなにすばらしいサービスを提供できるのだろうか？全従業員がクレド（credo：リッツカールトンのサービスの基本精神をかいたカード）を持ち歩いているからか？従業員の誰もに、スイーツの宿泊費に相当するような裁量を与えているからか？もちろん、これらの仕組みは大切だが、何よりも大切なのは、顧客が中心にいて、顧客とのやり取り（対話）によってサービスが向上していくからだ。

初回に、期待と実績の話をし、期待と実績をバランスよく向上させていくのが顧客が満足する方法であり、ディライトを提供する方法だと述べた。そのためには、対話が必要なのだ。違う言い方をすれば、サービスを顧客と一緒に作り上げていくことによって、ディライトの提供が可能になる。

◆ウォーターフォール（一方通行）プロセスでは対話はできない

さて、プロジェクトの話に戻ろう。プロジェクトにおいて顧客が満足するにはどうすればよいか？言い換えると対話をするにはどうすればよいか？

ここで必要なのは、ウォーターフォール型のプロセスの精緻化ではない。いくら頑張っても一方通行のウォーターフォールプロセスでは顧客との対話を深めていくことはできない。顧客との対話によってスコープが決まっていくスパイラルプロセスが必要である。

顧客との対話を重視する場合に、何が必要か？対話は顧客から聞き出すことではない。顧客がこうしたい（テーゼ）といえば、それにはこういう問題がある（アンチテーゼ）と反論をする。ここから始まり、プロダクトの利用者は何が欲しいのか？、そもそも、この機能を持つことはどういう意味があるのか？などといった問答を繰り返し、最初は持っていなかった結論を生み出していく。このプロセスが弁証法による対話である。

◆対話には顧客中心型チームが必要

顧客がプロジェクトチームの外部にいる限り、対話は成り立たないのではないかと思う。顧客をプロジェクトチームの中、それも中心に座らせる必要がある。そして、対話を行いながら、顧客がプロジェクトを動かしていけるようにサポートを提供する。

そんなフォーメーションが必要である。このようなフォーメーションはＣＤＴ（Customer Driven Term；顧客中心型チーム））と呼ばれ、今後、プロジェクトマネジメントのやり方の一つになっていくと思われる。

◆プロジェクトマネジメントはディライトを目指す

プロジェクトマネジメントを競争力強化のために導入したのだとすれば、目指すものは極めて明確だ。顧客満足ではなく、カスタマーディライトである。追って説明していくが、プロジェクトマネジメントの目的から展開していくマネジメントの考え方はディライトを実現するために最適であるといってもよい。

この議論をする前に、前回定義した顧客満足について、もう少し、深堀しておきたい。

◆「顧客が満足する」のか、「顧客を満足させる」のか

品質マネジメントにおける顧客満足活動というのは「顧客を満足させる」ことである。顧客を満足させるというのはどこまでいってもサービスや商品の「提供者の視点」での活動である。品質マネジメントにおける顧客満足は基本的に提供者の視点からの品質の一要素であるので、これはある意味、当然のことだ。

極論すれば、どれだけ満足するかについては顧客の「勝手」であり、提供者側はできるだけよいものを提供するように努力する。「結果」として顧客が満足するということだ。ここで「よいもの」の指標の一つに顧客がどれだけ満足しているかがあるが、それは、約束した機能が提供されているとか、約束した性能が実現されているといった品質指標の一つでしかない。

つまり、「顧客が満足する」ものを提供することを目的とする活動ではない。

一方で、顧客満足というのは、顧客を満足させることではない。「顧客が満足する」ことである。まず、ここの意識を変える必要がある。そのためには、「顧客の立場」で考えることが重要だ。たとえ品質であっても、顧客の立場に立った品質を作りこんでいかなくてはならない。

◆品質絶対は思考停止

以前、

品質絶対は思考停止

という記事を書いたが、この話はまさにそうだ。

ベンダー側からみた最高の品質は欠陥ゼロ（ゼロディフェクト）である。しかし、顧客が本当にそれを求めているかどうかは別である。これは納期とのトレードオフとか、製品原価とのトレードオフといったプロジェクト品質の問題を言っているわけではない。顧客はベンダーの考える品質に関心のないと言った方が正確だろう。顧客の立場からの品質は調達している製品により顧客自身の提供するサービスや商品の品質が高くなることである。調達する製品の品質がよかろうと悪かろうと関心がない。

ここを掛け違えて、顧客に提供する製品の品質レベルを決めてもらっているようなベンダーが少なくないが、そのようなベンダーは永遠に顧客の要求を正しく把握して、提供することなどできないだろう。それを行う唯一の方法は顧客の立場で考えることだけだからだ。

プロジェクト品質の議論では、ここにさらに、サービス要求が絡んでくる。つまり、納期だとか、原価、あるいは、コミュニケーション、ライフサイクルマネジメントなどである。そうすると、ますます、顧客が満足するのは何が満たされたときかを考えることが重要さを持ってくる。

◆何のためのプロジェクトマネジメントか？

多くの組織は「顧客を満足させる」ためにプロジェクトマネジメントを行っているが、これではディライトを目指すプロジェクトマネジメントとしては不十分である。ディライトを目指すためには「顧客が満足する」ことを目的としたプロジェクトマネジメントを行う必要がある。

◆顧客満足の定義

ＩＳＯ９０００の２０００年版から品質マネジメント活動の一環として顧客満足の把握が要求されるようになり、製造業やＩＴにも顧客満足という考え方は一挙に浸透してきた。ＩＳＯ９０００がうたっている顧客満足とは、

　　顧客の要求事項が満たされている程度に関する顧客の受けとめ方

と定義されており、かなり、狭い意味でつかわれている。もう一つ、多くの企業に顧客満足という方向づけをしている活動にボルドリッジ賞を手本にして作られたといわれる日本経営品質賞があるが、この活動では「顧客満足の明確化」が求められ、顧客満足を

　　顧客に期待以上の価値が提供されたときの、顧客の心理状況

と広い意味で捉えている。経営管理と品質管理という違いがあるので、このような違いが出てきているものと思われる。

◆顧客満足の評価

顧客満足の評価としては、リチャード・オリバー（Richard L.Oliver）が提唱している「期待不確認モデル（expectation - disconfirmation model）」がもっともよくつかわれている。このモデルでは、期待（Ｅ）と実績（Ｐ）に注目し、その大きさで顧客満足を評価している。

すなわち、

　Ｅ＜Ｐ　満足
　Ｅ＞Ｐ　不満足

と定義し、顧客満足度の把握（顧客満足度調査）においては、この関係を調査することに主眼を置いている。

このモデルを使うと、定義のところで述べた品質における顧客満足と、経営（製品やサービス）に対する顧客満足が異なることがよく分かる。ＩＳＯ２０００における顧客満足（ＩＳＯ９０００の顧客満足）というのは、Ｅ＜Ｐの状態ではなく、Ｅ＝Ｐである。Ｅ＜Ｐだといわゆる過剰品質ということになる。これに対して、日本経営品質賞では

　Ｅ≦Ｐ

の状態を顧客満足だと言っていることになる。

◆顧客満足の背景

さて、品質マネジメントにおける顧客満足にしろ、経営活動における顧客満足にしろ、その背景にあるのは、顧客が不満を持っているという前提である。ある意味で、これらの活動は顧客を満足させるための活動というよりは、顧客の不満を解消するための活動だといった方が適切である。

ところが、最近の傾向として、顧客満足を不満足の解消ではなく、満足を高めるととらえる考え方が普及してきつつある。これは従来の顧客満足と区別するために、カスタマーディライトと呼ばれる。カスタマディライトはオリバーのモデルでいえばＥ＜Ｐを言っているわけだが、単なるＥ＜Ｐではない。顧客が期待する以上の品質やレベルの製品やサービスを提供することで、顧客に「歓びや感動」を与えることだと定義される。

つまり、顧客満足におけるＥ＜Ｐとディライトは似て非なるものだと考えた方がよい。そのポイントはＥのレベルにある。

◆顧客の期待

オリバーモデルでＥ＜Ｐを作る方法の一つは顧客に高い期待を抱かせないことである。特に日本においては競争が規制されていたため、実際にいまでもそのようなマーケティング戦略を取る企業は多い。また、品質の面から顧客満足をとらえていく場合には期待を大きくすること自体が好ましくないと考える。これでは、仮にＥ＜Ｐが実現できても顧客の不満足心理は残る。

顧客はＰに対する理想（あるべき姿）を持っているからだ。

これに対してディライトというときの期待Ｅは、文字通り、顧客自身の体験を通じて想像しうる目一杯の期待である。そのような期待に対して、Ｅ＜Ｐのパフォーマンスを実現するのがディライトである。

違う言い方をすれば、よい意味で顧客の予想外のサービスや製品を提供することである。予想外であるゆえに感動するのだ。このように期待を位置づけるときの最大のポイントは、人間は「二度目は感動が薄くなる」ということである。つまり、一度、体験をすることにより、目一杯の期待値は高まる。

この関係をよく理解した上で、プロジェクトマネジメントやプロジェクト品質における顧客満足とは何かという問題を考えてみる。

道路特定財源の問題もいよいよ、大詰めになってきた。なにもなければこのまま、暫定税率は一旦廃止になる。

この１か月くらいを見ていてつくづく思うのは、「変えない」ことを前提にした議論をしていることだ。自民党や自治体の言っていることは、他のことは変えないで、この部分だけを変えるという前提で議論をしている。

他のことは何も変わらず（変えず）、暫定税率分がなくなると、財政的な穴が空いて（予定している来年度予算が足らず）混乱が起こる。これは当たり前のことだ。新規の道路工事を一切やらないとしても、混乱は収まらない（まだ、足らない）。

だから、暫定税率を無くす（仕組みを変える）などあってはならないという論法である。

もちろん、政治的な配慮もあってそのような論法を取っているのだと思うが、これと同じ論法をみなさんの組織の中で聞いたことはないだろうか？あるいは、みなさんは使っていないだろうか？

たとえば、こういう論理がある。

計画書を丹念につくると、プロジェクト作業の着手までに時間がかかり、顧客に迷惑がかかり、かつ、プロジェクトリソースの活用もスムーズにいかなくなる。だから、計画書をあまり時間をかけてつくることは、混乱のもとだ。いままで程度に作っておけばよいのではないだろうか？

これは正しいのだろうか？

朝日新聞を見ていたら、また、道路工事予算の問題がでていた。

●国土交通省が所管する道路・街路関連の国直轄事業や補助事業のうち、０２年度以降に完了・実施中の１１７６事業の過半数で、当初計画時より事業費が膨らんでいる。

●最終事業費が１００億円以上にのぼる道路・街路関連事業は１１７６、判明した当初事業費の総額は約４０兆６千億円。このうち当初事業費を上回ったのは５９７事業で、総額は約４８兆４千億円（差額　７兆８千億）。

●当初の３倍以上に膨らんだのは２１事業。理由は、「工場や病院、ガソリンスタンドなどの移転費用が増えた」「想定していなかったもろい岩質による崩落が発生した」など。用地補償費や工事費の見積もりが結果的に不十分だった。

●ひどい事例。青森県「白銀市川環状線」事業は完了が１５年も遅れたうえ、当初の約２４億５０００万円が、５．８倍の約１４２億２０００万円に。兵庫県主体の「阪神本線連続立体交差事業」は約１５２億８０００万円が約８３９億８０００万円に。

少し前に

計画されないプロジェクト
https://mat.lekumo.biz/ppf/2008/03/post-651a.html

という記事を書いたが、ここまでとは思わなかった。一応、工事積算基準、用地補償基準などはあるわけだから、ここまで来ると、費用対効果の数字を作るために、追加発注を前提にして当初見積もりを取っているのではないか？と疑ってしまう。

もっとも、仮にそうだとすれば倫理的な問題は感じるが、プロジェクトをコントロールできているという意味ではまだましかもしれない。これが無作為の数字であれば、事業者当事者としての能力に疑いを持たざるをえない。

前の記事でも述べたように、このような実態を作っている最大の原因は

　「スケジュールありき」

だろう。背景にあるのは、道路特定財源の設置当初からそうであったように道路が欲しいのではなく、工事がほしいという景気対策である。ゆえに、何が何でも計画通りに着手する。だとすれば、これでもまだ、よくやっている方だと言えなくもないか。

この構図は、企業のプロジェクトにもたくさん見られる。っていうか、これを裏返ししたのが、企業プロジェクトの実態だと考えてもよいだろう。道路工事を請けるゼネコンは、まったく準備ができていない状況で受注し、プロジェクトを走らせることになる。他の官庁でも同じだ。ＳＩ案件で予算だけつけて、仕様を決めないままで着手している例は少なくない。

あるＳＩ企業では、内部調査で失敗プロジェクトの８０％はスケジュールありきで実施していることがわかったそうだ。その大半は、「準備不十分なままで時計をスタートさせ、実質的に計画よりはるかに短い時間で完成させようとして品質の問題を起こしたか、納期遅れを起こした」だそうだ。

プロジェクトのスケジュールの要望は顧客が出すことが多いので、これを顧客側の問題に転嫁する人が多いが、実際に顧客の意見を聴くと、１０年使うシステムで、１０年間不適合で悩むよりは、１年カットオーバーが遅れる方がはるかにましだという意見が圧倒的に多い。

っていうか、要件定義ができないままでトラブって３年かかるよりは、プロジェクト開始を１年遅らせてでも要件を確定して、１年でやった方が、よほど早く、よいものができるだろうという短期的な話のような気もするが、、、

なんにしても、顧客側の問題だとかいって、ベンダーが言われたままで流されて、顧客ときちんと向き合った話をしていないだけだ。

つまり、スケジュールありきはほとんどは自分たちの事業成果（売上）の都合である。道路の比喩でいえば、サービスを提供することが目的ではなく、売り上げを上げることが目的なのだ。ゆえに、何よりもスケジュールが重要になる。国が景気対策で工事を作るのと、本質的に違いはない。

だからそんなプロジェクトのやり方は間違っているというほど、単純な話ではない。道路であれば政策の問題であり、企業であれば戦略の問題でもある。むしろ、問題なのは政策や戦略の中で成果に関する部分だけがひとり歩きしてしまって、その実現に必要な組織能力を持っていないことではないだろうか？実際に、道路についていえば、欧米の企業とはずいぶん生産性が異なるという話をよく耳にする。これは道路をつくる能力の違いだけではなく、労働政策とか、国土政策とか、総合的な政策の質の違いだと思われる。企業においても同じで、単にシステムを作る生産性の違いではなく、ＨＲＭ、組織マネジメントなど、さまざまな要因がシステム構築の生産性に表れているように思う。

ここをなんとかしなくてはならない。

エンジニアはプロセスが好きである。ある意味で当り前だ。工業製品であっても、ソフトウエアであっても、工芸品であっても、作り上げるまでのプロセスは必ずあるからだ。逆にいえば、プロセスがないとすれば再現性がなく、エンジニアリングとはいえない。

エンジニアからプロジェクトマネジャーになっていくとき、一皮むけるというのは、この信仰ともいってよいプロセスへのこだわりを捨てることだろう。

たとえば、ＰＭＢＯＫの４３のすべてのプロセスはインプットとアウトプットでつながっている。つまり、プロジェクトマネジメントを一つのプロセスで表現することが可能だと言っているようにも思える。たしかに、プロセスの「インプット→処理→アウトプット」の定義には当てはまっている。しかし、処理の内容をみればそうではないことは一目瞭然だ。処理の内容は思いっきり属人的なものがふんだんにある。というか、属人的ではない処理（ツールと手法）はほとんどない。したがって、形式的にはプロセスにしているが、再現性はほとんどない。

ＰＭＢＯＫはまだしも、プログラムマネジメント標準となると、技法とツールはすべてのプロセスに対してひとつである。つまり、インプットとアウトプットを明確にしているだけで、他は何も定義していない（これは、次のバージョンでは変わるらしいが、ＰＭＢＯＫレベルのツールと技法を指定するのは不可能だろう）。

したがって、ＯＰＭ３やＰＭＣＤＦといったメトリクス系の標準を使って、プロセスの品質を均質化させることを目指しているのだ。

これがマネジメントであり、正解がないということだ。ここで、よく認識しておくべきはこのような背景であるにも関わらず、ＰＭＩがプロセスに拘る理由はアカウンタビリティの確保だと思われる。仮に処理がなくても、インプットとアウトプットを明確にしておけば、アカウンタビリティを高めるには大変有用である。

これに対して、ＩＰＭＡはコンピテンシーを中心に標準化をしようとしている。プロセスを決めるのではなく、マネジメント行動として何をすべきかということを標準化しようとしている。

結果として、ＰＭＩとＩＰＭＡの標準というのは同じところに落ち着くのではないかと思うが、このポリシーの違いは大きいし、重要だ。トップダウンの管理をするために最も重要なポイントはアカウンタビリティの確保である。アカウンタビリティを確保した上で、あとは状況を見ながら指示していく。これが米国流プロジェクトマネジメント。（マネジメントの）行動規範を作っておき、それを実行させることで成果を生み出す。これが欧州流プロジェクトマネジメント。

もちろん、どちらの地域でも多くの企業はグローバル化されており、こんなステレオタイプの議論ができるような状況ではないのだが、なんとなく、イメージに合うのではないだろうか？

さて、日本はどうか？僕は米国流でも、欧州流でもないように感じている。日本には日本流がある。それは、何か。仕組みを作って成果を出すことだ。仕組みとはシステムである。システムとはプロセスと行動規範を合わせたものである。これが日本人の智慧だと思う。

プロセスでも行動規範でもなく、仕組み作りのプロジェクトマネジメント。エンジニアからプロジェクトマネジャーに脱皮するとはこの脱皮ではないだろうか？