プロジェクトの「補助線」

【補助線】マネジメントできないプロジェクトマネジャーたち

本ブログは移転しました。こちらをご覧ください。

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

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

とし、役割として

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

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

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

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

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

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

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

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

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

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

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

【補助線】プロジェクトは山登りか？

本ブログは移転しています。こちらをご覧ください。

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

「意思決定（Decision Making)」

「デザイン（Design）」

「実行（Do）」

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

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

＜エベレストに登る＞

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

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

・実行＝実際に登る

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

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

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

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

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

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

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

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

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

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

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

　誰が山をつくるのか

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

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

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

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

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

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

【補助線】脱・タコツボプロジェクトマネジメント

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

 

【補助線】栴檀は双葉より芳し

本ブログは移転しました。こちらをご覧ください。

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

【山村さんの質問】

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

僕は違うと思う。

　栴檀は双葉より芳し

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

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

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

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

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

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

【補助線】権限は奪うもの

本ブログは移転しました。こちらをご覧ください。

あるクライアントの話。

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

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

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

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

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

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

【補助線】優先順位マネジメント

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【補助線】コンピテンシーを標準化せよ

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【補助線】考古学のようなプロジェクトマネジメント

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

マネジメント革命

http://people.weblogs.jp/books/2006/10/post_62e3.html

という本がある。

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

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

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

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

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

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

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

【補助線】誰が土俵を作るか

本ブログは移転しました。こちらをご覧ください。

今年は、ＰＭＡＪのＰ２Ｍの改訂委員会に参加している。先日、委員会の合宿があり、ゆっくりと考えをめぐらせる時間が取れた。

ＰＭＢＯＫはいまや２００万人が使う標準である。プロジェクトマネジャーという限定された人が使う標準として、２００万という数はすごい。そして、プロジェクトマネジメントだけではなく、プログラムマネジメント、さらにはポートフォリオマネジメントとだんだんその範囲を拡大している。仮に、ポートフォリオマネジメントがメジャーになっていけば、その利用者の数は一桁上がってもおかしくないだろう。

そんな動きがある中で、ＥＵのプロジェクトマネジメントの標準であるＩＣＢも今年６月に新しいバージョンであるバージョン３が登場し、ＰＭＢＯＫに遅れはとっているものの、いよいよ、本格的にグローバル展開を開始した（グローバルというか、当面のＰＭＩとの戦場はアジア、特に、インドと中国らしい）。

そんな中で、日本では、Ｐ２Ｍという標準がある。５年前にできた標準で、僕も中小企業経営を中心に、結構、使っている。ただ、５年前というとＰＭＢＯＫ２０００と同じ記事であるが、その間の普及を較べると大苦戦をしている。

ＰＭＩのアプローチは大変、システマティックであり、実践的である。プロジェクトマネジメントという現場のマネジメントから入り、だんだん、その範囲を拡大し、プログラムはともかくとして、ついに、ポートフォリオまで出てきた。

今のところ、ポートフォリオマネジメント標準については、ＰＭＢＯＫ１９８７程度だと思う。指したり実体はない。しかし、この分野に出てきたことは極めて重要な意味がある。

ポートフォリオマネジメント標準の本にそれぞれの位置づけについて極めて適切な表現がある。それは

ポートフォリオマネジメント　：　Doing the right work
プログラムマネジメント、プロジェクトマネジメント：Doing work right

という位置づけである。日本語に訳すと

ポートフォリオマネジメント　：　正しい仕事をする
プログラムマネジメント、プロジェクトマネジメント：正しく仕事をする

とでも訳すのだろう。「い」と「く」の一字違い。しかし、この一字が現場と経営の違いになっている。いよいよ、この領域に来た。これはエライことだ。

オペレーションのマネジメントはどこの標準でもよいと思う。所詮、如何に合理的にやるかという話であり、よいものはどんどん取り入れていけばよい。しかし、経営レベルで、欧米の標準を使うというのは、文化を受け入れるということ。人の土俵で相撲を取るようなものだ。必ず負けるだろう。

実際のところ、これらの標準に則って仕事をすると、欧米流の考え方により、日本企業が強みの一つにしてきたきた「スカンクワーク」はすべて葬り去られるだろう。ひいては、「人活経営」も崩れ去れる。

ファイナンスの世界で、日本は欧米から、同じ土俵にあがれと非難される。これはそのとおりだと思う。勝手は土俵を作ってビジネスをしていたのでは、迷惑をこうむるのは顧客だ。しかし、問題は、その土俵を誰が作るかという話である。

一方で、Ｐ２Ｍはというと、最初から、正しい仕事をする＆正しく仕事をするという両方を睨んだ仕事だった。その意味で、非常に先進性があったし、欧米でも評価されている。

しかし、結局、現在のところ、普及できないままである。土俵になっていない。

話は変わるが、１５年くらいまでに、UDL/Iというハードウエア設計言語の標準化プログラムのあるプロジェクトのプロジェクトマネジャーをやったことがある。これも日本発の標準だった。ちょうど、米国の押すＶＤＳＬという標準があり、それに対抗する形でＭＩＴＩが標準を作ろうとした（というか、某企業がＭＩＴＩを担いで標準を作ろうとした）。

標準はできた。技術的先進性は国際的に評価された。しかし、結局、普及しなかった。このプロジェクトでは、日本で半導体ビジネスをやっている企業が３０社近く集まり、コミッティをつくり、進めていった。この中には外資系の会社もあった。しかし、結局、活動の半ばで、既に、ＶＨＤＬの採用に踏み切る企業もあった。その企業におけるグローバル展開のためである。

Ｐ２Ｍはグローバルな土俵になるのだろうか？

そんなことを考えさせられた１日だった。どれだけ戦力になれるか分からないが、とにかくがんばりたい。

ちなみに、弊社のプログラムマネジメントの標準はＰ２ＭとＰＭＩを折衷し、独自の考えで纏め上げたものである。

プログラムマネジメント～複数のプロジェクトを同時に成功させる方法とそのポイント

　http://www.pmstyle.biz/smn/mpm.htm

【補助線】仕込みポイントの勘違い

本ブログは移転しました。こちらをご覧ください。

タウンミーティングで仕込みが問題になっている。

タウンミーティングとはアメリカが「新大陸」であったころに、最初の入植地であるニューイングランドで行われた市民主導の統治方法である。タウンミーティングとは、市民が地域の問題を議論し投票するために集まるタウン集会をさす。

この統治方法の特徴は、意思決定の対象を市民自身が決めることと、投票者と市民の決断との間に仲介するものがなかったことである。つまり、直接民主制である。当然、このような形態では入植民が多くなると意思決定ができなくなるので、間接民主制に移らざるを得ない。アメリカの場合だと、連邦や連邦憲法による統治に移っていくが、タウンミーティングそのものは根強く残っているという。

この方法に注目したビジネスマンがいた。ＧＥのジャック・ウェルチである。ジャックウェルチはワークアウトプログラムの中にタウンミーティングを位置づけた。ワークアウトにおけるタウンミーティングはニューイングランドのそれとは若干異なる。まず、タウンミーティングメンバーが問題に対する議論をし、結論を出す。その上で、統治者（イシューに対するガバナンスを持つ人）をタウンミーティングに呼び、その場でメンバーの結論に対する意思決定をする。受け入れる場合もあれば、受け入れない場合もある。この仕組みで、通常であれば２～３ヶ月かかる意思決定が１週間程度で終わる。

これはたいへんな慧眼だと思う。タウンミーティングの本質は直接民主制にあり、それは、経営組織でいえば自律組織による統治を意味する。まさに、仕組みを使う人が仕組みを改善していく仕組みとしてはぴったりである。

日本でもこれに似た仕組みはあった。分野は狭いが、ＱＣサークルである。

さて、今回の問題を見ていると、いろいろ批判もあるが、日本では今の時点でタウンミーティングなるものをやろうとするとこういう方法しかなかったように思う。三権分立の理屈の上では、タウンミーティングは行政の仕組みとして行っているわけで、議員とは別の人たちを立てて行う。問題は仕込をどこでやるかだ。質問者に仕込みをやるのは間違いだろう。むしろ、タウンミーティングを仕切る人に仕込みをすべきで、その仕切りを国の行政機関がやっていることそのものが間違いではないかと思う。要するに、ガバナンスの問題である。

これと同じ構図はマネジメントの中にもよくある。コンサルタントとしてある企業でプロジェクトワークアウトを行ったときに、まったく同じことに出会ったことがある。上位マネジャー（統治者）がメンバーに仕込みをして、議論にならなかったことがある。組織のガバナンスとして仕込むのはかまわない。しかし、仕込みは人ではなく、文化である。

要するに民主主義の仕組みなのだ。組織のマネジメントにおいても民主化がされていないところに、プロジェクトマネジメントのような民主化を「前提」にした仕組みを持ち込んでいるところに、ガバナンスの混乱が発生している。

上に述べたように、米国における民主主義は直接民主主義から間接民主主義に変化し、その民主主義をベースにしてマネジメントが行われている。日本人が民主主義を解さないのは、直接民主主義の経験がないからではないかと思う。これが歴史なのだろう。

マネジメントの仕組みを考えるときには、このあたりをよく考えておく必要がある。