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

【補助線】角を矯めて牛を殺す

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

◆最近のプロジェクトの特徴

最近のプロジェクトによく見られる課題がある。

・スケジュールにチャレンジ要素がある
・リソースにチャレンジ要素がある
・仕様があいまいである
・新しい技術へのチャレンジにより、技術的不確実性がある
・今まで全く知らない人とチームを作って取り組む
・チームが分散している
・プロジェクトの中間的なスコープが変化する
・・・

などだ。このような課題がまったくないプロジェクトは珍しいだろう。

米国では、こういった課題のプロジェクトに対して、ＰＭＢＯＫに代表されるような「確定的な」プロジェクトに対して有効なマネジメントが本当に有効なのだろうか？という議論がある。アジャイルプロジェクトマネジメントやライドブレーンプロジェクトマネジメントといった手法が登場してきている。

◆手法ありきの傾向が強い日本

ところが、日本の企業をみていると、このような要素を含むプロジェクトに対して、ＰＭＢＯＫを適用するには何をすればよいかを考えている組織が多い。もちろん、手法を導入するというのはそういうことだから、頭ごなしにそれが悪いということではない。

問題はバランスである。

ＰＭＢＯＫは基本的には上位組織がプロジェクトを「管理」するには、プロジェクトはどのようにマネジメントされていればよいかという発想で作られている。しかし、すべてを管理しようとしても定型業務ではないのだから難しい。そこで、与える権限を明確にして、権限委譲をするようになっている。これに使われるツールがたとえば、プロジェクト憲章である。

ただ、権限委譲というのはそんなに簡単にできることではない。任せるだけであれば「丸投げ」ということで簡単だが、多くのプロジェクトはプロジェクトマネジャーやプロジェクトのエンパワーメントをしなくてはうまくいかない。

結果として、プロジェクトマネジメントを導入してもうまくいかなかった。その分析をしてみると、明らかになったのが冒頭に述べたようなプロジェクトではうまくいっていないという現実だった。

◆２つのアプローチ

ここで多くの組織は２つのアプローチをとることにした。ひとつはこのようなプロジェクトに対応できるようなプロジェクトマネジャーの育成である。一言でいえば、コンピテンシーやヒューマンスキルを持ったプロジェクトを育成しようとした。これは、今でも盛んに行われているが、そんなに短時間でできるものではない。

そこで現実策として出てきたのが、組織のマネジメントによりプロジェクトの性格を変えてしまうことだった。まず、リスクマネジメントと称して、チャレンジ要素を最小限に抑えてしまう。これがもっとも多い。また、不確実性の回避として、ゲート（レビュー）を設けたフェージングを導入した組織も多い。さらにはスコープマネジメントとして、変更管理を中心に行うのではなく、変えないということを前提にした運営を始めている組織も少なくない。

つまり、プロジェクトを定型業務化する方向に走っている。この効果は大きい。プロジェクトの失敗が減ってきた。

◆弊害と対策

これだけであれば、ハッピーエンドなのだが、弊害も見られるようになってきた。競争力の低下だ。商品の機能を落としてみたり、ＳＩサービスの顧客満足を低下させるということがかなり、目につくようになってきた。もちろん、クオリティとチャレンジのどちらが組織の競争力になるかは事業の性格や組織文化によって異なるので、チャレンジをあきらめたすべての組織がそうなっているというわけではないが、競争力を落とすというのが特殊ケースという状況でもない。

この問題の根底にあるのがスポンサーシップである。スポンサーが管理主義に陥ってきて、市場や顧客のニーズに十分な対応するものができない組織が増えてきた。結果として、そんな仕事に対してやりがいを見失っている人も少なくない。

こうなってくると、ＰＭＢＯＫの適用だという話ではなくなってくる。明らかにバランスを失い、手法に合わせて業務を変えるという状況になってくる。

このままでいくと、角を矯めて牛を殺すことになりかねないことをよく認識しておく必要がある。

【補助線】ＰＭＯとＰＭのレシプロシティ

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

前回は、ＰＭＯが作る標準というのは、その通りにやればプロジェクトマネジメントがうまくいくというものでなくてはならないということを述べた。ただし、マネジメントである以上、それは現実的に難しい。そこで、標準化のプロセスそのものを考え直す必要があることを指摘した。

◆ＰＭＯとプロジェクトマネジャーの関係の基本は「互恵関係」

今回は、少し、視点を変えて、この議論の本質を考えてみたい。この議論の本質にあるのは、「レシプロシティ」だと思う。日本語では「互恵関係」という。簡単にいえば、「よい行動には見返りが、悪い行動には報復が戻ってくる」というものだ。

ここで、多くのＰＭＯスタッフが頭を悩ますのは、何がよい行動かということである。

たとえば、あなたが

「上位組織のマネジャーが入る定例のレビューミーティングで、プロジェクトマネジャーの進め方に賛成の態度を示す」

と、その見返りとして、プロジェクトマネジャーは

「プロジェクトであなたが提唱する標準的な手法を使って、成果を作ってくれる」

といった行動をすることを期待するだろう。このような価値の交換が生じるのはレシプロシティである。

何でもない話のようだが、これは以外と難しい。その理由は、価値であるので、決めるのは相手であり、自分である。つまりは主観である。思いつきや、自分の価値感で行ったのでは、相手はそれを評価しない。

相手に評価されないと、人間だれしも、「なんだ、あいつ」という感情が芽生える。

こんな事件があった。

◆ある事件

プロジェクトマネジャーがプロジェクト計画書をなかなか出さない。プロジェクト計画書を出さなければ建前上はプロジェクトは承認されず、作業に着手することはできない。このプロジェクト担当のＰＭＯスタッフは時間がないので、苦労しているのだと思い、そこで、良かれと思って、代わりに計画書のたたき台を作って渡した。プロジェクトマネジャーは一応受け取った。

そこまでしてやったのだから、当然、すぐに計画書が出てくると思っていたが、依然として出てこない。後でわかったのは、このときに顧客側が経営陣の異動があり、計画がひっくり返りそうになっていた。落札はしたもののまた、入札はしていない。プロジェクトマネジャーは、まず、この問題をなんとかするのが先決だと考え、顧客の社内提案の支援をしていたのだ。この時点で、プロジェクトマネジャーは計画書を書いてもらってもありがたくもなんともかなったので、当然、ほったらかしにしていた。

一方、ＰＭＯスタッフは顧客の問題に立ち入っていくのはＰＭＯとしては行き過ぎだと考え、できる範囲で最善を尽くしたと思っている。にも関わらず、プロジェクトマネジャーは何もしない。最初はやんわりと言っていたが、だんだん、攻撃的になってきた。計画書も出していないのに、契約前に顧客に入り込んで仕事をしているというのはどういうつもりだといったことを言い出した。

不幸にもこの企業のＰＭＯは結構強く、最終的にこの声は通ってしまった。事業部長が出てきて、プロジェクトマネジャーに対して、顧客の内部の問題に首を突っ込むな、それよりは提案通り（内示通り）の内容という前提で社内の準備をしろという裁定をした。

どれだけの因果関係があるかは分からないが、結果としてこのプロジェクトは顧客側で中止になった。

この事件における、ＰＭＯ側の問題は何だろうか？これは理屈をいうのは簡単である。たぶん、まっ先に出てくる答えは状況を理解していなかったという答えだろう。ただ、理解していなかったわけではない。プロジェクトマネジャーとも話をしていたし、顧客側の状況も知っていた。

この問題の本質は、価値観にある。ＰＭＯスタッフは、自分たちは間接部門であり、プロジェクトマネジャーが稼いでいる。プロジェクトマネジャーの仕事を助けて利益が出るということを分かっていたにも関わらず、本当にそうは思っていなかった。社内ルールを守るということと、顧客へのサービスをすることを比較したときに前者が勝っていたのだ。えてしてこんなものだ。

では、どうすればよかったのだろうか？これは次回。

【補助線】顧客との互恵関係

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

◆顧客はだれか

顧客との良好な関係を保つことは難しい。といよりも、対立的な関係になることが少なくなり。なぜだろう？

プロジェクトからみたときの顧客と言ってもいろいろなケースがある。典型的なものだけでも以下のようものがある。

まず、ＳＩプロジェクトのように顧客に直接商品を売って対価を得るという関係がある。この場合は、プロジェクトの顧客＝エンドユーザとなり、これがある意味でもっともわかりやすい。

多くの消費材商品のように市場があり、エンドユーザはいるが、その顧客へ届く経路に流通がある。この場合、プロジェクトにとっての（ステークホルダ）としての顧客は、顧客の声の代表ということになる。

生産材商品であれば、メーカが直接営業するケースも少なくない。この場合には、デリバリチャネルとしての流通はあるが、プロジェクトとしての実質的な顧客は自社内の営業部門のように、エンドユーザに影響力を持つ部門であることが多い。良いか悪いかはその営業部門の活動内容の問題なのでさてき、これも一種の社内顧客である。

社内の情報システム開発のようなプロジェクトだと、社内の利用部門が顧客になる。文字通り、社内顧客である。

◆エンドユーザとそれ以外という区分

これらを同じように扱うのは難しいかもしれないが、大きく分けてしまえば２つに分けることはできるだろう。エンドユーザとエンドユーザ以外である。

エンドユーザとそれが以外は何が違うかというと、「目先」の利益である。インターネットが普及してきて顧客と提供者の関係についての変化が盛んに言われるようになってきたが、モノにしろ、サービスにしろ、エンドユーザの手に届かないものは買えないという事実は変わらないし、すべてのものが宅急便で運べるわけではない。はやり、流通は強いし、今までの通り、流通までと、その先という区分は根強く残っている。

プロジェクトにとってみると、エンドユーザの満足を実現するのは、ＱＣＤとのコンフリクトがありので、苦労を伴うが、困難ではない。プロダクトスコープの問題である。

ところが、エンドユーザ以外を考えると、顧客として満足させることは非常に難しい部分がある。なぜか。

◆カレンシーを見つけるとうまくいく

ここで面白い概念をご紹介しよう。コーエン＆ブラッドフォードが「影響力の法則」というフレームワークの中で言っている概念で、カレンシーという概念である。カレンシーとは言葉としては通貨のことだが、通貨というはもの代わりに登場したものだ。つまり、相手からの何かを得たい場合には、対価が必要になる。エンドユーザの場合は、商取引であるので、文字通り、通貨がカレンシーになる。通貨を得るためにニーズに沿う商品を開発するわけだ。

流通であれば、まだ、通貨で行けるかもしれない。要するに仕切りを下げておけば何とかなるかもしれないが、多少、複雑である。ボリュームが出てくるからだ。つまり、１００円の利益が上がって、１００個売れそうなものと、１０個の利益があって１０００個売れそうなものはどちらがよいかという話になる。これはやや難しい。

顧客が社内の営業部門となると、カレンシーとして使える資源となると、ぱっと思いつかないだろう。ある営業マンはたくさん売れて自分の給料が上がることに価値を求めるかもしれないし、ある営業マンは顧客が喜ぶことに価値を見出すかもしれない。ある営業マンは営業部長が気にいるものであることに価値を見出すかもしれない。こんなことを考え出すときりがない。わけがわからない。

顧客との関係がうまくいくということは、このカレンシーをうまく見つけることができて、それをうまく提供できるということだ。

◆カレンシーは主観である

ここで重要なポイントは何がカレンシーになるかは価値観の問題であり、主観的な問題であることだ。流通の話で、１００円の利益が上がって、１００個売れそうなものと、１０個の利益があって１０００個売れそうなもののどちらを選ぶかはおそらく、組織としての主観（意志）の問題だ。つまり、戦略なり、ビジョンの問題である。営業部門の話になると、プロジェクトとの関係は営業部という組織よりは担当者との関係になり、ゆえに、営業担当者の主観の問題である。

さて、ＳＩ。上で分かりやすいといったことに違和感を感じた方もいらっしゃると思うが、結局のところ、同じ問題だ。違和感を感じた人は、組織かプロジェクトチームか個人かという見極めが難しいと思っている人だと思う。

実はこの問題は腹をくくって決めてしまうのがよい。たとえば、プロジェクトだと腹をくくれば、そのプロジェクトの意見を組織内に通していくことそのものがカレンシーになり、ステークホルダマネジメントになるからだ。

相手の組織の状況をみて、中途半端な態度をとるので、スコープ変更が起こるのだ。相手を徹底的に支援して、その見返りに、手戻りの防波堤になってもらう。たとえば、こんな関係を作っていくのだ。これが互恵関係である。

【補助線】プロジェクトマネジャーの現場力

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

◆昔の日本企業の現場は本当に強かったのか？

「現場力」という言葉がある。正確な定義があるわけではないと思うが、「現場が強い」、「現場で会社が成り立っている」などの言霊のある言葉だ。

戦後の高度成長の中で、日本企業は一般的に現場力により成長してきたと認識されている。おそらくこれは、明確な戦略がない中で、現場が方向性を決め、それを次々に実行していくことにより、成長してきたことを指していると思われる。

この背景になるのが、「よいものを作れば売れる」という神話である。ここで、考えておかなくてはならないのは、高度成長期は本当に現場が強かったのかということだ。少なくともこの時代の日本人は勤勉だったし、工夫をする心にも富んでいた。これは間違いないと思う。その意味で現場が強いというのであれば、それは正しいだろう。この点については後でもう一度、触れたい。

◆戦略経営における現場力

その日本にも、戦略に基づく経営という考え方が取り入れられるようになってきたのは、おそらく９０年代の前半である。この時期は、バブルの崩壊とともも、右肩上がりの成長も停滞し、それまでのようにみんなが同じことをやっていたのでは、全員が立ち行かなくなるという危機感がでてきた時期だ。まず、立ち上がったのは製造業だ。現在、エクセレントカンパニーの地位を確立している企業は間違いなくこの時代に戦略的な経営に移行している。そして、やはり、「強い現場」、「現場力」が成功のキーワードになっている企業が多い。今のエクセレントカンパニーの戦略の３大成功要因は、情報技術、金融技術と現場力だろう。そして、日本の企業は現場力を競争優位源泉とする企業が多い。

では、戦略経営の中での現場力とはなんだろうか？戦略経営の中では、高度成長期のような現場の自由度はない。その中で、現場力が強いとはどういうことか。

現場力は、「あるべき姿」＝ビジョンに対して、策定された戦略を微調整しながら業務を進めていく能力である。あるいはこのために、現場で起こる問題（あるべき姿と現状のギャップ）を能動的に発見し、解決する力である。

◆リアルタイム経営のためにはプロジェクトの現場力が不可欠

戦略経営においては、戦略の精度を上げるためにだんだんモニタリングのスパンが短くなってくる。今は最低でも四半期で戦略を見直し、軌道修正をしている企業が多い。ただし、現実問題として考えると四半期というスパンが限界だろう。

そこで注目されているのが、プロジェクト経営とプロジェクトマネジメントなのだ。四半期より短いサイクルで戦略の修正をするためには、開発や販売などの業務をプロジェクト化し、現場としてのプロジェクトにその軌道修正の役割をゆだねるしかない。プロジェクトマネジメントの要素にはアカウンタビリティの確保があり、修正行動への介入は難しいとしてもモニタリングは可能であることも経営としては好都合である。現場の状況を見ながら、次のクオーターの戦略計画の微調整を行うことが可能になるからだ。

このように考えてみると、プロジェクトに要求されるのは、立ち上げ時の計画通りに行うことではない。自ら、プロジェクト環境を察知し、それに合わせてプロジェクトの計画を変えていくことである。この適応能力こそがプロジェクトマネジャーに求められる現場力である。

◆プロジェクトマネジャーに求められる現場力

では、現場力を持つためにプロジェクトマネジャーに求められるものは何か？以下の５つである。

（１）経営ビジョンの共有 （２）戦略の理解と把握 （３）戦略の計画への落とし込み （４）ビジョンに照らし合わせた計画の問題点の発見 （５）計画調整による戦略の微調整

特にプロジェクトマネジャーの方にはよく考えてみてほしいのだが、これはある程度の経営的意思決定を行う仕事なのだ。

つまり、プロジェクトにおいてはプロジェクトのメンバーまで戦略実行の一端を担っているという意識が必要であり、メンバーにそれを指導していくのはいうまでもなくプロジェクトマネジャーの仕事である。

【補助線】現場力とは

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

ここ数年、「現場力」という概念が注目されている。定義は人によってさまざまだが、大阪大学のコミュニケーションデザインセンターで中央アメリカのエスノグラフィーを専門にされている教授は、現場力を

実践の現場で人が協働する時に育まれ、伝達することが可能な技能であり、またそれと不可分な対人関係的能力などの総称

と定義した上で、

現場力は、現場にある物理的な力だけでも、個人に備わる能力だけでもない。その両方の性質を有するものである。言い換えると、現場力は、現場にあるのでも、個人にあるのではなく、現場と個人がマッチした場に現れる、人間の具体的な技能ないしは具体的な能力のことである

と指摘している。

ビジネスの場でも、「現場力を鍛える」という本を著作され、現場力に関する深い考察を行われている早稲田大学の遠藤功教授をはじめ、いろいろな現場力の定義があるが、おおむね広い意味では、この池田先生の定義の範囲に収まっている。

池田先生の定義のポイントは、現場力を現場にある物理的な力（ビジネスでいえば、たとえばオペレーションや仕組み）と個人がマッチしたときにあらわれる「ダイナミック」な能力だと捉えている点にある。つまり、現場力はスキルではなく、コンピテンシー（行動力）である。この点がポイントだ。

したがって、我々も、この定義の上で、プロジェクトマネジャーの現場力について考えてみたい。

【補助線】ＰＭＯが標準を提示する意味

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

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

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

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

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

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

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

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

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

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

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

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

◆ＰＭＢＯＫの価値

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

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

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

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

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

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

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

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

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

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

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

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

【補助線】トラブルプロジェクトを安定化することの難しさと重要性

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

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

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

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

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

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

◆はまるパターン

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

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

◆あせりは伝染する

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

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

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

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

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

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

◆佐々木正と和田富夫

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

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

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

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

◆液晶にみたビジョン

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

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

◆電卓の鬼

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

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

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

◆液晶が電卓を救う

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

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

◆独断発注と事後承諾

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

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

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

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

【補助線】ウォークマンを作った日本人は、なぜｉＰｏｄが作れなかったか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【補助線】「標準」再考

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

◆標準とは何か

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

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

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

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

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

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

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

◆「適正な適用」とは？

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

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

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

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

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

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

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

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

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

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

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