人気ブログランキング |

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

エンジニアリングとは統合力(インテグレーション能力)である

「エンジニアリング」という言葉を聞くと、読者諸賢はどのような仕事を想起されるだろうか。都会的なオフィスで遂行する、理知的な設計とデザインの仕事? それとも製図板と作業着とノギスをともなう、泥臭い仕事? あるいは企画と要求仕様だけを与えて、どこか海の外でやってもらう設計の力仕事?

エンジニアリング会社』と呼ばれる職場で、もう30年以上も働いている。会社には、机と椅子とPCと、あとは人が並んでいるだけだ。自社の工場は持っていない。建設現場はあるが、建設労働者を雇っているわけでもない。資機材は世界中の製造業の会社に頼んで作ってもらい、物流業の会社に頼んで現場まで運んでもらう。据付け組立工事は、現地の工事業者にお願いしてやってもらう。

じゃ自分たちは何をやっているかというと、設計図や仕様書を書いて、あとはプロジェクト全体をマネジメントしている。だから従業員は全員がホワイトカラーで、それも8割以上がエンジニア職種だ。

わたしの属するエンジニアリング業界には、国内で「専業」と呼ばれる大手が3社あるが、どこもほぼ同じような業態である。もっとも、国内には「エンジニアリング」と名前のつく企業が、大小様々に存在するし、分野もいろいろだ。わたしの勤務先は、「プラント・エンジニアリング」と呼ばれることも多い。ただしプラントばかりを作っているわけではなく、各種工場から病院まで、いろいろな施設を作っているので、『総合エンジニアリング』を自称している(が、たしかに売上の8割はプラント系である)。

こうした(プラント)エンジニアリング会社は、顧客にプラントや工場を作っておさめるのが仕事だ。なお日本では「プラント」と「工場」は別のものを指す(と思われている)が、英語で工場長はPlant Manangerであり、自動車工場はCar manufacturing plantである。だから両者を無理に区別する意義は、あまりない。

エンジニアリング会社とは、実は製造業やエネルギー産業の、生産技術部門(とくに工務部門)が独立してアウトソーシング先となった業態である。生産技術とは、製品設計と製造をつなぐ、「工程設計」「生産設備設置」を担う仕事だ。

こういう職務は、仕事量に波がある。増産と新工場設置のときは忙しく、定常運転に入ると暇になる。だから社内に抱えるより、アウトソーシング先として独立したほうが、お互い便利である。わたしの勤務先はたまたま、最初から独立したエンジ会社だったが、ライバル企業たちは、石油会社や化学会社の工務を担う子会社として出発した。

この業界では、工場づくりのプロジェクトを「EPC」と略称することが多い。EPCはエンジニアリング(Engineering)・調達(Procurement)・建設(Construction)の頭文字である。だが、先ほど書いたように、PとCの実作業は、外部の企業に発注するのが原則だ。自分で手を動かしてやっているのはE(エンジニアリング)のみである。だからまあ、「エンジニアリング会社」と呼ぶのかもしれぬ。

で、そのエンジニアリングというのは、冒頭に書いたようにカッコいい仕事なのか、泥臭い仕事なのか? 実は、エンジニアリングの日常というのは、次のような事の起きる日々である・・

***

<ある日の、機械設計部門にて>

「大変です。例のリアクター機器ですが、発注先のメーカーから、外形サイズが大きくなるって連絡が来ました。」
「どれくらい?」
「全体で、xxくらい増えるらしい、と。」
「いまさら勘弁してよ。もう配管設計部門に、ノズルの位置情報を渡して、設計をはじめてもらっているぜ。手戻りになるじゃないか!」
「そうですね。」
「それだけじゃなくて、機器の近くのパイプラック自体にも、位置的に影響するかもしれないな。ぎりぎりのレイアウトだから。なんでそんなにサイズが変わったの?」
「保温のためのジャケットの条件に変更が出たんです。顧客の要望で、上流側のプロセス設計部門から連絡がありました。それをメーカーに伝えたら、サイズに影響が出ますと返事が来たんです。」
「まずいな。それだと費用の追加請求も言ってくるぞ。納期にも影響が出るかもしれない。配管設計部門と調達部門と、一緒に相談したほうがいい。」

<その日の午後、配管設計部門の会議卓コーナーで>

「これだけサイズが増えると、機器周りの配管ルートをかなり変える必要がありますね。配管長も増えるし、コストアップになります。ラックとの距離を元のままにして、機器全体の位置をずらせないんですか?」
「逆側のメンテナンス用アクセスにも制限があって、もう壁からギリギリなんです。」
「調達の立場から言うと、このメーカーとの過去の経験から見て、確実に追加を言って来るね。まあウチが変更指示を出したんだから仕方ないけど。」
「納期は?」
「そっちの方が心配です。メーカーの側に余分な材料の在庫がなくて、サブオーダー(注:発注先の機械メーカーから、資材メーカーに手配をかけること)を出すとなると、2〜3ヶ月かかる可能性ありかも。」
「そんなに遅れたら、建設の機器搬入スケジュールに間に合わなくなるな。」
「納期もありますが、もう一つ。これ、機器全体の重量も増えますよね。そうすると、基礎にも影響するかもしれません。」
「げげ。建設現場ではもう、コンクリート基礎の工事が始まっちゃているぜ。どうしようか?」
「対案は2,3考えられますが、影響範囲が広いから、ぼくらだけでは決められません。エンジニアリング・マネージャーを呼びましょう。」

<翌朝、プロジェクト・ルームの会議室にて>

「・・皆さん忙しい中、緊急に集まってもらってすまない。例のリアクター機器No. KK-ZZZのサイズ変更への対応を、すぐに決めたい。まず、現状の位置のままサイズが増えた場合のインパクトを、各部から言ってほしい。下流側から行こうか。まず建設と調達から。」
「3ヶ月も納期が延びたら、建設の搬入据付けスケジュールがひっくり返ります。あの機器を据え付けないと着手できない後続工事がみんな遅れます。プロジェクト全体の納期に影響がありえます。」
「調達として心配なのはコストアップですね。あのメーカーはこういうチャンスに、必ず余計に上乗せして要求してきますから。」
「じゃあ設計側にいって、配管の影響は?」
「サブパイプラックが近くにあるので、干渉を避けるためには配管ルートを迂回する必要があります。」
「そうなると調節弁の位置も変わるね。計装のケーブルルートも見直さなけりゃ。」
「重量増による構造設計へのインパクトは?」
「今の程度の重量増なら、コンクリート基礎への影響は限定的です。幸い余裕は見ていました。」
「助かった。さすが。」
「ただ搬入のためのスペースが増えるので、架構の柱スパンに引っかかります。工事がそこだけ遅れます。」
「うーむ、そうか。とにかく、影響度合いは分った。対案は3つ。今の機器位置のままでいくか、場所を強引にずらすか、それとも入口の上流側の温度条件を変えて、リアクターのジャケットサイズがあまり増えないようにするか。」
「どれも簡単じゃないですが。」
「うん。でも、とにかく各案のPros/Consを表にまとめて書き出そう。その上で、コストと納期に一番インパクトが少なそうなものを選んで、決めることにする。」

***

まあ、これはいくつかの事実をもとに作ったフィクションである。まるで1日で決着するように書いたが、現実はもっと時間が掛かるし、こんなにカッコよくはない(笑)。ただ、肝要なポイントはおさえたつもりだ:

(1) エンジニアリングには複数の専門技術分野がかかわっている
(2) エンジニアリング・マネージャーという職種がいて、設計分野間の調整と意思決定をする
(3) エンジニアリングには基本設計→詳細設計という流れがあり、その一部は外部組織(発注先のメーカーなど)が担っている
(4) エンジニアリングの意思決定は、設計の品質や効率や整合性だけでなく、調達から実装までの全体を見て判断すべきである
(5) エンジニアリングにおいては、外部からの変更・変動への対応が、不可避である

エンジニアリングとは、基本デザインから実装までをカバーする仕事である。広義のエンジニアリングは、基本設計や要件定義に始まり、資機材やツールの調達、実装・設置工事・建設、そして試運転といった領域までの業務を含む。つまり発明・アイデアを現実化するまでの、トータルな仕事をさす言葉として、使われる。もう少し狭義には、基本デザインをインプットとして、それを実装可能なレベルにまで詳細設計する仕事を指す。その場合にも、様々な分野の工学的な要素技術を組み合わせて使うことになる。

エンジニアリングとは統合力(インテグレーション能力)である_e0058447_15401504.jpg
そしてエンジニアリングという業務の中心にあるのは、統合=インテグレーションである。

複数の機能要素を組み合わせて、全体として有機的な働きを実現するような仕事を、インテグレーション(統合)と呼ぶ。『有機的』というのは、目的意識があって、要素間のつながりやシナジーがあり、かつ環境の変化に柔軟に対応できる、というほどの意味である。目的意識もなく、環境変化に対応もできないような、要素の単なる寄せ集めを見て、わたし達は「有機的」と考えたりはしない。

そして、設計における統合力を担う職務を、「エンジニアリング・マネジメント」と呼ぶ。それはオーケストラの指揮者のように、一種の専門職である。交響楽団には、弦楽器だとか管楽器だとか、様々な専門の演奏職種がある。それらをまとめて、作曲家の提示した楽譜(=基本デザイン)に従い、現実化する。

楽譜に指揮者の「解釈」の余地があるように、実装にはいろいろな自由度がある。加えて、実際には完璧なデザインはありえないし、実装段階でのヘマをリカバーしなければならない場合もあるし(汗)、何よりも演奏会場と違って、エンジニアリングの場は外部環境に対して開かれている。顧客要求も市場環境も法規制も変化する中で、適応していかなければならない。

したがって、エンジニアリングにおいては、チェンジ・コントロール(変更管理)が重要である。設計とは実は、チェンジの積み上げである。むしろチェンジこそ本質である、といってもいい。設計の全体性をなるべく保ったまま、環境変化・条件変化に対して『適応制御』することが、エンジニアリング・マネジメントであろう。

マネジメントであるからには、設計のジャッジも必要に応じて担うことになる。そのためには、先読みとリスクテーク、そして何が良い成果であるかについての評価の価値観を持たなければならない。それも、部分的尺度ではなく、全体を見通した判断が必要である。

それを可能にするのは、設計プロセスと成果物に対する、「システム」としての見方である。変更の範囲と因果関係の予測ができないと、良い判断はできない。また外部機能→内部構造という階層性の理解、そしてV字モデルに従った詳細化と検証テストのコントロールが要求される。

ただ上の例に示したように、それはエンジニアリング・マネージャーだけが、一人で頑張って実現できるものではない。むしろ、協調的な働き方ができる組織力が望まれる。互いに独立し並行して進んでいるが、共通の着地点を目指すような、「すりあわせ」的な働き方である。ちょうどオーケストラの楽団員のように。そして変化を予見しながら、最小限の余裕を見越して設計できるスキルが望まれる。

エンジニアリング・マネージャーという職種は、わたし達の業界では普通の存在だが、分野によっては違うかもしれない。「エンジニアリング」という言葉の指し示す内容について、念のため最近、ゼネコン業界、工作機械メーカー、電子業界、IT業界などの知人にたずねてみたが、たしかにかなりの幅がある。それでも共通していたのは、「複数の設計技術要素を束ねる仕事」だという点だった。やはりエンジニアリングでは、統合力が、問われるのである。


<関連エントリ>
(2017-04-09)


(2019-11-21)




by Tomoichi_Sato | 2020-01-12 15:48 | プロジェクト・マネジメント | Comments(0)

PMにはなぜ設計論がないのか?

前回の記事(「プロジェクト&プログラム・アナリシス研究部会」(12月2日)開催のお知らせ)でも少しふれたが、なぜPMBOK Guide(R)には「設計論」がないのか、不思議に思われている方も多いと思う。米PMI (Project Management Institute)が'90年代に作成し、現在は改定第6版になっているPM界の標準ガイドブックは、10個のマネジメント領域を定義している(最初は9個だったが、途中からStakeholder Engagementが加わって、10個になった)。その10のエリアには、「調達」や「品質」があるのに、肝心の設計マネジメントがない。

プロジェクトにおいて、もしも設計がまずかったら、実装段階でどんなに頑張っても、良いプロダクトは生まれない。つまりプロジェクトの価値は上がらない訳だ。プロジェクト・マネージャーの任務は、プロジェクトの価値を最大化することのはずである。だとしたら、なぜ、設計論が欠落しているのか?

どうやら、初期のPMBOK Guideを作った人たちの頭の中には、設計(Design)の重要性の概念がなかった、としか思えない。その結果、今頃になって、やはりプロジェクトの成功には、良い基本設計が欠かせない、と気づいた。だからPMIはビジネス・アナリシスの標準プラクティスを制定しようとしたりしている。

ちなみに、設計と実装が一つのプロジェクトの中で一貫して行われるか、それとも別の企業に担われるかについては、業界および国の慣習によって、まちまちである。

たとえば、ビルや橋などをたてる、いわゆる一般建築や土木建設の分野についていうと、日米でバターンが異なる。基本的に、米国の建設会社には、設計機能がない。この点は日本のゼネコンと大きく異なっている。日本のゼネコンは(とくに大手は)かなりレベルの高い設計部門を抱えていて、独立した建築設計事務所と張り合っている。そしてしばしば、「設計施工一貫」という方式でプロジェクトを受注する。

しかし米国や英国は違う。建築設計は、設計事務所にいるアーキテクト(建築家)たちの専任事項である。アーキテクトがデザインした図面と仕様書をもとに、建設会社が工事をする。工事が図面通り適正に行われているかを、建築事務所がチェックする。この仕事を日本語では設計監理とよぶ(同じ音の「管理」と区別するため、「さらかん」といったりする。監の漢字の下にお皿があるからである)。設計と施工を分業するので、「設計施工分離」方式と呼ぶ。

このような分業と相互チェックの体制になっているため、英米の建設会社では一般に、設計機能を持たないのである。そして彼らは、工事のプロジェクト・マネジメント能力をもっぱら売り物にする。

ちなみに日本の官公庁のかかわる一般建築は、制度を英国に見習ったためだろう、同じように設計施工分離の方式がベースになっている。そして原則として、設計の後、工事は入札が行われる。だがふつうの民間工事では、しばしば同一のゼネコンが設計も施工も行う。理由の一つには、途中で工事入札をはさむよりも、全体期間が短くなるためである。

一般建築の他にも、発注者である官庁側が基本仕様の定義や基本設計までを行い、受注者が詳細設計と実装(製造)を担う、という業界はまだいろいろと存在する。米軍と軍需産業の関係なども、わたしは詳しくは知らないが、実はそうなっているのではないか。だから初期のプロジェクト・マネジメント概念を育てた米国の航空宇宙産業だって、似たような感覚があったのもしれない。

ちなみに、わたしが働いているプラント・エンジニアリングの業界は、両方のパターンが存在する。原則として、基本設計(業界でFEED = Front-End Engineering Designと呼ばれる)と、詳細設計・調達・建設(EPC = Engineering, Procurement & Construction)とは、別フェーズで遂行されるのだが、どちらも担うのは同じエンジニアリング業界の企業であり、プレイヤーが一般建築のように分業化していない。

おまけに、FEEDとEPCを一貫して遂行するプロジェクトも、ときどき存在する(とくに入札による透明性よりも工期短縮を重視する私企業が発注者の場合)。だから、エンジニアリング業界では、PM能力の重要な要素として、『エンジニアリング・マネジメント』が入ってくるのだ。

話を戻すが、設計と施工(実装)を受け持つ会社が別々になっていて、前者はデザイン能力を、後者は実装のプロジェクト・マネジメント能力を売り物にする、という業界にいる人達は、PMの技術の中に設計論がなくても、不思議はないだろう。

ただし、設計と実装が会社(業界)として分離していると、まずいこともある。

一番大きな問題は、実装段階における技術やノウハウが、設計段階にフィードバックされにくい点だ。たとえば、ビル建築の世界で、新しい建設工法が開発されたとしよう(たとえばジャッキアップ工法など)。当然ながら、その工法を活かせるような設計が必要である。しかし建設工法の開発はゼネコンが行っていて、そのノウハウは建築設計事務所にはすぐに共有されない。

製造の分野でも似たような事情はあるはずだ。新しい加工方法(たとえば3D printerによる金属積層造形など)が開発されたとしても、設計はデザインハウスが行い、製造は受託製造企業EMSが行う、というような分業が進んでいると、製造技術の進歩がすぐに設計に取り入れにくくなってしまう。

つまり、設計と実装が分離した形でプロジェクトを進められるのは、実装技術の進歩がゆっくりしている分野のみだ、とも言えよう。

もちろん、設計段階はスコープが柔らかく、実装段階に入ると、スコープはかなり固まるのが常だ。だから、発注者と受注者がフェアなリスク分担をはかるために、あえて設計と実装のフェーズを分けて、設計段階は実費償還型契約(日本のIT業界の言い方でいえば準委任契約)で行い、実装段階は一括請負型契約で行う、というのはもちろんあり得る。ただ、これはプロジェクトのフェージング技法であって、だからプロジェクト全体における設計マネジメントの重要性が減る、というわけではない。

あるいは、アジャイル開発のケースを考えてもいい。アジャイル開発はソフトウェア分野特有の方法論だが、設計と実装を細かな単位のサイクルで回し、機能を順に付加していく。アジャイル開発活動の主要なモチベーションは、それまで設計の下請け状態に置かれていた実装の仕事を、設計と同格の位置に持ち上げたい、というプログラマたちの悲願にあった。だからあえて、設計と実装が渾然一体となったグループ組織で進めるのだ。

下請け。そう、IT業界では長らく、SI系の受託開発プロジェクトを、大手計算機メーカーが「ゼネコン」として元請け受注し、実装部分を子会社や関係会社に下請けに出す、という業務形態がとられてきた。設計と実装の分業は、建築分野のような業界単位の棲み分けではなく、「企業の順位」を基準に行われてきた。何やら江戸時代みたいな「身分差」で決まる、とさえ言いたくなる実態があった。

そのくせ、元請けの大企業が担うから、設計品質や設計マネジメントはちゃんとしていた、と言えるかは、けっこう疑問なのである。システム設計とは、どういう仕事なのか。設計の品質(「前向き品質」)はどう、とらえるべきか。いわゆる「システムズ・エンジニアリング」の手法は、ITシステムの設計に応用可能なのかどうか・・とった設計に関する本質的な議論を、あまり聞いたことがない。聞こえてくるのは、開発方法論と、ソフトウェア工学の手法論がせいぜいだ。

もしも日本の大手IT企業が、本当に設計に大きな価値を認めているならば、SIビジネスの利益構造は別の形になっているべきだった。すなわち、「設計段階」で大きな報酬を得て、「実装段階」では、かつかつの利幅で受ける、という風になるはずである。だって良い設計のほうが、正しい実装よりも、ずっと顧客にとって価値が高いのだから。そしてエンジニアという人種は、何より、優れた知恵をお金に変えたいと願う存在だ。

しかし、現実にはそうならなかった。SIビジネスは、なんといっても実装部分で、全体工数の人月に比例して売上と利益を得る構造になっていた。このようなビジネス慣習の元で、設計の重要性がハイライトされるだろうか? 

米国PMIが'90年代にPMBOK Guideを作成するにあたって、設計論のエリアを省略してしまったのは、彼らの国の事情があったのだと想像する。日本が(とくにIT業界が)それを広く受け入れたのは、2000年代に入ってからだ。だが、爾来10数年間、誰もあまり設計マネジメントの欠落を、問題に思ってこなかった。それはとりもなおさず、設計という仕事を、価値の源泉ではなく、単なるコストの一部だととらえてきた結果に思えるのである。


<関連エントリ>
 →「システムズ・エンジニアリングとは何か」https://brevis.exblog.jp/25682507/(2017-04-09)
 →「設計の価値」 https://brevis.exblog.jp/2408181/ (2006-01-01)


by Tomoichi_Sato | 2019-11-21 06:56 | プロジェクト・マネジメント | Comments(0)

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

各位:

「プロジェクト&プログラム・アナリシス研究部会」の2019年第4回会合を開催いたします。
(なお、9月に「プロジェクト事例懇話会」を開催したため、研究部会としては前回から間が空いてしまいました。ご了承ください)

プロジェクト・マネジメントの目的は、プロジェクトの価値を最大化することにあります。ところで、プロジェクトの成果物が価値あるアウトカムを生み出すためには、その設計が非常に重要になります。どんなに効率よく精緻に成果物を作り出しても、もとの設計の出来がわるかったら、大して価値あるプロジェクトにならないことは明白です。

ところが、その大事な設計のマネジメントという仕事について、PMBOK Guideを始めとするPM論が、ほとんど何も語らないのは、なぜでしょうか。設計業務の現場において、現実のエンジニアは、過去の実例のコピー&ペーストみたいな仕事や、外注先との折衝・チェックに忙殺されている姿を、よく見かけます。これは望ましい設計マネジメントの姿でしょうか?

今回は、(株)アズサ・プロセル代表取締役で、日立製作所OBである梓澤昂様に、新製品開発プロジェクトや受注設計生産プロジェクトにおける設計業務のあり方を刷新する、「機能セル設計」のコンセプトについてご講演いただきます。梓澤様は日立時代に、大みか工場の設計生産改革をリードされ、今や同工場は日立製作所のスマート工場のショウケース事例となっています。

陳腐化しやすい「モノの設計」から、永続性のある「機能の設計」に転換するとは、どういう事なのか。具体的事例をもとに語っていただきます。ぜひご期待ください。


<記>

■日時:2019年12月2日(月) 18:30~20:30

■場所:田町キャンパスイノベーションセンター 
 5F スペース:509AB
 (JR田町駅の芝浦口から右方向の階段をおりて、50mほど先の右手の建物です)

■講演タイトル:
新製品・Eng.プロジェクトの価値を高め、モノ創り効率を10倍化する『機能セル設計』

■概要:
 かつて日本のモノ創りは若い技術者が開発に情熱を傾けて、世界を魅了する新製品を開発した。大企業化・豊かな生活化に伴い新製品開発への情熱とスピードが潜め、モノ創り力が弱まった。更に米国発信のディジタル化に翻弄され、モノづくり本質の自然の理に添った“アナログの機能“発想の“日本のモノ創り・モノづくり力”が落ちて、情報家電等で米国企業の後塵を拝して、かつての日本企業の強みと良さが弱体化し、「世界を魅了する新製品・エンジニアリング術の日本発信」が影を潜めてしまった。
 そこで、本講演では①人々の欲しがっているコトは“モノ”で無く“機能(アナログ)”(価値は機能が創る)である事と②40億年進化してきた生物は「機能を持つ細胞」で構成される(生態系の知恵)の教えとに学び、新しいモノ創り”機能セル設計”を提唱し、インフラ設備・システム造りの工場で実践してきた。
 新しいモノ創りは寿命のあるモノ{ハード・ソフトのモジュール等}で無く、価値の源泉で且つ永続性のある「機能Cell(細胞)」基準で発想するコンセプトです。
 「製品価値を向上する機能の分析・目標機能の設計」から「市場を魅了する製品を如何に早く開発するか」の新製品開発Keyポイントの創造、モノづくりに不可欠な「詳細・生産設計のAI/IT技術活用方法」、さらに海外展開(製造外注化・海外現場)で必須な「品質・コストを保証するモノづくり設計方法」の事例を織り込んで説明します。
 また、新しい設計方法「機能セル設計」は既存製品の踏襲機能を機能単位に活用し、設計情報をそのまま利用でき、効率を10倍以上加速する設計方法です。

■講師:梓澤 曻(あずさわ のぼる)
 (株)AZUSA・PROCELL代表取締役

■講師略歴:
1947年  埼玉県生まれ
‘69年   日立製作所大みか工場入社
‘69~83年 電動機制御装置開発
‘84~92年 電力・鉄鋼他制御装置開発
‘92~97年 大容量電動機駆動装置開発、全体の開発指導
‘98~00年 開発・技術総責任者{この間、世界初の製品開発を15件の他、50件以上の新製品を開発、特許367件出願、IEEE論文他多数発表} 
‘00年   モノ創りコンセプト(Progressive Cell Concept:PROCELL)を発表  
‘00~06年 大みか工場副事業部長兼事業所長兼MH他社外取締役 
‘06~10年 日立本社電機部門技師長兼CTO他
‘11年3月 退社 
‘11年4月~ (株)AZUSA・PROCELLを設立{国内外企業の開発・設計生産改革エンジニアリング等コンサルティング}
<著書>
‘18年9月「機能セル設計」を日刊工業新聞社から出版。

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 参加を希望される方は、確認のため、できましたら前日までに三好副幹事までご連絡ください。

 以上、よろしくお願いいたします。


佐藤知一@日揮ホールディングス(株)


by Tomoichi_Sato | 2019-11-16 08:17 | プロジェクト・マネジメント | Comments(1)

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

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

「頭は使うべきだが、仕事に心を使ってはいけない。」--昔、ある業界のベテランのプロジェクトマネージャーから聞いた言葉です。最初に聞いた時は、意味がよく分かりませんでした。プロジェクトは人の集団が行う活動です。頭を使うのは当然としても、他人への気遣い・心づかいを忘れたら、チームは円滑に回らないはず。そう、感じたのです。

しかし、その後しばらくして、この言葉は存外深い意味があるのでは、と感じるようになりました。とくにプロジェクトが火を吹いたような時、顧客との困難な交渉、社内外との調整、そしてストレスやら過剰な心配やらで、心身がへとへとになり、物事に機械的な応対しかできない状態に陥ります。「心がすり減った」としか言いようのない気分になるのです。

そんな時に、社会学者・石川准氏の著書「見えないものと見えるもの」(医学書院)で『感情労働』という概念を知り、衝撃を受けました。世の中の労働は、知的労働と肉体労働に分けられる--そう信じてきた自分には、全く見えていなかったカテゴリーの労働があり、それが感情労働だというのです。たとえば看護師の仕事がその典型で、感情というリソースを活用・消耗する仕事であり、過剰になると心が「すり減って」しまうのだ、と。たまたま同じ時期、欧州のPM研究で「社会構築主義」が話題になっていたのですが(「知識労働、肉体労働、そして『感情労働』」記事参照)、こちらでも感情の社会学が関心を呼んでいました。

そこで今回は、静岡県立大学教授・兼・東京大学先端科学技術研究センター特任教授である石川准氏をお招きして、感情労働についてお話いただきます。ちなみに石川氏は、目が不自由でありながら初めて東大に入った方で、だから著書のタイトルは非常に象徴的でもあります。

多くの人が感情をすり減らしながら毎日働いているように見える今日、感情のあり方について、社会学の観点から見直す機会になると思います。大勢の皆様のご来聴をお待ちしております。

<記>
■日時:2019年7月25日(木) 18:30~20:30

■場所:田町キャンパスイノベーションセンター 
 5F スペース:509AB
 (いつもの慶応大学三田キャンパスとは場所が違いますのでご注意下さい!
  JR田町駅の芝浦口から右方向の階段をおりて、50mほど先の右手の建物です)

■講演タイトル:
感情労働とは何か

■概要:
 感情を社会学というツールを用いて分析すると、感情規則、感情管理、感情労働といった概念が浮かび上がってくる。
 こうした基本概念を説明しつつ、感情規則の多様化、感情労働の高度化・広範化といった今日的な状況の中で、公的および私的領域における協同作業や他者理解の困難について考えたい。

■講師:石川 准(いしかわ じゅん)
 静岡県立大学教授
 東京大学先端科学技術研究センター特任教授

■講師略歴:
 1981年 - 東京大学文学部 卒業
 1987年 - 東京大学大学院 社会学研究科博士課程 単位取得退学(社会学博士)
 1997年 - 静岡県立大学 国際関係学部 教授
 2012年 - 内閣府障害者政策委員会 委員長
 2015年 - 東京大学先端科学技術研究センター 特任教授

<研究テーマ>
●社会学分野  存在証明、アイデンティティ・ポリティクス、障害学 (disability studies)、アクセシビリティ、感情労働
●支援工学分野 自動点訳・ スクリーンリーダー・点字携帯端末・移動支援機器の開発
<主な社会活動 >
国連障害者権利委員会 副委員長、内閣府障害者政策委員会 委員長

<著書・訳書>
『見えないものと見えるもの』医学書院 2004
『障害学への招待』明石書店 1999
『アイデンティティ・ゲーム:存在証明の社会学』新評論 1992
『管理される心:感情が商品になるとき』世界思想社 2000 =Arlie R. Hochschild, 1983, The Managed Heart, The University of California Press

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 参加を希望される方は、確認のため、できましたら前日までに三好副幹事(miyoshi_j@kensetsu-eng.co.jp)までご連絡ください。
 以上、よろしくお願いいたします。


佐藤知一@日揮(株)

by Tomoichi_Sato | 2019-06-20 22:36 | プロジェクト・マネジメント | Comments(0)

EVMSとアーンド・スケジュール法の弱点 ~ プロジェクト予測のミクロとマクロ

前回の記事から2週間ほど間が空いてしまった。先週から欧州で、製造業系と石油ガス業界系の二つのカンファレンスに立て続けに参加していて、サイトの記事を書く時間がなかなか取れなかったのだ。最初の会議では、わたしの勤務先で最近つくった、2030年の未来を見据えた長期的な「IT Grand Plan 2030」(https://www.jgc.com/jp/news/assets/pdf/20181218_1.pdf)の講演発表もした。それなりに一応、好評だったと思う。

ところで、こういう国際カンファレンスに来るといつも思うのだが、欧米人はハイ・レベルな概念論が大の得意だ(ここでいうHigh levelとは、もちろん「高級品の話」ではなく、視点が高い=抽象的という意味である)。たとえばDigital transformationだとか、Ecosystemだとか、Sustainabilityとか、彼らの好きな言葉がある。一種の流行言葉でバズ・ワードであるが、彼らは自分のプレゼンで、必ずと言っていいほど、自分なりにその内容を言葉で定義する。その定義が皆と共通であれば、もっと良いと彼らは考えている。だから標準化だとかBOK(知識体系)とかが好きなのだろう。

ところが、そういう講演を聞いていると、どうしてもわたし達のような日本のエンジニアは、「だけど具体的にはどうなの?」という風につっこんで聞きたくなる。ある程度の具体性、現実味がないと、なんだか綿飴を噛んでいるような、歯ごたえのなさを感じてしまう。逆にいえば日本の技術者の発表は、えてしていきなりディテールに入りすぎるきらいがある。

ハイ・レベルで抽象度の高い議論と、ディテールにこだわる議論。その両方が必要なのは言うまでもない。その優先度がどちらにあるべきかで、洋の東西は意見が微妙に分かれている。もっとも、一口に「欧米」といったってアメリカと欧州は違うし、ヨーロッパだって南北でずいぶん違うのは事実だ。でも、日本との隔たりは非常に大きい。西洋人はとにかく、マクロに物事をとらえたがる。

さて、最近注目の「アーンド・スケジュール」という手法は、EVMS(Earned value management system)から派生した新しい手法である。EVMSがもつ、これまでのスケジュール把握における問題点、とくに完了日予測に関する困難を解決しようと工夫した点に、特徴がある。これが前回まで2回続きの記事で書いたことだった。ところが、アーンド・スケジュール法にも弱点がある。それが、スケジュール把握におけるマクロとミクロに関係しているのである。

例を挙げよう(つまり、数式で抽象的に説明するより、具体的なディテールを提示したほうが、読者にもわたし自身にも分かりやすいからだ)。

下の図は、あるプロジェクトの構造を図示したものだ。システム開発系のプロジェクトだが、WBSはかなり簡潔化してあり、わずか6個のActivityから構成している。図はそのActivity間の順序関係を示した「ロジック・ネットワーク」で、いわゆるprecedence diagram形式になっている。この図の見方については、ずいぶん以前に書いた記事「納期が延びる要因を指標化する - スケジュールのDRAGとはどんな尺度か」 https://brevis.exblog.jp/20000432/ (2013-03-25)を参照してほしい(ただし、以前の記事の図とは、意図的にいくつか数字を変えているので注意されたい)。

EVMSとアーンド・スケジュール法の弱点 ~ プロジェクト予測のミクロとマクロ_e0058447_05395335.jpg
このプロジェクトは基本設計で始まるが、その後、二つの並行する経路に分かれる。それがハードの調達系と、ソフトの開発系である。両者は総合テストで合流する。クリティカル・パスは、下側のソフト開発系にある。上側のハード調達系は、図中の四角の左上に示されるES(Earliest start=最早開始日)と、左下のLS(Latest start=最遅開始日)の数値に、10日分の差がある。これは、このアクティビティ系列に10日のFloat日数(余裕日数)があることを示している。

Float日数を持つアクティビティは、いつ開始するべきかについて、自由度がある。たとえば「ハード選定」は、最早開始日ES=20日だが、最遅開始日LS=30日だ。これを見て、プロマネのあなただったらどうするだろうか? 基本設計が終わったら、間髪を入れず、すぐにハード発注作業をする? だが、この作業は実稼働日で10日(つまりカレンダーでは半月ほど)余裕があるのだ。だったら、基本設計に続く詳細設計をまずちゃんとまとめて、それからハード発注に頭を切り替えても遅くはあるまい。

そういう前提で作業のシーケンスを考えると、それぞれの計画上の予定完了日と、その時点までの出費PVは、下の表1のようになるだろう。全体期間は75日。ちょうど中ごろの35日目に、累積のPVは250万円になる。

[表1 予定の出費(PV)]
EVMSとアーンド・スケジュール法の弱点 ~ プロジェクト予測のミクロとマクロ_e0058447_06033096.jpg

さて。実際にプロジェクトを進めていくと、(いつものことだが)設計上の問題が生じてしまった。10日で終わるはずの詳細設計の冒頭に手戻りが発生し、15日くらいかかりそうな状況だ。あなたの上司は(あるいは顧客でもいいが)、プロジェクトの週次レポートで、累積の出来高(EV値)が予定通り上がっていくかを、チェックしている。このままでは遅れが出て、あなたは叱責されかねない。

そこであなたは考えをかえ、詳細設計が終わってからやるつもりだった「ハード発注」を、基本設計後に前倒しして並列に行うことにした。おかげで25日目にハード発注は完了。「詳細設計」は遅れて35日目に完了した(実績を示す表2では、アクティビティの完了日の順序が、上の表と一部逆転しているので注意してほしい)。35日目の時点で、出来高EV値=250万円だ。PV=EVだから、つまり「アーンド・スケジュール」ES(t)=35日、ということになる。万歳、プロジェクトは遅れていないのだ!

[表2 実際の出来高(EV)]
EVMSとアーンド・スケジュール法の弱点 ~ プロジェクト予測のミクロとマクロ_e0058447_06083510.jpg
本当だろうか?

もちろん、間違っている。「詳細設計」はクリティカル・パス上のアクティビティなのだ。だから、この完了が5日遅れたら、プロジェクト全体の納期が確実に5日遅れてしまう。まあ、あなたがプログラマを余計動員して、ソフト開発の所用期間を5日以上短縮できれば別だが、そのためには余計にコストがかかるはずだ。(詳細設計の工数が増えたのだから、プロジェクトはすでに予定より赤字になっているが、それがさらに増えかねない訳だ)

いかがだろうか。アーンド・スケジュール法による進捗コントロールの、どこがおかしいのだろうか? アーンド・スケジュール法の論理も計算自体も、間違ってはいない。だが、明らかに、プロジェクトの遅れの検出に失敗しているのだ。

それはもちろん、アーンド・スケジュール法が、マクロなEVやES(t)の値しか見ていないことに原因がある。ロジック・ネットワークが示すように、プロジェクトの完成予定日は、クリティカル・パスの長さで決まる。それは、ネットワークの構造をミクロに見なければ、分からないのだ。この例は簡略化してあるので、6つしかアクティビティが無いから、よく見れば誰でもおかしい点が理解できる。

だがアクティビティが100個も200個もあったら、ネットワークをたどっていくのは大変だ。だからEVやES(t)などのマクロな指標で見よう、という気持ちはわからないでもない。でも、EVやES(t)は、それまでに完了した全てのアクティビティの合計指標だ。この中には、クリティカルな作業もそうでないものも、ともに含まれている。だから、たとえクリティカル・パスの作業が遅れても、フロートのある作業を前倒しで進めることで、見かけ上、進捗率を上げることができるのである。

別の言い方をすると、コスト視点とスケジュール視点では、アクティビティの「重要度」の尺度が異なるから、こういう事が起こる。スケジュールでは、クリティカル・パス上のアクティビティは、たとえ予算が小さくても重要だ。だが、EVMSでは予算(コスト)でしか重みをつけないから、スケジュール差異を正しく検知できないのだ。

ミクロを積み上げても、マクロにならない。マクロに良さそうに見えても、ミクロにはおかしい場合がある。これが『システム』というものの基本的性質だ。

プロジェクトは、アクティビティのネットワークで構成される、典型的なシステムである。そして、人が重要な役割を担い、また外乱的な変動にもさらされる、ひどく複雑なシステムでもある。この複雑さを、まだ適正なレベルで、うまく予測しハンドリングできる理論はできていない、というのが現時点でのわたしの感覚だ。

最初に述べた、わたしの勤務先の「IT Grand Plan 2030」では、プロジェクトという目に見えない対象のデジタル・ツィン=『Project Digital Twin』という概念の実現を目標にしている。デジタル・ツィンであるから、その上でシミュレーションができる必要がある。

しかし、現状のEVMSも、クリティカル・パス法も、その意味ではまだ、単純にすぎる。何より、決定論的すぎるという限界がある。シミュレーションを行って、プロジェクトの完了日や完成コストの予測をしようにも、一点しか答えが出てこない。台風の進路を予測して、一本しか線が描かれないようなものだ。現実のプロジェクトとは、もっとブレがあって、そのリスクとどう戦うかが一番大事なのに。

そして本物のプロジェクトは時々、崩壊現象を起こす。だからプロジェクトのシミュレーションも、ちゃんと崩壊現象を再現できなければならない。今のPERT/CPMやEVMSの、どこをどうひねくっても、崩壊現象など出てこない。

その意味で、わたしは今のプロジェクト・マネジメント理論にはまだ、『第一原理』が欠けていると思っている。材料物性を研究している人達は、量子力学の波動方程式という第一原理から出発して、マクロな多体問題を解き、物性を推算している。だが、不確実性をはらむプロジェクトの予測をするための基礎方程式は、どんな形をしているのだろうか? 

わたし達の旅路は、まだ始まったばかりである。

<関連エントリ>
 →「プロジェクトの進捗を計る『アーンド・スケジュール法』とは何か 〜 その内容と課題」 https://brevis.exblog.jp/28339485/ (2019-05-26)
 →「納期が延びる要因を指標化する - スケジュールのDRAGとはどんな尺度か」https://brevis.exblog.jp/20000432/ (2013-03-25)




by Tomoichi_Sato | 2019-06-10 06:17 | プロジェクト・マネジメント | Comments(0)

プロジェクトの進捗を計る「アーンド・スケジュール法」とは何か 〜 その内容と課題

EVMS(Earned value management sysytem)とは、プロジェクトのコストと進捗を、「アーンドバリュー」(出来高)と呼ばれるメトリクスを使って測定し、コントロールする手法であって、モダンPMの技術の三本柱の一つになっていると前回の記事で書いた。ところがEVMSには、ある弱点があった。「アーンド・スケジュール法」は、この問題を克服するために、2003年ごろから考案され発展して、ついにはPMBOK Guide第6版やPMI Practice Standard for Schedulingにも正式に採用されるようになってきた。

それでは、EVMSの進捗管理における問題点とは何なのか? これを論じるためには、そもそも『進捗管理』(スケジュール・コントロール)という仕事の目的を、きちんと理解する必要がある。

進捗コントロールの目的とは、大きく次の4点にあると考えることができる。

(1) 現状の正確な把握:

プロジェクトの進行状況が、現時点でどうなっているかを、正確につかむ。プロジェクトを航海に例えるならば、自分の船は今、どこの位置にいるのか。そして、どれくらいの速力で移動中なのか。それを正確に知ることが、まず第一の目的である。船ならば現在はGPSで正確にわかるが、昔は北極星の位置や六分儀から割り出す必要があった。プロジェクトという目に見えない航行も、色々な手がかりから現在位置や速度を求めることが行われる。

(2) リスクと問題点の検知

船の航海のたとえを続けるならば、出発時に海図の上に線を引き、航行計画を立てたはずである。その予定線と現状は、どれくらい一致しているか。予定より進んでいるのか遅れているのか。積み荷の量は予定通りか。航行に要する燃費は想定通りか。こうした点をチェックして、問題があるなら、対策の手立てを取る必要がある。たとえ現状に問題がなくても、台風の発生や航路上の想定外の障害など、この先のリスクについて、定期的にウォッチしておかなければならない。

(3) 完了日時の予測

今のままのペースで行くと、船が目的地に着くのは(つまりプロジェクトが完了するのは)何月何日になりそうかを予測する。これは案外見過ごされがちだが、進捗コントロールの重要な仕事である。完了日時の予測がないと、プロマネが適正に判断できないばかりか、プロジェクトに人を出している関係部門も先の予定が立てられない。だから完了予測のない進捗報告は、単に虚しいレポート作成に過ぎない。なお、完了時点でのコスト予測(完成予想額:Cost EAC = Cost estimate at completion)も当然ながら重要で、完了日時とコストを合わせて「着地点予測」と呼ぶ場合もある。

(4) 次への学びをまとめる

プロジェクトが完了したり、あるいは大きなマイルストーンを超えて別のフェーズに入ったら、それまでの教訓(LL = Lessons Learned)をまとめ、次の航海に備える。これも忘れてはならない進捗コントロールの職務である。

さて、このような見地から、とくに(3)の目的に照らしてみると、EVMSによる進捗コントロールにはいささか不便な点があった。EVMSでは、計画と実績の予実比較のために、コストとスケジュールで二組の指標を計算する。

コスト差異:
 CV (Cost variance) = EV - AC
 CPI (Cost performance index) = EV / AC

スケジュール差異:
 SV (Schedule variance) = EV - PV
 SPI (Schedule performance index) = EV / PV

いずれも差をとるか比をとるかで、合計四種類の指標が出てくる。これらの指標は、どれも、数値が大きければパフォーマンスが高く、プロジェクトがうまく行っていることを示す。

さて、完了時の着地点予測を考えてみよう。コストの場合、通常は次のような計算をする。

Cost EAC = 現時点までの実績コスト(AC) + (今後行うアクティビティの予算額)/ (今後のCPI)

たとえば、予算総額1億円のプロジェクトを考えよう。現時点までに、およそ6割程度のアクティビティが完了しており、それに費やした実績費用ACは7500万円だった。ただ、元の予算は6000万円で済むはずだった(EV = 6000万円)。この場合、CPI = EV / AC = 6000/7500 = 80%である。

そして、残りのアクティビティに必要な費用は、4000万円と当初の計画では想定していた。現状すでに7500万円使っているから、7500 + 4000 = 1億1500万円、と見ていいか? そうはいくまい。これまで、7500万円かけて、6000万円分の仕事しかできなかったのだ(CPI = 80%)。この先も同じペースで行くと想定すると、

Cost EAC = 7500 + 4000/0.8 = 1億2500万円

が完成予想額だ。2500万円も赤字になる、ということになる。

では、完了日時の予測は、同じようにできるだろうか? たとえば、上の例で、全体期間は10ヶ月だが、今は7ヶ月経った現時点であり、SPI(=EV/PV)は、CPIと同じく80%だったとしよう。つまり、開始後7ヶ月時点でのPV=7500のはずだった。だったら、次のように計算していいか?

Time EAC = 現在までの経過時間 + (残りの予定時間)/ (今後のSPI)
 = 7ヶ月 + (10 - 7)/0.8 = 10.8ヶ月

そうはいかないのだ。なぜなら、まず、SPIというのはEV/PVという金額の比率指標であって、時間あたりの進捗指標ではないからだ。それにもう一点。今後のSPIは、現在の80%よりも必ず大きくなることが予想されるからだ。というのも、定義からいって、プロジェクト完了時点でのSPIは、100%に戻るためである。

これは、スケジュール差異SVに置き換えても同じである。SVは完了時点で必ずゼロに収束する。図を見て欲しい。CVは、完了時点で、一定の値が残るのが普通だ。だがSVは0に戻ってしまう。
プロジェクトの進捗を計る「アーンド・スケジュール法」とは何か 〜 その内容と課題_e0058447_15220513.jpg
かならずゼロに漸近するような数値が、いつゼロになるかを予測するのは、とても難しい。だから、SVやSPIだけを用いて、完了日時の予測をするのは困難なのである。これがEVMSの持っている弱点だった。

さて、ようやくアーンド・スケジュールの登場である。ES (Earned schedule)の定義は、シンプルである。それは、"Earned Schedule (ES) is the point in time when the current Earned Value was to be accomplished" と定義される(Stratton 2005による)。日本語に訳せば、

アーンド・スケジュール(ES)とは、現時点での出来高(EV)が達成されるはずだった日付をいう」

となる。図を見てもらえば一目瞭然だろう。そして、ここから二種類の指標が導出される。

プロジェクトの進捗を計る「アーンド・スケジュール法」とは何か 〜 その内容と課題_e0058447_15232446.jpg

 SV(t) (Schedule variance on time) = ES - AT
 SPI(t) (Schedule performance index on time) = (ES - AT) / ES

ここでATとはActual time、すなわち実際日付(現在日付)のことである。そして完了日時予測は、

Time EAC = 現在日付(AT) + (全体工期 − ES)/ SPI(t)

で計算する。上記の例でいうと、かりにEV=6000となる日時が開始後6ヶ月の予定だったとすると、
 ES = 6 - 7 = -1ヶ月
 SPI(t) = 6 / 7 = 86%
 Time EAC = 7 + (10 - 6) / 0.86 = 11.7ヶ月
という計算になる(無論ここでは、現時点までのSPI(t)の値が、今後もあまり変わらないという想定が入っている)。

Earned scheduleの概念と計算式は、米国のWalt Lipkeという人が2003年頃から提案したものだ。なお、アーンド・スケジュール法の各種指標については、次のサイトにまとまっている:

ただ念のために書いておくと、EVの値から横に線を引いて、PVカーブの日付を求めるアイデア自体は、Lipkeよりも前からあった(たとえばFleming and Koppelman、Anbariなど)。また実務でも、以前からわたし達は進捗率カーブを引いて、何日分進んでいる・遅れていると表現してきた 。そういう意味では、アーンド・スケジュール単体では、それほど独創的とは言えない。

ただ、わたしが注目したのは、このESを使った進捗コントロール手法が、米国防省に広まることで、かなり膨大なデータが蓄積されるだろう、という点だった。なぜなら、EVMS手法の進歩には、米国の防衛宇宙産業での膨大なデータの蓄積が役立ったからだ。

ちなみに、上の完成予想額の計算で、「この先も同じペースで行くと想定すると」と書いたが、これは、今後のCPIも同様な値が続くと、という意味だ。そして、米国におけるEVMSに関連する膨大なデータから、

プロジェクトのCPI値は、全体期間の最初の2〜3割を過ぎると、良くも悪しくも安定する

という経験値の集積があったから、使えたのである。そしてSPIは、途中でいったん1から離れても、また1に漸近するという性質のために、このようなデータ傾向が得られないのだ。

ちなみにわたしの記憶が正しければ、米国では50万ドル以上の公共事業では、EVMSを適用することが法律で義務付けられている。そして公共事業のデータだから、それは政府自治体だけでなく、社会全体がエッセンスを共有して使える。こうした各種プロジェクトデータの集積と、経験知の共有は、ある意味オープンな米国社会の強みでもある。

ひるがえって、たとえばわたし達の社会では現在、東京オリンピックを目指して多数の公共プロジェクトが進められているが、そうしたデータは誰がどう蓄積しているのだろうか。たしかに個別案件の予算などは取引上の秘密で、受託企業の競争領域に属するだろう。だが、CPIやSPI(t)などに関する統計分析は、強調領域として、皆の共有すべき知識となるはずであろう。

ともあれ、アーンド・スケジュール法に話を戻すと、この手法の登場によってEVMSの弱点は補強され、プロジェクトの進捗把握と完了日時の予測は、より高い精度でできるようになった −− のだろうか?

そうはいかないのだ。実は、ES法にはまだ、深刻な落とし穴が、一つある。だが、またしても長くなり過ぎたようだ。その問題について説明するのは、また次の機会に譲ることにしよう。


by Tomoichi_Sato | 2019-05-26 15:32 | プロジェクト・マネジメント | Comments(0)

プロジェクトの進捗を計る「アーンド・スケジュール法」とは何か 〜 (1)その基本

アーンド・スケジュール」の概念を初めて知ったのは、2006年のことだった。オーストラリアのシドニーで開かれた、プロジェクト・マネジメントの国際大会ProMAC 2006でのことである。わたしは、後に自分の学位論文のコアになる『RPV(Risk-based Project Value=リスク基準プロジェクト価値)』の考え方を発表するため、そこに参加していた。

豪州はPM研究の盛んな国であり、この大会も日米豪アジアから様々な講演発表があって、非常に面白かった。その一つが、米国海軍のコンサルタントWalter H. Lipke氏による、「アーンド・スケジュール」の発表だった。それまでのEVMS(Earned value management system)の弱点を、うまく補った手法だと、聞いていて感心した。

そこで、日本に帰ってから、すぐこのサイトでも、新しい方法論の提案があったと記した。
 →「プロジェクト・マネジメントの世界は変わりつつある」(2006-10-11) https://brevis.exblog.jp/4313708/

面白い考え方だから、すぐに日本の学会などでも盛んに紹介されるだろう、と思っていた。だが、これはいささか見込み違いだったようだ。あれほど日本人が大勢参加した大会だったのに、日本で一部の先進的な人がこの手法を研究し始めたのは、さらに数年後のことだった。

それが、10年以上経った今、急にネットなどでもこの用語を見かけるようになった。なぜか? その理由は、PMBOK Guide第6版に、アーンド・スケジュール法が正式に載ったからである。PMBOK Guideに載ると、PMP資格試験に出るから、勉強の対象になる。試験に出なければ、あまり研究しない。わたし達の社会の、外部からの知恵の学び方には、多少の歪みがあるのではないか?

まあ、そんな皮肉はさておいて、具体的にどう言う方法なのか、説明しよう。

ただ、アーンド・スケジュール手法を理解するためには、まず従来のEVMSにおける考え方をおさらいしておく必要がある。EVMSでのスケジュール・コントロールは、どのような指標を用いてきたのか。

いや、その前に、そもそも進捗コントロールとは、何のためにあるのか?

図を見てほしい。横軸にプロジェクトの開始から終了までの時間を取り、縦軸に使う費用の累積をプロットした、よくある図だ。一般にプロジェクトの開始時期はゆっくり立ち上がり、やがて活況に入るが、最後はまたスローダウンする。関わる人も同じ様に、少数→大人数→少数、という風に変化する。だから普通、このグラフはアルファベットのS字のような形になるため、「Sカーブ」と呼ばれる。

さて、計画段階で予想したSカーブは、図の黒い点線のようだった(計画線=Planned Valueと呼ぶ)。これに対して、現実の累積出費の線を、現在日付まで引いたら、青い実線のようになった(実績出費=Actual Cost)。この図から、どんなことが言えるだろうか。
プロジェクトの進捗を計る「アーンド・スケジュール法」とは何か 〜 (1)その基本_e0058447_06500057.jpg
一見してわかる通り、計画時点での出費予定に比べて、実績出費の方が大きくなっている。つまり想定したよりも、お金が出て行っているのだ。これはまずい状態だ! 大変だ! ・・これが普通の感覚だろう。そして、これがたとえば広報予算だとか電気代といった、定常的な出費なら、それは正しい。

しかし、これはプロジェクトなのだ。プロジェクトとは、達成すべきゴールがある、一過性の仕事である。だからそこには、『進捗』の概念がある。進捗が進んでいればいるほど、プロジェクトが早くゴールに到達するから、良いことだ。ところで、仕事が早く進んだら、そのぶん、出費も前倒しで出ていかないだろうか? その場合、実績出費ACの線は、計画線PVより、左(上)に来るはずである。

となると、この図は、どう読み取るべきなのだろうか。出費が予定よりもかさんだ、まずい状態というべきなのか。それとも、仕事が予定よりも早く進んでいる、良い状態なのか?

答えは、「分からない」、である。この図の2本の線だけでは、プロジェクトの現状が良いのか、まずいのか、区別できない。穴があくほどこの図をにらんで見たって、判断はできない。なぜなら、この図には、「費用」と「進捗」の情報が、混ざっているからだ。その二つを区分するために助けとなるデータがなければ、正しい判断はおぼつかない。

では、その二つを区分するためのデータとは何か? それは、「その時点までに完了しているアクティビティの予算額を累計した金額」=「出来高」と呼ばれる量だ。これを英語で、Earned Value= EVという。

出来高(EV)と実績出費(AC)は、何が違うか。実績出費は、すでに完了しているアクティビティに使った、現実の金額の累計だ。だが、出来高は、予算額の累計である点が異なる。たとえば、あるアクティビティは100万円でできるだろうと計画していたが、現実には120万円かかってしまった。EV=100万で、AC=120万である。

しかしEVの線は、元の計画線(PV)も異なる。なぜなら、タイミングが異なるからだ。元の計画では、当該アクティビティは5月15日に完了する予定だった。だが実際には6月1日に完了した。そうなると、PVには5/15に計上されるが、EVには6/01にならないと計上されない。

        費用  タイミング
計画線(PV)  予定  予定
出来高(EV)  予定  実績
実績出費(AC) 実績  実績  

そこで、図に3本目の線として、出来高EVの線を描き加えて見たところ、次の図のようになったとしよう。EVの線は、計画線PVよりも下側に来ている。これから、何がわかるか。
プロジェクトの進捗を計る「アーンド・スケジュール法」とは何か 〜 (1)その基本_e0058447_06505837.jpg
出来高EVが、計画線PVよりも小さいということは、
 「すでに完了したアクティビティの予定出費累計」<「計画上では完了しているはずだったアクティビティの予定出費累計」
であることを示している。言い換えると、このプロジェクトは、予定よりも進捗が遅れているのだ。

さらに、出来高EVは、実績出費ACよりも小さい。これは、
 「すでに完了したアクティビティの予定出費累計」<「すでに完了したアクティビティの実績出費累計」
を意味する。つまり、見積もっていたよりも大きな費用が出ていっているのだ。

まとめると、こうなる:本プロジェクトは、予定よりも進捗が遅れており、かつ、予定よりも費用がかかっている。だから、非常にやばい状況のプロジェクトなのだ!

非常にまずい状況にあることは、最初の2本の線だけでは、判別できなかった。これがわかったのは、3本目の出来高EVの線を描き加えて、比較したからだ。このように、出来高Earned valueという指標を使って、プロジェクトの進捗とコストについて予実管理する手法の体系を、Earned value management system = EVMSと呼ぶ。

上の表に示したように、EVとPVとを比較すると、両者とも費用は同じなので、タイミングの差=進捗の差が検出できる。ここで
 SV = EV - PV
を、「スケジュール差異」schedule varianceと呼ぶ。SVは値が大きいほど、良い。マイナスだったら遅れていることを示す。

また、EVとACを比較すると、両方ともタイミングは同じなので、費用の差だけが検出できる。つまり
 CV = EV - AC
は、「コスト差異」cost varianceと呼ばれる量で、これも大きいほど良い。マイナスは、赤字を示す。

スケジュール差異SVも、コスト差異CVも、出来高EVを比較の軸にしている点を覚えておいてほしい。だから、この手法をEVMS(出来高マネジメント・システム)と呼ぶのだ。

EVMSは、WBS(Work Breakdown Structure)、PERT/CPM(クリティカル・パス法)と並んで、モダンPM理論における三本柱となっている。周知の通りプロジェクトの三大制約条件は、コスト・スコープ・スケジュールである。そしてEVMSはコストを、WBSはスコープを、PERT/CPMはスケジュールを、定量化しコントロールするための方法論なのだ。だから、この三つの概念と手法を理解し使いこなせるかが、プロジェクト・マネジメント能力のバロメーターになっている。

ただし、スケジュール差異SVは、実務的には、若干使いにくい点がある。なぜなら、SV=EV-PVで、その単位は金額なのだ。現時点までにPVは1000万円になっているはずだった。だが現時点の出来高EVは700万円でしかない。だから進捗が遅れているわけだが、

 「プロジェクトはどれくらい遅れているのか?」
 「はい、300万円ほど、遅れています。」

・・じゃ、話がわかりにくい。そこで、実務の世界では、『進捗率』に換算して議論するのが普通だ。

 進捗率=[現在のEV]/[完了時のEV]

たとえば上記プロジェクトの完了時のEV(ということは、とりもなおさず予算総額だが)が1500万円だったとしよう。EVが700万円なら、進捗率は700 / 1500=46.7%、ということになる。計画線では、66.7%の進捗が達成されているはずだった。だが現実は46.7%しかない。遅れは、全体の20%ぶんに相当する・・この方が、はるかに直感的で分かりやすい。

という訳で、EVMSによる進捗のコントロールは、理屈の上でもすっきりしているし、現実にも計測しやすい、はずであった。

だが実は、EVMSには一つ、非常に厄介な弱点があった。そして、それを克服するために、「アーンド・スケジュール法」が考案されたのだった。長くなって来たので、続きは次回書こう。

(この項つづく)


by Tomoichi_Sato | 2019-05-17 07:48 | プロジェクト・マネジメント | Comments(2)

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

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

デジタル・トランスフォーメーション(略称DX)という概念が、今やビジネス界を席巻しています。最近発達の著しい『デジタル技術』をキーに、新しいビジネスドメインを開拓し、事業のあり方を変える、との意味で使われていることは、皆さんもご存知のことと思います。

そしてDXのための手法として、デザイン思考(Design Thinking)が注目されています。デザイン思考とワークショップ形式で衆知を結集し、アジャイル開発によってその成果をMVP(Minimum Viable Products)に結実します。これを核に、新しい価値を創出するのだ、という説明をよく聞くようになりました。これは従来の、「ITシステムは業務の効率化が目的」「システムはSIerが受託開発する」「開発プロジェクトはウォーターフォール型で遂行する」という常識から、相当に飛躍することを要請します。

そこで今回は、日本を代表するSI事業者である富士通のシニアフェロー・宮田一雄様をお招きして、同社におけるデジタル・トランスフォーメーションへの取り組みについてお話いただきます。宮田様は元・富士通ウェストの社長で、TOC理論によるクリティカルチェーン実践なども進めておられましたが、新たに本社で「デジタルフロント」ビジネスグループを立ち上げ、陣頭指揮をとられています。

同社が顧客のDXを支援する取り組みも興味深いものですが、同時に、天下の富士通さんが、従来の受託SI事業から転身(トランスフォーメーション)する試みとしても、非常に注目すべきと思います。

大勢の皆様のご来聴をお待ちしております。

<記>

■日時:2019年5月21日(火) 18:30~20:30

■場所:田町キャンパスイノベーションセンター 
 5F スペース:509AB
 (いつもの慶応大学三田キャンパスとは場所が違いますのでご注意下さい!
  JR田町駅の芝浦口から右方向の階段をおりて、50mほど先の右手の建物です)

■講演タイトル:
「デジタル時代に対応する富士通の取組ご紹介
 ~ デジタルイノベータの育成 ~」

■概要:
 DXの潮流の中、富士通自身が新たな価値を創造しないと破壊されてしまうという危機感を強く感じている。
 お客様のDX推進パートナーとして認知されるために、2017年1月に社内出島としてデジタルフロントビジネスグループを設立して、社内のモード2人材を発掘して新たなデジタル人材の育成とビジネス開発に取り組んできた。
 2年間の人材育成の取組内容や生まれてきた成果と課題、そして今後目指す2階建て経営への展望を紹介する。

■講師:宮田 一雄(みやた かずお)
 富士通株式会社 シニアフェロー

■講師略歴:
 1977年富士通入社。SEとして銀行(信金・地銀)・証券・通信キャリアなど、数多くのお客様を担当。
SEとして、プロジェクトマネージャーとして、大規模SIのプロジェクトを数多く経験する。
 2011年に株式会社富士通アドバンストソリューションズ、2015年から株式会社富士通システムズ・ウエストの代表取締役社長に就任。ICT業界におけるプロジェクトマネジメントの問題改善のため、TOCやCCPM理論に基づいた取り組みを進める。2016年11月から富士通株式会社の執行役員常務に就任。
 デジタル社会に向けたビジネスの変革と人材育成を進め、2019年2月からMobilityビジネスを担当。

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 参加を希望される方は、確認のため、できましたら前日までに三好副幹事までご連絡ください。

 以上、よろしくお願いいたします。


佐藤知一@日揮(株)


by Tomoichi_Sato | 2019-05-02 19:36 | プロジェクト・マネジメント | Comments(1)

PMBOK Guideに欠けている、3つの重要事項

春である。4月の花咲く頃になると、今年は何人くらい受講生がいるかな、とそわそわした気持ちを抱えながら、つくばエクスプレスに乗る日が来る。東大の柏の葉キャンパスで「プロジェクト・マネジメント特論」の開講日を迎えるからだ。まだ働いた経験のない学生たちに、PM論を教えるのは、あまり簡単でない。それでも柏の葉キャンパスは大学院なので、皆、とりあえず自分の卒論で多少は苦労した経験を抱えて、入って来る。つまり小さくて個人的ながら、プロジェクト的な取り組みをした訳だ。だから学部生よりは、少しだけ教えやすい。

PM論を教えるにあたって、どんな構成・体系で説明を進めるべきかも、悩ましい。大学で講義を持っている、というと、「じゃあPMBOKを教えるんですね」とたずねてくる人が時々おられる。こういう人は、PMBOK Guide®︎が『教科書』だと信じているのだろう。だがあれは、いくつかあるガイドブックの一つにすぎない。よくまとまっているが、あまり書かれていない部分、足りない部分もある。

たとえば、プロジェクトの類型論である。これがないのは、けっこう痛い。古今東西、すべてのプロジェクトが同じ一つの道具立てでマネージできる訳ではない。数ある技法やプロセスの、どれを使うべきか、どれが自分のプロジェクトにあっているのかを、判断する具体的な基準が、PMBOKには書いていない。

最初に読んだときから感じているのだが、PMBOK Guideには、無意識に前提されていることが一つある。それは、プロジェクトが比較的「固い」スコープをもって出発する、との前提である。そこで、SOW(Statement of Work=作業範囲記述書)を初期インプットとして、プロマネがProject Charter(=PMBOK日本語版では「プロジェクト憲章」と訳されている)をまず作る、といった作業プロセスが規定される。Charterはさらに、プロジェクト・マネジメント計画書のインプットとなり、その中でWBSが展開される・・と続く。SOWは、まさにプロジェクトの出発点である。

では、そのSOWなるものは、どこから来るのか? プロマネが受け取るのだから、プロジェクト・チームの外部から、ポンと来るわけだ。解説書などを読むと、プロジェクトの成果を利用する組織が作る、と書いてある。社内利用なら、内部のsponsoring organizationが、また外部顧客の利用なら、顧客から来る、と。だとすると、自動車の新車開発プロジェクトでは、まだ見ぬ顧客からSOWが届くのだろうか?

種明かしをしよう。SOWは、プロジェクトの発注者から来るのである。米国PMIで初期のPMBOK Guideをつくった人たちの多くは、防衛産業・航空宇宙産業やエンジニアリング産業の出身だった。彼らにとって、プロジェクトとは受注型のビジネスであり、「何を作るべきか」は発注者(国防総省とか石油メジャーとか)が決めるものであった。そして(少なくとも米国においては)国の機関や大企業は、自分達の要求事項は事細かに、紙に書いて入札を行うのだ。それは業界によってITBとかRFQとかいろいろな名前で呼ばれるが、抽象化してStatement of Workと呼ぶことにしたのだろう。

初期のPMBOK Guideにおいては、プロジェクトとは受注型であり、かつ明確なスコープから出発するものだ、という無意識の前提があった。だから、エンジニアリング業界に身を置くわたしのような者が読むと、なんだか似たような業種の匂いがぷんぷん感じられた。ただし、プロジェクトには自社が決めて行う、自発型のものもあるし、PMBOK Guideが標準である以上、それにも適用可能な記述でなければならない。だから、「社内利用の場合はsponsoring organizationがSOWをつくる」といった、なんだか無理の多い話になるのである。新車は誰が利用するものだろうか?

PMBOK Guideがもう一つ、無意識に前提したことがあった。それは、プロジェクトは複雑で大型の営為である、という感覚である。これも、防衛宇宙産業やエンジニアリング産業からみれば当然のことであった。大規模プロジェクトの場合、必然的に、「計画」「契約」そして「計数管理」が大切になる。わたしはこれを、プロジェクト・マネージャーの3Kと呼んでいる。この三つが、プロマネの仕事をひどく大変にするのだ。また、受注型プロジェクトではたいてい、コスト制約・スケジュール制約が厳しい。したがってプロマネに、より強い権限を与えるような組織体勢が望まれる。

ところで、世の中には自発型のプロジェクトもある。新製品開発がその典型だ。あるいは、イノベーティブな技術開発とか、自社向けの業務システム開発などもそうだろう。こちらは、ふつうスコープが柔かい。コスト制約よりも、プロジェクト価値の最大化がねらいになる。そこで、品質(とくに設計の品質)が重要になる。このような種類のプロジェクトに、計画・契約・計数管理を持ち込んでプロマネに権限を集中し、ギリギリやっても、あまり楽しい結果が出てきそうにない。別の種類のマネジメント技法が望まれるのだ。

これに関連して思うのは、PMBOK Guideに設計論がない、ということである。なぜ、10個の知識エリアには、『設計のマネジメント』が入っていないのか? プロジェクトが独自の製品・サービスを生み出すための有期性の業務であるなら、必ずその中には設計業務があるはずではないか。その設計のあり方、良し悪しが、その後のプロジェクトを大きく左右する。ヘマな設計をすると、作りにくく、時間がかかり、コストもかさむ。

設計によって、その後の段取りや作業が全く変わることも多い。3階建ての建物を作るとき、鉄骨造で設計するのと、木造2X4(ツーバイフォー)で考えるのでは、工法や要員や作業手順が全く変わる。それどころか、力学的構造が全く異なるので、建築デザインの見た目も、大きく異なる。それくらい、設計段階の意思決定は重要なのだ。

なのに、PMの知識エリアには品質やコストはあれど、「設計」がない。設計抜きで、構築(製造・実装・建設)だけがプロマネの仕事、という観念は奇妙である。え? 設計は分野ごとに個別性が高いから、Guideに書くのは適当ではない? だが、そもそも、分野ごとに個別性が高いのがプロジェクトの特性であろう。それでも、共通なプロセスを考えることは十分可能なはずだ。

その一例が、システムズ・エンジニアリング分野から発した「V字モデル」である。これは対象がシステムであれば、人工衛星であろうがワープロソフトだろうが共通に当てはまる。また、「エンジニアリング・マネジメント」という言葉は、日本ではプラント業界くらいしかお目にかからないが、米国にはEngineering Managementを教える専門学科だって存在する。だったらなぜ、PM論の中に、設計マネジメントがないのか?

なお、ここで問題にしているのは「プロジェクトのデザイン」(=WBSをどう作るか)の話ではない。また、製品デザイン(=美大を出たデザイナー達が行う仕事)だけの話でもない。エンジニア達の普通の仕事としての「設計論」である。

現在のPMBOKに設計論が欠けている理由は、わたしの想像であるが、おそらく米国における分離発注の商慣習にあったのではないか、と思われる。つまり、

 「基本設計」の段階 →(見積と競争入札)→ 「構築プロジェクト」(実装・製造・建設)の段階

の二段階に、発注を分離する、という商慣習である。たとえば建築業界では、20世紀前半から、「建築設計」→「施工」が別々の主体で、別契約になることが一般的だった(少なくとも英米では)。プラント業界でも、80年代頃には、「基本設計」(FEED)→「詳細設計・調達・建設」(EPC)が別になるのが一般化した。防衛宇宙産業のことはよく知らないのだが、米国政府発注なので、似たような分離発注形式をとっていたのではないか。

前段の基本設計において、かなり詳細な(=コスト見積が可能なレベルの)仕様書を作成しておき、契約書の雛形も用意しておく。競争入札を経て、後段の構築プロジェクトに入る。そしてPMBOK Guideを作った初期の人たちは、構築プロジェクトにもっぱら携わる業界人だった。だから、プロジェクトの最初にSOWがあるのは、彼らにとって当たり前だったのだ。そして、設計の主要な部分はもう終わっているのだから、知識エリアに設計マネジメントは入らなかった、と。

ところで、これが本当だとすると、IT業界にとってはいささか気の毒なことだった。なぜなら、SIプロジェクトの分野で、「要件定義」→「設計・実装」が別フェーズとして分離するのは、もっと遅かったからだ。ソフトウェア開発プロジェクトでは、一般に要件定義が「柔らかい」(固めにくい)ため、設計・実装のスコープも柔らかくなってしまう。そして、IT系プロジェクトの難しさのかなりの部分は、このスコープの曖昧さから生まれるからだ。

おそらく、初期のPMBOKコミュニティには、IT業界の人が少なかったのではないか。そして、少し後になってから、PMが注目されるようになった(日本での普及期は2000年台に入ってからだ)。そして、PMBOK Guideを学ぶことが推奨された。だがPMBOKが無意識に前提するハード型の一括発注契約を、ソフト型であるIT開発プロジェクトに適用したことが、多少の無理を生んだのではないかと想像される。

そして、この不足を補うべく、BA(ビジネス・アナリスト)の実務標準を最近になって付け加えたのだろう。設計(とくに基本設計)が、プロジェクトにおいて重要だと、あらためて皆が痛感したからである。

ちなみに、IIBAの「ビジネスアナリシス知識体系ガイド (BABOKガイド)」https://amzn.to/2OQvnMF などを読んでいると、同じような設計マネジメントのアプローチが、IT以外の分野でも必要だし有効だ、と気づく。ただ、BABOK自体、Version 3.0になってずいぶん良くなったが、まだ発展途上だという印象が強い。デザイン思考がIT分野で注目を集めている今日、もっと設計論は必要だと思う。

さて、PMBOK Guideに書いておいてほしかった第3のポイントは、プロジェクトの評価論(価値論)である。

プロジェクト・マネジメントの最大の仕事は、決断することだ。決断とは、複数の選択肢から、最も良いと信ずるものを選ぶことである。だが、最も良いとは、どういう意味か?

プロジェクト・マネージャーの責務とは、プロジェクトの価値を最大化することだ、とも言える。それがプロマネの査定、成績表になるはずである。では、プロジェクトの価値とはいったい何か? スコープ・コスト・スケジュールの制約条件(「鉄の三角形」)を守ることだろうか? それとも、成果物のもたらす顧客満足なりベネフィットを最大化することか?

もし後者だとしたら、じゃあ、「ちゃんと作ったけれど、使われないシステム」の価値はどうなるのだろうか? わたし自身も過去にそういうものを作った苦い経験があるから書くのだけれど、その場合、プロマネの点数は落第点となるのか。たとえば、ユーザが旧来の仕事のやり方を変えることに抵抗したら? それはプロマネの責任範囲なのだろうか。

あるいは、逆に、あえて機能とスコープを増やしたおかげで、予算を超過し納期も遅れたが、顧客が喜んで使ってくれるようなシステムを作るのは、是か非か? つまり、プロジェクトの価値とは、成果物(アウトプット)で評価するのか、アウトカムで評価すべきなのか。これが決まらないと、プロマネは判断できないではないか。だが、こうした価値論が、現在のPMBOK Guideには欠けている。

多くのプロマネは、しばしば二律背反のトレードオフに直面するものだ。外注先は、価格の安さを取るか品質を取るか。計画では、コストを取るか、スケジュールを取るか。目標設定では、リスクを取ってでも、リターン(利益)の最大化を狙うべきか? こうしたトレードオフについて、ある程度までは、出発時のミッション・プロファイリングとCharterで、判断基準の優先度を事前定義できる。だが、プロジェクトの途上で起きる全ての判断パターンを、事前に定義できる訳もない。

ところで、PMBOK Guideには価値論がないが、モダンPM論の世界に、全く欠けている訳ではないことは、知っておくべきだ。英国の商務省が開発した標準の中には、「Management of Value」(略称MoV)という標準書がある。現在はAXELOSという会社が版権を所有している。内容をざっと知りたければ、たとえば下記のSlideShareをみるといいと思う。
AXELOS - MoV® - Management of Value - Foundation

このMoVでは、Valueという尺度を、次式で定義している。

PMBOK Guideに欠けている、3つの重要事項_e0058447_20303249.jpg

つまり、単にベネフィット(便益)を最大化しても、それに投入する資源(コスト等)がむやみに増えてしまったら、全体としてはプロジェクトの価値が下がるのだ。この定義式は概念的なもので、必ずしも定量化に向いている訳ではないが、一つのわかりやすい表現ではある。そして、こういう議論は、とても欧州のPM論に特徴的だな、とわたしは感じる。欧州のPM研究では、プロジェクトのスコープを所与のものとして扱わず、より大きな社会的文脈の中で評価しようという視点が強いからだ。

類型論、設計論、価値論--この三つを、今後のPMBOK Guideはもう少し盛り込んで欲しいと、わたしは思っている。念のためにいっておくが、わたしは別にPMBOK Guideを批判したり否定している訳ではない。ただ、それが完璧な教科書だと信じて、鵜呑みにしないようにしよう、と主張しているだけだ。

前にも書いたが、教科書を暗記しすぎる人は、プロジェクト・マネージャーには向かない。PMBOKというのは、署名にもある通り、Guideである。ガイドなのだから、皆、自分自身で考え、自分の足で山に登っていく必要があるのだ。


<関連エントリ>
 →「プロジェクトのスコープには硬軟がある」 https://brevis.exblog.jp/27558796/ (2018-09-20)
 →「オーケストラの指揮者かジャズ・バンドのリーダーか - プロジェクト・マネジメントの4つの類型を知る」 https://brevis.exblog.jp/21641066/ (2014-02-02


by Tomoichi_Sato | 2019-04-06 20:48 | プロジェクト・マネジメント | Comments(0)

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

前回から少し間が空いてしまいましたが、「プロジェクト&プログラム・アナリシス研究部会」の2019年第1回会合を開催いたします。

皆さんは、自分や人の『感情』がマネジメント可能だと考えたことがおありでしょうか? あるいは、プロジェクトにも感情があるのでは、と思うことはありませんか?

プロジェクト・マネージャーの仕事の半分以上は、コミュニケーションにあてられています。チーム員や顧客・外部のステークホルダーとのやりとりに時間が割かれ、しかもその多くは、単なる情報伝達以上の、説得や交渉や動機付けといった難しい仕事です。難しい理由は、自分や他人が内心抱えている「感情」が、伝えるべき「理路」を左右してしまうからでしょう。おまけに、感情には一種の共鳴性ないし伝染性があり、チームの中でどんどん広がっていきます。

では、そもそも、感情にはどんな種類があるのか。自分や他者が抱えている感情に気づくには、どうしたら良いか。そして感情はどんなダイナミクスに従って動くのか。こうした感情に関する教育やトレーニングは、ほとんど受けたことがない人ばかりだと思います。

今回はPM関係の教育・コンサルティングに従事しておられるアイシンク(株)の丸山奈緒子様に、感情マネジメントのスキルについて、入門編をお話いただきます。目からウロコの話題がたくさん出ること、請け合いです。プロマネの仕事は技術をリードすることだ、だから優秀な技術者がやればいい、と信じている組織が世間ではほとんどでしょうが、本当は感情とリスクのマネジメントがその8割以上なのではないかと、皆さんもきっと思われるようになるはずです。

大勢の皆様のご来聴をお待ちしております。

<記>

■日時:2019年3月13日(水) 18:30~20:30

■場所:慶応大学三田キャンパス 研究室棟B
※キャンパスマップの【10】

■講演タイトル:
「プロジェクトマネジャーが高めたい『感情マネジメント』スキル」

■概要:
 感情の取り扱い能力は、個人やチームのパフォーマンスを高めるうえで大変重要です。
 一方で、ネガティブな感情に振り回されたり、むやみに抑え込もうとしたりと、
 どのように扱うべきか学ぶ機会がなかった方が少なくありません。
 本講演ではプロジェクトマネジャーなどチームを率いる方に知ってほしい、
 感情とのつき合い方についてお伝えします。

■講師:アイシンク(株)
丸山奈緒子(まるやま・なおこ)

■講師略歴:
 お茶の水女子大学 生活科学部 発達臨床心理学卒
 桜美林大学大学院 心理学研究科 修士課程修了
 日本健康心理学会認定 専門健康心理士
 米国PMI®認定PMP®
 東京大学特別講師
 心理学をベースにしたヒューマンスキル系講座の開発・講師担当。ストレスマネジメント、
 アサーション、コーチング、交流分析、ファシリテーションなど、PMのニーズに即した講座を提供。

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 参加を希望される方は、確認のため、できましたら前日までに三好副幹事までご連絡ください。

 以上、よろしくお願いいたします。


佐藤知一@日揮(株)


by Tomoichi_Sato | 2019-02-17 15:00 | プロジェクト・マネジメント | Comments(3)