◆マネジャーとリーダーの違い

ＰＭ養成マガジンを始めたころに、「プロジェクト管理とプロジェクトマネジメントは違う」、「プロジェクトマネジャーがすべきことはプロジェクトマネジメントであってプロジェクト管理ではない」と言い続けてきた。それは言葉の遊びだと指摘されることも少なくなかったが、僕の中では明確な区別があった。そろそろ、区別を明確にしたいと思う。

これに関連する議論で、マネジャーとリーダーはどう違うかという議論がある。この議論は、古くから行われている。この議論のベースラインができたのは、ハーバード・ビジネススクールの名誉教授アブラハム・ザレズニック氏の論文
「マネジャーとリーダー：その似て非なる役割」
という論文だ。この論文はハーバードビジネスレビューに1977年に掲載され、当年のマッキンゼー賞を受賞し、大変有名な論文である。ザレズニック氏はマネジャーとリーダーはまったく別の人種であるとして、以下のような指摘をしている。

（１）目標の違い
【マネジャー】人間の欲求よりは仕事上の必要性から生じるため受動的に見える
【リーダー】能動的であり、個人の意志の下、積極的な態度で臨む。人々のイメージや期待を喚起し、何らかの欲求を明らかにし、目的に向かって決断することで、組織が進むべき進路を決定する

（２）仕事観の違い
【マネジャー】戦略を立案し、意志決定を下すため、人々とアイデアを結びつけ、問題解決を図る。問題解決においては矛盾する価値の間で妥協案が受け入れられるように、バランスを図る。
【リーダー】積年の問題に新しい方法を導入し、どのような選択があるのか議論する。

（３）人のつきあい方の違い
【マネジャー】進行中の案件のや意志決定プロセスにおける役割を果たすために他人と交わる
【リーダー】何らかのアイデアに興味を抱いているとき、本能的に、しかも深く感情移入して人間関係を築く

（４）人格特性の違い
【マネジャー】自らを秩序の維持者あるいは調整者と考える
【リーダー】自分が何者かについてどのような組織に帰属しているのか、どのような仕事の従事しているのかを全く意に介さない

マネジャーとリーダーは、マネジメントとリーダーシップと置き換えて読んでもいい。このあと、この議論は進展しているが、大きくは変わっていないように思う。おそらく、１９８０年には、マネジャーはマネジメントを行い、リーダーはリーダーシップを発揮することが期待されていた。

◆リーダーシップが求められるようになってきたマネジャー

今の時代は、リーダーに期待されるものは変わらないように思うが、マネジャーに求められるものは大きく変わっている。マネジメントに加えて、リーダーシップの発揮が求められるようになってきたのだ。それは、イノベーションであったり、あるいは、スピーディーに決めることであったりする。「プレイングマネジャー」という言葉があるが、プレイングマネジャーとは、「リーダーシップを発揮するマネジャー」のことである。プレイングマネジャーが主役になっていることがマネジャーの役割が変わってきていることを示す証拠だといえよう。その意味で、マネジメントという言葉も、単にＰＤＣＡを回す「マネジメント」ではなく、「決める」、「変える」を含んだ言葉として定着してきている。

◆プロジェクトのマネジメント

さて、このような背景があることを理解していただいた上で、プロジェクトにはどのようなマネジメントが必要かを考えてみよう。

まず、一つは、プロジェクトの実行戦略を立案し、プロジェクトの意志決定を下すため、メンバー・ステークホルダやアイデアを結びつけ、問題解決を図ることである。要するに、計画を作って、その計画に基づいてプロジェクトをコントロールしていく役割である。

ただし、これだけではなくリーダーシップも求められることが多い。問題に合理的な解決策がない場合には、リーダーとして自分の考えで、どのようにするかを決めなくてはプロジェクトは進まない。たとえば、これまでの経験に照らし合わせるとどう考えても納期が間に合わない。このときに、納期を延ばすのか、仕事の仕方を変えるのか、といったことは決めた上で、プロジェクトが一丸となってその決定を支えていくように導いて行かなくてはならない。

つまり、プロジェクトマネジメントは、単に、計画を作って進捗を管理するだけの役割ではなく、プロジェクトの進め方に関する意志決定をしたり、あるいはプロジェクトの中での仕事のやり方を変えるといったリーダーシップも必要である。このようなプロジェクトマネジメントを支えるリーダーシップは「プロジェクトリーダーシップ」と呼ばれる。

◆組織の立場からのプロジェクトのマネジメント

これに対して、事業管理、経営管理の立場からのプロジェクトの管理という仕事も、広義の「プロジェクトマネジメント」である。たとえば、「組織のプロジェクト実施目的とプロジェクトの実行状況が整合していることを管理する」、「プロジェクトの効果に見合った資源投入をする」、「プロジェクトの状況を把握し、状況に応じたリソースのマネジメントを行う」といったことである。

PMstyleでは、前者のプロジェクトマネジメントを「プロジェクトマネジメント」とよび、後者を「プロジェクト管理」と呼んでいる。そして、前者の実施者を「プロジェクトリーダー」、もしくは、「プロジェクトマネジャー」とよび、後者を「プロジェクト管理者」と呼んでいる。また、プロジェクトマネジメントとプロジェクト管理を併せたものを戦略的プロジェクトマネジメントと呼んでいる。

プロジェクトマネジャーとプロジェクトリーダーの違いは、マネジメントが中心か、リーダーシップが中心かによって分けている。組織の中でマネジャーとリーダーは上下関係として使われているケースがあるが、PMstyleでは対等で、プロジェクトのタイプによって適性があると考えている。上下関係があるのは、プロジェクト管理者とプロジェクトマネジャー、あるいはプロジェクトリーダーである。

◆戦略的プロジェクトマネジメントとは

最後に、プロジェクトマネジメントに（プロジェクト）リーダーシップが必要なように、管理にも「シップ」は必要である。それがプロジェクトスポンサーシップである。

以上をまとめると、

戦略的プロジェクトマネジメント
＝プロジェクト管理（スポンサーシップ）＋プロジェクトマネジメント（リーダーシップ）
という図式になる。

◆フォロワーシップという考え方

「フォロワーシップ」という概念がある。くどくど説明するより、リーダーシップの逆の概念だと思ってもらうのがいいだろう。この概念は、1980年代に、リーダーシップの研究者だったロバート・ケリーが提唱し、1992年に「The Power of Followership」という本にまとめた。この本がバイブル的な位置づけになっている。

２～３年前から、日本でも着目する人が増えてきた。

ただ、リーダーシップが普及の初期において、「上司力」だと限定的に考えられていたように、現在のところ、「部下力」であると限定的に考えている人が多い。ロバート・ケリーが指摘しているように、リーダーシップがリーダーが目標とするものであるのに対して、フォロワーシップは「不快感」を与えるものである。従って、部下力と限定されているのではないかと思える。

部下力という言葉は、会社に入って２～５年目くらいの社員が、「偉い」マネジャーやリーダーに対して、自主的に手伝いをしたり、あるいはものを申すといったイメージだが、フォロワーシップは決してのそのようなものではない。

世界でもっともたくさん読まれているフォローワーシップのガイド「The Courageous Follower」のアイラ・チャレフは、このガイドはすべてのレベルのフォロワーシップに有効であると述べているが、新入社員とその上司の間でも、部長と事業部長の間でも同じ考え方ができるということで、まさに、シップである。

組織の中のさまざまなレベルでのフォロワーシップを重視している企業として有名なのは、スターバックスコーヒーである。スターバックを支えるのは、「情熱的なフォロワーシップ」であると言われている。詳しいことは書籍などでしか知るすべがないが、その成果は店舗でも垣間見ることができる。

◆プロジェクトマネジャーのフォロワーシップの必要性

さて、プロジェクトマネジメントの話に移る。プロジェクトマネジャーにはチームを引っ張るリーダーシップが必要だと言われる。このことについては全く異存はないのだが、リーダーシップだけでいいのかという思いはある。特に、戦略的なプロジェクトマネジメントやプロジェクトガバナンスを考えた場合、プロジェクトマネジャーにとって、リーダーシップを同じくらい、フォロワーシップが重要なのではないかと思う。

多くのプロジェクトマネジャーが指摘するように、上位のマネジャーが「仕事をしない」のでプロジェクトがうまく行かないという現実がある。このような現実を目の前にして、プロジェクトマネジメントなどやっても仕方ないという人も決してすくなくない。そこまでは言わないまでも、「自分たちは現場のプロジェクトマネジメントさえしっかりやればよい、結果としてプロジェクトがうまく行かないのは自分たちの責任ではない」というスタンスのプロジェクトマネジャーはかなり多い。

このようなプロジェクトマネジャーにもってほしいのがフォロワーシップとして、上位マネジャーをしっかりと支え、場合によっては意義を唱えていくことである。アイラ・チャレフは「The Courageous Follower」の翻訳のタイトルは、残念ながら「ザ・フォロワーシップ」となっているが、Courageousは「勇敢な」という意味。

◆勇敢なフォロワーシップ

アイラ・チャレフは勇敢なフォロワーシップは５つの勇気の上に成り立つとしている。

・責任を負う担う勇気
・役割を果たす勇気
・意義を申し立てる勇気
・（リーダーの）改革に関わる勇気
・良心に従って行動する勇気

戦略的プロジェクトマネジメントにおいては、この５つの勇気はすべて重要である。また、戦略実行の責任を担うこと。役割を果たすこと。そして、上位マネジャーや組織の行動が戦略実行において適切でない場合には、それに対して意義を申し立て、マネジャーの行動や組織を変えていくこと。その変革に積極的に関わっていくこと。そして、それらが正しく行われていない場合に、見過ごすことなく、指摘をしていくこと。

◆上位マネジャと共通目的を持つことからはじめよう

ロバート・ケリーによると、フォロワーシップの行動の源泉になるのは、「共通目的」である。プロジェクトマネジャーが上位組織に対してフォロワーシップを発揮するためには、まず、プロジェクトの目的を共有することから始めればよい。プロジェクトマネジメントの作法では、プロジェクトの目的は上位組織が決めることになっているが、その点にこだわる必要はない。

プロジェクトマネジャーが自ら目的を明確にし、それを上位マネジャーと共有できれば、フォロワーシップの成功は約束されるだろう。

プロジェクトを任された部下として、上位マネジャーとさまざまな交渉にあたり、顧客の要求を実現するような条件を引き出すのも悪いことではないが、これはあくまでも上位マネジャーがしっかりしていればの話だ。一方で、マネジャーを非難しながら、一方でたてるというのはナンセンス。

そんなつまらないことに時間を費やしているのであれば、フォロワーシップへの取り組みを試みてみてはいかがだろう。

そのために何をすればよいか？このブログでも時々、述べようと思っているが、待てない人は、とりあえず、アイラ・チャレフの本を読んで自分なりに考えてみてはどうだろう。

◇プロジェクトの３つの見方

プロジェクト活動を企業にとって有意義なものにするためには、デザインにおいてプロジェクトに対して３つの見方をしてみる必要がある。その３つとは

（１）視座
（２）視野
（３）視点

である。

最初の視座とは、誰がどのような目的を達成するために実施するプロジェクトかという見方だ。二番目の視野とは、そのプロジェクトをどのような範囲、どのような時間で捉えるかという見方だ。三番目の視点はよく使われるとおり、そのプロジェクトにどのようにアプローチしていくか、言い換えると目標をどのように設定するかという見方だ。

現場のプロジェクトマネジメントでは、視点が重視されている。しかし、視座や視野も持ち込まないと、経営的な成果は上がらない。

◇プロジェクトに対する視点

それぞれについてもう少し、詳しく考えてみよう。

視点については、目標設定であるので、その重要性は理解されているとおり。プロジェクトの目的を達成するには、何を目標にとり、目標値をどのレベルに設定すればよいかはプロジェクトマネジメントの肝要でもある。

一言付け加えるならば、ＳＱＣＤ（スコープ、品質、コスト、納期）だけの視点からの目標だけで、プロジェクトをうまくマネジメントできるかどうかというのは大いに考える必要があるということだろう。たとえばベースラインとしてよく使われるものに人的資源があるが、それ以外にもリスクに対する目標、調達に対する目標など、さまざまな視点からの目標を検討してみて、必要なものはどんどん取り入れていくという柔軟性が求められる。

◇プロジェクトに対する視野

次に、視野について。多くの問題プロジェクトは視野についての考えが欠如しているケースが多いと思う。素直に考えれば、視野というのはスコープだ。これ自体は正しい。問題はスコープという概念を矮小化して扱っていることではないかと思う。

上で触れましたように、視野には空間的な視野と時間的な視野がある。

まず、空間をみれば、どんな小さなプロジェクトでもプロジェクトチームの活動が単独で行われることはまずない。情報化でも商品開発でも投資でも、プロジェクトチームを作って活動を始めた場合には、必ず、周囲でそれに関連する活動が発生している。たとえば、情報化のプロジェクトだと、システム開発のプロジェクトに併せて、仕組みやルールの変更や、組織の変更などの活動をするのが一般的だろう。商品開発だと、商品そのものの開発に併せて、販売チャネルの開発や調整、プロモーション活動などを行うのが普通だ。

また、その活動からプロジェクトが生まれているケースも少なくない。たとえば、ビジネスプロセスの革新の活動の中から、情報システムの開発プロジェクトが生まれるといったケースだ。

これらの活動のうち、プロジェクトに取り込むものとプロジェクト外で行うものの整理をするのがスコープ定義（区分）である。

また、時間に関していえば、プロジェクトしてどこで終わるべきか、つまりプロジェクトライフサイクルを考える必要がある。ＩＴのプロジェクトであれば運用後をどのように位置づけるのか、商品開発のプロジェクトであれば発売後をどのように位置づけるかといった視野からの検討が必要だ。

これらをプロジェクトのスコープに取り込むかどうかによって、プロジェクトの目的はもちろんのこと、アプローチそのものが変わってくる。たとえば、ＩＴのプロジェクトで、１年間でシステムを開発することがスコープの場合と、開発後１０年間の運用アウトソーシングを含めてプロジェクトとした場合には、開発スケジュールそのものが変わってくるだろう。

その意味で、プロジェクトをデザインする際に、視野を変えて検討することは、プロジェクトの実施に当たってきわめて重要だといえる。

◇プロジェクトをデザインする視座

３つ目の見方は視座だ。

プロジェクトには代表的な３つの視座がある。プロジェクト実施を指示する上位組織（経営）、プロジェクトを実施するプロジェクトチーム（現場）、そして、プロジェクトの成果を活用するステークホルダ（一般には顧客や市場、場合によっては営業や流通）である。

プロジェクトをデザインする際には、現場の視座からだけではなく、経営の視座、顧客の視座から十分に検討する必要がある。そこに現場の困難を乗り越えるヒントがあるからだ。

◇プロジェクトの上位マネジャーの方へ

このように考えてみたときに、現場レベルで行き詰っているプロジェクトを成功に導くためには、視座を上げる必要がある。これは一般には、プロジェクトの上位マネジャーの役割だ。現場で短納期、低予算で苦しんでいるプロジェクトに対して、プロジェクトマネジャーに知恵を貸して問題を解決しようというのはプロジェクトではあまり有効だとはいえない。これはプロジェクトのコンサルティングをやっていても感じる。今、プロジェクトで起こっている問題は、マネジャーが経験したことのないような問題だからだ。確かに現場改善は重要であることに変わりはない。しかし、それは現場に任せ、経営の視座でそのプロジェクトをどのように定義すればよいかを考えるべきである。

経営レベルで考えれば、長期の安定的な取引の構築とか、人材の育成とか、いろいろとそのプロジェクトを実施する理由は見つかるはずだ。場合（戦略）によってはブランド構築ような理由もあるかもしれない。

また、組織ですので、視座が変われば視野も変わる。たとえば、システム開発のプロジェクトで開発部分だけでみれば採算が合わなくても、視野を広げて運用を取り込んでいくとか、あるいは開発プロジェクトを生み出している顧客側の仕事を取り込んでいくといったことで、問題を回避できる可能性もあろうだろう。

以上のようなことは、断片的には今もやっていることだと思うが、視座、視野、視点というフレームを持ち込むことによって、もっとうまい方法が見つかる可能性も大である。この点については、ぜひ、一度、真剣に考えてみる必要があるのではないかと思う。

◆実行責任と結果責任

「任せる」と「丸投げ」の違いがよく分かっていないマネジャーが少なくないことに愕然とすることがある。両者の違いは、「責任」の負い方にある。

任せるというのは、実行責任（業務プロセスに対する責任）は任された人が負い、結果責任は任せた人が負う。丸投げというのは、任せて結果責任も負わないことをいう。

レスポンシビリティとアカウンタビリティをきちんと分散するのが任せることで、双方を末端に押しつけることが丸投げだと言ってもよい。

◆職務を全うすることによって責任を負うのが「任せる」ということ

結果責任を負わないということができるはずがないと思う人も多いが、実際にはまかり通っている。この議論には責任を負うとはどういうことかがついて回る。

以前の日本的な考え方は、ある立場で何か問題を起こしたら、とりあえず、その立場を退くことによって責任をとっていた。政治でいえば大臣が辞めるというのがそうだし、企業であればトップが辞任する。

しかし、この１０年くらいの風潮をみていると、「職務を全うすることによって責任をとる」という「当たり前の考え方」がかなり広まってきた。要するに責任をとるとは、問題を何とかすることである。

結果責任を負わないというのは、問題を何とかしよう（職務を全うしよう）とせず、「任している」という金科玉条のもとに、見て見ぬふりをする。経営陣に説明をするような場面がくれば、平気でプロジェクトマネジャー一人のせいする。これは丸投げ。

プロジェクトマネジャー育成ブームはこの延長線上にあった。プロジェクトマネジャーの悩みの中に今でも「丸投げ」というキーワードがあるのはある意味で当たり前で、丸投げ保護施策をしていた訳だ（もちろん、それは枝葉末節の話で、育成の意味は十分ある）。

◆プロジェクトでは起こる問題の解をマネジャーはもっていない

この話は、プロジェクトというものに対するとんでもない勘違いに基づくものだ。一昔前の日本型の組織では、このようなやり方を丸投げとは言わなかった。もちろん、本当に丸投げをしていたマネジャーもいたとは思うが、おおむね、育成のために「やらせていた」のだ。かといって、「任せていた」わけではない。あくまでも自分の代わりに「やらせていた」のだ。

なぜ、そのようやり方ができたかというと、マネジャーは経験的に「うまくいく方法」を知っていたのだ。だから、いざとなると自分が介入していけばよかった。

ところが、今はマネジャーもよく分からない。いわゆる「正解のない問題」が増えている。プロジェクトでよく起こる問題をみても、どの業界でも、「正解のない問題」だと思えるものがある。少なくとも、経験で正解を導けそうもない問題がある。

だから、「プロジェクト」として取り組むのだ。にもかかわらず、自分が正解をもっていると考えるのは勘違い以外の何者でもないのだが、勘違いをしているマネジャーは少なくない。

◆部下への対応にも潜む「経験の落とし穴」

もう一つ、経験が問題になっていることがある。部下の育成である。自分は上司に「やってみる」ことで育成された経験を持っているマネジャーが多い。とりあえず、マネジャーになってどうやってよいか分からないときに、この経験に基づいて行動する。

丸投げしようと思っているマネジャーは少ないと思う。「やってみろ」と言ってみたものの、問題が生じたときに「答え」を示せないで、結果として丸投げになってしまったというケースが多いように感じている。

そのようなマネジャーが飛びつくのがコーチングである。ある意味健全で、「自分は答えを出せないので、頑張ってくれ」と考えているわけだ。

◆「正解のない問題」の２つのタイプ

ここで考えるべきことがある。正解がないという状況（問題）には２つの種類がある。「決めなくてはならない」問題と、「決めようのない問題」である。前者の典型的な問題は、ＱＣＤＳのコンフリクトである。仕様がふくらみすぎて、どのように工夫をしても今のスケジュールで十分な品質の商品を開発するのは難しい。これは決めなくてはならない問題である。逆にいえば、決めれば解決する問題である。

これに対して、ある機能がどうしても実現できない。その機能が計画通りに実現できないとこの商品は価値が全くない。代替技術はあるが、機能は低下する。という場合、これは「決めようのない問題」、本当の意味で正解のない問題である。

後者の場合にはコーチングは有効だと思う。しかし、前者の場合には、まったく見当違いで、状況を解決するには自分が決めるしかない。このような状況をコーチングを行い、決めさせようとするのは、丸投げ以外のなにものでもない。この判断は最終成果に対する責任を伴う判断だからだ。

少なくとも、ＱＣＤＳのプライオリティ、あるいはもう少し抽象的なレベルでのプライオリティ（たとえば、まず、十分な品質の成果を達成できるメンバーの心身の健康が優先、次に顧客満足度、最後が収益といったもの）を決めて、その上でプロジェクトマネジャーに具体的な方策を練らせる。その上で、そのプライオリティに基づき問題解決を行った結果についてはすべて責任を負う。これが任せるということだ。

◆プロジェクトマネジャーにとっての「任せる」問題

さて、マネジャーとプロジェクトマネジャーを意識して意見を述べてきたが、当然、プロジェクトマネジャーとメンバーの間にも同じ関係がある。これはプロジェクト制度のよいところで意識していなくても結果的にそうなる。マネジャーの方針を受けて作成したプロジェクトが達成できない場合の「結果責任」はプロジェクトマネジャーにある（上に述べたようにこれはあくまでもプロセスの責任である）。

ただし、そのためにはプロジェクト管理計画を細かく作る必要があるのはいうまでもない。プロジェクト管理計画というのは勘違いしている人もいるが、作業段取りではなく、プロジェクト内のガバナンスを明確にするとことに作成意義がある。

ここをしっかりと認識しておかないと、結局、プロジェクトのスケジュールの遅れや品質の未達成を「メンバーのスキル」というキーワードで逃げてしまうことになりかねない。これはマネジャーに対する責任転嫁に他ならない。

マネジャーとプロジェクトマネジャーで責任の転嫁の泥仕合をしている中で、迷惑するのはメンバーだということを認識しておく必要があろう。

◆制約条件は６つ

ＰＭＢＯＫのプロジェクトマネジメントの対象となる制約条件が、従来の３つ（４つ）から６つに変わった。

・スコープ
・品質
・スケジュール
・予算
・資源
・リスク

説明としては、これらの要素は相互に影響を与えるため、そのバランスが重要であるという説明にとどまっているが、なかなか、興味深いのは５つのベースラインに加えて、リスクが入っていることである。

他の５要素が変わるとリスクも変わるので、リスクも併せてどうするかを考えなさいといえば一見当たり前のように思えるが、実はそうでもない。

◆「問題は存在しない」という意識の中のリスクマネジメント

これまではプロジェクトには「リスクは存在すべきではないが、結果としてリスクは存在する」、もっと端的にいえば、「計画に問題はない」というスタンスだった。これに対して、リスクに対するバランスを考えることは、「問題はある」ということを前提にしたマネジメントに変わっていくことになる。

これが何を意味しているか？

問題は存在すべきではないという立場は、例えば、スケジュールでいえば、

「スケジュール計画は適正なものである（問題はない）。しかし、諸般の事情でスケジュールが遅れることもある」

という前提で、マネジメントを行う。そこで、スケジュールが遅れるのはどんな状況が考えられるかと分析し、それをリスクとして監視していくというものだ。計画段階でリスクを識別し、対応するという意味では、プロアクティブなのだが、リスクに対する姿勢そのものはリアクティブである。そのために、例えば、計画段階で大幅に工程を組み替えるとか、生産性向上対策にコストをかけてスケジュールのリスクを回避するといった対応は「しにくい」。なぜ、そこまでということになる。

これに対して、

「スケジュール計画には問題がある」

ということを前提にマネジメントを行うことになる。この場合に、問題が解決できればそれだけの話だが、現実には問題はどうしようと完全には解決できないのが今のプロジェクトである。つまり、リスク対応をすることによって、問題を最小化することが求められる。これが６つの制約のバランスを考えるということだ。

◆リスクの制約化でリスクマインドが高まる

ここにこだわりたいのは意味がある。どうも、リスクマネジメントが形骸化している。というよりは、本当のところ、リスクがあると思わないで、形ばかりのリスク識別をしているケースが目立つ。そのため、リスクに上げていて、リスク対応計画まで決めておきながら、現実にそのリスクが発生するとあたふたとして、あげくの果てにはリスク計画はチャラにして、その場で、その場しのぎにリスク対応をしているケースが多い。

我々はリスクマインドの欠如と言っているが、リスクマインドの欠如をもたらしているのが、「問題はない」、「リスクはあるべきではない」という前提ではないかと思っている。その点で、今回のＰＭＢＯＫのリスクに対する視座の変更は、リスクマインドを高めるのに一役買うことを期待できる。

また、このような意識は、ストレッチゴールのプロジェクトマネジメントを可能にするように組織を変えていく必要がある。

中嶋秀隆さんが、制約を６つにするとマネジメントが複雑になり、実務には向かないので、従来通り３制約でマネジメントをしていった方がよいと著書「ＰＭプロジェクト・マネジメント改訂４版」に書かれている。このこと自体は賛成なのだが、ただ、リスクを制約にするという考えはぜひ、取り入れてほしいとも思う。

◆ダムを造ることが目的なら、プロジェクトを中止する理由はない

ダム建設中止の是非が大きな問題になってきた。住民は、今の「中止ありき」で協議をしていくという方法に激しく反発している。

ダムのプロジェクトではダムを造ること自体を目的にしているわけではない。たとえば、熊本の川辺川の場合だと、ダムを造る目的には、治水、水源（かんがい）、発電の３つの目的があるとされる。時代が経てば、状況が変わり、目的が消失することがある。当たり前の話だ。３つある目的のうちの治水だけが残っている。

当然、投資対効果が変わってくるし、目的が変わるということはプロジェクトとしては仕切り直しをすることを意味する。しかし、仕切り直しをすることなく、４０年継続された

この問題の構図ははっきりしている。戦略的にプロジェクトを進めようとせず、「実行ありき」なのだ。目的というのはある意味でどうでもいいのだ。ある意味というのは、必要ないというとではない。「実行ありき」で、目的は実行するための「理由」に過ぎないということだ。従って目的が変われば、仕切り直しするという理由はない。

つまり結果としてか、確信犯かは別にして、ダムを建設すること自体が目的だったということになる。

よく走り出したプロジェクトは中止できないというが、目的が「ダムを造ること」だとすれば、中止する理由などないわけである。この点をよく押さえておいてほしい。

◆ビジネスプロジェクト

実はビジネスプロジェクトでもこのパターンは非常に多い。目的に

・商品を開発すること
・システムを開発すること
・売り上げを上げること

といったものを上げているビジネスのプロジェクトは、ほぼ、ダムと同じパターンだ。三番目は微妙だが、とりあえず、止めなければ目的が達成できるということを考えると同じパターンだといえよう。

このパターンに陥ると、そのプロジェクトを中止することはできない。特に、ＳＩや建設のように社外の顧客がプロジェクトオーナーのプロジェクトは、中止できない。

逆にいえば、中止するには、正しい目的を掲げ、目的のレベルで合意するようにすることだ。顧客のつくプロジェクトであれば、契約書の中でそれを謳い、中止後の処理についても明確にして、合意しておくことが必要である。

◆根本的な問題

もっと根本的な問題としては、そもそも、仕事の目的とはどのようにして達成されるかという話だ。

仕事と目的には、

　仕事
　　→（生み出す）
　　　サービス／プロダクト／・・・
　　　→（実現する）
　　　　　目的

のような構造がある。ダムでいえば、

　ダム建設
　　→（生み出す）
　　　ダム
　　　→（実現する）
　　　　　治水、水源（かんがい）、発電

という構造があるわけだ。この構図をみれば分かるように、目的が変わるということは、プロダクトも変わるし、仕事も変わる。当たり前の話である。

プロジェクトマネジメントというのは目的を達成するために、プロダクト（スコープ）や仕事を調整していくマネジメントである。

そんなことは分かっているという人は多い。しかし、実際にプロジェクトマネジメントとしてできている人は少ない。理由は様々であるが、共通の理由は分かっていないことではないかと感じることが多い。ダム工事の役人のように確信犯でやっている人は少ないように思う。

◆もっと根本的な問題

ではなぜ、確信犯でするか？

これは簡単である。やってきたことを失敗だと認めないためだ。

公共工事であれ、ビジネスであれ、中止と大赤字を比べると、大赤字の方が失敗としては小さいという考える。戦略性のなさのなせる業である。

であれば、簡単だ。失敗に対する対処、つまり、中止という判断のためのオペレーションを標準化すればよい。