プロジェクト・コミュニケーションのベーシック(2) ～ ドキュメント・インデックスを作る

前回の記事「プロジェクト・コミュニケーションのベーシック　～　情報のトレーサビリティを確立する」で、英語で言うCommunication Managementとは、日本語的感覚でいう「コミュニケーションの管理」ではなく、むしろ『情報伝達のマネジメント』に近い、と書いた。だから、伝達のトレーサビリティ確保が大事になる、と。

今回はその続きである。だがもう一歩進んだあり方として、「ドキュメントのインデックス化」の話をしたいと思う。ドキュメントのインデックスとは何か？　簡単だ。それはプロジェクトが作成する文書・図面類をリスト化して、多少の属性を付加したものである。「ドキュメント・リスト」と呼ばれる場合もある。

なあんだ、そんなのならいつでも作ってるよ。そういって、ドキュメントが保存されているサーバのプロジェクト・フォルダから、ファイルのリストを印字して持ってくる人がいる。ファイル名の他に、作成日、更新日、ファイルサイズ、種類などの属性が並んでいる。－－これのことでしょ？

全然違うのだ。そんなリストは、プロマネにとってどんな行動の契機も与えない。そのファイル・リストを見たら、まだ出来上がっていないドキュメントが何と何か、分かるだろうか？　どの図面が予定よりはるかに遅れて作成されたのか、問題発見の手がかりになるだろうか。誰を応援したり督促したりすべきなのかの、判断材料になるだろうか？　なるまい。

プロジェクト・マネージャーという職種は、最初に計画を立て、実行段階ではその計画からの逸脱をチェックしながら、問題をつぶしたり変更を追いかけたり、決断を下したりして、なるべくプロジェクト全体の生み出す価値を高めていくのが仕事である。だから問題発見のツールをいろいろ持っていて、そのセンサー感度を上げる仕組みが必要だし、問題解決のためには、何がいつどこで起きたのかを、正確にさかのぼってたどれる道具が必要なのだ。

ドキュメント・インデックスは、そのためのツールである。これ自体は、単純な表になっている。プロジェクトで作成しなければならないドキュメントを、すべて、重複も漏れも落ちもなく、計画段階であらかじめリストアップしておく。そして、各ドキュメントは、誰が担当で作成するのか、WBSのどのアクティビティで作成するのか、したがっていつ作成される予定なのかを、あらかじめ決めて書いておく。

つまり、ドキュメント・インデックスは、初期段階では「まだ存在していない文書の属性付きリスト」なのである。ファイル名のダンプリストじゃ役に立たないことは、おわかりだろう。それは「すでに存在している文書のリスト」を示すだけだ。あるいはもう少し高級な、いわゆるContents Management System風のリストも、役に立たない点では変わりない。そうした道具立ては、存在しているファイルの『在庫管理』には有用だろう。だが、まだ存在しない、これから作成すべきドキュメントについてのコントロールには、あまり役に立たない。

ドキュメント・インデックスというは次のような構造をしている。持つべき主な属性は、以下の通りだ：

(1) ドキュメントのID

(2) ドキュメントの名称

(3) ドキュメントのリビジョン番号

(4) プロジェクトNo.およびWBS No.

(5) 発行目的

(6) 作成者・検討者・承認者

(7) 発行予定日

(8) 発行実績日

(9) ドキュメントを構成する電子ファイルのリスト

すべてのドキュメントは、ユニークなIDを持っていなければならない。これは当たり前のことだ。従業員番号のない社員がいてはいけないのと同じである。何かをトラッキングしたりコントロールするためには、IDがいる。これは情報システムの世界では常識であろう。（それなのに、自分が仕事をする段になると、設計文書をタイトルだけで『管理』して平然としているシステム・エンジニアがいたりするのは若干、謎である）

ドキュメントにはリビジョン番号があるのは当然だが、WBSの中のどのアクティビティで作成されるものかを示すことも（当然ながら）大事である。誰が担当で、いつ出来るのかは、それによって決まる。作られたら、次にどこのアクティビティで利用されることになるのかも、注意しなければならない。かつて「仕事の最小単位－－アクティビティの構造を学ぶ」にも書いたように、文書（情報）はアクティビティのアウトプットであると共に、次のアクティビティのインプットともなるからだ。

ちなみに、わたしの勤務先では、ドキュメントのIDは、種類を示すコードと、それを作成するアクティビティのWBS No.を元にして構成している。一つのアクティビティから複数のドキュメントが作られるのが普通だから、後ろに連番をつける。かつ、それを電子ファイルの命名規約にもしている。ついでながら、仕事のプロセスを示すFunctional WBS (F-WBS)は標準的なコード体系にしたがっているため、どのプロジェクトでも、たとえばポンプの設計図書は同じF-WBS No.を持っている。だから、ドキュメント番号やファイル名称を見ただけで、「これはポンプの調達仕様書だな」と分かる仕組みになっている。

それから、インデックスには、何のために発行されるのかという目的がいる。つまり、顧客に出す承認用（For Approval）だとか、顧客からOKをもらった施工用（For Construction）だとか、あるいは据付工事後の最終納品版（As-Built）といった区別である。もちろん、顧客に気に入られないと、承認用を2回も3回も出し直し、という事態だってありえる。だからリビジョン番号と発行目的は、1対1にはならないのである。ちなみに「発行」という用語は、英語のIssueの翻訳だが、耳慣れないと思う人もいるかもしれない。これは、正式版として社内関連部署や顧客や外注先に対して配布する作業を意味している。「出図」という言い方をする企業もある。

作成者・検討者・承認者の項目は自明だろう（スペースの関係で一つにしているが、実際には別々にするのが普通だ）。

そして何よりも大事なのは、「発行予定日」と「発行実績日」である。プロジェクトの計画段階で、ドキュメント・インデックスを作る際に、個々のドキュメントの発行予定日を記入しておく。これは、プロジェクトのマスター・スケジュールに合致していなければいけない。そして、遂行段階に入って、実際にどんどんドキュメントが作成されるようになったら、それぞれの実績日を記入していくのである。

この予定日と実績日があるから、プロマネは問題を事前に検知したり、メンバーに上手に督促したりすることができるようになるのである。「今週、発行予定のドキュメントはこれとこれです。担当者はもし何か問題を抱えているようなら教えてください。支援します。」といった風に、週次のミーティングでいう訳である。

そして実際に発行されたドキュメントは、必要とする関連部署（下流側のアクティビティに関わる部門）や外部ステークホルダーに送付するとともに、プロジェクトのセンター・ファイルに保管する。情報伝達のトラッキングが必要になったら、プロマネは（あるいは、もう少し大規模なプロジェクトの場合は、専任のライブラリアン役の担当者が）、そのセンター・ファイルと、インデックスの履歴をチェックする。これがドキュメント・コントロールの仕事である。わたしが勤務先でこのようなやり方を初めて知ったときは、その見通しと効率の良さに舌を巻いたが、わたしの先輩達はどうやら何十年か前に米国の同業者達のやり方に学んだらしい。

またこうしたデータがあると、横軸に日付をとって、縦軸に発行予定ドキュメント数の累計をプロットしていけば、Ｓ字カーブが得られる。これに実績の線を書き加えれば、プロジェクト全体の遅れや進み具合が一目瞭然になる。一般に、設計作業の進捗は目に見えにくく、把握しづらい。ドキュメント・インデックスは、その進捗を可視化するためのツールになるのである。

わたしの業界では（海外の大規模プロジェクトは特に）進捗に応じて顧客が支払う契約が多い。このとき、設計の進捗を、発行されたドキュメントの数で測るのである。全体で100部の図面やドキュメントを作成する予定であり、現時点では45部が発行済みだから進捗45%、といった計算である。単純だが、分かりやすい。むろん、図面には情報量の大小があるし、ドキュメントだって厚いのも薄いのもある。だからそんな進捗計算なんかナンセンスだと、いえないことはない。だが、今日までに100部作成する予定なのに、まだ10部しか出来ていなかったら、やはり何かおかしいと判断するきっかけにはなる。測れないものは、マネジメントできない。もし設計をマネージしたいのなら、設計の進度を測る何らかの仕掛けが必要なのだ。

最後は、そのドキュメントを構成するファイルのリストである。本文はWordだが添付資料はExcelの表です、といったものはよくある。こうしたセットを、ひとつの「ドキュメント」として扱うのである。だから、個別のファイル単位にしか属性を扱えないCMSみたいなツールは、ちょっと不便だということになる。

と、ここまで読んだ読者の方は、二つの疑問を持たれるかもしれない。

Q1: 本当に最初の段階で、プロジェクトが作成すべきドキュメントを全部もれなく洗い出せるのか？　途中でどんどん増えてしまったりするのではないか。

Q2: ドキュメントの発行予定日なんて、そんな初期に決められるはずがない。

このような疑問は、プロジェクトの「初期の段階」という理解にズレがあるために生じると思われる。まさかプロジェクトの初日に、ドキュメント・インデックスを作れる訳はない。プロジェクト計画がある程度進んで、WBSが作成され、マスター・スケジュールが出来上がったタイミングでなければ、もちろん作ることはできない。それはすなわち、プロジェクトの全体像の目鼻がついた段階だ。目鼻とはつまり、成果物の構成（Product-WBS, P-WBS）がだいたい決まり、かつ、それを作るまでのプロセス手順（F-WBS）が見えて、アクティビティ・マトリクスができた時点である。

（アクティビティ・マトリクスとWBSについて知りたい方は、拙著「世界を動かすプロジェクトマネジメントの教科書　〜　グローバルなチャレンジを成功させるOSの作り方」参照のこと）

もちろん、プロジェクトの遂行途上で、インデックスにドキュメントを追加せざるを得なくなったり、あるいは削除（キャンセル）することもあり得る。追加は、当然ながらユーザの意向でスコープの増加があった場合、そして当初の見積が不足していた場合の二つがある。だから、この両者は区別できるようにしておかなければならない。そしてプロジェクトが完了したときに、自社理由で増えた分と、外部理由で増えた分が、それぞれどれだけあったかを調べ、次にドキュメント数を見積もるときには、どう教訓（Lessons Learned）を生かしたら良いかを、考える材料にするのである。こうしたことをしない限り、見積の精度など向上する訳がない。

そして、ドキュメント・インデックスを作る理由は、まさに自分たちの予測能力を高めるためにあるのだ。ドキュメント・インデックス作成というのは、プロジェクトのマスター・スケジュールなどと似ていて、プロジェクト全体を表す一種の『モデル』なのである。プロジェクトという複雑な、かつ見通しにくいシステムをモデリングする事。これこそが、プロジェクト・マネジメントの中心技術でなくて何だろう？　最終形を見通さぬまま、なりゆきでドキュメントを積み上げていっただけでは、最後に手元に残ったリストを見ても、次に生かすのは至難の業だ。経験から学ぶためには、自分が何を見通して、何を見通せなかったかを、後から追えるようなトレーサビリティが必要なのである。

＜関連エントリ＞

　→「プロジェクト・コミュニケーションのベーシック　～　情報のトレーサビリティを確立する」（2016-09-25）

　→「仕事の最小単位－－アクティビティの構造を学ぶ」（2011-01-16）