人気ブログランキング |

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

「プロジェクト&プログラム・アナリシス研究部会」(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)を参照してほしい(ただし、以前の記事の図とは、意図的にいくつか数字を変えているので注意されたい)。

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)]
e0058447_06033096.jpg

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

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

[表2 実際の出来高(EV)]
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)。この図から、どんなことが言えるだろうか。
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よりも下側に来ている。これから、何がわかるか。
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という尺度を、次式で定義している。

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)

プロジェクトのオーナーシップとは何か

オーナー(Ower)とは、所有者であり、オーナーシップ(Ownership)とは所有権を意味する。ただ英語の語尾 -shipは、名詞について、それを持つ人の志や、性質や「らしさ」をも示す(例えばリーダーとリーダーシップのように)。だから、オーナーシップとは、所有者らしいふるまい、ということにもなる。

有形のもの、車とか家などのオーナーシップの意味は、誰にも明らかだ。そのものを所有して、自分の意のままにすることができる。無形のもの、例えばライセンスといったものにも、オーナーシップを考えることができる。自分がお金を払い、そこから得られる便益を自分の自由にすることができる。何であれ、それを維持する労力や費用負担し、そこから主たる価値を得るものは、それに対するオーナーシップを持つと言えるだろう。

それでは、プロジェクトのオーナーシップとは、何なのか?

X社のプロマネP氏は、困惑していた。大型プロジェクトを受注して数ヶ月。このままでは、かなりの赤字になることが明白だ。現時点での詳細設計から、全体コストを見積もり直してみると、当初想定していた金額を大幅に上回ってしまう。

顧客のA社に窮状を訴えて、追加費用を出してもらうことも考え、実際内々に打診してみた。だが顧客の反応は冷たかった。そもそも基本設計も、X社が有償で行なったのではないか。その基本設計書の内容をもとに、両者が合意して一括請負契約を結んだのだから、その通り実行してもらいたい。それが向こう側の言い分だった。

確かにその通りだ。要件定義は前任者のプロマネが行い、P氏はそれを引き継いだまでだ。ただ、顧客の業務要件は思ったよりはるかに複雑で、例外が多く、新しく入ったメンバーが理解するまでの時間も、かなり必要だった。

おまけにもっとまずい事に、プロジェクトで中心的に使うつもりでいた自社製の新型装置を、隣のチームが並行して開発中だったのだが、予定された期日からかなり遅れていた。基本設計レベルに問題があったらしく、期待したパフォーマンスがさっぱり出ないのだ。そのおかげで、上司の命令により、自分のチームから優秀なメンバーを数名、隣に回さなければいけなくなった。

仕様は思ったより膨らんでいる。優秀なメンバーもとられてしまった。あてにしていた中核装置も出来上がってこない。顧客は頑固な態度である。このままでは赤字は必至だ。一体どうしたらいいのか?

世の中ではしばしば、大赤字を生みデスマーチが見えているプロジェクトが、延々と続けられている。なぜだろうか。受注したからには完成させるのが受注者の義務? だが、たとえ違約金を払ってでも、プロジェクトから降りてしまう方が、ビジネス的には傷が小さく済む場合だってあるではないか。

だが、一般にプロジェクト・マネージャーには、プロジェクトを中止・撤退する権限はないのである。プロマネとは、プロジェクトを遂行するように命じられた存在である。遂行の義務と責任を負っている。仕事のパフォーマンスがまずくて、プロマネの職を解かれることはある。だが、プロジェクトの価値が下がったからといって、自分からプロジェクトの遂行をやめる権利は無い(会社自体を辞めてしまうなら別だが)。

そこで改めて考えてみよう。プロマネを任命するのは、一体誰か。プロマネの成果を認定し、評価するのは誰なのか?

それが、「プロジェクト・オーナー」なのである(オーナーは、業界によっては「スポンサー」と呼ばれる場合もある)。プロジェクトの価値を考え、プロジェクトを発進させ、プロマネを任命し、予算を与えるのがオーナーの仕事である。なお、プロジェクトが上位の「プログラム」の一部である場合は、プログラム・マネージャーがオーナーシップをとる。だが、日本ではプログラム・マネジメントをまともに実施している企業がほとんど無いため、そのケースは無視していい。

さて、苦境に陥ったP氏は、上司である事業部長K氏に、状況を正直に報告し、対策を相談した。事業部長が、このプロジェクトのオーナーだったからだ。そこでK事業部長も、自ら顧客に追加交渉にいってみた。だが、相変わらず相手の態度は硬い。このまま続ければ、この開発プロジェクトと、自社の新型装置開発の、二つのプロジェクトがともに道連れで沈没しかねない。

K氏はさらに上の役員と相談の上、苦渋の決断を下した。顧客A社に対し、違約金を払って、このプロジェクトから降りると宣言したのだ。

発注者A社側のプロジェクト責任者は、X社の撤退に驚き、大いに怒った。たとえ違約金をもらったからといって、費やした時間も労力もかなり無駄になったからだ。しかしA社の担当役員は、X社の決断に舌を巻き、内心、敬意を評したという。X社が受注者としてのスポンサーシップを発揮し、痛みは伴うが適切な決断を下したからだ。「確かにウチは迷惑した。だが、あの決断は大したものだ。なかなかできる決断ではない。」

撤退の判断は、つねに難しい。特に受注型プロジェクトの場合は、なおさらだ。お金も労力も失われるが、自分のメンツや顧客からの評判は丸潰れになる。業績評定にだって、大いに影響が出るだろう。

プロジェクトが完遂できないのは、明らかにプロジェクト・マネジメントの失敗である。だが、失敗したプロジェクトから、適切なタイミングで撤退する事は、正しいオーナーシップの発揮なのだ。この点を世間の人は誤解しがちなので、あえて繰り返し強調しておく。失敗したプロジェクトから思い切りよく撤退する事は、オーナーシップの失敗ではない。

オーナーシップの失敗とは、価値のなくなったプロジェクトを、延々と続ける事なのだ。プロジェクトにおいて最も恐ろしい事とは、プロジェクト自体が自己目的化してしまう事だ。ゴールに到達したが、結果は無価値で、労力と金と時間の無駄だった、という事ほど、人心を荒廃させる事はない。それはオーナーシップの不在を意味する。

わたしは授業でよく、公共事業のケースを例にあげる。有名な公共事業の中には、すでに半世紀以上にわたって遂行中で、予算規模も千億円クラスのものがある。だが、終戦直後に計画されたその事業の完成を、もはや誰も待ち望んでいない。それでも続いているのはなぜか。役人という人種が、いったん始めた事は絶対に失敗を認めないし、撤回もしないからだ。だが、繰り返す。失敗を認めず、意味のなくなった事業を続けることこそ、より大いなる失敗なのだ。

もちろん、オーナーの仕事はプロジェクトを中止し撤退することだけではない。むしろそれは最後の選択肢だ。オーナーは、プロマネを助けて、プロジェクトが意味ある仕事として完遂することを支援するのが、本来の仕事である。

以前、米国のPMコンサルタントであるNeal Whittenの主張を紹介した(「プロジェクト・スポンサーシップが足りない」 https://brevis.exblog.jp/23393425/)。彼によると、米国におけるプロジェクトの問題の1/3は、オーナーシップの不全にある、という(彼は「スポンサー」という用語を使っている)。

それでは、プロジェクト・オーナーの仕事とは何か。それは、

  • プロジェクトを起動し
  • プロマネを任命し
  • Project Charterを承認し
  • 予算枠と期限を与え
  • プロジェクトの状態と価値を定期的にウォッチし、
  • プロマネの相談に乗り、助ける
  • プロジェクトの終結を承認し
  • あるいは、無価値となったプロジェクトを中止する

こうした、プロマネに対する「上からの支援」が、プロジェクトの成功のためには、非常に重要なのである。だからあえて、以前も掲げた図をここに再掲しておこう。
e0058447_23034860.jpg
プロジェクト・オーナー(スポンサー)は、プロマネの相談相手として機能しなければならない。そして、プロマネの悩みはたいてい決まっている。それは、お金が足りません、か、人が足りません、なのだ。オーナーというのは上級職の仕事で、普通はプロジェクトにフルタイムで関わることはない。だが、プロマネに対しては、いつでも悩みを聞いてあげる存在でなければならない。

ところが、わたし達の社会では、これが弱いのだ。あるいは、オーナーという役割が存在しない場合も多い。その必要性さえ、認識されていない。だが、プロマネを助けないプロマネの上司とは、一体何のためにいるのか?

とはいえ、多くの読者諸賢の職場では、実際問題、オーナーというポジションは存在しないかもしれない。だったら、どうすべきか。居ないものは居ないとして、それでもプロジェクトが倒れないようにするための、現実解を考えなければならない。

わたしがお勧めする方法は、三つである。

第一に、きちんとProject Charterを作ることだ。Charterというのは、日本では「憲章」と誤訳されているが、「趣意書・許可書」のことだ。もともと英国で、国王が特に出す勅許状のことを、Charterと呼んだ。特別仕立ての飛行機のことをチャーター便と呼ぶのは、その名残だ。また英国では、公式に認定された技術者をChartered Engineerと呼ぶ。

Project Charterという文書は、組織が、そのプロジェクトを公式に認めて、その発進を許す書状である。そこにはプロジェクトの目的や目標などを書く。そして本来は、このCharterはプロジェクト・オーナー(スポンサー)が作って、プロマネに与える、という建前になっている。少なくとも、PMPの試験では、そう書かないと正解にならない、と教わったはずだ。

だが現実には、プロマネがCharterを作っている企業が大半である(だってオーナーはいないのだから)。そこでCharterを作ったら、それをしかるべき上司に、承認してもらおう。表紙にハンコの承認欄を作るのもいい。判子をもらってしまえば、それは上司が公式に認めたことになる。そして上司にも責任(命令責任)が生じる。

あるいは、もう少しモダンなやり方としては、皆で集まってチームビルディングを行う。そして、最後に皆で「コミットメント・シート」を作る。そこにサインを寄せ書きする。無論、上司には中央にサインをしてもらおう。そのシートは、プロジェクト・ルームの壁に掲げて、いつでも見えるようにしておく。こうして、オーナーたるべき人物を、責任と面子のループに取り込んでおくことが重要である。わたし達の社会は、面子とコンセンサスの社会なのだから。

第二に、プロジェクトのJournalを頻繁に発信することである。Journalというのがまた、適切な訳語がない言葉なのだが、元々は日誌のことで、転じて定期刊行物や雑誌を意味するようになった。プロマネにとって、日誌をつけるのは非常に良い習慣である。それはいざという時の法的根拠にさえなる。だが、もっとソフトな意味で、定期的な情報発信のことを、ここでは言っている。

つまり「プロジェクト週報」だとか「プロジェクト新聞」といった簡単なニュースメールを発信し、関係者皆に送りつけるのである。関係者の中には、もちろん「オーナーたるべき人」も、さらにその上司をも、送付先に含めておく。

こうして、プロジェクトの状況を、定期的に、かつできる限り頻繁に、皆に知らせておき、上層部にも関心を持ってもらう。「そんなの多分、メルーボックスの肥やしになるだけだ」などと、最初から悲観してはいけない。捨てる神あれば拾う神ありで、世の中にはたまに、ちゃんと見ている人もいるのだ。プロマネはなるべく、いろんな人に味方になってもらう必要がある。

三番目の方法は、ちょっと大技だが、プロジェクトのために「ステアリング・コミッティー」を設置してしまう(設置してもらう)やり方だ。これは、拙著『世界を動かすプロジェクトマネジメントの教科書』 (最近増刷が決まった)に書いた方法でもある。

この本では、製造業の若手エンジニア・小川君が突然、海外企業とのジョイント・プロジェクトに巻き込まれるのだが、このプロジェクトたるや、誰がプロマネなのかも判然としない。そんな中、大学の先輩だった広田氏のアドバイスをもらいながら奮闘していく物語だ。その際、プロマネもオーナーも不明ながら、なんとか仕事を前に進めるために、あえて複数部門の管理職の層でステアリング・コミッティーを設置してもらうよう、小川君が上に提案する(広田氏がそう勧めたのだ)。

その顛末は本を読んでいただくとして、いったんコミッティーを作ると、なにせ面子とコンセンサスの国だから、なんとかサポートは得られる。そして、プロジェクト・ガバナンスの点からいうと、これはこれで立派な方策なのである。

もちろん、上記の三つの方法が、いつも功を奏するとは限らない。忙しい中、権限もないのに、実行するのはかなり大変だろう。でも、本当にプロジェクトが傾いてきたら、一番こまるのはプロマネの自分なのだ。だとしたら、少しでも会社にオーナーシップを自覚してもらうべきである。

それにしても、研究会などで多くのプロジェクト事例を聞くにつけ、感じることがある。日本の多くの組織で見られる、現場リーダークラスの共通の悩み、共通の問題があるのだ。

それは、ビジョンの不在や戦略の失敗を、戦術レベルでなんとかカバーしようと努力して苦労している、という事実だ。これが、中堅若手のプロマネや、サブリーダー・クラスの疲弊感を生んでいる。たとえば、営業部門が売上目標のために無理な価格、納期で受注してきた案件を、技術部門が苦心惨憺、遂行する。そして、プロジェクトをなんとか黒字にできないか、悩んでいる。あるいは、ヘンテコな製品戦略のために、新製品開発プロジェクトが迷走し、BOMや基準情報までが混乱する。こうした例は、枚挙にいとまがない。

なぜ、そんなことに努力を費やすのか。それは、現場リーダーに与えられた権限範囲と、リーダーの責任(評価・賞罰)とが、あっていないからだ。プロマネ自身ではどうしようもない環境条件において、結果だけを評価される。ここでプロジェクトの「環境」とは、プロマネが短期的な努力では左右し得ない条件をいう。

プロジェクトのオーナーシップは、プロマネを任命する権限を持つ者にある。したがって、プロジェクトの最終的な損益やアウトカムに対する最終的責任・評価もオーナー側にあるのだ。プロマネは与えられた条件下で、どこまで良くやったか(計画し遂行したか)を評価されるべきである。プロマネは、自分では途中でやめられないのだ。プロマネには実行責任がある。だが、命令責任は、オーナーは負うべきなのである。


<関連エントリ>
 →「プロジェクト・スポンサーシップが足りない」 https://brevis.exblog.jp/23393425/ (2015-07-08)
 →「アカウンタビリティとは『命令責任』である」 https://brevis.exblog.jp/24837740/ (2016-11-05)


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

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

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

当研究部会は2012年の12月に、4人の講師を招き、半日を使ってミニ・シンポジウムを開催しました。今回は、その時の講師の中で最も人気が高く反響の大きかった森茂利氏に、久しぶりにご講演いただきます。

森さんはリクルート社での長年の経験を起点に、現在はフリーのコンサルタントとして、主にサービス業のビジネス開発と組織づくりの仕事に関わっておられます。ところで、新しいサービスの開発とは、どのように進むものなのでしょうか? 周知の通り『独自の製品、サービス、所産を創造するために実施される有期性の業務』というのが、プロジェクトの一般的定義です。そして新製品開発だとかITシステム開発のように、成果物としての実質を作り出すプロジェクトについては、多く語られています。

しかし、目に見えず、顧客の利用と同時的にしか存在しえない「サービス」を開発していくプロジェクトの進め方、マネジメントのあり方は、当然かなり異なるはずです。とくに今回は、IT企業における事例をとりあげ、請負体質から脱却し、自らのビジネスをいかに創り上げていくかを、語っていただきます。またIT企業における営業のあり方には、さまざまな問題点が見受けられますが、森さんは営業・マーケティング改善のプロでもあり、その面でも、《お悩み解決》のヒントを多く聴けるはずです。

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

<記>

■日時:2018年11月27日(火) 18:30~20:30

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

■講演タイトル:
「IT企業 請負体質からの脱却
 〜 AIに振り回されず、お客さま起点で人材育成とサービス化推進中」

■概要:
50年続いているIT開発企業は、これまでずっと請負体質のままで商いを継続。しかし二代目社長になった年、次の成長にむけて、自立型企業への変革を一人に賭けた! この三年半の動きをお伝えします。

■講師:フリーエージェント、《稼げる力と強い組織創り》エヴァンジェリスト
森茂利(もり・しげとし)

■講師略歴:
名古屋工業大学卒
78年 リクルート入社
85年 ネットワーク起ち上げ事業に参加 技術系マネジャーとしてデータ・ 
   スーパーコンピュータ・音声サービスの技術支援部隊を統括
03年 ソフトブレーンに主席コンサルタントとして入社
15年 ソフトブレーン退社 独立コンサルタントとして、現在に至る

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

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


佐藤知一@日揮(株)


by Tomoichi_Sato | 2018-11-11 21:30 | プロジェクト・マネジメント | Comments(1)

海外プロジェクトの質的変化と、成功体験の罠

わたしが3年前に技術評論社から上梓した『世界を動かすプロジェクトマネジメントの教科書』は、製造業で働く若手エンジニアを主人公にした、ストーリー仕立ての本である。基本的な内容は、東大の大学院で教えている「プロジェクトマネジメント特論」の講義資料をベースにしているのだが、淡々とした記述のテキストなど、誰も興味をひかれないだろう。それにわたしは、対話形式の文章を書く方が、なぜか筆が進みやすい。

そこでこの本では、ある日突然、プロジェクト・マネジメントを急に学ばなくてはならなくなった若手技術者を、主役に立てることにした。それが、中堅製造業の製品設計部門に働くエンジニア、小川君である。彼の会社の社長は、出張先のとある新興国の企業経営者と意気投合し、共同でその国向けの製品開発プロジェクトをはじめることを、決めてくる。

しかしご承知の通り、製造業の組織というのは、営業・設計・生産技術・資材・製造・・という風に、機能別に縦割りになっている。製品開発プロジェクトは、これら全ての部署が、大なり小なり関わってくる。では、この海外企業との共同プロジェクトは、いったいどの部署の誰がリードするのか? 一般に、日本の製造業では、プロマネが所属すべき部署が、明確でないことが多い。小川君の会社もそうだった。

プロジェクト・マネージャーが誰なのかも不明なまま、結構な労力とリスクをはらむはずの、新プロジェクトは滑り出す。小川君自身はまだ、プロジェクト・マネージャーを張れるような職位ではないし、その経験もない。だが、会社のこの状況に危機感を抱いた彼は、久しぶりに会った大学時代の大先輩・広田氏に、プロジェクト・マネジメントの考え方を教えてほしいと頼み込む。

海外プロジェクトの経験に長けた広田氏は、何度かに分けて、小川君に基本をレクチャーしつつ、プロジェクトの状況を確かめ、アドバイスしていく。だが、海外通を任ずる常務、腰の引けた部長、妙に強気な課長などの上司の下で、プロジェクトを前に動かそうとする小川君に、つぎつぎと難題がふりかかってくる・・この本は、そういう話だ。

新製品開発という仕事それ自体は、製造業にとって珍しいことではあるまい。何度もそれを繰り返して、企業は成長してきているはずである。それなのに、海外企業との共同プロジェクトということになると、急に勝手が違ってくるばかりか、上手く回らなくなることが多い。それをたいていの会社は、言葉(英語)の壁だとか、技術基準の違いだとか、異文化のせいだとかにしたがる。

しかし、そこにはもっと本質的な、プロジェクト・マネジメント上の違いがあるのである。そして、多くの日本企業は、それを知らないまま、見えない壁のようなものに突き当たっているのだ。

図を見てほしい。横軸は、スコープの固さを示している。右側は自発型プロジェクトの世界で、スコープは自分で調整可能である。左側は受注型プロジェクトで、スコープは外部から与えられる。左に行けば行くほど、スコープは「固く」なる。自社の製品開発は、自分がかなり自由に決めることができるから、図では右側の領域にある。
e0058447_22584297.jpg
縦軸は、プロジェクト組織の規模・複雑さを示す軸だ。上は大型、下は小型プロジェクトの領域を意味する。ただし「規模」といっても、予算金額などで測ったのでは、プロジェクトの分野や種類によってかなり差が出てしまい、イメージが伝わりにくい。そこで図ではあえて、「小型プロジェクト」を、同じ行動習慣を持つ同士の協力、「大型プロジェクト」を行動習慣の異なる他社との協力、と注釈をつけた。

そうなると、従来の新製品開発は、図の右下の領域に位置づけられる。自社系列内で完結する場合もあるだろうし、サプライヤー等の他社と協力する場合もあるだろうが、それでも慣れた同士による国内プロジェクトである。

ところが、ほぼ同じ内容での製品開発プロジェクトも、小川君の会社のように、慣れない初めての海外企業と一緒にやることになると、図での位置が変わってくる。まず、海外企業との協力の場合、お互いの責任分担を文書化・契約化して、きっちり決める必要が出てくる。つまり、スコープがけっこう「固く」なるのである。

他方、これまでの慣れた同士の協力関係と違い、慣れない相手とは、コミュニケーションの言語やチャネルからはじまって、いろいろ目に見えない摩擦や障壁が生じがちだ。だからプロジェクト組織の規模・複雑性が,有意に上がることになる。

かくして、ほぼ同じ内容の筈の新製品開発プロジェクトが、図上でかなり左上にずれてしまう。そして、この図では、左上に行けば行くほど、専門的なプロジェクト・マネジメントが必要とされてくるのである。右下のエリアは、身内同士の阿吽の呼吸で進む領域であって、まあいってみれば、ジャズバンドのような世界である。誰かリーダーのもつ、気合いやリーダーシップで進めることができる。

ところが左上の領域は、いわばオーケストラの世界であって、数多くの演奏家(専門職種)と、指揮者(プロマネ)がいて、整然とことを進めなければいけない。各人がバラバラに動いたのでは、意味のある成果は出てこないのだ。スコープ制約が固く、かつ組織規模が大きい仕事とは、そういう存在だ。それなのに、プロジェクト・マネジメント技術もろくに知らぬまま、「気合いと根性」だけで海外プロジェクトをはじめたら、途中で現場が苦労の嵐に巻き込まれることになる。

これが、今、わたし達の社会のあちこちで起きている問題なのだ。そして、多くの若手エンジニア達が、さんざん苦労している。そういうことを、霞ヶ関の新進気鋭の官僚達にも知ってほしい。そう思って、レクチャーでは、前回も述べたように、スコープの話を主にしたのだが、さて、短い時間でどこまで伝わるかは、定かでない。そこで、あえて念押しとして、もう一枚、図を用意した。

e0058447_22595509.jpg
こちらの図は、左右がある意味、逆になっており、右に受注型プロジェクト、左に自発型プロジェクトを置いてある(不統一で申し訳ない)。上の欄に、(強い)←→(弱い) と書いてあるのは、スコープに対する主導権である。自発型の方が、当然ながらスコープの主導権が強い。受注型では、発注者の承認をもらわなければ、スコープ・チェンジが認められない。

こちらの図の上下は、買い手か売り手かという、商取引の立場になっている。取引では通常、お金を出す側の買い手(顧客)の方が強く、売り手の方が立場が弱い。

そして、この図表の4象限に、日本の海外ビジネスのあり方と変化を集約してある。

まず、高度成長期の’70〜80年代は、左下にある。この時代、衣料品にはじまり、家電・カメラ、そして自動車など、消費財の輸出で日本が伸びた時代であった。優秀・高品質な製品力と、円安による競争力に支えられ、大きく世界に進出していった。自分は売り手だからやや立場は弱いが、どこに何を売るかは自分で選ぶことができた。この時期は、「売ってあげる」型の輸出ビジネスだった、といえる。

それが'80年代後半~90年代前半のバブル時代に入ると、さらに勢いをかって、盛んに海外不動産を買ったり、企業買収・工場建設・営業所開設などのラッシュが続いた。舞台は欧米や豪州など先進国だ。そして自分が買い手で、かつ、自発型プロジェクトである。いわば最強の立場にあった時代だ。

ところがバブルがはじけ、不況の2000年代に入ると、海外調達・部品製造外注・オフショア開発などが、海外ビジネスの中心になってくる。まだ、立場は買い手だ。だが相手地域はアジア・中進国にシフトする。そして現地に行った技術者たちは、本社や日本国内の顧客からの勝手な指示に困惑しつつ、内心、OKY(「お前が来てやって見ろ」)と歯噛みしながら仕事をしていた。

そして2010年代。政府は「日本の新成長戦略」をとりまとめ、新興国に対するインフラ・システム輸出が、成長力回復の切り札だ、と位置づける。しかし、日本のものづくりの成果を海外に持っていくという事は、売り手で、受注型のプロジェクトを遂行することを意味する。すなわち、「買って下さい」型の輸出ビジネスになる、という訳だ。

わたしは長年プラント・エンジニアリング業界に働いてきた身として、それがいかに弱い立場であるかを知っているし、その中でいかに立ち回るべきかも、少しは承知しているつもりだ。そのための有力な武器の一つが、専門的なプロジェクト・マネジメント技術なのだ。だから、それについて本も書き、あちこちで講義したり宣伝したりして回っているのである。

繰り返しになるが、日本の海外プロジェクトは、バブル期頃までの、強い立場・先進国相手・売ってあげる型から、2000年以降の、弱い立場・新興国相手・買って下さい型へと、シフトしてきてきた。ところが、世の中にはまだ、バブル期までの過去の『成功体験』を、自らの栄光の記憶として抱えているシニア・マネージャー層がけっこう、残っている。

だが、彼らの成功体験はもう、賞味期限切れで、今の時代には使えないのである。昭和の古きよき時代はもう、とっくに終わったのだ。そして、そんな過去の成功体験にしがみついていると、現実がよく見えなくなってしまう。そのことを、日本の中枢にいる人たちにも、伝えたいのだ。昭和世代のわたしがこんなことを言うのはおかしいかも知れないが、これからわたし達の社会を担う層の人たちに活躍の場を残すためには、過去の成功体験の記憶を一度リセットして、新しい目で日本と海外を見るべきだと思う。


<関連エントリ>
 →「プロジェクトのスコープには硬軟がある」 https://brevis.exblog.jp/27558796/ (2018-09-20)
 →「海外プロジェクトの変化と、契約意識という不可視のハードル」 https://brevis.exblog.jp/18516049/ (2012-07-30)


by Tomoichi_Sato | 2018-09-29 23:12 | プロジェクト・マネジメント | Comments(0)