※本文中のARES PRISMはブランド名を「Contruent Enterprisse」に変更いたしました

みなさんはプロジェクト用アプリケーションにクラウドを活用しているだろうか。
クラウドというと IaaS（Infrastructure as a Service）[イァース]、PaaS（Platform as a Service）[パース]、SaaS（Software as a Service）[サース]の3つの考え方が定番となっている。この3つの定義について調べてみると、IaaSはハードウエアまで、PaaS は OS や実行環境を伴うプラットフォームまで、SaaSはアプリケーションまでとよく書かれている。
しかし、SaaS はアプリケーションベンダーがその会社のアプリケーションのみ提供しているものであり、実際には PaaSのプラットフォームに自社でアプリケーションのインストールや設定を行うか、メインベンダーのアプリケーションに絞って SaaS にするかのどちらかになり、複数ベンダーのアプリケーションが自由に選べるわけではない。

例えば、あるユーザーがプロジェクトでCADアプリケーションと工程管理アプリケーションを使う必要が出たとき、CADベンダーと SaaS 契約したうえで、更に工程管理アプリケーションのベンダーと SaaS 契約する必要がある。
また、ユーザーはバージョンの指定が困難であったり、それぞれのアプリケーションベンダーへテクニカルな問い合わせや教育依頼をしなくてはいけないなどの課題が出てしまう。

そこで今回話題にあげたいのが、PaaS でも SaaS でもない必要なアプリケーション層までを提供する次世代クラウドである。
ソフトウエア（アプリケーション）とプラットフォーム両方を提供するということで、ここではあえて SPaaS（Software and Platform as a Service）[エスパース]と呼びたいと思う。
SPaaS はプラットフォームに加え、アプリケーション層を提供する。つまり必要なアプリケーションと数量を伝えるだけで、必要なアプリケーションが必要な数量だけ、いつでもどこでもブラウザから利用できるようになる。
これによりインストールなどの設定作業や認証化、ユーザー設定などが一切不要になる。

上図は SPaaS サービスのイメージであるが、プラットフォーム上にアプリケーション層があり、そのなかに必要なアプリケーションが必要な数量用意される。
サービス利用者はサービス提供ベンダーへ使いたいアプリケーション名、数量、ユーザー情報を伝える（ここでは、ユーザー1がアプリケーションAとB、ユーザー2がアプリケーションBとCとD）。するとユーザー1のブラウザからアプリケーションAとBが、ユーザー2のブラウザからBとCとDが使えるようになる。
ユーザーはいつでもどこでも必要なアプリケーションが利用できるようになるのだ。もちろんプラットフォームに自社システムを乗せることも、システム間連携開発を行うことも可能だ。

SPaaS サービスのメリットは運用が開始されてからさらに発揮される。
下図は一般的にアプリケーションの導入と運用に必要な業務である。
環境構築とシステム運用保守（ユーザー管理や障害対応など）、教育、ユーザーサポート（ヘルプデスク）などアプリケーション導入後はやるべきことが山のようにある。

しかし SPaaS サービスは、使用するすべてのアプリケーションに対してこれらを1つのユーザー専用ポータルから提供しているのだ。
もちろん、管理者専用ポータルではシステム管理者が気になるアプリケーションライセンス使用状況（ライセンスが足りているか、多過ぎないかなど）や利用場所履歴（なりすまし対応など）をいつでも確認できるようになっている。

もう1つ運用時に大きな問題になるのが、アプリケーションのバージョンアップである。アプリケーションベンダーが提供する SaaS はアプリケーションのバージョンアップがあった場合、プロジェクトの途中であっても強制的にバージョンアップされてしまう。この場合、プロジェクトのレポーティング（発注者側にする報告）やシステムパフォーマンス、連携しているシステムへの影響が懸念される。このような懸念に対し SaaS ではなくオンプレミスや IaaS、PaaS にしてアプリケーション製品管理は自社でという結論になる企業も多いようだ。

実は SPaaS サービスは、このようなケースにもっとも強い。
1つのアプリケーションに対し、複数のバージョンを持ち、ユーザーごとにバージョンを変えることが可能だ。
よってプロジェクトの途中で強制的にバージョンアップされることもなく、自社で対応する必要もないのである。
まさに IaaS でもない、PaaS でもない SaaS でもない SPaaS は第四の次世代クラウドの考え方である。

では SPaaS サービスの例を紹介したいと思う。
今回は弊社のプロジェクト用 SPaaS サービス「PROJECT CLOUD™」の例で紹介する。

下図はブラウザからユーザが PROJECT CLOUD™ にログインして工程管理アプリケーション Oracle Primavera P6 とコスト管理アプリケーション ARES PRISM を使用している例である。弊社への手続きはアプリケーション名と使用したいバージョンを申請するだけである（注：ライセンス自体は取り扱っていないアプリケーションもあるので要確認）。

アプリケーションにもよるが、申請後一週間もあれば各ユーザーのブラウザから申請したアプリケーションの（指定したバージョンの）アイコンが画面左に表示される。アイコンをクリックするとアプリケーションが立ち上がり、すぐに使用できる。

PROJECT CLOUD™ はプロジェクトで使用する以下の5カテゴリに対するアプリケーションを、200種類以上用意している。

 ● アセット管理＆トラッキング
 ● CAD/BIM
 ● コスト管理/見積
 ● GEO 地理空間情報
 ● プロジェクト管理/契約管理

例えば、有名なアプリケーションとして AutoCAD、ARES PRISM、Oracle Primavera、Microsoft 関連のアプリケーションを PROJECT CLOUD™ に申し込んだ場合、一週間程度で各ユーザーのブラウザにアイコンが表示され使用できるようになる。

また、上図のとおりサポートページも用意されており、申し込んだすべてのアプリケーションに対してサポートが受けられるようになっている。問い合わせ先が一元化されているので、ユーザーはアプリケーションごとに違うベンダーへ問い合わせする必要がなくなる。
企業によっては、社内システムサポート部門を用意しているところもあるが、プロジェクトに特化した専門スキルが必要なアプリケーションのサポートは難しいため、これらのサポートが1ヶ所から提供されることは、とても効果的である。

さらに、PROJECT CLOUD™ ではユーザーは画面でトレーニングをしながらアプリケーションの操作を覚えることができる（動画コンテンツ作成は別サービス）。
下図は、工程管理のアプリケーション Oracle Primavera P6 の操作トレーニング動画を使用している例である。
ユーザーは Oracle Primavera P6 を使って工程作成する手順、進捗更新する手順などがわかるようになっている。

ここまでは、ユーザー側のイメージで紹介してきたが SPaaS サービスである PROJECT CLOUD™ はシステム管理者にもメリットがある。
下図はシステム管理者専用ページである。使用されているアプリケーションの使用状況を表示している。これにより、ライセンスが不足していないか、また過剰にライセンス契約していないかを確認でき、ライセンス違反対策や適正ライセンス数の検討ができるようになる。

また、下図は利用場所履歴となっており、なりすまし対策等どこでアプリケーションが利用されているかが確認できるようになっている。

そのほか、アプリケーション別利用者状況やストレージ、サポート・ステータス（重要度別平均解決時間など）などシステム管理者が確認したいレポートが揃っている。

このように SPaaS サービスである PROJECT CLOUD™ は、いつでもどこでも必要なプロジェクト用アプリケーションが使用でき、システム管理者も管理用ポータル画面でいつでも必要な情報が揃い、アプリケーションの導入・管理時間や労力を大幅に縮小することができるサービスとなっている。

以上、今回は日々進化する通信環境において、新しいかたちのシステム提供（プロジェクト用）について話をしてきた。
企業では下図のように社内標準システムだけでなく、プロジェクトや業務でよく使用されるアプリケーションも企業としてまとめて運用・管理したいという動きがでてきている。併せて検討されるのが必要なときに必要な分の環境利用料だけ発生するクラウド環境の活用である。
今回紹介した IaaS、PaaS、SaaS でもない第四の次世代クラウドはそんな時代の流れにあったニーズにより考えられたものである。

企業として本当に必要なシステム環境が何か、いつでもどこでも利用できる状態にするにはどうしたらよいか。
進化する通信環境をうまく活用しシステム構築・運用・管理をしていくことが、経営やプロジェクトの意思決定を迅速化し、企業の力をあげていくに違いない。

みなさんはプロジェクトのリソース計画・管理をどのようにしているだろうか。

昔は比較的規模が大きいプロジェクトが多かったため、プロジェクトで納期内かつ予算内に完了させるためのリソースを計画・管理が考えられていたように思う。

しかし、グローバル化や通信の発展にあわせ、各企業間での競争が激しくなりプロジェクトが低利益化、短納期化し、個別プロジェクトで十分な利益の確保が以前より難しくなるにつれて、企業としてリソース計画・稼働管理をどのようにするべきかが考えられるようになってきた。

下図は経営理念から考えるポートフォリオマネジメントのピラミッドに企業のリソースを当てる図となっている。
かつては各プロジェクト内でリソース管理が行われ、管理方法はプロジェクトに託されることが多かったが、最近では短納期の複数プロジェクトを抱える企業が増え、プロジェクトをまたいで、リソースを効率的に活用しようとする動きに変わってきた。

例えば、企業内に全社のプロジェクトを支援しモニタリングする立場のPMO（プロジェクトマネジメントオフィス）などを設置し、全社要員の稼働を可視化して非稼働要員を利用することにより、外注費を削減したり受注活動に割り当てて受注増を狙うなど、限られたリソースを最大限活用するための検討や調整を行っている企業も多くなっている。

まさに、プロジェクトのリソース管理から企業リソース最適化へ注目度が変化してきているのである。

では、企業リソース（要員）最適化のプロセスについて紹介していこう。
下図は企業リソース最適化のプロセスを示している。

各プロセスの詳細は次の通りとなる。

下図は、企業リソースの最適化の分析・調整を絵にしたものであり、① ～ ④ の情報のほかに企業のプロジェクト・ポートフォリオ分析による経営判断を含めたKPIをもとにしたプロジェクト優先度結果の情報を加え分析・調整により企業リソースが最適化されていく。

ここまでリソース稼働管理をテーマに企業リソースの最適化について述べてきたが、この仕組みを実現するにはシステムの活用が不可欠である。

ではここからシステムを活用した、企業リソースを最適化するリソース稼働管理について説明していきたいと思う。今回はプロジェクト・ポートフォリオマネジメント機能を持つ Oracle Primavera P6 を活用した例を紹介する。

まずは ① リソース情報の登録 と ② 要員計画の確認 であるが、下図のとおり要員情報、スキル（または役割）情報、年間の要員投入計画（月別など）を社内システムなどから Oracle Primavera P6 へ取り込む（システム間の連携開発は必要）ことで実現する。

次に ③ プロジェクト要求確認 であるが、ここではプロジェクトから必要要員を要求するところから説明したいと思う。
下図はプロジェクトのスケジュール計画者が必要要員と工数を割当てている。

各プロジェクトからのリソース要求を企業全体で確認すると下図のようになる。
下図は現在遂行中または計画しているプロジェクトと各要求されている役割の工数山積みを示している。下図の例では、Civil/Structural Crews の役割ができる要員をどのプロジェクトでいつ求められているかが分かるようになっている。
6つのプロジェクトが遂行中もしくは計画の状態にあり、キャパシティ（企業の要員投入計画値）を超えているのが分かる。
この場合、対象時期に増員を予定してキャパシティをあげて調整するか、プロジェクトの開始時期等の調整をすることが考えられる。

ここでは、プロジェクトの開始時期等の調整をする例をあげてみたいと思う。
⑤ 分析、調整<.b> であるので、もちろんプロジェクト優先度（規模、企業戦略など）は考慮すべきであるが、今回はシステムを使った調整例とする。
下図は、今後始める想定である計画中のプロジェクトの日程を調整してみた例である。
Oracle Primavera P6 のようなプロジェクト・ポートフォリオマネジメント機能を持ったシステムを使うと、この時期にプロジェクトが開始したら対象となる企業リソースは足りるのか、もしこのプロジェクトが開始しなかったら対象となる企業リソースの負荷はどうなるのかがシミュレーションできるようになっている。

もちろん、このようなシステムには全体的にキャパシティをもとにした企業リソースの最適化だけをするのではなく、リソース要求表（どの役割がどのプロジェクトでどのくらい要求されているか）やリソース稼働表（どの要員がどのプロジェクトにどのくらい入る予定か）の確認することも出来るので、これらを使って分析・調整することも可能だ。

さらに、スケジュール計画者が要員要求をしたあと、対象時期の稼働と役割（スキル）をもとに割当できるリソースのリスト確認と割当をすることもできる。
これによりスケジュール計画者が分析・調整をすることで企業リソースを最大限活用できるようになる。
ただし、これを行う上では企業としての割当ルールなどが必要であり、また実際には割当前に関係者との調整などが必要となってくる場合もある。

このように、プロジェクト・ポートフォリオマネジメントのシステムを活用することにより、企業リソースを最適化するプロセスが回せるようになる。 これにより企業としてのリソース稼働管理の仕組みができあがり、リソースが不足する状態や待ちになる状態が軽減され、効率的な企業としてのリソース稼働管理が実現するのである。</p/>

さて今回は企業としてのプロジェクト管理の仕組み作りとしてリソース稼働管理の話をしてきた。
グローバル化などにより世界の各企業との競争が行われるなか、企業の限りある資源をいかに効率よく活用するかが利益を確保していける1つの重要な要素となっている。
みなさんも仕組みとシステムを駆使して企業の限りある資源を有効に使ってみてはいかがであろうか。

※本文中のARES PRISMはブランド名を「Contruent Enterprise」に変更いたしました

プロジェクト責任者や現場責任者は、工程進捗・リソース負荷状況・コスト状況・生産性などを現状分析し対策を講じるために、手間と時間をかけて多種多様なレポートを受け取って情報を収集し、自分なりの整理と分析を行っている。

このような作業が、責任者の負担やレポートを作成する側の負担となっている。また情報の分析方法が責任者に依存してしまうため、企業としてもプロジェクト管理の属人化を招いている。

そこでいま注目を集めているのが、企業としてプロジェクト分析方法を考えて行くBI（ビジネス・インテリジェンス）を活用したプロジェクトKPI分析（キー・パフォーマンス・インデックス分析）である。
KPIやBIという言葉を聞くと、経営向けのイメージが強いと思われる。

しかし、最近ではプロジェクトで行われる業務の状況分析や製造現場の状況分析用にKPIを決め、BIで追跡を行いさまざまな分析・評価を行うことがトレンドになっている。

では、BIを活用したプロジェクトKPI分析の仕組み作りについて述べて行こう。

下図はプロジェクト関連と生産関連（製造業など内作が入る場合）の確認/評価/分析したい情報をまとめ、KPI分析を行う仕組みの例である。
プロジェクト管理システムの情報、設計/調達/工事に関連するシステムの情報、基幹システムからの情報、生産関連システムからの情報を集め、統合BIシステムでさまざまなKPI分析を行っている。
この例では組織側はプロジェクトサマリー分析などサマリー情報を、プロジェクト側では図書ステータスの分析や設計/調達/工事ステータス分析を、生産側ではジョブ進捗状況や工数などの分析を確認できるようになっている。またBIにより問題部分の追跡ができるようになっており、複数レポートで確認する必要がなくなっている。

では実際の統合BIシステムによるKPI分析の例を紹介していきたいと思う。
まずはプロジェクト情報分析として、以下4つの例を紹介する。

 ① プロジェクトサマリー分析
 ② 図書提出状況分析
 ③ 調達ステータス分析
 ④ 工事進捗分析

下図は「① プロジェクトサマリーKPI分析」の例である。

ここではプロジェクト全体の進捗状況、工数の予実、各WBSの状況が一目で分かる。
さらにSPI（スケジュール・パフォーマンス・インデックス）とCPI（コスト・パフォーマンス・インデックス）の低いところが色分けで分かるようになっており、ドリルダウンして追跡することにより、問題の詳細へたどりつけるようになっている。

① プロジェクトサマリー分析

下図は「② 図書提出状況分析」の例である。

ここでは各図書の提出状況として、図書分類ごとにステータスとして未提出数、未承認（提出し承認待ちになっているもの）、要再提出（コメントによる再提出が必要なもの）、承認済、それぞれ数が分かるようになっている。
これを見ると「設計図書」は14件中 9件が未完了（未承認、要再提出）であり、未承認の5件が提出済で承認待ちという状態になっているのが分かる。
さらに「計装チーム」に焦点を絞り、未承認2件をクリックすると追跡が行われ、対象となっている図書のドキュメントナンバーや名前、いつ提出したかが確認できる。

② 図書提出状況分析

下図は「③ 調達ステータス分析」の例である。

ここでは各調達品に対してRequisition（手配依頼）からDeliver on Site（現地到着）までのステータス状況を表現している。縦軸が機器/材料名、横軸がステータスイベントになっており、各機器／材料の手配状況はどうなのか、配送状況はどうなのか一目で確認できるようになっている。また予定より遅れている部分も色違いで警告される。
これによりスケジュールへの影響確認や調整への判断が迅速に行われるようになる。

③ 調達ステータス分析

下図は「④ 工事進捗分析」の例である。

ここでは工事全体をプログレスアカウントIDで明細をルールIDで表現しており、各工事（プログレスアカウントID）進捗率と工事明細（ルールID）のルールオブクレジット進捗率が分かるようになっている。下図の例では工事 PEVC-C06 をクリックし、PEVC-C06 工事明細を表示させることにより、工事明細（ルールID）V0021 と V0022 のルールオブクレジット進捗率の合計により、工事進捗率が30%になっていることが分かる。

④ 工事進捗分析

ここまで、プロジェクト情報分析の例をあげてきた。
次に生産関連システム情報分析として以下3つの例を紹介する。

 a. ジョブ消化-バーンダウン分析
 b. バッファ分析
 c. ジョブステータス分析

下図は「a. ジョブ消化-バーンダウン分析」の例である。

ここではジョブ消化計画と完了ジョブ、追加ジョブと総ジョブ状況を表現している。
赤の折れ線グラフが計画のタスク消化予定、赤の棒グラフが追加ジョブ数、青の折れ線グラフが総ジョブ数、水色の点が最新のジョブ消化予定数を表現している。
これによると追加ジョブにより総ジョブ数が増加し、予定消化スケジュールに対し、キャッチアップとしてジョブ消化スケジュールが見直されているのが分かる。
またここでは表現していないが、工数情報も取ると工数消化のバーンダウンに切り替えることも可能で、ジョブ消化状況とそれにかかる工数状況が一目で確認できる。

a. ジョブ消化-バーンダウン分析

下図は「b. バッファ分析」の例である。

ここではFOB（Free On Board）までのバッファ日数の変動が分かるようにしている。
棒グラフでバッファの日数を表し、棒グラフの頂点を線で結ぶことにより、バッファがマイナスになっていないか一目で確認できるようになっている。
これを見るとスケジュール途中でマイナスのバッファが出ており、対象時期に対するスケジュールの調整（もしくはリソースの調整）が必要となっていることが分かる。

b. バッファ分析

下図は「c. ジョブステータス分析」の例である。

ここではジョブの完了状況や予定に対する遅れを分かるようにしている。
折れ線グラフでジョブの完成予定を棒グラフでジョブの完了実績を表現している。
これを見ると初期段階で予定以上のジョブ数が完了し、途中からジョブの消化が少なくなっている。
一見前倒しているイメージに見えるが、初期のジョブ完了数が予定の倍になっていることから、追跡して倍になっている完了ジョブの確認をしていくと予定にないジョブが行われているケースもある。BIを使用しているので、追跡することで細部まで確認できるようになっている。

c. ジョブステータス分析

以上、本コラムでは企業としてのプロジェクト管理の仕組み作りのBIを活用したプロジェクトKPI分析について述べてきた。

いくつかのプロジェクトKPI分析の例をあげたが、企業やプロジェクトにより分析したいKPIは異なってくる。よってKPIを何にするか、どの情報を集めるべきか、つねに確認できる仕組みを作れるかが重要になってくる。
弊社のEPMソリューションサービスー統合BIシステム構築では、ワークショップで確認したいKPIとその必要情報がどこにあるかなどを確認していき、情報を一元化する仕組みとシステムを構築している。

企業としてKPIを決め、情報収集と可視化をする仕組みを作ることにより、企業としてのプロジェクトKPI分析の仕組みができあがるのである。

プロジェクトKPI分析は、いままで企業として仕組み作りを検討されることは少なく、プロジェクト担当者が手間と時間をかけて必要情報を必死に集め、Excel に詳しい人間に協力を得ながら独自に確認、分析を行っているケースが多かったと思う。

企業としてのプロジェクト管理の仕組みを検討・構築する企業が増えている中、その一環としてBIを活用したプロジェクトKPI分析も取り入れる企業がでてきている。

次世代の企業としてのプロジェクト管理の仕組み作りとして、みなさんもBIを活用したプロジェクトKPI分析を検討してみてはいかがであろうか。

最近よくプロジェクトを有する大手企業が米国プロジェクトマネジメント協会PMI®（Project Management Institute）のPMP®（Project Management Professional）取得社員を増やす目標を掲げているのを新聞で見たり、耳にしたりする。
PMI®ではPMの知識体系をガイドにしたPMBOK®ガイドを作成しており、このガイドや各参考書などを勉強してPMP®資格の試験の臨む人が多い。

今回はPMP®試験のベースともなるPMBOK®ガイドの「プロジェクト・タイム・マネジメント」の範囲に入る工程管理について述べていきたいと思う。

工程管理という言葉は、プロジェクト管理にはもちろん、そのほかのケースでも使用されていて、その考え方は業種やプロジェクトにより捉え方がまったく違うものになる。
たとえば、プラント建設などのエンジニアリング業や建設業では、マスタースケジュール・詳細スケジュールなどがイメージされるが、組立製造業では、大日程・中日程・小日程で管理され、工程管理手法や考え方も変わってくる。

今回はプラント建設、ビル建設など大規模プロジェクトの工程管理について説明したいと思う。たとえば海外の大規模プロジェクトの場合、発注者側からCPM（クリティカルパス計算）手法を使って、クリティカルパススケジュールを作成することが求められる。CPMはPMBOK®ガイドでも紹介されており、ネットワーク手法とも呼ばれスケジュールの作業レベルをアクティビティ（またはタスク）と呼び、アクティビティの順序設定を行うことによりスケジュールを作成する。

下図はCPMで計算を行う例である。

 ① 各アクティビティを定義し期間の設定する
 ② アクティビティの順序設定を行う
 ③ 順序に従ってアクティビティを移動する

以上によりスケジュールが作成され、アクティビティの最早開始、最早終了、最遅開始、最遅終了とフロート（余裕期間）が求められる。
たとえば [2F建設準備 20日] のアクティビティについては、[1F建設 30日] が完了するまでに完了させればよいことになるので、30日-20日=10日のフロート（余裕期間）があることになる。あわせて前からの計算で最早開始・最早終了、後ろからの計算で最遅開始、最遅終了の日程がわかるようになる。

また上図の赤字部分は、余裕期間がなく、最早と最遅日付が同じになっている。
このアクティビティをクリティカルアクティビティ、その流れをクリティカルパスと呼び、この手順でクリティカルパスを算出する方法をCPM（クリティカルパス計算）という。

海外のプラント建設やビル建設などでは、発注者側からの仕様書にCPMでクリティカルパスを明確にしたスケジュールを提出するよう求められるケースが多い。
初めて海外の建設プロジェクトに関わる方は、CPMではなく独自にスケジュールを引いて、ここがクリティカルであると表現してしまい、発注者側からきちんとCPMでクリティカルを計算するよう再提出を求められるケースが多いようである。

さて、ここまでCPMによるスケジュール作成を説明してきたが、スケジュール作成時に重要なのがリソース計画である。リソースのピークだけが高い状態であると、そこに一時的にリソースを多数投入することになるため、人の短期導入によるコスト高や作業に慣れないまま離れてしまうという生産性低下が発生する。

下図は各アクティビティに作業者というリソースを割り当て10日単位で負荷状況を表現したものになる。これをリソースの山積みという。

上図の例で確認すると山積みを行った結果、4/1～4/10にリソースのピークができており、制限も超えているため、スケジュールの見直しが必要となる。

下図では、準備②アクティビティのフロートを使い4/21～4/30へ移動させている。これによりリソース負荷のピークが崩されて制限値内に収まり、後続アクティビティの開始もそのままで安定的なリソース投入となるスケジュール計画ができている。このフロートを使った方法をリソースの山崩し（もしくは平準化・円滑化）という。
このあたりについてはPMBOK®ガイドの「資源最適化技法」で紹介している。

以上のように大規模プロジェクトの場合は、CPMや山積み、山崩しを行ってスケジュールを作成するが、これらを手動で行うのは非常に手間がかかるため、システムを使うケースが多い。

では、いままでの話をシステムを使うとどうなるか説明したいと思う。
今回はさまざまなスケジューリングに強いOracle Primavera P6を使った例をあげたいと思う。下図はOracle Primavera P6でスケジュール作成した例である。

 ① 各アクティビティを定義し期間を設定する
 ② 画面上でアクティビティ間の順序をつける
 ③ 計算ボタンを押す（順序に合わせアクティビティが移動される）

以上3つのステップで、各アクティビティの「最早開始/終了」「最遅開始/終了」「フロート」が計算され、クリティカルパスは赤で表現される。
ここまでがCPMによるスケジュール作成。このあとリソースの山積みと山崩し（平準化・円滑化）を行う。

 ④ 各アクティビティにリソース量を入力し、山積みを表示する
 ⑤ 山崩しボタンで山崩しを実行する

下図のように、このようなシステムを使うとスケジュール作成はスムーズにできるようになる。またこのようなシステムでは次にクリティカルになりそうな複数フロートパスの算出シミュレーションや山崩しの優先度など多数の機能が含まれている。

ここまで、工程計画について話をしてきた。
このあとは進捗管理と予実の話になるが、これはコラム第4回の設計進捗管理編、第5回の調達ステータス管理編、第6回の工事進捗管理編 に記載した方法で下図のとおり設計/調達/工事の進捗と生産性を測定していく仕組みを活用する。

工程管理側は上図の仕組みから収集した進捗と生産性の情報を把握・分析し、アクティビティ残期間（もしくは完了予定）を修正し、再度システムでCPM計算と山崩しを行いスケジュールを更新する。しかし、単純にマイルストンや納期を遅らせるわけにはいかない。
PMBOK®ガイドでは「スケジュール短縮」でクラッシングとファスト・トラッキングという2つの手法を紹介している。クラッシングとはリソースを増やすことによりアクティビティ残期間を縮める方法、ファスト・トラッキングとはアクティビティ順序設定を変えて並行作業させる方法である。下図はファスト・トラッキングの例である。

以上のように、工程管理ではスケジュール作成でCPM、リソース山積み・山崩しを使用し、スケジュールのコントロールでは、進捗と生産性の確認後ファスト・トラッキングやクラッシング手法を用いてスケジュールの見直しを行っていく。

今回は工程管理の手法を中心に説明したが、これはあくまでもプロジェクトでどのようにスケジューリングしていくかの話になる。
実際に企業として取り組むべきことは、プロジェクトに関わる人たちの工程管理用語や考え方の教育、システム作りによる情報共有化を行い企業としてのプロジェクト管理力を向上することである。このようなことからも国際標準的なPMの考え方としてPMI®のPMBOK®ガイドやPMP®資格が企業に注目されているのであろう。

最後に海外の大規模プロジェクト以外の工程管理にも少し触れておきたいと思う。
例えば、組立製造の量産では設備という制約が入るため、設備が重ならないスケジュールを作成しなくてはならないため、下図のようなスケジュール作成になってくる。

この他にも企業として全体プロジェクトの工程管理をしていくケース、人のスキル（専門リーダー）が中心となるプロジェクトの工程管理など、業種やプロジェクト規模、役割、管理内容により工程管理はさまざまである。
企業として業種や有するプロジェクトを考慮し、全体を見据えて工程管理の仕組みを作っていくことも必要で、これらの仕組み作りにより企業の競争力強化が実現するであろう。

※本文中のARES PRISMはブランド名を「Contruent Enterprise」に変更いたしました

企業としてのプロジェクト管理の仕組み作りとして、これまで3回にわたり、プロジェクト管理会計、設計進捗管理、
調達ステータス管理について記載してきた。
そこで今回は工事進捗管理について述べていきたいと思う。

工事の場合、まず現場状態が進み具合を左右すると言える。たとえば、現場の天候による影響や、現地の地盤状態や地形の影響などは、工事を進める上では避けて通れない問題であり、スケジュール遅れや工事数量の増加などをもたらす。

企業としては、これらをリスクと捉え、コンティンジェンシーを含めたリスク対策をとる。ただし、実際に発生したときは、スケジュール遅延の説明根拠や工事数量増加による変更承認をうけるための交渉が行われるため、現場の状況を迅速に把握し、それらの情報をしっかり管理・共有できる状態にしなければならない。

しかし、このような工事状況や進捗管理をExcelなどで個別に管理してしまうケースが多い。これでは、管理ファイルの紛失が起きたり、進捗管理が属人的になったり、情報の共有ができなかったりと、悪いケースでは工事状況を説明できずに承認を得られず泣き寝入りをすることになってしまう。

このように進捗と変更が大きくコストに影響する工事進捗管理を、企業としてどのような仕組み作りをしていけば良いだろうか？

まずは企業として考える工事進捗の計算例から明記していこう。

下図は工事進捗管理の例である。 ここでは、工事進捗を管理する単位としてプログレス（工事進捗）アカウントを用いている。このプログレスアカウントには、ルールという工事明細が管理される。
このルール（工事明細）別に「計画数量」と「重み」、「計画完了日」を設定する。そして、工事が進んだら「実績数量」を入れて「ルール・オブ・クレジット進捗率（出来高計上ルールによる工事進捗率）」を計算させる。

下図の例では、

・V0021は1.0㎥の計画数量に対し、実績数量1.0㎥以上で実績完了日もあることから作業進捗100%完了しているため、重みを考慮してルール・オブ・クレジット進捗率を計算すると以下のとおりとなる。

 計画数量1.0㎥×作業進捗1（100%）×重み0.2（20%）＝ルール・オブ・クレジット進捗率20%

・V0022は1.0㎥の計画数量に対し、実績数量0.5㎥で作業進捗50%となり、重みを考慮してルール・オブ・クレジット進捗率を計算すると、以下のとおりとなる。

 計画数量1.0㎥×作業進捗0.5（50%）×重み0.2（20%）＝ルール・オブ・クレジット進捗率10%
よって、PEVC11-06の工事進捗率は30% となる。

上記のように企業としての進捗計算の考え方を統一して管理することにより、属人的な進捗管理から企業として統一された管理方法に変わっていく。

次に工事数量が変更になったケースについて明記する。

今回は、現場で作業を行ってみると地形や地盤の影響などで、計画の数量より実際の作業する数量が多かったというケースの例を考える。

下図V0021は、計画数量が1.0㎥に対して実績数量が1.2㎥となり数量進捗は120となっている。つまり0.2㎥分追加で作業したことになる。
このように、数量が変更された情報をきちんと管理することにより契約相手との交渉材料にする。

このような重要な情報は、迅速に状況を把握・共有し、漏れのないよう管理し、前述の進捗計算と併せ、しっかり管理できるシステム作りが必要である。

最近では、工事進捗の算出・管理を行い、関係者に情報を共有しながら、迅速に現場の状況が把握できる工事進捗管理のシステムを活用する企業が多くなってきている。

では、システムイメージを含めた具体的な例をあげていこう。 今回はARES PRISMの現場管理システムを使った例をあげたいと思う。
下図は工事進捗を管理する単位としてプログレス（工事進捗）アカウントに対し、工事明細ごとに数量で進捗を測定し、工事進捗率を計算させている例である。
画面左上のプログレス（工事進捗）アカウントPEVC11-C06に対し、画面下にその工事明細となる各ルールが管理されている。

ルール（工事明細）ごとに「計画数量」「重み（加重）」「計画終了日」を入れる、工事が進んだら「実績数量（数量完了済）」をそれぞれ入れて行く。実績数量が入ると「数量進捗率」と「ルール・オブ・クレジット進捗率（出来高計上ルールによる工事進捗率） 」が計算される。そして、各ルールのルール・オブ・クレジット進捗率が加算され、PEVC11-C06の工事進捗率が算出される。

また上図のV0021では、計画数量1㎥に対し実際の作業が1.2㎥、この作業増が影響して計画終了日よりも実績終了日が10日間遅れている。このようなシステムを使うと、交渉の材料となる重要な情報が漏れずに保管され共有される。

ここまで、工事進捗の算出・管理や数量の変更についてシステムイメージを述べてきた。しかし、工事の場合もうひとつ重要なことがある。
それは現場作業の状況が、いかに迅速にかつ正確に収集できるかである。

今回紹介しているARES PRISM現場管理用のシステムでは、前述した工事進捗管理と併せて現場報告用に特化したシステムを持つ。

上図のように現場からタブレットなどで担当作業の実績を入力するとルール（工事明細）の実績として反映される仕組みになっている。これにより現場の進み具合がすぐに把握できるようになり、工事進捗が即時に計算される。
これらにより、現場作業の状況が即座に反映され、工事進捗率がいつでも確認できる仕組みができあがる。

また下図の通り、ARES PRISMでは前回、前々回 とコラムで記載してきた設計進捗管理と調達ステータス管理同様に現場管理システムもコスト管理システムとリンクする。そのため、現場管理システムで算出した進捗率は、プロジェクトとしてのコントロールアカウントの進捗率へ反映されプロジェクトの進捗率や完成予測コストを計算する。
これにより、プロジェクトの工事の現場状況報告から工事進捗率、工事のコスト関連までが企業としてわかる仕組みができあがる。

以上、本コラムでは工事進捗管理の仕組み作りについて述べてきた。

このように工事の現場状況と工事進捗率を常に共有化し、工事進捗状況や現場の変更状況などをプロジェクト管理システムに取り込むシステム作りをすることにより、企業としての工事進捗率をいつでも確認できる仕組み、また工事進捗率を考慮したプロジェクト管理会計の仕組みができあがる。

さて、4回にわたり企業としてのプロジェクト管理の仕組み作りとして、プロジェクト管理会計（コスト管理）、設計進捗管理、調達ステータス管理、工事進捗管理について記載してきた。

これらはまだ各プロジェクトでばらばらに管理されることも多いと思う。ただこのような企業としての取り組みを導入、もしくは導入に向けての準備をしているところは、非常に多くなってきているのも事実だ。

ここ数年は、弊社が受ける問い合わせもプロジェクト管理システム（またはプロジェクト管理製品）単体の問い合わせではなく、プロジェクト管理とERPなど基幹システムの連携やドキュメント管理と進捗管理の組み合わせ、プロジェクトスケジュールと調達ステータス管理の組み合わせ、企業全体のプロジェクト管理関連すべての組み合わせなど、企業システムとしての仕組みとシステムの提案依頼が多くなってきている。

みなさんも次世代プロジェクト管理の仕組みとして、企業としてのプロジェクト管理の仕組みを検討してみてはいかがであろうか。