カテゴリ:プロジェクト・マネジメント( 128 )

お知らせ:「オペレーションズ・リサーチ」誌に最適入札価格に関する論文を書きました

お知らせです。
日本OR学会の月刊誌「オペレーションズ・リサーチ」2015年7月号(http://www.orsj.or.jp/e-library/elcorsj.html#6007)に、

 「プロジェクト入札価格の決定問題
 ―競争入札における見積リスクと最適入札価格について―」

と題する論文を書きました。

一般に受注ビジネスの競争入札では、最安値を競います。しかし当然ながら、入札仕様書に書かれた条件だけでは正確にコストを見積もることができず、ある程度の不確実性(精度の問題)が残ります。そこにリスクがある訳ですが、対策のために予備費を積みすぎると、今度は値段が高くなって入札自体に負けるリスクが高まります。かといって値段を下げると、受注しても赤字になる可能性が大きくなる。このジレンマに解決はあるのでしょうか?

わたしのこの論文では、まず、一般に見積誤差は非対称で、プラス(コスト超過)の側にふれることが多いという傾向が、なぜ生じるのかを明らかにします。つぎに、競争見積状況下で対等なライバルに勝って、かつプロジェクトの期待利益を最大化できる入札価格があることをシミュレーションで示します。さらにオークション理論からみた入札のありかたを解説し、最後に、「ライバルと自分は互角である」という推測は、入札に何連敗したら見直すべきかを、数学的に示します。

多少数式も出てきますが、極力読みやすさに配慮した論文にしたつもりです。

なおこの雑誌は紙媒体ですが、Webからも記事を読むことができます。わたしの論文のURLは次の通りです。
 http://www.orsj.or.jp/archive2/or60-7/or60_7_374.pdf

ちなみにこの7月号は『プロジェクトの見積りと受注の科学』の特集で、責任編集されたのは文教大学の石井信明教授です(わたしのかつての同僚でもあります)。その石井先生の論文:「供給能力と受注量の最適化問題」は、わたしが以前このサイトで書いたエントリ「とれるだけ仕事をとってはいけない」 でご紹介した、プロジェクト&プログラム・アナリシス研究部会での講演内容を敷衍したもので、非常に興味深い論文です。入札と受注戦略に興味のある方は、ぜひ、あわせてお読みください。
by Tomoichi_Sato | 2015-07-30 23:00 | プロジェクト・マネジメント | Comments(0)

プロジェクト&プログラム・アナリシス研究部会(8月6日)開催のお知らせ

「プロジェクト&プログラム・アナリシス研究部会」2015年の第4回会合を、下記の要領にて開催いたします。

今回は久しぶりに、ITプロジェクトのマネジメントに真っ向から取り組みます。講師に元・三菱電機でソフトウェア生産管理を主導してこられた高根宏士氏をお招きし、IT分野のプロジェクトはどこに特徴があるのか、何が難しいのか、そしてどのようにしたら成功できるかについて、お話しいただきます。長年の経験に裏付けされた実践的な内容ですので、IT業界の方にも他業界の方にも、大きなヒントになると思います。

夏の暑い時期ですが、一夕、斯界の大ベテランを囲み、叡智に耳を傾け語り合うのも一興ではないでしょうか。


<記>

■日時:2015年8月6日(木) 18:30~20:30

■場所:三田キャンパス・北館会議室2(1階)(定員:28)
http://www.keio.ac.jp/ja/access/mita.html
キャンパスマップ・【1】

■講演タイトル:
経験から見たITプロジェクトマネジメントの基本

■概要:
プロジェクトマネジメントの役割はプロジェクトの目的に向けて、関係ステークホルダー、特にプロジェクトチームの力を結集し、最大限に発揮させることです。そのためにはまず、プロジェクトの目的、およびその目的に向けてプロジェクトを推進するイメージを実感として作ること、次にこのイメージを関係者に伝え、イメージに対して、共通認識を作るためのコミュニケーションが肝要であると思います。この「イメージ」と「コミュニケーション」について、50年近くの経験から思っていることを述べてみたいと思っています。

■講師: 髙根 宏士 (元・株式会社三菱電機ビジネスシステム常務取締役)

■講師略歴:
・1962年 東北大学通信工学科卒業
・同年  三菱電機(株)入社
  以後20年以上にわたり、データ伝送装置開発、計算機応用システムの開発に従事。国鉄貨物操車場自動化システム、自動倉庫、電力系統システム、ビル管理システム、原子力発電所監視システムなどに携わる。
・1984年 三菱電機東部コンピュータシステム(株)
・1991年 三菱電機(株)に復職(ソフトウエア生産管理を担当)
・1994年 (株)三菱電機ビジネスシステム常務取締役
・1997年 (株)エム・ビー・システム副社長(兼務)
・2000年 (株)三菱電機ビジネスシステム顧問を退任
情報処理学会理事および学会誌編集委員長、プロジェクトマネジメント学会理事、東京農工大学講師を歴任。
2014年プロジェクトマネジメント学会から功労賞受賞。

著書:
 「ソフトウエア工程管理技法」 (ソフト・リサーチ・センター)1991
 「ソフトウエア外注管理技法」 (ソフト・リサーチ・センター)1994
 「ダブリンの風 ~日常の風景から見るプロジェクトマネジメントの機微~」(ソフト・リサーチ・センター)2004
 「ITプロジェクトにおけるソフトウエア外注管理」(ソフト・リサーチ・センター)2006 ほか

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(\1,000)は免除されます。

参加を希望される方は、確認のため、当日までに佐藤までご連絡ください。
なお、会場の人数に限りがあるため、できましたら早めにご連絡くださることをお勧めします。ご来場いただいても、立ち見になってしまう場合がありますので。

よろしくお願いいたします。


佐藤知一@日揮(株)
by Tomoichi_Sato | 2015-07-18 07:09 | プロジェクト・マネジメント | Comments(0)

プロジェクト・スポンサーシップが足りない

アメリカに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) プロジェクトを支援する」とは、リソース(配員や資金など)面で助けてやり、ステークホルダーにプロジェクト状況を見えるようにし、適切なプロジェクト・レビューと意思決定がなされるよう組織を動かす事を指している。
e0058447_19482827.gif

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

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

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

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

さいわい、プロジェクト・マネジメントという概念と知識体系が普及することによって、そうか、プロマネには、身につけるべきスキル・セットがあるのだな、という認識が進んだ。多くのSIerが社内でPMP資格取得を奨励したのも、こうした理由が大きい。こうした活動の結果、10年間で、PM論に対する認識はかなり普及したといっていい。また、社内レビューなどの制度的な前進もあって、赤字プロジェクトはある程度、減少したという調査結果もある。しかし、では業界の悩みは解消したかというと、わたしの聞く限りは、そうではない。

そして、なまじPM論の知識が広まったが故に、「プロジェクトの失敗は、プロマネのマネジメント能力不足である」という認識も、妙に広まってしまったように思える。つまり、問題解決を部下であるプロマネに丸投げする上司の体勢自体は、あまりかわっていないのだ。単にキーワードが、曖昧なる『リーダーシップ』から、舶来風の『プロジェクト・マネジメント』に昇格(?)しただけである。人によっては、PMの最大のポイントはプロマネのリーダーシップである、と論じて、わざわざ論点をプロマネ個人の資質に引き戻したりしている。

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

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

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

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

PMPの資格はほんとうに仕事の役に立つのか

昨年、勤務先でPMIの来訪を受け、同僚と共にインタビューに応じた。目的は日本におけるPMP資格取得の動向を探ることで、相手はいかにも頭の良さそうな30代の米国人であった。名刺を見ると、PhD、つまり博士号保有者であるむね書かれている。むろんPhDのほかにPMPも資格として名前の後ろに書かれている。

今さら説明するまでもないが、PMIはProject Management Instituteの略で、米国発で世界最大のグローバルPM団体である。日本にも支部はあるが、米国の本部が、世界中の数十万人の会員を統括している。PMIは元々1960年代に、プロジェクト・マネジメントに携わる人々が、PMという仕事もプロフェッショナル専門職として世に認めてほしい、との願いをもって結成された組織だ。現在のPMIは、通称『PMBOK Guide』(R)、正式には"A Guide to Project Management Body of Knowledge”とよばれるプロジェクト・マネジメント分野の標準書を発行しており(邦訳『プロジェクトマネジメント知識体系ガイド』)、それを元にしたProject Management Professional(略称PMP)の資格試験を主催している。

PMBOK Guideの初版が編纂されたのは’90年代の前半で、PMP試験も最初は米国に受験しに行かなければならなかった。しかしこの標準書と資格制度は非常に成功し、次第に世界中に広まることとなった。今では日本でも、日本語で、いつでも好きなときにPMPを受験できる。PMIはその後、他の資格試験制度もいろいろと設立しており、昨年3月の時点でPMIの資格保持者数は世界で60万人を超えている。また、PMBOK GuideとPMP試験が大当たりした影響は大きく、他の諸団体もきそって”xxBOK”というBook of Knowledge(知識体系)を発刊するようになった。わたしが知っているだけで、BABOK(ビジネス・アナリシス)、DMBOK(データ・マネジメント)、CMBOK(コスト・マネジメント)などがある。

その大成功した米国PMI本部のディレクターが、なぜわざわざアジアの辺境のわが勤務先などを訪ねてきたのか。たしかにPMIの法人スポンサーだし、インタビューに応じた同僚もわたしも、一応PMP資格は持っている。だが、わが社におけるPMP資格保有者など、(正確に数えたことはないが)数十名の下の方だと思う。日本だけで20万人以上いると思われるPMPの意見を聞くには、ずいぶん不適格ではないか。3桁以上のPMPを抱える立派な日本企業だって、IT業界にはいくつも存在するはずだ。

むろん、相手はそうした企業も回っているのだろう。だがエンジニアリング業界の話も聞きたいと思って、選んでくれたのかもしれない。質問の中には当然、「プロジェクト・マネジメントをビジネスの基盤としているエンジニアリング会社なのに、なぜPMP保持者が少ないのか」という主旨の問いもあった。わたしの同僚達はPMO部門に所属しており、(わたしも数年前までは同じ部署だったのでよく知っているのだが)PMP資格取得を社内で推奨しているのに、実際には受験者が少ない。

なぜPMP受験者が少ないのか。答えは簡単である。なくても、とりたてて仕事に不便がないからだ。海外のOil & Gas業界には、プロジェクト・マネジメントに関する一種のIndustry Standardが存在しており、発注者も受注者もそのことを承知している。これは一種の業界の慣習であって、特に何か決まった書き物はない。しかし、プロジェクトの入札書類には、必ずプロジェクトをこの業界標準に従った形で進めることが条件として義務づけられている。いわく、きちんとしたProject Execution PlanとProcedureを最初に作成すること、WBSを構築すること、レベル-2・スケジュールを作成してCritical Pathを同定すること、EVMSで進捗をコントロールすること等々、事細かく規定される。むろん、プロマネやPCM (Project Control Manager)やEM (Engineering Manager)など重要職は、本業界で10年以上の経験を有していること、などの要求もついているのが普通だ。

逆に、プロマネがPMP資格を有すること、などの条件がついているのは見たことがない。つまり、たとえPMP資格を持っていても、十分な経験がなく、上記の要求レベルでプロジェクトを回せなければ、役に立たないことを意味している。だから、あえてPMPを取ろうという人が出てこないのだ。

誤解しないでほしいのだが、わたしはPMP資格が無価値だ、などと言っているのではない。むしろ、社内に対しては、PMPも取ってないようでは恥ずかしいではないか、とのメッセージを発している。試験はたいして難しくない。基本的に、知識を問う選択問題である。多少、用語理解と模擬試験のために数ヶ月程度の準備はいるかもしれないが、パスする者は多いだろう。PMBOK Guideだって、読めば頭の整理にはとても役に立つ。たしかに用語は若干、我々の業界からずれているところもあるが、それは頭の中で翻訳しながら読めばいい。もし業界をまたぐ共通語を習得できれば、他の業界から、より良いPracticeを学ぶ機会もありうるではないか。

それでも、PMBOK Guideを勉強する人は少ない。わが同僚のA氏は皮肉って、こんなジョークをつくった:

若手 :「PMBOKくらい読んでおけよといわれたのですが、どんなことが書いてあるんでしょうか?」
ベテラン :「PMBOKなんて実務には何の役にも立たないよ。」
若手 :「そうなんですか。 で、どんなことが書いてあるんでしょう?」
ベテラン :「きみきみ、役に立たないものを、私が読んだことがあると思うのかね?」

勤務先を訪問された上記PMIのインタビューアーへの回答としては、それ以外に二つのことをあげておいた。一つは試験費用である。PMPの受験料は、社内では負担の一部を補助しているが、それでも他の日本の公的資格試験等に比べて、かなり高価である。もう一つ、日本語の翻訳も、いささか生硬でぎこちない。PMP試験はPCの端末に向かって行う形式だが、わたしが受験したときは、英語がデフォルトで、あるオプションを押すと、翻訳の日本語が表示される仕組みだった。しかし日本語が読みにくいので、わたしはずっと英語で問題を読んだし、後輩にもそれを勧めている。

まあしかし、これらのことは本質ではない。わたしがPMP試験について一番問題に感じているのは、じつはそれが知識を問う試験にすぎないことだ。以前から書いていることだが、能力とは知識や資質だけで決まるものではないと、わたしは考えている。個人の能力を構成する要素としては、知識・感覚(センス)・身体的スキル・創造性などがあり、これらをきちんとバランスし、かつ整合的・臨機応変に、組み合わせて活用できなければならない。だから、誰かの能力を評価するのはとても手間のかかる、難しい仕事なのである。これを、わずか数時間程度の、パソコンの前の応答だけで測ろうというのが、もともと無理なのだ。PMやPM補佐を10年近くやってきた者は、こうした矛盾点にそもそも違和感を感じるのだろう。

じつはちょうど昨年の同じ頃、わたしはGAPPS Initiativeの活動も手伝っていた。GAPPSとは、”Global Alliance for Project Performance Standards”の略で、プロジェクト・マネジメント分野の標準化問題を整理するために組織された、まったく非営利のボランタリーな団体である(URL http://globalpmstandards.org)。GAPPSは10年ほど前に、PM分野の巨頭たち数人によって、私的に結成された。世界には、米国のPMIをはじめ、欧州のIPMA (International Project Management Association)、豪州のAIPM(Australian Institute of Project Management)、日本プロジェクトマネジメント協会 (PMAJ)、英国APMなどPM団体がいくつもあり、それぞれが独自に標準や資格を制定してきた。その結果、2000年代に入ると、複数の標準・資格の競合や乱立といった現象がおき、実務家にとってありがた迷惑な状況が発生してきた。

GAPPSはこの問題をただすために生まれ、PMI・IPMA・AIPM三団体の元トップらが参加して地道に活動してきた。メンバーは世界中に分散しているので、基本的に年に3回集まって、Working Sessionで作業を進めている。昨年はそのうち1回を日本で開催し、JICA(国際協力機構)がホストを務め、PMAJが協力した。わたしもPMAJからのお声がけで、参加したのである。

GAPPSは、PM能力(コンピテンシー)とは、外的に現れた成果を基準に評価すべきだと考える。PMP試験のように、知識を基準とした(Knowledge-based)評価から、成果基準(Performance-based)のコンピテンシー標準への進化を求めると共に、各国のPM標準を相互比較し、アセスメント結果を公表している。その目的のために、結局、GAPPS独自のPM Standardを作成したのだから、なんだかN個の基準の整合性をとるために、N+1個めの基準を作ってしまった感もなくはない。が、少なくともその目的意識は、わたしも共感するところである。

そもそもマネジメント分野で標準とか資格とかに、どういう意味があるのか。わたしは東大で夏学期に週1回、プロジェクト・マネジメントを教えているが、今年の授業開始直後に、こんな質問を院生から受けた:

「Managementの再現性の取れなさ、うさんくささがずっと気になっています。『君にもできるプログラミング』と『君にもできるプロジェクト・マネジメント』という2冊のタイトルを並べてみると、後者の本に頼りなさを感じます。どうして理論が組み立てられているのに、現実の組織はこんなにもうまく機能せず、有能なリーダーはこんなにも稀なのでしょうか?」

なかなか本質をとらえた、鋭い、よい質問である。これはいいかえれば、「PMの標準なんて何の役に立つんだ?」という疑問だ。で、わたしは、こう答えた:

「世の中の技術や能力には、決定論的なものと、リスク確率の伴うものがあります。プログラミングは前者で、プロジェクト・マネジメントは後者に属します。これはたとえば、『君にもできる航海術』というタイトルの本を考えてみれば分かるでしょう。航海には、船の構造や気象学・海洋学といった専門的な知識も、GPSをはじめとする最新の測量技術も必要です。しかし、それらをみんなそろえたからといって、誰でもすぐ航海に成功すると思いますか? 学ばなければ、航海には出られません。しかし、学んだ後で、自分のものにする努力がなければ、いずれにせよ役には立たないでしょう。」

マネジメントの能力とは、たえず変化する環境の中で試されるもので、「知っている」ことと「出来る」ことの間には、大きな距離がある。こうしたことは、落ち着いて考えれば誰にでも分かることだ。にもかかわらず、知識を基準とする資格制度が、世界的に非常に成功してしまった。これは、今後は製造業より知財ビジネスと金融で経済を支えていく、という米国の国家戦略ともマッチしていた。PMP試験は、受験資格を得るためにも、また3年に一度の更新のためにも、『PDU』とよばれる一種の単位を取得蓄積することが義務づけられる。その制度的発明は、PDUビジネスという大きな周辺産業を生み出すこととなった。こうしてPMIは、みごとに渦を巻いて、多くのプロマネやプロマネ予備軍の人たちを引き込んだのである。とくにPMBOK Guideは、IT産業への福音として喧伝され、歓迎された。

そのPMIは、しかし、どうやら二つの悩みを現在かかえているように見える。会員数が思ったように増えないこと、PMPを維持しない人が案外多いことだ。だから日本まで、市場調査のために行脚にくるのだろう。

なぜPMPを維持しないのか? なぜPMBOK Guideに失望するのか? 答えは明らかで、本当にはプロマネ達の悩みを解決する助けにならないからだ。少しは、助けになる。だが知識は必要条件だが、十分条件ではない。そのことは多くの人がうすうす、気づいている。そしてさらにいえば、あらゆる業種、あらゆる形態と規模のプロジェクトに、共通にフィットする知識体系というものも、そろそろ限界に達してきているのだろう。抽象的すぎて、自分の実務に適用するにはコンサルを呼ぶしかない、というのでは、ちょっと不便である。

どうやらプロジェクト・マネジメント関係の標準は、一つの曲がり角に来ているらしい。そういう問題を議論したくて、次回の「プロジェクト&プログラム・アナリシス研究部会」では、PM標準に関する国際的なエキスパートである田島彰二氏を招いた次第だ。知識だけでは、プロジェクトは救えない。知識を超えた知恵を、われわれが出すには、どうしたらいいのか? できれば皆で、一緒に考えたいと思うのである。


<関連エントリ>
 →「それは知識ですか、スキルですか、資質ですか?」(2013-06-02)
by Tomoichi_Sato | 2015-05-25 20:30 | プロジェクト・マネジメント | Comments(0)

プロジェクト&プログラム・アナリシス研究部会(6月9日)開催のお知らせ

「プロジェクト&プログラム・アナリシス研究部会」の2015年第3回会合を、以下の要領にて開催いたします。

皆さんは国際標準化機構(ISO)が、2012年にプロジェクト・マネジメントの標準「ISO21500」を策定した、というニュースをご存じでしょうか。 彼らはさらに現在、その標準を拡張し、プログラム・マネジメントやポートフォリオ・マネジメント分野にも策定すべく検討作業を進めています。 島国の日本はいつも、国際標準化の分野で出遅れになりがちですが、この状況の中、長年にわたり積極的に活動してこられたのが田島彰二氏です。 田島さんはある意味、世界のPM業界・学会で最も名の知られた日本人だと言ってもいいと思います。
長年、IT/通信業界で活躍してこられ、現在は独立コンサルタントをされている田島さんの、本音を交えた独自の語り口にご期待ください。


<記>

日時: :2015年6月9日(火) 18:30~20:30
場所: 三田キャンパス・北館会議室2(1階)
    http://www.keio.ac.jp/ja/access/mita.html
    キャンパスマップの【1】

講演タイトル: 「組織のマネージャが備えるべき必須な(PM)コンピタンスとは」

概要:組織のミッション、ビジョンと戦略立案、その後の実践に必要なマネージャの能力とは。 具体的には、広い意味の組織に価値をつけるために考えること(リスク、ヴァリュー・マネジメント)、プロジェクト・ポートフォリオ・マネジメント、プロジェクト・プログラム・マネジメント、とプロジェクトマネジメントの関係、その使い方事例をご紹介します。 抽象的・概念的なISOから、標準規格、べたべたの適用事例までの関係や、技術からビジネスまでのマッピングなど、なるべく広範囲な話題を提供したいと思っています。

講師: 田島彰二(たじま しょうじ) 戦略PMオフィス代表

講師略歴:
37年に渡り、国産コンピュータ通信製造会社に勤務。主として新事業開発に従事。技術系
SE,SA,PMからプログラム・マネジャ(相当)、ポートフォリオ・マネジャ(相当)、新事業企画事業責任者等を歴任。
その後、2014年3月末に独立。コンサル系の業務を推進中。兼務で先輩の会社(ソフト開発会社)で仙台の責任者も従事。
PMのISO化作成の委員(PC236,TC258)。主としてプロジェクトの国際標準化(ISO21500)、ポートフォリオの標準化(ISO21504)を作成してきた。
PMI日本支部では、PMBOK委員会、PFM&PGM研究会、PMO研究会、OPM3研究会に所属。PMIの最新版の標準ドキュメント(PMBOK5, PGMV3, PFMV3,OPMV3)すべての貢献リストに掲示。
その他、ITコーディネータ、PM学会、PMAJ, IPMA各会員でもある。

著書:
参加費用: 無料。
ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、
学会の入会金(\1,000)は免除されます。

参加を希望される方は、確認のため、できましたら当日までに佐藤までご連絡ください。

以上
by Tomoichi_Sato | 2015-05-21 23:31 | プロジェクト・マネジメント | Comments(0)

JUAS『ソフトウェアメトリックス調査2014』を読み解く

まず、ちょっとこのグラフを見てほしい。
e0058447_20145718.gif

「何だこのグラフ。点がバラバラに散らばってるだけじゃないか。」
--そんな反応が多いだろうと思う。一応斜めに直線を引いているけれど、点はその線上から、ほとんど倍半分のいきおいでずれている。無理やり引いているだけで、法則性があるとはとても言えないな。誰だよこんなグラフ作ったの・・。

だが、このグラフ、わたしはとても面白いと思う。これは、「一般社団法人 日本情報システム・ユーザー協会」、通称『JUAS』が独自に行った調査の結果をグラフにしたものだ(JUAS発行「ソフトウェアメトリックス調査2014」p.66よりスキャンして引用)。グラフの横軸は情報開発プロジェクトの全体工数。単位は人月だ。そして縦軸は、プロジェクトの全体工期(=期間の長さ)で、単位は月数である。図上に散らばった多数の点一つ一つは、個々のプロジェクトを表す。

なお、よく見ると横軸は一定間隔ではない。10の隣が100、一つおいて500、1000(人月)という具合に、ちょっと奇妙な間隔に見える。実はこれは工数の立方根を横軸としたグラフになっているのだ。そして、図中に引いてある回帰直線は、
 y = 2.50 x^(1/3)
という非線形な関係を表している。すなわち、
 (全体工期)=2.50 * (全体工数の1/3乗)
になっている、事を意味する。

つまりプロジェクトの全期間の長さは、それにかける必要工数の1/3乗におよそ比例する。この式によれば、たとえば00人月の工数がかかるプロジェクトでは、
 2.50 * (100^0.33) = 11.6ヶ月
かかるだろう、という予測が成り立つ。200人月なら、14.6ヶ月だ。

JUASの2014年度調査は、会員企業からのアンケート調査で集められた累計1,076件のプロジェクト実績データを分析している。ちなみにこのグラフにプロットされたデータ数は407点。条件は、ウォーターフォール法で進められた再開発・改修プロジェクトで、FP(ファンクション・ポイント)値が3000以下またはソースコード量が330,000行以下のものだけを抽出したグラフである。なお図中に R2=0.86 と書かれているが、このR2は統計学で「決定係数」と呼ばれ、回帰式で説明できる分散(バラツキ)の割合を示す。プロジェクト全体期間の長さは、バラバラであるが、その86%が「全体工数の1/3乗」との関係で決まる、ということをおよそ意味している。

たしかにグラフの見た目は、ひどく点が散らばっている。しかし、これは社会調査的な結果であることを考慮するべきだろう。そして、この「1/3乗則」の関係は、再開発・改修のプロジェクトだけでなく、新規開発プロジェクトだけのデータでも成り立つし、全プロジェクトに対してもほぼ成り立つことが、JUASの同じレポートで示されている。式の比例定数は2.67だったり2.56だったりするが、大きくは違わない。決定係数も、0.85前後だ。つまり、「一般に情報開発プロジェクトの全体期間は、それにかかる工数の1/3乗に比例して決まる部分がかなり大きく、それは新規開発でも、既存システムの再開発・改修でも、あまり変わらない」という、非常に示唆に富んだ統計的事実が分かるのである。

これが、データの力である。正確には、データを蓄積し、それを読み解くことによって得られる力だ。最近はビッグデータというバズワードが大流行だが、データ件数が1,000程度ではスモールデータだろう。しかし、このグラフの点一つひとつが、どれほど多くの人の労力と汗と涙の結果で得られたか、その重みを考えてみてほしい。そして、こうしたデータ調査を毎年、ITユーザ企業に対して行い、結果を解析する仕事をJUASは10年近くにわたって継続している。この努力と姿勢に、わたしは率直に敬服する。

わたしがJUAS(日本情報システム・ユーザー協会)という組織のことを知ったのは、つい近年である。同じ『ソフトウェアメトリックス調査』2013年版を見てからだ。中身を見て、驚嘆した。膨大なデータを会員企業からアンケートで集め、戦略を持って分析している。その文章にも明確な主張があって、面白い。すなわち、ソフトウェア工学という重要な、しかしいまだ薄弱な工学を進歩させて実務に役立たせるためには、現実のデータに基づくベンチマークが絶対に必要だ、との主張である。いわゆる業界団体だとか役所の外郭団体が定期的に出すA4サイズ簡易製本のレポート類は、めったに面白いものがないという印象が強かったのだが、これだけは違った。

たとえば、システム開発に使用する言語については、こんな結果になっている(p.45):
- COBOL 17.2%
- C 13.8%
- VB 13.1%
- PL/SQL 16.8%
- Java 46.9%
- HTML 8.0%
現在、半分近くのシステム開発はJavaで行われており、その比率はまだ伸びている。だがCOBOLもいまだ17%、PL/SQLも17%と、微減ながら現役である。CやVBよりもまだ多い。これは調査対象企業が製造業・流通業など一般企業で、その大半が業務系システムであることも大きく影響しているだろう。

なお、パッケージソフトを利用した開発は全体の10.4%にすぎない(p.43)。9割近くのシステム開発が、スクラッチから書いているのだ! 2013年調査では17.5%、2012年度は18.3%だった。つまりパッケージソフトの利用は、むしろ減少しているのである。かつて2000年頃のITバブル期、ERPブームの時代には、パッケージを使わない奴は馬鹿みたいなことを、世間では喧伝していた。いま、その風潮はひっそりと、だが明確に反省期に入っている。

システム開発のプラットフォームでは、こうなる(p.44):
メインフレーム=22.6%、オフコン=1.2%、Unix=33.2%、Linux=21.4%、Windows=52.8%。
これはマルチアンサーだから合計は100%以上になるが、オフコンを含む汎用機がまだ十分現役であることにも、少し驚いていい。システムのアーキテクチャでは、
汎用機:21.2%、C/S:26.6%、Web:68.2%。
この比率は2013年度からほとんど変わっていない(p.44)。クラサバもまだ根強いなあ、との印象である。上の結果とあわせると、現在でも業務系システムはその多くが、JavaでWebベースで、かつスクラッチから書かれている。某社の某基幹システムを思い出して、ううむ確かに、などと思ってしまう。

しかし、ここら辺はまだ序の口だ。JUASはできあがったシステムの品質についてもたずねる。彼らの品質(欠陥率)の定義は、
 欠陥率=(顧客側総合テスト~フォローのフェーズで発見された不具合数)/(プロジェクト全体工数)
である(p.76)。UAT以降のバグ数を、人月あたりで割り算したものだ。この指標の立て方には異論もあると思う。だが、ユーザ企業から見ると、とても実質的で分かりやすい。このモノサシをたてて、彼らは経年変化を調べている。その変化は、緩やかだ。つまり一定の統計的傾向があるのだ。その中央値は0.20、平均値は0.58である。そして過去8年間に、平均値は1.00から0.20へ、また中央値は0.35から0.18へと、おおむね減少してきた。

ソフトウェア開発の品質は、次第に、だがかなり決定的に、向上しているのだ(バグをABCランクで重要度の重み付けをした数値については、報告書を参照してほしい)。それだけではない、「品質については、要件定義・設計・実装の各フェーズがすべて請負・請負・請負の契約のものの品質が明らかに悪い」(p.191)と大胆にも分析している。『業者にお任せ』型の開発は、よい品質を生まないのだ。

ソフトウェア開発の生産性はどうか。パッケージ開発以外で、かつIFPUG法で計測した127プロジェクト(うち新規開発と改修・再開発はほぼ半々)について、人月あたり全体の平均は約11 FPだった。ファンクション・ポイントではなく、単純に画面数と帳票数から全体工数を推算する式も出している(p.148)が、補正決定係数は0.34なので、あまり精度はよくない)。

JUASの調査は開発だけでなく、運用保守まで対象に入れている。自社開発システムの稼働後の開発費用・保守費用の比率では、稼働までの開発費用を100とした場合、初年度には平均して追加開発費が19.4%、保守費が8.5%かかっているという(p.196)。年間IT総予算の中の運用費用の割合も、大企業の場合は55%に上る(p.245)。なお、情報子会社の保有状況を見ると、子会社ありが19.7%、なしが80.3%である(大企業に限ると、保有比率はもっと高くなる)。

また今年度から、「マスターデータ管理」ならびに「アジャイル法と超高速開発法」についての質問も追加されたらしい。マスターデータ管理では、「導入済み」企業が8.7%であるのに対し、「未検討」はまだ70.6%だ。開発方法論では、2014単年度の回答集計ではウォーターフォール法が101件であるのに対し、アジャイル法7件、超高速開発法が47件だ(p.47)。500万円以上のプロジェクトを対象としているわりに、思ったより新しい手法が多いと、わたしは感じた。ただ、調査開始以来の累計データでは、まだ9割以上がウォーターフォールである。データ件数がまだ少ない上に、今回は品質データがとれていないため、一番興味ある「新しい開発手法の品質満足度はどうか」が分析されていないが、これは次年度以降の課題だろう。

このほかにも、まだまだ紹介しきれないほどたくさんのデータと知見が詰まった本である。この調査は経産省からJUASが受託して行われたものだが、世界的に見てもこのレベルの調査をオープンにしているところはあまりなく、欧州からうらやましがられているとも書かれている。これはひとつには、日本の経済規模が大きいため、それなりに多数のユーザー企業が存在することによるものだろう。ソフトウェアのメトリクス(計量指標)に興味ある人々にとって、必携の参考資料だと言えると思う。とくに、繰り返しになるが、JUASのこの調査報告書には明確な『主張・思想』のある点が、読んでいて小気味よい。こうした報告書では希有の体験である。

ところで、最初にあげたグラフから、工数の立方根と全体プロジェクト期間の関係を導くような分析アプローチに対しては、当然、疑問や批判もあるだろうと思う。上記の式はマクロな関係を示しているだけだから、もし誰かが、“全体工数は100人月だから期間は11.6ヶ月でスケジュールを作成しました”、などといって計画書を持ってきたら、わたしは「まずきちんとWBSから具体的スケジュールを組んで持ってこい。」とつっかえすだろう。その上で、推算式はバックチェックにつかうはずだ。森を見るマクロな視点は、木の枝を見るミクロな作業の積み上げにおいて、何かクレイジーな勘違いをしていないかをチェックするためのものだ。あるいはせいぜい、ごく初期の段階での超概算見積などに使う程度だ。使い方を間違えてはいけない。

しかし、もっと根本から疑問を呈する人もいるかもしれない。「法則性と言うにはあまりにもバラツキが多く、精度が悪い。それに、プロジェクトというのは元々、ユニークで個別な存在だ。だから、過去データから見てこうなるはず的な議論はナンセンスだ。」 

この反論は、よく見ると二つの別々の意見から成り立っている。まず、「法則と言うにはバラツキが大きすぎる」という意見。これはいいかえると、精度が高ければ法則として使う、という立場を表している。ところが後半は違う。「プロジェクトはすべて個別でユニークな存在だから、過去を参考にするよりも、自分の意思が大事だ」と言っている。この立場から見れば、そもそも法則性などというものは認めないことになる。だからこの二つは、実は並び立たない両極端の意見を表している。

前者の立場を、ここでは「科学法則主義」と呼ぶことにしよう。これは、電気におけるオームの法則のように、厳密な関係性を求めている。たしかに冒頭のグラフは点のバラツキが大きい(だからワザとこれを引用したのだ)。おそらくプロジェクトの全体工期を決める要因としては、工数以外にまだ大事な変数があって、その要因が層別し切れていないために、このようなバラツキを生んでいるのではないか、とも考えられる。他方、後者の立場を「個別主義」とここでは呼んでおく。プロジェクトはすべてユニークだと考える立場だ。この立場ではリーダーの気合いやパッションを重んじる人が多い。

いずれの立場も、主義主張であるから、それ自体が正しいとか正しくないとかは簡単に議論しがたい。しかし、この両者は両極端であるにもかかわらず、不思議な共通点がある。それは、JUASが苦心惨憺して集めた過去のデータは価値がない、と見る点だ。JUASのこの報告書の著者は、科学法則主義でも個別主義でもなく、その中間の立場にいる。そして、過去のデータはそれなりに参考になるし、価値があると考える。過去のデータの価値をどれだけ認めるかを模式的なグラフにしてみると、両端がゼロ(無価値)で、真ん中が盛り上がる形になっているにちがいない。

e0058447_1921038.gif


そして、わたしもJUASの著者と同じ立場である。過去を知り、過去のデータに学ぶことには、とても大きな価値があるのだ。科学法則主義と個別主義は、たとえているならば二人の登山家であろう。山の中で道に迷って、日もとっぷり暮れてしまった。正しい道を探しているのだが、科学法則主義者は「磁石が不正確で正しい方位を指さない」といって途方に暮れ、個別主義者は「そもそも方位なんてものは当てにならないのだ」と文句を言っている。それだったら、他人の足跡を探せばいいじゃないか、とわたしは思う。足跡の集積が、道になるのだ。他人の経験に学ぶことこそ、わたし達が賢くなる一番の早道ではないだろうか?
by Tomoichi_Sato | 2015-03-28 19:08 | プロジェクト・マネジメント | Comments(0)

プロジェクト&プログラム・アナリシス研究部会(4月10日)開催のお知らせ

「プロジェクト&プログラム・アナリシス研究部会」の2015年第2回会合を、以下の要領にて開催いたします。

今回はいつもと少し趣向を変えて、当研究部会の副査であり、前スケジューリング学会長である八巻直一先生から、日本の技術開発史から見たマネジメントの問題点について、肩のこらない雰囲気のお話をいただく予定です。テーマは、お得意の分野である鉄道=蒸気機関車の話題です。 「日本的マネジメントの感性」(静岡学術出版)の著書もある八巻先生の語り口を、お楽しみください。


<記>

日時: :2015年4月10日(金) 18:30~20:30

場所: 三田キャンパス・旧図書館・小会議室
    http://www.keio.ac.jp/ja/access/mita.html
    キャンパスマップの【2】になります

講演タイトル: 「技術開発に夢を乗せて - 日本の蒸気機関車開発の悲哀 -」

概要:「新幹線の父」とよばれた島秀雄氏。そのお父上である島安二郎は、日本の蒸気機関車の父であった。単身ドイツに渡ったのち、国産蒸気機関車の開発に成功し、我が国の鉄道技術の礎となった。 本日は、そこに見える技術立国日本の悲哀などをかみしめることにしたいと思います。
気楽なお話ですので、ワイワイ議論をお願いいたします。

講師: 静岡大学名誉教授 八卷直一

講師略歴:
・昭和45年 3月 東京都理科大学大学院理学研究科修士課程 修了
・昭和45年 4月 東京理科大学理学部応用数学科助手
・昭和57年 4月 株式会社システム計画研究所取締役
・平成 8年12月 静岡大学工学部教授
・平成12年12月 静岡大学総合情報処理センター長(併任)
・平成18年 4月 静岡大学工学研究科事業開発マネジメント専攻長(~平成21年3月)
・平成19年 4月 CIO補佐 情報基盤担当学長補佐(~平成21年3月)

著書:
「非線形計画法」八卷直一・矢部博(共著)、朝倉書店(1999)
「問題解決のためのAHP入門」八卷直一・高井英造(共著)、日本評論社(2005)
「大学のITコンプライアンス」八卷直一(監修)、静岡学術出版(2007)
「日本的マネジメントの感性」八卷直一、静岡学術出版(2011) 他多数

参加費用: 無料。
ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、
学会の入会金(\1,000)は免除されます。

参加を希望される方は、確認のためできましたら当日までに佐藤までご連絡ください。
なお、席に限りがありますので、お早目のご連絡をおすすめします。

以上

by Tomoichi_Sato | 2015-03-14 18:46 | プロジェクト・マネジメント | Comments(0)

プロジェクト・ファイナンスとは何か

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

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

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

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

答えはいうまでもない。(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)しない」という点だ。

e0058447_538462.gif


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

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

e0058447_5393066.gif


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

ここで、ちょっと簡単な計算をしてみよう。今、あなたは裕福金満な貸し手である。あなたは、担保能力のない新興国の新設会社に、自分の手金を融資する。その金額を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にご出馬いただくまでもないような通常の企業のプロジェクトでも、その価値や投資の正当性について継続的・客観的な把握が必要であり、きちんとしたガバナンスも重要である。そのような観点から、プロジェクト・ファイナンスの構造について、もっと皆が関心を持つべきだとあらためて感じた次第である。
by Tomoichi_Sato | 2015-02-16 05:43 | プロジェクト・マネジメント | Comments(0)

プロジェクト&プログラム・アナリシス研究部会」(1月28日)開催のお知らせ

明けましておめでとうございます。
「プロジェクト&プログラム・アナリシス研究部会」2015年の第1回会合を、下記の要領にて開催いたします。
(訂正):最初、この記事で1月27日(水)と書きましたが、1月28日(水)が正しい日付です。お詫びして訂正します。

皆さんは「プロジェクト・ファイナンス」という仕組みをご存じでしょうか? プロジェクトそれ自体の価値を担保として、必要な資金を調達する手法です。どんなプロジェクトも、費用・時間・労力を投入して何らかの価値ある結果を作り出す投資事業と考えることができます。とくに資金を十分に持っていない者に対し、有形の担保でもなく連帯保証でもなく、プロジェクトそれ自体の価値とリスクを評価して、金融機関がお金を貸してくれるという仕組みがプロジェクト・ファイナンスです。

今回は、国際協力銀行株式会社の内藤英雄様にご講演いただきます。内藤様は国際協力銀行(略称・JBIC)の経営企画部長であり、本分野のプロ中のプロともいえる方ですが、今回はとくにお願いして、我々初心者にもわかりやすいプロジェクト・ファイナンスの入門編ともいうべき内容のお話をしていただきます。

プロジェクト・ファイナンスは従来、途上国における資金調達方法として発達してきましたが、最近は国内外を問わずいろいろな場面で注目されるようになってきました。これから新興国での海外型プロジェクトにチャレンジする日本企業にとっても、また国内で新しい事業創出に取り組もうとする人にとっても、大いに参考になるはずです。ぜひ、ご期待ください。


<記>

■日時:2015年1月28日(水) 18:30~20:30

■場所:三田キャンパス・旧図書館・小会議室
http://www.keio.ac.jp/ja/access/mita.html
キャンパスマップ・【2】になります

■講演タイトル:
「プロジェクトファイナンス ― 基本・特徴・課題 ―」

■概要:
 「プロジェクトファイナンス」(PF)は主に大規模プロジェクト向けの長期ファイナンスの金融手法の一つで、海外の資源開発やインフラ事業等において積極的に活用されています。日本でもPFI(Private Finance Initiative)事業向けのファイナンス手法として普及しつつありますが、海外と比べますと、まだまだ発展途上の段階です。当日は、PFの基本的な内容や特徴から始め、PF組成に必要なリスク分析や関係者間でのリスク分担等の内容についてもご紹介し、時間の許す限り、PPPやPFI等の民活インフラ事業を進める上での実践的な課題についてもご案内したいと考えています。


■講師: 内藤英雄 (国際協力銀行株式会社)

■講師略歴:
・1985年(昭和60年)3月 一橋大学(社会学部)卒業
・1985年4月 日本輸出入銀行(現(株)国際協力銀行)入社
・2011年1月 欧阿中東ファイナンス部長
・2011年7月 電力・水事業部長、プロジェクトファイナンス協議会議長
・2013年7月 経営企画部審議役
・2013年12月 経営企画部長(現職)


■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(\1,000)は免除されます。

 参加を希望される方は、確認のため、できましたら当日までに佐藤までご連絡ください。


佐藤知一@日揮(株)
by Tomoichi_Sato | 2015-01-08 12:29 | プロジェクト・マネジメント | Comments(2)

『プロジェクト・アナリスト』はなぜ必要か

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

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

設立趣意書には研究部会の目的として、次の三つの項目を挙げた:
・プロジェクトと、その上位概念であるプログラムの、価値・スケジュール・リスクなどの客観的分析と評価手法を工学的に確立する
・これにより、組織におけるプロジェクト/プログラムの意思決定に資するとともに、「プロジェクト・アナリスト」の専門職域を新たに構想する
・現実のプロジェクト/プログラムの事例検討を行う。それを可能にするクローズドな場をつくる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


<関連エントリ>
 →「プロジェクト・マネジメントの理論は科学たり得るのか 〜 EDEN PM Seminarに参加して」(2014-09-14)
by Tomoichi_Sato | 2014-12-09 22:48 | プロジェクト・マネジメント | Comments(0)