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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

倉科遼「夜王」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【補助線】プロジェクトマネジメントというギミック

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

ＰＭコンピテンシーの仕事をしているうちに、だんだん、プロジェクトマネジャーに足らないと思われるものがはっきりしてきた。

　コアマネジメントスキル

である。

プロジェクトマネジメントというのはどちらかといえば、テクニカルな色彩の濃いマネジメントである。ＰＭＢＯＫはその象徴でもあるが、「ツール」や「技法」に依存する割合が多い。

確かに、建設の仕事だとかを考えてみると、このようなマネジメントは必要なのだと思う。延べ人数で数万～数十万人の人を動かして一つの目標を達成する。このような仕事では今のようなプロジェクトマネジメントの枠組みは不可欠だろう。

一方で、今、盛んにコミュニケーションやネゴシエーションといったヒューマンスキルが注目されるようになってきている。これらに注目が集まる理由をよくよく聞いていると、マネジメントスキルの欠如をヒューマンスキルでカバーしようとしているようだ。正しいかどうかは別にして、この感覚はちょっと違う。

家を建てることに例えてみると、以下のような比喩ができる。

　基礎：コアマネジメントスキル

　デザイン（機能性）：プロジェクトマネジメントスキル

　デザイン（快適性）：ヒューマンマネジメントスキル

今、行われていることは、基礎工事が悪くて、ドアの立て付けが悪くなったときに、ドア枠をフレックスな構造にしておくことにより隙間風が入らないようにする仕掛けを作っているようなものだ。要するに、「ギミック」なのだ。

もっといえば、コアなマネジメントスキルを持たない人材がもつプロジェクトマネジメントスキルというのもギミックだという気もしなくもない。これは少し言いすぎかな、、、

「ギミック」が悪いどうかは別問題だ。

組織としての評価のポイントは２つある。一つは、その家にどれだけ住み続けるかだ。仮住まいで１０年ほど住んだら取り壊してしまうのであれば、それも一つの選択だ。

その際のもう一つのポイントは、コスト。基礎をしっかりするのと、このような「ギミック」を施すためのコストを比較し、「ギミック」の方が安いとすればそれでもいいのかもしれない。

個人のとして評価は言うまでもない。その会社が潰れても生きていかなくてはならない。基礎が大切だ。基礎がしっかりとしていれば、「ギミック」など必要ない。

「ギミック」を身につける前に、本物のマネジメントスキルを身に付けたいものですね。

新・ＰＭコンピテンシー強化術（スキル編）～プロジェクトマネジメント実践を強化するマネジメントの原理原則（リンクあり）

【補助線】エンジニアはマネジメントの資質なしには良い仕事はできない

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

プロジェクトマネジメントのあり方について

プロジェクトマネジャーにとって技術や分野の専門知識は必要である

という命題がある。

この命題が真だという人は、プロジェクトの成功が技術リスクに強く依存しているため、技術の素養がないとプロジェクトはうまくマネジメントできないという意見が多い。特に、管理職とは違うという言い方をする人が多い。

逆に偽だという人は、プロジェクトは専門家を集めて、彼らに権限委譲して行うのだから、マネジメントスキルがあればよいという意見の人が多い。

この議論はキャリアの議論としては意味があると思うが、プロジェクトマネジャーの任命やプロジェクトマネジメントの中ではほとんど無意味な議論だと思う。神学論争である。

この命題よりもはるかに重要なのは、

一人の技術者が技術者としていい仕事をするためにはマネジメントの資質が必要

だという命題である。

僕自身のコンサルタントとしてのキャリアの中で１５年間、多くのエンジニアに出会ってきたが、この命題を否定するような人材に出会っていない。この命題は明らかに真だと思う。

この理由は２つある。

一つは最近、エンジニアにもプロジェクトマネジメントのスキルが必要だという指摘の根拠になっている組織で仕事をしているからである。ただ、これはそんなに大きな問題ではないように思う。

もう一つは、自分が満足すればよい仕事だという人は別にして、はやり、自分が満足し、人からも評価されるためには、マネジメントの資質が必要になるという事実である。これは、組織に認められるからとかいったレベルではない。エンジニアの取り組む仕事で絶対的に価値のある仕事は残念ながら少ない。プロジェクトＸのような大きな仕事を見ていてもそんな数はない。

すると、すばらしい発見やアイディアを出す以前の問題として、分野の選定が極めて重要である。シーズにさえならないような分野で何をやってもそんなに認められるものではない。ニーズだけではなく、シーズもある意味で市場である。つまり、市場の認めない仕事をしても意味がないということになる。

ここでいう市場を商品市場のような狭い意味で捉えないでほしい。例えば、社内で技術開発をする場合には、自分の所属する組織なり、企業なりが市場を持っている。この市場に適応できなくては話にならない。

もう一つ、僕が持っている命題がある。それは、マネジメントの資質がある人はセルフマネジメントがきちんとできる。自らの目標発見、動機の維持、タイムマネジメントなど。これはいずれも、マネジメントの基本である。

この命題は逆も真である。セルフマネジメントができている人はマネジメントの資質もある。

このように考えていくと、画期的な仕事をできる人は市場を見つける活動と、セルフマネジメントにおいて、マネジメントの資質を持った人であるといえる。

さすがに１５年くらいの仕事をしているだけでは、イノベータに出会う機会はそんなになく、事例は少ない。それでも１０人程度はイノベーッティブな仕事をしたと評価されている人に出会ったことがある。最近の例で言えば、ウィルコムのＷ－ＺＥＲＯシリーズを開発したエンジニアは長い付き合いだが、抜群のマネジメントセンスを持っていた。

エンジニアがプロジェクトマネジメントのスキルが必要だから身につけるというよりは、エンジニアとして自らの仕事を大きく花を咲かせるためにどのようなマネジメントスキルが必要かを考えてほしい。

それがプロジェクトの成功にもつながるし、エンジニア自身の成功にもつながる。

【補助線】「こと・もの」分析でスコープマネジメント

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

プロジェクト（マネジメント）の議論をするときに、スコープを仕様というニュアンスで使っている人が多いが、ご存知の通り、これは正しくない。スコープというのは成果物と役務の相対を指す言葉だ。ＰＭＢＯＫではこれをさらに明確にし、

●プロジェクトスコープ：規定された特性や機能を持つプロダクト、サービス、所産等を生み出すために実行しなくてはならない作業

●プロダクトスコープ：プロダクト、サービス、所産に特有の機能や特性

と区別して使えと書いている。

ここまではいいと思うが、では、スコープマネジメントというのは何をすることなのか？問題はこちらだ。仕様管理、構成管理、変更管理だと思っている人が多い。これが冒頭の話。

実は、ＷＢＳがうまくかけない悩みを持つＰＭは極めて多いが、ＷＢＳは両方のスコープを統合するツールであるので、このスコープマネジメントの認識がないとまず、上手に作れない。

実際には、ここに工法（仕事の進め方）が絡む。建築プロジェクトを考えてみると分かりやすいが、ある仕様の建築物を作ろうとすれば、必ず、工法を決める必要がある。これがプロダクトスコープとプロジェクトスコープである。プロジェクトスコープとプロダクトスコープは１対１の場合も少なくない。

逆にソフトウエアなどでは自由度が高く、プロダクトスコープは厳密に管理する必要があるが、プロジェクトスコープはあまり真剣に考えない。プロジェクト見積の中でも、プロダクトスコープをベースにして見積もり、それにプロジェクトスコープの配慮を入れるというのが普通である。

実際にはプロダクトスコープとプロジェクトスコープはもっと微妙な関連にある。プロジェクトの目的を達成するためにプロダクトスコープだけを調整するのではなく、プロジェクトスコープを調整することを考える必要もある。つまり、工法の工夫だ（要員数の調整もこの中に含まれる）。

このマネジメントを一口でいえば、プロジェクトスコープで調整するか、プロダクトスコープで調整するかを工夫することより、プロセスをシンプルにし、それによって生産性を上げること。

プロジェクトスコープとプロダクトスコープの両方をマネジメントする方法を説明することは非常に難しいが、よい本を見つけた。経営工学の大家で、良い仕事をされている慶応大学の中村善太郎先生のご本だ。

この本は、仕事を「もの」と「こと」に分けて、整理し、調整することにより、プロセスがシンプルになり、生産性が上がることを書かれた本。

先生の言われている「もの・こと」分析は、例えば

　「素材」を「製品」に変える「こと」

　はじめの「もの」をおわりの「もの」に変える「こと」

として捉え、この変換過程を、「もの・こと」図として書くことによって、スコープがきれいに整理でき、仕事の最適なプロセスを見つけるという発想。これは非常に分かりやすい。

【補助線】「計画する」とはどういう行動か

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

この問題、結構、重要なのに考えられていない。

計画することをデスクワークだと考えているプロジェクトはだいたい失敗する。

　計画をするとは段取りをすること

である。つまり、計画の対象になる作業を実施する準備をすることである。

こんな例を考えてみて欲しい。

システムの受注開発をする。「計画書」に顧客から仕様が出てくると書く。その計画に基づいて、顧客にそのように対応してもらえるようにお願いをする。当然、顧客には顧客の都合があるので、素直にはウンを言わないが、そこを何とかしながら計画を実行していく。これをステークホルダマネジメントだという。ステークホルダマネジメントの甲斐なく、顧客からはお願いした通りのアウトプットは出てこない。結果として、スケジュールが遅れる。

このような状況はよくあるだろう。どこに、問題があるのだろうか？おそらく、多くの人はステークホルダマネジメントの問題をいうのだと思う。

しかし、このトラブルの本当の問題は、「計画ができていない」ところにある。計画を作るというのは、計画書に書くことのすべてについて、裏づけを取るという作業である。

どうもリスクマネジメントを導入するようになって、裏づけを取らずに、書いたことが実行できないのはリスクだと扱いたがる傾向がある。これはトンでもない間違いだ。

例えば、上の例で、顧客との間で、顧客側の具体的なスケジュールも含めて、合意をし、その通りにやってくれるという確約を取る。これは計画作業に他ならない。段取りだといってもよい。それでも、顧客の方に不測の事態が発生し、できないかもしれない。これがリスクだ。

確かに、ステークホルダマネジメントだとか、コミュニケーションマネジメントだとかが必要だというのはその通りなのだが、本当に必要なのは、計画の実行の中ではなく、計画を作るところである。

このような考え方で、pmstyle のプロジェクトマネジメント（ＰＭＢＯＫ準拠）はコミュニケーション計画を立ち上げプロセス群の中で、ステークホルダ分析を行うと同時に策定すべきだとしている。

これがプロアクティブなプロジェクトマネジメントである。