企業としてのプロジェクト管理の仕組み作りとして、これまで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など基幹システムの連携やドキュメント管理と進捗管理の組み合わせ、プロジェクトスケジュールと調達ステータス管理の組み合わせ、企業全体のプロジェクト管理関連すべての組み合わせなど、企業システムとしての仕組みとシステムの提案依頼が多くなってきている。

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

プロジェクトから調達へ機器の手配依頼（REQ-Requisition）をしたのに、予定日になっても機器が現地に届いていない？ そもそも手配されているのか？

みなさんはプロジェクトで機器の手配ステータスが分からずに、こんな心配をしたことがないだろうか。 プロジェクトとしては、「いつ設置や工事ができるのか」手配の状況はかなり気になるところである。

本コラムでは、このような課題にどう対応するか、企業としての調達ステータス管理の仕組み作りについて話をしたいと思う。

調達のステータス管理は、以下の3つがある。

 ① 注文書（PO）を発行するまでのステータス管理
 ② 注文書（PO）を発行した後の出荷のステータス管理
 ③ 注文書（PO）を発行した後の支払のステータス管理

プロジェクトでは、これらのステータスを常に把握することが難しく、実態としては担当者が調達部隊へExcelのリストを持ちながら、手配状況をつど確認するケースが多い。

では、これら3つのステータス管理に対してどのような仕組み作りをしていくのが良いか、まずは調達業務の流れを元に考えていこう。
下図は注文書発行までと注文書発行後の調達業務について流れを表したものである。

注文書発行までの業務では、設計側からREQ（手配依頼）が出されると、調達では依頼内容を確認し、RFQ（見積依頼）と入札（BID）が行われ、ベンダー決定後に注文書（PO）を発行する。そして、ここまでの注文書ステータスを管理する。
注文書発行の後は出荷（Shipment）業務と請求・支払（Invoice）業務に分かれる。
出荷業務では、Line Item（購入品アイテム）ごとに出荷ステータスを管理し、請求・支払業務では支払ステータスを管理する。

上図のように調達業務の中では、ステータスとともにコストの計上が発生する。

注文書発行により確定コストが計上し、支払により実績コストが計上される。この確定コストがコスト管理のポイントの１つとなっている。

プロジェクトの期間が長く、また手配する機器や材料の金額が大きいプロジェクトでは、支払業務が完了するまでコスト計上がされないと、コスト実績値が後になってから一気に上がることになり、スケジュール／リソースの調整が迅速にできなくなる。

よって、このようなプロジェクトでは支払金額が確定する注文書発行タイミングで確定コストを計上するのである。もちろん、支払業務完了時の金額は実績コストとして計上する。

以上のように注文書発行前、発行後における3つのステータス管理をプロジェクトと調達の双方が、常に確認できるよう可視化し、確定コスト（Commitment）と実績コスト（Actual）をコスト管理へ計上できる仕組みやシステムを作ることにより、「いつ設置や工事が行えるか」「実際にプロジェクトでかかっている調達コストはいくらか」が分かるようになる。

では、システムイメージを含めた具体的な例をあげていこう。 今回はARES PRISMの調達管理システムを使った例をあげたいと思う。

まずは注文書発行までの注文書ステータス管理から説明しよう。
下図はARES PRISM調達管理システムで注文書ID:PEVP11-PO-000001に対し、ステータスがどこまで進んでいるかを確認している例になる。

あらかじめ企業としての注文書ステータス測定用にイベントを用意しておき、いつでも注文書の状況が分かるようになっている。この例では、入札が完了して2/28に注文書（PO）完了予定であることが分かる。
もちろん、このようなシステムでは、REQ（手配依頼書）作成・確認、対象ベンダー選定など業務面の機能も備えている。

次に注文書発行後の出荷ステータス管理を説明しよう。 下図はARES PRISM調達管理システムで出荷ID:PEVP11-PO-000005-S01に対し、ステータスがどこまで進んでいるかを確認している例になる。

あらかじめ企業としての出荷ステータス測定用にイベントを用意しておき、いつでも出荷の状況が分かるようになっている。この例では、手配した機器や材料が輸送中で6/6に現地に到着する予定であることが分かる。
これにより手配を依頼した機器や材料の調達状況が分かり、「いつ設置や工事が行えるか」が計画できるようになるのである。同様に支払ステータス管理や請求・支払業務もできるようになっている。

さて、ここまで調達に関わるステータス管理の話をしてきた。 ここからは注文書発行や支払の完了時に計上される調達コストとプロジェクトコスト関連を説明していこう。

以前のコラムでも記載したが、ARES PRISMのコスト管理システムでは
コントロールアカウント（プロジェクトのコスト管理単位）で
予算（Budget）、変更予算（Change）、実績（Actual）、
確定（Commitment）、完成時予測（EAC）を管理する。
管理項目にある通り、ポイントの１つである確定（Commitment）も管理対象である。

たとえば、プロジェクト期間が長く、また手配する機器の金額が大きい場合、その金額はプロジェクトのコスト管理に大きな影響を与える。
そのためプロジェクトでは、支払完了ではなく金額が確定する発注段階でコスト計上したくなる。
ARES PRISMでは、注文書が発行され確定（Commitment）項目にコストが計上され、支払が完了すると実績（Actual）項目にコスト計上される。

また、ARES PRISMでは調達管理システムでとコスト管理システムがリンクしているため、注文確定時の発注金額と支払完了時の支払金額が、それぞれプロジェクトのコスト管理単位であるコントロールアカウントに対する確定（Commitment）と実績（Actual）に計上される。
これにより常に「プロジェクトで現在発注した額はいくらか、支払まで完了した額はいくらか」が分かるようになるのである。

以上、本コラムでは調達ステータス管理の仕組み作りについて述べてきた。

このように調達ステータスを共有化し、また発注・支払コストをプロジェクト管理システムに取り込むシステム作りをすることにより、企業としての調達ステータスをいつでも確認できる仕組み、また調達ステータスを考慮したプロジェクト管理会計の仕組みができあがる。

これによりプロジェクトマネージャ、プロジェクト関係者、組織長などのマネジメントはいつでもプロジェクトステータスとコスト状況を分析し、常に必要な対策を取れるようになるのである。

近年の通信やシステムの驚異的な進化により、調達業務のグローバル化や調達業務の効率化を考える企業が増えてきている。
企業として調達ステータスを可視化できる状態にし、遠隔地からでもプロジェクト担当者が確認できる仕組みができあがると、信憑性が高く迅速が対応が取れるようになる。

そうすれば、Excelのリストを持って調達部隊に確認しに行き、タイミング悪く古い情報を得てしまうようなことはなくなるに違いない。

みなさんは、設計業務の進捗管理をどのように計っているだろうか。

進捗基準を明確にせず、属人的で根拠がわからないまま90%完了したと連絡を受けてないだろうか。
よくある話であるが、90%終わっているはずなのに数週間経っても完了報告がなく、本当に終わるのかと心配になったことはないだろうか。

今回は、属人的にならない設計進捗管理の仕組みについて話をしていきたいと思う。

設計業務と言えば設計図書などのドキュメント作成が中心であるが、最近ではドキュメントの進捗基準にいくつかのパターンを用意し、ドキュメントのステータスを管理する企業が増えてきている。
ただし、ドキュメント管理のステータスをもとに、設計業務全体の進捗がわかるような仕組みを整えているところは少ないのではないだろうか。

では、どのような仕組みで設計図書（ドキュメント）の進捗と設計業務を管理していくか。
各社いろいろと設計業務の進捗管理単位はあると思うが、今回は設計進捗の管理単位を考えるエンジニアリングアカウントを使った管理例を紹介しよう。

設計図書の数が多い場合、設計図書１枚ずつを設計業務の進捗管理単位とすることは難しい。エンジニアリングアカウントは複数の設計図書をまとめた成果物の単位で管理する考え方である。
下図は一例であるがエンジニアリングアカウント（設計成果物ベースの管理単位）の進捗が算出される流れを明記している。

 ① エンジニアリングアカウントを定義する（対象設計図書など）
 ② 設計図書の進捗マイルストンを定義する
 ③ 設計図書提出に合わせて進捗計算する

下図の例では設計図書Aを5/11提出により、設計図書Aの進捗が50%となり、見積時間（重み）により成果物の進捗であるエンジニアリングアカウントは15%となる。
プロジェクトの各エンジニアリングアカウントを集約するとプロジェクトの設計進捗が計算される。
この仕組みをシステム構築し自動化することにより、企業としてプロジェクトの設計進捗を即時に捉えることが可能になる。

では、システムイメージを含めた具体的な例をあげていこう。
今回はARES PRISMの設計管理システムと、コレポン管理Aconexを使った例をあげたいと思う。

下図はAconexで [PEVE3#-PFD-000001] を含む設計図書を送付状を付けて送付し、提出日を設計図書の進捗マイルストンに反映させた例である。
これにより [PEVE3#-PFD-000001] の進捗率が50%となる。同じエンジニアリングアカウントに属する設計図書の進捗率もあわせエンジニアリングアカウントの進捗率が算出される。

それぞれのエンジニアリングアカウントで進捗率が算出されたら、関係するコントロールアカウントに反映されコントロールアカウントごとの進捗率が算出される。
つまり、それぞれの設計業務の進捗が、プロジェクト業務の進捗に反映されるのである。

そして、下図のようにコントロールアカウントの進捗率が見えると、「どこまでの進捗で、コストがいくらかかっているか」が分かるようになる。また、進捗率を踏まえた完成時予測も算出されるため、コントロールアカウントの進捗率、予算、実績、完成時予測がすべて自動で見えるようになる。
この仕組みをシステム構築し自動化することにより、企業としてプロジェクトの設計進捗をベースとしたコスト予測を即時に捉えることが可能になるのである。

もう一つ具体的な例として、前回のプロジェクト管理会計編でも登場したARES PRISMのコスト管理システムを使った例をあげたいと思う。 さきほどARES PRISM設計管理システムで算出した進捗率は、コスト管理システムに画面を切り替えると、コントロールアカウントの進捗率へ反映され表示されている状態になる。また、コントロールアカウントの進捗率をもとに完成予測が計算される。
（計算方法については、CPIを反映／SPIとCPIを反映など選択可、またこれらを参考値として直接入力する方法もある）

これらにより、統一した基準で設計進捗は管理されるようになり、どこまで進んでいくらかかっている（また、いくらかかりそう）が分かるようになる。
さらに、システムのレポート出力により、進捗率カーブやコストカーブも確認できるようになるのである。

エンジニアリング・進捗レポート例

エンジニアリング・コストレポート例

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

このように企業として進捗基準を統一し、設計進捗をプロジェクト管理システムに取り込むシステム作りをすることにより、企業としての設計進捗だけでなく、進捗を考慮したプロジェクト管理会計の仕組みができあがる。
これによりプロジェクトマネージャ、プロジェクト関係者、組織長などのマネジメントは　いつでも統一した基準で設計進捗を確認でき、プロジェクトの進み具合とコストを分析し、常に必要な対策をとれるようになるのである。

通信のめざましい発達により、いつどこでも必要な情報が取得できる現在、情報がいかに正しく伝わっているかが　ポイントとなっている。
プロジェクトにおける設計進捗を基準なく管理してしまうと、同じような設計図書で同じ進み具合であっても人によっては、90%であったり、30%であったりする。そうならないためにも、企業で進捗基準を作りシステム化する必要があるだろう。

90%から何週間も進まないような、属人的な報告はなくしたいものである。

今回はプロジェクト管理会計の仕組み作りについて述べていきたい。

さて、プロジェクト管理会計の仕組みとは何か？
通常、企業では基幹の会計システムで財務会計と管理会計を行っている。
財務会計は財務諸表を作成して外部関係者へ開示するのに対し、管理会計は企業活動を円滑に進めるための主に社内で使われるものとなり、組織の事業計画などの判断材料となる。企業ではこの管理会計を行うために、プロジェクトのコスト状況を集める必要がある。

しかし、プロジェクトで管理しているコストはそれぞれのプロジェクトがExcelなどで独自の切り口になっていることが多いため、企業の管理会計に反映するにはプロジェクトからの報告に対する集計時間がとてもかかる。

プロジェクトで管理しているコストや実際にかかっているコストについては、本社側もプロジェクト側もできるだけ早く見たいものである。

そこでプロジェクトのコスト管理と基幹システムの管理会計をつなげ、プロジェクトコストと基幹の実績コストがリアルタイムに把握できるようにするプロジェクト管理会計の仕組みを考える企業が増えてきている。

ではプロジェクト管理会計の仕組みの作り方について述べて行こう。
プロジェクト管理会計の仕組みは以下2つのアクションで作る。

 1．（コスト管理用共通フレーム）コントロールアカウントの作成
 2．システム構築

まず「1. コントロールアカウントの作成」であるが、これは重要かつとても難しい。
下図はコントロールアカウント作成イメージであるが、企業組織が見たいコスト管理体系とプロジェクトが見たいコスト管理体系があり、それぞれ見たいものが異なる。
これをいかにすり合わせてコントロールアカウントを作成できるかが、この仕組みを作るうえでの肝となる。

ではコントロールアカウントを実際にどのように作成していくのか。

弊社ではプロジェクト管理会計の仕組みを作る支援サービス（EPMソリューションサービス）で、コントロールアカウント検討のワークショップを開催している。具体的には、組織長、プロジェクトマネージャ、会計担当、システム担当など関係者を集め、それぞれ現状のコスト管理方法を確認し、管理ポイントをすり合わせていく。

もちろん自社内だけですり合わせていくことも可能であるが、外部の人間を入れ、外部の情報を参考にすると判断材料が増え、検討がスムーズにいく。

弊社の場合はエンジニアリング企業グループとしての海外プラントプロジェクトの実績、システム構築に関わった製造業プロジェクトの実績などから、エンジニアリング業や製造業から声をかけていただくことが多い。

なお弊社では検討プロセスの方法として、お客様と打ち合わせた後に、お客様内でも話し合ってもらい、こちらでは次の提案を用意し、その後、両者で打ち合わせる形式をとっている。

このように社内関係者と外部からの参考となる情報を組み合わせ、コントロール・アカウントを作り上げていくことをお勧めする。

コントロールアカウントが決定したら、下図のとおりプロジェクトにコントロールアカウントを設定し、予算、実績、確定、完成時予測コストとスケジュール、進捗率を入れて管理する。完成時予測コストは予算と進捗率などから算出することもできる。
なお、実績や確定コストなど実績値は企業で管理している情報を、予算や完成時予測など計画値や今後予測値はプロジェクト側で管理している情報を取り込み、これらの管理情報を可視化・共有化すると、プロジェクトはいつでも正しい実績値を確認することができ、企業側はプロジェクトの完成時予測が把握でき組織としても今後見込みが分かるようになる。
これにより企業としてのコスト管理であるプロジェクト管理会計の仕組みの考え方ができあがる。

さて、コントロールアカウントを作成し、プロジェクト管理会計の仕組みの考え方でできあがったら、次に「2. システム構築」に入る。
下図はプロジェクト管理会計に必要な、コスト管理情報、進捗情報の流れをまとめたものである。
企業が有するシステムを大きく「プロジェクト管理システム」「基幹システム」「設計/調達/工事システム」「組織マネジメントシステム」の4層に分けて表記している。
各層において、この情報の流れをスムーズにすることにより、プロジェクト管理会計の仕組みができあがる。

システム構築では以下の2つを行う。

 ① プロジェクト管理システムの構築

 ② システムの連携とレポート構築

まずは、「① プロジェクト管理システムの構築」から説明していこう。
私たちの場合、プロジェクト管理システムは海外でも利用できるアプリケーションの導入を提案している。

以前私が関わったシステム構築では、
・「工程管理／リソース管理」システムにOracle社のPrimavera P6
・「コスト管理」システムにARES社のPRISM
を導入した。

この2つのアプリケーションを組み合わせることによりプロジェクトのスケジュール／リソース／コストすべてを関連づけることができる。

導入後は以下の流れができあがる。

  a.「Oracle Primavera P6」でWBSの工程に合わせたローディング計画を作成する（下図イメージ）。

  b. ローディング計画を人件費予算として「ARES PRISM」へもっていき、
    「ARES PRISM」で人件費以外の予算を入力する。

これで、各コントロールアカウントのコスト計画（予算）が作成される。

ここで、コスト管理アプリケーションの「ARES PRISM」について説明しておこう。
下図はARES PRISMのコスト管理システムの画面である。
あらかじめ予算、変更予算、実績、確定、完成時予測などの箱が用意されてあり、コントロールアカウントを登録し、それらに明細を入れて行くと集計値が各箱に計算されるようになっている。
標準で「Oracle Primavera P6」との連携機能があるため、WBSやアクティビティコードの要素を反映させてコントロールアカウントが登録されたり、Excelなどのインターフェイスもあるので登録に手間はかからない。
また、多通貨対応があり外貨レートを持たせて換算をさせることもできるので、海外の調達コストなども現地通貨で使えるところも特長である。

このようにアプリケーションを導入することにより、システム構築時間とコストを大幅に削減できる。またアプリケーションを標準化することで関係者は専門性の高い共通言語で話をするようになり、企業のコミュニケーション力も向上する。

「① プロジェクト管理システムの構築」が完了すると「② システムの連携とレポート構築」に入る。
ここまでのプロジェクト管理システムの構築により、プロジェクトのリソースローディングや日程を考慮したコントロールアカウントのコスト計画ができるようになった。
これに基幹システムや既存システムとの連携を行うことにより、以下の流れができあがる。

  c. 基幹システムから、実績工数、実績コストを「ARES PRISM」にもっていき、
     コントロール・アカウントの実績値に反映させる。

  d. 既存システムからステータス状況をとり、コントロールアカウントに進捗率を反映させ、
    「ARES PRISM」上で完成予測コストを計算する。

これによりリアルタイムにコスト実績と完成予測コストが可視化され、プロジェクト管理会計が実現する。
システム連携により、プロジェクト管理会計が実現したら、組織長向けプロジェクトサマリーレポートを構築する。
私たちの場合はBIアプリケーションを活用し、組織長にKPIを確認し下図のようにコンパクトにまとめ、組織長がKPI分析できる画面を作成している。

このように組織長向けプロジェクトサマリーレポートが完成し、KPI分析が可能になることにより、プロジェクト管理会計の仕組みが整い、企業全体でプロジェクトコストの可視化が実現される。

以上、本コラムではプロジェクト管理会計の仕組み作りについて述べてきた。

プロジェクト管理会計はシステム作りもそうであるが、コストの共通フレームであるコントロールアカウントをいかに作っていくかが最大のポイントとなる。
弊社でもEPMソリューションサービスでプロジェクト管理会計の仕組み作りの支援業務を行っているが、やはりコントロールアカウント検討には力を入れており、関係者から情報を集め、繰り返し打ち合わせを行い精度を上げていく。

コントロールアカウントをしっかり決め、システムを作ることにより、全世界のプロジェクトコストをリアルタイムに確認できるようになるのである。

現在の情報化社会では情報伝達のスピードと情報の正確性が、企業の判断を左右する。
以前のようなプロジェクトに管理を任せている時代は過ぎ去り、企業としての管理の仕組みやシステムをどう考えるかという時代に変化してきている。

今回のプロジェクト管理会計の仕組みのように、企業としてプロジェクト管理の仕組みをきちんと考えていくことにより、企業の競争力が強化されていくであろう。

国内プロジェクトでは、よく口頭で「～お願いします」で作業が進んでしまう。

それで問題になったときに言った言わないのやりとりがよく始まり、結果として発注側／請負側で「まあこの件は後に・・・」となることがある。
私も国内プロジェクトではよく口頭で話をしてしまった経験がある。

しかし、契約社会の海外ではそうはいかない。きちっと文書で責められるし、
口頭で「それ言った」と言っても通用しない。そうすると、責められた方は急いで血眼になって議事録や履歴を探し始める。

このようなプロジェクト関係者とのやりとりを海外ではコレスポンデンス管理、略してコレポン管理という。
このコレポン管理、まだパソコンが普及していなかったころは、たくさんのキングファイルにコレポン履歴を入れ、部屋を倉庫にして保管し、すぐに必要な書類が取り出せるように専任者をつけてコレポンを管理していたところが多い。

パソコンが普及するようになってからは、各社とも情報システム化が進んでいく。これにあわせて、プロジェクト側から社内の情報システム部門にこういうシステムが欲しいと要望するようになり、コレポン管理についても要望を出すプロジェクトが増えていった。

しかし、よくありがちなのがコレポン管理のシステム化について社内情報システム部門に話をすると通常のドキュメント管理システムの話になってしまうというケースだ。これは、プロジェクト側ではコレポンを関係各社と行うが、情報システム部門ではコレポン管理をする機会がほとんどないからだ。

しかし、コレポン管理システムとドキュメント管理システムはまったく違うものである。

ドキュメント管理システムによりドキュメントの一元管理やバージョン管理はできるようになる。また、ワークフローもつければ、どのドキュメントがどこで止まっているかは分かる。

しかし、成果物として発注者側へ提出した図面などのドキュメントに対し、いつのやりとりでどのようなコメントが入っていたかまで探すことは困難だ。

これでは、発注者側で「そんなことは言っていない」という言葉に「○月×日の成果物○○バージョンのコメントでこのように言っていた」と証明することができない。メールの履歴を探すなどに時間をかけても、見つからないこともある。

このような話は海外プロジェクト担当のお客様や社内の海外プロジェクト担当からよく聞いていた。

プロジェクトの現場で欲しいのは、下図のように成果物送付に対するやりとりの中で、発注者側でどの成果物にいつ、どのようなコメントがあったか証明できるようなシステムである。ドキュメントのバージョンやワークフローではなく、どこかに書かれているコメントを探したいのである。

では、プロジェクトの現場で、一般的に使用されているコレポン管理システムはどのようなものか。コレポン管理システムでは、やりとり記録を保存・管理、必要なときに検索・参照できるようになっている。また、管理番号の自動採番、やりとりの自動タグ付けなどもコレポン管理システムのポイントである。

下の画面はコレポン管理システムの画面であるが、プロジェクト関係者間専用にメールやドキュメント（主な記録対象は以下に明記）が管理されており、文書中にあるコメントまで検索できるようになっている。これにより言った言わないのやりとりが無くなるのである。

近年はインターネットの普及やグローバル化、JV（ジョイントベンチャー）プロジェクトの増加などにより、プロジェクト間のコレポンも今までより更に多くの関係者へ迅速かつ正確に、また役割ごとに強固にセキュリティを守ることが求められている。

これらのことから、インターネットで使用でき、プロジェクト期間だけプロジェクトメンバー間のみで使用できるよう、コレポン管理もクラウドのシステムを使うプロジェクトが増えてきている。
多くの企業が集まってプロジェクトを進める中、自社のシステムを他社に使わせず、必要な期間だけ使用できる手軽さ、導入のしやすさなどが人気の理由のようだ。もちろんシステム提供側もセキュリティには万全を期しているようである。

以上、本コラムではコレポン管理について述べてきたが、ITの普及によりプロジェクトもプロジェクト業務の管理方法も複雑化し、システムもどんどん進化してきている。
次世代プロジェクトのコレポン管理に向け、コレポン管理の仕組みをしっかり設計し、必要なシステムを検討・導入し、そしてきちんと運用することにより、大きな情報の波を乗りこなせる強いプロジェクト、企業に成長していくだろう。