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

海外型プロジェクトの難しさ − それはOSレベルの問題である

先日、あるプライベートな勉強会に招かれて、議論する機会があった。テーマは「海外型プロジェクトの進め方」である。中堅ないし準大手の製造業およびソフト会社で、それなりに海外展開を進められている企業の実務家がメンバーであった。プロジェクト・マネジメントについては、すでに社内でもいろいろな取り組みをされているところが多いと見受けられたので、「PMBOK Guide(R)とは」みたいなレベルの、基礎的な解説はさけることにした。わたしは、国内では一応うまくいきつつあるプロジェクトが、なぜ一歩海外に出ると急に難しく感じられるのか、それは『組織のOSレベルの問題である』という見方の話をすることにした。

「組織のOSレベルって何のことだ?」と怪訝に思われた方もいるだろう。少し順を追って説明したい。過去10年ほどの間に、日本でプロジェクト・マネジメントの体系や技法がそれなりに普及したおかげで、プロジェクトの成功率が上がってきたことは、統計にも表れた事実である。たとえばIT系プロジェクトにおいて、日経コンピュータ誌の調査によれば、2003年の成功率はわずか26%だったものが、2014年の調査では75%が成功だったという。ここでの『成功』の定義は、QCDを達成したことであり、果たしてそれで真に成功と言えるのかという問題は別途あるが、ここでは脇に置いておこう。またJUAS(日本情報法システム・ユーザー協会)の2014年度調査によれば、予定通りあるいは予定より早く完了したプロジェクトは合計で74.2%だった。製造・建設など他の分野はあまり統計を見かけないが、それにしてもかなりプロジェクトの成功率が上がっているのは確かだろう。

ところで、プロジェクト成功率上昇の理由は、優秀なプロマネが日本にどんどん増えている、ということなのだろうか? たしかにPMP取得者数は増えただろう。だが、それだけではないとわたしは考えている。企業におけるプロジェクト・マネジメントの能力は、プロマネ個人だけで決まるものではあるまい。日本企業は、過去10年間の間に、プロジェクト遂行の能力を組織ぐるみで構築してきた。その結果が、統計に表れているのではないか。

これは逆の例を考えれば分かる。今まで全然プロジェクトらしい仕事を経験したことのない組織に、突然外から指折りのプロマネを引き抜いて連れてきたとしよう。その一人だけで、プロジェクトは十分なパフォーマンスを上げられるだろうか? 相当難しいに違いない。プロジェクトを計測する仕組みもなければ、過去のデータもなく、業務の標準的な手順やWBS体系もなく、さらに組織全体ががプロジェクト的に動く習慣のないところで、どうやって計画を立て統制できるというのか。

わたしの知っている、ある年配の元プロマネの方(もう現役は引退されている)から聞いた話だ。この人は有力なエンジニアリング会社出身だが、’90年ごろ転職して、別の巨大メーカーに入った。ちょうどそのメーカーはプラント輸出に注目して、海外でのプロジェクト展開に力を入れようとしていた。そして運良く、この会社はアジアの某国向けの案件を受注した。中規模の中ではかなり大きな案件だし、技術的にも国内で実績を積み、手慣れたものだった。ぴったりのタイミングで、この人はプロマネとして着任した訳だ。

ところが、この方いわく、「本当に死ぬかと思った」というくらい大変なプロジェクト遂行になった。なぜか。社内組織がちっとも動かないのである。プラントは機械・電気・制御・建築など多種多岐にわたる技術のかたまりで、プロジェクト・チームはいわば技術者のオーケストラのようなものだ。にもかかわらず、プロマネの振るタクトにあわせて誰も演奏しないのだ。では皆は誰の方を見て仕事しているかって? それぞれが所属するライン部門長の方だ。大きなメーカーでは、ライン部門長は強大な権限を持つ。人事面でも、予算面でも。その部門長達にとっては、国内での定常業務の運営が最大の関心事で、技術も人も、まずそちらに優先配分するのだ。「XXプロジェクト? それはお前たちが勝手にとってきた仕事じゃないか」というようなことを言う。いや、勝手にとったのではなく、会社として取り組んで受注したんじゃないか、と言ってもまったく馬耳東風である。

また、配属されたメンバーも、ちっともプロジェクト的に動けない。海外型プロジェクトでは基本、文字にかかれた契約がすべてである。そして、顧客に最終的な決定権がある。だが日本国内で人も知る巨大企業に働いてきた技術者達は、顧客の方を向いて、要求されたとおりに仕事する習慣がない。顧客や業者への説明能力・交渉能力にも欠けている(国内では殿様企業だったのだ)。過去の経験がないから、キーマンが自分で工程表を書けない。問題が生じても、部門をまたがる問題だと、お互いにそっぽを向いて自分で調整しない・・。

この例を見ても分かるとおり、プロジェクト・マネジメントの能力とは、組織の能力である、というのがわたしの理解だ。図に示せば、下のようなビラミッド構造である。最上位には、プロジェクト・マネージャーの個人的スキルがある。これは、さらにハード・スキルとソフト・スキルに分けることができよう。ハード・スキルとは、知識・技法など、主に座学で身につけることのできる能力である。ソフト・スキルとは問題解決力や交渉力など、いわゆるセンスや修練を要求される「人間力」的な能力だ。

e0058447_830782.jpg


プロマネ個人のスキルを支える中位の層には、三つの能力的な柱がある。(1) プロジェクト遂行のための標準的な業務手順・WBS体系、(2) プロジェクト管理のための情報システム、(3) 過去のデータベース、の三つである。これらがあってはじめて、プロマネは力が発揮できる。これらは、広義の「マネジメント・システム」だと言ってもいい。そして、このシステムを整備するのは、いわゆるPMO(Project Management Office)という部署の仕事だ。

ところで、この三本柱の下に、最も底辺の能力層がある。それがプロジェクト遂行に関する組織体勢・行動習慣なのである。プロマネが力をふるうためには、プロジェクト・チームの全員が同じ方向・同じベクトルを向いて動き、かつ権限や態度や行動習慣などにコンフリクトがない状態になっていなければならない(大事なことは、組織図にかかれたスタティックな状態ではなく、組織がどうダイナミックに動くかという姿勢の問題だから、あえて組織「体勢」という字を使っている)。たとえば、プロマネが「右向け、右」と号令をかけても、チーム員が上司であるライン部門長から別の指示を受けていたら、プロジェクトは迷子になるだろう。あるいは、皆がきちんとプロジェクト単位で記録やデータをとっていなかったりしたら、業務標準や過去データが生きてこなくなる。

3つの能力レイヤーを、ITの世界にたとえて言うなら、最上位の層はコンテンツ(知識)レベルの能力であろう。中位層は、アプリケーション(道具)レベルの能力に相当する。そして一番底辺の層は、いわば組織のOSレベルの能力である。組織のOSとは、言いかえるならチーム員全員にビルトインされた、「組織化され体系化された態度・行動の集合」なのだ。これがあってはじめて、プロジェクト・マネジメントは働きを得るのである。OSがおかしくなっていると、プロマネが何を言っても「笛吹けど踊らず」、データも情報システムもガーベッジ・インの状態になる。

そして、日本国内と海外プロジェクトでは、チーム員に求められるOSの質が違うのだ。なぜか。それは、大きく言って、4つの制約があるからだ。「『前例』も『正解』もない」という制約。「外国人同士で意思疎通が難しい」という制約。「前提としている価値観が違う」という制約。そして「先が予測しにくい」という制約の4つである。だから、海外型プロジェクトに日本人が携わる場合は、必ずこれら制約を意識した行動習慣が必要になり、それをサポートする組織体勢が必須になる。

『前例』も『正解』もない」ことの理由は言うまでもあるまい。だが日本は世界でもまれに見るほど高度に発達し組織化された社会だ。ありとあらゆる分野に、前例と正解が存在し、それを見つけて従うことが大事だとの思い込みが蔓延している。始めてとりくむ、構造もわかりにくい問題に、大局観を持って取り組むという、思考の習慣が身につきづらい。

意思疎通の難しさ」についても言うに及ぶまい。外国語だから、英語のうまい人間を連れてくれば解決、などと思ってはいけない。問題は、互いに共有する文脈(コンテキスト)のレベルの違いなのだ。日本は、世界でも有数の「ハイ・コンテキスト」レベルの社会である。言葉を連ねなくても、あうんの呼吸で通じる。そして、言葉を受けた側が、相手の意思を忖度して行動する習慣がある。世界で言うと、このようなハイ・コンテキスト社会は少数派で、個人的実感で言えば2割もあるまい。8割以上は、「言葉にしない限り通じない」相手なのだ。

価値観が違う」という制約は、文化の問題ではない。成功した海外プロジェクトでは、日欧米をはじめ何十という国から異なる文化背景の人間が集まってきて、それでちゃんと遂行できている。お金を儲ける、というビジネスの究極の目的だって一緒だ。だが、そこに至る過程・前提が違う(会社目標より部門成果、という前述の巨大メーカーの例を思い出してほしい)。だから、誰もが共通して納得できるプロジェクトとしての価値観を明示し尊重できなくてはならない。

先が見えない」も同様。皆が通ってよく踏み固められた道が存在していないのだ。だとしたら、自分でまず道筋を描いて、かつ、道中にぶつかる障害をうまくよけながらすすむという行動習慣がなくてはいけない。

こうした4つの大きな制約条件を乗り越えるために、日本人として訓練し身につけるべき組織体勢・行動習慣を、わたしは「OSレベル」の能力と呼ぶ。それはちょうど、(あまり良いたとえではないが)工場における「5S」のようなものだ。「5S」とは整理・整頓・製造・清潔・習慣化の頭文字で、よく組織された工場労働者は、これらを尊重するような行動習慣を持っており、おかげでものの流れにも機械の調子にも遅滞がない。

海外型プロジェクトの場合、OSレベルではだいたい8つくらいの基本的習慣に整理できるだろう。たとえば、以前かいた”Structured Approach"というのもその一つだ(「Structured Approachができる人、できない人」http://brevis.exblog.jp/18336958/)それは国内の仕事をずっと続けるならば、とくに不要な能力だ。だがこの先、もし外に出て行って仕事をしたいなら、せめてチーム単位で、身につけていく必要がある。この10年間にモダンPMの理論手法が普及したのはとても良いことだった。しかし、その副作用として、EVMSだとかCPMだとか道具レベルの能力さえ身につければ大丈夫、というような錯覚も生まれつつあるように思える。もっと下の、基礎的レベルの能力を忘れてはいけませんよ、とそろそろ声を大にして言わなければならないのだろう。

そして、ことは海外型プロジェクトだけではあるまい。優秀な人もしっかりした制度・システムもある。だが、何となく先が見えず、前例も役立たず、価値観もばらばらで、お互いに意思疎通がうまくできないような、もやもやとした状況の中で問題をかかえている組織や社会にも、こうした行動習慣は有用だと思われる。だからこの先、できるだけ機会を見つけては、具体例をこのサイトでも紹介していくことにしよう。また現在、海外型プロジェクトの進め方というテーマで、本も書くつもりでいる。早ければ、来年の春頃には上梓できるかもしれない。よければそちらもご期待ください。


<関連エントリ>
 →「Structured Approachができる人、できない人」 (2012-07-08)
by Tomoichi_Sato | 2014-12-03 08:30 | プロジェクト・マネジメント | Comments(0)

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

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

今回は、受注型プロジェクトの見積と受注戦略について、この分野の専門家である文教大学の石井信明先生にご講演いただきます。石井先生は情報システム学会理事で、要求工学やプロジェクト・マネジメントの研究家であり、また幅広い実務経験もお持ちです。

ご 存知の通り、受注ビジネスでは、限られたマンパワーの中で、受注したプロジェクトを遂行し、そのかたわら、次の案件の見積作業を行う必要があります。見積 の精度を上げるには多くのマンパワーを要し、受注案件の遂行を圧迫します。しかし見積を手薄にすると、見積精度が落ちます。しかも、需要は常に変動のリス クを伴っています。このような環境下で、どのようなバランスがもっとも長期的に利益を上げうるのか?
世界トップクラスの論文誌「International Journal of Project Management」に発表された最新の研究を中心にお話いただきます。ご期待ください。


<記>

■日時:2014年11月27日(木) 18:30~20:30

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

■講演タイトル:
需要変動下における受注戦略のマネジメント ~受注ビジネスを例に~」

■概要:
  グローバル化と技術革新スピードが速い現在、持続可能な経営の実現には、継続的なコスト低減努力に加え、顧客要求の変化、技術の陳腐化など、動的環境下で のリスクとコストのバランスの維持が求められています。なかでも、需要変動リスクに対応した需給マネジメントの高度化が必要です。ここでは受注産業を取り 上げ、受注戦略と需給マネジメントについて検討します。


■講師: 石井信明 (文教大学情報学部)

■講師略歴:
  東京工業大学工学部経営工学科卒業。日揮株式会社を経て、現在、文教大学情報学部教授。主な著書に、「プロフェッショナルを目指すシステム分析入門」(コ ロナ社)、「需給マネジメント」(朝倉書店)など。現在は、経営高度化技術の研究に従事。プロジェクトマネジメント学会理事、情報システム学会理事。博士 (工学)。


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

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


佐藤知一@日揮(株)
by Tomoichi_Sato | 2014-10-24 22:48 | プロジェクト・マネジメント | Comments(0)

存在しているだけで役に立つもの

これも、前回と同じ頃の話だ。

その日、わたし達は午前中の新幹線で出張に出ることになっていた。朝一番でオフィスに集まり、明日までの二日間の打合せで必要な書類一式を最終確認し、一緒にでかける手はずだった。ところが、プロジェクト・チームの一人が、なかなか出社してこない。彼は制御システムの担当で、その日の午後に、自動制御システム・メーカーと打合せする際の中心だった。気を揉みつつも、他のメンバーと書類の確認を続けていたら、ようやく40分近く遅れて、彼がやってきた。

--どうした。遅かったな。待ってたぞ。

「すみません。ちょっと家内が入院するんで、病院まで送ってました。」

--なんだ、奥さんが病気なのか。それは心配じゃないか。

「いえ、病気じゃないんです。だから出張は行けます。大丈夫です。」

--病気じゃないのに、病院に行ったの?

「今日が出産の予定日だったので・・。」

 あきれて、わたしは怒鳴った。

--そんな大事なこと、なんでもっと前に言わないんだ! 出張なんか行かなくていい。制御ベンダーとは俺が話をつけるから、書類を全部、すぐ渡せ。

「でも。」

--でもじゃない。向こうは命がけでやってるんだぞ。お前がそばにいなくてどうする!

彼は「わかりました」と小声でいって、書類を取り出すとすぐに会社を出ていった。わたしは重くなったかばんをかかえ、他のメンバーに合図して新横浜に向かった。

新幹線の車中で、書類を読みながら、今日の交渉のシナリオを考えてみる。わたしがその時おいかけていた新工場づくりのプロジェクトは、まだ提案段階のものだった。客先は何も言わないが、もう一社,競合相手が陰で動いている気配が強い。製造工程の中核装置は、客先のコア技術でもあり、客先が自分で設計・調達する。ただ、周辺工程をふくめて工場内にはかなりの物流量があり、クリーン度も必要とされるため、自動化された物流搬送が要求される。もちろん、建物も空調設備がごつい。そんな中、見えない相手と技術・価格の両面で勝負するのは容易ではなかった。顧客自身の要求仕様も、トータルの生産量や建物の面積などはあるが、細かい部分がない。というのも、製品が多品種受注生産である上に、技術革新が早く、顧客自身5年後に何をどれだけ新工場で作っているのか、予想もできないのだ。

競争の上で一番むずかしいのは、エンジニアリング会社であるわたしの勤務先に、メーカーのような目に見える具体的な『技術』がないことだった。この製品を見てください、どうです、このスピードと静音性! みたいなセールスがきかないのだ。わたし達がもっているのは、目に見えない“まとめの技術”、納期とコストと品質の制約の中で、複雑な新工場プロジェクトをまとめ上げる技術だ。すなわち「プロジェクト・マネジメント技術」が唯一最大の売り物なのである。

だが、これに顧客はどれだけの価値を認めてくれるのか。エンジ会社など通さずに、自分で直接メーカーからモノを買った方が安いじゃないか、と考える日本企業は少なくない。エンジ会社は毎年、何千億円の単位で工場の資機材を世界中から調達しているので、かなりのバイイング・パワーをもっているのだが、それでも国産の特殊な製造機械の分野は、自分達の方がプロで安く買えると、わが顧客も信じていた。だから、目に見えない“まとめ技術”に価値を見いだしてもらうためには、工場全体をスムーズに動かせる仕組みを提案し印象づけるしかない。そのため、制御システムが重要になるのだ。

ところで、ああは言ったけれども、正直なところわたしはPLCなどの制御系システムはあまり得意ではない。じゃあ何系が得意なんだと問われるとこまるけれども、制御よりももう少し上位系の、いわゆる製造実行システム(MES = Manufacturing Execution System)ならば、いくらか経験がある。

いわゆる中央制御室などのある大規模プラントでは、DCSと呼ばれる集中制御システムに、プラント各所の温度・流量・圧力などの計測データがすべて集められる。そこでDCSは制御ロジックに従ってフィードバック制御などのリアルタイム計算をして、各機械の起動停止や調節弁の開閉などの指示信号を送り出す仕組みになっている。プラント内の数万点のデータを1秒周期で取り込んでは計算し送り出す訳だから、扱うデータ量は膨大である。だから当時のDCSでは、1週間程度くらいしか履歴データを保持しなかった。そこで、DCSの上位に、Historianと呼ばれる別のシステムをつなげて製造実行管理に用いるのである。Historianのソフトは特殊な圧縮アルゴリズムをそなえていて、リアルタイムの測定データを数年分保持でき、しかもタイム・スタンプをキーとしたRDBみたいに扱うことができる。

しかし、そこまで規模の大きくない工場では、PCとPLCの組合せで制御と製造管理を行うというのが、当時の主流だった。その方が価格としてもずっと安くなるが、どこまでパフォーマンスを出せるかが鍵になる。そのための見積交渉が今回の打合せの主目的だった。技術論に深入りされると、ちょっとつらい。ただ、今朝遅刻してきた担当者が作った仕様書は、かなり詳細にできているので、何とか乗り切るしかない。彼は寡黙だが、仕事は正確で真面目だった。真面目もいいが、まだ子どもがいるとはきいていないから、奥さんは初産ではないか。ちょっと度が過ぎている・・。

それにしてもプロジェクト・マネジメントの価値とは何かな、とわたしは考えた。どうしたらそれを計量化して、顧客にも見える化できるのか。プロジェクトの価値とは何か、それを構成するアクティビティの価値はどう測るか、そしてプロジェクト・マネジメントの価値とは--こうした問題は、当時からわたしの主要なテーマだった。プロジェクトの価値を金銭的に評価し、それを、各アクティビティの貢献に分解する方法については、その後、リスク確率という概念を導入するときれいに数式化できることに気がついて、わたしの学位論文に結実した(興味がある方は「リスク確率に基づくプロジェクト・マネジメントの研究」を参照されたい。Amazonから購入可能である)。

しかし、プロジェクト・マネジメントの価値評価については、当時も今も、いまだに解けていない問題である。プロジェクト・マネジメントという行為は、それ自体は何も具体的なプロダクトを生みださない。当時はわたしも仕様書を作っていたが、それは設計者の佐藤がやっている作業であって、プロマネを兼務している方の佐藤の仕事ではない。プロジェクト・マネジメントというは、財務会計的に言うならば『間接業務』なのである。では、その間接業務は、プロジェクトの価値にどう貢献しているのか。

経済学風な言い方を借りれば、価値には使用価値と交換価値がある。使用価値は効用、交換価値とは市場価格といってもいい。プロマネという人材の市場価値なら、考える事はできる。しかしプロジェクト・マネジメントはモノではないから、交換価値は考えにくい。「サービス」ととらえることは可能だが、具体的な個別プロジェクトのマネジメントだけを、市場にとりだしてサービスとして売ることはできるのか? わたしには疑問である。

そもそも、最初から最後まで順調な仕事では、プロジェクト・マネジメントなんて、ほとんど何もすることがないはずなのだ。優秀なチーフ・デザイナーが気の利いた基本設計をする。それを実直なエンジニア達が詳細設計に展開する。そして辣腕の調達マンが手配し、百戦錬磨の工事管理部隊が業者を采配していく。小規模なプロジェクトなら、それで一丁上がりである。だとすると、プロマネの使用価値などないから、客観的な計量はできないことになる。何も機能しないのに、価値があるという議論など成り立たない・・。どうどうめぐりになって、わたしの思考は途切れた。

その日の午後の打合せは、何とか前向きに終わった。わたしの能力と言うよりも、制御メーカー側の技術者が優秀だったおかげである。一番の問題は、制御システムに冗長性をどう確保するかだった。いや、制御系に限らず、工場を作る際につねに問題になるのが、冗長性の確保である。冗長な機器構成は、ある意味では余裕であるが、見方によっては単なるムダにしかならない。冗長化すれば、それだけコストが高くなる。競争環境下では、コストは安い方が有利だ。だが、冗長性をけずってしまうと、いざというときにシステムが動かず、可用性が下がってしまう。ただし、この費用はすぐには見えない。表面的な価格だけを見ると、冗長性を削った方が安くなる。

だから、欧米系で本当に第一級のグローバルな企業は、ふつう、工場設計における『設計思想』として、どこにどこまで冗長性を持たせるかの指針を、文書で定めており、われわれもそれに従って見積もることになる。まあ、そうした文書があっても、しばしば解釈で揉めるのだが、日本企業でこのような指針を明文化しているところは稀だ。このときの顧客も、もちろん持っていなかった。しかし、この制御メーカーは、スタンバイ機を通常は別の軽い用途に使用しておき、いざというときだけフェイルオーバーする方法が可能だと提案してきた。あとは、明日、顧客との打合せで、この方式を飲んでもらえばいいだろう・・。

ホテルに戻って夕食をとり、リラックスしているときに、急にふと気がついた。冗長化したバックアップ機というものは、本来は普段、何の仕事もしていない。だが、それは価値があるのだ。なぜなら、いざというときに、システム全体が倒れずにすむからだ。機能していなくても、存在するだけで価値があるもの。それは目の前にあったではないか。その価値は、すべてが正常に動いている普段は、まったく目に見えない。しかし、いざというときになると役に立つのだ。プロジェクト・マネジメントというものもよく似ている。順風満帆なときは、別に大した仕事はしていない。物事が難しくなったり環境が急変したときに、その真価が現れるのだ。つまり、リスク環境下でこそ、マネジメントの価値は測れるのである。

何となくほっとして寝ようとしたら、部屋に電話がかかってきた。今朝、遅刻した彼からだった。奥さんは無事、出産されたらしい。おめでとう、とわたしは言った。「いてくれて助かったと、家内は感謝していました。」そう彼は答えた。「自分はそこにいただけで、何もできなかったですけれど。」

何もできなくても、存在しているだけで役に立つことが、この世にはあるのだ。


<関連エントリ>
 →「MES(製造実行システム)とは何か」 (2009-09-09)
by Tomoichi_Sato | 2014-10-05 23:52 | プロジェクト・マネジメント | Comments(0)

イノベーションのもう一つのジレンマ

数年前、「知的創造の現場―プロジェクトハウスが組織と人を変革する」という本の出版企画にかかわった。これは米国MITのビジネススクール教授でイノベーション研究の専門家であるトマス・アレンと、ドイツをリードする著名な建築家グンター・ヘンという、異色の組合せによる共著の本で、製品開発プロジェクトの組織設計とオフィスの作り方に関する最新の研究と実践例を述べたものだった。非常に重要なテーマであるにもかかわらず、日本では本書が注目されないばかりか、このようなテーマと問題意識が欧米にあることすら知られていないので、わたしの勤務先が監訳する形で訳書を出すことになった。

e0058447_16342838.gif

さて、翻訳作業がそれなりに進んだ段階で、訳書のタイトルをどうしようかと議論になった。原題は"The Organization and Architecture of Innovation"という、格調高くもアカデミックなフレーバーの漂う題である。ところで出版社の編集の方いわく、「この頃は、多少長くても読者の問題意識にズバリと刺さるようなタイトルがはやる」とのことだった。たとえば、当時売れていた本に、『スタバではグランデを買え』などがある。なるほど。それともう一つ言われたことは、「イノベーション」という言葉はすでに手垢がつきはじめているという意見だ。陳腐化しやすいので、タイトルそのものには使いたくない、とのことだった。

あれこれ悩んだあげく、皆で選んだのが『知的創造の現場―プロジェクトハウスが組織と人を変革する』というタイトルだった。「イノベーション」がダメなら、せめて「プロジェクト」という言葉を入れたい、それがわたし達の希望だった。だが、これが読者に”刺さる”タイトルだったかというと、かなり微妙だ。我々エンジニアには、まだ十分なマーケティング・マインドが足りない、ということかもしれない。

ところで、著者の一人トマス・アレンは、ちょっと変わった経歴を持つ学者だ。彼はもともと、ロッキード社のリサーチ・エンジニアだった。「リサーチ・エンジニア」という職種名自体、日本ではあまりポピュラーではないかもしれない。研究開発に携わる技術者という意味だ。「研究開発に携わる科学者」ではない点に注意してほしい。

わたし達の社会では、「科学技術」というような言葉があって、両者を一緒くたにする傾向があり、特にお役人にそれが強いが、科学者と技術者とは全く別のものである。科学者の動機は、科学自体に内在する知的興味にある。有益であれ何であれ、興味深い知識・知見を、人類にとって積み重ねることができれば、それで科学者は満足する。そのかわり、そこには理屈が通っていなくてはいけない。

ところが技術者はまったく違う。技術では具体的な成果が得られるかどうかが勝負だ。たとえそれが製品開発のような不確実性の高い分野であっても、である。そして良い結果が出れば、理屈に多少不明な点が残ってもそれでいい。そこでは集団的な、組織的な経験・知見の集合がものをいう。科学者が原則として個人で評価される(その当否は別として)のに対し、技術力は一種の組織力である。

聞くところによると、リサーチ・エンジニアだったトマス・アレンは、MITの経営大学院であるスローン・スクールで製品開発のマネジメントを勉強しようと思ったらしい。しかし、そこの教授にについて色々と質問しても、製品開発は非常に漠とした難しいテーマで、専門家はほとんどいない、という状況だった。そこで彼は一念発起し、こうなれば自分が専門家になる以外ない、と研究の道に踏み込んだという。まだ70年代ごろの話だ。

製品開発に専門的研究が無かったのも、無理はない。そもそも新製品開発はどこの企業でもマル秘事項であり、成功しても失敗しても外に出る情報はほとんどない。そんな中、アレンは色々な苦心をして事例調査と研究成果を積み上げて行く。

彼の業績の一つとして知られるのが、「研究開発における組織内コミュニケーションの重要性」の研究である。発明とは、すでに知られている要素の組合せである事が多い。その場合、組織内でいろんな知識を持ったもの同士が意見をかわし、「気づき」を生み出すチャンスが重要になる。だから、組織の構造と、その内部でのコミュニケーションの質・量に注目したのだ。

彼が発見したのは、ある意味あっけないほど単純な法則性だった。それは、コミュニケーションの量は、その二つの部門(あるいは二人の個人)の物理的な距離に依存するという事実である。近くにいれば、会話量が多い。遠ければ、少ない。彼によると、二つのチームが50m以上離れていると、(たとえ組織図の上では同一部門であろうと)ほとんどコミュニケーションがなくなってしまう。多分、週に一度とか月に一度の公式な会議などでは顔を合わせるだろうが、それ以外のやりとりは滅多にない。

そんな馬鹿な、電子メールってものがあるだろ。そんなのは昔の話だ、とお思いだろうか? もちろん、アレンはそれについても調べている。そして結果は同じだった。電子メールは、顔を合わせる機会のない相手には、あまり発信されないのだ。だから、組織図の上だけでなく、実際の配置においても、組織設計はよく考えねばならない。

--このアレンの研究は、日本ではほとんど注目されなかったようだ。初期の著書の翻訳は1冊出たが、あまり売れたふしもない。無理もない。なにしろ、マネジメントは科学の対象である、とは夢にも思わぬ人が大半なのだ。

しかし、ドイツではこれに注目した。自動車メーカーのBMW社がその筆頭である。BMWでは、新製品開発と生産の距離を縮め、技術の共有をはかりつつ、なお製品開発の効率を上げるにはどうしたら良いかを考えてきた。そこで建築家のグンター・ヘンの登場である。彼はアレンの問題を、建築面から解決する方法を考えた。そして、建築空間の中に人の流れる「軸」(spine)を作るとともに、そこでの人と人の偶然の出会いが増えるようなデザインを考えたのだ。

また、彼は組織と組織を隔てる壁の一部を素通しのガラスにしたり、ロー・パーティションを使って、違う階の人も顔が見える(在席がわかる)ように工夫した。こうして完成したBMWのプロジェクトハウスProjekthausは、専門技術者たちが作りかけの新車のモックアップのそばで出会いやすくなっており、同社のコミュニケーションは質的に大幅に向上したという。彼らはまた、同じような発想を工場にも取り入れて、新しい画期的なレイアウトを実現してきている。

もともとイノベーションには二重のジレンマがある。その一つはクリステンセンが指摘した「破壊的イノベーションのジレンマ」で、ベストセラーになった『イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき』に詳しく書かれている。破壊的イノベーションは当初、むしろ最先端よりも劣った技術として登場する。そしていつの間にか主流の持続的イノベーションの力を奪って行くのである。

もう一つはプロジェクト・マネジメント上のジレンマである。イノベーションは定義上、それまで誰も知らなかったものを生み出す行為だ。では、そのようなイノベーションを含む新製品開発というプロジェクトを、計画したりコントロールしたりすることは本当にできるのか。なりゆきまかせ風まかせ、では企業としてこまる。しかし、最初からすべてを見通して、WBSやCPMのネットワーク・ダイアグラムなんて作れるのか? どう見たって無理ではないか。

わたし自身も、新製品開発プロジェクトに関わった経験がわずかながらある。一番悩んだのは、スコープとスケジュールのジレンマであった。新製品開発は本質的に不確定要素が多い。したがって、スケジュールの要所要所に、バッファーを用意して、予期しない変化から納期を守る必要があると考えた。ところが新製品開発には市場をいかに早くつかむかが大事で、競合相手もあるから、できるだけバッファーを削って納期を早めたい。営業政策上、リリースの時期は外部に事前に公表する必要がある。最後は、製品の機能をとるかスケジュールをとるか、というトレードオフに何度も直面することになった。

これは、受注型プロジェクトのマネジメントとは随分異なる。受注ビジネス型企業では、赤字か黒字かは天と地ほどの差がある。たとえ1万円でも赤字は赤字である。しかも契約納期がある。だからジレンマはほとんどの場合、コストとスケジュールの間にあった。スコープはそもそも契約条件だから、これを勝手に変える訳にはいかない。ところが新製品開発では、1万円を惜しんで製品の大事な機能を削ったら、愚か者と言われる。予算枠はあるが、それはゴムのように多少伸縮可能なのである。ただ、機能はつけ加えたい、しかし納期は遅らせたくない、おまけにあとから機能を追加・削除したら、あちこち変更管理の手間が生じる。それをどうするか。

したがって、製品開発と受注業務とでは、マネジメントのスタイルも価値基準も変えなければいけない。この観点が、現在のPM論では抜け落ちているようなのだ。

そこで今週26日(金)の「プロジェクト&プログラム・アナリシス研究部会」では、新製品開発の専業である(株)iTiDコンサルティングの蟹江氏を招いて、『製品開発競争に打ち勝つスケジューリング』のお話しを聞くことにしたのである 。とくにスケジューリング技法の話が興味深い。PMBOK Guide(R)では、納期短縮のテクニックとして、CrushingとFast trackingの二種類のみがあげられている。しかし氏によると、実際の短縮技法は7~8種類に分類できるという。慶応大学システムデザイン・マネジメント研究科での特別講義の一部を、無料で聞けるチャンスでもある。ぜひ、製品開発に苦労しておられる製造業・サービス業の諸賢にご来聴いただきたい。

え? 宣伝くさいオチの付け方だって? そういわれてもあえて反論はしない。ただし、研究部会は自分の金儲けでやっている活動ではない。参加費も無料だし、わたしも純粋にボランティアで運営している。スポンサーであるスケジューリング学会が、この活動に多少なりとも価値を認め、続けてもいいかなと判断してくれるよう、「参加して良かった」と感じる方が大勢こられることを期待しているだけである。--「なんでわが社は(わが業界は、わが国は)画期的な新製品が出ないんだ!」とビール片手に叫ぶよりは、多少なりともマネジメント・テクノロジーの一端に触れて感じる方が、金曜の夜の過ごし方としては楽しいはずである。


<関連エントリ>
 →「(書評) "The Organization And Architecture of Innovation" by T. Allen and G. Henn」 (『知的創造の現場―プロジェクトハウスが組織と人を変革する』の原書)
by Tomoichi_Sato | 2014-09-21 16:36 | プロジェクト・マネジメント | Comments(0)

プロジェクト・マネジメントの理論は科学たり得るのか 〜 EDEN PM Seminarに参加して

8月下旬に、フランスのリール市で開催されたPM研究の国際セミナー "EDEN PM Seminar" に参加してきた。招待を受けて1時間ほどの講演をし、また他の発表を聴きながらPM理論の専門家達とネットワーキングを深める、楽しい4日間だった。わたし自身は2008年、2009年につづき、3回目の参加である。

EDEN PM Seminar は、EUの資金援助をえて、毎年夏に開催されるセミナーだ。会場はフランスのSKEMA Business School経営大学院が提供している。SkemaはPM専門の大学院(博士課程)を持ち、欧州のPM研究のメッカといわれている。このセミナーにも、欧州を中心に、米国・中東・アフリカ・南アジアなどから多くの参加者があった。セミナーを実質的に仕切るのは、長年International Journal of Project Management誌の編集長を務めるR. Turner教授である。

e0058447_16142418.jpg


今年のテーマは、「Challenging Projects」。難しいプロジェクトの計画・遂行・評価をめぐって講演発表と議論がかわされた。わたし自身は、「Projects in Distant Terrains: Arctic, Deserts, and Rain Forests」と題して、わたしの勤務先が関わってきた遠隔地プロジェクト(アルジェリアの砂漠、パプアニューギニアの熱帯、そして北極圏)のケーススタディ分析と考察について報告し、好意的なフィードバックを多くの方から得た。ただし自分の講演の内容説明は別の機会にゆずることとし、今回はもっぱら、他の講演を聴いて考えたこと、感じたことなどを述べてみたい。

面白い発表はたくさんあったが、たとえばNASA(米国航空宇宙局)のRoger ForsgrenとEd Hoffmanの2人による「Projects in Difficult Terrains at NASA」をあげておこう。NASAはある意味、プロジェクト・マネジメントの育ての親であり、現在のPMの概念や手法論の多くがここから巣立っている。Dr. Forsgrenの講演は、地球外環境という極限領域における機材設備の設計や、乗組員の保護方法といった技術論を語るもので、エンジニアリングの観点から非常に興味深かった。-100℃から+100℃に数分程度でかわる温度、宇宙線、真空、荷電(宇宙空間にはプラズマが飛んでいる)、そして飛来する宇宙のゴミdebrisなどから、どうやって機材を守るかといった話である。地球外探査のVoyagerなど、その過酷な環境を、もう36年間も航行しつつ、いまだに地球に信号を送り続けている。たいしたものだ。

ちなみに彼によると、NASAは2025年までに火星に人を送り込みたいと計画している。航続期間は年単位であり、それだけの長きにわたり乗員が暮らせるような宇宙船の仕様を考えなければならない。また、とくに火星からの離陸と帰還が大きな課題である。それゆえ、会場からは「装備を軽くするために、NASAは乗員にone way ticketを渡す考えもあると聞いたが」との質問が出た。片道切符、つまり火星からは戻れないという条件で希望者を募る、という意味である。そうすれば装備はずっと簡単になり、実現可能性も高まる。広い米国には、それでも希望者はいるだろう(ジュール・ヴェルヌの「月世界旅行」はまさに帰還を考えない飛行の話だった)。しかし、「倫理的観点から、それは行わないだろう」との回答だった。

しかし、Dr. Hoffmanの話の方は、もっと含蓄に富むものだった。Dr. Hoffmanは、見かけはいかにも気のいいアメリカ人のおっさんだが、なんとNASAのChief Knowledge Officer(CKO)である。その彼のテーマは「Projects in Hostile environments」で、この『敵意に満ちた環境』として、彼は4つをあげる。まずは、Rough neighborhoods、つまり友好的でない隣人・国家。次がTyrants、つまり専制君主的なボスである。ここらへんから話はぐっと人間くさくなる。ある種の毒性のあるリーダーシップtoxic leadershipを発揮する連中がいて、彼らは部下に対して、"you are working for me, not for you."という態度で支配をはじめるのである。

3番目に、彼は「プロジェクト 対 組織」という対立の問題をあげる。NASAも役所であり、プロジェクトという一時的なチームと、永続的な組織との間にはしばしば緊張関係がある。そのよい例が、ゴダード宇宙センターの科学者Mather博士が発案したCOBE Projectであった。COBEは宇宙マイクロ波の背景放射を関するするための人工衛星であるが、この計画はスペースシャトル「チャレンジャー号」の爆発事故による影響で、NASAの中でキャンセルされてしまう。

しかし、そのときのプロマネは、「俺の仕事は解決策を見つけることだ My job is to find a solution.」と宣言し、なんと英国など他の国の宇宙機関からこれを打ち上げるべく活動をはじめる。結局、COBEは最終的には米国から打ち上げられることになり、その観測結果が宇宙ビッグバンを実証して、Mather博士はノーベル賞を受賞するのだが、これは、このときのプロマネの組織をこえた使命感がなければ実現しないものだった(この一部顛末は"The Very First Light"という本になってまとめられている)。Hoffmanが4番目にあげたのは文化的衝突 culture clash であった。

とはいえ、NASAの宇宙の話を聞いているとSF少年に戻ったみたいで、ワクワクと楽しい。それにひきかえ、地上でのプロジェクトは困難が多く、楽しいばかりではない。たとえば、途上国における援助プロジェクトである。ここでは、今回の発表の中でも秀逸だったDr. Lavagnon Ikaの「世銀の監督はプロジェクトに影響を与えるか? Does World Bank project supervision influence project impact?」を紹介しよう。Dr. Lavagnon Ikaはアフリカのベニン出身で、現在はカナダのオタワ大学で働く優秀な若手PM研究者である。

彼はまず、世界における国際援助の統計をざっと紹介した上で、「果たして国際援助というのは機能しているのか?」と問題を投げかける。そして、"Aid is part of the problem and even is the problem”という途上国側の意見 (Moyo, Zambia出身)を紹介する。経済学的な実証研究からみて、マクロ経済学的には、国際援助額とその国の成長との間には相関が見られない。ただしミクロ経済学的な、プロジェクトレベルでは、たしかに有効性は確認されることが多い。ここには、マクロとミクロの矛盾があるのである。


そこで彼は、世銀のSupervisor制度について、215ものプロジェクトを対象にサーベイ研究を行うのである。世銀は自分が融資したプロジェクトに対して、Supervisor制度をもうけている。彼らは、プロジェクトの成功のためのカギ(Critical success factor)として、以下の5つを考えている。
- Monitoring
- Coordination
- Design
- Training
- Institutional environment

ところでDr. Ikaは、最近のPM理論のトレンドにしたがって、プロジェクトの成功を、『遂行上の成功』と『インパクトにおける成功』に区別する。「上手に遂行できた(予算や納期を守った)」ことと、「プロジェクトが良い効果を生んだ」ことは別だと考えるのである。この二つは、残念ながら日本では、まだきちんと区別されずにごっちゃに論議されがちである。

その上で、彼は調査分析の上で、世銀のProject supervision制度は、『遂行上の成功』はたしかに促すが、『インパクトにおける成功』はもたらしていないことを明らかにするのである。Supervision制度は、プロジェクト全体費用の 3%-5% を占めている。金額にすれば、かなり高額だ。だから、とくにプロジェクト計画段階におけるsupervisionをもっと充実させるべきだ、というのが彼のリコメンデーションである。

プロジェクトには、直接の成果物(output)と、それが生みだす結果(outcome)、そして、プロジェクトがもたらす効果・影響(impact)がある。それは短期・中期・長期的なプロジェクトの評価に対応する。こうした視点が、世銀をはじめとする海外援助にはまだ欠けている、というのが彼の問題意識であった。日本のPMコミュニティでの議論を思い返すにつけ、同じ思いを、わたしも感じた。

さて、このEDEN PM Seminarには、最新のPM研究の成果報告と別に、もう一つの柱がある。それは、SKEMA Business Schoolで学ぶ博士課程の院生(PhD Candidate)が、並みいる世界のPM研究者達の前で、学位論文の最終発表と審査を行ったり、博士研究の提案(Proposal)をしたりするのである。これを聴いていると、欧米におけるプロジェクト・マネジメント理論の研究がどのような形で、いかなるレベルで行われているかを目の当たりに見ることができる。

たとえば、以下はLynn Keeysという院生の研究提案のスライドからとったものである。研究パラダイムとしてはConstructivism(構築主義)をとり、コンセプトとしては「企業の持続的発展(SD)戦略から、プロジェクトのSD戦略の創出」をかかげ、理論として「創出的戦略(Emergent Strategy)」に依拠して、以下、モデルの提案、方法論と研究戦略、具体的研究方法・・という風に続く。

e0058447_16244247.jpg


これを見ると、欧米(とくに欧州)の研究では、方法論を重視し、博士課程の院生はそれを徹底的に叩き込まれることが分かる。「これこれを調べてみました。するとこんな結果になりました。だから自分はこう考えました」では、全然研究として認められないのである。わたしは前回、アメリカ人の院生が、自分の所属するデミング賞認定機関の過去データを分析して、品質改善プロジェクトについて研究提案をしたのを覚えている。たしかにそれだけのデータがあれば、かなり面白い分析ができるだろう。しかしそのときは、会場にいた大御所のLynn Crawford教授から、「あなたはどんな理論的枠組みでそれを分析しようとするのか」と問いかけられ、うまく答えられずにコテンパンにやられるのを目撃した。

なぜ、単に事実を報告し分析するだけでは研究としてダメなのか。それは、プロジェクト・マネジメント研究、いやマネジメント研究一般の根幹に関わる問題である。プロジェクトというのはその定義上、本質的に一回限りであり、同じものは二度とない。同じものが何度も繰り返されるなら、それはプロジェクトではなく「定常業務」になってしまう。そして、多くの人間が関わる作業であり、その報告も基本的に言葉を通じてなされる。数字はあるだろうが、言葉の説明も必須だ。

このような条件で、プロジェクト・マネジメント研究が科学的な客観性を保つためには、どうすべきなのか。単に観測事実を論評するなら、評論家、いや街場の居酒屋トークと何も違いがないことになる。それが研究であるためには、そして他の人にも普遍的に役立つためには、自身の研究スタンスや、その限界について、きわめて意識的でなくてはならないのである。わたしは今回、オイル・メジャーで働くエチオピア出身の院生に声をかけられて、研究のアドバイスを求められたが、彼の研究ノートにも、こうした方法論がびっしりと記述してあった。

そして、このような思考の態度を身につけることが、ドクターの学位を得ることの意味なのだろう。Skemaで博士号をとろうとしている院生達は、ほぼ全員、社会人である。修士課程を出て、そのまま博士に進んでいる院生は一人も見かけなかった。そして、ほぼ全員が、中年である(^^;)。これは、プロジェクト・マネジメント研究という分野の特徴なのだろう。学士か修士でいったん、社会に出る。そしてプロジェクトに従事する。だが、年月を重ねるうちに、しだいに内なる問題意識が強まってくる。そうして、もう一度きちんと考え直してみたいと、大学に通い始めるのだ。電子工学の研究なら、20代前半でまったく問題ない。だがプロジェクトでは、自分がマネジメントにかかわった経験年数がものをいう。

言い忘れたがSkemaでは、PMの博士号は、遠隔地で働きながらとることができるシステムである。限られた回数の集中講義は必要なようだが、あとは指導教官たちとやりとりしながら研究を進められる。今回もフランス以外の国から大勢の院生が集まっていた。欧州からも、北米も、南米も、アフリカ、中東、南アジア、中国などから、皆が学位取得の情熱を持って参加している。この人達は、別に全員が大学の先生になろうと思っている訳ではない。じっさい、Seminarで講演する側の人間も、(わたし自身を含めて)実務社会で働いているものが約半数である。今回、パキスタンでPM協会を立ち上げて会長を複数期つとめたDr. Khalid Khanと知り合い、何となく意気投合した(同じ化学工学出身だったのだ)が、彼も働きながらSkemaで学位を取った人だった。

e0058447_16263353.jpg

(SKEMA Business Schoolの内観)

なぜ、彼らは、自身がプロジェクト・マネージャーとして忙しく働きながら、なお、博士研究までしようとするのか。別に大学教授になろうという訳でもないのに。それはたぶん、二つの理由があるのだろう。一つには、彼ら自身が持つ、使命感である。何とかプロジェクト・マネジメントというものを良くしたいとの使命感。もっとプロジェクトの成功率を高めたいという、強い熱意。

もう一つは、おそらく社会の側にある。欧米、あるいは植民地として欧米の影響下にあった国々もそうなのだろうが、こうした地域では、博士号を持った、つまり高度に知的なリソースをもった人材を、それなりに遇する制度があるのである。研究職だけでなく、ビジネス部門や行政職でも、そうした人々を活用する仕組みがあるらしいのだ。

ひるがえって、わたし達の社会ではどうか、とつい思ってしまう。日本にはあいにく、そもそもプロジェクト・マネジメントの博士課程を持つ大学は存在しない(わたし自身は化学システム工学という専攻科で、「ほんとに化学と無関係な、マネジメント研究でもいいんですよね?」と指導教授に念を押しながら学位を得た)。社会人博士も、通常は、週に1,2回、大学に通う必要がある。そして、企業では、博士号を持っている人は研究所勤めが普通である。だから、マネジメントの研究で学位を取ろうというモチベーションが、きわめて得にくい。その結果として、「プロジェクト・マネジメント理論が科学たり得るためには、どうしたらいいか?」といったレベルの議論ができる場所も、極めて限られている。

わたしはこのような現状を、とても残念に思う。研究というのは、すべて科学や医学や工学といった、製品開発に直接結びつく「実学」であるべきで、Management Scienceとかマネジメント・テクノロジーとかいった分野があろうとは思いもよらない、という知的風土に、わたし達は育った。そして、そのこと自体が、我々の社会のブレイクスルーを阻害しているのではないか。まあ、そうした大げさな問題をわたしがすぐ解決できるとは思わないが、せめて自分が主催する研究部会くらいは、こうした問題のフレイバーだけでも議論できる場所に育てたいのである。

もちろん、今だって、たとえばそれこそ仏Skemaに遠隔入学するという手段はある。現時点では、残念ながら日本人の院生はゼロだった。主要大国でゼロなのは、たぶん日本だけだろう。こういう現状を何とかしたいと、わたしも微力ながら思うのである。そして、プロジェクト・マネジメントの実務に日夜苦労していて、この状況を何とか変えたいと願う人が、知的な出口を見つけ出せる世の中になってほしいのだ。


<関連エントリ>
 →「プロジェクトにとって成功とは何か ~ESC Lille PM Seminarより」(2008-09-05)
 →「知識労働、肉体労働、そして『感情労働』」(2011-08-19) (Constructivism「構築主義」について)

(追記:今回のSeminar参加にお声がけいただき、講演機会を得るチャンスをくださったSkema客員教授の田中弘氏に改めて感謝します)
by Tomoichi_Sato | 2014-09-14 16:32 | プロジェクト・マネジメント | Comments(3)

「プロジェクト&プログラム・アナリシス研究部会」(2014/09/26) 開催のお知らせ

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

今回は、製品開発プロジェクトのスケジューリングについて、この分野の専門家である(株)iTiDコンサルティングの蟹江淳様にご講演をお願いすることにしました。

新製品開発では、納期短縮と変更管理を両立させることが、プロジェクト・マネジメント全体の急所になります。納期を短くするためには複数の作業を平行に進める必要がある。 しかしそうすると変更が生じた時のインパクトが大きくなる--この矛盾を、どのように克服するか。自動車業界をはじめ、多くの企業に対し、製品開発の専門的コンサルティングの実績をお持ちの蟹江様から、その勘所を教えていただきますので、ぜひご期待ください。

<記>

日時: 2014年9月26日(金) 18:30~20:30
場所: 慶応大学 三田キャンパス・北館・会議室3(地下1階)
    アクセス http://www.keio.ac.jp/ja/access/mita.html
    ※キャンパスマップの【1】になります

講演タイトル: 「製品開発競争に打ち勝つスケジューリング」

概要:
 顧客ニーズの変化は激しく、開発途中の企画変更が当たり前になりつつあります。 一方で、開発スピード競争は留まるところを知らず、納期の前倒しも頻発しています。 本講演では、自動車業界を中心に広まりつつある、開発競争力強化に不可欠な変更対応とスピード開発を両立するプロジェクト・スケジュールリング手法と納期短縮の8つのワザをお知らせします。

講師: 蟹江 淳 (株式会社iTiDコンサルティング)

講師略歴:
 早稲田大学商学部卒業。大手ITシステム会社にて、セールスエンジニアとして電機・通信企業を中心とした製造業の支援に従事後、iTiDコンサルティングに参画。 大手自動車メーカーや自動車部品メーカーに対する開発効率化、開発期間短縮の実績多数。 コンサルティングに加え、DSM(Design Structure Matrix) Conferenceにおける海外講演、慶應大学大学院SDM研究科附属SDM研究所特別講座講師等を通じ、精力的に製造業の開発力向上に取り組んでいる。

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

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

以上
by Tomoichi_Sato | 2014-09-01 19:01 | プロジェクト・マネジメント | Comments(0)

お知らせ: システム制御情報学会誌にプロジェクト・マネジメントに関する論文を書きました

 システム制御情報学会の学会誌である「システム/制御/情報」第58巻第6号(2014年6月)は『プロジェクト・マネジメントにおけるシステム・情報技術』の特集号ですが、ここに、

プログラム&プロジェクト・マネジメント理論の全体概念」(佐藤知一)

という解説論文を書きました。構成は以下の通りです:

  1. プロジェクト・マネジメントとは何か
  2. プロジェクト・マネジメント理論の発達小史
  3. マネジメント理論の領域と手法
  4. 情報技術とプロジェクト・マネジメント
  5. プロジェクト、プログラム、ポートフォリオ
  6. プロジェクト・マネジメント関連の標準化動向
  7. おわりに

 この特集は全体で5本の論文と基礎用語集から成る特集で、わたしの上記の論文は、そのイントロダクションとしてプロジェクト・マネジメント理論を概観したものです。学会の依頼で半年ほど前に書いたものでしたが、読み直してみると、なかなか良く書けています(←自分に甘い評価 ^^;)。

 ところで、システム制御情報学会は伝統のある大きな学会ですが、学会誌は一般の書店や図書館などでは、なかなか見つけにくいと思います。また著作権の関係から、自分の論文の電子ファイルを、勝手にホームページなどで公開することはできません(一定年月がたつと学術データベースで公開されますが)。

 しかし、学会論文には「別刷り」の配布という、古くからの良き習慣が残っています。そこで、もし上記の論文を読んでみたいという方がいらっしゃれば、佐藤までメールにてご連絡ください。
 よろしく。


日揮(株) 佐藤知一
by Tomoichi_Sato | 2014-08-01 20:21 | プロジェクト・マネジメント | Comments(0)

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

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

三角形の一片の長さは、他の辺に影響を与えずに変えることができない。同じように、プロジェクトの三つの制約条件は、独立でなく必ず他と関わり合っている。例えばプロジェクトのやるべき責任範囲である「スコープ」が増えたとしよう。すると「コスト」が増えるか、「スケジュール」が伸びるか、あるいはその両方が必ず起きる。そこでプロジェクトマネージャーは、これら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という具合だ(図参照)。この対応関係は、偶然の産物ではあるまい。プロジェクトを運営して行くにあたって、最大の制約条件を何とかコントロール下におさえるべく、上記三つの技法がそれぞれ発達してきた、という事情なのである。

e0058447_22443372.gif


ちなみに、プロジェクトの難しさや失敗率について語るとき、米国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はまさに、歩きながら考える英国文化の産物なのだろう。

<関連エントリ>
 →「プロジェクト・リスクとは目標の反対概念である」 (2013-09-08)
by Tomoichi_Sato | 2014-07-21 22:51 | プロジェクト・マネジメント | Comments(0)

プロジェクトは失敗するものである、という英国人の思想

1993年3月、ロンドン証券取引所は、ビッグバンを背景に7年にわたって進めてきた、株式取引決済システム「トーラス」開発プロジェクトの中止を発表した。証券取引所はすでにこの事業に8000万ポンドの費用を投じており、人件費を含むシティ(ロンドン金融街)全体の投下コストは、総額5億ポンドに上っていた。証券取引所のP・ローリンズ理事長は、責任をとって辞任する。

「トーラス」は、株式売買のバックオフィス業務である株式決済処理の電子化・効率化を目的とした、英国金融界の共同事業で、中心的な推進役はロンドン証券取引所であった。トーラスは米国のパッケージソフト「ヴィスタ」をベースに開発されることになっており、本来ならば、'91年10月に稼働しているはずだった。それは一度、'92年夏に延期されていた。しかし、中止決定時点では'93年中の稼働すら危ぶまれる状況だった。

ちなみにこのプロジェクトは、ローリンズ理事長がはじめたものではない。'89年に弱冠38歳で理事長職に着任した彼は、その後の数年間、シティの規制緩和への対応に忙殺されていた。それがひと段落したとき、「トーラス」プロジェクトを見て、それが容易ならざるものであることに気づいたのであった。その当時、プロジェクト・マネージャーであったクーパース&ライブランド社のJ・ワトソンは、稼働開始日見通しの記者質問に絶句して答えられない状況だった。ローリンズ理事長は第三者のアンダーセン・コンサルティング社にプロジェクトの調査を依頼する。約3ヶ月間の調査の後、アンダーセンは、「トーラスの設計は未完成」と報告する。

結局、ローリンズ理事長は、この「トーラス」プロジェクトと差し違える形で辞任する。それは同時に、何年間も長時間の労働に耐えてきた、シティの大勢のSEとプログラマたちの失業をも意味していた。

この巨大プロジェクトが、いかなる経緯をとって迷走し頓挫したかについて、我々は詳しく知ることができる。経営学者ヘルガ・ドラモンドが、関係者への徹底的なインタビューを含む詳細な調査研究を行い、『プロジェクト迷走す―ビッグバン「トーラス」システムの悲劇』という本にまとめて公開したからだ。この本はきわめて興味深いアカデミック・ドキュメンタリーとなっている。

誰の目にも混乱を極めていたトーラス・プロジェクトを、関係者たちはどうして途中で止められなかったのか。従来の経営学では、(1)それまでにつぎこんだ損失に目が眩んで、合理的な決定ができなかったのだ、あるいは、(2)情報の不確実さゆえに、正しいリスク判断ができなかったのだ、という説明がなされてきた。いずれも、意思決定が合理的に行われなかったのだ、という解釈である。

しかしドラモンドは、プロジェクトの経緯を詳しく調べて、そのどちらも当たっていないと考える。そして、合理的な意思決定の積み重ねが、全体としては非合理な意思決定を導く、という第3の理論を提案する。ひとつひとつは当然にみえるミクロな意思決定の集積が、マクロにはまったくの不合理を導く。これを、ドラモンドは「意思決定エスカレーション」理論と呼んだ。

ドラモンドの理論の当否については、いろいろな議論があるだろう。だが、わたしが感心するのは、このような大きな失敗事例が、きちんと第三者によって検証され、分析が行われるイギリス社会のあり方である。これを英国文化のもつ理知性と公明正大のあらわれ、と解釈することも可能だろう。いやあ、英国人特有の変てこな自虐趣味さ、と皮肉ることもできる。だが、ともあれ、社会的資本を投下した事例については、その経緯や結果について、第三者による検証が必要だ、との発想が、彼らにははっきりある。

英国は失敗の研究がよく行われる、とも言える。もちろん日本でも、畑村洋太郎氏の「失敗学のすすめ」というベストセラーがあるし、「失敗学会」という学会組織もあって、失敗事例研究の普及につとめている。ただ、逆に言えば、そのような学会を作って旗振りをしなければいけないほど、わたし達の社会では「臭いものに蓋」という態度が蔓延している訳である。

当たり前のことだが、失敗を研究し分析しても、そこから教訓を学んで同じ轍を踏まぬよう努力するのでなければ、無意味である。失敗からの「学び」こそ、リスク・マネジメントの要(かなめ)なのだから。

もう一つ、英国の例を挙げよう。『FIDIC標準契約約款』と呼ばれる、海外の建設プロジェクトで広く使われる契約書の雛形がある。歴史はそれなりに古いものだが、1990年代の終わりに、英国主導で大きな改訂が行われた。これはじつは、80年代以降、英国で建設プロジェクトの失敗が相次いだためだったといわれている。

なぜ失敗プロジェクトが相次いだか。その最大の理由は、「発注者が請負業者に対して、あまりにも過剰にリスクをヘッジするような一方的な契約条件を求めたため」であった。もともと一括請負契約は、発注者がある程度のリスクを受注者にヘッジする形態である。だが、受注者のリスク管理能力を超えてリスクを押しつけすぎると、受託側がプロジェクトを正常に遂行できなくなる。結局、受注者が発注者と一蓮托生に沈没してしまう事例が、多く出たのである。その失敗の反省にたち、FIDIC約款は、受注者に対してよりフェアーとなるよう、条項を明確化したと言われる。まことに大人の知恵ではないか。

ちなみに契約法務の世界では、いわゆる商務仲裁機関も英国が主導している。さらに、損害保険(再保険)の世界も、英国がメジャーだ。彼らはリスク・マネジメントに関しては徹底している、と言うべきだろう。そして、「仕組みを作って世界を動かす」ことにかけては、たしかににたけている。

英国が自国向けに標準を作ると、それなりに実際的である点も特徴である。たとえば、プログラム・マネジメントの分野で、米国PMIのThe Standard for Program Managementと、英国商務省のManaging Successful Programmes (MSP) を読み比べるとわかるが、後者の方がずっと分かりやすく、何をどうすればいいか具体的である。「PMIの標準は、コンサルタントを呼ばないと分からないよう、わざと抽象化して書いている」という人もいるくらいだ。それと、MSPは、限られた少人数で著述しているらしく、全体の記述に一貫性があり、たしかに読みやすい。なお、ついでながらプログラムという語のスペリングが、米国と英国で少し違っている点も面白い。

同じ英国商務省が、プロジェクト・マネジメントに関して制定した標準がPRINCEである(現在はPRINCE2となっている)。PRINCEは元々、英国の官公庁で発注するコンピュータ・システム開発のプロジェクトに失敗があまりに多いため、それを改善するために生まれたと言われている。日本プロジェクトマネジメント協会の元理事長で、現在は北陸先端科学技術大学の教授である田中宏さんに以前うかがった話によると、PRINCE2というのは、“プロジェクトというものは放っておくと失敗するものである”という思想が根底にあるのだそうだ。まあ、たしかにこの「自虐的」規定の仕方は、いかにも英国人風である。だが、彼らが確立した立憲君主制や三権分立制などに見られるように、制度設計というものは、“放っておくと失敗する”という発想をベースに考えた方がリスクが小さいのである。

マネジメント標準というのは、それに従っていれば万事うまくいく、というような魔法の教科書ではない。せめてこれぐらいは知っておいた上で、自分の仕事にあわせて取捨選択しろよ、という体系的な道案内の書である。それを読むには、読み手のインテリジェンスが必須である。

ところで、このインテリジェンスというものは、知識や法則や論理的演繹といった、「頭の良さ」だけではないらしい。むしろ、自分はまだ一度も歩いたことのない道なのに、この先に何かがありそうだと察知するような能力のことを、インテリジェンスとよぶのである。わずかなデータしかないのに、何だか価値がありそうだと気づいたり、ヤバそうだと感づく嗅覚のような能力--それこそが、プロジェクトという深い森の中を正しく導く、導き手なのである。

だからインテリジェンスというものは、こまったことに、経験によって深まったり、逆に鈍ったりする。自分がいかに何も知らないかを分かれば、深まるし、なあに所詮こんなものよ、と知ったつもりになれば、逆に能力は鈍るものらしい。単なる経験年数ではない。経験から、何をどう学ぶか、なのである。

わたし自身がインテリジェンスをもちあわせているなどと言うつもりは、もちろん、さらさらない。だからこそ逆に、失敗に学ぶのがお好きな英国発のプロジェクト・マネジメント標準PRINCE2がどんなものか、知りたいと思って、今週、研究部会で講演をお願いした次第なのである。PMBOK Guide(R)は読んだけど、何だかもの足りない気がする--もう少し別の知恵はないのだろうか、そんな疑念をお持ちの同輩諸賢のご参加をお待ちする次第である。


 →「プロジェクト&プログラム・アナリシス研究部会」(2014/07/01) 開催のお知らせ

<関連エントリ>
 →「組織におけるルールはいかなる機能を持っているのか
by Tomoichi_Sato | 2014-06-29 23:12 | プロジェクト・マネジメント | Comments(0)

「プロジェクト&プログラム・アナリシス研究部会」(2014/07/01) 開催のお知らせ

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

今回は、落合和雄氏に「PRINCE2」についてご講演をお願いすることにしました。

皆さんは、PRINCE2という名前を聞いたことがおありでしょうか? PRINCE2は、英国発のプロジェクト・マネジメント標準資格で、英国商務局が開発したものです。 現在、この種のものは米国発のPMBOK Guide/PMP(R)が日本ではメジャーで、ほとんどこれが唯一の『グローバル・スタンダード』だと信じている人もいるようです。しかし、それは違います。最近ではPRINCE2が世界的に注目を集めており、資格受験者数もPMPを追い抜こうという勢いです。その理由は、抽象論ではなく、実務者のために具体的に使える方法論をめざして開発されているからです。

また、PMBOK Guideが最初からどの産業をも全方位的にカバーしようとしているのに対し、 PRINCE2は元々IT系プロジェクトを対象とした標準から出発し、他分野にも適用範囲を広げてきたことも特徴です。このため、とくにIT分野に対して親和性の高い資格となっています。

講師としてお招きした落合和雄氏は、税理士・中小企業診断士ですが、以前は長らくSI会社に勤務され、SEのバックグラウンドもお持ちです。 非常にバランスのとれたお話が聞けると期待しております。

   <記>

日時: 2014年7月1日(火) 18:30〜20:30

場所: 慶応大学 三田キャンパス・北館・会議室2(収容数:28)
    アクセス http://www.keio.ac.jp/ja/access/mita.html
    ※キャンパスマップの【1】になります

テーマ: 「PRINCE2の概要」

講師: 落合 和雄 (税理士・中小企業診断士)

要旨:
PRINCE2の基本的な概念とフレームワーク
PRINCE2の7つのテーマ
PRINCE2の7つのプロセス

講師プロフィル:

 1953年生まれ。77年東大卒、新日鉄情報通信システムなどを経て、 現在経営コンサルタント、システムコンサルタント、税理士として活動中。 経営計画立案、企業再建等の経営指導、プロジェクトマネジメント、システム監査等の経営、 IT関係を中心に、コンサルティング・講演・執筆等、幅広い活動を展開。

 主な著書に、「年金に頼らない蓄財術」(アスキー)「ITエンジニアのための法律がわかる本」(翔泳社)、 「実践ナビゲーション経営」(同友館)などがある。

参加費用: 無料。

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

参加を希望される方は、確認のためできましたら当日までに佐藤までご連絡ください。
多くの方のご参加をお待ちしております。
by Tomoichi_Sato | 2014-06-10 20:07 | プロジェクト・マネジメント | Comments(4)