コンセプチュアル・マネジメント

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

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

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

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

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

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

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

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

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

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

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

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