2005年、アメリカ国防契約管理局（DCMA）は、国防総省が抱える膨大な量の契約とスケジュールの評価を支援するために、工程評価の14項目をDCMA 14-POINT Schedule Assessmentとして策定、公開しました。

後年、この工程評価14項目は「DCMA 14ポイント」としてプロジェクトマネジメントの現場で広範囲に使用されるガイドラインとなり、Primavera P6などのスケジュールツールにもチェック機能として実装されています。

日本では馴染みが薄く、日本語でわかりやすく解説した情報が少ないため、弊社コンサルタントによる解説を公開いたしました。
プロジェクトの種類や規模を問わず、スケジュール作成時に留意するべきポイントが示されていますので、ぜひ「DCMA14ポイント」をスケジュール構築の評価にご活用ください。

より適切なスケジュール構築のため、合わせてこちらもご参照ください。

企業としてのプロジェクト管理の仕組み作り（5）　～工程管理編～　（クリティカルパス・メソッド解説）

①ロジックの確認 (Checking the Logic)

ネットワークスケジュールのロジック（リンク）が途中で切れていないか。
もしロジックが切れていてネットワークが完全ではない場合は、クリティカルパスの妥当性が低くなる。

② リードの調査 (Looking for Leads)

負のラグは「リードタイム」と呼ばれる。
負のラグはあらゆる種類の問題を引き起こす可能性があり、また紛らわしくなりがちである。負のラグはないのが望ましい。

③ ラグの調査 (Looking for Lags)

DCMAは正のラグになると少し寛容であるが、ここではスケジュール作成におけるラグの使用を最小限に抑えることを目標にする。
ラグを持つリレーションシップを全体の5%以内とすることが目標である。

④ 正しいリレーションシップタイプ (The Right Relationship Types)

P6などのスケジューリングソフトウェアは4つのリレーションシップタイプをサポートしている。
しかしStart to Start (SS) などFinish to Start (FS) 以外を多用するスケジュール計画は最適ではなく、DCMAではスケジュールの90%以上をFinish to Start (FS) で計画するべきであるとされている。

⑤ 強制制約について (How 'bout those Hard Constraints)

強制制約はロジックに影響し、スケジュールロジックを無効にする。
DCMAでは、強制制約はすべての制約アクティビティの5%以内にすべきといている。

⑥ 総フロートの長さ (Rein-in your Total Float)

総フロートは44稼働日を限界とする。
とても長いフロートを持つアクティビティは正しくロジックが組まれていない可能性があり、クリティカルパスを崩壊させる原因となる。

⑦ 負のフロートはあってはならない (Negative Float is Never Good)

DCMAでは負のフロートはあってはならないといている。
ある場合は文書化したキャッチアップ計画が必要となる。

⑧ 所要期間の長いアクティビティは分解する (Break Down Those Long Durations)

所要期間が2ヶ月を超えるアクティビティは長すぎるとし、一連の短いアクティビティに分解する。
また、長い所要期間のアクティビティは全アクティビティの5%以内に制限する。

⑨ 無効な日付を確認する (Check for Invalid Dates)

実績の日付が計算日（Data Date）より将来にあってはならない。
逆に今後のアクティビティの予測日付（未来の日付）が計算日（Data Date）より過去にあってはならない。
Primavera P6 はこのような状態を許容しないが、どのソフトウェアで作成されたスケジュールに対してもこのチェックは適用される。

⑩ リソースとコストを山積みする(Load it up with resoures and costs)

DCMAでは、リソースとコストが山積みされたスケジュールを好む。
有効なアクティビティは全て対象とする。

⑪ アクティビティの遅れを無くす (Subvert Activity Slippage)

誰でも納期は守りたい。ここでは、ベースラインと比較して遅れて終了したアクティビティ数を確認する。
プロジェクトが時間通りに完了するかを確認するための包括的なチェックとなる。

⑫ クリティカルパスの正当性 (Critical Path Integrity)

良いロジックによる流動性を確認し、スケジュールにおけるクリティカルパスの正当性をチェックする。
DCMAでは、（クリティカルパス上のアクティビティの所要期間を極端に長くしてみるなど）スケジュールの遅れにより、プロジェクト完了日が同じように遅れるかをチェックする。

⑬ CPLI (Critical Path Length Index)

プロジェクトの「クリティカルパスの長さ」と「プロジェクト総フロート」を加算したものを「クリティカルパスの長さ」で割り、比率を計算する。
計算結果が100%になることが良く、95%未満は失格とする。

⑭ BEI (Baseline Execution Index)

ベースライン実行指数（BEI）は、「完了したアクティビティ数」を「ベースライン上で完了しているべきアクティビティ数」で割り、比率を計算する。
計算結果が100%になることが良く、95%未満は失格とする

前回のコラムでは、洋上風力発電プロジェクト成功への留意事項「工程管理の責任範囲の拡大」についてお伝えしました。

今回はもう一つの留意事項、「日本と海外の商習慣の違い」に起因する留意点についてお伝えしたいと思います。

まず、日本と海外の商習慣について特徴的な違いを対比させてみます。

あえて一言で対比させると、「性善説と性悪説」、「信頼ベースと契約ベース」、「定性的と定量的」といった言葉が当てはまるかもしれません。

日本では、多くの社会的イベントがほぼ単一民族であることの相互認識や長年築いた信頼関係による暗黙の了解が、様々な問題を未然に防ぐ役割を果たしています。ビジネスでもこの文化が見られ、契約書にない状況や責任の曖昧な対処も、互いの信頼により問題解決が図られる傾向です。予想外の事態、例えば追加費用が発生しても、事後の話し合いで解決が期待できます。

対して海外ビジネスでは、将来の誤解や紛争を抑えるために責任範囲と計画を明確にしたうえで、言語や文化の差による曖昧さを避けるため、契約内容の明文化と合意、それに基づいた履行や交渉が前提です。逆に言えば、このプロセスを怠る・逸脱すると、後に大きな問題に発展するリスクが高まることを意味しています。

また前回のコラムでは、洋上風力発電プロジェクト特有の事情に触れ、「工事の遅れによる稼働期間の減少が投資回収リスクの増大に直結する」、ゆえに「受注者と事業者は計画通りの工程を維持・管理する責任を強く負う」ことをお伝えしました。
このことを念頭に、洋上風力発電のような大規模プロジェクトにおけるステークホルダー間の情報連携をイメージしてみます。




工程管理では、計画の進捗や遅延・変更の情報共有、例えばドキュメント承認による設計フェーズの完了確認や、想定外の要因による計画変更の合意などが行われます。
そしてこれらの情報は、プロジェクトが計画通りに進捗しているかを把握するのと同時に、契約の履行や修正に関連する意思決定の証拠でもあり、先に述べた「将来の誤解や紛争を最小限に抑えるため」の重要な証跡です。

特に洋上風力発電プロジェクトのような、海外ベンダーを含む多くのステークホルダーが関わる長期プロジェクトでは、重要情報の発信、受領、合意の記録と参照の確保が全ステークホルダーにとって必須です。

日本的な、信頼関係を前提とした暗黙の了解を期待しては「それ言ったはず」「それ...と思っていた」となり、紛争のリスクが高まります。

一般的な情報共有の主な手段はメールやファイル共有ですが、この方法ではプロジェクト完了までの履歴を完全に記録し、追跡可能に保つことが困難です。また、ドキュメント管理システム（DMS）とワークフロー（WF）など組み合わせでも、「削除が不可能」「中立」を満たすことが難しく、海外プロジェクトではコレポン専用のITソリューションが利用されています。

その中でも「Oracle Aconex」は、ビジネスにおけるインターネットの活用が始まった黎明期にコレポン専用のSaaS（Software as a Service）として開発され、20年以上にわたり利用され続けているソリューションです。
上に挙げた要素の網羅はもちろんのこと、プロジェクト終了までユーザ数とストレージ容量が無制限に利用できる、などの利便性から高い評価を受けており、建設業界やエンジニアリング業界をはじめとした数多くのプロジェクトで採用されています。

海外流のビジネス環境では「それは言ったはず」という主張は通用せず、契約の履行や変更に関する証拠が提出できない場合、将来的に大きな問題（例えば賠償責任）の火種となりかねません。

工事が本格化する前やプロジェクト検討フェーズでは費用を抑えて利用できるプランも用意されていますので、ぜひ「Oracle Aconex」でコレポンの実践を検討しては如何でしょうか。

「Oracle Aconex」の詳細に関しては、弊社のホームページや製品概要資料をご参照ください。

このほか弊社コンサルタントによる別のコラムも「Oracle Aconex」の理解を深めるのに役立ちますので、ぜひご一読いただければと思います。

【弊社コラム】「それ言ったはず」は海外では通用しない　～コレポン管理～

また、Oracle社のホームページでは、海外の洋上風力発電プロジェクトにおける「Aconex」の活用事例が公開されていますので、こちらもぜひご参照ください。

【海外事例】Oracle Aconex Helps Siemens Gamesa Renewable Energy Power the World

2024年2月13日、日本オラクルアプリケーションズ＆テクノロジーユーザーズグループ（OATUG）建設エンジニアリング分科会のセミナーにて、弊社 EPMソリューション部 部長 金子 健一が講演を行いました。

日本OATUGは1998年に発足したOracle Applicationsユーザー向けのコミュニティで、製品別や業界別に特化した分科会(SIG)が組織されています。中でも建設エンジニアリングSIGは、建設及びエンジニアリング業界での実務に役立つDXに関する情報提供と会員間の交流を目的としたグループです。
FY24 第2回セミナーとなる今回は、大手の建設会社や建設業界に関わるコンサルタントなど、約20名が参加されました。

FY24第2回 OATUG建設エンジニアリングSIGセミナー/懇親会 (2024/2/13)

弊社セッションでは「建設・エンジニアリングにおけるプロジェクト管理の変遷」をテーマに、2000年代初頭にプロジェクトマネジメントの知識体系である「PMBOK」が日本で注目を集め始めたことを起点とした、これまでのユーザー課題の振返りと将来の展望について講演いたしました。

【講演要旨】

・約20年間の建設・エンジニアリング業界におけるプロジェクトマネジメントに関するユーザ課題の変遷
・ユーザー課題解決のためのITソリューション発展の歴史
・コロナ過以降の働き方改革によるバーチャル組織における管理の必要性の増大
・特徴的な支援事例

セミナー後のQ&Aセッションでは、海外プロジェクトでは一般的なロジックスケジュールを用いた工程管理手法が日本で普及しない現状への問題提起と、その原因に対する意見交換が行われました。
この中で、日本の契約慣行や商習慣が、工程遅延に対するペナルティを明確にしていないことが要因の一つとの意見があり、参加者の考察が促されました。
また、セミナー後の交流会でもこのテーマに対する熱心な議論が交わされ、海外プロジェクトに携わるユーザーの関心の高さが伺えました。

TIS千代田システムズは、今後も建設・エンジニアリング業界のユーザーと連携しながら、最適なプロジェクトマネジメントソリューションの提供を通じて、ユーザーの課題解決に貢献してまいります。

【EPMソリューション部 部長 金子 健一 略歴】

国内外のインフラ建設プロジェクトを中心に、プロジェクトコントロール部門（工務部門）のスケジュールエンジニアリング、コストエンジニアリングを、20年以上にわたりIT面から支援。AACE日本支部会員、PMP。ENAA L2PM修了。

現代社会が目覚ましく進化し、世界情勢が変わるにつれて、持続可能なエネルギーソリューションへの需要が国際的に高まっています。

このエネルギー転換の波の中でも特に洋上風力発電が世界的な注目を集めており、日本は国土を囲む豊かな海域を活かし、この新たなエネルギー源の開発に適した地理的環境を持っていると評価されています。

日本では2019年4月に施行された「再エネ海域利用法」に基づき、洋上風力発電のための促進区域、有望区域、および準備区域を定めて開発を促進しています。既にいくつかの区域で発電事業者が選定され、先駆けとなるプロジェクトを進行中の事業者においては、発電・売電の開始が間近に迫っています（2024年1月現在）。


　
 ＜＜図版１＞＞
出展：「制度の概要｜洋上風力発電関連制度｜なっとく！再生可能エネルギー 」（資源エネルギー庁）を加工して作成

国の後押しもあり今後ますます発展が見込まれる洋上風力発電プロジェクトですが、太陽光発電などの再生可能エネルギーと比べ事業規模も大きく、工事も複雑・長期にわたるため高い事業リスクを伴います。しかしまだ国内における先例が少なく、プロジェクト成功に向けた発電事業者や施工関係者のご苦労は大きいものと想像します。

特に、キーコンポーネントとなる風車の調達や海上での施工に関しては、洋上風力発電をリードする海外ベンダーとの連携が欠かせず、しばしば海外の商習慣に則ったプロジェクトマネジメントの必要性に迫られるようです。

このような背景から、海外のプロジェクトマネジメントで利用されるソリューションを長年提供している弊社に対し、日本の洋上風力発電プロジェクト関係者より "海外流のプロジェクトマネジメント" に関する問いあわせが多く寄せられております。

これらの経験をもとに、TIS千代田システムズが考える「洋上風力発電プロジェクト成功への留意点」を2点、お伝えしたいと思います。

ひとつ目は、各ステークホルダーの業務遂行、ひいては事業計画に大きな影響を及ぼす「工程管理」に関してです。
以下は洋上風力発電プロジェクトにおけるステークホルダーとの関係と、留意すべき視点を現したものになります。

もしかすると、国内工事で多く見られる「一括発注・請負」の契約に慣れた関係者にとっては、事業者と受注者の契約/承認（視点①）に複数の矢羽が存在することに違和感をもたれるかもしれません。しかし海外ベンダーとの連携が必要な洋上風力発電プロジェクトにおいては、各パッケージごとに分割発注 ＝ バラコンで契約が行われることが一般的です。

実際には国内ベンダーの施工が１パッケージにまとめられる事があると想像しますが、風車の調達や特殊な海洋工事など、海外ベンダーとの連携においては分割発注となる事が多いようです。
このような場合、事業者は各パッケージ間の工程の調整にも積極的な関与が求められ（視点②）、プロジェクト全体工程の維持についても多くの責を負います（視点③）もちろん受注者においても、事業者や他の受注者と適切な工程の連携が欠かせません。

また、洋上風力発電事業は法規制により「FITによる売価×稼働期間」の売上キャップが想定されます。売価は事業者選定の入札で定められるため、工事の遅れは稼働期間の減少、すなわち投資回収リスクが高まります。
このため、受注者は事業者に、また事業者は出資者に対して、計画通りに工程を維持・管理する責任をより強く負います。

すなわち、海外ベンダーを含めた工程の維持管理の責を負う事業者とその受注者は、次のような要求にも応えられる工程管理ソリューションの利用が必要です。

・全てのステークホルダーの計画と進捗が統合して管理できること
・統合された工程情報をもとに、様々な視点で進捗確認が簡単にできること
・大規模プロジェクトの複雑な工程であっても、これらが実用的なスピードで動作すること

少なくとも、日本で多く利用される「Excelガントチャート」による工程管理手法では、適切な工程管理を維持することが難しいことは想像できるかと思います。

このような海外ベンダーを含めた多くのステークホルダーとの適切な工程管理が求められるプロジェクトにおいては「Primavera P6 EPPM」が広く利用されています。
30年以上にわたり数多くの海外プロジェクトで利用されてきた実績から、事業者の発注要件に「Primavera P6のデータで計画・進捗の提出」が明記されるほどの、グローバル・スタンダードな工程管理ソリューションです。

「Primavera P6 EPPM」の詳細についてはこちら

クリティカル・パス・メソッド（CPM)による計画の策定や、ガントチャートによるビジュアルな進捗把握など、工程管理ソリューションに求められる当たり前の機能に加え、先に挙げた要求にも全て応えられる仕組みが提供されています。
海外の事業者・受注者ともにPrimavera P6を駆使した工程管理のナレッジ蓄積があることからも、本ソリューションの利用がデファクトスタンダードと言えるでしょう。
工程管理の責任拡大への備え、ぜひ導入・利用に向けた準備をお勧めいたします。

Primavera P6 EPPMの詳細については、こちらのコラムも参考になるかと思いますので、ぜひご覧ください。
「企業としてのプロジェクト管理の仕組み作り（5）　～工程管理編～」

続いてのコラムでは、「洋上風力発電プロジェクト成功の留意点」の二つめ、「日本と海外の商習慣の違いへの備え」についてお伝えしたいと思います。

プロジェクトではオーナー、コントラクター、ベンダーなど様々な企業とドキュメントなどのやりとりやコミュニケーションを行う。特に近年では複数社でプロジェクトを契約する JV（ジョイントベンチャー）やコンソーシアムなどのケースが増えてきており、プロジェクト関係者は多数の企業をまたがってプロジェクトを進めていくことが多くなっている。

このようなプロジェクトでは、企業間でいろいろな決裁処理が発生する。しかし、これらの決裁処理はあまりシステム化されていないケースが多いようだ。

社内による照査・承認などの社内決裁については、ワークフローシステムを構築し、システムによる決裁を行っている企業があると思うが、企業間をまたがるプロジェクトの決裁では自社で使用しているワークフローシステムを活用するのが難しく、またプロジェクト期間中だけ必要となるためプロジェクトワークフローシステムを検討するプロジェクトが少ないようだ。

しかし、ビル建設内装のデザインなど実際に他社のプロジェクト関係者と合意を取りながら進めるケースは多数発生する。

これらの合意をメールでやりとりした場合、誰で決裁が止まっているのか、決裁がいつになったら終わるのかを追跡していくのは大変な作業になる。

下図はプロジェクトワークフローの例である。

社内承認（１次決裁）後にコンサルタント会社へ決裁依頼（２次決裁）が届き、承認後にオーナーへ決裁依頼（３次決裁）が届く仕組みとなっている。
それぞれの決裁を決裁ステップと呼んでおり、各決裁ステップに決裁期限を設けることにより、いつまでに決裁を完了させる必要があるかを明確にしている。

このように決裁ステップと決裁期限を明確にして管理することにより、数あるプロジェクト関係者間の決裁をスムーズに行おうという考え方になる。

ただし、この考え方に対しシステムを活用せずメールなどの履歴で管理すると非常に時間と労力がかかる。また離れた拠点間での決裁ルートが発生するため、手軽にアクセスし管理ができる仕組みが必要となる。

最近はこのようなケースで、プロジェクトワークフロー機能を持ったクラウドのドキュメント共有システムが活用されることが多くなってきている。

では、プロジェクトの決裁でシステムを活用する例を説明していこう。今回はプロジェクトワークフロー機能を持つドキュメント共有システム Oracle Aconexを使って紹介する。

下図はAconexのワークフロー設定画面である。Aconexの場合ワークフローの設定はマウスで手軽にできるので、専門的なスキルを持っていなくても以下の手順で設定できる。

①決裁ステップの追加と名前の登録（決裁者の数分を追加する）

②各決裁の期限を設定

③ステップ完了ルール（１ステップに複数承認者がいる場合）などの設定

この設定例では、

2日間以内に「Architect Review（社内決裁を想定）」に決裁をしてもらい、
承認後5日間以内に「Consultant Review（社外決裁を想定）」に決裁をしてもらい、
承認後2日間以内に「Owner Review（社外決裁を想定）」に決裁をしてもらう内容になっている。

またステップ内に分岐がある場合は、分岐全員の決裁を完了したら次のステップに進む設定にしている。

設定が完了したら作成したワークフローで（ドキュメントなどの）決裁処理を始める。
下図はワークフロー設定後にドキュメントの決裁を回してみた結果である。
「Architect Review（社内決裁を想定）」は完了になっており、現在「Consultant Review（社外決裁を想定）」 中（期限：2018年8月17日）となっている。
これにより、ドキュメントの決裁が現在どこでされているかがわかり、決裁依頼は決裁者にメールで通知される。
また、それぞれの決裁者は別画面で決裁依頼一覧（未決裁の確認など）も確認できるようになっている。

これらの決裁はクラウド上で行われるため、プロジェクト関係者が複数の国にわたっていても、インターネットでプロジェクトワークフローにアクセスできるようになっている。

以上のようにプロジェクトワークフローのシステムを上手に活用すると、プロジェクトで発生する決裁状況の追跡や決裁依頼の確認に大きな効果が得られる。

また、このようなワークフロー機能を有したドキュメント共有システムは、他にもプロジェクト関係者でドキュメント共有をする機能やコレポン機能なども必要に応じて持たせることができるようになっており、プロジェクト用のドキュメント管理・共有にとても適している。

さて、今回「企業をまたがるプロジェクト決裁の仕組み作り」というテーマで企業をまたがったプロジェクトの決裁ワークフローの仕組みについて述べてきた。
通信の発展により増えていくグローバルプロジェクト、プロジェクトの関係者は国を越え、企業を越え、複雑なコミュニケーションルートをいかに管理するかが重要となっている。
みなさんもシステムを活用したプロジェクトワークフローの仕組みを作って効率良くプロジェクトの決裁をしてみてはいかがであろうか。