プロジェクトマネジメント ワンポイント講義

プロジェクト・マネジメント(PM)、タイム・マネジメント(時間管理術)、プロジェクト・スケジューリング、などの分野で理解すべき用語と概念を解説しています。



プログラム・マネジメントとガバナンス

プロマネの悩みは誰が解決すべきか (2012/06/20)

半年ほど前のことだが、好川哲人氏の主催する「プロジェクトマネージャー養成マガジン 1000号記念セミナー」というイベントに参加した。好川さんはPM業界(?)における著名なコンサルタント兼エヴァンジェリストである。プロジェクトマネージャー養成マガジンという密度の高いメルマガを、ほとんど一人で書いて毎週何本も発信し、累計1000号に達したというのは、この分野にかける情熱の証拠であろう。16,000人ものの購読者がいることが、それを裏付けている。

さて、ラ・フォンテーヌ汐留で開催されたこのイベント、たしか30人近い人たちが参加した。その多くはIT業界である。好川さんは最初にキーノート・スピーチとして問題提起をされた。多くのプロマネは仕事が苦しくなってきているが、それをどう打開するべきか。苦しくなってきている、という箇所は、統計的な証拠を示したり会場の意見を聞いたりして、ほぼ全員の賛同するところとなった。その先の論理展開については、好川さんの話した言葉どおりではなく、むしろわたし自身の解釈(誤解?)も交えた形になるが、こんなストーリーだったと思う。

従来、日本企業では、組織のサポートが不十分なままプロジェクトをプロマネにまかせ、足りないところは「リーダーシップ」を発揮しろ、とやってきていた。ところが過去10年間かけて、PMBOK GuideやPMPの資格が次第に浸透・普及してきた。これととともに、組織のサポートはしっかりして来つつある。多くのIT系企業では、PMO(Project Management Office)組織も設立され、プロマネを支援・指導するようになった。

だが、その結果、プロマネの仕事はしだいに『中間管理職』化してきている。わたし自身、PMOの仕事を何年もやったから知っているが、あれはプロマネから見ると一種の小姑のような組織なのである。うるさいことこの上ない。しかも、顧客から指定されるScope, Cost, Scheduleの制約条件=『鉄の三角形』は、ますます厳しくなるばかりだ。

この状態を脱却するために、プロジェクト・マネージャーはビジネスを創造する方向に、もう一度リーダーシップを発揮すべきだ、というのが好川さんのストーリーなのだろう。ここでいう「リーダーシップ」は、10年前に会社がプロジェクト・リーダーという名前の担当者に押しつけたそれとは、内容を異にしている。いわば、「リーダーシップ2.0」である、という主張なのだ、とわたしは理解した。好川さんは、“マネジメント過剰・リーダーシップ不足”という表現もしていた。ジョン・コッターの定義を借りて、

 マネジメント:現在のシステムを機能させ続けるために、複雑さに対処すること
 リーダーシップ:現在のシステムをよりよくするために、変革を推し進めること

というのが氏の用語の使い方なのである。

(わたしがこのサイトで使っている用語の定義とは違うが、ここでその議論はしない。語の意味は、辞書的定義よりも、各人の文脈の中で理解すべきである。ちなみに『リーダーシップ』という語は、とくにアメリカでは後光を伴ったMiracle Wordであって、定義は千差万別なのに、皆がその内容を知っているつもりになっている不思議な概念だ。他方『マネージャー』の語は、アメリカではプランテーションの奴隷管理人を連想させる、鉄と鎖の匂いがあることを記憶されたい。)

近年のプロジェクト・マネジメントのあり方が、プロマネの手を縛って自由度を削減し、その覇気を萎縮させる方向に行っている、との告発は、ある程度わたしも賛成である。もちろん、プロマネ達がみな「一国一城の主」になって、“上納金(利益)は払ってるんだから、会社は俺のやることに口をはさむな”とうそぶく状態が望ましいとは思わない。逆に、困難に直面したプロマネを放置したり(あるいは叱責したり)する愚からも遠ざかった、といえよう。さらにリスク・レビューも真剣に行うようになってきた。その結果、企業でのプロジェクトの採算は向上した。だが、実は、“技術的に難しい(チャレンジングな)仕事は見送る”という、受注選別の結果だという声もある。プロジェクト・マネジメント・システムの強化は、良い面ばかりではないのだ。

そこをブレイクスルーするのが、主体的なビジネスの創造だ、という主張はまあ、わかるけれど、わたしにはむしろ、目指すべき方向はプログラム・マネジメントではないかとも思える。でも、その前にもう一つ、思い出したエピソードを紹介しよう。

昨年のPMI日本支部による、あるシンポジウム形式の席上だったと思う。わたしもパネラーとして壇上にならび、質疑の輪に加わった。最後に、司会者の方が、しめくくりの質問として、パネラー全員にこんな問いを発したのだ:「皆さんの会社におられるプロの火消し人が、愛読する書を教えてください」。

パネラーの中には、日本最大のICT企業で、傑出した火消し人として有名なHさんという方がおられたので、こんな質問が出たのだろうか。だが正直、わたしはこの質問に絶句した。自分自身が火消し人でないことはもちろんだが、わたしの勤務先には『火消し人』と呼ばれる者はいないのである。プロジェクトがトラブって、火を吹くことは無論ある。そのとき、PMOのメンバーは火消しに行ったりはしない。PMOは現業に手を出さないのが鉄則である。手を出したら、当事者が「仕事のオーナーシップ」=当事者意識を失うからだ。他の部署から腕利きのプロマネをリリーフ投入して助けたりもしない。

ではどうするか。それは、プロマネの上司が問題解決に踏み込むのである。上司はそのためにいる。わたしの業界では、トラブルは建設段階になって吹き出すことが多い。したがって、プロジェクト部門の部長やら役員やらが、海外の建設現場に1年も2年も駐在して、陣頭指揮をふるうことになっている。プロマネが途中交代になることも希にはあるが、原則は上司がカバーする。(その間、同じ部門の他のプロジェクトは、別の管理職が管掌することになる)

問題解決は、マネジメントの職能の一つである。必須の、重要な職能だ。これができなければ、プロマネ達のマネジメントはできない。つまり上司である意味がない。成功したら、全部お前の手柄だ。でも万が一失敗した時には、骨は拾ってやる−−これがプロマネへの、主要なメッセージではないか。むしろわたしが不思議なのは、「火消し人」が存在する組織である。誰か、消火隊が機内に待機しているジャンボ飛行機に乗りたいだろうか。消防署員が常駐している化学工場の隣に、誰が住みたいだろうか。発注者の立場で考えた場合、プロの火消し人がいるようなSIerには、仕事は出したくないとわたしなら思う。

冒頭の、プロマネが中間管理職化して不自由になってきている問題も、火消し人のいる組織の問題も、根っこは同じだ。それは、「プロマネの問題は、プロマネ・レベルで解決すべきだ」という考え方から生まれている。プロマネの悩みは、プロジェクト・マネジメントよりも上位のレベル、すなわち通常の用語では「プログラム・マネジメント」レベルでこそ対応すべきではないか。それは、(PMOなどではなく)職制上のラインが引き受けるべき仕事である。プロマネよりも一段階上のマネジメント・レベルの重要性に、もう少し皆が気づけばいいのに、と感じる今日この頃である。

→「革新的生産スケジューリング入門」にもどる

プロジェクト・スポンサーシップが足りない (2015/07/09)

アメリカにNeal Whittenという著名なプロジェクト・マネジメントのコンサルタントがいる。何年か前に、ボストンで講演を聴いたことがあった。彼はその中で、プロジェクトが失敗する三つの主な原因を挙げていたのだが、それがずっと頭にひっかかって残っている。彼のいうプロジェクトの三つの失敗理由とは、以下のようなものだ:

(1) プロマネのハード・スキル不足
(2) プロマネのソフト・スキル不足
(3) プロジェクト・スポンサーシップの不足

プロジェクトの失敗の理由がプロマネに帰されるのは、ある意味、当然のことだ。Whittenはプロマネの能力を、ハード・スキルとソフト・スキルとに分解する。ハード・スキルとは、知識や技法など、いわゆる座学で習得できる種類のものである。WBSだとか、PERT/CPMだとか、パラメトリック見積法だとかいった事柄で、これらは技術として移転可能なものである。わたしの言い方では「マネジメント・テクノロジー」であり、これを使いこなせる能力を、ハード・スキルと呼ぶ。

二番目のソフト・スキルとはむしろ、座学では学びにくい、より属人的な習熟を要する能力だ。交渉力だとか、指導力だとか、問題解決力だとか、後進育成とかコミュニケーションの能力など。わたし達の社会ではよく「人間力」などと称される。いわゆるリーダーシップとも、重なる点が多いだろう。

ところで、三番目の「プロジェクト・スポンサーシップの不足」という指摘には、意表をつかれた。プロジェクトの失敗の、いわば1/3は、プロマネ以外のところが原因で起きる。彼は経験をもとに、そう主張する訳だ。では、プロジェクトのスポンサーシップとは何か。

米国のPM関係の大会では、物事を理解するデフォルトの枠組みはPMBOK Guideと、PMP資格である。わたしもPMPは持っている。だが、PMOのメンバーとして社内のいろいろなプロジェクトを見ていくうちに、それだけでは次第に物足りない点を感じるようになっていた。
PMBOK Guideはたしかに、「プロジェクト」という枠組みの中で、それをいかに効率的に遂行するかを教える。しかし、そもそもプロジェクトの枠組みを与えるのは誰か。またプロジェクト・マネージャーを任命するのは誰なのか。プロジェクトがうまくいかなくなり、たとえ完遂しても価値を生み出さないことが明白になったとき、プロジェクトを止める権限があるのは誰か?

それは、プロジェクト・スポンサーである。

プロジェクト・スポンサー(業界によっては「プロジェクト・オーナー」ともいう)は、上級マネジメント層を代表して、プロジェクトをウォッチする。だから、重要なプロジェクトの場合は、役員かそれに準ずるレベルの人がなる。中小規模の場合は、プロマネの所属する部門長がやるだろう。
(もしプロジェクトが上位プログラムの一部である場合は、通常はプログラム・マネージャーがその役割を果たすか、あるいは自分のプログラム・オフィスのスタッフにその権限を委譲するはずである)

わたしは勤務先でPMOの仕事を何年間もやってきた。それなりの数のプロジェクト・レビュー会議に参加し、またプロマネ達のマンスリー・レポートをウォッチもした。念のためにいうと、社内にいるベテランのプロマネ達は、わたしなんかよりずっとマネジメント能力があり、技法などについても熟知している。なのに、なぜPMOによるウォッチや助言が必要なのか?

それはスポンサーのためなのだ。多忙なプロジェクト・スポンサーに、配下のあのプロジェクトはきな臭い煙が出ています、近いうちに火の手が上がるかも知れませんよ、と告げる。それがPMOの重要な仕事なのである。ちょっとPMとじっくり話してみてください、と。

なぜ、プロマネが直接、スポンサーに自分のピンチを告げないのかというと、通常は、問題を押さえ込めると自分で思っているからだ。わざわざ報告の要はない、と。プロマネという人種は楽天的で、自信家だ。そうでないと、プロマネはつとまらない。まあ、たまにはプロマネが自分のプロジェクトで問題が起きているのに気づかない場合もある。PMOは全部のプロジェクトを横並びで数値的に比較しながら見ているから、そのような異常に敏感になっている。むろん、異常がつねに病気とは限らないのだが、アラームはならすことになる。プロマネから見れば、自分が十分マネージしているつもりなのに、横で小うるさいことをスポンサーに進言する心配性のPMOなんか、うるさい限りだ。スコアラーは黙って試合を見てろ−−そういう気持ちにもなるだろう。ある意味、PMOはせつない役回りである。

むろん、本来はPMOがいようがいまいが、プロマネと、それを管掌するスポンサーとの間には、定期的なコミュニケーションがなければいけない。
スポンサーはプロマネを任命し、支援する。
プロマネはスポンサーに報告し、相談する。
−−これが両者の間の役割だ。

そしてプロマネの悩みとはたいてい、予算が足りないか、人が足りません、なのだ。(時間が足りません、ということもあるが、通常はお金か人をかければ期間は短縮できる)。そこでスポンサーは、トップ層を動かして、予算をつけたり、他部門から必要な人を持ってくるような働きが必要とされる。つまりスポンサーもまた、「実力」がないといけないのだ。

逆に言うと、プロジェクトにおいて、プロマネだけの能力と努力でできることには、一定の限度があるということだ。わたしの実感でも、プロジェクトの成否のうち、プロマネの権限内で達成できる部分はせいぜい2/3程度である。場合によっては、もっと少ない。それ以外の部分は、プロマネが任命される以前に決まっていた枠組み(契約条件等)とか、プロマネがコントロールできない社内の配員や、外部環境の変動(たとえば為替リスクだとかベンダーの倒産だとか)などで、成功か失敗かが決まってしまう。

つまり、与えられたプロジェクトという枠組み、所与の制約条件(予算・納期・スコープ)の中だけで、プロジェクトの成功率を上げることはできないのだ。したがって、プロジェクトの成功率をもっと向上したかったら、会社が本気でプロジェクトを支援する仕組みづくりが必要となる。

受注型プロジェクトの場合は、受注側のプロマネの上に、プロジェクト・スポンサーがおり、発注側にも本来はプロマネとスポンサーがいる。したがって、両者のスポンサーが定期的に(たとえば年4回とか隔月とか)で会合を持ち、プロマネのレベルでは解決できなかった問題(イシュー)を話し合い、なんとか解決に持ち込むことが望まれる。少なくとも、わたしが知る限り、エネルギー系の海外プロジェクトでは、そういう仕組みが常識化している。

では、プロジェクト・スポンサーという役割の人が、具体手にするべき仕事の内容は何か?

わたしの知る限り、ISOをはじめとして、米国PMIや英国OGC、日本のP2Mなどでも、スポンサーについて定めた標準書はほとんど存在しない。唯一知っているのは、GAPPS Initiativeの定めたStandardである。昨年、GAPPSのワークショップが日本で開催されたとき、わたしも手伝ったのだが、そのときはまだスケルトンだった。今年はドラフト段階まで来ている。
http://globalpmstandards.org/tools/gapps-pm-standards/project-sponsors/
これによると、スポンサーの役割は大きく三つある:

(1) プロジェクトのAccountabilityを引き受ける
(2) プロマネを支援する
(3) プロジェクトを支援する

最初の「(1) プロジェクトのAccountabilityを引き受ける」、とは、プロジェクトの意義を明確にし、有効なガバナンスを確立し、プロジェクトの生み出すアウトカムと便益が現実に役立つよう計画する、などを含む。Accountabilityとは『説明責任』などと訳されることも多いが、ふつうは説明行為だけではなく最終的な責任を引き受けることを指す(わたしは『面目責任』と訳した方がいいと思っている)。

つぎの「(2) プロマネを支援する」は、プロマネに時間を割いてやり、プロマネレベルでは解決しにくい紛争や問題について助けてやり、またプロマネ自身のパフォーマンスについて率直に評価・助言してやる、が含まれる。そして「(3) プロジェクトを支援する」とは、リソース(配員や資金など)面で助けてやり、ステークホルダーにプロジェクト状況を見えるようにし、適切なプロジェクト・レビューと意思決定がなされるよう組織を動かす事を指している。

もっとも、こうしたスポンサー制度の説明をすると、そんな風に上からプロマネを支援するなどしたら、プロマネの「甘え」を助長するからよくない、といった論議をする人が出てくる。何を甘えたことを言っているのか、寝言を言うな、と。

たしかに自分の判断を放棄して、すべてをスポンサーに相談し依存してくるプロマネがいたら、「甘えるのもたいがいにしろ」と叱るべきだろう。ある程度は厳しくしてこそ、育つ責任感というものもある。だが、そもそも組織がプロジェクトを遂行する目的は、何だろうか。一切の助言や支援を「甘え」の名前でシャットアウトして、本当に企業としてそれでいいのか。顧客やステークホルダーに迷惑をかけ、赤字を増大し、自社の信用を毀損するようなプロジェクトを放置してまで、プロマネの「甘え」を拒絶することで得られるものは何があるのか? 物事にはどこかに、適切な限界があるべきだろう。イエスかノーか、0か100かで決められるほど、マネジメントとは単純な仕事ではないはずだ。

ご存知の通り、日本におけるプロジェクト・マネジメントの普及とブームは、2000年以後におきた。その中心はIT産業、とくにSI(システム・インテグレーション)と呼ばれる受託ソフトウェア開発の分野である。SIerと呼ばれる業種において赤字プロジェクトの頻発が問題となり、業界全体の悩みとなったし、その結果生まれた労働環境の劣化は、優秀な人材をリクルーティングする障害になった。

PM論がはやる以前のキーワードは、『リーダーシップ』だった。「お前はプロジェクト・リーダーなんだから、リーダーシップを発揮しろ! それでなんとか困難を切り抜けろ!」と号令することで、赤字や納期問題を解決しようとしていた。意地わるくいえば、上司は問題を、部下であるリーダーに、リーダーシップなる魔法の言葉で、『丸投げ』していた訳である。

さいわい、プロジェクト・マネジメントという概念と知識体系が普及することによって、そうか、プロマネには、身につけるべきスキル・セットがあるのだな、という認識が進んだ。多くのSIerが社内でPMP資格取得を奨励したのも、こうした理由が大きい。こうした活動の結果、10年間で、PM論に対する認識はかなり普及したといっていい。また、社内レビューなどの制度的な前進もあって、赤字プロジェクトはある程度、減少したという調査結果もある。しかし、では業界の悩みは解消したかというと、わたしの聞く限りは、そうではない。
そして、なまじPM論の知識が広まったが故に、「プロジェクトの失敗は、プロマネのマネジメント能力不足である」という認識も、妙に広まってしまったように思える。つまり、問題解決を部下であるプロマネに丸投げする上司の体勢自体は、あまりかわっていないのだ。単にキーワードが、曖昧なる『リーダーシップ』から、舶来風の『プロジェクト・マネジメント』に昇格(?)しただけである。人によっては、PMの最大のポイントはプロマネのリーダーシップである、と論じて、わざわざ論点をプロマネ個人の資質に引き戻したりしている。

ここで最初のN. Whittenの「プロジェクトの三つの失敗理由」を思い出してほしい。プロマネ個人のリーダーシップは、もちろん非常に大切だ。だが、それはプロマネの「ソフト・スキル」である。また、PMBOK Guide的な知識と技法の習得も、必要である。それはプロマネの「ハード・スキル」部分だ。だが、それらと並んでもう一つ、プロジェクトへの「スポンサーシップ」も、企業にとっては必須なのである。

スポンサーは、トラブルがひどくなったら自分で出て行って混乱を食い止め、プロマネが倒れそうになったら支え、顧客やステークホルダーを説得して終結まで持ち込むだけの、覚悟が求められる。逆にプロジェクトがうまくいったら、部下であるプロマネを賞賛する。つまりスポンサーという仕事は、良いときは部下を誉め、まずい時は自分が責任をひっかぶる、割にあわない商売である。そういう役割なのだ。そのおかげで、部下であるプロマネが育っていく訳だ。

そして、スポンサーのさらに上位にいる経営層は、スポンサーがきちんと自分の仕事をして、プロマネを育成しているかどうかを評価する。成功したらプロマネの功績を横取りし、失敗したらプロマネに責任をかぶせるような、本来とは逆のことをしていないか、監視する。これが、あってほしい企業の姿だろう。

もう一度いうけれども、プロジェクトは、プロジェクト・スコープという枠の中だけで評価してはいけない。プロジェクトを取り囲む、企業のより大きなコンテキスト(文脈)の中に位置づけて、考えるべきなのである。プロマネに文脈を与えて、上位の戦略や外部環境とアライメントをとるのが、スポンサーシップの役目であろう。

→「革新的生産スケジューリング入門」にもどる

プログラム・マネジメントは本当にプロジェクト・マネジメントの上位概念なのか(2012/07/01)

前回「プロマネの悩みは誰が解決すべきか」では、プロマネの悩みはプロジェクト・マネジメントよりも職制的に上位のレベル、“すなわち通常の用語では「プログラム・マネジメント」レベルでこそ対応すべき仕事である”と書いた。

ところで、今回はまったく逆のことを書こうと思う。すなわち、プログラム・マネジメントはプロジェクト・マネジメントの上位概念ではない、という話題だ。なぜこんな矛盾したことを書くのかというと、それは国際標準の概念規定に、じつは目に見えない混乱があるためだ。でも、まずは(いつものように)ちょっと別のエピソードから入って、斜めの角度でこの問題にアプローチしてみたい。

先週わたしのところに、プロジェクト部門から電話がかかってきて、「佐藤さん、出張精算書を今週中に必ず提出してください」と催促があった。先月中旬、そのプロジェクトの用件で中東に一泊三日の短期出張に出かけたのである。他にも仕事を抱える身だったので、日曜の夜行便で出発して、月曜の午後と火曜一日だけ向こうで打合せに参加し、また火曜夜の夜行便で戻る(時差があるから水曜夜に成田帰着)、というとんぼ返りのスケジュールだった。会議の主題は、これから実行段階に入る巨大プロジェクトのリスク・アセスメントで、二日間の会議の議長として客先から呼ばれたのである。

ところで、このプロジェクトは『実費償還契約』(Reimbursable Contract)であった。そのため、すべての出費明細をタイムリーに客先に提出して、その費用を精算してもらわなければ、お金を取りはぐれてしまう。だから、例によって事務仕事を後回しにして、ぐずぐずしているわたしのところに、督促の電話が入った訳である。

この巨大プロジェクト、わたしはプロジェクト・コントロール・マネージャーの役割で、すでに2年以上働いている。これまでにフィージビリティ・スタディ(事業化検討)と基本設計作業をやってきたのだが、震災の影響や種々の事情で2年以上もかかってしまった。これからようやくプラントの設計・調達・建設(EPC)という実行段階に入るが、プロジェクトがあまりに巨大なため(投資は1兆円近い)、全体を1ダースものスコープに分割し、別々のパッケージとして入札を行った(ちなみにわたしは、顧客の側、つまり受注者ではなく発注者のサポートとして働いてきた)。だから、この先のリスク分析をすると、どうしても各パッケージ間のインタフェース調整にリスクを見ざるを得ない。

ところで、これまでの基本設計段階は、ずっと実費償還契約だった。一方、この先、実行段階での各パッケージの受託企業は全て一括請負契約(Lump Sum Contract)である。なぜ、段階ごとに契約形態をかえるのか?

答えは単純である。基本設計段階では、どのようなプラントの構成にして、何をどれだけ生産するか、まだ目安程度しか決まっていない。だから設計にはいろいろな、オープン・エンドな可能性がある。したがって、設計が完了するまでにどれだけの工数がいるのか、精度をもって見積もることができない。もし、これを一定金額の請負契約にしてしまうと、肝心の設計を詰める段階で、工数上限を理由に手を抜かれないとも限らない。だから、「使用した工数と経費の分だけ、一定のマージンをのせてペイバックする」実費償還契約が現実的なのである。ところで、いったん基本設計が完成すれば、もう実行段階のスコープは確定し、かなりの精度で費用を見積もることができるようになる。だから、実行段階は一括請負契約が合理的になる。

さて、ここで一つ問題を提出しよう。「プログラムとは複数のプロジェクトを束ねたもの」という概念が正しいとするならば、このプロジェクトは実行段階に入って、プログラムへと質的に変化した、ということになる。これは本当だろうか?

プログラムとかプロジェクトといった用語・概念は、'60年代米国のアポロ計画のあたりから使われるようになった。アポロ計画自体は、プログラムである(=The Apollo Program)。プログラムの下に、アポロ1号、アポロ2号、などロケット打ち上げに関する個別ミッションがある。これが「プロジェクトProject」と呼ばれた。プロジェクトはさらに、設計・製作・飛行などの「フェーズPhase」(あるいはActivity)に分解される。このように、巨大な事業全体を、構造的に分解して、管理していくのは、米国的思考法の得意とするところだ。

アポロ計画がスタートしたとき、最終目標は「10年以内に月面に人間を送る」だったが、それ以上の明確なスコープも詳細な予算も、まだ存在しなかった。つまり、オープン・エンドな事業だったのである。それを逐次的に具体化・詳細化していくために、複数のロケット打ち上げプロジェクトを積み重ねていく方法がとられた。つまり、アポロ・プログラムは複数プロジェクトを時系列的にたばねたものである。先行プロジェクトと後続プロジェクトの間には、直前に達成された成果にもとづくフィードバックがあった。全プロジェクトのスコープが最初からきっちりと確定していた訳ではなかった。

「プログラムとは複数のプロジェクトを束ねたものである」と定義するとき、それが同時的バンドルを意味するのか、時系列的バンドルを意味するかについては、実は相当な質的開きがあることに注意してほしい。プログラムが事業として、外部環境の変化、あるいは内部での能力・知識の成長とともに、適応的に発展していくためには、どこかにフレキシビリティーがなければならないはずである。時系列的なプロジェクトの集合で、かつプロジェクト間にフィードバックが存在するなら、たしかにそこに変化への柔軟性や進化が見られるだろう。

他方、巨大な事業を同時に複数のプロジェクトに分解する場合、そして各プロジェクトのスコープが皆確定している場合、どこにフレキシビリティーが保証されるのか? プロジェクト間の相互調整的なインタフェースだけでは、はなはだ限定的であることが分かるだろう。

ちなみに、日米欧の三国は、プログラムをどう定義しているか。米国Project Management Institute(PMI)、英国Office of Government Commerce (OGC)、そして日本プロジェクトマネジメント協会(PMAJ)の標準書から、それぞれ引用してみよう:

米国PMI: The Standard for Program Management (2008)
A Program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually.

英国OGC: Managing Successful Programmes (2007)
A temporary flexible organization created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits to the organization's strategic objectives

日本PM協会: 新版P2M標準ガイドブック (2007)
使命(ミッション)を実現するために、複数のプロジェクトが有機的に結合された事業。  「大規模システム型プログラム」と「戦略型プログラム」(創出・変革型)とに分類される(定常業務はサービスプロジェクトとして位置づけられている)。

文言はある程度似通っているが、標準書全体の文脈を含めて読み取ると、米国ではプログラム=「巨大なプロジェクト」というとらえ方が強いが、日欧では「事業を創出する諸活動」との文脈でとらえる傾向があるように、わたしには思える。その違いは、すなわちオープンエンドな、変化への適応能力(Adaptive Solution)の差違である。複数のプロジェクトを同時的にバンドルしても、それが主体的な適応能力や、スコープ・バウンダリーの拡がりを支援するものでない限り、それは「プログラム」の名前には値しないと考えられる。

逆に言うならば、別段、複数プロジェクトの形に分割されていなくても、そこに適応能力とフレキシビリティーを支える仕組みがあれば、それはプログラム・マネジメントだと呼んで良いだろうと、わたしは思う。いいかえれば、生みだす成果物の価値に応じて、スコープや、納期や、必要予算の枠さえ拡大できるような主体性の強さである。ただし、そうなると、WBSとかPERT/CPMとかEVMSとか、明確なスコープ・バウンダリーを前提するプロジェクト・マネジメント技法はそのままでは適用しづらいだろう。だから、ある程度、“固いスコープ”の部分と、“柔らかでオープンエンド”な部分を有機的に組み合わせていかざるを得ないだろう。

いずれにせよ、プログラムであるかどうかは、実行する側の主体性の強さによって定義すべきだとわたしは思うのである。

→「革新的生産スケジューリング入門」にもどる

プロジェクト・ポートフォリオ・マネジメントと、顧客を選ぶということ (2015-09-21)

プロジェクト・ポートフォリオ・マネジメントという言葉をはじめて知ったのは2003年頃のことで、ITRという調査会社のレポートからだった。当時わたしは米国のPM関連製品について調べていたのだが、米国ではじつに100種類以上のPMソフトウェア・パッケージが発売されていた。その中でメジャーな商品は、ローエンドがMirosoft Project、ハイエンドがPrimavera Project Plannerというプロ向きの製品だった。Primaveraは大規模プロジェクトの計画とスケジュール・コントロールに特化した製品で、日本ではごく一部の業界でしか使われていないため知名度が低いが、欧米ではエネルギー産業や航空宇宙産業に広く使われてきた。MS ProjectもPrimaveraも現在ではサーバ型製品が主流だが、10年以上前はPC上でのスタンドアローン・ユースが普通だった。ちなみに当時すでにASP型(今でいうクラウド型)商品もでていたが、メジャーな製品はなかった。

ほかに、ERPのプロジェクト管理モジュールというものも存在した。SAP R/3のPSだとか、Oracle EBSのPAなどだ。これらは金額的には超弩級だが、プロジェクト・マネジメントの日々の実務を助けるツールというより、プロジェクト会計や原価管理のための道具であった。

しかし調査会社のレポートによると、これ以外に第3のカテゴリーが勃興しつつあるという。それがプロジェクト・ポートフォリオ・マネジメント(略称PPfM)であった。これはプロジェクトを投資ととらえ、企業が持つ複数のプロジェクトの組み合わせを、ちょうど金融資産のポートフォリオと同じように最適化し管理するための道具立て、との位置づけだった。

プロジェクトの上位計画をプログラムと呼ぶことは、当時も知っていた。アポロ計画は英語ではApollo Programという。そして個別の飛行ミッション、たとえばアポロ11号をプロジェクトと呼ぶのだ。プロジェクトの下には「フェーズ」がある。Program > Project > Phaseの序列は、頭文字をとってPPPと呼ばれていた。しかし、実は第4のP、すなわちポートフォリオ(Portfolio)があって、それはプログラムよりも上位の概念なのだった。

そして米国の市場は、明らかにこのプロジェクト・ポートフォリオ・マネジメントに向かっている、とレポートは結論していた。この予測は、米国に関していうと、きわめて適切であった。MS ProjectもPrimaveraも、その後の新バージョンではポートフォリオ・マネジメントを意識した形で、プロダクトを再デザインしていった。サーバ型製品が主流になったのも、ある意味でその影響である。PPfMにねらいを特化した製品も出るようになった。

そして日本市場は米国のトレンドを数年遅れて追っている。したがって、今後の期待株はPPfM関連の製品にある、とレポートは言いたげであった。

しかし、わたしは、それが日本でも広がるという予測には疑問を持った。そもそも、わたし達の社会では、プロジェクト・マネジメントは受注者がやる仕事だと考える風潮が強い。まるで投資者(発注者)は、発注書さえ切ってしまえば、あとは口々に好きな放題な要望を言えばよく、それをとりまとめるて調整するのは受注者の仕事だと思っているかのようだ。発注者こそ、きちんとプロジェクトを舵取りしなければならない、という社会的常識はきわめて薄い。

そして受注者にとって、プロジェクトは投資ではない。競争環境下にいる受注ビジネス企業は、どのプロジェクトをやるかは自分で決められないのだ。だからポートフォリオ・マネジメントなどやりようがない。日本では普及しないし、ソフトも売れないだろう。これが、わたしの予測だった。

10年以上が経った現在でも、わたし達の社会でポートフォリオ・マネジメント・ブームが来そうな兆しはない。企業にプロジェクト・ポートフォリオ・マネージャーという役職が設置されたという話も、いっこうに聞かない。

・・だが、つい最近、わたしは重大な見落としをしていた事に気がついた。それは、6月に開催した「プロジェクト&プログラム・アナリシス研究部会」でのことだった。

6月の研究部会では、元NECの田島彰二氏を講師に迎えた。田島さんは世界におけるプロジェクト標準化活動では、日本を代表する論客として長年、活躍してこられた方だ。国内より海外でずっと知名度が高い。PMIの各種スタンダードの巻末にある貢献者リストで、最も頻繁に名前を見かける日本人だろう。最近では、国際標準化機構ISOの、プログラムとポートフォリオ・マネジメントの標準策定に尽力しておられる。

その田島さんが、欧州で参加されたポートフォリオに関するワークショップで出題されたグループワークの問題を紹介された。著作権の関係もあるので正確な引用はできないが、おおよそこんな問題だった:

あなたは脱サラをして、風光明媚なエリアに地産地消のピザ屋を開くことにした。店を構え、レシピを工夫し、地元の仕入れもなんとか道筋をつけて、順調に運営しはじめたところだ。ところである日のこと、あなたのところに電話がある。これから観光バス1台に乗り込んだ団体ツアー客50名が、店の評判をきいて昼食に行きたいというのだ。今は11時過ぎだが、12時には来るという。それだけの数の客が来たら、小さなあなたの店は完全に満杯になる。それに、あなたの店はいつも11時半に開店して、いつもそれなりの常客が来てくれているのだ。さて、あなたはどうするべきか?

田島さんは研究部会の参加者を二人一組にわけて、それぞれに8分間で意見をまとめるよう依頼した。各チームの話し合いを見ていると、出題にどう取り組むか、参加者の頭がフル回転している様子がありありと感じられた。まず、50人分ものピザの材料はあるのか? 仕入れは今から追加手配して間に合うのか? 椅子やテーブルの数は足りているか? 店の外にもテーブルを並べるべきか。フロアのサービス係の人数は。かまどは一度にそれだけの数量を焼けるのか。そして、いつもの常客にはどう応対するのか。本日貸し切りにする? だが何とかやっと安定運営にこぎつけた店で、常客を断ったらまずくはないか。いや、そもそもこんな飲食店の話、どこがプロジェクト・マネジメントなんだ!?

だが、これは非常に面白い出題だと、わたしは思った。この話は、突発的な需要増が見込まれるケースで、どう戦略的な意思決定を下すかを問うている。その際にポイントとなるのは、経営資源が限られている、ということだ。店の従業員数も、スペースも、かまども椅子もテーブルも、そしてピザ製造の材料も、すべて『経営資源』の一種である、という風に抽象化して問題を捉えることができるかに、かかっている。

経営資源が限られている際に、どこに重点的に投入していくかという問題こそ、ポートフォリオ・マネジメントの要点である。そして、需要に対して経営資源が限られている場合、考えられる主な対応は、二つしかない。
(1)ボトルネックの資源を手配する(資源制約を緩める)
(2)顧客を選別する、
の二つである。だからこの地産地消ピザ屋の問題は、この(1)(2)の視点に気がつけるかどうか、回答者の戦略思考能力(抽象化能力といってもいい)を試しているわけだ。

ところで、わたしの見た限り、参加者のほとんどは(1)の対応策にのみ集中して議論していた。材料をどうするか、テーブルや椅子やスペースをどう広げるか、という議論で、つまりボトルネックはそうした点にあるだろう、という仮定に立っている。

しかし、(2)を明確に意識して、「観光客か常客のいずれかを選んで、他はお断りしよう」との意見は、あまり出てこないようだった。仕事(需要)が来たら、それをどうこなすかを必死に考える。しかし、顧客を選ぼう、という発想は意識に上らない。なんて技術屋的だろうと、わたしは感じた。

常客に加えて50人もの観光客が来たら、店は明らかにパンクする。無理に受け入れたら、確実にピザの味やサービスのクォリティは下がるだろう。それでも受け入れようと決めるのは、たしかにひとつ戦略的決断である。だが店の将来を考えたら、下手に今、評判の落ちるような仕事はできないのだから、顧客を選ぼう、というのもやはり戦略である。どちらがベターかは議論の余地もあろうし、たぶん正解はない。ただ、この両面の視点を持つことは、経営者として必須だ。

顧客は選べないし、選んではいけない、という思い込みは、わたし達の間に強固に存在している。顧客の中には上客も、こまった客も存在する。しかし注文しに来てくれた客である以上は、応対しなければいけない。応対すべきである。もし今かりに手一杯でも、一度断った客はたぶん二度と来ない。だから何とか応対を考えるべきだ、と。値切ってくる客とも、仕事を失わないよう、どこかで折り合いをつけるべきだ、と。

しかし、世の中にはまったく別の視点も存在するのだ。それは、経営とは顧客(のセグメント)を選ぶことである、という視点である。「経営者の仕事とは、店の前に客の行列をつくることだ」という意見も読んだことがある。客がつねに行列をなしていれば、自分のペースで、クオリティを落とさずに仕事ができるし、値切りにも応ぜず、いやな客はお断りできる。そのためには、どのような形で他社との競合から避けるか、どのような見えない参入障壁を築くか、どのような独自技術や商品を作り、どうマーケティングしプライシングていくかこそ、戦略である??そんな見方だって、存在するのだ。

ポートフォリオとは元々、書類を束ねる紙挟みを意味する言葉だ。そこから派生して、債権や株などいろいろな金融資産の束、組み合わせを意味するようになった。さらにそこから広がって、経営資源を投入する行為自体も、一種の投資と考え、それをうまく組み合わせようとするのが、現代のポートフォリオ・マネジメントである。

経営資源はつねに、有限である。そこで、どこにどう投入するかを、選ばなくてはいけない。何かを選んだら、他は捨てることになる。捨てたり、やめたり、断ったりすることが、ポートフォリオ・マネジメントから必然的に導かれる行為である。その対象の中には、市場のセグメントや、需要や、見込案件が含まれる。

あいにく長らく不況の続いた現在、案件選別という考え方は、受注ビジネスの分野ではきわめて薄弱だ。とにかく有望そうな案件にはトライしてみる。三つでも四つでも追いかけてみる。どれがとれるかは、わからない。二つ以上とれたら、どうするかって? そんなこと、とれる前に心配しても仕方がない。取れてから考えればいい・・「とれるだけ仕事をとってはいけない」とわたしが信じるようになったのは、つい近年のことである。

わたし達はやはりもう少し、ポートフォリオの視点を持つべきではないかと思う。日本プロジェクト・マネジメント協会が、日本独自の標準である「P2M=プログラム&プロジェクト・マネジメント」の改訂3版を昨年度出したが(わたしも標準ガイドブックの貢献者の一員である)、田島氏は、「経営戦略とプログラムの間に、ポートフォリオ・マネジメントを入れるべきだった」と批判している。たしかに、上記のような状況を考えると、正当な批判というべきだろう。顧客(セグメント)を選ぶこと、そのために圧倒的な競合力のある市場を作ること、それをめざして経営資源を投入すること、そして仮想的な顧客の行列を生み出すこと。そうしたポートフォリオの視点こそ、今のわたし達が必要とするものかもしれない。

<関連エントリ>
 →「とれるだけ仕事をとってはいけない」(2015-03-03)

→「革新的生産スケジューリング入門」にもどる

PRINCE2の教え−−プロジェクトで大事なのはマネジメントかガバナンスか? (2014-07-21)

このサイトをご覧の読者の方なら、『鉄の三角形』という言葉をご存知と思う。プロジェクトを定める「スコープ」[コスト][スケジュール」という三大制約条件を、三角形の形で模式的に示したものだ。

三角形の一片の長さは、他の辺に影響を与えずに変えることができない。同じように、プロジェクトの三つの制約条件は、独立でなく必ず他と関わり合っている。例えばプロジェクトのやるべき責任範囲である「スコープ」が増えたとしよう。すると「コスト」が増えるか、「スケジュール」が伸びるか、あるいはその両方が必ず起きる。そこでプロジェクトマネージャーは、これら3つのファクターの相互関係とバランスを、よく考えながらコントロールする必要がある。

ちなみに、製造業の三大ファクターと言えば「QCD」、すなわち、品質(Quality)・コスト(Cost)・納期(Delivery)である。プロジェクトの場合は、品質で三角形を書くこともあるが、ふつうはスコープを用いる点が大きな違いだ。では品質はどこに行ったのかというと、品質を確保し保証し検証するための活動(activity)として、スコープが含んでいると解釈される。品質要求のレベルに応じて、プロジェクトのスコープが増えたり軽くなったりする訳である。

ところで、現代プロジェクト・マネジメント理論(モダンPM論)の中心的な技法は、
・WBS (Work Breakdown Structure)
・EVMS (Earned Value Management System)
・CPM (Critical Path Method, PERT/CPMとも表記)
である。これらを知らずに、プロジェクト・マネジメントは語れまい。PMBOK Guide(R)などでも丁寧に記述している。

とくに計数管理が必要なプロジェクトでは、上記は必須の技法である。計数管理は、ほんの数人・数ヶ月程度のプロジェクトを一度やるだけなら、たいして要りはしない(リーダーシップやチームワークや「気合い」で乗り切れる)。だが、大規模な場合や、小規模でも複数プロジェクトを常時動かしている場合は、数字でのコントロールがやはり大事になってくる。

ところで、上記の三つのマネジメント技法は、それぞれがちょうど『鉄の三角形』の三辺に対応している。スコープをマネージしたければWBSを、コストをマネージするにはEVMSを、そしてスケジュールにはPERT/CPMという具合だ(図参照)。この対応関係は、偶然の産物ではあるまい。プロジェクトを運営して行くにあたって、最大の制約条件を何とかコントロール下におさえるべく、上記三つの技法がそれぞれ発達してきた、という事情なのである。

ちなみに、プロジェクトの難しさや失敗率について語るとき、米国Standish Groupの統計が引用される。これは3年に一度行われる大規模調査の統計である。そこでの成功・失敗の定義は次のようになっている(2003年度版による)。

(1) Successful: completed on time, on budget, with all specified features.
(2) Challenged: completed and operational, but over-budget, over time and with fewer features than specified.
(3) Failed: the project is cancelled before completion or never implemented.

すなわち、品質・コスト・納期を計画通り満足して終わった「成功プロジェクト」と、完了したが3 大制約条件を満たせなかった「困難なプロジェクト」、そして中断終了した「失敗プロジェクト」のクラスがある。かくて、WBS, EVMS, CPMのマネジメント三技法は、プロジェクトの成功率を高めるために貢献する訳だ。

もちろん、WBSにせよEVMSにせよCPMにせよ、技法の中核的アイデアは単純だが、実際に適用となるとかなり奥が深い。わたしの所属するエンジニアリング業界では、コスト・エンジニア、スケジュール・エンジニアなどの専門職が形成されており、プロマネの参謀的なスタッフとして、マネジメントを補佐していく。プロジェクト・マネージャー自身も、この三つの技法について、ある程度は習熟し、議論でき、きちんと決断できるだけのハード・スキルが望まれる。『鉄の三角形』を御すのは、決してたやすい仕事ではない。

しかし。

プロジェクトには、もっと別の難しさもある−−そういう風に、わたしは最近つよく感じるようになった。それは、プロジェクトは予算内に完遂するが、成果物に価値が見いだせない、という形での失敗だ。仕様どおり作ったけれど使われなかったシステム、予算内に完成したけれど利用客のさっぱり来ない道路や空港、期日どおり出荷したが売れない新製品・・わたし達のまわりには、そうした失敗例が、実はあふれているのではないか。そして、このような失敗は、上記のStandish Groupの統計の、どれに分類されるのだろうか? 明らかに、どれでもあるまい。

だとすると、プロジェクトは、スコープ・コスト・スケジュールの『鉄の三角形』を守るだけでは、不十分なのだ。こうした失敗はそもそも、プロジェクトのゴール、プロジェクトが生みだすべき成果物に、十分な利用価値が見いだせない状態なのに、最後まで進めてしまったことに原因がある。である以上、プロジェクトを途中でいったん止めて、ゴールや成果物を根底から見直すべきであるし、それが無理ならば、プロマネを交替させるか、いっそプロジェクトを中断撤退すべきだったのだ。

では、その判断を下すべきなのは、誰か?

明らかに、プロジェクト・マネージャーではない。プロマネは、自分で始めたプロジェクトを、途中で降りる権限はない。プロマネ自身を罷免する権限もない(自分で辞任することはできるが、「罷免」とは本人が望まないのに強制的に辞めさせることである)。

である以上、その決断を下すべき者は、プロマネより上位に位置する権限者である事が分かる。それは、プロジェクト・オーナーかもしれないし、ステアリング・コミッティーかもしれないし、場合によってはプログラム・マネージャーかもしれない。ともあれ、プロマネを任命した権限者が、プロジェクトの価値や行く末について、要所要所でジャッジするべきなのである。

“ある程度の自立性(自律性)を持つ組織を、どう動かすべきか”の方策を、『ガバナンス』と呼ぶ。自律性を持つ組織に対し、何かの役割を委託した際に、委託した側の利益や期待に合致するように働いてもらう必要がある。そのためには、どうコントロールをきかせるべきかが、ガバナンスだ。株主が会社の運営を役員に委託する際に、株主利益から反しないようにはかることを企業ガバナンスと呼ぶのが、その典型である。

ガバナンスでとくに大事なことは、相手が勝手に変な方向に進んでいかないようにすることだ。何かをまかせる以上、資源をおかしなことにつかわれてはまずい。したがって、上に書いたように、プロジェクトの方向性を適時ウォッチし、成果物が期待した価値を生みだすように下す判断は、プロジェクト・ガバナンスの領域なのである。

旅客の来ない空港、使われない情報システムは、まさにプロジェクト・ガバナンスの不全を示している。プロジェクトの最大の失敗は、ガバナンスがきちんときかないことなのだ。

そこで、PRINCE2の登場である。先日、わたしが主査を務める「プロジェクト&プログラム・アナリシス研究部会」では、講師に落合和雄氏を招いて、英国のプロジェクト標準であるPRINCE2の勉強会を行った。その席上、落合氏が開口一番いわれたことが、

 「PRINCE2は、プロジェクト・マネジメントよりもプロジェクト・ガバナンスの方法論です」

という言葉であった。PRINCEの原型は、1989年、イギリス政府の情報システムのプロジェクト・マネジメントの標準として中央電子計算機局 (CCTA) が開発した。やがてこれは、IT向けに政府機関以外でも使われるようになる。そして、より汎用的なマネジメント手法として PRINCE2 が1996年に発表され、今や英国でのプロジェクトのデファクトスタンダードとなっている。

PRINCE2の中心にあるのは、段階的な漸進主義(Manage by stages)と、プロジェクトのもたらす便益(Benefit)へのフォーカス、そしてマネジメントの階層性である。PRINCE2では、プロジェクト・マネジメント・チームならびにその機能には、3つの階層がある。

(1) Project Board - Directing (プロジェクト理事会 − 方針指導)
(2) Project Manager - Managing (プロジェクト・マネージャー − マネジメント)
(3) Team Member - Delivering (チーム員 − 実務)

という階層になる(なお、PRINCE2にはまだ日本語版の正式翻訳がない。上記の括弧内は、わたしの勝手な意訳である)。

そして、指示は上から下へ、報告は下から上に伝えられる。とくに、コスト、スケジュール、スコープ、品質、リスク、ベネフィットにおいて、何らかの予期せざる大きな変動があった場合、必ずそれは上位組織に対して報告され、判断を仰がなければならない(Manage by exception=例外管理)。組織は、「許容できる変動の範囲(tolerances)」をあらかじめ定めておく。

こうして、プロジェクトが、上位組織の知らぬ間に変な風に進まないよう、たがをはめておくのである。まさにガバナンスである。ちなみに、Project Boardよりもさらに上位の階層は、企業(Corporate)ないしプログラム・マネジメントだと規定されている。PMBOK Guideは「プロマネがどうプロジェクトをマネージするか」を中心テーマに据えて、いわばプロジェクトという単位の中で考えている。これに対しPRINCE2は、プロジェクトを企業活動全体の文脈の中にはめこむことに、苦心している。

落合氏は、元大手SIerのSEという異色の経歴を持つ税理士だが、「PRINCE2のようなきちんとしたガバナンスの発想は、日本企業にはとても必要だが、もしかすると文化的に受け入れられないかもしれない」と言われた。「しかしPRINCE2を見ていると、世界中の植民地を支配した大英帝国の根っこにある考え方が、本当によく分かる」とも。

わたしの受けた感想は、また方角が少し違うものだった。PMBOK Guideが記述する10のマネジメント・エリアやそのプロセス群は、受注型プロジェクトによくフィットする。他方、RPINCE2の規定する概念や手順は、むしろ自社が自発的に行うタイプのプロジェクトに向いているのではないか、と感じたのである。

もともと、初期のPMBOK Guideは、米国の防衛宇宙産業とENG産業の人たちが中心になってまとめたものだった。だから、受注型ビジネスが主軸になるのは当然なのである。そして、受注型プロジェクトの最大の特徴とは、スコープ・コスト・スケジュールの三大制約が厳しいことにある。だからこそ、その三つを統括する立場にいるプロマネには、かなりの権限が与えられ、決断がなされるべき、という思想になる。

PRINCE2はむしろ、オープンエンドな自発型プロジェクト、たとえば自組織(官庁を含む)が発案し投資する情報システム開発などが典型例である。そこではむしろ、プロジェクトの方向性と、組織全体の方向性のアライメントが重要なのである。だから、ある意味では過剰に上から介入される(ように見えかねない)3階層モデルや例外管理が大事とされるのだ。

したがって、PRINCE2は、製造業におけるBOM再構築プロジェクトなどには最適ではないかと感じる。あるいは新製品開発や、業務改革プロジェクトなどにもいい。こうした種類の自発型プロジェクトは、“基本設計さえ決めれば、あとは力仕事”というスタイルでは進めにくい。むしろ、“考え考え、少しずつ進んでいく”スタイルがあっている。いいかえれば、「歩きながら考える」である。欧州の定番ジョークに、“フランス人は考えてから走り出す、イタリア人は走ってから考える、そしてイギリス人は歩きながら考える”というのがあるが、PRINCE2はまさに、歩きながら考える英国文化の産物なのだろう。

→「革新的生産スケジューリング入門」にもどる

ガバナンスと自由の3つのレベル (2013/02/26)

ガバナンス』という言葉は多義的な語だ。元々Governという動詞は政治の用語で、英国王は「君臨すれども統治せず」(the king reigns, but doesn't govern) のように、権力や統治の意味で使われてきた。それがいつからか経営の世界に入り込んできて、もう少し別の意味で使われるようになった。たとえば「コーポレート・ガバナンス」とは、主に“企業の行動が株主の利害に一致するよう仕向ける事”で、社外取締役を置いて第三者の目で、幹部たちの運営をチェックする、といった仕組みなどを指す。統治よりもやや弱く、牽制や監視という程度に近い。(もっとも、企業の反社会的な行動を抑制することがガバナンスの主目的だ、という議論もあるが、ここでは深入りしない)

企業行動をその株主の利害に一致させるという点では、子会社政策のあり方も「ガバナンス」の一種であると考えられる。親会社と子会社の関係には、全面的指示から自由放任まで、後述するようにいろいろなパターンがあるが、どれをとるのが適切かを考えるときに「ガバナンス問題」が論じられるのである。

これが「ITガバナンス」となると概念はもっと茫漠としている。経産省の定義によれば「企業が競争優位性の構築を目的としてIT戦略の策定及び実行をコントロールし、あるべき方向へと導く組織能力」なのだそうだが、だとしたら経産省自身のような官庁・公共団体のITガバナンスはどうなるんだ、とツッコミを入れたくもなる。そもそもこの定義だと、ITのマネジメントとどこが違うのか、疑問が生じる。マネジメントとはまさに、戦略や計画を策定し、組織を動かして実行をコントロールすることではないのか?

しかし、このITガバナンスという言葉には、妙なところで出くわすことがある。今でも思い出すのは10年近く前、ある大企業の本社を訪れた時のことだ。某地方の工場(製造子会社)の複雑なスケジューリング問題に関連して、いろいろと知恵を絞って解決策となるはずのシステム構想を作成した。計画系だけでなくMES(製造実行システム)をうまく組み合わせた点に工夫があると自負していた。

見積書を客先担当者に提出し、それなりの評価をもらったな、と感じたのはいいが、「予算は工場子会社が出すが、本社の情報システム部門に説明して了承をとってくれ」、という。(それって本来あなたの仕事じゃないの?)という気もしたが、そんなことを言っていたら仕事は取れない。のこのこ本社に出かけて情報システム部長に面会したところ、ちょうどそのころ某最大手ERP導入が佳境に入っていてイライラしていたらしい。言下に「NO」と拒絶された。理由を聞くと、「ITガバナンスの観点上」という。

「ITガバナンスの面でどういった問題点があるのでしょう?」と質問したが、あまり明確な理由はない。「今のこの時期に、こんな金額の投資は認められない」というだけだ。本社に相談せずに、現場側で先走ったとの印象を持たれたらしい。「お金は別に貴方が出すわけではなく、子会社が負担するんでしょ」と口に出かけたが、それを言ったら喧嘩になるだけなのは見えている。本社の『ガバナンス』の壁にすごすごと引き下がるしかなかった。今でもあの工場は、複雑なスケジューリングを、たった一人の担当者のExcelスキルでまわしているのかな、と思う。

顧客の意思決定権限を確認するのは、セールスの基本だ。営業的な手順を間違えたわたしの失敗談はさておき、「ガバナンス」という言葉が使われる局面をいろいろ調べていくと、ひとつの共通点に気がつく。それは、“ある程度の自立性を持つ相手を、どう動かすべきか”という局面である。「自立性」がキーポイントだ。子会社などその典型である。相手は一応、企業として自分で稼いで利益を上げている。だから自分の行動は自分で決められる(はずである)。しかし親会社は、自分たちが望む方向性にベクトルを合わせたいと考える。これが、自立性のない相手、たとえば直接の部下だったらガバナンスではなく「マネジメント」になるはずだし、意識を持たぬ機械だったら「コントロール」(制御)と呼ぶはずである。あるいは外注先の場合も、発注金額と契約書で勝手な自立性を縛っているわけだから、ガバナンスなどとは誰も言わない。これはITに限らず、どの分野でも共通である。

このガバナンスのあり方だが、具体的な仕組みや方法はさておき、大きくいって三つのレベルがあるのではないかと考えられる。それは「統治力」の強さによって分類される。相手の「自立性」をどれだけ制限するか、と言い直してもいい。(わたしの好きな用語でいえば、相手の「自由度」を制約する度合いである)

統治力として最も強いのは、完全な中央集権的ガバナンスである。上位側が、相手側の一挙手一投足、箸の上げ下ろしまですべて指示命令を下して実行させる。自立性はほぼゼロだ。決められたことをやるだけ。そのかわり、結果の責任も全部、上位側が引き受けることになる(当然だが)。むろん、投資などの費用も上位側がすべて負担する。

この対極にあるのは、自由放任だ。いちいち指示はしない。とにかく自分で動いて勝手に稼げ、と。もっとも、完全な自由放任で、相手が何をやっているのかもわからない状態だと、「ガバナンスは存在しない」と同義だ。だからこれをガバナンス・レベル=0と呼ぶことにしよう。

では、最低限のガバナンスとは何か。それは、相手側の行動が上位側につねに見えるようにしておくこと、すなわち「見える化」「可視化」の実現である。これを、ガバナンス・レベル=1、と考えよう。相手の行動は見えるが、何かを決めるのは基本的に相手側の自立(自律)によっている。このレベル1ではふつう、大きな問題や異常が起きた時だけ、上位側に相談がくることになる。

レベル1と、先ほどの中央集権型ガバナンスとの中間レベルには、どんなものがありうるか。それは、「承認型ガバナンス」であろう。予算あるいは権限のどこかに上限を設けておいて、そこを超えるような事案については、上位側の承認をうける。上位側は審議権(拒否権)を持つ。これをガバナンス・レベル=2と呼ぼう。レベル2は、会社とプロジェクト・マネージャーとの間などでもしばしば取り交わされる形式だ。こうして、プロマネが自分の恣意性や私益のために、勝手に巨額発注することを防ぐのである。この順でいえば、中央集権型はレベル=3になる。もちろん中間レベルをさらに細かく区分することも可能だが、そういう議論は学者にまかせよう。

レベル0からレベル3まで、図式化すると下図のようになる。レベル0はガバナンスの範囲外である。1−3のレベルに従って、上位からの指示命令(権力)は強くなるし、逆に対象側の自由度は小さくなる。自由度とは何かというと、つまり指針がない状態のことである。さらに、これらと対になる項目として、ビジネスの結果への責任と、投資の費用負担をあげても良いだろう。指示命令の力が強いほど、結果への責任が大きくなり、投資は対象側の負担比率が下がる(上位側の負担比率が上がる)。つまり、金も出すし口も出す、という状態である。どれをとるかは、その企業グループの経営方針によるが、同時に、相手側のビジネス環境や市場変化の速度、上位側からの注文への依存度などなどで、一番まともなレベルを選ぶべきである。企業だけでなく、地方自治などもこの図式でみると分かりやすい。

そして、大体において議論がこじれるのは、この4つの項目の比重がアンバランスになる場合だ。上位側が口は出すのに金は出さない、とか(上にあげた某大企業のケースはややこれに近いかもしれぬ)、相手側は自立した稼ぎがあまりないのに自分で全部決めたがるとか。口を出すのに責任はとらない、あるいは、言うことを聞かないのに投資ばかり求める、などなど。

考えてみると、サラリーマンが飲み屋で議論したがる問題点も、ある意味で「上位側=上司」と「相手側=自分」との自由度と責任の確執ばかりだといっていい。つまり、「ミニ・ガバナンス問題」なのである。部下には通常自立した予算執行権はないから、厳密にはガバナンスと呼ぶべきではないだろうが、上司が部下の仕事にどこまで指示(介入)するかは永遠のテーマでもある。

ただし、一つだけ忘れてはならぬ事がある。それは、ガバナンスのレベルを中央集権に近づければ近づけるほど、上位側の情報処理能力がたくさん要求されることだ。相手側の箸の上げ下ろしまで指示するわけだから当然だろう。それも、業務が正常に回っている間はまだ良い。問題は、異常が発生したときだ。異常が大きく、リアルタイム性が高ければ高いほど、上位側の処理は間に合わなくなるだろう。だから現場側に権限移譲が必要になるはずだ(現場が責任を上にかぶせて逃げる傾向があれば別だが)。逆に現場側に隠し立ての傾向が強く、あまり「可視化」できていない組織の場合、重大な問題を上位側がつかむのが手遅れになりがちだ。その場合は上位側が相手に踏み込まなくてはならない。

つまり、ガバナンスのレベルをどう決めるかのルール決めはもちろん大切だが、「どういうときは、そのルールを乗り越えなければならないか」を共有することの方がもっと大切なのである。だからこそ、ガバナンス問題はややこしくて難しいのだ。

→「革新的生産スケジューリング入門」にもどる

ガバナンスの最適設計を考える (2013/03/19)

少し前のことだが、メディア系のWebサイトを見ていたら、部下の使い方に関するなかなか興味深い記事を見つけた。著者は外資系経営コンサルティング会社の人で、自分が初めて部下を使う立場になった時に、放任し過ぎたり指示しすぎたりして失敗したという話だった。結局適切に仕事を委譲しながら、成功した時は部下の手柄にし、失敗した時は自分が責任を取るようにすることで、最終的に部下のモチベーション高め、いい企画を量産できるようになったという。“量産された経営企画”なんて受け取って、はたしてクライアントは嬉しいのかという問題はさておき、部下のマネジメントの仕方という点では賛同できるところの多い記事だった。

ただし読んでいて少し疑問に思ったこともあった。そもそもマネジメントの本来の原義は、「人を動かして目的を達すること」である。部下の使い方は、その意味でマネジメントの基本中の基本である。その著者は金融業界出身で経営コンサルタントに身を転じ、 MBAの資格も取っていた。にもかかわらずマネジメントの基本については、何も知らななかったということになる。マネジメントの基本を知らない人が、なぜ他人の会社経営については助言できると思えるのだろうか?

ここ何回か、ガバナンスの問題について続けて考えてきた。ガバナンスとは、ある程度の自立性を持つ相手を、自分の利害関係に沿った形で動かすための仕組みである。子会社を動かす場合がその典型だし、社内の組織や部門を動かす場合もその一つである。マトリクス型組織の中で、いろいろな機能部門をプロマネが動かす仕組みを、プロジェクト・ガバナンスとよぶこともある。自分の部下だけで完遂できる中小規模のプロジェクトと違い、クロス・ファンクショナルな仕事では、どうしても直接の命令権の及ばぬ部門にも動いてもらわねばならぬ。

先にあげた、部下をどう動かすかという問題も、ガバナンスとかなり共通した面がある。もちろん個人と組織では大分違うわけだが、自由放任だけでも厳格な指示命令だけでも、なかなかうまくいかない点は共通している。では、適切なガバナンスのあり方とは、どのようなものなのだろうか。

このサイトでは、まず、ガバナンスには3つのレベルがあるという話を書いた(『ガバナンスと自由の3つのレベル』)。3つとは、中央集権型承認型、そして可視化型である。ガバナンスの強さはこの順に弱くなる。そして、さらに外側に自由放任型が来る。いろいろなガバナンスのあり方は、この類型ないし尺度のどこかに定置できそうだ。

その次には、国と地方自治体のガバナンスの関係について書いた(『ネストする地名の謎』)。明治に成立した近代日本のガバナンス体制は、国が都道府県に自治権をあまり与えぬ中央集権型であった。その手段として、恣意的な合併や、名称の操作なども利用した。このような制度設計は官庁・民間問わず、その後の日本の組織に大きな影響を与えたに違いない。

さらにそこから派生する話題として、コストセンターとプロフィットセンターの区別について考えてみた(『コストセンターとは何か』)。コストセンターとはお金だけかかって、何も生みださぬ組織であるかのように誤解されている。しかし経営学的に考えれば、コストセンターとはコストとサービスレベル(品種・納期など)に対して管理責任を持つ組織である。サービスレベルがきちんと定義されないと、コストセンターはただただコストダウンを要求されるだけの、自律性のない組織になってしまう。

さらに言うと「コストセンター子会社」という呼び方は、会計学的には間違いだ。この言葉は多くの場合、親会社からの収入に100%依存している機能子会社のことを、暗に指している。そして外販比率が高くなると、子会社は「プロフィットセンター」と呼んでもらえるようだ。プロフィットセンターになりさえすれば、少しは格が上がり、親会社からのうるさい干渉をはねつけやすくになる、と理解している向きも多い。「コストセンター」の用語を、このように妙に差別的な意図で使うのはおかしいと思うが、世の中に横行しているのは事実である。

では、これら一連の考察から見えてきたものはなんだろうか? なぜ「コストセンター」論と、一見無関係なガバナンスのあり方が、一つながりのものとして意識されるのか。そもそも企業ガバナンスの原義が、「企業経営の方向性を、株主の利害に一致するよう保証する仕組み」であるならば、子会社の株主は親会社なのだから、どこまで口をはさんでもかまわぬ、適切な限度など無い、という結論になりはすまいか。

ここで問題となるのが、中央集権型ガバナンスの限界ないし短所である。短所は二つあった。まず、あらゆる判断が上位の決定に委ねられるわけだから、上位側の情報処理能力がかなり高くなければいけない。かつてフセイン大統領時代にイラクに住んでいた研究者から聞いた話だが、生活上の、アパートの不都合か何かを知人にこぼしたところ、「だったら大統領府に直接かけあえばいいじゃないか」と言われたという。これを聞いて、独裁者というのはひどく忙しいものだな、と思った。あらゆる細かな問題や雑事が上がってくるのである。ナポレオンの睡眠が3時間だったというのも、たぶん寝ているヒマがなかったのではないか。

中央集権型のもう一つの欠点は、現場の問題の解決に時間がかかることだ。はるか上までお伺いを立てるのだから、当然だろう。だから、比較的平穏で、問題の少ない職場や業界ならばいいだろうが、リアルタイム性の高いトラブルが頻発する組織では、中央集権型ではやっていけなくなる。情報のパイプだって輻輳し、詰まってしまうだろう。

そこで考案されたのが、Management by Exception(「例外による管理」)だった。これは、「異常時が発生したときだけ報告を上にあげ、上位側が問題解決に乗り出す」方式だ。異常がないときは、報告はあまり小刻みには上げない。そうすることで情報の輻輳を避け、上位側が本来業務に集中できるようにするのである。逆に言うなら、通常でのガバナンス・レベルは、少し下げることになる。

ところで、問題解決について言うなら、どんなに優秀な上位管理者でも、分野的な得意不得意はあるはずだ。自分が経験しよく知っている事象なら解決できるが、自分から縁遠い分野では、うまく指示できにくい。ここにもう一つのポイントがある。つまり下位側の問題解決力がどれだけあるか、である。もし下位側の自己管理能力が高い場合は、方向性と状況だけを見えるように指示し、内容は任せてしまう方が現実的となる。

以上をまとめたものが、図に示した4類型である。ここでは子会社へのガバナンスの問題として表現している。縦軸は、その子会社業務の、上位側(本業)から見た重要性、あるいは本業とのシナジーである。横軸は、子会社の自己管理能力だ。これは、外販比率と置きかえてもいい。というのは、自己管理能力は「プロフィットセンター」としての自立経験を通して培われるからである。



左上の象限は、本業から見た重要性が高く、かつ子会社の自己管理能力が低い場合。当然、細部まで指示命令を下す「中央主権型ガバナンス」になる。ところで、親会社(内販)依存だが重要性が低い、左下の象限は、「承認型ガバナンス」(例外による管理)が現実的である。問題発生時には上位側が入り込んで解決せざるを得ない。

右上の象限はこれに対し、外販比率が高く、自己管理能力の高い子会社で、かつ本業ともシナジーの高い分野を示す。こちらは「可視化型ガバナンス」で、業務の進捗状況をモニタリングできるようになっていればいい(問題は自分で解決できる)訳である。最後に残った右下の象限は、シナジーも低く、外販中心の分野。ここはもう「自由放任型」になる。そのかわり、投資も自分で負担してくれ、ということなる。

このように整理してみると、最初にあげたガバナンスのレベル0〜レベル3は、どれもぴったりはまる位置があるようだ。何もかも中央集権や自由放任ではなく、どのタイプにはどれを当てはめるのが適切か、軸が分かったように思う。

ところで、現実には問題が一つだけ残っている。それは「自己管理能力」の評価が、上位側と当事者ではちがう、という問題だ。人間の世界でも、子どもの側はもう自立したつもりなのに、親はいつまでも世話を焼き小言を言いたがる、という例は多い。上位側がいつまでも下位側の能力を過小評価すると、いつまでも中央集権型ガバナンスから抜け出せず、その結果、組織全体として非効率が生じる可能性がある。

そういう意味では、自己管理能力≒外販比率、と図示したが、これは本当はフェアではない。先に述べたように、本来は内販100%のコストセンターでも、サービス・レベルをきちんと定義できれば、自律的な管理ができるのである。自己管理能力は、コストセンターとしての達成経験等によっても、培われるはずだ。だからガバナンスの設計においては、組織の自己管理能力をたえず再評価する仕組みが必要だということが分かるのである。

→「革新的生産スケジューリング入門」にもどる

結果オーライのマネジメントでいいのか? (2017-01-20)

帰国した知人と久しぶりに会った。アジアの新興国で会社の経営陣の一員として働いている。日系ではなく純然たる現地企業だ。中堅規模でそれなりの業績も上げているらしい。知人の主な仕事はBusiness Development、すなわち事業分野の拡大と経営面の仕組み造りである。わたしも最近ずっと経営企画的な仕事をしているので、興味が重なり、いろいろな話を聞かせてもらった。

知人がその会社にヘッドハントされて着任したとき、真っ先に気になったのは、きちんとした中期的な経営の方針がないことだった。彼の会社は、その国の結構大きなコングロマリットの一部であり、子会社の位置づけだ。だが親会社からは、「何の指針も指示もなく、P/Lのボトムラインだけで管理されている」状態だったという。

P/Lとは財務諸表の『損益計算書』(Profit & Loss)の略称だ。損益計算書は一番上に売上収入が書かれ、その下に出費経費がずらずらとならぶ構造になっている。一番下の行には、差し引きの結果である経常利益が記載される。これを英語ではよく"bottom line"と称する。「P/Lのボトムラインで管理する」とはつまり、通期の利益額だけを見て、赤字だったら叱責され、黒字ならよしよしと言われるか、「まだ足りない」と言われるか、だけだったということを意味する。収益が大きければたぶん経営者はグループ内で地位が昇格し、赤字が続けばクビになって別の者にすげ替えられるのだろう。

だが、これだけでは、会社の経営陣として次にどういう手を打つべきか、さっぱり分からず、方向性が定まらないと知人は言う。そうだろうな、とわたしも思う。お前の会社はグループ内でこういう位置づけ、こうした役割を担っているのだから、こんな風な姿を目指せ、親会社として支援できるのはここまでで、判断基準ややり方はこうだ、というような指針が一切ない。ただ結果としての利益を出せ、と言われているだけだ。

きいていてわたしは、「甘えるな、結果が全てだ!」という標語を思い出した。わたし達の社会では、あちこちで出会うセリフである。経営者は結果が全てだ、利益を出せるかどうかだ。これは多くの株主が感じていることだろう。あるいは職場でも使う。営業は結果が全てだ、受注できるかどうかだ、という具合に。学校教育でもそうかもしれない。入試は結果が全てだ、いくら試験場で気張っても入試に通らなければ意味がない。スポーツも、参加したって勝てなければ意味がない・・

これは裏を返せば、良い結果さえ得られれば、その方法や途中経過は問わない、というメッセージでもある。そのやり方がどんなに属人的でも運頼みでも、とにかく結果さえ出れば、それで良いとほめられる。そして結果は、たいていリーダーの功績に帰せられる。だから優れた業績を上げた人は、どんどん引き上げて、より上位のポジションにつける。結果とは一種の人材選別のフィルターであって、優秀な人間を見いだしてリーダーに据えることですべてはうまくいく。そういう思想の表れである。そう考えると、わたし達の社会でやっている受験競争だとか就活だとかの大騒ぎの意味が、よく分かるではないか。試験で優秀な結果を出せた者が一流大学に進学でき、その中の成績上位者がさらに中央に引き立てられてエリートとして社会に君臨する。そのおかげで日本はここまで立派な大国になったのである、と。

でも、知人のケースに話を戻そう。結果を出すために、目の前の仕事を取りに行って、何とか完遂する。それをおえたら、また次の仕事を取りに行き、完遂する・・これの繰返しだけでは、会社は新興国の不安定な景気の波にもまれるだけで、真の成長はむずかしい。このままではまずいので、Strategic Business Planを作ることになった。それが彼に期待されたミッションの一つでもあった。ちなみに知人は元々、技術屋である。だが長らくプロジェクト・マネージャー職に従事し、さらに<マネジメント的な視点>を持っている人だ。経営関係の勉強もそれなりにしている。彼の上司にあたる社長も、技術者上がりだ(わたしは一度だけ挨拶したことがあるが、人柄を感じさせる立派な方だった)。だからこうした方面の役割を、その知人に期待したらしい。

Strategic Business Planであるから、まずは会社が中長期的に目指す姿を明らかにすることからはじめなければならない。そのためには無論、ある程度のマーケットの読みが必要である。魚のいない海に船を出してもしかたがないからだ。アジアのその国では、長い政治的低迷時代を少し前に脱し、ようやく成長過程に入っていて、エネルギーやインフラなども市場が期待できる。ただし市場は大きくても、競争をどうしのぐかが次の問題になる。せっかく豊富な漁場に出ても、周りを見渡したら、(たとえば)中国漁船がうじゃうじゃ、というのでは始末に負えまい。それから、自社の強みを明らかにして、それを向上させる技術なり人材なりの方策が必要である。漁場も良く、回りにライバル船が不在でも、自分の船にGPSもレーダーもなく、古代さながらの投げ網だけでは、収穫はしれているというものだ。

こうした仕事を進めるにあたり、すべてを自分だけで我流でやらず、社内を動員し、また外部のコンサルタントを活用したそうだ。とくに遂行面での弱みを補強するために、欧米系の超有名な、「マ」ではじまるコンサル会社を雇ったりもしたのだが、ここは期待外れだったらしい。それはさておき、彼が目指すStrategic Business Planを一通りつくり上げることができた。外部コンサルも、自分たちの頭を整理してくれる点では役に立った。なぜなら、経営計画を策定するという仕事はどこの会社にも共通しているし、経営学という学問の蓄積も一応はある訳だから、自分でゼロから車輪を再発明せずにすむ訳である。

こうして海図と羅針盤は手に入れた。だが、これからPlanを実行する段になると、別種の難しさに向き合うことになる。それは環境変化だ。

ここでちょっと考えて見て欲しい。今、AとBの二人の経営者がいるとする。彼らの会社の利益は次の通りだ。あなたが投資家だったら、どちらの会社がより投資先として好ましいと思うだろうか?

どうやらこの国では、第2期は景気が良く、第3期はその反動で不況だったようだ。こうした環境変化はつねに起こりうる。企業の業績も、それを反映して変わるのがつねだ。それはこの表にも現れている。そしてA社・B社とも、4期合計の利益額は180億円で、結果に違いはない。

だが、A社はいかにも、業績にムラがある。これにたいしてB社の方が、より安定している。あなたが投資家だったら、B社の方が好ましいと思わないだろうか。たしかに経営者は結果が大切で、たくさんの利益を出した方が勝ちかもしれない。だが、ある期は黒字、次の期は赤字で、先々の予測がつかない経営では、ジェットコースターに乗っているようなものだ。過度のスリルを楽しみたいギャンブル的投機ならともかく、投資としてはいただけない。

つまり、組織のパフォーマンスというのは、個別の結果の良し悪しだけでなく、『予見可能性』が高いことが、社会から信用を得るためには非常に大事なのである。それはある意味、個人でも似ている。天才肌で、仕事の業績が飛び抜けて良い日もあるが、別の日はさっぱりふるわない、では組織の一員として使いにくい。何年に一度かヒット作が出れば食っていける職種もあるかもしれないが、たいていの業種はそうではない。

では、組織として、環境条件の変化にあまり左右されずに、安定してパフォーマンスを上げるためにはどうしたらいいのか。長くなってきたので、この続きは稿をあらためて、また考えよう。

→「革新的生産スケジューリング入門」にもどる

結果オーライのマネジメントでいいのか? − 成果の予見可能性を高めるために (2017-01-25)

海外企業で経営者の一員として働く知人が、「利益額という結果だけで親会社から評価されマネージされるのではたまらん」と考え、Strategic Business Planを策定したという話を、前回書いた。彼は安定した成長の軌道を描くために、そして必要な経営資源を明らかにするために、苦心している訳である。では組織が「結果オーライのマネジメント」を脱して、成果の予見可能性を高めるためには、どうしたらいいのか?

答えはある意味、単純である。最終結果だけではなく、途中段階をコントロールする。すなわち、仕事を結果に至るまでの過程=プロセスに分解し、プロセスを構成するそれぞれのステップがきちんと働くようにすることである。たとえていうならば、長い釣り竿の先端を、ねらった位置にぴたりと当てるゲームを考えてみてほしい。根元だけ持って、先端の位置をコントロールするのは難しい。途中で勝手にしなるし、手元のブレや風の影響でブルブルゆれるだろう。だが、竿の途中の何カ所かに細い棒か何かで支えを入れて、その支えの位置をそれぞれ動かせれば、先端の位置決めははるかに精度が高くなる。そういうことだ。

仕事をプロセスに分解するとは、受注型営業ならば、商品説明→提案→見積→受注、という段階になるだろうし、設計作業なら要件確認→基本設計→詳細設計→試験確認、といった流れかもしれない。図では、仕事を直列な4つのステップに分けているが、べつに4でなくてもいいし、直線状ではなく分岐や並行があってもいい。

各ステップには、それぞれの中間成果物や達成状態がある。そして各ステップには、そのパフォーマンスを左右するような、主要な導因(Key drivers)と、それを測るモノサシがあるはずだ。これが先ほどの釣り竿の例でいう、途中の支えに相当する。たとえば営業の商品説明なら、客先への訪問がKey driverだろう。それは訪問件数で測ることができる。そのステップの中間結果としては、次のステップ=提案まで持ち込める案件の比率が、達成度合いを示す。このようにプロセスを分解して、各ステップの状態を良く見分けることができれば、最終結果に至るずっと以前に、先行きの予想がつきやすくなる。つまり『予見可能性』が高まるのだ。

かりに営業の受注プロセスをよく見たら、商品説明から提案までは高い比率で進んでいくのに、その後、見積に行く段階で急に案件数が下がったとしよう。だとしたら、受注がふるわないのは、「商品力がないから」とか、「他社より価格が高いから」といった理由ではなく、「提案段階での内容・質に問題がある」ことが主要な原因だと分かるだろう。商品に興味は持ってもらえるのだ。だが、提案が顧客の期待にマッチしていない。だとしたら、提案力を上げるにはどうしたらいいかを考えることになる。

そして各ステップには、そのパフォーマンスに影響を与える環境要因がある。これもステップ毎に異なるはずだ。環境要因とは、担当者の意志や努力ではどうにも変えられない事象を指す。提案段階のパフォーマンスに影響を与えるのは、「世の中の景気」でもないし、「他社との競合の激しさ」でもあるまい。

提案力が低いのは、もしかすると設計部門が多忙すぎて提案営業に協力できない、といった内部環境なのかもしれない。あるいは単に、営業から技術部門への顧客ニーズの伝達が、うまくいっていないのかもしれない。ただ明らかなのは、「世の中の景気が落ち込んで競合が厳しくなったから受注高が上がりませんでした」という説明は、事実を正しく伝えていないということだ。こうした営業部門の言い訳は、プロセスに分解すると正当かどうか判断できる。

戦略とは、限られた経営資源をどこに集中し、どこは略すかを決めることである。だから上記のような状況では、提案能力を上げる部分に、人員や資金や技術を投入すべきだということになる。戦略は一種の賭けでもあるので、経営資源の投下が本当に期待した効果を上げているかを、Key driverと中間成果の数字で測って、適時検証しなければならない。

・・と、いうような話は、別にわたしの創意でもないし、取り立てて新しい考えでもない。結果だけを見るのではなく、結果に至るまでの段階と構成要素を見てコントロールすること、かつ全体を見て判断すること、必要ならばその仕組みを改良すること。これがシステムズ・アプローチである。原理自体はとりたてて難しいものではないし、図を見ればほとんどの人は「なるほど」と同意するだろう。プロジェクトという大きな仕事のまとまりを、構成要素であるActivityに分解するWBSという手法だって、その一例である。工場の人なら、工程単位に検査をしながら進んでいく「自工程完結方式」だな、と思うかもしれない。

だが、システムズ・アプローチを知っているということと、組織がいつでもそれを使いこなせるかどうかは、別物である。組織の構成員が無意識に従う、体系化された思考と行動の習慣を、わたしは『組織のOS』と呼んでいる。「結果オーライのマネジメント」が横行している組織では、システムズ・アプローチはまだOSレベルに至っていないな、と判断できる。そういう組織では、仕事の成果は人で決まるか、環境に左右されるか、だと信じられている。だから競争で人を選別するか、あるいは各人の頑張りで環境条件をはね返すしかない、という結論になる。

最近、とある著名な経営コンサルタントから聞いた話がある。この方は製造業の分野に強いのだが、日本企業の海外展開のあり方について気になることをいっておられた。海外に工場を建て、子会社を作るのはいいのだが、その子会社に対してまさに「利益額の結果だけで管理する」やり方をとっている企業がほとんどだ、というのだ。きいていて、ちょっとドキッとした。

かと思うと逆に、やれ機械稼働率だ部品購入単価だ一人あたり生産性だと、部門別に細かなモノサシをたくさん指定して、それで工場同士を比較競争させる発想もけっこう強いらしい。「KPI経営」と、その方はよんでおられた。

KPI経営のどこがまずいのか? 企業の部門というのは、営業・資材購買・製造・物流、という風に、仕事の機能単位に、まさにプロセスで並んでいるのだから、それぞれの機能をKPIでコントロールするやり方は、まさに上に述べたシステムズ・アプローチではないか、と思う人もいるかもしれない。

だが、両者は似て非なるものである。まず、プロセス全体を見ている者がいない。日本の工場を「マザー工場」に指定して、海外工場にならわせるマザー工場制度を取るところも多いので、実質的には日本の各部門が、子会社の各部門をそれぞれ個別に指導・管理しているだけだったりする。だから、工場長はいるだろうが、日本では適切だったはずのKPIが、海外工場に同じように該当するかどうか、誰もきちんと全体を見て検証していない。

それに、上述の各ステップのパフォーマンスを左右する動因の一つは、すぐ上流側から受け取る中間成果物の品質やタイミングなのである。いってみれば上流側プロセスが、各ステップにとって最大の『環境』に相当するのだ。それなのに、上流側が勝手にそれぞれ局所最適を目指したらどうなるか。

たとえば資材購買のKPIが購入単価だったとする。つまり安ければ安いほどいい、と。いきおい、入ってくる資材は品質や納期にリスクを抱えることになる。加工課のKPIは機械稼働率だったとしよう。そしたら、とにかく機械を遊ばせないため、遅れ気味の資材が、入るはしから部品に加工したがるかもしれない。低品質な部品が、使うかどうかも不明なまま大ロットで工場倉庫に積み上がる。ところで組立課のKPIは一人あたり生産性である。そこで、できるだけ部品を作業ラインの近くに置いておきたがる。かくて、工場はモノであふれかえっているのに、必要なモノは足りなかったり、出来上がった製品の品質はさんざんだったりする・・

おわかりだろう。各ステップのKey Driversというのは、プロセス全体をとりまく状況に依存するのである。だから、システム全体を見る目と、判断する能力が必要なのだ。中小零細の工場主なら、こうしたことは理屈で知らなくても体感でわかっている。むしろ中堅以上の、分業が進んだ企業組織ほど危ない。業務を機能別に分解してKPIで働かせるだけででは、マネジメントしていることにはならない。だって。WBSをつくって各Activityに担当者を割り振ったら、あとはプロマネなしでもプロジェクトは成功するだろうか? そうはいくまい。つねに変わりつつある内部環境や内部環境に応じて、総合的に判断する役目が必要なのだ。「総員がその持ち場で最善を尽くせば、結果は必ずついてくる」などというのは、じつはマネジメントの不在を示している。

くりかえすと、組織全体の成果の予見可能性を高めるためには、プロセス(工程)によるマネジメントとコントロールが必要である。そのためには、

という手順を踏むことになる。こうしたことは、皆がある程度、無意識にやっている事かもしれない。いわれてみれば当たり前、あるいは「そんなの知ってるさ」という事かもしれない。だが、それを形式化し、OS化することが大切なのだ。それによって、属人的な仕事の進め方(技能)が、標準化された技術になるからだ。

そしてもう一つ。こういった原則的な知識は、字で読んだだけでは身につかない。自分自身の状況に引きつけて応用問題を考え、少しずつ試しながら理解する必要がある。たとえば上記のプロセスに、ループや分岐があったらどうしたらいいのか。どうみても数値化しにくい中間成果は、どう扱うか。

一般にマネジメントの問題には正解がないといわれる。それは、現実の仕事には環境条件や不確実性が左右して、結果に必ずしも再現性がないためである。だが同時に、『全体を見て総合的に判断する』ためには、確固とした価値観を持たなければならないからでもある。そして、こうした総合的判断の訓練のためには、学ぶ仲間がいるほうがいい。現在、わたしが主宰する研究部会では「PM教育の新しいアプローチ」を構想中だが、そこで学びのコミュニティが必要であると考えているのは、このためだ。一人だけで問題を考えると、どうしても視野が限られるが、複数人なら「三人寄れば文殊の知恵」が働くからだ。

そしてわたし自身も、まだ学びの途中である。

→「革新的生産スケジューリング入門」にもどる

ビジネス・マネージャーとは何をする人か (2017-07-09)

数年前、製造業に働く方から相談を受けた。その企業では、西南アジアの某国でプロジェクトをはじめるという。プロマネ以下、何人かのチームでその国に乗り込み、現地企業と共同で新しい製品の製造ラインを作る仕事だ。そこで、何かアドバイスがあれば頂戴したいという話だった。

もちろん、わたしはその会社の製品について何も知らないから、技術的アドバイスなどしようもない。できるのはマネジメント的なアドバイス、つまりプロジェクト・マネジメント面での助言ということだろう。そこで、チーム編成やプロジェクト期間などについて少したずねた後で、わたしは申し上げた。

ビジネス・マネージャーを任命してチームに入れるべきです。
 営業畑でも、法務でもいい。文系の人を任命してください。」

技術的プロジェクトだからと言って、技術者ばかりでチームを編成するのは賢いやり方ではない。そう、わたしは申し上げた。もちろん文系といっても、英語が一応しゃべれることが望ましいですが(その国でビジネスをやるなら、英語のコミュニケーションが必要になる。大学教育は英語で行っているはずだから)。
??でも、ビジネス・マネージャーって、何をするんですか?

それが先方の疑問だった。なるほど、知らない人には分かりにくいかもしれない。

日本には理系と文系という、諸外国にはあまり見ない不思議な制度的区分がある。理系の人は文系のことは知らなくて良いし、文系の人は技術に興味がなくてもて当然だという、思考習慣がある。MITすなわちマサチューセッツ工科大学に、経済学や言語学の講座があってもいいじゃないかと考える欧米流とは少し、ギャップがある。

ただし英語では(つまり、英語でビジネスをする業界では)、Technical と Commercial という区分がある。たとえば、きちんとした国際入札は普通、Technical Proposal と Commercial Proposalのに分冊の作成が要求される。日本語でいえば。技術提案書と商業提案書かな。

技術提案書には、設計面での提案や、遂行方針などが記される。そして商業提案書には、価格(明細・合計)、支払・保証など契約面についてが書かれる習慣だ。通常の日本の商慣習に翻訳すれば、前者が「見積仕様書」、後者が「御見積書」になるだろう。

そして国際入札では、まずTechnical Proposalの評価(技術評価)で合格した入札者のみ、Commercial Proposalが開封されるルールになっている。入札の選定は、値段だけでは決めない。いや、先に値段を見て安い応札者に対して、技術面をネゴしたりもしない。まして、技術的には優秀だが値段が二番手以下の応札者に対し、一番札の値段を教えて値引き要求をしたりもしない。これが国際的な慣習で、それを破ると業界内で信用を失う。つまり二度とまともに入札ができなくなる(応札者がいなくなる)、という仕組みである。このようなTechnicalとCommercialの区別と順位付けが、国際入札の仕組みを守っているのである。

さて、Proposal全体を取りまとめる責任者は、PM=プロマネである(あるいはProposal Managerともいう)。そしてCommercial Proposalの部分をまとめるのが、BM=ビジネス・マネージャーの仕事なのだ。

しかし、BMの仕事が一番大事になるのは、受注後の遂行段階である。そして、客先との交渉(ならびに、その準備)が主要な仕事の柱となる。追加や変更に伴う交渉においては、BMが過去の書類やメールなど、証拠(エビデンス)を全部まとめ上げる仕事をしてくれる。そして変更に伴うインパクトや、作業費用を見積もるのもBMだ。さらに過去データや外部企業の事例を探してきて、交渉の材料にするのだ。ここまで揃えば、プロマネの交渉の仕事はずいぶんやりやすく、楽になる。

なんだそれ、営業の仕事じゃないか、と思われた方もいるかもしれない。かもしれないが、貴方の会社の営業マンは、受注後もプロジェクトにはりついていられるだろうか? それも海外プロジェクトの現場で? せいぜい、たまに来て手伝うだけではないだろうか?

それに、交渉以外にもやる仕事はたくさんあるのだ BMは金銭や契約や雇用・労務に関わる一切の仕事に責任を持つ。もう少し具体的に列挙すると:

こういうこと一切合切を仕切るBMがいなかったら、どうなるだろうか? こうした事柄は、いずれにせよ不可避である。避けて通れないのだ。となると、結局誰かがやるしかない。そして、それはつまりプロマネの仕事になってしまうのだ。技術に専念したい技術系プロマネにとって、こうしたことは「雑用」に思える。わたしは技術以外のことを、雑用として軽んじる見方には組みしないが、そう考える人は現実に多いだろう。

ここで、R・ハインラインの名作SF「月を売った男」 に出てくる挿話をわたしは思い出す。この物語の中で主人公は、自分が月ロケットの設計図に集中したいときにかぎって、運送業者がトラックの手配について文句を言ってくる、といって嘆く。すると彼の片腕になる男が現れて、そうした「一切の雑用」を自分が引き受けます、だからボスは技術に集中してください、と宣言するのだ。

ソフトウェア産業における生産性の問題を論じた「人月の神話」 の著者Brooks Jr.は、この「月を売った男」のエピソードを引用し、技術系PMの下に、商務に強いBMがいるのが理想だ、と書いた。たしかに一つの考え方である。

いや、ちょっとまって。ウチの会社にはそんな、営業面も法務も人事も会計も総務もわかるような、しかも英語も話せるようなスーパーマンはいないよ。そんな声も聞こえる気がする。たしかにそうかもしれない。

だが海外のライバル会社には、専門のBMがいるかもしれない。BMの交渉力やサポートが案外、赤字と黒字の分かれ目になるかもしれない。だったら、今からでも育成するしかないのだ。そのためには、まず、ビジネス・マネージャーという専門職種が必要なのだと、会社が認識することが先決だ。

以前にも書いたが、わたしは「文系」と「理系」という人材の区分をあまり認めていない。わたしの勤務先には、いわゆる文系出身ながら、エンジニアリング会社のプロマネとして立派な仕事をしている人が何人もいるし、まだ駆け出しだった若い頃について勉強した先輩も経済学部出身のエンジニアだった。またわたし自身、理系と文系の両方の資質を持った人間だと自覚している。だから、「技術屋だから契約オンチでいい」とか「営業マンだから設計の話は知りたくない」といった、自分で壁を作ってしまう人々の態度は、一種の怠惰だと思っている。

だが、文系・理系という区分は世間に流通しているし、そういう形で自己規定している人も多い。だったら、せめてその範囲内では責任感を持ってもらいたい、というのがわたしの期待だ。だから営業マンであって労務や会計は素人であっても、せめて「文系の守備領域」については、技術屋に対して自負を持ってくれるだろうと思い、冒頭に述べたような提案をしたのだ。

念のためにいうけれど、プロマネ人財だって、固有技術も管理技術もよくわかり、かつ人徳があってリーダーシップも豊富な、スーパーマンみたいな人は滅多にいないと思う。で、スーパーマンがいなくても仕事がある程度成り立つためには、仕事の仕組み(システム化)が必要なのだ。そしてプロマネを補佐したり助けたりする支援組織や専門機能が必要である。

もちろん、ちゃんとしたプロマネをまず、意識して育成しなければならない。ただプロマネは最終責任者なのだから、BMの領域についてだって、少しは知る必要がある。つまり契約や請求や会計や雇用について、せめてBMとちゃんと会話が成り立つ程度には、概念と用語の知識が必要である。そしてBMの側にとっても、営業や財務や法務など本社の専門部署からのサポートが必要なのである。

冒頭にあげた会社が、うまくBMを任命できたかどうか、残念ながらその後の話はまだ聞いていない。社内で見つけるのは、そう簡単でなかったろう。ただ海外ならば、逆に欧米人の専門家を雇う手段だってある。まあ専門家を呼べば、たぶん高給取りだろう。しかし、それで技術者達が技術に専念でき、赤字を回避できるなら、総合的には安いものだ。

それは、マネジメントの価値とコストの比較論である。マネジメントはリーダー職の片手間仕事ではない。とくに海外プロジェクトならば、なおさらである。契約社会でのプロジェクトには、「文系」的な職域に強い人材も、必要なのだ。技術力だけでは勝てない。そのことの認識が、海外に打って出るときの第一歩なのである。

→「革新的生産スケジューリング入門」にもどる

アカウンタビリティとは「命令責任」である (2016/11/06)

RACIチャート」というものをはじめて知ったのは、90年代半ばのことだ。当時使っていたアメリカのERPコンサルタント会社が、要件定義段階での役割分担をRACIチャートの形にまとめてきて、なるほど、こういう整理の仕方があるのかと知った次第だ。ついでにいうと、「サプライチェーン」という言葉も、同じ時にはじめてきいたのだった。まだ日本ではほとんど知る人のいない概念だった。

RACIチャートとは、業務の上での役割分担と責任範囲(Role and Responsibility)を、分かりやすく整理するための表である。ふつう横軸の欄には、関係者や部門の名前が並び、縦の行には業務を構成するアクティビティが続く。そして、どのアクティビティは誰がどのような役割で関わり、責任はどこが持つかを書く。このとき、

R: Responsible
A: Accountable
C: Consulted
I: Informed

の4種類の関わり方で表すため、頭文字をとってRACIチャートと呼ぶ。

ところで、いつもいっていることだが、知ることと分かることは違う。RACIチャートを見たときには「なるほど」と思ったが、自分で書こうとすると、なかなか上手く作れない。それでわたしは、しばらくの間、RACIチャートから遠ざかってしまった。また使うようになったのは、会社の中で多少なりとも組織論に関わる立場になってからである。

RACIチャート作成がなぜ、むずかしいか。それには二つの理由がある。一つ目の理由は、ConsultedとInformedの役割の違いが分かりにくいためだ。「相談される」のと「知らされる」のは、似たようなものではないか? どうやって使い分けるのか。前者は双方向のコミュニケーションだが後者は一方向だ、と解説する人もいる。だがTV放送じゃあるまいし、ビジネスにおいては、文書やメールで伝達したって、相手が意見や質問を返すことが可能だ。本当に一方的な、問答無用な伝達というのは滅多にあり得ない。

じつは両者の違いは、タイミングの違いなのである。

つまり何らかの仕事のアウトプットを出す最中に、また何かの決断の際に、意見をきいて取り入れる相手がConsultedであり、出たアウトプットを渡したり決断の結果だけを伝える相手がInformedなのだ。この区別を知れば、CとIで悩むことはなくなる。

ところでRACIチャートを難しくする二番目の問題は、もう少しシリアスだ。それはR: ResponsibleとA: Accountableに正確に対応する概念が日本語の中にない、という問題である。ConsultやInformには、相談・伝達という訳語があって、その点では迷いはない。しかし、Accountableという英語に対応する訳語が、少なくとも’90年代半ばには、明確でなかった。辞書を引くと、「責任」とある。だがResponsibleとの違いは何なのか? たとえば研究社の「新英和中辞典」には、AccountableもResponsibleも「責任のある」と書かれているのだ。訳語がないとは、つまり日本文化の中にないということだ。

知り合いの米国人にたずねたが、どうやら彼には当たり前すぎるらしくて、かえって説明を聞いてもよく分からなかった。ただ、一つのヒントになったのは、予算権限に関係するときはどうやらAccountableらしい、ということだった。まあ、この言葉は語源的にははcount(勘定)からきているのだから、関係はありそうだ。他方、Responsibleはrespond(応答)から発生している。

さて、ご存じの通り、アカウンタビリティという言葉は、今世紀に入ってから、なぜかメディアで多少の脚光を浴び、その結果「説明責任」という訳語が登場した。苦心の訳語だったろうと想像する。だが、この言葉が流通するに及び、かえって日本文化では奇妙な誤解が広まったように、わたしは感じる。たとえば「説明責任を果たせ!」を他人を指弾したり、攻められた方は「記者会見で説明したから、説明責任を果たした」などと答える、へんてこな事態が生じた。記者会見の席上で30分間、頭を下げて、意地悪な質問にも耐えたから「責任は果たした、あとは無罪放免だろ」という理屈は、明らかに英米のAccountabilityの概念とかけ離れている。

じつは、AccountabilityとResponsibilityとは、「命令責任」と「実行責任」の区別に対応している。前者は命じたことへの責任で、後者は最後までやり遂げることへの責任である。Accountableな人は承認したり、NOといったりする最終権限を持つ。他方、Responsibleな人は、実行に関する権限や判断をある程度、まかされる。こう理解すると、両者の違いはすっと納得できよう。

え? すっと納得できない? では例を挙げよう。今日は、お母さんの誕生日である。お父さんと、二人の子ども(姉と弟)は、お母さんに感謝するため、バースデーケーキを内緒で買ってきてプレゼントしようということになった。お父さんはお財布を出して、小学生の息子に、街のケーキ屋さんから買ってこい、と指示する。息子はしかし、どんなケーキを選んだらいいか分からない、という。すると中学生の娘が、お母さんはこの間、タルトタタン(リンゴのパイの一種)を見て、美味しそうねえといっていたから、あれがちょうどいいんじゃない、という。そこで息子はお札を握りしめて、ケーキ屋さんまで走って行く。

ところがしばらくたって、息子から父に電話が入る。「たいへんだ・・ごめんなさい、お父さん!」という。「何だ。どうした?」「あのね。道でうっかりしてケーキの箱を落としちゃったの。箱をちょっと開けたらグチャグチャになっていて・・どうしよう。」「どうしようって、落としたものはしかたがない。店に戻って、もう一つ買ってきなさい」「お金は?」「あとでお父さんが払いに行く。念のため、店に名前と家の電話番号を書いておいてきなさい。お父さんからもお店に電話しておくから」「わかった・・。」

息子が神妙な顔でケーキを持って家に帰ると、父親は落としたときの状況を問いただす。どうやら、スマホのゲーム画面に熱中しすぎて、近づいてくる自転車に気づかなかったらしい。危ないじゃないか! ケーキならともかく、自動車だったらお前の命が危ないんだぞ! 今度から歩きスマホは厳禁だ、と言い渡し、息子はシュンとなる。

かくて、すったもんだはあったが、夕食の後で、娘と息子はかくしておいたバースデーケーキを取り出し、驚いているお母さんの前に差し出す。お母さんはよろこんでロウソクの火を吹き消し、お皿とナイフを取り出し、紅茶を入れて皆に配る・・。

さて、この話のRACIチャートは以下のようになる。

「プレゼントを買う」アクティビティについては、知恵を出した(C)のが姉、承認してお金を出した(A)のが父、店に買いに行く作業をした(R)のが弟、そして(時間差はあるが)結果を知らされる(I)当事者が母だ。

次の、ケーキを運ぶ最中のトラブルについては、ケーキを道に落とした弟は店に戻って「買う」という作業を完遂する責任(R)を負う。本当は、重大な過失なのだから、お金も自分で弁償する義務がある。もし高校生だったら、父はそう言っただろう。しかし小学生では経済的にも責任能力がないので、父が再度お金を出して事態を収拾する(A)。ただし、父はトラブルの再発防止策を息子に指示する。

バースデーケーキを取り出して祝うのは、姉と弟の仕事だ(R)。母はうれしいサプライズに驚く(驚いてみせる)役柄を演じる(I)。ただしお皿やナイフを出して切り分けるのは母だから、まあ実質的な仕事も分担しているので、あえて(+R)と表記した。このアクティビティには判断もコストも伴わないので、とくにAccountableな役割がないことも注意してほしい。

日本語の「責任」には、「責めを任ずる、になう」という意味が含まれ、どこかネガティブなニュアンスがある。英語のResponsibleはもう少しポジティブで、仕事を完遂する義務を負うかわりに、仕事上の問題解決に関する判断の権限を任されている。では、Accountableは何かというと、仕事の結果生み出される価値と、その仕事に投入するコストや時間や資源とのバランスを評価し判断する権限を持っている。つまり、仕事上の結果が生み出すアウトカムについて、賞賛も責めも引き受ける、ということだ。

Accountableな人は、実質的な仕事を誰かに任せて、Responsibilityを委譲することができる。しかし、結果に対する賞賛を受ける権利、責めを受ける義務は自分の元に残る。これを権限委譲の原則と日本語では呼ぶ。結果への権利を持つからには、委譲して任せた相手の仕事ぶりをちゃんとウォッチして、自分の意図したとおりに仕事してくれるような仕組みをつくらなければならない。これゆえ、Accountabilityを「結果責任」とか「監督責任」と訳す人もいる。わたしはかつて「面目責任」と訳したらどうかと考えた。だが、今は「命令責任」と「実行責任」が分かりやすいと思うようになった。

独立した権限を持つ人が、自分の利害に沿って行動するように仕向けることを、『ガバナンス』と呼ぶ。つまり、Accountableな人は適切なガバナンスを行う義務がある訳だ。逆に言うと、ガバナンスの仕組み作りを怠ったら、不作為や放置の責めを受けるべきである。つまり、「そんなことは自分が知らぬ間に担当者がやったことだ」などという弁解はきかない、ということである。

ま、ここではRACIチャートの説明が目的だから、AccountabilityとResponsibilityを明確に分けたが、英語の実際の場面では、似たような意味で使われていることも案外みかける。ただ、いずれにせよ、仕事のアウトカムをもとに人を評価したり責めたりする際には、その人が自分から行った決断や行為をもとにすべきだと、わたしは考えている。何の権限もなく、ただ命じられたことだけを実行する人、あるいは、自分の決断や行為に無縁な外的環境によって結果を左右される立場の人は、結果の責めを負わされるべきではない。より責められるべきは、命令した側である。アカウンタビリティというカタカナ言葉が普及すると共に、こうした原則への理解も広まってほしいと、切に願う。

→「革新的生産スケジューリング入門」にもどる

サービス、『感情労働』、そしてプロジェクト・マネジメント (2011/08/18)

「経済のソフト化」が言われ、「サービス・サイエンス」という新学問が提唱される今日においても、肝心な「サービス」の定義や中身はなかなか定まらない。なぜ、サービスをめぐる議論はかくも混乱するのか。前にも書いたとおり、サービス業とは「リソース提供ビジネス」であり、物質的なリソースあるいは人間系リソースの利用権・占有権を売るビジネスではないか。通信インフラや鉄道輸送などの物質的リソースについての機能は工学的に明確なはずである。また人間系リソースの提供にしても、知識労働(弁護士や通訳など)ないし肉体労働(整体師や溶接工やら)の役割は明瞭なはずであり、多くは資格制度も付随している。

それなのに、なぜかしばしば、ノードストローム(米国の高級百貨店=物販業)やディスニーランドや銀座の高級マダムの接客術みたいな要素が、サービスをめぐる議論の俎上にのせられる。お客様の「おもてなし」や、要望への「気づきの心」が声高に求められるのはなぜなのか。

そこには従来見過ごされていた、あるきわめて重大な種類の労働が関わっているからである。それは『感情労働』である。

感情労働という概念は、'70年代アメリカにおいてConstructivismと呼ばれる社会学研究の中で提唱された(Constructivismは「社会構成主義」ないし「社会構築主義」と訳される)。口火を切ったのはホックシールドいう学者で、その仕事は『管理される心―感情が商品になるとき』という著書にまとめられている。感情はふつう、それが喜びであれ悲しみであれ、私生活において適切に表出し、互いに贈り合うことで、人間関係を円滑に成り立たせる機能を持つ。つまり、感情とはプライベートな社会関係において必要不可欠な資源(リソース)なのである。ところが現代社会では、この感情が商品化され、仕事の領域でも使われる。サービス業の従事者は、その仕事の一環として感情を制御することや、顧客に「感情の贈り物」を提供することを求められる。これが「感情労働」である。

ホックシールドが研究対象とした一例は、航空会社のフライト・アテンダントだった。業務としてひんぱんに感情操作を求められるこの職種では、労働強化は労働者の情緒障害と自己疎外を招く、とホックシールドは警告した。彼女の研究に続いて、ショット、ケンパーなど気鋭の社会学者達が、感情の社会学とも言うべきこの分野に入ってくる(ここらへんの事情については、中川伸俊氏の「社会構築主義と感情の社会学」という論文−以前はネットで公開されていたが現在はリンク切れになっている−によって勉強させてもらった)。

ところで、何でわたしがConstructivismなどを勉強しているかというと、プロジェクト・マネジメント研究に関係するからである。毎年夏に欧州の主立ったPM研究者が集まるEDEN PM Seminarという会議があり(今年もちょうど今週、仏Lilleで開催中)、3年前にそこで知ったからだった。欧州のPM研究は、方法論を徹底的にやるのが特徴で、ただ単にアンケート調査やケース・スタディをしてみたらこういう結果になりました、というだけでは研究と認められず、いかなる理論的枠組みで、なぜこのような方法をとったのかが厳しく問われる。そこに登場するのがConstructivismやPositivismやCritical Theoryといった理論で、様々なプロジェクト(それ自体は各々ただ一度限りの社会現象である)を、どう把握し分析するかの導きとなるのである。日本の、実務的だがある意味ナイーブなPM研究との違いに驚かされる。

話を元に戻すが、感情は人間が「生まれつき自然に」持つのではなく、社会的に訓練され構成されるものである、というのがConstructivismの立場だ。そして、社会的場面に応じて、適切に感情を表出/制御するべく、人々を動かしていく(たとえば社長による深刻な訓話の最中に笑い出したりしない、といったように)。これを社会の『感情規則』と呼ぶ。

そして、世の中には、感情を相手に応じて制御しなければならないタイプの労働がある。これが感情労働なのである。ホックシールドはフライト・アテンダントを研究したが、その著書の翻訳者である石川准氏は、看護師の感情労働を例に挙げている(わたしの長年の友人である彼は、全盲の社会学者であり、また天才的プログラマーでもある)。たしかにナースの仕事は、知識労働もあり肉体労働でもあるが、同時に絶え間ない感情制御を伴う労働でもある。看護師たちは感情を酷使されている。と石川氏は言う。ちなみに看護師には喫煙者が多いと言われているが、喫煙の害を誰よりもよく知っているはずの彼女たちが喫煙に向かうのは、このような仕事のストレスが生むのかもしれない。

感情労働には、感情を抑える仕事と感情をつくる仕事の両方が混じっている。これを職業的に求められる職種は、CAやナースだけではない。たとえば、俳優もそうだ。そして、あらゆる業種をまたいで、広く感情労働が必要な職種がある。営業職だ。

セールスの現場はまさに、感情労働のかたまりである。相手にあわせ、相手を不快にせず、しかも相手を自分に都合良く誘導しなくてはならない。そのために必要な感情の制御はかなり高度なスキルであるし、またそのことが営業マンの消耗とストレスの原因ともなっている。

セールスマンの感情労働を見事に描いたマンガに、業田良家の「ゴーダ哲学堂」がある。「オレってまるで、ロボットじゃん」と、その登場人物は言う。実際彼の姿はスーツを着たロボット風に描かれている。理不尽な客のワガママにぶつかると、彼は「感情制御装置」のキーパネルをとりだし、『笑』のスイッチを押しては「ハッハッハッハッ。冗談きついなぁ店長さん。」と笑顔を作り、『哀』を押して「かんべんしてくださいよ〜〜。」と泣き落としにかかるのである。ただ、『怒』のボタンはひどく小さく、押しにくいようにできている。そして、「感情全テノボタンヲ、強ク激シク、毎日ツカワナケレバイケナイ」と独白するのである。

以前「新しい販売マネジメント思想こそ、競争力再生の要点である」に書いたように、現代日本の成熟市場においては、営業とは顧客ニーズの創出と供給側のコントロールを同時に行う“きわめて高いインテリジェンスを求められる仕事”になっている。それに加えて、この感情労働だ。今日の競争力のかなりの部分が営業にあるにもかかわらず、これをリードする思想は成熟していない。その理由は、「感情労働」という知識労働でも肉体労働でもないあたらしいカテゴリーの概念を、きちんと認識していないためである。概念がないから、教育訓練の方法論もない。パフォーマンスの尺度もない。これで改善をマネジメントできる訳はない。

そして、もう一つ、感情労働が重要な役割を占める職種がある。それがプロジェクト・マネージャー職だ。わがままな顧客と感情をすり合わせ、疲弊したチーム員を慰撫し、居丈高なくせに不安そうな上司には、信頼感を持たせる。これら感情を素早く切り替えて表出し、なおかつ計画やら報告やらにも気を配らなければならない。プロマネが世にも大変な職種である理由は、このような感情労働のレイヤーが、他者にも自分にも見えていない(だからその報償も得られない)ことにあるのではないか。

わたしは、知識労働も肉体労働も感情労働も、別に上下や貴賤はないと考えている。社会学者達は「商品化される心」というタイトルからみて、感情労働にネガティブな視線をなげかける傾向があるようだが、どんな労働だって、それが過重で無報酬だったら、人を壊していってしまうと思う。一定のニーズが社会の中にあるのだから、感情労働にもちゃんとした地位を与えればいい。感情労働に問題があるとしたら、人がそれを認識しないまま、当然のサーヴィス(無料)として「感情」のリソースを浪費してしまう点にある。プロマネ達がみんな疲弊してしまわないためにも、マネジメント業務の中に感情労働のスキルと価値があることを、皆もっときちんと意識すべきだと思うのである。

→「革新的生産スケジューリング入門」にもどる

『プロジェクト・アナリスト』はなぜ必要か (2014/12/10)

わたしが「プロジェクト&プログラム・アナリシス研究部会」を立ち上げたのは、3年半ほど前のことだ。2011年の5月、まだ東日本大震災と原発事故の余波がさめやらぬ頃で、毎日、小さな余震におびえ、計画停電という名の不便を皆が強いられていたときだった。スケジューリング学会会長(当時)の八巻・静岡大教授と、慶応大学の松川教授のご支援をいただいて、隔月に慶応三田キャンパスで勉強会を開く、今のようなスタイルに落ち着いたのはその年の秋頃だったと記憶する。第1回目は、発起人として、「リスク確率にもとづくプロジェクト評価と合理的意志決定の基準」という基調講演をした。内容は、その前年に出した自分の学位論文が中心で、数式だらけのOR的研究だが、なぜこんな研究部会が必要なのか、どうして長ったらしくて聞き慣れない会の名称をつけたのか、についても触れている。

それは、『プロジェクト・アナリスト』という職種の確立が必要で、そのためにはプロジェクト価値分析手法の研究が喫緊の課題だと信じたからだ。

設立趣意書には研究部会の目的として、次の三つの項目を挙げた:

3年たった今、研究部会の活動を通して、これら目的の実現に少しでも近づいたかというと心許ないが、目指しているものは間違っていないと、今でも思う。プロジェクトには、第三者としての専門家であるアナリストが必要である。プロジェクトの上位概念であるプログラムにも、しかり。アナリストの仕事は、プロジェクトやプログラムの計画や遂行状況を客観的に分析し、その価値とリスクを評価し、進めるなり止めるなり(あるいは強化するなり)の提案をマネージャーおよび経営者層に対して、行うことだ。

なぜ、第三者が必要なのか? 経営者と、プロジェクト実行の当事者であるプロマネがいれば、意思決定には十分ではないか。プロマネ以上に、そのプロジェクトの全体像について詳しく理解しているものがいるだろうか。経営者以上に、その組織における判断に適任な者がいるだろうか。だとしたら、なぜ、知識においてはプロマネに劣り、判断において経営者を超えられぬ第三者をつれてこなければならないのか。そう、思う人も多いだろう。

その理由は、「プロジェクトは賭けである」からだ。大きな労力と、費用と、時間とを投資した賭け。それをやりぬくには、夢とパッションが必要だ。だから良きプロマネは、例外なしに情熱の人である。かりに見かけはクールで冷静でも、内なる確信と熱意を秘めている。そういう人でないと、大きなプロジェクトは、やり通せない。つまり、プロマネとは職業的楽天家であるということだ。

そして『賭け』である以上、失敗するリスクもある。誰もが絶対成功するなら、それは賭けとは言わぬ。先の見えている、ただの日常業務に過ぎない。十分に見通せないから、リスクがある。

リスクのある使命に、楽天家であることを職業的に義務づけられている人が任命されたら、どうなるか。答えは簡単である。「何とかやり抜きます」という発言だけが、かえってくる。「この仕事はやる意味がありません。止めさせてください」とは、口が裂けても、いえない。それはギブアップ宣言だからだ。つまりプロジェクト・マネージャーとは、自分で決して仕事を止められない職業なのだ。

止める・止めないといった大げさな話でなくても、同じだ。プロジェクトがある段階まで進んだとしよう。いつ、その仕事は完成するのか。完成したときにコストは予定内に納まるのか。そう、経営者が問いかけたら、情熱を持ち自信家のプロマネほど、楽天的な答えを返す。大丈夫です、今はちょっと遅れているけれど、かならず予定通りに終わらせます。予算だって、きっとプラスにして見せます−−。もし同僚が、前の類似プロジェクトではこれこれのトラブルがあったから、同種のリスクに気をつけた方がいい、と進言したとしても、プロマネはこう言い切るだろう:「自分だったら、そんなドジは踏まない。」

これが、有能で責任感の強いプロマネ達の危険性なのだ。彼らの元では、プロジェクトの問題は最後の段階にならないと表に出ない。能力の低いプロマネが、プロジェクトをひどい状況に陥れている場合、危険は誰の目にも見えて明らかだ。一日も早く交代させて、プロジェクトを立て直すか、いっそ中止させるべきだと、皆が思う。だが優秀なプロマネが多いほど、組織は大きなリスクという爆弾を抱え込むことになる。リスクの一部は押さえ込んでくれるかもしれぬ。だが全部は無理だろう。

うまくいっていないプロマネを交代させ、意義の薄いプロジェクトをキャンセルするのは、本来、プロジェクトの上位に位置するプログラム・マネージャーの仕事だ。もし、そういう人が組織にいるならば、だが。しかしまあ、わたしの知る限り、ほとんどの日本企業には、そんな役職者はいない。民間企業のみならず、政府官庁にも地方公共団体に外郭団体にも、まず、いない。

その結果、何が起こるのか。わたし達はもうそれを十分知っている。誰も使わぬ空港、誰も通らぬ高速道路が、それだ。民間企業の中にも、作ったが使われぬ情報システム、開発したが売れない新製品などがごろごろしている。それに投資したお金も労力も、まったくリターンを生まない。お金の使い方には、「生きた使い方」と「死んだ使い方」があるが、こうした失敗プロジェクトは明らかに後者である。後には借金が残るだけだ。

だから、第三者による冷静なプロジェクト評価が必要なのである。そのための専門家を、企業も、官庁も、社会も、必要としているのではないか。

わたしの働くエンジニアリング業界では、プロジェクト・マネージャー(PM)以外に、チームの中にプロジェクト・コントロール・マネージャー(PCM)という職種を置く。PCMはプロマネを補佐する立場で、プロジェクトの三大要素:コストとスケジュールとスコープについて、ベースライン計画を作成し、進捗と出費を集計し、予実管理を行う職種だ。通常、経営者に対する報告は、全体の責任者であるプロマネが行う。

ところで欧米企業の中には、このPCMが直接、プロマネとは別に、経営者に報告をあげるシステムをとっているところがある。つまり、プロマネとPCMから、二重に報告を受ける訳だ。なぜこんな仕組みを作るのか。それは、計量管理の専門家であるPCMに、プロマネの情熱や主観のバイアスをはずした、客観的な状況報告をしてもらうためだ。こうして経営者は複眼でプロジェクトを見るのである。

複数の視点から立体的に物事を見る。これは”Structured Approach”と呼ばれる態度の一例であり、欧米人はこのアプローチにたけている。とくにイギリス人は、客観的な第三者をつかってチェックするのが好きだ。一種の三角測量であろう(人によっては、いや、あれは英国文化の根強い人間不信が生み出した悪弊である、と主張するかもしれないが)。

ただし、プラント業界におけるPCMには、欠けている面がある。それは、プロジェクトのコストは集計するが、ベネフィットは評価しない、という点である。今作っているプラントが、完成後、誰にとってどのようなベネフィットを生み出すのかは、PCMの職務範囲の外だ。だが、コスト(費用)を見てベネフィット(便益・効果)を見ないのでは、結局、経営判断において半面が抜けてしまうではないか。プロジェクトは賭けであり、投資である。だったら、投下費用に対するリターンがあって、はじめてその価値が測れるはずだ。

念のために書いておくが、ベネフィットとは、プロフィット(利益)ではない。長年、受注型ビジネスの世界にいると、この両者の区別が分からなくなってしまいがちだが、それは最終ユーザーの視点を忘れてしまうからだろう。プロジェクトは、何らかの施設や仕組みを作るために実行される。もう少し抽象化した言い方をすると、プロジェクトは、組織がなんらかの『能力』を得るために行うのである。工場ならば生産能力を得る。新製品ならば、市場開拓能力を得る。ベネフィットとは、こうして得られた能力の価値を表している。

では、通行料を取らない、普通の橋をかけるベネフィットは? 無料なのだから、何も価値を生み出さないではないか? −−そんなことはない。交通工学によれば、地域間を行き来する交通量(トリップ数)は時間距離の2乗に反比例して増大する。橋ができて近くなれば、交通が増え、それは経済活動や通勤・通学などの社会的便益を生み出す。そしてそれは、きちんと計算できるのである。

もちろん、プロジェクトの便益は、そうした金銭で換算可能なものばかりではない。プロジェクトを通して得られる経験値とか、人材の成長とか、無形の便益もいろいろある。それら便益を総合し、投下する費用・時間との対比を通じて、プロジェクトの価値が評価できるのである。そして、このようなプロジェクト価値評価を客観的に行う専門職として、『プロジェクト・アナリスト』が望まれるのだ。

ところが、現在のプロジェクト・マネジメント学には、この価値評価理論が欠けている。せいぜいあるのは、金融工学におけるDCF法によるNPV・IRRとか、さらにCAPM理論やリアル・オプション理論だが、あいにくプロジェクトのダイナミクス(動力学)や内部構造までは、切り込む力が弱い。そもそも、金銭面しか測れない。だから、プロジェクト価値評価の研究が必要であり、それがために研究部会を立ち上げたのである。

以前も書いたとおり、プロジェクトの成功を、「スコープ・コスト・スケジュールを満足させたか」だけで測ることに、わたしは基本的に賛成しない。それは成功の一部でしかない。本当の成功というのは、「プロジェクトが大きな価値を生み出すこと」であるはずであり、プロジェクト・マネジメントの仕事とは、「プロジェクト価値を最大化すること」でなければなるまい。プロジェクト・アナリストの仕事は、それを助けることなのである。プロマネの仕事を経営者の仕事にたとえると、プロジェクト・アナリストの仕事は証券業界のアナリストにたとえられる。自分でチームを統率し実行するのとは、別種の能力がそこには求められる。

今、わたし達の社会は、経済の低成長に悩んでいる。GDPを押し上げるには、国内投資が必要である。民間企業が国内に投資しないので、公共投資がそれを引っ張るべきだという議論がある。経済成長とは、お金が貯まることではなく、お金が回ることだからだ。だが投資には、生きたお金の使い方と、死んだ使い方がある。車の通わない橋、旅客の来ない空港をいくら作っても、そんなプロジェクトには「価値がない」。しかし、現在の経済理論は、その区別を無視しているように思える。あるいは、うまく区別できずにいる。

わたし達の社会が、投資を有効に行うためにも、プロジェクト・アナリストの職域確立が急務だと、わたしには思えるのである。

→「革新的生産スケジューリング入門」にもどる

プロジェクト・ファイナンスとは何か (2015/02/16)

プロジェクトは投資である。

どんなプロジェクトも、最初に労力や費用を投下して、最後に金銭や無形の価値を得る、という構造になっている。新製品の開発であれ、新工場の建設であれ、あるいは新オフィスへの引っ越しだって、そうだ。受注型プロジェクトの場合はもっとはっきりしていて、プロジェクトの最初には見積・設計提案などが必要で、無事受注し完了すると代金収入を得られる構図になっている。

そして、投資には労力と金がかかる。労力だって、社内的にはお金が動かないように見えるかもしれないが、経営者から見れば人件費の消費である点に変わりはない。われわれの経済では、純粋に無料なものなど、ほとんど存在しない。だから、プロジェクトは金銭を投下し最後に価値を得る、投資行為だとみることができる。

さて、あなたは何かとっておきの素晴らしいプロジェクトをはじめることに決めた。ただし、手持ちの資金だけでは不足である。誰かからお金を借りる必要がある。世の中には一流の金融機関から街金まで、さまざまなプロの貸し手がいるし、あるいは親戚友人から借りるという手もあるかもしれない。その際、どのような条件が借り手のあなたにとって一番好ましいだろうか?

答えはいうまでもない。(1)金利が安い、という条件が一番であろう。しかし、それだけではない。よく考えてみると、お金を借りる際の条件には、他にもいろいろあるのだ。たとえば、
(2)返済期間が長い、というのも魅力的だろう。3年返済と10年返済では、毎年の負担額がまったく違う。多少金利が高くても、返済期間が長いのはありがたい条件だ。

(3)金利が固定、というのもある。住宅ローンなどでは、固定金利か変動金利かを選ぶ場面が出てくる。返済期間が長くなると、将来の利率が不確定だ。いまは不況の上に「異次元の金融緩和策」のおかげで金利は比較的安いが、将来インフレが起きて利率が跳ね上がる心配も、ないとはいえない。だったら、当面の利率は多少高くても、固定金利を選べる方が好ましく見える。

他には? (4)連帯保証や担保が不要、という条件があるなら、(1)(2)(3)の諸条件がひっくり返るくらい、非常にありがたいだろう。何であれ、事業には将来の不確実性がある。必ず、絶対に成功できます、とあなたは自分で信じ人にも約束するだろう。だが、何が起きるか分からないのがこの世間である。プロジェクトが失敗したときは、手元に何の果実も残らず、ただ借金が残る。その借金のカタとして、家や資産をとられたり、あるいは連帯保証人に迷惑がかかるような事態は、誰だって避けたい。多少金利が高くても、無担保で借りられるなら、それにこしたことはあるまい。

そもそも、担保に差し出せる資産があるくらいなら、別に金なんて借りる必要はないじゃないか。資産がないから、プロジェクトに投資して、資産を増やそうと試みているのだ。ならば、いっそのこと、「プロジェクトという無形の資産」を担保にして、金を借りられないか−−じつはこれこそ、『プロジェクト・ファイナンス』という概念なのである。

今度は、視点を貸し手側に換えてみよう。あなたは今度、金貸しである。誰かに金を貸すとき、あなたとしては何を根拠に、お金を貸せるだろうか。金融業というのは、まるで労せずに利息だけを取っていく、ひたすら楽な商売だと思っている人も世間には多い。しかし、それは誤解である。「銀行家の不眠」という諺もイギリスにあるくらい、心配の絶えない商売なのだ。なぜなら、貸した金がちゃんと全部返ってきて、はじめて成り立つのが、金融というビジネスなのだから。だから、貸し手としては、借り手がちゃんと返済してくれるかどうかを、まず問う。その根拠となる条件は何か。

第一の条件は、(1)担保で貸す、である。担保さえ押さえておけば、相手が万が一夜逃げしたって、貸した金額分はほぼ回収できる。わたしが住宅ローンを借りるとき、まず家を担保に差し出さなければならない理由も、また家の価格分には満たない金額しか貸してくれないのも、このためである(家は住み始めたら中古になるから担保価値は割り引かれるのだ)。連帯保証をとる、というのも担保に準じている。取りはぐれなくする工夫だ。

第二の条件は、(2)相手への信用で貸す、である。相手が返してくれると、信用する。親戚友人など、個人間の融資の多くはこれだ。また、企業に対する融資も、一段進むと、このレベルになる。企業の信用力にはいろいろな要素があるが、最大のポイントは、きちんと毎年利益を計上していることだ。金利元本の返済は、黒字だろうと赤字だろうと払わなければならない(赤字だと払わずにすむ法人税とは、その点が全く異なる)。だが赤字が続けば企業が倒れる危険性がある。そうなれば貸した金を回収できなくなる。さらにいうと、企業は市中銀行から借りる以外に社債を発行して金を借りる手段もある。この際に、貸し手の目安となるのが、格付け機関による『格付け』である。格付けこそ信用力を実体化したものに他ならない。

そして、第三の条件が、(3)事業への信用で貸す、である。相手が生まれたばかりの会社で、過去の経営実績もなく、信用力も評価しようがない。連帯保証人もいない。これが全くの新技術・新分野なら、ベンチャー・キャピタル(VC)の出番だ。しかし、相手が取り組もうとしているのが、ある程度、確立した分野のプロジェクトの場合に用いられるのが、プロジェクト・ファイナンスという手法なのである。

たとえば、ある新興国が、地域への電力供給事業に取り組みたいと考えている。工業化と発展のためには、まずインフラとして発電所が必要だ。だが、それを自前で建てる資金がない。一方、ここに先進国の事業会社がいて、あの国のあの地域には電力ニーズが潜在的にあるな、と考えている。投資したいが、相手国側の協力も必要である(通常はインフラ事業ゆえに現地法人の設立が必要だ)。それに、全部を手金でやるのではなく、借金をして、レバレッジをきかせたい。ただし、新興国ゆえに、将来には不確実性もある。プロジェクトが失敗したときに、その借金を全部かぶるのはごめんだ、と考えている。もちろん発電は確立した技術分野なので、VCの出番ではない。

そういうときに、頼りになるのが、ECA(Export Finance Agency)と呼ばれる準政府機関である。ECAは先進国が自国産業の輸出促進のために設立する機関で、その業務にはいろいろあるが、プロジェクト・ファイナンスへの取り組みもその一つだ。その代表格が、日本の『国際協力銀行』(略称JBIC)という存在である。JBICは現在のところ、北米・欧州・韓国などのECAの中で、質量ともにプロジェクト・ファイナンスの最大の融資者なのである。そのことを、日本人はもっと知って、誇りを持っていい。

わたしが主催する「プロジェクト&プログラム・アナリシス研究部会」では、さる1月28日に、この国際協力銀行の経営企画部長である内藤様を講師に迎えて、初心者にも分かるプロジェクト・ファイナンスのお話しをうかがった。だからわたしがここで書いていることも、大部分は内藤部長の講演の聞き書きを元にした、受け売りの知識である(汗)。

さて、プロジェクト・ファイナンスは、通常の企業融資(コーポレート・ファイナンス)とどこが違うか。その最大のポイントは、「当該プロジェクト事業を専ら目的とした特別目的会社を設立し、そこに対して融資をする。プロジェクト事業が失敗した場合でも、返済請求権を出資元の親会社に遡及(Recourse)しない」という点だ。

図を見て欲しい。通常のコーポレート・ファイナンスでは、事業会社は複数の事業を営んでおり、基本的にはその信用力をベースに融資する。新興国に現地法人を設立して取り組んだ発電プロジェクトが途中で失敗した場合でも、返済請求は出資者である事業会社に遡及されてくる。通常は、そのために「親会社保証状」を要求される(つまり連帯保証である)。あるいは逆に、その新興国の政府自体に、保証人になることを要求するケースもある。これをソヴリン・ファイナンスとよぶ。ソヴリンSoverignとは国王とか主権者のことだ。

ところが、プロジェクト・ファイナンスでは、現地に設立された特定目的法人(これをSpecial Purpose Company = SPCと略す)に融資する。そのベースとなるのは、当該プロジェクト事業の信用のみである。これが失敗した場合、貸し手はお金を回収できなくなる。だから、貸し手としては、いやでもプロジェクト内容の評価に真剣にならざるを得ない。その発電事業の採算性はどうなのか。立地・市場性はあるのか。電力価格(しばしば政策が介入する)は適正か。建設コストやスケジュールは妥当か。設計・調達・建設(EPC)を請け負うエンジニアリング会社は、きちんとしたプロジェクト遂行能力と品質を担保できるのか。どういう契約でEPCを発注するのか。発電所の運転操業は誰がどうやるのか。送電網は誰が用意してどういう条件でつなぐのか、etc., etc...

おわかりだろうか。これは「プロジェクト価値評価」業務そのものである。そして、貸し手が一切を合意・承認できる計画条件でない限り、融資は行われない。借り手にとっては、ある意味、うるさい限りだ。おまけに、金利は、通常の融資より少し高い。当然のことだろう。貸し手は貸し倒れのリスクを、その金利に含めざるを得ない。

ここで、ちょっと簡単な計算をしてみよう。今、あなたは裕福金満な貸し手である。あなたは、担保能力のない新興国の新設会社に、自分の手金を融資する。その金額をCとしよう。返済時には、利息として利率Rを加えた金額を返済してもらうことにする。つまり、返ってくるお金は (1+R) Cで、融資による純粋な利益は、差し引き RCとなる。では、あなたは利率Rを、いくらに設定すべきだろうか。

もしこの新設会社のプロジェクトが失敗したら、あなたはCだけ損失を被る。いま、このプロジェクトが失敗するリスク確率をrとしよう。すると、rC が、あなたが潜在的に抱えている貸し倒れ損失金額の期待値だ(これをリスク・エクスポージャーという)。また、あなたが得られる利益の期待値は、成功する確率を乗じた(1-r)RCということになる

である以上、あなたとしては、利益の期待値が、損失金額の期待値を上回るように、利率を設定しなければいけないことになる。

(1-r)RC > rC

この式を変形すると、次のようになる:

R > r/(1-r)

これが、あなたの設定すべき利率なのだ。この条件には、C(いくら貸したか)は一切現れないことに注意して欲しい。純粋に、相手のプロジェクトが失敗するリスク確率が問題なのだ。それがもし10%なら、あなたは0.1/(1-0.1) = 11.1%を、もし20%なら、0.2/(1-0.2) = 25%を、最低でも利率としなければならない。

現実には、金融機関は手金を融資するわけではない。そこで、実際の利率は、基準となる市中金利(たとえばロンドン銀行間金利LIBORなど)をベースに、自社の運用したい水準を設定した上で、上記のRの分を加算しなければならない。このRを、『リスク・プレミアム』と呼ぶ。そこでは、年間の貸し倒れリスク確率(年次デフォルト率)が問題となるわけである。

プロジェクト・ファイナンスでは、JBICなどECAだけでなく、民間銀行もシンジケートを組んで融資することが多い。より正確に言うと欧州系のECAは保証業務だけを行うので、必ず民間銀行が必要になる。そして、この種のファイナンス組成のためには、客観的な評価が必要だから、プロジェクト事業の専門家をはじめ、法務・財務・金融・国際関係など様々な専門家が世界中から集まって、協議交渉を続けることになる。言語は、当然ながらすべて英語である。期間も、半年や1年以上はザラだ。金銭をめぐる交渉は文字通り、切ったはったのツバぜり合いである。それだけ大変な仕事だが、そのかわり世界の一流の専門家とやり合えるわけだから、非常にやりがいのある仕事だともいえる。

先ほど述べた研究部会でも紹介された興味深い事実は、プロジェクト・ファイナンスの方が、じつは案外デフォルト率が低い、という統計である。Moody’sは約4,000件のプロジェクト・ファイナンスの実績を調べ(その中の約300件がデフォルトを起こした)、累積デフォルト率はMoody’sのBaa/Ba格付と同等であることを見いだした。しかも、年次デフォルト率の推移を見ると3年目から一貫して低下を続け、10年後にはシングルA格をこえている(!)。したがって、「プロジェクトファイナンスはリスク耐性の強い特別なコーポレート貸付である」と彼らは結論づけている。プロジェクト・ファイナンスの組成は通常より時間がかかるし、事業者に対してはあれこれと口を出して縛りが多いわけであるが、それがプロジェクト・ガバナンスのレベルを向上する効果を生んでいるのである。

ここでは、プロジェクト・ファイナンスという奥の深い世界の、とば口の一端を紹介したに過ぎない。しかし、それがプロジェクト客観評価に密接に関わっていることはお分かりだと思う。わたしがかねてから主張している、プロジェクトの価値やリスクを客観的に評価できるプロフェッショナル=『プロジェクト・アナリスト』の必要性も、このMoody’sの統計調査などから支持されているといえるだろう。JBICにご出馬いただくまでもないような通常の企業のプロジェクトでも、その価値や投資の正当性については継続的・客観的な把握が必要であり、きちんとしたガバナンスが重要である。そのような観点から、プロジェクト・ファイナンスの構造について、もっとみなが関心を持つべきだとあらためて感じた次第である。

→「革新的生産スケジューリング入門」にもどる


→「革新的生産スケジューリング入門」にもどる
サイトマップ
このページの冒頭に戻る

(c) 佐藤知一
e-mail: tomsato@rio.odn.ne.jp