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

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

各位:

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

新年第1回は、久しぶりに製品開発、とくに研究開発におけるプロジェクト・マネジメントについて、キユーピー(株)の元常務取締役・研究所長であった和田義明様に、ご講演いただきます。

ご承知の通り、企業におけるイノベーションの創出活動、とくに研究という仕事は、まだ誰も知らないものを生み出すことにあります。他方、マネジメントとは計画を立て、明確な目標イメージを持って統率していく行為です。誰も知らない目標に向かって、一体どのように組織をマネージすべきなのか? ここに研究開発マネジメントの本質的な難しさがあります。

今回は、実際の研究開発の実務を長年リードしてこられ、さらに研究開発の方法について博士号を取られた和田様から、R&Dのマネジメントについて実戦的なお話を伺う予定です。ぜひご来聴ください。


<記>

■日時:2018年1月25日(木) 18:30~20:30

■場所:三田キャンパス 研究室棟B会議室(1F)
 ※キャンパスマップの【10】
 (いつもの北館とは別の場所ですので、ご注意ください)

■講演タイトル:
企業における研究開発の活性化策(プラットフォームとブーストゲート法)

■概要:
 研究開発を活性化してイノベーションにつなげることを目的に、キユーピー㈱研究所にて取り組んだ手法を紹介する。具体的には、組織力を高めるプラットフォーム・マネジメントと、研究を事業につなげるブーストゲート法である。その方法、効果、事例について紹介する。

■講師:キユーピー㈱ アドバイザー 和田 義明

■講師略歴:
【学歴】
 1978年 東京農工大学農学部農芸化学科卒業
 2012年 東京農工大学専門職大学院技術経営研究科修了
 2014年 東京農工大学大学院工学府応用化学専攻博士後期課程修了
    博士(学術)
【職歴】
 1978年 キユーピー㈱入社(以後工場、研究所、マーケティング部門勤務)
 2000年 同社研究所部長
 2006年 同社執行役員品質保証本部長
 2009年 同社取締役研究所長
 2012年 同社常務取締役(ファインケミカル事業、研究開発本部、品質保証本部、商品開発本部、知的財産室管掌)
 2017年 同社取締役退任
【現在役職】
 キユーピー㈱アドバイザー
 上海海洋大学客員教授
 中央大学、関西大学、千葉工業大学非常勤講師
 東洋食品工業短期大学非常勤講師兼テクニカルアドバイザー
 国際プロジェクト・プログラム・マネジメント学会評議員
 タマゴ科学研究会理事、日本能率協会食品安全部判定委員

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

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

佐藤知一@日揮(株)

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

プロジェクト計画のロジックとは何か 〜 やはりExcelで工程表を書いてはいけない (2)

前回の記事「ダイレクト・ガントチャート方式の問題点」http://brevis.exblog.jp/26231556/ で、世間ではそもそも「WBS」とか「Activity」という概念のレベルで、誤解や混乱があると書いた。

たとえば、WBS=「ガントチャートの線表に引いた線の集合」だ、と理解している人達を、よく見かける。ためしにネットで、「WBS スケジュール」の2キーワードで検索をかけてみると、よくわかる。上位の検索結果に、こういう説明が出てきたりする:

「WBSとはプロジェクトのスケジュール管理に使われるツールの1つ。作業工程を分解して示したものと、それをスケジュールにしたものを合わせてWBSと呼ぶことが多い」

この説明など、残念ながら逆立ちしている。WBSはスケジュール管理用のツールでもないし、もちろんガントチャートの線も含まない。WBS(Work Breakdown Structure)とは、プロジェクトのスコープを階層的に分解したものを指す。スコープを単位作業の集合として構成し管理番号を付番したもので、つまりスコープ管理用のツールなのだ。まずWBS作成が先にあって、最後にガントチャートや予算表ができる訳なのだから、逆立ちなのである。(なお、たまたまGoogle検索で上位にヒットしたので、上記サイトをやり玉にあげさせていただいたが、全体としては平易で良い記事が多いと思う。だからこそ、こうした誤解が残念なのだ)

ついでにいうと、タスクとアクティビティという用語も、しばしば混乱して使われているようだ。プロジェクトのWBSを構成する要素作業は、「タスク」とよぶのか、「アクティビティ」とよぶべきなのか?

世界で最も広く普及しているPM分野の標準書「PMBOK Guide」では、一貫して、プロジェクトの要素作業を”Activity"とよんでいる。これが、世界的な共通語である。ただ、わたしの知る限り、日本のIT業界では、プロジェクトの下位要素を「タスク」とよぶ人が非常に多い。まあ、一種の業界慣習(?)なのだろうか。むろん習慣に従うのは自由だが、外の人と話すときには、自分たちが方言を使っていることを意識しておいた方が良い。

ちなみにPMBOK Guideでは、タスクという用語は、"Daily task”の形で出てくる。日々の細かな宿題、課業である。すなわちTaskとは、To Doリストとか課題管理表で追いかけるべき、細かな作業を指す。

しかし、Activityは違う。これはプロジェクトを構成する単位作業で、ある意味、プロジェクトの縮小版であり似姿だ。Activityは、通常、完了条件を持つ。つまり、アウトプットとしての成果物がある。あるいは、ある状態になったら完了していい、との条件がある。

たとえば、要件定義というActivityは、『要件定義書』という成果物を生み出したら完了する。あるいは、テストだったら、試験完了の状態になれば終わる(まあ普通はテスト報告書も作成するけれど)。つまりActivityというのは、プロジェクトと同じく一過性の仕事なのである。じゃあ、週次ミーティングは何なのか? WBSには入れないのか? との疑問が浮かぶかもしれない。それはDaily taskです、というのが答えだ。

Activityには、必要なインプットがある。インプットは、部品・材料といったモノの場合もあるし、情報の場合もある。さらにActivityには、それを遂行するためのリソース(経営資源)も割り当てなければならない。つまり担当者であり、機械やツールであり、作業場所である。こうしたものは作業中は占有するが、終われば開放されて、別の仕事に使える。リソースは、Activityで消費されてしまうインプットとは性質が異なる。

そして、各Activityはその内容・種類に応じて、作業量(BoQ=Bill of Quantity)を推算しなければならない。これがコストやスケジュールのベースとなるからだ。

プロジェクトのWBSを構成する全Activityについて、そのインプット、アウトプット(完了条件)、リソース、そして作業量(BoQ)をまとめた表を、Activitlyリストとか、WBS Dictionaryとよぶ。たとえていうならば、WBSとは、日本全国を50都道府県に分解し、さらに各県を市町村に分割し、マネジメントしやすい自治体の単位に表示した、お仕事の地図のようなものである。この地図帳には、WBS Dictionaryという統計表がついている。これが、プロジェクト・マネジメント計画の土台なのだ。単なるスケジュール管理用のツールではないことが、お分かりいただけたと思う。

さて、「ダイレクト・ガントチャート方式」の問題点に話を戻そう。いうまでもなく、ガントチャートは、チームメンバーや顧客・外部協力会社とのコミュニケーション上、必須の道具である。PERT/CPMの計算に使うActivity Network線図など、誰も見たくないだろうし、見てもよく分かるまい。わたしの勤務先でも、PERT/CPMの計算の後、必ずガントチャートを作成して、プロジェクト・チームに配布する。それを元に、キーパーソン同士による「総合工程会議」を開いてレビュー・議論し、完成するやり方をとっている。

だが、頭の中にWBSもActivityリストもないまま、いきなりガントチャートの線表を書き始める「ダイレクト・ガントチャート」方式は、全然別物だ。アウトプットとしての線表は共通だが、背後にきちんとしたスケジューリングのロジックがないため、これをスケジュール管理用に使うのは、けっこう危険である。まあ「ロジック・ガントチャート」方式と「ダイレクト・ガントチャート」方式は、アウトプットの線表だけ見ると似ているので、両者の違いを知らない人が多いのかもしれない。

では、プロジェクトのロジックとは何か?

狭義には、Activity間の依存関係やスケジュール上の制約条件を示したものを指す。たとえば、あるActivityのアウトプットが、他のActivityのインプットやリソースになる場合、両者の間に先行→後続という、依存関係が生じる(Finish to Startの略でFS関係とよぶ)。あるいは、ペンキ塗装のように、あるActivityが開始してから一定日数後に、別のActivityを開始できることがある。これをStart to Startの依存関係とよぶ(略してSS)。

こうしたロジックは、Activity Networkを組むベースとなるだけではない。あるActivityが予定から変化(遅れた・早く完了した)場合に、他のActivityにどう影響するかの予測を、可能にする。

なお、スケジュール・ロジックは広い意味では、Activityの所要期間の推定根拠(何で決まるか)も含む。つまり、作業量(BoQ)と、投入リソース量と、生産性である。所要期間は、以下の式で計算する。

所要期間=作業量÷(生産性×投入リソース量)

リソースが人間の場合は、所要期間=作業量÷(生産性×人数) になる。作業量は、ソフトウェア開発の場合なら、たとえばFunction Point(FP)だとか画面帳票数だとかLOC(コード行数)などのパラメータで測ることが多い。

かくして、WBSを構成する各Activityについて、作業量(BoQ)と投入リソース量と生産性から、所要期間が決まる。もっとも中には外部調達機器の納期のように、外から与えられる所要期間も無論ある。

そして、ロジックを元にActivity Networkを組んで、はじめてクリティカル・パスがわかり、プロジェクト全体工期が計算できるのである。全体工期がわかって、はじめてプロマネの工数を積むことができる。だから、計画立案は必ず、スコープ→WBS作成→スケジュール計画→コスト見積の順番になる。

ところが、ダイレクト・ガントチャート方式は、途中を中抜きして、いきなりスコープからガントチャートを作ってしまう。家を建てるのに、土台や柱の骨組み抜きで、壁を立て屋根を乗せているようなものだ。途中で倒れなかったら、まあ幸運である。

e0058447_23224980.jpg
e0058447_23231505.jpg
ダイレクト・ガントチャート方式をとる人には、しばしばもう一つの問題がつきまとう。それは、ガントチャート上に、フロートを表示しないことである。フロートとは、そのアクティビティがどれだけ遅れると、プロジェクト全体の納期に影響を与え始めるかを表す数値だ。無論、クリティカル・パス上のアクティビティのフロート日数はゼロである。

たとえば4月開始で、実質の所要期間は3ヶ月のActivityがあるとしよう。ただし、並行する別の作業があるために、8月末までに完成すればいい。このとき、本来ならば3ヶ月間の実線と、2ヶ月分の余裕日数(フロート)を表す点線を、横に並べて引くべきだ。

だが4月から8月末まで、5ヶ月分、バーの実線を引いてしまうケースが多いのである。ロジックをよく理解していない人は、フロートの概念があいまいだからだ。こうすると、そのActivityの正味の所要期間が見えなくなってしまう。

こういう線をあちこち引いたガントチャートを見て、さて、プロジェクトの最長の経路(見かけ上の最長経路)をクリティカル・パスだと判断したら、当然おかしなことになる。クリティカル・パスとは、フロートを差し引いた正味の経路長が最大のものを指す。プロジェクトの全体工期を制約する最長の経路である。プロマネは、納期を守るために、クリティカル・パスが遅れないよう、注意を集中すべきだ。だが、フロートが見えないと、間違ったAcitivityに注意を向けたりしかねない。

ちなみに、プロジェクト・マネジメントという特殊なActivityについても、注意を向けておきたい。これをWBSにいれていない大企業を、見かけたことがある。思わず、「プロジェクト・マネジメントはしないんですか」、と口走ってしまった(苦笑)。もちろん、プロジェクト・マネジメントには確実に工数がかかるので、見積に必要である。プロマネだけでなく、書類事務などが多い場合は、アシスタントもつける必要もある。だからWBSに無いのはおかしい。

ただしプロジェクト・マネジメントというActivityは、固有の成果物と、固有の所要時間を持たない点が特殊だ。その期間は、プロジェクトのクリティカル・パスの長さに依存する。
だからガントチャートでは、省略されることも多い。うっかり線を引くと、それがクリティカル・パスみたいに見えてしまう。だが、WBSの一部である。このように、WBSとガントチャートは、一致しない点がある。

以上、ダイレクト・ガントチャート方式を批判してきたが、じつはわたし自身、直接ガントチャートを引くことがある。それは、身近で数人が関わる程度で、期間も数週間程度のごく小規模なプロジェクト的業務の場合である。役割分担を決め、やる事とタイミングを決めたら、あとは走りながら考える。必要に応じて、微調整していく。その程度で十分な仕事が、確かにある。え? 線表は何で引くかって? もちろんExcelでだ(笑)

無論、きちんとWBSを作りプロジェクト計画を立てるべき仕事もある。当たり前だが、規模によって、マネジメントのやり方は変えなければならない。3人のお客様を呼ぶパーティーと、300人のお客様を呼ぶパーティーでは、段取りから何から全て違うのだ。あるいは、先ほどの家を建てるアナロジーでいうと、犬小屋なら地面にすぐ壁を立て屋根を乗せても大丈夫だ。だが普通の木造家屋では、そうはいかない。そして10階建てのビルなったら、そもそも材料も構造も変える必要がある。

つまり、規模とマネジメント手法の相関が大事なのである。少しでも複雑化した仕事、規模の大きなプロジェクトでは、それに見合うやり方を選ばなければならない。なぜなら、小さなスケールの仕事で「分かっている」と思ったやり方が、通用しなくなるからだ。本格的なやり方を知った上で、小さな場合には適時省略する、のは構わない。だが、本式のやり方を知らないのでは危うい。

現在のPMBOK GuideやPMP試験の問題点は、ここにある。プロジェクトの規模や複雑性によって、適切なマネジメントのやり方を選ぶべきだ、という事をハイライトしていない。たとえ規模は変わらなくても、海外プロジェクトは、パートナーやステークホルダーと契約関係が、複雑性を増大させる。なのに国内と同じ簡略化した進め方が通用すると思ってはいけない。規模が大きくなったり、プロジェクト構造が複雑化したら、より精度の高いプロジェクト計画が必要なのだ。

ちなみに、上に挙げた図の中で、点線で囲まれた部分は、わたしの主催するプロジェクト&プログラム・アナリシス研究部会が開発中の、初級者向け研修コースのカバー範囲である。わたし達の研修プログラムの最大の特徴、他との違いは、PMにおける「システムズ・アプローチ」の涵養にある。受講者には最初に手を動かして、ロジック・ネットワークを作成してもらう。それを通じて、「プロジェクトとはActivityからなるシステムであり、そこには独特のロジックと動力学がある」という感覚を得てもらうことがポイントだ。ここが身につかないと、どこを簡略化すべきか、分からない。

Excelで工程表を書くべきではない、というのは、こうしたロジックが磨かれないからだ。それは、本当はツールの問題ではない。MS ProjectでもPrimaveraでも、やろうと思えば「ダイレクト・ガントチャート方式」は可能だ。まずいのは、ツールではない。ツールを使う条件、使える範囲を知らずに、いつでも使うことだ。

知らないことは、別に恥ではない。知ろうとしないことが、恥なのである。


<関連エントリ>
→「ダイレクト・ガントチャート方式の問題点」http://brevis.exblog.jp/26231556/ (2017-12-02)
→「仕事の最小単位ーーアクティビティの構造を学ぶ」 http://brevis.exblog.jp/13992804/ (2011-01-16)



by Tomoichi_Sato | 2017-12-10 06:21 | プロジェクト・マネジメント | Comments(2)

ダイレクト・ガントチャート方式の問題点 〜 やはりExcelで工程表を書いてはいけない (1)

このほど、自分で「マイ・ベスト・セレクション」なる本を編んでみた。過去17年間に書いてサイトに公開した数百の記事の中から、自分が気に入っているベスト12を選んで、ePub形式の電子書籍をつくってみたのだ。まあ書籍といっても、素人のつくった手製(手編み?)の本で、いってみればβバージョンではある。ベスト・セレクションの中には、アクセス数の多かった記事も入れたが、目立たないけど愛着のある記事も選んだ。多少は文章に手を入れたつつも、なるべく発表当時のスタイルを残している。

ところで、わたしのサイトには、アクセス数で言うとダントツ1位の記事がある。「Excelで工程表を書いてはいけない」(http://brevis.exblog.jp/9052344/)という、2008年11月24日の記事だ。もう9年前の記事だが、いまだに毎週のBlog記事ランキングのトップに位置し続けている。

そして、実を言うと、これほど評判のわるい記事もない。それは、コメント欄を見ていただければ分かる。当サイトのコメント欄は、明らかに広告宣伝と分かるもの以外は原則、消さないことにしている。コメントの8割以上が、まあ、ぼろくそな批判である。

批判の主旨は、「お前はExcelを批判しているが、かわりの提案をしていない」というものが多い。たしかにその通りで、これは批判者の方が正しい。「Excelのかわりにこのツールを使えば大丈夫だよ」というソリューションを書いていないから、記事の前半で提起した問題意識が、後半で腰砕けになっている、という風に読める。かわりにわたしは、「自分で考えましょう」みたいな書き方をしているからだ。

しかし、そんなに程度の低い記事だったら、なぜあっという間に忘れられてしまわなかったのか。なぜいまだに、毎日かなりの数の閲覧があるのか。そして、なぜ皆、Excelのかわりを求めて読みに来て、回答が書かれていない、と怒って帰って行くのか? −−もちろん、Excelで描く工程表が、やはり不便だからだ。

では、わたし自身は、実際の仕事では何を使っているか。

わたしは現在、経営企画部門におり、プロジェクトのライン部門は5年前に離れている。ライン部門にいた時は、じつはPrimavera Project Planner(略称P6)をつかっていた。Primavera P6は、いわゆる大規模なエンジニアリング系プロジェクトでは、ほとんど国際的な標準ツールになっている。

今でもわたしは、ちょっと込み入ったプロジェクトのスケジュールを考えるときは、Primaveraを使いたくなる。それだけ便利だからだ。

ただし、これはプロのツールである。

プロとは、"Project Control Manager”とか"Schedule Engineer"とか呼ばれる職種・ポジションの人達を指す。そもそもこういう職種自体、多くの業種には馴染みがないと思う。大規模プロジェクトをつねに遂行している組織でなければ、こういう専門職種は必要ないからだ。ちなみにプロジェクト・マネジメントはゼネラリストの仕事だと思っている人が多いが、じつは、スケジュール、コスト、品質、ドキュメントなどの要素別に専門分化している、プロマネのためのスタッフ職種があるのだ。米国PMIには資格試験まである。

それはともかく、Primaveraというソフトウェアは、きちんとトレーニングを受けなければ、使えないし、使っても意味がない(出力の意味が読み取れない)。値段は1本約30万円。まあ、プロの道具としては安いとわたしは思う。

参考までに、Primaveraの画面の一つ(典型的なガントチャート表示と、各Activityの属性を示すサブペイン)のスナップショットをつけておく。Primaveraでは、Activityには自由にカテゴリーと属性を定義でき、その順にソートしたりフィルタリングしたりできるようになっている。もちろん、リソース負荷山積みによるヒストグラム表示なども、よく用いる。
e0058447_09063235.png
では、それほど大きくない、もっと日常的なプロジェクトを組む場合、わたしは何を使うか? −−じつは、Excelで工程表を書くことが多い。

なんだBlog記事の主張と矛盾してるじゃないか! とお怒りの読者もいるかもしれない。いや、だが元の記事を、よく読んでほしい。別にわたしは、ガントチャートを画くのにExcelを使うこと自体がわるい、といっているわけではない。「Excelで工程管理してはいけない」と書いているのだ。

『工程管理する』とはどういう意味か。それはもちろん、工程(日程とかスケジュールと読み替えても良いが)の計画とコントロールである。

  • プロジェクトのスタートにあたり、工程表(ガントチャート)を作成し、定期的にアップデートすること
  • 進捗上の問題を検知し、対策を立てて問題解決をすること
  • それによって、プロジェクトの最終納期を目標通り収まるようコントロールすること、そして
  • 社内・社外の関係者に、先々の予定を立て準備できるようにすること

これが工程管理だ。そして、こういうひとまとまりの仕事を、Excelの絵1枚だけで済まそうとすると、相当に苦労するよ、と申し上げているのである。

2008年に書いた問題のサイト記事では、Excel工程管理について、とくに実行段階に入ってからのトラッキングとアップデートが大変だと書いた。しかし、もう一つの問題があることに、最近気がついた。それが、「ダイレクト・ガントチャート方式」である。

3ヶ月ほど前のことになるが、研究会仲間のY氏からメールをもらった。Y氏は、問題プロジェクトの火消しのために、海外に駐在されているところだった。この時期、わたしは「プロジェクト&プログラム・アナリシス研究部会」の仲間とともに、新しいPM教育のプログラムを作成していた。それに際して、Y氏がコメントを送ってくれたのである。

わたしたちのつくった研修カリキュラムでは、最初にプロジェクトのWBS構成と、アクティビティを表すカード数十枚を、受講者に配る。受講者はグループを組んで、各アクティビティのインプットとアウトプットを見ながら、アクティビティ間の順序関係(ロジック)を理解する。そして、アクティビティ・カードを模造紙の上に並べて、ロジック・ネットワークを作成する。ここは手作業で、ワイワイ言いながら、結構時間のかかる部分だ。その上で、PERT/CPMの計算をして、余裕日数(フロート)=0となるクリティカル・パスを見つけ、納期を予測する、という段取りになっている。

コンピュータソフトを使わず、あえて紙の手作業、それもグループ単位の演習にしたのは、言葉にして話し合う方が、より頭に残りやすいからである。

そしてこの演習では、プロジェクト計画立案の本来のプロセス(の一部)を、順を追って理解してもらうことに主眼がある。本来のプロセスとは、

(1) スコープ定義
(2) WBSの作成
(3) Activityリスト(WBS辞書)作成 →アウトプット(成果物)とインプットの定義
(4) ロジック・ネットワーク作成
(5) クリティカル・パス法(PERT/CPM)計算
(6) スケジュールの決定
(7) コスト見積

という流れである。このプロセスをきちんとやるのは面倒で、時間がかかるが、計画の精度が高まり、うっかりした見落としがなくなる。

ところで、Y氏はメールの中で、しばしば現実には「ダイレクト・ガントチャート方式」が行われている、と指摘された。ダイレクト・ガントチャート方式とは、プロマネがプロジェクト計画をつくる際に、WBSやアクティビティ・ネットワークを作成せず、いきなりスケジュール・ガントチャートを描き始めるやり方である。

「プロマネのハンドリングでさばける範囲であれば、Activity Networkを作成するより、ダイレクトにガントチャートを作成する方が負担にならない」とY氏は指摘する。しかし、「その範疇を超えた、(より規模の大きな)プロジェクトに対して、Activity Networkとクリティカルパスの概念を理解していないプロマネが、ガントチャートでマネジメントしようとすると、失敗プロジェクトに陥る。」−−これがY氏の経験から見た観察であった。

ちなみにY氏は、「ソフトウェア業界ではActivity Networkを作っていないケースが非常に多い」とも書いている。これは、そうだろうと感じた。いや、わたしの見るところでは、その前にそもそも、「WBS」とか「Activity」という概念のレベルで、誤解や混乱があるのである。

(この項続く)


by Tomoichi_Sato | 2017-12-02 15:05 | プロジェクト・マネジメント | Comments(0)

PM理論に関する講演のお知らせ(12月8日)

来る12月8日(金)の夜、東京・東麻布の日本プロジェクトマネジメント協会で、講演を行います。

先月、わたしは米国シカゴで開催されたProject Management Institute (PMI) Global Conference 2017に参加し、講演発表を行ってきました。ご存じの通りPMIは世界最大の影響力を持つプロジェクト・マネジメント専門職団体で、その世界大会はPM分野の最新状況を反映しています。

今回の講演では、まずPMI世界大会2017にみる北米PM界の潮流を概観します。その上で、わたしが行った発表『Decision making with Risk-based Project Value (RPV) analysis and activities’ value contributions』(「リスク基準プロジェクト価値RPVとアクティビティの貢献価値に基づく意思決定」)の内容を、そのままご説明します。

リスク基準プロジェクト価値(RPV)は、わたしが提案した意思決定のための尺度で、文字通りリスクを勘案したプロジェクトの価値を数字で表したものです。これを用いると、プロジェクトを構成する各アクティビティの貢献が計算できるばかりでなく、コスト対リスクといったトレードオフ状況下における意思決定を、客観的にサポートする基準を導出することができます。

このRPV理論は、わたしが自分の学位論文の中ではじめて提案し、研究・発展させてきたものです。理論的な内容のため、これまでは学会論文誌や大学講義、ならびに海外でのみ、発表してきました。今回、はじめて普通の民間の場を借りて、お話しする機会をいただきました。そこで具体的なケース事例を交えて、できるだけ分かりやすく解説させていただくつもりです。

この講演は、どなたでも参加できます。大勢の方のご来聴をお待ちしております。

<記>

日時:12月8日(金) 18:00〜

場所:日本プロジェクトマネジメント協会 「PMAJ Networking」
   〒106-0044 東京都港区東麻布一丁目5番2号 トウセン東麻布ビル7階

講演タイトル:
「PMへのシステムズ・アプローチと、『リスク基準プロジェクト価値(RPV)』理論の応用」

要旨:
 モダンPMの手法は、1950年代の米国で、プロジェクトを『アクティビティのネットワークからなる一種のシステム』と認識した事にはじまる。以来、PERT/CPM、WBS、EVMSなどの定量的技法が開発され普及してきた。しかし今日のPM論の枠組みには、まだ意思決定に資する価値論が欠けているように思われる。演者は数年前から、『リスク基準プロジェクト価値(RPV)』という指標を用いた、独自の理論的枠組みを研究してきた。本講演では、10月末に米国シカゴのPMI世界大会に発表した内容を中心に、ケース事例への応用と今後の課題について展望する。

講師プロフィール:
 日揮株式会社・グローバル戦略室長代行。博士(工学)。中小企業診断士。
 ながらく国内外の製造業のプラント計画、生産システム構築と、プロジェクト・マネジメントに従事。現在は経営企画部門で戦略立案に携わる。
 そのかたわら、近年はプロジェクト・マネジメント手法の改善・体系化と教育に力を注ぎ、「リスク確率に基づいた新しいプロジェクト・マネジメント」の研究開発にも取り組んでいる。
 静岡大学客員教授、東京大学・法政大学非常勤講師。

参加申込みは、以下のURLからお願いします。


佐藤知一@日揮(株)


by Tomoichi_Sato | 2017-11-16 22:10 | プロジェクト・マネジメント | Comments(0)

天の時・地の利・人の和と、プロジェクト

プロジェクトに関わる仕事をずっとしていると、プロジェクトの成否はプロマネの手腕やチーム員の努力だけでなく、「天の時・地の利・人の和」とでも言うべき要因によって左右されがちだ、と感じることがある。いわば、プロジェクトの出発点における環境条件である。こうした環境がプロジェクトのパフォーマンスにどのような影響を与えるのか、まだ十分に解明されていないように思う。

たとえば、「天の時」である。

プロジェクトのスタートするタイミングは、さまざまな形でパフォーマンスに影響する。端的には、マーケットの状況だ。市場全体が活況を呈しているかどうか。受注型プロジェクトの場合なら、契約金額が上昇気味かどうか? これは、プロジェクトの採算性にとって重大である。また、外部に発注するリソースや資機材の値段が上がりつつあるか、どうか。これも採算に影響する。

自社が好調か、それとも苦しい時期かも大きな要因だ。苦しい時期だと、どうしても無理して仕事を取りに行く姿勢が強まる。当然、予算は厳しくなる。

こうした全体的な市況は、プロマネ自身が勝手に選べるものではない。まったく同じ前提条件ではじめても、スタートする時期が好況期で売り手市場なのか、あるいは不況期で買い手市場なのかによって、結果は相当異なるだろう。途中で市況が急変することだって、ある。わたしは10年近く前、あるビッグ・プロジェクトの見積をしていたが、途中でリーマンショックが深刻化し、プロジェクト自体の成立が急に危ぶまれたことを思い出す。そうなると、億の単位でかかる見積費用が、パーになってしまうのだ。たまったものではない。

次の、「地の利」とは何か。

プロジェクトを遂行する上で、立地的な優位性があるかどうか、の意味が第一だ。プロジェクトを遂行したり成果物を納入する場所の近くに、自社の拠点があるかどうか。これは、ふつうプロマネが自分で決められる条件ではない。海外プロジェクトの場合は、そこに支社や合弁相手がいるかどうか。いるとして、その能力はどうか。あるいは、日本から出かけていかなければならないのか。これらは大きな違いを生む。たまたまわたしは今、この文章をジャカルタの空港で書いているが、多くの日本企業がすでに存在していることも、ある種の地の利であると考えられる。

地の利は、より象徴的には、競合状態が厳しいかどうか、を表す。たとえ市況は好調期、現地に拠点があろうとも、競合相手が5社も10社も現れるようでは、レッド・オーシャンそのものである。勝ち抜くのは、かなり厳しい。

では「人の和」は、プロジェクトにとって、何を意味するか。

もちろん、それはまず、プロジェクト・チーム自体の協働意識を、そのまま表す。だが、そこはプロマネがある程度は醸成できるし、しなければならない。

しかしさらに掘り下げると、適切なメンバーがアサインされているか、という問題になる。メンバーがプロマネの固定的な部下であるような組織では、まあ、これは問題になるまい。が、機能型組織やマトリクス型組織では、複数の部門からメンバーをアサインしてもらわなければならない。とくに製造業ではライン部門長の権限は強大だ。プロマネが好きに人を集められる訳ではない。

もっと言うと、プロマネ自身の任命が適切か、ということもある。これはPMO的な視点から言っているのだが、「あのプロジェクトの最大のリスク要因は、XXさんがプロマネをやっていることだ」という笑えない冗談も、生まれたりする。良い仕事は、チームワークから生まれる。ぎくしゃくしたチームから、優れた仕事が生まれる可能性は、少ない。

しかし、人の和に関する、より深刻な問題は、外部のステークホルダにある。たとえば顧客(発注者)、ユーザ、協力会社、ベンダー、監督官庁、地域住民などである。とくに顧客は重要だ。受注型プロジェクトで、訳の分からん顧客に当たって、苦労した経験のあるプロマネは多いだろう。顧客と和の気持ちを持って、適度に緊張した関係を続けられるかどうかは、プロジェクトの成否を大きく左右する。

このほかに、かなり大事な要素として、プロジェクト・スポンサーの能力をあげたいところだ。スポンサーとは、経営層に近い上級管理者で、プロジェクトに予算枠を与え、プロマネを任命する権限を持つ人のことである。「スポンサー」のかわりに「プロジェクト・オーナー」と呼ぶケースもある。

プロジェクト・スポンサーは、プロマネの後見人であり、相談相手でもある。この人が、プロジェクトに理解があり、適切に経営層を動かせるかどうかが大事だ。大事なのだが、そもそも日本企業では「スポンサー」の役割が存在していなかったり、十分に認識されていない場合が多い。そうなると、「人の和」に、重大な欠落があることになる。

(余談だが、拙著『世界を動かすプロジェクトマネジメントの教科書』は、海外企業と合同でプロジェクトを始めることになった製造業を舞台に、主人公の若手技術者が、プロマネもスポンサーも誰だか曖昧な状況下で、なんとか成功させようと懸命に奮闘する物語である。つまり、あれは和を尊しとなす日本企業で、じつは機能的な「人の輪」が欠落している問題を扱っている)

元々、天の時・地の利・人の和とは、「天の時は地の利に如かず、地の利は人の和に如かず」という孟子の言葉から来ている。これが日本では、戦国時代に兵法の判断条件として、流布されるに至った。人の和が一番大事だと、孟子はいう。だが、戦国大名ならいざ知らず、現代のプロマネにとっては、上記の通り自分の力だけで人の和を作り上げることはできない。まして天の時や地の利は、所与の条件、としか言いようがない。

こうした要素は、環境としてプロジェクトに影響を及ぼす。ここで環境とは、「プロマネの意思では短期間に変えられないものごと」を意味する。

プロジェクトの成否は、受注時点で半分以上が決まっているーーそう言ったら、読者諸賢は、オーバーだと思うだろうか。だが、これに近い実感を、受注型プロジェクトに長年従事する実務者は、少なからずもっている。受注の時点で、天の時・地の利がもう決まっている。人の和も、かなり重要な部分が定まってしまっている。残された自由度の中で、プロマネは奮闘をはじめなければならない。

問題は、プロジェクトの採算が結果として悪化した時に、その原因のうち、環境因子による部分と、プロマネに起因する部分が、それぞれどれだけあるか、客観的な評価が難しいということだ。もちろん、「半分以上が環境」というのは、感覚論にすぎない。これについて定量的な分析を、あいにくわたしは見たことがない。

「プロジェクトの結果・採算は、全てリーダーであるプロマネの責任」、という結果責任の原則をとる企業は多い。これは、プロマネに責任感を持たせて育てるためには、良い指針である。プロマネがいつも責任回避的、あるいは他責的な人間では、会社はこまってしまう。

しかし、だからといって、プロジェクトの最終的な損益金額だけで、プロマネたちを、
 「貴方は今期2千万円の黒字を出したからA評価」
 「お前は今回、5百万円の赤字を喫したからC評価」
と、単純に査定していいだろうか?

それはあまり賢明ではない、と、わたしは考える。個別の案件の結果は、短期的な環境因子に左右されやすいからだ。プロ野球の一流バッターだって、打率は3割台である。1打席ごとの結果は、その時の状況に左右されやすい。能力の査定はある程度、長期的に見るべきだ、というのがわたしの意見である。ただ人事の査定は、半年ないし一年ごとに行わざるを得ない。数プロジェクトの平均打率を計算していては、間に合わない。では、どうするか。

わたしの提案は、プロマネの査定を行う前に、「プロジェクトの評価」を組織として公式に行うべきだ、というものである。会社として
  • プロジェクトの成果物、
  • 達成した金銭的価値、
  • 非金銭的な達成(人材の成長や実績レコードの確立など)、
  • 出発時点での環境条件、そして
  • 今後への教訓など
を評価し、記録する。このとき、損益の数字だけでプロジェクトを評価しないことが大切であろう。

その上で、出発点から到達点までの、プロマネの貢献を考量する。それが査定のベースとなるべきである。たとえプロジェクトの最終評価が低くとも、出発点での環境条件が厳しい場合は、その分を勘案する。

そのためには、プロジェクトの出発時点で、『案件のプロファイリング』を行う必要がある。市場環境(天の時)・競合状況(地の利)・顧客特性と組織メンバー(人の和)などを、プロファイリングして事前評価しておくのである。別に5段階評価程度でもいい。このような作業は、営業段階における受注戦略・案件選別においても有用だろう。営業部長の胸先三寸にすべてを任せるより、少なくとも公平に思える。

念のために書いておくが、上記のようなことを、わたしの勤務先がすべて実践しているから真似た方がいい、というような話をしているのではない。そうではなくて、環境条件の重要性に目を向けて、各社でそれを評価するようにしたらどうか、と提案しているのだ。また、そういう問題に定量的に取り組む研究者が、できれば現れてほしい。

その上で、厳しい環境条件が揃っている場合は、組織として積極的にプロジェクトの支援を行う。そうして、プロジェクトが倒れないように支える。そういう仕組みが必要だろう。

支援で人を出すと、その人件費のぶん、採算がさらに悪化する。すると、プロマネ自身は赤字をおそれて、支援を遠慮するかもしれない(問題を抱え込んで、上に報告しない可能性さえある)。しかし、放置したら会社としては、もっと赤字が膨らむ。それを防止することが、全体としては重要だ。

会社がプロマネを任命して、「プロジェクトは結果が全てだ」「あとは死ぬ気で頑張ってこい。」というのは、以前も書いたようにレベル1のマネジメントである。それで良い場合もあるが、いつでも正しい訳ではない。適切なマネジメントの仕組みを作るのは、会社の側の仕事である。

またプロマネの側も、本当に良い仕事をしたければ、人の和をつくり、地の利を整えた上で、天の時を待つだけの忍耐力が必要だということになる。それを昔の人は、「人事を尽くして天命を待つ」と言った。

それだけの謙虚さが、わたし達には必要なのだろう。気合や根性よりも、天の時への謙虚さが。


<関連エントリ>
→「マネジメントのレベル0からレベル2まで」(2017-09-22) http://brevis.exblog.jp/26064558/








by Tomoichi_Sato | 2017-11-12 18:16 | プロジェクト・マネジメント | Comments(0)

お知らせ:プロジェクト・マネジメントの一日研修セミナーを行います(12月4日)

東京での研修講演のお知らせです。
来る12月4日に、日本テクノセンター(東京・新宿)で


と題する1日研修を行います(有償です)。

本講座では、プロジェクト・マネジメントの主要な技術について解説します。とくに、プロジェクトの成功をしばる三大制約条件であるスコープ・コスト・スケジュールと、それらをコントロールする技法であるWBSEVMSPERT/CPMについて、演習を交えてしっかりと学びます。とくにプロジェクトの基礎となるWBSの作り方については、他にあまりない実戦的なテクニックをお伝えします。また「海外型プロジェクト」の特性と進め方に関しても、講師自身の長年の経験に基づく実践的な解説を行います。

ただし、プロジェクトの成功はプロマネ個人の知識レベルや、スキルだけでは決まりません。組織がもつ思考と行動習慣(いわば組織の「OS」)に応じて人を動かすことが大切だからです。たとえば、

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

といった項目に、一つでも思い当たることがある方に、ぜひ受講していただきたいと願っております。単なる外国の教科書の解説ではなく、実践的で身につく知識とスキルを学べる講習ですので、とくにこれから海外系のプロジェクトに取り組もうとされる方に、おすすめします。また、中小規模のプロジェクト実務に携わりつつも、世間のPM標準では満たされぬ思いを感じておられる方々にも、身のある内容だと自負しています。

本研修の内容は、拙著『世界を動かすプロジェクトマネジメントの教科書』とも連動しています。著書はストーリー仕立てになっていますが、研修では背後にある原理とセオリーなどについてもきちんと解説いたします。

お申し込みは案内サイトから行えます。大勢の方のご参加をお待ちしております。


佐藤知一

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

PMの世界はどこに向かうのか 〜 PMI世界大会2017に参加して


1. PMI世界大会とは

米国で10月28日から30日まで開催された、PMI Global Conference 2017 https://www.pmi.org/global-conference/about というカンファレンスに参加してきた。PMIはProject Management Instituteの略で、ご存知の方も多いと思うが、米国発・世界最大のプロジェクトマネジメント専門職団体である。全世界に40万人以上の会員を擁し、通称「PMBOK Guide」(正式名称"A Guide to Project Management Body of Knowledge")と呼ばれるPMの標準書を制定、さらにProject Management Professional(略称PMP)という資格試験認定制度を有している。世界で最も影響力の大きなPM関連団体だ。

そのPMI Global Conference(長いのでPMI世界大会と略そう)は、今年はシカゴで開催された。約3千人が参加する、大規模なカンファレンスである。ベンダーの展示会も併設されている。世界大会の名にふさわしく、60カ国から参加者があったという。みたところ、聴衆は北米、南米からの参加者が多い。他に中東、インドからの参加者も多少眼についた程度か。

ただ意外だったのは、中国人がほとんどいなかったこと。今どき、どこの分野の技術展示会でも大勢の中国人をみかけるものだが、不思議と少なかった。また韓国人らしき人や、東南アジア・アフリカからの参加者も少なかった。ちなみに日本からは、数名の参加者があったようだ(PMI日本支部の方とは、挨拶を交わした)。わたし自身、この大会に参加したのは、はじめてである。2コマ、合計2時間ほど、講演発表をした。その内容については、後で触れよう。

わたしは個人資格で、自費で参加した(発表申込みの事前審査をパスすると、大会参加費約15万円は無料になるが、旅費宿泊費は負担が必要)。日本人の発表者は、他にはいなかったと思う。だが日本にはPMI日本支部・PM学会・日本PM協会という大きな団体が三つもあるのだから、もっと競い合って米国で発表したらどうかと思うのだが。
e0058447_12501480.jpg
(PMI世界大会2017 基調講演の風景)

2. セッションの構成

今回の大会では、全部で100以上のセッションがある(https://www.pmi.org/global-conference/program-schedule)。10以上の部屋で、並行して進んでいく。そしてセッションは基本的に、どれも1時間以上の長さがある。

PMI世界大会は、いわゆる学会風のカンファレンスではない。ふつう学会となると、発表時間は15-30分程度だし、アカデミック・スタイルで論理的に、堅苦しくしゃべらなければならない。しかしPMIの大会は、もっとずっと自由である。講演者が聴衆に語りかける感じだ。分類としては、Educational Session(教育セッション)が中心で、その他に、展示会の出展者によるベンダーセッションがある。

教育セッションは、さらに5種類に分かれる
  • Analyzing and Process Improvement(プロセスの改善)
  • Communication and Teamwork(コミュニケーションと組織)
  • Decision Making and Problem Solving(意思決定と問題解決)
  • Enhancing PM Skills(PMスキル向上)
  • Influencing and Business Strategy(ビジネス戦略と働きかけ)

こう並べてみると分かる通り、セッションの話題はPMのソフト・スキルが中心であり、ハード・スキル系の講演は少なかった。ちなみにハード・スキルとは、技術・知識として確立されており、座学などで習得が可能な能力を指す。PMの分野でいえば、WBSやCPM・EVMSなど、理論やツールに関する事柄だ。だが、こうした話題の発表はほとんどなかった。

他方、ソフト・スキルとは、交渉力や問題解決力など、もっと属人的な技能である。日本だと「人間力」などと一括されがちな能力だ。こちらがどうやら、米国PM界の現在の関心の寄せどころらしい。人間心理などにも関わりが深い。ちなみに米国には「行動科学」「社会心理学」などの流派の心理学がけっこう旺盛である。それは最近の「行動経済学」などにもつながっているし(今年のノーベル経済学賞も行動経済学者だった)、経営学にも取り入れられている。その影響が PM分野にも、かなり流れ込んでいる感じだ。

大会では同時に、"PMI Project of the Year”の発表とポスター・セッションが行われた。毎年行われる数々のプロジェクトの中から、最優秀プロジェクトを選んで表彰するものである(わたしの勤務先は2002年に、サウジアラビアのプロジェクトで受賞した)。今年の候補者は、優勝のHanford Double Shell AY-102 Recovery Project(放射性廃棄物の漏洩回収プロジェクト)のほか、シアトル市のUniversity Link Light Rail Extension(郊外型公共交通システム建築プロジェクト)、Gahcho Kué Mine Project(北極圏でのダイヤモンド採掘施設建設プロジェクト)などである。こうしてみると建設系のプロジェクトが多いのに、大会のセッションには建設関係の話題がきわめて少ないのは不思議である。

ちなみに、本大会のセッションは、よく日本などで行われるような産業別・分野別などの分類にはなっていない。業種を越えて共通の話題を取り扱う、という方針なのだろう。なお、この秋には、遅れていた
PMBOK Guide第6版がやっと出版された訳だが、この解説セッションなどはなかった。


3. わたしの講演発表

わたしの講演タイトルは、"Decision making with Risk-based Project Value (RPV) analysis and activities’ value contributions"である。長さは1時間。日曜日に1回行い、さらに月曜日午後にアンコール講演を行った(アンコールの実施は、事前に事務局からの要望で決まっていた)。

内容は、わたしが近年ずっと取り組んできた、「リスク基準プロジェクト価値(RPV)」理論の概要と、ケーススタディの応用例である。今日のモダンPMには、価値論が欠けている、というのが、かねてからのわたしの課題認識である。意思決定はプロマネの主要な仕事であり、何かを決めるためには、複数の選択肢の中から、ベストなものを選ぶ必要がある。ベストなもの、とはすなわち、「プロジェクトの価値を最も高めるもの」という意味だ。

だが、どんな選択肢にも、不確実性とリスクが付随しているのが、プロジェクトの世界である。では、リスクを伴うプロジェクトの価値とは何で定義されるのか。また、プロジェクトを構成する一つひとつのアクティビティ自体は、そのプロジェクト価値に対して、どのような貢献をするのか。こういった問題を、RPV分析という手法で定量化できる、というのが、わたしの理論的枠組みである。

この上で、たとえば二つの選択肢AとBがあり、AよりもBの方が余計にコストがかかるが、そのかわりBの方が、プロジェクト全体に与えるリスクが小さい場合、どちらをとるべきか、数字で比較評価できるような方法を提示する。このようにして、プロジェクト意思決定に客観性のある基準を確立する、というのがわたしの講演発表の主旨である。さいわい講演は2回とも、好意的な反応を多くの方から(とくに実務者から)いただいた。

なお、今回の発表内容は、来る12月8日(金)夕刻に、東京神谷町の日本プロジェクトマネジメント協会(PMAJ)が開催する「PM Networking」で詳しく再演する予定である(もちろん日本語で)。PMAJ非会員も自由に参加できるので、近いうちに本サイトでもご案内するつもりだ。
e0058447_12500077.jpg
(講演発表のスライドの前で)


4. 他のセッション内容

わたし自身が聴けた中で、ほかに印象に残ったセッションを、いくつかご紹介しよう。

全体のオープニング・セッションでは、Sir Tim Berners-Leeの講演があった。89年にスイスの物理学研究機関CERNで、はじめてWorld Wide Webとhttpを開発した人だ。これは20世紀後半の最大の発明だったと思う。最後に彼は、AIが将来、裁判で人を刑務所に送り返すか放免するかを決めるようになる可能性もある、と予測。だがその時には、Accountabilityが大切になるし、裁定の理由を説明できなければいけないだろう、との意見には感心した。

もう一人のキーノート講演者・Nicholas Epleyシカゴ大教授の "Mindwise: How We Understand What Other Think, Believe, Feel, Want”もなかなか興味深かった。Epley教授はまさに行動科学者で、マスコミにも頻出する有名人である。彼はさまざまな心理学実験から、わたし達人間が、いかに他人と理解し合えていないかを説明する。にもかかわらず、わたしたちは、「他者に理解してもらっている」と過剰に自信を持っていることが、実験から証明できる。このギャップこそが、われわれのコミュニケーションに横たわる最大の問題点だ、というのが彼の解説である。

一般講演の中で一番面白い、と個人的に感じたのは、Andy Silberというコンサルタントによる、"Adaptive Project Management: Leading Complex and Uncertain Projects"という講演だったかも知れない。Silberは、ハードウェア製品開発プロジェクトの専門家である。彼は縦軸に複雑性、横軸に不確実性をとって、プロジェクト方法論を分類していく。まず左下に「最小限の計画」を位置づける。つまり出たとこ勝負だ。縦軸の不確実性とは、プロジェクトの規模をある程度、表す。だから、左上に「ウォーターフォール」をとる。大規模な建設プロジェクトが、その好例だ。そして、クリティカル・パスはPMの重大な関心事となる。

一方、彼は右下に「アジャイル」をおく。アジャイル開発は、要求仕様の不確実性に対応する、良い方法だ。ただし、これはITプロジェクトの一部にしかうまく適用できない。同じ製品開発でも、ハード系になると、長納期の部品調達などにプロジェクトが引きずられるからだ。そこで彼は、右上の象限に、 "Adaptive PM"をおく。ハードの製品開発がここに位置づけられる、というのはなかなか良い。
e0058447_12502596.jpg
Adaptive PMでは、"Replan often"(しょっちゅう再計画)という漸進的なアプローチをとる。この点では、アジャイルに似ている。しかし長納期部品などクリティカル・パスにもフォーカスする必要がある。そこで、フェーズ化されているが、フェーズを一部やり直しながら進める方法をとる、という。これによって進む方向をアジャストしていくのだ。これを通称「刺身モデル」という。なかなか面白い。そして、今回聞いた中で、これが一番、ハードスキル的な話だった。

他にも、Brian Clausenという人の"Design Thinking”の講演、Andy Kaufmanの"Decision making”の講演、
人間類型を用いた"Business Chemistry”の解説、パワポを使わずにプレゼンしようという講演、そして米国企業で働くインド人による、異文化の問題の講義など、興味深い講演が多かった。


5. PMIは、そしてPMの世界はどこに向かうのか

今回のPMI世界大会でのセッション全体をみると、Agile関連の話題がわりと多い印象である。また、Design Thinking(デザイン思考)もいくつか眼についた。

これは結局、プロジェクト・マネジメントにおける”How”(コストやスケジュールなどをいかに計画しコントロールするか)の問題から、”What”(プロジェクトで何を生み出すか)に、関心が移行していることを示しているように思われる。別の言い方を借りれば、"Do things right”から、"Do right things”へ、ということである。

わたしは2003年に、ボストンでProject Worldというカンファレンスに参加したが、その時はハード・スキルや方法論の話が多かった。そして、非常に勉強になったという記憶がある。分野も、医薬品もあればITも防衛産業もある、という感じだった。ただし当時はまだ、米国全体で、Program以上の上位概念への関心が薄かった。

それから12年後、2015年のProject World Bostonは、かなり様変わりしていた。まず、BA(Busines Analyst)団体の大会との共同開催だった。これは、もはやIT ProjectがPM界の主体となったことを示している。その流れは、PMIによるBusiness Analysisの標準制定などの動きにも通底している。

察するに米国では、ハード・スキルの教育普及はおそらく一巡したのだろうと考えられる(その点、日本とはまだ事情が違う)。そして、ソフト・スキルに関心が移ったのだ。

こうした変化は、米国の経営学の歴史の流れをなぞっている、ともいえる。ちょうど100年前、米国でテイラーが「科学的管理法」を提唱したとき、それはハード・スキル中心だった。それはフォード・システムなど自動車産業での応用に結実していった。しかし、1930年前後の有名な「ホーソン実験」以後は、モチベーション理論へと経営学の焦点が移っていく。すなわち、リーダーシップなどソフト・スキルへの注目である。日本風にいえば、理系的な経営工学から、文系的な経営学へのシフトだった。

そして'80年代以降は、金融工学への傾斜があった。つまり、経営における関心事が、
 科学→人の心→お金
という風に、アメリカではシフトしていったのである。

米国におけるPMの分野でも、科学から人の心へ、という方向性が感じられる。CPMやEVMSなど、技術とツールは整った。プロマネもPMBOK Guideで知識を得て、PMPの資格も取った。だが、プロマネの悩みは、あまり解決されていないのである。ハード・スキルの普及によって、プロジェクトの短期的な成功率は上昇した(これは米国IT分野の統計が示している)。だが。望んだアウトカムは得られていない。そのもどかしさ・不満感が、伝え聞くようなPMIの会員数の伸び悩みにつながっているのではないか。

もう少し問題をさかのぼると、PMBOK Guideの枠組みとその限界に突き当たる。PMBOKは周知の通り、「プロセス」を中心にして、プロジェクト・マネジメントの仕事を整理した。それはじつに見事な体系化だったと思う。また、とくに初期のPMBOKは、受注型プロジェクトを無意識に前提としていた。つまりScopeは顧客からSOWで与えられていて、かなり固まっている、という前提である。これは防衛宇宙産業やエンジニアリング産業では確かにその通りだが、そうでない種類のプロジェクトも世には多い。

プロセスとは、How(いかに)を記述するものだ。だが、本当にプロセス中心アプローチで、望む成果が得られるのか。それが今の多くの人の悩みなのではないか? そこでデザイン思考やアジャイルなど、Whatを明らかにする技法に脚光が当たっている。だがWhatを掘り下げていくと、そもそも、何を目的とし、何を価値としてプロジェクトをやっているのか(Why)の問題に突き当たる。

 How→What→Why

こう考えていくと、現在のPM理論のパラダイムには、大きな革新が必要だと分かる。そして、そのブレイクスルーとなるのは価値論であろう、というのがわたしの信条である。当然ながら、これには異論もあろう。だから、そういったオープンな議論ができる場を、わたしは作りたいのである。


by Tomoichi_Sato | 2017-11-03 12:56 | プロジェクト・マネジメント | Comments(0)

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

各位:

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

今回は、製造業におけるプロジェクトの一つである、受注設計生産のスケジューリングについて、この分野の専門家である(株)シムトップスの伊藤昭仁様にご講演いただきます。

日本の製造業の生産形態は、高度成長時代の大量見込生産から、次第に受注生産中心へと移っています。中でも、顧客の個別仕様に合わせて、受注してから設計し生産する受注設計生産(一品受注生産ともいう)は、プロジェクトの一種でもあり、もっとも生産管理の難しい形態ということができます。それは設計・調達というホワイトカラー業務と、製造現場の両方をシームレスにコントロールする必要があるからです。また、生産スケジューリングの基礎データとなるBOM(部品表)が、受注時点ではまだ固まっていない、という難しさもあります。

この受注設計生産プロジェクトの分野において、早くからスケジューラをはじめとするソリューションを開発してきた伊藤氏から、現実に即したお話を伺います。また久しぶりにIT業界の方のご講演でもあります。

いささか直前のご案内になりましたが、ぜひご参加ください。

<記>

■日時:2017年10月12日(木) 18:30~20:30

■場所:慶応大学 三田キャンパス・北館会議室2(1階) (定員:28)
キャンパスマップ 【1】

■講演タイトル:
「受注設計生産のプロジェクトスケジューリングの課題と改善期待効果」

■概要:
 量産を前提にしない受注設計生産では、事前に基本マスターの整備ができず、プロセスフロー(BOP)の定義が困難な場合が多い。その結果、ストラクチャー型のBOM (部品表)を前提にした生産管理システムや生産スケジューラの適用を難しくしている。これらの現状の課題と、受注設計生産へのプロジェクトスケジューリングを適用するための取組みと日々の工程管理における改善期待効果を述べる。

■講師: 株式会社 シムトップス 伊藤 昭仁(いとう あきひと)

■講師略歴:
 1991年 株式会社シムトップス 設立と共に入社20年以上にわたり、受注設計生産の製造業向けの生産スケジューラ/工程管理システムの導入前の提案からシステム導入後の立ち上げサポートまで、広範囲の業務に従事。国内主要自動車メーカの金型部門、工機部門、試作部門、半導体製造装置から発電設備などのプラント設備まで、幅広い受注設計生産タイプの生産工場へ100社以上のシステム導入経験を持つ。

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

 参加を希望される方は、確認のため、できましたら当日までに三好副幹事(miyoshi_j@kensetsu-eng.co.jp)までご連絡ください。

以上、よろしくお願いいたします。
佐藤知一@日揮(株)

by Tomoichi_Sato | 2017-09-28 07:51 | プロジェクト・マネジメント | Comments(0)

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

講師急病により先月の講演を延期いたしましたが、幸い復調されましたので、あらためて8月8日(火)に開催させていただきます。
会員の皆様にはご心配をおかけいたしました。(7/19 佐藤知一・追記)
----------------------------------------------

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

今回は、雪印メグミルクの松本卓夫様を講師にお迎えして、同社の企業再生のプロジェクトについてご講演いただきます。

ご承知の通り、旧・雪印乳業を中心とした雪印グループは、2002年に企業存亡の危機を迎えます。四面楚歌の中、会社に残られた方々は、生産と物流をカバーするサプライチェーンの改革に、収益回復と業績再生の希望をつなぎます。

その渦中を奔走し、改革プロジェクトをリードされた当事者である松本様から、具体的なお話を頂戴します。ある意味で、我が国が必要とするプロジェクト・マネジメントの生きた姿を示すと言っても過言ではありません。サプライチェーンの改革と企業の復活はどのようなものか、興味深いご講演に、ぜひご期待ください。


<記>
■日時:2017年8月8日(火) 18:30~20:30
■場所:慶応大学三田キャンパス 北館会議室2(1階) (定員:28)
※プロジェクターあり
キャンパスマップ・【1】

■講演タイトル:「雪印メグミルクのSCM構築と統合工場(阿見工場・総合物流センター)建設の概要

■概要:
雪印メグミルクでは雪印乳業時代の2003年から2009年にかけてSCMシステムの開発導入と業務改革を実施し、大きな収支改善を実現した。また、さらに高度なSCMの実現のため既存3工場を集約した乳製品統合工場と原料・製品保管と保税機能を有する総合物流センターを建設し、サプライチェーンの全面見直しによる収支基盤の強化を実現した。これらの取組みとプロジェクトの概要を述べる。

■講師: 雪印メグミルク(株) 松本卓夫(まつもと たかお)様
■講師略歴:
1981年 早稲田大学 理工学部 工業経営学科卒業
      雪印乳業 入社
      福岡工場 本社 技術部 装置技術部 SCM推進部 物流部
2007年 本社 生産部 担当部長
      生産設備 企画導入施工・装置開発・SCMシステム開発 総括
2011年 会社合併により、雪印メグミルク 生産技術部 副部長
2012年 乳製品統合SCMシステム構築プロジェクト統括マネージャ
      阿見工場システム構築・阿見総合物流センター建設
2015年 生産技術部 装置開発グループ 副部長
      生産設備技術開発・FA開発導入・SCM開発 総括

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

会場の人数に上限があるため、参加を希望される方は、できましたら前日までに三好副幹事(miyoshi_j@kensetsu-eng.co.jp)までご連絡ください。
以上、よろしくお願いいたします。


佐藤知一@日揮(株)


by Tomoichi_Sato | 2017-07-19 23:14 | プロジェクト・マネジメント | Comments(0)

ビジネス・マネージャーとは何をする人か

数年前、製造業に働く方から相談を受けた。その企業では、西南アジアの某国でプロジェクトをはじめるという。プロマネ以下、何人かのチームでその国に乗り込み、現地企業と共同で新しい製品の製造ラインを作る仕事だ。そこで、何かアドバイスがあれば頂戴したいという話だった。

もちろん、わたしはその会社の製品について何も知らないから、技術的アドバイスなどしようもない。できるのはマネジメント的なアドバイス、つまりプロジェクト・マネジメント面での助言ということだろう。そこで、チーム編成やプロジェクト期間などについて少したずねた後で、わたしは申し上げた。

ビジネス・マネージャーを任命してチームに入れるべきです。
 営業畑でも、法務でもいい。文系の人を任命してください。」

技術的プロジェクトだからと言って、技術者ばかりでチームを編成するのは賢いやり方ではない。そう、わたしは申し上げた。もちろん文系といっても、英語が一応しゃべれることが望ましいですが(その国でビジネスをやるなら、英語のコミュニケーションが必要になる。大学教育は英語で行っているはずだから)。
−−でも、ビジネス・マネージャーって、何をするんですか?

それが先方の疑問だった。なるほど、知らない人には分かりにくいかもしれない。

日本には理系と文系という、諸外国にはあまり見ない不思議な制度的区分がある。理系の人は文系のことは知らなくて良いし、文系の人は技術に興味がなくてもて当然だという、思考習慣がある。MITすなわちマサチューセッツ工科大学に、経済学や言語学の講座があってもいいじゃないかと考える欧米流とは少し、ギャップがある。

ただし英語では(つまり、英語でビジネスをする業界では)、Technical と Commercial という区分がある。たとえば、きちんとした国際入札は普通、Technical Proposal と Commercial Proposalのに分冊の作成が要求される。日本語でいえば。技術提案書と商業提案書かな。

技術提案書には、設計面での提案や、遂行方針などが記される。そして商業提案書には、価格(明細・合計)、支払・保証など契約面についてが書かれる習慣だ。通常の日本の商慣習に翻訳すれば、前者が「見積仕様書」、後者が「御見積書」になるだろう。

そして国際入札では、まずTechnical Proposalの評価(技術評価)で合格した入札者のみ、Commercial Proposalが開封されるルールになっている。入札の選定は、値段だけでは決めない。いや、先に値段を見て安い応札者に対して、技術面をネゴしたりもしない。まして、技術的には優秀だが値段が二番手以下の応札者に対し、一番札の値段を教えて値引き要求をしたりもしない。これが国際的な慣習で、それを破ると業界内で信用を失う。つまり二度とまともに入札ができなくなる(応札者がいなくなる)、という仕組みである。このようなTechnicalとCommercialの区別と順位付けが、国際入札の仕組みを守っているのである。

さて、Proposal全体を取りまとめる責任者は、PM=プロマネである(あるいはProposal Managerともいう)。そしてCommercial Proposalの部分をまとめるのが、BM=ビジネス・マネージャーの仕事なのだ。

しかし、BMの仕事が一番大事になるのは、受注後の遂行段階である。そして、客先との交渉(ならびに、その準備)が主要な仕事の柱となる。追加や変更に伴う交渉においては、BMが過去の書類やメールなど、証拠(エビデンス)を全部まとめ上げる仕事をしてくれる。そして変更に伴うインパクトや、作業費用を見積もるのもBMだ。さらに過去データや外部企業の事例を探してきて、交渉の材料にするのだ。ここまで揃えば、プロマネの交渉の仕事はずいぶんやりやすく、楽になる。

なんだそれ、営業の仕事じゃないか、と思われた方もいるかもしれない。かもしれないが、貴方の会社の営業マンは、受注後もプロジェクトにはりついていられるだろうか? それも海外プロジェクトの現場で? せいぜい、たまに来て手伝うだけではないだろうか?

それに、交渉以外にもやる仕事はたくさんあるのだ BMは金銭や契約や雇用・労務に関わる一切の仕事に責任を持つ。もう少し具体的に列挙すると:

- 客先への請求と支払いに関わる事項
- 変更(Change Order)と見積・交渉に関わる事項
- プロジェクトの資金管理とキャッシュフローに関わる事項(海外プロジェクトならば外貨と為替も)
- 要員の手配・採用に関わる事項(海外ならばビザ手続きも)
- 外部発注企業に対する契約と支払いに関わる事項
- 執務環境に関する事項(海外プロジェクトならば宿舎の手配も)

こういうこと一切合切を仕切るBMがいなかったら、どうなるだろうか? こうした事柄は、いずれにせよ不可避である。避けて通れないのだ。となると、結局誰かがやるしかない。そして、それはつまりプロマネの仕事になってしまうのだ。技術に専念したい技術系プロマネにとって、こうしたことは「雑用」に思える。わたしは技術以外のことを、雑用として軽んじる見方には組みしないが、そう考える人は現実に多いだろう。

ここで、R・ハインラインの名作SF「月を売った男」 に出てくる挿話をわたしは思い出す。この物語の中で主人公は、自分が月ロケットの設計図に集中したいときにかぎって、運送業者がトラックの手配について文句を言ってくる、といって嘆く。すると彼の片腕になる男が現れて、そうした「一切の雑用」を自分が引き受けます、だからボスは技術に集中してください、と宣言するのだ。

ソフトウェア産業における生産性の問題を論じた「人月の神話」 の著者Brooks Jr.は、この「月を売った男」のエピソードを引用し、技術系PMの下に、商務に強いBMがいるのが理想だ、と書いた。たしかに一つの考え方である。

いや、ちょっとまって。ウチの会社にはそんな、営業面も法務も人事も会計も総務もわかるような、しかも英語も話せるようなスーパーマンはいないよ。そんな声も聞こえる気がする。たしかにそうかもしれない。

だが海外のライバル会社には、専門のBMがいるかもしれない。BMの交渉力やサポートが案外、赤字と黒字の分かれ目になるかもしれない。だったら、今からでも育成するしかないのだ。そのためには、まず、ビジネス・マネージャーという専門職種が必要なのだと、会社が認識することが先決だ。

以前にも書いたが、わたしは「文系」と「理系」という人材の区分をあまり認めていない。わたしの勤務先には、いわゆる文系出身ながら、エンジニアリング会社のプロマネとして立派な仕事をしている人が何人もいるし、まだ駆け出しだった若い頃について勉強した先輩も経済学部出身のエンジニアだった。またわたし自身、理系と文系の両方の資質を持った人間だと自覚している。だから、「技術屋だから契約オンチでいい」とか「営業マンだから設計の話は知りたくない」といった、自分で壁を作ってしまう人々の態度は、一種の怠惰だと思っている。

だが、文系・理系という区分は世間に流通しているし、そういう形で自己規定している人も多い。だったら、せめてその範囲内では責任感を持ってもらいたい、というのがわたしの期待だ。だから営業マンであって労務や会計は素人であっても、せめて「文系の守備領域」については、技術屋に対して自負を持ってくれるだろうと思い、冒頭に述べたような提案をしたのだ。

念のためにいうけれど、プロマネ人財だって、固有技術も管理技術もよくわかり、かつ人徳があってリーダーシップも豊富な、スーパーマンみたいな人は滅多にいないと思う。で、スーパーマンがいなくても仕事がある程度成り立つためには、仕事の仕組み(システム化)が必要なのだ。そしてプロマネを補佐したり助けたりする支援組織や専門機能が必要である。

もちろん、ちゃんとしたプロマネをまず、意識して育成しなければならない。ただプロマネは最終責任者なのだから、BMの領域についてだって、少しは知る必要がある。つまり契約や請求や会計や雇用について、せめてBMとちゃんと会話が成り立つ程度には、概念と用語の知識が必要である。そしてBMの側にとっても、営業や財務や法務など本社の専門部署からのサポートが必要なのである。

冒頭にあげた会社が、うまくBMを任命できたかどうか、残念ながらその後の話はまだ聞いていない。社内で見つけるのは、そう簡単でなかったろう。ただ海外ならば、逆に欧米人の専門家を雇う手段だってある。まあ専門家を呼べば、たぶん高給取りだろう。しかし、それで技術者達が技術に専念でき、赤字を回避できるなら、総合的には安いものだ。

それは、マネジメントの価値とコストの比較論である。マネジメントはリーダー職の片手間仕事ではない。とくに海外プロジェクトならば、なおさらである。契約社会でのプロジェクトには、「文系」的な職域に強い人材も、必要なのだ。技術力だけでは勝てない。そのことの認識が、海外に打って出るときの第一歩なのである。





by Tomoichi_Sato | 2017-07-10 22:32 | プロジェクト・マネジメント | Comments(0)