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

【補助線】イニシエーション

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

ＰＭＢＯＫの立ち上げプロセスは、英語では「Initiation」である。イニシエーションは通過儀礼という意味が一般的である。通過儀礼とは、出生、成人、結婚、死などの人間が成長していく過程で、次なる段階の期間に新しい意味を付与する儀礼のことだ。

日本で一般的にイニシエーションという言葉が認知されたのは、オーム真理教が話題になったときだと思う。彼らはキリスト教徒同じく入信の儀式をイニシエーションと言っていた。オーム事件の後で、そのイメージの悪ささからか、イニシエーションに「洗脳」という言葉があてられるようになってきて、あまりよくないイメージがある。

しかし、宗教の中でもイニシエーションというのは重要な意味を持っている。キリスト教では、神と人間とを仲介し、神の恵みを人間に与える秘跡（あるいは、洗礼）と呼ばれる儀式があるが、これがイニシエーションである。

神戸大学の金井壽宏先生は、これに加えて、

　そこから始まる

という意味を持つと指摘し、新卒社員が入社時の「リアリティ・ショック」を乗り越えるには（イニシエーション）が必要だと述べている。

米国の産業組織心理学者D・フェルドマンは、

・「職場集団への加入儀礼（グループ・イニシエーション）」
・「職場の仕事上の課題面での加入儀礼（タスク・イニシエーション）」

という二つのイニシエーションがあると指摘している。これは、導入研修などのOff JTの話ではなく、配属先の職場になじむための二つの課題である。

また、慶応大学の榊原清則先生は、フェルドマンの説をさらに具体的にし、

会社に入ったときに，個人は組織に適応し，その組織文化を内面化しようとする。その際に個人は２種類のイニシエーションに直面する。第１は，新しい世界での仕事に慣れ，課題がうまくこなせるかどうかという「課題」イニシエーションである。第２は，その世界で出会う新しい人々と文化にうまく溶け込めるかどうかという「人・文化」イニシエーションである。これらのイニシエーションを通過することで，個人は組織に適応し社会化していく。

と指摘している。

このようにイニシエーションというのは極めて意味の深い言葉であり、儀式である。

これをＰＭＢＯＫの日本語版では「立ち上げ」という言葉で片付けている。これでは、プロジェクトを巡るメンバーの不適合や不全が起こっても全く不思議ではない。ＰＭＢＯＫの訳語の適切さをめぐってはいろいろな議論があるが、すべての訳語の中で、これが一番ひどいのではないかと僕は思っている。

スコープは訳をあきらめて、スコープのままで、プロジェクトマネジメントを行う組織の中では普通に使われるようになってきた。その例に学び、イニシエーションをカタカナ英語に変えてほしい。

【補助線】続・ＰＭＯリーダーに求められるリーダーシップ

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

前回、ＰＭＯはプロジェクトに対してサーバントリーダーシップを発揮すべきだということを書いたところ、プロジェクト（マネジャー）の召使になれというならまだわかるが、理由が分からいし、イメージが持ちにくいという意見を頂いた。また、別の方からはそれはリーダーシップというよりもプロパガンダではないかという意見も頂いた。さらに、別の方からは、そんなユルイことを言っていないで、強権的なリーダーシップを持つべきではないかという意見を頂いた。まあ、記事としてそれなりに響いたということだろう。

プロパガンダという話はある程度、当たっている部分もあるのだが、本質的には違うと思うので、今回、もう一度、この問題を考えてみたい。

◆サーバントリーダーシップが必要な背景（１）

まず、この話の背景はどこにあるのだろうか？この点から考えてみたい。

この話の背景は２つあると思っている。ひとつは今年の５月７日のコラムに書いた話であるが、ＰＭＯはその組織のプロジェクトマネジメントのオーナーシップを持つということだ。つまり、プロジェクトをどのように行うかということは事業組織の戦略の問題だとしても、そのプロジェクトのマネジメントをどのように行うべきであるかについては、ＰＭＯは決めるべき立場にいる。

実は、５月７日の記事についても、その後、お会いした人と議論したり、メールでご意見を戴いたりしたが、プロジェクトマネジメントのオーナーシップを持つことと、プロジェクトのオーナーシップを持つことは違う次元の話であることを混乱している人が多い。

プロジェクトのオーナーシップを持つことは、プロジェクトの作業をどのように進めるか、顧客にどのようなスタンスで対応するかといったようなことであり、成果物を生み出すことについて、責任と権限を持つということである。これに対して、プロジェクトマネジメントについてオーナーシップを持つというのは、プロジェクトが責任と権限が果たせるようにするために行う管理（マネジメント）に対して責任と権限を持つということである。これは全く異なるものである。

◆サーバントリーダーシップが必要な背景（２）

もう一つの背景は、プロジェクトマネジメントの導入はマネジメントの変革であるということだ。変革であるので、基本的にはＰＭＯがああしろ、こうしろと言える類の問題ではなく、どうすればよいかを当事者が一番よく知っている。知らないのであれば、考えるべき問題である。

ＰＭＯがオーナーシップを持ち、強権的にプロジェクトマネジメントのやり方を決めていくというのであればわかりやすいのだが、ＰＭＯとしては

・オーナーシップを持つ
・現場（プロジェクトマネジャー）の意見を重視する

という二律背反を実現しなくてはならない。そこで、ポイントになるのが、「変革」であるということだ。

セミナー「ＰＭＯによるプロジェクトマネジメントの定着化のポイントと事例」
http://www.pmstyle.biz/smn/pmo_startup.htm

でも基本コンセプトしているが、プロジェクトマネジメントの定着化は変革マネジメントである。したがって、ＰＭＯが細かなやり方を指示していくことは適切とはいえばい。むしろ、ＰＭＯはプロジェクトマネジメントの方向性、方針、取組のスタンス、導入後のビジョンなどを明確に示し、その範囲で各プロジェクトでプロジェクトマネジャーが工夫したやり方を考える。ＰＭＯはプロジェクトマネジャーが実際にそれを実行できるように支援をしていく。そして、うまくいったやり方（プラクティス）を組織に吸い上げていき、調整をしながら、最高のやり方（ベストプラクティス）を作り上げていくことが望まれる。

◆ＰＭＯがすべき支援はサーバントリーダーシップを以て可能となる

ただし、プロジェクトマネジャーに一から考えよというのは現実的とはいえない。そこで、プロジェクトマネジャーが「ＰＭＯが示したビジョンに対して、マネジメントのやり方を工夫することを支援する」という位置づけで、標準を提供していくことはある意味で不可欠である。

すると、その場合の標準は守らなくてはならないルールという位置づけではなくなる。むしろ、たたき台であり、また、プロジェクトマネジャーたちのこういう風にやっていこうという考えを集約したものになるのだ。その意味で、自己決定であり、プロジェクトマネジメントの導入はスムーズに進んでいくだろう。

このように、決して表にでるわけではなく、といって、裏方だからといって意思決定を逃げるわけでもない。このようなやり方をサーバントリーダーシップという。少しは理解が進んできただろうか？

さて、こういう話をすると違和感がある人がいると思う。そう、組織としてはそんなつもりでプロジェクトマネジメントを入れているわけではない、組織として管理したいのでプロジェクトマネジメントを入れているんだ。プロジェクトマネジャーがレポートをしないというルールをきめたらどうするんだという意見が聞こえてきそうである。

【補助線】常に計画は常に守られるべきか？

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

ＰＭＢＯＫを知ると

　計画は常に守られるべき

という思ってしまうが、これは錯覚である。計画が常に正しいとは限らない。ゆえに、正しい行動をするためには時として計画を無視する必要がある。

この錯覚は根が深い。一つは計画という言霊の問題だ。内部統制とか、コンプライアンスとかいうよりも、言霊の方が強烈だと思う。計画とか、ルールとかいうと、守らなくてはならないものという言霊ができてしまっている。

もう一つは、少なくともプロジェクトにおいては、計画は目安に過ぎない。ＰＭＢＯＫはここの扱い方がよくできていて、段階的詳細化により、計画は可能になった時点で行えばよいとしている。そして、さらに、「リスク計画」なる計画を持ち込み、計画に対して予想外の状況も「計画をしておけ」と言っている。そして、段階的詳細化にしろ、リスクマネジメントにしろ、変更管理をきちんとして、常に、計画と行動を合わせるべきだといっている。

これで完璧なのように思えるかもしれないが、それは錯覚だ。ＰＭＢＯＫは計画は段階的詳細化も含めて常に作れるという前提に立っている。しかし現実にはリスク計画など、完璧なものが作れることはないだろう。

ＰＭＢＯＫではここに組織成熟度なるものを持ち込んできて、組織としてリスクマネジメントに対する知見が蓄積されていくことにより、完璧なリスク計画が作れると言っているが、これはレトリックである。完璧な計画というのがありうるとすれば、確かにそうなのだが、完璧な計画などあり得ないという考え方もある。その前提に立つとＰＭＢＯＫのロジックは崩れ去る。

現実には完璧な計画などあり得ない。

それゆえに、計画の実行が大切になってくる。つまり、計画の実行の際に、一人一人のメンバーが計画にないことまでやっていかないとプロジェクト成功はおぼつかない。

このためにはメンバーのスキルやマインドが大切になってくる。これがチームビルディングの議論であり、また、コミュニケーションやヒューマンスキルの議論である。

また、リスク計画が完璧ではないとすれば、計画を無視する必要も出てくる。その時の状況を想定内だと言えなくなるために、担当者が独自の判断を迫られるのだ。

このように議論していくと難しいのだが、もっと単純にいえば、以下の命題に対して、どういう答えができるかということだ。

　計画通りにやっていて、もし、結果が好ましくない場合には、誰の責任か

計画を作るというのは、責任を明確にするということに他ならない。どうも、あまり、細かな計画を作りたがらない背景には責任を明確にしたがらない文化が見え隠れするというのは考えすぎだろうか？

【補助線】リスクマインド

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

◆リスクマインド

リスクマネジメントの環境整備が進んでいる。たとえば、ＩＴ系だと日本プロジェクトマネジメント協会（ＰＭＡＪ）が標準的なリスクマネジメントマニュアルの頒布をはじめているし、企業独自でリスクチェックリストを準備している企業も増えている。ＰＭＯのメインの役割がリスクのチェックだという企業も少なくない。

さて、そんな中で考えておきたいことがある。それは、リスクマネジメントというのは統制では実現できにくということだ。統制というのは確定的なことがらに対して威力を発揮するものである。

◆リスクマインドがあって初めてリスクマネジメントが活きる

一例としてこんなことを考えてみよう

（１）スケジュールが遅れそうであれば、できるだけ早く申し出てくれ
（２）スケジュール遅れが、各アクティビティに対してベースラインの１０％を超えたら、その日のうちに報告してくれ

いずれも、プロジェクトマネジャーがメンバーに対して出す指示としてはありそうな話だ。ところが、（２）は実効的であり、統制しているといえるのに対して、（１）はほとんど実効力がなく、統制しているとは言い難い。聞き流して終わりだろう。リスクマネジメントというのは本来は（１）のようなことをやりたいのだ。

もし、メンバーがこのスケジュールが遅れたら、仲間に迷惑をかけるとか、顧客に迷惑をかけるといった「危機感」を持っていたとしたらどうだろうか？まずいことが起こったらちょっとでも早く相談しようと考えるだろう（もっともプロジェクトマネジャーの対応の仕方にもよるが）。

これがリスクマインドである。メンバーやステークホルダがリスクマインドを持っていなければ、リスクマネジメントは機能しない。

◆リスクマインドの診断

さて、では、あなたのプロジェクトリスクマインドの診断をしてみよう。

プロジェクトマネジャーの方は今、あなたがプロジェクトマネジメントを担当しているプロジェクトを思い浮かべて欲しい。ＰＭＯの方は、あなたの組織の代表的なプロジェクトを思い浮かべてみて欲しい。

そして、「あなたのプロジェクトにどのくらい当てはまるか？」について、以下の点数をつけていただきたい。

まったく当てはまらない　１点
しばしばあてはまる　２点
かなりあてはまる　３点

（１）計画を無視して作業をすることはまずない
（２）直面する状況、課題はこのプロジェクトでも他のプロジェクトでも起こっているものだ
（３）作業に必要な情報の全てはメンバーの手に入りにくい
（４）プロジェクトマネジャーやメンバーは業務遂行にあたり、特定の方法の遵守を求められる
（５）納期、予算、収益において厳しい計画が課せられる
（６）メンバーは計画の達成のためにしばしば近道となる案を採ろうとする
（７）プロジェクトにミスの報告を躊躇させる雰囲気がある
（８）リスク事象が発生した際に、メンバーに対策を実行する権限を与えられていない
（９）リスク事象に対処するのに必要なスキルや専門知識に欠けるメンバーが多い
（１０）問題の討議の中で、議論の前提に疑問を投げかける発言がメンバーからでくることはほどんどない
（１１）ミスをすると責められる
（１２）他のメンバーに助けを求めにくい雰囲気がある

１２の質問の合計点数はいくらになっただろうか？

［１］１３点以下の場合
あなたのプロジェクトは高いリスクマインドがある。リスク計画を十分に立てれば、リスクをうまくコントロールすることができる

［２］１４～２３点の場合
あなたのプロジェクトはリスクマインドが十分とはいえず、リスク計画を作っていても、リスク事象の発生により、致命的なダメージを負う可能性がある。リスクトラッキングをしつこく実行する必要がある

［３］２４点以上の場合
リスク計画を作ってもあまり効果がない。リスクマネジメント以前に、リスクマインドの向上策をとるべき。

【補助線】ＰＭＯリーダーに求められるリーダーシップ

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

◆ＰＭＯリーダーの定義

PMstyleでは、数年前から「ＰＭＯリーダー」という言葉を使っている。ご承知のように、昨年からはＰＭＯリーダー養成講座という連続講座を始めた。ＰＭＯブームと相俟って、多くの方に受講して頂いているが、以前として、ＰＭＯは本当にリーダーシップを持つ必要があるのかという質問をいまだに受ける。

プロジェクトマネジメントの導入、実施、成熟という一連のミッションに対してリーダーシップを発揮するのがＰＭＯリーダー

というのが答えなのだが、なかなか、理解していただけない。

◆ＰＭＯリーダーのリーダーシップ

プロジェクトマネジャー、あるいは組織とＰＭＯの関係からすると、ＰＭＯが決めたようにプロジェクトマネジメントを行うことを命令することはもちろん、ＰＭＯがプロジェクトの中に入って率先してプロジェクトマネジメントをする、あるいはするように仕向けて行くことは、ＰＭＯとしての本務の範囲を逸脱していると考えている人が多いからだ。

実は、このようなリーダーシップをＰＭＯに求めているわけではない。ＰＭＯリーダーが発揮すべきリーダーシップはリーダーシップである。サーバントリーダーシップはリーダーとしてフォロワーに奉仕することを基本とするリーダーシップである。ただし、サーバントになるわけではない。

◆ＰＭＯの仕事はプロジェクトに奉仕すること？！

仕事がら、ＰＭＯの人との付き合いは多いが、ＰＭＯがプロジェクトに奉仕すべきだという人は多い（支援という言い方をする人が多い）。しかし、奉仕といった場合に、微妙な、しかし、決定的な温度差がある。プロジェクトマネジャーやプロジェクトが困っていればとりあえず支援しなくてはならないと思っているＰＭＯもいれば、もう少し、支援の目的を明確にして支援しようとしているＰＭＯもいる。

トラブルプロジェクトのサポートという同じ活動を行う２つのＰＭＯを考えてみよう。ひとつのＰＭＯは、プロジェクトでトラブルが発生したときに、経緯はともかくサポートをし、そのプロジェクトを予定通りに終わらせることに全力を尽くして支援する。

これに対して、自分たちが定着させようとしているプロジェクトマネジメントの進め方をしているプロジェクトに対してのみ、トラブルの場合にサポートするＰＭＯがある。こちらはプロジェクトに奉仕するのではなく、「プロジェクトマネジメントに奉仕」しているのだ。

◆ＰＭＯの影響力

みなさんのＰＭＯはどちらのタイプだろうか？ＰＭＯにリーダーシップはいらないと思っているＰＭＯは前者であることが多い。この場合、如何に尽くせるかというのが問題になる。ちょっと、言葉が過ぎるかもしれないが、このタイプのＰＭＯはなくなってもその組織のプロジェクトマネジメントへの影響は小さい。

ところが後者のＰＭＯの場合、仮にそのＰＭＯがなくなれば、組織のプロジェクトマネジメントは崩壊してしまう可能性すらある。なぜか？

仮に、ＰＭＯのミッションが導入、実施、成熟だとしたとすれば、後者のＰＭＯは自ら（あるいは組織としての）ミッションを達成するために支援をしている。これに対して前者のＰＭＯはお助けＰＭＯである。

あえていえば、前者のＰＭＯは、組織としてプロジェクトをきちんと終わらせるというミッションがあって動いているといえなくもないが、このミッションはどちらかというとプロジェクトスポンサーのミッションである。

◆ＰＭＯリーダーのリーダーシップはサーバント型リーダーシップ

話を元に戻そう。ＰＭＯリーダーは

プロジェクトマネジメントの導入、実施、成熟というミッションに達成のために、プロジェクトやプロジェクトマネジャーの支援を行う

人である。そして、このような奉仕活動はリーダーシップに他ならないことをよく認識しておく必要がある。

リーダーシップには「俺についてこい」型だけではなく、このようにリーダーが考えるミッションを達成するためにフォロワーに奉仕するというタイプのリーダーシップもある。一般的にはこのようなリーダーシップはサーバントリーダーシップと呼ばれる。

サーバントリーダーシップの詳細は、ＰＭ養成マガジンの「戦略ノート」に２００２年に書いているので、こちらを参考にして頂きたい。

リーダーシップ考（４）～サーバントリーダーシップ
http://pmstyle.jp/honpo/note/note25.htm

【補助線】逆ピラミッドのプロジェクトマネジメント

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

◆資生堂のビューティーコンサルタント

僕がいつも泊っている汐留のホテルは、資生堂から近いこともあって、資生堂のビューティコンサルタント（ＢＣ）が研修などので本社を訪れる際の宿泊先になっているようだ。このホテルではニューヨークスタイルの朝食のサービスがあるのだが、同じような雰囲気の服装の女性　数十名と遭遇すると圧倒されてしまう（笑）。

資生堂の中では、ＢＣは最前線で顧客と接する。単に化粧品を売るだけではなく、文字通り、「美」についてのコンサルティングをする存在である。資生堂の興味深いのは、池田守男前社長の時代に、逆ピラミッド型組織というのを社長が自ら提唱し、その実現に力を尽くしていることだ。

◆資生堂の逆ピラミッドは店頭起点

資生堂の逆ピラミッドは

お客様＞店頭＞ＢＣ＞営業担当＞支社長＞本社／研究所／工場＞社長

であり、「店頭起点」という、企業としての活動はすべて店頭に集約されるというコンセプトを実現すべく、組織上、上の立場の人が下に対して献身的に奉仕し、彼らの活動をスムーズに進めるという考え方である。

池田社長がこのような感がけかを持ち出したのは、経営改革が必要だったためで、店頭起点を実現することによって経営を変えようとしたわけだ。

このような考え方はそんなに特別なものではない。軍隊のように平時は極めてピラミッド型の組織ですら、いざ、戦争となると如何に現場が作戦を実行できるかという視点から組織の機能が組み替えられ、作戦を実行するために上位組織が前線に尽くしていくのが普通である。

ビジネスの組織も改革や革新にような非常時には現場を中心にした動きが求められるわけで、資生堂のやり方はその意味で合理的だと言える。

◆逆ピラミッドの２つのポイント

このやり方には２つのポイントがある。まず、一つ目はビジョン（あるいは組織のミッション）が明確になっていることである。これがない限り、絶対にこんなやり方はできない。このやり方はある意味で現場にすべてを託すやり方であり、上位組織が自分たちはどこを目指したいということが明確になっている必要がある。

ここがなければ、多くのＩＴ企業にみられるように単なる現場の暴走になってしまう。

次に、そのミッションの達成をすべて現場にゆだねてしまうことだ。ただし、一般的にいえば、上位組織が持っている権限をすべて現場に委譲することはできないし、無理にやるのは統制上の問題もある。何を委譲しているかというと、ミッションを達成するための方法である。その方法を現場に委譲した上で彼らに尽くし、ミッション達成を実現していく。この中には、当然、現場でもできないこともあるが、そのような意志決定もあくまでも現場の動きに合わせて行っていく。

口でいうほどやさしいことではないが、このようなやり方をすれば、ミッションの達成のためには何をすべきかを一番よく知っている現場に主導権を委ねながらも、組織のリーダーとしてリーダーシップを発揮しながら進めていくことができる。これが逆ピラミッド型組織の基本的な発想である。

◆逆ピラミッドのプロジェクトマネジメント

この逆ピラミッド組織こそ、組織のプロジェクトマネジメントに必要な組織ではないだろうか？

プロジェクトマネジャーはプロジェクトミッションをプロジェクト目標に落とし込み、メンバーにその達成をゆだねる。その際には、メンバーに奉仕する。もちろん、メンバーは顧客に対して奉仕する。プロジェクトスポンサーはプロジェクトミッションをプロジェクトマネジャーにきちんと伝えた上で、プロジェクトマネジャーに奉仕する。シニアマネジャーはプロジェクトスポンサーに奉仕する。エグゼクティブはミッションを決めるとともに、シニアマネジャーに奉仕する。このような逆ピラミッドの関係があって初めて、プロジェクトによって成果をあげることができるのでないだろうか？

今、なぜ、うまくいかないかということを考えてみると、ピラミッド構造になっているために、顧客とメンバーの間の成果に対する合意が、組織の中で減退してしまうのだ。

つまり、ちょっと頑張ればできるようなことに対して、組織は収益性だとかリスクだとかいろいろな理屈をつけて、梯子を外して言うからできない。そんなことはしていないという人も多いと思うので、もっとはっきり言っておくが不作為という梯子のはずし方をしている。

月並みなことばで言えば、プロジェクトマネジャーが前線で苦労しているのに、上位組織は内向きで対応すべきかどうかの意思決定をしている。組織の論理を優先すれば、プロジェクトが始ってから出てくる顧客の要求など対応するいわれのないものばかりだそう。

これがすべてだ。これをひっくり返すための逆ピラミッドは有効な方法である。プロジェクト起点の逆ピラミッドのプロジェクトマネジメントを組立てよう！

逆ピラミッド型組織

◆資生堂のビューティーコンサルタント

僕がいつも泊っている汐留のホテルは、資生堂から近いこともあって、資生堂のビューティコンサルタント（ＢＣ）が研修などので本社を訪れる際の宿泊先になっているようだ。このホテルではニューヨークスタイルの朝食のサービスがあるのだが、同じような雰囲気の服装の女性　数十名と遭遇すると圧倒されてしまう（笑）。

資生堂の中では、ＢＣは最前線で顧客と接する。単に化粧品を売るだけではなく、文字通り、「美」についてのコンサルティングをする存在である。資生堂の興味深いのは、池田守男前社長の時代に、逆ピラミッド型組織というのを社長が自ら提唱し、その実現に力を尽くしていることだ。

◆資生堂の逆ピラミッドは店頭起点

資生堂の逆ピラミッドは

お客様＞店頭＞ＢＣ＞営業担当＞支社長＞本社／研究所／工場＞社長

であり、「店頭起点」という、企業としての活動はすべて店頭に集約されるというコンセプトを実現すべく、組織上、上の立場の人が下に対して献身的に奉仕し、彼らの活動をスムーズに進めるという考え方である。

池田社長がこのような感がけかを持ち出したのは、経営改革が必要だったためで、店頭起点を実現することによって経営を変えようとしたわけだ。

このような考え方はそんなに特別なものではない。軍隊のように平時は極めてピラミッド型の組織ですら、いざ、戦争となると如何に現場が作戦を実行できるかという視点から組織の機能が組み替えられ、作戦を実行するために上位組織が前線に尽くしていくのが普通である。

ビジネスの組織も改革や革新にような非常時には現場を中心にした動きが求められるわけで、資生堂のやり方はその意味で合理的だと言える。

◆逆ピラミッドの２つのポイント

このやり方には２つのポイントがある。まず、一つ目はビジョン（あるいは組織のミッション）が明確になっていることである。これがない限り、絶対にこんなやり方はできない。このやり方はある意味で現場にすべてを託すやり方であり、上位組織が自分たちはどこを目指したいということが明確になっている必要がある。

ここがなければ、多くのＩＴ企業にみられるように単なる現場の暴走になってしまう。

次に、そのミッションの達成をすべて現場にゆだねてしまうことだ。ただし、一般的にいえば、上位組織が持っている権限をすべて現場に委譲することはできないし、無理にやるのは統制上の問題もある。何を委譲しているかというと、ミッションを達成するための方法である。その方法を現場に委譲した上で彼らに尽くし、ミッション達成を実現していく。この中には、当然、現場でもできないこともあるが、そのような意志決定もあくまでも現場の動きに合わせて行っていく。

口でいうほどやさしいことではないが、このようなやり方をすれば、ミッションの達成のためには何をすべきかを一番よく知っている現場に主導権を委ねながらも、組織のリーダーとしてリーダーシップを発揮しながら進めていくことができる。これが逆ピラミッド型組織の基本的な発想である。

◆逆ピラミッドのプロジェクトマネジメント

この逆ピラミッド組織こそ、組織のプロジェクトマネジメントに必要な組織ではないだろうか？

プロジェクトマネジャーはプロジェクトミッションをプロジェクト目標に落とし込み、メンバーにその達成をゆだねる。その際には、メンバーに奉仕する。もちろん、メンバーは顧客に対して奉仕する。プロジェクトスポンサーはプロジェクトミッションをプロジェクトマネジャーにきちんと伝えた上で、プロジェクトマネジャーに奉仕する。シニアマネジャーはプロジェクトスポンサーに奉仕する。エグゼクティブはミッションを決めるとともに、シニアマネジャーに奉仕する。このような逆ピラミッドの関係があって初めて、プロジェクトによって成果をあげることができるのでないだろうか？

今、なぜ、うまくいかないかということを考えてみると、ピラミッド構造になっているために、顧客とメンバーの間の成果に対する合意が、組織の中で減退してしまうのだ。

つまり、ちょっと頑張ればできるようなことに対して、組織は収益性だとかリスクだとかいろいろな理屈をつけて、梯子を外して言うからできない。そんなことはしていないという人も多いと思うので、もっとはっきり言っておくが不作為という梯子のはずし方をしている。

月並みなことばで言えば、プロジェクトマネジャーが前線で苦労しているのに、上位組織は内向きで対応すべきかどうかの意思決定をしている。組織の論理を優先すれば、プロジェクトが始ってから出てくる顧客の要求など対応するいわれのないものばかりだそう。

これがすべてだ。これをひっくり返すための逆ピラミッドは有効な方法である。プロジェクト起点の逆ピラミッドのプロジェクトマネジメントを組立てよう！

【補助線】ＰＭＢＯＫではプロジェクトＸはできない

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

仮説「プロジェクトＸにはプロジェクトマネジメントはないが、スポンサーシップがあった」

メルマガで少し、触れたが、日経ＢＰ社の谷島さんにプライベートセミナーの講演をして頂いた後でお話をしているときにこんな話になった。ＰＭ業界では、「プロジェクトＸになりたくなければ、プロジェクトマネジメントをやれ」という話をみんながしていたが、谷島さんの話によると、この話はプロシードの西野さんが言い出して、谷島さんがこれを記事で書いたので、あっという間に広まってしまったのだという。

　プロジェクトＸになりたくなければプロジェクトマネジメントをやれ

という指摘は極めて正しいと思う。

ただし、プロジェクトＸというのは本当に悪いのか？言い出した人たちは、プロジェクトＸに取り上げられたプロジェクトなど、苦境の連続で、最後に何とか成功したのは、偶然にすぎないという思いがあるのだと思う。

実は、メルマガをはじめて２～３年目くらいに１０回くらいメルマガの読者とのコミュニティセミナーを行ったが、このときに、好川はこの指摘をしていた。

プロジェクトＸになりたくなければプロジェクトマネジメントをやれというが、ＰＭＢＯＫプロジェクトマネジメントをやるとプロジェクトＸになれないというべきではないか

と何回か言っている。その頃は、何となくそのように感じていて、コミュニティセミナーの気楽さからそのような発言をしていたのだが、今、改めて考えてみると、その時に思っていたものが何だったかよくわかる。

プロジェクトＸを支える一貫したマネジメントはプロジェクトスポンサーシップである。もちろん、スポンサーシップとは付随的なものである。スポンサーシップだけでプロジェクトが進められるわけではない。また、ＰＭＢＯＫにはＰＭＢＯＫのプロセスを前提にしたスポンサーシップがある。

しかし、プロジェクトＸのスポンサーシップは明らかにそのようなスポンサーシップとは異質なものである。ＰＭＢＯＫの世界のスポンサーシップはいかにすれば失敗プロジェクトをなくすことができるかという考え方で組み立てられている。失敗プロジェクトをなくすというのは、「如何に失敗しないプロジェクト目標を掲げるか」という意味である。プロジェクト要求（Project requirement）からすればそれは、１００％の要求実現にならなくてもかまわないという考え方が背景にある。ビジネスプロジェクトというのはそういうものだ。

これに対して、プロジェクトＸのスポンサーシップは、如何にプロジェクト要求を１００％実現するかという考え方で組み立てられている。プロジェクトＸで取り上げらている多くのプロジェクトは、ＰＭＢＯＫのような卓越したマネジメント手法ではなく、卓越したスポンサーシップでプロジェクト要求を完全実現しているのだ。

そして、これはＰＭＢＯＫ的なプロジェクトマネジメントでは正しい考えとはいえない。上に述べたようにあくまでも失敗しないような目標やスコープの設定をすることこそが正しいのだ。

ゆえに、ＰＭＢＯＫではプロジェクトＸは実現できない。

【補助線】カップヌードルの開発で「ラーメンの父」安藤百福の果した役割

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

◆８２億食の奇跡

今年のお正月早々に即席ラーメンの生みの親である日清食品創業者会長である安藤百福氏が９６歳で人生の幕を閉じたというニュースが流れた。安藤氏は１９４８年に日清食品の前身、中交総社を設立。即席ラーメン第一号である「チキンラーメン」を５８年に発売、爆発的なヒットをさせた。その後、即席ラーメンは市場が厳しくなり、チキンラーメンの地位も安泰ではなくなる。併せて、チキンラーメンを主力商品としていた日清食品の経営も苦しくなる。安藤は海外展開を試みるが、器の問題で躓き、失敗する。

この状況で、安藤が次に目論んだのは、「丼」のない諸外国でのラーメンの普及だった。プロジェクトＸ「８２億食の奇跡」はここから始まるカップヌードルの開発ストーリーを描いたものである。

◆容器と麺の開発

当時社長だった安藤氏は、ラーメンではなく食品化学の知識を活かした仕事をしたいと言って入社し、社内で問題児扱いをされていた大野一夫研究員（３２歳）と新入社員だった佐々木雅弘氏（２３歳）に白羽の矢を立てた。安藤に課題を与えられた大野は、容器の問題から着手する。さまざまな容器を考案するが、いずれも安藤の厳しい意見の前にボツ。ある日、出社すると安藤からのヒントが机に置いてあった。大野はそのヒントで、「ラーメンを食べるための器」という既成概念から脱却でき、安藤の満足するものを作りあげる。
麺でも同じような試行錯誤を繰り返す。麺ではいかに中まで火が通るように揚げるかというのが最大の課題になった。ここでも、安藤の「天ぷらはどうやって揚げるか知っているか」という一言がヒントになり、なんとか、クリアする。

◆海老と高級感

次は具だ。大野は大学の時に学んだフリーズドライの知識を活用し、この課題をクリアしたかに見えたが、またしても安藤から「高級感を出すためにどうしても赤い海老」がほしいという難題を吹っ掛けられた。この問題に絡んだのがプライシングの問題。安藤はどうしても１００円という価格に固執した（チキンラーメンは３０円）。また、どうしても「赤い」海老が見つからず、諦めかけ、海老を入れずに値段を下げることを考えていた大野に対して、「世界中にいる海老の種類の中で、君はどれだけ試したのか。買いかぶりすぎていた」と挑発し、大野に粘り強い挑戦をさせる。大野は四六時中海老のことを考えていた大野は偶然入ったバーで注文したシュリンプカクテルに使われていたインド洋でとれるプーラハンという海老に遭遇する。そして、見事に赤い海老を具にすることに成功し、高級感を実現した。

◆販売での苦戦と銀座歩行者天国キャンペーン

営業の結果が好ましくないことでみんながあきらめ感が漂ってきたときに、安藤は営業の秋山是久に「忙しい現代人に時間を売る」というコンセプトに立ち返り、その対価として１００円をぶらすなと激励する。

販路にも試行錯誤したが、あるとき、大野の提案で賭けにでる。銀座の歩行者天国でカップヌードルを売って、コンセプトを広めようとする。このときに、安藤は陣頭指揮をとって、自ら販売員になり、熱く思いを語る。銀座キャンペーンも徐々に効果を奏し、ついには長蛇の列ができるまでになる。そして、カップヌードルは一挙に全国区に知られる商品となる。賭けに勝ったのだ。

◆大成功

そして、２０００年。カップヌードルは全世界で年間８２億食を売るフードになった。阪神大震災のときに、大活躍したことも記憶に新しいし、また、スペースシャトルでの食事として実験されたことも記憶に新しい。忙しい現代人に時間を売る商品としてコンセプトされたが、このような社会的に意味のある用途がどんどん開発されていくことは、まさにラーメン王の安藤百福の真骨頂だと言えよう。

【安藤百福の５つのスポンサーシップ】

このカップヌードル開発プロジェクトの中で、プロジェクトスポンサーである安藤百福氏が果たした役割の中から重要なものを５つあげてみる。

（１）覚悟をもったメンバーアサイン
まず、人選である。初期のメンバーは問題児の社員と新入社員である。当時、チキンラーメンが頭打ちになり、会社の業績自体が停滞している中で、この２人に託した。特に大野氏に託したのは、人を見る目を背景にした、適材適所だといえる。
ただし、適材適所だけではこのようなメンバーアサインはできない。適材適所だけを考えてみたところで、「人材がいない」で終わるのが関の山だ。人材のいない中で、伸びシロを考えて、人を選ぶ。そして、彼らに任せて、直接の手しをしない。このような覚悟を決めて、初めて適材適所が可能になる。

（２）タイミングのよいアドバイス
安藤氏は大野氏や営業の秋山氏に実によいタイミングで、彼らの思考を加速するすばらしいアイディアを与えている。プロジェクトＸの物語からははっきりしないが、これは、手の平で遊ばせているというのではなく、おそらく安藤氏も彼らと一緒に考えることによって、その答えを導き出したのだと思う。そのために、安藤氏はコミュニケーションを欠かさなかった。これが一つのポイントだろう。
また、安藤氏は「タイミングよく」アドバイをすることによって、次の世代を担う大野や佐々木、秋山という人材を育てていることも見逃せない。

（３）コンセプトをぶらさない
中間成果物に対して厳しい目を持ち続けていたことは、どうしても譲れないものがあったのだ。それが１００円という価格で表現される高級感。安藤氏が狙っていたのは、この価格戦略によるラーメンの既成概念の打破。日清はその後、「ら王」で同じ戦略をとったことがあるのだが、その原点がここにあった。

（４）成功を大きくする
それまでは決して腰を上げることはなく、大野や秋山に任せていた安藤氏は銀座キャンペーンで自らが陣頭指揮を執る。この背景には自分の思いを顧客に伝えたいという思いがあると思うが、プロジェクトの成功を加速するために必要だと思ったのではないだろうか？プロジェクトスポンサーが表にでるときは、トラブルのときではない。成功を確実なものに、かつ大きくしたいときだ。その原則を貫いた行動だと言える。

（５）卓越した戦略眼
カップヌードルの一番の成功は、８２億食という驚異の数字もさることながら、阪神大震災の時の非常食での活躍や、宇宙食への可能性が開けたことではないかと思う。５８年に開発されたということなので、来年で５０年である。一般に食品の商品寿命は長いが、用途が社会環境の変化に合わせてどんどん変化していくことは究極の商品である。その背景に、安藤氏の戦略眼があることは間違いないだろう。
そのような戦略眼があるので、信念を貫くことができる。これからの５０年使われる商品だからコンセプトは譲らない。戦略上の目的を決してぶらさない。ここにプロジェクトスポンサーとしての真骨頂があるといえる。

【参考資料】
プロジェクトX 挑戦者たち 第4期 Vol.2 魔法のラーメン 82億食の奇跡 ― カップめん・どん底からの逆襲劇（2002）
http://www.amazon.co.jp/exec/obidos/ASIN/B000068WJL/opc-22/ref=nosim

【補助線】プロジェクトマネジメント組織のＲＲＡＡ

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

◆ＲＲＡＡ

前回、ＰＭＯがプロジェクトマネジメントのオーナーシップを持つべきであるという話をしたが、今回は、この点も含めて、ＰＭＯがどのような権限と責任を持つべきかを議論してみた。

日本ではあまり使われないが、組織のガバナンスを定義する方法として、ＲＲＡＡというフレームがある。

　Role（役割）
　Responsibility（実行責任）
　Accountability（説明責任）
　Authority（権限）

である。ステークホルダ分析などの場合にも使われることがある。このフレームに従って、ＰＭＯを定義してみよう。

◆ＰＭＯのＲＲＡＡ

最初はいわゆるＰＭＯのＲＲＡＡについて考えてみよう。「いわゆる」という書き方が気持ち悪ければ、この後で述べるＣＰＭＯ（全社ＰＭＯ）によって確立されたプロジェクトのマネジメントの標準の適用による効果を見ながら、事業部、地域などの範囲で、プロジェクトマネジメント推進の戦術的なマスタープランに対する責任を持つＰＭＯである。

ＰＭＯのＲＲＡＡは

・Role（役割）：ＰＭＯ
・Responsibility（実行責任）：プロジェクトマネジメント遂行の戦術的なマスタープランとリソースマネジメント
・Accountability（説明責任）：CPMOと事業部マネジャーへの報告
・Authority（権限）：年次の全社マスターポートフォリオ、および、プロジェクト資源予算計画の策定と調整

と定義できる。

◆ＣＰＭＯのＲＲＡＡ

次に、ＣＰＭＯについては

・Role（役割）：ＣＰＭＯ
・Responsibility（実行責任）：全社におけるビジョン、ミッション、ゴール、目的など、戦略的マスタープラン
・Accountability（説明責任）：CEOへの直接報告
・Authority（権限）：年次の全社マスターポートフォリオ、および、プロジェクト資源予算計画のレビューと承認

と定義できる。

基本的には、ＣＰＭＯとＰＭＯでほぼガバナンスが決まってくるが、もうひとつ、ＰＳＯの定義を決めておくと混乱が少なくなる。

◆ＰＳＯのＲＲＡＡ

ＰＳＯのＲＲＡＡは

・Role（役割）：ＰＳＯ
・Responsibility（実行責任）：プロジェクトマネジメント遂行のオペレーショナルマスタープランとプロジェクトポーフォトリオマネジメント
・Accountability（説明責任）：ＰＭＯとラインマネジャーへの報告
・Authority（権限）：プロジェクトポートフォリオのオペレーションプランと予算要求の承認

と定義できる。

【補助線】リーダーシップの旅

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

すごいマネジャーの続編。

「すごい人」がリーダーになるのではなく、「すごいことを考えた・した人」がリーダーとなってゆくと考え、その過程を旅になぞらえる「リーダーシップの旅」と呼ぶ考え方がある。

例えば、野田智義先生、金井嘉宏先生の「リーダーシップの旅　見えないものを見る」では、リーダーシップを、「見えないものを」を見通す能力であると捉えている。ある種のビジョンである。そして、そのビジョンを実現するために、まず自分で自分自身のリーダーとなることから旅が始まるとしている（リード・ザ・セルフ）。

次に、そしてそのビジョンに対して周囲の人に共鳴しする（リード・ザ・ピープル）。それが次第に社会全体に広がってゆく（リード・ザ・ソサイエティ）。このような過程でリーダーが生まれていくと述べている。

また、最近、出た本で、「シンクロニシティ　未来をつくるリーダーシップ」というリーダーシップの名著がある。

この本も著者である社会起業家ジョセフ・ジャウォースキー氏が、自身のリーダーシップの旅の様子を書いた自叙伝である。リーダーシップの旅を知るには、このあたりの本を読まれるとよいだろう。

先日、PMstyleプライベートセミナーで、「できる組織の条件」という議論をした。好川が考えているできる組織の条件は、新入社員も含めて、一人ひとりの社員（組織のメンバー）がリーダーシップの旅をしていることではないかと思う。

先日、あるコンシューマー商品メーカの社長から面白い話を聞いた。商品開発のプロジェクトに新入社員を「馴らす」つもりで突っ込んだ。もちろん、戦力になろうなど期待していない。ところが、その新入社員は偶然にもその商品の長年のユーザであった。なんと、プロジェクトの誰よりも使用経験が長かったそうだ。

普通であれば、プロジェクトの中の誰かが彼からうまく意見を引き出し、進めて行くのだろうが、この新入社員は明確な夢を持ってこの会社に入ってきたそうだ。そして、どんどんと自分の意見をプロジェクトリーダーにぶっつけた。最初は、疎んじられていたが、だんだん、プロジェクトがその新入社員のペースに巻き込まれていき、結果的に、その新入社員の発案した主だった意見はほぼ商品に採用された。さらには、商品コンセプトそのものがクリープして変わってしまったことに気がついた。

これを契機に、この社長はプロジェクトリーダー制を廃止し、チームが動かない場合にを動かすことに責任を持つチームリーダーだけを残して、フラットな開発組織に変えていく決心をしたそうである。

野田先生たちの考えに沿うと、この新入社員はすでにリーダーシップの旅にでている。おそらく、数年後にはたいへんなリーダーになっていると思われる。

あなたはこの新入社員の話をどう思うだろうか。

★「シンクロニシティ　未来をつくるリーダーシップ」は、今、読者プレゼント中（１１月７日まで）

PMstyle.jp読者プレゼント

　　http://www.pmstyle.jp/honpo/present/20071028.html