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

Ａクラスのプロマネ。

大手のＳＩ企業だとどこの企業でも、プロジェクトマネジャー認定制度がある。企業によって差はあるが、おおむね、３～４段階で、段階は実績のあるプロジェクト規模というのが普通だ。

さて、人材マネジメントの世界に目を移すと、Ａクラス社員、Ｂクラス社員、Ｃクラス社員という区分がある。これもプロジェクトマネジャー認定制度を同じ発想で、能力に着目した区分である。

ところが日本ではこの考え方は合わないのではないかと思うことがよくある。日本の人間観の中には、Ｂクラスがいるから、Ａクラスがいるという人間観は根強くある。つまり、「能力の違いは役割の違いに過ぎない」という人間観がある。さすがに、最近では、ＣクラスがいるからＢやＡがいるというのは消えてきたが、僕が就職した頃は、それもアリだったように思う。

ここで言っているＣクラスとは「いくら指導しても業績が改善されない」社員のことをいうので、それはもうこのような議論では論外だとしても、ＡクラスとＢクラスは、役割だと考えることが間違いだと言えない部分がある。

一般企業でいえば、Ａクラスの集まりだと思われているコンサルティングファームでも、やはり、Ｂクラスはできる。Ｃクラスもできるそうだ。そう考えると、組織の中ではＢクラスにはＢクラスの役割があると考えるのが自然である。

日本の組織の考え方で、強い組織を作るにはＢクラス（二番手）が優秀な組織を作るとよいという考え方がある。この一番手、二番手は能力のことを言っているのではないのは明らかだ。能力のことを言っているのであれば、みんながＡクラスを目指せばよいからだ。能力以外の何かで優秀なＢクラスを必要としているのだ。

という風に考えると、そもそも、バリバリの能力を持った人材がＡクラスという定義そのものが怪しくなる。

ここでふと思うのが官僚という人種のことである。明治にできた制度だが、官僚というのは、国を成長させることに目覚めた人たちである。結果として、よく勉強し、優秀な人材が集まるようになった。が、決して優秀なのは官僚だけではない。民間にも優秀な人材はいる。違いは、民間の優秀な人材が自分（自社）の発展だけを考えるのに対して、官僚は国家のことを考えていることだ（皮肉にも、その官僚が自社のことだけを考えるようになって、民間人と同じようになりつつあるようだが、、、）。

これは立場の違いである。

ＡクラスとＢクラスの人材の違いもこれではないかと思う。話は、少しスケールダウンするが、Ａクラスの人材は自分の成長の発展を考える。Ｂクラスの人材はＡクラスの人材の描いたビジョンを実行するために自分の成長を考える。能力だけでいえば、Ａクラスの人材に勝るとも劣らない人もいる。組織からみて、Ａとか、Ｂとかいうのはそういうことではないかと思う。

さて、そこで、Ａクラスのプロマネ。とはどういう人材か？少なくとも、１０億のプロジェクトができるのがＡクラスで、１億のプロジェクトができるがＢではないだろう。もし、本気でそう思っている組織があるとしたら、その組織には明日はないと思う。単なる個人の集まりのような組織に過ぎない。

では、何か？あとは、あなたが考えて、コメントしてほしいと思うが、ヒントは２つあると思う。ひとつは、プロジェクトマネジメント自体を成長させることに目覚めた人だ。もうひとつは、プロジェクトマネジメントを企業の競争優位源泉にしていくことに目覚めた人だ。

僕の愛読しているメルマガのひとつである経営コンサルタントの吉田繁治さんの「ビジネス知識源」で、だいぶ昔であるが、責任について面白いことを書かれていた記憶がある。

「ビジネス知識源」
http://blog.mag2.com/m/log/0000048497/

バックナンバーを探しても見つからなかったので、うろ覚えのままで紹介しておく。

「日本人は責任というのをネガティブに捉えすぎる。責任を取ると言った時は、「個人が不利益を蒙ること（例えば、会社を辞める）」を意味する。つまり、責任という言葉を持ち出すときにはそこまでの覚悟を問われることになる。このように責任というのを捉えると、誰も容易には責任は取れないので、みんなが責任を回避することに精力を費やす。また、逆に責任の追求をあいまいなままで済ますという図式ができあがった」

といったような話だった。

プロジェクトにおいても、責任回避や、責任追求をあいまいにしているプロジェクトは少なくない。トラブルプロジェクトにコンサルティングに入ると必ずといってよいくらい、責任転嫁の構図がある。さすがに名指しで誰が悪いといった露骨なものはめったにないが、プロジェクト自身に問題があるというスタンスのプロジェクトはあまりないが、要員が見つからない、顧客側に問題があるとか、組織のサポートが悪いとかいう話はしょっちゅう耳にする。

特に困るのは、自分の失敗を認めておきながら、プロジェクトは悪くないというプロジェクトマネジャーだ。「スケジュール遅延を速やかに上司に報告しなかったのは自分の責任だ。しかし、スケジュールが遅れているのはプロジェクトの問題というよりも、人の確保ができないことが問題で、メンバーは今の陣容でよくやっていることは認めてほしい」といったことを平気でいう。一見、潔いようにも見えるが、究極の責任転嫁である。

また、このような状況を嫌い、責任をあいまいなままでプロジェクトを進めている企業も少なくない。プロジェクトメンバーが互いに助け合ってプロジェクトを進めていく。責任を明確にしてもプロジェクトの中の人間関係がギクシャクするだけで、プロジェクトにとってメリットはないという言い方をする人も珍しくない。

このような状況の背景には、「責任」というのをネガティブに捉える文化がある。ネガティブに捉えていては捉えていてはプロジェクトマネジメントは成り立たない。

いずれの場合も、プロジェクトにおける責任というのを必要以上に重く考えているからだと思う。ＲＡＭを考えてもらえば分かるが、プロジェクトで言っている責任というのは、できなければそんな転地がひっくり変えるような話ではない。少なくとも、個人が不利益をこうむるべき筋合いのものではない。もちろん、責任を持ってやってもらうことは重要なのだが、仮に、任されたことをできなかったときには、「最後までやり遂げることによって責任を取る」という程度のものだ。

こういう話で思い浮かぶのは、日本の国務大臣の責任のとり方である。５年前に小泉が首相になるまでは、何か問題があれば「やめて責任を取る」というパターンだった。つまり、個人が不利益を蒙ることによってみんな納得してねというパターンだ。しかし、５年間で完全に変わった。「業務を全うすることにより責任を取る」ということを堂々と言うようになってきた。これである（安部首相になって先祖がえりしているのが気になるが、、、）
難しいプロジェクトのマネジメント、あるいは、リスクのマネジメントを適正化するためには「責任」に対する意識改革が急がれる。

この記事を書いていてふと思い出したことがある。岡部幸雄という偉大な競馬のジョッキーがいる。競馬では、Ｇ１レースの１番人気の馬に乗って騎乗ミスでもしようものなら、１００億円もの賭け金が泡に帰す。我々には想像もできないようなプレッシャーだと思うし、日本人的責任感覚でいえば、Ｇ１で１回騎乗ミスをすれば騎手を辞めなくては収まらないだろう。ところが彼は、「たかが競馬、されど競馬、Take it easy」といっていた。騎乗ミスしたら、その後のレースできちんと責任を果たすことにより騎手としての責任を果たす。

こういう責任の感じ方、とり方が必要なのではないだろうか？これがプロフェッショナルでもある。

ドラッカーが発明したというマネジメント。ドラッカーは

マネジメントをその役割によって定義しなければならない

とし、役割として

　・組織に特有の使命、目的を果たすこと
　・働く人を人間的存在として活かす
　・社会的問題の解決に貢献すること

の３つをマネジメントの役割だと定義した。以来、マネジメントは、さまざまな学者、実務家によってさまざまな形で語られているが、大枠でドラッカーの定義の範囲での議論になっている。

中でも興味深いのは、戦略論のグル（大家）の一人である、ミンツバーグのエスノグラフィー（民族誌学）

ヘンリー・ミンツバーグ（奥村哲史、須貝栄訳）「マネジャーの仕事」

である。この本を読んでみても、はやり、マネジメントとは、ドラッカーの定義した役割を果たすためのさまざまな活動だという印象が残る。

ミンツバーグのエスノグラフィーを参考にしつつ、ドラッカーの定義をもう少し、具体化してみると、マネジャーの仕事というのは

　（１）ビジョンを策定し、課題、目標を設定する
　（２）メンバー全員で目標達成のためのプラニングをする
　（３）プラン実行のための組織の運営方法を決める
　（４）メンバーとコミュニケーションをし、一人ひとりの能力を発揮させる
　（５）プロセスマネジメントを強化する
　（６）目標達成に立ちはだかる問題を解決する
　（７）メンバーを評価する

の７つの集約されるのではないかと思う。成果を生み出すためにこれらを効果的に行うのがマネジメントである。

プロジェクトマネジメントはマネジメントである。プロジェクトに対してこれらの７つを行うことが仕事である。プロジェクトマネジャーはプロジェクトを任され、これらの仕事をしなくてはならない。

マネジメントはプロセスではできない。コンピテンシーを以って行うべきものである。しかし、ＰＭＢＯＫの標準プロセスなるものが膨張してくるとともに、プロジェクトマネジャーの中にはプロセスを指向するものが増えている。これが幻想だといわざるを得ない。マネジメントができないプロジェクトマネジャーになる可能性が大きい。

「ひとつ上のプロマネ。」はプロジェクトマネジャーを目指すのではなく、マネジャーを目指さなくてはならない。プロセスではなく、コンピテンシーを指向しなくてはならない。そのような視点を持って自分の能力を開発していかなくてはならない。

マーケティングコンサルタントの阪本啓一さんが、メールマガジン電脳市場本舗～Marketing Surfin'で、「マネジメントの３Ｄ」ということを言われている。３Ｄとは

「意思決定（Decision Making)」

「デザイン（Design）」

「実行（Do）」

の３つのＤであり、マネジメントにはこの３Ｄが重要だというのが阪本さんの考えだ。

そして、阪本さんは「エベレストに登る」のと、会社経営をすることはどちらが難しいかという問題提起をする。

＜エベレストに登る＞

・意思決定＝エベレストに登ることを決める

・デザイン＝ルートや使う道具を決める

・実行＝実際に登る

ところが会社を経営する場合には、そこに山はないので、山を作ることから始めなくてはならない。すると、次のような感じになる。

＜会社を経営することの比喩＞

・意思決定＝山をつくることを決める

・デザイン＝どんな山をつくるかを決める

・実行＝山をつくり、登る

このように会社経営は登るだけではなく、山をつくるところから始めなくてはならない。だから会社経営の方が難しいというのが阪本さんの考えだ。

このメルマガを読んでいるうちに、僕が今までうまく表現できていなかったことがはっきりした。

プロジェクトというのはどちらなのだろうか？

この比喩でいえば、プロジェクトは山登りであると思っている人が多い。そして、エベレストに登れるか、その辺の山に登れるかがプロジェクトマネジャーの能力であると思っている人も多い。

たしかに、どんな山を作るかは決まっている。山頂が見えていることも多い（最近は、見えないことも多いが）。

しかし、プロジェクトは山登りだと言い切ってしまうと、

　誰が山をつくるのか

という問題が残ってしまう。プロジェクトは経営（戦略）の実行部分である。これは、阪本さんの比喩を使うと、

　プロジェクト＝山をつくりながら、登る

ということを意味している。

もちろん、つくるという程度はいろいろあると思う。もろい地盤があり、それを固めながら登っていけばよいプロジェクトもあるかもしれないし、ひょっとすると、一から土を盛りながら登っていかなくてはならないプロジェクトもあるかもしれない。

このときに、山を作るのは「経営の責任だ、山ができてから登れといってほしい」と行ってみても何も変わらない。

「普通の優秀なプロマネ」がエベレストに登れる人だとすると、「ひとつ上のプロマネ。」は、経営がデザインした山を創りながら登れる人である。

『ひとつ上のプロマネ。』という言葉から、「プログラムマネジメント」、「マルチプロジェクトマネジメント」を連想される人は多いと思う。

ある意味でこれは正しいと思う。ある意味というのは、これらは

　視野を広く持った上で、全体のバランスを考える

ことに本質があるからだ。

プロジェクトマネジャーは、得てして自分のプロジェクトの利益だけを考えて動く傾向がある。タコツボプロジェクトである。権限委譲の意味を勘違いし、権限委譲されているので、自分たちだけで「できる」と勘違いしているケースだ。

組織の中でプロジェクトをやっている限り、これは論理的に成立しない。無理は、組織の中での無理を生み、必ず自分のプロジェクトに跳ね返ってくる。ここをいかにうまくコントロールできるかが問題だ。

このすべてがプロマネの守備範囲だとは思わないし、それがＰＭコンピテンシーだとも思わない。むしろ、これは組織の問題であり、プロジェクトスポンサーの問題である。しかし、どこまで見えているか、そして、それに対してどのようなイニシャティブを取れるかは大きなポイントである。

タコツボから出て、海で泳ぐことができる。

これが、ひとつ上かどうかのひとつの分かれ目であることは間違いない。とりあえず、こんな本は如何でしょうか？

アービンジャー・インスティチュート（金森 重樹監訳、富永星訳「自分の小さな「箱」から脱出する方法」

ＳＩのプロマネをやっている山村さんから質問（意見）を戴いた。企業名を出さないことを条件に了解がえら得たので、公開質疑としたい。

【山村さんの質問】

「ひとつ上のプロマネ。」というのは、経験をつんだベテランのプロマネということでしょうか？ひとつ上のプロマネ。を目指すには、まず、多くのプロジェクトを経験するということになりますが、現実には同じようなプロジェクトしか担当しないので、難しいと思います。何か、アドバイスをいただければありがたいです。

僕は違うと思う。

　栴檀は双葉より芳し

という言葉がある。エンジニアの場合、この例えは難しい場合がある。それは、ファーストキャリアで、会社で仕事をすることの作法とか、お客さんとはどういうものなのかとか、常識がわかっていない人が、いきなり、うまくできるものではない（組織もそれはよく分かっているので、その時点での能力が発揮できるところにはめ込むので、それをあまり感じることはないだろう）。

ところが、プロマネはファーストキャリアであることはまずない。つまり、仕事をすることがどういうことか、お客様とはどういうものかを「その人」なりに分かっている。その上で、プロジェクトマネジャーという「ロール」をこなす。すると、やはり、「栴檀は双葉より芳し」となるのだ。たる人は、最初から「何かいいもの」を持っているのだ。

これを「人間力」だとか、「ＰＭコンピテンシー」だとかで言いたがるが、僕はそれでは物足らない。ひょっとすると、スピリチャルなものかもしれない。それをみなさんと一緒に探したいと思っている。

僕もよく分からないので、今のところ、「何かいいもの」とだけ言っておく。

確かに、「何かいいもの」は経験で身につくこともあるだろう。そういう人もたくさんいる。でも、経験だけでは身につかないようにも思う。

同じようなプロジェクトをやっていても、やり方が劇的に変わる。そんなゴールを目指しましょう！

あるクライアントの話。

先週、若いプロダクトマネジャーが何のために商品開発をやっているかわからない。何か妙案はないかという相談を受けた。ウソだと思われるかもしれないが、意外なくらいこの手の話は多い。

要するに話の本質は「自分の想い」がないという話。せっかく、権限委譲をしても、無責任に投げ出すわけではないが、寝食を忘れてコミットするという話でもない。当事者に聞いてみると、やらされ感があって楽しくないという。権限委譲というのは難しいなあと思った。

権限委譲といえば思い出すのが、オーナー企業の後継者問題。中小企業の経営コンサルティングをしているとこの問題にはよく遭遇する。後継者には２タイプある。待つタイプと、奪うタイプ。後継者は血縁が多い関係もあり、日本的には待つ方が好ましいように感じる人が多い。

しかし、この２０年くらいを見ていると、経営環境がどんどん変わって行くので、待っていると、自分が引き受けたときには、自分の思いを実行するだけの体力がなくなっていることが多い。やっぱり、奪うことがお互いの幸せにつながるようである。

権限委譲というのも本質的にそんなものだろうと思う。逆の立場になってみればすぐに気づくが、部下が自分のスタイルで必要なものが何かというのに気がつくほど、上司は部下を見ていないし、見ようとしても見れない。従って、上司から委譲された権限で、自分が思い通りにできるはずがないのだ。すべてを任せてしまうと「丸投げ」といわれ、アドバイスすれば「口出し」と言われる。挙句の果てには、任せ方が悪いと言われる始末。

権限は委譲されるものではなく、奪うものである。プロジェクトマネジャーとして活動に必要なものがあれば要求すべきである。権限委譲とは、その要求に対して、「フェア」にこたえることだろうと思う。

◆優先順位のマネジメントはプロジェクトの要

戦略マネジメントとは優先順位付けであるといってもよい。戦略の実行手段であるプロジェクトマネジメントの中では優先順位のマネジメントは特別な意味を持っている。

プロジェクトにおける優先順位はさまざまな要因で決まってくる。一つのプロジェクトの中でいえば、クリティカルパスにある作業は他のタスクに優先される。

プロジェクトのメンバーが専従ではなく、複数のプロジェクトに参画している場合は、プロジェクトの優先順位が問題になるケースがある。例えば、Ａさんが行っている仕事が双方のプロジェクトでクリティカルパスにあり、他人を以って変えがたい仕事である。すると、全体のスケジュールが遅れること、あるいは、それ以降でスケジュールを調整しなくてはならないことを覚悟してその人の仕事の優先順位をつけなくてはならない。その際に問題になるのは、プロジェクト同士の優先順位である。優先順位の高いプロジェクトのＡさんの仕事を優先する。

もう少し経営側に目を向けると、どのプロジェクトを実施するかという問題もある。これも一種の優先順位である。

つまり、あるプロジェクトの中でコンフリクトを解消するためには、いくつかのレベルの優先順位を考えていく必要がある。逆にいえば、いくら一つのプロジェクトの中で最適の意思決定をしたと思っていても、それが結果として、そのプロジェクトの失敗につながるケースは少なくない。

◆優先順位を考えずに失敗しているオフショア開発プロジェクト

最近、このようなパターンをよく耳にするケースはＳＩにおけるオフシェア開発である。人材が確保でいないのでオフショア開発に踏み切る。オフショアという解決策が本当に問題解決になるかどうかという根本的な議論はあると思うが、それはさておいて、オフショア開発を考える際に、まず、他のプロジェクトでとは考えない。決め撃ちである。オフショア開発の意義をどこにおくかにもよるが、リソースマネジメントにおくのであれば、リスクがあまりにも大きいにも関わらず、決め撃ちでオフショア開発をするのは無謀である。事業部なり、部門なりで、抱えているプロジェクトを抱えてプロジェクトを眺めてみて、プロジェクトの優先順位を分析し、リスクをとれるプロジェクトをオフショアとして、原因になったプロジェクトはオフショアのプロジェクトからのリソースをまわすという選択もある。

このような意思決定の根拠になるのは、プロジェクトの優先順位である。

◆「優先順位などつけれない」は本当か

ここで、最近、よく耳にする誤解を指摘しておく。ＳＩ企業の人からよく聞く話だが、

「実施しているプロジェクトはすべて受注したプロジェクトなので、優先順位という考え方はなじまない。すべてのプロジェクトを、納期の早いものから、同じ品質で収めるのが我々の任務である」

一見、正しい。ただし、「リスクがなければ」である。優先順位付けというのはそもそも何のために行うのかをよく理解しておく必要がある。リスクマネジメントである。プロジェクトリスクがある限り、論理的に準備したリソースですべてのプロジェクトに対応できるとしても、現実にできるという保証はない。ましては、３件に１件は納期遅れプロジェクトがあるといわれる業界である。原因はいろいろあるとしても３件に１件のプロジェクトは納期に遅れる。そもそも、上のような理屈など成り立たないのだ。プロジェクトをやめるという選択肢はないとしても、このプロジェクトではお客にないてもらうという選択肢はあるのだ（もちろん、おおっぴらにはいえないので、公式には上のようなコメントになるのだろうが、もし、真剣に言っているとすれば怖いものがある）。

ここで考えておくべきことは、プロジェクトの優先順位をマネジメントすることによって、確実に初期の計画通りに終わらないとならないプロジェクトは確実に終わることができることだ。これが戦略的なプロジェクト実行である。

まず、最初にお断りしておくが、この記事は特定の企業を誹謗するために書いているものではない。考察は個人の意見であるが、考察の元になったトラブルは事実である。

最近、事務所で、佐川急便のトラブルが多くなっている。それも繰り返しが多い。トラブルは２つ。

（１）時間指定した便が指定時間帯に届かない

（２）アマゾンからのメール便が行方不明になる

これが数回繰り返されている。ちなみに、京都のオフィスだけではなく、東京の仕事場でも同じようなことがある。

もう少し、詳しく説明しよう。（１）は説明までもないだろう。今、佐川急便は２時間ごとに時間指定できるようになっているが、時間指定してもその時間帯を超えることが多い。時間指定するときはスケジュールのあるときなので、たいへん、困る。

（２）は少し説明が必要だ。佐川もヤマトもメール便規格で、うちのポストには入らないものがある。ポストの口が小さいという話もあるのだが、郵便ポストというのはどうやら規格がないらしいので、それは傍におく。

佐川もヤマトもメール便については、

・入らない場合には持ち帰り、荷主に戻す

・メール便については、不在配達は入れない、連絡もしない

・ポストに入れるだけで、直接、渡さない

という業務ルールがあるらしい（もちろん、荷主は了解している）。

佐川の配達員はほぼ、このルールを忠実に守っている。ヤマトの配達員は自分の判断で、入らない場合には、呼び出してくれる。不在の場合には、伝票がないので不在配達票は作れないが、手書きメモで配達員まで連絡をくれるように書置きしてくれる。

これはほぼ例外なくやられている。

２つの会社の標準プロセスはほとんど同じものだ。この違いは何によって生じるのか？

コンピテンシーの標準化によるものだと思われる。実はコンピテンシーの標準については意外かもしれないが、佐川急便の方が先駆者である。業界トップを切って、セールスドライバーというコンセプトをつくり、配達員に顧客接点としてに行動を求めた。

ヤマトはそれを追従する形で取り組んでいるのだと思う。そのコンピテンシーの標準化の質の差がでているといえる。

プロセスの標準については組織として一生懸命やるが、コンピテンシーの標準化は個人の問題だと考えている組織が多い。実はプロジェクトマネジメントでもこの問題があちこちで見られる。

ヤマトと佐川の比較に見るように、プロセスの標準化は当たり前。競争はいかに、コンピテンシーの標準化が展開できるかで決まる。

これは、PMstyleの基本的な思想でもある。

原丈人という実業家がいる。原さんは、実業家として、手始めに光ファイバーのベンチャー事業で成功し、その後、ベンチャーキャピタルを創設する。技術型のベンチャー育成投資家としては、ボーランド、ゾーラン社などの育成で名をはせている。欧米で活躍している実業家なので、日本ではあまり著名ではないが、世界トップの育成投資家の一人である。

原さんは慶応大学の法学部の卒業で、ファーストキャリアはなんと、考古学の研究者である。一度、原さんの話を聞いたことがあるが、考古学研究とベンチャー発掘育成は似たところがあるという話をされていて、なるほどと妙に感心してしまった。

そのようなものの見方をする原さんが、雑誌ウェッジに非常に面白い記事を書いていたのが目に留まった。

「ビジネススクールの流儀はもはや人を幸せにできない」

という過激なタイトルだ。原さん自身、スタンフォード大学経営学大学院に学んだ経験がある。この記事の内容もとても面白い。ビジネススクールの流儀の数字絶対主義の経営が米国で主流になったのは、米国がいろいろな人種が住む国であり、その中で、唯一、共通の価値観、言語になりえたのが数字だったからだという指摘をしている。その上で、もはや、そのような価値観に行き詰まりが生じ、新しいパラダイムを探しているというだ。ところが、そのような価値観にも関わらず、日本ではいまだに、数字絶対主義経営がもてはやされているのはどういうわけだという問題提起をしている。

この記事を読んで真っ先に思ったのが、この構図はプロジェクトマネジメントの構図そのものであるということ。プロジェクトマネジメントがダイバーシティを前提にしているというのは、難しい話でも何でもなく、単に現象や価値を数字に置き換え、マネジメントをしているに過ぎない。そして、グローバル企業においては、このような考え方が有効だとしている。

イラク戦争を見ても、過去の歴史をみてもそうだが、ものごとを単純化するというのはアメリカという国の特徴である。しかし、ものごとを単純化すると免疫がなくなり、純粋に体力勝負になる。国でいえば大国、企業で言えばグローバル企業だけが有利な構図だ。

プロジェクトマネジメントで重要だとされていることにリスクマネジメントがある。これは間違いないと思う。しかし、リスクマネジメントの識者の共通の見解として、

　リスクに強い組織を作るには原理原則を重視し、ものごとを単純化しないことが大切

というのがある。米国がよくやるのは

　ものごとを単純化し、単純化された世界で原理原則を大切にする

という、強者が生き延びるためのレトリックである。

米国発のＰＭＢＯＫのリスクマネジメントの原理を思い出してみてほしい。まず計画と称して、現象や価値を数字化する。その上にリスクというのを定義しているのだ。かつ、数字化するから、リスクが明確になるとまで言っているし、そこでさらにリスクを数字化するという点に及んでは驚きである。

まさに、単純化しておいて、リスクを高め、リスクマネジメントは大切だというマッチポンプをやっているわけである。本当にリスクマネジメントが大切であれば、簡単に数字化すべきではない。現象をきちんと扱っていくべきである。

そして、日本には昔から、そのような知恵があった。それが、ビジネススクール流で崩れつつある。

最近、可視化というのは注目されている。これがまた危険な発想だ。可視化をする前に現場を見るべきである。数字化しておいて、現場（現実）を見えなくし、可視化するというなんとも訳の分からない話だ。これもビジネススクールの流儀だ。

奇遇にも同じウェッジにソニーの不調の話が出ていた。「ビジネス書の杜」ブログでも紹介したが、天外伺朗さんの

マネジメント革命

https://mat.lekumo.biz/books/2006/10/post_62e3.html

という本がある。

この本に書かれているのは、まさに、ものごとを単純化しない経営である。

天外伺朗さんは、実は、ソニーでNEWSワークステーションや、AIBOを開発された土井利忠さんのペンネームである。NEWSやAIBOそのものが成功したかどうかというのは微妙なところだが、土井利忠さんが実践されてきたようなマネジメントが本当の意味での現場力を生み、ソニーの反映に寄与したことは間違いないだろう。間違っても、電池の発火原因が数ヶ月経過しても分からないといったことはなかったと思う。

PMBOKを導入した。しかし、何かうまく行かない。しっくりこない。腑に落ちない。

ある人はこれをPMBOKへの理解が足らないという。PMBOKを感じていないという人すらいる。

しかし、本質的に、数字的なマネジメントがそぐわないという組織も少なくないと思う。ソフトウエアの企業で、CMMIやPMBOKを導入して、「社相」が悪くなったなと思う会社がいくつかある。クライアントであれば、だんだん、お付き合いがなくなっている。

ビジネススクールの流儀ではないプロジェクトマネジメントを考えるべきときにあるのではないかと思う。単純化して理解しあうのではなく、コミュニケーションにより相互理解を形成するグローバルマネジメントを考えるべきであろう。

まさに、原さんの言う考古学のように現実を直視し、ありのままに受け入れ、大切に扱っていくようなマネジメントである。