前回「プロマネの悩みは誰が解決すべきか」では、プロマネの悩みはプロジェクト・マネジメントよりも職制的に上位のレベル、“すなわち通常の用語では「プログラム・マネジメント」レベルでこそ対応すべき仕事である”と書いた。
ところで、今回はまったく逆のことを書こうと思う。すなわち、プログラム・マネジメントはプロジェクト・マネジメントの上位概念ではない、という話題だ。なぜこんな矛盾したことを書くのかというと、それは国際標準の概念規定に、じつは目に見えない混乱があるためだ。でも、まずは(いつものように)ちょっと別のエピソードから入って、斜めの角度でこの問題にアプローチしてみたい。 先週わたしのところに、プロジェクト部門から電話がかかってきて、「佐藤さん、出張精算書を今週中に必ず提出してください」と催促があった。先月中旬、そのプロジェクトの用件で中東に一泊三日の短期出張に出かけたのである。他にも仕事を抱える身だったので、日曜の夜行便で出発して、月曜の午後と火曜一日だけ向こうで打合せに参加し、また火曜夜の夜行便で戻る(時差があるから水曜夜に成田帰着)、というとんぼ返りのスケジュールだった。会議の主題は、これから実行段階に入る巨大プロジェクトのリスク・アセスメントで、二日間の会議の議長として客先から呼ばれたのである。 ところで、このプロジェクトは『実費償還契約』(Reimbursable Contract)であった。そのため、すべての出費明細をタイムリーに客先に提出して、その費用を精算してもらわなければ、お金を取りはぐれてしまう。だから、例によって事務仕事を後回しにして、ぐずぐずしているわたしのところに、督促の電話が入った訳である。 この巨大プロジェクト、わたしはプロジェクト・コントロール・マネージャーの役割で、すでに2年以上働いている。これまでにフィージビリティ・スタディ(事業化検討)と基本設計作業をやってきたのだが、震災の影響や種々の事情で2年以上もかかってしまった。これからようやくプラントの設計・調達・建設(EPC)という実行段階に入るが、プロジェクトがあまりに巨大なため(投資は1兆円近い)、全体を1ダースものスコープに分割し、別々のパッケージとして入札を行った(ちなみにわたしは、顧客の側、つまり受注者ではなく発注者のサポートとして働いてきた)。だから、この先のリスク分析をすると、どうしても各パッケージ間のインタフェース調整にリスクを見ざるを得ない。 ところで、これまでの基本設計段階は、ずっと実費償還契約だった。一方、この先、実行段階での各パッケージの受託企業は全て一括請負契約(Lump Sum Contract)である。なぜ、段階ごとに契約形態をかえるのか? 答えは単純である。基本設計段階では、どのようなプラントの構成にして、何をどれだけ生産するか、まだ目安程度しか決まっていない。だから設計にはいろいろな、オープン・エンドな可能性がある。したがって、設計が完了するまでにどれだけの工数がいるのか、精度をもって見積もることができない。もし、これを一定金額の請負契約にしてしまうと、肝心の設計を詰める段階で、工数上限を理由に手を抜かれないとも限らない。だから、「使用した工数と経費の分だけ、一定のマージンをのせてペイバックする」実費償還契約が現実的なのである。ところで、いったん基本設計が完成すれば、もう実行段階のスコープは確定し、かなりの精度で費用を見積もることができるようになる。だから、実行段階は一括請負契約が合理的になる。 さて、ここで一つ問題を提出しよう。「プログラムとは複数のプロジェクトを束ねたもの」という概念が正しいとするならば、このプロジェクトは実行段階に入って、プログラムへと質的に変化した、ということになる。これは本当だろうか? プログラムとかプロジェクトといった用語・概念は、'60年代米国のアポロ計画のあたりから使われるようになった。アポロ計画自体は、プログラムである(=The Apollo Program)。プログラムの下に、アポロ1号、アポロ2号、などロケット打ち上げに関する個別ミッションがある。これが「プロジェクトProject」と呼ばれた。プロジェクトはさらに、設計・製作・飛行などの「フェーズPhase」(あるいはActivity)に分解される。このように、巨大な事業全体を、構造的に分解して、管理していくのは、米国的思考法の得意とするところだ。 アポロ計画がスタートしたとき、最終目標は「10年以内に月面に人間を送る」だったが、それ以上の明確なスコープも詳細な予算も、まだ存在しなかった。つまり、オープン・エンドな事業だったのである。それを逐次的に具体化・詳細化していくために、複数のロケット打ち上げプロジェクトを積み重ねていく方法がとられた。つまり、アポロ・プログラムは複数プロジェクトを時系列的にたばねたものである。先行プロジェクトと後続プロジェクトの間には、直前に達成された成果にもとづくフィードバックがあった。全プロジェクトのスコープが最初からきっちりと確定していた訳ではなかった。 「プログラムとは複数のプロジェクトを束ねたものである」と定義するとき、それが同時的バンドルを意味するのか、時系列的バンドルを意味するかについては、実は相当な質的開きがあることに注意してほしい。プログラムが事業として、外部環境の変化、あるいは内部での能力・知識の成長とともに、適応的に発展していくためには、どこかにフレキシビリティーがなければならないはずである。時系列的なプロジェクトの集合で、かつプロジェクト間にフィードバックが存在するなら、たしかにそこに変化への柔軟性や進化が見られるだろう。 他方、巨大な事業を同時に複数のプロジェクトに分解する場合、そして各プロジェクトのスコープが皆確定している場合、どこにフレキシビリティーが保証されるのか? プロジェクト間の相互調整的なインタフェースだけでは、はなはだ限定的であることが分かるだろう。 ちなみに、日米欧の三国は、プログラムをどう定義しているか。米国Project Management Institute (PMI)、英国Office of Government Commerce (OGC)、そして日本プロジェクトマネジメント協会(PMAJ)の標準書から、それぞれ引用してみよう: 米国PMI: The Standard for Program Management (2008) A Program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. 英国OGC: Managing Successful Programmes (2007) A temporary flexible organization created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits to the organization's strategic objectives 日本PM協会: 新版P2M標準ガイドブック (2007) 使命(ミッション)を実現するために、複数のプロジェクトが有機的に結合された事業。 - 「大規模システム型プログラム」と「戦略型プログラム」(創出・変革型)とに分類される(定常業務はサービスプロジェクトとして位置づけられている)。 文言はある程度似通っているが、標準書全体の文脈を含めて読み取ると、米国ではプログラム=「巨大なプロジェクト」というとらえ方が強いが、日欧では「事業を創出する諸活動」との文脈でとらえる傾向があるように、わたしには思える。その違いは、すなわちオープンエンドな、変化への適応能力(Adaptive Solution)の差違である。複数のプロジェクトを同時的にバンドルしても、それが主体的な適応能力や、スコープ・バウンダリーの拡がりを支援するものでない限り、それは「プログラム」の名前には値しないと考えられる。 逆に言うならば、別段、複数プロジェクトの形に分割されていなくても、そこに適応能力とフレキシビリティーを支える仕組みがあれば、それはプログラム・マネジメントだと呼んで良いだろうと、わたしは思う。いいかえれば、生みだす成果物の価値に応じて、スコープや、納期や、必要予算の枠さえ拡大できるような主体性の強さである。ただし、そうなると、WBSとかPERT/CPMとかEVMSとか、明確なスコープ・バウンダリーを前提するプロジェクト・マネジメント技法はそのままでは適用しづらいだろう。だから、ある程度、“固いスコープ”の部分と、“柔らかでオープンエンド”な部分を有機的に組み合わせていかざるを得ないだろう。 いずれにせよ、プログラムであるかどうかは、実行する側の主体性の強さによって定義すべきだとわたしは思うのである。
by Tomoichi_Sato
| 2012-07-01 22:03
| プロジェクト・マネジメント
|
Comments(1)
|
検索
カテゴリ
全体 サプライチェーン 工場計画論 プロジェクト・マネジメント リスク・マネジメント 時間管理術 ビジネス 思考とモデリング 考えるヒント ITって、何? 書評 映画評・音楽評 English articles 最新の記事
記事ランキング
著書・姉妹サイト
ニュースレターに登録
私のプロフィル My Profile 【著書】 「世界を動かすプロジェクトマネジメントの教科書」 「時間管理術 」(日経文庫) 「BOM/部品表入門 (図解でわかる生産の実務)」 「リスク確率に基づくプロジェクト・マネジメントの研究」 【姉妹サイト】 マネジメントのテクノロジーを考える Tweet: tomoichi_sato 以前の記事
ブログパーツ
メール配信サービス by Benchmark 最新のコメント
ブログジャンル
画像一覧
|
ファン申請 |
||