コンセプチュアル・マネジメント

◆回復力、あるいは弾力性

最初のテーマを何にしようかと思って、ふと、頭に浮かんだのがレジリエンス(resilience)である。レジリエンスは一言でいえば、

困難な状況にもかかわらず、うまく適応できる力

であり、カタカナで使われることが多い言葉だが、日本語では回復力とか、弾力性といった言葉があてられる。僕が、レジリエンスという言葉を知ったのは、ある仕事で金井壽宏先生にアドバイスを求めたときに、キーワードとしていただいたことがきっかけである。金井先生は、昨年出版されたポジティブ心理学のワークショップ記録書籍「人勢塾」の中で、以下のように　説明されている。

（レジリエンスとは）ネガティブな逆境、葛藤あるいはポジティブであるが進歩、責任の増大など圧倒されてしまいそうな状況に、立ち向かい、克服し、元の状態にまで跳びはねていく力、さらに、そのような状況に偶然遭遇するだけであく、自らの選択で、安定して快適なゾーンを後にして、なにか新しくて未知なことに乗り出し、途中であきらめずにそれを成し遂げる力を指す。

金井 壽宏編著『「人勢塾」 ポジティブ心理学が人と組織を鍛える』、小学館（2010）
https://mat.lekumo.biz/books/2010/04/positive.html

※ＰＭＢＯＫはＰＭＩの登録商標です。登録商標マークは省略しています。

◆ついに、ＰＭＩがアジャイルに

米国ＰＭＩがアジャイルプロジェクトマネジメントの試験を始めると発表した。結構、話題になっている。ＰＭＢＯＫとアジャイルというと、水と油のように思っている人が多いようだ。

これが大きな誤解だ。ＰＭＢＯＫはプロセスに対して、インプットとアウトプットが完全につながっている。つまり、全体が巨大な一つのプロセスになっている。ＰＭＢＯＫの信奉者の大好きな世界だが、このことにさして意味があるわけではない。ＰＭＢＯＫのプロセスをすべて実行するようなマネジメントが必要なケースはほとんどないからだ。

ＰＭＢＯＫのすべてのプロセスには、ツールと技法という「プラクティス」が示されている。ＰＭＢＯＫのプロセスは、プロセスの形で示されたプラクティスだと考えた方がすっきりする。

ＰＭＢＯＫの原型ができたのは、１９８７年であるが、標準になったのはそこから１０年後の１９９６年である。当初はプロセスとして標準化しようとしたが、実際には難しく、知識体系に落ち着いたという経緯があり、収束に１０年の月日がたったという話を聞いたことがある。

実際にマネジメントプロセスを記述するというのは不可能に近い。実際に１９９６年に出版された初版のＰＭＢＯＫはすべてのプロセスはつながっていない。

◆プロジェクトリーダーはビジョンを決める

戦略ノート２４２で述べたように、正しい意思決定をするプロジェクトリーダーと、正しくプロジェクトを実施するプロジェクトマネジャーの両方の役割が必要である。言い換えると、プロジェクトにはプロジェクトマネジメントとプロジェクトリーダーシップが必要である。ここで、いくつか考えるべき点がある。

一つ目は、プロジェクトリーダーは何を意思決定する役割かという問題である。もっともしっくりくるのは、プロジェクトリーダーはプロジェクトのビジョンを決める。つまり、そのプロジェクトが企業や社会にとってどのような役割を果たすプロジェクトにするのか、言い換えるとプロジェクトの目的を決める。そして、プロジェクトマネジャーはそのビジョンを実現する役割になる。

このようなフォーメーションでは、プロジェクトリーダーはプロジェクトスポンサーになることが多い。プロジェクトである目的を達成するためにプロジェクトを立ち上げ、予算をつける。そして、プロジェクトマネジャーを指名し、その目的の達成を委ねる。

◆真摯さと成果

プロジェクトマネジメントオフィス（ＰＭＯ）がプロジェクトに対して何ができるかという議論は今でも、オープンな問いである。もっとも、そんなことは考えなくなっている組織が多いが。

この議論のポイントは、「真摯さ」という意味での正しさと、成果を上げるという結果の正しさの折り合いの付け方にある。

昨年来、ドラッカーが注目されるようになり、「真摯である」ことの意味が見直されるようになってきた。ドラッカーのリーダーは、リーダーの資質など存在しないという立場に立っているが、唯一、リーダーの資質としているのが、真摯さである。

真摯さの定義は難しい。何が正しいかを考え、誰がどう思おうと気にせず、正しさの実現を求めていく。そんなところだろうか。さらにいえば、正しいことは独善であってはならず、共通善である必要がある。

成果を示す概念に、アカウンタビリティという概念がある。これがまた、わかりにくい。日本語では説明責任といったり、成果責任といったりする。実は、両方正しい。成果を上げたと言えるには、取り組んでいることが正しいことを説明できなくてはならない。そのためには、何が正しいかを考えておかなくてはならない。これが真摯さである。

◆リーダーシップのないマネジャーと、マネジメントのできないリーダー

よくこんな議論をすることがある。

リーダーシップのないプロジェクトマネジャーの率いるプロジェクトと、マネジメントのできないリーダーが率いるプロジェクトのどちらに参加するか

リーダーシップは正しいことを行うこと。マネジメントは正しく行うこと。

前者は、プロジェクトのビジョンや目的を示さず、また、メンバーを鼓舞するわけでもなく、ひたすら、ＱＣＤＳのプロジェクト目標達成のために厳密な計画を立て、管理をするイメージだ。

これに対して、後者はプロジェクトにビジョンを持たせ、メンバーの動機づけも行うが、基本的にはメンバー任せで、困難に直面しても、励ます以上のことはしないようなイメージである。

どちらもどちらだという意見が圧倒的に多いのだが、プロジェクトには本質的に

正しいプロジェクトを行うという側面と、プロジェクトを正しく行うという側面

が必要である。

◆自分にとってのプロジェクトの意味づけをしていない

新年早々、ネガティブなタイトルで恐縮だが、年末にある忘年会でこの話題になった。実際のところ、コンサルタントとしてクライアントのプロジェクト憲章などでプロジェクトの企画を見る機会は少なくないが、参加してみたいと思うようなプロジェクトは滅多にない。

いろいろな意見が出てきたが、結局、そのプロジェクトに参加しているひとりひとりのメンバーが、自分にとってのプロジェクトの意味づけをしていないことに行き着くのではないかということになった（もちろん、その一人はプロジェクトリーダーである）。

◆はじめに

今年は史上空前の「マネジメント」ブームだった。小説のスタイルをとっているとはいえ、ドラッカーの「マネジメント」をテーマにした本が２００万冊近く売れるというのは、冷静に考えると、ちょっと考えられない話である。ビジネス書のミリオンセラーというと、２００７年に刊行された水野敬也さんの「夢をかなえるゾウ」が記憶に新しいが、こちらは自己啓発の本なので、まだ、想像の範囲内であった。

そんな１年の締めくくりにというわけでもないが、深田和範さんという自称「リストラされ、求職中」のフリーランスのコンサルタントが「マネジメント信仰が会社を滅ぼす」という本を出版された。マネジメントは本当に有益なのかというのは、興味深いテーマなので、戦略ノートでも少し、議論してみたい。

マネジメント信仰が会社を滅ぼす（新潮新書）

深田さんの指摘は、マネジメントが不要だというのではなく、ビジネス不在のマネジメントに意味があるのかという指摘だ。この問に関する結論は明確である。不要だ。昔から言われている管理のための管理、マネジメントを目的化することのナンセンスさをマネジメント信仰と揶揄している。

◆求められる概念的思考

この１０年くらい、というかある意味では高度成長期からずっと言われているのが「考えよ」ということだ。ものを考えるとは、「概念的に」考えるということである。

研修にしろ、ＯＪＴにしろ、何か概念的な説明するとかならず「例えばどういうことですか」という質問をする人がいる。質問の理由を聞くと、「曖昧」であるという人がいる。あるいは、具体的なイメージがないと腑に落ちないという人がいる。

ここが本質だと思う。多くの人は概念的な話を、曖昧だと感じてしまうのだ。この議論に日本語という言語の曖昧さの問題を持ち出す人もいるが、今回はこの問題は除外
する。

◆自律的なチームを管理する

２０１１年の１月に企画したセミナー「ＰＭＢＯＫ（Ｒ）とチームファシリテーションの融合」というセミナーに「自律的なチームを管理する考え方と方法」というサブタイトルがついている。告知すると早速、自律的なチームの管理というのは矛盾ではないかという指摘があった。「管理されているチームは自律的ではないでしょう」という指摘だ。

これは誤解である。自律とはレスポンシビリティ（作業責任）に対するものであり、管理はアカウンタビリティ（成果責任）に対するものである。簡単にいうと、個人やチームは自分の役割を果たすことに自律的な責任を持つが、その成果に対しては組織（プロジェクト）が責任を持つ。これが、「自律的チームを管理する」という概念であり、プロジェクトマネジメントの最も基本的な形なのだ。

◆なぜ、日本人は画期的なアプリケーションが作れないのか

先日、「日経コンピュータ」の前編集長である谷島宣之さんと、弊社のPMstyleプラチナ会員向け会報用の対談をしたときに、モノづくりでは現物があるのでうまくいったが、ソフトウエアでは目に見える現物がないのでダメだという話になった。

今回はこの問題を議論してみたい。

ものづくりはモノから入る。つまり、現物という具体的な姿から入り、そこでいろいろとモノをいじくり回しながらアイデアを出していく。そこでのアイデアの創出はすばらしく、それが日本企業の躍進を生み出した。これがうまくいったという意味だ。

しかし、ソフトウエアの場合、目に見える現物がない。そこで、ものを概念的に捉え、概念的なレベルで設計をし、アイデアを埋め込んでいく必要がある。

マッキンゼー出身のコンサルタントで、ＳＡＰやクインタイルズ・トランスナショナル、ルイ・ヴィトンなどの日本法人の代表を務め、現在は電気自動車用充電インフラ提供をするベタープレイスの日本法人代表を務める藤井清孝さんが、「グローバルイノベーション」（朝日新聞出版、2010）という本で、興味深い指摘をしている。ちょっと長くなるが、紹介しよう。

=====
私は、ＳＡＰという基幹業務向けのソフトウェア企業の日本法人社長を６年近く務めたおかげで、ソフトウェアの開発力強化に必要なものを身をもって体験した。ソフトウェア開発で一番大切な能力は「概念設計」である。まず、いろいろなシナリオをシミュレートしながら、論理的に詰めていく力である。
（中略）
日本人には「現場にすべての答えがある」と信奉している人が多いと感じるが、これは現場を積み重ねて結論を出す「演繹(えんえき)的な思考」教育の結果だと感じる。これに対してソフトウェアの開発には、トップダウンで概念設計から入っていく「帰納的な思考」が必要であり、これは日本の教育が得意としてきた分野ではない。このようにソフトウェアの開発では、「トップダウンの概念設計」「目に見える現場が存在しない」「試行錯誤が必要」といった特徴があり、従来の日本のメーカーが得意とする分野での経験が活かしにくいのである。
=====

まさにそのとおりだと思う。概念思考スキルを身につけない限り、ソフトウエアビジネスで日本が成功できるとは思えない。

しかし、現実には、ソフトウエア開発は国を挙げて見える化の方向に向かっている。これはこれだ重要な取り組みだと思うし、否定するものではないが、結局、概念的な思考ができるようにならない限り、競争力のあるソフトウエアはできないと思うし、プロジェクトマネジメントをうまく行い、ビジネスで勝つことも難しいのではないかと思う。