コスト・マネジメントという困難な仕事に、プロジェクト・マネージャーはどう立ち向かえばよいのか
このノートは、多摩大学大学院の講義で使用してきた教材を下敷きに、その大幅改定のためのドラフトを、クリエイティブコモンズ［©中分毅 (Licensed under CC BY-NC-ND 4.0)］として公開するものです。
今回はその第5講として『コスト・マネジメントという困難な仕事に、プロジェクト・マネージャーはどう立ち向かえばよいのか』ということについてお話しします。
この記事の最後で、過去のノートのマガジンを紹介して載せていますので、ご関心ある方はぜひご活用ください。
コストはPMの鉄の三角形QCTの一角を占めるものです。プロジェクト・マネージャーが、Tスケジュールと並んで最も神経をすり減らすマネジメント項目の一つで、「適切な予算を組み、これを守ってプロジェクトを遂行する」と言う一文に集約される様な生易しい活動ではありません。
この講義では、コスト・マネジメントの核心として、次の6点について述べていきます。これらを弁えているか否かで、プロジェクト・マネージャーの力能（コンピテンシー）は大きく異なってきます。
1. プロジェクトのコストが何を含んでいるのか、プロジェクト・オーナーとの明確な共通認識を打ちたてることが重要です。
2. コストはオーバーランする、を前提認識としてプロジェクトに相対する必要があります。
3. コストとプライス（費用と価格）の違いを認識し、適切な調達方法を選んでください。
4. 情報の少ないプロジェクト初動期のコスト・マネジメントが重要です。
5. コスト・マネジメントには不条理が付き物です。これにどう立ち向かっていくのかが問われます。
6. 協働的なコスト・マネジメントという新しい流れにも注目しておきましょう。
以下の図は、上記コスト・マネジメントの核心を概念的に示したものです。
コスト・マネジメントに関して初学の方は是非テキストの順番で読み進めてください。既に一定の経験や知識をお持ちの方は、5に飛んで頂いても結構です。
<目次＞
１. プロジェクトのコストが何を含んでいるのか 明確な共通認識を打ちたてることが重要です
プロジェクト・オーナーとプロジェクト・マネージャーとの間で、「プロジェクトの予算でカバーしなければいけないものは何か」に関する認識が異なっていると、どこかでプロジェクトは危機を迎えます。
そんな馬鹿なことがあるのか？と思われるかもしれませんが、この様な事態は結構な頻度で起こっています。
何故かと言うと、業界や組織によってコストの概念や常識が異なっているのですが、長年それに慣れ親しんでいると、自分にとっての常識が世間一般の常識だと思い込んでしまい、相手の常識と自分の常識が異なるかもしれないと、疑うことすらしない様になるからです。
恥ずかしいことですが、私も20余年前、欧州の金融機関をクライアントとするプロジェクトで、我々の業界の常識（工事予算に消費税は含まれない）に基づいて検討を進め、工事を発注する直前にクライアントの予算は消費税込みであることを知り、真っ青になった苦い記憶があります。
1.1. プロジェクト・オーナーの観点からのコスト/Owners View Costs
プロジェクト・オーナーとプロジェクト・マネージャーのコストの対象範囲に関する認識を一致させておくことが、コスト・マネジメントの出発点となります。
■コスト・マネジメントの専門家団体AACEはどう言っているでしょうか？
この点は、当たり前すぎで見過ごされがちですが、コスト・マネジメントの専門家団体である米国AACEも、その手引書で次のように述べています（訳は筆者）。
注1. AACE International Certified Cost Technician Primer
プロジェクト・オーナーはコスト全般に関して関心を有しています。
つまり、オーナーは建設費やプロセスにのみに関心を持っているのではなく、内部監査費用、間接費用、実行に伴う諸費用、資金調達費用、家具・什器・備品（FFE）、その他諸費用にも関心を持っています。それ故、プロジェクトやプロセスの意図や期待される成果を、関係者に明確に伝えるのがオーナーやオーナーの代理人（一般的にはプロジェクト・マネジャー）の責務となります。プロジェクトのオーナーや利害関係者は、プロジェクトからの成果やROI（投資利益率）に関する期待を有しています。
これに対して、請負者、下請負者やサプライヤーは自身の担当部分のコストにのみ関心があり、それに対してのみ責任を有しています。
The owner approaches cost from a holistic point of view. Owners not only consider the cost of the construction, or process, but internal supervision and overhead, implementation costs, cost of money, furniture, fixtures, equipment (FFE) and other considerations. It is the responsibility of the owner or the owner’s representative, to clearly communicate the project or process intent and the desired outcome. The owner or stakeholders have expectations on the value received from the project and the return on their investment.
Contractors, subcontractors, suppliers only consider their part of the project costs and are responsible for that alone.
注2. AACEとは
AACE International は1956年に設立された米国を拠点とするNPOであり、TCM: Total Cost Managementの推進を目的としています。当初の名称は「The Association for the Advancement of Cost Engineering」でAACEはこの略称でした。
■ プロジェクト・マネージャーのなすべきこと
AACEの述べている事は余りにも当たり前ですが、何故わざわざ記述されているのかを考えてください。この様なミスマッチが余りにも頻繁に生じているからです。
プロジェクト・マネージャーにとって、以下の3点が重要です。
① プロジェクト・オーナーの全体的関心を理解する必要があります（これが出発点です）。
② 常識は業界によって異なるので、ベースラインを合わせる必要があります（例えば消費税）。
③ 当初に関連する費用も幅広く提示した上で、マネジメントの対象とする範囲に関し、プロジェクト・オーナーとの合意を形成しておくことが必須です。
1.2. コストの範囲の不一致：事例で理解してください
プロジェクト・オーナーの観点からのコスト/Owners View Costsは基本的で大変重要な概念なので、事例で確認しておきたいと思います。
例えば、あなたがレストランを開業しようとしていて、新築する建物の設計を設計者に依頼したとしましょう。工務店の選定や工事の契約手続きなども、経験豊富な設計者に合わせて依頼したものとします。
設計者に「ご予算は？」と尋ねられ、例えば「5億です」と答えたとします。
この場合、どの様な誤解が、オーナーと設計者間に発生しうるでしょうか？
冒頭の一般図を具体例で書き直した上の図を用いて説明します。
設計者が5億に含まれていると考える費用が最も狭い範囲の場合は、上図の「通常の建設プロジェクト・コスト」に該当する下記の項目で5億円だと解釈するでしょう。
・設計・監理報酬
・建築の本体工事費
・標準内装工事費用
・確認申請手数料等本体工事に関係する諸手続き費用
通常、設計者がほぼ間違いなく5億円には含まれていないと判断するのは、上図左上のオーナーにとってのコストと設計者にとってのコストが交わらない部分にある項目です。以下の様な項目があります。
・開業準備費用（広告宣伝費、人材募集、研修など）
・レストラン・コンサルタントへの報酬
・メニュー開発に要する費用
・借入金の利息（借入額が大きければ馬鹿になりません）
・開業までのオーナーの活動費用
・新築建物の登記にかかる費用
良心的な設計者であれば、これらは含まれているのですか？とオーナーに尋ねるのが下記の項目です。これらは建築物には含まれていないので、建築の設計を依頼された側が予算には入っていない（つまり別途予算として準備されている筈）と解釈することが一概に不当だとは言えません。
・厨房機器
・食器、家具、特殊照明
・オーディオ機器
・看板
・キャッシュ・レジスター
・消費税
これらで、費用的には3割から5割のギャップとなります。早い時点で気付けばよいのですが、遅いと設計が概ね終了し、工事を発注する段階になってから気が付く、ということになります。
この例の様に、オーナーと設計者の2者間の誤解であればまだ傷は浅いのですが、外資系企業の日本でのプロジェクトとなると、本国の取締役会や投資家を巻き込む大騒ぎとなることもあります（筆者自身、この仕事を辞めようかと思ったほどのつらい経験があります）。
何れにしても、このギャップを埋めるための膨大な作業が発生する訳で、この費用をだれが負担するのかの整理も（オーナーなのか設計者なのか、両者とすれば負担割合等）、頭の痛い問題です。
注3. 実際の工事費ではどの程度の差になるか
この点を更に具体的な工事費で確認しておきましょう。
建築工事費には、建物本体のベース・ビルディングの工事費用と利用者が自分の利用に供するために必要な工事費用という二区分があり、通常前者を甲工事、後者を乙工事と呼んでいます。本社ビルを自分で建設する場合には、オーナーは両者を負担することになりますが、設計者は後者を本体工事ではなく別途工事として扱うので、オーナーの考えている予算と食い違いが発生する原因となることがあります。数字的なインパクトを理解して頂くために、下表に工事事例を示した。
・乙工事が全体の工事費に占める割合は、以下の様に大きな割合を占めます
・賃貸ビルを一棟借りして本社として使用：乙工事は全体の8～25%程度
・ディベロッパーの開発したベースビルにホテル会社が入居：乙工事費は全体の40%程度
２. コストはオーバーランする、を前提認識としてください
下のグラフは、コスト超過に関する研究で有名なオックスフォード大学のBent Flyvbjerg教授が2009年に発表した論文から引用したもので、英国における建設プロジェクトとITプロジェクトに関して、プロジェクトの規模と実際にかかったコストが予算を超過する率との関係を示したものです。
建設プロジェクトでは、規模に関係なくコストが40％程度予算を超過しており、ITプロジェクトでは、規模が大きくなる程予算超過率も大きくなる傾向が見られます。これに対し予算内に収まったのは青のトーン内に位置するプロジェクトで、少数派に留まっています。
注4
file:///D:/Users/02933/Downloads/UnfittestOXREPHelm3.4PRINT%20(1).pdf
2.1. コスト・オーバーランの要因と対策をまとめると
日本の情況は英国程には酷くはないと思われますが、それでもプロジェクト・マネージャーは、普通にやれば「コストはオーバーランする」という前提認識を持ってプロジェクトに当たる必要があります。
既往研究と筆者の経験に基づいて、コスト・オーバーランをもたらす要因を、プロジェクト要因、心理的要因、政治的要因の3要因に分解しました。
三要因への対策を整理したものが下表です。本節で述べることはこの表に尽くされているのですが、コスト・オーバランの実情と要因に対する具体的理解を図るため、次の順番で説明を加えることにします。
・公共工事におけるコスト・オーバーランの要因と対応策
・ソフトウエア開発におけるコスト・オーバーランの要因と対応策
・コスト・オーバーランの要因と対応策
2.2. 公共工事におけるコスト・オーバーランの実態と参照クラス予測The Reference Class Forecasting
ここでは、前出のFlyvbjerg教授が2004年に発表した論文を紹介します。英国の公共交通プロジェクトにおける計画時のコスト見積に基づく予算（以下予算と略す）と実際に要した費用の分析に基づいて、コスト・オーバーランへの対応方法として、参照クラス予測The Reference Class Forecastingが提案されています。
注5. From Nobel Prize to Project Management https://arxiv.org/ftp/arxiv/papers/1302/1302.3642.pdf
この手法は2005年発行のAPA（米国計画協会：American Planning Association）のニュースにおいて、これまで用いられてきた技術分野でのコスト推定において併用すべき方法として推奨されています。
■公共工事におけるコスト・オーバーランの実態
英国交通省が2004に発行した報告書では、道路、鉄道、交通関連建築物、橋梁やトンネルなどの公共交通プロジェクトにおける予算と実際の費用に関する統計的な分析がなされています（The British Department for Transport, Procedures for Dealing with Optimism Bias in Transport Planning Guidance Document, June 2004）。この内、道路に関する分析を引用します。
下図左のグラフにおいてX軸は実際の費用の予算に対する超過率（（実際の費用－予算）÷予算X100（%））、Y軸は該当するプロジェクト件数の頻度であり、これを累積頻度にしたものが図中右上のグラフです。
これより、予算内で実行されたプロジェクトは全体の2割にも満たず（点A）、全体の40%が実際の費用が予算を20%以上上回る（点B）結果となっており、コスト・オーバーランが深刻な問題であることが分かります。
■コスト・オーバーランをもたらす要因は何だろうか？
Flyvbjerg教授は、コスト・オーバーランをもたらす要因を大別して、二つの範疇を提示しています。尚、2の冒頭の表で示した分類はこれを参考にしていますが、筆者が改変しています。
A Optimism Bias：楽観主義バイアス
B Strategic Misrepresentation：戦略的な不実表示
A 楽観主義バイアスOptimism Bias
楽観主義バイアスとは、好ましい出来事が起きる確率を過大評価し、好ましくない出来事が起きる確率を過小評価する認知的錯誤の一種で、約80%の人がこの傾向を有すると言われています。
公共交通プロジェクトにおける楽観主義バイアスの要因として、Flyvbjerg教授は以下を挙げています。
① 技術的要因Technical Causes （この講義ではプロジェクト要因と呼んでいます）
公共交通プロジェクトは長期に及び関係者も多いため本来的にリスキーであると言え、技術的要因は更に次の3点に細分できる。
· 不完全な情報Imperfect Information：予測技術やデータの不完全性、悪意のない誤り
· プロジェクト・スコープの変化Scope Changes：プロジェクト実施中に生じるプロジェクトに対する要求事項の増大や高度化
· マネジメントManagement：初期段階での条件整理が不十分というマネジメントに起因するもので、プロジェクトの複雑さとは関係なく起こりうる
② 心理的要因Psychological Causes
関係者はプロジェクトを実現したいという思いが強いため、特にプロジェクトの承認審査段階（appraisal phase）でプロジェクトの推進者やコスト推定担当者に強く働く。
③ 政治的・制度的要因Political-institutional Causes
意思決定におけるプロジェクトに関する利害、権力、制度的設定によってもたらされるバイアスであるが、驚くべきことにこの点に関する検討は余りなされていない。
④ 経済的要因Economic Causes
プロジェクトの実施によって事業機会を得るエンジニアリングや施工会社が関与すると、実施側にバイアスがかかる場合がある。
B 戦略的不実表示Strategic Misrepresentation
プロジェクトの実施に際して政治的な圧力や組織内での上層部の圧力によって、合理的な推定とは異なる虚偽の推定が意思決定者に提示される状況のことです。Flyvbjerg教授は、公共プロジェクトにおいてこの要因の影響は大きいとしています。
■コスト・オーバーランをもたらす要因にどう対応すればよいのでしょうか？
当然のことながら、対応策は要因によって異なってくるのですが、両者に共通する根拠となるのが、参照クラス予測The Reference Class Forecasting（類似事例の統計的分析に基づく予測）です。
この方法は、なるべく多くの類似プロジェクトに関する予算と実際にかかった費用データを収集し、統計的に分析することによって、実際の費用の予算に対する超過確率を一定範囲に抑えるためには、予算に対してどの程度の安全率をかけるべきかを割り出そうとするものです。
Flyvbjerg教授の上げている例はやや分かり難いので、筆者が簡単な例題を作成しました。
実績データは下表の通りです。
・予算以内で完了したプロジェクト（コスト超過率0％）は6％に過ぎません。従って見積通りの予算とすると、プロジェクトが予算を超過する確率は94％となります
・実績コストが予算を上回る額の対予算比率は20％を上限とするという基準を設けた場合、これを守れない確率は38％となり（下表の赤字）、30％を上限とするとこれを守れない確率は20％に減少します（下表の青字）。
・超過率の平均は18％で、中央値は15％です。
では、プロジェクトの予算設定ではどの様にこれらのデータを使うのでしょうか？
Flyvbjerg教授は、下図の様に実績データから、予算超過率の累積頻度を作成し（下図左下）、これを逆転させて安全係数モデルを作成することを推奨しています。逆転とはプロジェクト超過確率をX軸にとり、コスト超過率をY軸にとることを意味しています。
実際のプロジェクトでは、以下の手順となります。
① 従来通りの方法で、プロジェクト・コストの見積を作成する
② 予算設定の際に許容される予算超過確率を設定する
③ ②に該当する安全係数を見積額に乗じてこれを予算とする
例えば、許容される予算超過確率が20%の場合、つまり80%の確率で予算以内に収めたい場合には、コスト超過率は30%なので、見積額を1.3倍したものが、投資対効果を検証する際の予算となります（上表青字表記）。これを90%にすると安全係数は1.4となります。
■この方法の有効性
前出のコスト・オーバーランをもたらす2つの要因に対して、この方法はどの様に機能するでしょうか？
・楽観主義バイアスOptimism Biasが主たる要因である場合、つまり予算の算定は誠実に行われているものの、無意識に働くバイアスによって楽観的な推定となる恐れがある場合には、この方法は外部の視点を持ち込むものとして、非常に有効であると言えます。
・戦略的な不実表示Strategic Misrepresentationの場合にはプロジェクト関係者が意図的に行っている訳ですから、Reference が当事者に有効に働くとは期待できません。この場合は中立的な第三者によるチェックが不可欠となりますが、第三者が判断を下す上で、この方法は有効に活用されることが期待されます。
なお、数多くの実績データが得られない場合は、経験豊かでプロジェクトには中立的な第三者に意見を求めることが有効です。
2.3. ソフトウエア開発におけるコスト・オーバーランと対応策
ソフトウエア開発の領域においても、プロジェクト・コストの超過は大きな問題となっています。2014年に発行されたCLAES WOHHIN編著Software Project Management in a Changing Worldの1章もこの問題にあてられています（Cost Prediction and Software Project Management）。ここではその内容を要約して紹介することにします。
■コスト・オーバーランの実態
民間プロジェクトのデータが公表されることが少ないため、実態は捉えにくいとしつつ、下記の二つの報告から、コスト超過率は契約金額の30%程度ではないかとしています。
文献01： How Large Are Software Cost Overruns? A Review of the 1994 CHAOS Report, Magne Jørgensen and Kjetil Moløkken, Simula Research Laboratory 2006 （下図左表）
文献02： Cost overruns, delays and terminations: 105 outsourced public sector ICT projects, Dexter Whitfield 2007 （下図右表）
この30%が、コスト・オーバーランしたプロジェクトにおけるコスト超過率なのか、全プロジェクトを対象にしたものかが問題ですが、文献02から引用した表右からも分かるように、後者つまりコスト・オーバーランのなかったプロジェクトを含む全プロジェクトが対象であり、超過したプロジェクトは全体の57％なので、超過したプロジェクトだけをとれば予算超過率は50%超となります
日経コンピュータのITプロジェクト実態調査 2018では1745件のうち、コストが超過したプロジェクトは365件（20.9％）あったと報告されています。こちらは件数ベースで額の情報はありませんが、上記の4割程度です。
注6. https://xtech.nikkei.com/atcl/nxt/column/18/00177/022100002/
■コスト・オーバーランの要因
コスト・オーバーランが起きる要因として、下記の4点が指摘されています。
① プロジェクトが複雑であるComplexity
規模が大きく、ステイクホルダーが複数存在し、不確実性、一貫性の欠如、頻繁な変更がある等の特徴を有するプロジェクトです。
② プロジェクトがデザイン的性格のプロジェクトだと見做されているViewed as a design type activity
開発的な要素や試行錯誤が多く、生産性という側面が軽視されがちです。
③ プロジェクト予算が早期になされるEstimates are required at a very early stage
この結果、成果物に対する要求事項は明らかになっておらず、予算の根拠となる情報が不足しています。
④ 社会的・政治的な圧力が存在するSocial and political pressures
この結果、費用は少なめに、便益は大きめに推定され、費用便益分析における便益/費用（B/C）が大き目となり、本来実施すべきでなかったプロジェクトが実施され、中止に追い込まれることになる場合があります。
■SWEBOK（ソフトウエア工学知識体系Software Engineering Body of Knowledge）の推奨する原理
残念ながら本課題に関する豊富な記述がある訳ではないのですが、同書が参照しているSWEBOKの推奨原理は以下の様に要約できます。
① 分割して管理するDivide and Conquer
見積（費用推定）は、ひと声いくらというやり方でも積上げでも可能ですが・・・両者何れにおいても、業務を適当に分割する方が見積は容易となります。
分割された業務の見積を合計したものは、全プロジェクトの費用をカバーしなければならないのですが、厄介な問題は、整然とした階層的な分割には馴染まない業務が存在することです。
Estimates can be derived top-down or by means of some breakdown of tasks.・・・The idea behind a top-down or a decomposition approach to cost estimation is that of divide and conquer.
The individual estimates should be summed across the entire project.
The chief difficulty is the fact that some activities do not easily fit into neat hierarchical breakdown.
② 見積は点でなく幅で考えるto consider representing an estimate as a range
③ 公開されたコスト・モデルを活用するthe use of formal cost model
各業務に関する見積額はコスト・モデルを用いて算出できますが、利用可能な実績データが存在する場合は地域の事情を考慮した補正が必要です。利用できない場合には、専門家による判断が必要です。
COCOMO（補足2参照）の様な広く利用されているコスト・モデルは、ソフトウエア開発における規模の不経済を反映した、ソフトウエアの規模（ステップ数）と費用の間の非線形関係に基づいています。
For each such task the expected effort [cost] range can be derived from a cost model which needs calibration to the local environment using historical data if available. Otherwise, an alternative is needed such as expert judgment.
Widely used models include COCOMO81, which is based on a non-linear relationship between estimated LOC and effort, implying diseconomies of scale.
④ 見直しを必ず行うthe need to revisit any prediction
見積はステイクホルダー間（SWEBOKでは主として開発技術者と経営層）での合意が形成されるまで、繰り返し改訂される必要があります。
見積の改訂の必要性は、ソフトウエア開発を一旦方針が定まればそのまま進んでいくものと見做しがちな研究者たちの認識とは異なって、以下の様に前提条件がダイナミックに変化していくものであることから、軽視してはなりません。
· 開発が進むにつれて、プロジェクト・オーナーの要求事項が明確となっていき、これを実現する上での課題も明らかとなります。
· プロジェクトが置かれている環境条件が変化します。
Estimates need to be revised iteratively until agreement is reached amongst all stakeholders, which the SWEBOK identifies as principally software engineers and management.
This has often been neglected by researchers who tend to see a software project as a static snapshot, which does not reflect the realities of
· A growing understanding of the requirements and challenges as the software project plays out
· The changing environment in which the project is embedded.
■ 実践への提言Practical Recommendations
ソフトウエア開発におけるプロジェクト・コストの見積に関する問題点は次の2点です。
・過度に楽観的な見積（over-optimistic costs）
・見積に対する過度な信頼（be less accurate than anticipated）
この問題に打ち勝つためにCOCOMO等の様々な調査研究とそれに基づく公開モデルが提案されてきました。残念ながら、一貫性のある根拠が不足していることから、特定の公開されたモデルを強く推奨することはできず、人間（専門家）による判断の重要性を指摘せざるを得ない、と述べています。
経験的な根拠を有し現実のプロジェクトに利用可能な実践的提言として、下記6点が示されています。
① 類似プロジェクトの実績などローカルなデータを重視する
② 重要な要因に関して感度分析を活用する
③ 複数の手法を活用し、結果を平均化しないでおく
④ グループでの見積は楽観性の程度が低い
⑤ システマティックな教育訓練と過去プロジェクトの知見の蓄積
⑥ 信頼性配慮のため点でなく幅で考える
It is not possible to strongly recommend any one formal technique, for the simple reason of a lack of consistent evidence. Thus any recommendations must be grounded in the understanding that human judgement plays a substantial contribution.
The following is a list of six practical recommendations that are supported by empirical evidence and could usefully be deployed in real-life projects;
① Data driven
② Sensitivity analysis
③ Multiple techniques
④ Group estimates
⑤ Training and reflection
⑥ Estimation and confidence
2.4. プロジェクト・マネージャーが認識すべきコスト・オーバーランの要因と対応策
公共工事とソフトウエア開発におけるコスト・オーバーランの要因と対応策を見てきましたが、これらも踏まえてプロジェクト・マネージャーが認識すべきコスト・オーバーランの要因と対応策をまとめておくことにします。尚、この分類は2.2で紹介したFlyvbjerg教授の分類とはやや異なっていますが、2009年に教授自身も分類を見直していて、これとは合致していると思います。
注7. Survival of the unfittest https://arxiv.org/ftp/arxiv/papers/1302/1302.3642.pdf
■オーバーランの要因の3範疇
① コスト・オーバーランの要因には、プロジェクト要因（技術要因）、心理的要因、政治的要因の3つの範疇があります。プロジェクト要因（技術要因）は最後に説明します。
■心理的要因と対応策
② 心理的要因とは、コストや便益・利益の見積において故意ではなく作用する楽観主義バイアスOptimism Biasが働くことで、計画の誤謬Planning Fallacyが発生することになります。
・便益・利益、損失、確率の合理的な重み付けではなく、妄想的な楽観主義に基づいて意思決定する
・便益・利益を過大評価し、コストを過小評価する
・無意識のうちに成功のシナリオを描き、ミスや誤算の可能性を見落とす
③ 脱バイアス手法Debiasingを導入します
・参照クラス予測The Reference Class Forecastingを導入する
・第三者的判断を導入する
・プロジェクトを分割してコストを検討する
■政治的要因と対応策
④ プロジェクトの採択に向け、意図的かつ戦略的に利益を過大評価し、コストを過小評価する戦略的不実表示Strategic Misrepresentationが行われる場合です。
⑤ この場合は、結果として成功することがあるので（例えば東海道新幹線）、扱いは厄介です。
（第2講2.3プロジェクト・マネジメントの成功・失敗と鉄の三角形の達成・未達の関係を分析する、参照）。
https://note.com/nakawaketakeshi/n/nc4eb1a863d79
・防止の観点からは、第三者判断の導入が有効です。
・プロジェクト・マネジメントの範囲外ですが、プロジェクト・マネージャーは自己防衛策を検討する必要があります。自分が発意したプロジェクトの場合は守護神を見出すことが必要で、プロジェクト・マネージャーとして任命された場合、守護神不在であれば降りることを検討すべきです。
■プロジェクト要因（技術要因）と対応策
⑥ プロジェクトの要求に絡む次の様な要因が主たるものと言えます。
・成果が要求を充たしていないとの理由で変更作業が発生する
・プロジェクトの進行に伴って追加要求や要求の高度化が発生する
・要求が明確化していない初動期に予算を決定した
⑦ 要求に起因する場合は以下の対応が有効です
・目標の設定・要求の抽出をプロジェクト・オーナーと協働で反復的に行う（第3講プロジェクトの目標や要求事項の設定は極めて重要だが、難しい、ではどうするか、参照）https://note.com/nakawaketakeshi/n/n9ba35989803c
・確実に必要とされるものと不確定な要求を区分し、後者に対応する変動対応費用Contingencyを計上して、そのマネジメントを継続的に実施する
⑧ デザイン的性格のプロジェクトであるとみなされていて、コスト・オーバーランは当たり前だと思われている
この場合は、発想を切り替えることが重要となります。
・設計をしてから見積るのではなく、予算内で設計をするDesign to Budget
・設計者任せにせず、初期から関係者が協働する
⑨ 予測技術やデータが不完全などの技術的要因による場合には、下記の方策を講じることになります。特に経験豊富な人の意見を取り入れることは予測の確度を上げることに留まらず、予想される重要な課題（key issues foreseen）は何かを認識する上でも重要です。
・経験豊富な予測者の意見を取り入れる
・複数の手法を用いる
・予測モデルを改良する
・予測のためのデータを蓄積する
３．コストとプライス（費用と価格）の違いを認識し、適切な調達方法を選んで下さい
プロジェクト・オーナーが有する内部の資源のみでプロジェクトを遂行することは不可能で、外部から何らかの製品やサービスを調達する（購入する）必要がある場合が殆どです。従って、調達マネジメント（Procurement Management）は、コスト・マネジメントやプロジェクト・マネジメントの重要な要素となります。
調達において重要になってくるのが、コスト（費用）とプライス（価格）は本質的に異なるものであるという点です。コストとは一般的な方法であるモノやサービスを提供するのに必要な費用で、プライスとは売り手が買い手に提示する価格を意味します。建築を例にとると、次の様になります。
工事費にはコストとプライスの考え方があり、一般的には建物を造るのに必要な費用がコスト、企業等が独自の判断で発注者に示す価格がプライスと考えられています。つまり積算により理論的に費用（コスト）を算定することができますが、この金額は市場競争原理を考慮して示される価格（プライス）とは必ずしも一致しないことになります。
注8. 「ストック時代の建築積算と価格情報」（建築新聞電子版）http://www.kentsu.co.jp/mlmg/521/news/000000000004.html
注文生産か一般的なモノ・サービスの購入かといった点や、買い手の力、売り手のおかれた状況によってコストとプライスの関係は大きく異なってくることは、量販店と街の電気屋さんでの価格差等で日常的に経験するところです。
3.1. コストとプライスの相違を認識し調達戦略に活かす
コストとプライスの相違を認識することは、プロジェクト・マネージャーやコスト・マネジャーにとって大変重要だと考えるのですが、一般のプロジェクト・マネジメントの教科書ではあまり触れられていないのは不思議に思います。プロジェクト・マネージャーは、モノやサービスの調達を行う市場がどのような性質を持っているかを理解していないと、適切な予算が策定できないでしょうし、適切な調達戦略もたてられないことになります。コスト・マネジメントのテクニックに習熟するよりも、コストとプライスの相違を認識し実践に生かす方が重要です。
■留保価格（許容価格）Reservation Cost
実現する価格は買い手と売り手の関係によって決まることになりますが、この関係性を観察する上で、留保価格あるいは許容価格という概念が有用です。
留保価格には、買い手にとっての留保価格、売り手にとっての留保価格の二通りがあります。プロジェクト・オーナーは買い手の立場にあります。買い手にとっては買っても良いと考える上限値、売り手によっては売っても良いと考える下限値を意味するので、取引が成立する場合、一般には以下の関係となる筈です。
売り手の留保価格≦実現した価格≦買い手の留保価格
生産者余剰＝実現した価格－売り手の留保価格
消費者余剰＝買い手の留保価格－実現した価格
一般論としては、買い手であるプロジェクト・オーナーはなるべく安く買って消費者余剰を最大化したいと考え、売り手である製品やサービスの供給者はなるべく高く売って生産者余剰を最大化したいと考えるので、価格に関しては利害が相反する関係にあります。
■売り手の価格戦略Price Strategyにはどの様なものがあるか
適切な調達を行うためには、売る側の考え方も知っておく必要があります。そこで、売る側の値付けの考え方即ち価格戦略を、AACEの手引書に従って紹介することにします。
価格戦略は個々の状況に即して策定されるべきものですが、プロジェクト遂行時に出くわすのは以下の二つのケースであることが多く、それぞれのケースには固有のビジネス上の目的があります。
・ビジネス上の目的はプロジェクトを受託し、遂行し、契約を充たす成果を達成してかつ利益を得ることである。従って、簡単に値下げに応じることはしない。
・必ず受託しなければならない場合で、売り手には価格支配力が無い場合です。企業がそれまで実績のない領域に足場を築きたい場合がこれに相当します。利益よりも実績作りが優先されます。
具体的な値付け戦略としては以下の様なものがあるので、プロジェクト・マネージャーは調達先の戦略がどのようなものであるかを推測・把握しておくことが重要です。
① 時価による値付けMarket Pricing：現状の比較可能な価格指数に基づく値付け
② 市場浸透を目的とする値付けMarket Penetration Pricing：新商品を素早く、大量にかつ簡単には置き換えられない様に市場に浸透させるための戦略です。この戦略は以下の仮定に基づいています。（1）商品には固有の相場形成がない、（2）購入者は価格に敏感で需要は弾力的である（安くすれば大量に売れる）、（3）市場が大きく薄利多売が成立する、（4）競争相手も迅速に価格を引き下げると予測される
③ 需要対応の値付けDemand-Oriented Pricing：需要が旺盛な時には値上げし、需要が弱い時には値下げをする値付け方法。
④ 略奪的値付けPredatory Pricing：競合相手や競合商品を市場から排除するため法外な安値を付ける場合です。略奪的価格は優位性の乱用であり、国によっては違法となります。
⑤ コストに基づく値付けAt Cost Pricing：建設市場が停滞している時に、施工者がしばしば用いる方法で、労働力の確保、市場でのポジションの維持といった観点から、コストぎりぎりで受託します。しかし、契約後、発注者は、施工者の利益確保を目的とする変更要望に悩まされる場合が多いといえます
3.2. 三つの調達方法の特徴を理解し適切な方式を活用する
建物の建設やソフトウエアの開発のように取引の個別性が強い場合、コストとプライスの乖離が大きくなることが予想されます。そこで、プロジェクト・マネージャーには以下を行うことが求められます。
① プロジェクト構成要素の中に、建築物の様にコストとプライスが乖離する可能性のあるものがないかをまず確認します。
② そのような要素がある場合には、不利な調達を強いられないような調達方式を検討します。
どの様な調達方法を採用するかが調達戦略の核となるので、種々の調達方法の特質を理解し適切に使い分けることが重要です。3.2では広く用いられている以下の3つの調達方式を紹介します。
・競争入札方式
・総合評価方式（プロポーザル方式）
・特命・随意契約方式
注9. 対立的な調達観と協働的な調達観
ところで、調達戦略と言った場合に、買い手の得は売り手の損、売り手の得は買手の損につながるとの対立的な関係にあると考える調達（Adversarial）と、買い手と売り手が協力して効率化を図りその成果を両者で分け合うという協働的な調達観（collaborative）の両者があります。伝統的には対立的な調達観が主流ですので、3ではこれについて説明します。協働的な調達観は6で説明します。
③ プロジェクト・オーナーやプロジェクト・マネージャー側の当該分野の経験が不十分な場合や、経験が十分であっても慣行的なやり方を改めたい場合は、専門家の意見をなるべく早い段階で聞いておくことが重要です。
以下、3つの方式を紹介した後に、外部知識の活用を説明します。
3.2.1. 最も分かり易い競争入札方式
発注者（買い手、プロジェクト・オーナー）は、受注候補者（売り手候補者）に見積条件を提示し、受注候補者が提示した価格（応札価格、値付け）によって受注者を選定します。
上の図で競争入札を説明します。
発注者（買い手）は売り手にかかる製品コストを知らないのですが、なるべく製品コストに近い価格で購入して消費者余剰を最大化したいと考えます。しかし売り手の候補一社だけと交渉したのでは、買い手の交渉力には限界があります。そこで、複数の売り手候補を競争させることによって、消費者余剰を最大化しようと考えます。
受注者（売り手）は発注者の留保価格（買い手にとっての商品価値）を知らないので、これを推測するとともに、競争相手の値付けも推測して自身の値付けを決めます。これらをどう推測するかという点と製品コストそのものも企業によって異なるので、各社の値付けは異なったものとなります。
発注者は最も低い値付けを行った応札者（上図ではB社）を選定することになります。
注10. 売り手である応札者たちが値付けを一定額以上にするように共謀することが、世に言う談合（collusion）です。
■競争入札方式においてプロジェクト・マネージャーが注意すべきこと
競争入札方式を用いる時に、プロジェクト・マネージャーが注意すべき点として、3点述べることにします。
① 受注者（売り手）の質を確保する
値段は安いが質も悪い受注者（売り手）を選んだのでは話になりませんが、残念ながらしばしば起こってしまう事態です。この様な事態を避けるために、次の様な対策を行います。
・入札参加者を制限する
入札参加者を、一定条件を満たす事業者に限定する指名入札が多用されます（参加者を限定しないやり方を一般入札と呼びます）。入札参加者を限定するための手続きを予備審査・事前審査（PQ: Pre-Qualification）とよびます。PQでは、プロジェクトに対する関心の有無を確認し（関心表明と呼ばれます）、類似実績、関係領域の技術者数、企業の財務状況などの提出を求めるのが一般的です。
・最低価格を設定する
ある価格以下では受注者に赤字が発生し質の劣化が不可避と推測される場合には、最低価格を設定しこれ以下の価格を提示した応札者は失格とするというやり方で、官庁の発注で用いられることのある方法です。前述した市場浸透を目的とする値付けや略奪的な値付けの場合は、質の劣化につながるとは考えられないので、最低価格を設定しようとする場合には、プロジェクトや応札者の情況を考慮した上で判断すべきでしょう。
② Apple to Apple（同じ条件に基づく値付け）となるよう心掛ける
受注候補者は、発注者の提示した見積条件書に基づいてコストを算定しそれに生産者余剰を上乗せして値付けをします。見積条件書が提示する情報が不足していたり曖昧であったりすると、それをどう解釈するかによって見積は異なってくるので、複数の受注候補者の値付けの比較は林檎と林檎の比較ではなく林檎と梨の比較となってしまい、適切な比較が出来なくなってしまいます。
この様な事態を招かない様に、見積条件書は解釈の多様性の生じない明快な内容とすべきであり、見積条件書に対する応札者の質疑にも丁寧に答えるべきです。
発注者の中には、見積条件書を曖昧にすることによって安値での応札を誘おうとする一種の引掛けのような策略を採用する企業もありますが、契約後に手抜きをされるか係争となるのでお勧めできません。
また明快な（Apple to Appleとなる）見積条件書が作成できない場合には、他の方法（次に述べる総合評価方式や6で述べる協働型の採用を考えるべきです。
③ 入札は情報戦でもある
ある応札者が発注者の予算（留保価格）を知ると、他の応札者に働きかけて談合が成立することが危惧されます。そこで、一般的には公正な入札を行うためには、発注者の予算は厳に秘密にしなければならないと考えられています。応札者はあの手この手でこれを聞き出そうと努力します（甚だしい場合は収賄が発生します）。
他方、発注者の予算が厳しい時には、全ての応札者の値付けが予算を越えてしまい、入札が不調に終る（落札者がいない）こともあり、プロジェクトのスコープの見直しやスケジュールの遅延につながってしまいます。そこで、発注者は何らかの方法で予算を暗示することによって予算に近い応札を誘導する場合もあります。
この様に、入札には情報戦としての側面があり、プロジェクト・マネージャーには臨機応変の対応が求められます。
3.2.2. 総合評価方式
受注候補者から、品質確保に関する提案やプロジェクトの進め方に対する提案と価格に関する提案の両者を求め、その総合評価によって選定する方式です。提案競技方式（Proposal方式）とも呼ばれ、品質やプロジェクトの進め方に関する提案は技術提案Technical Proposal、価格に関する提案は価格提案Fee Proposalと呼ばれます。
受注者の位置付けが、契約通りのものを納入する単なるベンダーではなく、プロジェクト・オーナーのパートナーとなって一緒に考えてもらいたい場合やプロジェクトに決めきれない部分があって明快な見積条件書が作成できない場合などに適した選定方式です。
プロジェクトの進め方や品質確保策と価格という尺度の違うものの総合評価であることから、事前に評価方法を定め、それを提案者にも通知しておくのが、透明性の高い方式と言えます。
具体的な選定方法としては、次の2者が良く用いられています。
・プロジェクトの進め方や品質確保策に関する評価を例えば70％、価格提案を30％など評価の重みを事前に決めておいて採点する1段階の評価（上図a）
・先ず、プロジェクトの進め方や品質確保策に関する評価で応札者の順番をつけ、この順番に沿って価格提案を見ながら価格交渉を行う2段階の評価（上図b）
■総合評価方式においてプロジェクト・マネージャーが注意すべきこと
総合評価方式を用いる時に、プロジェクト・マネージャーが注意すべき点として、3点述べることにします。
① 適切な候補企業を絞り込む
総合評価方式で選定される業務の受注者は、プロジェクト・オーナーにとってはパートナーと位置付けられる訳ですから、候補者は適切に絞り込む必要があります。
候補者の選定は、下図の様に2段階で行われるのが標準的です。
・先ず、候補者を幅広くリストアップします。どの程度リストアップするかはプロジェクトの規模や特殊性によりますが、5〜10社程度です。Long Listと呼ばれます。
・リストアップされた企業に、プロジェクトに対する関心の有無を確認し（関心表明と呼ばれます）、類似実績、プロジェクトに関係する領域の技術者数、企業の財務状況などの予備審査書類の提出を求めます。これは、前述の入札者を選定する際と同様の手順です。
・予備審査書類に基づき本審査に進む候補企業をさらに3～5社程度に絞り込みます。Short Listと呼ばれます。予備審査書類の評価方法は、予備審査書類を開封する前に決めておく必要があります。そうでないと、特定候補者に有利に働くように評価方法が歪められる可能性があるからです。
② 技術提案の内容は、核心的な情報が得られ応募者の過大な負担とならないものとする
・技術提案書の提出には通常対価は支払われないので（無償提案）、応募者にとって過大な負担とならないものである必要があります。
・提案内容は、選定にとって必要な情報が収集できるものである必要があります。プロジェクトを進めていく上で予想される重要課題とその解決方法を問う場合や、特定の課題に対する解決の方向性を問うなど、プロジェクトの情況と応募者に求めるものを明確にした上で、提案項目を厳選することが重要です。
・提案された内容が机上の空論でないことを確認することも重要で、企業としての類似実績の提出、担当するメンバーの実績説明やインタビューなどを行います。
・予備審査と同様、評価方法を事前に定め、プロジェクト・オーナーの了解を取り付けておくことが必要で、応募者にも事前に提示しておくことが望ましいでしょう。
・以上を踏まえて、提案要綱書（RFP: Request for Proposal）を準備します。
・一点付け加えておきたいのは、要綱に無い過剰な提案内容の場合は失格とする、減点するなどの措置を明記し、提案書の焦点以外の処が決定要因とならないように配慮することです。
③ 価格提案のロジックを重視する
・総合評価方式を採用するのは、価格だけではなくパートナーとしての適性を重視したい、価格だけで決定するには前提条件が曖昧であるといった要因があるからで、場合によっては価格提案を求めないこともあり得ます。
・パートナーとして行う業務内容や曖昧な要因をどう解釈するかによって価格は大きく異なってくる可能性があります。パートナーとして行う業務内容として何を提案してくるかは、提案者の能力や適性を判断する上で非常に重要な情報ですから、これをプロジェクト・オーナーの側から具体的に提示するのでは、提案書の意味が半減することになります。
・以上から、価格の額そのものよりも、どの様な前提で価格提案がなされているのかという価格提案のロジックを重視するべきであると考えます。
3.2.3. 特命・随意契約方式
あらかじめ定めた唯一の受注予定者と交渉によって金額を定める方式です。発注者は受発注関係を継続し受注者にとっての「お得意さん」となる場合が一般的です。
価格交渉力は働きませんが（受注者にとっては指定席なので競争相手がいない）、発注者・受注者の間に信頼関係や学習効果が生まれるという利点があるとされています（日本では、不透明性が問題とされることが多いのですが、2000年代の米国の建設プロジェクトでは訴訟が少ない日本流のプロジェクト方式として注目を集め、Strategic Allianceがこれを意味する場合もあります）。
一般論としては発注者側の価格交渉力が働かないと考えられますが、それにも拘らず特命方式が採用されるのには、特命方式にそれなりのメリットがなければなりません。この理由として、以下を挙げることが出来ます。多少価格が上昇しても、下記のメリットが大と判断すれば特命方式を採用することになります。
① プロジェクト・オーナーが有する独自の要求を熟知していているので、手間が省けて安心である
② 社内にプロジェクトを実施するだけの知識や人材がなく、立上げの段階から支援を依頼できる
③ 過去の成果物のメンテナンスを引き受けてもらっており、自社でそれを行う必要がない
④ プロジェクト以外の他の業務、例えば建設プロジェクトにおける建設用地の手当など、を依頼している
⑤ 自社商品を優先的に利用してもらっているお得意先でもある
⑥ 取引銀行からの強い推薦による
⑦ オーナー同士が旧知の間柄である
特命方式の良い部分を取り入れ（例えば①と②）、かつ価格の合理性を追求することが出来ればこれに越したことはありません。6で紹介する協働的なコスト・マネジメントは、この様な志向性も持っています。
3.2.4. 外部知識の活用
外部から調達を必要とする領域に関する経験が十分でない場合や、これまでの慣行を改めたい場合には、調達方式の選択を行う段階から、外部の知識や人材の活用を図るべきです。当然、この段階での支出は増えることになりますが、不適切な調達を行ったために後段になって払わされることになるつけの額と比べると、はるかに安い（桁の異なる）出費に過ぎません。
では、外部からはどの様な支援を期待することが出来るのでしょうか？大きく、下記7点で支援を受けることが期待されます。①～⑥についての説明は不要だと思いますので、ここではコスト・マネジメントに直結する価格交渉についてやや詳しく説明します。
① 調達したい業界の情況把握
② 適切な調達方式の推奨
③ 採用の決まった調達方式のプロセス構築・スケジュール策定
④ 候補企業のリスト作成
⑤ 見積条件書、提案募集要綱の作成
⑥ 提出された提案書の評価
⑦ 提出された見積書の評価と価格交渉
■提出された見積書の評価
提出された見積をそのまま信用することができれば話は簡単ですが、そうはいきません。そこで見積内容を検討すること（通称査定）が必要になります。
見積書の基本的な構成と検討のポイントを述べることにします。
見積書を見慣れていない人のために、先ず実例を示しておきます。
見積は、数量と単価が明示され単価X数量で表示されているものと、経費の様に一式で計上されているものの合計からなります。
見積内容を検討しなければならない理由は、大きく次の2点です。
① 見積条件書に提示された条件の解釈が適切でない（意図が伝わっていない）可能性がある
② 残念ながら、見積の金額が故意に吊り上げられている
そこで、外部の知識を活用して、見積内容を検討することになりますが、以下がポイントとなります。
数量X単価で算出されているものについては以下がポイントとなります。
・数量が明示されている部分の数量の想定は妥当か（故意に増量されている場合があります）
・単価は妥当か（プロジェクト・オーナーが想定しているグレードと合っていない場合があります）
・大雑把すぎるのでもう少し分解できないか（とはいえ細かければよいというものではありません）
一式計上されているものについての検討ポイントは以下となります。
・全体の金額に対する比率は妥当か（他の事例との比較となります）
・一式に含まれているものは何か（これを確認しておかないと、後々トラブルの原因となります）
・もう少し分解できないか（あまりにも大雑把な場合は、分解することを求めます）
合計金額については、以下がポイントとなります。
・プロジェクト・オーナー側が把握しているプロジェクト固有の重要事項の抜け（見積落ち）がないか
・一般に値引きがされていることが多いのですが、前提条件が変わっても値引き率が維持されるのか（尚、値引き率が非常に高い時は、税務署から贈与と認定される場合もあるので注意が必要です）
・物価やプロジェクトのスコープ等前提条件が変わった場合の見積の見直しのやり方はどうなっているのか
■契約すると買い手の交渉力は弱まる
一般に、契約が成立すると買い手の交渉力は急速に低下します。プロジェクトが人質になってしまうからです。
例えば、新製品を製造する工場の竣工が遅れて製品の出荷も遅れると、プロジェクト・オーナーは製品の購入者に莫大なペナルティを支払う必要があるので、期日は非常に重要です。これだけであれば、工事や製造ラインの発注先に期日が遅れた場合のペナルティを課せばよさそうなものですが、そう簡単にリスクの転嫁ができる訳ではありません。
加えて、見積条件書には何らかの情報の欠落や誤りがあるのが常なので、契約した企業はこれを理由に増額を迫ってくる場合があります。
つまり、プロジェクト・オーナーは、スケジュールと見積条件書の不備の挟み撃ちに会い、受注者の要求する増額を飲まざるを得ない立場に追い込まれてしなうことになります。
従って、買い手の交渉力が強い契約以前の段階での売り手との交渉が重要となるので、発注金額の1,2%の費用をかけても外部知識を活用することは合理的であると言えます。
注11. Claim Engineer
海外では、発注者と受注者の対立関係を利用したClaim Engineerと言う専門職があるとのことです。
業務内容は、発注者が提示する見積条件書を精査して不備を見つけ（例えば設計図面の不備）、契約後にこの不備を突くことによって獲得できる追加報酬の目安を示します。
例えば、普通に行った見積が10億ドルで、不備による追加報酬が2億ドル見込めるとします。すると、競争相手より安い9億ドルで落札しても、追加報酬を加えれば11億ドルになる、と言う算法です。
Claim Engineerは入札に応募者の依頼を受け、見積条件書にどの様な不備があるかを検討することが役割です。
6で述べる協働型のコスト・マネジメントでは、この様な発注者‐受注者間の対立構造を回避することも意図されています。
4. 情報の少ないプロジェクト初動期のコスト・マネジメントが重要です
プロジェクトの初期段階ではプロジェクトのコストを見積るための情報は少なく、見積の確度が悪いことが指摘されています。このことは、プロジェクトを実行するかどうかを判断する投資対効果検討（Business Case）や事業実現性判断（Feasibility Studies）の段階で大きな問題となり、次の2つが重要なテーマとなります。
① さほど多くはない情報で的確な予算を設定するための見積手法
② 設定した予算で目標とする成果物を実現するためのマネジメント手法
4.1. プロジェクト段階における見積の確度とその問題点
プロジェクトの段階によって見積に利用することのできる情報は異なっている訳で、通常初期段階の見積の確度は低いことになります。AACEは、利用可能な情報量に対応した見積のタイプとして3タイプを設定しており、このタイプに見積の確からしさが対応しています。以下に引用し、訳出しておきます。
■AACEの定義する見積のタイプTypes of Estimates
コスト見積のタイプを分類する際には様々な属性が考えられますが、もっとも一般的に用いられる見積は次の3タイプです。
オーダーレベルの見積（超概算）Order-of-Magnitude Estimates
詳細な技術上の情報が無い段階での見積です。このタイプの見積は、+50%から-30%の確度です。オーダーレベルの見積は、超概算と呼ばれることもあります。確度は落ちますが、プロジェクトの実行可能性を迅速に判断する、複数の代替案のふるい分けをする、などで有用です。オーダーレベルの見積は、期待される成果物、建物の全体面積、必要なユニット数と言った基本的な条件のみを用いて推定するのが一般的です。
予算用の見積（概算）Budget Estimates
予算用の見積は、プロジェクトの詳細条件を決定するために必要な情報、即ち、フロー・シート、レイアウト、装置の詳細等の情報に基づくもので、+30%から-15%の確度です。予算用の見積はオーダーレベルの見積よりも確度が高いので、プロジェクトの実現可能性の判断や予算決定には、このレベルを用いることが望まれます。予算用見積の正確性や有用性は、見積において利用可能な情報量に規定されます。
最終見積（精概算）Definitive Estimates
名前が示すように、詳細で確定的な技術情報に基づくものです。この様な技術情報は建設の許可を受けた設計図書や仕様書に基づくものです。+15%から-5%の確度が求められており、その後のプロジェクト運営の物差しとなる見積です。
There are numerous characteristics that can be used to categorize cost estimate types. The most significant characteristics are degree of project definition, end usage of the estimate, estimate methodology, as well as the effort and time needed to prepare the estimate.
The Most Commonly Used Estimates
Order-of-Magnitude Estimates
Estimates made without detailed engineering data. An estimate of this type would normally be expected to be accurate within +50 percent or – 30 percent. Order-of-magnitude estimates are sometimes referred to as “conceptual” or “ballpark” estimates. They have a wide range of accuracy, and have important applications, such as using them to determine the feasibility of a project quickly or to screen several types of alternative designs. Order-of-magnitude estimates are generally prepared using only basic criteria such as desired output, total square meters, or number of units.
Budget Estimates
Budget estimates are prepared with the help of flow sheets, layouts, and equipment details. In other words, enough preliminary engineering has taken place to further define the project scope. An estimate of this type is normally expected to be accurate within +30 percent or -15 percent. Since the budget estimate is more definitive than the order-of-magnitude estimate, it is better suited for determining project feasibility and establishing definitive budget. The accuracy and usefulness of a budget estimate depends, to a large extent, on the amount and quality of information available.
Definitive Estimates
As the name implies, these are estimates prepared from very defined engineering data. The definitive estimate includes various degrees of detail estimates which could be made from “approved for construction” drawings and specifications. Definitive estimates are also called “check” lump sum, “tender,” and “post-contract change” estimates. An estimate of this type is usually expected to be accurate within +15 percent or – 5 percent.
■BoehmのコーンとAACEの見積のタイプの関係
プロジェクトの段階と見積の確度の関係としては、古典ともいえるBoehmのコーンThe Cone of Uncertaintyがあります。前述のAACEの見積タイプとの比較をしてみましょう。これを下図に示します。
両者ともにプロジェクトのフェーズが進むと見積の確度は指数関数的に高まっていくのですが（確度の幅はAACEの方が小さいのですが）、プロジェクトの予算を設定する段階の確度の幅は、下記の様に大きすぎると言えます。
・現実の観察に基づくBoehmのコーンでは要件定義の段階では‐33%～＋50％の幅
・これ位であるべきとの規範的要素も含むAACEでは-15%～+30%
プロジェクト実施の決定段階での予算が‐15%であったとすると、実際のコストは予算の17.6%増となりますので（100/85）投資対効果の判断が大きく狂うことになってしまいます。第4講の「2.4プロジェクトの収益力に基づく経済性評価」での事例では、IRRは19.2％から12.5%に下落してしまいます。
https://note.com/nakawaketakeshi/n/na4068cd25453
4.2. プロジェクト初期段階での低い見積の確度にどう対応すれば良いのでしょうか？
予算設定段階の見積の確度が-15%～+30%ではとてもプロジェクトに対してGoやKillの判断は下さないのではないか、と述べましたが、では一体どうすれば良いのでしょうか？
■予算を構成する要素
ここでは、コスト・マネジメント観の転換を提案したいと考えているのですが、その前に一般的な予算構成の考え方を理解しておく必要があるので、これを簡単に説明しておくことにします。
AACEのガイドブックでは、予算構成を下図のように捉えるのが適切だと述べています。
① コスト算定基礎額
プロジェクト全体に関するその時点での情報に基づくコストの算定額です。先程の確度はこの値に関するものです。
② 変動対応費Contingency
大変重要な要素ですが、日本では残念ながらキチンとした概念で捉える事は余りないようです。正確を期すため以下AACEの説明を引用・訳出しますが、通常起こりうる変動に対応するための費目で、使用することが前提となっています。
経験的には発生しがちであることが知られていてコスト上昇につながりますが、生じるか否か及び生じた場合の影響度合いが不確実な事象に対応するために、見積に上乗せされる費用を変動対応費と呼んでいます。過去のプロジェクト事例に基づく統計的推定や経験的判断に基づいて上乗せ額が設定されるのが一般的です。
以下は、変動対応費には含まれないことに注意して下さい。
・最終成果物の仕様、要求性能、建築物の規模、プロジェクトの敷地の変更などの大規模なスコープの変更
・ストライキや自然災害などの例外的な事象の発生
・予備費（下記③を参照のこと）
・急激な物価上昇や外貨為替変動
An amount added to an estimate to allow for items, conditions, or events for which the state, occurrence, or effect is uncertain and that experience shows will likely result, in aggregate, in adding costs. Typically estimated using statistical analysis or judgment based on past asset or project experience. Contingency usually excludes: 1) Major scope changes such as changes in end product specification, capacities, building sizes, and location of the asset or project; 2) Extraordinary events such as major strikes and natural disasters; 3) Management reserves; and 4) Escalation and currency effects.
③ 許容誤差/Allowance
人間の行動に不可避な誤差に対応するものです。分かり難いのですが、以下の様に定義されています。
その存在は分かっているけれども明確に定義することができない資源の利用に対応するのが許容誤差です。
Resources included in estimates to cover the cost of known but undefined requirements for an individual activity, work item, account or sub-account.
建築工事費の見積における典型的な許容誤差として、以下の様なものが挙げられています。
・設計上の許容誤差Design allowance for engineering equipment
・数量上の許容誤差Material take-off allowance
・購入上の許容誤差Overbuy allowance
・運搬時の破損Unrecoverable shipping damage allowance
・主要な要素に関する定義できない許容誤差Allowance for undefined major items
④ 予備費/ Reserve
プロジェクトのスコープの範囲外の事象に対応するために、プロジェクト・オーナー側に使用を一任された費用です。変動対応費と予備費の相違は、スコープの範囲の内（変動対応費）か外（予備費）かであり、予備費が使用された場合には、プロジェクトのスコープやベースラインを変更する必要があります。
An amount added to an estimate to allow for discretionary management purposes outside of the defined scope of the project, as otherwise estimated. Use of management reserve requires a change to the project scope and the cost baseline, while the use of contingency reserve funds is within the project’s approved budget and schedule baseline.
■コスト・マネジメント観を転換する
見積の確度が低い原因として、要求事項に追加や変更が生じる、を上げることができます。プロジェクトの出発時点で要求事項を明確に定義することのできないプロジェクトが増えた現在、要求事項が確定することを前提としてコストの基礎額を算定し、これに変動対応費や予備費を別々に見込むという予算設定の方法そのものに無理があるとも言えるでしょう。
そこで、コスト・マネジメント観を下図の様に転換することを提案します。図中転換①としているのは6で述べる協働型のマネジメントが転換②になるからです。
では、図に従って説明します。
① 要求事項が確定しない段階でプロジェクト全体を対象とする算定基礎額をコスト・マネジメントの基礎とすることにはあまり意味がありません。これに替えてその時点で必須の、確定した要求に対応したコストを算出します。ただし、この部分のコスト算定は通常の初期段階の算定法よりも確度を上げることが必要です。
② 現時点では確定しないけれども、追加される可能性がある要求、高度化される可能性がある要求をリスト化し、夫々のコストへのインパクトを大雑把に推定します。
③ 予算は、プロジェクトによってもたらされる便益から設定されますが、一般には次の関係になる筈です。
必須（確定）要求に対するコスト＋追加・変更される要求に伴う増額
＞ 予算
そこでこの差額が、プロジェクトにおける減額目標となります。
④ 追加・変更は、優先順位の高い順に検討し採用が確定する毎に、そのコストを算定し、確定コストに加算し、予算を超過する場合にはそこで、追加変更を終了するか、既に採用した要求の取りやめを検討します。
⑤ 追加・変更はオーナーに起因する訳ですので、この様なコストの追跡は、オーナーとプロジェクト・マネージャーの協働作業とするのが適切です。
⑥ 予算項目もこれに対応させ、変動対応費と予備費を一括し追加変更対応費用として予算計上します。
■Agile開発との関係
ソフトウエアのAgile開発ではオーナーにとって優先順位の高い項目から開発を進めて行き、当初想定した優先順位の変更や機能の追加・変更を取り入れるプロジェクト進行となります（下図の上段）。
ハードな構築物の場合、要求の優先順位に従って成果が出来上がる訳ではないので、プロジェクト・オーナーの要求がプロジェクトの進行にともって具体化・豊富化されることに対応するというAgile発想は、必須要素を明らかにした上で、これに付け加える出発点では曖昧な要求の具体的なイメージをオーナーに提示し（プロトタイプやBIM）、オーナーにとっての優先順位を明らかにしながら予算の割り当てを行っていくことになると考えます（下図の下段）。
５．コスト・マネジメントには不条理が付き物 これにどう立ち向かっていくのかが問われます
プロジェクト・マネージャーは、限りある予算と限りない要求という圧力に常にさらされており、コスト・マネジメントは大変困難な仕事です。
コスト・マネジメントを困難にする要因として、以下の9点を挙げることができます。
① プロジェクト目標・要求事項の曖昧性が高い
② 要求事項の変更が多い
③ ステイクホルダーの要求が対立する場合がある
④ 予算を初期に決めなければならない
⑤ コストが政治的に決まっていてその変更に対して政治的圧力がある
⑥ プロジェクト推進側にバイアスがある
⑦ 予算が硬直的で変更ができない
⑧ 物価変動がある
⑨ プロジェクト・オーナーの価格交渉力が働かない
以下では、これらへの実践的な対応策を検討したいと思うのですが、この様な記述は類書には見られず、発展途上であり、今後の豊富化が必要であることをお断りしておきます。
5.1. プロジェクト目標・要求事項の曖昧性が高い
プロジェクトの対する要求事項のベースとなるプロジェクトの目的や目標の抽象度・曖昧度が高いのが現代プロジェクトの特徴と言えます。他方、企業の財務規律や収益力の確保といった観点から、プロジェクトに投入できる資金には、自ずとかなり明確な上限が存在します。
そこで、明確な予算の制約の下で目標の曖昧なプロジェクトがスタートする、という矛盾に直面することになります。ここでの真の仕事は、通常のプロジェクト・コスト・マネジメント「承認済みの予算内で完了するための、計画、見積り、予算化、資金調達、財源確保、マネジメントおよびコントロール」とは異なったものとなります。
通常のコスト・マネジメントでは、プロジェクト全体を対象とするコスト算定の基礎額があって、この額を見積ることと、これをベースに様々な変動要素や不確実性をマネジメントすることが仕事の中核となります。他方、目標の抽象度・曖昧度が高いプロジェクトの場合、算定基礎額そのものが曖昧なので、算定基礎額と予備費を区分することに意味がなくなってくるからです。
この場合重要となるのは、プロジェクト・オーナーや主要なステイクホルダーが、これはやる価値がある、これこそ我々が求めていたものであると、賛同しその具体化を積極的に支援してくれるような、目的→目標→要求事項の具体化であり、以下の3点を実施することがプロジェクト・マネージャーに求められる対応となります。
a. やりたい事と当初の予算枠の中でできることの関係を明確にしていきます。
b. 要求事項に優先順位付けをし、絞り込みをします。
c. 予算枠の対象範囲と金額の見直しをしていきます。
曖昧性の高いプロジェクトの場合、プロトタイプやパイロットによって、プロジェクト・オーナーやステイクホルダーの意向と、技術的な重要課題の所在と解決の方向、の両者の確認を行うことの有効性が多くの専門家によって指摘されています。下記の2点が重要となります。
d. 曖昧性を明確化する過程と明確となった要求事項をモデルとして具体化する過程を並行して進めます。
e. プロジェクトによっては上記過程dを繰り返してプロジェクトを進行させます。
5.2. 要求事項の変更が多いが予算の増額が殆どない
要求事項の変更が多くなる要因として、以下の（ア）～（ウ）が挙げられます。この内、要因（ア）と（イ）への対応は5.1で述べた「曖昧性対応」と共通であり、特に要因（イ）の場合には「曖昧性対応e」が該当します。
(ア) プロジェクト・オーナーやステイクホルダーの要求が曖昧である
(イ) プロジェクトが一定進行することによって具体化する課題や条件がある
(ウ) プロジェクトの置かれた環境条件が変化する
環境条件の変化については、都度対応していてはプロジェクトの現場が混乱し、モティベーションの低下→品質の低下を招くことになるので、以下の対応が望ましいと言えます。
f. プロジェクトの節目の終了時点において、まとめて変更を施します。
g. 次の段階における変更事項として他の追加条件と合わせて対応します。
以上の様に進行すればプロジェクト・マネジメントとしては理想的ですが、要求事項に変更はあっても予算の変更は殆んどない、が実情ではないでしょうか。この場合の対応は、不透明性はあるものの、プロジェクト・マネージャーの裁量によって予備費を確保しておくしかないでしょう。即ち、
h. 全体予算の中に変更対応という枠を設け一定割合をプールします。この中では最も合理的と思われ、本来プロジェクト・マネージャーはこれを採用すべきです。但し要求事項の変更があっても予算変更は認めないという非合理な組織文化でこの様な措置が認められるか、疑問です。
i. プロジェクト構成要素夫々に、一定の非本質的な過剰品質を組込んでおいて、この予算を変更対応として放出します。但し、一旦過剰品質がオーナーに見破られると、それ以降のプロジェクト運営に支障をきたすので、それなりの戦術的工夫が必要です。
j. 一般にプロジェクト予算管理では資本的支出（CAPEX）が中心となるので、資産購入（CAPEX）からサービス購入（OPEX）へと切り替えることによってプロジェクトの範囲外とします。但し、LCC（Life Cycle Cost）の観点からの妥当性の検証が必要です。
k. サプライヤーとの厳しい価格交渉によって値切ります。この場合、品質低下や他のプロジェクトでの調達価格とのバーターなど不透明な関係が発生しやすいので注意を要します。
5.3. ステイクホルダーの要求が対立する場合がある
第3講で紹介したブリーフィング誕生の背景の一つは、行政、学校経営、教育者、父兄等の多数のステイクホルダーが存在する学校建設プロジェクトにおける合意形成であったと言われていますが、ステイクホルダーの要求が対立する場合、プロジェクト・マネージャーの対応は以下の様になるでしょう。
https://note.com/nakawaketakeshi/n/n9ba35989803c
l. ブリーフィングを活用して、ステイクホルダーのオープンな議論の場を作り、共通する価値や目標と相互の立場性の相違を確認します。「ハーバード流交渉術」Getting to YESが提案する相互満足型の円満交渉術「原則立脚型交渉」の基盤を作ります。
m. より具体的な局面では、それぞれの要求事項を一定充足する代替案を複数提示し、現実的な解決策を絞り込みます。
また、5.2で述べたh～kも極めて現実的な対応として必要となる局面もあります。
尚、詳しくは第8講のステイクホルダー・マネジメントで検討します。
5.4. 予算を初期に決めなければならない
プロジェクトに関する様々な情報が不十分な中でプロジェクト実施が決定されることから、宿命とも言える課題であり、後出pの類似例の情報収集が重要です。
初期に決定されるということは、曖昧性が高い中での決定である訳ですからその後の変更が多い、という事態を招来することになるので、「5.1要求事項の曖昧性が高い」「5.2要求事項の変更が多い」で述べた対応を行うことになります。
5.5. コストが政治的に決まっていてその変更に対して政治的圧力がある
国家的プロジェクトの場合、予算は過去の事例に基づく推定といったような技術的な数字ではなく、この値でないと合意形成が不可能であるという、政治的、宣言的な数字である場合が多いと言えます。東海道新幹線の場合も、当初予算は政府内の反対を押し切るために意図的に低く抑えられ、世界銀行のファイナンスを獲得して外堀が埋められたと言われています。
一方、各方面からの要望を取り入れて要求事項はエスカレートする傾向にあります。
この様にして、宣言的な予算とエスカレートする要求事項の乖離は大きくなっていきます。一方プロジェクト実施機関は、この事をプロジェクト・オーナーに説明できない弱い立場にあることが多いので、問題の所在をプロジェクト・オーナーや外部に訴えるといった自己犠牲的な行為を別にすると、プロジェクト・マネージャーが問題解決のために取りうる選択肢は極めて限定的です。
n. 乖離が小さい場合には、そもそものプロジェクト予算の定義が曖昧な事に立脚し、当初予算の範囲を限定的に定義して追加予算を獲得に努力します。
o. 乖離が大きい場合には、問題が爆発した際に、自身を含め実務関係者がスケープゴートにされないよう明確な根拠を残しておきます。
5.6. プロジェクト推進側にバイアスがある
「公共工事におけるコスト・オーバーランの実態と参照クラス予測」で述べた事項です。プロジェクト実施判断の重要な根拠の一つであるプロジェクト予算の推定は、実施推進サイドで行われるので、5.5で述べた政治的圧力以外に、自身にもプロジェクトを実施したいというバイアスがかかっています。
それ以外にも、専門家には（或は人間には）、過去の都合のよい例などを参照にするといった計画の誤謬が働くことが明らかとなっています（本講補足3を参照して下さい）。
p. プロジェクト予算の見積においては、過去の類似事例を収集し、対象プロジェクトとの相違点を明らかにした上で、市況・仕様・調達力等を加味した適切な補正を行います（本講補足2を参照して下さい）。
q. これに対して、中立的な第三者のレビュー（peer review）を仰ぎます。
5.7. 予算変更ができない
日本のプロジェクトの場合、官民を問わず一旦決めた予算の変更が認められず、当初予算内でプロジェクトを終了させるのがプロジェクト・マネージャーの任務であり能力である、という一種の非合理主義が存在します。
本来は、予算変更ができないのであれば要求事項を緩和するのが合理的対応の筈ですが、これが認められないのです。
従って、プロジェクト・マネージャーの対応には合理的対応と非合理への対応の二面作戦が求められることになります。これらについては既に「5.1プロジェクト目標・要求事項の曖昧性が高い」、「5.2要求事項の変更が多い」の項で述べた通りです。
5.8. 物価変動がある
物価変動に関しては、次の2ケースが想定されます。
(ア) 計画・設計中に起きた物価上昇のためにFS上の予算を超過してしまった。
(イ) 製作や工事が長期間に及び物価上昇への対応をコントラクターが求める。
物価変動への対応はしないと契約で定めるといった強権的な対応を除くと、プロジェクト・マネジメント上の対応は以下となります。
r. VE（ヴァリュー・エンジニアリング）や仕様変更によるCD（コスト・ダウン）を実施し、設計変更によって予算に合致させます。
s. 価格やVE・CD能力が総合的に競われるような調達方法を工夫します。
t. 契約後は、プロジェクトが人質にされて発注者の交渉力が弱まるので、物価の上昇・下降両者に対応する契約とするとともに、物価変化の判断に公正さが導入される見直し手順や見直し基準を契約条件として明確にします。
注12. VE（Value Engineering）
製品やサービスの「価値」を、それが果たすべき「機能」とそのためにかける「コスト」との関係で把握し、 システム化された手順によって「価値」の向上をはかる手法です。実務的には、品質・性能水準を保ったままコストを削減する方法、コストの増加なしに品質・性能水準を引き上げる方法を意味しています。
5.9. 交渉力が働かない
3.2.4で述べた様に、一般に、契約後はプロジェクトが人質となって発注者の交渉力が格段に弱まることになります。そこで、契約後の買い手の交渉力を確保するために以下の方策を実行します。
u. 事前に、業界の状況に詳しい第三者をコンサルタントとして採用し、プロジェクト・オーナーの期待する事項に合致する様な調達先の選定方式を工夫します。
v. 変更対応等、契約後の交渉のルールを契約前に明確に定めておきます。
以上を一覧表にしました。尚、買い手と売り手が協働する実践については次節6で取り上げることにします。
6. 協働的なコスト・マネジメントという新しい流れにも注目しておきましょう
3「コストとプライス（費用と価格）の違いを認識し、適切な調達方法を選ぶ」での記述は、買い手はなるべく安く、売り手はなるべく高く売りたいとの相反した欲求を持つ主体間の相互作用を基本とするものでした。下図の対立的Adversarialな調達観と言えます。
これだけが、唯一の調達方法でしょうか？そうではないでしょう。ここで考えたいのは、買い手と売り手が協働することによって双方に利益をもたらす協働的Collaborativeな調達観です。
6.1. 協働的な調達の基礎にある考え方
協働的な調達では、下の概念図に示すように、買い手と売り手が協働して売り手にかかる製品コストを削減し、この削減分を買い手と売り手の両者で分け合うというものです。買い手にとっては購入価格が低減し、売り手にとっては利益が増加することになります。
これは絵に描いた餅ではないか？
その様に思われる方も多いかもしれませんが、決してそうではありません。その理由を説明します。理由は大きく5点あります。
① 変動対応費Contingencyが圧縮される
② コスト削減につながる合理的な提案を行うことに対するインセンティブを働かせる
③ プロジェクト初期より製作者が参加し、製作のしやすさを設計に反映する
④ 分野を越えた協力により合理的な方法を見出す
⑤ 手戻りを減らす
① 変動対応費Contingencyが圧縮される
4.2では変動対応費を、買い手側であるプロジェクト・オーナーの予算の構成要素として説明しました。しかし、売り手（下図A社）も買い手の要求を十分に理解している訳ではないので、売り手としての変動対応費を見込むでしょう。この売り手が業務の一部を外注すると（下図B社）、B社も同様に変動対応費を見込むという様に、変動対応費の連鎖が発生します。（下図参照）
これらの変動対応費を合計すると、当初予算の相当な割合となります。例えば、予算の10％の変動対応費を見込み予算の半分を外注するとすれば、変動対応費の合計はオーナー予算の20％に達します。
変動対応費は買い手の要求が良く分からない、買い手の要求には変更がある、等の想定に基づいているので、プロジェクトの早い段階から買い手と売り手が情報を交換し不確実性を減らすことができれば、変動対応費を圧縮できる可能性が生れます。
対立的な調達では、プロジェクトの早い段階から買い手と売り手が情報を交換することは困難なので（買い手の手の内が売り手にばれてしまう）、この様なやり方は成立しません。
② コスト削減につながる合理的な提案を行うことに対するインセンティブを働かせる
売り手が早い段階からプロジェクトに参加し、買い手とコミュニケーションを行うことによって買い手の要求を深く理解すると、それを実現するためのより合理的な方法を見つけ出す可能性が高まります。ここで、合理的な方法の採用によって一般的なやり方よりもコストが削減された場合、この削減分を買い手と売り手が分け合う仕組みを導入することによって、売り手の売上額は減っても純利益は増大するので、合理的な提案を行うインセンティブを持つことになります。
③ プロジェクト初期より製作者が参加し、製作のしやすさを設計に反映する
一般に、建築であっても、プラントであっても、ソフトウエアであっても、設計する人たちが実際の製作を行う訳ではありません。従って、設計する人たちには製作のしやすさに関する実践的な知識が十分にある訳ではないので、設計に製作のしやすさが十分に反映されるとは限りません。
プロジェクトの早い段階から、プロジェクト・オーナーと設計メンバー、製作メンバーが一つのティームを構成することによって、この様なメリットを引き出すことのできる可能性がります。トヨタ式の新車開発方法として世界的に有名となった、Front Loading方式に他なりません。
④ 分野を越えた協力により合理的な方法を見出す
設計メンバー、製作メンバーと言っても様々な分野があり、別の部署であったり別の企業であったりします。一般には夫々の分野にわかれて業務を行い、分野の接点で情報交換や調整が行われることになります。この場合、各分野内での最適化や合理化の提案がなされることはあっても、分野を跨ぐ提案は中々なされないのが現実です（蛸壺化、サイロ・エフェクト）。
そこで、③で述べた一つのティームに様々な分野のメンバーが参加し、分野を跨ぐ合理化の成果が公平に配分されるルールを導入することによって、分野を越えた協力が生れる可能性が高まります。
⑤ 手戻りを減らす
製作に着手した後に設計変更が発生し、このため出来上がった成果物に修正を加える、一から作り直すなどの手戻りによるロスも頻繁に発生しる事象です。軽微な変更であれば変動対応費で処理されますが、そうでない場合、オーナーは追加変更費用を支払う必要があります。
そこで、手戻りを減らすことが重要となりますが、これまで述べてきたことは、下記の要因によって手戻りの減少につながります。
・プロジェクト・オーナーのプロジェクトへの参画度が高く、設計段階での意思決定が通常よりも良く考えられた上での決定であったので、製作段階での変更が減少した
・設計段階で設計者は製作者とコミュニケーションをしながら設計を進めているので、製作段階での設計変更が減少する。
6.2. 協働的な調達は既に実践されている
6.1で述べた協働的な調達は絵に描いた餅ではなく、既に実践が試みられているものです。
ここでは、実践例として最も対立的と考えられている欧米の建築プロジェクトにおけるIPD: Integrated Project Delivery, alliance, partneringを簡単に紹介します。
また、ソフトウエアにおけるAgile開発も協働的な調達の一つであると解釈できることを述べたいと思います。
6.2.1. 建設プロジェクトにおける協働型のプロジェクト方式
伝統的なプロジェクト方式におけるプロジェクト体制と、協働型のプロジェクト方式のプロジェクト推進体制を比較して、下図に示します。
■ 伝統的な建設プロジェクト方式
伝統的な建設プロジェクト方式のプロジェクト推進体制は上図左のようになっています。
・設計者はオーナーと設計契約を結び、設計を行い工事に入ると設計通りの工事がなされているかどうかをオーナーに替わって監理します。
・設計図に基づく工事金額の競争入札を経て、元請施工者が選定されます（英語ではGeneral Contractorですが、日本ではこれを略してゼネコンと呼ばれます）。プロジェクト・オーナーは元請施工者との二者間で工事契約を締結します。
・元請施工者は、自分自身で行う直営工事の他は、電気工事、機械工事、衛生工事、鉄骨製作等工事を分割して専門工事施工者と契約します（英語ではSub-Contractorですが、日本では略してサブコンと呼ばれます）。
・サブコンは、請負った工事の一部を2次下請けに、2次下請けは一部を3次下請けに、と重層的な契約関係で工事が進められますが、プロジェクト・オーナーが工事契約を結ぶのは上述の様に元請のみです。
・施工者がプロジェクトに参加するのは、設計が終了した時点であるのが通常なので、施工者の有している施工ノウハウが設計に反映されることは基本的にありません。
・同様に、専門工事施工者の有しているノウハウが元請施工者の工事運営に反映されることも基本的にはありません。
・この方式では、プロジェクト・オーナー、設計者、ゼネコン、サブコンの関係者間で様々なコンフリクトが発生し、関係者間の関係は協働的と言うよりは対立的な関係となっています。
・プロジェクト・オーナーは入札方式を用い、通常最も安い値付けをした元請施工者を選定します。
■協働的な建設プロジェクト方式
この様な関係者間の対立構造を協働構造に変革すべきであるとして提案されたのが、IPD: Integrated Project Delivery方式で、米国、豪州、フィンランドなどで実践が活発化しています。
・この方式では、プロジェクトの当初から、プロジェクト・オーナーと設計者、元請施工者、専門工事施工者が一つのティームを形成してプロジェクトを推進します。メンバーの選定には、総合評価方式が適しているとされています。
・プロジェクトの初期には、このティームはプロジェクト・オーナーの目標が予算内で実行可能かどうかを協働で検討します（Validation Studiesと呼ばれます）。
・その結果がYesであれば、プロジェクトの予算とその予算で実現すべき成果を設定し、設計に着手します（Target Value Design）。設計においても、継続的に施工や製作の合理性が反映されます。
・図中トーンのかぶせられた、プロジェクト・オーナー、設計者、元請施工者、専門工事施工者A～Cは、プロジェクトが予算を下回った場合の利益を共有する（上回った場合は負担を共有する）R/R Group: Risk Reward Groupを形成します。これによって、R/R Groupメンバーには、協力してプロジェクトの効率化や創造的な解決方法を見出すための動機付けが働くことになります。これが伝統的な競争入札に替わるコスト合理化のメカニズムです。
・R/R Groupを形成するメンバーは一つの契約にサインします（Poly-party Form）。
・設計と並行して一部の製作も進められるので、プロジェクト期間の短縮も可能となります。
6.2.2. ソフトウエア開発におけるAgile方式
■Agileはどの様な問題を解決しようとしたのか？
Agile方式は、2001年Agile宣言（米国）によってWaterfall方式のソフトウエア開発に対するアンチテーゼとして提案されました。
顧客は開発の出発点で自分のニーズを理解している訳ではないにもかかわらず、Waterfallでは、出発点で、顧客の要望を詳細かつ厳密に抽出した後に設計に着手しようとします。従って、以下の問題が生じる、とAgileでは考えます。
1. ソフトウエア開発の成功率が低くなります
2. キチンと要件を定義し、QCTを守っても顧客は満足しません
3. 顧客内もビジネス担当とシステム担当で認識が異なります
4. 顧客は、要件定義書を見てもシステムのイメージができません
5. 具体的に動くものを見て、ニーズが湧き上ってきます
6. Waterfallでは、これは違うと認識するのはほぼ出来上がった時点です
7. 失敗した時には、ほぼすべてが没になります。
■Agile開発方式とWaterfallの実践上の最大の相違は何でしょうか？
両者のプロセスを比較して下図に示します。
・Waterfall開発ではシステム全体の設計条件を詳細に検討し、プロジェクト・オーナーとシステム開発側がこれに合意した後に、システム開発に着手します（図中の設計条件にサインオフする）。
・設計条件に合意した後の変更は合意した条件の変更となるので、変更の条件（期間や費用）に関してオーナーと開発側が協議を行い、変更の条件に合意した後に変更が行われることになります。
・Agileでは、オーナーが最も優先順位が高いと考える要素から開発に着手し、オーナーと開発者が協働で要求事項を整理し、開発を進めて行きます。
・オーナーは、一つの要素ごとにシステムの働きを確認していきます。また、開発を進めて行く時点で要素の優先順位の見直しや、新たな要素の追加が行われます。
■協働的なコスト・マネジメントとしてのAgile開発
Agileは、プロジェクト・オーナーの要求を出発点で詳細に定義することは困難で変更は不可避である、という現実を解決する方法として提案されたものですが、コスト・マネジメントの観点からも、協働的なアプローチであると言えます。プロジェクトの予算の有効な使い方を、プロジェクト・オーナーとシステム開発側が議論しながら、対話的に決定していると解釈できるからです（下表参照）。
注13. What’s Different about Agile Cost Management? を参照しました。
https://www.dummies.com/careers/project-management/whats-different-agile-cost-management/
コスト・マネジメントの奥深さが分かって頂けたでしょうか？
売り手はより高く売ろうとして、買い手はより安く買おうとして策略をめぐらすという取引こそが現実的で有効であり、協働的なコスト・マネジメントは幻想だ、と思われる方もいるかもしれません。
勿論、全てを協働的な取引をすることはできない訳ですが、その可能性を拡げていくことは重要だと考えるものです。
本論はこれで終了ですが、補足として以下の3点を紹介します。
補足１：PMBOKにおけるコスト・マネジメント
補足２：コストの見積方法
補足３： 計画の誤謬
補足１：PMBOKにおけるコスト・マネジメントの扱い
■PMBOK®6th
第7章が、プロジェクト・コスト・マネジメントに当てられており、次のように定義されています。
プロジェクト・コスト・マネジメントは、プロジェクトを承認済みの予算内で完了するための、計画、見積り、予算化、資金調達、財源確保、マネジメントおよびコントロールのプロセスからなる。
① コスト・マネジメント計画策定 Plan Cost Management
② コスト見積 Estimate Costs
③ 予算設定 Determine Budget
④ コスト管理 Control Costs
予算の構成概念は下図の通りです。PMBOK®7thでは少し変更され単純化されているので、両方を示します。
・WBSで分割した各業務の見積基礎額（Activity Cost Estimates）が出発点となります。
・これに各業務レベルでの変動対応費①（Activity Contingency）を加算したものが、分割された業務のコスト見積（Work Package Cost Estimates）となります。
・更に、プロジェクト全体での変動対応費②（Contingency Reserve）を加えたものが、プロジェクト・マネージャーが所管するコスト・マネジメントの基準となるコストです。
・オーナー側は、プロジェクト・マネジメントの範囲を超える事態に対応するための予備費を持っており、これを加えたものがオーナーにとってのプロジェクト予算となります。
6で述べた協働的なコスト・マネジメントからすると、変動対応費や予備費は一体的に運用されるべきだと言えます。
■PMBOK®7th
2021年8月に発行されたばかりのPMBOK®7thについての筆者の見解は、番外編「PMBOK®7thの先へ プロジェクト・デザインでプロジェクトの発意・形成と実行をつなぐ」https://note.com/nakawaketakeshi/n/nca88e79be338に述べた通りですが、ここではコスト・マネジメントに限って記述します。
PMBOK®6thでは「5のプロセスX10の知識領域」というマトリックス型の構成となっていて、コスト・マネジメントは10の知識領域の一つでした。一方、PMBOK®7thでは、12の原理と8のパフォーマンス・ドメインと言う2部構成になっており、コスト・マネジメントがまとまった一つの章として記述されている訳ではありません。
そこで、巻末の索引を使って、コストに関する記述を拾ってみることにしましょう。
■12の原理でのコストに関する記述
原理の4番目価値に焦点を当てるFocus on Valueで、費用便益分析Cost Benefit Analysisとして登場するだけです。
■8のパフォーマンス・ドメインにおけるコストの記述
予算の構成 Budget Build Up
2.4 計画Planning Performance Domain 2.4.2.4Budgetにおいて上図の予算の構成概念が示されています。
① PMBOK®6thに比較してシンプルな構成となっています。
② EVMで用いられるCost Base Line＝Work Cost Estimateに変更されています。Contingencyを含まないこの区分の方が明快であると考えます。
③ Project Budgetも予備費を含まないものとなっています。予備はオーナー側に属し、プロジェクト・マネージャーの所管外なので、この区分が適切と思われます。
品質とコストCost of Quality
2.6 成果Delivery Performance Domain 2.6.3.1で品質にまつわるコストCost of Qualityが記述され、次の4段階でのコストを見込むべきであるとしています。
① 品質の問題を発生させないための予防的費用Prevention
② 品質の確認に要する費用Appraisal
③ 成果が使用される以前に発見される欠点を改善するための費用Internal Cost
④ 成果が使用された後に発見された欠陥の改善費用External Failure
EVM: Earned Value Management
2.7 計測Measurement Performance Domainで記述されているEVM: Earned Value Managementの記述に関連したコストへ言及しています。
予備費Cost Reserve
2.8 不確実性Uncertainty Performance Domainにおける予備費Cost Reserveへ言及しています。
PMBOK®6thでは、まとまったコスト・マネジメントへの言及があるものの手続き的知識が多く、実践における有用性は限定的でした。PMBOK®7thでは冗長と思われる手続き論的知識の記述はなくなり、また予算の構成概念も明快になったと思いますが、新たな観点が導入されている訳ではありません。プロジェクト・マネージャーは重要なマネジメント領域であるコスト・マネジメントに関して、自分でガイドブックを編集する必要がありそうです。
補足2：コストの見積方法
１．コストの見積方法は大きく4種類
コストの見積は、見積対象に関する情報がどの程度あるかによって用いることのできる方法が異なってきます。使用できる情報量が少なくて済む順番に並べると、大きく下記の4種類の方法があります。
① 専門家による推測Expert Judgement Method
② 統計データを用いる方法Parametric Estimating Method
③ 類似プロジェクトを参考にする方法Analogous Estimating Method
④ 積上げBottom-up Estimating Method
① 専門家による推定Expert Judgement Method
プロジェクトに関する簡単な情報を伝えて、その道の専門家にどれくらいの費用が必要かを判断してもらうものです。専門家は、自身の直観によって回答する訳ではなく、類似事例を参考に、難易度、規模、物価指数や市場の情況（売り手市場か買い手市場か）などを参考に、「これくらいのオーダーでしょう」と答えるものす。Order-of-Magnitude Estimatesとも呼ばれます。
オーナーはこれ以上検討することに意味が有るのか無いのかなど、入り口の判断や求めるレベルを設定する際に用います。
② 統計データを用いる方法Parametric Estimating Method
実績データを統計的に分析して、プロジェクトの特徴を表す幾つかの変数とコストとの間の関係式を導き出すものです。ソフトウエア開発におけるCOCOMOモデルや、建築プロジェクトにおけるジャパン・ビルディング・インフォメーション等が分かり易い事例です。
COCOMOモデルConstructive Cost Model
統計的手法を用いたコスト見積もりのモデルで、ソフトウエアのコストを増加させるさまざまな要因を明確にして、それに対する係数を考慮しながら開発工数を推定して見積を行います。
下表に示す3つの段階のモデルがあります。最も少ない情報しか利用できない基本COCOMOの場合は、下表の下ようにしてコストを見積ます。
klocはソースコードの行数（キロステップ）、effortは工数(人月)
注14. COCOMOによるプロジェクト工数の見積もり http://itref.fc2web.com/management/cocomo.html
JBCI Japan Building Cost Information
実際の契約価格に基づいて下図6に示したような建築コストに関する統計データが公開されており、現在はインターネット経由で利用することが可能です（有償）。この事例では、地域、地上・地下の階数、建物高さ、全体面積、杭の長さといった、建築コストに影響を及ぼす要因を考慮できますが、建物グレードを明示的に考慮することはできません。
多くの事例に基づいているので、蓋然性は確保されていますが、プロジェクト固有の条件は反映されないので、①や③と併用するのが良いと思われます。
③ 類似プロジェクトを参考にする方法Analogous Estimating Method
対象とするプロジェクトと類似したプロジェクトのコストを参照して、プロジェクト固有の条件で補正を行う方法です。通常プロジェクト・オーナーが類似プロジェクトの情報を入手することは困難なので、専門家に依頼することになります。言い換えれば、この様な情報を多数保有し適切に補正することができるのが優れた専門家の条件だと言えるでしょう。
事例数が少ない特殊なプロジェクトでない限りFS（Feasibility Study）における使用に耐えうる方法です。FS上知りたいのは、コストではなくプライスの予測値なので、下記の要因を顧慮した補正を行う必要があります。
・時点修正：物価の変動が大きく時点修正が必要です
・調達方式修正：競争がどの程度働くか買い手の交渉力で価格は大きく異なる場合があります
・品質による修正：プロジェクト固有の品質を考慮した修正が必要です
・特殊要因修正：その他プロジェクト固有の条件を考慮します。
④ 積上げBottom-up Estimating Method
通常の見積書でイメージするもので、∑数量X単価で構成されています。
数量を拾うといっても、プロジェクトの段階で利用できる情報密度が異なっているので、初期段階から細かな内訳を求めるのは意味がないし、時間の無駄だと言えます。また作成に費用も掛かるので、プロジェクト固有の条件を反映した見積と言えますが、代替案を機動的に検討し、意思決定を固めていく段階の方法としては適していません。
２．求められる方法論の改革
下記の様な理由から、プロジェクトの初期段階から種々の代替案を比較検討する場合が増えており、コスト・マネジメントもこれに対応することが求められています。
・マーケティング上、多数の選択肢の中から有効な案を絞り込んでいきたい
・市場環境が複雑で、先験的に事業内容を絞ることができない
・価値観の異なる複数の事業者による共同事業のため、合意形成のために複数案を検討する必要がある
・プロジェクト・ファイナンスを得る上で、投資家の賛同を取り付ける必要がある
他方、プロジェクトのコストの決まり方を考えてみると、プロジェクト全体のコストが徐々に霧が晴れるように決定されていくのではなく、ある初期的な判断を下すことによって確定するコストがあることが分かります（例えば建物の階数を決めれば、階段やエレベーター等の必要な最低限のコストは確定するでしょう）。
このことは、統計データによる方法や類似事例に基づく方法を補う方法を開発する必要があることを意味しています。下図左の様な、常にプロジェクト全体のコストがマネジメントの対象で、徐々にコストが確定していくという霧が晴れるモデルではなく、右の様に、ある決定によってあるコストが確定し、コスト・マネジメントの対象範囲が絞られていく、例えて言えば陣取りゲームのような手法の開発が求められており、DXはこれを可能にすると思われます。
補足３：計画の誤謬とバイアスの緩和方策The Planning Fallacy and Debaising
公共工事におけるコスト・オーバーランの実態と参照クラス予測で述べたThe Reference Class Forecastingがベースとしているのは、ダニエル・カーネマン（Daniel Kahneman）の提唱したThe Planning Fallacy計画の誤謬です。ここでは計画の誤謬から脱却するためのバイアスの緩和方策を紹介します。
注16. 本項の記述は、Roger Buehler et.al, The Planning Fallacy, Advances in Experimental Social Psychology, Vol. 43, 2010の要約的紹介です。
■計画の誤謬とは過去に対する現実主義と将来に関する楽観主義の逆説的結合です
計画の誤謬とは、考慮に入れるべき経験を過去にしているのにも関わらず、あることを達成するのに必要な時間を過小に見積もる傾向と定義されています。
people’s tendency ‘‘to underestimate the time required to complete a project, even when they have considerable experience of past failures to live up to planned schedules.’’
つまり、計画者が単に楽観的であるということではなく、それに逆行する歴史的な根拠に直面してもなお楽観を維持するという点が、単なる楽観主義バイアスと計画誤謬との概念上の相違点です。
not that planners are optimistic but that they maintain their optimism about the current project in the face of historical evidence to the contrary
したがって、過去に対する現実主義と将来に関する楽観主義の逆説的結合に対する認識こそが計画誤謬という概念の豊かさです。
we believe it is the remarkable combination of realistic knowledge about the past and continuing optimism about the future that gives the planning fallacy its bite. Definitions that do not acknowledge the paradoxical combination of optimism about the future with realism about the past miss much of the richness of the phenomenon.
■過去の経験の利用を阻むものObstacles to using past experiences
対象とする業務の遂行に要する時間の推定において、外的視座の活用つまり対象とする業務を類似の課題の範疇・集合の一要素として扱うことを阻む顕著な要素として次の3点を挙げることができます。
① 予測・計画という行為がそもそも未来志向の行為であって、このことが過去の経験を参照することを阻む要因となります
② 類似の経験という際の「類似」という言葉の意味の曖昧さによって、類似の経験に関する情報に接してもそれを類似とは見なさない傾向があります
· 自分の経験でも不快なものは軽視する傾向
· 他人の経験は、本当に何が起こったのかは分からないとして一般化することを疑問視する
③ 類似経験とみなした場合でも、類似の範囲を限定してしまって教訓をくみ取る範囲を限定する傾向があります。
· 過去の事例解釈において、外部の不安定要因や事例固有の要因を重視し、適用可能な範囲を限定
「人間は、他人の経験から学ぶことができるという点でユニークだが、それが嫌いであるという点でも特筆に値する。」
In sum, we note three particular impediments to using the outside perspective in estimating task completion times: the forward nature of prediction which elicits a focus on future scenarios, the elusive definition of ‘‘similar’’ experiences, and attributional processes that diminish the relevance of the past to the present. …‘‘Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.’’(Douglas Adams)
■バイアス緩和策/Debias
計画の誤謬という観点から、予測の楽観主義的傾向をもたらす要因が分析され、バイアス緩和策/Debiasとして以下が示唆されています。
・類似事例の統計分析による予測Reference Class Forecasting
・中立的な第三者の判断の導入The Third-person Perspective
・第三者的立場の採用The Imagery Perspective
・潜在的な障害への注意喚起Attending to Potential Obstacles
・成功させたいという動機付けの最小化To minimize Motivations and Social Pressures
・業務の分割The Unpacking or Segmentation of a Target Task
・予測を現実化しようとする意志の持続Implementation Intension, Behavior-based Approaches
以上でコスト・マネジメントの講義は終了です。
過去の講義は下記マガジンから参照して下さい。
https://note.com/nakawaketakeshi/m/m130881b572e0
次回はコミュニケーションマネジメントの予定です。
この記事が気に入ったらサポートをしてみませんか？