« 2007年2月 | メイン | 2007年4月 »

2007年3月

2007年3月29日 (木)

【補助線】プロジェクトマネジャーのIO比

今年度の仕事も一段落した。昔ほどではないが、新年度の仕事が立ち上がるまでのこの時期は貴重な充電期になる。

評論家の立花隆氏がよくIO比という言葉をよく使う。インプット(I)とアウトプット(O)の比で、IO比が高ければ高いほど、情報がつまったいい仕事と評価することができるという話。立花氏が評論活動をする際に品質保証のために保っているIO比は100:1だという。

比のとり方はいろいろだと思うが、100:1というと、例えば、100冊の本を読んで1冊の本を書く。1000時間の取材をして、10分間の講演をする。こんな感じ。凄い密度である。

IO比は、知識労働のバランスシートといってもよいだろう。

10年くらい前に立花氏の著作でIO比の話を読んでそれ以来、IO比というのを結構気にしている。コンサルをやっている限り、せめて30:1くらいのIO比は保ちたいと思っている。30:1を切ると、危険水域だと思う。

30:1のイメージだが、例えば、

 1時間の話をするのに、最低30時間の調査や取材をする
 1時間のコンサルをするのに、最低30時間の類似経験をする

など。コンサルのインプットは、たぶん、経験と情報だと思う。できれば、経験20、情報10くらいのIO比を保ちたいと思っている。

気をつけているのは、バランスだ。経験0、情報30というのは論外だが、逆に、経験30、情報0になってしまうと30:1のIO比でも別の意味で危険水域に入ると思っている。サスティナブルではなくなる。サスティナブルであるためには、何よりも、経験と情報のバランスが大切だと思っている。

ただし、経験というのは曲者で、仕事すべてが経験になるわけではない。十分の一もあればいいところではないかと思う。すると、30時間の経験をしようと思えば、300時間くらいの仕事をしなくてはならない。これは結構なものだ。

ちなみに、セミナーのようなパッケージものをつくる場合には、IO比をあげるようにしている。50:1くらいを目標にしている。例えば、7時間のセミナーを作る際には、350時間の調査、経験をベースにするように心がけている。

さて、マネジャー。日本の平均的なマネジャーのIO比というのはどのくらいだろうか?まず、目立つのは1:1、あるいは、せいぜい、2:1くらいのIO比でやっている人が多いことだ。マネジャーやシニアマネジャーになってくると、仕事をしても、ほとんどアウトプットだ(それでなくては給料分の仕事はできない)。従って、仕事はほとんど経験(インプット)にならない。そこで、1は情報を中心にほそぼそという感じになる。どこかで断片的な話を聞いてきたら、そのまま試してみるの繰り返しっていう感じか?

ただし、これでいいかというと要注意。大企業だと問題が顕在化しないが、中小企業だとこのタイプの社長がやっている企業はまず成長しない。大企業でもこのようなマネジャーは確実に組織を蝕む。

ここで、プロジェクトマネジャーについて考えてみよう。IO比はどのくらいでありたいか?専門職であることを考えると、5:1とか、可能なら10:1のIO比は保ちたい。あなたのIO比はどのくらいだろうか?一度、計算してみてほしい。

ちなみに、プロジェクトマネジャーにとって、インプットになる経験(プロジェクト)は以下のようなものである。

組織にとって新しい課題解決となるプロジェクト
火消しの仕事
大規模化、クライアントの多様化したプロジェクト
見本となる人との出会いの中でやるプロジェクト
同じ価値感、異なる価値観の人とやるプロジェクト
失敗プロジェクト
プロジェクトマネージャーの交代が起ったプロジェクト
メンバーの業績に問題のあるプロジェクト

2007年3月27日 (火)

MBAフェロー

先週、土曜日に、母校神戸大学の経営学部の大学院で、「MBAフェロー」というボランティア活動をした。

この活動は、OBの中から20名ほど選ばれたフェローが現役の学生さん(ほとんど社会人)のゼミに参加して、いろいろとアドバイスをしたり、意見を交わすという活動だ。

神戸大学のMBAコースは発足してもう20年近くになるが、比較的古い世代のOBから選ばれたようで、みんな、卒業後、10年以上といった感じ。

好川が参加してきたのは、松尾博文教授のゼミで、SCMとか、製品開発を中心にやっているゼミ。

好川がMBAのコースに行ったのは95年だが、この当時は学生のほとんど中堅・中小企業だった。大企業は、欧米のMBAコースに留学に出すからだ。

ところが今回、参加してまずびっくりしたのは、大企業ばっかりだったということ。関西を代表する大企業は一通り来ているような様相だ。聞けば、最近では、海外留学はほとんどなく、国内留学が主流になってきたとのことで納得。

これがいいかどうかはともかくとして、まあ、学生の質は高く、議論は刺激があって面白かった。

フリーディスカッションをする機会があって、プロジェクト組織の作り方で激論になった。特に、武田製薬、松下電器、任天堂の方との議論が印象深かったが、なんにしても、MBAコースに来ている人がこれだけプロジェクトマネジメントに興味をもっていることが分かったのは収穫だった(製品開発のゼミというバイアスがあるが、、、)

日本のMBAコースにもプロジェクトマネジメントの講義を入れるべきですね。

MBAフェローについてはこちら

2007年3月26日 (月)

【補助線】事前の責任と事後の責任を区別する

以前、メルマガで書いたことがあるが、プロジェクトマネジメントにおける責任には、アカウンタビリティとレスポンシビリティがある。

第131回 アカウンタビリティとレスポンシビリティ
http://www.pmos.jp/honpo/note/note131.htm

問題は、どこで責任を明確にするかだ。

例えば、リーダーが自分のチームのメンバーの設計作業の成果物をきちんとレビューしていなかった。そのため、その設計を受けた後段の作業が少し混乱してしまった。ミーティングでは責任追及が始まった。メンバーが悪いだとか、リーダーが悪いだとか。

結局、「組織だからリーダー」がきちんとチェックすべきだという結論になった。

この例で本当に悪いのは誰か?

プロジェクトマネジャーである。事前にリーダーやメンバーの責任を明確にしていない。最低でも、マネジャー - リーダー という体制であれば、リーダーのマネジメントRAMだけでも明確にしておく必要があるのにそれを怠った。ここに問題がある。

プロジェクトでは責任を明確にしなくてはならない。しかし、問題が発生したときに犯人探しをしても問題解決にはならないという。犯人探しをしている時間があれば、その時間で問題の収拾にかかった方が賢明である。そういう教訓である。

どこに間違いがあるかというと、事後に責任を明確にしようとしていることだ。プロジェクトマネジメントで責任をはっきりしなくてはならないのは、事前の責任である。事前の責任をあいまいにしておいて(というか、何かあったらみんなで協力してことに当たろうと誓っておいて)、何か起ったら責任追及をする。

熱さに懲りて膾を吹くではないが、責任追及をしていると、雰囲気が悪くなるので、コトが起きても責任を追求しない。こうなると最悪だ。

PMBOKにプロアクティブという概念がある。PMI流プロジェクトマネジメントの根幹をなす概念である。プロジェクトマネジメントの根幹を成すといってもよいかもしれない。

アカウンタビリティについてはステークホルダマネジメント、レスポンシビリティについてはその名のとおり、RAMといった優れた責任定義のツールがある。このようなツールを使って、必ず、計画段階で責任を明確にしておく。これがプロジェクトマネジメントの本質である。

ちなみに、事後の責任は「連帯責任」が正しい。明らかにあるメンバーのミスでも連帯責任であるし、プロジェクトマネジャーのミスもメンバーとの連帯責任である。事前の責任の明確化の必要性と、事後の連帯責任という認識があって初めて、チームマネジメントというのが必要になってくる

2007年3月23日 (金)

PMサプリ69:なぜが見えなくなったときが危ない

「なぜが見えなくなったときが危ない」(ミシガン大学教授 ジェフリー・ライカー)

【効用】
・PM体質改善
  リスク管理力アップ、自信をつける、顧客感度アップ、問題解決能力向上、
・PM力向上
  ピープルマネジメント力向上、チームをまとめる力の向上、リスク対応力向上
・トラブル緩和
  モチベーション向上、チームの士気向上

【成分表示】
◆「なぜが見えなくなったときが危ない」は組織文化
◆非定型業務での「なぜが見えなくなったときが危ない」
◆「なぜが見えなくなること」を防ぐには
◆なぜを理解せずにノウハウを使うのは危ない

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

2007年3月19日 (月)

【補助線】プロジェクトと計画

先日、リカバリーについて述べたが、もうひとつ、リカバリーに関連してはっきりさせておきたいことがある。

プロジェクトと計画というのを分けて考える必要があることだ。リカバリーという言葉は、

 ・プロジェクトのリカバリー
 ・計画のリカバリー

という両方の意味で使われるが、この2つは全然意味が違う。前者は目標変更であり、後者は計画変更である。

実は、この区分が必要なのはリカバリーだけではなく、リスクである。リスクにはプロジェクトリスクと計画リスクがある。プロジェクトリスクはプロジェクトのゴールに影響を与えるリスクであり、計画リスクは計画の実行に影響を与えるリスクである。

例えば、技術リスクを考えてみよう。製品の構成技術が実現できないかもしれないというリスクはプロジェクトリスクである。これに対して、設計を効率化する技術に問題が生じるかもしれないというリスクは計画リスクである。

PMBOKでいえばプロジェクトリスクが存在している場合には、そのリスクは回避しないとプロジェクトを開始することはできない。プロジェクトリスクの多くは、プロジェクトに責任はなく、プロジェクトスポンサーが解決すべきリスクが多い。ちなみに、よく、「リスクをとる」という言い方をするが、これはプロジェクトリスクをとることを意味する場合が多い。リスクはどこまで行ってもリスクであり、リスクが起らないことにかけるわけだ。このような場合、リスクモニタリングをいくらしても仕方ない。この手のリスクが運悪く発生した場合には、プロジェクトリカバリーが必要になる。

これに対して、計画リスクは、可能性が大きい、あるいは、計画に対する影響が大きければ、計画の見直しという形で着手前に対応するが、それ以外の場合には、軽減措置をとった上で受容することが多い。しっかりとモニタリングすれば、マネジメントで解決できる範囲にあるからだ。これがリスクマネジメントであり、発生した場合には計画のリカバリーを行うことになる。

実際のプロジェクトを見ていると、プロジェクトリスクはかなり慎重に検討しているが、計画リスクはあまり考えていないケースが多い。計画そのものがそんなにクリティカルではないのでこれで済んでいるが、はやり、ここを何とかし、脂肪のない計画を作りたいものである。

それはそうとして、このプロジェクトと計画の区別がきちんとできることが、大局観の第一歩であることをよく認識しておきたいものだ。

2007年3月17日 (土)

【補助線】プロジェクトの安定性を見極める

先日、PMOリーダー養成講座の中のリカバリーマネジメントのセミナーを行った。このセミナーは、かれこれ、5回くらいやっているのだが、初めて満席になった。

PMstyleが提案しているリカバリーマネジメントは、「安定化」と「そのあとの計画変更」を明確に分けている。

安定化の話をするには、どのような場合にマネジメントが必要かということを整理しておく必要がある。プロジェクトのある時点で、ベースライン計画との差異があるという状態は、代表的には2つのケースがありうる。ひとつは、徐々に差異が大きくなっているケース。もうひとつはどこかでドンと差異が生じてしまって、それをそのまま引きずってしまっているケース。

例えば、スケジュールを考えてみてほしい。プロジェクト期間の3分の1が終わった時点でベースラインと10%の差が出てきたとしよう。前者であれば、結構、大変な状況である。ほっておくと、おそらく、15%、20%とだんだん、差が大きくなってくると考えるのが自然である。このようなクリープ的状態では原因すら分からないことが多い。あるいは複合原因であることが多い。

これに対して、後者である場合、例えば、初期のリソース調達の問題で、着手が10%遅れた。そして、それがそのまま残っているような場合だ。この場合はそんなに心配するような状況ではない。

この区別をせずに計画変更をしようとするとどうなるか。前者の場合は、計画変更をしてもまず、うまく行かない。スケジュールが遅れているからといって、要員の追加投入をして失敗するようなケースはほとんどこれ。

例えば、このケースの一因に必ずといってよいくらいあるのはコミュニケーションや人間関係の悪さである。そこに、追加要員を投入したらどうなるか。言うまでもないだろう。

これに対して、後者では、適切な時期に、予定通り納期を達成するための手を打てばよい。この場合、コストに対する自由度が出てくる。状態として問題であることは問題なのだが、その中でも回復コストを最適化する余地があるのだ。

このように考えると、まず、最初にすべきことは、プロジェクトが安定か、不安定化を判断することだ。安定な場合には、問題があってもその問題を解消する方法を考えていけばよい。不安定な場合には安定化が必要になる。

ところがプロジェクトマネジャー側の問題というのがあって、状況をよいように解釈したがるのだ。プロジェクトが不安定な状況で、例えば、これから3ヶ月の間にリカバリーしますといってみても信用できるはずはないのだが、そういうことを言う。「ひとつ上のプロマネ。」はなぜそうなったかは別にして、プロジェクトが安定か、不安定かの判断をしっかりとできるようになる必要がある。

どうするかって?セミナーにお越しください!(笑)

プロジェクトリカバリーマネジメント

http://www.pmstyle.biz/smn/recovery.htm

2007年3月16日 (金)

PMサプリ68:重要な仕事を選択する

重要な仕事を選択することのほうが、仕事のやりかたよりも重要である(リン・スニ
ード、ジョイス・ワイコフ)

【効用】
・PM体質改善
  アカウンタビリティ向上、実行力向上、問題解決能力向上
・PM力向上
  プロ意識の向上
・トラブル緩和
  チームの士気高揚

【成分表示】

◆価値観に基づく時間管理
◆やるべきことの選択ができるとプロジェクトの成功確率があがる
◆ステークホルダが共通の価値観を持つ

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

2007年3月12日 (月)

【補助線】セーラー服と機関銃

3月8日にプロジェクトプロの峯本さんをお招きして、第2回のPMstyleスペシャルセミナーを実施した。今回のテーマ「内部統制とプロジェクトマネジメント」は、あまり、食いつきのよいテーマではなかったが、それでも、30名近くの方にご参加頂いた。お越しいただいた方、本当にありがとうございました。

食いつきの悪かった理由で、何人もから指摘されたのは、「内部統制プロジェクト」の話、あるいは、内部統制プロジェクトのマネジメントの話だと思ったというもの。ある知人が言った言葉が印象に残った。「プロジェクトマネジメントと内部統制」って「セーラー服と機関銃」みたいな印象を受けるテーマだとか。。。むう

だれもプロジェクトマネジメントで内部統制ができるとは思っていない。でも、、、

これは今後の反省点になった。確かに内部統制プロジェクトでもプロジェクトマネジメントは重要だが、内部統制としてのプロジェクトマネジメントはその数十倍重要なテーマだろう。

それはそれとして、峯本さんの話は、今まで僕が聞いた話の中ではもっともプロジェクトマネジメントの話に具体的に言及した話で、主催者としてだけではなく、一受講者としても満足なセミナーだった。

今のブームともいえるような内部統制への関心の高まりの原因になっているのは、いうまでもなく、来年の春から施行される日本版のSOX法である 。なぜ、SOX法という財務会計のシステムの健全性を規制する法律がこんなに関心を集めているかというと、実施基準(評価対象)の中に
 (1)財務報告に関する業務プロセス
 (2)事業目的に大きくかかわる勘定科目に至る業務プロセス
というものに並んで、
 (3)質的に重要な業務プロセス
という一項目があるためである。つまり、いくら財務関連の業務プロセスがきちんとしていても、それ以外の業務プロセスがきちんとしていない限り、問題になるからだ。

先日、ついに、日本での実施基準が明確になった。全般的な印象としては、米国の実施基準と比べて(3)が重視されている印象がある。これは日本人の考え方や、これまでの仕事のスタイルを考えてみると、非常に現実的だし、ある意味で、競争力の源泉になっていくことが予想されるので、評価できる。

中でも注目されるのが、非定型業務が(3)の中でも重視されていることである。非定型業務とはいうまでもなくプロジェクト業務である。言い換えると、J-SOX法が施行されると、プロジェクトマネジメントをきちんとやらないとまずいという状況が発生したわけだ。

いよいよ、日本のプロジェクトマネジメントも正念場を迎える。今までのように、形を作っておけばよいといった状況からの一段の飛躍が必要になる。このテーマは、今後、PMstyleの重要課題として扱っていきたいと思うので、ひとつ上のプロマネ。を目指す方は、ぜひ、押さえておいてほしい!

2007年3月 9日 (金)

PMサプリ67:リーダーシップを共有する

「高い業績を誇るチームではリーダーシップが共有される」(ジョン・カッツェンバ
ック、ダグラス・スミス)

【効用】
・PM体質改善
  PM体質の全般に対して効果があります
・PM力向上
  PM力向上の全般に対して効果があります
・トラブル緩和
  モチベーション向上、チームの士気向上

【成分表示】

◆ホットグループで引用されたカッツェンバックの名言
◆管理も一つの仕事に過ぎない
◆PMI流のプロジェクトマネジメントでの考え方
◆楽しく仕事ができるプロジェクトを創るには

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

2007年3月 5日 (月)

【補助線】顧客に対応することは義務、それとも権限

PMOマガジンにプロジェクトマネジャーの権限についての記事を書いていて、ちょっと迷ったこと。

それは顧客に直接対応することは権限か、義務か?という点。ベンダーに対応することは明らかに権限のように思うが、顧客に対してはどうかといわれると、権限だと思っている人はほとんどいないし、実際に権限化していないようにも見える。

プロジェクトマネジャーの権限というのは多くの人が言うが、そもそも、義務と権限というのは何かという議論もある。プロジェクトマネジャーの権限とは、プロジェクトを成功させる上でプロジェクトマネジャーに意思決定をさせるべきものである。義務とは組織のガバナンスを維持するために行う仕事である。この話を組織ガバナンス(業務ガバナンス)の議論がごちゃまぜになっているので、話がややこしくなっている。

例えば、調達の決裁を考えてみよう。大雑把にいえば、調達内容に関する意思決定と調達方法に関する意思決定がある。一概には言えないが、調達方法によってプロジェクトの成功に大きな影響があるケースは珍しい。ところが、調達内容の意思決定は成果物に大きな影響があるし、成果物そのものだといえるケースも少なくない。

このような場合、調達内容の決定に関する権限委譲はするが、調達方法に関する権限委譲はしないというのが妥当な線だろう。ところが、このような整理をせずに、調達に関する権限委譲をするかどうかを議論するので話がややこしくなる。

さて、では、顧客に直接対応することは権限か、義務か。僕は権限だと結論したのですが、みなさんはどちらだと思いますか?

お客様がいない場合には、仮想顧客になるステークホルダで考えてみてください。

PMstyle 8月~19年3月公開講座(★:開催決定)

PMstyle facebook

Twitterアカウント(PMstyle)

カテゴリ

Googleメニュー

  • スポンサーリンク
  • サイト内検索
    Google

最近のトラックバック

Powered by Six Apart

プロフィール

フォトアルバム

好川哲人

技術士&MBA 技術経営のコンサルタントとして、数々の新規事業開発や商品開発プロジェクトを支援、イノベーティブリーダーのトレーニングを手掛ける。「自分に適したマネジメントスタイルの確立」をコンセプトにしたサービスブランド「PMstyle」を立上げ、「本質を学ぶ」を売りにしたトレーニングの提供をしている。