2025-12-31T11:05:43+09:00 Tomoichi_Sato タイム・マネジメントとSCM専門家のエッセー・批評・考察集 Excite Blog http://brevis.exblog.jp/33553116/ 2025-03-18T10:04:00+09:00 2025-12-31T11:05:43+09:00 2025-03-18T10:04:58+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス

会議は､あっけなく終わった。「質問は？」議長がたずねたが、誰も声を上げない。それが最後の議題だったので散会となった。参加者は皆、三々五々部屋を出て行く。報告者のプロマネも、しばらくじっと黙ってうつむいていたが、自分のノートPCをたたんで静かに出て行った。ただ、わたしは呆然とした気持ちのまま､席を立つ気がしなかった。


この種類のプロジェクトが、この段階でこの状態にあるとは、まともじゃない。基本構想の仕事ならいざ知らず､すでに投資決定も下り､力仕事の段階に入っている。報告内容から見て､明らかに人も､予算も足りていない。当然､納期にも間に合うまい。ただ、プロマネ自身は､そうは言わなかった。顧客起因の重大な変更があって、進捗も遅れ気味だが､「何とか頑張ります」と言ったのだ。


会議の出席者の中には、経営層の人もいた。他のメンバーだって、昨日今日仕事を始めた人たちではあるまい。だったらなぜ、発言しないのか。「今すぐ､このプロジェクトを助けなけりゃダメだ。このまま放っておいたら大変なことになる」と。だが、誰もそうは言わなかった。実際に会議で決まったのは､問題プロジェクトなので、さらに定期報告やレビューの義務を課すことだった。


わたし自身は違う会社の人間で､たまたまオブザーバーとして後ろの席に座っていただけだから､当然、発言権はない。だが当事者の一員だったら､こう主張したくなったろう。「プロマネ一人の責任に任せて、レビューだゲートだ報告だ、などと言っている場合じゃないですよ」と。逆に自分がプロマネの立場だったら､どうするか。「こんな状態で一体、何をどうしろと言うんです!?」とでも叫ぶだろうか。




プログラム・マネージャーとプロジェクト・オーナーの圧倒的不在


モダンPMの参考書や標準書を読むと､プロジェクトは複数のアクティビティから構成され（業界によっては「タスク」とも呼ぶ）、さらにプロジェクトの上位概念としてプログラムがある､と書いてある。つまりプログラム、プロジェクト､アクティビティ（タスク）の三階層がある、という訳だ。


また、かりにプロジェクトが単独で行われ､上位にプログラムがない場合にも､プロマネの上位に『プロジェクト・オーナー』という立場が存在する､と書いてある（これも業界によってはプロジェクト・スポンサーと呼んだりもするが）。このオーナー/スポンサーの役割とはすなわち、プロジェクトを公式化し､予算枠を与え､プロマネを任命することだ。これが、連関する複数のプロジェクトを束ねるプログラムの場合だと､その仕事はプログラム・マネージャーが行うことになる。


とはいえ受注型プロジェクトは、単独で行われることがほとんどだ（複数の連関するプロジェクトを気前よくバサッと渡して、全体を任せてくれる顧客なんていやしない）。だとしたら、受注したプロジェクトの数だけ、オーナーもいるはずだ。そしてオーナーは、フルタイムでプロジェクトを面倒見ている訳ではないが、それでも遂行状態を時折ウォッチして、問題が起きたらプロマネを助ける存在である、はずである（それが任命責任というものだ）。


だが現実には､そんな上等なプロジェクト・オーナーなんかいない。プログラム・マネージャーなんか、もっと不在だ。そもそも『プログラム・マネジメント』なんて概念､社内で知る人もいないし勉強する人もいない。勉強する場所もない。――それが受注ビジネスで食べている、大方の組織の現状ではないか？




PMOとプロジェクト「管理」


そういう会社にも､PMO(Proejct Management Office)と呼ばれる組織はあったりする。PMOは何をする部門か？　一つの重要な役割は､プロジェクト・マネジメントに関する標準プロセスや仕組みを作り上げることだ。もう一つは､個別のプロジェクトで、「マネジメントを支援する」ことになっている。


支援というのは､しかし、微妙な概念だ。支援した人は､結果についても責任を持つのか？　そうではあるまい。プロジェクトの最終責任は､やはりプロマネが負うことになっている（ところが多い）。PMOが横から手を出しても、何か重要なことを決断するのは､プロマネである。そうでなければ、今度はプロマネの側がやってられなくなる。自分とは違う考えの人が､横から勝手に判断を下したら、誰が結果に責任を持つのか？


つまり、マネジメントという仕事の一番大切な部分は､「決断を下す」ことにあるのだ。状況は流動的､先行きは不確実、技術にもリスクがある。だが、何かを決めなければならない。決めるために、マネージャーがいる。いったん決めたら､それが良い結果を生むよう、周囲を動かしていかなければならない。「先を読む」「決断する」「人を動かす」――それがマネージャーの仕事だ。


もちろん、「進捗や品質やコストの状況を、正確に把握する」「報告する」も、マネジメントの仕事ではある（PMOは主にこちらを助ける）。それをしなくていい､とは言わない。だが状況把握は、より良い決断のために必要なのだし､報告はそれによって会社（チームの上位の組織）が助けてくれるからこそ、意味があるのだ。報告それ自体が目的なのではない。


実をいうと、わたし自身､PMO的な仕事を何年間もやっていた。だから、その難しさを少しは知っている。PMOはプロマネの部下ではない。その指揮命令の下で、手足として動く訳ではない。しかし、プロマネの上位にいる訳でもない。上位にいるのは（一応）オーナーだ。PMOにはプロマネへの指揮命令権限もない。


じゃあ何かというと､いわばスポーツのスコアラーなのだ。フィールドで観察し､記録する。そのデータ蓄積はとても重要だ。決断の参考にもなる。ただ、日本語ではモニタリングし記録する仕事も、『管理』と呼ぶ。わたしがプロジェクト・マネジメントを「プロジェクト管理」と呼ばないのは､この点を区別したいためだ。主体的に決断し､最後まで覚悟を決めて実行すること。それが責任あるマネジメントの姿で、上から目線の「管理」とはほど遠い。




必要なのは責任にバランスした権限である


日本のサラリーマン組織の中核問題（の一つ）は、上位マネジメントの機能不全を､現場リーダーが無理にカバーしている点にある。そう、わたしは考えている。


プロジェクトとは、スコープ・コスト・スケジュールの3つの制約条件に取り囲まれ､トリレンマの状態にある。これは製造業における生産マネジメントが､QCDのトリレンマ状態にあることとよく似ている。


トリレンマだから、どれか一つを変えようとすると､必ず他の二辺に影響が及ぶ。したがって、プロジェクト・マネージャーは、スコープ・コスト・スケジュールの3つについて、適切な手を打てるような権限が必要である。そもそもマネジメントの仕事とは､経営資源の適切な配分によって、組織のアウトカムの価値を最大化することである。もっと具体的に言えば、人員を動かし､必要ならば外部組織を動かすための金を使い、技術や設備など有形無形の資産を動員して、トリレンマを緩和することにある。


それなのに、少なからぬ組織では（とくにIT業界のSIer等では）､プロマネに予算の執行や発注の権限を、十分に与えない。トリレンマの内､コストはすでに片手を縛っている訳だ。スケジュールも、契約で最初に決まってしまう。そうなると、スコープの多少の出し入れと、チーム内の人員（再）配置だけで､なんとか成果物を出せと言っているのに等しい。


そのくせ､「プロマネは結果が全て」「成果主義人事」などと称して､利益だけで人を評定しようとする。そもそも権限のないところで、結果責任だけを評価する企業が多いのだ。


そして仕事が利益を生まず､うまくいかないと､「もっと管理すれば良い」と考える。プロマネの権限をセーブして､必要な決断を、他人が承認しないとできないようにする。プロジェクト・マネジメントをマネジメントするための、屋上屋の組織を作る。「管理」はするが、助けることはしない。マネージャーとは一国一城の主のはずだった。それを、中間管理職化してコントロールしようとする。つまり、（はっきり言って）稼げない現場のリーダーは馬鹿だ、と思っているのではないか。


「だったら一体、何をどうすればいいんですか!?」と言いたくなるところだが、プロマネだって組織人だ。そして（上が思っているほどは）馬鹿ではない。だから心の中で静かにPCを閉じて会議室を立ち去り､そんな報われない仕事を､会社を､そして業界を、優秀な人ほど見限っていくのである。


組織の形態（フォーメーション）をデザインすることが､経営やマネジメントの仕事だと思っている上級職の人は、ずいぶん多い。だが組織の形態と、評価システムのデザインはワンセットである。プロジェクトには、プロマネが自分でなんとか采配できる範囲と､自分の意思や権限が及びにくい外部環境・内部環境の変動がある。責任も評価も､その権限範囲に対応していなければならない。


そして長年、プロジェクト・ビジネスを見てきた自分だから言うのだが､とくに大きなプロジェクトは必ず外部環境の影響を受ける。期間が長いからだ。その全てを、プロマネの能力のせいにしてはいけない。もう一度言うが､「プロマネは結果が全て」などというのは虚妄である。




〈関連エントリ〉
「プロジェクトのオーナーシップとは何か」 https://brevis.exblog.jp/27925736/ (2019-01-17)


]]> http://brevis.exblog.jp/30445143/ 2023-09-20T22:56:00+09:00 2025-12-31T11:05:43+09:00 2023-09-20T22:56:24+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス


それでは、部長が課長をマネージすることも、ガバナンスなのか？　課長だって、立派なマネジメント職である（ちなみに、わたしの職場では課長職のことを、昔から「マネージャー」と言う職名でよんできた）。


答えから言うと、それは違う。確かにガバナンス的な側面も、少しはある。だが、課長は部長にマネジメントされている。部長の指示には強制力があるからである。強制力を伴う計画・指示と報告・評価のサイクルをマネジメントと呼ぶ。


強制力とは何か。それは簡単に言うと、賞罰の力である。指示に従った場合には、褒賞を与え評価する。従わなかった場合には、罰を加え、あるいはその地位から追放することができる。また、重要な経営資源の運用に関する決裁の権限も持つ。具体的には、特に金銭である。費用の支出には、承認が必要となる。それがマネジメントの強制力だ。


これに対して、取締役会が会社の執行役員や経営者に対して用いる権限は、影響力でしかない。取締役会はなるほど、役員や社長の首を切る権限がある（株主の同意が前提だが）。また、重要な予算に関しては、承認の権限もあるだろう。だが、ほとんどの決裁事項は、執行側にゆだねられている。そのかわり、大きな指針や基準を与える。これがガバナンスのあり方だ。


さて、プロジェクト・マネージャーはどうだろう。プロマネにも普通は上司がいる。課長だったり部長だったり役員だったり、その規模や役割に応じて様々かもしれない。


プロマネを任命し、プロジェクトに予算枠を与える権限を持つ者を、「プロジェクト・オーナー」ないし「プロジェクト・スポンサー」と呼ぶ。普通、プロジェクト・オーナーないしスポンサーは、執行権限のほとんどをプロマネに譲渡し、あまり日々のオペレーションに口を出さない。ただし、重要な判断や予算・配員等については、相談に乗り、プロマネを支援する義務がある。


もっとも、こうしたオーナー制（スポンサー制）を充分きちんと認識し、確立していない日本企業は、非常に多い。が、日本企業だけでなく米国企業でも、実際はその弊害をしばしば見かける。


ところで、プロマネを任命し、プロジェクトに予算枠を与え、そのスタートを承認する権限を持つ職種が、もう1種類ある。それは「プログラム・マネージャー」である。


プログラム・マネージャーとは誰か。それはプログラムをマネジメントする責任者である。・・じゃぁ、プログラムってなんだ？


プログラムとは、その配下に複数のプロジェクトを持ち、互いに調整して動かすことで、共通の事業目標を達成する活動の集まりである。


例えば、アポロ計画の英語は、Appolo Programであった。アポロ計画は、60年代のうちに人類を月に送り込む、と言うケネディ大統領の'61年の演説で公式にスタートした。そして、複数ロケットの製造と打上げを経て、次第に技術開発と実証を繰り返しつつ、最後に'69年のアポロ11号で、本当に乗員3人を月に送り込んだ。


アポロ計画では、個別のロケット打上げミッションが「プロジェクト」と呼ばれた。つまり、複数のプロジェクトを組み合わせることで、月面制覇という最終目的を達成したのである。もちろん、個別のロケット打上げ以外の活動として、地上側設備の構築、ロケット乗員の育成訓練、様々な技術開発などが並行して進められた。これらも皆、ある意味プロジェクトである。


アポロ計画を構成するプロジェクトは、最初から全て決まっていたわけではない。難しい技術開発を組み合わせた困難なチャレンジであるから、その途上で、新たなプロジェクトの必要性も生じてくるだろうし、中には不要となったプロジェクトもあったかもしれない。ただ、全体としては、相互にコーディネートされた複数のプロジェクト群によって、アポロ計画は一応見事に遂行された。


プログラムとは、何らかの目的（多くは能力獲得や価値創出）を達成するための活動で、複数のプロジェクトを組合せ、調整しながら進める。プロジェクトとは、それぞれが明確なゴールと目標をもつ、期限のある営為で、複数のActivityを組み合わせて調整しながら進める。そしてActivityとは、特定のインプットとアウトプットをもつ任務である（プロジェクトを構成する期間を表す場合は「フェーズ」とも呼ばれる）。



そしてプログラムの達成のために、配下のプロジェクトをアウトカムと価値の視点から絶えずウォッチし、ガバナンスを効かせる仕事を「プログラム・マネジメント」と呼ぶ。それはプロジェクトを起案し、発進させ、完了を見届け、あるいは途中で中止させることをも含む。


プログラムマネジメントとは言いかえるなら、配下のプロジェクトの間に、全体目的に合致したシナジーを生み出す働きである。この「シナジー」と言う用語は、あまりPMIやPMAJの標準には出てこないが、プログラムを理解する上で非常に重要である。


このような「プログラム・マネジメント」の概念は、残念ながらわが国にはほとんど輸入されなかったようだ。もともと、プロジェクト・マネジメントの概念自体、20世紀の間はロクにかえりみられなかった社会だから、当然と言えば当然かもしれない。


わたし達の社会で何かが広まり、受け入れられるためには、わかりやすい物語、スター的なカッコいい人物や企業の存在が必要だ。抽象概念だけが、世の中に広まる事は滅多にない。目に見えないことには、あまり興味を示さない人々が、大多数なのだ。


でも、当サイトのミッションは、その抽象概念を少しでもわかりやすく提供することにある（笑）。プログラム・マネジメントは、その典型例であろう。


そこでもう一つ、プログラムの例をあげよう。英国のロンドン五輪開催の事例である。彼らがオリンピック競技場を作った際のやり方は、どうだったか。2020年を目指した東京五輪の国立競技場建設の際のドタバタを思い出しながら、比較すると分かりやすい。


ロンドンのメイン・スタジアムは入場者数８万人で、規模は東京と同じだが、じつは本設２.５万人、仮設５.５万人のスタンド形式になっていた。総工費は4億8600万ポンド＝日本円でわずか644億円である（2011年のレートで換算）。それも納期内に、予算より1000万ポンドも安く完成した。


推進母体のオリンピック開発公社（略称ODA）は当初から、プログラム・マネジメント方式による取り組みを決めていた。ODAはスタジアムなど遺産（Legacy）の五輪後の活用計画を最初に作成し、本設2.5万人の構想はそこから生まれた。そして彼らは、五輪準備のためのプログラムおよびプロジェクト・マネジメントを、外部の専門家人材に委託した。かれら専門家は、配下の請負業者たちのマネジメントに携わった。


さらにODAは、他の競技場を含むプログラム全体を一元的にマネジメントするチームを設置した。このチームは、複数プロジェクト間のスケジュール、コスト、変更、そしてリスクなどを横断的に調整し、コントロールした。特に複数箇所の工事で物流が輻輳するため、物流センター３カ所の建設など、効率的なロジスティックスも考案した。


じつはロンドン五輪の準備期間は、2008年のリーマン・ショックの金融危機に重なる時期だった。業者の倒産や資材価格値上げに見まわれ、環境問題対策のための大幅設計変更もおきた。だが、適切なマネジメントと十分な予備費の設定によって見事に乗り切っている。


これに対して、日本の新国立競技場建設プロジェクトはどうだったのか？　新国立競技場整備計画経緯検証委員会は、一連の騒動の後、2015年に「検証報告書」を発表した。それによると、プロジェクトの方向性を見直すべきタイミングは、全部で3回あった。ザハ・ハディド氏の設計が最優秀案と決まった（同時にその工費が懸念された）12年11月と、下村文科相が工費3000億円に達する見込みと国会で表明した2年後の13年10月、そしてゼネコン２社が技術協力者として見積り直した、4年後の15年1月。最後の時点で、予算も納期も危いことが、あらためて明らかとなった。


にもかかわらず政府は、当初予算枠からの超過を、事後的にずっと承認し続けた。新競技場自体がライフサイクル全体でどれだけの価値をもたらすのかも、十分な評価を行わなぬままだった。


上記の検証報告書は「プロジェクト・マネージャーが不在だった」ことを問題原因の一つに挙げている（p.59）。しかしプロマネには原則として、プロジェクトを途中で中止させる権限はない。正しくは、プロマネに中止を命じる職能、すなわちプログラム・マネジメントの不在を指摘すべきであった。


プロジェクトは普通、何らかの成果物（アウトプット）を目指して動く。ただし、そのアウトプット自体は、より大きな目的を実現するための手段であることが多い。ちょうど競技場がスポーツ振興や親善という目的のための、手段であるように。


だが、わたし達がいったん、プロジェクトに配属されると、手段だったはずのプロジェクトが、いつの間にか目的にすり替わりやすい。そしてゴール到達のために、必死に頑張ることになる。あるいは、プロジェクトを提起した責任者のメンツのため、さらにこれまでプロジェクトに投入した労力と費用のために、意義の薄れたプロジェクトが無理やり続けられる。こうしたことを、わたし達はあまりにも多く眼にしてこなかったか？　それはプロジェクトに対するガバナンスの不在である。


わたしは何も、英国が日本よりすぐれているとか、東京五輪に関わった人々が無能だとか主張するためにこの記事を書いているのではない。新国立競技場に関わった多くの人が優秀で有能だったろうことは、疑いがない。だが、担当者が優秀で有能なだけでは、足りないことがあるのだ。その有能さが、価値を生み出す活動に関わるように振り向ける仕組みが、わたし達の社会には断じて必要なのである。

建設中（当時）のロンドン五輪スタジアム
（画像引用元：https://webarchive.nationalarchives.gov.uk/ukgwa/20161003115235/http://learninglegacy.independent.gov.uk/themes/programme-organisation-and-project-management/index.php ）


＜関連エントリ＞
「プロジェクトのオーナーシップとは何か」 https://brevis.exblog.jp/27925736/ (2019-01-17)
「企業経営のガバナンスとシナジーを再考する」 https://brevis.exblog.jp/30433520/ (2023-09-04)


]]> http://brevis.exblog.jp/29853806/ 2022-02-28T23:43:00+09:00 2025-12-31T11:05:43+09:00 2022-02-28T23:43:51+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス

孫武は一同に矛（ほこ）を持たせると、「お前たち、いいか。左の合図をしたら自分の左手を、右の合図なら右手を、前の合図では自分の胸を、後ろの合図で背中を見よ。」といいわたした。そして再度訓令して何度も申し伝えてから、さて大太鼓で「右！」の合図を打ったところ、うら若き女達はどっと笑いこけた。


「取り決めが徹底せず、命令が行きとどかないのは、将軍たるわたしの責任です。」孫武はそういって、再三訓令し、何度も伝えさせてから、今度は「左」の合図を打った。ところが女達はまたどっと笑った。


「すでに取り決めが徹底している以上、決まりの通り動かないのは、これは監督の隊長の罪だ」と孫武はいい、二人の隊長を斬り殺そうとした。台上から見ていた呉王は、自分の愛姫が殺されそうになったので、あわてて伝えた。「将軍が立派に軍隊を指揮できるのは、もう分かった。しかしこの二人の女は殺さないでほしい」


しかし孫武はこう答える。「自分は命を受けて将軍となりました。軍中にあっては、王の命令といえどもきけないときがあるのです」。そして見せしめのために、本当に二人の女を切り捨てた。青ざめた女達は、さすがに次の太鼓では定め通り整然と動いて、声もなかった。


「軍はすっかり整いました。王よ、おいでください。お望み通りに、たとえ火の中といえども動かせます。」奏上した孫武に対して、呉王は「・・予は気分がすぐれない。将軍は休息を取って宿舎に帰られたい。」と答える。すると孫武はこう言い放つ。


「王はただ兵法の言葉づらを好まれるだけで、実際の運用はおできにならないのですね。」


——司馬遷が「史記」に伝える、孫子の逸話である。呉王は深く恥じ、孫子を実戦の将軍に任命すると、西の大国・楚を撃破し、北の斉や晋にも威勢を示したという。


ずいぶんと剣呑なエピソードだ。だが「孫子」13巻は、今読んでも確かに面白い。「戦わずして人の兵を屈するのが善の善」（＝戦争をせずに勝つのが最上）だとか、「彼を知り己を知れば百戦あやうからず」とか、有名な言葉だが、まことに含蓄がある。


また結構数字に詳しい点も、興味深い。孫子はきちんとデータにもとづいて考え、数字をベースに作戦を立てた人だと分かる。「（謀で戦わずに勝つことなどに比べて）最もまずいのは城攻めである。櫓など城攻めの道具の準備に3ヶ月かかり、土塁の土盛りにさらに3ヶ月。その間に将軍が待ちきれずに総攻撃をかけたりすれば、兵の三分の一を戦死させて、しかも城が落ちなかったりする。これが攻の災いだ」などという。


（なお、本稿の引用は、金谷治訳注「孫子」岩波文庫版に依っている。といっても、かなり自由に改編させていただいたが、非常に読みやすい訳文で、お勧めである）


孫子が生きていたのは、春秋戦国時代の動乱期であった。古代国家・周の力が衰え、諸国乱立で戦争の絶えなかった時代である。もっとも、それから2千5百年経っても、人類は相変わらず戦争をやめないのだから、この間の進歩とは何だったのか（・・なんだか、前回記事でも似たようなことを書いたなあ）。


少なくとも、この、戦争がやめられない問題に関しては、人類のメンタリティの設計自体に、何かバグが内在しているのではないか、という疑念が生じてくる。だが、今はこの問題には深入りしないでおく。


ここで考えたいのは、Why、すなわち、なぜ戦（いくさ）をするのか、という事である。戦争目的といってもいい。最近の流行の言い方ならば「パーパス」かもしれない。


孫武は将軍だが、斉の出身者で、呉国の人ではない。呉王とは、いわば契約関係で結ばれているだけである。つまり、傭兵隊長のようなものだ。古代中国の帰属意識がどうなっていたのか、わたしは詳しくはない。だが、呉国と命運を共にする必要はないし、そのつもりもなかったろう。もちろん、実際の戦闘は命がけだが、彼が命をかけるのは自分の任務、あるいは自分の名誉のためであって、呉への愛国心ではない。


孫子の、最高の兵術家として名をなしたい、という個人的パーパスと、呉国の、領土を拡大し支配を安定させたい、という組織のパーパスが、たまたま重なり合うところに、彼の働きが成立した。傭兵隊長としての孫子、いわばプロジェクト・マネージャーとしての彼にとって、個別の戦争というプロジェクトで成功することだけが、求められる。


戦争をプロジェクトととらえ、将軍をプロジェクト・マネージャーにたとえるのは、いささか不穏当な形容だろうか。まあ、少なくともわたし個人は、ビジネスの用語や概念に、「戦略」だの「戦術」だのといった軍事用語を持ってくるのは、本当はあまり好きではない。争いが苦手な、臆病な性格だという事もあるだろう。だが、冷徹で合理的な判断を要するビジネスに、戦争用語の持つ奇妙な高揚感やヒロイズムが紛れ込むのが、いやだからかもしれない。


ただ、現代プロジェクト・マネジメントの技法や概念が、主に米国のミリタリー分野の周辺で発達してきたことも事実である。その典型例が、1950年代にポラリス・ミサイルの開発に伴って、米軍シンクタンクのRAND研究所で考案された、PERT計画手法であろう。


また、米国NASAによるアポロ計画も、モダンPM論の枠組みを推し進めるのに、大きな役割を果たした。


たとえば、「アポロ計画」全体は、プログラムである（アポロ計画の英語はApollo Program）。その下に、アポロ1号・2号・・といったロケット打ち上げという、個別のプロジェクトが並ぶ。それぞれのプロジェクトの下は、さらにロケットの設計から始まって、打ち上げ後の回収まで、フェーズがある。プログラム＞プロジェクト＞フェーズ、という周知の階層構造は、このときに概念が定まった。


アポロ計画が1961年のケネディ大統領の演説で始まったことは、以前の記事 にも書いたし、良く知られていることだ。ケネディが宣言した、「'60年代のうちに、人を月世界に送る」という目標については、当時これを聞いた多くの専門家が、「そんなの無理だろう」と思ったらしい。


「一見不可能な目標設定をすることで、人びとの挑戦心を引き出し、イノベーションを実現するのが、ブレークスルー手法である。」みたいなことを、よくコンサルタントが、ケネディを引き合いに出して述べる。だが、実際に米国人達を駆り立てたのは、このままでは宇宙競争でソ連に負ける、という危機感だった。事実、50年代終わりの時点で、ソ連は米国を宇宙開発技術で一歩も二歩も引き離していた。


だが、なぜ宇宙競争に後れを取ることが、そんなにも米国にとって重要だったのか。威信？　それもある。だが、もっとシリアスな理由があったのだ。


人類を月に送り込む、というは、ケネディがアポロ計画に設定した『ゴール』である。ゴールというのは、マラソンのゴール地点を思えば分かるとおり、そこに到達したら仕事が終わりになる地点である。


プロジェクトとかプログラムとかは、一過性の仕事だ。一過性とは終わりがあるという意味で、その終点、いいかえれば「完了条件」を定めるのがゴールだ。ゴールは、プロジェクトが何を（What）生み出すか、とか、どこに（Where）到達するか、といったことで決められる。


ちなみに、ふつうの仕事、いわゆる定常業務というのは、銀行の窓口にせよ、営業のセールスにせよ、工場での生産にせよ、毎日続けるものである。定常業務には、終わりがない。むしろ、終わらないために努力するのが、ふつうの仕事である。


ところがプロジェクトとかプログラムは、「終わらせるために努力する仕事」である。そういう意味で、定常業務とは、性質が全く違う。とうぜんながら、マネジメントの方法も相当に違う。


プロジェクトやプログラムがどういう終わり方をしたら、成功と言えるかを測る基準が、「目標」である。目標は、時間・コスト・性能など、客観的に測れる形で定義する事が望ましい。アポロ計画の目標は、「60年代内に」という時間的な期限が目標だった。コストでも、送り込む人数でもなかった。


だがケネディは、なぜ（Why）アポロ計画を始めるのか、本当の理由は言わなかった。彼は単にアメリカ人の競争心を刺激しただけだ。ある意味、多くの米国人にとっては、それで十分なのだろう（なにせ単純な人達なのだから）。


では、アポロ計画の真の目的とは何だったのか。それは軍事にあったのだ。


第一次世界大戦は、欧州を広範囲に巻き込んだ戦争だった。アメリカも途中から参戦した。そして、第一次大戦の勝敗を決したのは、『制海権』＝海上の支配権、だった。英語で、Mastery of the seaという。


それまでの戦争は主に陸地戦で、歩兵や機動部隊、そして補給線が問題だった。その点では、孫子の時代から本質はあまり変わっていない。だから地形が重要になり、地政学などと言う学問が欧州で育った。しかし戦域が欧州全体から米国まで広がるに及んで、海上輸送による補給の重要性がはるかに増した。そのため、海を支配する側が、戦争に勝つことになったのだ。


ところで、第二次世界大戦のときには、すでに状況が変わってしまった。その間の四半世紀で、一番大きな軍事上の変化は、飛行機の発達だった。戦闘機や爆撃機が、機動的な攻撃の中心になった。そして、第二次大戦の勝敗を決したのは、『制空権』＝空の支配権だった。制空権を持つ側は、陸上・海上の軍隊の移動や補給を、空からの攻撃で牽制し断ち切ることができる。したがって、敵地の防空網を破壊し、空域を支配することが、絶対的に重要なのだ。



では、きたるべきソ連との第３次世界大戦で、勝敗を決するのは何か。それは『制宇宙権』だというのが、当時の米国の認識だった。だから彼らは、宇宙技術を進めるために、アポロ計画をはじめたのだ。


アポロ計画の目的は決して、人間を月に送り込むことではなかった。それは当面のゴールに過ぎない。なるほど、ロマンチックなゴール設定ではある。純真な科学者・技術者を駆り立てるには、適切なゴールだ。だが、真のねらいは、米国が宇宙の支配権を確立すること、それによってソ連と戦争し打ち負かすことであった。


プロジェクトのゴールはWhat（あるいはWhere）を示す。目標は、成功基準としてのHowを示す（how fastとかhow muchとか）。


そしてプロジェクトの目的・パーパスとは、なぜそのプロジェクトを行うか（Why）を示すものだ。



目的はたいていの場合、ゴールよりもずっと先を見ている。短距離走者にとって、ゴールは100m先のテープだ。だが、陸上競走の目的は、100m先のゴール地点にたどり着くことではない。そんなことは、二本足を持つ健康人なら誰だってできる。だから走者にとっての目標（成功基準）は、たとえば「12秒台で走る」とか「自己記録を更新する」になるのだ。


孫武が将軍として兵を率いた西の大国・楚との戦いの、目的はなんだったのか。「勝つこと」は目的ではない。それはゴールに過ぎないのだ。成功基準は、「勝つ」ないし「有利な条件で停戦協定を結ぶ」だったろう。「戦争に拙速はあっても、巧久（うまくて長引く）は無い」と、孫子は書いている。


じつは、傭兵隊長である孫子には、戦争の目的を決めることはできないのだ。だから、戦争を始める権限も無く、勝手におしまいにする権限もない。たとえ戦いが無益に見えても、勝手に休戦したら、それは投降を意味する。プロジェクト・マネージャーは、プロジェクト目的を決めることはできない。彼/彼女には、与えられたミッションを上手に遂行することだけが、求められる。


目的を決めるのは、傭兵隊長の上司である国王（経営者）である。プロジェクトの開始も終了も（あるいは中止・撤退も）、すなわちプロジェクトの全体的な価値判断は、プロマネではなく、その上が決める。「上」とは、経営者かも知れないし、ステアリング・コミッティーという組織体かもしれない。いずれにせよ、プロジェクトを発進させ、プロマネを任命する権限を持つものである。


もちろん孫子は、単に兵術家であるだけでなく、すぐれた思想家であった。春秋戦国時代にすぐれた武将は大勢いたが、彼の名が残ったのは、深い思想を持っていたからだ。彼自身は、従事する戦争の目的についても、内心吟味していたに違いない。


「軍中にあっては、王の命令といえども聞けないときがあります」という彼の冒頭の言葉は、通常は「現場の状況は現場にいる者が一番知っているのだから、権限委譲が必要だ」という意味でとられる。もちろん、その通りだろう。だが、王の愛姫を承知で斬り殺そうとしたとき、彼は自分も無事ですむと思っただろうか。覚悟を決めて、柔弱な王を目覚めさせなければ、いくらでも命が無駄になると悟ったのではないか。


「戦争は国家の大事で、よくよく熟慮せねばならぬ」と、孫子は冒頭に述べる。孫子は戦略家だが、決して好戦家ではなかった。彼はWhatやHowの前に、Whyの方がずっと重要だということを、よくよく知っていたのである。




＜関連エントリ＞
　 (2021-11-04)
　(2022-02-19)

]]> http://brevis.exblog.jp/27925736/ 2019-01-17T23:12:00+09:00 2025-12-31T11:05:43+09:00 2019-01-17T23:06:44+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス

有形のもの、車とか家などのオーナーシップの意味は、誰にも明らかだ。そのものを所有して、自分の意のままにすることができる。無形のもの、例えばライセンスといったものにも、オーナーシップを考えることができる。自分がお金を払い、そこから得られる便益を自分の自由にすることができる。何であれ、それを維持する労力や費用負担し、そこから主たる価値を得るものは、それに対するオーナーシップを持つと言えるだろう。


それでは、プロジェクトのオーナーシップとは、何なのか?


X社のプロマネP氏は、困惑していた。大型プロジェクトを受注して数ヶ月。このままでは、かなりの赤字になることが明白だ。現時点での詳細設計から、全体コストを見積もり直してみると、当初想定していた金額を大幅に上回ってしまう。


顧客のA社に窮状を訴えて、追加費用を出してもらうことも考え、実際内々に打診してみた。だが顧客の反応は冷たかった。そもそも基本設計も、X社が有償で行なったのではないか。その基本設計書の内容をもとに、両者が合意して一括請負契約を結んだのだから、その通り実行してもらいたい。それが向こう側の言い分だった。


確かにその通りだ。要件定義は前任者のプロマネが行い、P氏はそれを引き継いだまでだ。ただ、顧客の業務要件は思ったよりはるかに複雑で、例外が多く、新しく入ったメンバーが理解するまでの時間も、かなり必要だった。


おまけにもっとまずい事に、プロジェクトで中心的に使うつもりでいた自社製の新型装置を、隣のチームが並行して開発中だったのだが、予定された期日からかなり遅れていた。基本設計レベルに問題があったらしく、期待したパフォーマンスがさっぱり出ないのだ。そのおかげで、上司の命令により、自分のチームから優秀なメンバーを数名、隣に回さなければいけなくなった。


仕様は思ったより膨らんでいる。優秀なメンバーもとられてしまった。あてにしていた中核装置も出来上がってこない。顧客は頑固な態度である。このままでは赤字は必至だ。一体どうしたらいいのか？


世の中ではしばしば、大赤字を生みデスマーチが見えているプロジェクトが、延々と続けられている。なぜだろうか。受注したからには完成させるのが受注者の義務？　だが、たとえ違約金を払ってでも、プロジェクトから降りてしまう方が、ビジネス的には傷が小さく済む場合だってあるではないか。


だが、一般にプロジェクト・マネージャーには、プロジェクトを中止・撤退する権限はないのである。プロマネとは、プロジェクトを遂行するように命じられた存在である。遂行の義務と責任を負っている。仕事のパフォーマンスがまずくて、プロマネの職を解かれることはある。だが、プロジェクトの価値が下がったからといって、自分からプロジェクトの遂行をやめる権利は無い（会社自体を辞めてしまうなら別だが）。


そこで改めて考えてみよう。プロマネを任命するのは、一体誰か。プロマネの成果を認定し、評価するのは誰なのか？


それが、「プロジェクト・オーナー」なのである（オーナーは、業界によっては「スポンサー」と呼ばれる場合もある）。プロジェクトの価値を考え、プロジェクトを発進させ、プロマネを任命し、予算を与えるのがオーナーの仕事である。なお、プロジェクトが上位の「プログラム」の一部である場合は、プログラム・マネージャーがオーナーシップをとる。だが、日本ではプログラム・マネジメントをまともに実施している企業がほとんど無いため、そのケースは無視していい。


さて、苦境に陥ったP氏は、上司である事業部長K氏に、状況を正直に報告し、対策を相談した。事業部長が、このプロジェクトのオーナーだったからだ。そこでK事業部長も、自ら顧客に追加交渉にいってみた。だが、相変わらず相手の態度は硬い。このまま続ければ、この開発プロジェクトと、自社の新型装置開発の、二つのプロジェクトがともに道連れで沈没しかねない。


K氏はさらに上の役員と相談の上、苦渋の決断を下した。顧客A社に対し、違約金を払って、このプロジェクトから降りると宣言したのだ。


発注者A社側のプロジェクト責任者は、X社の撤退に驚き、大いに怒った。たとえ違約金をもらったからといって、費やした時間も労力もかなり無駄になったからだ。しかしA社の担当役員は、X社の決断に舌を巻き、内心、敬意を評したという。X社が受注者としてのスポンサーシップを発揮し、痛みは伴うが適切な決断を下したからだ。「確かにウチは迷惑した。だが、あの決断は大したものだ。なかなかできる決断ではない。」


撤退の判断は、つねに難しい。特に受注型プロジェクトの場合は、なおさらだ。お金も労力も失われるが、自分のメンツや顧客からの評判は丸潰れになる。業績評定にだって、大いに影響が出るだろう。


プロジェクトが完遂できないのは、明らかにプロジェクト・マネジメントの失敗である。だが、失敗したプロジェクトから、適切なタイミングで撤退する事は、正しいオーナーシップの発揮なのだ。この点を世間の人は誤解しがちなので、あえて繰り返し強調しておく。失敗したプロジェクトから思い切りよく撤退する事は、オーナーシップの失敗ではない。


オーナーシップの失敗とは、価値のなくなったプロジェクトを、延々と続ける事なのだ。プロジェクトにおいて最も恐ろしい事とは、プロジェクト自体が自己目的化してしまう事だ。ゴールに到達したが、結果は無価値で、労力と金と時間の無駄だった、という事ほど、人心を荒廃させる事はない。それはオーナーシップの不在を意味する。


わたしは授業でよく、公共事業のケースを例にあげる。有名な公共事業の中には、すでに半世紀以上にわたって遂行中で、予算規模も千億円クラスのものがある。だが、終戦直後に計画されたその事業の完成を、もはや誰も待ち望んでいない。それでも続いているのはなぜか。役人という人種が、いったん始めた事は絶対に失敗を認めないし、撤回もしないからだ。だが、繰り返す。失敗を認めず、意味のなくなった事業を続けることこそ、より大いなる失敗なのだ。


もちろん、オーナーの仕事はプロジェクトを中止し撤退することだけではない。むしろそれは最後の選択肢だ。オーナーは、プロマネを助けて、プロジェクトが意味ある仕事として完遂することを支援するのが、本来の仕事である。


以前、米国のPMコンサルタントであるNeal Whittenの主張を紹介した（「プロジェクト・スポンサーシップが足りない」 https://brevis.exblog.jp/23393425/）。彼によると、米国におけるプロジェクトの問題の1/3は、オーナーシップの不全にある、という（彼は「スポンサー」という用語を使っている）。


それでは、プロジェクト・オーナーの仕事とは何か。それは、


プロジェクトを起動し
プロマネを任命し
Project Charterを承認し
予算枠と期限を与え
プロジェクトの状態と価値を定期的にウォッチし、
プロマネの相談に乗り、助ける
プロジェクトの終結を承認し
あるいは、無価値となったプロジェクトを中止する



こうした、プロマネに対する「上からの支援」が、プロジェクトの成功のためには、非常に重要なのである。だからあえて、以前も掲げた図をここに再掲しておこう。

プロジェクト・オーナー（スポンサー）は、プロマネの相談相手として機能しなければならない。そして、プロマネの悩みはたいてい決まっている。それは、お金が足りません、か、人が足りません、なのだ。オーナーというのは上級職の仕事で、普通はプロジェクトにフルタイムで関わることはない。だが、プロマネに対しては、いつでも悩みを聞いてあげる存在でなければならない。


ところが、わたし達の社会では、これが弱いのだ。あるいは、オーナーという役割が存在しない場合も多い。その必要性さえ、認識されていない。だが、プロマネを助けないプロマネの上司とは、一体何のためにいるのか？


とはいえ、多くの読者諸賢の職場では、実際問題、オーナーというポジションは存在しないかもしれない。だったら、どうすべきか。居ないものは居ないとして、それでもプロジェクトが倒れないようにするための、現実解を考えなければならない。


わたしがお勧めする方法は、三つである。


第一に、きちんとProject Charterを作ることだ。Charterというのは、日本では「憲章」と誤訳されているが、「趣意書・許可書」のことだ。もともと英国で、国王が特に出す勅許状のことを、Charterと呼んだ。特別仕立ての飛行機のことをチャーター便と呼ぶのは、その名残だ。また英国では、公式に認定された技術者をChartered Engineerと呼ぶ。


Project Charterという文書は、組織が、そのプロジェクトを公式に認めて、その発進を許す書状である。そこにはプロジェクトの目的や目標などを書く。そして本来は、このCharterはプロジェクト・オーナー（スポンサー）が作って、プロマネに与える、という建前になっている。少なくとも、PMPの試験では、そう書かないと正解にならない、と教わったはずだ。


だが現実には、プロマネがCharterを作っている企業が大半である（だってオーナーはいないのだから）。そこでCharterを作ったら、それをしかるべき上司に、承認してもらおう。表紙にハンコの承認欄を作るのもいい。判子をもらってしまえば、それは上司が公式に認めたことになる。そして上司にも責任（命令責任）が生じる。


あるいは、もう少しモダンなやり方としては、皆で集まってチームビルディングを行う。そして、最後に皆で「コミットメント・シート」を作る。そこにサインを寄せ書きする。無論、上司には中央にサインをしてもらおう。そのシートは、プロジェクト・ルームの壁に掲げて、いつでも見えるようにしておく。こうして、オーナーたるべき人物を、責任と面子のループに取り込んでおくことが重要である。わたし達の社会は、面子とコンセンサスの社会なのだから。


第二に、プロジェクトのJournalを頻繁に発信することである。Journalというのがまた、適切な訳語がない言葉なのだが、元々は日誌のことで、転じて定期刊行物や雑誌を意味するようになった。プロマネにとって、日誌をつけるのは非常に良い習慣である。それはいざという時の法的根拠にさえなる。だが、もっとソフトな意味で、定期的な情報発信のことを、ここでは言っている。


つまり「プロジェクト週報」だとか「プロジェクト新聞」といった簡単なニュースメールを発信し、関係者皆に送りつけるのである。関係者の中には、もちろん「オーナーたるべき人」も、さらにその上司をも、送付先に含めておく。


こうして、プロジェクトの状況を、定期的に、かつできる限り頻繁に、皆に知らせておき、上層部にも関心を持ってもらう。「そんなの多分、メルーボックスの肥やしになるだけだ」などと、最初から悲観してはいけない。捨てる神あれば拾う神ありで、世の中にはたまに、ちゃんと見ている人もいるのだ。プロマネはなるべく、いろんな人に味方になってもらう必要がある。


三番目の方法は、ちょっと大技だが、プロジェクトのために「ステアリング・コミッティー」を設置してしまう（設置してもらう）やり方だ。これは、拙著『世界を動かすプロジェクトマネジメントの教科書』 （最近増刷が決まった）に書いた方法でもある。


この本では、製造業の若手エンジニア・小川君が突然、海外企業とのジョイント・プロジェクトに巻き込まれるのだが、このプロジェクトたるや、誰がプロマネなのかも判然としない。そんな中、大学の先輩だった広田氏のアドバイスをもらいながら奮闘していく物語だ。その際、プロマネもオーナーも不明ながら、なんとか仕事を前に進めるために、あえて複数部門の管理職の層でステアリング・コミッティーを設置してもらうよう、小川君が上に提案する（広田氏がそう勧めたのだ）。


その顛末は本を読んでいただくとして、いったんコミッティーを作ると、なにせ面子とコンセンサスの国だから、なんとかサポートは得られる。そして、プロジェクト・ガバナンスの点からいうと、これはこれで立派な方策なのである。


もちろん、上記の三つの方法が、いつも功を奏するとは限らない。忙しい中、権限もないのに、実行するのはかなり大変だろう。でも、本当にプロジェクトが傾いてきたら、一番こまるのはプロマネの自分なのだ。だとしたら、少しでも会社にオーナーシップを自覚してもらうべきである。


それにしても、研究会などで多くのプロジェクト事例を聞くにつけ、感じることがある。日本の多くの組織で見られる、現場リーダークラスの共通の悩み、共通の問題があるのだ。


それは、ビジョンの不在や戦略の失敗を、戦術レベルでなんとかカバーしようと努力して苦労している、という事実だ。これが、中堅若手のプロマネや、サブリーダー・クラスの疲弊感を生んでいる。たとえば、営業部門が売上目標のために無理な価格、納期で受注してきた案件を、技術部門が苦心惨憺、遂行する。そして、プロジェクトをなんとか黒字にできないか、悩んでいる。あるいは、ヘンテコな製品戦略のために、新製品開発プロジェクトが迷走し、BOMや基準情報までが混乱する。こうした例は、枚挙にいとまがない。


なぜ、そんなことに努力を費やすのか。それは、現場リーダーに与えられた権限範囲と、リーダーの責任（評価・賞罰）とが、あっていないからだ。プロマネ自身ではどうしようもない環境条件において、結果だけを評価される。ここでプロジェクトの「環境」とは、プロマネが短期的な努力では左右し得ない条件をいう。


プロジェクトのオーナーシップは、プロマネを任命する権限を持つ者にある。したがって、プロジェクトの最終的な損益やアウトカムに対する最終的責任・評価もオーナー側にあるのだ。プロマネは与えられた条件下で、どこまで良くやったか（計画し遂行したか）を評価されるべきである。プロマネは、自分では途中でやめられないのだ。プロマネには実行責任がある。だが、命令責任は、オーナーは負うべきなのである。




＜関連エントリ＞
　→「プロジェクト・スポンサーシップが足りない」 https://brevis.exblog.jp/23393425/ （2015-07-08）
　→「アカウンタビリティとは『命令責任』である」 https://brevis.exblog.jp/24837740/ （2016-11-05）


]]> http://brevis.exblog.jp/26258058/ 2017-12-15T00:48:00+09:00 2025-12-31T11:05:43+09:00 2017-12-14T22:52:22+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス

「プロジェクト＆プログラム・アナリシス研究部会」の2018年第1回会合を開催いたします。


新年第1回は、久しぶりに製品開発、とくに研究開発におけるプロジェクト・マネジメントについて、キユーピー（株）の元常務取締役・研究所長であった和田義明様に、ご講演いただきます。


ご承知の通り、企業におけるイノベーションの創出活動、とくに研究という仕事は、まだ誰も知らないものを生み出すことにあります。他方、マネジメントとは計画を立て、明確な目標イメージを持って統率していく行為です。誰も知らない目標に向かって、一体どのように組織をマネージすべきなのか？　ここに研究開発マネジメントの本質的な難しさがあります。


今回は、実際の研究開発の実務を長年リードしてこられ、さらに研究開発の方法について博士号を取られた和田様から、R&Dのマネジメントについて実戦的なお話を伺う予定です。ぜひご来聴ください。




＜記＞


■日時：2018年1月25日（木）　18：30～20：30


■場所：三田キャンパス　研究室棟B会議室（1F）
　https://www.keio.ac.jp/ja/maps/mita.html
　※キャンパスマップの【10】
　（いつもの北館とは別の場所ですので、ご注意ください）


■講演タイトル：
「企業における研究開発の活性化策（プラットフォームとブーストゲート法）」


■概要：
　研究開発を活性化してイノベーションにつなげることを目的に、キユーピー㈱研究所にて取り組んだ手法を紹介する。具体的には、組織力を高めるプラットフォーム・マネジメントと、研究を事業につなげるブーストゲート法である。その方法、効果、事例について紹介する。


■講師：キユーピー㈱　アドバイザー　和田 義明


■講師略歴：
【学歴】
　1978年　東京農工大学農学部農芸化学科卒業
　2012年　東京農工大学専門職大学院技術経営研究科修了
　2014年　東京農工大学大学院工学府応用化学専攻博士後期課程修了
　　　　博士（学術）
【職歴】
　1978年　キユーピー㈱入社（以後工場、研究所、マーケティング部門勤務）
　2000年　同社研究所部長
　2006年　同社執行役員品質保証本部長
　2009年　同社取締役研究所長
　2012年　同社常務取締役（ファインケミカル事業、研究開発本部、品質保証本部、商品開発本部、知的財産室管掌）
　2017年　同社取締役退任
【現在役職】
　キユーピー㈱アドバイザー
　上海海洋大学客員教授
　中央大学、関西大学、千葉工業大学非常勤講師
　東洋食品工業短期大学非常勤講師兼テクニカルアドバイザー
　国際プロジェクト・プログラム・マネジメント学会評議員
　タマゴ科学研究会理事、日本能率協会食品安全部判定委員


■参加費用：無料。
　ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金（¥2,000）は免除されます。
　参加を希望される方は、確認のため、できましたら当日までに三好副幹事までご連絡ください。


　以上、よろしくお願いいたします。


佐藤知一＠日揮（株）
]]> http://brevis.exblog.jp/26170090/ 2017-11-12T18:16:00+09:00 2025-12-31T11:05:43+09:00 2017-11-12T18:16:50+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス

たとえば、「天の時」である。


プロジェクトのスタートするタイミングは、さまざまな形でパフォーマンスに影響する。端的には、マーケットの状況だ。市場全体が活況を呈しているかどうか。受注型プロジェクトの場合なら、契約金額が上昇気味かどうか？ これは、プロジェクトの採算性にとって重大である。また、外部に発注するリソースや資機材の値段が上がりつつあるか、どうか。これも採算に影響する。


自社が好調か、それとも苦しい時期かも大きな要因だ。苦しい時期だと、どうしても無理して仕事を取りに行く姿勢が強まる。当然、予算は厳しくなる。


こうした全体的な市況は、プロマネ自身が勝手に選べるものではない。まったく同じ前提条件ではじめても、スタートする時期が好況期で売り手市場なのか、あるいは不況期で買い手市場なのかによって、結果は相当異なるだろう。途中で市況が急変することだって、ある。わたしは10年近く前、あるビッグ・プロジェクトの見積をしていたが、途中でリーマンショックが深刻化し、プロジェクト自体の成立が急に危ぶまれたことを思い出す。そうなると、億の単位でかかる見積費用が、パーになってしまうのだ。たまったものではない。


次の、「地の利」とは何か。


プロジェクトを遂行する上で、立地的な優位性があるかどうか、の意味が第一だ。プロジェクトを遂行したり成果物を納入する場所の近くに、自社の拠点があるかどうか。これは、ふつうプロマネが自分で決められる条件ではない。海外プロジェクトの場合は、そこに支社や合弁相手がいるかどうか。いるとして、その能力はどうか。あるいは、日本から出かけていかなければならないのか。これらは大きな違いを生む。たまたまわたしは今、この文章をジャカルタの空港で書いているが、多くの日本企業がすでに存在していることも、ある種の地の利であると考えられる。


地の利は、より象徴的には、競合状態が厳しいかどうか、を表す。たとえ市況は好調期、現地に拠点があろうとも、競合相手が5社も10社も現れるようでは、レッド・オーシャンそのものである。勝ち抜くのは、かなり厳しい。


では「人の和」は、プロジェクトにとって、何を意味するか。


もちろん、それはまず、プロジェクト・チーム自体の協働意識を、そのまま表す。だが、そこはプロマネがある程度は醸成できるし、しなければならない。


しかしさらに掘り下げると、適切なメンバーがアサインされているか、という問題になる。メンバーがプロマネの固定的な部下であるような組織では、まあ、これは問題になるまい。が、機能型組織やマトリクス型組織では、複数の部門からメンバーをアサインしてもらわなければならない。とくに製造業ではライン部門長の権限は強大だ。プロマネが好きに人を集められる訳ではない。


もっと言うと、プロマネ自身の任命が適切か、ということもある。これはPMO的な視点から言っているのだが、「あのプロジェクトの最大のリスク要因は、XXさんがプロマネをやっていることだ」という笑えない冗談も、生まれたりする。良い仕事は、チームワークから生まれる。ぎくしゃくしたチームから、優れた仕事が生まれる可能性は、少ない。


しかし、人の和に関する、より深刻な問題は、外部のステークホルダにある。たとえば顧客（発注者）、ユーザ、協力会社、ベンダー、監督官庁、地域住民などである。とくに顧客は重要だ。受注型プロジェクトで、訳の分からん顧客に当たって、苦労した経験のあるプロマネは多いだろう。顧客と和の気持ちを持って、適度に緊張した関係を続けられるかどうかは、プロジェクトの成否を大きく左右する。


このほかに、かなり大事な要素として、プロジェクト・スポンサーの能力をあげたいところだ。スポンサーとは、経営層に近い上級管理者で、プロジェクトに予算枠を与え、プロマネを任命する権限を持つ人のことである。「スポンサー」のかわりに「プロジェクト・オーナー」と呼ぶケースもある。


プロジェクト・スポンサーは、プロマネの後見人であり、相談相手でもある。この人が、プロジェクトに理解があり、適切に経営層を動かせるかどうかが大事だ。大事なのだが、そもそも日本企業では「スポンサー」の役割が存在していなかったり、十分に認識されていない場合が多い。そうなると、「人の和」に、重大な欠落があることになる。


（余談だが、拙著『世界を動かすプロジェクトマネジメントの教科書』は、海外企業と合同でプロジェクトを始めることになった製造業を舞台に、主人公の若手技術者が、プロマネもスポンサーも誰だか曖昧な状況下で、なんとか成功させようと懸命に奮闘する物語である。つまり、あれは和を尊しとなす日本企業で、じつは機能的な「人の輪」が欠落している問題を扱っている）


元々、天の時・地の利・人の和とは、「天の時は地の利に如かず、地の利は人の和に如かず」という孟子の言葉から来ている。これが日本では、戦国時代に兵法の判断条件として、流布されるに至った。人の和が一番大事だと、孟子はいう。だが、戦国大名ならいざ知らず、現代のプロマネにとっては、上記の通り自分の力だけで人の和を作り上げることはできない。まして天の時や地の利は、所与の条件、としか言いようがない。


こうした要素は、環境としてプロジェクトに影響を及ぼす。ここで環境とは、「プロマネの意思では短期間に変えられないものごと」を意味する。


プロジェクトの成否は、受注時点で半分以上が決まっているーーそう言ったら、読者諸賢は、オーバーだと思うだろうか。だが、これに近い実感を、受注型プロジェクトに長年従事する実務者は、少なからずもっている。受注の時点で、天の時・地の利がもう決まっている。人の和も、かなり重要な部分が定まってしまっている。残された自由度の中で、プロマネは奮闘をはじめなければならない。


問題は、プロジェクトの採算が結果として悪化した時に、その原因のうち、環境因子による部分と、プロマネに起因する部分が、それぞれどれだけあるか、客観的な評価が難しいということだ。もちろん、「半分以上が環境」というのは、感覚論にすぎない。これについて定量的な分析を、あいにくわたしは見たことがない。


「プロジェクトの結果・採算は、全てリーダーであるプロマネの責任」、という結果責任の原則をとる企業は多い。これは、プロマネに責任感を持たせて育てるためには、良い指針である。プロマネがいつも責任回避的、あるいは他責的な人間では、会社はこまってしまう。


しかし、だからといって、プロジェクトの最終的な損益金額だけで、プロマネたちを、
　「貴方は今期2千万円の黒字を出したからA評価」
　「お前は今回、5百万円の赤字を喫したからC評価」
と、単純に査定していいだろうか？


それはあまり賢明ではない、と、わたしは考える。個別の案件の結果は、短期的な環境因子に左右されやすいからだ。プロ野球の一流バッターだって、打率は３割台である。1打席ごとの結果は、その時の状況に左右されやすい。能力の査定はある程度、長期的に見るべきだ、というのがわたしの意見である。ただ人事の査定は、半年ないし一年ごとに行わざるを得ない。数プロジェクトの平均打率を計算していては、間に合わない。では、どうするか。


わたしの提案は、プロマネの査定を行う前に、「プロジェクトの評価」を組織として公式に行うべきだ、というものである。会社として
プロジェクトの成果物、達成した金銭的価値、非金銭的な達成（人材の成長や実績レコードの確立など）、出発時点での環境条件、そして今後への教訓などを評価し、記録する。このとき、損益の数字だけでプロジェクトを評価しないことが大切であろう。



その上で、出発点から到達点までの、プロマネの貢献を考量する。それが査定のベースとなるべきである。たとえプロジェクトの最終評価が低くとも、出発点での環境条件が厳しい場合は、その分を勘案する。


そのためには、プロジェクトの出発時点で、『案件のプロファイリング』を行う必要がある。市場環境（天の時）・競合状況（地の利）・顧客特性と組織メンバー（人の和）などを、プロファイリングして事前評価しておくのである。別に5段階評価程度でもいい。このような作業は、営業段階における受注戦略・案件選別においても有用だろう。営業部長の胸先三寸にすべてを任せるより、少なくとも公平に思える。


念のために書いておくが、上記のようなことを、わたしの勤務先がすべて実践しているから真似た方がいい、というような話をしているのではない。そうではなくて、環境条件の重要性に目を向けて、各社でそれを評価するようにしたらどうか、と提案しているのだ。また、そういう問題に定量的に取り組む研究者が、できれば現れてほしい。


その上で、厳しい環境条件が揃っている場合は、組織として積極的にプロジェクトの支援を行う。そうして、プロジェクトが倒れないように支える。そういう仕組みが必要だろう。


支援で人を出すと、その人件費のぶん、採算がさらに悪化する。すると、プロマネ自身は赤字をおそれて、支援を遠慮するかもしれない（問題を抱え込んで、上に報告しない可能性さえある）。しかし、放置したら会社としては、もっと赤字が膨らむ。それを防止することが、全体としては重要だ。


会社がプロマネを任命して、「プロジェクトは結果が全てだ」「あとは死ぬ気で頑張ってこい。」というのは、以前も書いたようにレベル1のマネジメントである。それで良い場合もあるが、いつでも正しい訳ではない。適切なマネジメントの仕組みを作るのは、会社の側の仕事である。


またプロマネの側も、本当に良い仕事をしたければ、人の和をつくり、地の利を整えた上で、天の時を待つだけの忍耐力が必要だということになる。それを昔の人は、「人事を尽くして天命を待つ」と言った。


それだけの謙虚さが、わたし達には必要なのだろう。気合や根性よりも、天の時への謙虚さが。




＜関連エントリ＞
→「マネジメントのレベル0からレベル2まで」（2017-09-22） http://brevis.exblog.jp/26064558/














]]> http://brevis.exblog.jp/23696790/ 2015-09-21T14:18:00+09:00 2025-12-31T11:05:43+09:00 2015-09-21T14:17:47+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス
ほかに、ERPのプロジェクト管理モジュールというものも存在した。SAP R/3のPSだとか、Oracle EBSのPAなどだ。これらは金額的には超弩級だが、プロジェクト・マネジメントの日々の実務を助けるツールというより、プロジェクト会計や原価管理のための道具であった。

しかし調査会社のレポートによると、これ以外に第3のカテゴリーが勃興しつつあるという。それがプロジェクト・ポートフォリオ・マネジメント（略称PPfM）であった。これはプロジェクトを投資ととらえ、企業が持つ複数のプロジェクトの組み合わせを、ちょうど金融資産のポートフォリオと同じように最適化し管理するための道具立て、との位置づけだった。

プロジェクトの上位計画をプログラムと呼ぶことは、当時も知っていた。アポロ計画は英語ではApollo Programという。そして個別の飛行ミッション、たとえばアポロ11号をプロジェクトと呼ぶのだ。プロジェクトの下には「フェーズ」がある。Program > Project > Phaseの序列は、頭文字をとってPPPと呼ばれていた。しかし、実は第4のP、すなわちポートフォリオ（Portfolio）があって、それはプログラムよりも上位の概念なのだった。

そして米国の市場は、明らかにこのプロジェクト・ポートフォリオ・マネジメントに向かっている、とレポートは結論していた。この予測は、米国に関していうと、きわめて適切であった。MS ProjectもPrimaveraも、その後の新バージョンではポートフォリオ・マネジメントを意識した形で、プロダクトを再デザインしていった。サーバ型製品が主流になったのも、ある意味でその影響である。PPfMにねらいを特化した製品も出るようになった。

そして日本市場は米国のトレンドを数年遅れて追っている。したがって、今後の期待株はPPfM関連の製品にある、とレポートは言いたげであった。

しかし、わたしは、それが日本でも広がるという予測には疑問を持った。そもそも、わたし達の社会では、プロジェクト・マネジメントは受注者がやる仕事だと考える風潮が強い。まるで投資者（発注者）は、発注書さえ切ってしまえば、あとは口々に好きな放題な要望を言えばよく、それをとりまとめるて調整するのは受注者の仕事だと思っているかのようだ。発注者こそ、きちんとプロジェクトを舵取りしなければならない、という社会的常識はきわめて薄い。

そして受注者にとって、プロジェクトは投資ではない。競争環境下にいる受注ビジネス企業は、どのプロジェクトをやるかは自分で決められないのだ。だからポートフォリオ・マネジメントなどやりようがない。日本では普及しないし、ソフトも売れないだろう。これが、わたしの予測だった。

10年以上が経った現在でも、わたし達の社会でポートフォリオ・マネジメント・ブームが来そうな兆しはない。企業にプロジェクト・ポートフォリオ・マネージャーという役職が設置されたという話も、いっこうに聞かない。

・・だが、つい最近、わたしは重大な見落としをしていた事に気がついた。それは、6月に開催した「プロジェクト＆プログラム・アナリシス研究部会」でのことだった。

6月の研究部会では、元NECの田島彰二氏を講師に迎えた。田島さんは世界におけるプロジェクト標準化活動では、日本を代表する論客として長年、活躍してこられた方だ。国内より海外でずっと知名度が高い。PMIの各種スタンダードの巻末にある貢献者リストで、最も頻繁に名前を見かける日本人だろう。最近では、国際標準化機構ISOの、プログラムとポートフォリオ・マネジメントの標準策定に尽力しておられる。

その田島さんが、欧州で参加されたポートフォリオに関するワークショップで出題されたグループワークの問題を紹介された。著作権の関係もあるので正確な引用はできないが、おおよそこんな問題だった：

あなたは脱サラをして、風光明媚なエリアに地産地消のピザ屋を開くことにした。店を構え、レシピを工夫し、地元の仕入れもなんとか道筋をつけて、順調に運営しはじめたところだ。ところである日のこと、あなたのところに電話がある。これから観光バス1台に乗り込んだ団体ツアー客50名が、店の評判をきいて昼食に行きたいというのだ。今は11時過ぎだが、12時には来るという。それだけの数の客が来たら、小さなあなたの店は完全に満杯になる。それに、あなたの店はいつも11時半に開店して、いつもそれなりの常客が来てくれているのだ。さて、あなたはどうするべきか？

田島さんは研究部会の参加者を二人一組にわけて、それぞれに8分間で意見をまとめるよう依頼した。各チームの話し合いを見ていると、出題にどう取り組むか、参加者の頭がフル回転している様子がありありと感じられた。まず、50人分ものピザの材料はあるのか？　仕入れは今から追加手配して間に合うのか？　椅子やテーブルの数は足りているか？　店の外にもテーブルを並べるべきか。フロアのサービス係の人数は。かまどは一度にそれだけの数量を焼けるのか。そして、いつもの常客にはどう応対するのか。本日貸し切りにする？　だが何とかやっと安定運営にこぎつけた店で、常客を断ったらまずくはないか。いや、そもそもこんな飲食店の話、どこがプロジェクト・マネジメントなんだ!?

だが、これは非常に面白い出題だと、わたしは思った。この話は、突発的な需要増が見込まれるケースで、どう戦略的な意思決定を下すかを問うている。その際にポイントとなるのは、経営資源が限られている、ということだ。店の従業員数も、スペースも、かまども椅子もテーブルも、そしてピザ製造の材料も、すべて『経営資源』の一種である、という風に抽象化して問題を捉えることができるかに、かかっている。

経営資源が限られている際に、どこに重点的に投入していくかという問題こそ、ポートフォリオ・マネジメントの要点である。そして、需要に対して経営資源が限られている場合、考えられる主な対応は、二つしかない。
(1)ボトルネックの資源を手配する（資源制約を緩める）
(2)顧客を選別する、
の二つである。だからこの地産地消ピザ屋の問題は、この(1)(2)の視点に気がつけるかどうか、回答者の戦略思考能力（抽象化能力といってもいい）を試しているわけだ。

ところで、わたしの見た限り、参加者のほとんどは(1)の対応策にのみ集中して議論していた。材料をどうするか、テーブルや椅子やスペースをどう広げるか、という議論で、つまりボトルネックはそうした点にあるだろう、という仮定に立っている。

しかし、(2)を明確に意識して、「観光客か常客のいずれかを選んで、他はお断りしよう」との意見は、あまり出てこないようだった。仕事（需要）が来たら、それをどうこなすかを必死に考える。しかし、顧客を選ぼう、という発想は意識に上らない。なんて技術屋的だろうと、わたしは感じた。

常客に加えて50人もの観光客が来たら、店は明らかにパンクする。無理に受け入れたら、確実にピザの味やサービスのクォリティは下がるだろう。それでも受け入れようと決めるのは、たしかにひとつ戦略的決断である。だが店の将来を考えたら、下手に今、評判の落ちるような仕事はできないのだから、顧客を選ぼう、というのもやはり戦略である。どちらがベターかは議論の余地もあろうし、たぶん正解はない。ただ、この両面の視点を持つことは、経営者として必須だ。

顧客は選べないし、選んではいけない、という思い込みは、わたし達の間に強固に存在している。顧客の中には上客も、こまった客も存在する。しかし注文しに来てくれた客である以上は、応対しなければいけない。応対すべきである。もし今かりに手一杯でも、一度断った客はたぶん二度と来ない。だから何とか応対を考えるべきだ、と。値切ってくる客とも、仕事を失わないよう、どこかで折り合いをつけるべきだ、と。

しかし、世の中にはまったく別の視点も存在するのだ。それは、経営とは顧客（のセグメント）を選ぶことである、という視点である。「経営者の仕事とは、店の前に客の行列をつくることだ」という意見も読んだことがある。客がつねに行列をなしていれば、自分のペースで、クオリティを落とさずに仕事ができるし、値切りにも応ぜず、いやな客はお断りできる。そのためには、どのような形で他社との競合から避けるか、どのような見えない参入障壁を築くか、どのような独自技術や商品を作り、どうマーケティングしプライシングていくかこそ、戦略である−−そんな見方だって、存在するのだ。

ポートフォリオとは元々、書類を束ねる紙挟みを意味する言葉だ。そこから派生して、債権や株などいろいろな金融資産の束、組み合わせを意味するようになった。さらにそこから広がって、経営資源を投入する行為自体も、一種の投資と考え、それをうまく組み合わせようとするのが、現代のポートフォリオ・マネジメントである。

経営資源はつねに、有限である。そこで、どこにどう投入するかを、選ばなくてはいけない。何かを選んだら、他は捨てることになる。捨てたり、やめたり、断ったりすることが、ポートフォリオ・マネジメントから必然的に導かれる行為である。その対象の中には、市場のセグメントや、需要や、見込案件が含まれる。

あいにく長らく不況の続いた現在、案件選別という考え方は、受注ビジネスの分野ではきわめて薄弱だ。とにかく有望そうな案件にはトライしてみる。三つでも四つでも追いかけてみる。どれがとれるかは、わからない。二つ以上とれたら、どうするかって？　そんなこと、とれる前に心配しても仕方がない。取れてから考えればいい・・「とれるだけ仕事をとってはいけない」とわたしが信じるようになったのは、つい近年のことである。

わたし達はやはりもう少し、ポートフォリオの視点を持つべきではないかと思う。日本プロジェクト・マネジメント協会が、日本独自の標準である「P2M＝プログラム＆プロジェクト・マネジメント」の改訂3版を昨年度出したが（わたしも標準ガイドブックの貢献者の一員である）、田島氏は、「経営戦略とプログラムの間に、ポートフォリオ・マネジメントを入れるべきだった」と批判している。たしかに、上記のような状況を考えると、正当な批判というべきだろう。顧客（セグメント）を選ぶこと、そのために圧倒的な競合力のある市場を作ること、それをめざして経営資源を投入すること、そして仮想的な顧客の行列を生み出すこと。そうしたポートフォリオの視点こそ、今のわたし達が必要とするものかもしれない。

＜関連エントリ＞
　→「とれるだけ仕事をとってはいけない」（2015-03-03）]]> http://brevis.exblog.jp/23393425/ 2015-07-08T19:52:00+09:00 2025-12-31T11:05:43+09:00 2015-07-08T19:52:03+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス
(1) プロマネのハード・スキル不足
(2) プロマネのソフト・スキル不足
(3) プロジェクト・スポンサーシップの不足

プロジェクトの失敗の理由がプロマネに帰されるのは、ある意味、当然のことだ。Whittenはプロマネの能力を、ハード・スキルとソフト・スキルとに分解する。ハード・スキルとは、知識や技法など、いわゆる座学で習得できる種類のものである。WBSだとか、PERT/CPMだとか、パラメトリック見積法だとかいった事柄で、これらは技術として移転可能なものである。わたしの言い方では「マネジメント・テクノロジー」であり、これを使いこなせる能力を、ハード・スキルと呼ぶ。

二番目のソフト・スキルとはむしろ、座学では学びにくい、より属人的な習熟を要する能力だ。交渉力だとか、指導力だとか、問題解決力だとか、後進育成とかコミュニケーションの能力など。わたし達の社会ではよく「人間力」などと称される。いわゆるリーダーシップとも、重なる点が多いだろう。

ところで、三番目の「プロジェクト・スポンサーシップの不足」という指摘には、意表をつかれた。プロジェクトの失敗の、いわば1/3は、プロマネ以外のところが原因で起きる。彼は経験をもとに、そう主張する訳だ。では、プロジェクトのスポンサーシップとは何か。

米国のPM関係の大会では、物事を理解するデフォルトの枠組みはPMBOK Guideと、PMP資格である。わたしもPMPは持っている。だが、PMOのメンバーとして社内のいろいろなプロジェクトを見ていくうちに、それだけでは次第に物足りない点を感じるようになっていた。

PMBOK Guideはたしかに、「プロジェクト」という枠組みの中で、それをいかに効率的に遂行するかを教える。しかし、そもそもプロジェクトの枠組みを与えるのは誰か。またプロジェクト・マネージャーを任命するのは誰なのか。プロジェクトがうまくいかなくなり、たとえ完遂しても価値を生み出さないことが明白になったとき、プロジェクトを止める権限があるのは誰か？

それは、プロジェクト・スポンサーである。

プロジェクト・スポンサー（業界によっては「プロジェクト・オーナー」ともいう）は、上級マネジメント層を代表して、プロジェクトをウォッチする。だから、重要なプロジェクトの場合は、役員かそれに準ずるレベルの人がなる。中小規模の場合は、プロマネの所属する部門長がやるだろう。
（もしプロジェクトが上位プログラムの一部である場合は、通常はプログラム・マネージャーがその役割を果たすか、あるいは自分のプログラム・オフィスのスタッフにその権限を委譲するはずである）

わたしは勤務先でPMOの仕事を何年間もやってきた。それなりの数のプロジェクト・レビュー会議に参加し、またプロマネ達のマンスリー・レポートをウォッチもした。念のためにいうと、社内にいるベテランのプロマネ達は、わたしなんかよりずっとマネジメント能力があり、技法などについても熟知している。なのに、なぜPMOによるウォッチや助言が必要なのか？

それはスポンサーのためなのだ。多忙なプロジェクト・スポンサーに、配下のあのプロジェクトはきな臭い煙が出ています、近いうちに火の手が上がるかも知れませんよ、と告げる。それがPMOの重要な仕事なのである。ちょっとPMとじっくり話してみてください、と。

なぜ、プロマネが直接、スポンサーに自分のピンチを告げないのかというと、通常は、問題を押さえ込めると自分で思っているからだ。わざわざ報告の要はない、と。プロマネという人種は楽天的で、自信家だ。そうでないと、プロマネはつとまらない。まあ、たまにはプロマネが自分のプロジェクトで問題が起きているのに気づかない場合もある。PMOは全部のプロジェクトを横並びで数値的に比較しながら見ているから、そのような異常に敏感になっている。むろん、異常がつねに病気とは限らないのだが、アラームはならすことになる。プロマネから見れば、自分が十分マネージしているつもりなのに、横で小うるさいことをスポンサーに進言する心配性のPMOなんか、うるさい限りだ。スコアラーは黙って試合を見てろ－－そういう気持ちにもなるだろう。ある意味、PMOはせつない役回りである。

むろん、本来はPMOがいようがいまいが、プロマネと、それを管掌するスポンサーとの間には、定期的なコミュニケーションがなければいけない。
スポンサーはプロマネを任命し、支援する。
プロマネはスポンサーに報告し、相談する。
－－これが両者の間の役割だ。

そしてプロマネの悩みとはたいてい、予算が足りないか、人が足りません、なのだ。（時間が足りません、ということもあるが、通常はお金か人をかければ期間は短縮できる）。そこでスポンサーは、トップ層を動かして、予算をつけたり、他部門から必要な人を持ってくるような働きが必要とされる。つまりスポンサーもまた、「実力」がないといけないのだ。

逆に言うと、プロジェクトにおいて、プロマネだけの能力と努力でできることには、一定の限度があるということだ。わたしの実感でも、プロジェクトの成否のうち、プロマネの権限内で達成できる部分はせいぜい2/3程度である。場合によっては、もっと少ない。それ以外の部分は、プロマネが任命される以前に決まっていた枠組み（契約条件等）とか、プロマネがコントロールできない社内の配員や、外部環境の変動（たとえば為替リスクだとかベンダーの倒産だとか）などで、成功か失敗かが決まってしまう。

つまり、与えられたプロジェクトという枠組み、所与の制約条件（予算・納期・スコープ）の中だけで、プロジェクトの成功率を上げることはできないのだ。したがって、プロジェクトの成功率をもっと向上したかったら、会社が本気でプロジェクトを支援する仕組みづくりが必要となる。

受注型プロジェクトの場合は、受注側のプロマネの上に、プロジェクト・スポンサーがおり、発注側にも本来はプロマネとスポンサーがいる。したがって、両者のスポンサーが定期的に（たとえば年４回とか隔月とか）で会合を持ち、プロマネのレベルでは解決できなかった問題（イシュー）を話し合い、なんとか解決に持ち込むことが望まれる。少なくとも、わたしが知る限り、エネルギー系の海外プロジェクトでは、そういう仕組みが常識化している。

では、プロジェクト・スポンサーという役割の人が、具体手にするべき仕事の内容は何か？

わたしの知る限り、ISOをはじめとして、米国PMIや英国OGC、日本のP2Mなどでも、スポンサーについて定めた標準書はほとんど存在しない。唯一知っているのは、GAPPS Initiativeの定めたStandardである。昨年、GAPPSのワークショップが日本で開催されたとき、わたしも手伝ったのだが、そのときはまだスケルトンだった。今年はドラフト段階まで来ている。
http://globalpmstandards.org/tools/gapps-pm-standards/project-sponsors/
これによると、スポンサーの役割は大きく三つある：

(1) プロジェクトのAccountabilityを引き受ける
(2) プロマネを支援する
(3) プロジェクトを支援する

最初の「(1) プロジェクトのAccountabilityを引き受ける」、とは、プロジェクトの意義を明確にし、有効なガバナンスを確立し、プロジェクトの生み出すアウトカムと便益が現実に役立つよう計画する、などを含む。Accountabilityとは『説明責任』などと訳されることも多いが、ふつうは説明行為だけではなく最終的な責任を引き受けることを指す（わたしは『面目責任』と訳した方がいいと思っている）。

つぎの「(2) プロマネを支援する」は、プロマネに時間を割いてやり、プロマネレベルでは解決しにくい紛争や問題について助けてやり、またプロマネ自身のパフォーマンスについて率直に評価・助言してやる、が含まれる。そして「(3) プロジェクトを支援する」とは、リソース（配員や資金など）面で助けてやり、ステークホルダーにプロジェクト状況を見えるようにし、適切なプロジェクト・レビューと意思決定がなされるよう組織を動かす事を指している。

もっとも、こうしたスポンサー制度の説明をすると、そんな風に上からプロマネを支援するなどしたら、プロマネの「甘え」を助長するからよくない、といった論議をする人が出てくる。何を甘えたことを言っているのか、寝言を言うな、と。

たしかに自分の判断を放棄して、すべてをスポンサーに相談し依存してくるプロマネがいたら、「甘えるのもたいがいにしろ」と叱るべきだろう。ある程度は厳しくしてこそ、育つ責任感というものもある。だが、そもそも組織がプロジェクトを遂行する目的は、何だろうか。一切の助言や支援を「甘え」の名前でシャットアウトして、本当に企業としてそれでいいのか。顧客やステークホルダーに迷惑をかけ、赤字を増大し、自社の信用を毀損するようなプロジェクトを放置してまで、プロマネの「甘え」を拒絶することで得られるものは何があるのか？　物事にはどこかに、適切な限界があるべきだろう。イエスかノーか、0か100かで決められるほど、マネジメントとは単純な仕事ではないはずだ。

ご存知の通り、日本におけるプロジェクト・マネジメントの普及とブームは、2000年以後におきた。その中心はIT産業、とくにSI（システム・インテグレーション）と呼ばれる受託ソフトウェア開発の分野である。SIerと呼ばれる業種において赤字プロジェクトの頻発が問題となり、業界全体の悩みとなったし、その結果生まれた労働環境の劣化は、優秀な人材をリクルーティングする障害になった。

PM論がはやる以前のキーワードは、『リーダーシップ』だった。「お前はプロジェクト・リーダーなんだから、リーダーシップを発揮しろ！　それでなんとか困難を切り抜けろ！」と号令することで、赤字や納期問題を解決しようとしていた。意地わるくいえば、上司は問題を、部下であるリーダーに、リーダーシップなる魔法の言葉で、『丸投げ』していた訳である。

さいわい、プロジェクト・マネジメントという概念と知識体系が普及することによって、そうか、プロマネには、身につけるべきスキル・セットがあるのだな、という認識が進んだ。多くのSIerが社内でPMP資格取得を奨励したのも、こうした理由が大きい。こうした活動の結果、10年間で、PM論に対する認識はかなり普及したといっていい。また、社内レビューなどの制度的な前進もあって、赤字プロジェクトはある程度、減少したという調査結果もある。しかし、では業界の悩みは解消したかというと、わたしの聞く限りは、そうではない。

そして、なまじPM論の知識が広まったが故に、「プロジェクトの失敗は、プロマネのマネジメント能力不足である」という認識も、妙に広まってしまったように思える。つまり、問題解決を部下であるプロマネに丸投げする上司の体勢自体は、あまりかわっていないのだ。単にキーワードが、曖昧なる『リーダーシップ』から、舶来風の『プロジェクト・マネジメント』に昇格(?)しただけである。人によっては、PMの最大のポイントはプロマネのリーダーシップである、と論じて、わざわざ論点をプロマネ個人の資質に引き戻したりしている。

ここで最初のN. Whittenの「プロジェクトの三つの失敗理由」を思い出してほしい。プロマネ個人のリーダーシップは、もちろん非常に大切だ。だが、それはプロマネの「ソフト・スキル」である。また、PMBOK Guide的な知識と技法の習得も、必要である。それはプロマネの「ハード・スキル」部分だ。だが、それらと並んでもう一つ、プロジェクトへの「スポンサーシップ」も、企業にとっては必須なのである。

スポンサーは、トラブルがひどくなったら自分で出て行って混乱を食い止め、プロマネが倒れそうになったら支え、顧客やステークホルダーを説得して終結まで持ち込むだけの、覚悟が求められる。逆にプロジェクトがうまくいったら、部下であるプロマネを賞賛する。つまりスポンサーという仕事は、良いときは部下を誉め、まずい時は自分が責任をひっかぶる、割にあわない商売である。そういう役割なのだ。そのおかげで、部下であるプロマネが育っていく訳だ。

そして、スポンサーのさらに上位にいる経営層は、スポンサーがきちんと自分の仕事をして、プロマネを育成しているかどうかを評価する。成功したらプロマネの功績を横取りし、失敗したらプロマネに責任をかぶせるような、本来とは逆のことをしていないか、監視する。これが、あってほしい企業の姿だろう。

もう一度いうけれども、プロジェクトは、プロジェクト・スコープという枠の中だけで評価してはいけない。プロジェクトを取り囲む、企業のより大きなコンテキスト（文脈）の中に位置づけて、考えるべきなのである。プロマネに文脈を与えて、上位の戦略や外部環境とアライメントをとるのが、スポンサーシップの役目であろう。]]> http://brevis.exblog.jp/22810621/ 2015-02-16T05:43:00+09:00 2025-12-31T11:05:43+09:00 2015-02-16T05:43:48+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス
どんなプロジェクトも、最初に労力や費用を投下して、最後に金銭や無形の価値を得る、という構造になっている。新製品の開発であれ、新工場の建設であれ、あるいは新オフィスへの引っ越しだって、そうだ。受注型プロジェクトの場合はもっとはっきりしていて、プロジェクトの最初には見積・設計提案などが必要で、無事受注し完了すると代金収入を得られる構図になっている。

そして、投資には労力と金がかかる。労力だって、社内的にはお金が動かないように見えるかもしれないが、経営者から見れば人件費の消費である点に変わりはない。われわれの経済では、純粋に無料なものなど、ほとんど存在しない。だから、プロジェクトは金銭を投下し最後に価値を得る、投資行為だとみることができる。

さて、あなたは何かとっておきの素晴らしいプロジェクトをはじめることに決めた。ただし、手持ちの資金だけでは不足である。誰かからお金を借りる必要がある。世の中には一流の金融機関から街金まで、さまざまなプロの貸し手がいるし、あるいは親戚友人から借りるという手もあるかもしれない。その際、どのような条件が一番あなたにとって好ましいだろうか？

答えはいうまでもない。(1)金利が安い、という条件が一番であろう。しかし、それだけではない。よく考えてみると、お金を借りる際の条件には、他にもいろいろあるのだ。たとえば、
(2)返済期間が長い、というのも魅力的だろう。3年返済と10年返済では、毎年の負担額がまったく違う。多少金利が高くても、返済期間が長いのはありがたい条件だ。

(3)金利が固定、というのもある。住宅ローンなどでは、固定金利か変動金利かを選ぶ場面が出てくる。返済期間が長くなると、将来の利率が不確定だ。いまは不況の上に「異次元の金融緩和策」のおかげで金利は比較的安いが、将来インフレが起きて利率が跳ね上がる心配も、ないとはいえない。だったら、当面の利率は多少高くても、固定金利を選べる方が好ましく見える。

他には？　(4)連帯保証や担保が不要、という条件があるなら、(1)(2)(3)の諸条件がひっくり返るくらい、非常にありがたいだろう。何であれ、事業には将来の不確実性がある。必ず、絶対に成功できます、とあなたは自分で信じ人にも約束するだろう。だが、何が起きるか分からないのがこの世間である。プロジェクトが失敗したときは、手元に何の果実も残らず、ただ借金が残る。その借金のカタとして、家や資産をとられたり、あるいは連帯保証人に迷惑がかかるような事態は、誰だって避けたい。多少金利が高くても、無担保で借りられるなら、それにこしたことはあるまい。

そもそも、担保に差し出せる資産があるくらいなら、別に金なんて借りる必要はないじゃないか。資産がないから、プロジェクトに投資して、資産を増やそうと試みているのだ。ならば、いっそのこと、「プロジェクトという無形の資産」を担保にして、金を借りられないか——じつはこれこそ、『プロジェクト・ファイナンス』という概念なのである。

今度は、視点を貸し手側に換えてみよう。あなたは今度、金貸しである。誰かに金を貸すとき、あなたとしては何を根拠に、お金を貸せるだろうか。金融業というのは、まるで労せずに利息だけを取っていく、ひたすら楽な商売だと思っている人も世間には多い。しかし、それは誤解である。「銀行家の不眠」という諺もイギリスにあるくらい、心配の絶えない商売なのだ。なぜなら、貸した金がちゃんと全部返ってきて、はじめて成り立つのが、金融というビジネスなのだから。だから、貸し手としては、借り手がちゃんと返済してくれるかどうかを、まず問う。その根拠となる条件は何か。

第一の条件は、(1)担保で貸す、である。担保さえ押さえておけば、相手が万が一夜逃げしたって、貸した金額分はほぼ回収できる。わたしが住宅ローンを借りるとき、まず家を担保に差し出さなければならない理由も、また家の価格分には満たない金額しか貸してくれないのも、このためである（家は住み始めたら中古になるから担保価値は割り引かれるのだ）。連帯保証をとる、というのも担保に準じている。取りはぐれなくする工夫だ。

第二の条件は、(2)相手への信用で貸す、である。相手が返してくれると、信用する。親戚友人など、個人間の融資の多くはこれだ。また、企業に対する融資も、一段進むと、このレベルになる。企業の信用力にはいろいろな要素があるが、最大のポイントは、きちんと毎年利益を計上していることだ。金利元本の返済は、黒字だろうと赤字だろうと払わなければならない（赤字だと払わずにすむ法人税とは、その点が全く異なる）。だが赤字が続けば企業が倒れる危険性がある。そうなれば貸した金を回収できなくなる。さらにいうと、企業は市中銀行から借りる以外に社債を発行して金を借りる手段もある。この際に、貸し手の目安となるのが、格付け機関による『格付け』である。格付けこそ信用力を実体化したものに他ならない。

そして、第三の条件が、(3)事業への信用で貸す、である。相手が生まれたばかりの会社で、過去の経営実績もなく、信用力も評価しようがない。連帯保証人もいない。これが全くの新技術・新分野なら、ベンチャー・キャピタル（VC）の出番だ。しかし、相手が取り組もうとしているのが、ある程度、確立した分野のプロジェクトの場合に用いられるのが、プロジェクト・ファイナンスという手法なのである。

たとえば、ある新興国が、地域への電力供給事業に取り組みたいと考えている。工業化と発展のためには、まずインフラとして発電所が必要だ。だが、それを自前で建てる資金がない。一方、ここに先進国の事業会社がいて、あの国のあの地域には電力ニーズが潜在的にあるな、と考えている。投資したいが、相手国側の協力も必要である（通常はインフラ事業ゆえに現地法人の設立が必要だ）。それに、全部を手金でやるのではなく、借金をして、レバレッジをきかせたい。ただし、新興国ゆえに、将来には不確実性もある。プロジェクトが失敗したときに、その借金を全部かぶるのはごめんだ、と考えている。もちろん発電は確立した技術分野なので、VCの出番ではない。

そういうときに、頼りになるのが、ECA（Export Finance Agency）と呼ばれる準政府機関である。ECAは先進国が自国産業の輸出促進のために設立する機関で、その業務にはいろいろあるが、プロジェクト・ファイナンスへの取り組みもその一つだ。その代表格が、日本の『国際協力銀行』（略称JBIC）という存在である。JBICは現在のところ、北米・欧州・韓国などのECAの中で、質量ともにプロジェクト・ファイナンスの最大の融資者なのである。そのことを、日本人はもっと知って、誇りを持っていい。

わたしが主催する「プロジェクト＆プログラム・アナリシス研究部会」では、さる1月28日に、この国際協力銀行の経営企画部長である内藤様を講師に迎えて、初心者にも分かるプロジェクト・ファイナンスのお話しをうかがった。だからわたしがここで書いていることも、大部分は内藤部長の講演の聞き書きを元にした、受け売りの知識である（汗）。

さて、プロジェクト・ファイナンスは、通常の企業融資（コーポレート・ファイナンス）とどこが違うか。その最大のポイントは、「当該プロジェクト事業を専ら目的とした特別目的会社を設立し、そこに対して融資をする。プロジェクト事業が失敗した場合でも、返済請求権を出資元の親会社に遡及（Recourse）しない」という点だ。



図を見て欲しい。通常のコーポレート・ファイナンスでは、事業会社は複数の事業を営んでおり、基本的にはその信用力をベースに融資する。新興国に現地法人を設立して取り組んだ発電プロジェクトが途中で失敗した場合でも、返済請求は出資者である事業会社に遡及されてくる。通常は、そのために「親会社保証状」を要求される（つまり連帯保証である）。あるいは逆に、その新興国の政府自体に、保証人になることを要求するケースもある。これをソヴリン・ファイナンスとよぶ。ソヴリンSoverignとは国王とか主権者のことだ。

ところが、プロジェクト・ファイナンスでは、現地に設立された特定目的法人（これをSpecial Purpose Company = SPCと略す）に融資する。そのベースとなるのは、当該プロジェクト事業の信用のみである。これが失敗した場合、貸し手はお金を回収できなくなる。だから、貸し手としては、いやでもプロジェクト内容の評価に真剣にならざるを得ない。その発電事業の採算性はどうなのか。立地・市場性はあるのか。電力価格（しばしば政策が介入する）は適正か。建設コストやスケジュールは妥当か。設計・調達・建設（EPC）を請け負うエンジニアリング会社は、きちんとしたプロジェクト遂行能力と品質を担保できるのか。どういう契約でEPCを発注するのか。発電所の運転操業は誰がどうやるのか。送電網は誰が用意してどういう条件でつなぐのか、etc., etc...



おわかりだろうか。これは「プロジェクト価値評価」業務そのものである。そして、貸し手が一切を合意・承認できる計画条件でない限り、融資は行われない。借り手にとっては、ある意味、うるさい限りだ。おまけに、金利は、通常の融資より少し高い。当然のことだろう。貸し手は貸し倒れのリスクを、その金利に含めざるを得ない。

ここで、ちょっと簡単な計算をしてみよう。今、あなたは裕福金満な貸し手である。あなたは、担保能力のない新興国の新設会社に、自分の手金を融資する。その金額をCとしよう。返済時には、利息として利率Rを加えた金額を返済してもらうことにする。つまり、返ってくるお金は (1+R) Cで、融資による純粋な利益は、差し引き RCとなる。では、あなたは利率Rを、いくらに設定すべきだろうか。

もしこの新設会社のプロジェクトが失敗したら、あなたはCだけ損失を被る。いま、このプロジェクトが失敗するリスク確率をrとしよう。すると、rC が、あなたが潜在的に抱えている貸し倒れ損失金額の期待値だ（これをリスク・エクスポージャーという）。また、あなたが得られる利益の期待値は、成功する確率を乗じた(1-r)RCということになる

である以上、あなたとしては、利益の期待値が、損失金額の期待値を上回るように、利率を設定しなければいけないことになる。

(1-r)RC > rC

この式を変形すると、次のようになる：

R > r/(1-r)

これが、あなたの設定すべき利率なのだ。この条件には、C（いくら貸したか）は一切現れないことに注意して欲しい。純粋に、相手のプロジェクトが失敗するリスク確率が問題なのだ。それがもし10%なら、あなたは0.1/(1-0.1) = 11.1%を、もし20%なら、0.2/(1-0.2) = 25%を、最低でも利率としなければならない。

現実には、金融機関は手金を融資するわけではない。そこで、実際の利率は、基準となる市中金利（たとえばロンドン銀行間金利LIBORなど）をベースに、自社の運用したい水準を設定した上で、上記のRの分を加算しなければならない。このRを、『リスク・プレミアム』と呼ぶ。そこでは、年間の貸し倒れリスク確率（年次デフォルト率）が問題となるわけである。

プロジェクト・ファイナンスでは、JBICなどECAだけでなく、民間銀行もシンジケートを組んで融資することが多い。より正確に言うと欧州系のECAは保証業務だけを行うので、必ず民間銀行が必要になる。そして、この種のファイナンス組成のためには、客観的な評価が必要だから、プロジェクト事業の専門家をはじめ、法務・財務・金融・国際関係など様々な専門家が世界中から集まって、協議交渉を続けることになる。言語は、当然ながらすべて英語である。期間も、半年や1年以上はザラだ。金銭をめぐる交渉は文字通り、切ったはったのツバぜり合いである。それだけ大変な仕事だが、そのかわり世界の一流の専門家とやり合えるわけだから、非常にやりがいのある仕事だともいえる。

先ほど述べた研究部会でも紹介された興味深い事実は、プロジェクト・ファイナンスの方が、じつは案外デフォルト率が低い、という統計である。Moody’sは約4,000件のプロジェクト・ファイナンスの実績を調べ（その中の約300件がデフォルトを起こした）、累積デフォルト率はMoody’sの通常のBaa/Ba格付と同等であることを見いだした。しかも、年次デフォルト率の推移を見ると3年目から一貫して低下を続け、10年後にはシングルA格をこえている（!）。したがって、「プロジェクトファイナンスはリスク耐性の強い特別なコーポレート貸付である」と彼らは結論づけている。プロジェクト・ファイナンスの組成は通常より時間がかかるし、事業者に対してはあれこれと口を出して縛りが多いわけであるが、それがプロジェクト・ガバナンスのレベルを向上する効果を生んでいるのである。

ここでは、プロジェクト・ファイナンスという奥の深い世界の、とば口の一端を紹介したに過ぎない。しかし、それがプロジェクト客観評価に密接に関わっていることはお分かりだと思う。わたしがかねてから主張している、プロジェクトの価値やリスクを客観的に評価できるプロフェッショナル＝『プロジェクト・アナリスト』の必要性も、このMoody’sの統計調査などから支持されているといえるだろう。JBICにご出馬いただくまでもないような通常の企業のプロジェクトでも、その価値や投資の正当性について継続的・客観的な把握が必要であり、きちんとしたガバナンスも重要である。そのような観点から、プロジェクト・ファイナンスの構造について、もっと皆が関心を持つべきだとあらためて感じた次第である。]]> http://brevis.exblog.jp/22712067/ 2015-01-08T12:29:00+09:00 2025-12-31T11:05:43+09:00 2015-01-08T12:28:46+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス 「プロジェクト＆プログラム・アナリシス研究部会」2015年の第1回会合を、下記の要領にて開催いたします。
（訂正）：最初、この記事で1月27日(水)と書きましたが、1月28日(水)が正しい日付です。お詫びして訂正します。

皆さんは「プロジェクト・ファイナンス」という仕組みをご存じでしょうか？　プロジェクトそれ自体の価値を担保として、必要な資金を調達する手法です。どんなプロジェクトも、費用・時間・労力を投入して何らかの価値ある結果を作り出す投資事業と考えることができます。とくに資金を十分に持っていない者に対し、有形の担保でもなく連帯保証でもなく、プロジェクトそれ自体の価値とリスクを評価して、金融機関がお金を貸してくれるという仕組みがプロジェクト・ファイナンスです。

今回は、国際協力銀行株式会社の内藤英雄様にご講演いただきます。内藤様は国際協力銀行（略称・JBIC）の経営企画部長であり、本分野のプロ中のプロともいえる方ですが、今回はとくにお願いして、我々初心者にもわかりやすいプロジェクト・ファイナンスの入門編ともいうべき内容のお話をしていただきます。

プロジェクト・ファイナンスは従来、途上国における資金調達方法として発達してきましたが、最近は国内外を問わずいろいろな場面で注目されるようになってきました。これから新興国での海外型プロジェクトにチャレンジする日本企業にとっても、また国内で新しい事業創出に取り組もうとする人にとっても、大いに参考になるはずです。ぜひ、ご期待ください。


＜記＞

■日時：2015年1月28日（水）　18：30～20：30

■場所：三田キャンパス・旧図書館・小会議室
http://www.keio.ac.jp/ja/access/mita.html
キャンパスマップ・【2】になります

■講演タイトル：
「プロジェクトファイナンス ― 基本・特徴・課題 ―」

■概要：
　「プロジェクトファイナンス」（PF）は主に大規模プロジェクト向けの長期ファイナンスの金融手法の一つで、海外の資源開発やインフラ事業等において積極的に活用されています。日本でもPFI（Private Finance Initiative）事業向けのファイナンス手法として普及しつつありますが、海外と比べますと、まだまだ発展途上の段階です。当日は、PFの基本的な内容や特徴から始め、PF組成に必要なリスク分析や関係者間でのリスク分担等の内容についてもご紹介し、時間の許す限り、PPPやPFI等の民活インフラ事業を進める上での実践的な課題についてもご案内したいと考えています。


■講師： 内藤英雄　（国際協力銀行株式会社）

■講師略歴：
・1985年（昭和60年）3月　一橋大学（社会学部）卒業
・1985年4月　日本輸出入銀行（現（株）国際協力銀行）入社
・2011年1月　欧阿中東ファイナンス部長
・2011年7月　電力・水事業部長、プロジェクトファイナンス協議会議長
・2013年7月　経営企画部審議役
・2013年12月　経営企画部長（現職）


■参加費用：無料。
　ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金（\1,000）は免除されます。

　参加を希望される方は、確認のため、できましたら当日までに佐藤までご連絡ください。


佐藤知一＠日揮（株）]]> http://brevis.exblog.jp/22221532/ 2014-07-21T22:51:00+09:00 2025-12-31T11:05:43+09:00 2014-07-21T22:51:14+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス
三角形の一片の長さは、他の辺に影響を与えずに変えることができない。同じように、プロジェクトの三つの制約条件は、独立でなく必ず他と関わり合っている。例えばプロジェクトのやるべき責任範囲である「スコープ」が増えたとしよう。すると「コスト」が増えるか、「スケジュール」が伸びるか、あるいはその両方が必ず起きる。そこでプロジェクトマネージャーは、これら3つのファクターの相互関係とバランスを、よく考えながらコントロールする必要がある。

ちなみに、製造業の三大ファクターと言えば「QCD」、すなわち、品質(Quality)・コスト(Cost)・納期(Delivery)である。プロジェクトの場合は、品質で三角形を書くこともあるが、ふつうはスコープを用いる点が大きな違いだ。では品質はどこに行ったのかというと、品質を確保し保証し検証するための活動(activity)として、スコープが含んでいると解釈される。品質要求のレベルに応じて、プロジェクトのスコープが増えたり軽くなったりする訳である。

ところで、現代プロジェクト・マネジメント理論（モダンPM論）の中心的な技法は、

　・WBS (Work Breakdown Structure)
　・EVMS (Earned Value Management System)
　・CPM (Critical Path Method, PERT/CPMとも表記)

である。これらを知らずに、プロジェクト・マネジメントは語れまい。PMBOK Guide(R)などでも丁寧に記述している。

とくに計数管理が必要なプロジェクトでは、上記は必須の技法である。計数管理は、ほんの数人・数ヶ月程度のプロジェクトを一度やるだけなら、たいして要りはしない（リーダーシップやチームワークや「気合い」で乗り切れる）。だが、大規模な場合や、小規模でも複数プロジェクトを常時動かしている場合は、数字でのコントロールがやはり大事になってくる。

ところで、上記の三つのマネジメント技法は、それぞれがちょうど『鉄の三角形』の三辺に対応している。スコープをマネージしたければWBSを、コストをマネージするにはEVMSを、そしてスケジュールにはPERT/CPMという具合だ（図参照）。この対応関係は、偶然の産物ではあるまい。プロジェクトを運営して行くにあたって、最大の制約条件を何とかコントロール下におさえるべく、上記三つの技法がそれぞれ発達してきた、という事情なのである。



ちなみに、プロジェクトの難しさや失敗率について語るとき、米国Standish Groupの統計が引用される。これは3年に一度行われる大規模調査の統計である。そこでの成功・失敗の定義は次のようになっている（2003年度版による）。

(1) Successful: completed on time, on budget, with all specified features.
(2) Challenged: completed and operational, but over-budget, over time and with fewer features than specified.
(3) Failed: the project is cancelled before completion or never implemented.

すなわち、品質・コスト・納期を計画通り満足して終わった「成功プロジェクト」と、完了したが3 大制約条件を満たせなかった「困難なプロジェクト」、そして中断終了した「失敗プロジェクト」のクラスがある。かくて、WBS, EVMS, CPMのマネジメント三技法は、プロジェクトの成功率を高めるために貢献する訳だ。

もちろん、WBSにせよEVMSにせよCPMにせよ、技法の中核的アイデアは単純だが、実際に適用となるとかなり奥が深い。わたしの所属するエンジニアリング業界では、コスト・エンジニア、スケジュール・エンジニアなどの専門職が形成されており、プロマネの参謀的なスタッフとして、マネジメントを補佐していく。プロジェクト・マネージャー自身も、この三つの技法について、ある程度は習熟し、議論でき、きちんと決断できるだけのハード・スキルが望まれる。『鉄の三角形』を御すのは、決してたやすい仕事ではない。

しかし。

プロジェクトには、もっと別の難しさもある－－そういう風に、わたしは最近つよく感じるようになった。それは、プロジェクトは予算内に完遂するが、成果物に価値が見いだせない、という形での失敗だ。仕様どおり作ったけれど使われなかったシステム、予算内に完成したけれど利用客のさっぱり来ない道路や空港、期日どおり出荷したが売れない新製品・・わたし達のまわりには、そうした失敗例が、実はあふれているのではないか。そして、このような失敗は、上記のStandish Groupの統計の、どれに分類されるのだろうか？　明らかに、どれでもあるまい。

だとすると、プロジェクトは、スコープ・コスト・スケジュールの『鉄の三角形』を守るだけでは、不十分なのだ。こうした失敗はそもそも、プロジェクトのゴール、プロジェクトが生みだすべき成果物に、十分な利用価値が見いだせない状態なのに、最後まで進めてしまったことに原因がある。である以上、プロジェクトを途中でいったん止めて、ゴールや成果物を根底から見直すべきであるし、それが無理ならば、プロマネを交替させるか、いっそプロジェクトを中断撤退すべきだったのだ。

では、その判断を下すべきなのは、誰か？

明らかに、プロジェクト・マネージャーではない。プロマネは、自分で始めたプロジェクトを、途中で降りる権限はない。プロマネ自身を罷免する権限もない（自分で辞任することはできるが、「罷免」とは本人が望まないのに強制的に辞めさせることである）。

である以上、その決断を下すべき者は、プロマネより上位に位置する権限者である事が分かる。それは、プロジェクト・オーナーかもしれないし、ステアリング・コミッティーかもしれないし、場合によってはプログラム・マネージャーかもしれない。ともあれ、プロマネを任命した権限者が、プロジェクトの価値や行く末について、要所要所でジャッジするべきなのである。

“ある程度の自立性（自律性）を持つ組織を、どう動かすべきか”の方策を、『ガバナンス』と呼ぶ。自律性を持つ組織に対し、何かの役割を委託した際に、委託した側の利益や期待に合致するように働いてもらう必要がある。そのためには、どうコントロールをきかせるべきかが、ガバナンスだ。株主が会社の運営を役員に委託する際に、株主利益から反しないようにはかることを企業ガバナンスと呼ぶのが、その典型である。

ガバナンスでとくに大事なことは、相手が勝手に変な方向に進んでいかないようにすることだ。何かをまかせる以上、資源をおかしなことにつかわれてはまずい。したがって、上に書いたように、プロジェクトの方向性を適時ウォッチし、成果物が期待した価値を生みだすように下す判断は、プロジェクト・ガバナンスの領域なのである。

旅客の来ない空港、使われない情報システムは、まさにプロジェクト・ガバナンスの不全を示している。プロジェクトの最大の失敗は、ガバナンスがきちんときかないことなのだ。

そこで、PRINCE2の登場である。先日、わたしが主査を務める「プロジェクト＆プログラム・アナリシス研究部会」では、講師に落合和雄氏を招いて、英国のプロジェクト標準であるPRINCE2の勉強会を行った。その席上、落合氏が開口一番いわれたことが、

　「PRINCE2は、プロジェクト・マネジメントよりもプロジェクト・ガバナンスの方法論です」

という言葉であった。PRINCEの原型は、1989年、イギリス政府の情報システムのプロジェクト・マネジメントの標準として中央電子計算機局 (CCTA) が開発した。やがてこれは、IT向けに政府機関以外でも使われるようになる。そして、より汎用的なマネジメント手法として PRINCE2 が1996年に発表され、今や英国でのプロジェクトのデファクトスタンダードとなっている。

PRINCE2の中心にあるのは、段階的な漸進主義（Manage by stages）と、プロジェクトのもたらす便益（Benefit）へのフォーカス、そしてマネジメントの階層性である。PRINCE2では、プロジェクト・マネジメント・チームならびにその機能には、3つの階層がある。

(1) Project Board - Directing （プロジェクト理事会　－　方針指導）
(2) Project Manager - Managing （プロジェクト・マネージャー　－　マネジメント）
(3) Team Member - Delivering （チーム員　－　実務）

という階層になる（なお、PRINCE2にはまだ日本語版の正式翻訳がない。上記の括弧内は、わたしの勝手な意訳である）。

そして、指示は上から下へ、報告は下から上に伝えられる。とくに、コスト、スケジュール、スコープ、品質、リスク、ベネフィットにおいて、何らかの予期せざる大きな変動があった場合、必ずそれは上位組織に対して報告され、判断を仰がなければならない（Manage by exception＝例外管理）。組織は、「許容できる変動の範囲（tolerances）」をあらかじめ定めておく。

こうして、プロジェクトが、上位組織の知らぬ間に変な風に進まないよう、たがをはめておくのである。まさにガバナンスである。ちなみに、Project Boardよりもさらに上位の階層は、企業（Corporate）ないしプログラム・マネジメントだと規定されている。PMBOK Guideは「プロマネがどうプロジェクトをマネージするか」を中心テーマに据えて、いわばプロジェクトという単位の中で考えている。これに対しPRINCE2は、プロジェクトを企業活動全体の文脈の中にはめこむことに、苦心している。

落合氏は、元大手SIerのSEという異色の経歴を持つ税理士だが、「PRINCE2のようなきちんとしたガバナンスの発想は、日本企業にはとても必要だが、もしかすると文化的に受け入れられないかもしれない」と言われた。「しかしPRINCE2を見ていると、世界中の植民地を支配した大英帝国の根っこにある考え方が、本当によく分かる」とも。

わたしの受けた感想は、また方角が少し違うものだった。PMBOK Guideが記述する10のマネジメント・エリアやそのプロセス群は、受注型プロジェクトによくフィットする。他方、RPINCE2の規定する概念や手順は、むしろ自社が自発的に行うタイプのプロジェクトに向いているのではないか、と感じたのである。

もともと、初期のPMBOK Guideは、米国の防衛宇宙産業とENG産業の人たちが中心になってまとめたものだった。だから、受注型ビジネスが主軸になるのは当然なのである。そして、受注型プロジェクトの最大の特徴とは、スコープ・コスト・スケジュールの三大制約が厳しいことにある。だからこそ、その三つを統括する立場にいるプロマネには、かなりの権限が与えられ、決断がなされるべき、という思想になる。

PRINCE2はむしろ、オープンエンドな自発型プロジェクト、たとえば自組織（官庁を含む）が発案し投資する情報システム開発などが典型例である。そこではむしろ、プロジェクトの方向性と、組織全体の方向性のアライメントが重要なのである。だから、ある意味では過剰に上から介入される（ように見えかねない）3階層モデルや例外管理が大事とされるのだ。

したがって、PRINCE2は、製造業におけるBOM再構築プロジェクトなどには最適ではないかと感じる。あるいは新製品開発や、業務改革プロジェクトなどにもいい。こうした種類の自発型プロジェクトは、“基本設計さえ決めれば、あとは力仕事”というスタイルでは進めにくい。むしろ、“考え考え、少しずつ進んでいく”スタイルがあっている。いいかえれば、「歩きながら考える」である。欧州の定番ジョークに、“フランス人は考えてから走り出す、イタリア人は走ってから考える、そしてイギリス人は歩きながら考える”というのがあるが、PRINCE2はまさに、歩きながら考える英国文化の産物なのだろう。

＜関連エントリ＞
　→「プロジェクト・リスクとは目標の反対概念である」 (2013-09-08)]]> http://brevis.exblog.jp/19964608/ 2013-03-18T22:57:00+09:00 2025-12-31T11:05:43+09:00 2013-03-18T22:56:48+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス
ただし読んでいて少し疑問に思ったこともあった。そもそもマネジメントの本来の原義は、「人を動かして目的を達すること」である。部下の使い方は、その意味でマネジメントの基本中の基本である。その著者は金融業界出身で経営コンサルタントに身を転じ、 MBAの資格も取っていた。にもかかわらずマネジメントの基本については、何も知らななかったということになる。マネジメントの基本を知らない人が、なぜ他人の会社経営については助言できると思えるのだろうか？

ここ何回か、ガバナンスの問題について続けて考えてきた。ガバナンスとは、ある程度の自立性を持つ相手を、自分の利害関係に沿った形で動かすための仕組みである。子会社を動かす場合がその典型だし、社内の組織や部門を動かす場合もその一つである。マトリクス型組織の中で、いろいろな機能部門をプロマネが動かす仕組みを、プロジェクト・ガバナンスとよぶこともある。自分の部下だけで完遂できる中小規模のプロジェクトと違い、クロス・ファンクショナルな仕事では、どうしても直接の命令権の及ばぬ部門にも動いてもらわねばならぬ。

先にあげた、部下をどう動かすかという問題も、ガバナンスとかなり共通した面がある。もちろん個人と組織では大分違うわけだが、自由放任だけでも厳格な指示命令だけでも、なかなかうまくいかない点は共通している。では、適切なガバナンスのあり方とは、どのようなものなのだろうか。

このサイトでは、まず、ガバナンスには3つのレベルがあるという話を書いた（『ガバナンスと自由の３つのレベル』）。３つとは、中央集権型、承認型、そして可視化型である。ガバナンスの強さはこの順に弱くなる。そして、さらに外側に自由放任型が来る。いろいろなガバナンスのあり方は、この類型ないし尺度のどこかに定置できそうだ。

その次には、国と地方自治体のガバナンスの関係について書いた（『ネストする地名の謎』）。明治に成立した近代日本のガバナンス体制は、国が都道府県に自治権をあまり与えぬ中央集権型であった。その手段として、恣意的な合併や、名称の操作なども利用した。このような制度設計は官庁・民間問わず、その後の日本の組織に大きな影響を与えたに違いない。

さらにそこから派生する話題として、コストセンターとプロフィットセンターの区別について考えてみた（『コストセンターとは何か』）。コストセンターとはお金だけかかって、何も生みださぬ組織であるかのように誤解されている。しかし経営学的に考えれば、コストセンターとはコストとサービスレベル（品種・納期など）に対して管理責任を持つ組織である。サービスレベルがきちんと定義されないと、コストセンターはただただコストダウンを要求されるだけの、自律性のない組織になってしまう。

さらに言うと「コストセンター子会社」という呼び方は、会計学的には間違いだ。この言葉は多くの場合、親会社からの収入に100%依存している機能子会社のことを、暗に指している。そして外販比率が高くなると、子会社は「プロフィットセンター」と呼んでもらえるようだ。プロフィットセンターになりさえすれば、少しは格が上がり、親会社からのうるさい干渉をはねつけやすくになる、と理解している向きも多い。「コストセンター」の用語を、このように妙に差別的な意図で使うのはおかしいと思うが、世の中に横行しているのは事実である。

では、これら一連の考察から見えてきたものはなんだろうか？　なぜ「コストセンター」論と、一見無関係なガバナンスのあり方が、一つながりのものとして意識されるのか。そもそも企業ガバナンスの原義が、「企業経営の方向性を、株主の利害に一致するよう保証する仕組み」であるならば、子会社の株主は親会社なのだから、どこまで口をはさんでもかまわぬ、適切な限度など無い、という結論になりはすまいか。

ここで問題となるのが、中央集権型ガバナンスの限界ないし短所である。短所は二つあった。まず、あらゆる判断が上位の決定に委ねられるわけだから、上位側の情報処理能力がかなり高くなければいけない。かつてフセイン大統領時代にイラクに住んでいた研究者から聞いた話だが、生活上の、アパートの不都合か何かを知人にこぼしたところ、「だったら大統領府に直接かけあえばいいじゃないか」と言われたという。これを聞いて、独裁者というのはひどく忙しいものだな、と思った。あらゆる細かな問題や雑事が上がってくるのである。ナポレオンの睡眠が3時間だったというのも、たぶん寝ているヒマがなかったのではないか。

中央集権型のもう一つの欠点は、現場の問題の解決に時間がかかることだ。はるか上までお伺いを立てるのだから、当然だろう。だから、比較的平穏で、問題の少ない職場や業界ならばいいだろうが、リアルタイム性の高いトラブルが頻発する組織では、中央集権型ではやっていけなくなる。情報のパイプだって輻輳し、詰まってしまうだろう。

そこで考案されたのが、Management by Exception（「例外による管理」）だった。これは、「異常時が発生したときだけ報告を上にあげ、上位側が問題解決に乗り出す」方式だ。異常がないときは、報告はあまり小刻みには上げない。そうすることで情報の輻輳を避け、上位側が本来業務に集中できるようにするのである。逆に言うなら、通常でのガバナンス・レベルは、少し下げることになる。

ところで、問題解決について言うなら、どんなに優秀な上位管理者でも、分野的な得意不得意はあるはずだ。自分が経験しよく知っている事象なら解決できるが、自分から縁遠い分野では、うまく指示できにくい。ここにもう一つのポイントがある。つまり下位側の問題解決力がどれだけあるか、である。もし下位側の自己管理能力が高い場合は、方向性と状況だけを見えるように指示し、内容は任せてしまう方が現実的となる。

以上をまとめたものが、図に示した４類型である。ここでは子会社へのガバナンスの問題として表現している。縦軸は、その子会社業務の、上位側（本業）から見た重要性、あるいは本業とのシナジーである。横軸は、子会社の自己管理能力だ。これは、外販比率と置きかえてもいい。というのは、自己管理能力は「プロフィットセンター」としての自立経験を通して培われるからである。



左上の象限は、本業から見た重要性が高く、かつ子会社の自己管理能力が低い場合。当然、細部まで指示命令を下す「中央主権型ガバナンス」になる。ところで、親会社（内販）依存だが重要性が低い、左下の象限は、「承認型ガバナンス」（例外による管理）が現実的である。問題発生時には上位側が入り込んで解決せざるを得ない。

右上の象限はこれに対し、外販比率が高く、自己管理能力の高い子会社で、かつ本業ともシナジーの高い分野を示す。こちらは「可視化型ガバナンス」で、業務の進捗状況をモニタリングできるようになっていればいい（問題は自分で解決できる）訳である。最後に残った右下の象限は、シナジーも低く、外販中心の分野。ここはもう「自由放任型」になる。そのかわり、投資も自分で負担してくれ、ということなる。

このように整理してみると、最初にあげたガバナンスのレベル０～レベル３が、どれもぴったりはまる位置があるようだ。何もかも中央集権や自由放任ではなく、どのタイプにはどれを当てはめるのが適切か、軸が分かったように思う。

ところで、現実には問題が一つだけ残っている。それは「自己管理能力」の評価が、上位側と当事者ではちがう、という問題だ。人間の世界でも、子どもの側はもう自立したつもりなのに、親はいつまでも世話を焼き小言を言いたがる、という例は多い。上位側がいつまでも下位側の能力を過小評価すると、いつまでも中央集権型ガバナンスから抜け出せず、その結果、組織全体として非効率が生じる可能性がある。

そういう意味では、自己管理能力≒外販比率、と図示したが、これは本当はフェアではない。先に述べたように、本来は内販100%のコストセンターでも、サービス・レベルをきちんと定義できれば、自律的な管理ができるのである。自己管理能力は、コストセンターとしての達成経験等によっても、培われるはずだ。だからガバナンスの設計においては、組織の自己管理能力をたえず再評価する仕組みが必要だということが分かるのである。]]> http://brevis.exblog.jp/19855969/ 2013-02-25T23:23:00+09:00 2025-12-31T11:05:43+09:00 2013-02-25T23:24:10+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス
企業行動をその株主の利害に一致させるという点では、子会社政策のあり方も「ガバナンス」の一種であると考えられる。親会社と子会社の関係には、全面的指示から自由放任まで、後述するようにいろいろなパターンがあるが、どれをとるのが適切かを考えるときに「ガバナンス問題」が論じられるのである。

これが「ITガバナンス」となると概念はもっと茫漠としている。経産省の定義によれば「企業が競争優位性の構築を目的としてIT戦略の策定及び実行をコントロールし、あるべき方向へと導く組織能力」なのだそうだが、だとしたら経産省自身のような官庁・公共団体のITガバナンスはどうなるんだ、とツッコミを入れたくもなる。そもそもこの定義だと、ITのマネジメントとどこが違うのか、疑問が生じる。マネジメントとはまさに、戦略や計画を策定し、組織を動かして実行をコントロールすることではないのか？

しかし、このITガバナンスという言葉には、妙なところで出くわすことがある。今でも思い出すのは10年近く前、ある大企業の本社を訪れた時のことだ。某地方の工場（製造子会社）の複雑なスケジューリング問題に関連して、いろいろと知恵を絞って解決策となるはずのシステム構想を作成した。計画系だけでなくMES（製造実行システム）をうまく組み合わせた点に工夫があると自負していた。

見積書を客先担当者に提出し、それなりの評価をもらったな、と感じたのはいいが、「予算は工場子会社が出すが、本社の情報システム部門に説明して了承をとってくれ」、という。（それって本来あなたの仕事じゃないの？）という気もしたが、そんなことを言っていたら仕事は取れない。のこのこ本社に出かけて情報システム部長に面会したところ、ちょうどそのころ某最大手ERP導入が佳境に入っていてイライラしていたらしい。言下に「NO」と拒絶された。理由を聞くと、「ITガバナンスの観点上」という。

「ITガバナンスの面でどういった問題点があるのでしょう？」と質問したが、あまり明確な理由はない。「今のこの時期に、こんな金額の投資は認められない」というだけだ。本社に相談せずに、現場側で先走ったとの印象を持たれたらしい。「お金は別に貴方が出すわけではなく、子会社が負担するんでしょ」と口に出かけたが、それを言ったら喧嘩になるだけなのは見えている。本社の『ガバナンス』の壁にすごすごと引き下がるしかなかった。今でもあの工場は、複雑なスケジューリングを、たった一人の担当者のExcelスキルでまわしているのかな、と思う。

顧客の意思決定権限を確認するのは、セールスの基本だ。営業的な手順を間違えたわたしの失敗談はさておき、「ガバナンス」という言葉が使われる局面をいろいろ調べていくと、ひとつの共通点に気がつく。それは、“ある程度の自立性を持つ相手を、どう動かすべきか”という局面である。「自立性」がキーポイントだ。子会社などその典型である。相手は一応、企業として自分で稼いで利益を上げている。だから自分の行動は自分で決められる（はずである）。しかし親会社は、自分たちが望む方向性にベクトルを合わせたいと考える。これが、自立性のない相手、たとえば直接の部下だったらガバナンスではなく「マネジメント」になるはずだし、意識を持たぬ機械だったら「コントロール」（制御）と呼ぶはずである。あるいは外注先の場合も、発注金額と契約書で勝手な自立性を縛っているわけだから、ガバナンスなどとは誰も言わない。これはITに限らず、どの分野でも共通である。

このガバナンスのあり方だが、具体的な仕組みや方法はさておき、大きくいって三つのレベルがあるのではないかと考えられる。それは「統治力」の強さによって分類される。相手の「自立性」をどれだけ制限するか、と言い直してもいい。（わたしの好きな用語でいえば、相手の「自由度」を制約する度合いである）

統治力として最も強いのは、完全な中央集権的ガバナンスである。上位側が、相手側の一挙手一投足、箸の上げ下ろしまですべて指示命令を下して実行させる。自立性はほぼゼロだ。決められたことをやるだけ。そのかわり、結果の責任も全部、上位側が引き受けることになる（当然だが）。むろん、投資などの費用も上位側がすべて負担する。

この対極にあるのは、自由放任だ。いちいち指示はしない。とにかく自分で動いて勝手に稼げ、と。もっとも、完全な自由放任で、相手が何をやっているのかもわからない状態だと、「ガバナンスは存在しない」と同義だ。だからこれをガバナンス・レベル＝０と呼ぶことにしよう。

では、最低限のガバナンスとは何か。それは、相手側の行動が上位側につねに見えるようにしておくこと、すなわち「見える化」「可視化」の実現である。これを、ガバナンス・レベル＝１、と考えよう。相手の行動は見えるが、何かを決めるのは基本的に相手側の自立（自律）によっている。このレベル１ではふつう、大きな問題や異常が起きた時だけ、上位側に相談がくることになる。

レベル１と、先ほどの中央集権型ガバナンスとの中間レベルには、どんなものがありうるか。それは、「承認型ガバナンス」であろう。予算あるいは権限のどこかに上限を設けておいて、そこを超えるような事案については、上位側の承認をうける。上位側は審議権（拒否権）を持つ。これをガバナンス・レベル＝２と呼ぼう。レベル２は、会社とプロジェクト・マネージャーとの間などでもしばしば取り交わされる形式だ。こうして、プロマネが自分の恣意性や私益のために、勝手に巨額発注することを防ぐのである。この順でいえば、中央集権型はレベル＝３になる。もちろん中間レベルをさらに細かく区分することも可能だが、そういう議論は学者にまかせよう。

レベル0からレベル3まで、図式化すると下図のようになる。レベル0はガバナンスの範囲外である。1－3のレベルに従って、上位からの指示命令（権力）は強くなるし、逆に対象側の自由度は小さくなる。自由度とは何かというと、つまり指針がない状態のことである。さらに、これらと対になる項目として、ビジネスの結果への責任と、投資の費用負担をあげても良いだろう。指示命令の力が強いほど、結果への責任が大きくなり、投資は対象側の負担比率が下がる（上位側の負担比率が上がる）。つまり、金も出すし口も出す、という状態である。どれをとるかは、その企業グループの経営方針によるが、同時に、相手側のビジネス環境や市場変化の速度、上位側からの注文への依存度などなどで、一番まともなレベルを選ぶべきである。企業だけでなく、地方自治などもこの図式でみると分かりやすい。



そして、大体において議論がこじれるのは、この4つの項目の比重がアンバランスになる場合だ。上位側が口は出すのに金は出さない、とか（上にあげた某大企業のケースはややこれに近いかもしれぬ）、相手側は自立した稼ぎがあまりないのに自分で全部決めたがるとか。口を出すのに責任はとらない、あるいは、言うことを聞かないのに投資ばかり求める、などなど。

考えてみると、サラリーマンが飲み屋で議論したがる問題点も、ある意味で「上位側=上司」と「相手側=自分」との自由度と責任の確執ばかりだといっていい。つまり、「ミニ・ガバナンス問題」なのである。部下には通常自立した予算執行権はないから、厳密にはガバナンスと呼ぶべきではないだろうが、上司が部下の仕事にどこまで指示（介入）するかは永遠のテーマでもある。

ただし、一つだけ忘れてはならぬ事がある。それは、ガバナンスのレベルを中央集権に近づければ近づけるほど、上位側の情報処理能力がたくさん要求されることだ。相手側の箸の上げ下ろしまで指示するわけだから当然だろう。それも、業務が正常に回っている間はまだ良い。問題は、異常が発生したときだ。異常が大きく、リアルタイム性が高ければ高いほど、上位側の処理は間に合わなくなるだろう。だから現場側に権限移譲が必要になるはずだ（現場が責任を上にかぶせて逃げる傾向があれば別だが）。逆に現場側に隠し立ての傾向が強く、あまり「可視化」できていない組織の場合、重大な問題を上位側がつかむのが手遅れになりがちだ。その場合は上位側が相手に踏み込まなくてはならない。

つまり、ガバナンスのレベルをどう決めるかのルール決めはもちろん大切だが、「どういうときは、そのルールを乗り越えなければならないか」を共有することの方がもっと大切なのである。だからこそ、ガバナンス問題は難しいのだ。]]> http://brevis.exblog.jp/18293202/ 2012-07-01T22:03:00+09:00 2025-12-31T11:05:43+09:00 2012-07-01T22:03:20+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス
ところで、今回はまったく逆のことを書こうと思う。すなわち、プログラム・マネジメントはプロジェクト・マネジメントの上位概念ではない、という話題だ。なぜこんな矛盾したことを書くのかというと、それは国際標準の概念規定に、じつは目に見えない混乱があるためだ。でも、まずは（いつものように）ちょっと別のエピソードから入って、斜めの角度でこの問題にアプローチしてみたい。

先週わたしのところに、プロジェクト部門から電話がかかってきて、「佐藤さん、出張精算書を今週中に必ず提出してください」と催促があった。先月中旬、そのプロジェクトの用件で中東に一泊三日の短期出張に出かけたのである。他にも仕事を抱える身だったので、日曜の夜行便で出発して、月曜の午後と火曜一日だけ向こうで打合せに参加し、また火曜夜の夜行便で戻る（時差があるから水曜夜に成田帰着）、というとんぼ返りのスケジュールだった。会議の主題は、これから実行段階に入る巨大プロジェクトのリスク・アセスメントで、二日間の会議の議長として客先から呼ばれたのである。

ところで、このプロジェクトは『実費償還契約』（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とか、明確なスコープ・バウンダリーを前提するプロジェクト・マネジメント技法はそのままでは適用しづらいだろう。だから、ある程度、“固いスコープ”の部分と、“柔らかでオープンエンド”な部分を有機的に組み合わせていかざるを得ないだろう。

いずれにせよ、プログラムであるかどうかは、実行する側の主体性の強さによって定義すべきだとわたしは思うのである。]]> http://brevis.exblog.jp/18246750/ 2012-06-24T22:44:00+09:00 2025-12-31T11:05:43+09:00 2012-06-24T22:43:47+09:00 Tomoichi_Sato B6 プログラム・PMO・ガバナンス
さて、ラ・フォンテーヌ汐留で開催されたこのイベント、たしか30人近い人たちが参加した。その多くはIT業界である。好川さんは最初にキーノート・スピーチとして問題提起をされた。多くのプロマネにとって、仕事が苦しくなってきているというが、それをどう打開するべきか。苦しくなってきている、の箇所は、統計的な証拠を示したり会場の意見を聞いたりして、ほぼ全員の賛同するところとなった。その先の論理展開については、好川さんの言葉どおりというよりも、わたし自身の解釈（誤解?）も交えた形になるが、こんなストーリーだったと思う。

従来、日本企業では、組織のサポートが不十分なままプロジェクトをプロマネにまかせ、足りないところは「リーダーシップ」を発揮しろ、とやってきていた。ところが過去10年間かけて、PMBOK GuideやPMPの資格が次第に浸透・普及してきた。これととともに、組織のサポートはしっかりして来つつある。また多くのIT系企業では、PMO（Project Management Office）組織も設立され、プロマネを支援・指導するようになった。

だが、その結果、プロマネの仕事はしだいに『中間管理職』化してきている。わたし自身、PMOの仕事を何年もやったから知っているが、あれはプロマネから見ると一種の小姑のような組織なのである。うるさいことこの上ない。しかも、顧客から指定されるScope, Cost, Scheduleの制約条件＝『鉄の三角形』は、ますます厳しくなるばかりだ。

この状態を脱却するために、プロジェクト・マネージャーはビジネスを創造する方向に、もう一度リーダーシップを発揮すべきだ、というのが好川さんの主張だと理解した。ここでいう「リーダーシップ」は、10年前に会社がプロジェクト・リーダーという名前の一担当者に押しつけていたそれとは、内容を異にしている。いわば、「リーダーシップ2.0」だ、という話なのだろう。好川さんはたしか、“マネジメント過剰・リーダーシップ不足”という表現もしていた。ジョン・コッターの定義を借りて、

マネジメント：現在のシステムを機能させ続けるために、複雑さに対処すること
リーダーシップ：現在のシステムをよりよくするために、変革を推し進めること

というのが氏の用語の使い方なのである。

（わたしがこのサイトで使っている用語の定義とは違うが、ここでその議論はしない。語の意味は、辞書的定義よりも、各人の文脈の中で理解すべきである。ちなみに『リーダーシップ』という語は、とくにアメリカでは後光を伴ったMiracle Wordであって、定義は千差万別なのに、皆がその内容を知っているつもりになっている不思議な概念だ。他方『マネージャー』の語は、アメリカではプランテーションの奴隷管理人を連想させる、鉄と鎖の匂いがあることを記憶されたい。）

近年のプロジェクト・マネジメントのあり方が、プロマネの手を縛って自由度を削減し、その覇気を萎縮させる方向に行っている、との告発は、ある程度わたしも賛成である。もちろん、プロマネ達がみな「一国一城の主」になって、“上納金（＝利益）を払ってるんだから、会社は俺のやることに口をはさむな”とうそぶく状態が望ましいとは、思わない。逆に、困難に直面したプロマネを放置したり（あるいは叱責したり）する愚からも遠ざかった、といえよう。さらにリスク・レビューも真剣に行うようになってきた。その結果、企業でのプロジェクトの採算は向上した。だが、実は、“技術的に難しい（チャレンジングな）仕事は見送る”という、消極的受注選別の結果だという声もある。プロジェクト・マネジメント・システムの強化は、良い面ばかりではないのだ。

そこをブレイクスルーするのが、主体的なビジネスの創造だ、という主張はまあ、わかる気はする。けれど、わたしにはむしろ、目指すべき方向はプログラム・マネジメントではないかとも思えた。でも、その前にもう一つ、思い出したエピソードを紹介しよう。

昨年のPMI日本支部による、あるシンポジウム形式の席上だったと思う。わたしもパネラーとして壇上にならび、質疑の輪に加わった。最後に、司会者の方が、しめくくりの質問として、パネラー全員にこんな問いを発したのだ：「皆さんの会社におられるプロの火消し人が、愛読する書を教えてください」。

パネラーの中には、日本最大のICT企業出身で、傑出した火消し人として有名なHさんという方がおられたので、こんな質問が出たのだろうか。だが正直、わたしはこの質問に絶句した。自分自身が火消し人でないことはもちろんだが、わたしの勤務先には『火消し人』と呼ばれる者はいないのである。プロジェクトがトラブって、火を吹くことは無論ある。そのとき、PMOのメンバーが火消しに行ったりはしない。PMOは現業に手を出さないのが鉄則である。手を出したら、当事者が「仕事のオーナーシップ」＝当事者意識を失うからだ。他の部署から腕利きのプロマネをリリーフ投入して助けたりもしない。

ではどうするか。それは、プロマネの上司が問題解決に踏み込むのである。上司はそのためにいる。わたしの業界では、トラブルは建設段階になって吹き出すことが多い。したがって、プロジェクト部門の部長やら役員やらが、問題を起こした海外の建設現場に1年も2年も駐在して、陣頭指揮をふるう例を何度も見てきた。その人はプロジェクト・スポンサーである場合も、そうでない場合もある。希にはプロマネが途中交代になることもあるが、原則は職制上の上司がカバーすることになっている（その間、同じ部門の他のプロジェクトは、別の管理職が管掌することになる）。

問題解決は、マネジメントの職能の一つである。必須の、重要な職能だ。これができなければ、プロマネ達のマネジメントはできない。つまり上司である意味がない。「成功したら、全部お前の手柄だ。でも万が一失敗した時には、骨は拾ってやる」－－これがプロマネに与えるべき、一番大事なメッセージではないか。むしろわたしが不思議なのは、「火消し人」が存在する組織である。誰か、消火隊が機内に待機しているジャンボ飛行機に乗りたいだろうか。消防署員が常駐している化学工場の隣に、誰が住みたいだろうか。発注者の立場で考えた場合、プロの火消し人がいるようなSIerには、仕事は出したくないとわたしなら思う。

冒頭の、プロマネが中間管理職化して不自由になってきている問題も、火消し人のいる組織の問題も、根っこは同じだろう。それは、｢プロマネの問題は、プロマネ・レベルで解決すべきだ」という考え方から生まれている。プロマネの悩みは、プロジェクト・マネジメントよりも上位のレベルでこそ対応すべきではないか。それはすなわち、通常の用語では「プログラム・マネジメント」レベルということになる。そして、その仕事は（PMOなどではなく）職制上のラインが引き受けるべき仕事である。プロマネよりも一段階上のマネジメント・レベルの重要性に、もう少し皆が気づけばいいのにと、その時以来、わたしは思い続けているのである。]]> https://www.excite.co.jp/ https://www.exblog.jp/ https://ssl2.excite.co.jp/