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

プロジェクト・インテグレーション・マネジメントと「鉄の三角形」

プロジェクト・マネジメントの世界で最も広く普及している標準書PMBOK GuideⓇには、ご存じの通り以下のような、10の知識エリアが規定されている。

・プロジェクト・インテグレーション (Project integration)
・スコープ (Scope)
・スケジュール (Schedule)
・コスト (Cost)
・品質 (Quality)
・人的資源 (Human resource)
・コミュニケーション (Communication)
・リスク (Risk)
・調達 (Procurement)
・ステークホルダー・エンゲージメント (Stakeholder engagement)

各知識エリアは、それぞれが”xx Management"と題されている。つまりQuality ManagementとかCost Managementといったたぐいだ。もっとも上記10個には多少の変遷があり、最初は9個だった。途中からステークホルダー・マネジメントが追加され、さらに最新版ではステークホルダー・エンゲージメント・マネジメントにかわった(ステークホルダーは外部の利害関係者なので、プロマネが直接はマネージできないためだろう)。またスケジュール・マネジメントの用語も、第5版まではタイム・マネジメントだった。

PMBOK Guideには、PMをプロフェッショナルな職域として確立しようとした、先達の叡智がつまっている。中でも一番偉かったのは、最初に「プロジェクト・インテグレーション・マネジメント」なる領域をおいたことだと思う(日本語版では「プロジェクト統合マネジメント」と訳されている)。プロジェクトという複雑な活動の集合を、一種のシステムとしてとらえ、そのIntegrityを保つ必要があるという問題意識から、この概念が生まれたのだろう。ちなみにIntegrityという英語には、全体性、統合性、整合性などのほかに、誠実さ・品位といった意味もあり、非常に高い価値が込められている。

ところで、プロジェクトのインテグレーション・マネジメントというのが何を指しているのか、ここが意外と分かりにくい。

PMOBK Guideはプロセス中心の記述になっていて、Project integrationの中には5つのプロセスが定義されている。(1)Project charterの作成、(2)プロジェクト・マネジメント計画書の作成、(3)プロジェクト作業の指揮・マネジメント、(4)プロジェクト作業の監視・コントロール、(5)統合変更管理、(6)プロジェクトやフェーズの終結、の6つである。

このうち、(1)と(2)は立ち上げフェーズと計画フェーズでの、いわば全体計画立案作業なので、明確だろう。遂行フェーズに入ると、プロジェクトのマネジメントとコントロールを行う。どちらもプロジェクトの全体が対象だ。

ただ、マネジメントとコントロールの二つが、別々のプロセスになっているのは、英語ではmanagementとcontrolがレベルの違う概念として、区別されるからだ(「わたしはなぜ、「プロジェクト管理」という言葉を使わないのか」 https://brevis.exblog.jp/26270824/ 参照のこと)。実際、大規模プロジェクトでは、両者はプロジェクト・マネージャー(PM)とプロジェクト・コントロール・マネージャー(PCM)という風に、職種が分かれて分担する。もちろん、PMはPCMの上位職である。

さて、問題は『統合変更管理』(Integrated change control)である。日本語訳では「管理」となってるが、原語はContorlであることに注意してほしい。これはいったい何をするのか。

PMBOK Guideはプロセス中心、つまり手続き主義の記述になっている。そして「変更要求」だとか「承認済み変更要求」だとかが、インプット/アウトプットに出てくる。

米国流のプロジェクト遂行では、発注者と受注者の間で、変更要求Change Requestと変更指示Change Orderが、やりとりされる。通常は受注者から変更のリクエストが提出され、発注者がそれを審査・承認して正式なオーダーを切る。オーダーには変更作業の詳細と共に、追加費用や納期延長が記載されている。もちろん現実には、提出から承認までの間に、「これは高すぎるだろ」と値切られたり、「これは追加じゃないはずだ」と言われて押し問答したり、といった交渉がはさまるのだが、そういう商慣習のプロトコルを知らないと、ここら辺の記述は分かりにくい。

また、自社内で完結する自発型プロジェクトの場合も、予算権限を持っているプロマネと、社内のステークホルダとの間で、似たようなやりとりが行われる。だからPMBOK Guideでは「承認済み変更要求」という用語になっているのだろう。

ところで、どうしてこれに、あえて『統合』という修飾語がついているのか? 何かの事情で仕様の追加や変更等が必要になり、それで予算が増えるなら予算追加要求、納期が延びるなら納期変更要求、それだけの話ではないか。

ところが、そうではないのである。

プロジェクトを取り巻く制約条件には様々なものがありうるが、通常、その中でも
• Scope(役務範囲)
• Cost(予算)
• Schedule(納期)
Project の三大制約条件である。まあ、だからこそPMBOK Guideでは最初の方の章に、この3つのエリアがあげられている。

ところで、この三大要素を図にすると、三角形で表される。三角形は、知っての通り、他の2辺に影響を及ぼさずに1辺だけをかえることができない。どれか、ある要素を変更するには、他の要素の変更も必要になるのだ。
e0058447_15161741.jpg
たとえば、何か仕様上の追加が必要になったとしよう。その場合、作業(Activity)が増える訳だから、スコープの1辺が長くなる。この場合、
・期限(スケジュール)を延ばして作業を完了
・人員(コスト)を増やして作業を完了
のいずれかが必要になる、という具合だ。

図を見てほしい。三角形の底辺であるスコープを長くすると、どちらかの斜辺を同時に長くせざるを得ない。いや、しばしばあることだが、スケジュールとコストの両方が増大したりする。

似たようなケースとして、遅れつつあるプロジェクトで、納期を間に合わせる工夫が必要だとしよう。その場合、
・人員を追加して(=コスト追加)、仕事を完了する
・スコープを減らして、期限までの作業量を減らす
のいずれかの方策が必要になる。

あるいは、予算内(コスト)で終わらせる場合ならば、こうなる:
・残業などはせず、プロジェクトの納期を延長する
・スコープを減らして、コストを削減する

プロジェクトには、変更がつきものである。だが、その影響範囲や必要性を考える際には、コストならコストだけ、スケジュールならスケジュールだけでは、判断できない。プロマネは、上述のように、つねにスコープ・コスト・スケジュールの3辺を制約条件として意識しながら、変更をコントロールしなくてはならないのだ。だから、「統合」変更管理 Integrated change control と呼ばれるのである。

英国の初期のPM研究者マーティンは、1970年頃、Scope/Cost/Scheduleからなるこの三辺を、「鉄の三角形」と名付けた。鉄の三角形は、プロマネをとじこめる束縛、あるいは牢獄のようなものだ。プロマネは、とくにプロジェクトの中盤以降、つねにこの三角形の制約条件と戦い続ける。なにか予期せぬ事が起きても、なんとかしてこの三角形の内部で解決すべく努力する。どれか一辺でも破ると、三角形全体の形が変わってしまう。

プロジェクトの成功には、いろいろな定義が可能だが、一番短期的に測りやすいのは、「スコープ・コスト・納期が、当初の予定通り完遂できた」である。外部コンサルタントなども、よくこの指標を用いる。それはつまり、鉄の三角形の内部で完結できたか、を問うている訳だ。

そして、逆に言うと、プロジェクト・マネージャーが首尾良く仕事を完遂するためには、スコープ・コスト・スケジュールのいずれについても、判断し実行する権限を持たなければならない。プロマネは結果に責任を持て、とか、プロマネは結果が全てだ、といった標語をよく耳にする。だが、もしも組織がプロマネにそうした仕事ぶりを期待するなら、それなりの権限を与える必要がある。

「ウチの会社ではプロマネは進捗管理係でしかない」とか、「○○業界のプロマネは、コスト管理の権限がない。発注権は、その上の部課長級が握っている」といった話を、ときどき耳にすることがある。それなりの理由があって、そうした慣習ができあがっているのかも知れない。だが、3辺に対する権限もなしに、3辺の結果責任だけを問われるのは、フェアなマネジメントのやり方ではないと、わたしには思えるのである。


<関連エントリ>
「わたしはなぜ、『プロジェクト管理』という言葉を使わないのか」 https://brevis.exblog.jp/26270824/ (2017-12-18)

by Tomoichi_Sato | 2018-02-25 15:45 | プロジェクト・マネジメント | Comments(0)

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

各位:

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

今回は、グローバルプロジェクトデザイン・ジャパン代表取締役の池大様に、プロジェクトデザインについてご講演いただきます。

企業が新しい製品をつくるにあたって、何の設計図も青写真も持たずに、いきなり実現に向けて走り出すことは稀でしょう。必ず最初にデザインという行為があるはずです。それでは、プロジェクトを開始する場合はどうでしょうか。たしかに今日、多くの組織では、WBS・スケジュール・予算等を含む「プロジェクト計画書」くらいは作ると思います。しかし、「適切なデザイン」という視点で、プロジェクトづくりに向かうケースは、まだ少ないのではないでしょうか。

デザインには、つねにサイエンスとアートの両方の要素があります。プロジェクト・マネジメントの分野でも「デザイン思考」が 注目を集めつつある今日、プロジェクトのデザインはいかなる行為であるべきか。この問題について、東大とMITのコラボレーションによる共同研究と研修プログラムのキーマンとなっている池様から、最新の潮流についてお話を伺います。ぜひご来聴ください。


<記>

■日時:2018年3月23日(金) 18:30~20:30

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

■講演タイトル:
「多様化、不確定の時代に対応するプロジェクトデザイン」

■概要:
 現在の社会は、複雑化、多様化、不確定に向かっています。その中でプロジェクトは関係者の多様性を受け入れ、変化に柔軟に対応する必要があります。今回は、東京大学とMITのコンソーシアムであるグローバル・チームワーク・ラボも採用しているプロジェクトデザインと言う考え方についてご紹介します。

■講師:グローバルプロジェクトデザイン・ジャパン 代表取締役  池大(いけ・だい)

■講師略歴:
 前職はアクセンチュアでシステム運用保守方法論およびツールの日本国内の責任者を務める。25年以上IT業界に従事し、多くのプロジェクトにSEおよびコンサルタント、PMとして参加。
 リスクマネジメント協会会員 Certified Risk Manager

 参考Url:

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

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

佐藤知一@日揮(株)

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

わたしはなぜ、「プロジェクト管理」という言葉を使わないのか

旅先ではいつも、その土地のものを食べるのが習慣だ。だが、ときおり、外国で日本料理屋に入ることもある。そして、たまに面食らうような体験もする。いつだったか、アメリカの日本料理屋で食事を頼んだら、まっさきに味噌汁だけが出てきた。ふつうの街にある店で、来客はアメリカ人が多い。どうやら彼らの概念では、味噌汁はスープだから(Miso soupとよばれる)、真っ先に出すのが当然だということらしい。味噌汁を飲み終えたら、メインのおかずとご飯が出てきて、妙な気分だった。

汁物をsoupと訳するのは、もちろん正しい訳だ。だが日本語で言う汁物と、英語のスープは微妙に違う。たとえば英語では、スープは食べる(eat)という。日本人で、「味噌汁を食べる」という人は滅多にいるまい。ふつうは飲む、を使う。そして、当たり前だが、ご飯と一緒にいただくものだ。

わたし達が言葉を翻訳をするときは、自国の文化にある似たものや、似た概念を対応づけている。だがスープと味噌汁に見るように、翻訳は近似でしかない。時には、けっこう違うことに注意が必要だ。

わたしは、このサイトでは原則として「管理」という言葉を使わないことにしている。拙著『世界を動かすプロジェクトマネジメントの教科書』でも書いたように、わたしのモットーの一つは、言葉を大切にする、である。だから、このサイト内では、二つの原則に従うことにしている。第一に、このサイト内では、用語はできるかぎり整合性・一貫性を持った使い方をする。第二に、そうはいっても、世間での使い方からあまりかけ離れないようにすること、の二つだ。

以前も書いたが、日本語の「管理」に対応する英単語は三つある。
  • マネジメント(management)
  • コントロール(control)
  • アドミニストレーション(administration)
なお日本語では、「管理・監督」と並べて使うことも多い。「監督」の英語は、supervision, superintendenceなどだ。

英語では、これらは別の概念である。これを全部、「管理」と一括りに呼んでしまうと、どれのことをいっているのか、分からなくなる。それでは、言葉を大切にしているとはいえない。

ちなみに英語の”manage"には、「荒馬を乗りこなす」といったような語感がある。自分の意思ではなかなか動かない相手を、なんとか自分の目的にあうよう、使いこなす感じだ。

これに対し、”control"は、自分の意思の通りに動く対象について行う、もっと精度の高い行為である。たとえば機械を制御する、自分の思った方向や速度に持って行く、というように。あるいは、個別にきちんとチェックし記録する、という風に。だから、品質管理はQuality controlだし、在庫管理はInventory control、原価管理はCost controである。空港における入国管理官の仕事はパスポート・コントロールであって、これを「パスポート・マネジメント」といったら変だ。入国窓口担当官が、個別の旅行客のパスポート発行に、すごく裁量を持っている感じになる。

そして"administration"は、執務環境を整えるとか、事務手続きをするイメージである。総務的・行政的・庶務的な仕事といってもいい。あるいは、銀行や役所などの窓口業務と言えるだろうか。よくsystem administration(略称シスアド)と呼ばれる仕事があるが、ユーザを登録削除したり記憶領域をバックアップしたりメンテナンスしたりというのが内容だ。ある米国人が”housekeeping type of work”といっていたが、とても感じが出ている。

では、「プロジェクト管理」とは、一体このうち、どれに相当するのか?

わたしの働く業界では、大規模なプロジェクトになると、プロマネ一人では面倒見切れなくなるため、プロマネをサポートするスタッフ達からなるPMT(Project Management Team)が必要になる。このPMTの中には、
  • Project Manager
  • Project Controller (Project Control Manager)
  • Project Administrator
という役職が、それぞれ存在する。

Project Manager(PM=プロマネ)はもちろん、プロジェクトの成果に対して最終的な判断を下し、その責任を負う人物である。これに対し、Project Control Manager(PCM)は、プロマネの立てた戦略を元に、プロジェクトの詳細な計画を立案し、WBS・スケジュール・予算配分などを決め、その計画通りに遂行が行われているかをチェックする。もしコストや進捗について、予実の差異が生じて問題だったら、是正策を考え、プロマネに進言する。つまりプロマネが将軍だとしたら、PCMは参謀役である。Project Adminは、それに比べて、プロジェクト・チームの配員や執務環境のケアをしたりする、まあ総務課長的な役割だ。

これらを全部、「プロジェクト管理」といってしまうと、どの職の仕事を指しているのかわからなくなってしまう。もちろん、小さな規模のプロジェクトでは、プロマネがControlもAdminの仕事も兼ねるし、もっと小規模なら設計などの実務も片手間でやるだろう。ただ、それはConrolやAdminの仕事の要素がなくなる、という意味ではない。

で、日本語の「管理」概念(あるいは語感)は、三つの英語を全て包含するかというと、そうではなくて、もう少し狭い。

たとえば、何か大事な物品をあずけて、「ちゃんと管理しておいてくれ」という場合、それはモノをちゃんと保管し、位置や状態を把握しておくことを意味する。つまり「管理」とは、誰かや何かを、自分の指示下に置いて、細かく動かすことである。言いかえれば、コントロール下におくイメージだ。

同じように、部下を管理する、とは、部下の一挙手一投足を指示し把握することを、通常、意味しがちだ。それは部下の自由度を奪うこと、ないし、上司の権力(強制力)を誇示することにも、通底している。こういう「管理」とは、上官の指示で突撃する兵卒に対して使う言葉のニュアンスをもっている。実際、少なからぬ組織では、軍隊式が「管理」の暗黙のモデルになっているようだ。

逆に、「管理」という言葉は、目上や対等な相手については、使わない。「ステークホルダー(たとえば顧客主や官庁)を管理しておけ」、とはあまり言うまい。この点、英語のManageとは違う(ご存じの通り、PMBOK Guide第5版からは、"Stakeholder Management"という章が付け加わった)。このように、日本語における管理概念は、とてもタテ社会的な序列感覚に裏打ちされている。したがって、『管理』という語に反発心を感じる人も、現場には多い。
e0058447_00064885.jpg
さらに言うと、日本語の「管理」は語義が広いとは言え、英語のManagementの全領域をカバーしきれていない。たとえば「マネジメント・サイクル」という概念がある。Plan-Do-Seeのサイクルを回すことである(PDCAのデミング・サイクルの方が日本の製造業ではポピュラーだが)。あるいは、計画・組織化・統率という、ファヨールのプロセスでもいい。

仕事をきちんと回すとは、このサイクルを動かすことと同じである。であるからには、
  • ろくな計画も立てずに行き当たりばったり獲物を追いかけたり
  • フォーメーションや役割分担も考えずに自分が真っ先に走り
  • 終わったことについて記録もとらずふりかえりの反省もしない
  • もちろん標準化も考えず、改善も変革もしない
…こんな「突撃型」上司を持った日には、下の人間はたまらない訳である。これではマネジメントをしているとは、言えない。なのに、マネジメントの仕事をきちんと教育せぬまま、『管理職」につけて、部下を管理する権力を与えてしまう組織を、しばしば見かける。

ちなみに、知的な職種でも、『管理』という言葉をカッコいい、と感じる人は多いらしい。昔、中小企業診断士の勉強をしていたとき、教科書や教科書に、管理・管理のオンパレードで驚いたことがある。経営基本管理・販売管理・仕入管理・財務管理・労務管理・生産管理・・あらゆる項目名に管理がついていた。それどころか、労務管理のテキストを読んでいたら、「労務管理の管理」という章があって、頭が痛くなった。なんだそれ? である。

その説明によると、労務管理という仕事について、計画→統率→評価のプロセスを回せ、と書いてある。これ、英語ならHuman resourceに関する仕事のManagement cycleを回せ、と表現するだろう。だが、この先生の頭の中では、「労務管理」とは労働者への指示命令のことだけを指すらしい。だから「労務管理」の管理、などという、屋上屋を架す用語が出てくるのだ。こういうのは管理中毒と言うべきだろう。

だが、もっとこまるのは、『管理過剰症候群』という病気だ。この病気にかかった人や組織は、何かうまくないことが起きると、「管理を強化しろ」という。業績が不振になったり、プロジェクトがうまくいかなかったりすると、上位職の管理者が、事細かにプロマネや現場に指示を出し、報告を要求する。そして、ありとあらゆる判断に、承認手続きを義務づけ、現場の裁量を奪う。事細かに目標値や制約条件を設定し、押しつける。これによって、現場の暴走を止め、プロマネの無能力を補正するつもりなのだ。だが、結果としてプロマネは報告義務に追われ、落ち着いて考える時間を持てなくなりがちだ。

たいていの場合、トラブルに陥ったプロマネに対して必要なのは管理ではなく、支援であろう。プロマネの悩みとは、いつも相場が決まっている。それは、お金がないか、人が足りない、なのだ。だが部門の壁や、プロジェクト独立採算制の制約にはばまれて、こまっている。だから、会社の側は、そこをどうにかしてやる必要があるのではないか。仮にもし、それでもプロマネが無能力だったなら、それはそもそも、任命した側に責任があることになる。

マネジメントとは、適切な裁量を持たないとできないことを、管理過剰症候群の人達は忘れている。裁量とはすなわち、(わたしの好きな用語で言うと)『自由度』だ。いいかえると、自分で決められる、ということ、自分が自分自身の主人であることである。これが自由の意味だ。

適切な自由度を与えることで、はじめて現場の様々な環境変化に、自在に適応できるようになる。日本語の「管理」には、あいにく、この「適切な自由度」の感覚が足りない。だが、自由度を与えないと、現場の者に責任感が生まれない。責任感のある仕事をしてもらいたかったら、「管理」するだけでは不十分である。そうでなければ、どうして創意などというものが生まれるだろうか。

名著「自由を子どもに」 を書いた小児科医の松田道雄は、次のような意味のことを述べている。保育や教育という仕事は、いつの間にか、子どもの「管理」になってしまっている。子どもたちに問題が生じると、もっと管理を強化しろと、親も社会もいう。それほどまでに、今の大人は管理に自信を持っているのだ。だが、そのこと自体が、まさに子ども達を不幸にしているのに気がつかないのだ、と。

松田道雄がこの本を書いたのは、今から44年前の1973年だった。わたし達はそれ以来、少しは進歩しているのだろうか。もし仕事に責任感と創意を求めたかったら、まず「管理」を見直すことから、はじめるべきではないだろうか?


<関連エントリ>
 →「マネジメントと管理はどこが違うか」 http://brevis.exblog.jp/10625203/(2009-07-15)

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

プロジェクト&プログラム・アナリシス研究部会」(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(4)

ダイレクト・ガントチャート方式の問題点 〜 やはり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)