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

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

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

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

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

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

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

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

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

が必要である。

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

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

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

◆はじめに

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

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

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

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

◆求められる概念的思考

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆理解＝分ける＋再構成

今回はちょっと変わった話をしてみたい。

ＷＢＳをベースにしたプロジェクトマネジメントは、分けることを前提にしている。
では何のために分けるのか？分かるためである。つまり、このプロジェクトがどういうものであるかを理解（認識）するためである。

ただし、細分化するだけでは理解に到らない。細分化されたものを再構成する作業が理解を導く。再構成の方法にはいろいろとあるわけだが、一般的にいえばシナリオに
沿って再構成する。プロジェクトではこれをスケジュールといっている。

◆見える化から見せる化へ

見える化はあたり前になりつつあるが、一方で、「見せる化」という言葉が注目されつつある。見える化というのは内向きの話だが、見せる化は外向きの話である。

見せる化の元祖はおそらく、寿司屋である。もう２０年以上前になるが、米国から来日したビジネスパートナーを寿司屋に連れて行ったら、寿司そのものよりも、カウンターで客を前にして握ることに感動していた。確かに、珍しかった。最近では、飲食では、蕎麦屋とか、うどん屋とか、刀削麺の店でよく見かける。

◆リスクマインドの低さがものごとを複雑にしている

突然だが、リスクマインド強化研修の中で、リスクマインドを作り出す５つのプロセスとして

・失敗から学ぶ
・単純化を許さない
・現場を重視する
・専門性を尊重する
・復旧能力を高める

が必要だという説明をしている。以前、この研修を受講して戴いた方と偶然お会いする機会があり、シンプリシティの話になった。彼がいうには、リスクマインドが低いから、ゴテゴテの商品ができるのではないかというのだ。

◆プロジェクト憲章を誰が書くのか

１０月２８日に開催したセミナー「ＰＭＯ２.０」セミナーのパネルで、プロジェクト憲章を誰が書くかが話題になった。一般的なプロジェクトマネジメントの教科書では、プロジェクト憲章はミッションステートメントであり、プロジェクトのミッションとプロジェクトマネジャーの指名を目的としたドキュメントである。

その意味では、例えば、事業部長など、組織のしかるべき人が書く。プロジェクトによっては、社長が書くようなものがあってもおかしくはない。