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

文部大臣が小学生から英語を勉強させる必要はないといって、ちょっとした騒動になった。行政の一貫性を無視した発言なので、発言そのものはどうかと思うが、考え方は与したい部分がある。

英語でコミュニケーションできることはこれまでもこれからも必須である。そして、言語中枢は１０歳くらいまでにかなり出来上がってしまうので、小学生から学ばせることが望ましい。この理屈は良く分かる。

しかし、言葉というのは文化である。モノがなければ、単語はない。思考法がなければ、その思考法を具現化するレトリックはできない。典型的な例を挙げれば、否定と肯定だ。例えば、「基本的にそれでよいと思う」という言い方がある。これを英作文しろといわれれば、困る。文脈が明確な中で、合意する前提条件を明確に述べるといったことしか思いつかない。

こういう言い方はビジネスの中で論理的にものごとを進めていく際の障害になるので、歓迎されない。しかし、逆に明確にすることで問題が派生するケースがある。

例えば、顧客の要求を明確にする作業の中で、顧客が「基本的にそれでよいと思う」と言ったとすれば、「だいたい、よいと思うが、まだ自分たちにも見えない部分があるので、それを基本路線として一緒に考えてほしい」というような意味のことが多い。分からないのだから、条件として明確にかけない。しかし、書こうとするので、不完全な条件記述になる。当然、後でトラブルの元になる。こんな感じだ。

どこに問題があるかというと、言葉の背後になる行動様式の違いがあり、そもそも、それは文化に拠る部分が大きい。ソフトウエアの世界でいえば、仕様記述の問題としてワインバーグがこの問題はよく指摘しているし、ユースケースなどが使われだした理由もここにある。ユースケースは英語でも日本語でもない新しい言語ということになり、そこに新しい行動様式、思考様式を築いていこうという試みだ。

マネジメントとか、エンジニアリングでは、多くの場合、欧米から日本に概念を持ってくるので、この逆のケースがよく発生する。プロジェクトマネジメントでもそれはある。

よい意味でもっとも痛感するのがスコープ。この言葉は日本語にはない。だから外来語としてカタカタになっている。スコープという言葉を一つ導入することで、今までやってきたいろいろな工夫も説明できるので、導入に意味がある例。実際に、組織のプロジェクトマネジメントを導入すると、真っ先に普及する言葉はスコープであることが多い。今まで、もやもやしていたのが、霧が晴れたように言葉にできたのだと思う。

逆に、どうかなと思うのが、レスポンシビリティ。例えば、ＲＡＭに相当する概念は体制図だと思うが、日本的な業務運用を考えると、ＲＡＭより体制図の方が自然だし、定義する意味がある。日本的な考え方では責任とは連帯責任であり、いろいろな意味でプロジェクトを最後まで成し遂げるためにはプラスに働くことが多い。極論すれば、ＷＢＳがなくても、職務記述があれば、やってしまうのが日本の組織である。

ＰＭＢＯＫがこのやり方よりよいなどとは言い切れないだろう。民主党が農業政策として付加価値を全面に押し出した政策を主張しているが、工業の分野でも同じような特性がある。少なくとも、日本人は、このやり方で高い付加価値の商品を生み出してきた。これは日本人のＤＮＡであり、文化でもある。

このような文化の中に、不用意に新しい言葉を入れると、琵琶湖の外来魚のようになってしまう可能性がある。外来魚が従来の生態系を壊したように、その言葉が文化を壊してしまう可能性がある。

技術をどんどん、欧米から導入するのは明らかにプラスである。しかし、マネジメントを不用意に入れるのは、日本人のコアコンピタンスである現場を壊してしまう可能性が高い。そろそろ、考えるべきときに来ている。

◆ＰＭＯブーム到来！？

９月２９日に第２期のＰＭＯリーダー養成講座の説明会を行った。１週間前にすでに５０名になり、好評だった。今回は講演をマイクロソフトの浦さんに、プロジェクトマネジメントの導入をテーマにお願いした。PMstyleでもそろそろ、ツール（ＰＭＩＳ：プロジェクトマネジメント情報システム）の問題と正面から取り組もうと思っており、どんな切り口がいいかを探る意味があったが、こられた方の関心は、はやり、ＰＭＯの立上げとか、成長にあるようだった。

ちなみに、同じ日の夕方、ＰＭＩ東京支部の例会で、三菱総研の方がＰＭＯの話をされるということで参加したが、こちらも盛況で、ＰＭＯに対する関心はどんどん高くなっていることを実感した。

このセミナーでも簡単に問題提起をしたのだが、実際問題として、ＰＭＯにはどんな問題があるのだろうか？あるいは、ＰＭＯを作ったときにうまく機能するにはどのような問題をクリアしなくてはならないのだろうか？この問題はさまざまな観点があるのだとは思うが、今、もっとも痛切に感じているのは、人の問題である。また、企業から聞く話の中でもやはり、人の問題が大きいようだ。

◆ＰＭの標準化は賽の河原で石を積むような仕事？

先日、こんな相談を受けた。３年くらい前から、ＰＭＯを作ってＰＭＢＯＫ流の定着を図っているのだが、なかなか、成果がでない。コンサルも使っているが、コンサルの分析は仕組みやプロジェクトマネジャーの問題点の指摘が多い。確かに指摘としては正鵠を得ているので順に取り組んでいるのだが、あまり、成果には結びつかない。「賽の河原で石を積んでいるような思いだ」とも言われていた。

この企業はコンサルタントを入れているので、方法論を作るところにはあまり問題がないのだと思うが、よく見かけるＰＭＯの活動の問題で以下のような問題がある。

標準や制度を作っても実行されない
プロジェクトガバナンスのマネジメントができない
プロジェクトに影響を与えられない
プロジェクト実施環境に応じて、ＰＭＯが変容できない

この中でもっとも基本的な問題はやはり、最初の「標準や制度を作っても実行されない」という問題である。最近、ＰＭＯの権限という話をよく聞く。ＰＭＯが権限を持ち、現場に出るといろいろな問題が解決するという話はある意味で幻想である。そんな活動をするＰＭＯを作るのであれば、プロジェクトマネジャーの強化をするだろうし、そもそも、そんなことができないから、プロジェクトマネジメントに対する支援の必要性が訴えられているのだ。

◆ＰＭＯの切り口での支援をするＰＭＯリーダー

その意味で、ＰＭＯはＰＭＯとしての切り口で支援を行わなくてはならない。そのためには、まずは、標準や制度を実行性のあるものにすることだ。

ここで再び、ＰＭＯの権限というのが登場してくる。ＰＭＯに権限を与えると、標準や制度を実行させることができると考える。これも幻想だ。プロジェクトマネジャーが標準や制度を実行することでプロジェクトの結果責任から逃れられるのであれば、確かに、考えるプロジェクトマネジャーはいるような気がする。しかし、最終的には、やはり、そういう理由では実行しないだろう。

プロジェクトマネジャーが標準や制度を実行する「唯一の理由」はその標準を使えばプロジェクトが成功すると思うことである。ここでまた水掛論になる。ＰＭＯが他の成功したプロジェクトや識者の意見を取り入れて開発した標準を、「一介のＰＭ」が無視するのは如何なものか？

これでは良い商品を作ったのに買ってくれないと顧客のレベルを非難している企業と同じだ。ＰＭＯにとってプロジェクトマネジャーはコントロールの対象ではなく、顧客である。そのような対応ができるのが、われわれが提唱しているＰＭＯリーダーである。そうあってほしいと思っている。