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

◆何のために標準化するのか

前回、問題提起だけしたが、みなさんの結論は出ただろうか？

前回述べたように、標準とは、メソドロジーが適切に適用されるためのルールである。目的とは、なぜ、わざわざ、そのようなルールを作りたいのか？という問題に他ならない。

論理的な答えは簡単だ。標準を作る目的は

　組織としてプロジェクトの成功を予測すること

に他ならない。標準は、組織としてのプロジェクトマネジメントの共通的なアプローチであり、メトリクスとして指標化されたり、あるいはマネジメントプロセスとして具体化され、それが標準としてドキュメント化される。

つまり、標準として決められたメトリクスを守り、決められたプロセス通りにメソドロジーを実施すれば、プロジェクトの成功は保証されるというのが標準なのだ。

◆ＰＭＯが標準を提示する意味

もっと正確にいえば、プロジェクトマネジメントの標準はプロジェクトの成功を保証するわけではなく、プロジェクトマネジメントの成功を保証するだけだ。そして、プロジェクトマネジメントの成功がプロジェクトの成功を生み出す。この因果関係が成り立つためには、メソドロジーが正しい（妥当な）ものであることが必要である。

たとえば、ＰＭＯが標準を示すということは、ＰＭＯとしてその通りにやればプロジェクトの成功を保証することに他ならない。それができるから、プロジェクトマネジメントのオーナーシップを持ちうるのだ。

しかし、現実にそう言われてみてももう一つピンとこないだろう。というよりも、プロジェクトを確実に成功させる方法などないとみんなが思っているといった方がよいかもしれない。では、何が適切ではないのか？メソドロジーなのか、標準なのか？

◆ＰＭＢＯＫの価値

ここでＰＭＢＯＫを導入することの意味が出てくる。ＰＭＢＯＫは膨大なプラクティス集である。つまり、うまくいったプロジェクトでやっているプロジェクトマネジメントのやり方を、９つの知識領域に分けて、プロセスとプロセスを実行するための手法ということで整理したのがＰＭＢＯＫである。

ということは、常識的に考えて、メソドロジーには問題はないと考えられる。現に、そう考えるからＰＭＢＯＫを導入しているともいえる。ということは、うまくいかないとすれば、それは標準の問題だということになり、ついては、ＰＭＢＯＫを導入することは、導入先の組織のプロジェクトの特性に合わせて、ＰＭＢＯＫに適用に当たって標準を策定するという作業を行うことを意味する。

◆現実的な標準化の考え方

実は、これがなかなかできない。つまり、メソドロジーを導入するのは簡単である。しかし、標準を策定するのは至難の技である。

そこで、よく行われるのが、アカウンタビリティというよりも、透明性、可視性を高めるために共通的なアプローチを決めるという方法である。この方法は、プロジェクトや問題を可視化することによって、ＰＭＯや上司組織、あるいは組織全体が知恵を集結することによってプロジェクトをうまく進めていこうという発想に基づいている。このようなアプローチを標準とみなすべきかどうかは別にして、

　組織が常にプロジェクトにかかわっておくことにより、成功を予測できる

といえ、標準の目的を達成するひとつの考え方であることは確かだ。

◆なぜ、標準に対する抵抗があるのか

最後にこの問題について一言触れておきたい。ここまでの議論ではっきりしたと思う。

その標準通りにやったときに、プロジェクトが成功するということが保証されていないからだ。

ただし、プロジェクトマネジメントがマネジメントである以上、万人が納得するメソドロジーなり、標準を発見するのは難しいだろう。

そうすると、標準化のプロセスそのものについて考えなおす必要がある。それが、プロジェクトマネジメントの成熟度を上げることにもなっていく。

◆なぜ、失敗すると、どんどん、はまるのか

先週末にフィギュアスケートのＮＨＫ杯のフリーをみていたら、ショートプログラムの上位選手が次々に失敗していた。失敗する様子を見ていると、失敗したものを立て直すのは難しいものだとつくづく感じる。

演技の最初の時期に失敗すると、そのあとのプランがきちんと実行できなくなってくる。理屈の上では、プラン通りに演技しないとどんどん状況が悪くなるというのは分かっているし、もう失敗するわけにいかないという気持ちが先立つのだろう。きっとあとの演技をより完璧にこなそうとする気持ちと、力が入るので事態がより悪くなる。

解説の荒川静香さんは盛んに「忘れて」とか「平静になって」とか言っているが、それが難しいのだろう。

多分に心理的な話だと思うが、この話はプロジェクトにおいても、そのまま、当てはまる。プロジェクトが深刻なトラブルに陥ったときに、冷静に進めていくというのは難しい。一般的な話でいえば、理由は組織の「眼」にある。組織がどう評価するかは別にして、多くのプロジェクトマネジャーは組織の「眼」を必要以上に意識する。上司だ。

◆はまるパターン

組織の眼を気にし始めたプロジェクトマネジャーがはまるパターンは２つある。一つは、何とかしないといけないとあせり、目先の状況がよく見えるような対応をすることだ。たとえば、要員を追加するといった策はこの典型であることが多い。

もう一つは上位組織にゆだねてしまう。つまり、上位組織の指示を受け入れることによって、その場をしのぐという行動に出る。その場をしのぐという言い方をしたのは、多くの場合、不適切な判断であっても受け入れてしまうことが多いからだ。本質的には上と同じ。とりあえず、受け入れればそれ以上評価が下がることはないという錯覚に陥るのだ。

◆あせりは伝染する

話は競馬に移る。地方競馬からのＪＲＡに転入してきて大活躍をしているベテラン安藤勝己騎手がＪＲＡのスター騎手である武豊騎手について「ジョッキーが心の中に勝ちたいと思うと、その思いが馬に伝わって、馬も力んでしまい、最後に効いてくる。彼はそれがたくさん勝てる理由だろう」と評価しているという記事をスポーツ雑誌で読んだ。

この心理もプロジェクトに当てはまる。プロジェクトマネジャーが焦ってなんとかしようと思ってしまうと、騎手と馬の関係のように口に出して何も言わなくてもチームに伝染する。チームメンバーが焦ってしまう。これによって、品質などのミスが出てくる。このパターンは多い。

◆いったん、断ち切り、プロジェクトを落ち着かせることが重要

著者はよくプロジェクトを失敗しないようにやるのではなく、成功させるように考えるべしと言っているが、トラブルの時に失敗しないようにすると逆効果であることが多い。スケートの例の如く、トータルで失敗しない（つじつまを合わせる）ためには、何とかして取り返さなくてはならないと思ってしまうのだ。トラブルが起こったら、まず、チームやステークホルダも含めて冷静になることを目指す必要がある。そのためには、まずはプロジェクトを落ち着かせることだ。これが安定化である。

◆佐々木正と和田富夫

電子・情報分野のエンジニアであれば、佐々木正の名前を知らない人はいないのではないだろうか？富士通の役員からシャープに転身し、電卓のＩＣ化で偉大な業績を上げ、シャープの事業基盤を作った一人と目され、副社長まで務めた人物だ。社外においても、世界最大の学会IEEE(The Institute of Electrical and Electronics Engineers,Inc.)において日本人としては５人目になる名誉会員を授与されるなどの評価を受け、また、さまざまな公的機関の役職を務めてあげている。近年では、ソフトバンクの相談役として、孫正義社長の後見人的存在になり、注目された。

その佐々木正がシャープの液晶事業でも大きな役割を果たす。

シャープの液晶事業の基盤作りを担ってきたのは、和田富夫というエンジニアである。和田はＥＬ（エレクトロルミネッセンス：電圧をかけると蛍光を発行する無機体。一時、ブラウン管の代替技術として本命視された時代があった）による液晶テレビの開発プロジェクトに取り組んでいた。

しかし、なかなか、うまくいかず、プロジェクトは解散し、プロジェクトメンバーは左遷される。和田も技術管理部の配属になり、現場を離れて技術者の裏方仕事に従事することになった。

◆液晶にみたビジョン

それから３年、技術管理の仕事にも慣れてきたころ、夕食をとっていた和田は運命の出会いをする。「世界の企業　現代の錬金術」というドキュメンタリーで、ＲＣＡの液晶技術の開発を知る。いてもたってもられなくなった和田は、当時の産業機械事業部長である佐々木に液晶に関するレポートを上げる。あきれながらとりあえずレポートを受け取った佐々木は、サポートを読むや否や、ＲＣＡに連絡を取る。そして、表示速度が遅いため、実用に堪えないという情報をＲＣＡから得る。

しかし、和田はあきらめない。こうすれば表示速度の問題が解決するというのを延々と佐々木に説明する。ついに、佐々木は和田に、「一線の技術者は出せない、実用化できなければ解散」という２つの条件で、開発を許可する。和田は背水の陣で、社内で協力してくれるエンジニアを自分で探す。また、人事に頼み、新入社員を配属してもらう。この一人が大学で有機化学を専攻していた船田文明だった。和田は、しばらく様子を見て、実験計画をすべて船田に任せる。

◆電卓の鬼

さて、当時のシャープの主力製品は佐々木が先鞭を付けた電卓であった。電卓においては、電卓の鬼とまで言われた鷲塚諫が大成功をおさめてトップシェアを誇っていたが、カシオの追い上げに、泥沼の価格競争に陥っていた。電卓の課題は電力と小型化だった。それに対して、両陣営とも画期的な策はなく、価格競争に陥っていたのだ。鷲塚は、コスト競争に終止符を打つ切り札を探していた。

この状況を見て、和田は、鷲塚に電卓の表示装置に液晶を使うことを提案する。しかし、その時点の技術では、あまりにも遅くて使えない。また、長時間連続使用により化学反応で気泡が生じるという問題もあった。

電卓のニーズにこたえるために頑張っていた船田が世紀の大発見をする。電圧を交流にすることにより、画期的に表示スピードが速くなり、かつ、気泡も生じないのだ。意気込んで電卓部隊に提案するも、電卓の表示装置は直流で設計されており、全面的な設計変更になるという理由で見送りになった。

◆液晶が電卓を救う

和田は気落ちすることなく、時計、電子レンジなどが、さまざまな応用先を探して奔走した。一方で、鷲塚は断ったあとも、不毛なコスト競争への対処に迷いに迷う。そして、ついに、液晶の採用を決断した。結果として、この判断が社を救うことになる。交流への設計変更をした電卓を開発しているうちに、ライバルのカシオが「カシオミニ」という電卓史上に残る商品を発売した。シャープが直流で考えていたレベルでは価格的にも、サイズ的にも到底太刀打ちできないような商品で、家計簿などのニーズを取り込み、電卓はビジネス用途から一挙に市場を広げる。同時に、トップシェアもシャープから奪い去っていった。

シャープの液晶電卓もなんとかめどがついてきた。価格を下げることなく、消費電力を下げることによって、電池代がかからなくなり、ライフサイクルコストで勝てる見込みが立った。

◆独断発注と事後承諾

いよいよ生産である。しかし、社内には反液晶の逆風が強く、なかなか、ラインを立ち上げられない。完成期限まで４か月を切った。生産装置の提案を依頼していた日本真空技術に、３か月で開発を頼むが、営業担当者には無理だと断られる。そこに先方の副社長が現れ、その場で契約するなら引き受けると譲歩する。まだ、決済などされていない。

和田はここで、首を覚悟で契約書にサインをした。会社に戻った和田は、当時、専務になっていた佐々木に、「独断発注してきた」と告げる。これを聞いた佐々木は「俺が佐々木の事後承諾を取る」と答えた。

約束通り、生産機械は３か月後に届き、無事に、液晶表示器の生産のラインが立ち上がる。シャープは、カシオからトップシェアを奪い返した。

これが、「液晶のシャープ」の始まりである。ちなみに、電卓の鬼といわれた鷲塚は液晶を取り入れる戦略を推進する旗頭になる。和田は不幸にも脳梗塞に倒れるが、液晶への執念からよみがえり、液晶のエンジニアとしての仕事人生を送った。

◆日本人はアイディアを大切にする。

ジェームズ・アンドリュー、ハロルド・サーキン（重竹尚基、遠藤真美、小池仁訳）「BCG流 成長へのイノベーション戦略」、ダイヤモンド社（2007）4270002719

いわゆる日本的企業のいまだに多くのミドルマネジャーやシニアマネジャーは、建前はともかく、本音の部分ではプロジェクトマネジメントや、ＭＢＡ流のマネジメントを否定している人が多い。

国民性だの、現場主義だのいろいろな理由が言われているが、今まで、どれもあまり納得のいく理由ではなかった。それについてこの本に書かれていることはかなり納得できた。

日本人はアイディアを大切にする。この本のテーマであるイノベーションのような分野だけではなく、日常業務の中でも常にアイディアを出し、改善をしようとする。創造性に富んでいる。

一方で、アイディアに頼りすぎる傾向がある。大したアイディアではないと思えば、アイディアが受け入れなければすぐにあきらめる。諦めて次のアイディアを探す。よく言えば潔さがある。国の政策などはこの典型かもしれない。逆に良いアイディアだと思えば、受け入れなれなくてもしつこく粘る。

◆ウォークマンを作った日本人は、なぜｉＰｏｄが作れなかったか？

この発想の原点は、「よいものは売れる」とかいった発想があると思われる。「提供者が満足できないものを売るのは不道徳だ」という発想さえもあるし、これらが社会的価値観になっていると言ってもよいだろう。

実は、この本の中で、ひとつの問題提起がある。日本の会社はなぜ、ｉＰｏｄを作れなかったかという問題提起だ。アイディアもあった（ＩＣオーディオを最初に世に出したのはソニーである）。開発する能力もあったし、実際にソニーなどいくつかのメーカはアップルより先行して開発していた。しかし、実際に、ＩＣオーディオの「ドミナントモデル（普及モデル）」を作ったのはアップルだった。

この指摘はこの本で初めてされたというわけではない。いろいろな分析がされている。アップル社のコアコンピタンスである商品デザインやインタフェースデザインが日本の企業にはなかったという人もいる。ネットワークで音楽を提供するというビジネスモデルが日本の企業にはできなかったという人もいる。いずれもそういう一面はあったのだろう。

この本が指摘するのは、アイディアをお金に換えるまでのマネジメントの違いである。アイディア実現の戦略能力の違いだということもできる。ソニーがＩＣオーディオで消費者に対してやってきたことは、アイディアを提案し、受け入れられなければ新しいアイディアを提案する。このパターンで成功したのが、ウォークマンだったのだろう。

◆良いアイディアが売れるのではなく、売れたものがよいアイディアだというパラダイムシフトがプロジェクトマネジメント成熟のカギ

日本の組織はこの部分のマネジメントを放棄している組織が多いように思う。商品であればアイディア勝負ということになるが、商品開発に限ったことではない。事業でも、プロジェクトでも、計画（アイディア）に対して、それを何とかしようと強く思わない。日本人は責任を取らないという。一方で責任感が強いという評価もある。

責任感は強いのだが、アイディアや計画がうまくいくかどうかは「風まかせ」なのだ。マネジメントをしてうまくいかなければ、マネジメントの責任ということになるが、風まかせであれば、ある意味で責任のとりようがない。

ここにどうしても抜けないプロダクトアウトの発想がある。そのアイディアがよいかどうかを決めるのは、発案者や開発者ではない。市場であり、顧客である。その意味で、アイディアを自身で評価するのは「不遜」ではないかと思う。価値がわからなければわかってもらうという謙虚な姿勢がないので、マネジメントがないのではなかろうか。

プロジェクトマネジメントはアイディアを実現するための手法である。

◆標準とは何か

前回は、プロジェクトマネジメントの標準は現場のプラクティスを吸い上げていき、構築していくべきだという話をした。

このノートでは、標準については第１７回から６回にわたって、「戦略的ＰＭＯの標準化への取り組み」と題して議論している。まずは、こちらを改めて読み直してみてほしい。

第１７回　戦略的ＰＭＯの標準化への取り組み（１）
http://pmos.jp/pmstyle/pmcoe/pmcoe17.html

さて、今回は、この記事も踏まえつつ、標準とは何かということを改めて考えてみたい。

上記の記事でも定義したが、標準とは

　メソドロジー（方法論）の適正な適用を保証するためのルール

である。表現形式は様々である。これについても上の記事を参考にしてほしい。

◆「適正な適用」とは？

ここで考えたいのはこれはどういう意味かということだ。もっと的を絞っていえば、「適正な適用」とは何を指しているのかということだ。

みなさんの組織でスコープ定義をするときに、ＷＢＳを作り、中間成果物に対するマイルストーンを設定する、いわゆるマイルストーン管理をすることを「標準」として定めている組織は多いだろう。これは標準といえるだろうか？

実際に、マイルストーン管理をしようとすると、プロジェクトマネジメントの初心者がよく悩むように、ＷＢＳでワークパッケージの規模はどのくらいにすればいいのか、あるいは、マイルストーンはどのくらいのスパン（あるいは数）を設定すればよいのかという問題が出てくる。

ここで勘違いしてはならないのは、ＷＢＳとか、マイルストーン管理というのは、メソドロジーである。標準とは、これらが適正に適用されるためのルールである。そう考えると、たとえば、上のような問題（ワークパッケージの規模とか、マイルストーンのスパン）の決め方を明示しない限り、メソドロジーが適正に適用されるのは難しいかもしれない。すると、それらのルールが標準だということになる。

◆コンピテンシーを標準化するという考え方

あるいは、発想を変えると、これも、以前の記事で述べたが、「コンピテンシー」を標準化するという考え方もある。プロジェクトマネジメントもマネジメントであるので、適正といってみたところで、一律に決めれるものではないという考え方は当然ある。

すると、メソドロジーを適正に適用するために一律に決めることができるものは何かと考えたときに、プロジェクトマネジャーの能力であり、また、その能力を使った行動であると考えるのだ。実は、マネジメントの中ではこちらの発想の方がマジョリティである。

プロジェクトマネジメントであれば、ＰＭコンピテンシーを入れるものがこれに該当する。同じようなＰＭコンピテンシーをもった人が２人いたとしよう。その２人がＷＢＳを作ったときに、結果として、ＷＢＳのワークパッケージのサイズは違うかもしれない。これはこれで、同等なＰＭコンピテンシーを持つプロジェクトマネジャーのマネジメント行動なので、両方とも適正な適用をしていると考えましょうという考え方である。

◆何のために標準化するかの

ちょっと、違和感を感じる方もいるかもしれない。実は、ここでもう一つ考えるべきことがある。それは、何のために標準化するのかという問題である。

この問題については次回に議論するので、ぜひ、みなさんの方でも考えてみてほしい。

モチベーションは必ず感染する。顧客のために自身のモチベーションを向上させなくてはならない。（京都大学教授・田尾雅夫）

【効用】
・ＰＭ体質改善
　　顧客感度アップ、顧客説得力アップ
・ＰＭ力向上
　　プロ意識の向上
・トラブル緩和
　モチベーション向上

【成分】

◆顧客満足のカギは「モチベーション」
◆顧客との関係がうまくいかない理由は顧客の「モチベーション不足」
◆モチベーションを顧客に「感染」させる

このサプリを服用したい方はこちら。

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

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

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

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

　そこから始まる

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

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

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

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

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

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

と指摘している。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＰＭＢＯＫを知ると

　計画は常に守られるべき

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

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

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

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

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

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

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

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

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

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

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

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

ＰＭＡＪの理事の渡辺さんと一緒に仕事をさせてもらっている。

今度、PMstyleでセミナーを共催することになった。セミナーのテーマは

　プロジェクトマネジャーの現場力

だ。企画の議論の中でなんとなく出てきた言葉なのだが、議論をしているうちに、今、ＰＭコンピテンシーだの、ヒューマンスキルだの、人間力だの言っている言葉はすべて「現場力」という一言に集約されるのではないかという気がしてきた。

皆さんは「プロジェクトマネジャーの現場力」という言葉から何を連想されますか？

コメントお待ちしています。