人気ブログランキング |

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

プロジェクトの進捗を計る「アーンド・スケジュール法」とは何か 〜 (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)

プロジェクトのスコープには硬軟がある

先月のことだが、霞ヶ関のある有力省庁に呼ばれて、プロジェクト・マネジメントについて1時間ほどの簡単なレクチャーをしてきた。聴衆は、製造業を所轄する部局の、若手中堅の官僚20人弱である。先方からは『ビジネスで成功を勝ち取るプロジェクトマネジメントとは』という、いささか大げさなタイトルを頂戴したが、いかんせん1時間弱でしゃべれる事は限られている。

短い時間でプロジェクト・マネジメントのエッセンスを紹介するなら、何を話すべきか。相手にもよるが、わたしはスコープとWBSの概念の話をすることにしている。プロジェクトにおいて、日本人は概して、計画軽視だ。与えられた目標や暗黙の目的意識のもとで何となく走り出し、人を集め、あとは各人の努力と互いのすり合わせで進めていく。「現場重視」「歩きながら考える」の習慣が、とても強い。

欧米人と一緒に仕事をした経験のある人なら、彼らはまず、全体の計画を立てるところからはじめる習慣が強いことを、ご存じだろう。計画を立てずに走り出すことは、まるで地図を持たずに旅に出るようなもので、心配になるらしい。プロジェクト・マネジメントという概念も、PMBOK Guideのような標準書も、このような文化の元で生まれ育った。

計画力と現場力は、車の両輪で、どちらが弱くても真っ直ぐちゃんと走れない。ただ、自分たちが何に弱いかは、そこに強い相手と組んだり闘ったりしないと、なかなか気づかないものだ。たまたまわたしは、海外プロジェクトを中心としたビジネスをする企業にずっと勤めてきたので、ある程度は両方を知っている。

とくに、日本は製造業の影響力が大きいので、「QCD」、すなわち品質・コスト・デリバリー(納期)の制約については、多くのビジネスマンが常識として肌身で知っている。しかし、現代プロジェクト・マネジメント(モダンPM)の柱は、

 QCD+S

の4つなのである。4番目のSは、『スコープ』の頭文字だ。いや、海外の文献などを読むと、品質は当然の前提としてQを抜かし、SCDの3つがプロジェクトの柱だ、という言い方が多い。スコープは、モダンPMの第一の柱、最大の制約条件なのだ。事実、PMBOK Guideを見てもらえれば分かるように、10の知識エリアの記述順は、最初に統合マネジメント、次がスコープとなっている。

そして、スコープの具体的表現手法として、WBSがある。これはプロジェクト・マネジメントの基礎となる手法で、60年代頃から整備されてきた。だが、この一番肝心なスコープとWBSの概念が、日本では良く理解されていない。

プロジェクトは、何らかの成果物やサービスを生み出すための営為である。ただ、プロジェクト全体は大きいし,出発時点ではもやっとしていて、それを全体として扱うのはやりにくい。そこで西洋人は、彼らの思考習慣である"Structured Approach” にしたがって、大きな問題を小さな部分問題に分割していく。つまりプロジェクト全体を、やらなければならない具体的な個別の要素作業に、階層的に分解するのである。

この要素的作業を『アクティビティ』とよぶ(日本のIT業界では「タスク」ということが多いようだが、PMBOK Guideは昔からActivityという用語で統一している)。そしてプロジェクト全体のスコープ(仕事の責任範囲)を、アクティビティ(タスク)の集合として捉えるのである。まあたとえて言えば、日本全土を、都道府県に分け、さらに県を地形に従い市町村に分割するようなものだ。そのようにして、全体のエリアを、統括可能な部分に分けて地図を作る。

わたしのレクチャーでは、簡単なプロジェクトの例をとって、それを構成するアクティビティの洗い出しを10分ほどの演習で体験してもらった(さすがに優秀な人たちが多く。通常の社会人相手のときより倍近い早さで進んだ)。そして、次は洗い出したアクティビティを、紙の上で階層的に図示してもらう。これだけでも、気づかなかった抜け漏れや作業のアンバランスなどが、気づきやすくなる。

スコープとはプロジェクトのなすべき責任範囲のことであり、それをアクティビティに階層的に分解して、管理番号を付番したものがWBS(=Work Breakdown Structure)である。これは仕事のスコープの見取り図、地図に相当する。WBSこそはプロジェクト・マネジメント計画の出発点であり、その出来不出来によって、その後のマネジメントの成果を大きく左右する。

WBSの一例を、図に示す。これはわたしの勤務先の得意とするプラント・エンジニアリング系のプロジェクトについて、WBSの骨子を示したものだ。本当はもっとずっと詳細なのだが、骨格を理解してもらうのが目的なので、枝葉はばっさり切ってある。
e0058447_23493235.jpg
なお、ここに示したWBSの構成は、Functional-WBS(略称F-WBS)とよばれる種類のもので、主に仕事の機能のプロセスを主体としたものだ。他に成果物の構造にしたがったProduct-WBS(P-WBS)もあるのだが、話が複雑になるのでここでは省略する。

このWBSには、とくに時間の概念はないことに注意してほしい。まだ、ガントチャートは、ない。この後、それぞれのアクティビティの作業量を見積り、割り当てるリソースの量を決めて必要な期間を推定し、さらにアウトプットとインプットから生じる関連性(他のアクティビティとの依存関係)を考慮して、初めてガントチャートが作成可能になる。

日本ではガントチャートのことをWBSだと誤解したり、スコープを明確化する前に、いきなり線表を描き始めたりする『ダイレクト・ガントチャート』方式の人が少なくないが、それでは成功するはずのプロジェクトだってうまくいかない。こうしたことを、日本の中枢を担う若手官僚に分かってもらいたかったのである。

さて、ここから先は、PMBOK Guideにあまり書いていない、大事な話になる。それは、プロジェクトはスコープのあり方に応じて、二種類に分けられ、それに応じてマネジメントの力点も変わる、ということだ。

どういうことかというと、プロジェクトはスコープが『ハード』なものと、『ソフト』なものに分類可能なのである。ハードなスコープとは、プロジェクトのなすべき責任範囲がかなりかっちりと規定されているタイプのものだ。これに対して、ソフトなスコープは、プロジェクトの範囲が、途中でかなり変わりうる(自分で変えうる)タイプである。

なお、プロジェクトについての”Hard”, “Soft"という用語は、2000年頃から欧米のPM研究論文などに現れるようになってきた。ただし、これは別にコンピュータのハードとソフトの話をしているのではないので、注意されたい。鋼鉄製の橋を架けるのはハードなスコープで、木の吊り橋はソフトだ、という話でもない。あくまで、なすべき仕事の領域・範囲の変わりやすさ、硬軟をいっている。

簡単に言うと、自社が自らの意思ではじめる「自発型プロジェクト」、たとえば製品開発や社屋新設などのプロジェクトは、スコープがソフトな場合が多い。他方、誰か顧客から請け負う「受注型プロジェクト」は概して、スコープがハードだ。スコープがふにゃふにゃして曖昧だったら、そもそも見積ができないから、契約が成立しない(無論、単価契約とか派遣契約にすれば別だが、その場合はプロジェクト・マネジメントの責任を受注側は負わない)。

スコープがかっちりと固まっている受注型プロジェクトにおいては、プロマネは通常、コストと納期を、よりシビアにコントロールすることが求められる。したがって、ハード・スコープのプロジェクトを沢山遂行する組織においては、プロマネにより権限が与えられなければならない。権限がなく、判断もできずに、責任など負えないからだ。マネジメントの主眼は、スケジュールとコストになる。

(ただし余談だが、日本のIT企業の方の話を聞いていると、プロマネにはコスト管理の権限がなく、ただ与えられた予算と人員の中で、スケジュールをなんとか守る事が求められているケースが多いようだ。これはわたしのような他の業界人からは、奇妙に見える。コストの権限が上司が握ったまま、納期と品質の責任だけを問われるのでは、まるで後ろ手にしばったパン食い競争みたいで、ずいぶんだと思うのだが)

さて、ところで、自発型プロジェクトは受注型とかなり違う。たとえば新製品開発を考えてみよう。予算を満たし納期を守っても、できあがった製品に魅力がなければ、プロジェクトは失敗だ。したがって、プロマネは何よりも、ユーザにアピールする品質(「前向き品質」)を上げるべく、スコープを調整することになる。この種類のプロジェクトでは、プロマネは管理・監督よりも、創造の役割を強く求められる。

だから、ユーザを惹きつけないと成立しない、いわゆる『SoE』(Systems of Engagement)では、アジャイル開発などの手法に価値が出てくるのだ。アジャイルでは、スコープを動的に入れ替え、調整して進んでいく。しかし、設計図通りに橋梁を建設するようなプロジェクトには、アジャイルは使えない。スコープがハードだからだ。

さて、スコープについて、一般的教科書にあまり書いていないことまで説明したのは、理由がある。せっかく霞ヶ関まで行って、日本の製造業や貿易政策を担う省庁の人たちに聞いてもらうのだから、もう一つ、説明しておきたいことがあったからだ。

それは、海外プロジェクトの進め方に関する留意点、彼我の違いについてである。日本企業とその製品群は、70年代頃から、世界を席巻した。自動車、家電、カメラ、パソコン等、あげればきりがない。高度成長期とはまた、日本企業の国際化・グローバル化の進展でもあった。——そういう風に、マスコミをはじめ、多くの人たちが思っている。

だが、その思考には、意外と大きな大きな罠がひそんでいるのだ。そして、それが『スコープ』の硬軟の概念と、密接に関係しているのである。

(この項つづく)


<関連エントリ>
 →「ダイレクト・ガントチャート方式の問題点 〜 やはりExcelで工程表を書いてはいけない (1)」 https://brevis.exblog.jp/26231556/ (2017-12-02)
 →「Structured Approachができる人、できない人」 https://brevis.exblog.jp/18336958/ (2012-07-08)


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

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

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


今回は、元フジテレビ海外特派員、テレビ静岡会長で、現在は一般社団法人静岡アジアパシフィック協会理事長の曽根正弘様に、メディアから見た世界の転換点と、その取材とについてご講演いただきます。


ご存じの通り、現在のマスメディアは時間的な媒体であり、とくにTVの場合は取材におけるリアルタイム性の高さが求められます。そして、対象とするのは、繰り返しのない一過性の出来事で、かつライバルとの激しい競争もあります。
そのような現場を抱える中、どのような形で世界的な出来事にかかわり、それをレポートしているかについて、貴重な体験をベースにお話しいただきます。


他では聴けない、興味深いご講演は、暑い夏の夕べ、一服の清涼剤となるはずです。

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


<記>

日時:2018831日(金) 18302030

場所:慶応大学三田キャンパス

 北館会議室21階)(定員:28

 https://www.keio.ac.jp/ja/maps/mita.html

 キャンパスマップ 【1


講演タイトル:

タイトル「TV特派員が現場で見た世界の転換点」


概要:

フジテレビ特派員としてモスクワ、ワシントン、ニューヨーク、ロンドンと転任する中で、東西冷戦の終結、ソ連のクーデターに端を発する体制崩壊を千載一遇の機会を生かして現場レポートをすることができた顛末を語る。


講師:一般社団法人 静岡アジアパシフィック協会

理事長 曽根正弘(そね・まさひろ)


講師略歴:

略歴:

静岡県出身

1964年早稲田大学卒、()フジテレビジョン入社。

1970-71 米国ミシガン大学、MITに短期留学。

1982-85 モスクワ特派員・支局長。

1989-90 ワシントン特派員・支局長、FCI報道担当副社長。

1990-94 ロンドン特派員・支社長。

1994-98 フジテレビ総合調整局長、社長室長、取締役国際局長

1998 ()テレビ静岡移籍

1998-2017 同社専務取締役、代表取締役社長、会長、相談役、顧問

(この間、静岡商工会議所情報文化部会長、静岡交響楽団理事長、静岡市

 行財政改革推進審議会会長ほか兼職多数)

現在:()TOKAIホールディングス社外取締役、東京音楽大学特任教授、

 静岡県ニュービジネス協議会統括副会長ほか。


参加費用:無料。

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

 参加を希望される方は、確認のため、できましたら前日までに三好副幹事までご連絡ください。



佐藤知一@日揮(株)



by Tomoichi_Sato | 2018-08-18 17:58 | プロジェクト・マネジメント | Comments(0)

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

各位:

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

今回は、ギルドワークス(株)代表の市谷聡啓様に、アジャイル開発プロジェクトについてご講演いただきます。

2001年に米国で「アジャイルソフトウェア開発宣言」が発議されてから、すでに17年がたち、アジャイル開発は日本のIT業界でも、かなり広く認められる手法となりました。とくに開発・実装の仕事に直接関わる人たちからは、大きな期待が寄せられています。またPMIが昨秋発表した「PMBOK Guide」第6版は、「Agile Practie Guide」との合本の形で発売され、米国のプロジェクト・マネジメント分野でも重要性が増していることが分かります。

しかし、多くの利点にもかかわらず、現実のアジャイル開発は様々な障壁やチャレンジに直面し、また不振なプロジェクトの事例を耳にすることも出てきました。その理由にはソフトウェア技術的な面から、日本におけるIT業界の構造・慣習の面まで、いろいろあるようです。IT業界がたまさか活況を呈し、人手不足も語られる今日、アジャイル開発の賢い進め方について、この分野でエヴァンジェリスト的に活躍される市谷様からお話を伺います。ご期待ください。


<記>

■日時:2018年6月7日(木) 18:30~20:30

■場所:場所:三田キャンパス 研究室棟B会議室(1F)定員:36名
※キャンパスマップの【10】
HPの下部にキャンパスマップがございますので、ご確認ください。

■講演タイトル:
アジャイル開発の実際

■概要:
 改めてアジャイル開発とは何か。そして、日本の現場ではどのように実践されているのか。
プロジェクト、プロダクト開発の運営の観点から、アジャイル開発の実際についてお話ししたいと思います。

■講師:ギルドワークス株式会社 代表・株式会社エナジャイル 代表   市谷聡啓(いちたに・としひろ)

■講師略歴:
 サービスや事業についてのアイデア段階の構想から、コンセプトを練り上げていく仮説検証とアジャイル開発の運営について経験が厚い。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、ギルドワークスを立ち上げる。それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。著書に「カイゼン・ジャーニー」、訳書に「リーン開発の現場」がある。

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

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

佐藤知一@日揮(株)

by Tomoichi_Sato | 2018-05-19 18:49 | プロジェクト・マネジメント | Comments(0)