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

【補助線】シャープの液晶事業を生み出した５つのスポンサーシップ

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

◆佐々木正と和田富夫

電子・情報分野のエンジニアであれば、佐々木正の名前を知らない人はいないのではないだろうか？富士通の役員からシャープに転身し、電卓のＩＣ化で偉大な業績を上げ、シャープの事業基盤を作った一人と目され、副社長まで務めた人物だ。社外においても、世界最大の学会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でセミナーを共催することになった。セミナーのテーマは

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

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

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

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

ＰＭサプリ１００：意志の力

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

エネルギーと集中力の背後にある意志の力、これこそがモチベーションよりも決定的に重要だ（ザンクト・ガレン大学教授　ハイケ・ブルック、ロンドン・ビジネススクール教授　スマントラ・ゴシャール）

・ＰＭ体質改善
　　ＰＭ体質の全般に対して効果があります
・ＰＭ力向上
　　ＰＭ力向上の全般に対して効果があります
・トラブル緩和
　　弱気克服

◆はじめに

今回でサプリも１００回を迎えました。約２年間継続していることになります。基本的な記事の作り方としては、皆様に覚えておいてほしいメッセージを紹介し、その「プロジェクトマネジメント的解釈」を自分の経験に基づいて紹介するというスタイルをとっています。狙いは、コンピテンシーの強化です。

まだ、スムーズに立ち上がっていませんが、スキル強化の道具箱と両輪で今後も継続していきたいと思っていますので、今後もよろしくお願いいたします。

それでは、１００錠目のサプリをお届します。

◆究極のサプリ「意志の力」

これまで、いろいろなサプリを提供してきたが、「究極のサプリ」は「意志の力」というサプリではないかと思う。意志力は、ハイケ・ブルックとスマントラ・ゴシャールが言い出した言葉である。

彼らが意志の力に注目し始めた理由はある意味で明快である。

企業のマネジャーの多くは、目標達成のために、スキルもある。自分に与えられた職務にも十分に満足している。そして、組織のために役立ちたいと思っている。

◆なぜ、目標が達成できないのか

しかし、実際には目標達成ができない。なぜだろう。

このようなマネジャーは、目標達成ができない理由から２つのタイプに分かれるというのが、ハイケ・ブルック＆スマントラ・ゴシャールの指摘である。

ひとつのタイプは一生懸命やっているのだが成果の上がらない人。このタイプの人の特徴は

・毎日行うおびただしい量の仕事に気を奪われている
・エネルギッシュであるにもかかわらず、集中力に欠ける
・必死で、性急である

といったようなものだ。もう一つのタイプは、物事を先延ばしするタイプの人。このようなタイプの人の特徴は

・エネルギーも集中力もかける
・プロジェクトにとって本当に重要な仕事をぐずぐずと先延ばしにする
・不安定で、失敗を恐れる

といったものだ。

◆プロジェクトマネジャーに見られる現象

プロジェクトマネジャーにとってもこれは極めて重要な指摘だ。成果を上げることのできないプロジェクトマネジャーはやはり、このどちらかのタイプの人が多い。

前者はとにかく、自分の席にいることが珍しいくらい、顧客、上司、関係者とのうち合わせに飛び回っている。メンバーに任せればよい仕事まで首を突っ込むのだから、いくら時間があっても足らないくらいの仕事を抱える。ところが、ひとつひとつをみるとうまくいっているかというと、中途半端なのだ。それゆえに、ますます仕事が増えてしまっている。その理由は、ほかにもやることがあるというので、集中してその仕事に取り組まず、中途半端なところでメンバーに任せてしまうからだ。じっくりと腰を落ちけてやることができない。関西弁でいえば「イラチ」なのだ。

後者のタイプはとにかく優柔不断が問題だ。組織や企業に貢献したいという思いが却って決定を難しくしている。そのために、先延ばしにする。これはプロジェクトにとっては最悪の行動である。この典型的な問題が、スケジュールが遅れた時の対応だ。無理が続いてメンバーは明らかにつかれている。少し、ゆるめた方がよい。ゆるめないと、どんどんパフォーマンスは落ちるだろうし、品質の問題も出てくる。最悪はダウンしてしまう。

それがわかっていてもメンバーダウンするとか、何か契機がないとなかなか行動に移せない。こんな人は多い。

◆目標達成のために必要なアクション～意図を持ち、コミットする

いずれの人も、パターンを脱するには、ひとつひとつの仕事に対して、明確な意図を頭に思い浮かべ、意図を持って実行していくことが重要である。たとえば、スコープを決めるとしよう。その際に、自分としてこうしたいという明確な意図を持つ。そして、自分の意図にコミットする。この際に重要なことは、意図は自分の素直な思いと異なることがある。たとえば、顧客満足を考えると不本意ながらも機能追加をせざるを得ないとしよう。このような場合にも、意図にコミットすることが必要だ。

このためには、目標に対する思考と、目標に対する感情を一致させるようなマネジメントが必要だ。平たくいえば、不本意な目標であっても、その目標に自分がコミットしたいという感情を見つける。お客さんに好感を持っていてなんとか力になりたいという感情でもいいし、自分は難しい状況を乗り越えることに快感を感じるという感情でもいい。状況を肯定できる感情を見つけ、思考と合致させることは大切である。これにより、格段にその仕事に集中でき、最後までやりぬくことができるだろう。

◆意志の力

これが意志の力である。

難しいのは、マネジャーにしろ、プロジェクトマネジャーにしろ、それをチームとして引き起こさなくてはならないことだ。つまり、自分が自分の仕事に没頭するだけではなく、チームも同じような状況していなくてはならないことだ。

これも意志の力である。チームとしての目標を同じように位置付けていく。そして、チームで共有する感情を目標に対して肯定的にしていく。ある意味で、集団信仰のような話であるが、ここに突っ込んていく必要がある。

モチベーションでは解決しない状況も意志の力によって解決することができるだろう。自分自身も、チームとしても意志の力をコントロールできるようなプロジェクトマネジャーになりたいものだ。

　　　　（２００７年１１月１５日　ＰＭ養成マガジンプロフェッショナルより抜粋）

ＰＭサプリを購入したい方はこちら。

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

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

◆リスクマインド

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

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

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

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

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

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

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

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

◆リスクマインドの診断

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

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

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

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

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

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

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

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

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