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

プロジェクト・マネジメントは組織としての能力である

プロジェクト・マネジメントという言葉は、この10年間でずいぶん普及した。それと同時に、誤認識や誤解もある意味で増えたと思う。そのひとつが、リーダーシップとの混同だろう。そもそも会社によっては、そもそもプロマネと呼ばずにプロジェクト・リーダーと呼ぶところもある(IT系企業に多いような気がする)。リーダーとは課長ないし係長相当の役職を示しているに過ぎないのだが、「リーダー」という言葉からリーダーシップを連想するのは、ほんのひとまたぎの距離だ。

ここから、プロジェクトの失敗はリーダーシップの欠如に原因する、という判断が生まれてくる。そうなると、“じゃあ、有能なリーダーをもってくれば解決する”、あるいは“リーダーシップの強い人物を任命すれば成功する”との短絡した結論が出てくる。リーダーシップ論だけではプロジェクトの失敗は救えない、という話は前にも書いたので、ここでは繰り返さないが(「プロジェクト・マネジメントにリーダーシップ論は要らない 2007/07/09」参照)、日本のIT産業には、なんだか英雄待望論みたいな気分が漂っているらしい。

もともと、「マネジメント」managementという概念自体が、日本人にとってわかりにくい。それなのに、“わかりにくい”という事態が意識されていないので、もっと始末に終えないのだ。たとえば「サプライチェーン」という言葉をだったら、対応する日本語がないから、“何じゃそりゃ?”とたいていの人間は思う。分かりにくさが意識されるから、誰しもよく理解しようと注意が働く。でも、「マネジメント」は“管理”とか“経営”という日本語が堂々と(?)ひかえていて、読めば分かったような気がする。そして、管理者の「人間力」の問題なのだな、などと思われてしまう。

実際は、プロジェクト・マネジメントの能力は、マネージャー個人だけの能力ではなくて、組織としての能力である。この点が理解されないので、議論がいつも空回りしてしまうのだ。プロジェクト・マネジメント能力には、上位構造・中位構造・下部構造の三階層がある。そしてこれらはピラミッド状になっている。頂点に位置するのは、PM個人の能力であり、具体的にはハード・スキルとソフト・スキルからなっている。

しかし、上位構造としてのPM個人の能力は、じつは中位構造によって支えられている。中位構造は、「プロジェクト遂行標準・手順書」「プロジェクト・マネジメント・ソフトウェア(ツール)」「過去の実績データベース」の3要素からなっている。そして、これら中位構造は、下部構造としての「組織体制・権限関係」の上に成り立っているのだ。図にすると、次のような関係である。

いいかえると、プロジェクトに向いた適切な組織体制や権限委譲の仕組みがないと、プロジェクト標準やPMソフトや実績データが構築されないし、こうした道具立てがなければ、いかに優秀なプロマネといえど、実力を発揮しようがないのだ。優秀なプロマネを社外から引き抜いてくればOK、あるいは最新機能のPMソフトウェアを買ってくればOK、なんて簡単な話ではない。ここでいう中位構造・下部構造とはすなわち、PMBOK Guideの「組織のプロセス資産」の中身なのである。

プロジェクトを中心としたビジネスを成長させる原動力は、最近の経営学の流行の言葉で言えば『能力構築競争』である。そして、組織の能力をはかるベンチマークが必要なのであろう。この種のものとしては、PMIの開発したOPM3があるが、これはちょっと大掛かりすぎる。CMMIはIT業界向けだが少し方向性が違う。もう少し簡便な、かつ業界をまたいで使えるものが必要だと私は考えている。こうしたモノサシがポピュラーになれば、なにせ横並びがお好きなこの国のことだから、あっという間に広がるだろうに。
e0058447_2254354.gif
by Tomoichi_Sato | 2008-06-02 22:54 | プロジェクト・マネジメント | Comments(0)

プロジェクト・マネジメントとはどういう仕事か

もうだいぶん前のことになるが、大学の後輩にあたる留学生から、会社訪問の希望があった。彼は東南アジアの出身で、良家の子弟である。いずれは国に帰って立派な職に就くのだろうが、しばらく日本企業でビジネス経験を積みたい、との希望らしい。ついては、私の勤務先の国際プロジェクト部門で働きたいという。

私の勤務先はエンジニアリング会社で、プロジェクト・マネジメントを専門に受け持つ部門がある(念のため書いておくがPMOとは別である)。その部門には、プロジェクト・マネージャー達や、プロマネの卵であるプロジェクト・エンジニア達が配属されており、国内外のプロジェクトを切り盛りしている。彼はそこで少しの間、仕事を学びたいというのだ。

で、どれくらいの期間を考えているの? そうたずねたら、彼は「1年間です」という。私はため息をついて、答えた。「1年では短すぎる。5年とはいわないけれど、せめて3年くらい働いてくれないと、君も仕事を覚えられないし、会社の側も給与に応じたアウトプットを期待できないよ。」そう説明したが、彼は1年という希望をどうしても譲らない。20代前半の人間にとって、1年は永遠の半分くらい長い時間に思えるのだろうか。結局その話はお流れになった。

電話を切って、つくづく思った。“海外プロジェクトのマネジメント”という仕事を、彼はずいぶんかっこいい仕事だと想像しているのだろうな。私は今、この文章をまさに海外プロジェクト現場の宿舎で書いているが、実際のそれは、まさに交通整理と雑用の集積だ。ひどい渋滞の交差点の真ん中で、一日中、汗をかきかき腕を振り回す警官を見て、彼は“大勢のドライバーたちを指揮・指導するかっこいい仕事”と思うだろうか。

乗客や荷物を運ぶドライバー達は、たしかに何らかの付加価値創造に貢献している。しかし、コーディネーションを任務とする警官自身は、何物も作り出さないのだ。接触事故を処理し口げんかを仲裁し、ひどいときには自分で荷物を担いで運ぶ。本署にすわって若い交通警官達を采配している部長は、たしかにかっこいいマネージャーに見えるかもしれないが、仕事の本質は同じである。

私はプロジェクト・マネジメントという仕事を矮小化しすぎているだろうか? IT業界では、国際標準としてPMBOK Guide (R)の勉強と摂取が盛んだ。今から10年前には、「ぼくはプロジェクト・マネージャーなんかにされるのが嫌で、前の会社を辞めました。」という人がいたのだから、まあ隔世の感かもしれない。その人はシステム技術屋としての本分を捨てて、そんな雑用係にされるのはまっぴらごめん、と言っていたのだ。

ところで、この人の言う「雑用」と、わたしのいう「雑用」では、意味が少し違うことにお気づきだろうか? わたしは、顧客への納品物製作という直接作業(価値創造)につながらないものを雑用と呼んでいるのに対し、この人は、自分の技術的興味や満足につながらない仕事を雑用と呼んだのだ。この人にとって、データベース設計書作成やコーディングは楽しい仕事で、マニュアル作りやテストや顧客への報告は雑用だ。しかし、わたしの定義では、コーディングとマニュアル制作こそが直接作業であって、設計書などは雑用なのだ。ただ、その設計書はコーディングやデバッグの生産性を上げるから、雑用でも必要なのである。

PMPの有資格者が2万人を超えようという今日では、プロジェクト・マネージャーは「かっこいい仕事」にいつの間にか昇格した。交通警官などとはとんでもない。むしろオーケストラの指揮者か、映画の監督にでもたとえられる職種と思われているようだ。

ところが、その映画の世界には、『助監督』という職種があって、これがまさに雑用係なのだ。クルーのロケの切符を手配したり、宿舎を予約したり、俳優たちの用事をきいたり、とにかく何でも屋である。多くの映画監督はこれを経験しており、キャリアパスの一種になっている。

助監督の任務の中には、会社で言えば「総務」みたいな種類の仕事がある。配車や掃除や機材運びなどの雑用である。この種の仕事を、『アドミニストレーション』とよぶ。

また、助監督の仕事の中には、スタッフ間の都合や意見を調整したり、主張がかみ合わない場合は“とりあえずA案で進めますけど、天候がダメな場合どうするかは任せてください”みたいに判断をあずかったりする役割がある。この種の仕事を、『コーディネーション』と呼ぶ。

そして、撮影予定をスケジューリングしたり予算と出費の勘定をしたりといった、表やリストで追いかけるのに適した雑用がある。これを『コントロール』と呼ぶ。

プロジェクト・マネージャーの仕事とは、すなわち『アドミニストレーション』・『コーディネーション』・『コントロール』の三つの領域を包含した、采配の仕事である。とくに『コントロール』は数字化しやすいので、PERT/CMPだのEVMSだのといった技術手法が発達している。これらは一般に“管理技術”とよばれるものだ。データベース設計だとか応力計算といった“固有技術”とは別の領域である。「技術的なこと以外は雑用」と考えるエンジニアは、じつは管理技術というものの存在を理解していないのである。

とはいえ、プロジェクトは人間の集団がすすめるものであって、プロマネの仕事の中核には“人を動かす”という行為がある。これは技術論だけでは、なかなかうまくいかない。そこで、もっと属人的な『ソフトスキル』が必要となるのだ。

プロジェクト・マネジメントとは、こういう仕事である。しかも映画とは違って、世間に名前の出るケースはまずまれだ。それでも、なかなか面白い。かの留学生君が実際にやってみたら、どういう感想をもっただろうかと、ときどき考えることがある。あなたはやってみたいですか? 
by Tomoichi_Sato | 2008-04-22 23:29 | プロジェクト・マネジメント | Comments(0)

プロジェクト・マネジメントの世界は動いている その3

先週は東京でPM関連の大きなイベントが二つあった。10・11日は「国際プロジェクト&プログラムマネジメント・シンポジウム」 が江戸川タウンホールで開かれ、また14・15日にはプロジェクトマネジメント学会春季大会 が白山の東洋大学キャンパスで開催された。いずれも数百人の参加者を集め、盛況だ。PMに関する関心が世間で高まっていることは明らかなようだ。ちなみに私自身はPM学会で「Convertible LSTK契約によるプロジェクト・リスクの緩和」という研究発表を行った。

日本PM学会は、今年9月にアラスカのアンカレッジで開催される予定の国際大会ProMAC 2008を応援しており、参加をさかんに呼びかけている。ProMACは2年ごとに開かれるアジア/パシフィックの大会で、私自身も、2004年の東京、2006年のシドニーと2回にわたり、研究発表を行った。今回のPM学会の懇親会にも、アラスカからゲストが見えて、日本人に海外に目を向けてほしいと呼びかけていた。

しかし国際色という意味では、「国際プロジェクト&プログラムマネジメント・シンポジウム」(IP&PMS)の方が上をいっている。この大会、講演者の半分近くが外国人、ホームページも講演プログラムも予稿集も全て英語である。むろん、何も別に英語だから偉いと言っているのではない(念のため)。参加者の顔ぶれのバラエティから、必然的にこうなったということである。主催は日本プロジェクトマネジメント協会(PMAJ)だ。

PM学会の発表は、どちらかといえば実務に根ざしたプロジェクト運営の改善研究が多い。他方、IP&PMシンポジウムはハイレベルな戦略論ないし経営論に近い視点の講演が目立つ。前者はプロジェクトの現実に悩むIT業界系参加者が中心であるのに対し、後者はエンジニアリング業界なども加わり、プロジェクト&プログラムという上位の視点をメインに据える違いが現れているようだ。私には、どちらもとても面白かった

とくに興味深かったのは、IP&PMシンポジウムの最後に行われたパネル・ディスカッションだ。壇上にはなんとPMI・IPMA・PMAJ・AIPMの代表者/元代表者が顔をそろえて議論を行ったのだ。念のため書いておくと、国際的PM団体=PMI、国際PM標準=PMBOK Guideだけ、と信じている人が案外多いが、これは“アメリカ=世界”と思いこみがちな日本の視点の狭さを表しているに過ぎない。

ところで、「なんで世界に国際プロジェクトマネジメント団体がいくつもあるんだよ? PMの理論や技法は世界共通だろ? 資格だって、なんで国ごとに作る必要があるんだ。」と疑問に思われる方もいるだろう。当然の疑問だ。この狭い日本にも、PM学会とPM協会とPMI東京支部が3つひしめき合っている。この議論を、パネルディスカッションの司会者Hugh Woodward(米国人・元PMI会長)があえて、"burning question"として提起したから面白い。

Adesh Jain(インド人・初めての非欧州人のIPMA理事長)は、「医師やエンジニアのように、異なる資格の間での対応付けmappingをするべきだろう」と答える。これはある意味で順当な意見だ。Lynn Crawford(豪Bond大学教授・AIPM理事)の答えは、「競争があるのは健全だ。何事も独占はよくない」というものだった。たしかに、互いに切磋し刺激しあって良い標準を作ればいいとの見方にも一理ある。

PMAJの田中理事長は、「PMIメンバーの80%はIT業界だが、IPMAは非IT業界が80%を占めている。一口にプロジェクトといっても、その性質や文化の違いは無視し得ない」という考えだ(ちなみに、今回これだけそうそうたるメンバーを集められたのは、PMAJ田中理事長の力量だろう)。

しかし、一番共感したのは、Ralf Muller(スウェーデンUmea大学教授)のコメントで、「資格というのはそれを必要とするマーケットのニーズで動かされるものなのだ」というものだ。言いかえれば、供給者側がそれをコントロールしようと考えるのがおかしいので、一番世の中に必要とされ受け入れられる資格が、次第に生き残り発展していくだろう、という見方である。これはいかにもヨーロッパ人らしい、大人の見方だな、と思う。同時に、以前『誰のための資格?』『資格はユーザーのためにある 』(「コンサルタントの日誌から」2003/01/13, 21)に私が書いた意見とも共鳴するからだ。

今後複数の団体がどのようになっていくのかは、分からない。しかし、世の中のニーズが減っていくことは、もはやあり得ないと思う。プロジェクトマネジメントは初期の啓蒙期を過ぎて、すでに普及発展期に入っているのだ。それが今回、私が一番感じたことだった。単一プロジェクトだけでなく、複数プロジェクトをハーモナイズして動かしていくマネジメントも、ますます重要になりつつある。こうした国際大会に参加するたびに、ますます目の離せない分野だと痛感するのである。
by Tomoichi_Sato | 2008-03-17 21:54 | プロジェクト・マネジメント | Comments(0)

良いWBS、わるいWBS

先日、プロジェクトマネージャ合格論文集 改訂版(齋藤登志勝・編、リックテレコム刊)の読者の方からご質問があった。内容は、小生の執筆した論文で「・・・WBSを成果物(サブモジュール)中心ではなくプロセス中心に構成した・・・」と記載しているが、WBSの構成を変更した意図がわからない。WBSの構成変更のメリットは何か? というご質問である。

これはとても良い質問だと思うので、ここに取り上げさせていただこう。ここには、WBS(Work Breakdown Structure)構築の中心課題があるからだ。最近WBSという用語・概念が業種の枠を超えて広まったのは、とても良いことだと思っている。しかし、その結果(?)、奇妙なWBS、不思議なワークパッケージを見かける機会もでてきたように感じる。この論文では、その点をやんわり取り上げたつもりだった。

WBSは、誰でも作れる。プロジェクトを種々の作業の階層構造に展開することは、ちょっと頭が働く人間ならば、可能である。しかし、時計を部品に分解していくのとちがって、展開のやり方には、いろいろなアプローチがありううる。つまり良いWBSも、わるいWBSもありうるのだ。後者を作ってしまうと、その後のプロジェクト・コントロールが混乱しがちになる。

米国PMIは"Practice Standard for Work Breakdown Structures"というモノグラフを出している(2001年刊)。本文がたった18頁で、付録が58頁もある、珍しい本だ。本文では、WBSの説明として、PMBOK Guideを引用して、"A deliverable-oriented grouping of project elements"だと書いている。このまま訳すと、『プロジェクト要素の、成果物指向によるまとめ上げ』ということになる(ちなみにPMBOK Guide第3版では"A deliverable-oriented hierarchical decomposition of work")。

前の「WBSのつくり方」にも述べたように、WBSへの分解は大別して、成果物中心と、プロセス中心の方法がある。両者は一長一短あり、成果物中心は“もれなく・重複なく”ワークを数え上げるのには適している(いわゆるMECEな展開だ)。後者はWBSのマスタを作りやすいという長所がある。そして、PMIの本は前者を推薦しているように見える。しかし、この本の付録にあげられた、数々のプロジェクトのWBS例では、必ずしも、いや、ほとんどがそうなっていない。たとえばAppendix OにはSoftware Implementationの事例がついているが、Level 1をリストアップすると、
1 Project Management
2 Product Requirements
3 Detail Software Design
4 System Construction
5 Integration & Test
という具合だ。私が本の論文に書いた事例とよく似ている。でも、いったい何故こうなのか?

じつは、このモノグラフの本文第4章には、WBS作成上の留意点がいろいろと説明されている。その一つに、「WBSが作業間のロジカルな依存関係を十分規定していること」という要件がある(ロジカルな依存関係が何かについては、『ロジック・ネットワーク・スケジュールとは何か』を参照してほしい)。また、「すべての作業は、見積・配員・スケジュール・予算化が行われ、コントロールされなければならない」とも書かれている。WBSを作成する目的はプロジェクト・スコープを、コントロール可能な作業要素に分解することにある。このとき、WBSはあくまでも、枝葉だけではなく木や森が見えるようになっていなければならないことを、この節は告げている。

これはすなわち、コストやスケジュールの進捗実績情報を集計していくときに、WBSの構造にしたがってロールアップされるということだ。だとしたら、プロマネであるあなたは、基本設計→詳細設計→実装、という方向で進捗やコストを見たいのか。あるいは、画面モジュールA・画面モジュールB・帳票モジュールC、という風に見たいのか、ということに帰結してくる。

もしも大規模なシステムを開発していたら、基本設計の全体性integrityが固まらないうちに、いくつかのモジュールの詳細設計に進むことなど、普通は許さない。そんなことをしたら、あとで設計の手戻りの危険性が高くなる。だから、プロセス中心のWBSが望ましいのだ。これが、パッケージソフトのマイナー・バージョンアップ程度の仕事なら、ばらばらにモジュールに手を入れてもかまわないだろう。だから、成果物中心WBSでもまったく問題ない。

ちなみに余談だが、中国のオフショア開発で私が経験した事例では、個人がそれぞれ決められたスコープの縄張りの中で(他人は一切お構いなしに)猛スピードで突っ走っていく仕事のやり方だった。これがその会社だけの慣習なのか、あるいは中国全体に共通するマネジメント・スタイルなのか、即断は避けたい。しかし、このような状況では、個人別にモジュールを渡し個人単位にWBSを切って進捗を稼いでいたら、統合テストがめちゃくちゃになるのは目に見えている。

PMIのモノグラフの付録は、実務家が集まってワークショップ形式で作り上げたものだ。だから、おのずからコントロールの方向性が定まっているのだろう。それは、たまたまかもしれないが、プロセス指向がメインだった。とくに、目に見えないものを作り上げるプロジェクトでは、最初はなかなか航空機の部品表のように構造は決められない。したがってプロセス指向にならざるをえないのである。WBSの良しあしが、プロジェクトを左右する--ここが、プロジェクトマネジメントの難しさでもあり面白さでもあるのだ。

(末筆ながら、本参考書の編著者である齋藤登志勝先生は本年11月、若干42歳の若さで急逝された。人柄・能力・経験、いずれの点でも惜しまれてあまりある人材だった。先生のご冥福をお祈りしたい)
by Tomoichi_Sato | 2007-12-12 22:51 | プロジェクト・マネジメント | Comments(3)

情報の経済的ロットサイズを考える

部品材料の購買においては、経済的ロットサイズの理論があって、買う量がそれより多すぎても少なすぎても、余計にコストがかかることを、前回書いた(2007/08/21)。この事情は、社内の製造工程などにも同じように当てはまる。最終組立などは一個流しが理想といわれているが、材料加工・塗装やチップマウントなど、技術的制約からどうしてもロット加工の方がやりやすい工程が存在するものである。こうした工程では、ロットサイズを決める際に、Wilsonの公式から割り出した経済的ロットサイズ(EOQ)をたよりに計算すると効果的だと考えられている。

社内加工の場合には、購買発注をかけるたびにかかる手数のコストのかわりに、段取り替えのセットアップ・コストをつかって計算する。ロットをあまり小さくしすぎると、段取り時間ばかりが増えて正味作業率が下がることになる。逆にロットを大きくしすぎると、仕掛り在庫量が増えてしまう。

ところで、この考え方をさらに敷衍して、社内を順に流れる情報についても適用できないだろうか、と思うことがある。それは、プロジェクトにおいて機能組織の間を流れていく情報の、経済的ロットサイズである。

たとえば、私にとって一番身近な、エンジニアリング系のプロジェクトを例にとってみよう。こうしたプロジェクトでは通常、最上流工程で機能設計を行い、ついで運用設計も加味して基本設計図面に落としこむ。後工程の部門は、これを受け取って構造設計・制御設計・電気設計・・などに展開し、部品表(BOM)と仕様書を作成する。購買部門はさらにそれを受け取って、引き合い書類を作成し、また生産技術/工務部門は加工手順計画を立案して労務手配に動く、といった風になる。つまり、情報が上流工程部門から下流工程部門へと、順に加工されて流れていくのである。

このとき、問題となるのは、どれだけのかたまりで情報を下流部門に流すか、である。ここのさじ加減が、結構適当に決められる場合も多い。いうまでもないが、仕事というのはある程度の分量がまとまらないと、結果を公式に発信しにくいものだ。また受け取る側も、ある程度まとまらない限り、手をつける気がしないものである。こうしたことは単なる感情論だと思われがちだが、そうではない。知識労働においては、頭を切り換える時間(頭を次のことに向けて準備し集中するための時間)は案外、大きい。つまり思考のロット切替には見えないコストが無視できないほどかかっているのだ。このため、情報ロットは大きめになりがちである。

では、そうした切替ロスのコストを承知の上で、情報のロットサイズを意図して小さくしたら、何か効果がえられるだろうか。工場の部品の場合は、仕掛り在庫が減るという、目に見えるメリットがある。しかし、情報の場合、そもそも在庫という概念がマッチしない。すると、利点はないのだろうか?

そんなことはない。むしろ私は、情報のロットサイズは小さめにした方が効果が現れやすいと考えられる。どこにその効果が出るかというと、プロジェクト全体の「リードタイム短縮」である。

IEの工程分析をやったことのある方ならおわかりだろうが、そもそもロット生産における最大の問題点は、「ロット待ち時間」の無駄の発生である。ロット全数について、ある仕事が完了しないと、次の工程に流れないような工場内物流設計の場合、ロットを構成する個別の部品にとっては、仲間がそろうのを待っている時間が一番多くなるのだ。情報のロットサイズにも、この問題がつきまとってしまう。逆に言うと、情報の受け渡しの単位を小さくすれば、それだけ全体のリードタイムは短縮される。

これは、プロジェクト・スケジューリングにおける「ファーストトラッキング」の技法にも通じる。ファースト・トラッキングとは、2つのタスク間に“先行が完了→後続が開始”という順序依存関係(F-S関係)がある場合に、それを“先行が開始→後続もつづいて開始”という並列関係(S-S関係)に変えてしまう技法である(「StartとEnd -- タスク間の依存関係」『プロジェクト・マネジメント ワンポイント講義』参照)。つまり、上流からの情報が全部そろうのを待たずに、少しずつ受け取ったはしから処理を開始するやり方を意味している。

しかし、だからといって、情報のロットサイズをむやみと小さくすればいいというものでもない。たとえば、BOM(部品表)データを、できた端から毎日1個づつ流されたのでは、下流部門はたまったものではない。加工計画や購買手配は、ある程度の量と全体像が見えてから進めないと、かえって非効率になってしまうからだ。

そこで、一番ちょうど良いロットサイズがどこかにあるはずだ、という考えに至るのである。むろん、Wilsonの公式はそのままでは適用できまい。もう少し別の数学的道具立てが必要となってくるのである。しかし、私の見るところ、設計段階でコンピュータ利用が進んできているのにもかかわらず、普通に行われている情報のロットサイズは、過去の紙の時代の習慣を踏襲して、大きすぎる状態だと感じる。どのような単位での流し方が適当なのか、もう一度熟考すべき問題である。
by Tomoichi_Sato | 2007-08-29 23:42 | プロジェクト・マネジメント | Comments(0)

プロジェクト・マネジメントにリーダーシップ論は要らない

昨年、国内最大手のシステム・インテグレーターのPMOの方から依頼されて、そこの社内PMセミナーで講演する機会があった。どういう話をしようか、少し迷ったのだが、その冒頭で、私はこう切りだした。「プロマネを選ぶときに、リーダーシップの有無を最初に問題にするのはおかしいと思います。少なくとも、私の業界ではそういうことは議論になりません。」

ご承知の通り、私はエンジニアリング会社に勤務して、プラント系のプロジェクトとSI系のプロジェクトの両方を経験してきた。二足の草鞋をはき、両者を子細に比べてみて気づいたのは、技術的な要素が大きくちがうにもかかわらず、プロジェクト遂行のストラクチャーがずいぶん似ているということだ。いずれも受託型のビジネスである。スコープと納期とコストが主要なコントロール対象である。元請け-下請け構造で複数業者が関わっている。個別受注・個別設計である(とはいえ、客先の要件はじつは業種によってかなり共通している)。納品物は生産財であって、客先はそれを受け取って自分のビジネスを運転しなければならない・・・

それにもかかわらず、エンジ業界とSI業界の人々のプロジェクト・マネジメント論議は、驚くほどちがう。その違いの一つが、リーダーシップ論だと思う。リーダーの資質とは何か。それは育成できるのか。PMOはそれをどう支援すべきか。こうした論点がくりかえしトピックに現れてくる。

しかし、ちょっと考えてほしい。あなたが航空会社を選ぶとき、機長のリーダーシップを気にするだろうか。「ご安心ください。当社のジャンボ・ジェット機のパイロットは、リーダーシップに優れた統率力ある人材を選んでいます。」などと広告されていたら、なんだかかえって不安にならないだろうか?

ジャンボ・ジェット機の操縦が易しい仕事だとは、決して思わない。しかし、リーダーシップだけで飛行機が飛ぶわけではない。われわれがパイロットに期待するのは、まず専門的教育を受けていること、ついで飛行実務経験だろう。機長のリーダーシップなどというものは、何か非常事態が起こった際に、迅速・的確かつ勇気ある決断ができるかどうかが問われるときのみ、真に重要になる。だが私はそんな事態は、あまり頻繁に予想したくないのだ。

同じようなことが、プロジェクトにも言える。少し前になるが、IT分野の雑誌にPM特集があって、その見出しの一つが「プロの火消し人集団」だった。だが、果たしてプロの火消し屋が何人もいるような組織は正常だろうか? あなたが工場を見学に行ったとき、「ご安心ください。わが工場には、専任の消防隊が3班もおります。」と胸を張られたらかえって心配になるにちがいない。あなたはその職場で働きたいと思うだろうか?

念のためにいっておくが、私は別にプロジェクト・マネージャーにリーダーシップが全く不要だ、などと主張しているのではない。それが真っ先に議論されるのはおかしい、と言っているのだ。リーダーシップは、いざというときのために必要だ。そして、不思議なことにある一定規模以上のプロジェクトでは、かならずそういう危機が訪れる。私の知っているベテランのプロマネは、「さすがの俺も、今回はもうダメか! と思うことが必ず2回来る。」と言っていた。リーダーシップは、そうした危機を乗り越えるためには、たしかに必要である。だが、危機を乗り越えるときは、プロマネだけでなく、プロジェクト・スポンサーやエンジニアリング・マネージャー、コントローラー達が一丸となって解決に動いていくものだ。プロマネ一人が背負うべきものではない。

それでは、なぜリーダーシップ論がSI業界では優先されがちか。それは、SIプロジェクトは『失敗率が高い』という信念、ないし神話があるからではないか。失敗確率が高ければ、たしかにリーダーシップの心配も高まろう。大西洋をはじめて横断する機長には、たしかに操縦技術以上に、強いリーダーシップがいるだろう(もっともリンドバーグには部下の副操縦士はいなかったのだから、誰に対するリーダーシップかと問われると答えられまい)。

プロジェクト・マネジメント技術とは畢竟、プロジェクトのリスク確率との闘いの技術である。PMBOK Guideのプロジェクトの定義(A project is a temporary endeavor undertaken to create a unique product or service)に、なぜ『リスク』の語が入っていないのか、私は常々疑問に思っている。もしあなたが、ジャンボ・ジェットの運行をプロジェクトだと思えないとしたら(上記の定義にはぴったり合っている)、それは、そこに失敗のリスクをほとんど感じないからだ。だから、プロジェクトの定義には「リスクをともなう」という一語が追加されなければならない。

と同時に、ビジネスの技術というものは、プロジェクトのリスクを低減して、だれもそれがプロジェクトだと感じないようにしむけていくべき存在だ。それが、プロジェクト・マネジメントのハード・スキルと呼ばれるものなのである。
by Tomoichi_Sato | 2007-07-09 22:47 | プロジェクト・マネジメント | Comments(0)

プロマネのハードスキルとソフトスキル

「ハードスキル」と「ソフトスキル」という用語をはじめてきいたのは、2003年のことだったと思う。米国で参加した会議におけるPMコンサルタントの講演で、この区別を知った。プロジェクト・マネジメントに携わる人間のスキルを、「ハード」と「ソフト」に二分する思考方法は、そのときまで私の中には無かった。

米国の思考法は、つくづく「分けていく」思考法だな、と思う。分類し、分析し、分業する。全体を部分に細分化して、それぞれの特徴・特性を多面的に把握する。そして目的合理性の見地から、それらを使い分け、組み合わせていく。だから道具立ては専門分化したツールの集合体になる。PMBOK Guideの構成を思い出してほしい。まるでゴルフバッグに入ったクラブの束みたいだ。あるいはナイフとフォークを何本も並べるフルコースの食事のようだ。(これに対し日本人は最初から最後まで一膳の箸だけですませる。最小限の道具だけで何でもできるよう、自分の側があらゆるスキルを駆使するのが日本のスタイルだろう)

さて、そのスキルだが、プロジェクト・マネジメントの理論や手法やツールなど、形式化された知識を使いこなせる能力、これを「ハードスキル」とよぶ。一方、問題解決や交渉やモチベーションアップなど、非定型な(主に対人的な)技能を「ソフトスキル」という。

当然ながら、良いプロジェクト・マネージャーには、この双方のスキルが必要である。では、これらはどう習得すべきか? 習得の面からいうと、両者は全く異なる。ハードスキルは本や座学で学べる。しかしソフトスキルは、持って生まれたセンスを経験の蓄積の中でみがいていくしかない。前者はコンピュータなどの仕組みに乗せやすいが、後者はなかなか仕組みにのせにくい、といってもいい。

と、こう書いていくと、“だからソフトスキルを充実させる方が重要な課題で・・”とつながりそうに思えるかもしれない。しかし、私は今のところ逆だと考えている。ソフトスキルは、部下を持ち中間管理職の立場になったら、誰でもその必要性に気づく。プロジェクト的職種だろうが、そうでなかろうが、あまり関係がない。だから世の中の本屋には、リーダーシップ論や人心掌握術や処世訓があふれかえっているのだ。だれもがこの問題について悩んでいる。つまり、だれもがこの問題を認識している訳だ。

ところが、プロジェクト・マネジメントのハードスキルに関しては、その存在すら知らない管理者がいまだに圧倒的に多い。問題を認識していなければ、改善の対策などあるわけがない。さすがにIT系企業ではCMMiだとかPMBOK GuideだとかITILだとか、毎年あの手この手でおどかされているから、うすうすその存在については気がついている。しかし、それ以外の業種・職種ではどうだろうか。製造・生産技術・研究開発・マーケティング・経営企画・サービス・・・あらゆる分野で非定型な「プロジェクト」は存在する。中には企業の短期・中期の命運を左右する大きなプロジェクトもある。にもかかわらず、こうした世界のプロマネたちは、「プロジェクト管理に理論がある」という基本的なことさえ知らずに仕事をしているかもしれないのだ。まるで、海図も測量器具も知らずに航海に出る船長のように。怖ろしいではないか。

たとえば、12ヶ月スケジュールのプロジェクトがあったとしよう。今、開始してから3ヶ月たった。当初の計画では、現時点までに600万円の出費が予想されていた。ところで、実際の出費は500万円だった。このとき、「このプロジェクトはコストを予定内におさえているから安心だな」とプロマネが判断したら・・それは決定的に間違っている。プロジェクトのコスト管理は、定常業務と同じような予実対比で見てはいけない。これがアーンドバリュー分析(EVMS)の教えである。

EVMSに限らず、WBSコード、アロウアンス、クリティカル・パス、トータルフロート、TRM、マイルストーン、ドキュメント・インデックス・・・これらプロジェクト管理の基本的な理論や手法はみな、ハードスキルの範囲だ(とはいえ、適当に選び出したこれら用語がすべてカタカナの外来語であるということ自体が、この国のビジネス文化を象徴しているなあ)。

幸い、ハードスキルは短期間で一通りの知識を学べる。学んだ知識を実践力にかえていくためには繰り返し練習が必要だが、その機会は実務にいくらでもころがっている。だからこちらの方が優先課題だ、と私は言うのである。そのためにはまず、プロマネ、ならびにその上にいる上級管理職が、ハードスキルの存在を知らなければならない。

私の知っている米国人は長らく金融関係でシステム開発にたずさわっていたが、中年になってからこうした理論を学び、「あと10年早くこれを学んでいたら、あれほど苦労せずにすんだのに!」と痛感したという。彼はのちに、独立してPMコンサルタントとなり、こうした知識の普及活動に従事することで、大勢の人が自分と同じような無駄な苦労を避けられるように貢献している。

前回、私は『だれのための生産管理?』(「タイム・コンサルタントの日誌から」2007/05/06)で、人間不在の管理論を強く非難した。しかし、今回はまったく逆のことをあえて書いている。人間論を排除したPM論が必要なのだ。リーダーシップ論も人格論も部下の掌握術も、いらない。まず、ハードスキルを学ぶべし!
by Tomoichi_Sato | 2007-05-14 22:00 | プロジェクト・マネジメント | Comments(0)

プロジェクト貢献価値の理論

EVMSを製品開発型プロジェクトに単純に適用しようとすると、意外な困難に見舞われる。前回それを、単純なガレージカンパニーの例題で考えてみた。いま、発明家(技術者)と実際家(セールスマン)が協力し、まず発明家が20万円の材料費で100万円相当の新装置を製作する。成功確率はフィフティ・フィフティ。つぎに実際家が買い手を捜す。9割方の確率で成功するだろう。この、2タスクからなるシンプルな製品開発プロジェクトで、「製造」タスクが成功裏に完了したとき、進捗率はいくつと算定すべきだろうか?

通常のアーンドバリュー分析は、タスクのコストをその価値と考える。「販売」タスクのコストがほとんどゼロのため、このままでは進捗率=100%という答えになってしまいそうだ。この困難を避けるためには、タスクのもつ真の『価値』を算定しないといけない。しかし、それでは真の価値とは、いったい何か?

ためしに、この問題をもっと単純化してみよう。タスクをたった一つ、「製造販売」にしてしまう。かかる費用は20万円。失敗するリスク確率は、 100%-50%×90%=100%-45%=55%となる。もし、このプロジェクトがうまくいけば、収益は100万-20万=80万円の価値を生み出す。

ところで、この単純化プロジェクトがはじまる時点では、まだ100万円の売上は確実ではない。売上の期待値は、100万×45%=45万円にすぎない。一方、失敗しても部品代20万円は確実にかかる。したがって、プロジェクトの期待価値は、45万-20万=25万円だったのである。言いかえると、この「製造販売」タスクの成功は、25万円のプロジェクト価値を、80万円の価値に増大させたわけだ。差し引き、80万-25万=55万円の価値増大に貢献したことになる。

これを別の言い方で表現すると、タスクの貢献価値とは、そのタスクの開始時点で期待されるプロジェクトの収益(=価値の期待値)と、そのタスクの完了時点での価値の期待値の差分で表現される。そして、価値の期待値とは、各タスクのもつ失敗のリスク確率と、タスク遂行に伴う費用ならびに収入(キャッシュフロー)で決まるのだ。

では、最初のように「製造」「販売」の2タスクからなるプロジェクトではどうなるか、計算してみよう。プロジェクトの期待価値は次のようになる。
「販売」完了時点:100万-20万=80万円
「製造」完了時点:100万×90%-20万円=90万-20万=70万円
「製造」着手時点:100万×90%×50%-20万円=45万-20万=25万円
したがって、
「販売」タスクの貢献価値=80万-70万=10万円
「製造」タスクの貢献価値=70万-25万=45万円

両方のタスクの貢献価値を合計すると、55万円となって、さきほど計算した1タスクのプロジェクトの貢献価値と同じになることがお分かりいただけるだろう。

さて、これで準備はできた。いま、「製造」が完了して「販売」の開始時点になった。すると、進捗率は、まさにアーンドバリュー分析の教えるとおり、その時点までに達成した価値を、価値の合計で割ることで得られる。それは、
45万円÷55万円=81.8%
となる。

よろしいだろうか? タスクの価値とは、そのタスクの前後で増えるプロジェクトの期待収益であらわされるのだ。そして、価値は、タスクのリスク確率(失敗確率)に依存する。上の例を見てほしい。「製造」の方が「販売」よりもずっと貢献価値が大きい。これは、「製造」の方がリスク確率が大きい、すなわち“難易度が高い”からである。難しい仕事ほど、価値が高いのだ。当たり前に思える常識を、貢献価値の理論は数式で証明してくれる。

ちなみに、上の例で「販売」のリスク確率を失敗ゼロ、としたらどうなるか。「販売」の貢献価値もゼロになることは、すぐ分かると思う。失敗するリスクの全くないタスクは、必要かもしれないが、貢献価値はゼロなのである。

実際のプロジェクトでは、タスク数は2よりもずっと多いし、並行するタスクも存在する。こうした複雑な系でも、貢献価値を計算する手法は構成可能だ。詳しくはProMAC 2006の拙論文を見ていただきたい。

それにしても、もう一度、上の例をよく考えてみてほしい。従来の経営論では、しばしば「製造」はコストセンターで、「販売」がプロフィットセンターと扱われてきた。そして、プロフィットセンターの営業部門の発言力が、どんどん増していった。しかし、貢献価値を比較したら、コストセンターであるはずの製造部門の方が、より大きな価値を生み出しているのだ。どちらが経営上重要であるか、明らかではないか。

そしてまた、貢献価値の理論は、従来は評価の困難だった、企業内のバリューチェーンや、複数企業をまたぐサプライチェーンの適正付加価値の計算も可能にしてくれるのである。それもこれも、「リスク確率」の概念をキャッシュフロー分析に取り入れたからである。貢献価値の理論の威力が、少しでも納得いただければ幸いである。
by Tomoichi_Sato | 2006-12-12 17:38 | プロジェクト・マネジメント | Comments(0)

プロジェクトにおけるタスクの価値を計算する

米国PMIがまとめたプロジェクト・マネジメント知識体系の標準"PMBOK Guide"の普及にともない、日本でも次第にアーンドバリュー管理システム(EVMS)が使われるようになってきた。進捗とコストを同時におさえながら、プロジェクトのコントロールをする上では、非常に有用なツールである。日本にも『出来高』という立派な言葉と概念があったのだが、それをマネジメントの技術として普遍化・活用できなかった。日本のビジネス文化の弱点かもしれないと思うと、ちょっとくやしい気もする。

ところで、EVMSが広まるにつれ、なんとなく進捗はアーンドバリューで測ればすべてOK、という理解も広まってしまったようだ。舶来の理論をそのまま鵜呑みにしたがる風潮も、またわれらが文化の弱点かもしれない。以前、「アーンドバリュー分析の落とし穴」(『コンサルタントの日誌から』2002/10/20)などにも書いたとおり、EVMSは用法を心得て使うべきであり、決して万能の手法ではない。

EVMSの最大の弱点は、じつは製品開発型のプロジェクトに適用しようとする際に、うきぼりになる。ためしに、きわめて単純な例を考えてみよう。いま、発明家(技術者)と実際家(セールスマン)が二人でガレージカンパニーをはじめようとしている。発明家は、20万円ほどの部品を組み合わせて、100万円相当の機械と同等の機能を持つ新装置を作れる画期的アイデアを考案した。実際家は、それができたら自分が買い手を捜してやろう、ともちかける。つまり、この二人の事業は、「製造」と「販売」の2タスクからなる、きわめてシンプルな製品開発プロジェクトである。

ただ、発明家が実際にその装置を組み上げられるかどうかは、まだフィフティ・フィフティの見込みだ。一方、セールスマンは、もしその装置ができあがれば、9割方は買い手を見つけられる自信がある。製造タスクのコストは20万円。販売タスクのコストは、まあ電話代や交通費が多少かかるだろうが、ほぼゼロとしよう。

さて、ここで問題である。いま、ぶじ発明家が装置を組み上げることに成功した。つまり第1の製造タスクは完了したわけだ。ではプロジェクトの現時点の進捗率はいくつか? あなたはどう考えますか?

アーンドバリュー分析の立場から言うと、プロジェクトの進捗率とは、その時点までに完了したタスクの価値の合計を、全タスクの価値の総計(=つまりプロジェクト全体予算)で割った数値である。では、この場合はいくつか。プロジェクト全体のコストは20万円だ。そして、完了したタスクのコストも20万円だった。したがって、最初のタスクしか終わっていないのに、進捗率は100%になってしまう! はたしてこれで良いのだろうか?

はっきりしていることが一つある。それは“これでは働いている人間の実感にあわない”ということだ。実感に合わない尺度では、人をマネジメントすることはできまい。いや、問題は販売経費をゼロとしたことだ、と思う人もいるかもしれない。しかし、では販売経費をかりに千円としようか。そうしたら、進捗率は20÷20.1=99.5%となる。少数以下を切り上げると100%だ。これではなんら解決になるまい。EVMSによる進捗計算を製品開発プロジェクトに無反省に適用すると、いかに問題かおわかりになっただろうか。

この問題の本質はどこにあるのか。それは、「タスクにかかる費用を『タスクの価値』と見なす」というアーンドバリュー分析で広く用いられる前提にある。これは言いかえれば、費用のかからないタスクは価値が低い、と考えていることになる。一般に知的作業は人件費のみだからコストが小さい。それにひきかえ製造や建設や量産はコストが大きい。つまり、力仕事の方が価値が高いと評価されるわけだ。EVMSはアメリカ国防省の調達プロジェクトにおいて発達したから、コスト基準でタスクの価値をはかる考えがしみついてしまっているようだ。

コスト基準がだめだとすると、“二人の協力によるプロジェクトなのだから、半分終わったら50%と考えよう”といった解決法もあろう。しかし、これはマネジメント理論による解決というより、政治的決着というべきだ。製造作業が2人がかりだったらどうするのか。セールスに5人かかったらどうか。声の大きいタスクの方が勝つような進捗率計算など、マネジメントシステムの役には立つまい。それでは、どうすべきだろうか。

答えだけ先に言おう。『貢献価値の理論』を用いれば、タスクの真の価値を計算することが実はできる。そして上記の例では、進捗率=81.8%となるのだ。製品開発プロジェクトは、いや一般に全てのプロジェクトは、複数の人間が協力して、一度限りの目標を達成するための、リスクを伴う活動である。そこではリスク基準による貢献価値の理論が活きてくる。その考え方と具体的計算方法については、次回書こう。
e0058447_23371037.gif

by Tomoichi_Sato | 2006-12-04 23:39 | プロジェクト・マネジメント | Comments(0)

プロジェクト・マネジメントの世界は変わりつつある

オーストラリアのシドニーに行ってきた。ProMAC 2006に出席するためだ。正式にはInternational Conference on Project Management 2006といって、APAC(アジア・パシフィック)地域のプロジェクト・マネジメント国際学会である。2年ごとに持ち回りで開催されており、前回のProMAC 2004は東京で(正確には千葉で)開催された。第一回は2002年でシンガポールで行なわれた。2年後の第4回はアラスカ州のアンカレッジで開かれる予定だ。

3年前、米国ボストンで開催されたProjectWorldに参加したときの感想を、この「タイム・コンサルタントの日誌から」で『プロジェクト・マネジメントの世界は動いている』と書いた(2003/06/07)。その感は今回さらに強くなったと思う。このPM業界(というのもおかしな表現だが)に、多くの俊英が集まって、急速に経験の集積と手法の進歩するのが感じられる。

豪州側は豪PM協会とPMI Sydney支部が主催者になっているが、Defenceつまり政府国防関係も共催しているところが面白い。そしてかなり熱心に活動に参加していた。もともとプロジェクト・マネジメントと軍事との関係は深い。PERTは米国海軍のコンサルタントであったランド・アソシエイツが開発した手法だったし、 EVMSだって米国国防省が調達の標準手順として採用したからここまで広まったと言うことができる。それ以外に、建設/エンジニアリング関係の発表も多かった。むろんIT産業も参加している。製造業もいる。とにかくオーストラリアからの参加者は分野の裾野が広い、と感じる。

ひるがえって、日本からの参加者はというと、ここには若干の片寄りを感じた。参加者の数でいえば、おそらく2番目に多い国だと思うが、そのほとんどはIT業界の企業人なのである。それも、特定の大企業数社に限られていて、各社から大勢くり出している、という感じだ。こうなると容易に想像がつくが、日本人同士がかたまって日本語でしゃべっている状態になる。ちょっと、もったいない。

それはともかく、学会発表はなかなか興味深いものも多かった。一例を挙げれば、"Earned Schedule" の考え方の提案がある。米国海軍のコンサルタントLipke氏が発表で、EVMSの応用として、CPIやSPIといったアーンドバリュー分析の指標をいろいろと調べ、遂行途中で真の納期を精度良く予測するために、"ES"という新たな尺度の提案をしている。事実の集積に基づいた議論で面白かった。

私自身は2年前のProMAC 2004で初めて公開した『リスク基準のプロジェクト評価手法』の発展版を発表したわけだが、リスクは一つのキーワードだった。ほかに多くの参加者を集めていたテーマは組織論と人材教育だろうか。誰もが悩むテーマだからだろう。しかしこの種の話題はどうしても「工学」というより「経営学」みたいなアプローチになる。言葉による分析、インタビュー調査による集計が中心で、エンジニアとしてはどうにも歯がゆい。

プロジェクト・マネジメントの議論は、どうしても理工学的アプローチと、“文系”的アプローチの両面が出てくる。対象が人間の集団だから、それは無理もないことだと思うが、理論や手法として世界で通用するためには、やはり沢山の事実への適用によって磨かれないといけない。自戒を込めて言うわけだが、日本がこの分野で貢献するためには、もっと広い業種・分野での意見の交換が必要ではないかと思うのだ。
by Tomoichi_Sato | 2006-10-11 21:52 | プロジェクト・マネジメント | Comments(0)