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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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