PMBOK Guideに欠けている、３つの重要事項

春である。4月の花咲く頃になると、今年は何人くらい受講生がいるかな、とそわそわした気持ちを抱えながら、つくばエクスプレスに乗る日が来る。東大の柏の葉キャンパスで「プロジェクト・マネジメント特論」の開講日を迎えるからだ。まだ働いた経験のない学生たちに、PM論を教えるのは、あまり簡単でない。それでも柏の葉キャンパスは大学院なので、皆、とりあえず自分の卒論で多少は苦労した経験を抱えて、入って来る。つまり小さくて個人的ながら、プロジェクト的な取り組みをした訳だ。だから学部生よりは、少しだけ教えやすい。

PM論を教えるにあたって、どんな構成・体系で説明を進めるべきかも、悩ましい。大学で講義を持っている、というと、「じゃあPMBOKを教えるんですね」とたずねてくる人が時々おられる。こういう人は、PMBOK Guide®︎が『教科書』だと信じているのだろう。だがあれは、いくつかあるガイドブックの一つにすぎない。よくまとまっているが、あまり書かれていない部分、足りない部分もある。

たとえば、プロジェクトの類型論である。これがないのは、けっこう痛い。古今東西、すべてのプロジェクトが同じ一つの道具立てでマネージできる訳ではない。数ある技法やプロセスの、どれを使うべきか、どれが自分のプロジェクトにあっているのかを、判断する具体的な基準が、PMBOKには書いていない。

最初に読んだときから感じているのだが、PMBOK Guideには、無意識に前提されていることが一つある。それは、プロジェクトが比較的「固い」スコープをもって出発する、との前提である。そこで、SOW（Statement of Work＝作業範囲記述書）を初期インプットとして、プロマネがProject Charter（＝PMBOK日本語版では「プロジェクト憲章」と訳されている）をまず作る、といった作業プロセスが規定される。Charterはさらに、プロジェクト・マネジメント計画書のインプットとなり、その中でWBSが展開される・・と続く。SOWは、まさにプロジェクトの出発点である。

では、そのSOWなるものは、どこから来るのか？　プロマネが受け取るのだから、プロジェクト・チームの外部から、ポンと来るわけだ。解説書などを読むと、プロジェクトの成果を利用する組織が作る、と書いてある。社内利用なら、内部のsponsoring organizationが、また外部顧客の利用なら、顧客から来る、と。だとすると、自動車の新車開発プロジェクトでは、まだ見ぬ顧客からSOWが届くのだろうか？

種明かしをしよう。SOWは、プロジェクトの発注者から来るのである。米国PMIで初期のPMBOK Guideをつくった人たちの多くは、防衛産業・航空宇宙産業やエンジニアリング産業の出身だった。彼らにとって、プロジェクトとは受注型のビジネスであり、「何を作るべきか」は発注者（国防総省とか石油メジャーとか）が決めるものであった。そして（少なくとも米国においては）国の機関や大企業は、自分達の要求事項は事細かに、紙に書いて入札を行うのだ。それは業界によってITBとかRFQとかいろいろな名前で呼ばれるが、抽象化してStatement of Workと呼ぶことにしたのだろう。

初期のPMBOK Guideにおいては、プロジェクトとは受注型であり、かつ明確なスコープから出発するものだ、という無意識の前提があった。だから、エンジニアリング業界に身を置くわたしのような者が読むと、なんだか似たような業種の匂いがぷんぷん感じられた。ただし、プロジェクトには自社が決めて行う、自発型のものもあるし、PMBOK Guideが標準である以上、それにも適用可能な記述でなければならない。だから、「社内利用の場合はsponsoring organizationがSOWをつくる」といった、なんだか無理の多い話になるのである。新車は誰が利用するものだろうか？

PMBOK Guideがもう一つ、無意識に前提したことがあった。それは、プロジェクトは複雑で大型の営為である、という感覚である。これも、防衛宇宙産業やエンジニアリング産業からみれば当然のことであった。大規模プロジェクトの場合、必然的に、「計画」「契約」そして「計数管理」が大切になる。わたしはこれを、プロジェクト・マネージャーの3Kと呼んでいる。この三つが、プロマネの仕事をひどく大変にするのだ。また、受注型プロジェクトではたいてい、コスト制約・スケジュール制約が厳しい。したがってプロマネに、より強い権限を与えるような組織体勢が望まれる。

ところで、世の中には自発型のプロジェクトもある。新製品開発がその典型だ。あるいは、イノベーティブな技術開発とか、自社向けの業務システム開発などもそうだろう。こちらは、ふつうスコープが柔かい。コスト制約よりも、プロジェクト価値の最大化がねらいになる。そこで、品質（とくに設計の品質）が重要になる。このような種類のプロジェクトに、計画・契約・計数管理を持ち込んでプロマネに権限を集中し、ギリギリやっても、あまり楽しい結果が出てきそうにない。別の種類のマネジメント技法が望まれるのだ。

これに関連して思うのは、PMBOK Guideに設計論がない、ということである。なぜ、10個の知識エリアには、『設計のマネジメント』が入っていないのか？　プロジェクトが独自の製品・サービスを生み出すための有期性の業務であるなら、必ずその中には設計業務があるはずではないか。その設計のあり方、良し悪しが、その後のプロジェクトを大きく左右する。ヘマな設計をすると、作りにくく、時間がかかり、コストもかさむ。

設計によって、その後の段取りや作業が全く変わることも多い。3階建ての建物を作るとき、鉄骨造で設計するのと、木造2X4（ツーバイフォー）で考えるのでは、工法や要員や作業手順が全く変わる。それどころか、力学的構造が全く異なるので、建築デザインの見た目も、大きく異なる。それくらい、設計段階の意思決定は重要なのだ。

なのに、PMの知識エリアには品質やコストはあれど、「設計」がない。設計抜きで、構築（製造・実装・建設）だけがプロマネの仕事、という観念は奇妙である。え？　設計は分野ごとに個別性が高いから、Guideに書くのは適当ではない？　だが、そもそも、分野ごとに個別性が高いのがプロジェクトの特性であろう。それでも、共通なプロセスを考えることは十分可能なはずだ。

その一例が、システムズ・エンジニアリング分野から発した「V字モデル」である。これは対象がシステムであれば、人工衛星であろうがワープロソフトだろうが共通に当てはまる。また、「エンジニアリング・マネジメント」という言葉は、日本ではプラント業界くらいしかお目にかからないが、米国にはEngineering Managementを教える専門学科だって存在する。だったらなぜ、PM論の中に、設計マネジメントがないのか？

なお、ここで問題にしているのは「プロジェクトのデザイン」（＝WBSをどう作るか）の話ではない。また、製品デザイン（＝美大を出たデザイナー達が行う仕事）だけの話でもない。エンジニア達の普通の仕事としての「設計論」である。

現在のPMBOKに設計論が欠けている理由は、わたしの想像であるが、おそらく米国における分離発注の商慣習にあったのではないか、と思われる。つまり、

　「基本設計」の段階　→（見積と競争入札）→　「構築プロジェクト」（実装・製造・建設）の段階

の二段階に、発注を分離する、という商慣習である。たとえば建築業界では、20世紀前半から、「建築設計」→「施工」が別々の主体で、別契約になることが一般的だった（少なくとも英米では）。プラント業界でも、80年代頃には、「基本設計」（FEED）→「詳細設計・調達・建設」（EPC）が別になるのが一般化した。防衛宇宙産業のことはよく知らないのだが、米国政府発注なので、似たような分離発注形式をとっていたのではないか。

前段の基本設計において、かなり詳細な（＝コスト見積が可能なレベルの）仕様書を作成しておき、契約書の雛形も用意しておく。競争入札を経て、後段の構築プロジェクトに入る。そしてPMBOK Guideを作った初期の人たちは、構築プロジェクトにもっぱら携わる業界人だった。だから、プロジェクトの最初にSOWがあるのは、彼らにとって当たり前だったのだ。そして、設計の主要な部分はもう終わっているのだから、知識エリアに設計マネジメントは入らなかった、と。

ところで、これが本当だとすると、IT業界にとってはいささか気の毒なことだった。なぜなら、SIプロジェクトの分野で、「要件定義」→「設計・実装」が別フェーズとして分離するのは、もっと遅かったからだ。ソフトウェア開発プロジェクトでは、一般に要件定義が「柔らかい」（固めにくい）ため、設計・実装のスコープも柔らかくなってしまう。そして、IT系プロジェクトの難しさのかなりの部分は、このスコープの曖昧さから生まれるからだ。

おそらく、初期のPMBOKコミュニティには、IT業界の人が少なかったのではないか。そして、少し後になってから、PMが注目されるようになった（日本での普及期は2000年台に入ってからだ）。そして、PMBOK Guideを学ぶことが推奨された。だがPMBOKが無意識に前提するハード型の一括発注契約を、ソフト型であるIT開発プロジェクトに適用したことが、多少の無理を生んだのではないかと想像される。

そして、この不足を補うべく、BA（ビジネス・アナリスト）の実務標準を最近になって付け加えたのだろう。設計（とくに基本設計）が、プロジェクトにおいて重要だと、あらためて皆が痛感したからである。

ちなみに、IIBAの「ビジネスアナリシス知識体系ガイド (BABOKガイド)」https://amzn.to/2OQvnMF などを読んでいると、同じような設計マネジメントのアプローチが、IT以外の分野でも必要だし有効だ、と気づく。ただ、BABOK自体、Version 3.0になってずいぶん良くなったが、まだ発展途上だという印象が強い。デザイン思考がIT分野で注目を集めている今日、もっと設計論は必要だと思う。

さて、PMBOK Guideに書いておいてほしかった第3のポイントは、プロジェクトの評価論（価値論）である。

プロジェクト・マネジメントの最大の仕事は、決断することだ。決断とは、複数の選択肢から、最も良いと信ずるものを選ぶことである。だが、最も良いとは、どういう意味か？

プロジェクト・マネージャーの責務とは、プロジェクトの価値を最大化することだ、とも言える。それがプロマネの査定、成績表になるはずである。では、プロジェクトの価値とはいったい何か？　スコープ・コスト・スケジュールの制約条件（「鉄の三角形」）を守ることだろうか？　それとも、成果物のもたらす顧客満足なりベネフィットを最大化することか？

もし後者だとしたら、じゃあ、「ちゃんと作ったけれど、使われないシステム」の価値はどうなるのだろうか？　わたし自身も過去にそういうものを作った苦い経験があるから書くのだけれど、その場合、プロマネの点数は落第点となるのか。たとえば、ユーザが旧来の仕事のやり方を変えることに抵抗したら？　それはプロマネの責任範囲なのだろうか。

あるいは、逆に、あえて機能とスコープを増やしたおかげで、予算を超過し納期も遅れたが、顧客が喜んで使ってくれるようなシステムを作るのは、是か非か？　つまり、プロジェクトの価値とは、成果物（アウトプット）で評価するのか、アウトカムで評価すべきなのか。これが決まらないと、プロマネは判断できないではないか。だが、こうした価値論が、現在のPMBOK Guideには欠けている。

多くのプロマネは、しばしば二律背反のトレードオフに直面するものだ。外注先は、価格の安さを取るか品質を取るか。計画では、コストを取るか、スケジュールを取るか。目標設定では、リスクを取ってでも、リターン（利益）の最大化を狙うべきか？　こうしたトレードオフについて、ある程度までは、出発時のミッション・プロファイリングとCharterで、判断基準の優先度を事前定義できる。だが、プロジェクトの途上で起きる全ての判断パターンを、事前に定義できる訳もない。

ところで、PMBOK Guideには価値論がないが、モダンPM論の世界に、全く欠けている訳ではないことは、知っておくべきだ。英国の商務省が開発した標準の中には、「Management of Value」（略称MoV）という標準書がある。現在はAXELOSという会社が版権を所有している。内容をざっと知りたければ、たとえば下記のSlideShareをみるといいと思う。

AXELOS - MoV® - Management of Value - Foundation

https://www.slideshare.net/miroslawdabrowski/axelos-mov-management-of-value-foundation-en-instructor-presentation

このMoVでは、Valueという尺度を、次式で定義している。

つまり、単にベネフィット（便益）を最大化しても、それに投入する資源（コスト等）がむやみに増えてしまったら、全体としてはプロジェクトの価値が下がるのだ。この定義式は概念的なもので、必ずしも定量化に向いている訳ではないが、一つのわかりやすい表現ではある。そして、こういう議論は、とても欧州のPM論に特徴的だな、とわたしは感じる。欧州のPM研究では、プロジェクトのスコープを所与のものとして扱わず、より大きな社会的文脈の中で評価しようという視点が強いからだ。

類型論、設計論、価値論－－この三つを、今後のPMBOK Guideはもう少し盛り込んで欲しいと、わたしは思っている。念のためにいっておくが、わたしは別にPMBOK Guideを批判したり否定している訳ではない。ただ、それが完璧な教科書だと信じて、鵜呑みにしないようにしよう、と主張しているだけだ。

前にも書いたが、教科書を暗記しすぎる人は、プロジェクト・マネージャーには向かない。PMBOKというのは、署名にもある通り、Guideである。ガイドなのだから、皆、自分自身で考え、自分の足で山に登っていく必要があるのだ。

＜関連エントリ＞

　→「プロジェクトのスコープには硬軟がある」 https://brevis.exblog.jp/27558796/ （2018-09-20）

　→「オーケストラの指揮者かジャズ・バンドのリーダーか　－　プロジェクト・マネジメントの４つの類型を知る」 https://brevis.exblog.jp/21641066/ （2014-02-02