]1プログラム・マネジメントは本当にプロジェクト・マネジメントの上位概念なのか前回「プロマネの悩みは誰が解決すべきか」では、プロマネの悩みはプロジェクト・マネジメントよりも職制的に上位のレベル、“すなわち通常の用語では「プログラム・マネジメント」レベルでこそ対応すべき仕事である”と書いた。ところで、今回はまったく逆のことを書こうと思う。プログラム・マネジメントはプロジェクト・マネジメントの上位概念ではない、という話題だ。こんな矛盾したことを書くのかというと、それは国際標準の概念規定に、じつは目に見えない混乱があるためだ。(いつものように)ちょっと別のエピソードから入って、斜めの角度でこの問題にアプローチしてみたい。先週わたしのところに、プロジェクト部門から電話がかかってきて、「佐藤さん、出張精算書を今週中に必ず提出してください」と催促があった。先月中旬、そのプロジェクトの用件で中東に一泊三日の短期出張に出かけたのである。他にも仕事を抱える身だったので、日曜の夜行便で出発して、月曜の午後と火曜一日だけ向こうで打合せに参加し、また火曜夜の夜行便で戻る(時差があるから水曜夜に成田帰着)、というとんぼ返りのスケジュールだった。会議の主題は、これから実行段階に入る巨大プロジェクトのリスク・アセスメントで、二日間の会議の議長として客先から呼ばれたのである。Contract)であった。そのため、すべての出費明細をタイムリーに客先に提出して、その費用を精算してもらわなければ、お金を取りはぐれてしまう。例によって事務仕事を後回しにして、ぐずぐずしているわたしのところに、督促の電話が入った訳である。この巨大プロジェクト、わたしはプロジェクト・コントロール・マネージャーの役割で、すでに2年以上働いている。これまでにフィージビリティ・スタディ(事業化検討)と基本設計作業をやってきたのだが、震災の影響や種々の事情で2年以上もかかってしまった。これからようやくプラントの設計・調達・建設(EPC)という実行段階に入るが、プロジェクトがあまりに巨大なため(投資は1兆円近い)、全体を1ダースものスコープに分割し、別々のパッケージとして入札を行った(ちなみにわたしは、顧客の側、つまり受注者ではなく発注者のサポートとして働いてきた)。この先のリスク分析をすると、どうしても各パッケージ間のインタフェース調整にリスクを見ざるを得ない。ところで、これまでの基本設計段階は、ずっと実費償還契約だった。Contract)である。段階ごとに契約形態をかえるのか?答えは単純である。基本設計段階では、どのようなプラントの構成にして、何をどれだけ生産するか、まだ目安程度しか決まっていない。設計にはいろいろな、オープン・エンドな可能性がある。したがって、設計が完了するまでにどれだけの工数がいるのか、精度をもって見積もることができない。これを一定金額の請負契約にしてしまうと、肝心の設計を詰める段階で、工数上限を理由に手を抜かれないとも限らない。「使用した工数と経費の分だけ、一定のマージンをのせてペイバックする」実費償還契約が現実的なのである。ところで、いったん基本設計が完成すれば、もう実行段階のスコープは確定し、かなりの精度で費用を見積もることができるようになる。実行段階は一括請負契約が合理的になる。ここで一つ問題を提出しよう。「プログラムとは複数のプロジェクトを束ねたもの」という概念が正しいとするならば、このプロジェクトは実行段階に入って、プログラムへと質的に変化した、ということになる。これは本当だろうか?プログラムとかプロジェクトといった用語・概念は、'60年代米国のアポロ計画のあたりから使われるようになった。プログラムの下に、アポロ1号、アポロ2号、などロケット打ち上げに関する個別ミッションがある。これが「プロジェクトProject」と呼ばれた。「フェーズPhase」(あるいはActivity)に分解される。このように、巨大な事業全体を、構造的に分解して、管理していくのは、米国的思考法の得意とするところだ。アポロ計画がスタートしたとき、最終目標は「10年以内に月面に人間を送る」だったが、それ以上の明確なスコープも詳細な予算も、まだ存在しなかった。オープン・エンドな事業だったのである。それを逐次的に具体化・詳細化していくために、複数のロケット打ち上げプロジェクトを積み重ねていく方法がとられた。アポロ・プログラムは複数プロジェクトを時系列的にたばねたものである。先行プロジェクトと後続プロジェクトの間には、直前に達成された成果にもとづくフィードバックがあった。全プロジェクトのスコープが最初からきっちりと確定していた訳ではなかった。「プログラムとは複数のプロジェクトを束ねたものである」と定義するとき、それが同時的バンドルを意味するのか、時系列的バンドルを意味するかについては、実は相当な質的開きがあることに注意してほしい。プログラムが事業として、外部環境の変化、あるいは内部での能力・知識の成長とともに、適応的に発展していくためには、どこかにフレキシビリティーがなければならないはずである。時系列的なプロジェクトの集合で、かつプロジェクト間にフィードバックが存在するなら、たしかにそこに変化への柔軟性や進化が見られるだろう。プロジェクト間の相互調整的なインタフェースだけでは、はなはだ限定的であることが分かるだろう。ちなみに、日米欧の三国は、プログラムをどう定義しているか。(2007)使命(ミッション)を実現するために、複数のプロジェクトが有機的に結合された事業。「大規模システム型プログラム」と「戦略型プログラム」(創出・変革型)とに分類される(定常業務はサービスプロジェクトとして位置づけられている)。文言はある程度似通っているが、標準書全体の文脈を含めて読み取ると、米国ではプログラム=「巨大なプロジェクト」というとらえ方が強いが、日欧では「事業を創出する諸活動」との文脈でとらえる傾向があるように、わたしには思える。Solution)の差違である。複数のプロジェクトを同時的にバンドルしても、それが主体的な適応能力や、スコープ・バウンダリーの拡がりを支援するものでない限り、それは「プログラム」の名前には値しないと考えられる。逆に言うならば、別段、複数プロジェクトの形に分割されていなくても、そこに適応能力とフレキシビリティーを支える仕組みがあれば、それはプログラム・マネジメントだと呼んで良いだろうと、わたしは思う。いいかえれば、生みだす成果物の価値に応じて、スコープや、納期や、必要予算の枠さえ拡大できるような主体性の強さである。なると、WBSとかPERT/CPMとかEVMSとか、明確なスコープ・バウンダリーを前提するプロジェクト・マネジメント技法はそのままでは適用しづらいだろう。ある程度、“固いスコープ”の部分と、“柔らかでオープンエンド”な部分を有機的に組み合わせていかざるを得ないだろう。いずれにせよ、プログラムであるかどうかは、実行する側の主体性の強さによって定義すべきだとわたしは思うのである。23:32はじめまして。22:20退路を断つことです。17:48本当にその通りですね。メッセージを入力してください。