« 2006年8月 | メイン | 2006年10月 »

2006年9月

2006年9月27日 (水)

pmstyle.bizアンケート結果中間発表

pmstyle.bizで実施しているアンケートの中間結果です。コメントするとバイアスが乗るので、コメントはしません。現場を見ている実態が出ていると思います。

■回答者業種ベスト3
 (1)IT 52%
 (2)製造業 26%
 (3)コンサルタント業 5%

※だいたい、こちらで把握しているメルマガ読者の傾向に似ています。

■職種ベスト3
 (1)プロジェクトマネジャー 32%
 (2)エンジニア 22%
 (3)支援スタッフ 14%

※これも、メルマガ読者の傾向ですが、支援スタッフが増えてきました。

■プロジェクトマネジャー育成に重要な一手 ベスト3
 (1)経験 54%
 (2)上司、メンターの指導 21%
 (3)コミュニティ活動 8%

※む~、これについてはそのうち、記事を書きましょう。

■研修日数
 (1)3日以内 40%
 (2)なし 30%
 (3)5日以内 20%
 (4)6日以上 10%

※むう~、研修は受けないという人が2位で、全体の30%いらっしゃいます。

■受講したことのある研修ベスト3
 (1)PM基礎知識 23%
 (2)PMBOKなどの標準手法 19%
 (3)リスクマネジメントなどの個別テーマ 16%

※だいたい、予想通りですね

自分の考えは違うという人はぜひ!
 http://www.pmstyle.biz/20060810.htm

10月4日までやっています!

2006年9月25日 (月)

正しいPMOの作り方

◆PMブームからPMOブームへ

プロジェクトマネジメントのブームが沈静化し、地に足を据えた取り組みをする企業が増えてきたなと思ったのもつかの間、なんやら、PMOブームのような状況になってきた。プロジェクトマネジメントブームもPMOブームも根っこは同じだ。プロジェクトマネジメントがうまく行かないことにある。

話は変わるが、PMAJのP2Mの改訂に関わることになった。その入り口で、P2Mがどうすれば売れるかという議論があり、なかなか、興味深かった。P2Mはプロジェクトマネジメントとプログラムマネジメントの標準であるが、はやり、企業の多くはプログラムマネジメントではなく、プロジェクトマネジメントをきちんとやることを望んでいるという。

この感覚は僕がコンサルティングの現場で感じている感覚に近い。付け加えれば、かなりの人は、プロジェクトで起こっている問題の原因の多くがプログラムの問題であると気がついているにも関わらず、やはり、それをプロジェクトマネジメントの範囲で何とかしようする。これは単に職務権限の問題なのかもしれないが、深刻な問題であることは間違いない。

◆PMOに注目すれば何が変わるのか?

では、PMOに注目すれば何がどう変わるのか?PMOを強化するとプロジェクトマネジメントがうまく行き、プロジェクトが成功するのか?残念ながら、そうはならないだろう。その理由を説明する前に、なぜ、こういう発想になるのかを考えておきたい。

一般的に、人が問題解決を行う場合には、例外なく自分(の役割と実績)がきちんとできているという前提で進めていく。プロジェクトマネジメントの問題であれば、まずはプロジェクトマネジャーをなんとかしなくてはならないという話になる。ここで何らかの施策を行い、これ以上成果がでない、あるいは、十分に成果が出なかったという認識をすると次のフェーズに移る。これが現在の状況で、ここで、PMOが注目された。PMOを作ればなんとかなると思う人が多い。

PMOを作ること自体は無駄なことではないが、これは優先順位が違う。プロジェクトチームにはもう一つ、内部のロールがある。戦略ノートの4回あたりで述べたプロジェクトスポンサーである。

 ラインマネジャーはプロジェクトスポンサー
  http://pmos.jp/pmstyle/pmcoe/pmcoe4.html

◆課題解決型のPMOの設立を目指す

Pmo2 一通り、プロジェクトマネジメントの導入を行って、さらに、次に進もうとしたときに、まず、行うべきことは、プロジェクトが成功させるためにはプロジェクトスポンサーが何をすればよいかを真剣に考えることである。その中に、PMOを作るという話が出てくる。ただし、何でもいいからPMOを作るということではない。プロジェクトスポンサー(多くの場合、プログラムマネジャーである)が複数のプロジェクトのマネジメントを見ていく中で、もう一つの顔である組織マネジャーの一人という立場でみて、プロジェクト単体でやるのではなく組織として取り組んだ方がよい課題が出てきたときに、PMOを作るという選択が出てくる。

実は、プロジェクトマネジメントの導入というのは本来はこの文脈で出てくるものだ。プロジェクトスポンサーがプロジェクトマネジメントの導入の必要性を感じ、それを組織マネジャーの立場でPMOを作り、展開していったケースが多い。

そのように考えると、PMOにどのような機能を持たせるかを他社がどうだといった理由で分析してみてもほとんど意味がない。考えるべきことは、自社のプロジェクトマネジメントの問題を分析し、それに併せて、PMOの機能を設計することだ。

◆PMOの設立は毒になるケースがあるので要注意!

ここで警告しておきたいことがある。プロジェクトマネジメントの導入というのはなんやかんやと言っても薬になっても毒になるケースはあまり見たことがない(導入のアクティビティが混乱して毒になったケースはいくつか知っているが)。しかし、PMOの導入は下手をするとプロジェクトガバナンスを混乱させ、毒になるケースがあるので注意を要する。

2006年9月19日 (火)

PMコミュニティ考

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

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

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

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

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

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

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

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

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

2006年9月12日 (火)

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

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

 「PMBOKは叡智か陰謀か」

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

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

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

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

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

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

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

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

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

 「PMBOKではプロジェクトXはできない、いや、できる」

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

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

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

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

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

2006年9月11日 (月)

【補助線】続・なぜ、プログラムマネジメントか?

◆フェーズマネジメントによる不確実性への対処

PMBOKをよくご存知の方なら、フェーズという概念があることはご承知の通りだろう。例の立ち上げ、計画、実行、統制、終結というプロジェクトマネジメントライフサイクルはフェーズにFukakujitu 対するものである。したがって、一般的には一つのプロジェクトにおいては複数のフェーズが存在し、フェーズを実行する中で次のフェーズにおける不確実さを拭い去っていき、状況を(前提条件、制約条件など)を明確にし、徐々に進めていくことになる。

逆にいえば、プロジェクトの最初の段階でゴールまでの計画ができるものにはプロジェクトマネジメント的手法はあまり必要ないともいえる。

◆商品開発プロジェクトにおけるフェーズ

例えば、商品開発のプロジェクトを例にとれば、最低2つはフェーズが存在する。一つは商品企画である。戦略上(経営上)の課題から開発する商品のコンセプトや機能仕様を明確にする。企画フェーズ開始の段階では、どのような商品を作るかはぼんやりしている。企画フェーズを通じて、だんだん、それを明確にしていく。明確になったものを次のフェーズである商品開発フェーズに渡す。

商品開発フェーズでは、企画フェーズからきたコンセプトや機能仕様を実現する商品を設計し、開発をする。開発フェーズの最初の段階では、実装仕様も決まっていないが、設計作業を通じてそれをだんだん明確にしていき、設計が終われば試作やフィールドテストを行い、企画フェーズで決められたコンセプトや機能仕様を満足しているかどうかを確認する。

Bunsan商品企画から商品開発に進む際に、技術的な裏づけができていないケースがある。この場合ような場合、企画の後、あるいは、企画と並行して技術検証(技術開発)フェーズを設けることが多い。

SIでいえば、要件定義 → 基本設計 → 詳細設計・開発といったフェーズを設定することが多いが、意図するところは商品開発を同じである。

◆フェーズマネジメントの限界とプログラムマネジメント

フェーズマネジメントの考え方は製品開発マネジメントの基本であるが、ここでやっかいなことがある。それはフェーズというのは(IT系の用語でいえば)ウォーターフォールを前提にしている点だ。上の商品開発でいえば、企画フェーズが終わって、その成果をインプットとして開発フェーズに渡し、開発フェーズに渡し、開発フェーズの作業を始めるという点である。このようなやり方は長時間かけて、じっくりと商品開発を行う際にはあまり問題にならないが、短期間で開発する、あるいは、商品への戦略的ニーズそのものが比較的に短期間に変化するようなケースは難しい。このようなケースでは、商品開発によるベネフィットの維持が最大の課題になる。企画フェーズである程度、設計との調整を取りながら進めていくことが要求されるし、開発中もある程度企画変更に対応しながら進めていくことが要求される。

この問題を解決するためのポイントは、各プロジェクトを独立にマネジメント(decentraized management)することである。この独立性を保証しないと、設計やデザイン、あるいは、技術的な制約に必要以上に引っ張られる。

その上で、各プロジェクトの目標を一段上から調整していくことにより、全体のベネフィットを最適化する必要がある。

例えば、ある電子商品を開発している最中に小型化のブームがやってきた。当然、デザインからは小型化という付加的な要求が持ち上がる。しかし、小型化をすればコストが上がるし、また、開発要素があり、発売時期そのものに影響がでそうだ。

ここで開発はデザインされたものを実現するといった関係をつけてしまうと、最適な判断をするのは難しくなる。おおかた、市場やユーザをたてにしたデザインの主張に引っ張られる。いくらユーザが受け入れても、競合に先を越されては意味がない、価格が高ければ売れないなどの問題が出てくる。このあたりをトータルで考えるためには、市場、ユーザ受容性、コストなどをトータルで考えて、その意思決定を各プロジェクトの目標に落とし込む必要がある。

このようなケースに、検討に値するのが、プログラムマネジメントの適用である。一つのプロジェクトをサブプロジェクトに分解し、独立したプロジェクトとしてプロジェクト間の調整を取りながら進めていく。このようなマネジメント手法が有効である。

また、これにより、技術開発のような複数のプロジェクトにまたがるプロジェクトは全体最適を考慮した進行が可能になる。その意味でも、意味がある。

2006年9月10日 (日)

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

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

408876462509 倉科遼「夜王

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

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

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

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

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

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

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

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

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

2006年9月 4日 (月)

【補助線】なぜ、プログラムマネジメントなのか?

◆ITにおけるプログラムマネジメントの適用事例

最近は企業統合が珍しくなくなっている。この際、たいてい問題になるのが、情報システムの統合である。例えば、東京三菱とUFJの経営統合ではまさに、情報システムの統合スケジュールが問題になり、監督官庁も絡んで経営統合のスケジュールそのものが二転三転したのは記憶に新しい。

この例からも分かるように、規模の大きなプロジェクトの情報システムを統合しようとすれば、数十の情報システムを統合しなくてはならないことは珍しくない。このようなときに、これを一つのプロジェクトとして行うと2~3年では到底完了しないだろう。それゆえに、このようなプロジェクトでは、全体をプログラムとして管理し、プログラムマネジメントを実施するのが当たり前になっている。

◆リードタイムの短縮を実現するプログラムマネジメント

このような話は、決して、経営統合の際の情報システムに限ったことではない。ライフサイクルがどんどん短くなっている最近のビジネスでは、工法やプロセスの工夫では思ったようなリードタイムの短縮ができず、課題をプログラムとして捉え、並列的に実行することにより、リードタイムの短縮を図ることは珍しくなくなってきた。

Juggle4_2 製品開発の世界では、従来よりコンカレントエンジニアリングという手法でリードタイムの短縮を図ってきた。コンカレントエンジニアリングは企画・開発から販売・廃棄にいたる製品ライフサイクルの全フェイズに関連する部門が、製品の企画や開発、設計などの段階に参加・協働し、同時にプロセスを進めていく開発手法である。これもある製品を開発するという一つのプロジェクトであるが、プログラムとして扱い、マネジメントを行っている。

◆プログラムマネジメントと分散マネジメント

企業の戦略があって、その戦略を実行するためにどのような課題があるかが決まる(戦略課題)。この戦略課題を実際のアクションに落とすものがプログラムであり、プロジェクトのコントロールの対象は戦略に対するベネフィットになる。そして、ベネフィットを最適化するために、複数のプロジェクトをデザインし、実行していく。

これが、P2Mなどで言われているプログラムのイメージであるが、プログラムはこのような形だけではなく、上のような形態が増えている。一方で、プログラムにすればスムーズに進むプロジェクトを強引にプロジェクトとして実行しようとして失敗している事例も目立つ。

SIプロジェクトでは何らかの形で並列開発をすることが多くなっているが、これをプロジェクトをみなして開発すると必ずといってよいくらい失敗している。スケジュール的に無理があり、タイムマネジメント、リソースマネジメントが破綻をきたしている。このようなケースはプログラムとしてマネジメントしていかないとうまく行かない。

その意味で、プログラムマネジメントはプロジェクトマネジャーにとっても現実的で重なマネジメント手法になってきている。大規模、納期の厳しいプロジェクトをマネジメントしなくてはならないプロジェクトマネジャーにとっては必須スキルだといってもよいだろう。

それだけではない。プログラムマネジメントはプロジェクトの分散型マネジメントという非常に興味深い枠組みも提供する。これについては次回!

2006年9月 3日 (日)

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

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

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

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

【条件3】研修をトップマター(事業部)だと認識する

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

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

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

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

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

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

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

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

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

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

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

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

PMstyle facebook

Twitterアカウント(PMstyle)

カテゴリ

Googleメニュー

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

最近のトラックバック

Powered by Six Apart

プロフィール

フォトアルバム

好川哲人

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