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

海外プロジェクト・マネジメントにおけるシステムズ・アプローチとは 〜化学工学会展望講演(9/09)から

・・・ただいまご紹介いただきました日揮の佐藤です。本日このセッションには、アカデミアの先生方、また実務界の諸先輩が大勢お見えになっていると思います。そこで、まず皆さんに考えていただきたい問題があります。

時は紀元前215年のこと。秦の始皇帝は、北方の異民族・匈奴の侵入を防ぐため、部下の将軍・蒙恬に城壁の建設を命じました。 今日「万里の長城」として知られるものの原型で、歴史に残るビッグ・プロジェクトでした。
e0058447_2215421.gif
しかし、長城はなかなか完成しません。そればかりか、苦役にかり出された民の怨嗟の声も届きます。そこで始皇帝は、自分の長男・扶蘇を現地に派遣し、建設事業の状態を調べることにしました。では、扶蘇が現地でまず調べるべき事は何でしょうか? ご自分が始皇帝なら、何を調べろと扶蘇に命じますか?

(本サイトの読者諸賢も、この先を読む前に、ちょっと考えてみてください。)

次に、第二問です。
今度は、皆さんは化学企業の経営者になったと想像してください。そして自社の業容拡大のため、南米の新興国に新しく化学プラントを建設することにしました。

皆さんは部下をプロマネに任命し、現地に派遣しました。しかし、プラントはなかなか完成しません。現地のパートナー企業の不満の声も届きます。そこでTV会議で現地のプロマネを呼び出し、話すことにしました。では、皆さんがまず質問すべき事は何でしょうか?

いずれも、遠隔地で遂行する「問題プロジェクト」の実態を調べるケースです。

最初のケースについて、詳しい史料が残っているかどうか、寡聞にして知りません。しかし想像するに、2000年前の扶蘇がが訊ね、調べたのは、こんな事だったのではないでしょうか?

− いったい今までいくらの費用を使ったのか?
− 長城の建設はいつ終わるのか?
− そもそもこの蒙恬将軍という男は、どういう人物か? はたして信用できるのか。

では、二番目のケースについてはどうでしょうか。まさか、現代人の皆さんが、2000年前の扶蘇と同じことをたずねて良い訳はないですよね? 現代ならば、プロマネにたずねるべきは、こんな質問のはずです:

− プロジェクトの『スコープ』はどうなっているのか。WBSを見せろ。
− このプロジェクトの『クリティカル・パス』は何か? アクティビティ・ネットワークの上で示せ。 主要なリスクは何か?
− 現在までのPV, AC, そしてEVはいくらか。完成時のCost EACを予測せよ!

現代のプロジェクト・マネジメント理論(以後『モダンPM』と略称することにします)が生まれたのは、20世紀中盤のことでした。モダンPMは、1950 年代にデュポン社が化学プラント建設プロジェクトの工期予測のために開発した、スケジューリング手法である”Critical Path Method” (CPM)に始まります。

このCPMは、プロジェクトを複数の要素作業(アクティビティ)から構成される『システム』としてモデリングした、システムズ・アプローチの産物です。プロジェクトを構成するアクティビティのネットワークを考えたとき、プロジェクトの全体工期はネットワークの始点から終点までを結ぶ最長の経路=クリティカル・パス(Critical Path)によって決まる、というのが、CPMの理論的骨子です。
e0058447_21572456.gif

クリティカル・パスに属するアクティビティの比率は、実規模のプロジェクトでは全体の2~3割程度と言われています。他のアクティビティは、日程上のフロート(余裕日数)を持っているのです。そしてクリティカル・パス上の仕事が遅れた場合、他の仕事をどんなに頑張っても、プロジェクト全体の納期が遅れます。だから、納期遅延のおそれのあるプロジェクトでは、状況把握のために、まずクリティカル・パスがどこにあるかを問うのです。

またCPMは、スケジューリングとコスト管理に際だった違いがあることを示しています。コストの世界では、どこかのアクティビティで1円得すれば、プロジェクト全体で1円、得します。単純な足し算の論理です。しかし、時間の世界はそうなりません。フロート(余裕日数)を持つアクティビティを、いくら頑張って短縮しても、プロジェクト全体の納期にはちっとも貢献しないのです。プロマネはどこがクリティカル・パスになっているか、つねに意識し、そこに集中すべきです。だから、現代でプロマネに問うべき3つの質問に、この項目が入っているのです。

さて、モダンPMの発展史で次に議論になったのは、「プロジェクトはどのようにアクティビティに分解すべきか」という問題でした。ここで確立したのが、WBS(Work Breakdown Structure)という概念です。プロジェクト全体のスコープ(作業範囲)をアクティビティで階層的に構成し、管理番号を付番したものをWBSと呼びます。各アクティビティは、達成すべきアウトプット(成果物)と、必要なインプットが決められており、担当する人とリソースを割り当てる 必要があります。また、それをさらに下位のサブ・アクティビティに階層的に分解することができます。

WBSはスコープ、すなわちプロジェクトの責任範囲を可視化したものです。またWBSはプロジェクト組織の分担の表現でもあり、またコストをロールアップし集計する際の基準にもなります。ですから、WBSをよく見れば、どのようにプロジェクトを進めようとしているのかがすべて見て取れます。だから問題プロジェクトの状況把握では、最初にWBSについて質問するのです。

このようにWBSはモダンPMにとって非常に重要なのですが、多少の論争がありました。ある人々は、プロジェクトを、仕事のプロセスに沿った機能別・仕事の種類別に分解すべきだと考えました。これをFunctional-WBS(略称F-WBS)といいます。たとえば化学プラント建設を例にとると、基本計画・設計・調達・建設・試運転・・といった分解になります。
e0058447_21581110.gif

他方、いや、プロジェクトは必ず何らかの成果物を生み出す活動なのだから、成果物自体の構成に準じた分解をするべきだと主張した人々もいます。これを、Product-WBS(略称P-WBS)と呼びます。たとえば化学プラントならば、製造設備・ユーティリティ設備・物流エリア・事務棟、といった分解です。

両者に論争があったということは、実はどちらか片方では十分ではないことを示しています。そこで、両者を縦横にとった二次元マトリクスでアクティビティを数え上げるのが、もっとも理想的な方法だという考えに至ります。単位要素となるアクティビティは、「製造設備-設計(1-E)」「物流エリア-調達(3-P)」といった具合です。
e0058447_2202622.gif

ただしこの方法では、アクティビティが必要以上に小さく分解されすぎてしまうことがあります。アクティビティが小さすぎると、情報収集やレポーティングなど、コントロールにかかる手間が増大し、本末転倒の「管理のための管理」になる 危険性があります。そこで、いくつかをまとめて、アクティビティの最小単位「ワークパッケージ」とする 技法が用いられています。

WBSにつづいて70年頃から発展したのが、EVMS(アーンドバリュー・マネジメント・システム)と呼ばれる手法です。扶蘇が蒙恬将軍にたずねたであろう問いを思い出してください。「この仕事にこれまでいくら費用を使ったのか?」--それでは、もしも現在までの出費(Actual Cost = AC)が、当初計画していた現時点までの予算(Planned Value = PV)よりも小さかったら、プロジェクトはうまく出費をコントロールしていると言えるでしょうか? たとえば、現時点までの出費予定が1億ドルだったのに、現実の出費実績が9千万ドルだったら、うまくいっていると判断していいでしょうか?

そうは言えないのです。なぜなら、単に仕事が遅れているために 出費実績が計画より小さいのかもしれないからです。むろん、本当にうまくコストを押さえ込んでいるのかもしれない。どちらの理由で1千万ドルの差が生じているのかは、この二つの数字だけいくら眺めたって分かりません。

そこで、Earned Value = EVとよぶ第3の金額を計算してみるのです。EVとは、「現時点までに完了した作業(アクティビティ)の予算金額合計」のことで、日本語では『出来高』と呼ばれます。かりに、前述のプロジェクトでEVを計算してみたら7500万ドルだったとしましょう。これから何が分かるでしょうか? まず、EVとPVを比べます。すると、EVの方が小さいですね。つまり、元々の予定では現時点までに1億円分のアクティビティが終わっているはずだったのに、現実には7500万ドル分しか完了していない訳です。これは、プロジェクトの進捗が予定よりも遅れている(予定の75%の進捗しかない)事実を示します。

さらに、EVとACを比べると何が分かるでしょうか。EVが7500万ドルなのに、ACが9000万ドルということは、すでに終わったアクティビティについては、当初の予算では7500万ですむはずだったの出費が、実際には9000万かかった、つまり見込よりも余計にコストがかかっていることを意味します。まとめると、このプロジェクトは、進捗は予定よりも遅れており、なおかつコストは予算より超過しているという、非常に危険な状態にあることが、わかるのです。これはEVという指標を導入することで明らかになったことで、予算PVと実績ACの二つだけをいくら比べたって、分かりません。これが、プロジェクトの予算管理と、通常の定常業務の予算管理との大きな違いなのです。

では、プロジェクトの完成時にはいったいいくらの金額になる見込なのか。これを完成予測額(Cost Estimate at Completion = Cost EAC)と呼びます。それは、すでに使ってしまったお金ACと、残っているアクティビティを完了するのにこれからまだ必要となる金額ETC(Estmate to Complete)の合計ということになります。Cost EAC = AC + ETCです。ACは9000万ドルですね。あと、仕上げなければいけない作業が、元々の予算計画ではまだ2億ドル分あったとしましょう。すると、Cost EACは2億9000万ドルでいいでしょうか?

むろん、それでは楽観的すぎます。まず、これまで7500万ですむと思っていた仕事が現実には9000万かかっていたことを思い出してください。これは、平均するとちょうど2割だけ、実際の出費が高いことを示します。このトレンドは、おそらく将来も続くでしょう。EVMSの膨大な経験が教えるところによると、プロジェクトが全体の2割を過ぎたあたりから、AC/EVの比率は安定してきます。である以上、残る仕事も、2億ドルではなく、2.4億ドルはかかりそうです。おまけに、進捗が遅れていることもお忘れなく。納期に間に合わせるためには、人を増員するなどキャッチアップのために余計な費用が必要でしょう。となると、たぶんCost EACは3億3000万をもっと上回ることが予想されます。

このように、EVを用いてコストと進捗をコントロールしていく手法を、Earned Value Management System = EVMSと呼びます。

モダンPMで用いられている三大技法であるCPM、WBS、そしてEVMSの原理を、簡単にご説明しました。この3つはちょうど、プロジェクトを取り囲む三大制約である『スケジュール』『スコープ』そして『コスト』に対応しています。この三大制約は別名、「鉄の三角形」とも呼ばれ、プロマネは日夜その中で苦労しながら進んでいるのです。だからこそ、これを押さえるための手法が真っ先に発達してきたのでしょう。
e0058447_2242310.gif

もちろん前述の原理を、現実のプロジェクトに適用するためには、いろいろな道具立てやノウハウの集積が必要です。そうした原理・ツール・ノウハウの総体を称して、技術と呼ぶのです。プロジェクト・マネジメントの技術です。

こうしたマネジメント技術の基本を押さえた上で、プロマネのリーダーシップやメンバー達のモチベーションを問うのならわかります。プロジェクトは結局、人間がやることですから。しかし、こうした基本さえ知らずに、いきなりリーダーの人格や志気を問題にするとしたら、そして、プロジェクトの構造を見ずに、ただ全体の費用や納期だけを見るとしたら、2000年前の扶蘇と同じではないでしょうか。

国内で顔見知り同士が、同じ言語と文脈を共有して、以心伝心で仕事を進めていける国内プロジェクトならば、技術なしでも気合で乗り切れるでしょう。しかし海外プロジェクトは、根本的に違います。 こうした技法を押さえた上で、さらにわたし達が身につけるべき思考と行動の習慣、いわばマインド面でのOSがあるのです。それは端的にいえば、

言葉を大切にする(言語化)
・かならず計画をたてる(計画重視)
契約と責任を重んじる(契約責任制)
そして、
・システム的な見方をする(Systems approach)

です。 システム・言葉・計画・契約の頭文字をとって、 わたしは「S + 3K」と呼んでいます。


・・ということで、展望講演はこの後、海外プロジェクトの進め方を概説し、さらに現在のモダンPM理論に欠けている価値評価をめぐって、わたしが進めてきた「リスク基準プロジェクト価値」研究成果を紹介した。そして、今後のモダンPMの発展には「仕事のプロセスシステム工学」が大事になるだろう、という話で締めくくった。だが長くなりすぎるので、後半は割愛させていただこう。なお念のために書いておくと、化学工学とは元々、化学プラントの設計論であり、とくに各種装置を組み合わせてプラント全体のシステムを設計・最適化する手法論を「プロセスシステム工学」と呼ぶ。

プロジェクトもまた一種の化学プラントに類似したシステムであり、個別のアクティビティという要素を組み合わせて、全体のシステムを作り上げ、動かしていく。そうした思考方法=システムズ・アプローチこそ、これからのプロジェクトにとって必須のものだ、というのが、聴衆の皆さんに伝えたかったコアのメッセージだ。

では最後に、WBSをはじめとするモダンPMの技術、そしてシステムズ・アプローチを中心としたマインド面でのOSについて、もう少し深く知りたい方のために、格好の入門書をご紹介しよう。1年半かけて書いた、わたしの新著『世界を動かすプロジェクトマネジメントの教科書』である(笑)。今週末から書店に並ぶが、電子版はさきがけて本日から発売である。ぜひ手にとってご覧いただきたい。海外プロジェクトに長年実務で携わり、また近年はPM理論研究と教育も実践してきた人間として、類書にない思想と技法を盛り込んだつもりである。

地図を読んでも山には登れず、海図を見ても船は航行できない。だが、どこに登るべき山があり、渡るべき海があるかは分かる。本を読んでも能力がすぐ得られるわけではないが、できればぜひ一人でも多くの方に、海を渡って広い世界を目指してほしいと願っている次第である。
by Tomoichi_Sato | 2015-09-15 22:18 | プロジェクト・マネジメント | Comments(0)

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

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

皆さんは「シナリオ・プランニング」手法について聞いたことがあるでしょうか? 事業プログラムの戦略立案においては、つねに複雑で不確実性の高い環境の中で予測を行い、最適な目標とアクションを選ばなければなりません。またプロジェクトのリスク・アセスメントにおいても、定量化し確率を予測できる事ばかりではなく、定性的な先読みが求められる局面がしばしばあります。そうした問題に対応するため、主に欧州を中心に開発されてきた手法がシナリオ・プランニングです。

この手法の初期の有名な成功例は、'70年代に石油メジャーであるロイヤル・ダッチ・シェル社が作成した「石油危機シナリオ」でした。同社は事前に複数シナリオによる予測を行い、組織内の体制を整えていたことで、世界的な石油ショックに効果的に対応することができました。同社はその後もシナリオ・プランニングの手法を継続して発展させ、戦略構築に結びつけてきました。そして、他の企業・政府機関などでも戦略構築のために広く使われるようになったのです。

今回は、シナリオ・プランニングに関する日本の権威である、昭和シェル石油チーフエコノミストで東京大学客員教授の角和昌浩様をお招きして、その方法と成功のポイントについてお話しいただきます。業種を問わず、戦略や予測に関心のある方に興味深い内容になると思います。

<記>

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

■講演タイトル:「シナリオ・プランニングによるビジネス環境分析
        ~シェルのグローバルシナリオ作成に学ぶ」
■概要:
シェルグループは、なぜシナリオプランニングを戦略検討ツールとして40年以上、継続してやっているのか。このツールを戦略検討作業や戦略決定に取り込むと、どういう便益があるのか。最新のシェルのシナリオ作品を紹介しながら、その方法と成功のポイントを理解していただきたいと思います。

■講師: 角和 昌浩 (かくわ まさひろ)
    昭和シェル石油株式会社 チーフエコノミスト 兼 東京大学 公共政策大学院 客員教授
■講師略歴:
 1977年3月 東京大学法学部政治学科 卒
 1977年4月 昭和石油(現昭和シェル石油)入社
 1982-83年 ロンドン大学東方アフリカ研究所 中近東学科留学
 1987-89年 石油公団に出向
 1992-95年 ロイヤル・ダッチ/シェルロンドン本社に出向
 2003年10月 日本エネルギー経済研究所 兼 名古屋大学エコトピア科学研究所客員教授 兼 電力中央研究所客員研究員
 2009年4月 現職にいたる

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

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

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

プロジェクト・マネジメントについての新著を、9月に出します

お知らせです。
9月初旬に、プロジェクト・マネジメントについて新しい著書を技術評論社より上梓します。

 「世界を動かす プロジェクトマネジメントの教科書」 佐藤知一・著

 出版社の新刊紹介ページ:(概要・目次を見ることができます)
 http://gihyo.jp/book/2015/978-4-7741-7604-8

 Amazonでもすでに予約可能になっています!
 世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方
e0058447_235327100.jpg

本書の中心テーマは、『海外型プロジェクトの進め方』です。現在、海外への事業展開を検討し、チャレンジしている日本企業は多いですが、わたし自身が見聞きした範囲では、いくつか共通する弱点を抱えているように見受けられます。国内ではうまくいったはずの仕事のやり方が、一歩海外に出たとたん通用しなくなる、というのはよくある話です。それはPM技法的な能力の不足もさることながら、組織のスタンス自体がずれているからです。たとえば、もし、

- 計画がきちんと立てられず、行き当たりばったり
- だれが何を決めるのかわからず、意思決定が遅れる
- 以心伝心・暗黙の了解で動いて、言葉にしない
- 契約感覚に乏しく、地雷を踏んでしまう

といった項目に、一つでも思い当たることがある方は、ぜひ本書を手に取ってご覧ください。本書は通常のPMの標準書に書かれている技法論もカバーしていますが、それよりももっと底にある組織の思考・行動習慣(これをわたしは組織の『OS』と呼んでいます)に、何が不足しているかを解説しています。

本書の内容は元々、東大大学院でのプロジェクト・マネジメント講義資料を中心にまとめたものです。ただ、単なる教科書ではなく対話形式とし、これから初めて海外プロジェクトにチャレンジする製造業の若手エンジニアを主人公に、多少のストーリー性を加味した形にしました。

海外型プロジェクトの進め方について問題意識を持っておられる方、あるいは中小規模のプロジェクト実務に携わっていながら世間のPM標準では満たされぬ思いを感じておられる方々に、ぜひ読んでいただきたいと願っております。


佐藤知一
by Tomoichi_Sato | 2015-08-08 23:54 | プロジェクト・マネジメント | Comments(0)

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

お知らせです。
日本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)