プロジェクトマネジメント ワンポイント講義

プロジェクト・マネジメント(PM)、タイム・マネジメント(時間管理術)、プロジェクト・スケジューリング、などの分野で理解すべき用語と概念を解説しています。



プロジェクト・マネジメント

プロジェクト制の要件

ソフトブレーン(株)の会長・宋文洲氏はいつだったか、持論のプロセス・マネジメントに関連して、「プロセスは線路で、プロジェクトはそこを走る個別の電車である」と言われたことがあった。これはなかなか面白い喩えだと思う。プロセスはいったん路線を引いたら固定して変わらないが、プロジェクトは運転手も、乗せている客も毎回違う。行き先だって変わることもある。“だからプロセスの設計が重要なんだ”というのが宋さんの立論である。

しかし、これはある意味では例外的なケースだとも考えられる。通常の製造業においては、まず「プロジェクト」という仕組み自体が確立していない。製品開発や受注生産といった個別の『案件』は、たとえば

企画→設計→試作→生産技術→購買→製造→物流、

という複数の機能部門の中を、上流から下流に向けて流れていくケースがほとんどだ。言いかえれば、縦割り組織の中をバケツリレーのように受け渡されていくわけだ。普通の電車の運転手は終点まで変わらないが、縦割り組織のメーカーは、ひと駅ごとに運転手が交替する鉄道に似ている。

むろん、それでずっとうまく行っているならば、何の問題もない。しかし、製品開発や個別受注生産は、複数の機能部門が関わり合う、クロス・ファンクショナルな活動である。業容を拡大したり、短納期化を進める状況下で、複数の案件が並行して進むとき、ボトルネックの作業負荷を誰が調整するのだろうか? 部門を統括する上級マネジメントか? しかし、個別の案件で設計と購買の鞘当てが起こるたびに、いちいち事業部長が介入して調整するわけにもいくまい。

たとえば、既存の部品を転用すれば、早くできるのは分かっているが、しかしオーバースペックで高いものにつく。今回用に注文し直せば安く上がるが、とうぜん手配に時間がかかる。製品出荷の早さ(納期)をとるか、製品コストを取るか。製品開発は常にトレード・オフに直面するものだ。決断には責任がともなう。誰がそのリスクをとるのか?

答えは明らかだ。プロジェクト・マネージャーが必要なのである。納期とコストの双方に最終的な責任をもつ、プロマネが判断すべきだろう。そして、そのためには、社内でまず『プロジェクト制』の確立が必須になる。バケツリレーがこんぐらがって、もう限界に達したな、と思ったら、それはプロジェクト制を導入すべき時期なのだ。

プロジェクト制、というと、なぜだかすぐ「社長直属プロジェクト」を想起する人が多い。しかし、ここではそんな、“社運を決する一大プロジェクト”だけを考えているのではない。始まりがあり、明確なゴールがあって、複数の部署の人間が協力して成し遂げなければならない仕事(しかも失敗の可能性もある仕事)は、「プロジェクト」として公式に扱おう、と決めるのだ。

プロジェクト制の要件はいくつかある。まず第一に、プロジェクト・マネージャーの指名である。プロマネに、品質・納期・予算(QCD)に関する最終的な権限と責任を与える(人事権までは与える必要はない)。

予算に責任を持つためには、プロジェクト予算体系を確立しなければならない。これを支える仕組みとして、プロジェクト番号制が望ましい。プロジェクト番号をキーとして、日報による社内人件費把握や、外部費用のプロジェクト別把握ができなければならない。

誰をプロジェクト・マネージャーに任命すべきかも、悩ましいところだろう。企画部門かもしれないし、設計部門かもしれないし、生産技術部門から出すのがいいかもしれない。タスクフォース(「工務店」型)組織か、マトリクス(「置屋」型)組織かによっても、答えは違う。だが、いずれにせよ、プロジェクト・マネジメントに関する基礎的なトレーニングは必須だろう。固有技術と、管理技術は違うからだ。この点を忘れると、プロジェクト制など、すぐに絵に描いた餅になってしまう。

スムーズな製品開発や個別受注生産にとって、「プロセス」は必要条件だが、十分条件ではないのだ。最後まで決定に責任を持つ「運転手」=プロジェクト・マネージャーが望まれる

→「革新的生産スケジューリング入門」にもどる

プロジェクト・マネジメントとはどういう仕事か (2008/04/22)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

→「革新的生産スケジューリング入門」にもどる

プロジェクト・マネジメントの目的とは何か (2016-05-25)

中堅エンジニアが壁を破って成長するには、何を学ぶべきか。そういう問いに関連して、ここ何回か書いている。初級の仕事を一通りおえて、とりあえず一人前のことはできるようになっても、その先にしばしば壁がある。そこを乗りこえて面白い仕事をしていくためには、もう少しマクロにものを見て、人を動かせるようになっていく必要がある。

今年の1月に、静岡大学と浜松ソフト産業協会の共催によるプロジェクト・マネジメント講座に呼ばれて、初日の講師を務めさせていただいたときも、その話から始めた。集まった方はほぼ全員がIT技術者だった。IT分野は勉強会も盛んで、知識欲に燃えた熱心なエンジニアも少なくない。わたしはたずねた。
「この中で、現在プロマネの仕事をされている方はいらっしゃいますか?」

手を上げた方は全体の1/3もいなかった。ある意味、予想通りではある。プロマネの仕事をばりばりこなしている人は、こうした講座を聴きに来る必要がないし、第一、忙しくて聴きに来る暇もないだろう。わたしは受講者の方に申し上げた。

「すると、ここにいる過半数の方は、SE的な仕事をメインにされているソフトウェア技術者だと思います。じゃあ、もう一つおうかがいします。今やっている仕事が楽しい人、手を上げてください。今の仕事が楽しくて楽しくて仕方がない人は?」

結果はご想像に任せよう。少なくとも、全員からはほど遠かった。「つまり、楽しくない仕事をしている人が、結構いらっしゃる訳ですね。では、今の皆さんの状況を打破するためには、どうしたらいいでしょう? 充実した、面白い仕事をするためには? −−たしかに皆さん、勉強熱心でいらっしゃる。しかし、あるレベルに達したら、そこから先はソフトウェア技術だけでは、充実した仕事はむつかしいのです。」そう、わたしは続けた。

「たった一人でプログラムを書いて、世界を転換させる、そんな夢を抱いて業界に入った人もいるでしょう。ただ、それで成功する人は、たぶん百万人に一人。それ以外の人は、他人と協力して、チームで仕事に取り組まなければなりません。そして面倒なユーザを説得し、上司を動かして、目的を達する必要があるのです。一つの目的のために、人を動かす技術。それがプロジェクト・マネジメントです。良い仕事をしたければ、プロジェクトの動かし方を知るべきなのです。」

仕事を良く理解したければ、仕事の『なぜ』=目的をしっかり把握する必要がある。プロジェクトとは、一つの目的のために、チームを動かして進める仕事だ。プロジェクトの目的とは、たいていはシステムなどの成果物と、そのアウトカムである。そこは、はっきりしている。

では、プロジェクト・マネジメントという仕事の目的はなんだろうか。

え? それはプロジェクトの目的と同じじゃないか。つまり成果物としてのシステムだよ??という答えは、じつは答えになっていない。もしそうなら、コーディングやテストという仕事が、プロジェクト・マネジメントの内部になければいけないことになる。もしかりにチームがプロマネ抜きでちゃんと仕事を果たして、システムを納品したら(理屈の上では可能だ)、プロジェクト・マネジメントの役割は何なのか? いや、理屈の上どころか、チームの足を引っ張る無能なプロマネだって、実在する。じゃあ、上手なプロマネと下手なプロマネの違いはどこから生まれるのか。有能なプロマネは何に奉仕し、無能な奴は何に失敗しているのか?

答えは簡単だ。プロジェクト・マネジメントの目的は、プロジェクト価値を最大化することなのだ。

え、それだけ? −−そう。それだけだ。この目的を分かっているプロマネは、良い成果物が短期間にできるよう、チームの目標を明確化し、チームが働きやすい場や状況を作り上げ、問題を適時解決していく。ときには余計な管理で手間取らせないよう、手出しを控えたりする。逆のプロマネは・・言わなくてもお分かりだろう。

以上。

ま、ここで終わりにすれば、最近やたら長い傾向にあるわたしの記事の中では、画期的に短いエントリになるな。そうすれば省エネだし、地球環境にも優しい(?)かもしれない。が、ちょっとだけ補足を付け加えることにする(だから長くなるのだが・・)。

前々回の記事によれば、生産マネジメントの目的は、「生産の仕組み(生産システム)をつくり、活かし、進化させ、それによって働きがいを創出すること」だった。だったらPMだって、「プロジェクトの仕組みをつくり、活かし、進化させ、働きがいを創出する」という風にならないのか? 生産とプロジェクトはある意味、兄弟ではないか。そう感じられる読者もおられるかもしれない。

だが、そうではないのだ。プロジェクトを立ち上げ、場や組織を作るのは、プロジェクト・マネジメントの目的ではなく、「本来業務の一部」である。チーム作りは、手段に過ぎない。レンガを積むことは、レンガ職人の仕事の目的ではないことを思い出してほしい。本来業務は、仕事の目的ではない。

そして、プロジェクトはその定義上、一度限りの仕事であり、プロジェクト組織は一過性のものなのだ。生産マネジメントは永続的な仕事だが、プロジェクト・マネジメントは一過性の仕事である。そこが根本的に違う点である。

じゃあ、進化させるのは? つまり、プロジェクトで得た知見や教訓を、他のプロジェクトの改善に結びつけること。もっと別の言い方をすれば「組織のプロセス資産」の強化だ。これはPMの目的ではないのか?

あいにく、知見やL&Lや組織の資産は、プロジェクトの波及効果(アウトカム)の一部である。良いアウトカムを生み出すことは、プロジェクト価値を高めることの中に、すでに含まれている。という訳で、プロジェクト・マネジメントの目的は、生産の場合より、ずっとシンプルな文章で表現できるのである。

もともとプロジェクト・マネジメントは、直接の成果物を生み出さない、「間接業務」である。だからもし、プロジェクト・マネジメントに全体の1割のコストがかかり、それが全体に対し1割以上の価値向上をもたらさなかったら、そんな作業は引き合わないのだ。

ただし念のため書いておくが、価値(Value)とは、利益(Profit)とイコールではない。ここを間違える人は、受注型ビジネスの業界に多い。プロジェクトの価値とは、受注金から原価を差し引いた値だろ、と。だが、それだけではないのだ。価値は、金銭的価値と、非金銭的価値とからなっている。受注型プロジェクトではたしかに、利益という金銭的価値はとても大事だ。だが、たとえば、その顧客やその分野での実績を得られたとか、プロジェクトで人が育ったとか、そうしたお金に換算しにくいアウトカムもまた、プロジェクトの価値の一部なのだ。

だから、「プロジェクト・マネジメントの目的はプロジェクト価値を最大化することだ」という定義は、すなわち「価値とは何か」という大きな問題を考えることを、プロマネに要求しているのだ。金銭的価値、そして複数のお金に換算しがたい価値があるとき、どれをとるのか、どれを優先するのか、そうした問いに、自覚的なプロマネは答えなければならない。

もともとマネジメントが決断能力を持つためには、価値観が必要である。「決断」はマネジメントの中心にある行為だ。そして、何が「良い」状態であり、どうなれば「価値が高い」かが明確でなければ、適切に「決める」ことはできない。ただし残念ながら、現在のプロジェクト・マネジメント理論には、こうした適切な価値論が欠けている(唯一、英国OGCのガイドライン"Management of Value"だけが、この問題への一つのアプローチを与えていると思う)。

もう一つだけ付け加えておこう。それは「プロジェクトは見えないシステムである」ということだ。プロジェクト価値の向上は、その見えないシステムの設計や運転からもたらされる。そこがこの仕事のむつかしさなのだ。

現代プロジェクト・マネジメントの考え方は、1950年代の『クリティカル・パス法』の誕生とともに生まれた。これはプロジェクトというものを、複数のアクティビティ(要素作業)から構成されるシステムととらえた、システムズ・アプローチの産物であった。つまりモダンPMとは、「プロジェクト=システム」という視点の上に立っているわけだ。

それ以前までは(つまり古代のピラミッド建設や万里の長城の時代から20世紀初頭の帝国覇権主義の時代まで、えんえん数千年にわたって)、人間はプロジェクト全体を「かたまり」としてしか見ていなかった。大きなかたまりのまま計画したり操作しようとしたりしてきたが、決してうまくいかなかったのだ。デュポン社の化学プラント建設スケジュールや、ポラリス潜水艦ミサイルの納期の予測のために、クリティカル・パスやPERTの手法が開発されてはじめて、人類はやっとプロジェクトに対する科学的理屈を手に入れたのである。


ところで、プロジェクトをシステムとしてみた場合、生産システムや交通システムなどとは歴然とした違いが一つある。それは、「実在」か「過程」かの違いだ。

生産システムは、空間的にも実在しているし、それに属する機械や人間も目に見える。永続的な仕組みである。しかしプロジェクトは、同じシステムではあるが、目に見えない。全体が同時に実在している訳ではないからだ。個別の瞬間には、その時点で走っているいくつかのアクティビティが動いているだけで、全体像を「見る」ことはできない。

たまにIT産業の方から、「プラント・エンジニアリングの業界はうらやましいですね。プラントが出来ていく姿は目に見えますから。ソフトウェアは目に見えないから大変なんです」といわれることがある。どういたしまして! それはものごとを表層的に見ているだけである。現場に組み上がっていくプラントは目に見えるかもしれないが、結果でしかない。プロジェクトの成否を決める大事な部分は、その現場に資材を届けるサプライチェーンであり、工事図面を作成するエンジニアリング・チェーンである。こうしたアクティビティは世界中に散らばっているし、よく目にも見えないのだ。

プロジェクトは目に見えないシステムである。それは(哲学者のホワイトヘッド風にいうならば)永続的な「実在」ではなく一過性の「過程」である。それを設計し運転していくのが、PMである。途中で後戻りできない。だから大変なのだ。

そして、プロジェクトは人間をその構成要素として含む「第二種のシステム」である。機械的な構成要素だけからなる「第一種のシステム」は、科学法則だけで予測可能だ。だが、自分で勝手に判断する人間を含む第二種のシステムでは、予測や制御がはるかにむずかしい。そして、だからこそ面白いのだし、上手くいった場合には価値が高いのだ。プロジェクトは放っておくと混沌に陥りやすい。それを束ねて、ある目的成果物やアウトカムを生み出す。放置した場合と統合した場合の価値の差が、プロジェクト・マネジメントの良否を測る尺度である。

価値観と、システムズ・アプローチの視座。これの二つが、プロジェクト・マネジメントの目的、すなわちプロジェクト価値の最大化を実現するために、必要なのである。こういうことは、輸入版のPM教科書にはあまり書いていない。いや、じつをいうと、わたしがこのことに気がついたのも、ほんの数年前のことだった。それまでは自分でもうまく言語化できていなかったのだから、いつも偉そうなことを書いているわりには、お恥ずかしい次第だ。

言葉にすること。それはマネジメントの第一歩である。マネジメントとは(少なくともその中核の意味は)人を動かすことにある。人を動かすには、テレパシーが使えない限り、言葉で伝えるしかない。だから言語化はとても大事なのだ。そして動かすべき「人」の中には、じつは未来の自分も含まれる。いや、正直にいうと、未来の自分ほど、動かしがたく、迷いやすく、忘れっぽい存在はいない。だから目的の言語化とは、何よりもぶれない自分自身への、道しるべなのである。

→「革新的生産スケジューリング入門」にもどる

センス、キャリア、資格 ― マネジメント能力を左右するのはどれか (2011/11/26)

ある女声合唱の演奏会で、わたしの所属する男声アンサンブルが、2曲ほど手伝うことになった。相手はプロのソプラノ歌手が主宰し、指揮する女声合唱団である。本番の数週間前、相手方との打合せにいった。これまで別々に練習してきたが、本番までに何回か合同練習が必要だ。それに、演奏会当日の段取りも確認しなくてはならない。相談すべき事柄は多い。

打合せの席でお互いに自己紹介し、議題に入ると、相手方から資料数枚が配られた。その資料を見て、わたしは驚いた。当日までに準備しなければならないこと、当日の手順とタイムテーブル、担当すべき係と受け持つ人の名前、費用について、などがきちんとワープロで整理されて書かれている。そして、その資料を作った女性が説明をはじめた。「今日、決めておかなくてはならないことは、○○と○○と○○です」穏やかな口調だが、進め方はとてもてきぱきしている。じつに感心してしまった。

その打合せ資料は、演奏会に関わる仕事のスコープ・スケジュール・予算・そして体制がきちんとカバーされている。つまり、マネジメントの要点をすべておさえているのである。作成した女性は落ち着いた身なりの方だが、とくにばりばりのキャリアウーマンにも商売人にも見えない。主婦だろうか。「彼女は女性にしておくのはもったいないんです、こう言っちゃなんですけれど」と、主宰される声楽家の先生は笑いながら言われた。わたしはマネジメントが男性向きの仕事だとはべつに思わないけれど、生まれつきのマネジメント・センスってあるんだなあ、とあらためて感じた。

別のある日。とあるプロジェクトのキックオフ・ミーティングに顔を出した。チーム・メンバーとしてではなく、アドバイザーとして呼ばれたのだ。ソフトやハードを作るのではなく、どちらかといえば企画コンサルティングに近いプロジェクトであった。チーム・リーダーが前に出て資料を配付し、皆に説明する。本プロジェクトの背景と意義、めざすべきゴール、そしてトップや行政からの期待、等々。

しかし、わたしはがっかりしてしまった。キックオフの資料には、やるべきアクティビティも、全体のスケジュールも、概略予算も、遂行体制図も役割分担表も、何もないのだ。たしかに、ものづくり的なプロジェクトとちがって、明確なスコープを定めにくい、難しい仕事だ。だがこれでは、飛び上がったものの、どこに着地するかわからぬ飛行船のようではないか。リーダーは、立派な大学を優秀な成績で卒業し、以来、高度な技術分野でずっとキャリアを積んできた技術者だ。だがプロジェクト・マネジメントというものをどう考えているのか。疑問符が繰り返し頭の中にわいた。

さらに別のある日。とある協業相手の会社からメールがとんできた。半年足らずのプロジェクトの説明資料である。添付ファイルを開けてみると、10数ページにもわたる立派なプロジェクト・マネジメント計画書がついている。さらに末尾にWBSが添付されていた。その一部をあげると、こんな感じである:

 ・・・ ・・・ ・・・
2.3 ソフトウェア詳細設計
 2.3.1 制御システム詳細設計
2.4 中核部品調達
 2.4.1 調達要求書(RFP)作成
 2.4.2 引き合い・発注
 2.4.3 サプライヤー承認図のレビュー
 ・・・ ・・・ ・・・

一目見て、部下が言った。「ダメですね、こいつら。プロジェクトのこと何にもわかっちゃいない。素人ですよ。」わたしも、ためいきをついて、同意した。「うーん、困ったね。なんでもPMPの資格を持ってる人が計画を作ってると聞いたんだけど・・」

WBSのどこがダメか、おわかりと思う。2.3「ソフトウェア詳細設計」のサブ・アクティビティとして、2.3.1「制御システム詳細設計」がただ一つだけあげられている。ところで、WBSというのは、

 (親アクティビティのスコープ)=Σ(全サブ・アクティビティのスコープ)

という形で分解すべきものである。これを『100%ルール』と呼ぶ人もいる(子ども全員で親を100%カバーしなくてはいけない)。そうしないと、コストや必要リソースを集計した時に、要素がどこかに消えてしまうからだ。

上記のWBSでは、「制御システム」は親の「ソフトウェア」のすべてをカバーしているわけではなさそうだ。注意すべき代表例が上げられているだけだろう。逆に、もし「ソフトウェア詳細設計」=「制御システム詳細設計」だったら、そもそもbreakdownする必要がないのである。こうしたことは、WBS作成のイロハに属する。口さがない部下が「素人だ」と断じたのは、そのためであった。

(とはいえ、この程度のことさえ理解せずに、PMPの資格が取れてしまうとしたら、あの試験にはいささか問題があるということになる。名刺に「PMP」とれいれいしく刷っている身としても、これはやや困る)

それにしても、ここにあげた三つの例を考えてみると、マネジメントに一番役に立たないのは『資格』であり、次に役に立たないのは『学歴』『キャリア』で、一番役に立つのは、持って生まれた『センス』だということになりはしないか。だが、果たしてそれで良いのか? 本来は逆の順であるべきだろう。持って生まれたセンスを教育や仕事の経験が磨き、それを資格が保証する、というのがあるべき姿のはずだ。しかし多くの企業では、キャリアも資格も固有技術・知識として頭の表層に残るだけで、管理技術としてのマネジメントは「センス」のみで進められている、らしい。

最初の合唱団の例を思い出してほしい。指導する声楽家はリーダーである。そして、単に歌の練習を繰り返す間はそれだけで十分だった。でも、演奏会にはマネジメントの仕事が生じる。マネジメントは、何か新しいことに挑む時に、あるいは過去の繰り返しでは先がない時に、必要となるものだ。ちょうど新製品を作ったり、業務や組織を改革したりする時に。それ自体は、必ずしも華々しいものではないかもしれない(演奏会で脚光を浴びるのは指揮者やソリストだし、新製品で賞賛を受けるのはデザイナーだ)。でも、上手にやることが望まれる。そのマネジメントの仕事を、キャリアでも資格でもなく、皆が持って生まれたセンスだけでやっているのだとしたら ―― たしかにまあ、わたし達の社会が泥沼から脱出するのに時間がかかるのも無理のないことである。

→「革新的生産スケジューリング入門」にもどる

PMPの資格はほんとうに仕事の役に立つのか (2015-05-25)

昨年、勤務先でPMIの来訪を受け、同僚と共にインタビューに応じた。目的は日本におけるPMP資格取得の動向を探ることで、相手はいかにも頭の良さそうな30代の米国人であった。名刺を見ると、PhD、つまり博士号保有者であるむね書かれている。むろんPhDのほかにPMPも資格として名前の後ろに書かれている。

今さら説明するまでもないが、PMIはProject Management Instituteの略で、米国発で世界最大のグローバルPM団体である。日本にも支部はあるが、米国の本部が、世界中の数十万人の会員を統括している。PMIは元々1960年代に、プロジェクト・マネジメントに携わる人々が、PMという仕事もプロフェッショナル専門職として世に認めてほしい、との願いをもって結成された組織だ。現在のPMIは、通称『PMBOK Guide』(R)、正式には"A Guide to Project Management Body of Knowledge”とよばれるプロジェクト・マネジメント分野の標準書を発行しており(邦訳『プロジェクトマネジメント知識体系ガイド』)、それを元にしたProject Management Professional(略称PMP)の資格試験を主催している。

PMBOK Guideの初版が編纂されたのは’90年代の前半で、PMP試験も最初は米国に受験しに行かなければならなかった。しかしこの標準書と資格制度は非常に成功し、次第に世界中に広まることとなった。今では日本でも、日本語で、いつでも好きなときにPMPを受験できる。PMIはその後、他の資格試験制度もいろいろと設立しており、昨年3月の時点でPMIの資格保持者数は世界で60万人を超えている。また、PMBOK GuideとPMP試験が大当たりした影響は大きく、他の諸団体もきそって”xxBOK”というBook of Knowledge(知識体系)を発刊するようになった。わたしが知っているだけで、BABOK(ビジネス・アナリシス)、DMBOK(データ・マネジメント)、CMBOK(コスト・マネジメント)などがある。
その大成功した米国PMI本部のディレクターが、なぜわざわざアジアの辺境のわが勤務先などを訪ねてきたのか。たしかにPMIの法人スポンサーだし、インタビューに応じた同僚もわたしも、一応PMP資格は持っている。だが、わが社におけるPMP資格保有者など、(正確に数えたことはないが)数十名の下の方だと思う。日本だけで20万人以上いると思われるPMPの意見を聞くには、ずいぶん不適格ではないか。3桁以上のPMPを抱える立派な日本企業だって、IT業界にはいくつも存在するはずだ。

むろん、相手はそうした企業も回っているのだろう。だがエンジニアリング業界の話も聞きたいと思って、選んでくれたのかもしれない。質問の中には当然、「プロジェクト・マネジメントをビジネスの基盤としているエンジニアリング会社なのに、なぜPMP保持者が少ないのか」という主旨の問いもあった。わたしの同僚達はPMO部門に所属しており、(わたしも数年前までは同じ部署だったのでよく知っているのだが)PMP資格取得を社内で推奨しているのに、実際には受験者が少ない。

なぜPMP受験者が少ないのか。答えは簡単である。なくても、とりたてて仕事に不便がないからだ。海外のOil & Gas業界には、プロジェクト・マネジメントに関する一種のIndustry Standardが存在しており、発注者も受注者もそのことを承知している。これは一種の業界の慣習であって、特に何か決まった書き物はない。しかし、プロジェクトの入札書類には、必ずプロジェクトをこの業界標準に従った形で進めることが条件として義務づけられている。いわく、きちんとしたProject Execution PlanとProcedureを最初に作成すること、WBSを構築すること、レベル-2・スケジュールを作成してCritical Pathを同定すること、EVMSで進捗をコントロールすること等々、事細かく規定される。むろん、プロマネやPCM (Project Control Manager)やEM (Engineering Manager)など重要職は、本業界で10年以上の経験を有していること、などの要求もついているのが普通だ。

逆に、プロマネがPMP資格を有すること、などの条件がついているのは見たことがない。つまり、たとえPMP資格を持っていても、十分な経験がなく、上記の要求レベルでプロジェクトを回せなければ、役に立たないことを意味している。だから、あえてPMPを取ろうという人が出てこないのだ。

誤解しないでほしいのだが、わたしはPMP資格が無価値だ、などと言っているのではない。むしろ、社内に対しては、PMPも取ってないようでは恥ずかしいではないか、とのメッセージを発している。試験はたいして難しくない。基本的に、知識を問う選択問題である。多少、用語理解と模擬試験のために数ヶ月程度の準備はいるかもしれないが、パスする者は多いだろう。PMBOK Guideだって、読めば頭の整理にはとても役に立つ。たしかに用語は若干、我々の業界からずれているところもあるが、それは頭の中で翻訳しながら読めばいい。もし業界をまたぐ共通語を習得できれば、他の業界から、より良いPracticeを学ぶ機会もありうるではないか。

それでも、PMBOK Guideを勉強する人は少ない。わが同僚のA氏は皮肉って、こんなジョークをつくった:

若手 :「PMBOKくらい読んでおけよといわれたのですが、どんなことが書いてあるんでしょうか?」
ベテラン :「PMBOKなんて実務には何の役にも立たないよ。」
若手 :「そうなんですか。 で、どんなことが書いてあるんでしょう?」
ベテラン :「きみきみ、役に立たないものを、私が読んだことがあると思うのかね?」

勤務先を訪問された上記PMIのインタビューアーへの回答としては、それ以外に二つのことをあげておいた。一つは試験費用である。PMPの受験料は、社内では負担の一部を補助しているが、それでも他の日本の公的資格試験等に比べて、かなり高価である。もう一つ、日本語の翻訳も、いささか生硬でぎこちない。PMP試験はPCの端末に向かって行う形式だが、わたしが受験したときは、英語がデフォルトで、あるオプションを押すと、翻訳の日本語が表示される仕組みだった。しかし日本語が読みにくいので、わたしはずっと英語で問題を読んだし、後輩にもそれを勧めている。

まあしかし、これらのことは本質ではない。わたしがPMP試験について一番問題に感じているのは、じつはそれが知識を問う試験にすぎないことだ。以前から書いていることだが、能力とは知識や資質だけで決まるものではないと、わたしは考えている。個人の能力を構成する要素としては、知識・感覚(センス)・身体的スキル・創造性などがあり、これらをきちんとバランスし、かつ整合的・臨機応変に、組み合わせて活用できなければならない。だから、誰かの能力を評価するのはとても手間のかかる、難しい仕事なのである。これを、わずか数時間程度の、パソコンの前の応答だけで測ろうというのが、もともと無理なのだ。PMやPM補佐を10年近くやってきた者は、こうした矛盾点にそもそも違和感を感じるのだろう。

じつはちょうど昨年の同じ頃、わたしはGAPPS Initiativeの活動も手伝っていた。GAPPSとは、”Global Alliance for Project Performance Standards”の略で、プロジェクト・マネジメント分野の標準化問題を整理するために組織された、まったく非営利のボランタリーな団体である(URL http://globalpmstandards.org)。GAPPSは10年ほど前に、PM分野の巨頭たち数人によって、私的に結成された。世界には、米国のPMIをはじめ、欧州のIPMA (International Project Management Association)、豪州のAIPM(Australian Institute of Project Management)、日本プロジェクトマネジメント協会 (PMAJ)、英国APMなどPM団体がいくつもあり、それぞれが独自に標準や資格を制定してきた。その結果、2000年代に入ると、複数の標準・資格の競合や乱立といった現象がおき、実務家にとってありがた迷惑な状況が発生してきた。

GAPPSはこの問題をただすために生まれ、PMI・IPMA・AIPM三団体の元トップらが参加して地道に活動してきた。メンバーは世界中に分散しているので、基本的に年に3回集まって、Working Sessionで作業を進めている。昨年はそのうち1回を日本で開催し、JICA(国際協力機構)がホストを務め、PMAJが協力した。わたしもPMAJからのお声がけで、参加したのである。

GAPPSは、PM能力(コンピテンシー)とは、外的に現れた成果を基準に評価すべきだと考える。PMP試験のように、知識を基準とした(Knowledge-based)評価から、成果基準(Performance-based)のコンピテンシー標準への進化を求めると共に、各国のPM標準を相互比較し、アセスメント結果を公表している。その目的のために、結局、GAPPS独自のPM Standardを作成したのだから、なんだかN個の基準の整合性をとるために、N+1個めの基準を作ってしまった感もなくはない。が、少なくともその目的意識は、わたしも共感するところである。

そもそもマネジメント分野で標準とか資格とかに、どういう意味があるのか。わたしは東大で夏学期に週1回、プロジェクト・マネジメントを教えているが、今年の授業開始直後に、こんな質問を院生から受けた:

「Managementの再現性の取れなさ、うさんくささがずっと気になっています。『君にもできるプログラミング』と『君にもできるプロジェクト・マネジメント』という2冊のタイトルを並べてみると、後者の本に頼りなさを感じます。どうして理論が組み立てられているのに、現実の組織はこんなにもうまく機能せず、有能なリーダーはこんなにも稀なのでしょうか?」

なかなか本質をとらえた、鋭い、よい質問である。これはいいかえれば、「PMの標準なんて何の役に立つんだ?」という疑問だ。で、わたしは、こう答えた:

「世の中の技術や能力には、決定論的なものと、リスク確率の伴うものがあります。プログラミングは前者で、プロジェクト・マネジメントは後者に属します。これはたとえば、『君にもできる航海術』というタイトルの本を考えてみれば分かるでしょう。航海には、船の構造や気象学・海洋学といった専門的な知識も、GPSをはじめとする最新の測量技術も必要です。しかし、それらをみんなそろえたからといって、誰でもすぐ航海に成功すると思いますか? 学ばなければ、航海には出られません。しかし、学んだ後で、自分のものにする努力がなければ、いずれにせよ役には立たないでしょう。」

マネジメントの能力とは、たえず変化する環境の中で試されるもので、「知っている」ことと「出来る」ことの間には、大きな距離がある。こうしたことは、落ち着いて考えれば誰にでも分かることだ。にもかかわらず、知識を基準とする資格制度が、世界的に非常に成功してしまった。これは、今後は製造業より知財ビジネスと金融で経済を支えていく、という米国の国家戦略ともマッチしていた。PMP試験は、受験資格を得るためにも、また3年に一度の更新のためにも、『PDU』とよばれる一種の単位を取得蓄積することが義務づけられる。その制度的発明は、PDUビジネスという大きな周辺産業を生み出すこととなった。こうしてPMIは、みごとに渦を巻いて、多くのプロマネやプロマネ予備軍の人たちを引き込んだのである。とくにPMBOK Guideは、IT産業への福音として喧伝され、歓迎された。

そのPMIは、しかし、どうやら二つの悩みを現在かかえているように見える。会員数が思ったように増えないこと、PMPを維持しない人が案外多いことだ。だから日本まで、市場調査のために行脚にくるのだろう。

なぜPMPを維持しないのか? なぜPMBOK Guideに失望するのか? 答えは明らかで、本当にはプロマネ達の悩みを解決する助けにならないからだ。少しは、助けになる。だが知識は必要条件だが、十分条件ではない。そのことは多くの人がうすうす、気づいている。そしてさらにいえば、あらゆる業種、あらゆる形態と規模のプロジェクトに、共通にフィットする知識体系というものも、そろそろ限界に達してきているのだろう。抽象的すぎて、自分の実務に適用するにはコンサルを呼ぶしかない、というのでは、ちょっと不便である。

どうやらプロジェクト・マネジメント関係の標準は、一つの曲がり角に来ているらしい。そういう問題を議論したくて、次回の「プロジェクト&プログラム・アナリシス研究部会」では、PM標準に関する国際的なエキスパートである田島彰二氏を招いた次第だ。知識だけでは、プロジェクトは救えない。知識を超えた知恵を、われわれが出すには、どうしたらいいのか? できれば皆で、一緒に考えたいと思うのである。

→「革新的生産スケジューリング入門」にもどる

プロジェクト・マネジメントの教育について (2014-01-27)

先日、わたし自身が主査を務める研究部会で『プロジェクト・マネジメントの教育について』という講演をさせていただいた。過去何年間かにわたり、 大学・大学院・自社・他企業などで試行してきたPM教育カリキュラムの内容と課題について、ディスカッションしたいと考えたからだ。当日は普段の倍以上の方が来場され、この問題への関心の高さがあらためてうかがえた。遠くは岩手から参加された方もいたが、都合の合わなかった読者もおられると思い、ここにその一部をご紹介しよう。ちなみに、会の名称は「プロジェクト&プログラム・アナリシス研究部会」といい、スケジューリング学会の下部組織だが、とくに学会員でなくても自由に参加できるオープンな組織である。

当日の発表内容は、前半が「大学におけるPM教育の実践例から」ということで、主にカリキュラムの内容の話、後半が「PM教育のあるべき仕組みを考える」で、わたしの今の考えを述べたものである。前半は、授業でわたしが学生に問いかける質問集をつかった、インタラクティブな説明なので、ここには再現しにくい。ただ、カリキュラム構成自体に興味のある方もおられると思うので、実際に大学で行っている講義日程だけご紹介しておく。今年度、前期は東大・柏キャンパスの大学院で、後期は法政のデザイン工学部で、それぞれ週1回、「プロジェクト・マネジメント」の科目を教えており、どちらも全部で約15週間である。説明のレベルに多少差はあるが、内容やカバーする範囲に質的な違いがあるわけではない。下記は法政大学での例である。

第1回: Projectとは何か、Managementとは何か
第2回: ゴール・目標・目的
第3回: Scope
第4回: WBS
第5回: 組織と要員
第6回: スケジューリング
第7回: コスト
第8回: 進捗とEVMS / ミニテスト
第9回: 時間管理
第10回:品質と問題解決 / グループ課題出題
第11回:契約と交渉
第12回:プロジェクト評価
第13回:コミュニケーション
第14回:リスク
第15回:グループ課題 最終発表会

第1回と2回は全体のイントロ、第3回〜7回がプロジェクト計画立案、第8回〜14回がプロジェクト遂行と評価についての講義である。試験は行わない。プロジェクト・マネジメントは知識だけの能力ではないので、ペーパーテストにあまり意味はない。かわりに最後の1ヶ月程度をかけて、班編制でグループ課題に取り組んでもらい、その発表をもって試験にかえる。つまり、小さなプロジェクトを実体験してもらうわけである。採点は、原則として出席と、最終発表の評価(これも学生に他の班を採点させて平均する)を用いる。

なお、途中に「ミニテスト」があるが、これは講義内容をどれくらい受講者が理解しているかをチェックするために行う。わたし自身の教え方のよしあしをチェックするのが目的である。テストというと、学生はすぐ自分達の評価が目的だと思い込むが、本来テストというのは教える側のためのものだ、というのがわたしの信念である(→「品質工学から見た日本の教育の問題点」2013/02/18 参照のこと)。

さて、後半の話題の出発点は、「そもそも教育とはどういうことか」という“そもそも論”からはじめた。

読者諸賢にもちょっと考えてみていただきたい。「自分は成長した」と実感したのは、どんなときだったろうか?

たぶん、何かを『教わった』ときではあるまい。また、何かの試験に合格したり、どこかに入学したときでもない。自分が成長したと実感できたのは、「それまでやったことのない未経験のことを、自分でやり遂げたとき」ではなかったろうか。

教育とは、人の成長を支援するプログラムのマネジメントである−−これが、わたしの理解だ。教育とは、「教え」たり「育て」たりすることではない。相手が学び、育つことをサポートする仕事、つまり他動詞的な行為ではなく自動詞を助ける行為が教育なのではないか。そんな風に、しだいに思うようになってきた。

ここで、「プログラムのマネジメント」という語は、PM理論でいう、「プロジェクトのマネジメント」の上位概念としてつかっている。プログラムは、単発的なプロジェクトを複数、配下に持っていて、それらを協調して動かす事で、ある大きな目的を達成する。そういう意味である。つまり、教育とはプログラム・マネジメントの一種なのだ−−そう理解すると、いろいろなことが明確に見えて来るではないか。

プログラム・マネジメントの概念は、日本ではまだあまり普及していないが、大まかに言うと以下のようなステップをとる:

Step 1: ミッション・プロファイリング(「あるべき姿」を考える)
Step 2: プログラム・アーキテクチャ設計(「あるがままの姿」=現状からの変革の道筋となるプロジェクト群を決める)
Step 3: プログラム実行のマネジメント(目標と道筋に沿って、現実に対処しながら進む)
Step 4: 価値実現のチェンジ・マネジメント(到達点で得た能力を、具体的価値に実現する)

ちなみに上記の手順は、日本のP2Mと英国MSPの考え方をつき交ぜて簡略化したものだ。さて、この4つのStepを、PM教育(PM育成の支援プログラム)に適用すると、こんな展開になるだろう。

Step 1. 「持つべきPM能力」を考える
Step 2. どういう段階をたどって育つかを想定する
Step 3. 支援の『仕組み』を作って(システム化)、それを回していく
Step 4. 成長によって得たPM能力を仕事に生かす

組織内でプロジェクト・マネジメントの教育を確立するためには、この4ステップが必須である。第1ステップ(持つべきPM能力)の中身については、組織によってそれぞれ違いがあろうから、自分達の仕事に即して考える必要がある。上で紹介した大学教育のカリキュラムは、2番目のステップの一例で、いくつかの企業で行った入門講座(2日程度のセミナー)を元に作ったものだ。第3のステップ(システム化)は、教育を単発のイベントに終わらせないために重要である。そして第4のステップ、すなわち成長によって獲得したPM能力を、実際の仕事に生かすチャレンジは、それがなかったら何のために教育があるのか分からない。

とくに、Step 3で教育を支援の仕組み(システム)としてとらえるとき、忘れてはならない大事な要素がいくつかある。以前も書いたことだが、人が何かを学ぶ際には

(A) 先生、ないし手本になる人
(B) 基本的な原理原則
(C) 練習の繰り返し

の三つが必要だ(→「それは知識ですか、スキルですか、資質ですか?」2013/06/02 参照)。

したがって、学びを支援するためには、まず、(A)良い教師、(B)原理に基づくきちんとしたテキスト、(C)実戦と研鑽の場、がいるのは自明だろう。そしてたしかに学校という教育機関は、教師・テキスト・教室を必ず用意している。

しかし、その三つに加えて、とても大事なものがもう一つある。それは、

(D)「学びの途中で、まだ成果の出ない者を、待って支える報奨系

である。成長には、時間がかかる。だが、学びの途上にある人は、まだ生かすべき成果を持っていない。つまりコストだけがかかって、ベネフィットが何もない期間が長く存在する訳だ。そこで、この人自身のモチベーションを維持し、また彼/彼女をとりまく家族や職場や上司など周囲の人々の負担を軽くするような報奨系が、教育のシステムにおいては死活的に重要なのだと思う。

余計なことだが、今日の学校教育制度では、この報奨系がひどくやせ細っているように見える。良い学校に進んで、就活にうまく勝たなければ、一生『負け組』のままだ、といったような、負の脅迫系ばかりがはびこって、“人として成長すればこんなに良いことがある”というポジティブなメッセージが世の中に足りない。育英のための奨学金制度は、社会における報奨系の典型例だが、いつのまにか有利子返済すべき“学生ローン”に大半が変質してしまった。待ってやっている間にも利息が付くからな、という訳である。

人の成長には、“成長してみないと、それがどんな良いことなのか、よく分からない”という性質がある(プロジェクト・マネジメントの能力など、その典型であろう)。また成長とは、自分で少し成長を実感できると、もっと学んでみたいと望む−−そういう、ポジティブ・フィードバック型のプロセスになっている。だからこそ、「待って支える」仕組みがとても大事なのである。

もし自分の周囲に良い報奨系が無ければ、きっと、「自分が成長できたあかつきには、さっさとここから抜けだそう」と考える若者ばかりになるだろう。そうなったら、教育システム構築のコストなど、すべて無駄になる。わたしたちの社会が、そんな状態にならないために、教育には「待つこと」と「支えること」が必須なのだということを、わたしたちは忘れるべきではない。

→「革新的生産スケジューリング入門」にもどる

オーケストラの指揮者かジャズ・バンドのリーダーか − プロジェクト・マネジメントの4つの類型を知る (2014/02/04)

前回、「プロジェクト・マネジメントの教育について」(2014-01-27)で、“PM教育の第1ステップは、自分たちが持つべきPM能力がどんなものかを考える”ことだと書いた。あるべき姿が決まらなければ、成長の道筋も決まらないからだ。当然のことである。

ところが、自分の組織に必要な『PM能力』というものに関して、どうも誤解が多いようだ。世の中にあるPM標準、たとえばPMBOK Guide (R)や、それに準拠した資格であるPMP(Project Management Professional)の習得が、「あるべき姿」だと想定している人も多い。あるいは、英国発のPRINCE2や、日本のP2Mでもいいが、これら標準書を教科書のように思い込み、その教科書に自分の現実の方をあわせようとする。これは、プロジェクト・マネジメントの標準化活動がもたらした副作用かな、と感じる。

わたし自身もPMPの資格を持っているし、PMBOK Guideがプロジェクト・マネジメントの世界に偉大な貢献をもたらしたことには、大いに感謝すべきと思っている。どんなプロジェクトでも共通に話せる言語・概念を確立したことは、とても重要だ。そこには、制定に尽力した米国人たちの抽象化能力が生かされている。しかしその反面、PMBOK Guideの普及は、プロジェクトの分野に対し"One-size-fits-all"な発想、つまりどんな種類の仕事にも同じ手法論が適用可能だ、という考え方ないし錯覚を広めてしまったようだ。今回は、この誤解を解き、プロジェクト・マネジメントのスタイルには4つの類型を区別する必要がある、という話をしたい。

いうまでもないことだが、プロジェクトには大規模なものと小規模なものがある。家一軒建てるのも、超高層ビルを建てるのも、等しくプロジェクトであり、共通の性質を持つ。だが、そのマネジメントの仕方が異なるのは当然だろう。あるいは、友人一人を呼んで食事をふるまうのと、友人100人を呼んで食事をもてなす違いを考えてもらっても良い。100人前となれば、材料の調達から下ごしらえ、調理、配膳までの十分な計画と、手伝ってくれる人の役割分担が必要である。あるいは自分では作りきれないから、仕出しなど外部サービスに委託しなければならない。100人来る訳だから、受付係や名簿や座席表もいる。出欠の急な変更や飛び入り、遅参などの連絡にどう対処するか・・etc, etc.

小規模なプロジェクトではその場その場で対処できることも、大規模プロジェクトになると、事前の十分な計画と、スタッフの専門分業的組織で対応しなければならなくなる。仕事の規模によって、マネジメントのやり方が変わるのである。こうした規模の違いに対するセンスを、わたしは『スケールアップ感覚』と呼んでいる。そして、大規模なプロジェクトでは、計数管理が必須となる。

もう一つ、プロジェクトの性格を決めるものとして、「自発型」か「受注型」かの区別があげられる。受注型の意味は、おわかりだろう。受託開発のSIプロジェクトとか、建設、造船などは受注型である(英語ではExternal projectという)。逆に、自発型(Internal project)とは、自らが発案して自ら実行するタイプのプロジェクトで、たとえば業務改革であるとか新製品開発とか新社屋移転などが自発型である。

受注型プロジェクトと自発型プロジェクトの最大の違いは、スコープ(遂行すべき責任範囲)が明確で他者から与えられるか、それとも自分自身で決められるか、にある。受注型では、契約書や要求仕様書によって、最初から文書化されているケースが多い。自発型ではそうはいかない。トップや関係者のもやもやとした期待からスタートし、プロジェクト・チームはまず、その内容を明らかにするところから仕事せねばならない。

もっとも、受注型といっても日本の顧客は欧米企業に比べて“自分が欲するものが何か”が不明確な場合が多く、請負側の提案するアイデアに依存する傾向がある。また、準委任契約で行う基本設計なども、スコープは受注側がそれなりに提案できる。だから、受注型か自発型かは契約形態だけで決まるものではなく、スコープの「明確さ」で測るべきものだろう。

これを図示すると、次のようになる。縦軸はプロジェクトの規模である。大規模になるほど、プロジェクト組織も専門分化した集団になっていく。横軸は受注型か自発型かの区別を表す。左の方がスコープが明確で、右に行くほどスコープは変幻自在、自分で決めるべき範囲が大きくなる。読者諸賢が普段たずさわっておられるプロジェクトは、どこらへんに位置づけられるだろうか?


<プロジェクトの4つの類型>
 (佐藤知一「プロジェクト・マネジメントの教育について」 スケジューリング学会プロジェクト&プログラム・アナリシス研究部会発表資料より(2014/01/16))

ちなみに、わたしの所属するエンジニアリング業界は、左上の象限の、大規模受注型プロジェクトが多い。プロマネは、きちんと計画を立案し、専門分化した大所帯のプロジェクト・チームを率いて、計数管理のツールを駆使しながら仕事を回していく。設計などの実務に手を動かしているヒマはないため、自身はマネジメント業に専念する。したがって、PMBOK Guideなどにあるような、WBSやEVMSやCPMといった、マネジメントの技術やツールの知識が重要である。

その対極にあるのが、右下の、小規模・自発型プロジェクトだ。少人数で、まったく斬新な次世代製品をデザイン・開発したりする種類の仕事である。そこでは、よって立つ契約や仕様書などないし、計数管理なども意味が薄い。大事なことはクリエイティビティや問題解決力であり、関係者と交渉し動かしていく説得力である。このような種類の仕事では、WBSの知識などなくても、メンバー間の協調と、一人ひとりの強いリーダーシップさえあれば、なんとか進んでいく。

両者をたとえていうならば、左上の大規模受注型プロジェクトはオーケストラのようなものだ。他種類の楽器からなる専門職集団を、一人の指揮者が引っ張っていく。指揮者は自分では演奏したりしない。演ずるべき曲(スコープ)は、作曲家から与えられる。これに対して、右下の小規模自発型プロジェクトはジャズ・バンドのようなものだ。指揮者はいない。バンドリーダーはいるが、ソロのときには各人がリードする。曲は、そのときの状況に合わせて自由に即興で演じていく。両者で、演奏をまとめるスタイルがまったく異なるのは分かるだろう。

図に戻ると、右上の象限は、大規模で自発型のプロジェクトである。これはかなり難易度が高い。こうした分野では、単なるプロジェクト・マネジメントではなく、その上位概念であるプログラム・マネジメントの方法論が要求される。日本のP2M(Project & Program Management)や英国のMSP(Managing Successful Programmes)などは、この領域をねらった標準書である。

ちなみに、PMBOK Guideは左上の、大規模受注型プロジェクトの領域を、暗黙のうちにターゲットとしている。これは、米国PMIで初期のPMBOK Guideの枠組みをつくった人たちの多くが、防衛産業・航空宇宙産業やエンジニアリング産業の出身だったからであろう。また右下は、巷間のリーダーシップ論で十分カバーされる世界である。

さて、残る左下の象限は、小規模の受注型プロジェクトだ。中堅・中小のSIerなどに多いタイプだが、こちらが簡単かと言えばそんなことはなく、別種の難しさを持っている。巨大プログラムが大型タンカーの航海のようなものだとすれば、中小の受注型プロジェクトはヨットの操縦である。タンカーは滅多に沈まないが、ヨットが沈んでも新聞記事にもなるまい。しかも、自分で行き先を決められる自発型プロジェクトとちがい、顧客の意向という名前の変わりやすい風を受けて、定められた目的地まで進まねばならない。制約が多く、自由度は少ない。きちんとしたコントロールが必要だが、大げさな自動化航行システムを乗せられるほど、船には余裕はない。WBSなど、ある程度のマネジメント手法と、簡略化した道具立てのバランスが必要なのだ。

<プロジェクト・マネジメント標準のカバー範囲>

そして、お分かりのとおり、左下の象限だけは、世の中にガイダンスとなる標準書や参考書が欠けている。だから、PMBOK Guideを勉強してPMPを取得してみたはいいが、何だか自分の仕事にはフィットしない、と感じる人が出てくるのである。世の中では、この左下のマネジメント類型に対するガイダンスが足りないと思う。だから、わたしが大学などで行っている教育は、ある程度この左下の象限を意識しているつもりだ(とはいえ、受講生がその意図を理解しているかは定かでないが)。

ここまで読んだ方の中には、“この佐藤という奴はPMBOKやP2Mを批判している”と勘違いする人がいるかもしれないが、それは誤解だ。どのプロジェクト・マネジメント標準書も、普遍性を志向している。ただ、それぞれが生まれたコンテキスト(歴史的文脈)や、前提している問題意識をよく理解して、それを使いこなさなければいけない。WBSとかEVMSとかいった技法は、ノウハウである。だが、それをいつどのように使うかは、各人に任されているのだ。G・ワインバーグの名言を借りて言えば、大事なのは「Know How(やり方)ではなくKnow When(しおどき)」なのである。

→「革新的生産スケジューリング入門」にもどる

プロジェクトにとって成功とは何か 〜ESC Lille PM Seminarより (2008/09/04)

8月17日から22日までの一週間、フランスのリールで開かれた"EDEN Project Management Seminar"に参加してきた。リールはベルギー国境に近い北フランスの古都で、フランドルの入口に位置する商業都市だ。そこに、Ecole Superieure de Commerce de Lille(略称ESC Lille)という、フランスでも有名なビジネススクールがある。ESC Lilleは、欧州におけるプロジェクト・マネジメント研究のメッカともいうべきセンターであり、そこで毎夏開催される"EDEN Project Management Seminar"は、実務家とアカデミックな研究者が各国から集い、最先端の研究報告や情報交換を行う場となっている。

私は今回、日本プロジェクトマネジメント協会理事長でESC Lille教授でもある田中弘氏のご紹介により参加招待を受け、最近の研究テーマであるRisk-based Project Value Analysisについて発表した(写真)。リスクの伴うプロジェクトにおいては最適予算が存在する、という講演内容は好評をもって迎えられたと一応感じたが、その話はまた別の機会にしよう。今回は、そのEDEN PM Seminarで聞いた内容の中でも、とくに面白かった講演をいくつか紹介したい。

ちなみに、世界のPM関連団体といえばProject Management Institute(PMI)が唯一最大で、標準といえば"PMBOK Guide"(A Guide to PM Project Management Body of Knowledge)第3版がグローバル・スタンダードであるかのように思っている人が、我が国(とくにIT業界)では多いようだ。しかし、このセミナーに集う人々の顔ぶれと意見を見れば、それは誤解であることがわかる。PMIは米国発の団体だが、欧州にはそれより古くからInternational Project Management Association(IPMA)が設立され活動している。そしてPMIの学術雑誌"Project Management Journal"の編集長Christoph Bredilletと、欧州を代表する論文誌"International Journal of Project Management"の編集長J. Rodney Turnerが、二人ともESC Lilleの教授であることを見れば、このセミナーの層の厚みが想像できるだろう。

前置きはこれくらいにして、まず、英Middlesex大学Darren Dalcher教授の"The Success School in Practice"という講演を紹介しよう。

元々実務家としてのキャリアをもつDalcher教授は、英国のプロジェクト・リスクマネジメント関係の諮問委員会のメンバーらしく、かかわった実例の中から、"プロジェクトにとって何が成功なのか"という根本の問題をあらためて問い直す。たとえば、彼自身が関わった2つのITプロジェクトで、A:片方は納期も予算も守ったが、成果物はろくに利用されなかったケースと、B:納期も予算も超過したがシステムは13年間にわたり使い続けられるケースを紹介する。いったい、A・Bどちらのプロジェクトが成功といえるのか? 

この問いは一見単純に見えるが、案外奥が深い。納期も予算も超過したら失敗だ、とプロマネなら答えるだろう。よく、「ITプロジェクトは7割が失敗といわれている」と語る人が多いが、実はこの数字は米国Standish Groupが発表している統計資料によっている。

その一方、顧客満足が最大価値であるから、システムを使ってもらった方が成功だ、と答える人もいる。経営論を学んだ人に多いような気がする。しかし、システム開発を受託する企業は慈善事業でなく、営利でビジネスを動かしているはずである。だとしたら、赤字を出して成功というのは、自社の経営戦略とマッチしないことになる(もっとも、ハード販売が利益の源泉でソフト構築は無償でも良い、というのが戦略なら別の話だが)。

さらにDalcher教授は、有名な英仏海峡のEuro Tunnel事業をとりあげる。大陸と英国を海底トンネルで結ぶこのプロジェクトは、予定の6倍の予算超過を引き起こした。旅客数は当初予想の1/3、いったんは倒産状態に陥る。巨額の借金棒引きにより、開通後14年後の今年になって、ようやく単年度黒に転じた事業である。彼は、これがプロジェクトとして成功か失敗かを問う。あなたの意見はいかがだろうか?

聴衆の意見はさまざまに割れた。納期やコストの点では明らかに失敗だ。ビジネスとしてもかなりの難点がある。トンネルは不法移民の移動手段にもなってしまった。しかし! トンネルのおかげで、ロンドンと大陸は非常に近く、便利になった(何しろリールからロンドンまで列車に座っていけるのである)。英仏両国の記念碑的協力事業となった。また、難工事だったかもしれないが、あの海底トンネルは技術としては偉大な成果ではないか・・・。

結局その答えは、誰にとって、どのような尺度で測るかに依存する。プロジェクトは、遂行を請負うプロマネの視点、発注当事者の視点、利用者等のステークホルダの視点、そして事業を取り巻く社会の視点がある。これに応じて、成功には次の4レベルがある、というのがDulcherの定義である。

レベル1 Project Management Success:納期・コスト・品質(スコープ)が守れること
レベル2 Project Success:プロジェクトの成果物に価値が認められること
レベル3 Business Success:プロジェクトがビジネスの成功をもたらすこと
レベル4 Future Ptential:プロジェクトが将来への可能性を生み出すこと

ふつうプロジェクトの成功は階層的にレベルを上がっていくと考えられる。しかし、それは必ずしも必須条件ではない。というのは、小さいレベルでは失敗だが、上のレベルでは成功というケースもあるからだ。たとえば、最初の二つのプロジェクトの例では、Bはレベル1では失敗だが、レベル2では成功だったわけである。ユーロトンネルの場合は、レベル1〜3まではことごとく失敗であった。しかし、レベル4の視点に立てば、成功と呼ぶことができる。そして、米Standish Groupが発表している「プロジェクト成功率統計」は、レベル1の成功率を示しているにすぎないことが分かるだろう。

私自身、受託プロジェクトの遂行をビジネスとするエンジニアリング業界に身を置いているため、どうしてもレベル1の狭い視点に限られる傾向があったようだ。そうした意味で、本講義はまさに目を開かれた思いであった。読者諸賢も明日からは、“頑張ってプロジェクトを成功させろ!”と号令されたら、「誰にとっての、どのレベルでの成功ですか?」と問いかけるといいかもしれない。あるいは、レベル0(Activity Success)というのを考えてみるのも面白いだろう。各アクティビティの担当者は過労でボロボロになったのに(レベル0=失敗)、プロマネは納期通り利益を上げて昇進・栄転した(レベル1=成功)、という風に。

さて、この講演でも分かるように、欧州では、より広いコンテキストからプロジェクトをとらえる思考様式を持っている。また社会との調和を重視しようとする点も、欧州的思考の特徴だ。これに対して、一般に米国では、明確に決められた枠組みの中で、量的にはかりやすい尺度でビジネスや物事を評価したがる。だからStandish Groupのようにレベル1に着目するのだ。プロジェクトの成功の判定に、両者のスタンスの差がくっきりと出てくる点が面白い。

このように、EDEN Project Management Seminarでは、興味深い発表が他にもいくつもあった。今回は長くなってしまったので、それらについては、次回紹介しよう。

→「革新的生産スケジューリング入門」にもどる

PMO(プロジェクト・マネジメント・オフィス)の命運 〜ESC Lille PM Seminarより(2)

前回に引き続き、8月にフランスのリール大学院ビジネススクール(ESC Lille)で行われたEDEN Project Management Seminarでの話題を紹介しよう。

ケベック・モントリオール大学のMonique Aubry教授が行った、"Making sense from PMOs through a multi-phases and multi-methods program of research" という研究発表はなかなか衝撃的だった。M. Aubryはカナダのベテラン研究者として学会では有名だが、何年かかけて継続的にPMO(Project Management Office)組織の実態調査を実践している。その結果の一部はすでにProject Management Journal(PMI発刊の学術誌)に発表されているが、それを概括した講演である。じつをいうと、私自身、昨年秋からエンジニアリング会社の中の一種のPMO組織に属することになり、その点でも興味深い話であった。

さて、Dr. Aubryによると、PMOという組織は2000年以降ポピュラーになり、さまざまな業種の企業・公共機関に生まれてきた。しかし、その機能や役割にはバラエティが多いという。そればかりでなく、数年間隔の調査の間に、目標や位置づけ、職務機能などが大きく変化するのが常であり、消滅している場合も多いという。彼女は、"PMOという組織はhigh mortality rate(高死亡率)であり、その平均寿命は2年程度である"と述べている。

この原因については、研究者らしく慎重な態度で「分析中」としている。が、PMO組織とは、プロジェクトに関するガバナンスの確立を共通使命としている。そのPMOが抱える、社内改革ならびにガバナンス確立という使命と、現実の組織がもつ変化への抵抗性の間の矛盾が原因であろうことは想像に難くない。PMO自体、永続的な組織ではなく、ガバナンス・システム構築という目標を達成したら解散すべきものだ、という考え方はあるだろう。しかし、わずか2年足らずでそのゴールを達成できる企業ばかりではないはずだ。

Seminarでは他にもPMO設立に関する事例研究発表があったが、PMOとは、作るのは易く、使命達成するのは難しい組織である、ということがうかがわれる。

もうひとつ、今度は日本人の発表をご紹介しよう。日本人と言っても、ギリシャの会社Consolidated Construction Company(CCC)の顧問をしておられる石倉氏の講演である。CCCは中東でも指折りの巨大建設工事会社だが、その立場から、中東における11のエンジニアリング・プロジェクトの現況を分析し、欧米コントラクターと日本コントラクターの違いを分析している(社名は明記されていないが、私の勤務先も明らかに含まれているようだ)。

評価軸は、建設マネジメントのパフォーマンス、設計・調達(E&P)のパフォーマンス、そして従業員満足度(Employee satisfaction)の3つの切り口で採点する。「顧客満足度」ではなく「従業員満足度」が入っている点が、いかにも多国籍建設会社である。多くの国から労働者を集めてプロジェクトを進めなくてはいけない企業にとって、従業員のパフォーマンスは死活問題だからである。

さて、石倉氏の調査によると、欧米コントラクターよりも日本のコントラクターのパフォーマンスには明瞭な差がある。むろんジョブ毎の差はあるが、3つの評価軸いずれでも日本は欧米を上回っており、とくにその差はE&Pのパフォーマンスで著しい(百点満点で日本75点vs.欧米59点)。"端的に言って、工事に必要なときに、必要なマテリアルと図面を供給できる能力の点で、大きな違いがある"という解説があった。

石倉氏はさらに、これをHackman & Oldhamのモチベーション・スコアリング手法を用いて分析し、現場に対してより大きなautonomy(権限委譲)とfeedback(発言力)を与えていることによるモチベーションの差があるのではないかと結論している。

ところで、すこし仏のセミナーで垣間見た、世界のPM標準化団体の動向について記しておこう。現在、世界のPM団体としては米国のProject Management Institute(PMI)が圧倒的な勢力を誇っており(会員数20万人以上)、またその標準書である"PMBOK Guide"(A Guide to PM Project Management Body of Knowledge)第3版が唯一のグローバル・スタンダードであるかのように、我が国(とくにIT業界)では受け取られている。

しかし、欧州やアジアでの情勢を見てみると、それは少し偏った理解である。例えば英国にはPRINCE2(PRojects IN Controlled Environments)という標準が'96年から存在しており、APM Groupが認定試験を実施している(今回のSeminarにはAlan Harpham会長が参加し講演している)。日本PM協会の田中理事長の解説によると、PRINCE2は“PJは放っておけば失敗する性質のものである”という認識が根底にあるらしい。したがって、プロジェクトの状況に応じて適用すべき手法を決める、との考え方に立っている。この試験は英国以外でも実施されている。

また、欧州には国際団体International Project Management Association(IPMA、本部スイス)があり、欧州各国およびインド・中国・韓国などのプロジェクト・マネジメント団体が参加している。IPMAはICB(IPMA Competence Baseline)と呼ばれる、PM資格認定制度の水準を統一するためのコンピテンシー標準を制定・発行している。IPMAは国別の文化・風土を尊重し、各国が独自の要件を追加変更することを認めている。こうした点が、PMBOK Guideこそ万国共通のスタンダード、と考える米国PMIとのスタンスの違いであろう。

欧州のPM関係者は、米国に比べると、プロジェクトを広い視点(事業の将来価値や社会との関わり)から見るという特徴がある。PMIが最近、Program Managementの標準を制定したのも、これに対応する動きのように感じられる。

現在、ISOではISO 21500と呼ばれる新しい標準を制定するためにISO/PC 236というWGを立ち上げている。これは英国標準局(BS)の提案になるものだが、内容は上述PRINCE2とは別のものである。ただし実質的にはPMIがこの動きに先制して参加し、方向性を主導しつつある現状であるという。

いずれにせよ、プロジェクト・マネジメントの世界は標準化・手法・理論のいずれの面でも急速に動いている。今回のセミナーでは、日本からの参加者は私を含め3人だけだった。国内にいるだけでは分かりにくい、世界の潮流を肌に感じるためにも、もっと多くの人がこうした集まりに参加するべきだと私は信ずる。

→「革新的生産スケジューリング入門」にもどる

プロジェクト・マネージャーが魔神に願うこと ―― 国際PM大会2013に参加して (2013/10/15)

クロアチアのドブロブニクという街で開かれた、国際PM協会(International Project Management Association: IPMA)の2013年度国際大会に参加してきた。なかなか得るところの大きい会議だったので、その中から、読者にも面白いと思われる話をご紹介しよう。

ちなみにドブロブニクという街は、東地中海(アドリア海)に面した港町で、古くから栄え、一時はベネチア共和国と覇権を争った。美しい中世都市の街並みがよく保存されており、風光明媚なため国際的な保養地としても知られる。旧ユーゴスラビアのクロアチアに属するが、飛び地であり、周囲はボスニア・ヘルツェゴビナに囲まれている。このため'91年の旧ユーゴ崩壊後の内戦で砲撃を受け、ユネスコが指定した世界遺産もかなりのダメージを受けた。今は平和に復興している。

世界には大きなPM組織が二つある。一つがこのIPMAで、主に欧州を中心とした各国が参加している。もう一つは米国のPMI (Project Management Association)で、こちらは標準書PMBOK Guide(R)の発行とPMP資格試験制度で知られ、日本ではこちらの方が有名だろう。両者は今からほぼ40年前、同時期に設立された。PMIは日本にも支部がある。

わたしは今回、IPMAの発起人の一人、英国のBarnes氏とも挨拶を交わしてきた。周知の通りプロジェクトの最大の制約条件は、「コスト」「スコープ」「スケジュール」の三つであり、これらは互いに関係しあっているため、『鉄の三角形』とも呼ばれる。この『鉄の三角形』という概念を提唱したのがBarnes氏であった(ということを、今回はじめて知った)。日本ではこの種の「概念作り」の意義があまり評価されないが、人々の理解を促進し、頭を整理できるということは極めて重要なことである。

今回の大会は約60カ国から参加者があり、発表申込は300件以上に達した(査読審査があるため実際の発表数はそれより少ない)。欧州中心と書いたが、北米・南米やCIS諸国・中央アジアからの参加者もそれなりに多い。

日本からの発表は、わたしを含めて3件。 大きなプレゼンスを世界に示したとは、残念ながら言えないだろう。他は、日本PM協会(PMAJ)の前理事長で、現在は北陸先端大や仏SKEMAビジネススクールの教授をされている田中弘氏による、メガプロジェクトに関する研究発表。もう一件は、現・IPA(情報処理推進機構)の大高浩氏の発表だ。ただし後者はあいにくわたしと時間帯が重なっており、聞きにいけなかった。

正直、こうした場で、自信を持って英語で持論を主張できる日本の大学人や実務家が、もっと大勢いて欲しいと感じる。その事は、JPMA (International Journal of Project Management)やPMJ (Project Management Journal)といった、世界トップクラスの研究雑誌への投稿の少なさを見ても、残念に感じることだ。たとえ多少間違っていても、持論を主張する。それに対して、議論が巻き起こる。そうした議論を通じて、参加者がみな、より高い認識を共有することができる−−これが西洋人の発想である。正しいこと以外を口にすると叱られるような学校教育を受けると、この大切な線が見えにくくなる。

それはともかく、IPMAの大会は特定の業種分野に偏らず、公共・エネルギー・建設・IT・エンジニアリングなどいろいろな事例を聞けるのがいい点だ。とくに今回は、Project portfolio management / Program management といった、プロジェクトよりも上位概念に位置するマネジメントのあり方の議論や、リスクマネジメント、スケジューリング関係の講演が充実していたように思う。

周知の通り、プロジェクト・マネジメントの世界ではISO 21500という標準規格が昨年制定された。これはISO 9000 QMSなどと違って認証制度を取らないことが合意されている。この企画の延長として、現在ISO 21502というProgram Managementの検討が始められた。リーダーはドイツのWagnerという人である。

ちなみに、この審議は日本が事務局をやることになっている。日本側の体制は、PM学会と日本企画協会の共同である。ちょうど大会に、日本のPM関係のISO活動に関わってこられたNECの田島さんが来られていたので、いろいろと(ここには書けないような裏事情も含めて)聞くことができた。

リスクマネジメントについていえば、この分野はやはり発展中だ。逆にいえばまだ十分完成されていない訳で、「リスク」の用語・概念一つをとってもかなりの幅がある。これに関連して、PMBOK GuideでいうRisk Breakdown Structure (RBS)なるものの有効性について、わたしといく人かの発表者の間で議論になった。PMBOKのRBSの例が、なげやりでできがあまり良くないことについては、先月の日本のPM学会でも指摘があったところだ。

細かい議論を一つ一つ説明していても切りがないと思うので、最後に一つ、この大会で聞いた傑作と思えるジョークをご紹介しようう。キーノートの司会をした英国の Peter Taylor氏の講演で聞いた話だ。氏は"Lazy Project Management"という興味深いタイトルの本の著者で、壇上に上がる時にはディープ・パープルの名曲「Lazy」(古いなあ^^;)をテーマソングにかける。

ところで、彼が近くの浜辺を歩いていたら、古いオリエント風のランプを見つけた、という(ドブロブニクはオリエント世界に近い)。汚れているので、ハンカチを取り出して磨き始めてみたら、おお! お約束どおり、中から魔神が現れて、彼にいった。

「お前がランプをこすったのか。ならば、一つだけ願い事を聞こう。」

彼は考えた。自分はプロジェクトでよく米国に行く。ところが飛行機が大嫌いなのだ。空港に2時間前にいき、面倒な手続きをして、セキュリティチェックではベルトから靴の果てまで脱がされ、おまけに何時間も遅延で待たされる。

「そうだ。たのむから大西洋に橋をかけてくれないか。そうすれば車で行ける。」
「大西洋横断の橋か。そりゃ、かなりのプロジェクトじゃないか。たしかに俺は偉大な魔神だ。しかし・・もうちょっと別の願いはないのか。」

別の願い。プロマネとして、本当に願いたい事は何か。彼は思いついていった。

「それじゃあ、こうしてくれ。これから関わるプロジェクトでは全部、顧客もステークホルダーも、最初の日に自分たちの考えを決めて、それ以降は絶対に気を変えない、と。これが一番の望みだ。」

すると魔神は首をふって答えた。

「わかったよ。大西洋横断橋は片側何車線が欲しい?」

・・どんな魔神でも、人の気が変わることは防げないのだ。

→「革新的生産スケジューリング入門」にもどる

プロジェクト・マネジメントの理論は科学たり得るのか 〜 EDEN PM Seminarに参加して (2014-09-15)

8月下旬に、フランスのリール市で開催されたPM研究の国際セミナー "EDEN PM Seminar" に参加してきた。招待を受けて1時間ほどの講演をし、また他の発表を聴きながらPM理論の専門家達とネットワーキングを深める、楽しい4日間だった。わたし自身は2008年、2009年につづき、3回目の参加である。

EDEN PM Seminar は、EUの資金援助をえて、毎年夏に開催されるセミナーだ。会場はフランスのSKEMA Business School経営大学院が提供している。SkemaはPM専門の大学院(博士課程)を持ち、欧州のPM研究のメッカといわれている。このセミナーにも、欧州を中心に、米国・中東・アフリカ・南アジアなどから多くの参加者があった。セミナーを実質的に仕切るのは、長年International Journal of Project Management誌の編集長を務めるR. Turner教授である。

今年のテーマは、「Challenging Projects」。難しいプロジェクトの計画・遂行・評価をめぐって講演発表と議論がかわされた。わたし自身は、「Projects in Distant Terrains: Arctic, Deserts, and Rain Forests」と題して、わたしの勤務先が関わってきた遠隔地プロジェクト(アルジェリアの砂漠、パプアニューギニアの熱帯、そして北極圏)のケーススタディ分析と考察について報告し、好意的なフィードバックを多くの方から得た。ただし自分の講演の内容説明は別の機会にゆずることとし、今回はもっぱら、他の講演を聴いて考えたこと、感じたことなどを述べてみたい。

面白い発表はたくさんあったが、たとえばNASA(米国航空宇宙局)のRoger ForsgrenとEd Hoffmanの2人による「Projects in Difficult Terrains at NASA」をあげておこう。NASAはある意味、プロジェクト・マネジメントの育ての親であり、現在のPMの概念や手法論の多くがここから巣立っている。Dr. Forsgrenの講演は、地球外環境という極限領域における機材設備の設計や、乗組員の保護方法といった技術論を語るもので、エンジニアリングの観点から非常に興味深かった。-100℃から+100℃に数分程度でかわる温度、宇宙線、真空、荷電(宇宙空間にはプラズマが飛んでいる)、そして飛来する宇宙のゴミdebrisなどから、どうやって機材を守るかといった話である。地球外探査のVoyagerなど、その過酷な環境を、もう36年間も航行しつつ、いまだに地球に信号を送り続けている。たいしたものだ。

ちなみに彼によると、NASAは2025年までに火星に人を送り込みたいと計画している。航続期間は年単位であり、それだけの長きにわたり乗員が暮らせるような宇宙船の仕様を考えなければならない。また、とくに火星からの離陸と帰還が大きな課題である。それゆえ、会場からは「装備を軽くするために、NASAは乗員にone way ticketを渡す考えもあると聞いたが」との質問が出た。片道切符、つまり火星からは戻れないという条件で希望者を募る、という意味である。そうすれば装備はずっと簡単になり、実現可能性も高まる。広い米国には、それでも希望者は出るだろう(ジュール・ヴェルヌの「月世界旅行」はまさに帰還を考えない飛行の話だった)。しかし、「倫理的観点から、それは行わないだろう」との回答だった。

しかし、Dr. Hoffmanの話の方は、もっと含蓄に富むものだった。Dr. Hoffmanは、見かけはいかにも気のいいアメリカ人のおっさんだが、なんとNASAのChief Knowledge Officer(CKO)である。その彼のテーマは「Projects in Hostile environments」で、この『敵意に満ちた環境』として、彼は4つをあげる。まずは、Rough neighborhoods、つまり友好的でない隣人・国家。次がTyrants、つまり専制君主的なボスである。ここらへんから話はぐっと人間くさくなる。ある種の毒性のあるリーダーシップtoxic leadershipを発揮する連中がいて、彼らは部下に対して、"you are working for me, not for you."という態度で支配をはじめるのである。

3番目に、彼は「プロジェクト 対 組織」という対立の問題をあげる。NASAも役所であり、プロジェクトという一時的なチームと、永続的な組織との間にはしばしば緊張関係がある。そのよい例が、ゴダード宇宙センターの科学者Mather博士が発案したCOBE Projectであった。COBEは宇宙マイクロ波の背景放射を関するするための人工衛星であるが、この計画はスペースシャトル「チャレンジャー号」の爆発事故による影響で、NASAの中でキャンセルされてしまう。

しかし、そのときのプロマネは、「俺の仕事は解決策を見つけることだ My job is to find a solution.」と宣言し、なんと英国など他の国の宇宙機関からこれを打ち上げるべく活動をはじめる。結局、COBEは最終的には米国から打ち上げられることになり、その観測結果が宇宙ビッグバンを実証して、Mather博士はノーベル賞を受賞するのだが、これは、このときのプロマネの組織をこえた使命感がなければ実現しないものだった(この一部顛末は"The Very First Light"という本になってまとめられている)。Hoffmanが4番目にあげたのは文化的衝突 culture clash であった。

とはいえ、NASAの宇宙の話を聞いているとSF少年に戻ったみたいで、ワクワクと楽しい。それにひきかえ、地上でのプロジェクトは困難が多く、楽しいばかりではない。たとえば、途上国における援助プロジェクトである。ここでは、今回の発表の中でも秀逸だったDr. Lavagnon Ikaの「世銀の監督はプロジェクトに影響を与えるか? Does World Bank project supervision influence project impact?」を紹介しよう。Dr. Lavagnon Ikaはアフリカのベニン出身で、現在はカナダのオタワ大学で働く優秀な若手PM研究者である。

彼はまず、世界における国際援助の統計をざっと紹介した上で、「果たして国際援助というのは機能しているのか?」と問題を投げかける。そして、"Aid is part of the problem and even is the problem”という途上国側の意見 (Moyo, Zambia出身)を紹介する。経済学的な実証研究からみて、マクロ経済学的には、国際援助額とその国の成長との間には相関が見られない。ただしミクロ経済学的な、プロジェクトレベルでは、たしかに有効性は確認されることが多い。ここには、マクロとミクロの矛盾があるのである。

そこで彼は、世銀のSupervisor制度について、215ものプロジェクトを対象にサーベイ研究を行うのである。世銀は自分が融資したプロジェクトに対して、Supervisor制度をもうけている。彼らは、プロジェクトの成功のためのカギ(Critical success factor)として、以下の5つを考えている。
- Monitoring
- Coordination
- Design
- Training
- Institutional environment

ところでDr. Ikaは、最近のPM理論のトレンドにしたがって、プロジェクトの成功を、『遂行上の成功』と『インパクトにおける成功』に区別する。「上手に遂行できた(予算や納期を守った)」ことと、「プロジェクトが良い効果を生んだ」ことは別だと考えるのである。この二つは、残念ながら日本では、まだきちんと区別されずにごっちゃに論議されがちである。

その上で、彼は調査分析の上で、世銀のProject supervision制度は、『遂行上の成功』はたしかに促すが、『インパクトにおける成功』はもたらしていないことを明らかにするのである。Supervision制度は、プロジェクト全体費用の 3%-5% を占めている。金額にすれば、かなり高額だ。だから、とくにプロジェクト計画段階におけるsupervisionをもっと充実させるべきだ、というのが彼のリコメンデーションである。

プロジェクトには、直接の成果物(output)と、それが生みだす結果(outcome)、そして、プロジェクトがもたらす効果・影響(impact)がある。それは短期・中期・長期的なプロジェクトの評価に対応する。こうした視点が、世銀をはじめとする海外援助にはまだ欠けている、というのが彼の問題意識であった。日本のPMコミュニティでの議論を思い返すにつけ、同じ思いを、わたしも感じた。

さて、このEDEN PM Seminarには、最新のPM研究の成果報告と別に、もう一つの柱がある。それは、SKEMA Business Schoolで学ぶ博士課程の院生(PhD Candidate)が、並みいる世界のPM研究者達の前で、学位論文の最終発表と審査を行ったり、博士研究の提案(Proposal)をしたりするのである。これを聴いていると、欧米におけるプロジェクト・マネジメント理論の研究がどのような形で、いかなるレベルで行われているかを目の当たりに見ることができる。

たとえば、以下はLynn Keeysという院生の研究提案のスライドからとったものである。研究パラダイムとしてはConstructivism(構築主義)をとり、コンセプトとしては「企業の持続的発展(SD)戦略から、プロジェクトのSD戦略の創出」をかかげ、理論として「創出的戦略(Emergent Strategy)」に依拠して、以下、モデルの提案、方法論と研究戦略、具体的研究方法・・という風に続く。

これを見ると、欧米(とくに欧州)の研究では、方法論を重視し、博士課程の院生はそれを徹底的に叩き込まれることが分かる。「これこれを調べてみました。するとこんな結果になりました。だから自分はこう考えました」では、全然研究として認められないのである。わたしは前回、アメリカ人の院生が、自分の所属するデミング賞認定機関の過去データを分析して、品質改善プロジェクトについて研究提案をしたのを覚えている。たしかにそれだけのデータがあれば、かなり面白い分析ができるだろう。しかしそのときは、会場にいた大御所のLynn Crawford教授から、「あなたはどんな理論的枠組みでそれを分析しようとするのか」と問いかけられ、うまく答えられずにコテンパンにやられるのを目撃した。

なぜ、単に事実を報告し分析するだけでは研究としてダメなのか。それは、プロジェクト・マネジメント研究、いやマネジメント研究一般の根幹に関わる問題である。プロジェクトというのはその定義上、本質的に一回限りであり、同じものは二度とない。同じものが何度も繰り返されるなら、それはプロジェクトではなく「定常業務」になってしまう。そして、多くの人間が関わる作業であり、その報告も基本的に言葉を通じてなされる。数字はあるだろうが、言葉の説明も必須だ。

このような条件で、プロジェクト・マネジメント研究が科学的な客観性を保つためには、どうすべきなのか。単に観測事実を論評するなら、評論家、いや街場の居酒屋トークと何も違いがないことになる。それが研究であるためには、そして他の人にも普遍的に役立つためには、自身の研究スタンスや、その限界について、きわめて意識的でなくてはならないのである。わたしは今回、オイル・メジャーで働くエチオピア出身の院生に声をかけられて、研究のアドバイスを求められたが、彼の研究ノートにも、こうした方法論がびっしりと記述してあった。

そして、このような思考の態度を身につけることが、ドクターの学位を得ることの意味なのだろう。Skemaで博士号をとろうとしている院生達は、ほぼ全員、社会人である。修士課程を出て、そのまま博士に進んでいる院生は一人も見かけなかった。そして、ほぼ全員が、中年である(^^;)。これは、プロジェクト・マネジメント研究という分野の特徴なのだろう。学士か修士でいったん、社会に出る。そしてプロジェクトに従事する。だが、年月を重ねるうちに、しだいに内なる問題意識が強まってくる。そうして、もう一度きちんと考え直してみたいと、大学に通い始めるのだ。電子工学の研究なら、20代前半でまったく問題ない。だがプロジェクトでは、自分がマネジメントにかかわった経験年数がものをいう。

言い忘れたがSkemaでは、PMの博士号は、遠隔地で働きながらとることができるシステムである。限られた回数の集中講義は必要なようだが、あとは指導教官たちとやりとりしながら研究を進められる。今回もフランス以外の国から大勢の院生が集まっていた。欧州からも、北米も、南米も、アフリカ、中東、南アジア、中国などから、皆が学位取得の情熱を持って参加している。この人達は、別に全員が大学の先生になろうと思っている訳ではない。じっさい、Seminarで講演する側の人間も、(わたし自身を含めて)実務社会で働いているものが約半数である。今回、パキスタンでPM協会を立ち上げて会長を複数期つとめたDr. Khalid Khanと知り合い、何となく意気投合した(同じ化学工学出身だったのだ)が、彼も働きながらSkemaで学位を取った人だった。

なぜ、彼らは、自身がプロジェクト・マネージャーとして忙しく働きながら、なお、博士研究までしようとするのか。別に大学教授になろうという訳でもないのに。それはたぶん、二つの理由があるのだろう。一つには、彼ら自身が持つ、使命感である。何とかプロジェクト・マネジメントというものを良くしたいとの使命感。もっとプロジェクトの成功率を高めたいという、強い熱意。もう一つは、おそらく社会の側にある。欧米、あるいは植民地として欧米の影響下にあった国々もそうなのだろうが、こうした地域では、博士号を持った、つまり高度に知的なリソースをもった人材を、それなりに遇する制度があるのである。研究職だけでなく、ビジネス部門や行政職でも、そうした人々を活用する仕組みがあるらしいのだ。

ひるがえって、わたし達の社会ではどうか、とつい思ってしまう。日本にはあいにく、そもそもプロジェクト・マネジメントの博士課程を持つ大学は存在しない(わたし自身は化学システム工学という専攻科で、「ほんとに化学と無関係な、マネジメント研究でもいいんですよね?」と指導教授に念を押しながら学位を得た)。社会人博士も、通常は、週に1,2回、大学に通う必要がある。そして、企業では、博士号を持っている人は研究所勤めが普通である。だから、マネジメントの研究で学位を取ろうというモチベーションが、きわめて得にくい。その結果として、「プロジェクト・マネジメント理論が科学たり得るためには、どうしたらいいか?」といったレベルの議論ができる場所も、極めて限られている。

わたしはこのような現状を、とても残念に思う。研究というのは、すべて科学や医学や工学といった、製品開発に直接結びつく「実学」であるべきで、Management Scienceとかマネジメント・テクノロジーとかいった分野があろうとは思いもよらない、という知的風土に、わたし達は育った。そして、そのことが、我々の社会のブレイクスルーを阻害しているのではないか。まあ、そうした大げさな問題をわたしがすぐ解決できるとは思わないが、せめて自分が主催する研究部会くらいは、こうした問題のフレイバーだけでも議論できる場所に育てたいのである。

もちろん、今だって、たとえばそれこそ仏Skemaに遠隔入学するという手段はある。現時点では、残念ながら日本人の院生はゼロだった。主要大国でゼロなのは、たぶん日本だけだろう。こういう現状を何とかしたいと、わたしも微力ながら思うのである。そして、プロジェクト・マネジメントの実務に日夜苦労していて、この状況を何とか変えたいと願う人が、知的な出口を見つけ出せる社会になってほしいのだ。

<関連エントリ>
 →「サービス、『感情労働』、そしてプロジェクト・マネジメント」(2011-08-18) (Constructivism「構築主義」について)

(追記:今回のSeminar参加にお声がけいただき、講演機会を得るチャンスをくださったSkema客員教授の田中弘氏に改めて感謝します)

→「革新的生産スケジューリング入門」にもどる

埋没コストの原理と、プロジェクト・ポートフォリオ・マネジメントのためのDIPP尺度 (2013/04/10)

マネジメントの原理・原則にはいろいろあるが、『埋没コストの原理』ほど、学ぶのは簡単ながら実践がむずかしいものはない。埋没コスト(Sunk cost)とは、すでに使ってしまったお金のことである。埋没費用とか埋没原価とも言う。使ってしまったお金はもう使ったのだから、それが幾らであったにせよ、現時点での意思決定がそれに左右されてはいけない。「意思決定は、今とこれから先の事象だけで考えるべきだ」、というのが『埋没コストの原理』である。とても単純だ。だが、人は“それまでの経緯”にひきずられて思考しがちだから、実際には難しい。

たとえば、こんな例を考えてみよう。ある女性が、8千円の演奏会のチケットを買っていたとしよう。なかなか高価だ。ところが、コンサート会場についてハンドバッグの中を見てみると、肝心のチケットがない。忘れたのかもしれず、無くしたのかもしれない。ともかく窓口にきいてみると、まだ8千円の席は残っているという。一応お金は持っている。そして演奏会は今夜一度だけだ。さて、この女性はどうすべきか? 買い直して入るか、あきらめてかえるか?

もし、そのコンサートが本当に8千円分の価値があると信じるのだったら、買い直して入るべきなのである。なぜなら、無くしたか忘れたかはともかく、前に買ったチケットに払ったお金はもう戻ってこないのだから、『埋没コスト』なのだ。問題は、今現時点で、まだ席があり、支払い能力があるのなら、「演奏会の内容」と「8千円という対価」の比較になるからだ。この女性にとっては、演奏会の方が価値があるはずである(だから以前チケットを買ったのだ)。

それなのに、この問題で判断が分かれるのは、「演奏会に1万6千円分の価値はあるか?」という問題設定にしてしまう人が多いからだ。上記は行動経済学者カーネマンが出題した例だが、彼は「仮にその女性の当月の収入がたまたま8千円少なかったとして、さてその場で演奏会のチケットを買うかどうか、という問題だったら、ほとんどの人は“買う”と答えるだろう。それなのに、論理的には同じ問題を、“一度買ったチケットを無くした”という形で出題すると皆が迷うのは、失った8千円をコストの側に計上してしまうからである」と解説している(カーネマン「ファスト&スロー (下): あなたの意思はどのように決まるか?」下巻第34章)。

同じような問題は、もっと大規模なプロジェクトにおいても発生する。固有名詞はあえて書かないが、北関東のあるダム建設プロジェクトをめぐって、過去何年間も継続か中止かが政治的議論になっている。この議論の根幹にあるのは、官僚機構にはいったん発進した公共プロジェクトを停止するための判断基準も仕組みも存在しない点にある。しかし、議論を難しくするもう一つのポイントが、“すでにあれだけ巨額の税金を投じてしまったのだから、今それを中断することは勿体ない”という思考である。もちろん、ごく自然な発想だ。だが、経済学的な埋没コストの原理からいくと、過去どれだけの費用を投じたかは関係ないのである。判断は、「この先いくらかかるのか」と「完成したダムにどれだけ価値があるのか」の比較だけで決めるべきだからだ。

このように、プロジェクトの継続か中止かという問題は、規模の大小を問わず難しい。現実には、過去に投下した努力や費用やメンツが関わってくるからだ。

「これから先、いくらかかるのか」の指標を、マネジメントの専門用語でCost ETCと呼ぶ。ETCは、Estimate to Completeの略である(ついでにいうと、「この先、あと何日で終わるのか」はTime ETCと呼ぶ)。プロジェクトが出発した時点での予算がいくらだったかはともかく、進行中の現時点で、終わるまでに必要な費用を言う。また、官僚時点でのプロジェクト全体のコストを、Cost EAC (Estimate at Completion)と略称する。日本の建設業会計ならば、「完成工事原価」と呼ぶ項目だ。

さて、“プロジェクトを発進するか”“プロジェクトを中断するか継続するか”の決定は、プロジェクト・ポートフォリオ・マネジメントと呼ばれる領域に属する。普通、そこで一番大事なのは、プロジェクトの経済性評価である(学術研究等の純非営利的なものは例外だが)。この経済性評価尺度には、回収期間法とか、DCF法のNPV/IRRとか、いろいろあるが、共通する問題点が一つある。それは、どれも「全費用」対「全収益」の比較をしている点だ。これは計画時点での評価にはいいが、上で述べたように進行中のプロジェクトの評価では問題がある。それは埋没コストの原理を忘れている点だ。

この欠点を解決する指標として提案されたのが、DIPPという尺度である。DIPPはDevaux's Index of Project Performanceの略で、前々回紹介したDRAGや、前回のDrag Costと同様、Stephen Devaux氏の考案による。

DIPPの定義はきわめて単純である:
 DIPP = EMV / Cost ETC
 
ここで、EMVはExpected Monetary Value、すなわち「プロジェクトが稼ぐ期待収益」だ。それを「これから先、かかる費用」で割っただけ。たとえば、今、4つのプロジェクトがあり、それぞれ進行中だったり計画段階だったりするとして、以下の表のようになる。

------------------------------------------------------------------
Project EMV  完成予定日 Cost ETC DIPP 遅延コスト(週あたり)
A    1,000   8/01   200   5.0   5%
B    2,000   10/01  1,000   2.0  10%
C    5,000   11/25  2,000   2.5  20%
D    10,000   12/30  3,000   3.3  10%
全体  18,000       6,200   2.9
------------------------------------------------------------------

とても単純だ。さて、今、ここに新たなプロジェクトの案件が舞い込んできたとする。それをProject Eとしよう。

Project EMV  完成予定日 Cost ETC DIPP 遅延コスト(週あたり)
E    12,000   02/10  3,000   4.0  20%

この案件が、他に何の影響も与えないのなら、収益性も高いし、ぜひポートフォリオに組み込みたいところだ。ところが、社内の人員には限りがある。既存の4つのプロジェクトの納期に多少影響を与えるだろう(その影響度は、まともなスケジューリング・ソフトウェアを使っていれば、すぐに計算できる)。そこでシミュレーションを行ってみたところ、以下のようになることが分かった。

------------------------------------------------------------------
Project EMV  完成予定日 Cost ETC DIPP 遅延コスト(週あたり)
A     800   8/29   200   4.0   5%
B    1,200   10/29  1,000   1.2  10%
C    2,000   12/16  2,000   1.0  20%
D    4,000   03/13  3,000   1.3  10%
E    12,000   02/10  3,000   4.0  20%
全体  20,000       9,200   2.2
------------------------------------------------------------------

ここで、納期遅延に応じて、各プロジェクトの期待収益EMVが下がっていることに注意してほしい。つい欲張って、プロジェクトEを優先的に組み入れたがために、ポートフォリオ全体でのDIPPは2.9から2.2に下がってしまった。これでは、何をやっているのだか分からない。

・・というのは無論、机上の計算である。現実には、これに根性論だとかメンツとか行きがかりとか顧客のつきあいとかが混入してくるのは、周知の通りだ。しかし、くどいようだが、こうした計算を知った上で決断するのと、知らずにカンで決めるのとでは、長い間には大きな差がつくと思った方がいい。そして、このような評価は、埋没コストを考慮しない通常のDCF法などでは計算できない点に、あらためて注意してほしい。

DIPPという指標は、プロジェクトの進行とともに増大する性質がある。これはゴールが近づくとともに、定義式の分母がだんだん減っていくのだから当然である。そして、異なる進捗状況のプロジェクト間で、費用や人員配分など何かの優先順位を決めたいときには、DIPPの大きな方、いいかえれば「完成間近な方」を選ぶことが合理的となる。

これまで3回にわたってS. Devaux氏の提案した手法について解説した。いずれも、'90年代に米国で提案され、防衛産業などでそれなりに普及している手法である。わたしがこれを知ったのは、2003年にボストンで行われたProject World in Boston大会においてだった。この大会では、これ以外にも種々の手法や技術の提案があり、アメリカでは優秀な人材がどんどんプロジェクト・マネジメントの世界に集まって来ているのだな、と肌で感じた。

爾来10年。DRAG, DIPPをはじめ、日本ではそうした最新のアイデアがほとんど紹介されず、いまだに「PMBOK Guideという教科書」の枠内での知識や、自社内でのトライ&エラーの工夫報告が主流なのは残念である。Devaux氏の著書"Total Project Control: A Manager's Guide to Integrated Project Planning, Measuring, and Tracking"(John Wiley & Sons, 1999)も、わたしは社内教育に一部を使っているが、日本ではまだ翻訳がされていない。彼は近々また著書を出す予定らしいが、わたし達ももう少しアンテナを敏感にしてもいいのではないかと思うのである。

→「革新的生産スケジューリング入門」にもどる

プロジェクトにおけるタスクの価値を計算する (2006/11/18)

米国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%となるのだ。製品開発プロジェクトは、いや一般に全てのプロジェクトは、複数の人間が協力して、一度限りの目標を達成するための、リスクを伴う活動である。そこではリスク基準による貢献価値の理論が活きてくる。その考え方と具体的計算方法については、次回書こう。

→「革新的生産スケジューリング入門」にもどる

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

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の拙論文を見ていただきたい。

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

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

→「革新的生産スケジューリング入門」にもどる

プロジェクト・マネジメントは組織としての能力である (2008/06/02)

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

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

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

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

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

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

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

→「革新的生産スケジューリング入門」にもどる

プロジェクト・マネジメントにリーダーシップ論は要らない (2007/07/09)

昨年、国内最大手のシステム・インテグレーターの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)に、なぜ『リスク』の語が入っていないのか、私は常々疑問に思っている。もしあなたが、ジャンボ・ジェットの運行をプロジェクトだと思えないとしたら(上記の定義にはぴったり合っている)、それは、そこに失敗のリスクをほとんど感じないからだ。だから、プロジェクトの定義には「リスクをともなう」という一語が追加されなければならない。

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

→「革新的生産スケジューリング入門」にもどる

海外プロジェクト・マネジメントにおけるシステムズ・アプローチとは 〜化学工学会展望講演(9月9日)から〜 (2015/09/15)

・・・ただいまご紹介いただきました日揮の佐藤です。本日このセッションには、アカデミアの先生方、また実務界の諸先輩が大勢お見えになっていると思います。そこで、まず皆さんに考えていただきたい問題があります。

時は紀元前215年のこと。秦の始皇帝は、北方の異民族・匈奴の侵入を防ぐため、部下の将軍・蒙恬に城壁の建設を命じました。 今日「万里の長城」として知られるものの原型で、歴史に残るビッグ・プロジェクトでした。

しかし、長城はなかなか完成しません。そればかりか、苦役にかり出された民の怨嗟の声も届きます。そこで始皇帝は、自分の長男・扶蘇を現地に派遣し、建設事業の状態を調べることにしました。では、扶蘇が現地でまず調べるべき事は何でしょうか? ご自分が始皇帝なら、何を調べろと扶蘇に命じますか?

(本サイトの読者諸賢も、この先を読む前に、ちょっと考えてみてください。)

次に、第二問です。
今度は、皆さんは化学企業の経営者になったと想像してください。そして自社の業容拡大のため、南米の新興国に新しく化学プラントを建設することにしました。

皆さんは部下をプロマネに任命し、現地に派遣しました。しかし、プラントはなかなか完成しません。現地のパートナー企業の不満の声も届きます。そこでTV会議で現地のプロマネを呼び出し、話すことにしました。では、皆さんがまず質問すべき事は何でしょうか?

いずれも、遠隔地で遂行する「問題プロジェクト」の実態を調べるケースです。

最初のケースについて、詳しい史料が残っているかどうか、寡聞にして知りません。しかし想像するに、2000年前の扶蘇がが訊ね、調べたのは、こんな事だったのではないでしょうか?

− いったい今までいくらの費用を使ったのか?
− 長城の建設はいつ終わるのか?
− そもそもこの蒙恬将軍という男は、どういう人物か? はたして信用できるのか。

では、二番目のケースについてはどうでしょうか。まさか、現代人の皆さんが、2000年前の扶蘇と同じことをたずねて良い訳はないですよね? 現代ならば、プロマネにたずねるべきは、こんな質問のはずです:

− プロジェクトの『スコープ』はどうなっているのか。WBSを見せろ。
− このプロジェクトの『クリティカル・パス』は何か? アクティビティ・ネットワークの上で示せ。 主要なリスクは何か?
− 現在までのPV, AC, そしてEVはいくらか。完成時のCost EACを予測せよ!

現代のプロジェクト・マネジメント理論(以後『モダンPM』と略称することにします)が生まれたのは、20世紀中盤のことでした。モダンPMは、1950 年代にデュポン社が化学プラント建設プロジェクトの工期予測のために開発した、スケジューリング手法である”Critical Path Method” (CPM)に始まります。

このCPMは、プロジェクトを複数の要素作業(アクティビティ)から構成される『システム』としてモデリングした、システムズ・アプローチの産物です。プロジェクトを構成するアクティビティのネットワークを考えたとき、プロジェクトの全体工期はネットワークの始点から終点までを結ぶ最長の経路=クリティカル・パス(Critical Path)によって決まる、というのが、CPMの理論的骨子です。

クリティカル・パスに属するアクティビティの比率は、実規模のプロジェクトでは全体の2〜3割程度と言われています。他のアクティビティは、日程上のフロート(余裕日数)を持っているのです。そしてクリティカル・パス上の仕事が遅れた場合、他の仕事をどんなに頑張っても、プロジェクト全体の納期が遅れます。だから、納期遅延のおそれのあるプロジェクトでは、状況把握のために、まずクリティカル・パスがどこにあるかを問うのです。

またCPMは、スケジューリングとコスト管理に際だった違いがあることを示しています。コストの世界では、どこかのアクティビティで1円得すれば、プロジェクト全体で1円、得します。単純な足し算の論理です。しかし、時間の世界はそうなりません。フロート(余裕日数)を持つアクティビティを、いくら頑張って短縮しても、プロジェクト全体の納期にはちっとも貢献しないのです。プロマネはどこがクリティカル・パスになっているか、つねに意識し、そこに集中すべきです。だから、現代でプロマネに問うべき3つの質問に、この項目が入っているのです。

さて、モダンPMの発展史で次に議論になったのは、「プロジェクトはどのようにアクティビティに分解すべきか」という問題でした。ここで確立したのが、WBS(Work Breakdown Structure)という概念です。プロジェクト全体のスコープ(作業範囲)をアクティビティで階層的に構成し、管理番号を付番したものをWBSと呼びます。各アクティビティは、達成すべきアウトプット(成果物)と、必要なインプットが決められており、担当する人とリソースを割り当てる 必要があります。また、それをさらに下位のサブ・アクティビティに階層的に分解することができます。

WBSはスコープ、すなわちプロジェクトの責任範囲を可視化したものです。またWBSはプロジェクト組織の分担の表現でもあり、またコストをロールアップし集計する際の基準にもなります。ですから、WBSをよく見れば、どのようにプロジェクトを進めようとしているのかがすべて見て取れます。だから問題プロジェクトの状況把握では、最初にWBSについて質問するのです。

このようにWBSはモダンPMにとって非常に重要なのですが、多少の論争がありました。ある人々は、プロジェクトを、仕事のプロセスに沿った機能別・仕事の種類別に分解すべきだと考えました。これをFunctional-WBS(略称F-WBS)といいます。たとえば化学プラント建設を例にとると、基本計画・設計・調達・建設・試運転・・といった分解になります。

他方、いや、プロジェクトは必ず何らかの成果物を生み出す活動なのだから、成果物自体の構成に準じた分解をするべきだと主張した人々もいます。これを、Product-WBS(略称P-WBS)と呼びます。たとえば化学プラントならば、製造設備・ユーティリティ設備・物流エリア・事務棟、といった分解です。

両者に論争があったということは、実はどちらか片方では十分ではないことを示しています。そこで、両者を縦横にとった二次元マトリクスでアクティビティを数え上げるのが、もっとも理想的な方法だという考えに至ります。単位要素となるアクティビティは、「製造設備-設計(1-E)」「物流エリア-調達(3-P)」といった具合です。

ただしこの方法では、アクティビティが必要以上に小さく分解されすぎてしまうことがあります。アクティビティが小さすぎると、情報収集やレポーティングなど、コントロールにかかる手間が増大し、本末転倒の「管理のための管理」になる 危険性があります。そこで、いくつかをまとめて、アクティビティの最小単位「ワークパッケージ」とする 技法が用いられています。

WBSにつづいて70年頃から発展したのが、EVMS(アーンドバリュー・マネジメント・システム)と呼ばれる手法です。扶蘇が蒙恬将軍にたずねたであろう問いを思い出してください。「この仕事にこれまでいくら費用を使ったのか?」−−それでは、もしも現在までの出費(Actual Cost = AC)が、当初計画していた現時点までの予算(Planned Value = PV)よりも小さかったら、プロジェクトはうまく出費をコントロールしていると言えるでしょうか? たとえば、現時点までの出費予定が1億円だったのに、現実の出費実績が9千万円だったら、うまくいっていると判断していいでしょうか?

そうは言えないのです。なぜなら、単に仕事が遅れているために 出費実績が計画より小さいのかもしれないからです。むろん、本当にうまくコストを押さえ込んでいるのかもしれない。どちらの理由で1千万円の差が生じているのかは、この二つの数字だけいくら眺めたって分かりません。

そこで、Earned Value = EVとよぶ第3の金額を計算してみるのです。EVとは、「現時点までに完了した作業(アクティビティ)の予算金額合計」のことで、日本語では『出来高』と呼ばれます。かりに、前述のプロジェクトでEVを計算してみたら7500万円だったとしましょう。これから何が分かるでしょうか? まず、EVとPVを比べます。すると、EVの方が小さいですね。つまり、元々の予定では現時点までに1億円分のアクティビティが終わっているはずだったのに、現実には7500万円分しか完了していない訳です。これは、プロジェクトの進捗が予定よりも遅れている(予定の75%の進捗しかない)事実を示します。

さらに、EVとACを比べると何が分かるでしょうか。EVが7500万円なのに、ACが9000万円ということは、すでに終わったアクティビティについては、当初の予算では7500万ですむはずだったの出費が、実際には9000万かかった、つまり見積よりも余計にコストがかかっていることを意味します。まとめると、このプロジェクトは、進捗は予定よりも遅れており、なおかつコストは予算より超過しているという、非常に危険な状態にあることが、わかるのです。これはEVという指標を導入することで明らかになったことで、予算PVと実績ACの二つだけをいくら比べたって、分かりません。これが、プロジェクトの予算管理と、通常の定常業務の予算管理との大きな違いなのです。

では、プロジェクトの完成時にはいったいいくらの金額になる見込なのか。これを完成予測額(Cost Estimate at Completion = Cost EAC)と呼びます。それは、すでに使ってしまったお金ACと、残っているアクティビティを完了するのにこれからまだ必要となる金額ETC(Estmate to Complete)の合計ということになります。Cost EAC = AC + ETCです。ACは9000万円ですね。あと、仕上げなければいけない作業が、元々の予算計画ではまだ2億円分あったとしましょう。すると、Cost EACは2億9000万円でいいでしょうか?

むろん、それでは楽観的すぎます。まず、これまで7500万ですむと思っていた仕事が現実には9000万かかっていたことを思い出してください。これは、平均するとちょうど2割だけ、実際の出費が高いことを示します。このトレンドは、おそらく将来も続くでしょう。EVMSの膨大な経験が教えるところによると、プロジェクトが全体の2割を過ぎたあたりから、AC/EVの比率は安定してきます。である以上、残る仕事も、2億円ではなく、2.4億円はかかりそうです。おまけに、進捗が遅れていることもお忘れなく。納期に間に合わせるためには、人を増員するなどキャッチアップのために余計な費用が必要でしょう。となると、たぶんCost EACは3億3000万をもっと上回ることが予想されます。

このように、EVを用いてコストと進捗をコントロールしていく手法を、Earned Value Management System = EVMSと呼びます。

モダンPMで用いられている三大技法であるCPM、WBS、そしてEVMSの原理を、簡単にご説明しました。この3つはちょうど、プロジェクトを取り囲む三大制約である『スケジュール』『スコープ』そして『コスト』に対応しています。この三大制約は別名、「鉄の三角形」とも呼ばれ、プロマネは日夜その中で苦労しながら進んでいるのです。だからこそ、これを押さえるための手法が真っ先に発達してきたのでしょう。

もちろん前述の原理を、現実のプロジェクトに適用するためには、いろいろな道具立てやノウハウの集積が必要です。そうした原理・ツール・ノウハウの総体を称して、技術と呼ぶのです。プロジェクト・マネジメントの技術です。

こうしたマネジメント技術の基本を押さえた上で、プロマネのリーダーシップやメンバー達のモチベーションを問うのならわかります。プロジェクトは結局、人間がやることですから。しかし、こうした基本さえ知らずに、いきなりリーダーの人格や志気を問題にするとしたら、そして、プロジェクトの構造を見ずに、ただ全体の費用や納期だけを見るとしたら、2000年前の扶蘇と同じではないでしょうか。

国内で顔見知り同士が、同じ言語と文脈を共有して、以心伝心で仕事を進めていける国内プロジェクトならば、技術なしでも気合で乗り切れるでしょう。しかし海外プロジェクトは、根本的に違います。 こうした技法を押さえた上で、さらにわたし達が身につけるべき思考と行動の習慣、いわばマインド面でのOSがあるのです。それは端的にいえば、

そして、

です。 システム・言葉・計画・契約の頭文字をとって、 わたしは「S + 3K」と呼んでいます。

・・・ということで、展望講演はこの後、海外プロジェクトの進め方を概説し、さらに現在のモダンPM理論に欠けている価値評価をめぐって、わたしが進めてきた「リスク基準プロジェクト価値」研究成果を紹介した。そして、今後のモダンPMの発展には「仕事のプロセスシステム工学」が大事になるだろう、という話で締めくくった。だが長くなりすぎるので、後半は割愛させていただこう。なお念のために書いておくと、化学工学とは元々、化学プラントの設計論であり、とくに各種装置を組み合わせてプラント全体のシステムを設計・最適化する手法論を「プロセスシステム工学」と呼ぶ。

プロジェクトもまた一種の化学プラントに類似したシステムであり、個別のアクティビティという要素を組み合わせて、全体のシステムを作り上げ、動かしていく。そうした思考方法=システムズ・アプローチこそ、これからのプロジェクトにとって必須のものだ、というのが、聴衆の皆さんに伝えたかったコアのメッセージだ。

では最後に、WBSをはじめとするモダンPMの技術、そしてシステムズ・アプローチを中心としたマインド面でのOSについて、もう少し深く知りたい方のために、格好の入門書をご紹介しよう。1年半かけて書いた、わたしの新著『世界を動かすプロジェクトマネジメントの教科書』である(笑)。今週末から書店に並ぶが、電子版はさきがけて本日から発売である。ぜひ手にとってご覧いただきたい。海外プロジェクトに長年実務で携わり、また近年はPM理論研究と教育も実践してきた人間として、類書にない思想と技法を盛り込んだつもりである。

地図を読んでも山には登れず、海図を見ても船は航行できない。だが、どこに登るべき山があり、渡るべき海があるかは分かる。本を読んでも能力がすぐ得られるわけではないが、できればぜひ一人でも多くの方に、海を渡って広い世界を目指してほしいと願っている次第である。

→「革新的生産スケジューリング入門」にもどる

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

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

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

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

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

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

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

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

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

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

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

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

→「革新的生産スケジューリング入門」にもどる

『なぜ』からはじめよう − 仕事の目的を設定する (2016/04/28)

たしか林達夫の西洋史に関する論考だったと思うのだが、「古代ギリシャは豊かなイメージがあるが、社会的な生産性はじつはかなり低かった。ギリシャ社会を支えていたのが、奴隷労働だったからだ」という説明を読んだことがある。林達夫はわたしの尊敬する思想家で、平凡社の『世界大百科事典』の編集長をやった博学の人だ。

人を動かすということが、技術リーダーとして面白い仕事をする必要条件だと、前回書いた。では、具体的に、人は何で動くのだろうか?

一番すぐに思いつくのは、給料などのお金だろう。お金という報酬で、人を動かす。会社というのは、そうなっている。業務上の命令通りに働けば、給料がもらえる。上司の覚えも良くなる。そむけば、叱責されて給料が下がったり、首になったりするかもしれない。つまりアメ(給料・昇進)と、ムチ(罰則・失職)で動かす訳だ。

ここで人を動かすために使われているのは、「強制力」(権力)である。強制力を使うことができるのは、マネージャー職種(=上司)という立場にあるときだ。動かす相手は、部下である。部下以外には、この手はきかない。業務命令と、統制。このような仕組みで組織を動かすことを、英語で"Command and control”という。軍隊が、その典型だ。そして組織の成員が、この中で仕事の代償として期待することは、給料と生活の維持である。

部下でない他人に対しては、直接の命令権はない。給与を左右することもできない。しかし、もう少し別の報酬で動かす方法がある。それは、「貸し借り」で動かす方法だ。人に仕事上やプライベートでの貸し(恩義)を作っておく。そして、あとで「借りを返して」もらう。これは「影響力」と呼んでもいい。職場で上手に貸し借りを利用する人は、あなたの周りにもいると思う。

ほかに人を動かす方法はないだろうか? ある。それは、仕事を通じた成長や、自己実現への期待によって動かすことだ。「この人についていけば、自分も腕が上がるかもしれない。いい仕事ができるかもしれない」、と思えば、命令や貸し借りなしでも、人は動いてくれるだろう。これは、同種の職能から現れるリーダーや、上司という立場にはないプロマネが、もしもそれなりの腕前の人であれば、ふるえる力だ。これも影響力の一種だから、第二種の影響力とよんでおこうか。この場合、チーム員が期待するのは、自分の能力向上や、仕事の成果への満足感である。

そして、さらにその上がある。それはリーダーの信念や、他人への貢献意欲で人を動かすことだ。これはもう、カリスマか教祖の域であろう。そこに加わる人の期待は、他人を助けるという仕事への使命感・達成感だ。

かくして、人はいろいろな理由で動く。まあ、一番最初のレベルというか、デフォルトは「言われたから」「命じられたから」やることである。その最低次元が奴隷労働だ。これに、どれだけ他の要素が混ざるかで、パフォーマンスに差が出る。それはちょうど、三人の職人のたとえ話のようなものだ。

三人の職人の話をご存じだろうか? いくつかのバリーションがあるが、ともかく出だしは旅人が働いている職人たちのそばを通りかかるところから始まる。旅人は職人の一人に、何をしているのですか? とたずねる。最初の職人は、答える。
「見ればわかるじゃないか。レンガを積んでいるのさ。」
旅人がさらに、なぜレンガを積んでいるのですか、とたずねると、その職人は面倒くさそうに
「親方に言われたからさ。そのとおりにすれば、給金がもらえる。さあ、どいた、どいた!」

旅人はつぎに、別の職人に同じ事をたずねる。何をしているのですか?
二人目の職にの答えは、こうだ。
「壁をつくっているんです。どうです、立派でしょう? 親方のところに来たすぐの頃は、こんな風にまっすぐ積めなかったけれど、いまはここまでできるようになった。壁の高さは、この街で一番ですよ。」

さらに旅人は、三人目の職人にたずねる。何をしているのですか?
年老いた職人は、こう答える:「大聖堂を作っているんじゃよ。これが完成した暁には、大勢の信者が集まって、日照りの夏も寒い冬も、一つ屋根の下で祈ったり、ありがたい神様の話をきいたりして過ごせるじゃろう。尊い仕事じゃないか! まあ、完成までにはあと百年近くかかるかもしれんがの・・。」

なぜその仕事をしているのか? ?それが出発点である。わたし達が新しいことにチャレンジするとき、まず目的を明確にすることからはじめよう。そう、わたしはPMの授業などで教えている。それが賃金や貸し借りのためなのか、自分の成長のためなのか、あるいは他人や信念のためなのか。べつに給料のために働くことを卑しむつもりはない。それは最低限必要なことだ。だが、それ以上の成果を上げたかったら、「言われたこと以上」を考えて自分から動いてもらわなくてはならない。

目的とは、なんのためにその仕事をするのか、つまり英語の”Why”を示す。どのような期待や価値観によって、一人ひとりが動くのか。よく組織の壁だとか「サイロ化」といったことが問題になるが、Whyを皆で共有することは、サイロ化を防ぐはたらきがある。大きな目的を共有すると、自分や自部門を守ることよりも優先すべきことがある、と分かるからだ。

じつはプロジェクトで一番恐ろしいのは、ゴールが自己目的化することである。ゴール地点にたどり着くこと、決められた成果物を作ること、それが最終目的になってしまう。大学に進学する目的は、大学に入っていろいろ新しい学問を身につけ、成長することであるはずだ。だが、大学受験の勉強を続ける内に、いつの間にか大学合格自体が目的になってしまう。その大学になぜ入るのか、入ってから何をしたいのか、考えないまま、ただ点数競争に駆り立てられる。そうして、自分の適性と大して関係もない学部に、点数ランクの都合だけで進んでしまう。ばかげたことではないか。

同じように、組織で一番恐ろしいのは、存続が自己目的化することだ。組織はもともと、なんらかの目的のために結成されたものであるはずだ。「組織は戦略に従う」という言葉もあるくらいだ。だが、組織ができあがり、大きくなると、いつの間にか「組織を守る」ために仕事を作ったり、仕事をねじ曲げたりするようになってくる。あちこちの官庁や公共団体で、そういう例を見かけないだろうか?

手段が目的化する、というのは、あまりにも陥りがちな罠であろう。ゴールは遠い目的地への、中間地点にすぎない。プロジェクトが何かの成果物を作るとき、それはふつう、なにかの手段なのである。成果物が新製品なら、それはマーケットを拡大するための手段である。成果物が新工場なら、それは生産能力を拡大するための道具であり、成果物が情報システムなら、業務を刷新するための手段であるはずだ。より遠い目的を目指すためにプロジェクトを進めないと、おざなりな成果物を形だけ作って、ユーザが気に入ろうが気に入るまいが一件落着、といったへんてこなことが起きるのだ。それでインパクトのある、面白い仕事ができるはずがない。

目的を明らかにし、皆で共有することが大事である??それは、わかった。だが、具体的に、どうしたらいいのか? 我々は(少なくともわたしは)カリスマではない。仕事だって、大聖堂を建てるような崇高な仕事ばかりではない。そういう時、どうしたら人の心をつかみ、同じ方向に動かせるのか?

Simon Synekという人は、ゴールデン・サークル=『黄金の輪』というモデルを使ったコミュニケーション論を提案している。モデルは単純で、三つの同心円からなる。一番外側はWhat、その内側がHow、そして一番中心にWhyがくる。

Synekによれば、普通の人や企業がやりがちなアプローチは、外側から内側に向けた順番で、物事の意義を説明することだという。つまり、

(1) What「こういう製品です」
(2) How「こんな風にすごいんです」

で、多くのプレゼンや広告は(3)のWhyまでは説明しない。

しかし、本当に人の心を動かしたいのなら、順番は逆で、中心から外側に向けた順序にコミュニケーションしなければならない。それは、

(1) Why「我々はこうあるべきと信じます」
(2) How「だからこんな風にしたんです」
(3) What「それが、この製品です」

である。傑出したリーダーや、優れた企業はこういう話し方をする。

Synekはその例として、たとえばジョブズ時代のアップルや、キング牧師や、ライト兄弟とそのライバルだった男をとりあげる。彼はこの理論をわずか18分間にまとめてTED Talkで講演しているが、非常にプレゼンの巧い人だし、翻訳字幕もついているので、試しにぜひ見ることをおすすめする。
「サイモン シネック: 優れたリーダーはどうやって行動を促すか」
http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html

Synekは、このゴールデン・サークルを、人の脳の構造から説明している。つまり一番外側に大脳新皮質があり、ここが言語や理知で「What」を判断している。しかし、一番真ん中には古い大脳辺縁系があり、そこは言語化されないが、人の信頼感や行動を決定する。人が決断し行動するのは、理性ではない。もっと深い場所にある、感動や信念が一番強いのだ。(それはたとえば異性に惹かれる時を考えてみれば分かる)。ただ、人に理由をたずねられたら、理屈を後付けすることはできる。(「だって、優しい人だから。」)

まあ、Synekはプレゼンが上手すぎるので、ライト兄弟のライバルの例など、後からよく考えてみると本当に彼の理論で説明できるのかな、という気もするけれど、説得力があるのは事実だ。コミュニケーションは、Whyからはじめる。なぜ、この仕事が必要なのか。なぜ、これには意義があるのか。イノベーターとよばれる人々(100人に2.5人しかいない)は、そうした信念を共有することによって、彼の言う”Early Adaptor”(人口の13.5%)を集める。そして賛同者が20%を超えれば、あとは勢いがついてくる。それによって全体を変えていくことができるのだ。

もし、わたし達がイノベーティブな成果を生みたかったら、なぜその仕事に意義があるのかを知らなければならない。そして、その目的を高く掲げるのだ。今、もし自分のやっている仕事のWhyが明らかでないなら、よく考えて他人と共有するべきだ。考えるのに遅すぎるという時はない。ぜひ、明日からでも考えよう。


→「革新的生産スケジューリング入門」にもどる

海外型プロジェクトの難しさ − それはOSレベルの問題である (2014/12/03)

ず先日、あるプライベートな勉強会に招かれて、議論する機会があった。テーマは「海外型プロジェクトの進め方」である。中堅ないし準大手の製造業およびソフト会社で、それなりに海外展開を進められている企業の実務家がメンバーであった。プロジェクト・マネジメントについては、すでに社内でもいろいろな取り組みをされているところが多いと見受けられたので、「PMBOK Guide(R)とは」みたいなレベルの、基礎的な解説はさけることにした。わたしは、国内では一応うまくいきつつあるプロジェクトが、なぜ一歩海外に出ると急に難しく感じられるのか、それは『組織のOSレベルの問題である』という見方の話をすることにした。

「組織のOSレベルって何のことだ?」と怪訝に思われた方もいるだろう。少し順を追って説明したい。過去10年ほどの間に、日本でプロジェクト・マネジメントの体系や技法がそれなりに普及したおかげで、プロジェクトの成功率が上がってきたことは、統計にも表れた事実である。たとえばIT系プロジェクトにおいて、日経コンピュータ誌の調査によれば、2003年の成功率はわずか26%だったものが、2014年の調査では75%が成功だったという。ここでの『成功』の定義は、QCDを達成したことであり、果たしてそれで真に成功と言えるのかという問題は別途あるが、ここでは脇に置いておこう。またJUAS(日本情報法システム・ユーザー協会)の2014年度調査によれば、予定通りあるいは予定より早く完了したプロジェクトは合計で74.2%だった。製造・建設など他の分野はあまり統計を見かけないが、それにしてもかなりプロジェクトの成功率が上がっているのは確かだろう。

ところで、プロジェクト成功率上昇の理由は、優秀なプロマネが日本にどんどん増えている、ということなのだろうか? たしかにPMP取得者数は増えただろう。だが、それだけではないとわたしは考えている。企業におけるプロジェクト・マネジメントの能力は、プロマネ個人だけで決まるものではあるまい。日本企業は、過去10年間の間に、プロジェクト遂行の能力を組織ぐるみで構築してきた。その結果が、統計に表れているのではないか。

これは逆の例を考えれば分かる。今まで全然プロジェクトらしい仕事を経験したことのない組織に、突然外から指折りのプロマネを引き抜いて連れてきたとしよう。その一人だけで、プロジェクトは十分なパフォーマンスを上げられるだろうか? 相当難しいに違いない。プロジェクトを計測する仕組みもなければ、過去のデータもなく、業務の標準的な手順やWBS体系もなく、さらに組織全体ががプロジェクト的に動く習慣のないところで、どうやって計画を立て統制できるというのか。

わたしの知っている、ある年配の元プロマネの方(もう現役は引退されている)から聞いた話だ。この人は有力なエンジニアリング会社出身だが、’90年ごろ転職して、別の巨大メーカーに入った。ちょうどそのメーカーはプラント輸出に注目して、海外でのプロジェクト展開に力を入れようとしていた。そして運良く、この会社はアジアの某国向けの案件を受注した。中規模の中ではかなり大きな案件だし、技術的にも国内で実績を積み、手慣れたものだった。ぴったりのタイミングで、この人はプロマネとして着任した訳だ。

ところが、この方いわく、「本当に死ぬかと思った」というくらい大変なプロジェクト遂行になった。なぜか。社内組織がちっとも動かないのである。プラントは機械・電気・制御・建築など多種多岐にわたる技術のかたまりで、プロジェクト・チームはいわば技術者のオーケストラのようなものだ。にもかかわらず、プロマネの振るタクトにあわせて誰も演奏しないのだ。では皆は誰の方を見て仕事しているかって? それぞれが所属するライン部門長の方だ。大きなメーカーでは、ライン部門長は強大な権限を持つ。人事面でも、予算面でも。その部門長達にとっては、国内での定常業務の運営が最大の関心事で、技術も人も、まずそちらに優先配分するのだ。「XXプロジェクト? それはお前たちが勝手にとってきた仕事じゃないか」というようなことを言う。いや、勝手にとったのではなく、会社として取り組んで受注したんじゃないか、と言ってもまったく馬耳東風である。

また、配属されたメンバーも、ちっともプロジェクト的に動けない。海外型プロジェクトでは基本、文字にかかれた契約がすべてである。そして、顧客に最終的な決定権がある。だが日本国内で人も知る巨大企業に働いてきた技術者達は、顧客の方を向いて、要求されたとおりに仕事する習慣がない。顧客や業者への説明能力・交渉能力にも欠けている(国内では殿様企業だったのだ)。過去の経験がないから、キーマンが自分で工程表を書けない。問題が生じても、部門をまたがる問題だと、お互いにそっぽを向いて自分で調整しない・・。

この例を見ても分かるとおり、プロジェクト・マネジメントの能力とは、組織の能力である、というのがわたしの理解だ。図に示せば、下のようなビラミッド構造である。最上位には、プロジェクト・マネージャーの個人的スキルがある。これは、さらにハード・スキルとソフト・スキルに分けることができよう。ハード・スキルとは、知識・技法など、主に座学で身につけることのできる能力である。ソフト・スキルとは問題解決力や交渉力など、いわゆるセンスや修練を要求される「人間力」的な能力だ。

プロマネ個人のスキルを支える中位の層には、三つの能力的な柱がある。(1) プロジェクト遂行のための標準的な業務手順・WBS体系、(2) プロジェクト管理のための情報システム、(3) 過去のデータベース、の三つである。これらがあってはじめて、プロマネは力が発揮できる。これらは、広義の「マネジメント・システム」だと言ってもいい。そして、このシステムを整備するのは、いわゆるPMO(Project Management Office)という部署の仕事だ。

ところで、この三本柱の下に、最も底辺の能力層がある。それがプロジェクト遂行に関する組織体勢・行動習慣なのである。プロマネが力をふるうためには、プロジェクト・チームの全員が同じ方向・同じベクトルを向いて動き、かつ権限や態度や行動習慣などにコンフリクトがない状態になっていなければならない(大事なことは、組織図にかかれたスタティックな状態ではなく、組織がどうダイナミックに動くかという姿勢の問題だから、あえて組織「体勢」という字を使っている)。たとえば、プロマネが「右向け、右」と号令をかけても、チーム員が上司であるライン部門長から別の指示を受けていたら、プロジェクトは迷子になるだろう。あるいは、皆がきちんとプロジェクト単位で記録やデータをとっていなかったりしたら、業務標準や過去データが生きてこなくなる。

3つの能力レイヤーを、ITの世界にたとえて言うなら、最上位の層はコンテンツ(知識)レベルの能力であろう。中位層は、アプリケーション(道具)レベルの能力に相当する。そして一番底辺の層は、いわば組織のOSレベルの能力である。組織のOSとは、言いかえるならチーム員全員にビルトインされた、「組織化され体系化された態度・行動の集合」なのだ。これがあってはじめて、プロジェクト・マネジメントは働きを得るのである。OSがおかしくなっていると、プロマネが何を言っても「笛吹けど踊らず」、データも情報システムもガーベッジ・インの状態になる。

そして、日本国内と海外プロジェクトでは、チーム員に求められるOSの質が違うのだ。なぜか。それは、大きく言って、4つの制約があるからだ。「『前例』も『正解』もない」という制約。「外国人同士で意思疎通が難しい」という制約。「前提としている価値観が違う」という制約。そして「先が予測しにくい」という制約の4つである。だから、海外型プロジェクトに日本人が携わる場合は、必ずこれら制約を意識した行動習慣が必要になり、それをサポートする組織体勢が必須になる。

『前例』も『正解』もない」ことの理由は言うまでもあるまい。だが日本は世界でもまれに見るほど高度に発達し組織化された社会だ。ありとあらゆる分野に、前例と正解が存在し、それを見つけて従うことが大事だとの思い込みが蔓延している。始めてとりくむ、構造もわかりにくい問題に、大局観を持って取り組むという、思考の習慣が身につきづらい。

意思疎通の難しさ」についても言うに及ぶまい。外国語だから、英語のうまい人間を連れてくれば解決、などと思ってはいけない。問題は、互いに共有する文脈(コンテキスト)のレベルの違いなのだ。日本は、世界でも有数の「ハイ・コンテキスト」レベルの社会である。言葉を連ねなくても、あうんの呼吸で通じる。そして、言葉を受けた側が、相手の意思を忖度して行動する習慣がある。世界で言うと、このようなハイ・コンテキスト社会は少数派で、個人的実感で言えば2割もあるまい。8割以上は、「言葉にしない限り通じない」相手なのだ。

価値観が違う」という制約は、文化の問題ではない。成功した海外プロジェクトでは、日欧米をはじめ何十という国から異なる文化背景の人間が集まってきて、それでちゃんと遂行できている。お金を儲ける、というビジネスの究極の目的だって一緒だ。だが、そこに至る過程・前提が違う(会社目標より部門成果、という前述の巨大メーカーの例を思い出してほしい)。だから、誰もが共通して納得できるプロジェクトとしての価値観を明示し尊重できなくてはならない。

先が見えない」も同様。皆が通ってよく踏み固められた道が存在していないのだ。だとしたら、自分でまず道筋を描いて、かつ、道中にぶつかる障害をうまくよけながらすすむという行動習慣がなくてはいけない。

こうした4つの大きな制約条件を乗り越えるために、日本人として訓練し身につけるべき組織体勢・行動習慣を、わたしは「OSレベル」の能力と呼ぶ。それはちょうど、(あまり良いたとえではないが)工場における「5S」のようなものだ。「5S」とは整理・整頓・製造・清潔・習慣化の頭文字で、よく組織された工場労働者は、これらを尊重するような行動習慣を持っており、おかげでものの流れにも機械の調子にも遅滞がない。

海外型プロジェクトの場合、OSレベルではだいたい8つくらいの基本的習慣に整理できるだろう。たとえば、以前かいた”Structured Approach"というのもその一つだ(「Structured Approachができる人、できない人」)それは国内の仕事をずっと続けるならば、とくに不要な能力だ。だがこの先、もし外に出て行って仕事をしたいなら、せめてチーム単位で、身につけていく必要がある。この10年間にモダンPMの理論手法が普及したのはとても良いことだった。しかし、その副作用として、EVMSだとかCPMだとか道具レベルの能力さえ身につければ大丈夫、というような錯覚も生まれつつあるように思える。もっと下の、基礎的レベルの能力を忘れてはいけませんよ、とそろそろ声を大にして言わなければならないのだろう。

そして、ことは海外型プロジェクトだけではあるまい。優秀な人もしっかりした制度・システムもある。だが、何となく先が見えず、前例も役立たず、価値観もばらばらで、お互いに意思疎通がうまくできないような、もやもやとした状況の中で問題をかかえている組織や社会にも、こうした行動習慣は有用だと思われる。だからこの先、できるだけ機会を見つけては、具体例をこのサイトでも紹介していくことにしよう。また現在、海外型プロジェクトの進め方というテーマで、本も書くつもりでいる。早ければ、来年の春頃には上梓できるかもしれない。よければそちらもご期待ください。

→「革新的生産スケジューリング入門」にもどる

ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係 (2013/07/07)

ある、社外の人との集まりに顔を出した時のこと。IT分野の経験を積んだ人が多く、みな一家言持っておられる。わたしは昨年後半から、久しぶりに社内のIT関連業務を見るセクションに移ったばかりなので、最近の事情に疎い。なるべく拝聴する側に回ることにした。話は業界の技術トレンドから、クラウドやビッグデータといった最新のバズワードに向かい、日本のIT業界の現状をなげく論調にうつった。日本を代表する大手SIerたちの低空飛行ぶり、技術的イノベーションの不足、そして多重下請に象徴される業界の構造的問題。追い打ちをかけるように、オフショアとの競合による単価の下落。なんだか、あんまりエンカレッジされるような話題が出てこない。

−−だとすると、日本のSI業界というのは将来性があるのでしょうか? わたしは思い切って、直球ど真ん中の質問をなげてみた。しかし返ってきたのは、苦笑いするように首を横に振る姿ばかり。

「情報システムを開発・維持する仕事は、この国に経済がある限り、無くならないでしょう。しかし今のSIerのような業態が続くかといえば、疑問だと思いますよ。」一人が答え、他のメンバーも賛同する。「一括請負で、プロマネは受注側には居るが発注側にはおらず、人月を一山いくらで売るばかりのソフトウェア商売は、もうこの先、もたないんじゃないかな。」これを別の人が引き取って続ける。「アメリカではPMは発注側の組織にいて、バラバラなユーザ要求をまとめる責任もあるんです。そうやって、納期やコストとのバランスを調整する。日本のユーザ企業って、そういう旗振り役がいないんで、全部請負側にリスクが押しつけられるんですよ。」

アメリカの事情は別にいい。わたしも多少は知っているし、ユーザ側のPMもじつは有期契約の渡り鳥だったりする。だが、とりあえずわたしは日本企業に勤めており、日本の業界の実態を知りたい。すこし矛先をかえて別の質問を出してみた。−−ソフトウェア開発のプロジェクト・マネジメントで、一番苦心されるのは、どんな点ですか?

「それはね、人の確保ですよ。」右隣の人が答える。「それも、人数じゃない。出来る技術屋の確保。プロジェクトはこれに尽きます。ITエンジニアの生産性って、人によって30倍くらい違いますから。」すると向かいの人が突っ込む。「いやあ、人によっちゃあ、いつまで経っても出来あがらない奴がいるから、生産性の違いはもう無限大だな。」(笑)

あれ? わたしが駆け出しだったころ、プログラマの生産性の違いは“倍・半分”といっていた。10年ほど前には、たしかどこかで、SEの能力差は“10倍くらい”ときいた覚えがある。そして今や、30倍だという。この指標では、インフレが進んでいるようだ。なぜだろうか。開発環境やライブラリが充実したせいか。それとも、職種自体が変化しているのか。わたしはそれもたずねてみた。−−その個人別の生産性の数字かグラフ、もしあったら見せてもらえますか?

「いや、そんなものはありませんよ」が、答えだった。
−−じゃあ、どうやって30倍だと分かるんですか?
「そりゃあ、プロが見ていれば分かります。感覚ですけどね。」
−−経年変化とかのグラフもない、と?
「佐藤さん。ITエンジニアの生産性って、具体的に測るのは難しいんですよ。」相手は諭すような口調でわたしに言った。

難しいくらいは、わたしにだって分かる。だから、どうやってそれをマネージしているのか興味を持ったのだ。何かをマネジメントしたかったら、まず、それを測って、数値化する。そして、標準値を設定する。その上で、実績が標準に足りない場合はその原因を調べて取り除き、さらに標準値自体を押し上げる改善の努力をする。これが、生産管理の世界での常識、いや、マネジメント全般に共通するやり方だ。

だから、IT分野のマネジメントで人の生産性が問題なら、それを測って数値化する試みから、着手されるはずである。そう、単純に考えたのだった。仕事の実績から、個人単位の生産性を割り出すのが難しいのなら、テスト問題を作ってみて、それで測る手もあるだろう。あるいは、もしプロが見て分かるのなら、5〜6人の社内のベテランの目から評価させ、平均値をとる方法も考えられよう。だが、そうした発想は、ここでは通用しないらしい。

−−個人の生産性の違いを決める、決めてってのは何ですか?
「そりゃあ、センスですよ。もって生まれたセンス。」
−−てことは、生まれつき決まっていて、教育や研修では伸びないものだ、と。
「まあ多少、経験や、あと、誰について仕事を学んだかで、かわってきます。」
ーーふうむ。そうすると、IT開発マネジメントの最大の仕事というのは?
「だから、社内にいる限られた優秀なキーパーソンを、どうやって確保するかで勝負が決まるんです。」

この方は、社内の椅子取りゲームに勝つのがプロジェクト・マネジメントの要点であると信じているようだった。社内全体の椅子の数を増やして、全員が座れるようにするにはどうしたらいいか、は眼中にない様子だ。まあ、それを考えるのはPMOの仕事、ということなのかもしれない。

全体の話は次第に、ビッグデータの方に流れていった。ビッグデータという語の流行(?)とともに、『データ・サイエンティスト』という職種の概念が新たに登場し、急に脚光を浴びるようになってきた。多量のデータを見て、そこから“意味”や“仮説”を汲み出す力。まあ、たしかにエンジニアリングと言うよりもサイエンスに近い。技術は発明が主題だが、科学は発見が重要だからだ。では、そのデータ・サイエンティストはどのように育成するのか。大学はどこの専門を出た人間が適切なのか。いや、これはサイエンスと名付けているが、実際にはかなり「アート」に近い仕事なのではないか、云々。

だが、わたしは次第に話に興味を失っていった。とるべきデータなら、目の前に沢山ころがっているではないか。それは、自分たちIT分野の仕事の実績データである。生産性でもいい。生産性がもし難しいのなら、品質(つまり瑕疵)のデータでもいいし、あるいは受注確率のデータでもいい。自分達の仕事を向上させる手がかりは、データの中にしかないはずだ。なのに、なぜ商品RFIDの移動や、スマフォの緯度経度のデータばかりが重要だと考えるのか。データサイエンスから最も縁遠い業界の一つが、じつはIT業界ではないのか。そんな気がしてきたからだ。

国内外で仕事をしてきた経験から感じるのは、彼我の技術者のマネジメント観の違いである。いや、こういう言い方が大ざっぱすぎるなら、言い直そう。英米社会で教育を受けた技術者と、日本社会で主に教育を受けた技術者の違いはどこか。それは、マネジメントという仕事が独立した科学の対象でありうるかどうか、という意識の差である。

日本の技術者というのは、ほぼ例外なく真面目で、優秀だ。たとえば、最近読んだ調査によると、日本の大企業の基幹情報システムの障害による月間停止時間はわずか1.7時間なのに対し、北米では14.7時間だそうだ。まさに10倍近い信頼性の差である。また、ソフトウェアの不具合数(1年後に発見された1KLOCあたりの不具合数)は、
 日本 0.020
 アメリカ 0.400
 インド 0.263
 欧州他 0.225
 平均 0.150
だということで、日本のIT技術は格段に信頼性が高い(JUAS=日本情報システム・ユーザー協会「ユーザー企業ソフトウェアメトリクス調査2013」p.291 より引用)。

だが日本の技術者は、(IT分野に限らず機械だろうが建築だろうが)マネジメントは「文系の仕事」だと思っている人が少なくない。自分の仕事と認識している人でも、マネジメントとは“人間力の問題”だととらえることが多い。つまり、いかに出来の良い人をとってくるか、いかに人をモチベートしてやる気を出させるか、いかに明確なビジョンを示して皆を引っ張るか、いかにメンタルな面に気をつけてやるか、etc, etc... マネジメントとはヒューマン・ファクターの集合であり、個人が修行して悟るしかない。そして、それは自分の固有の技術領域とは無関係のものである、と。

IT業界人こそ、こうした「普通の日本人」の思考法の枠内から、自覚的に離れる努力をしていってほしいと、わたしは願う。もし生産性を測るのが難しいのだったら、そこをブレークスルーできた者は、大きな優位性を得られるはずである。なぜ、そうした方向を目指す企業が少ないのか。なぜ、一山いくらの値段勝負の泥沼から抜け出そうとしないのか。

IT業界には頭の良い人が多い。論理的に思考する能力を持たないと、仕事にならない。しかし、論理性だけでは、何かが足りないのだ。その何かは、「仕事に関するサイエンス」の中にしかないと思うのだが。

→「革新的生産スケジューリング入門」にもどる

チーフデザイナーとプロジェクト・マネージャー、どちらが上に立つべきか (2013/09/23)

宮崎駿の映画「風立ちぬ」は、ゼロ戦の設計者・堀越二郎を題材にした物語だ。堀越は実在の人物だが、映画全体は評伝ではなく、フィクションの色彩が強い。とはいえ、物語は主人公・二郎による新型飛行機の設計を軸として展開していき、その部分は比較的史実に近い。だから、一種の製品開発プロジェクトのストーリーとしても、見ることができる。その中における主人公の職務上のポジションは、「設計主任」だ。設計主任とは何か、その役割は開発プロジェクトのプロジェクト・マネージャーとは何が違うのか。そんなことを、今回は考えてみたい。

設計主任に対応する英語はいくつかありうるが、チーフ・デザイナーあたりが最も一般的だろう。ところで、チーフ・デザイナーというと、もう一つ思い出すストーリーがある。ハインラインの「月を売った男」(だ。これは月世界旅行の夢にとりつかれた主人公ハリマンが、月ロケットを完成させるまでの物語である。小説が書かれたのは1950年で、まだアポロ計画など影も形もない。だから国の予算ではなく、個人でなんとかして資金をかき集めて実現するしかない。この物語は、儲からぬモノにはびた一文払いたがらぬ米国ビジネス界を相手に、雲をつかむような夢のための金をどうやって引き出すかがポイントになっている。その奇抜なアイデアの数々については、ぜひ小説を読んでもらいたいが、設計とビジネス・マネジメントの兼ね合いについても、一つ忘れがたいエピソードを書いている。

ようやく資金にめどがつき、まさに月ロケットの設計が佳境にさしかかろうとしている時のことだ。チーフ・デザイナーがこぼすのである。「たとえばエンジンの性能について真剣に考えたい時に限って、資材業者がやってきて『トラックはどこにつけたらいいのか』と質問をしてくる。雑用や割込で細切れにされて、肝心の設計に集中できない。」−−これを助けるため、ある有能なパートナーが彼にこう言う。「その種の、交渉だとか契約だとか支払いだとかいった仕事は、今後は全部自分に投げてくれ。ぼくが全力でサポートするから、あなたは技術的なことだけに集中してほしい。」(以上、じつは今、本が手元にないので記憶で書いているが、だいたいこういったやりとりだったと思う)−−そして事実、有能な彼が右腕として面倒なビジネス面での仕事を引き受けてくれたため、設計は急速に前進していくのである。

このエピソードは、たしかFrederick Brooks Jr.が、彼のソフトウェア開発論の古典的名著「Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition」((邦訳『人月の神話』)の中でも引用していた。そして、この二人の関係を理想的だと賞賛している。すなわち、デザイナーが主で、ビジネス・マネジメント役が従、という風な関係である。

Brooks Jr.は元々、IBMでSystem 360とOS/360開発のプロジェクト・マネージャーだった人だ。後にNorth Carolina大学に移り、この本を書いた。System 360はIBMの社運を賭けた画期的計算機だったが、そのOSであるOS/360の開発は予定の2年近く遅れ、「ソフトウェア危機」という言葉が生まれるに至った。「The Mythical Man-manth」は、その彼の思索と反省をまとめた本である。その論点の一つに、開発のための組織論がある。巨大な開発プロジェクトにおいては、技術的仕事のみならず、人事・資材・調達・販売・契約・資金・オフィス環境その他諸々を含めた、非・技術的な仕事がかなり発生する。そうしたビジネス面については、分業して設計から切り離すのが、米国的な発想だ。専門家による分業によって、それぞれの効率を達成する。これが彼らの定石である。

その際、問題になるのが、技術面のチーフと、ビジネス面のチーフの、どちらが組織で上に立つかだ。ピラミッド型組織では、位階の上下ははっきりさせる必要がある。上にいる方が、最終的判断を下す。その場合、技術面と、ビジネス面のどちらが主導権を握るべきなのか。

どちらのパターンもあり得るが、設計が主で、ビジネスが従の形の方が良い、というのがBrooks Jr.の意見である。その傍証として、上記「月を売る男」のエピソードを引用する。実際のところ、System 360の開発では、アーキテクト(設計主任)としての彼がプロジェクト全体を引っ張った訳だ。片腕としてのビジネス・マネージャーがいたかどうかは不明だが。

ところで、このような関係は一般的なのだろうか? つまり、設計が上でビジネスが下の関係だが。たとえば映画の世界ではどうか? 宮崎駿の映画の場合、設計(技術面)の責任者は無論、宮崎駿である、他方、いわゆるビジネス面の責任者はプロデューサーと呼ばれるが、それは鈴木敏夫だ。ジブリの中では、たしかに宮崎が上で鈴木は下に見える。

ただし、他の映画では必ずしもそうではない。というか、むしろ逆のパターンの方が一般的だ。プロデューサーが上にいて全体を統括し、監督が製作(技術面)の責任を持つ。プロデューサーは、いざとなれば監督の首を切れる。たとえ相手が「世界のクロサワ」でも、切ってしまうのがハリウッドのやり方だ。Brooks Jr.の思想から言えば、この関係は間違っているのだろうか?

あるいは、わたしの働くエンジニアリング業界ではどうか。プラント系プロジェクトでは、一番上の責任者はプロジェクト・マネージャーである。そして設計(技術面)の責任者はエンジニアリング・マネージャーと呼ばれ、プロマネの右腕になる。契約だの発注だののビジネス的な仕事は主にプロマネの仕事である。しかし、重工業界や産業機械などの業界では、設計主任がプロジェクト・マネージャーであったりする例もある。

ここで、混乱を避けるため、ちょっと用語を整理しておきたい。チーフ・エンジニア(設計主任)という言葉は、まさに設計の責任者を表す。他方、プロジェクト・マネージャーは、プロジェクト全体の責任者だ。ただ、大きなプロジェクトの場合、自然に技術面と非・技術面の分業が生まれてくる(前者の方が作業量は多い)。そのとき、プラント業界などではプロマネが非・技術面を主に分担する。ただし、設計主任がプロジェクトの一番上に立ち、その従として非・技術面の専門家が動く場合は、「ビジネス・マネージャー」という用語腕呼ぶ場合が多い。

では、両者はどちらが上に立つべきか? それは、プロジェクトの性格による、というのがわたしの答えである。もう少し具体的に言うと、

設計(技術面)の方が難易度が高い場合は、チーフ・エンジニアが上に立つべし。設計面ではそれほど難易度は高くないが、非・技術面(予算や配員や納期等)の制約がきつい場合は、プロジェクト・マネージャーが上に立つべし

ということになる。言いかえれば、より困難な方(=リスクの大きな方)が、全体の判断を下すべきだということだ。

これから考えると、System 360で技術者Brooks Jr.が上だった理由は明らかだろう。技術開発要素が、プロジェクトの成否を決したからだ。彼が「月を売った男」で同じパターンを考えたのも当然だ。これも難易度の高い技術開発だからだ(しかし、小説全体では、資金集めの方がずっと難しく、だからそっちが話のメインになる)。映画の場合も、シナリオライターがおり、俳優達がいて、監督やキャメラなどのスタッフを常時かかえているハリウッド・システムでは、やはり資金面をおさえるプロデューサーが上になる。だが、作家性の高い宮崎映画などの場合は、監督よりも偉い人はいないし、いらない。プラント・エンジニアリング業界では、技術はある程度成熟しており、しかし予算や納期などの制約が厳しいから、プロマネが一番上に立つことになる。

念のためにいうが、技術面とビジネス面を、「理系」対「文系」という枠組みでとらえないでほしい。理系文系という意識は、欧米にはほとんど無い。わたしの勤務先だって、プロマネはほとんど工学部の出身だ。だが、契約やマネジメントの方に専門特化していったのだ。

残念ながら、多くの企業や組織では、設計や財務などの部門の力関係が固定化されてしまっており、上に述べた「プロジェクトの性格」に応じた役割分担ができないことがままある。これが、わたし達の社会でのプロジェクトの成功率を下げる一因なのではないかと、わたしは疑っている。どうも、「上下関係」ばかりに敏感になりすぎるタテ社会文化に、その遠因がありそうである。技術もビジネスも、役割にすぎないことを、わたし達はあらためて再認識すべきではないだろうか?

プロジェクト・コミュニケーションに必要な3つの能力 (2009/03/02)

一般にプロジェクト・マネージャーの働く時間の4割は、コミュニケーションに使われている、としばしばいわれる。いや5割以上だ、との説もあり、私の実感はこちらに近い。とにかく、プロジェクト・マネジメントというのは、朝から晩までかなりの時間を、何らかのコミュニケーションに費やしている。メールを読み、メールに答え、社内で打合せし、顧客や発注先と会い、会ったらその結果を打合せメモにしてまた発信する。そのかたわら上司の質問に答え、会社に報告書を出して、というわけで、朝から晩までずっとコミュニケーションに追われている感じである。

「プロマネ」という社内肩書きはついていないが、個別受注生産の設計部門や、あるいは品種の多い製造業の開発部門・生産技術部門の技術者なども、おそらく似た事情だと思われる。エンジニアと名乗って仕事はしているが、自分で計算したり図面を書いたりする時間はちょっぴりで、大半の時間を顧客や社内との連絡調整につかっている。多くの場合、図面や計算は専任の担当者や協力会社にまかせざるをえないし、事実まかせきりになっているようだ。

このように、設計・技術部門の多大なマンアワーを費やしている「コミュニケーション」作業であるが、それでは、その内容・レベルはどうとらえるべきなのだろうか。プロジェクトにかかわる人々の能力や生産性を問うならば、当然、その作業の重要な要素であるコミュニケーション能力を測り、その効率を改善しなければならない。しかし、「コミュニケーションの生産性」とは、いったい何なのだろうか? PMBOK Guideなどには、9つの領域の一つとしてコミュニケーション管理があげられている。しかし、具体的に何をどうマネジメントしたらいいのか、抽象的すぎて読んでも歯がゆいと思う人は多いだろう。

このことを考えるためには、私たちが一口で「コミュニケーション」とよんでいることがらの中身を、少し立ち入って調べてみる必要がある。MITのトマス・アレン教授は、近著「知的創造の現場―プロジェクトハウスが組織と人を変革する 」で、彼の長年の実測研究結果をまとめて、いわゆるコミュニケーションには、三種類の別の機能のことがらがまざっていると書いている。その3つとは、
●インスピレーション
●インフォメーション
●コーディネーション
である。これらはどう違うのだろうか。

インスピレーションとは、日本語で言えば「ひらめき」である。互いに会話する中で、ふとした気づきがおき、それが形になってくるプロセスだ。誰にも経験はあると思う。話をしているときに、ふとアイデアを思いつく。このときの会話は、とくに確とした目的のない、雑談めいたやりとりの場合が多い。ただ、何らかの問題意識をめぐる雑談なのだろう。たとえば、「あのモジュールの設計はどうやろう」とか、「この客に買ってもらうにはどんな説明がいいのか」といった漠とした問題意識だ。こうした背景を共有する何人かが、ほとんど偶然に集まって、ちょっとしたおしゃべりをする。その中でひらめきが生まれてくる。

だから、インスピレーション=ひらめきを活性化させたかったら、似たような問題意識を持つもの同士が、偶然出会えるような場所や時間が必要だ。そう、アレンは推奨する。これは、壁とドアで仕切られた個室だけの米国式オフィスではむずかしい。だからチーム員を一つの部屋に放り込むとか、廊下にカフェコーナーを設けるとか、日本式の大部屋にするとかいった工夫が必要になる。こうしたひらめきの生産性は、アウトプットであるアイデアの質や量によって測ることになるだろう。

次のインフォメーションとは、「お知らせ」である。あることを知っている者が、そのことを知らない相手に情報を伝達する。上意下達の命令、下からの報告、ことなる部署間での伝達、客先や外注先への通知、そして発注−−こうしたものは、みなインフォメーションである。そして、インフォメーション=お知らせは、その情報を必要とするどれだけ多くの人が、十分な知識レベルに達したかで効果が測られる。つかった時間や労力を分母にとり、知らされた情報量や受け手の数を分子にとって生産性が定義できる。つまり、早い話が時間あたりに伝達したビット数である。

ちなみに、コミュニケーションとは、日本語でのイメージと違い、英語では一方通行的な概念である。誰かが誰かに一方的に伝えること。これをcommunicationとよぶ。だから、放送局のアンテナから全国のTVセットに電波を配信する仕組みを、mass communication=マスコミと呼ぶのだ。

英語の概念では、コミュニケーションは基本的に発信者側に伝達の責任がある。相手が分かるように表現し、相手に伝わるように渡し、かつ相手が受け取ったかどうか確認する。まさに通信技術そのものである。日本人のように、コミュニケーションは双方向で、かつ受け手の側に理解責任がある、という感覚ではない(むろんこれは両者をわざと図式的に対比した言い方であり、現実には日米ともその中間に広い領域があるが)。

さて、第3の種類は、コーディネーションである。Coordinationという英語は、ordinate(座標軸)をあわせる、という意味である。ばらばらになっている方向性をあわせるのだ。何の方向性か? それは、それぞれの話者の考え方の方向性である。皆のベクトルを一致させると言ってもいい。日本語で表現するなら、「折り合い」をつけるといおうか。

そして、このコーディネーション=折り合いこそが、ビジネス・コミュニケーションにおける最大の難物、時間消費の元なのである。なぜなら、コーディネーション=折り合いとは、その場の集団による意志決定にほかならないからだ。

プロジェクトにおいて、インスピレーション・インフォメーション・コーディネーションが、それぞれどの時期にどれだけの割合になるか、私の経験を示してみたのが次の図だ。仕事のごく初期は、ほんの数人でアイデアをふくらませる段階だ。だから「ひらめき」が主体になる。しかし、仕事が広がりをもってくると、メンバーを増員していくことなる。この新参の人たちは従来の背景を知らないから、説明して理解してもらう必要が出てくる。また、アイデアの結果は次第に設計その他の成果物として形になってくる。これも共有する必要がある。こうして、情報伝達のためのインフォメーションが次の主役になる。

しかし、さらに仕事が発展して、会社の様々な機能部門を動かして進める段階になると、こんどは各部の人間の目的意識や行動規範の違いが目立ってくる。ホワイトカラーはみな、一家言ある人たちだ。そして、互いに自分なりの仮説や憶測や流儀をもっている。同じ目的のために働いているのだが、それを達成するための方法や、状況認識にいろいろ違いが出てくる。同じ企業内ならまだしも、これが顧客や関係会社との折り合いとなると、もっと大変だ。

しかも、プロジェクトには、つねに不確実がつきまとっている。誰も先のことは分からない。だから、AがいいかBがいいか、判断が分かれてくる。でも、この判断の差というのも、しょせん「55% vs. 45%」程度の確信度の差でしかないのだ。それを、「いや、そんなこと俺は聞いていない」「あのミーティングには呼ばれていなかったから」などと言い合うのが、会社員の常らしい。とにかく、皆の発言を一度は聞いておかなければならない。これは知識の問題ではなく、じつは感情の問題なのだから。

このようにして、最盛期にはコーディネーション=折り合いのために、ひたすら時間が消費されていくのである。浪費と言ってもいい。アウトプットは、というと、別に合意書とか議事録とかの数ではなく、要は互いの感情がいかに静まったか、互いのメンツがいかに立ったか、であるから、これほど生産性の測りにくい営為はない。

では、コーディネーション=折り合いの消耗さを減らすにはどうしたら良いのか? 皆で飲みに行くしかないのか? そこに生まれたのが、ひとつの実際的な解決法である。それは、「プロジェクト・マネージャー」という役割の人間を置いて、最終的にはこの人の決断にしたがって動こう、という決めごとだ。そのかわり、プロジェクトの結果に対する最終責任も、この人が負う。これは上司部下の問題ではなく(なぜなら、ことなる部署間での折り合いなのだから)、役割=ロールの問題である・・・これが、プロジェクト・マネジメントの基本的な考え方なのだ。

そして、プロジェクト・マネージャーはベターな判断をするために、できるかぎりすべての情報を知っておかなくてはならない。そのためには、プロマネを頂点としたツリー型のインフォメーション・ルートを構築しなくてはならない。こうして、大勢の人間が55%対45%の言い争いをするかわりに、誰か一人(別に全知全能でもなんでもない人間)が始めから終わりまで責任を持って仕事を見る、という仕組みが生まれたのである。そんなわけで、組織全体のコミュニケーションの浪費を減らすために、プロマネは今日も朝から晩までメールとミーティングに追われるのである。

→「革新的生産スケジューリング入門」にもどる

プロジェクト・コミュニケーションのベーシック 〜 情報のトレーサビリティを確立する (2016-09-26)

英語のCommunication と、日本語の「コミュニケーション」という言葉には、微妙なニュアンスの違いがある。わたし達が会話で「コミュニケーションが良くなった」などと語る場合、ふつうは双方向の意思疎通を意味している。「前の課長は向こうが一方的に命令してくるだけだったが、今度の課長はちゃんとコミュニケーションができるよな」という風に。もっと柔らかい言い方をすれば、『ふれあい』みたいな、感情面での同調というニュアンスを含む。

ところが英語のCommunicationは、原則として情報の伝達を意味している。それは、たとえ一方向でも成立する。だから、TV局が電波で大勢に向けて一方的に情報を発信する様な仕組みを、英語ではMass Communicationとよぶ。これは日本語でマス・コミュニケーションとなり、いつものように発音しやすい4文字言葉化して「マスコミ」になった(口頭では、コミュニケーションではなく「コミニュケーション」と発音する人がほとんどだ)。

PMBOK Guide(R)が、プロジェクトの10個のマネジメント知識エリアの一つとして、Communication Managementを入れたのはとても卓見だったと思う。だが、これを「コミュニケーション管理」と、ベタな日本語のニュアンスで捉えてしまうと、本質がずれてしまう。じゃあ赤提灯にいって酒でも飲んで、メンバー同士の「コミニュケーションを良くしよう」みたいな発想になりがちだ。だが、それではプロジェクト・コミュニケーションの半分も捉えていないことになる。

PMBOK Guide(R)は元々、大規模なプロジェクトのことを念頭に置いて作られた。だから、全員が顔見知りでない状態で、どのように知識・情報を確実に他者に伝達するか、ということが問題意識のベースにある。そこで「コミュニケーション計画」のような概念が出てくるのだ。そして実行段階は、「インフォメーションの配布」ということになる。英語のCommunicationは、一方向の配布がベースだからだ。どこにも“飲みニュケーション”みたいな話題の入る余地はない。この英語はむしろ、「情報伝達のマネジメント」と訳した方が、日本の読者にはピンときたと思う。

プロジェクトにおいてコミュニケーションが重要なことは、いまさら言うまでもないだろう。ただ、これほど我々にとって分かりにくく、つかみ所のない領域もない。PMBOK Guide(R)があげる10の知識エリアは、(全体を統合するProject Integration Managementを除くと)大きく二つのカテゴリーに分けられる。

A. スコープ、コスト、スケジュール(タイム)、品質

B. 人的資源、調達、リスク、ステークホルダ、コミュニケーション

上記のカテゴリーAは、いわゆる「ハード・スキル」に属する知識エリアである。つまり、定量的・計数的な管理技術として、かなり確立している分野である。そして、WBS、EVMS、CPM(クリティカル・パス法)、SQC(統計的品質管理)などの手法が開発されている。1950年代のクリティカル・パス法の発見が、モダンPMの誕生をうながした、という歴史も頭に入れておきたい。

そして「ハード・スキル」の特徴は、技術的手法論とツールが発達しているために、座学で習得が可能なことだ。むろん本で読んだり講義で聴いたりしただけでは不十分だ。自分で練習し実践してみないと、使いこなすレベルには達しない。しかし、知識を得ることによって、入門者は相当程度にレベルアップできる。なんとなく、自分にもできそうだ、と感じさせてくれる。

ところが上記カテゴリーBの方は、どちらかというと「ソフト・スキル」に近い面が強い。ソフト・スキルとは、日本語で『人間力』みたいな言葉を使いたくなるような、属人性の高い技能である。人を使う、業者を使う、危険を予知する、利害関係者とうまくやりあう、人に何かを伝達する・・。こうした能力にも、もちろん頼るべき原理原則はある。だからPMBOK Guide(R)でも苦心惨憺して、プロセスだのツールだのを説明している。だが、それを読んで、「うん、これなら俺もできそうだ」と感じる読者は希だろう。

プロジェクトにおけるコミュニケーション(情報伝達)の最大の目的とは何か。それは、次の二つに集約できる。

(1) 必要な知識・情報を、必要な人たちに、必要なタイミングで、最新の内容で伝える

(2) 伝えたことを確認し、トレーサブルにしておく

こうしたことは、PMBOK Guide(R)には明記していない(あの本は全体としてプロセス志向で記述しており、あまり目的志向には書かれない)。しかし、たとえばエンジニアリング業界ではもう何十年も前から、欧米を中心に、世界的にこの目的に従うやり方を守ってきた。

(1)についてはあまり説明の要はないだろう。上の表現はあえて、ジャスト・イン・タイムの「必要なものを、必要な量だけ、必要なタイミングで供給する」という言い方を真似て書いている。必要な情報のみを伝達し、余計なことで膨らまさない。必要な(そして正当なアクセス権限のある)人たちだけに、それを伝える。そして遅滞なく必要なタイミングで伝える。いずれも、当たり前のことだ。ちなみに、文書や図面情報の内容が最新であることがすぐ分かるように、リビジョン番号を明記することなどは、今時どこの業界でもやっているはずだ。

(2)の方は、しかし、業界によってはあまり常識化していないと思う。とくに「伝えたことを確認する」というのは、いささか欧米流に感じられるだろう。かの国々では『発信者責任の原則』でビジネス文化が動いており、相手に伝わるよう、ちゃんと伝えるのは、発信者側の責任だからだ。だからこそ、相手が分かったかどうか、自分から確認する。

ところが、わたし達の社会は『受信者責任の原則』で暗黙のうちに動いている。伝わらない・分からないのは、メッセージを受け取った側の、理解する努力が足りないからだ、ということになっている。分からないのは恥だから、質問も返さない。逆に「一度しか言わないからな!」と偉い人が怒鳴ったりする。こういう土壌を持った社会に、「コミュニケーション・マネジメント計画を立てましょう」などといっても、何のことやら、である。

トレーサブルという言葉には、多少注釈が必要かもしれない。「トレーサビリティ」という用語は、誰にも分かりやすいように選んだもので、わたしの勤務先では、「トラッキング可能」という方が通じるだろう。いずれも、後からさかのぼって、どういう経緯で今どこまでたどり着いているかを、明らかにできるという意味だ。ちょうど牛肉トレーサビリティと同じように、である。

このためには、すべての情報の伝達に、ユニークなIDをふることが必要になる。それは、わたし達の業界では、何十年も前の紙の時代から、実践してきたことだ。たとえば顧客に公式なレターを発信する。あるいはベンダーに仕様書を送付する。ベンダーから逆に承認図が上がってくる。これを協力会社の関係部署に送付する。こうした伝達行為はすべて、IDをふって、リストに記録する。たとえば、

T-YOC-ABC-0012

といった具合だ。最初の一文字は伝達の種類を表す(TならTransmittalで、書類の送付状である)。次に、発信者-受信者、を表すコードが来る。関連するステークホルダはすべて3文字の略号をつけるのがわれわれの慣例だ。最後は連番である。だから上記のIDは、

「YOCからABC社への書類送付状の12番目のもの」

という意味になる(YOCというのはYokohama Operation Centerの略で、わたしの勤務先の本社のことである。建設現場もあるためこういう表記をするのだ。どうでもいいけど)。これを連綿とリストに記帳していく。その書類送付状には、添付された一連の仕様書や図面の番号とリビジョンが記載されているはずだ。紙の時代だったら、この送付状は複数枚つづりになっていて、受け取った側は受領サインを記入して、返送する。こうして、受領確認が行われる。現代ではもちろん、こうした手続きはすべて電子化されているが、エッセンスは同じである。

だから仮に、後になってABC社と追加交渉でもめたときにも、「T-YOC-ABC-0012でこの図面はあなたに何月何日に送っていて、そちらも受信確認を返しているではないか」という風に証拠立てられる。言った・言わないの無駄な議論を省けるだけではない。情報を受け取った側も、お互いがそれを注意深く取り扱うようになる。

書類送付状ではなく、単純な文章による伝達(昔ならレター、今ならeメール)も、同様である。IDをふっておき、発信した内容、受信した内容は、プロジェクト・チームとしてセンター・ファイルしておく(これも昔なら紙、今ならデータベース)。チーム員はいつでも、それを探せるようにする。こうしたセンター・ファイルをきちんと持っているならば、少なくともそのプロジェクト・コミュニケーションは及第点であるといえよう。

そしてこういう手続きに従って、すべてのやりとりをトレーサブルにしておくよう、新入社員の時から習慣づける訳だ。これがわたしのいう、組織の「OS」の一部を形成していく。こうしたベーシックな行動習慣をチーム員みなが持って、はじめて、プロジェクト・マネージャーの能力が本来の仕事に生かせるようになるのである。

→「革新的生産スケジューリング入門」にもどる

プロジェクト・コミュニケーションのベーシック(2) 〜 ドキュメント・インデックスを作る (2016-10-14)

前回の記事「プロジェクト・コミュニケーションのベーシック 〜 情報のトレーサビリティを確立する」で、英語で言うCommunication Managementとは、日本語的感覚でいう「コミュニケーションの管理」ではなく、むしろ『情報伝達のマネジメント』に近い、と書いた。だから、伝達のトレーサビリティ確保が大事になる、と。

今回はその続きである。だがもう一歩進んだあり方として、「ドキュメントのインデックス化」の話をしたいと思う。ドキュメントのインデックスとは何か? 簡単だ。それはプロジェクトが作成する文書・図面類をリスト化して、多少の属性を付加したものである。「ドキュメント・リスト」と呼ばれる場合もある。

なあんだ、そんなのならいつでも作ってるよ。そういって、ドキュメントが保存されているサーバのプロジェクト・フォルダから、ファイルのリストを印字して持ってくる人がいる。ファイル名の他に、作成日、更新日、ファイルサイズ、種類などの属性が並んでいる。−−これのことでしょ?

全然違うのだ。そんなリストは、プロマネにとってどんな行動の契機も与えない。そのファイル・リストを見たら、まだ出来上がっていないドキュメントが何と何か、分かるだろうか? どの図面が予定よりはるかに遅れて作成されたのか、問題発見の手がかりになるだろうか。誰を応援したり督促したりすべきなのかの、判断材料になるだろうか? なるまい。

プロジェクト・マネージャーという職種は、最初に計画を立て、実行段階ではその計画からの逸脱をチェックしながら、問題をつぶしたり変更を追いかけたり、決断を下したりして、なるべくプロジェクト全体の生み出す価値を高めていくのが仕事である。だから問題発見のツールをいろいろ持っていて、そのセンサー感度を上げる仕組みが必要だし、問題解決のためには、何がいつどこで起きたのかを、正確にさかのぼってたどれる道具が必要なのだ。

ドキュメント・インデックスは、そのためのツールである。これ自体は、単純な表になっている。プロジェクトで作成しなければならないドキュメントを、すべて、重複も漏れも落ちもなく、計画段階であらかじめリストアップしておく。そして、各ドキュメントは、誰が担当で作成するのか、WBSのどのアクティビティで作成するのか、したがっていつ作成される予定なのかを、あらかじめ決めて書いておく。

つまり、ドキュメント・インデックスは、初期段階では「まだ存在していない文書の属性付きリスト」なのである。ファイル名のダンプリストじゃ役に立たないことは、おわかりだろう。それは「すでに存在している文書のリスト」を示すだけだ。あるいはもう少し高級な、いわゆるContents Management System風のリストも、役に立たない点では変わりない。そうした道具立ては、存在しているファイルの『在庫管理』には有用だろう。だが、まだ存在しない、これから作成すべきドキュメントについてのコントロールには、あまり役に立たない。

ドキュメント・インデックスというは次のような構造をしている。持つべき主な属性は、以下の通りだ:

(1) ドキュメントのID
(2) ドキュメントの名称
(3) ドキュメントのリビジョン番号
(4) プロジェクトNo.およびWBS No.
(5) 発行目的
(6) 作成者・検討者・承認者
(7) 発行予定日
(8) 発行実績日
(9) ドキュメントを構成する電子ファイルのリスト

すべてのドキュメントは、ユニークなIDを持っていなければならない。これは当たり前のことだ。従業員番号のない社員がいてはいけないのと同じである。何かをトラッキングしたりコントロールするためには、IDがいる。これは情報システムの世界では常識であろう。(それなのに、自分が仕事をする段になると、設計文書をタイトルだけで『管理』して平然としているシステム・エンジニアがいたりするのは若干、謎である)

ドキュメントにはリビジョン番号があるのは当然だが、WBSの中のどのアクティビティで作成されるものかを示すことも(当然ながら)大事である。誰が担当で、いつ出来るのかは、それによって決まる。作られたら、次にどこのアクティビティで利用されることになるのかも、注意しなければならない。かつて「仕事の最小単位−−アクティビティの構造を学ぶ」にも書いたように、文書(情報)はアクティビティのアウトプットであると共に、次のアクティビティのインプットともなるからだ。

ちなみに、わたしの勤務先では、ドキュメントのIDは、種類を示すコードと、それを作成するアクティビティのWBS No.を元にして構成している。一つのアクティビティから複数のドキュメントが作られるのが普通だから、後ろに連番をつける。かつ、それを電子ファイルの命名規約にもしている。ついでながら、仕事のプロセスを示すFunctional WBS (F-WBS)は標準的なコード体系にしたがっているため、どのプロジェクトでも、たとえばポンプの設計図書は同じF-WBS No.を持っている。だから、ドキュメント番号やファイル名称を見ただけで、「これはポンプの調達仕様書だな」と分かる仕組みになっている。

それから、インデックスには、何のために発行されるのかという目的がいる。つまり、顧客に出す承認用(For Approval)だとか、顧客からOKをもらった施工用(For Construction)だとか、あるいは据付工事後の最終納品版(As-Built)といった区別である。もちろん、顧客に気に入られないと、承認用を2回も3回も出し直し、という事態だってありえる。だからリビジョン番号と発行目的は、1対1にはならないのである。ちなみに「発行」という用語は、英語のIssueの翻訳だが、耳慣れないと思う人もいるかもしれない。これは、正式版として社内関連部署や顧客や外注先に対して配布する作業を意味している。「出図」という言い方をする企業もある。

作成者・検討者・承認者の項目は自明だろう(スペースの関係で一つにしているが、実際には別々にするのが普通だ)。

そして何よりも大事なのは、「発行予定日」と「発行実績日」である。プロジェクトの計画段階で、ドキュメント・インデックスを作る際に、個々のドキュメントの発行予定日を記入しておく。これは、プロジェクトのマスター・スケジュールに合致していなければいけない。そして、遂行段階に入って、実際にどんどんドキュメントが作成されるようになったら、それぞれの実績日を記入していくのである。

この予定日と実績日があるから、プロマネは問題を事前に検知したり、メンバーに上手に督促したりすることができるようになるのである。「今週、発行予定のドキュメントはこれとこれです。担当者はもし何か問題を抱えているようなら教えてください。支援します。」といった風に、週次のミーティングでいう訳である。

そして実際に発行されたドキュメントは、必要とする関連部署(下流側のアクティビティに関わる部門)や外部ステークホルダーに送付するとともに、プロジェクトのセンター・ファイルに保管する。情報伝達のトラッキングが必要になったら、プロマネは(あるいは、もう少し大規模なプロジェクトの場合は、専任のライブラリアン役の担当者が)、そのセンター・ファイルと、インデックスの履歴をチェックする。これがドキュメント・コントロールの仕事である。わたしが勤務先でこのようなやり方を初めて知ったときは、その見通しと効率の良さに舌を巻いたが、わたしの先輩達はどうやら何十年か前に米国の同業者達のやり方に学んだらしい。

またこうしたデータがあると、横軸に日付をとって、縦軸に発行予定ドキュメント数の累計をプロットしていけば、S字カーブが得られる。これに実績の線を書き加えれば、プロジェクト全体の遅れや進み具合が一目瞭然になる。一般に、設計作業の進捗は目に見えにくく、把握しづらい。ドキュメント・インデックスは、その進捗を可視化するためのツールになるのである。

わたしの業界では(海外の大規模プロジェクトは特に)進捗に応じて顧客が支払う契約が多い。このとき、設計の進捗を、発行されたドキュメントの数で測るのである。全体で100部の図面やドキュメントを作成する予定であり、現時点では45部が発行済みだから進捗45%、といった計算である。単純だが、分かりやすい。むろん、図面には情報量の大小があるし、ドキュメントだって厚いのも薄いのもある。だからそんな進捗計算なんかナンセンスだと、いえないことはない。だが、今日までに100部作成する予定なのに、まだ10部しか出来ていなかったら、やはり何かおかしいと判断するきっかけにはなる。測れないものは、マネジメントできない。もし設計をマネージしたいのなら、設計の進度を測る何らかの仕掛けが必要なのだ。

最後は、そのドキュメントを構成するファイルのリストである。本文はWordだが添付資料はExcelの表です、といったものはよくある。こうしたセットを、ひとつの「ドキュメント」として扱うのである。だから、個別のファイル単位にしか属性を扱えないCMSみたいなツールは、ちょっと不便だということになる。

と、ここまで読んだ読者の方は、二つの疑問を持たれるかもしれない。

Q1: 本当に最初の段階で、プロジェクトが作成すべきドキュメントを全部もれなく洗い出せるのか? 途中でどんどん増えてしまったりするのではないか。

Q2: ドキュメントの発行予定日なんて、そんな初期に決められるはずがない。

このような疑問は、プロジェクトの「初期の段階」という理解にズレがあるために生じると思われる。まさかプロジェクトの初日に、ドキュメント・インデックスを作れる訳はない。プロジェクト計画がある程度進んで、WBSが作成され、マスター・スケジュールが出来上がったタイミングでなければ、もちろん作ることはできない。それはすなわち、プロジェクトの全体像の目鼻がついた段階だ。目鼻とはつまり、成果物の構成(Product-WBS, P-WBS)がだいたい決まり、かつ、それを作るまでのプロセス手順(F-WBS)が見えて、アクティビティ・マトリクスができた時点である。

(アクティビティ・マトリクスとWBSについて知りたい方は、拙著「世界を動かすプロジェクトマネジメントの教科書」参照のこと)

もちろん、プロジェクトの遂行途上で、インデックスにドキュメントを追加せざるを得なくなったり、あるいは削除(キャンセル)することもあり得る。追加は、当然ながらユーザの意向でスコープの増加があった場合、そして当初の見積が不足していた場合の二つがある。だから、この両者は区別できるようにしておかなければならない。そしてプロジェクトが完了したときに、自社理由で増えた分と、外部理由で増えた分が、それぞれどれだけあったかを調べ、次にドキュメント数を見積もるときには、どう教訓(Lessons Learned)を生かしたら良いかを、考える材料にするのである。こうしたことをしない限り、見積の精度など向上する訳がない。

そして、ドキュメント・インデックスを作る理由は、まさに自分たちの予測能力を高めるためにあるのだ。ドキュメント・インデックス作成というのは、プロジェクトのマスター・スケジュールなどと似ていて、プロジェクト全体を表す一種の『モデル』なのである。プロジェクトという複雑な、かつ見通しにくいシステムをモデリングする事。これこそが、プロジェクト・マネジメントの中心技術でなくて何だろう? 最終形を見通さぬまま、なりゆきでドキュメントを積み上げていっただけでは、最後に手元に残ったリストを見ても、次に生かすのは至難の業だ。経験から学ぶためには、自分が何を見通して、何を見通せなかったかを、後から追えるようなトレーサビリティが必要なのである。


→「革新的生産スケジューリング入門」にもどる
サイトマップ
このページの冒頭に戻る

(c) 佐藤知一
e-mail: tomsato@rio.odn.ne.jp