◆取り残されるという「勝手な思い込み」

我々のもう一つの失敗はグローバルスタンダードに従わないと世界から取り残されるのではないかという、勝手な思い込みしてしまったことである。これは大変な勘違いであった。文化ほど独自なものはない。文化は弱さの原因でもあるが、他の人のまねできない強さ、つまり、独自能力の原因でもある。

このフレーズは、加護野忠男先生の「経営の精神」に出てくるフレーズである。この議論で最も念頭に置かれているのは、ＳＯＸ法による内部統制である。ＳＯＸに限らず、一般的な議論だと思うが、この議論は難しい議論である。何が難しいかというと、競争のルールをどう考えるかだ。

ビジネスに限らず、スポーツ、外交など、さまざまな分野で日本のルールに対する駆け引きは下手だという指摘がある。それがもっとも顕著に表れているのがスポーツだろう。柔道のようにお家芸と言われた種目で、度重なるルール変更によってメダルが取れたら喜ぶレベルになってしまった競技もある。ジャンプや、スキー複合のように、せっかく、切磋琢磨して強くなってきたら、いきなり、ルール変更でまったく勝てなくなった競技もある。ビジネスでもこういう例はたくさんある。興味があれば、青木高夫さんのこの本を読んでみて欲しい。怒りがふつふつとわいてくるだろう（笑）。

青木高夫「ずるい!? なぜ欧米人は平気でルールを変えるのか」、ディスカヴァー・トゥエンティワン（2009）

まあ、加護野先生の言葉でいえば、そのような環境変化に愚直に対応してきたのが、今の日本を作っているということなのだろうが、、、

◆欧米と日本ではルールの決め方が違う

さて、ビジネスにおいてスタンダードの持つ意味は、商品、企業、国といったあらゆるレベルでの競争のルールに他ならない。つまり、ビジネスで競争をするにあたって、これだけは守りましょう。という暗黙の了解である。加護野先生の指摘は、それをグローバルスタンダードという名のもとに、欧米にコントロールされているという指摘である。青木さんも同じことを言われている。

なぜ、こういうことになるのか？日本におけるルールの決まり方を見ているとよく分かる。ルールを決める目的（戦略）がない。目先の問題を解消するためにルールを決めるというもっとも原始的なやり方でルールを決めていることがほとんどである。よく言えば誠実である。

スポーツや貿易を見ているとよく分かるが、ルールがそのように決められることは珍しくなっている。目的ありきだ。

目的　→　ルール　→　問題

というロジックになっている。競争なのであたり前だ。例えば、

ジャンプの日本の優位性をなくしたい（戦略）
→　スキー板の長さを短くしよう
→　スキー板が長いと、飛行の安全性に問題がある

というロジックになっているわけだ。問題があまりにもとってつけたものであれば支持されないルールになるが、残念ながら欧米のシナリオを書く能力は日本人の比ではない。

ところが、日本人がルールを決めるときには、

問題　→　ルール　→　成果

となる。上の場合と、この場合では、できるルールが全く違う。これがグローバルスタンダードというルールの作られ方である。

◆ルールにどのように向き合うか

ただし、ビジネスの競争をするのにルールを作って、そのルールを守りながら公正な競争をしようという発想自体は正当なものである。この否定は、資本主義の否定である。

すると、道は３つしかない。
（１）新しいルールで競争力を高めていく
（２）ルールを作る場で勝つ
（３）ルールができることに抵抗する
かのいずれかである。加護野先生の指摘は、今まで一番目の選択肢でやってきたことへの警鐘である。（２）は今後は分からないが、今のところ、アングロサクソンが世界を支配しているので、難しいと思われる。そうなると（３）しかない。（３）の先輩は中国人である。

◆プロジェクトマネジメントのグローバルスタンダードを巡る詭弁

前置きが長くなったが、プロジェクトマネジメントの話に移ろう。プロジェクトマネジメントの世界には、大きなルール（グローバルスタンダード）が２つある。ＰＭＢＯＫ（米国）とＰＲＩＮＣＥ２（英国）である。ずっと拮抗しながら発展していっているところに、プロジェクトマネジメントというツールの位置づけの重要性が伺われる。

このような情勢の中で、日本はＰＭＢＯＫに従おうとしている。ただ、ここで考えるべきなのは、そもそも、プロジェクトマネジメントのルールの目的は何かという点である。

例えば、ＰＭＢＯＫが注目去れ始めたときに、まとこしやかに

グローバルプロジェクトでは、いろいろな国の人が同じ方法で管理をしなくてはならない。だから、ＰＭＢＯＫがよい

と言われた。

これは明らかに詭弁である。どこをごまかしているかというと、透明性とオープンであることをごちゃ混ぜにしている。グローバルプロジェクトに必要なのは透明性であって、オープンであることではない。ＩＴを使った管理を前提にしているので、オープン性もある程度問題になることは理解できるが、本質的には管理はその国にあった方法で、

（１）アカウンタビリティの明確化
（２）インタフェースの統一

だけをしておけば、マネジメントの透明性が担保でき、協働できる。文化に根ざさないやり方など非生産的なこと、きわまりない。

プロジェクトマネジメント自体が目的であれば話は別だが、手段である。手段である限り、プロジェクトを成功させるという目的を達成できればよい。その場合、合理性が手段を選ぶ基準になる。ダイバーシティが求められるときに、ものごとを明確にするというのは、生産性が高いやり方とはいえない。日本流の必要な部分だけドキュメント化し、根回しで意思決定をしていくというやり方の方が遥かに合理的である。

◆一周遅れか、一周進んでいるのか

例えば、ドキュメント化の是非という議論があるが、信頼関係が構築されており、かつ、スピードの勝負をしているときにドキュメント化することはあまりメリットがあるとは思えない。

ドキュメントに記録的な意味合いがあるのであれば、各プロジェクトにエスノグラファーでもつけて記録すればよい。というのは冗談だが、例えば、７つの習慣で有名なスティーブン・コヴィーは、「スピード・オブ・トラスト」という本の中で、「信頼」がスピードを上げ、コストを下げ、組織の影響力を最大化すると指摘している。

スティーブン・コヴィー、レベッカ・メリル 「スピード・オブ・トラスト」、キングベアー出版（2008）

この考え方は、日本の企業は高度成長期の中で構築したものを、グローバルスタンダードに従うために、自ら捨ててきた考え方である。そして、仕事の仕方がだんだん、雑になって、品質が下がり、コストをかけて品質を維持するという愚か者のサイクルに入っている。
印象的には一周進んでいるのに、自分が信じられないで、一周遅れのランナーを一生懸命追いかけている気がする。企業が閉塞感に包み込まれた今こそ、一度、立ち止まって考えてみるチャンスである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上をまとめると、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

３つ目の見方は視座だ。

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

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

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

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

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

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

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