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

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

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

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

■回答者業種ベスト３
　（１）ＩＴ　５２％
　（２）製造業　２６％
　（３）コンサルタント業　５％

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

■職種ベスト３
　（１）プロジェクトマネジャー　３２％
　（２）エンジニア　２２％
　（３）支援スタッフ　１４％

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

■プロジェクトマネジャー育成に重要な一手　ベスト３
　（１）経験　５４％
　（２）上司、メンターの指導　２１％
　（３）コミュニティ活動　８％

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

■研修日数
　（１）３日以内　４０％
　（２）なし　３０％
　（３）５日以内　２０％
　（４）６日以上　１０％

※むう～、研修は受けないという人が２位で、全体の３０％いらっしゃいます。

■受講したことのある研修ベスト３
　（１）ＰＭ基礎知識　２３％
　（２）ＰＭＢＯＫなどの標準手法　１９％
　（３）リスクマネジメントなどの個別テーマ　１６％

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

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

１０月４日までやっています！

正しいＰＭＯの作り方

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

◆ＰＭブームからＰＭＯブームへ

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

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

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

◆ＰＭＯに注目すれば何が変わるのか？

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

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

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

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

◆課題解決型のＰＭＯの設立を目指す

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

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

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

◆ＰＭＯの設立は毒になるケースがあるので要注意！

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

ＰＭコミュニティ考

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

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

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

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

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

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

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

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

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

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

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

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

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

　「PMBOKは叡智か陰謀か」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

倉科遼「夜王」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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