国際開発高等教育機構（FASID）の方から日本プロジェクト・マネジメント・フォーラム（JPMF）にプロジェクト管理手法の有効性について1時間半ほどの話をしてほしいと依頼があり、私がJPMF代表でここにきております。
担当者の意図は「皆様はすでにプロジェクトを手がけられておられ、プロジェクトがどういうものかご存知であります。今回も専門家からプロジェクト実施監理手法に関する研修を受けられ、知識も豊かになりますが、プロジェクトマネジメント（PM）手法が本当に役立つとは信じておられないようで、格好だけになる傾向があるようです。PM手法の適用と否適用ついての具体的な経験談も交え、その有効性について納得のゆくお話しが聞きたい」ということでした。
この問題提起はまさに的を得たものと思います。
ISO9000など品質管理システムは書類を作っているだけで、本質的な品質向上に役だっていないではないかという感じを皆さんが持っているのではないでしょうか？PM手法も同じようなものではないかと若干思っているのではないでしょうか？
「仕事をすぐはじめなければならないのに、役にもたたないバーチャートを作らされ、必要もないのにワークブレークダウン・ストラクチャー(WBS)を作らされ、やってみなければ分からないのに計画書など作っていられるか」と考えられるのではないでしょうか？
ISO9000が書類を要求するのは、品質保証の本質的要求というより、WTOで各国が合意した相互認証の仕掛けに応ずるための必要悪にすぎません。品質保証の概念は各アクティビティー毎に受け取った全段階の成果物、自ら完成させた成果物に単純ミスはないか、最終目的にそっているかをチェックしようと言っているわけです。ただ後日チェックを確実にしたという第三者のお墨付きを頂くために、証拠を書類で残さねばならないということになってしまいました。相互認証はそれぞれの国が同じ土俵で競争しようという国際ルールですのでこれはこれで守らなければなりません。
日本企業が一番、認証取得に熱心だったといわれております。ISO9000が日本で普及したのは残念ながら、多重システムの有効性を認めたからではなく、大部分の企業が、商品の本質品質で勝負できないヨーロッパの陰謀に負けてなるものかとか、もしかしたら認証が企業のブランドイメージを高めるのではと考えたことのほうが大きかったと思います。しかし、だれもソニーの製品を買うときISO9000の認証を取得している会社か気にしないでしょう。消費者は良いと思うから買うのです。
車を運転するためには運転免許証を取得しなければなりません、練習して免許を手にいれても事故を起こさない保証が得られるわけではないのと同じで、認証は国際的な無免許運転を防止しようという、ルールに過ぎないのです。
われわれは、日本式の担当者に動機付けさせて、根元から不良品の発生を断つという方法が一番優れているという確信のようなものを持っております。これを動機付け論信仰とよびましょう。日本のゼロディフェクツ（ZD）運動はそもそもデミングの統計論が日本で動機付け論に変質し、それを米国が統計論の合理性を再付加して日本に6シグマとして逆輸出したものと私は理解しております。
ISO9000の考え方は動機付けしても人はそれでも間違う、手抜きをするという現実に立ちチェックしようという、多重安全またはフールプルーフのシステム論で組み立てられております。ISO9000のルーツは1970年代の米国原子力安全ガイドライン10CFR Appendix Aにあるということです。
はからずも２週間ばかり前、JCOの臨界事故で、日本人のこの確信をぶち壊す事件がありましたが、これからもISO9000流の多重安全の有効性は納得されたと思います。
さて、皆様が書類を作るのは無駄だと考えるのはよく理解できます。かくいう私もかってジョイントベンチャーパートナーのべクテルという会社のロンドン事務所で１プロセスエンジニアとして仕事にとりかかった時、隣に座っている英国人のプロセスエンジニアがフレアシステム設計の担当者となったのですが、１週間位自分の作業のスケジュール作りだけしかしておりません。内心仕事から逃避しているのではないかと疑っていたのですが、スケジュールを仕上げてからはそのスケジュールの通り自分の仕事を仕上げてゆくのに驚いたことがあります。
PM手法は書類を作成するのが目的とは言っておりません。将来しなければならないことを事前に論理立って考えて段取りを立てろといっているのです。ただ頭のなかで漠然と考えるより書類なり電子ツールの画面上で文書の形にしたほうがロジックが明確になって、考えやすいし、記録が残るから忘れないし、仲間や協力者に伝達するにも便利ではないかと言っているのです。確かに、プロジェクトは一過性の仕事で、定常業務ではありませんので、情報システムをあらかじめ作っておいてもあまり役にたちません。それでも、モダンツールは必要に応じて利用できるところには利用したほうがいいに違いありません。
ソニーのヒット商品のVAIOを開発したプロジェクト・マネジャー氏はついにバーチャートをついに作らずじまいであったと告白されました。成功されたのだからスケジュールも適切であったということでしょう。頭の中で処理できればそれはそれでよいのです。
建設省が発表した建設産業界へのアンケート調査結果ではPMを知っていると回答した建設会社は59％、建設コンサルタントに至っては43％に過ぎないということです。
プロジェクトに対応する日本語がないことがプロジェクト概念の普及の最大阻害因子ではないかと私は考えます。該当する日本語が無かったので英語をそのまま使っております。強いて訳せば「新規展開」となりますか。一語でぴったりするものがないので複合語にせざるを得ません。
該当する日本語がないのはそのような文化が無かったからとも考えられますが、言葉がないから普及しないこともあるのだと考えたほうがよさそうです。PMの英国規格BS6079にはプロジェクトという概念は人間の歴史と共にあった古い管理手法であると書いてあります。米国のプロジェクトマネジメントインスティチュート（PMI）が編纂した教科書プロジェクトマネジメント・ボディー・オブ・ノレジ（PMBOK）ではプロジェクトとは独自の成果物またはサービスを創出するための有期活動としています。ちなみに恒常組織による定形業務遂行はオペレーションといいます。いずれも1990年代半ばに再定義された考え方であります。この定義なら人類が発生した時からあったといえます。すなわち今まで無かったことを発想し、実行するのは人類の発生と共にあった行為なわけです。すなわちオペレーョンは日常を維持し、プロジェクトは変化のためのエンジンと見てよいと思います。
この文脈からすれば、日本の文化にプロジェクトという行為が無かったわけでないことは明らかです。たとえば「普請」とか「普請奉行」という言葉がありました。ただ「新規展開」という抽象概念を定義する日本語がなかっただけです。
10年以上前、日本が一時的に米国をしのいだのは、米国が戦争に勝ち、勝ったシステムのオペレーションに安住していたときに、日本が多数のプロジェクトを立ち上げて生産設備を一新し、社会の生産性を上げたためです。そして世界の工場となりました。今度は米国が新しいプロジェクトを次々と立ち上げて情報革命を行い、情報産業を立ち上げたため、日本に勝ちました。今、日本でプロジェクトというと生産設備や「はこもの」を作ってどうするという条件反射が出るのはプロジェクトの概念が「普請」の段階にとどまっており、未だプロジェクト概念が「新規展開」という抽象化が普及していないためと考えられます。プロジェクトに「新規展開」という抽象概念が加わったのも欧米においても比較的新しく、この10年というタイムフレームの間です。その結果、米国のPMIの会員の中心はかっての設備新設プロジェクト（普請）関係者から情報産業関係者に重心が移っております。PMIの会員数が1万人から5万人近くに急成長したのはこの数年のことです。
ここらへんの日米関係は太平洋戦争初期、英国の戦艦プリンスオブウェールズが日本の航空機に撃沈されたことにショックを受けた米国が大艦巨砲主義から空母中心の機動部隊編成にシフトして日本に勝った歴史のアナロジーに似ていなくもありません。
今、日本がしなければならないのは普請ではなく、新しい産業を生むプロジェクトを立ち上げることであると言われている所以です。
皆様方が担当されるプロジェクトは私も今お役所を重要な顧客とするコンサルティング業をしていますのでよくわかるのですが、ニーズの掘り起こし、ニーズを満たすプロジェクトの発案、プロジェクトのフィージビリティースタディー、予算や実施期間を含むプロジェクトの基本計画、設計などプロジェクト・ライフサイクルの初期のフェーズでは、いずれにしてもそう大きな要員を動員する仕事ではありませんので、大げさなプロジェクト管理ツールを使う必要ではありませんし、それだけのスタッフを用意するほどの余裕もありません。しかし、小粒であっても手法は本質的には大型のプロジェクト管理と差はありません。
プロジェクト・ライフサイクルの最後のフェーズでは、プロジェクトも大型となり、プロジェクト管理に専門のプロのスタッフを使えますが、初期のフェーズまたは小型プロジェクトではプロジェクト・マネジャーが何から何まで自分でしなければならないということになります。最低限、ワープロと表計算ソフトで済ませているのではないでしょうか。少し努力すれば自分のPC上にインストールしたMS Projectなどのプロジェクトツールでマネジャーが自らネットワーク図と作成し、計画立案と進捗モニタリングもできる時代が到来しています。
私が以前、エンジニアリング企業にいたころ、契約金額1,800億円、プロジェクト要員350名、海外の建設現場の建設作業員の最大動員数5,000名というLNGプラント建設プロジェクトの実質上のプロジェクトマネジャーを勤めたことがあります。PMの予備知識も無く、いきなりアサインされ、びっくりしました。当時の私は有能な基本設計エンジニアではありましたが、PMの理論は勿論のこと、その教育も受けたこともなく、実践でたたき上げたことも、ましてPM分野に転進しようという心構えもできていなかったのです。そのような私をアサインしたのは、オンザジョブでもう１人のプロジェクト・マネジャーを育成しようとしたためです。このようなリスクを犯してもプロジェクトが成功しました。それには成功する理由が沢山あったのです。
第1に改良部分があったとはいえ、基本的にはコピープラントであったこと、第2に予算にゆとりがあったこと、第３にこの位の規模になるとエンジニアリング企業でもトップレベルの才能とプロジェクト経験を積んだ人材がスタッフとして支えてくれたからです。現在は企業の役員として全社のプロジェクト管理、設計、調達、工事部門を担当している人々です。私に残された仕事は顧客とのインターフェースと内部的調整をするだけでした。それでもプロジェクトは大洋を航行する大型客船のように進捗し、予定より速く、予算より少ない費用で完成し、完成したプラントも欠陥もなく直ちに立ちあがりました。
プロジェクト管理のスタッフは当時まだ開発されたばかりのメーンフレームコンピュータによるネットワークスケジュール技法とクリティカルパスメソド（CPM）法を駆使して詳細なスケジュールを作成してくれ、月々の進捗度と計画の対比をS字曲線で表現してくれました。目標設定を前倒しになるように変えるとしばらくは遅れがでますが、次第にキャッチアップして行く様が手に取るように見えました。コストエンジニアはプロジェクト全体の予算の作成とその消費状況、発注金額の妥当性、コンティンジェンシーの消耗度を詳しく教えてくれます。エンジニアリング・マネジャーは350名の各専門分野の技師達の指揮とパーフォーンスに目を光らせ、齟齬のないようように配慮してくれます。まさに大型客船の船長のような立場です。調達スタッフはベンダー、サブコントラクタをしっかり把握してくれました。
このように人材がそろっている大型プロジェクトは問題ないのですが、人材をふんだんに使えないプロジェクト・ライフサイクルの初期のフェーズとか小型プロジェクトではプロジェクト・マネジャー自ら全てを担当しなければならないのでPMのエッセンスを絞り込んで適用し、使うツールも簡便なものしか使えません。
最近は私が経験したような素人をオンザジョブトレーニングしてプロジェクトマネジャーに育成することが出来る条件が整ったプロジェクトなど見当たりません。
その理由は：
まずPMIのプロジェクトの定義にあるようにそもそもプロジェクトは人が集まって行う活動のうち、オペレーションが恒常業務を継続するのに対し、プロジェクトは一回限りの活動で常に新しいことにチャレンジする活動だということです。新しいことにチャレンジする活動といえばカッコいいですが、リスクだらけということです。プロジェクト管理手法はこのリスクを管理するためにあるのです。
数年前カタールのLNGプロジェクトを受注しましたが、これは完全にグラスルーツのプラントであったためとFEEDコントラクタが行った基本設計まで遡ってやり直したため、予想外のコストがかかりました。しかし、追加で受注した第３系列は第1＆２系列より遥かに少ないコストと納期で完成しました。このように新規と繰り返しにはコストに大きな差があり、新規プロジェクトに潜在するリスクがお分かりいただけたと思います。
通常プラントオーナーはEPCコントラクタの選定を入札で行うために基本設計と引き合い仕様書の作成をFEEDコントラクタにさせます。ところが、最近、FEEDコントラクタの選定すら競争入札で行うようになったため、基本設計の定義不足、品質低下が著しく、基本設計のリスクも含めEPCコントラクタの責任とされます。このため、EPCコントラクタのリスクはますます大きくなってまいりました。
歴史を持った力のあるプラントオーナーは失敗を折り込んだ詳細仕様をもっており、これに準拠することがプロジェクトの実施条件でした。しかし、最近ではコストダウンのため、詳細な自社基準を押し付けるのをさけ、日本式の要求性能のみを規定するパーフォーマンス仕様による調達法を学んで、コントラクタ、ベンダー仕様での応札を求めるよう変わってまいりました。しかし、オーナー組織の末端では従来の詳細自社仕様しか理解できず、対応できなく、混乱を生じております。これもEPCコントラクタに取ってチャンスではありますが、リスクも高まる原因となっています。
加えて欧米、韓国などの競争相手と激しいコスト競争を強いられております。予算がきついとアバウトで仕事をすることはゆるされず、スコープマネジメント、チェンジマネジメント、計画立案、WBS、スケジュール管理、海外調達、エンジニアリングの海外へのアウトソーシングのためのコミュニケーションマネジメントなどをきちっとしなければなりません。
最後にエンジニアリング企業はそのリソースの有効利用のために純粋なプロジェクト組織は巨大プロジェクト以外は採用せず、次善の策としてマトリックス組織を採用しております。マトリックスという言葉に該当する良い日本語はありませんが、強いて訳せば交差組織とでもなりましょうか。
オペレーション型の縦割り機能組織を図-1に、プロジェクト型組織を図-2に、マトリックス型組織を図-3に示しました。プロジェクト型組織もそうですが、マトリックス型組織は特にピーターの法則を回避するのに適しております。
ピーターの法則とはカナダの学者が言い出したことです。表-1のようになります。
集団にはゲマインシャフト（運命共同体）とゲゼルシャフト（目的集団）があるといわれますが、オペレーション型の縦割り機能組織は本来目的集団のはずですが、ゲマインシャフト化しやすく、プロジェクト組織は有期臨時編成組織ですからゲゼルシャフト（目的集団）を維持できるという特徴を持っております。これを図-4のBS 6079にある図の上に示してみました。
しかし、日本のように深くゲマインシャフト化した社会に欧米ですら運営のむずかしいマトリックス組織を持ち込むとどうしてもゲマインシャフトの方に大きくふれてしまいます。すなわち、限りなくオペレーション型になってしまい、機能組織の方が権限、意識の面で力が強くなりがちであります。したがって有能な人材も機能組織の方に多く、有能で（アカウンタブルな）柔軟なプロジェクトマネジャーが育ちにくいということになります。このようなわけで有能なプロジェクトスタッフやマネジャーが不足気味のため、プロジェクトが有効に運営できないということも生じてまいります。
それでもプロジェクトライフサイクルの初期のフェーズであるフロントエンド・エンジニアリング・アンド・デザイン（FEED）段階でプラントの詳細仕様がきちっと定義されていたころはプロジェクト遂行手順も類似でパターン化しておりましたので、処理できましたが、突然、フロントエンドまで取り込む型の新しいプロジェクト遂行になりました。このような時は今までのプロセスをテンプレートとして利用できないわけですからPMの基本に立ち返って計画の立案しなければなりません。しかし柔軟に対応できず、設計および工事の手戻りによるロスなどを経験しました。
このようなわけで、石油精製工場、石油化学工場、天然ガス液化などのプロセス・プラント・プロジェクト・ビジネスに携わるエンジニアリング業界にも今までやってきたことはこれで良いのかという反省が生まれました。特に新しい事態にも対応できる柔軟で有能なプロジェクト・マネジャーの育成が共通の課題でした。
エンジニアリング各社が加入している（財）エンジニアリング振興協会（ENAA）の内部で検討した結果、日本でも米国のPMIのような職業人団体が必要と判断し、JPMFを設立しました。
PM専門職としての職業人意識がまだ低い日本では、JPMFが将来一人立ち出来てプロジェクトマネンジメント協会に発展するまでの間、ENAAが保護者になろうと決めたのです。
JPMFのミッションまたは目標は米国式の広義のPM概念と手法の普及と職業人としてのアイデンティティーとステータスの確立です。従ってJPMFの個人会員はエンジニアリング振興協会メンバーの産業の枠を超えて全てのプロジェクトマネジャーおよびその予備軍に開かれています。
従来の普請奉行の分野だけでなく、情報産業、製造業、中央官庁、地方自治体まで会員の対象範囲を広げております。現在1,200名の個人会員の参加が得られております。通産省からENAA に委託されたPMIのPMP資格と同等の日本資格策定にもに協力しております。建設省は独自にPMを研究されております。米国防省のEVMSの専門家が英国、カナダ、オーストラリア、ニュージーランド各国軍に、EVMSの共同研究会を持ちましょうと声をかけたが、返事もなかった、JPMFから声をかけてくれないかと依頼されたこともあります。どこに声をかけたらよいかわからずまだ成功していません。
日本のPM資格が出来るまではデファクトスタンダードとなっているPMI資格取得も國際ビジネスでは必要と考え、受験講座や試験のホスト、3年毎の更新のためのProfessional Development Program (PDP) 活動の場の提供も行おうとしています。
最近、建設省や外務省が納税者にたいする「説明責任」を果たすためにPM手法を導入することになっています。
ここでも英語と日本語の微妙なずれによる誤解があります。
「説明責任」はアカウンタビリティーの日本語訳とされていますが、PM手法では「説明責任」という語はアカウンタビリティーの一部の意味を表しているに過ぎません。(Memo Serial No.769)
BS6079ではWBS作成についての説明の個所で「プロジェクト・マネジャーにとってアカウンタブルなタスクレベルまで分割し、ステートメント・オブ・ワーク（SOW）/タスクオーナー/タスクオーナーのコミットメント/タスクオーナーが使えるリソースが一対一に対応するようにしなければならない」と記述しています。
PMBOKでは簡単に「管理可能な成果物レベルまで分割」とあります。実行可能な業務量に分割し、それを遂行可能な人または組織に与え、それを遂行する責任と権限（オーソリティー）を付与するという意味の方が説明責任より重要であります。
念を押しますとPMBOKのヒューマンリソース管理の章でもリスポンシビリティー/アサインメント表（Responsibility / Assignment Matrix 略してRAM表）というものを作成することになっていますが、これは起用人材候補リストであり、合格レベルはアカウンタブルといわれ、それ以下のレベルは見直し必要、再教育必要、契約破棄となっています。
プロジェクトは新規に何かをすることで、全く珍奇なアイディアですが、もしかしたら社会を変えるようなうねりとなるかもしれないニーズをまめに拾い上げる仕掛けが重要となります。
ところが、新しいことはうまく行かない可能性のほうが大きい。すなわちリスクが高い。したがって新規なことをトライすることを許容するが、うまく行かないときは損失が大きくならないうちに撤退するという仕掛けが重要となります。長期にわたる社会プロジェクトの場合、環境が変わり、ニーズが消えてしまうこともあります。
プロジェクトのリスクは図-5に示されるように初期に最大で指数曲線的に減ってゆくという特性を持っております。従ってPM手法にはプロジェクトライフサイクルをいくつかのフェーズに分割し、フェーズの完成毎に評価して次ぎのフェーズに行くかどうかきめることが規定されております。この評価を行うフェーズの終了点は従って、フェーズの出口、舞台の出入り口、キル・ポイントなどという派手な名前がつけられています。
リスクが少ないときは前のフェーズが完成しないうちから次のフェーズを立ち上げることも可能です。これをファストトラックといいます。リスクがあるのにファストトラックすれば暴走です。
オペレーションになれ親しんだ集団が中心となると、このプロジェクトの途中で撤退ということを実行することが難しくなります。オペレーションになれた集団はゲマインシャフト化してしまい、変化への抵抗は大きく、個人がどうこうできるものではありません。ゲマインシャフト化した集団はバイソンとかムーの集団と同じで、暴走をはじめたら個としてこれに立ち向かうには場合によっては死を伴う行為となります。システムに仕掛けが必要となります。これが透明性とプロジェクト手法であります。
透明性は運命共同体の内部の利益とか当事者の面子を守る動機だけて事が決せられないようにする仕掛けであります。企業は株主と社会に、行政は納税者に対しその決定と行為の透明性を高めることがゲマインシャフト化を防止してくれるのです。
プロジェクトの場合はステークホルダーに対して透明性を確保することが必要となります。ステークホルダーの適切な日本語訳がないので、どこまで透明にすべきかも不明確ですが、（皆様はすでにステークホルダー分析を学んでおりますので、先刻ご承知でしょうが）利害関係者と理解すれば、企業なら、ストックホルダー（株主）、行政なら、納税者または利害を有する住民もステークホルダーに入るでしょう。
プロジェクトの透明性の確保はプロジェクトライフサイクルのフェーズ毎の判断の過程をステークホルダーに情報公開することにより達成できると思います。
このような意味で「説明責任」より、「情報公開」またはトランスパレンシーすなわち「透明性」のほうが誤解を生まないと思います。
さて多少はPM手法が欧米で発達した特殊な手法ではなく、普遍的で論理的な手法で、適用しようがしまいが、ことは必然的にPM手法が事前に手を打たないとそうなると推定したようになるということがお分かりいただけたでしょうか。それ以上に1990年中ごろに再定義された新PM概念は米国社会を変える重要な意味を持っていたということもご理解いただけたと思います。私は日本の現在の苦境も新PM概念の普及が遅れたことに一因があると睨んでいます。
プロジェクトマネジメントの教科書は幾つかあります。
1997年に発行されたISO10006は品質管理システムをプロジェクトマネジメントに適用する規格ですが、相互認証の対象になっておりませんので、ISO9000と異なり、本質論で取り組めます。ただISO10006は項目が書いてあるだけでどうしてそうなのかはわかりません。理由が書いてないのです。
PMIのPMBOK1996年版は最良のPM教科書です。しかしここにもなぜそうなのかという理由は深くは触れられておりません。
1996年に制定された英国規格BS6079はとちらかというと、普請の影を引きずっており、ステークホルダー間の契約にも触れておりますが、なぜそうなのかという理由が書いてあるため、これを読むと目を開かされるところがあります。
少し古いですが、米国防省が1991年に改定したDoD Instruction 5000.2なども国家調達プロジェクトの参考になります。略称アーンドバリュー・マネジメント・システム（EVMS）とも略称されております。
PMBOKが重要としているのは
プロジェクト・ライフサイクル
プロジェクト・マネジメント・プロセス
プロジェクト・マネジメント知識
プロジェクト・マネジメント・ツール
の4項目です。
プロジェクトと言うと、すぐプロジェクト・マネジメント知識、特にクリティカルパスメソド（CPM法）等のツールなどが思い浮かびますが、リスクをどうコントロールするかという面からプロジェクト・マネジメントを見ますと、すでにアカウンタビリティーとトランスパランシー論で述べましたようにプロジェクト・ライフサイクルを幾つかのフェーズに分け、フェーズ毎にチェックポイントを設けてプロジェクトの上のレベルの判断を仰ぎ、進路を決定するという手法が非常に重要になります。
プロジェクト・ライフサイクルのフェーズ毎に立ち上げる担当組織も必然的に単一目的機能統合時限組織となりますが、これもすでに述べましたように、大変重要なプロジェクト特有のポイントであります。
プロジェクト・ライフサイクルの各フェーズはどれも同じ5つのプロセスをたどります。
立ち上げのプロセス
計画のプロセス
遂行のプロセス
コントロールのプロセス（他のプロセスと同時並行でアダプティブ・コントロール）
終結のプロセス
です。
これを見るとすぐ皆さんは有名なPlan―Do―CheckのPDCサイクルを思い出してPM手法などつまらないと思われるのではないでしょうか？しかし別のプロセスが考えられないのも事実です。
図-6に各フェーズのプロセスの進捗度変化率を示しました。上記５プロセスのうち、プロジェクトでは立ち上げのプロセスと計画のプロセスが最も重要な活動です。
図-7はBS 7000 Design management systemsにある私の好きな図です。設計作業で確定してゆく、未来費用は指数曲線にしたがうため、初期にほとんどのコストが決まってしまいますが、実際の支出は遅れてS字曲線を描くということを表しております。プロジェクトも本質的には設計と同じですので、まず始めることが最重要ですが、次いで初期の計画が重要であるということをあらわしております。プロジェクトライフサイクルの初期フェーズでF/Sを行いto go or not to goを決定するのも同じ理由です。
FASIDが実施されているプロジェクト・サイクル・マネジメント（PCM）計画・立案研修コースが教えているPCM手法は開発援助プロジェクトの目標を明確にする作業ですので、ODAプロジェクトの初期フェーズの立ち上げのプロセスに相当すると思います。
プロジェクト・デザイン・マトリック（PDM）というツールを使用されますので、目標を達成するための活動、成果、評価基準、外部条件も検討するので目的を達成するための概略計画も含まれています。
ここで私が良く知っているプロセス・プラント・プロジェクトのライフサイクルについて少し詳しく説明してみます。
図-8がその全体像です。プラント・オーナーから見れば、プロジェクトライフサイクルは通常３つのフェーズに分けられます。
すなわち計画、基本設計、詳細設計と建設各フェーズです。
各フェーズの詳細は表-2、表-3、表-4に示しました。作業開始のチャーター文の発行が計画フェーズに2回、基本設計フェーズに１回あります。詳細設計・建設フェーズでは前のフェーズでチャーター文の発行済みですので進むのみです。
先に図-6に各フェーズのプロセスの進捗度変化率（活動密度）を示しましたが、図-9に詳細設計・建設フェーズのEPC各アクティビティーとプロジェクト全体の進捗度変化率の経時変化（山積表）を示しました。
図-10に詳細設計・建設フェーズのEPC各アクティビティーとプロジェクト全体の進捗度を示しました。（S字曲線）
表-5に山積表からS字曲線の計算法を説明してあります。どのような計算ツールを使われても結構です。進捗度の実績もS字曲線で表示されますが、これはプログレズ・ペイメントの基準に使われるため、コントラクタにとっては重要なものです。
生態系にも見られるように、プロジェクトでも、人、物、金などの資源（リソース）は無制限に得られるわけではありません。資源の制約下での活動は必然的にロジスティック・モデルに似た経過をたどるため、山形になります。
ロジスティック・モデルは1838年にベルギーの数学者 Pierre Verhulstによって考案されました。ロジスティックとは兵站と訳されるている軍隊用語で補給の意味をもっていることからこのような名がつけられたと思います。
このモデルは生物群の増殖速度は生物の数が少ない時はその固体数（N）に比例するが、その数が環境が養える最大数（K）に近づくと資源の取り合いで増殖は減速し、ついに成長はゼロになることを簡単な数式で表記したものであります。
進捗度 f= Nt /K とし、ロジスティックモデルを計算し、進捗度変化率 df/dt = r0f(1-f) を時間に対してプロットすると図-11のようなベル形になります。
上の式を積分すれば、図-12のようなS字形になります。これがロジスティック曲線といわれるものです。
同じ式の形ですが、ロジスティックモデルをオイラー差分式は下のような式となります。
ft+1=r0ft(1-ft)
1974年ロバート・メイがサイエンティフィック・アメリカンにこの式は非線型のため、0<f0<1、1<r0<4で収斂したりしなかったりする。すなわちカオス的な振る舞いをする。 1<r0<3で収斂、 3<r0<4でカオス現象を生じると発表しました。図-12に図示しました。
1941年に京都大学の昆虫学者の内田俊郎氏が豆につくマメゾウムシのように世代が重ならない昆虫が、まったく同じ現象を生ずるという研究を発表しておりますが、上のカオス的な振る舞いでよく説明ができます。プロジェクトでもタスク間のコミュニケーションが無いと同様の現象が生じます。
人がある活動をするとき、関係する人が集まってヨーイ・ドンで仕事を始めることはできません。ある人が分担する仕事は他の人の仕事の成果（成果物、デリバラブル）にたって、初めて開始できる性質があるからでです。仕事が基本的なものから次第に詳細なもの、または汎用なものから特殊なもの、あるいは下から上に時間的にまたは空間的に展開していく中で、関係する人の数が増し、ついにはピークを迎え、人はそれぞれの仕事が終われば、別の仕事に移っていって最後にゼロになるというサイクル出来あがります。このため、山形はロジスティック曲線の微分形のように左右対称ではなく、山の中心が後半にずれる非対称の山形を積分した形になります。
プロジェクトのアクティビティーの時系列上の相関関係はネットワーク・ダイアグラム（パート図、PERT）で記述できます。
ネットワーク・ダイアグラムはバーチャート（ガントチャート、Gantt Chart）でも表示できます。
ネットワーク・ダイアグラムは各アクティビティーに投入される要員の数も配分でき、集計もできるますので、資源の山積み表を作成してどのような山形になるのかネットワーク・ダイアグラムを使って見てみましょう。
ネットワーク・ダイヤグラムの表記法にはPrecedence Diagramming Method(PDM法)を採用します。PDM法はタスクの相互関係を図-13に示した、4つの表記法のみで記述する方法です。（BS-4435にも定義あり）一般の人が使う記述法はfinish-to-startの関係が最も一般的です。
PERT（Program Evaluation Review Technique）は1950年代に米海軍がポラリス・ミサイル開発時にロッキード社が開発した手法であるが、現在はパート図はただネットワーク・ダイヤグラムのことをいいます。
CPM (Critical Path Method) は1950年代にデュポン社とレミントンランド社が開発した各タスクの期間と相互依存関係から全体の期間とそれを支配するシリーズに連なる一連のタスクの経路を探し出す数学的計算手法です。
ネットワーク・ダイヤグラムの使用法の注意としては
(1)スコープを分割してタスクを定義する（WBSを作成する）
(2)タスクを達成するリソースと時間は途中変化のない一対一の関係にあるとの前提があるため、 WBSを機能組織毎のタスクに分けるだけでは不充分
(3)タスクとタスクをオーバーラップ（リード）させることも遅らせる（ラグ）こともできるが、計画のためには役にはたたず、プレゼンテーションに使えるだけである。（タスク数数十のレベルー１）
(4)計画に役立つ使い方は機能組織の資材関係の多量のデータ処理を要するタスクを更にプラント・エリア毎等のロットに分割し、ロット毎にリソースの動員をし、ロット完成毎に完成する成果物を下流の機能組織にリレーするということを表記しなければならない。このロットを処理する時間、リソースはその担当者がアカウンタブルなものでなければならない（タスク数数百のレベルー2または3 ）
(5)レベルー2または3にして初めてCPMを駆使したケーススタディーが可能となる
(6)同様の過去のプロジェクトで作成したダイヤグラムをテンプレートとして再利用可能である
(7)結果は各成果物の完成時期を一覧表にして、各機能組織の担当者と確認する
(8)CPMを駆使しても目標とされる期日に完成させることが出来ないことにほうが多い。このときは前タスクの成果物完成前に仮定に基付いて次段階のタスクを開始させなければならない。後で仮定を修正しないで済むように、コストを犠牲にして仮定を設定することが重要となる（カオスの防止）
であります。
リード表現のあるプレンゼン用のレベルー１で建設工事のバー・チャートによる表示を図-15に示しました。各タスクに表示した数値は動員するリソース（作業員の数）の量です。これを集計すると図-16のような形の山形がえられます。
工事は逐次作業が避けられないこと、基礎工事から鉄架構工事、配管工事、電気・計装工事と次第に人の投入量が増す性質を持っているため、ロジスティック曲線の微分形のように対称ではなく、山の中心が後半にずれる非対称の山形になります。
長年プロジェクトに関係してきて忘れられない言葉を箇条書きにしてみました。説明の必要もないでしょう。
「ツルの一声」
「プロセス屋の一声１億円、機械の一声1,000万円、土木屋の一声100万円」
「プロジェクトとは段取りだ」
「プロジェクトマネジャーは自分で仕事を抱えてはいけない、全て他人に押し付けろ」
「根まわし」
「MBWA, Management by Walking Around」
「時間は金で買え」
「見きり発車」
「フリージング」
「JITコンストラクション」
「現場の声は神の声と聞け」
「人海戦術」
「打ち上げ」
以上まとめますと下記のようになります。
以上