◆プロジェクトマネジメントの導入をみていて感じること

日本企業や日本型組織が苦手だとされている考え方の一つに多様性がある。多様性のなさを示唆するエピソードはさまざまで言い尽くされている感がある。日本企業で働いている人であれば、一度や二度は遭遇したことがあるのではないだろうか。

マネジメントの世界でももちろんこの問題はある。典型的なものは、標準化という考えと結びつけ、何がなんでも同じようにマネジメントしようとすることだろう。最近でいえばプロジェクトマネジメントにその兆候が見られる。

プロジェクトマネジメントは日本ではITの分野で導入され効果があったため、プロジェクト（的）な活動であれば、すべて同じ手法で管理するという方向に向かった。そして、これが過剰なプロジェクトマネジメントを行う原因になっていることをよく見かける。

この問題は日本企業のPMBOK(R)の使い方を見ると顕著である。PMBOK(R)は（プロセス）標準ではなく、プロジェクトマネジメントを実践するために必要な要件を明確にし、その要件を満たすツールを探してきて実践するフレームワークである。にもかかわらず、大抵の企業はプロセス標準の発想で活用している。つまり、標準的なプロセスとして導入し、その通りにやることを求めている。これは、マネジメントの発想ではない。

標準化というのはプロセスに適用される考え方で、標準化することによって、プロセスを改善、洗練するといった管理が効果的になることに意味がある。ところが、プロジェクトはもっと複雑な（システマティックな）ものであり、標準化してもメリットが得られるとは限らない。そればかりでなく、標準として想定されているより単純なプロジェクトに適用しようとすれば、必要以上に複雑なマネジメントが必要になり、パフォーマンスを下げてしまう。これは上に述べた通りだ。

◆アジャイルで行われていること

最近の手法で、同様に標準化の問題を感じているのが、アジャイルだ。今回のＰＭスタイル考はアジャイルについて考えてみたい。

日本でアジャイルが注目されるようになったのは15年くらい前で、比較的新しい分野だ。それ以来、幾度となく、コンサルティングで接点があるが、ずっと気になっていることがある。それは、アジャイルが有効であれば、何とかして水平展開しようとすることだ。水平展開という言葉を使ったのはちょっとした想いがあるのだが、例えば、アジャイルによって一つの開発作業が効率的にできれば、その部門の開発はすべてアジャイルでやろうとするのだ。要するにプロセスの標準化の発想である。

これは、開発（というかテクノロジー）の分野で活用しているのでそういう発想になっていると思われるが、このような発想は本当に正しいのかという疑問を持っている。不確実性の低い開発にアジャイルを使おうとするのは本当に正しいのかという疑問だ。

この疑問、経営的にみれば答えははっきりしている。正しくない。正しいのは、アジャイルに取り組むものと、ウォーターフォール（従来型）で取り組む開発のバランスの問題なのだ。つまり、多様性が重要なのだ。これが冒頭に述べた問題である。

日本では、アジャイルはまずITの開発分野で導入された。顧客やユーザを理解し、彼らを巻き込みながら製品を作り上げていくためには、アジャイルが最良の方法だと考えられたのだ。

◆新たな新製品開発競争とアジャイル

そこに、もう一つの流れもあった。日本には1980年代に生まれた日本の独特の方法である新しい製品開発ゲームのコンセプトがアジャイルの考え方とマッチしたことだ。このコンセプトとは、1986年に「ハーバード・ビジネス・レビュー」誌に掲載された、野中郁次郎と竹内弘高の論文で、タイトルは「新たな新製品開発競争（The New New Product Development Game）」であった。

この論文で野中と竹内は、ホンダ、富士ゼロックス、３Ｍ、ヒューレット・パッカードなど、生産性の高い革新的な企業を分析し、ＮＡＳＡに代表される段階的なプログラム開発、すなわちウォーターフォール方式には根本的に欠けているものがあると指摘したのだ。

そしてこの方法は、ジェフ・サザーランドとケン・シュエイバーが1990年代にIT産業の開発の現場で効果的にソフトウェア開発を進める手法として開発したスクラムの原点になったされている。

その後、スクラムがアジャイルの中で注目されたことも追い風になったこともあり、日本のやり方とアジャイルは相性が良かったと考えられる。

◆アジャイルのフレームワーク

その後、アジャイルは組織全体へスケールされるようになる。アジャイルのフレームワークは数十種類あると言われている。そして、米国ではすべてのチームが同じフレームワークを実践しているとは限らない。あるチームはスクラムを利用し、別のチームはカンバン、エクストリーム・プログラミング（XP）、また別のチームはクリスタル・システムズ・ディベロップメント・メソッド（DSDM）を利用するというような実践がされているケースもある。

もちろん、このような実践のためには、コストがかかる。日本では標準的なフレームワーク（スクラムが圧倒的に多い）を決めて、組織的に展開している理由はこのコストを避けている一面がある。

利用されている割合は、スクラムが圧倒的にトップで、２位のカンバンと比べて10倍近い顧客の活用されていると言われている。これはスクラムという手法の持つ特性によると思われる。スクラムは非常に柔軟性があるフレームワークで、カンバンやXPなどと簡単に結びつけることができる。このため、スクラムが選ばれる可能性が高く、それに伴い、トレーニングが充実し、ノウハウも蓄積されている。

◆「アジャイル・アット・スケール」

一方で、アジャイルの対象も製品開発からどんどん組織全体へ広がってきた。これは、End-to-Endという概念で表現されるように、「アイデアを考え顧客に価値を届けるまでの最初から最後まで」、アジャイルにしようとするものである。

このために2010年くらいからアジャイルのコンセプトのアップデートをするスケーリングが考えられるようになってきた。スケーリングはアジャイルを開発チームだけではなく、組織全体に適用することにより学習を多元的に行うものだ。

スケーリングのフレームワークとしてよく使われているのは、スケールド・アジャイル・フレームワーク（SAFe）、スクラム・オフ・スクラムズ、インターナリー・クリエイテッド・メソッド、ドント・ノウなどがある。この分野はさらに新しく、どんどん新規参入がある。例えば、最近注目されているフレームワークに、ほとんと未着手だったメディア・サービスの分野でスポティファイ社が作り上げたスポティファイ・モデルといったフレームワークがある。

スケーリングは小さくても良いので素早く顧客に価値を届け、そこから顧客のニーズを学習することを重視するという流れの考え方である。つまり、アジャイル開発の考え方や働き方を開発チームだけでなく組織全体にスケールさせるものだが、スケーリングして作られる組織はアジャイル組織と呼ばれる。組織のすべての領域で顧客に対し素早く価値を届け、学習を繰り返すようになる。

◆アジャイル組織の考え方

アジャイル組織は、スクアッド（分隊）というチームを基本単位として運営する。スクアッドの特徴として挙げられるのは以下の通りだ。

・9人以下のスタートアップのような雰囲気のチーム
・後述のトライブの優先順位を鑑みて、目的、権限、責務が設定される
・単独で顧客に価値を提供できる「End-to-Endの単位」で区切る
・プロダクトオーナーが設置され、仕事の優先順位付け、プロジェクトマネジメントを行う

そして、アジャイル組織に移行するために重要なのは

・変化に強い組織への移行の意思決定
・素早い学習サイクル
・End to Endの単位での組織設計
・パーパス（目的）ドリブン
・ピープルマネジメント

の５つだとされている。

◆アジャイル組織の経営的課題

ここまでは、製品を中心にしたアジャイルだが、経営という視点からみると問題が２つある。一つは、経営全般でみれば、アジャイル組織をつくり、開発プロジェクトをアジャイル化しても、経営的にみた場合に業務効率が画期的に改善されるものではないという問題だ。

例えば、ある製造業では、開発現場にアジャイルを取り入れたが、製品の展開までの時間はあまり変わっていないし、コストもあまり変化していないという現実に遭遇した。開発自体の時間は短縮されているのだが、戦略的な企画立案、意思決定の承認、予算の確保、人材配置のタイミングなどがそのままだからだ。

これは、考えてみればすぐにわかる。仮に企業における開発作業以外の作業の稼働率が20％だとすると、アジャイルで仮に30％の作業スピードが改善されても、業務スピードが6％しか改善されないのだ。

つまり、アジャイルの効果を経営的に生かす（イノベーションの創出速度を速める）ためには、大局的な取り組みが必要なのだ。

もう一つの大きな問題は、アジャイルの適用範囲だ。日本企業でもそうだが、アジャイルが適用されるプロジェクトは注目されるプロジェクトであり、そこに経営的な関心も集中する。このため、アジャイルにかかわるコストを賄うために業務や業務サポートに充てる人材を減らすことになる。そして、業務のスピードが減少する。これは、上で述べた稼働時間の減少を意味する。つまり、アジャイルにすることによって、却って開発プロジェクトの期間が伸び、イノベーションのスピードが減少するということになりかねない。

しかし、イノベーションを考えてみればすぐにわかるように、アジャイルを適用し開発した製品が収益源になるとは限らない。これはイノベーションにはついて回る問題だが、だからといって保守的になりすぎれば、イノベーションが生まれなくなる。

◆アジャイル経営企業への道

このように、経営的に考えれば、アジャイルをどの範囲に適用し、イノベーションを生み出しながら、収益の確保をするかは非常に難しい課題である。この課題を乗り越えた企業はアジャイル経営企業と呼ばれている。

つまり、アジャイル経営企業は、単に開発作業のスピードを上げることではなく、この経営的な課題を乗り越えて、

・従来型のやり方の業務を効率的に行う
・予期せぬビジネスチャンスに遭遇すればアジャイルの適用によって取り込んでいく
・従来型のやり方の業務とアジャイル業務のバランスをとる

を実現することに他ならない。

以上のように、アジャイルの導入・範囲の拡大は、

アジャイル開発→アジャイルチーム→アジャイル組織→アジャイル経営企業

と行われていく。このように考えてみると、アジャイルの拡大自体がアジャイルな取り組みだと考えることが望ましい。これによって、経営的なバランスが取れるようにアジャイルの範囲を試行錯誤していくことになるだろう。

◆おわりに

日本は慢性的なイノベーション不足だと言われて久しい。

アジャイル開発を導入したい理由は、顧客に声を聞き、そこから新しいデザインや技術などのイノベーションを起こしたいからである。だから、なんでもかんでもアジャイルというのはいいことだと考えるかもしれないが、イノベーションが起こらない理由は、そこではない。

アジャイルを導入すれば、なんでもかんでもアジャイルにしたがるところにある。これが現場主義の弊害だと思われるが、経営的にみれば、それではやっていけないことは今回のＰＭスタイル考でお分かりいただけたかと思う。

この問題の本質は多様性が受け入れられないことであるが、こういう発想でやっている限り、イノベーションが生まれにくいという状況は変わらないだろう。アジャイルを経営的に生かすには、ここを変えていく必要がある。つまり、アジャイルを組織にスケールしていく中で、従来型の業務とアジャイル業務のバランスを取る必要がある。

このバランスをとるためには、コンセプチュアルスキルが必要になることはいうまでもないだろう。

◆はじめに

前回、プロジェクトに「心理的安全性は必要か」という議論をした。

【ＰＭスタイル考】第１７３話　プロジェクトには心理的安全性が必要か
https://mat.lekumo.biz/pmstyle/2021/02/post-8fd0.html

今回は前回の続きで、心理的安全性を危うくするのは何かという話だ。

◆魂なきマネジメントをおこなうための５つの簡単な方法

ヘンリー・ミンツバーグが自身のブログの中から42編選んで作った書籍
「これからのマネジャーが大切にすべきこと」（ダイヤモンド社、2021）
の中に、非常に興味深い部分がある。それは、第5話の「「魂なきマネジメント」の蔓延」というブログ記事の中にある、
「魂なきマネジメントをおこなうための５つの簡単な方法」
というリストで、この中の一つだけ実行すれば魂なきマネジメントがを実践できるというものだ。ちょっと長くなるが、転載しておく。以下の５つだ。

（１）ひたすら財務諸表を気にしてマネジメントを行う。製品やサービスや顧客を尊重するより、お金をマネジメントすることによって利益が得られると考える。
（２）あらゆるこを計画通りにおこなう。物事を自然な流れに任せたり、その過程で学習したりすることは一切拒否する。
（３）マネジャーを頻繁に人事異動させ、流行のマネジメント手法以外は何も詳しくない自分物をつくり上げる。
（４）原材料や設備などの「資源」を売買する感覚で、「人的資源」を雇ったり首にしたりする。
（５）あらゆることを「５つの簡単な方法」の類に従って行動する。

◆簡単な調査

この記事はマネジメント全般に書かれたものだが、プロジェクトには魂が必要なのだろうかと思って、プロジェクトマネジャー（スポンサー）としてはリタイヤしている人数名に意見を聞いてみた。細かい話はあとで紹介するが訊ねた人全員が昔のプロジェクトのマネジメントには「魂が必要だったし、あった」と言っていた。

同時に、現役の若手のプロジェクトマネジャー数名にも意見を求めた。結果は割れて、３名は必要ない（ただし、うち２名はなかなかできないとのコメントあり）、１名が必要だというものだった。

これらの調査で出てきた必要だと思う理由は

・コストを抑えても、顧客が満足しなければ意味がない
・現場を管理するのはプロジェクトマネジャーだから数字だけではない
・計画はあくまでも目安だ。生産性のようにあまり根拠のない目標が入っている
・人的資源はパフォーマンスが変動するので、メンバーと同じように扱う

といった意見だった。逆に、必要ないと思うという理由は

・コストを守らなくてはプロジェクトとしては失敗だ
・いくら良い成果物を作っても、予算オーバーしたのでは意味がない
・計画通りに進まないとプロジェクトは破綻する
・学習はKPTに分けて、実践できるものだけ実践する
・人的資源は調達できなくてはプロジェクトは計画通りに進まない
・コストを調整するために、人的資源は有力な武器になる
・プロジェクトは短期勝負なので、魂などと言っている余裕はない

といったものだった。双方の意見ともよく分かるが、改めてPMBOK(R)の影響力は凄いなと思った。

◆魂のある組織とは

お気づきの方もいらっしゃるだろうが、実はこれまでに「魂のある」組織やマネジメントとは何かは定義していない。

実は、ミンツバーグのブログ記事でも明確な定義は書かれていない。ただ、長年に渡り組織論を研究してきたミンツバーグは組織に魂があるかないかを瞬時に感じ取れるときがあるという。

また、同じ記事の中で、魂のあるホテルのエピソードも出てくる。娘さんと一緒に宿泊したホテルで、レストランのウェーターにバイキングコースについて尋ねたり、受付の女性と話をしたり、ベットにおいてあるクッションをみたり、支配人や副支配人の勤続年数を尋ねたりしていると魂のあるホテルであることが分かった。

娘さんに「魂のあるってどういうこと」と聞かれて、「見ればすぐに分かるよ。それは職場の隅々に現れるんだ」と答えている。そして、魂のないマネジメントは、一度、構築した素晴らしい組織を崩壊させると指摘している。

◆魂のある組織は魂のないマネジメントで崩壊する

このブログ記事の冒頭で、ある産科医から聞いた話だということで、以下のようなエピソードを紹介している。

研修時代のいくつもの病院を行き来する日々を振り返ってみると、働くのが楽しいと感じる病棟があったそうだ。とても「幸せな職場」で、看護師長の気遣いの賜物だったという。彼女は思いやりがあり、すべての人を尊重し、医師と看護師のチームワークづくりに気を配っていた。

やがて、その看護師長が退職し、MBAを持つ看護師が後任に就いた。新しい看護師長は人の話を聞くこともなく、いろいろと問題点を指摘し始めた。看護師たちには厳しい態度で接し、厳しい言葉を投げかけた。以前は勤務開始前には笑いがあったが、今は誰かが鳴いていることも珍しくなくなった。看護師の士気は下がり、すぐに医者にも伝染し、わずか2～3ヵ月で素晴らしい職場が崩壊した。昔はわれ先に出勤していたが、もうその病棟に行くのは楽しくなくなっていた。

最初の看護師長のいたときの病棟は魂のある組織で、MBAの看護師長が就任した後の病棟は魂のない組織だということになる。魂のある組織は、魂のないマネジメントであっというまに崩壊したのだ。

◆プロジェクトの規模は魂づくりに影響があるか

この話を読んで、どう感じるだろうか。

まず、事実として捉えておきたいことは、一つの病棟の雰囲気が崩壊するのはあっという間だということだ。著者もこういう状況のプロジェクトに何回遭遇したことがあるが、実際のところ速い。おそらく、MBAの看護師長のようなプロジェクトマネジャーであれば、プロジェクトでチームビルディングする以前に崩壊するだろう。また、チームビルディングができて、順調に進んでいても、ちょっとした行違いからこういう状況になるのも数回見ている。これもあっという間だ。

このように考えると、プロジェクトマネジメントに魂が必要かどうかを議論するに当たって、プロジェクト期間が短いというはあまり関係がなさそうだ。

では、プロジェクトのメンバー数と魂はどういう関係があるのだろうか。病棟の例はせいぜい、数十名くらいの組織だろうから魂のある組織でつくうことは可能だ。メンバーの数が多くなれば、そもそも、魂のある組織をつくることは難しいのではないだろうと思った人もいるだろう。

確かにそういう一面はあるように思える。人数が多くなれば、魂のある組織をつくるのは難しくなる。プロジェクトも例外ではない。数名から数十名程度のプロジェクトでは、魂のあるプロジェクトを魂のあるマネジメントで動かしているケースも見かける。一方で、数百人といったプロジェクトが魂のあるプロジェクトだと思ったことはほぼない。

著者が大きなプロジェクトで魂があると感じたプロジェクトはリーダーが素晴らしかった。プロジェクトの中のサブチームのリーダーシップが素晴らしく、プロジェクトマネジメントもチーム単位でみれば、マイルストーンを守る以外は計画にはあまり拘っていない。これは、プロジェクトは一つであり、ばらばらに仕事をしていてもマイルストーンで全体が統合されることをよく理解しているからである。これは、リーダーがメンバーにそのことを繰り返し伝え、メンバーはオーナーシップを持っているからだろう。

重要なことは、このようなプロジェクトは各サブチームは自分たちのやり方で作業を進めていても、全体に一体感があることだ。これは魂のあるプロジェクトということだろう。

そして、その魂のあるプロジェクトをつくっているのはトップに立つプロジェクトマネジャーのリーダーシップだろう。例えば、プロジェクトの中でチームを超えて作業を協業したり、あるいはプロジェクト内の別のチームに人を動かすことがあるが、そのフォローをプロジェクトマネジャーがきちんとしている。これは、魂のあるプロジェクトにするためのマネジメントだと言える。

◆コミュニケーションと魂

プロジェクトマネジメントには、コミュニケーションマネジメントというマネジメントがある。コムにケーション計画が相当緻密でなくてはプロジェクトを計画通りに進めていくことは難しい。

ところが、逆に魂のあるプロジェクトにしていくためには、計画的なコミュニケーションは阻害要因になっていることが少なくない。これは計画について回る義務感のようなものがもたらす影響かもしれないが、魂をつくるコミュニケーションが不足するからだだと思われる。

例えばアジャイルプロジェクトのように、自然の流れに任せてコミュニケーションを取っていると、結果として魂のある組織といえるプロジェクトになっていく。その意味で、狭い意味でのコミュニケーションマネジメントは魂を排除するマネジメントなのかもしれない。

ここでコミュニケーションの密度は、コストや進捗に大きな影響を与えることに注意しておく必要がある。著者の知り合いにコミュニケーションマネジメントは一切せずに、プロジェクトは計画通りに成果物を作り出すのが理想だと考えるプロジェクトマネジャーがいた。結局、コミュニケーションマネジメントをするという結末になるプロジェクトが多かったという。現実には、予算にしろ、スケジュールにしろ、計画的なコミュニケーションで計画的に積み上げていくことが必要なタイプのプロジェクトが多いのだ。

一方で、VUCA時代のプロジェクトや、事業変革や組織変革などの複雑で先の見えないプロジェクトでは、積み上げよりは試行錯誤が重要である。このようなプロジェクトにおいてはコミュニケーションマネジメントはコミュニケーションの阻害要因、ひいてはプロジェクトの阻害要因になりかねない。

◆心理的安全性で魂のあるプロジェクトをつくる

このように考えてみると、試行錯誤が必要なプロジェクトにおいては、魂のある組織やマネジメントが必要だと考えられる。問題はそのためにはどうするかということだ。仮に、魂のある組織は、魂のあるマネジメントの結果だと考えると、どういうプロジェクトマネジメントが必要なのかという議論になる。

この議論には答えはないかもしれない。例えば、

・プロジェクトチーム編成の工夫
・チームマネジメントの工夫
・プロジェクトプロセスオンアジャイル化
・プロジェクトチームのアジャイル組織（自律分散組織）化

など、有力だと思われるアプローチはいくつかあるが、いずれにしても、必ずそれでうまくいくというものではない。ただし、これらも含めて試行錯誤が必要なプロジェクトに共通したマネジメントのポイントがある。それは、心理的安全性を高めることである。

心理的安全性が高くないと、魂のある組織やプロジェクトにはならないし、魂のあるプロジェクトマネジメントではプロジェクトは動かないだろう。特に、（１）や（２）の実行によって魂のないマネジメントになってしまうだろう。

結局のところ、魂のある組織とはリーダーがさまざまな気配りをし、そこに集う人が幸せだと感じる組織をつくることだろう。そして、その気配りがマネジャーのすべき魂のあるマネジメントだ。

プロジェクトでいえば、プロジェクトマネジャーがあらゆる気配りをし、プロジェクトを参加者が幸せだと感じる場にする。実はこれはステークホルダーマネジメントの問題なのだ。

ステークホルダーマネジメントというと、プロジェクトに協力してくれない人を巻き込み、プロジェクトの協力してくれる人を推進力にしていくマネジメントである。そのマネジメントの方向性はプロジェクトの成果物に焦点を当てて進めていく。

志向錯誤が必要なプロジェクトではその方向を捨て、すべてのステークホルダーに心理的な安全性を与える場を作ることにステークホルダーマネジメントの焦点を絞るといいだろう。そのような場を作ることによって、プロジェクトの成果が生まれる可能性が高くなる。そのような前提のマネジメントが必要だ。

◆心理的安全性とは

先日、メルマガ「コンセプチュアル・マネジメント」に「心理的安全性」の議論を書いたところ、プロジェクトに心理的安全性は必要ないのではという意見を頂いた。今回は、ＰＭスタイル考でこの問題を考えてみたい。

心理的安全性とは、一言でいえば

「みんなが気兼ねなく意見を述べることができ、自分らしくいられる文化」

のことで、なかなか深い話だ。

ちなみに、「コンセプチュアル・マネジメント」に書いたのは、この記事だ。心理的安全性という考え方がぼんやりしている方は、まず、こちらの記事をお読み頂ければと思う。

【コンセプチュアル講座コラム】心理的安全性を高める
https://mat.lekumo.biz/ppf/2021/02/post-1ead.html

◆プロジェクトの心理的安全性の議論の際に念頭においておきたいこと

プロジェクトにおける心理的安全性の議論をする際に念頭においておきたいことが２つある。一つは心理的安全性が存在するレベル（範囲）だ。

心理的安全性というと、組織全体の話のように感じるかもしれない。もちろん、組織のレベルでも心理的安全性という議論はあるし、組織論の中で古くから議論されてきた心理的安全性は、組織全体の話だった。

しかし、近年の研究で心理的安全性は組織レベルだけの話ではなく、グループレベルでも存在することが明らかにされた。詳細な内容は、上の記事でハーバードビジネススクールのエイミー・エドモンドソン教授の研究の結果を紹介しているので、読んでみて頂きたい。また、時間に余裕がある人は、この記事の末尾に参考図書リストを掲載している。この中で数々のグループレベルの心理的安全性について事例を示している「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」をお読み頂くとよりイメージが明確になると思う。

そして、グループレベルで心理的安全性は存在するということは、プロジェクトレベルでも存在するということに他ならないということに留意しておいて欲しい。

もう一点は、プロジェクトの心理的安全性が必要かどうかという議論のポイントでもあるが、目標設定と心理的安全性にはどういう関係があるかという点だ。

心理的安全性を表面的に捉えると「気楽に仕事できること」だと考えらえるので、心理的安全性を高めるということは目標設定の基準を下げるものだと考える人もいるだろう。実際に、企業のプロジェクトスポンサーたちと心理的安全性の話をしていると、そういう感覚の人が多いのも事実だ。

しかし、これについてもいくつかの研究で、少なくともグループレベルでは目標達成の基準を下げるものではないということが分かってきた。さらにいえば、心理的安全性は、挑戦的な目標を設定し、その目標に向かって協働するのに有効なものだと主張する人もいる。この点から考えると、心理的安全性はプロジェクトマネジメントとしての有用なものだと考えられる。

◆２つのモチベーションの与え方について

これらの研究結果を紹介して、プロジェクトで心理的安全性が必要かどうかという議論をすると、必ず出てくる意見が、

「プロジェクトは挑戦的なものばかりではなく、堅実性の求められるものも多い」

というものだ。

PMBOK(R)のプロジェクトの定義は、新規性と有期性のある仕事なので、堅実性の求められるプロジェクトというのはふさわしくないような気もするが、現実に企業でプロジェクトとして行われている仕事の中に堅実性が求められるものが多いのも事実だ。そこでここではこの言い分は受け入れ、プロジェクトには堅実さを求められるものもあれば、挑戦を求められるものもあるという前提で議論を進めていくことにしよう。

プロジェクトに心理的安全性が有用かどうかを考えるヒントは、モチベーションの与え方にある。心理的な側面に注目して考えると、モチベーションの与え方には２種類ある。

一つは「頑張らないと失敗するかもしれない」、「失敗しなら大変なことになる」といった「不安」を与えることによってモチベーションを高める方法。もう一つは「失敗しても大丈夫だ」といった「安心感」を与える方法だ。

一般的にいえば、組み立てラインの仕事のように反復作業を個人レベルで正確に行うことが評価される仕事では、不安を与えることはモチベーションをあげるために効果的だと考えられている。実際に、この方法は戦後の日本企業では多くのの企業で取られていた方法で、今でも顕在である。

これに対して、新製品開発のようなイノベーティブな仕事では、不安はモチベーションの要因にならない。これらの仕事は、学習したり、相互に協力しない限り、成功しないからだ。

◆プロジェクトのモチベーションの与え方

ではプロジェクトはどちらの性格の仕事なのだろうか。

上での述べたようにプロジェクトには何らかの新規性がある。プロジェクトの新規性には、新しい機能の製品を作るとか、新しい技術を使うとかいったものばかりではなく、これまでより少ないコストで開発するとか、これまでより短い期間で開発するといったものが多いのが現実だ。

このためには作業のやり方を新しくするとか、プロセスを工夫するといった新規性が求められる。さらに、ここに市場や顧客をはじめとするステークホルダーの要求に応えるという要素が入ってくると、新規性がより大きなものになる。

この点においては、プロジェクトは同じ環境で、同じものを、同じ方法で繰り返し作ればよいという仕事ではない。新しい機能の製品を作ったり、新しい技術を使ったりする以外でも、新しいやり方が必ず含まれる。

そのように考えると、プロジェクトという仕事では、不安を与えるやり方ではメンバーのモチベーションを高められないをできないことは明らかだ。現実に、不安を与えることによって、メンバーがすっかりやる気を失っているプロジェクトはよく見かける。

◆できることしかやらないプロジェクト

もう一つ、よくある意見に

「プロジェクトマネジメントとして、メンバーに不安を与えることによって奮起を促すようにしている。プロジェクトマネジメントの導入により計画を明確にすること、リスクを正しく認識することにより、大きく成功率が上がってきた」

というものがある。もっともな話なのだが、少し、ひっかる点がある。

ここで注目したいのは、リスクマネジメントを行う理由だ。プロジェクトマネジメントを導入する以前からリスク管理をしていた企業が少なくない。ただし、リスク管理の目的は、リスクのない計画を作るためだった。

ここに、WBSを基本とする精密な計画を作るプロジェクトマネジメントを導入した。その結果、よりリスクを考えた作業の計画を作り、進捗を細かく管理するようになり、作業の正確性が上がり、成功率が向上した。

が、そのまま残ったものがある。それはリスク管理の問題だ。つまり、プロジェクトマネジメント以前のリスク管理はリスクのない計画を作るために行っていた。プロジェクトマネジメントを導入したのは、プロジェクトコストを下げ、納期を短縮するためである。リスクマネジメントは、目標を厳しくした結果出てくるリスクをマネジメントするためである。

にもかかわらず、ここで決定的な勘違いをしていうプロジェクトや組織が多い。それは、リスクマネジメントはリスクを回避するためのものであるという勘違いだ。この勘違いをすると、できる計画しか作らなくなる。

もう少し正確にいえば、ここにいくばくかのマネジメントをしないリスクを乗せて、プロジェクトの計画を作る。そして、そのリスクは、マネジメントするのではなく、不安を与えることによって、クリアしようとする。

しかし、このやり方は逆機能を起こしている。不安を与えらられるので、不安を回避するような計画になってきた。例えば、競合に負けないように１年以内で開発して欲しいという経営方針があっても、（従来通りのやり方で）どう積み上げても1年以内には収まらないという計画が出てくるようになった。その前提で議論をし、1年で収まる成果物を作るようなプロジェクトが主流になってきた。

このように、不安を与えられることによって、1年以内で収めるような新しいやり方で行うというリスクも、1年以上かかっても競合とは比べ物にならないような製品を作ることもだんだんできなくなってきたのだ。

そして、不安に基づくリスクマネジメントの結果が新しいものへの挑戦しないという文化になってきた。この文化により流石に大きな軸になる製品がなくなり、問題になっていた。そして、この5年くらい払拭されているように感じる人もいるかもしれないが、ニッチを指向しているのが気にかかる。この話は別途したい。

◆プロジェクトマネジャーに求められる心理的安全性の実現

以上の２つの現実があり、不安を与えてもモチベーションは高まらず、リスクも取れない現実に直面している

何らかの新規性のあるプロジェクトにおいてはメンバー個々の仕事の正確性はどうでもよい。重要なことは、いろいろと試行錯誤してみて、学習し、最終的に、製品ではなく商品を創り上げることが重要だ。

プロジェクトのマネジャーに求められるのは、プロジェクトを心理的安全な場にすることであり、それがリーダーの最大の役割だ。心理的安全性があってはじめて、本当の試行錯誤ができ、より質の高い成果が生み出すことができる。

◆VUCAなプロジェクトでは不可欠になる心理的安全性

さらに、最近の傾向として、プロジェクトがVUCAになっているという問題がある。VUCAなプロジェクトでは、求める成果は決められているが、その成果を実現する成果物は不確実なもので、変動していく。

にも関らず、組織はプロジェクトに不安を与えることによって奮起を促し、また、プロジェクトマネジャーもそれを受けてメンバーに不安を与えることによって動機付けしようとするというやり方が続いている。

VUCAなプロジェクトにおいては、これは完全に逆効果だ。モチベーションの向上につながらないどころか、若年層のメンバーが多いプロジェクトではモチベーションがそがれてしまうという事態が起こっている。

いずれにしても、VUCA時代のプロジェクトを、どのような切り口の不安であれ、不安を与えてメンバーのモチベーションを高め、パフォーマンスを向上させることは不可能だ。であれば、動機付けとしてできることは限られている。心理的な安全性を高め、方向性が変わっても安心して方向転換できるような環境をつくることだ。

VUCAなプロジェクトにおいては、プロジェクトマネジャーがメンバーの行動を指示することは不可能だ。つまり、場面場面でどのような行動をとっていくかは、計画ではなく、最前線オンメンバーの判断に任せざるを得ない。すると、メンバーの意思決定において、心理的に不安定な状況にある場合と、心理的に安定な状況にある場合では、決定の質が変わってくることは容易に想像できるだろう。

◆まとめ

以上のように考えてみると、プロジェクトにおいては、成果物の革新性に関らず、心理的安全性を実現していくことが有効なプロジェクトマネジメントの役割だといえる。特に、VUCAなプロジェクトにおいては、もっとも重要なプロジェクトマネジャーの役割であると考えらえる。

◆心理的安全性のセミナー

VUCAマネジメント塾 オンラインセミナー「VUCAを乗り越える心理的安全性の高いチームを創る」を開催します。

━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆VUCAを乗り越える心理的安全性の高いチームを創る◆
　日時・場所：【ZOOM】2021年 07月 20日（火）19:30-21;30（19:20入室可）
　　　※ZOOMによるオンライン開催です。
　　　※少人数、双方向にて、演習、グループディスカッションを行います
　講師：好川哲人（有限会社エムアンドティ、MBA）
　詳細・お申込　https://vuca-safety-management.peatix.com/
　主催　VUCAマネジメント塾
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【カリキュラム】　　　　　　　　　　　　　　　　　　　　　
１．VUCAへの向き合い方
２．VUCAを乗り越えるチームのスタイル
３．心理的安全性がVUCAを乗り越える鍵になる
４．心理的安全性を高めるためにリーダーがすべきこと
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆心理的安全性について書かれた本

ピョートル・フェリクス・グジバチ「世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法」、朝日新聞出版（2018）
https://www.amazon.co.jp/exec/obidos/ASIN/4023317284/opc-22/ref=nosim

レイ・ダリオ（斎藤 聖美訳）「PRINCIPLES(プリンシプルズ) 人生と仕事の原則」、日本経済新聞出版（2019）
https://www.amazon.co.jp/exec/obidos/ASIN/4532357977/opc-22/ref=nosim

岸野道子「心理的安全なチームって、どうやってつくるの？」（2019）
https://www.amazon.co.jp/exec/obidos/ASIN/B08372ZGKD/opc-22/ref=nosim

石井 遼介「心理的安全性のつくりかた」、日本能率協会マネジメントセンター（2020）
https://www.amazon.co.jp/exec/obidos/ASIN/4820728245/opc-22/ref=nosim

エイミー・C・エドモンドソン（村瀬俊朗解説、野津智子訳）「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」、英治出版（2021）
https://www.amazon.co.jp/exec/obidos/ASIN/4862762883/opc-22/ref=nosim

◆高まるプロジェクト憲章の重要性

プロジェクトマネジメントのコンサルティングの中で、15年くらい前からプロジェクト憲章の重要性を言い続けてきたが、VUCAの時代を迎えて、いよいよプロジェクト憲章の重要性が高まっている。VUCAなプロジェクトでは、ある意味で計画書よりもプロジェクト憲章の方が重要である。今回はこの問題について議論したい。

プロジェクト憲章を作る際によく誤解されていることがある。それは、プロジェクトマネジメントは「期待された成果物」にどのように到達するかを考えるものだという誤解である。まず、この認識を、プロジェクトマネジメントは「期待された成果」をどのように実現するかを考えるものだと変える必要がある。

このためには、まず、期待された成果から、その成果を上げるために適した目的を設定し、その目的を実現するためにクリアすべき目標を設定し、目標を達成するための計画を作って進めていく必要がある。

つまり、この一連の流れをプロジェクトデザインと呼ぶが、プロジェクト憲章をつくるというマネジメントはプロジェクトデザインそのものである。

◆プロジェクト目的は与えられるという誤解

プロジェクトデザインの中でも気になるのは、プロジェクトの目的の設定である。これがプロジェクトデザインのスタート地点で、すべてのプロジェクトの活動は目的を実現するためにあるからだ。

著者は長年プロジェクトマネジャーやプロジェクトスポンサーのメンタリングサービスを提供しているが、プロジェクト憲章を作る際に、「プロジェクト目的は与えられるものではない、自分で考えるものだ」と指摘すると、今度は「上司や上位組織はどう考えているのだろう」と目的を探し始めることが多い。

つまり、プロジェクトの目的は誰かが考え、どこかにあるものだと思っている。あるいは、組織では暗黙の了解で決まっていると考えているのだ。

このように考えると、出てくる答えは、納期通りにプロジェクトを終了させる、収益を上げる、顧客を満足させるといったことだ。少し勉強している人は、プロジェクトで得られた技術を組織に残していくとか、プロジェクトマネジメントで得られた経験を組織で共有するといったことが目的だと考える。

プロジェクトをデザインするというのはそういうことではない。プロジェクトをデザインするというというのはプロジェクトの目的を自分で決めることで、決めたプロジェクトの目的を実現するために、必要な目標設定を行うことだ。そして、その目標を達成するための計画を作る。これがプロジェクト計画である。

◆プロジェクト憲章の役割

PMBOK(R)の普及で非常に分かりにくくなっているが、PMBOK(R)以前のプロジェクトマネジメントの教科書には、プロジェクト憲章は（最低限）、

・プロジェクト目的（成果）
・プロジェクトマネジャー

が書かれているドキュメントであると書いてあるものが多い。もちろん、最低限なので、PMBOK(R)のようにプロジェクト計画の前提を細かく決めることが悪いということではない。いずれにしても上位組織が行うプロジェクトデザインの結果を書いたものである。

重要なことは、これはどれだけ権限移譲をするかを意味していることだ。

プロジェクト目的だけ決めて、あとはプロジェクトマネジャーに全て任せるというのがもっとも権限委譲したスタイルである。しかし、ビジネスプロジェクトは、経営計画に基づく予算があり、その予算を超えることは好ましくないので、すべてをプロジェクトマネジャーに任せるとことは難しい。そこで、もう少し権限委譲の範囲を小さくするために、

・総予算
・納期
・プロジェクト成果物の概要（顧客要求）

といった主要な目標を決め、場合によっては、そのような目標に対するリスクの洗い出しも行うことがある。これらを整理するのがプロジェクト憲章であり、その作成はプロジェクトスポンサーの役割である。

言い換えるプロジェクトスポンサーの役割は、プロジェクトのデザインのうち、このような事項について決める役割がある。

プロジェクト憲章で指名されたプロジェクトマネジャーは、プロジェクト憲章の決定を前提にして、実現するために、マイルストーンなどの目標を決定し、その目標を達成するためのプロジェクト計画を作る。ここまでが、プロジェクトデザインである。

重要なことは、プロジェクトデザインはプロジェクトスポンサー（組織）とプロジェクトマネジャーが協力して行うことである。

◆VUCAなプロジェクトでは成果物を決めることができない

ところがVUCAなプロジェクトではこの構図が崩れる。詳しい話は、

【ＰＭスタイル考】第１５８話：プロジェクトの成果と成果物
https://mat.lekumo.biz/pmstyle/2019/10/post-f682.html

などを読んで頂きたいのだが、一言でいえば、プロジェクト環境の変化のため、組織から求められる成果を上げるための必要な成果物が変わっていく。このため、プロジェクトのデザインを変更せざるを得ない。ここで、問題になるのが、プロジェクト憲章の記載事項である。

プロジェクト憲章の段階で、成果物の概要（顧客要求）を決めることはできない。決めることができるのは、プロジェクトで得る成果だけであり、これをできるだけ実現できるようにプロジェクト目的を決定することになる。

さらにいえば、VUCAの度合いにもよるが、不確実性や曖昧性が大きく、大きな変動が予測される場合には、予算や納期を決めることも難しい。つまるところ、プロジェクト憲章の段階で決めることができるのは、（求める成果を実現できる）目的とプロジェクトマネジャーだけになる。

このようにVUCAなプロジェクトには、権限移譲が不可欠なのだ。

◆VUCA以前のプロジェクトスポンサー

このような枠組みで考えなくてはならないが、VUCA以前のプロジェクトではプロジェクトスポンサーが機能していないケースが多い。プロジェクトデザインにおいて、自身のすべきことをプロジェクトマネジャーに投げ出している。この背景にもプロジェクトの目的は決まっているという誤解があるのだ。

このようなプロジェクトスポンサーはプロジェクトの目的を上位組織が決めた予算や納期を守ることくらいしか考えない。このような考え方をするので、マネジメントではなく、管理が中心になる。そして、その管理はプロジェクトマネジャーに引き継がれ、プロジェクトマネジャーはひたすら、プロジェクトの作業管理をしているという光景をよく見かける。

VUCAでないプロジェクトであればこれで何とか回ったが、VUCAなプロジェクトはこのやり方では絶対に回らないし、それをよく分かっている人、実感している人が多い。このため、ひたすら不確実性や曖昧性を回避するために、創造的なことを受け入れない。つまり、使い慣れた技術、過去の経験のある仕様などに拘り、結果として、創造性のないプロジェクト成果物が生まれる。単に創造性がないだけならまだよいが、問題は変化した市場や顧客の期待に反していることが多いことだ。言い換えると、十分な成果が実現できない。

◆目的の扱い方

なぜ、このような状況に陥るのだろうか。問題はプロジェクトの目的の扱い方にある一言でいえば、プロジェクトでは何よりも目標や計画が大切で、目的は二の次であると考えているからだ。もう少し詳しくいえば、多くのプロジェクトでは

・目的は組織が決めている
・目的は見つけるものである
・目的は一つしかない
・目的は時間が経っても変わらない

といった認識がある。

このような認識をしていると目的は組織の暗黙の前提で考えられていることが多い。例えば、収益を挙げるという目的をすべてだと考えていたり、他社にできない製品を開発することだとか、社会や顧客に貢献するといった目的を暗黙の了解にしている企業もある。

そして、このような暗黙の目的を前提にして、目標設定を行い、計画を作っているのだ。その理由は、成果物を作り上げることが全てであり、期待している成果物が完成すれば、成果はほぼ実現できると考えているからだ。つまり、成果と成果物の間に目的は出て来ないのだ。

◆VUCAプロジェクトの目的

このような考え方はVUCAの時代には通用しない。

プロジェクト環境や市場の変化により、目標を変え、成果物を変えていく必要が生じる。言い換えると、そのプロジェクトで得たい成果を実現するためには、目標を変えざるを得ない。あるいは、目標を変えないと成果が小さくなる。VUCAの時代を迎えて、後者は多くのプロジェクトで問題になっている。当初決めていた目標で成果物を完成させたが、終わってみればあまり成果は実現できていないというケースだ。例えば、収益を上げることを目的にしていたのに、変更に次ぐ変更で、結局、あまり利益が出なかったプロジェクトは多いし、当初の仕様を大きく変更することを避けて売れない製品を作ったプロジェクトは少なくない。

このような問題を避けるにはもっと目的に拘る必要がある。

目標ありきではなく、ある成果を得るという目的があり、その目的を実現するために目標を調整していくことをマネジメントの中核に据える。VUCAでないプロジェクトでは、目標を設定し、目標を達成するために計画を変更していくのがマネジメントの中心にすることが多いが、ここがVUCAなプロジェクトと、VUCAでないプロジェクトの違いである。

実際にプロジェクト憲章を作ると、目標はしっかりと考えているが、目的はおざなりに書いているケースはよくある。酷い場合には、目標を達成することが目的だとしている。このようなプロジェクトでは、レビューの際になぜそのプロジェクトをやるのかを深掘りして質問すると、最終的な答えがでてこないケースが少なくないのだ。

◆成果物から成果へ

以上のように、VUCA以前のプロジェクトの目的は組織としての暗黙の前提に基づくものであり、憲章に書いて目標はそれを明文化しているだけだという認識でもよかった。そうすると、成果物ありきで考えることができる。

このようなやり方はVUCAの時代には通用しない。VUCA時代のプロジェクトで実現すべきことは、最初に決めた成果物ではない。もちろん、プロジェクトである限り成果物は必要であるが、必要な成果物はどんどん変わっていく。どう変わるかというと、目的を実現するために変わるのだ。

このためにプロジェクトマネジメントには、最初に決めた成果物を実現することではなく、目的を実現することが求められるのだが、今、プロジェクトをはじめるに当たって設定している目的にはこのような役割を果たせないものが多い。

◆目的は見つけるものではなく、自ら創るものである

では、どのように目的の設定を変えるかという話にあるが、そのときにもっとも考えるべきことが目的は見つけるものではないということだ。すでに述べたように多くの人は目的は与えられるものだと考えているが、目的は与えられるものでも、見つけるものでもない。自分たちで創るものだ。

さらにいえば、目的を創ることは難しいと思われがちだが、その原因は目的は一つしなかいと思っていたり、普遍性のあるものだと思っていることだろう。つまり、目的は複数あってもよいし、プロジェクトの実施している中で時間が経てば変えても構わない。

このようにプロジェクトの目的は見つけるものではなく、プロジェクトの（主要）メンバーで自分たちで決めるものなのだ。そして、VUCAなプロジェクトにおいては、そこにプロジェクトマネジメントのもっとも重要な意味がある。

プロジェクトでステークホルダーが期待した成果を得るためには、目的に対する認識の転換と、目的を中心を中心にしたマネジメントが不可欠である。そのようなマネジメントの実現のためには、計画よりは、プロジェクトデザインに重心を置く必要がある。

◆関連セミナー

パーパス・ドリブンのコンセプチュアルプロジェクトマネジメントについて学ぶセミナーです。

━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆「パーパス」でプロジェクトを動かす
　　　　　　　　　～VUCA時代のプロジェクトデザインの実践的方法◆
日時：2021年 07月07日（水） 13:30-17:00
　　　　　　～　07月 08日（木） 13:30-17:00
　　　　※少人数、双方向にて、演習、ディスカッションを行います
形態：ZOOMによるオンライン開催
講師：好川哲人（エム・アンド・ティ　コンサルティング代表）
詳細・お申込　https://pmstyle.biz/smn/conceptual_pm.htm
主催　プロジェクトマネジメントオフィス
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【カリキュラム】
＜第１日＞
１．パーパスとプロジェクトデザイン
２．パーパス実現のシナリオ創り
３．成果と成果物を明確にし、プロジェクト目的と目標を決める
＜第２日＞
４．シナリオからプロジェクトコンセプトを創る
５．成果を実現する本質要求を見極める
６．成果物を実現する本質目標を決定する
７．環境変動時のプロジェクトマネジメントの対応
８．VUCA時代に求められるプログラム＆プロジェクトマネジメント
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆プロジェクトは「目標」で動くのか

プロジェクトを動かしているのは、上位組織が戦略計画や事業改革からプロジェクトに落とし込む「目標」であると多くの人が信じている。

これに対して、「最も影響力のある経営思想家」トップ50人にも選ばれているマーカス・バッキンガム氏が興味深いことを言っている。それは、

「最高の企業は目標を落とし込まない。最高の企業は「意味」を落としこむ。」

だ。バッキンガム氏がこのように考える背景には、

「目標が役に立つかどうかの判断する唯一の基準は自分自身で自発的に設定したかどうかだ」

という考え方がある。これを基準に考えると、上位組織が落とし込んだプロジェクトの目標は役に立たないことになる。

今回のＰＭスタイル考はこの問題について考えてみたい。

◆現場主義とプロジェクト

プロジェクトマネジメントを学んだことのある人なら、

「プロジェクトとは、ビジョンにもとづいて戦略を作り、戦略から目標を作り、目標を達成するために計画を作り、実行する活動である」

と考え、その活動を推進していくのがプロジェクトマネジメントだと考える人が多いだろう。一言でいえば、戦略実行のためのトップダウンのオペレーションがプロジェクトであり、そのオペレーションを自律的に行うのがプロジェクトマネジメントである。

一方で、かつての日本の現場主義はこのような前提では考えられていなかった。戦略の必要性が言われるようになる以前はもちろんだが、90年代くらいから戦略マネジメントが注目されるようになってきて戦略を作らなくてはならないと考えるようになってきても90年代は現場視点からの戦略を作っていた。つまり、現場がすべきだと考えることが実行できるように戦略を作っていた。

一方で、経営者の中には、現場を中心に据えながらも大局観を持ち、企業として進み方を調整している人と、現場から突破していこうと考える人がいた。そして、21世紀になってまず前者が戦略マネジメントに舵を切った。そして、企業統治の強化という大きな流れの中で、多くの企業がトップダウンの戦略マネジメントに舵を切った。そして、その「オペレーションとして実施されるようになったのがプロジェクトである。

皮肉なことに戦略マネジメントが進むにつれて徐々に経済が衰退していったので、日本企業には戦略マネジメントは適合しない、現場軽視の結果だと批判する識者も少なくない。

いきなり余談になるが、菅義偉総理の政治の進め方を見ていると、現場主義の時代を思い出す。脱炭素社会の実現、携帯料金の値下げ、捺印の廃止、オンライン診療の推進など、いわば一点突破で進めようとしている。菅総理を批判をする人は国家としてビジョンを示さず、戦略もなく、デジタル化推進とか、公共サービスの見直しといった戦術レベルで課題を取り上げ、個別問題を解決しようとしているという。

◆正解のない時代を迎え衰退する戦略マネジメント

話を元に戻す。日本では現場主義から戦略マネジメントに変わってきた流れがあり、今でも戦略に時間をかけることが重要だと考えられているが、逆に世界では戦略マネジメントが衰退しつつある。今、世界を牛耳いるGAFAは戦略的な経営をしていない（また機会があれば書きたいと思っているが、戦略というのは本質的に投資家対策であり、企業にとって本質的に必要なものかどうかは怪しい）。

つまり、ビジョンやパーパスを明確にし、ビジョン実現の戦略は作らずに、どんどん事業を作っていく。そして、ビジョン実現に効果のある事業だけを残し、成長の起点にし、ビジョンを実現している。これをドラスティックに行っているのが、グーグルである。創業以来20年間で手掛けた新規事業は50以上にのぼり、その三分の一は5年程度で撤退しているという。これまでだと考えられないような事業スタイルだ。

その背景にあるのが、VUCAである。よく知られているようにVUCAは当初、軍事領域の話だったが、21世紀になってから一般的な社会生活や経済活動もVUCAになってきている。予測や最適化ができないVUCAの中では、戦略というのはあまり意味がない。逆に、ビジョンが重視され、ビジョンに基づき、どんどん新しい取り組みをしていくことが必要になる。

そして、その取り組みは自発的であることが不可欠である。逆にいえば、従来のようにビジョンから戦略を作り、戦略を実現するために達成しなくてはならない目標に落とし込むトップダウンのやり方ではVUCAに対応できない。

なぜなら、トップダウンのやり方は経営や事業には正解があり、それを的確に見つけることができるのがマネジャーであるという前提に立っている。しかし、そもそもVUCAの時代には正解がないのだ。だから、VUCAに対処するには何をすればよいかが問題ではなく、このような前提を変えた組織やマネジメントに変わっていくことが必要だ。

VUCAの時代を迎え、多く人はその中でも正解を出してくれるリーダーを求めているが、これはナンセンスである。

◆プロセスを重視する管理

このように、VUCAの時代にはプロジェクトの目標を企業や組織の目標から落とし込んでも役に立たない。にも拘わらず、なぜこういうやり方をしているかというと、管理に役立つからだ。その背景には、成果ではなく、プロセスの重視がある。

プロセスを重視すれば、ビジョンから戦略、戦術、目標の落とし込みは管理しやすくなる。これを透明性という言葉で表現される。成果を評価して云々ではなく、プロセスをちゃんと踏んでいれば、望ましい成果が生まれるという仮定があるからだ。

ちなみにこのような考え方の延長線上にプロセス改善がある。プロセスがきちんとしていれば成果が生まれるという思いは強く、それが改善の推進動機になっている。このような思いは今でも継続している。そして、正解がある世界であればこのような仮定は正しいかった。

しかし、VUCAの世界ではそうではない。どうすべきかは、社員の一人一人が考え、それを自発的に目標にしなくては成果は生まれない。言い換えるとトップの果たすべき役割は正解を出すことから、ビジョンやパーパスを示すことに変わっているが、それに気がついていない企業が多い。ここに、日本の経済的な衰退の大きな原因がある。

例えば、GAFAを考えてみてほしい。どういうビジョンを持っているか、どういうパーパスを持っているかは話題になるし、トップは明確に発信している。成果としてどういう新製品が出てくるかも話題になる。そして、市場や投資家はビジョンと照らし合わせて製品の評価をされることが多い。しかし、戦略がどうだとか、目標がどうだとかいうことがあまり議論にならなくなっている。マネジメントの方法が変わってきたわけだが、そもそも、組織の在り方そのものも変わってきている。

◆組織がチームに落とし込むもの

だからといって、組織は仕事やプロジェクトに何も落とし込まなくてもよいというわけではない。仕事やプロジェクトが組織に関係なく、目標を立てて進めてよいわけではない。企業や組織として意思統一が図られている必要がある。

もう一度、バッキンガム氏が行った調査の結果を紹介しよう。彼は最高のチームがどういうものを調査し、高業績チームとそうでないチームの違いには以下の８つの違いがあることを明らかにした。

（１）仕事で「自分に期待されていること」をはっきりと理解している
（２）所属チームでは「価値観が同じ人」に囲まれている
（３）仕事で「強みを発揮する機会」が毎日ある
（４）私には「チームメート」がついている
（５）「優れた仕事」にをすれば必ず認められると知っている
（６）仕事ではつねに「成長」を促されている
（７）「会社の使命」に貢献したいと心から思っている
（８）「会社の未来」に絶大な自信をもっている

ここで注意すべきは（１）～（６）はチームの内部で生み出すことができるが、（７）と（８）は内部だけでは生み出すことができないことだ。

ここで鍵になるのが、チーム、あるいはメンバー一人一人にとってのビジョンやパーパスの意味なのだ。ビジョンやパーパスはその人にとってどのような意味があるのか。

逆にいえば、チームは、ビジョンやパーパスという抽象度の高い組織からのインプットを解釈し、自主的に自分たちの目標に変換していく必要がある。このような目標こそが組織やプロジェクトや仕事にとって意味のある目標である。

例えば、KPI、OKRを考えてみてほしい。目標が役立つかどうか、自分がより大きな貢献をする助けになるかどうかを判断する唯一の基準は、自分が自発的に設定し、自分にとって意味があるかどうかだ。それが組織への貢献に結びつく
。

◆プロジェクトは意味で動かす

繰り返しになるが、VUCAの時代においてはプロジェクト目標を上位組織の戦略や目標から落とし込んできても役に立たない。もちろん、上位組織がプロジェクトを管理する役には立つ。

しかし、プロジェクトチームにとってはノルマになるだけで、パフォーマンスの向上には結びつかないし、創造的な仕事をするためにも役に立たない。プロジェクトで大きい成果を得るためには、ビジョンやパーパスからプロジェクトが自発的に目標を作り、取り組んでいく必要がある。そのためには、組織はプロジェクトに目標ではなく、意味を与える必要がある。

さらにいえば、他人が決めた目標を嫌うのがミレニアム世代の一つの特徴であるという。彼らは仕事に対しても、自分としての意味を求め、自分にとって意味があることには熱中する。プロジェクトマネジメントとしてメンバーのこういう特性を利用しない手はない。その意味でも、上位組織の目標設定者の想いを意味に落とすことは合理的である。

そして、プロジェクトチームは自ら、意味をプロジェクトの目的に変換していくのだ。

◆参考記事

【ＰＭスタイル考】第１６５話　成果物はプロジェクトの目的ではなく、目的実現の手段である
https://mat.lekumo.biz/pmstyle/2020/02/post-2238.html

【ＰＭスタイル考】第１６１話：「役に立つ」から「意味がある」へ
https://mat.lekumo.biz/pmstyle/2020/01/post-f031.html

◆関連セミナー

パーパス・ドリブンのコンセプチュアルプロジェクトマネジメントについて学ぶセミナーです。

━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆「パーパス」でプロジェクトを動かす
　　　　　　　　　～VUCA時代のプロジェクトデザインの実践的方法◆
日時：2021年 07月07日（水） 13:30-17:00
　　　　　　～　07月 08日（木） 13:30-17:00
　　　　※少人数、双方向にて、演習、ディスカッションを行います
形態：ZOOMによるオンライン開催
講師：好川哲人（エム・アンド・ティ　コンサルティング代表）
詳細・お申込　https://pmstyle.biz/smn/conceptual_pm.htm
主催　プロジェクトマネジメントオフィス
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【カリキュラム】
＜第１日＞
１．パーパスとプロジェクトデザイン
２．パーパス実現のシナリオ創り
３．成果と成果物を明確にし、プロジェクト目的と目標を決める
＜第２日＞
４．シナリオからプロジェクトコンセプトを創る
５．成果を実現する本質要求を見極める
６．成果物を実現する本質目標を決定する
７．環境変動時のプロジェクトマネジメントの対応
８．VUCA時代に求められるプログラム＆プロジェクトマネジメント
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆プロジェクトの特徴

基本的なプロジェクトマネジメントの教科書を見ると、プロジェクトの特徴は

・有期性
・新規性
・段階的詳細化

の３つだとされている。これらの特徴を前提として、納期、予算、スコープをコントロールしながらプロジェクトを進めていくのがプロジェクトマネジメントである。

しかし、VUCA時代のプロジェクトにおいてはこの３つ以外の特徴として、

・自己組織化

というという特徴も考えなくてはプロジェクトとしての成果が生み出さすプロジェクトマネジメントが難しいような印象がある。

そこで、今回のＰＭスタイル考では、組織的な面を中心にプロジェクトの持つべき特徴を考えてみたい。そのための切り口として、最近、非常に注目度が高くなってきた自己組織化組織であるティール組織への進化を取り上げてみたい。

◆ティール組織とは

ティール組織を提唱している「Reinventing Organizations」においては位置づけとしてティールに至る組織の進化について丁寧に解説されている。これはプロジェクト組織の性格を考える上で極めて大きな示唆があるので、この進化も含めてティール組織の概要を説明することにする。

ティール組織は2014年にフレデリック・ラルーが書籍「Reinventing Organizations」において提唱した概念で、4年後の2018年に「ティール組織」（英治出版）として翻訳が出版され、多くの人が読み、一挙に知られるようになった。

ラルーがこの本を書いた動機は、

「旧来のマネジメント手法は成果が上がっており正解だと思われているが、実は組織に悪影響を与える可能性を孕んでいる」

と認識したからだ。このため、この本では過去に見られる組織を進化の順に５つのスタイルに分け、そのスタイルの進化を示すことによって組織のスタイルとマネジメントの関係を議論にしている。

ラルーが組織スタイルの進化を示すために用いているのは、ケン・ウィルバーが提唱したインテグラル理論における「意識のスペクトラム」であり、意識のスペクトラムにあわせて組織の進化を

レッド（衝動型）→アンバー（順応型）→ オレンジ（達成型）
　　　 → グリーン（多元型） →ティール（進化型）

としている。この進化で５番目がティール組織になっている。

では、それぞれに、どのような組織なのかを説明していこう。注意しておいてほしいのは、組織としては後に行くほど進化しているが、それがよいかどうかはどういう目的の組織かによって変わってくることだ。プロジェクトにおいても同様で、その目的によって望ましいプロジェクトが異なる。その意味でラルーの認識は参考になる。

◆衝動型、順応型、達成型、多元型の組織スタイル

まず、衝動型（レッド）だが、「特定の個人の力で支配的にマネジメントする」ことにより、強力な上下関係が形成されることを特徴とする組織スタイルである。この組織は短期的な視点で動いており、どのようにして組織として生存していくかだけに焦点が当てられている。このスタイルの例として、ギャングやマフィアが挙げられる。

次に順応型（アンバー）だが、明確に役割が決められており、厳格にその役割を果たすことを求められる組織スタイルである。この組織では、中長期で計画を立てられるようになり、さらに、規模を拡大できる安定した組織構造を作れるようになっている。このスタイルの組織の例として、カトリック教会、軍隊、公立学校などがあげられる。

三番目は達成型だが、アンバー型の役割を、成果があるかないかという基準に置き換えたもので、これは環境の変化に適応するために発展したものだ。つまり、階層構造によるヒエラルキーが存在しながらも、成果を出せば昇進出来る組織スタイルだといえる。このために、常に、イノベーション、説明責任、実力主義が求められれる。このスタイルの組織が今のビジネス組織としては最も一般的であるし、プロジェクト組織においてももっとも基本だといえる。

四番目は多元型だ。多元型は達成型の問題である、物質主義、社会的不平等、コミュニティーの喪失といった問題を解消しようとした組織で、その人らしさを表現可能であり、主体性を発揮しやすく個人の多様性が尊重されやすいことが求められる組織スタイルである。

このため、公平、平等、調和、コミュニティー、協力、コンセンサスを創ろうとし、このため、権限移譲、価値観を重視する文化、心を揺さぶるパーパス、多数のステークホルダーの視点を生かすことなどが求められる。

この組織も一種の自律／自己組織型の組織である。スタイルで成功している企業には、サウスウエスト航空、ベン＆ジェリーズといった経営学のケースによく登場してくる企業があることからも、先進的な組織だと言える。

◆ティール型組織

そして最後が進化型（ティール型）であり、「組織を一つの生命体」であることを特徴とする組織である。ティール組織は、組織に関わる全員のものであり「組織の目的」を実現すべく、メンバー同士で共鳴しながら行動をとる。

ティール組織には、

（１）セルフマネジメント
　指示に従うのではなく、1人ひとりが自分の判断で行動し、成果をあげていく
（２）ホールネス
　個人のありのまま（全体）を尊重し、受け入れることを重視する
（３）進化する目的
　会社のビジョンや事業、サービスは、社員の意思でどんどん進化する

の３つの要素が必要だとされる。

◆衝動型プロジェクトスタイル

さて、ラルーが示したように組織スタイルが進化するとすれば、プロジェクトはどのスタイルであることが望ましいのかが気になるが、既に述べたようにこれはプロジェクトの性格によって望ましいスタイルが変わってくる。

まず、衝動型のプロジェクトスタイルである。プロジェクトはプロジェクトマネジャー次第だという人もいるが、その人のイメージは、衝動型プロジェクトスタイルをイメージしていると想像される。このスタイルのプロジェクトは少なくなってきていると思われているが、衝動型でなくては成果が生まれないプロジェクトもあるのは事実だ。

例えば、会社のスタートアップでは衝動型のプロジェクトスタイルであることが望ましいことも多いし、商品の開発プロジェクトにおいても例えば、ジョブズのような衝動的なプロジェクト運営をすることが大きな成果を生み出すことも決して珍しいことではない。

◆順応型プロジェクトスタイルと達成型プロジェクトスタイル

プロジェクトで一番、多いのは順応型のスタイルである。プロジェクトという言い方をするときにこのスタイルのプロジェクトが最も多い。つまり、明確に役割が決められており、厳格にその役割を果たすことを求められる。そして、役割を決め、その役割を厳格に果たしていくことを求めるのがプロジェクトマネジメントである。特に大規模プロジェクトではこのスタイルの組織を作っていくことが圧倒的に多い。

さらにいえば、IT企業のように経営活動をプロジェクトで行い、プロジェクトで成果をあげれば評価されるような仕組みにしている企業も増えている。これはプロジェクトを達成型のスタイルにしているとみることができる。

◆権限移譲と多元型のプロジェクトスタイル

一般組織と同じようにプロジェクトにおいても、大きな隔たりがあるのは、達成型と多元型の間だろう。その原因になっているのは、権限移譲の難しさである。

プロジェクト自体が組織からの権限移譲だが、ここでプロジェクトマネジャーが計画を作り、すべてをコントロールしようとすれば順応型になるし、そこに成果評価を入れれば達成型になる。さらにメンバーの多様性を活かすためにメンバーに権限移譲すれば、多元型のプロジェクトになっていく。

例えば、WBSとOBSを決めて後はメンバーに任せるというスタイルで運営しているプロジェクトは、多元型スタイルだといえるだろう。これより一歩進んだのが、WBSが作れないようなVUCAなプロジェクトにおいてアジャイルを適用してプロジェクトを進めていくと、多元型になる（これを順応型や達成型でやろうとするとうまく行かない）。

◆ティール型プロジェクトスタイルとパーパスドリブン

それでは、ティール型プロジェクトとはどのようなものかということになる。進化型（ティール型）の組織の要件として、

（１）セルフマネジメント
　指示に従うのではなく、1人ひとりが自分の判断で行動し、成果をあげていく
（２）ホールネス
　個人のありのまま（全体）を尊重し、受け入れることを重視する
（３）進化する目的
　会社のビジョンや事業、サービスは、社員の意思でどんどん進化する

という要件を考えると、一つのパターンとしてあるのはパーパスの実現のために行うプロジェクトである。

パーパスドリブンなプロジェクトでは

「組織のパーパスを実現するためにプロジェクトのパーパスが決まる」

という形で（３）を実現する。そして

「パーパスを実現する方法を自分（たち）で決め、実行していく」

という形で（２）の「個人のありのまま（全体）を尊重し、受け入れる」を実現する。さらに、

「実行する中で発生する様々な問題を自身で解決していく」

ことによって、（１）を実現する。このようにティール型のプロジェクトになっていると考えることができる。

◆VUCA時代のプロジェクトスタイルとプロジェクトマネジャーの役割

このような方法でプロジェクトを進めて行く場合、プロジェクトマネジャーは要らなくなると思われるかもしれないが、それは誤解だ。パーパスに向き合い、パーパスの実現のためにさまざまな調整をしていくことがプロジェクトマネジャーの役割になるからだ。

VUCA時代のプロジェクトはティールなスタイルが必要になるプロジェクトが圧倒的に増えている。そこで、

「ティールなプロジェクトに、パーパスドリブンなコンセプチュアルなプロジェクトマネジメントを行う」

これこそが、VUCA時代のプロジェクトマネジメントの在り方だといえよう。

◆関連セミナー

ティールなプロジェクトのプロジェクトマネジメントについて学ぶセミナーです。

━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆「パーパス」でプロジェクトを動かす
　　　　　　　　　～VUCA時代のプロジェクトデザインの実践的方法◆
日時：2021年 07月07日（水） 13:30-17:00
　　　　　　～　07月 08日（木） 13:30-17:00
　　　　※少人数、双方向にて、演習、ディスカッションを行います
形態：ZOOMによるオンライン開催
講師：好川哲人（エム・アンド・ティ　コンサルティング代表）
詳細・お申込　https://pmstyle.biz/smn/conceptual_pm.htm
主催　プロジェクトマネジメントオフィス
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【カリキュラム】
＜第１日＞
１．パーパスとプロジェクトデザイン
２．パーパス実現のシナリオ創り
３．成果と成果物を明確にし、プロジェクト目的と目標を決める
＜第２日＞
４．シナリオからプロジェクトコンセプトを創る
５．成果を実現する本質要求を見極める
６．成果物を実現する本質目標を決定する
７．環境変動時のプロジェクトマネジメントの対応
８．VUCA時代に求められるプログラム＆プロジェクトマネジメント
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━