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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プロジェクトという箱から出よう

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

プロジェクトマネージャー養成マガジンの次の書籍読者プレゼントは

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

の予定だ。自分の箱に閉じこもって、箱に外にいろいろと影響をするようなリーダーシップでは本質的な問題解決にならず、自ら箱の外に出て、影響を与えていくようなリーダーシップと、そのためには、問題の原因はすべて自分にあるという考え方が重要であるということをストーリー形式で書いた本である。

この本の指摘はプロジェクトマネジメントにとって非常に有益である。プロジェクトマネジメントではしばしば、チームビルディングなどでチームに視点が偏りすぎるために、ついつい、箱の中からプロジェクトステークホルダに対応することが多い。極端な場合には、本来、プロジェクトチームに片足入っているはずのプロジェクトスポンサーすら、箱の外から影響を与えようとすることが多い。

これによって、箱の外で付き合えば味方になるステークホルダを敵に回しているようなケースがおおいのだ。

さらに、チーム内でもプロジェクトチームの中でも、プロジェクトマネジャーが箱の中にいてプロジェクトメンバーを動かしているケースが多い。この背景には、スコープ区分やＷＢＳによって分業をしていることと無関係ではない。

分業をして責任範囲を明確にし、その上でチームが一丸となってプロジェクト目標をクリアしていこうという一見矛盾する考え方であるが、この矛盾をとく鍵が「箱から出ること」にあるのではないかと思う。

箱から出る鍵は、自己原因性（Personal Causation）にある。自分原因説を唱える人も少なくないが、これだ。

プロジェクトチームとステークホルダの間、チームメンバー間、チームメンバーとプロジェクトマネジャー間、いずれも、責任転嫁の嵐が吹き荒れているプロジェクトが多い。しかし、責任転嫁は何も生み出さない。問題を先送りするだけである。

例えば、顧客が忙しくて対応してくれない。「顧客が悪いのだから仕方ない」というのは簡単だ。しかし、それでプロジェクトの状況が変わるかというと決してよくならない。

こんなときには、まず、自分たちに顧客が対応してくれない理由がないのかと考えてみる。これはＳＩのプロジェクトで実際にあった話だが、ベンダーの担当者を好きになれないので、忙しさにかまけてついつい対応が遅れるというようなことだってあるのだ。

ステークホルダとの問題においてはプロジェクト側に原因がある、メンバー間においては自分に問題があるという視点を持ってプロジェクトを進めていくと、格段にパフォーマンスはあがるだろう。

ＰＭＯの現場力

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

現場力というのがなんとなくキーワードになってきている。

現場力というのを、経験と混同している人によく会う。これは曲者だ。例えば、ＰＭＯのメンバーとして仕事をするのに、ＰＭの経験が不可欠だと考える人が多い。プロジェクトマネジャーの考えを理解する必要があるといった理由だ。

しかし、ＰＭＯの現場力というのは少し、違う。現場力というのは現場を見て、ものごとを判断する力である。上に曲者だと書いたのは、経験をすると、自分の経験で現場で起こっていることを無視して判断する危険があることだ。これは大いに気をつける必要がある。

確かに、自分が経験したことが、今、現場でも起こっている可能性はある。しかし、やっぱり違うことの方が多い。お客さんが違えば、きっと違う。ミッションが違えば、やっぱり違うだろう。経験に頼って現場の判断をするというのはかくも危険なことである。

ある意味で、昔取った杵柄で、強硬な意見をいう役員とか、ＰＭＯがそんな役回りになる危険もある。そうなったら、プロジェクトの足を引っ張るだけだ。

自分にどんな経験があろうと、謙虚に現場を見る。その上で、自分の経験を使って判断する。そういう力が現場力だ。

ここで、経験で「こんなことが起こっているだろう」と推測するのであれば、経験などないほうがましだ。

言葉がマネジメントを変える

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

文部大臣が小学生から英語を勉強させる必要はないといって、ちょっとした騒動になった。行政の一貫性を無視した発言なので、発言そのものはどうかと思うが、考え方は与したい部分がある。

英語でコミュニケーションできることはこれまでもこれからも必須である。そして、言語中枢は１０歳くらいまでにかなり出来上がってしまうので、小学生から学ばせることが望ましい。この理屈は良く分かる。

しかし、言葉というのは文化である。モノがなければ、単語はない。思考法がなければ、その思考法を具現化するレトリックはできない。典型的な例を挙げれば、否定と肯定だ。例えば、「基本的にそれでよいと思う」という言い方がある。これを英作文しろといわれれば、困る。文脈が明確な中で、合意する前提条件を明確に述べるといったことしか思いつかない。

こういう言い方はビジネスの中で論理的にものごとを進めていく際の障害になるので、歓迎されない。しかし、逆に明確にすることで問題が派生するケースがある。

例えば、顧客の要求を明確にする作業の中で、顧客が「基本的にそれでよいと思う」と言ったとすれば、「だいたい、よいと思うが、まだ自分たちにも見えない部分があるので、それを基本路線として一緒に考えてほしい」というような意味のことが多い。分からないのだから、条件として明確にかけない。しかし、書こうとするので、不完全な条件記述になる。当然、後でトラブルの元になる。こんな感じだ。

どこに問題があるかというと、言葉の背後になる行動様式の違いがあり、そもそも、それは文化に拠る部分が大きい。ソフトウエアの世界でいえば、仕様記述の問題としてワインバーグがこの問題はよく指摘しているし、ユースケースなどが使われだした理由もここにある。ユースケースは英語でも日本語でもない新しい言語ということになり、そこに新しい行動様式、思考様式を築いていこうという試みだ。

マネジメントとか、エンジニアリングでは、多くの場合、欧米から日本に概念を持ってくるので、この逆のケースがよく発生する。プロジェクトマネジメントでもそれはある。

よい意味でもっとも痛感するのがスコープ。この言葉は日本語にはない。だから外来語としてカタカタになっている。スコープという言葉を一つ導入することで、今までやってきたいろいろな工夫も説明できるので、導入に意味がある例。実際に、組織のプロジェクトマネジメントを導入すると、真っ先に普及する言葉はスコープであることが多い。今まで、もやもやしていたのが、霧が晴れたように言葉にできたのだと思う。

逆に、どうかなと思うのが、レスポンシビリティ。例えば、ＲＡＭに相当する概念は体制図だと思うが、日本的な業務運用を考えると、ＲＡＭより体制図の方が自然だし、定義する意味がある。日本的な考え方では責任とは連帯責任であり、いろいろな意味でプロジェクトを最後まで成し遂げるためにはプラスに働くことが多い。極論すれば、ＷＢＳがなくても、職務記述があれば、やってしまうのが日本の組織である。

ＰＭＢＯＫがこのやり方よりよいなどとは言い切れないだろう。民主党が農業政策として付加価値を全面に押し出した政策を主張しているが、工業の分野でも同じような特性がある。少なくとも、日本人は、このやり方で高い付加価値の商品を生み出してきた。これは日本人のＤＮＡであり、文化でもある。

このような文化の中に、不用意に新しい言葉を入れると、琵琶湖の外来魚のようになってしまう可能性がある。外来魚が従来の生態系を壊したように、その言葉が文化を壊してしまう可能性がある。

技術をどんどん、欧米から導入するのは明らかにプラスである。しかし、マネジメントを不用意に入れるのは、日本人のコアコンピタンスである現場を壊してしまう可能性が高い。そろそろ、考えるべきときに来ている。

ＰＭコミュニティ考

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

今年も１１月の最初にPMI東京のフォーラムが開催される。プログラムが発表になったので見ていたら、ずいぶん、コミュニティ色が強いフォーラムになってきた。学会は別にすると、日本の職業人のフォーラムで、これだけコミュニティ色が強いのも珍しい。

発表の大半が、研究会の成果や、会員による自主的な発表である。まさに、コミュニティの本来あるべき姿といったところだ。素晴らしい。

いろいろとご苦労もあるようだが、PMI東京の事務局、リーダの方の活動には頭が下がる思いである。

このメールマガジンもコミュニティができれば思ってやっているが、ＰＭにとってコミュニティというのは、特別な意味を持つものだ。

まず、何よりも、他社のプロジェクトマネジャーとの交流ができる。交流の中で、新しい知が生まれる。

これがなぜ、重要か？プロジェクトマネジメントは新規性との戦いである。確かに新規性の中には世の中にないといった新規性もあるが、自分の所属する企業や組織の中での新規性というのも少なくない。これはひょっとすると、他の企業や、他の組織で経験していることかもしれないのだ。

２つの同じ経験が出会えば、新しいアイディアが生まれるかもしれない。

初めて　×　経験　のコラボレーションも新しいアイディアを生むかもしれない。

いろいろな人の経験が混じり、新しい知見が生まれる。そんなコミュニティを作りたい。

【補助線】泥臭さの消えたプロジェクトマネジャー

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

ＰＭ養成マガジンを始めたころに、

　「PMBOKは叡智か陰謀か」

　　http://www.pmos.jp/honpo/note/note3.htm

という記事を書いたことがある。この記事についてはおそらく、メルマガセミナーなどの機会に１０人以上の人と議論をしたと思う。

この記事は競争という視点で書いているのであまり理解してもらえないままだったような印象があるが、この記事を書いたときに漠然と思っていたことが現実になってきたように思う。

この記事を書いたときに思っていたのは、日本の産業は泥臭さを捨てたらおしまいだということだった。ＰＭＢＯＫ導入にその危険を感じていた。

そもそも論を言えば、日本人はこの種の形式化をするのが下手である。というよりも、したがらないといった方が正しいかもしれない。よい例がトヨタのカンバンだ。この仕組みを、技術的に捉えなおしたのは、日本の研究者でなく、アメリカの研究者だった。

日本人の研究者の能力が云々というよりも、社会的にこの部分は守らなくてはという意識が研究者に二の足を踏ませているように思う。平たくいえば、そんな研究をしても、産業界から支援を受けることはできない。

理論化をすることは素晴らしいことだが、同時にそれは誰にでもできるようになることを意味している。ここに突入することは自殺行為だと直感的に分かっているのだ。

プロジェクトマネジメントで起こっていることはまさにこれだ。確かに、組織としての能力は上がってきたと思う。しかし、泥臭く、すごいことをやってくれるプロジェクトマネジャーが少なくなってきている。

プロジェクトＸにならないように、プロジェクトマネジメントをしましょうはいいのだが、プロジェクトＸができなくなっては話にならない。これも何度か議論した。

　「ＰＭＢＯＫではプロジェクトＸはできない、いや、できる」

アニメーションの例を引き合いに出すまでもなく、日本の強い産業は職人的なところである。思いっきり泥臭いところである。

すごいことをしてくれるプロジェクトマネジャーがなくなったことはかまわないといえばかまわない（産業的には大問題だが、、、）

しかし、プロジェクトマネジメントを生命線とする企業で起こっているもう一つの問題は、問題は、プロジェクトに現場感がなくなってきたことだ。プロジェクトマネジャーがデスクワークを重視し、泥臭さがなくなってきた。これはいくつもの組織で感じている。

泥臭さが消えたプロジェクトマネジャーにはメンバーはついてこない。それどころか、メンバーの泥臭さを否定するようなプロジェクトマネジャーすら出てきた。

そろそろ、「是正」の時期に来ているように思うが、みなさんはどう思われるだろうか？

【補助線】「夜王」に学ぶマネジメント

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

僕の好きな倉科遼氏の書いたコミックスで、夜王というコミックスがある。テレビドラマでもやっていたが、新宿歌舞伎町を舞台に一人のホストの成長を描いた物語だ。

倉科遼「夜王」

このコミックスを読んで、ホストの行動規範、思考規範に興味を持った。

二つ三つ考えてみてほしい。

（１）あなたは顧客の満足を得るのにホストのような行動ができるか

（２）あなたは派閥の長として、ホストのリーダーのようにチームのパフォーマンスをあげるがことができるか

（３）あなたは組織をまとめ、組織を拡大にするためにホストクラブの店長のような行動ができるか

（１）。何でもお客の言いなりになるホストに顧客満足は生まれない。顧客をコントロールし、自分のイニシャティブの中に引き込んで、そこで素晴らしいサービスを提供して、初めて、顧客の満足は生まれる。これ、ビジネスでもまったく一緒。

（２）。チームのメンバーのココロを掌握ができないホストに、顧客を満足するサービスは提供できない。自分のロジックではなく、相手のロジックの中で、何を支援すれば相手のパフォーマンスが上がるかを考える。これ、チームマネジメントの基本中の基本。自分のロジックの中で一生懸命どうすれば相手が動きやすいかを考えてもパフォーマンスはあがらない。

（３）。リスクがあることを察知し、しかし、あきらめない。如何にそのリスクを小さくするを全知全能を絞って考える。リスクが見えた時点で、君子危きに近寄らずこそがリスクマネジメントだといっていたのでは、組織としての成功はない。

これらはまさしく、プロジェクトやプログラムのマネジメントのコアな部分である。

【補助線】ＰＭ研修に必要な条件

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

pmstyleでは、研修に必要な条件として

【条件１】経験を意味づけ、経験に弾みをつける

【条件２】研修をスタンドアロンで完結させず、プロジェクトマネージャーとしてのアサインに連動させる

【条件３】研修をトップマター（事業部）だと認識する

の３つを掲げ、これに基づいて研修をデザインしている。

条件２は制度上実現困難な企業が多いが、残りの２つの条件はやろうと思えばできる。特に、条件１は重要だ。

経験が重要だというのは多くの人が言うが、経験はしっぱなしでは意味がない。難しい言葉でいえば概念化ができて初めて経験の意味があるし、学習につながる。例えば、失敗したときになぜ失敗したのか、うまく行ったときになぜうまく行ったのかをきちんと分析し、概念化をする。これはレッスンズラーンドの一つであるが、ここで、単にノウハウとして蓄積するだけではなく、理論との結び付けをすることが重要である。プロジェクトマネジャーに対する研修ではこれが最も重要な事項であろう。

それができて初めて、応用力のあるノウハウになるし、また、次の新たな経験につながる。例えば、自分なりに行っている進捗管理が実はＥＶと同じ原理で行っているというのはよく見かける現象である。

その際に、自分のやり方がＥＶと結びつけばＥＶの世界で発見されていること（手法）やノウハウを纏めて使うことができるようになる。そして、それらの手法を自分のやり方に加えることによってさらに、自分のやり方が幅を持つようになる。これが経験を意味づけ、さらに、経験に弾みをつけることだ。

ちなみに上のような条件を考えた弊社のトレーニングはキャリア段階にあわせ、以下の４段階としている。

【ステップ１】
プロジェクトマネジメントの基礎知識を身に付ける

【ステップ２】
プロジェクトマネージャーとしての行動規範を身につける（PMコンピテンシーの獲得）

【ステップ３】
業務の中で遭遇した問題に立ち返り、経験を分析し、必要な知識を補給する

【ステップ４】
業務経験を振り返り、自分のプロジェクトマネージャーとしての特性を知り、自分のスタイルを作っていく

ステップ３、ステップ４の段階においては上に述べたような経験の意味づけと、弾み付けができて初めて研修としての意味が持つことを忘れてはならない。しかし、この指摘をすると、多くの人は、そんな理論を持ち出さなくても分かっているし、できているという態度を取る。もう少し、謙虚にありたいものだ。

【補助線】トヨタの品質問題とプロジェクトマネジメント

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

ＷＥＤＧＥの９月号に製造業の品質問題の記事が掲載されている。

「電子化偏重・人間軽視」開発現場から崩れる製造業

という記事だ。なかなか、興味深い記事なので、機会があれば目を通して見られるとよいだろう。

この中に、プロジェクトマネジメントの立場からは気になる指摘が書かれている。

トヨタでは、この１年くらい、過去に市場に送り出した商品の品質問題に頭を痛めている。マスコミでも何度も取り上げられているように信じられないようなリコールが多発しているのだ。それを受けて、品質担当の副社長を１名増やして２名にし、さらには担当専務まで設置したが、それでも思ったような効果がでない。なぜか？

これがこの記事の問題提起である。その上で効率とコストを追求するために起こっている「開発プロジェクトでのコミュニケーション不足」があると指摘している。これはトヨタに限らない。僕のコンサルティングをしたプロジェクトでもこの問題はよく直面する。

この種の問題は極めてやっかいである。プロジェクトスコープの中に現れてきにくいからだ。自動化された設計上の問題はない。品質基準も満たしている。そのような中でも、設計者同士が議論をしていると気づく問題も多い。しかし、効率追求・コスト優先の中ではその時間がままならない。

この問題は今に始まったことではない。僕が三菱重工で仕事をしていた頃に、ＣＡＥのシステムの自動設計の開発に携わっていたことがある。このときに多くの設計エンジニアにインタビューしたことがあるが、多くの人はこの問題を指摘していた。僕流に言えば次のようなことを言っていたように思う。「設計というのは形式化できない。ナレッジベースを作っても無理。コラボレーションの中で生まれてくる部分が多い」

さて、この問題、トヨタも気づいていなかったわけでも、手をこまねいていたわけではない。記事によると、早くから問題の所在に気がつき、手を打ってきた。２００３年くらいから、開発段階における設計、生産、調達の横断的なすりあわせを強化してきたという。タラレバになるか、だから、この程度で済んでいるともいえよう。

この問題、プロジェクトマネジメント的にはどうすればよいのだろうか？

難しいのはコストと時間の制約が極めて大きいために起こっている問題で、コミュニケーションマネジメントをきちんとすればよいといった単純な問題ではない。かといって、いまさら、リードタイムや製品原価を緩くする方向に向かうというのはできない相談だろう。

このような状況で唯一の解になりうるのは、今まで真剣に考えてこなかったチームマネジメントではないかと思う。ただし、自動車メーカは製品アーキテクチャーから組織を作りこんでいるので、チームマネジメントを何とかしようといってもそう簡単にはいかないだろう。そこは悩ましい点だ。

一方で、他の業界ではこの矛盾に満ちた問題を解消できるようなチームマネジメントは比較的容易に実現できるように思うのだが、如何だろうか。

実は、この問題、マスプロダクションだけに限った話ではなく、受注生産製品でも起こっている。その典型がＳＩプロジェクトである。ＳＩプロジェクトでは、顧客コミュニケーションの悪さは目に見える形で品質の問題として出てくる。しかし、システム内部の不適合はそう簡単には出てこない。そこで、要件定義や設計時のプロセスマネジメントで品質の作りこみを行うのだが、短納期化やエンジニアのスキルの問題などでコミュニケーションの品質が落ちてきて、それが製品の品質問題になっているケースが増えている。

ＳＩの場合であれば、チームマネジメントを丁寧に行うことで、納期と品質のコンフリクトという問題は解消できる。

日本の現場の強さは、コミュニケーションの強さであるし、上流工程のさまざまな問題のバッファになってきた。実際に「現場あわせ」という言葉が象徴するように、上流工程のコミュニケーション不足を現場のコミュニケーションで解消してきた。

それができなくなってきたのだとすれば、ある意味で転機だといえる。製品開発プロセスにプロジェクトマネジメントを導入し、コミュニケーションマネジメント、リスクマネジメントなどをチームマネジメントで統合していくようなマネジメントが求められるようになってきたといえる。

【補助線】プロジェクトマネジャーは小泉的をめざせ！

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

自民党の総裁選挙が近づいてきて、マスコミがこぞって特集番組を放映し始めた。小泉という首相は非常に面白いことを見せてくれた。それは、議員内閣制でもここまでできるという限界である（本当に限界か、まだできるか、常識的限界を超えて属人的に許される限界かは分からない。おそらく次の首相が方向を決定付けることになるのだろう）。

なぜ、こんな話題を持ち出したかというと、これまでずっと述べてきた組織によるプロジェクトマネジメントのイメージは、ある意味で議員内閣制に似ているからだ。プロジェクトマネジャーは首相である。プロジェクトチームは内閣。スポンサーは与党。ステークホルダは野党や国民。

小泉以前の内閣は少なくともこのフォーメーションであった。ところが、小泉はこのフォーメーションをひっくり返した（と表面的には見える）。世論の支持を背景に、カリスマリーダーのごとく行動した。彼の行動がよいか悪いかはまだしばらく答えがでないと思うが、少なくとも、今までの首相ではフォーメーションをひっくり返すことにより今まではできなかったことをやってのけた。

プロジェクトマネジャーにはあまり権限がないと思っている人が多い。内閣総理大臣もそうだった。しかし、やればこれだけできた。問題はやり方と意志である。

大志あるプロジェクトマネジャーは小泉的を目指せ！