contents

contents / home

IMGプロジェクトの時に、平成7年度から9年度の三年間、三菱総研に委託して、プロジェクト実施に際しての外注作業の推進手法、作業にともなう文書の管理手法、およびプロジェクト評価について調査した。

藤田昌大(三菱総研)､小林博和､近藤靖(三菱総研)､大規模研究開発のプロジェクトマネージメント､三菱総合研究所報告､1997年9月.
小林博和、藤田昌大、衛星搭載温室効果気体センサ開発におけるプロジェクトマネジメント、研究・技術計画学会第１３回年次学術大会一般講演、1998年10月25日.

このページは、それらの結果を取り纏めてみたものだ。今、読み返すと、十年前に調査したものなので、技術的には古くなってしまったものもあるが、考え方はまだまだ新鮮だ。色々なプロジェクトを進める上のハウトゥー集として参考にして頂ければ嬉しい。

doc
■■■ 1 プロジェクト・マネジメントとは

プロジェクトとは一般に「特定の目的・目標・ねらいを持って、特定の実施課題を解決するために、特定のメンバーによって期限付きで行う一度きりの活動」と定義される。世の中のプロジェクトの例を以下に挙げると

このようにプロジェクトの種類は国家的な規模で行われるものから、個人的なものまで千差万別であるが、全てに共通しているのは「ある制約のもとで、特定のねらいをもって行う」ということである。さらに注意しなければならないのはプロジェクトが基本的に一度きりの活動であることである。したがって、たとえ多数の人間が参加するものであっても日常的に繰り返される活動、たとえば通勤やラジオ体操などはプロジェクトとは呼ばない。この「一度きりの活動」だということが、プロジェクトを成功させるのが容易でない原因である。すなわち過去の経験がそのまま役立つわけではなく、常に初めての状況を考慮せねばならないからである。

top
■■■ 1-1 何をマネジメントするのか？

プロジェクトには必ず目標が存在し、それを達成しなければプロジェクトは成功したとは言えない。同時にプロジェクトを行うためにはいろいろな「資源」が必要であり、それらには様々な条件が付いているのが普通である。それは

したがって、プロジェクトに対する制約を大きく３つに分類すると

となる。つまりプロジェクトの成功とは「ある期日までに、決められたコスト以下を使って、一定以上の品質のものを完成させること」である。そして「プロジェクト・マネジメント」とは上で述べた「プロジェクトに必要な資源のマネジメント」に他ならない。

なおここでは文献[8]にしたがって、「プロジェクト管理」という言葉の代わりに「プロジェクト・マネジメント」という言葉を用いる。一般には「管理」と「マネジメント」を同義としていることが多いが、「管理」の英語訳は"administration"であり、"management"ではない。上で述べたプロジェクトを成功させるための資源のやりくりは英語の意味では"management"を指し、「規制・制限」を連想させる"administration"すなわち「管理」とは、全く別のものなのである。( ちなみに文献［8］の著者によれば、日本で「プロジェクト管理」の手法が発達しなかった理由の 一つは"managiment"が「管理」と訳されてきたためであるという。実務レベルの人たちに“一方的に上から抑え込まれるのではないか”といった感覚を生じさせる「管理」という言葉が、日本人全般にネガティブなイメージを与えているというのは事実かも知れない)

一般に大規模なプロジェクトが行われるときには、プロジェクト・メンバーを体制化することによってメンバーの役割分担や命令系統を明確にし、プロジェクトの円滑な進行をめざす。プロジェクト・マネジメントにおいて最も重要な役割を果たすのは、当然プロジェクトの最高責任者であるプロジェクト・マネージャーであり、プロジェクト全体の能力を最大限に機能させることが要求される。プロジェクト・マネージャーに必要とされる資質は一般に

と言われている。つまるところ、プロジェクトに必要な資源のマネジメントを行うのがプロジェクト・マネージャーの役割であり、成功を通して各メンバーに達成感と成功感を持たせることが使命である。

top
■■■ 1-2 プロジェクト・マネジメントの実際

第二次世界大戦後、米国においてPERT（Program Evaluation and Review Technique）やCPM（Critical Path Method）などの科学的プロジェクト・マネジメント手法が開発されてきた。これらの手法は当初は工程管理のために開発されたが、その後PERTは人や物、コストの管理も行えるように拡張されており、PERT/TIME、PERT/MAN-POWER、PERT/COSTなどと命名されている。またCPMはプロジェクトを納期通りに終了させ、かつ最小コストになる最適スケジュールを求める手法である。

この種のネットワーク系マネジメント手法の利点は、他の作業との相互作用を考慮でき、作業の繰り返しが可能であることである。たとえば最近のシステム開発において主流となっているトップダウン開発において必要となる部分的修正の繰り返し作業にも、これらのマネジメント手法は対応できる。

上述のようなマネジメント手法を利用するためには全体の作業を細分化することが必要であるが、全作業を上位から階層的に分析し、アクティビティの集合として構造化する手法をWBS （Work Breakdown Structure）という。それぞれのアクティビティに対してはPDCAデミング・サイクルが適用される。すなわち、PLAN（計画）→DO（実施）→CHECK（判断）→ACTION（対策）を１回のサイクルとして、これを繰り返すことによってアクティビティを処理していく。このような、プロジェクトの開発作業で確実にPDCAサイクルを回すという基本的な考え方のことを、PPP（Phased Project Planning）という。

以上の手法によってプロジェクトにおける全作業の流れが明らかになるが、誰がその作業を行うかを決めるために、OBS （Organization Breakdown Structure）が用いられる。これをWBSとマトリックス状に組み合わせることによって作業の役割分担と責任を明らかにすることができるが、この手法をTRM（Task Responsibility Matrix）という。

近年、米国のエンジニアリング企業ブラウン&ルート社ではPLAN （Planned Logical Activity Network scheduling）システムとよぶプロジェクト管理ツールを開発した。この中ではプロジェクト実行業務を細分化して、さまざまなプロジェクトに共通の基本的業務として位置づけた上で、これまでの完了プロジェクトのデータからそのような基本的業務データを分析・抽出し、それらをヒストリカルデータとして蓄積する。それらをうまく活用し、比較対象とすることでプロジェクト遂行におけるスケジュールの計画と管理をより合理的におこなうことをめざしている。

プロジェクト計画を立案する際に最も重要で、かつ困難な仕事が作業量の見積りである。システム開発を例にとると、見積りをするには大きく分けて２つの方法がある。

(1)は過去のプロジェクトの経験を参考にして、類似したプロジェクト全体の実績データを今回の見積りに生かすやり方であり、 (2)は全体の作業を小さい作業単位に分け、これらの作業ごとに妥当な基準値を使って見積ったものを積み上げるやり方である。この場合の妥当な基準値は、過去の実績データ、３点見積り法、モデル法などによって求める。よく使われるモデル法には、ファンクション・ポイント法とCOCOMOモデルの２つがある。 さらに大規模プロジェクトにおけるコスト・マネジメントに関しては、以下のような方法が評価されている。

・徹底したプロジェクト別の管理をおこなう。
プロジェクト・マネジメントはカスタムメイドである。プロジェクト一つ一つにコストマネジメントの最善をつくし、かつ経験を情報として蓄積していくことが重要。

・コストマネジメントの管理期間は、プロジェクトのライフサイクル全体である。
プロジェクトの成果が、会社の決算期間とは何ら関係なく管理されることが必要である。プロジェクトの経過時間とコスト発生額を関連づけ、コストの動きのタイムパターンによりプロジェクト全体のコストを管理する方法が良い。

・積極的なコストコントロールをおこなう。
プロジェクト進行の各段階において、きめ細かな内容を入れた迅速なコスト報告をおこない、それに基づいた全ての段階へのフィードバックと適切な軌道修正をおこなう。その際、計画、実行状況把握、報告、分析のいずれの過程においても、高レベルのコンピューター利用が不可欠である。

実際のプロジェクトは、ここで述べたマネジメント手法を用いた場合でも、しばしば失敗する。プロジェクトの成功とは「ある期日までに、決められたコスト以下を使って、一定以上の品質のものを完成させること」であるから、「プロジェクトが失敗する」とは、目標の品質のものが完成せず、あるいは完成したとしても期日に遅れるかコストが予算をオーバーしていたり、またはその両方であることを指す。そしてその原因はマネジメント手法そのものではなく、その用いられ方にある場合が多い。

top
2 プロジェクト失敗の構図

既に述べたように、プロジェクトの成功とは「ある期日までに、決められたコスト以下を使って、一定以上の品質のものを完成させること」であった。したがって「プロジェクトが失敗する」とは、目標の品質のものが完成せず、あるいは完成したとしても期日に遅れるかコストが予算をオーバーしていたり、またはその両方であることを指す。実際には納期になってはじめて失敗したことが分かるわけではなく、プロジェクトの途中から失敗の気配は確実に漂い始める。文献[9]によれば、プロジェクトが失敗に向かう典型的な構図は以下のごとくである。

プロジェクトの納期が迫ってきてとてもその時期には完成しないことが誰の目にもはっきりしてくると、急に進捗管理が厳しくなり、しかもそのための資料の作成が多くなる。そして対策会議がそれまでの慣例を破って頻繁に行われる。なによりも変化したことは、それまでほとんど顔を出すことがなかったプロジェクト・マネージャーよりも上の管理者の姿が見えることである。こんな状況になると、今まで一部の読みの鋭いメンバーが心の中だけで考えていた「このままではきっと失敗する」という感じがメンバー全員の共通の認識になる。プロジェクトの進捗管理は一応なされており、この前の段階までは順調に進んでいるという報告が上司宛になされていたのに．．．

一度でもプロジェクト・マネージャーをやったことがある人なら、こんな状況は考えるだけでも恐ろしいに違いない。しかしこのような失敗は、たとえ1.1.3で述べたマネジメント手法を用いたプロジェクトにおいても、しばしば起こるものなのである。そしてその原因はマネジメント手法そのものではなく、その用いられ方にある。

top
■■■ 2-1 コミュニケーション不足の問題

PDCAに象徴される進捗のマネジメントとは、プロジェクトの進行状況をチェックし、もし遅れていればそれに対策を講じるのが目的である。ところが多くで見られるやり方は、状況をチェックする際に遅れるという事実を報告できないと担当者に感じさせるような雰囲気で行われるのである。すなわち、それを報告することが自分の能力がないという評価になると感じれば、担当者はそれを隠そうとする。そのため、検討されるべき問題が次々と後回しにされ、結局最後の段階で一挙に問題点が噴出して身動きがとれなくなるのである。

このような進捗のマネジメントは何もしていないのと同じで、むしろ問題が表面化しない分有害であるといえる。強圧的“管理”（ここでは管理という言葉が適当である）により管理資料上、全ての作業が日程通り進んだように見せることはできても、最終的には必ず破綻する。いかに資質のあるプロジェクト・マネージャーとメンバーがおり、優れたマネジメント手法を採用していても、プロジェクト・マネージャーとメンバーのコミュニケーションがうまくいっていなければプロジェクトは成功しないのである。

同様な状況が、メンバー間に発注者・受注者の関係を含むプロジェクトでもしばしば発生する。発注者側は当然目標についてはできるだけ高いものを要求してくるが、受注者側は顧客との関係の悪化を恐れて、その目標が達成困難であると分かっていても、それを主張しない。さらに納期についても無理な顧客の要求を承認してしまう。その結果このプロジェクトは初めから失敗を運命づけられてしまうのである。結局、できないことをできないと言えないために失敗したプロジェクトが現実には多い。そしてその場合、メンバーの多くには、最初から失敗の予感があったのである。

また仕様の凍結に関しても、発注者・受注者間のコミュニケーション不足は致命的な問題を生じかねない。発注者すなわち顧客によっては開発仕様がなかなか固まらず、いつまでも仕様変更が続く場合が少なくないが、これでは受注者すなわち開発側はある限度以上の仕事ができなくなる。にもかかわらず、顧客の際限のない要求を認め続けて納期までに完成しなければ、その失敗は結局開発側の責任である。

一方顧客の仕様に誤りが発見された場合、それが仕様の凍結後であるという理由で放置され、開発が続けられるとすれば、結局納期までに完成したものは無意味なシステムであって品質の点でそのプロジェクトは失敗したということになる。どちらの場合も仕様の凍結・変更に関しては開発側からの適切なコミュニケーションが重要であり、顧客側ではそれを容易にする体制づくりが必要である。

top
■■■ 2-2 コミュニケーション手段の問題

正しいマネジメント手法を採用してきちんとそれに従っているはずなのに、作業の進行が遅れ、コストが増えてしまうことが少なくない。これに対して多くのプロジェクト・マネージャーは、担当者を叱咤激励することによって生産性が上げられると信じているようである。この“管理”手法は頭脳労働者で構成されるプロジェクトには何の効果もないばかりか、結局は優秀な担当者を失うことになる( 文献［10］の著者によれば、この主のマネージャーは「ハンバーガー・ショップの店長」としては理想的である。)。 ここではプロジェクト・メンバーの生産性を下げる外部要因を取り上げる。

会議

プロジェクトにおけるコミュニケーション手段として会議は不可欠であるが、同時にこれほど問題の多い作業もない。会議の本来の目的は利害関係の調整やブレーン・ストーミングにあるのだが、現実には意志決定の責任を分散させるため（「私が決めたのではない、会議が決めたのだ」）や、親睦会的なもの、単なる暇つぶしのための会議が大変多い。これらの会議では「前回議事録の確認」から始まって会議時間の大部分が資料説明に費やされ、実質的な決定は何もなされないまま終わる。参加者のレベルが揃っていれば情報を得る機会として有用なこともあるが、そうでない場合は事情を良く知っている参加者にとっては全くの時間の無駄でしかない。本来ならその時間はプロジェクト自体の作業に使えるはずなのに。

電話

コミュニケーションの手段として見た場合、電話ほど不公平な道具はない。連絡をする側はいつでも自分の好きなときにかけられるのに、連絡を受ける側はどんなに重要な仕事をしていても中断を余儀なくされ、電話が終わった後仕事を再開しようとしても、しばらくの間自分が何をやっていたのかさえ思い出せない。その結果仕事の能率が落ちるだけでなく、重要なアイディアを忘れてしまうことさえある。このように電話の最大の問題点は、通話そのものに時間がかかることよりも仕事が中断されることにある。( この「中断シンドローム」は心理学の立場から分析されている。人間は、一つのことに没頭した“フロー”状態になって初めて仕事が上手く運ぶが、この“フロー”状態になるには、通常15分以上の精神集中過程が必要である。この精神集中過程では騒音や割り込みに非常に敏感になるため、騒々しいオフィスではフロー状態になるのは不可能に近い)

さらに電話は相手が不在の確率が意外に高いので、発信者にとっても不便である。ある調査によれば一度の電話で相手をつかまえられる確率は平均3割だという。したがって伝言してコールバックを頼んでも、今度はこちらが7割の確率で不在だから、結局２度の電話で話せる確率は5割しかないことになる。もちろんこの問題はメンバー全員が無線電話を携帯することによって解決されるが、そうなると初めの「中断シンドローム」の問題は完全に致命的である。

電話にはこのほかコミュニケーションの証拠が残らず、後でトラブルが起こったときに解決が困難になるなどの問題もあり、プロジェクト・メンバー同士の連絡手段としては全く不十分であるといえる。

top
■■3 プロジェクトを成功させるには

様々なプロジェクト・マネジメント手法が正しく機能するかどうかは、プロジェクト・マネージャーとメンバー間のコミュニケーションが上手く行っているかどうかで決まる。大抵のプロジェクトでは、マネージャーは職場の上司であるか発注者の立場であるかのいずれかだから、コミュニケーションを促進させる方策はマネージャーの側から講じなくてはならない。以下にそれを列挙する。

コミュニケーションの促進

(1)「プロジェクト管理」ではなく、「プロジェクト・マネジメント」であることを意識する。 言葉を変えることによってマネージャー、メンバー両者の意識が変わる。職場の組織構造を越えて、ともに一つの目標に向かうという仲間意識が生まれる。“部長あるいは発注者”と“プロジェクト・マネージャー”は別の機能であることを認識しなければならない。

(2)マネージャーはメンバーの犯したミスを大目に見、むしろそれを発見したことを評価する。 間違いが許されないという雰囲気をプロジェクト組織の中につくってはいけない。頭脳労働者が時々ミスを犯すのはきわめて自然で、仕事を真面目にやっている証拠である。大切なのはミスを早めに発見してすぐに対策を打つことである。

(3)マネージャーはメンバーの作業を理解しなければならない。しかし作業に手を出してはいけない。
メンバーは自分の作業を理解してくれるマネージャーにだけ、相談しようという気を起こすものである。しかし作業に手を出すマネージャーに対しては、自分が信用されていないと感じ、言うことを聞かなくなる。

(4)プロジェクトの開始時には、メンバー全員にプロジェクト・プランを完全に納得させる。
メンバーに十分納得できない仕事をさせると、自分勝手な判断で行動にでる恐れがあるばかりか、マネージャーの能力に対して疑問を抱くようになるかもしれない。マネージャーはメンバーに信頼されて初めてマネージャー足りうる。

(5)コミュニケーションの回数は最小限になるよう努める。
逆説的だが、コミュニケーションは十分行わねばならない一方、コミュニケーションの数が多くなるほど仕事の生産性は低下する。したがって作業を細かく分割し、一つの作業をできるだけ少ない人数で担当させるなど、組織を工夫する必要がある。

コミュニケーション手段の改良

プロジェクト・メンバー間のコミュニケーション手段として、会議や電話に大きな問題があることを先に述べた。これらに共通しているのは、ともに口頭による情報交換であるという点である。口頭による情報交換は相互即時交信性があるのが特徴であるが、プロジェクト作業における情報交換ではその必要性はあまり感じられない。実際のところ会議で報告を受けても、資料を読んで理解した後でなければ実のある議論はできないし、電話で伝えられるような簡単な内容ならそもそも議論する必要がない場合が多い。

最近の情報技術の進歩は著しく、ワード・プロセッサ、コピー機、ファクシミリ、電子メールなど、文書を作成・編集・複製・通信することが以前に比べてはるかに容易になってきた。それにともなってプロジェクト作業における情報交換を文書で行うことの優位性が高まって来つつある。文書による情報交換では発信者は十分に内容を校正でき、受信者は受け取ったものを時間をかけて理解できるので、誤った情報伝達の可能性が減ると同時に情報交換の証拠も残る。さらに電話の重大な欠点である受け手の仕事の中断や不在の問題も一切ない。以下では文書による情報交換という基本原理のもとに、コミュニケーション手段の改良のためのいくつかの考え方を挙げる。

(1)会議を開く前にそれが文書連絡で済まないかを考えてみる。
先に述べた無駄な会議を減らすための方策である。定例業務報告会といった類の、説明・報告のための会議がこれで減るだろう。また実質的には親睦会・暇つぶしである会議にも、建前上は何らかの情報交換を行うというような議題がついているものであるが、文書連絡のスタイルが普及すれば、それらは全く存在する名分を失う。

(2)すぐそばにいるメンバー同士の連絡も文書で行う。
口頭での連絡は電話の場合と同じように相手の仕事を中断させる。連絡を文書化すればこの問題を回避できる。また通常の業務は連絡の連続によって進むことが多いから、大きめの紙に次々と連絡事項を書いていけば、同じ事を繰り返すことなく次のメンバーに伝えられるという利点もある。

(3)遠隔地との文書連絡をファクシミリから電子メールに変える。
ファクシミリは文書連絡を即時化したという点で大きな効果をもたらしたが、たとえ元の文書をワード・プロセッサで作成しても送られた文書は紙の上のイメージになってしまい、再度編集することは不可能である。これに対して電子メールは電子データのまま送信することができるので、受け取ったあとの保存・検索が容易で、情報を先々まで有効に使うことができる。なお電子メールにはファクシミリとは違った多くの特徴があり、それらを利用することによってさらに高度な文書連絡が行える。

(4)文書の規格を統一する。
紙の大きさをそろえることはもちろん、文書のフォーマットを統一することによって文書処理の効率は高まる。そのためにはまずできるだけ構造化した文書を作る必要がある。すなわちいつ・誰が・どこで・なにを・どうした、という構造をあらゆる文書で明確にし、余分な内容をそぎ落とすことである。このことは電子メールを用いる場合にとくに効果的で、大量に保存されたメールの中から必要なものを取り出すための検索が大幅に高速化する。

(5)電子的文書をプロジェクト・メンバーで共有する。
コンピュータの中にある電子的文書も各メンバーが独立して扱っている内は、コンピュータは単なる文書清書マシンということになってしまう。電子データがディスケットや通信ケーブルを介してコンピュータ間で容易に伝送できるという特徴を利用して、それを多数のメンバーで共有して扱えば、プロジェクトにつきものの共同作業が大幅に効率化できる。この作業を、高速なネットワークを用いて遠隔地にある多数のコンピュータ間で半自動的に行おうというのが、グループウェア型の文書データベースの考え方である。

(6)文書を時間順に保存する。
紙であれ電子データであれ、どんどん増えていく文書を内容別に分類して整理するのは大変な作業である。これに対して文献[1]に従えば、文書を一切分類せず到着時間順に並べて保存するのが良い。この考え方は書類は新しいものほど頻繁に利用するという原理に基づいており、実際古くなった文書は捨ててしまってもほとんど困ることはない。必要なのは、いらないものを捨てる勇気だけである。

top
■■ 4 プロジェクト・マネジメントを支援するグループウェア

グループウェアとは、グループ共同作業を支援するための技術の総称。設計理論、方式から、構成要素となるコンピュータ（ソフトウェア＋ハードウェア）や通信ネットワークまで含める。CSCW(ComputerSupported Cooperative Work)とほぼ同義。狭義にはソフトウェアを指す。ここで言うグループ共同作業とは

等のことである。 グループウェアの起源は1960年代から70年代にかけて、米国のスタンフォード研究所、ランド研究所、未来研究所等で始まったコンピュータによる人間の共同作業支援に関する研究に見ることができる。なかでもスタンフォード研究所に在籍していたDouglas Engelbartは、コンピュータによる知的作業とはどんなものかを最初に表現し、共同作業支援のコンセプトを多数生み出した。これらのコンセプトは全て、今になってグループウェア・アプリケーションとして実現し始めている。

“グループウェア”という言葉は、1980年代になってCal Pava（ハーバード・ビジネス・スクール）やJohnson-Lenz夫妻（ニュージャージー工科大学）らによって使われ始めた。また、マスメディアの世界で初めてこの言葉が用いられたのは1987年6月8日のFortune誌上であった。 グループウェアを大きく二つに分類すると

となる。また、グループウェアの基幹技術としては、電子メール・通信ネットワーク（高速及びマルチメディア）・ヒューマンインターフェイス等が挙げられる。現在の代表的グループウェア商品としては、以下の通り。

・ForComment (Access Technology)：共同文書編集
作成された文書にLAN上で他の利用者からの校正やレビューを受け、それを文書上に反映させる。校正ステップを原本に影響なしに追跡、保存することができる。Novell社のNetwareを用いる。対象メディアは文字のみ。

・The Coordinator II (Action Technology)：コーディネーション
E-mailと個人スケジュール管理をベースに作業状況の追跡機能を提供。メッセージの分類やスケジュールに対応した必要作業の管理を行う。対象メディアは文字のみ。

・Lotus Notes (Lotus Development) ：コミュニケーション
(1994年11月現在、全世界で4000社が導入し、ユーザーは90万人以上。サーバー版はOS/2, NetWare, Windows NTに対応し、クライアント版はOS/2, Windows, Macintoshに対応している。また通信プロトコルはすべてのプラットフォーム上でTCP/IPが利用可能。機能が制限された廉価版Lotus Notes Expressも発売されている。)

クライアント・サーバ概念をベースにLAN-to-LAN接続に加え、E-mail機能と高度なセキュリティ管理による共有DB管理機能を有し、文書通信と文書蓄積管理の統合作業インターフェイスを実現。電子会議・書類の自動回覧などに利用可能。LAN間接続は専用デジタル回線によって行うことを基本にしているが、クライアント側からは一般のアナログ公衆回線による接続も可能。1994年11月25日にVer. 3.2が発売された。

また、研究中のグループウェア製品としては、会議支援グループウェアプラットホームシステム、MERMAID(NEC：1989年〜)がある。これは広域を含むマルチメディア在席会議技術であり、地点数・人数ともに制限はない。B-ISDNに対応しており、あらゆるメディアの情報を同時に交換、参加者全員で共有、処理ができる。UNIXワークステーションを用いる。

グループウェアを用いたプロジェクト作業
以下に、グループウェアによるプロジェクト・チーム作業支援の代表的なアプローチをいくつか紹介する。

・グループ用スケジュール管理システム
プロジェクト・メンバーはそれぞれ、自分の都合の良い時間と悪い時間を優先順位を付けてシステムに入力しておく。マネージャーが会議を開きたいと思ったときは、このシステムが全員の共通空き時間を検索して会議の日時を決定するとともに、メンバー全員に通知を出す。必ず全員がこのシステムに参加することが必要で、自分の予定を秘密にしたがる人に対する説得がポイント。

・工程管理システム
あらかじめプロジェクトの工程計画を立ててスケジュールに入力しておけば、チームのメンバーは他人のものを含めて、いつでもそれを参照できる。このシステムはチームがすべきことを整理し、それを実行すべき時に催促してくれるので、メンバーは自分の進行状況をチェックするできるとともに、マネージャーは全体の進捗状況をつかみやすい。

・文書共同執筆システム
プログラム・ソースを含むあらゆる文書ファイルを、ネットワーク上のプロジェクト・メンバー全員からアクセス可能にしておく。各メンバーは順次その文書ファイルに対して、自分の分担分を追加・修正していくとともに、必要に応じて他人の分担箇所へのコメントをつけ加える。システムはファイルを上書きすることなく全てのバージョンを保管するので、誰がどのような修正をしたかを記憶している。このシステムによって、遠隔地にいるメンバー同士の間で、効率的な文書作成が可能になる。

top
■■ 5 外注の必要性

大規模なプロジェクトにおける全作業を、すべて内部でおこなうことのできる組織は少ない。たとえば政府主導の研究開発プロジェクト等の場合は、プロジェクトを推進する組織は通常なんの生産設備も持たず、技術者のリソースも多くはない。したがって詳細設計や研究開発のほとんどを契約した複数の外注先に委託し、自らはプロジェクト・マネージャーに徹することになる。この場合外注先は発注側にない専門能力や技術を保有し、設計や開発を進めていくことになる。

一般に外注とは、ビジネス・プロセスの中でいくつかの機能や資源を外部から調達することを意味する。すなわち生産、販売、経理、人事、情報システム等の企業の経営機能の一部を外部機関に請け負ってもらい、自らの限られた経営資源を本質的な業務に集中することによって、経営効率を上げようとするやり方である。例えば自動車メーカーなどの総合組立メーカーが部品の生産を下請け会社に委託することや、社内の情報システムの開発、運用、保守をベンダーに委託すること（アウトソーシング）などがあげられる。

外注をおこなうことによって期待される具体的な効果は以下の通りである。

外注は以上のような目的を持っておこなわれるが、その委託形態にはさまざまな種類があり、大きく二つに分けると

となる。1.の外注方式は発注側（ユーザー）と請負側（ベンダー）の間に、資本関係がない場合で、2.の別会社方式は、発注側である親会社が請負側の子会社の資本を50〜100%保有する場合である。日本では2.の比率が高く、アメリカでは逆に1.の比率が高い。

top
■■ 5-1 外注業務の流れと管理

企業が実際に外注をおこなう場合には、おおむね次のような手順で進む。

1.は外注の可能性のある企業ならば日頃から行っておくべき作業である。外注することを決めてから評価を行おうとしても、短時間で適当なベンダーを見つけることは難しく、結局以前からのつき合いにたより、適切な評価を行わないまま発注することになりがちである。

また2.は開発（生産）プロジェクトの開始時点でおこなわれるもので、3.の内製か外注かの決定をおこなうためのデータとなる。

内製か外注かの決定は経営戦略上、重要な判断であるから、企業としての明確な方針の下に行われなければならない。開発（生産）機能から見た、外注に出すことを決める判断基準としては以下のようなものがある。

さらに経営機能全体から見た判断基準としては、

等が考えられる。

4.の開発（生産）計画は要求する品質と納期を決める作業であり、それに基づいて5.の見積り依頼が出される。ベンダーから提出された見積書に対しては明確な基準で見積額評価をおこない、価格交渉を経て6.の注文書が発行される。

外注利用も開発や生産プロジェクトの一部であるから、品質、納期、コストの管理が当然重要となる。このうちコストに関しては契約時に決められることが多く、発注側にとって作業進行中の管理の必要がないことは、内製と異なる事情である。代わりに品質、納期に関しては、作業が発注側の手元で行われないことから管理が難しく、7.作業進捗管理の要となる。

ベンダーでの作業が終了すると、8.納品、9.検収となるが、ここで重要なのは納品物の品質を保証するという考え方である。すなわち品質検査をベンダー側で実施するにせよ発注側でおこなうにせよ、不良品（バグ）を発見するという意識では、検査基準を厳しくすればするほど不良率は上がるばかりである。検査結果をベンダーにフィード・バックして不良原因の分析を進めるとともに、ベンダーの品質意欲を高めることによって不良率を下げていかなければならない。

top
■■ 5-2 外注利用の問題点

前述のような外注業務の中で、発注企業が実際に直面している問題には以下のようなものがある。

これらの問題点に対して発注側ではおおむね次のような対策をとってきた。

いずれの対策も、発注側には開発（生産）計画の変更を余儀なくし、予定の生産量、売上高が得られないという事態を招き、ベンダーには受注先を失ったり、コストアップに見合った売り上げの上昇が得られないという事態を招く。この傾向が続くとどちらの側でも経営状態が悪化し、最悪の場合倒産につながる。

外注はビジネス・プロセスの一部を外部化することであり、企業経営の根幹にかかわる重要な機能である。したがって外注管理の巧拙が直接利益の大小につながることを認識して、企業においては全社的問題として取り組まなければならない。なお、情報システム部門をアウトソーシングする場合など、長期にわたって外注を利用する場合には、上にあげた以外にも次のような問題点が指摘されていることをつけ加えておく。

top

■■ 6 開発プロジェクトにおける外注利用の特徴

前節では一般的な外注のしくみについて述べた。その典型例としては、製造業において総合組立メーカーが下請けメーカーから部品を調達する場合である。日本においては高度成長時代、急激に拡大した大手メーカーが、足りない生産能力を補うために中小メーカーの生産設備を利用する目的で始まった。その後多品種少量生産の時代へと転換してからは、下請け先の安い人件費を利用するコスト削減の目的に変わり、現在では自社内に保有しない専門技術を得て、弱点を補強しようという戦略的外注利用の形態が生まれている。

また、最近広く行われつつある情報システム部門のアウトソーシングは、自社の経営機能のうち本質的でない領域を外部に委託することによって、経営資源を集中させようという経営戦略上の考え方である。これら新しい外注の形態は、従来の下請け、従属的なベンダーの立場を変化させて対等で提携的な関係へと変えつつある。そこではベンダーは発注側にない専門能力や技術を保有し、発注側企業における経営戦略にも参加して、設計や開発を進めていく。発注先がベンダーを一方的に選んで価格を押しつけるのではなく、ベンダーも取引上のメリットのある発注先を選択しようとする。発注先とベンダーの双方にメリットがなければ、外注が成立しなくなるのである。

このような新しい形態の外注は、とくに政府主導の開発プロジェクトにおいて顕著である。すなわちプロジェクトを推進する組織は通常なんの生産設備も持たず、技術者のリソースも多くはない。詳細設計や開発のほとんどを契約した複数のベンダーに委託し、自らはプロジェクト・マネージャーに徹することになる。

この場合組立メーカーに見られたような内製の選択肢はない。この種の開発プロジェクトではかなり研究的要素の強い技術開発が含まれるから、ベンダーの能力によって達成できる仕様に差が出る可能性が高い。したがって発注するベンダーの評価および選択はきわめて重要な作業となる。

また納期に関しても制約は厳しい。巨大システムの開発プロジェクトでは、多数のベンダーと契約を結んでそれらの同期を取りながら開発を進めることになるから、あるベンダーが納期遅れを起こすとその影響はすぐプロジェクト全体に及び、代替手段がない場合が多い。納期遅れに対処する手段も必要だが、出来るだけその危険の少ないベンダーを選定することがより重要である。

一方、政府予算でプロジェクト費用が決められることが多いため、通常はプロジェクトを推進する組織であっても費用を自由に調整することは出来ない。このため発注側にとってはコストをあらかじめ固定できる反面、ベンダーにとってはリスクの高い契約を強いられる可能性がある。開発途中にコストが上昇し、収益が圧迫されてきた場合、よほど体力のあるベンダーでなければ品質低下によって対処しようと試みるのが自然であろう。このように発注側にのみ都合よく見える契約は、結局のところ品質低下や不良率の上昇という返礼を受けることになる場合がある。

top
■■ 6-1 プロジェクトにおける外注管理の流れ

プロジェクトにおける外注業務の中で最も重要なことは、一般的な外注業務と同様に、いかにして優秀な外注先を選定するかということである。優秀な外注先を見つけることが出来れば、それ以後の外注管理業務ははるかに容易におこなうことができると考えられる。

しかし本質的に一度きりの活動であるプロジェクトで全てを予測することは不可能であり、プロジェクト開始前の外注先の評価作業で今までつき合いのなかった外注先を調査する場合、表面的な資料に頼らざるを得ず、十分な外注先の能力評価がおこなえないこともある。したがって外注先の事後評価が、次のプロジェクトにおける外注先の選定作業の準備として重要になる。

ほとんどの組織ではプロジェクトのたびに外注先を全く新しくすることはまれで、たいてい少数の企業と継続したつき合いを続けている。これは外注先選定作業の手間を減らすことが目的であるが、反面なれ合いのつき合いによって、プロジェクトにおける外注の最適化がおこなわれていない場合もある。プロジェクトの事後評価は、次のプロジェクトの外注先選定のための事前評価としてとらえられる。

外注先の能力評価のためにプロジェクト終了後に分析する場合には、提案書及び契約書の中に書かれた品質、納期、コストに関する仕様の達成度合いだけでなく、外注先内部での請負プロジェクトが成功したかどうかを見極めることが重要である。発注側から見てたとえ品質、納期、コストが契約通り満足されたとしても、外注先内部でコスト超過が起こっていれば、プロジェクトは成功したとは言えない。外注先の能力を正しく判断し損なった結果の外注先へのしわ寄せは、結局次のプロジェクトで発注側が付けを支払うことになる。

とくに研究的要素の多い開発プロジェクトでは、外注先の能力によって達成できる仕様に差が出る可能性が高い。したがって発注する企業の評価および選択はきわめて重要な作業となる。

また巨大システムの開発プロジェクトでは、多数の外注先と契約を結んでそれらの同期を取りながら開発を進めることになるから、ある外注先が納期遅れを起こすとその影響はすぐプロジェクト全体に及び、代替手段がない場合が多い。納期遅れに対処する手段も必要だが、出来るだけその危険の少ない外注先を選定することがより重要である。

一方、政府予算でプロジェクト費用が決められる場合には、通常はプロジェクトを推進する組織であっても費用を自由に調整することは出来ない。このため発注側にとってはコストをあらかじめ固定できる反面、外注先にとってはリスクの高い契約を強いられる可能性がある。開発途中にコストが上昇し、収益が圧迫されてきた場合、よほど体力のある外注先でなければ品質低下によって対処しようとするだろう。

このように開発プロジェクトにおける外注管理は、通常に比べてより困難な条件を備えており、とくに外注先の選択がプロジェクトの成否を決定する最大の要因になりうる。

プロジェクトにおいて外注先を選定するためには、事前に外注先の能力・特徴について評価しなければならない。そのためには、まず外注先から次のような情報を収集する。

複数の企業に関する以上のようなデータを集めた上で比較をおこなう。ここでのポイントは、研究開発プロジェクトでは納品物の品質が結局のところ担当者個人の能力に依存することが大きいから、外注先の中でどういう担当者が実際に作業を担当するかを把握することである。担当者個人の実績を知り、また労働時間からはその生産性を知ることができる。

さらに契約を考えた場合の課題は、技術面やコスト面でのブラックボックスをどう打破していくかということである。内製出来ない専門技術導入を目的とした外注の場合、発注側で技術評価を正しくおこなうことは難しく、売り手市場になりやすい。複数企業の過去の実績を出来るだけ多く入手して比較検討することによって、品質とコストを相対評価し、技術面においても対等な折衝が出来る体制をつくらなければならない。

データの検討が済んだ後で、ベンダーを訪問する。システム開発などの頭脳労働においても労働環境の善し悪しは生産性を大きく左右するし、社内の雰囲気や社員の士気を知る貴重な機会である。

以上の調査によって複数ベンダーの評価が済んだ後、過去の実績にとらわれず、プロジェクトのたびに選定基準を定めて外注先の選定をおこなう。その際、すべての条件において他社より優れている企業を捜すことは通常は困難であり、要求仕様を適度なバランスで満たすことの出来る外注先を選ぶことになる。

外注先選定作業はまずRFP（Request For Proposal）の作成から始まる。RFPには外注に際しての発注要件仕様と外注先の提案・見積りに関する要望事項の二つが含まれる。ただし現実には自前でRFPを作成できる場合は少ないであろう。その場合は発注側と外注先がプロジェクト内容について共同で検討しつつ、RFPを作っていくことになる。

RFPが出来上がったら、それを事前検討で絞り込んだベンダー数社に提示し、提案書（Proposal）の作成を依頼する。各社の提案書が出そろったところで、各社の提案内容を比較評価し、外注先を最終的に決定し契約となる。

発注側が外注先と取り交わす契約方式を大別すると、期間契約方式と請負契約方式がある。単一のハードウェアやソフトフェアを外注する場合などは請負契約方式を採用して問題がない。ところが研究開発プロジェクトのように対象となるシステムが大規模になると、発注側、外注先ともに様々の要因を正確に見積もれなくなってしまう。そこで長期にわたる情報システム開発などでは、期間契約方式と請負契約方式を適宜組み合わせた契約方式を採用することが多い。具体的にはシステムの規模や不確定性の程度によって以下のような組み合わせがある。

top

■■ 6-2 外注先の評価・選定・契約

上で述べたように開発プロジェクトにおける外注管理は、通常に比べてより困難な条件を備えており、とくに外注先の選択がプロジェクトの成否を決定する最大の要因になりうる。ここでは開発プロジェクトにおける外注先の選定・評価・契約・事後評価について述べる。

外注先の評価

外注先であるベンダーを選定するためには、まずベンダーの能力・特徴について評価しなければならない。過去のプロジェクトで実績のあるベンダーであっても、新規プロジェクトが始まる際には、改めてそのプロジェクトに対して適切な外注先であるかを検討する。同時にこれまでつき合いのないベンダーに対しても、情報を収集することによって新規外注先となり得るかどうかを調査する。常に代替外注先を考慮しておくことは、プロジェクト進行上何らかの問題が生じた場合に、発注側に有効な選択肢を与えることになる。

ベンダーの能力を評価するためには、まずベンダーから次のような情報を収集する。

複数のベンダーに関する以上のようなデータを集めた上で比較をおこなう。ここでのポイントは、開発プロジェクトでは納品物の品質が結局のところ担当者個人の能力に依存することが大きいから、ベンダーの中でどういう担当者が実際に作業を担当するかを把握することである。会社としての開発実績を知ることは重要であるが、その経験が全ての担当者に共有されているとは限らない。担当者個人の実績を知り、また労働時間からはその生産性を知ることができる。

さらに契約を考えた場合の課題は、技術面やコスト面でのブラックボックスをどう打破していくかということである。内製出来ない専門技術導入を目的とした外注の場合、発注側で技術評価を正しくおこなうことは難しく、売り手市場になりやすい。複数ベンダーの過去の実績を出来るだけ多く入手して比較検討することによって、品質とコストを相対評価し、技術面においても対等な折衝が出来る体制をつくらなければならない。

データの検討が済んだ後で、ベンダーを訪問してみることは有用である。従来から組立メーカーの下請け先評価では、工場の視察が必ず実施されているが、システム開発などの頭脳労働においても労働環境の善し悪しは生産性を大きく左右するし、社内の雰囲気や社員の士気を知る貴重な機会である。

外注先の選定

前述の調査によって複数ベンダーの評価が済むと、続いてそのプロジェクトに合った外注先を選定する作業に入る。プロジェクト毎に要求する専門技術、品質、納期、コストは異なるため、過去の実績にとらわれず、プロジェクトのたびに選定基準を定めて選定をおこなうべきである。その際、すべての条件において他社より優れているベンダーを捜すことは通常は困難であり、要求仕様を適度なバランスで満たすことの出来る外注先を選ぶことになる。

外注先選定作業はまずRFP（Request For Proposal）の作成から始まる。RFPには外注に際しての発注要件仕様とベンダーの提案・見積りに関する要望事項の二つが含まれる。発注要件仕様には以下の内容が含まれることが望ましい。

またベンダーからの提案・見積りに関する要望事項として含まれるべきものは、

などである。ここではRFPを発注側が事前に作成し、ベンダーに提示の上検討を依頼するケースを想定しているが、現実には自前でRFPを作成できる企業は少ないであろう。その場合は発注側とベンダーがプロジェクト内容について共同で検討しつつ、RFPを作っていくことになる。

RFPが出来上がったら、それを事前検討で絞り込んだベンダー数社に提示し、提案書（Proposal）の作成を依頼する。各社の提案書が出そろったところで、各社の提案内容を比較評価し、外注先を最終的に決定し契約となる。ここでのポイントは各社の提案書を全く同じ形式に統一するということである。これによって各社提案内容の相違が明白となり、比較評価が容易になる。

外注先との契約

発注側がベンダーと取り交わす契約方式を大別すると、期間契約方式と請負契約方式がある。それぞれの概要は以下の通りである。

期間契約方式

例えば月額の単価を決めて契約額を決める方式であり、発注業務の概算見積に従って契約の大枠を設定し、一定期間（例えば年一回）に対して清算をしていくやり方である。単価の算定基礎となるものは人件費、外注費（2次外注を使う場合）、設備費、出張費などである。価格折衝の際に最も問題になるのはベンダーの担当者が人件費（経験年数で決まる場合が多い）に見合った能力を持っているかどうかであり、発注側がこれを正しく評価しなければならない。

請負契約方式

発注する作業に必要な投入人工、設備使用時間、所要経費などに対するベンダーの見積りに従って折衝を行い、合意の上発注する方式である。請負契約方式はベンダーにとっては、上手く作業をこなせば付加価値が大きい反面、全てを受注側の責任でおこなうので、リスクは期間契約の場合よりも大きいのが普通である。

単一のハードウェアやソフトフェアを外注する場合などは、発注対象のシステムが比較的簡単で、発注側、受注側双方が相当の確度を持って開発に必要な所要期間、開発費、所要人工等を見積もれるため、請負契約方式を採用して問題がない。ところが開発プロジェクトのように対象となるシステムが大規模になると、両者ともこれらの要因を正確に見積もれなくなってしまう。そこで長期にわたる情報システム開発などでは、期間契約方式と請負契約方式を適宜組み合わせた契約方式を採用することが多い。具体的にはシステムの規模や不確定性の程度によって以下のような組み合わせがある。

1.の一括請負契約は比較的簡単なシステム開発等の場合に採用される方式で、目標分析から設計、開発、テストまでの一連の作業を一括して発注するものである。

2.の二分割期間／請負契約は研究開発的なシステムや不確定要素の多いものを外注する際に用いられるもので、目標分析およびシステム設計のフェイズを期間契約で、開発フェイズを請負契約とするやり方である。このようなシステムは初期段階では開発の範囲も不明確なことが多く、したがって開発期間や人工は、発注側でも受注側でも分からないことが多い。

システム全体を見通すためには相当量の事前調査が必要で、このようなシステムに対して、最初から請負契約で進めるのは両者にとって大きなリスクを負うことになる。すなわちベンダーでは不測の事態を予測して、高い安全率をかけた見積りをするようになるし、発注側では高額の開発費を算定できるだけの根拠を得るのは、かなりの事前調査をしても難しい。このような場合に契約を二分割して、プロジェクトの初期段階におけるリスクを減らすやり方である。

3.の多分割期間／請負契約は、非常に大規模で開発期間が長期にわたるシステムを発注するときに用いられるやり方で、プロジェクトを目標分析、システム設計、開発などのフェイズに分割し、それぞれに対して期間契約か請負契約かを決めるやり方である。分割された一つのフェイズになお不確定要素が多い場合には、そのフェイズに対して2.の契約方法を適用する。

4.の一括期間契約はシステム開発終了後の保守契約などで用いられる方式で、一定の期間保守サービスを行ったり、要員を張り付けておく等の体制を取る場合である。

top

■■ 6-3 NASAにおけるプロジェクト管理と外注管理の例

この節では、プロジェクト管理手法の研究と実施に関して日本に比べて大きく進んでいる米国における、大規模プロジェクトを推進する場合の外注管理手法を具体例を挙げて述べる。ここで取り上げるのはNASAの例である。

1958年に発足した米国のNASA（National Aeronautics and Space Administration）は宇宙開発プロジェクトを推進する官僚組織であり、ハードウェアおよびソフトウェアの開発は、たとえ内部で可能であっても基本的に民間会社に外注するという方針を持っている。その組織は時代とともに変わってきたが、外注管理の基本方針はアポロ計画の時代からほとんど不変である。 NASAは世界でも類のない巨大プロジェクトを次々と成功させてきたという点できわめて優秀なプロジェクト管理組織であり、プロジェクト・マネジメント手法同様、その外注管理手法にもユニークなものを持っている。

NASAのプロジェクト管理手法の中核はPPP（Phased Project Planning）である。これによって巨大で長期にわたるプロジェクトを次のようにA、B、C三つのフェイズに分ける。

フェイズAはNASAの各センターの中で、個人または少人数のグループが自らの考えをまとめることから始まる。大学の研究室の活動に似たこの作業は、頭の中にあるアイディアを具体化するための構想を練り、実現可能性を示す報告書を書くことで完結する。それぞれ数千人の規模のセンター内では、常時このような活動がいくつも行われていて、将来のプロジェクトの種がまかれている。

NASAは本来学問研究の場ではなく宇宙開発をすすめる官庁であり、 本当の意味での新技術の開発をおこなうことを目的としている。 文献によれば、ある研究にNASAが手を出す条件が二つあり、一つはそれがプロジェクトである ということ、もう一つは人類がまだそれをやったことがないということである。アポロ計画も、最初に人間を月に送るという目的だけで始まったプロジェクトである。

このようにNASAは自らの能力をさらに発展させる可能性のあるものをフェイズAとして積極的に奨励しており、同時にそれまで秘密であった軍事技術を民間に公開する役割も持っている。

フェイズAで作成された報告書は、センター所長をはじめとするマネージャーが検討し、有望なものがあれば次の段階であるフェイズBに進む手だてを講じる。フェイズBはNASAの本部が認知した段階であり、通常はフェイズAを実行したセンターが担当する。ある計画のフェイズBを実行することになったセンターは、センター内の計画開発局と呼ばれる組織の中に、マネージャーをおいた数人の精鋭チームを作って、計画の「定義」作業をおこなう。ここでは計画の「大目標」が明示されて方針が立てられた後、計画に参加する研究者が全世界から募集されるが、このときはフェイズAを実行した研究者でさえも同じ基準で選抜される。

このフェイズBの計画定義という作業は日本ではほとんどなじみのない概念であるが、一言でいえば計画を具体化するためのさまざまな問いに対する答えを出す作業である。すなわち必要なハードウェアとソフトウェア、その性能、必要技術、経費、開発期間など、次の計画段階に進むための承認を得るのに必要な項目を全て明らかにし、言葉の定義を済ませておく。ここでは当たり前と思われる事柄も含めて、ありとあらゆる要求が検討され、初期設計と工程計画、コスト見積等、計画実行上必要なものを全て作成することになる。この作業は1年程度の期間で行われ、多くの場合外注される。そしてこれがプロジェクトにおける最初の外注となる。

フェイズBにおける外注は、次のように進められる。

このようなやり方によってNASAは外注先二社の特色を反映させた二つの計画定義書（積み上げると1メートル程の高さになる）を完成させる。計画定義書には以下の内容が含まれる。

1.の要求確認で次の構想を立てるために必要な条件を全て書き上げ、2.の構想では、そのプロジェクトの全ての側面について、必要ならばそれまでの研究結果も取り入れて実現可能な姿を描いて書き表す。そして3.の予備設計では、コストと日程の作成に必要な主要部分について、日本では設計と考えられている作業までやってみる。これらの作業の中にマイルストーンとしての審査（Review）があり、それぞれ要求審査、構想審査、予備設計と運用審査と呼ばれ、これら全てを経てフェイズBは終了する。

ところがフェイズBで作成された計画定義書はそのまま実行されるのではなく、あくまでスタディである。政府によって計画が承認されてフェイズCに進むと、あらためてプロジェクト・オフィスが設置される。そこではフェイズBの二つの構想をもとにして計画案を作り直し、作業を細分化し再定義してそれぞれの発注形態を決め、RFPをを作り上げる。

ここで、NASAにおけるプロジェクト・マネジメント手法の特徴を日本と比較して列挙すると

などとなる。外注管理手法の一例としてはマトリックス構造の報告書式が挙げられる。これはWBS（Work Breakdown Structure）とOBS（Organization Breakdown Structure）の組み合わせであるTRM（Task Responsibility Matrix）に、コストの尺度を加えた3次元のマトリックス構造をもつ報告書式であり、大規模プロジェクトに対するプロポーザル提出時に求められるものである。この統一した書式をもつ見積書によって、マネージャーの外注先評価が容易になる。

NASAは、プロジェクトに含まれる各作業が、たとえ内部で可能であっても基本的に民間会社に外注するという方針を持っている。これはNASAが、軍事技術等最先端技術を民間に公開する役割も持っているためであるが、外注主体ですすめられるプロジェクトでは、これまで述べた外注先の評価がきわめて重要な意味を持ってくる。

top
■■ 6-4 NASAの外注評価法

NASAはプロジェクトを民間部門に請負に出すことを美徳とする習慣を持っており、民間組織に対して一貫して買い主の立場をとっている。その外注契約はプロジェクト毎に一件づつおこなわれ、特定の企業と継続的な取引を続けることはなかった。これは民間の専門技術を適宜迅速に取り入れることに役立つが、外注先の技術を正しく評価する能力が必要になってくる。

このためにNASAはいくつかの先端的研究所を設立した。Lewis、Langley、Goddardにおける先端的研究の目的は、外注先の技術を評価するための能力をNASAが獲得するためにあった。実際NASAの高い研究レベルに魅力を感じて集まった優秀な人材は、いずれプロジェクトマネージャーとして外注業務を含むプロジェクト・マネジメントに力を発揮することになった。

プロジェクトの中で外注先を選定する場合、NASAでは局長直属の「供給者評価委員会」の委員が外注先の能力評価をおこなう。この委員会は組織上はNASAの本部にあるが、委員を務めるのは各センターの従業員であり、したがって購買手続の実権は、プロジェクトを担当する各センターにある。応札書評価のための技術的専門知識と業者選定のための管理機能は各センターに集中しているので、これはたいへん効率的な方法である。

「供給者評価委員会」の職務は可能性のある供給者を評価し、評価結果をランク付けすることだけであり、業者選定の決定権は局長だけにある。こうしてNASAは巨大プロジェクト遂行上もっとも重要な問題である外注先選定をトップ１人に任せた。ただし本部が委員会で評価の低かった業者を選定することはこれまで滅多にないのも事実である。

NASAは供給者選定手続きで特定の一つの基準だけを重視するということはない。たとえば、コスト見積は請負業者が故意に安値を出したり、売り手も買い手も関係コストを現実的に検討していなかったりして、誤解を生みやすい。また技術的能力という基準だけでも不十分である。技術的能力に加えて、外注先企業が契約を遂行するのに必要な企業の管理的柔軟性と経営能力をとくに重視している。すなわちNASAはすべての条件が同じとして（そんなことは滅多にないが）、マンパワーと施設の提供の可能性、詳細な管理計画の立案、プロジェクト管理手法の理解、NASAが採用しようとする契約方式に対する理解などの事業能力も技術的基準と同様に評価するのである。

アポロ計画の時、月軌道船を受注したBoeing社の価格は、全部で5社から出された見積の中で最高だった。しかし選定担当者が、当社の管理能力を技術的能力と同等に高く評価した結果、 Boeing社が落札することになった。宇宙船システムにBoeing社を参入させたいというNASA幹部の願望もあったにしても、Boeing社が評価された具体的な根拠は以下の3つに要約される。

ここで注意すべきことは、最終評価で決め手になったのはNASAとの取引における応札者の過去の経験よりも、別種の大型システム（ここでは空軍のプロジェクト）の作業で示された潜在能力であったことである。

とはいえNASAが常に統一した外注評価手続を持っていたわけではない。「手続きはＮＡＳＡのプロジェクトの数と同じくらいあった。．．．ＮＡＳＡの本部は供給者評価手続きについて大まかな指針を出しただけで、．．．この分野では各センターに広範な酌量の余地と柔軟性を認めていた」というのが実状であった。

NASAのプロジェクトにおける外注契約の多くは、初期の段階では「コスト・プラス・手数料」方式で結ばれた。これはプロジェクトの性格上、外注企業側がリスクを負担するメリットがなく、特殊な作業を請け負うことのできる企業が数多く存在しないために競争が成立しにくかった事情による。しかしこの契約方式では、リスクは全面的にNASAの側にあり、どんな場合でも外注業者が損をすることはない。そこでNASAは、無競争状態でも外注先がコスト低減を図りながらパフォーマンスを向上していく動機をつくるため、「奨励金付き請負契約」方式を導入していった。これはプロジェクトの節目で外注先から提出される作業報告書にもとづいて、外注作業の実績を評価し、それに対して契約金の他に奨励金を与える契約である。

ただしこのやり方の問題点は、宇宙開発等の先端的研究開発プロジェクトの場合、仕様書通りとか納期通りという実績の相対的重要性を判定するはっきりしたデータがない場合が多いということである。開発途中で発生した問題点に応じて仕様は次々と変化し、それに応じて作業量も変化するので、正しい納期の定義も困難になってくるのである。これに対してNASAは実績基準の定義を洗練化して、実績について適正な加重値と得点を決める等の対策を講じたが、その目標の達成は容易ではなかった。

本質的に、この種のプロジェクトは「成功」自体を明確に定義できないと言える。たとえば費用対効果の尺度を持ち出してみても、NASAの計画のほとんどは現状技術水準を超えるものであったり、費用対便益の点で費用が上回ることは明白であった。既存の能力の拡張をおこなうプロジェクトなら、その能力を尺度として評価をおこなうことができるが、アポロ計画やその他ＮＡＳＡの非常に大型の計画の場合、各計画の相対的な「成功」の尺度となるものは何もなかった。アポロ11号の乗組員以前に月面に着陸したものは誰もいなかったし、バイキング以前に火星への軟着陸に成功した探査機は一つもなかったからである。

結局このようなプロジェクトを評価するためにNASAは「効果」ではなく、「効率」に注目した。ある実績（それが成功したかどうかに関わらず）を達成したスタッフや外注企業がそれをどの程度上手くやったかというものである。この「効率」の絶対的基準を設けることは容易ではない。そのかわり、複数の外注企業による競争状態においては効率を相対的に測ることができる。

NASAではブレークダウンされた各作業毎に、できるだけ多くの企業と契約した。このときハードウェア部門とサービス部門の両方に同じ企業が参入することを許さなかった。その結果外注企業同士が、その実績を互いに評価し合うような状態になった。さらに主契約企業には下請け企業と契約することを強く奨励して、できるだけ多くのメンバーによってプロジェクトを「効率的に」推進する方策をとったのである。

top
■■ 6-5 外注業務の評価

プロジェクトにおける外注結果の分析事項の主なものは、次の通りである。

評価対象には、比較的統計データが得られやすい定量的評価項目と、評価者の主観に影響されやすい定性的評価項目がある。前者の例として、

等があり、後者の例として、

等が挙げられる。

top
■■ 6-5-1 市場を通じた企業の評価

本章では外注業務の評価をどのようにして上手くおこない、外注先選定の役に立てることができるかについて述べる。プロジェクトや外注業務の成功度を正しく評価してマネジメントにフィードバックすることが必要である。ここで注意すべきことはその評価が客観的におこなわれるということであり、プロジェクト・マネージャーにとって正しい判断を可能にする根拠が得られることになる。また多数のメンバーをかかえる大規模なプロジェクトでは、評価の公正さがチームワークの鍵である。

外注業務の評価は、同時に外注先企業の評価をすることになる。ここでは製造業（特に自動車メーカー）を中心として、市場および発注元企業に評価されるのはどういう企業かをみていくことにする。

市場に評価されるメーカー

1970年以前の自動車メーカーがほとんど技術力のみで市場から評価されたのに対して、1970年代以降は、機能・品質・コストをより高い次元でバランスさせる能力が評価されるようになってきた。すなわち変化する顧客ニーズへ的確に対応した製品を、迅速に市場投入すると同時に、複雑で多様な製品開発を統合する能力である。言い換えれば

この２つのトレードオフを成功させたメーカーということになる。

一方、近年企業競争力の主要因として注目されている概念が「コアコンピタンス」である。コアコンピタンスとは企業が競合企業と比較して明確に優位性をもつ中核資源のことである。ここでいう資源とは、技術的なノウハウや、それをもたらす組織能力が組み合わさったものをさす。つまり中核資源とは単独の技術を意味するのではなく、人的資源や組織的にそれを統合するプロセスなどを含めた概念のことであり、これを持つ企業が市場から高く評価されるというのである。

次に、製品開発戦略からみた企業の評価について述べる。企業の製品開発戦略には先行者型と追従者型があり、先行者型で成功する企業は、製品が市場で差別化されるために評価が高いのに対して、追従者型で成功する企業は、開発や生産のプロセスにおいて優位性を獲得し低コストを実現するため評価が高くなる。新規性という指標でみると、先行者型の企業は革新的な新技術を伴った製品開発を得意とし、追従者型の企業は漸進的な技術改良を中心とした製品開発を得意としている。

一方単体技術の革新性ではなく、既存技術の組み合わせのあり方に関して革新性がある場合も高い評価をうける。これは複数要素から構成されるシステムとしての革新性が認められたものであり、アーキテクチュアル・イノベーションとよばれる。

結局コアコンピタンスとアーキテクチュアル・イノベーションから考えられる評価される企業とは、革新的な技術を創造する組織能力だけでなく、既存技術と革新技術を包んだ企業内の技術資源全体をうまく組み合わせていく組織能力がある企業ということになる。

以上をふまえて自動車メーカーに対する評価指標としては次の3点が挙げられる。

（1）新製品導入率が高い企業
この指標に関して評価される企業とは、新製品導入頻度を高めながらも、それぞれの製品では比較的新しいコア技術(プラットフォーム）を展開利用する企業である。ここで新製品導入頻度とは新製品導入率を指し、各期間内に導入された新製品の数を、それぞれの期間の最初の時点での製品ライン数で割った値で定義される。この尺度を用いれば企業サイズに関係なく公平に測定が可能である。

またコア技術の新規性は平均プラットフォーム経年数で測定される。これは製品開発においてベースとして採用するプラットフォーム技術が、その新製品を導入する時点においてどれだけの年数を既に経過しているかで定義される。平均プラットフォーム経年数が低い企業ほど、その短い期間中の製品全体にわたって新しいプラットフォーム技術を導入したということで高い評価を受ける。

（2）並行技術移転戦略をより多く利用した企業
並行技術移転戦略とは複数のプロジェクトが時間的に並行した状態でコア技術を移転することで、開発されつつある新技術をその新しさを保っているうちに他製品ラインに移転する製品開発戦略である。これによって製品の新規性と頻繁な新製品導入の両方を同時に成立させることができる。 コア技術の移転スピードが速く、組織的効率がよい（コア技術に対して、複数のプロジェクト間で相互調整して効果的な設計分担と共同設計ができ、重複した投資や工数を削減できる）のが特徴。

（3）現行技術改良戦略をあまり利用しない企業
新製品導入率を高めるために現行技術改良戦略を利用した企業は、新しいコア技術を創造する点でも、コア技術を複数プロジェクトへ効果的に展開・活用する点でも劣っているため、評価が低い。したがって現行技術改良戦略を利用しない企業ほど高い評価が得られる。

さらに製品開発効率という面からの評価をおこなう場合には、コンカレントエンジニアリングを採用している企業は、開発効率が高く、評価も高いといえる。ここでコンカレントエンジニアリングとは、後工程で必要とされる要件を前工程プロセスの途中段階で十分に取り入れることにより、全体のプロセスを効率化することである。

発注元に評価されるメーカー

日本のメーカーは新製品の開発にあたって、市場で競争可能な目標価格を設定し、その範囲内に収まるように部品の発注単価を決めて下請企業に通知するやり方をとっている。その際下請け企業が発注単価で採算が取れない場合は、親企業がコストダウンのために助言したり、下請企業側からその単価で採算可能な仕様変更や生産方法の改善を提案することがしばしばおこなわれる。これをＶＥ（Value Engineering）といい、VEに熱心な下請け企業への親企業側の評価は高くなる。すなわちＶＥ提案を積極的に行う下請企業に対しては、原価率が低下するので優先的に発注がおこなわれるようになり、ＶＥ提案にあまり熱心でない企業には発注が減り、それらの企業は整理・淘汰されていく。

ここで注意すべき点は、下請企業における生産工程の詳細や原価構成という内部情報が親企業によって把握されている必要があるということであり、日本における伝統的な外注関係の中ではこのことが可能であった。

これに対して米国のメーカーは、外注先の企業によるＶＥ提案にはほとんど期待しておらず、多数の下請け企業による入札結果によって適正な価格を決める方法に依っている。これは米国では、親企業が下請け企業における生産工程の合理化などの内部情報を把握することが困難であるとともに、下請け企業は競争入札の際に入札価格の算定に必要なすべての情報を提供する必要があるため、その段階で設計は完全なものであり、ＶＥ提案が活かされる余地も期待もないことに原因がある。

自動車部品メーカーの場合、下請け企業は承認図メーカーと貸与図メーカーの2種類に分けられる。承認図メーカーとは、発注元から仕様書、レイアウト図、取付部分の詳細図面、外観図面などを情報として受け取り、それに基づいて独自のノウハウと技術によって設計図面を作成し、発注元から承認を受けるメーカーであり、一方貸与図メーカーとは発注元が設計図面を作成し、それを貸与された上で、貸与図図面に基づいて生産をおこなうメーカーである。

両者を比較した場合、承認図メーカーの方が、技術力や開発力を蓄積している点で発注側に評価されている。すなわち、

発注側の立場に立ってみれば、外注業務に高いパフォーマンスを求めるなら、できるだけ承認図メーカーを選ぶべきである。ただしこの評価法を用いる際には、同じ部品メーカーが両方の方式で納入している場合があることや、仕様書がポンチ絵程度のものから数字で書かれているものまで様々であるため、承認図と貸与図との区別が付きにくいことなどの問題点もある。

また自動車メーカーは新モデル開発時に常に旧モデルよりも部品購入価格を低減することを課題とするから、そのままでは外注先企業の利益は次第に圧迫されていく。これに対して外注先企業は新しい機能、より高度な機能を持つよう設計差をつけ、そのことを自動車メーカー側に評価してもらい、価格設定をさせることが必要になる。すなわちモデル開発時には部品の新規開発をおこなうが、その際部品メーカーは旧モデルとの設計差をつけることで「スペック変更、価格変更、付加価値引き上げ」をおこなうのである。逆に言えば発注元にとって、付加価値引き上げも外注先評価の対象となるわけである。

組立メーカーが部品メーカーに要求している品質はスペックに表れたものだけではない。たとえば、自動車メーカーは、発注に際して細かなスペックを指定してくるのではなく、どのような部位で使うのかなどの加工条件を提示する。これを高炉メーカーのR&D部門が技術スペックに置き換えて製造する。契約上は高炉メーカーの責任はスペック通りに製造することであるが、実際は自動車メーカーが実際に加工できるような鋼材を作ることが求められている。すなわち、設計標準を満たす加工をトラブルなく実施できる条件が、契約段階ですべてスペックとして表現できないことから、トライ＆エラーを繰り返して明瞭になるスペックも含めて品質保証を要求されるということである。このことを「パフォーマンス・ギャランティー」といい、発注元である自動車メーカーが外注先を評価するときの重要な対象となる。

非メーカー企業の場合

メーカー以外の企業における外注関係ではどうだろうか？たとえば中小小売業者が卸売業者に期待している機能を項目別にみると、

したがって品揃えが充実しており、注文に対して迅速な配送のできる卸売業者ほど、小売業者からの評価が高いことになる。

また中小製造業者が卸売業者に求めている機能は次のようになっている。

品揃えの充実を評価することは小売業者と同様であるが、自らの製品の顧客を増やすための販売促進機能を重要視しているところに特徴がある。

部品外注などの下請け先となる中小企業は本質的に次のような問題を抱えていることが多い。すなわち、技術水準が十分でない、老朽設備が多い、納期・品質管理が悪い等である。したがって中小企業が評価されるためには、大企業にはないオリジナルな自前の技術を持つことが必要になる。たとえば部品提供の中小企業においてオリジナルな自前の技術があれば、完成品製造の大企業は新製品開発のたびにそこへ新しい研究開発の要請をもちこんでくるようになる。発注側が高く評価する外注先はこのような企業である。

一方研究開発プロジェクトにおける外注先の場合は、その企業が高い専門技術をもっていることが前提だが、それでも経営戦略やプロジェクト・マネジメント手法には企業ごとにかなりの差があると考えられる。発注側は、専門技術以外に経営能力や管理能力等、企業全体の力を評価する必要がある。

top
■■ 6-5-2 外注業務の事後評価

前項までのような評価・選定・契約の作業は、プロジェクト推進のために最適な外注先を見つけ、それらを管理するためにたいへん重要なことである。しかし本質的に一度きりの活動であるプロジェクトで全てを予測することは不可能であり、プロジェクト終了後になってようやく明らかになる事柄も少なくない。またプロジェクト開始前の外注先の評価作業で今までつき合いのなかったベンダーを調査する場合などは、表面的な資料に頼らざるを得ず、十分な外注先の能力評価がおこなえないこともある。多くの場合外注先の能力評価はプロジェクト開始前に比べて、プロジェクト終了後のほうがはるかに容易である。

外注先の能力評価のためにプロジェクト終了後に分析する場合には、提案書及び契約書の中に書かれた品質、納期、コストに関する仕様の達成度合いだけでなく、外注先内部での請負プロジェクトが成功したかどうかを見極めることが重要である。分析事項の主なものは、

等である。発注側から見てたとえ品質、納期、コストが契約通り満足されたとしても、ベンダー内部でコスト超過が起こっていれば、プロジェクトは成功したとは言えない。ベンダーの能力を正しく判断し損なった結果のベンダーへのしわ寄せは、結局次のプロジェクトで発注側が付けを支払うことになる。

このようにプロジェクト終了後に、プロジェクト全体の総括だけでなく、機能を果たした全ての外注先について分析をおこなうことは、外注先の能力を正しく評価し、次のプロジェクト時の外注先選定の資料として大きな意味を持つ。ほとんどの組織ではプロジェクトのたびに外注先を全く新しくすることはまれで、たいてい継続したつき合いを続けている。これは外注先選定の作業を省くことが目的であるが、反面なれ合いのつき合いによって、プロジェクトにおける外注の最適化がおこなわれていない場合もある。プロジェクトの事後評価は、次のプロジェクトの事前評価だということを認識することが必要である。

以上のように重要な役割を持つ事後評価であるが、国内ではほとんどきちんとした外注先の事後評価がおこなわれていないのが現実である。その原因として、たとえば情報部門のアウトソーシング等の場合はベンダー側の能力が発注側を上回っているとか、組立メーカーにおける部品外注の場合は子会社方式による無競争状態等が挙げられる。しかし日本においては従来大規模プロジェクトのマネジメント手法自体に注意が払われておらず、納品されればそれで終わりの、いわゆるやりっぱなしのプロジェクト管理が日常であったことが根本的な原因である。

外注業務の評価はプロジェクト終了後の事後評価に重点があるが、プロジェクト開始前や進行中の準備がなければ不可能である。一般的な外注評価プロセスは以下のようになる。

1.および2.はプロジェクト開始前に、3.はプロジェクト進行中におこなわれる。実績データは統計情報として収集されるが、その種類は、

などである。これらを業務別、開発グループ別、工程別に整理して実績データとする。これらのデータは会社組織や開発システム、プロジェクトの状況によって要求されるものは異なるから、計画と実績との差異分析や評価基準との対比がしやすいように整理することが重要である。このときの留意事項としては、

等が挙げられる。外注品の納入時には検収テストをおこなうのが普通である。その際テストを容易におこなうためには、システム開発外注を例にとると以下の事柄に留意する必要がある。

次に結果評価の段階では、コスト、生産性、品質のそれぞれに対して目標値と実績値の差異分析をおこなう。コストに関しては各作業毎の予算と実績、あるいは利益率を分析し、品質に関しては、機能性、信頼性、使用性、効率性、保守性の他、ユーザーの満足度やトラブル発生率も評価項目となる。品質に関する評価は、たとえば自動車部品の外注では次のようにおこなわれることがある。各段階での評価対象は、

これら1〜4は順に評価され、承認を得たあとで次のステップに進むことになる。 また生産性を測る尺度の例としては、次のようなものがある。

1. ステップ数／人月

最終成果物であるモジュール中心に捉えるもので、実務上よく使用される。

2. 文書量／人月

ドキュメントのページ数の正確な定義が必要であり、開発プロジェクトによるバラツキも大きく、標準値の判断が難しい。

3. 人月／1000ステップ

1とは逆に、生産性を作業単位ではなく、コスト単位で考える場合の表現法である。

また納期の評価では進捗目標と実績対比の表を作成して差異分析をおこなう。このような差異分析をおこなう際には、

等を心がけておく。また計画と実績は１対１で対比するのが原則であり、総実績値だけではなく、要件や機能ごとの実績値も管理して、発生した作業が当初の見積り要件に対するものであるかどうかを的確に把握していくことが必要である。これは開発規模の実績の中には、プロジェクト進行過程における新たなユーザー要件の発生、システム処理の都合による新たな処理の追加、バグに対する修正作業の発生等、当初の見積りには予定していないような工数が含まれ得るからである。また開発規模の増加要因と減少要因とが同時に発生してそれらが相殺し合うような場合には、結果的に計画と実績との間の差異が消えてしまうことも考慮しておかなければならない。

top
■■ 6-6 次回プロジェクト外注先の選定方法

これまでのやり方によって外注業務の事後評価が終われば、それを次回プロジェクトにおける外注先選択の条件として用いることができる。すでに述べたように、外注先の評価は品質、コスト、納期等、プロジェクト・マネジメントの全ての面からおこなわれる必要がある。しかしそれをもとにした外注先の選択になると、選択作業の容易さや客観性を考慮して、どうしてもコスト重視の選択をおこなう場合が多い。この場合もっとも単純なやり方が市場原理による方法である。すなわちプロジェクト毎に複数の企業を競わせて、短期的にコスト最小の外注先を選択することになる。この方法によって期待される利点は、

一方予想される欠点は、

等である。

ここで考慮しておかなければならないのは「取引コスト」の概念である。「取引コスト」とは委託内容や条件の設定、契約のための交渉、契約事務、 業務の監視、問題が生じた場合の対応に要するコスト、時間のことであり、一般には内製より外注の場合に大きくなる。これは外注の場合、契約仕様の明確化や取引実施の監視等が不可欠なためであるが、取引の継続とともに取引コストは低下する傾向がある。市場原理を導入しての外注先選択をおこなう際には、単に購入価格だけでなく、その企業と取引する場合の「取引コスト」も含めた総合的なコストを評価しなければならない。

米国のある損害保険会社では、自動車損害保険の保険金支払いのための損害調査機能を複数の自動車修理工場に委託している。これは損害調査を自らおこなうより、修理工場に委託した方が調査の処理速度が速くコスト効率が低くなるという利点があるためである。一方修理工場にとっては、損害を大きく評価した方が修理費用収入が増えることになるため、修理費の過大請求が発生する恐れがある。これに対して損害保険会社は毎年、とくに請求額の大きい修理工場との外注契約を解除するというやり方で外注先の選別を図っている。修理工場側としては契約解除につながる危険があるため過大な請求がやりにくくなるのである。

この方法はコストのみで外注先を選択するやり方であり、評価の過程が単純で客観的な方法である。ただしこの評価方法が使えるのは、複数の外注先の能力にほとんど差がなく、品質や納期において差別化できない場合に限られる。

相手の専門技術を期待して外注をおこなう場合、必ず直面するのが情報の非対称性の問題である。すなわち受注側に知識が多く、発注側は知識が少ないため、受注側はこの情報面での優位性を自分の利益のために用いようとする。これに対して発注側が劣位を克服するために、自らの知識レベルを向上させるやり方もあるが、これは外注業務のパフォーマンスを最大化することにはつながらない。確かに同じ知識レベルをもつ外注先に対してはマネジメントが容易になるが、自らの知識レベル向上のためのコストを考えると、このやり方ではマネジメントに成功してもプロジェクト成果の品質を高めたことにはならないのである。

したがって発注者にとって重要なことは受注者との知識レベルの著しい差異を前提に、高いレベルのマネジメントを実施することであり、当該業務の専門家であるよりも、マネジメントの専門家であることが求められる。この考え方に立てば、外注先を選択する際には自らの知識レベルとは関係なく、できるだけ高いレベルの相手を選ぶことが、プロジェクト成功の鍵となるのである。

top
■■ 7 プロジェクト全体の事後評価

前章で述べたプロジェクト・マネジメントとその中の外注管理はプロジェクトを成功させるための重要な鍵である。これらの手法の有効性はプロジェクトが成功して初めてはっきりと示すことができるが、それではプロジェクトがどの程度成功したかを判断するためには何を評価すればよいのだろうか？プロジェクトの進行とともにもたらされる結果はたいへん多く、また複雑である。本章ではプロジェクトやその中の外注業務、そして外注先の企業の何を対象として評価をおこなうべきかを述べる。

評価対象

プロジェクト・マネジメントおよびその中の外注業務のマネジメントはプロジェクトを成功させるための重要な鍵であり、本節ではプロジェクトやその中の外注業務、そして外注先の企業の何を対象として評価をおこなうべきかを述べる。

プロジェクトにおける主な制約条件は品質、納期、コストである。したがってプロジェクト・マネジメントにおいて評価をおこなう対象も上の3つとなる。すなわち品質が目標通りか、納期が守れたか、コストは予算通りであったか、を評価することによって、そのプロジェクトが成功したかどうかの判断ができる。

ここで納期およびコストに関する評価は比較的容易である。納品の日時は誰の目にも明らかであるし、正しくコストが集計されていれば、プロジェクト全体のコストは数字で表れることになる。一方品質の評価はそれほど簡単ではない。ソフトウェアは目に見えるものではなく、品質の水準を理論的、統計的に測定することは困難なためである。たとえばソフトウェア品質の定義についてはBoehmモデルやISO9000-3モデルが提案されており、プロジェクトの各フェイズにおける実際の評価ではそれらの指標をできるだけ定量化して評価項目として用いることになる。

政府主導の大規模研究開発プロジェクトでは、実際の開発作業を複数の企業に外注するのが普通である。そこでここでは特にプロジェクトにおける外注業務の評価対象を考える。プロジェクトにおける外注結果の分析事項の主なものは、

等である。これらの評価対象には、比較的統計データが得られやすい定量的評価項目と、評価者の主観に影響されやすい定性的評価項目がある。前者の例として、

等があり、後者の例として、

等が挙げられる。

研究開発プロジェクトにおける外注先の場合は、その企業が高い専門技術をもっていることが前提だが、それでも経営戦略やプロジェクト・マネジメント手法には企業ごとにかなりの差があると考えられる。発注側は、専門技術以外に経営能力や管理能力等、企業全体の力を評価する必要がある。

評価方法

前述した様々な評価対象はいずれもプロジェクトや外注業務の成功度を測る重要な尺度であり、これらを正しく評価してマネジメントにフィードバックすることが必要である。ここで注意すべきことはその評価が客観的におこなわれるということであり、プロジェクト・マネージャーにとって正しい判断を可能にする根拠が得られることになる。また多数のメンバーをかかえる大規模なプロジェクトでは、評価の公正さがチームワークの鍵となる。ここではプロジェクトや外注業務の評価をどのようにして上手くおこない、外注先選定などの役に立てることができるかについて述べる。

プロジェクトの成果を評価するには、まず評価のための組織を構成しなければならない。評価を公正におこなうためには、プロジェクトマネージャー個人の意見のみでなく、当該プロジェクトに携わった複数の関係者の意見によって評価を実施する必要がある。開発部門だけでなくユーザー部門からも評価者を参加させて、実作業における評価をおこなえるようにする。その際全てのユーザー部門から偏りなく評価者を集め、各ユーザー部門間の調整を取りながら大局的な観点での評価をおこなうことが重要である。

プロジェクト終了後の事後評価では、完成したシステムに対して上記の評価対象に関する評価をおこなう。一方プロジェクト・マネジメント手法としてPPP(Phased Project Planning)を用いた場合、分割された各フェーズをさらに小さな作業単位（タスク）に分割して、各タスクの最初に“計画タスク”、最後に“評価タスク”を新たに挿入し、評価タスクにおいて当該タスクの評価をおこなうことになる。

システム開発を例にとると、品質を評価する具体的な方法は大きく分けて以下の3段階になる。

一方納期やコストに関する分析をおこなうときには、機能の達成度（品質）とは無関係に評価をおこなわなければならない。品質が目標を達成できなかったプロジェクトの評価をおこなう際には、しばしば外注先での進捗の遅れを暗に仮定しがちであるが、機能未達成の真の原因はプロジェクトメンバーの選定ミスや仕様の不備にあったかもしれないからである。

またプロジェクト終了後にはプロジェクト完了報告書を作成するのが一般的であるが、それに含まれるべき内容は以下の通りである。

次に外注業務の評価方法について述べる。外注業務の評価はプロジェクト終了後の事後評価に重点があるが、プロジェクト開始前や進行中の準備がなければ不可能である。一般的な外注評価プロセスは、

(1)および(2)はプロジェクト開始前に、(3)はプロジェクト進行中におこなわれる。実績データは統計情報として収集されるが、その種類は、

などである。これらを業務別、開発グループ別、工程別に整理して実績データとする。これらのデータは会社組織や開発システム、プロジェクトの状況によって要求されるものは異なるから、計画と実績との差異分析や評価基準との対比がしやすいように整理することが重要である。

次に結果評価の段階では、コスト、生産性、品質のそれぞれに対して目標値と実績値の差異分析をおこなう。コストに関しては各作業毎の予算と実績、あるいは利益率を分析し、品質に関しては、機能性、信頼性、使用性、効率性、保守性の他、ユーザーの満足度やトラブル発生率も評価項目となる。また納期の評価では進捗目標と実績対比の表を作成して差異分析をおこなう。

計画と実績は１対１で対比するのが原則であり、総実績値だけではなく、要件や機能ごとの実績値も管理して、発生した作業が当初の見積り要件に対するものであるかどうかを的確に把握していくことが必要である。これは開発規模の実績の中には、プロジェクト進行過程における新たなユーザー要件の発生、システム処理の都合による新たな処理の追加、バグに対する修正作業の発生等、当初の見積りには予定していないような工数が含まれ得るからである。また開発規模の増加要因と減少要因とが同時に発生してそれらが相殺し合うような場合には、結果的に計画と実績との間の差異が消えてしまうことも考慮しておかなければならない。

これまでのやり方によって外注業務の事後評価が終われば、それを次回プロジェクトにおける外注先選択の条件として用いることができる。すでに述べたように、外注先の評価は品質、コスト、納期等、プロジェクト・マネジメントの全ての面からおこなわれる必要がある。しかしそれをもとにした外注先の選択になると、選択作業の容易さや客観性を考慮して、どうしてもコスト重視の選択をおこなう場合が多い。この場合もっとも単純なやり方が市場原理による方法である。すなわちプロジェクト毎に複数の企業を競わせて、短期的にコスト最小の外注先を選択することになる。

相手の専門技術を期待して外注をおこなう場合、必ず直面するのが情報の非対称性の問題である。すなわち受注側に知識が多く、発注側は知識が少ないため、受注側はこの情報面での優位性を自分の利益のために用いようとする。これに対して発注側が劣位を克服するために、自らの知識レベルを向上させるやり方もあるが、これは外注業務のパフォーマンスを最大化することにはつながらない。確かに同じ知識レベルをもつ外注先に対してはマネジメントが容易になるが、自らの知識レベル向上のためのコストを考えると、このやり方ではマネジメントに成功してもプロジェクト成果の品質を高めたことにはならないのである。

したがって発注者にとって重要なことは受注者との知識レベルの著しい差異を前提に、高いレベルのマネジメントを実施することであり、当該業務の専門家であるよりも、マネジメントの専門家であることが求められる。この考え方に立てば、外注先を選択する際には自らの知識レベルとは関係なく、できるだけ高いレベルの相手を選ぶことが、プロジェクト成功の鍵となるのである。

top
■■ 8 プロジェクト・マネジメントのケーススタディ　〜IMGプロジェクトの場合〜

IMGプロジェクトの目的

1996年2月に打ち上げられる地球観測プラットホーム技術衛星 ADEOS (Advanced Earth Observing Satellite)( 地球環境監視及び観測システム技術の開発を目的とした人工衛星。宇宙開発事業団、通商産業省、環境庁、NASA、フランス宇宙開発センターが共同で開発。重量3.5トン、軌道傾斜角98.6度、周期101分、回帰日数41日)に搭載されるIMG(Interferometric Monitor for Greenhouse Gases)センサーとそのデータ通信・解析・検証システムを開発し、運用する。

本プロジェクトではIMGセンサーを用いて地球全表面の観測を行い、大気温度、炭酸ガスなどの濃度を求めることによって、赤外線を放射する温室効果気体の発生源と消失先を知ることを目的としている。

プロジェクト・メンバー
本プロジェクトは通商産業省が電力中央研究所に委託して実施している。したがってプロジェクト・マネジメントは電力中央研究所の担当者が行う。グループ別のメンバーは

また上記のプロジェクト・メンバーの業務形態レベルはおおよそ次の３段階に分けられる。

レベル1：ネットワーク利用
ワークステーション端末を持ち、日常的に利用している。作業成果の他、スケジュール、予算、作業進行状態などの管理もコンピュータ上でおこなっている。

レベル2：ネットワーク非利用
日常的にパソコンを利用して、文書作成など個人的作業を行っている。スケジュール、予算、作業進行状態などの管理は紙の上でおこなっている。

レベル3：コンピュータ非利用
コンピュータをほとんど利用していない。日常的に利用する情報機器は、電話機とFAX程度。

プロジェクト・メンバー全体の中での構成割合は、レベル１が２割、レベル２が５割、レベル３が３割程度である。したがってここでは、レベル２以下のメンバーを対象としてプロジェクト・マネジメント手法を考慮する。

プロジェクトの進み方

プロジェクト実施時期は1990年〜2000年頃。本プロジェクトの進行形態はおおよそ次の３段階に分けて考えることができる。

各段階においておこなわれるプロジェクト・メンバー間のコミュニケーション（会議・打ち合わせ）は、(1)→(3)の順で構成メンバーが多様化し、(3)→(1)の順で技術的内容が増加する。作業内容が実質的に決定されるのは(2)の段階。したがって(2)の段階でのプロジェクト・マネジメントが重要となる。

マネジメントの対象

等が考えられる。

top
■■■ 8-1 IMGプロジェクトの成功のために

ここでは第１章で述べたプロジェクト・マネジメント手法をもとに、IMGプロジェクトを効率よく推進し、成功させるための考え方を示す。

1. 確立されたマネジメント手法を正しく理解する。
まずやらなくてはならないのは、1.1.3で述べたマネジメント手法の正しい理解である。これらの手法は主にプロジェクト・マネジメント先進国のアメリカで開発されたものであり、兵器開発などの大規模プロジェクトに関して相当な実績がある。従来マネージャーが無意識のうちにやってきたことでも、それを科学的手法として明確に意識することで、その適用効果は飛躍的に高まる。

2. メンバー全員に仲間意識を育て、結束を強める。
共通の仲間意識にあふれた結束の強いプロジェクト・メンバーの生産性はたいへん高いが、一般的にプロジェクトの規模が大きくなるほどそれを育てるのは難しくなる。とくに本プロジェクトのように別々の組織の異なったバック・グラウンドを持ったメンバーが、それぞれ別の仕事もやりながら離れた場所で作業を行う場合、その困難は最大になる。これに対してプロジェクト・マネージャーができることは、常に小さな機会を見つけては自分の顔を見せ、またメンバー同士が顔を合わせる場をつくることである。その際プロジェクト作業とは別の、ちょっとした共同作業を行えばなお効果は高まる。

3. メンバー全員がプロジェクト・プランを十分納得する。
メンバーは、プロジェクトの目標とプランを完全に納得した場合にのみ仕事に熱中し、自ら品質と生産性を上げようと努力し始める。したがってプロジェクトの開始時にメンバー全員がプロジェクト・プランを十分納得しておくのは、とくにこのような長期にわたる複雑なプロジェクトの場合に重要となる。その際大切なことは、詳細で正しい情報が流れることである。さばを読んだ納期がもたらすものは、マネージャーへの信頼の失墜とメンバーの士気の喪失だけである。マネージャーにできるのは、メンバーを働かせることではなく、メンバーに働く気を起こさせることだけである。

4. メンバー全員が業務形態レベルの向上を図る。
プロジェクトにおけるコミュニケーションの手段としては、最新の情報技術を利用した文書連絡の手法が有効である。しかし本プロジェクトのようにメンバーの業務形態レベルがバラバラな場合は、必然的に最低レベルのメンバーにあわせるほかなく、これらの手法が上手く使えない。そこでマネージャーはとくに、先に定義したレベル３のメンバー（しばしばプロジェクトの中で重要な役割を果たす人達である）に対して、パソコンを扱える程度のレベル２への転換の支援を行う必要がある。これによって全員が電子メールを利用できるようになって手法の有効度は大幅に高まる。

5. 委員会の運営を効率化する。
今までのところ本プロジェクトにおける委員会は「調整のための会議」として正常に機能しているが、会議を効率化するために運用方法に工夫を加えるべきである。すなわち会議で提出する資料は当日配布するのではなく、少なくとも数日前までに参加メンバーに配ってあらかじめ読んできて貰う。同時に予定している議題を示して、当日議論したい内容をメンバーから収集しておくことも必要である。これによって会議当日は開始直後から本質的な議論を行うことができる。このほか会議終了時刻をきちんと決め、会議中参加メンバー全員が常に終了時間を意識しておくことも効果的である。もちろん会議日程の決定から事前の資料配布まで、２章で述べた電子メールを利用した手法を採用すべきなのは言うまでもない。

6. メンバーが、仕事を中断されない職場環境で作業する。
プロジェクト全体の生産性は、結局開発現場における各メンバーの生産性の和に他ならないから、それぞれのメンバーの職場環境を整えることもプロジェクト・マネージャーの責任である。すなわち電話や余計な会議をはじめとして、仕事を中断させ生産性を下げる原因の数々を一つでも多く取り除くよう努めることだ。( アメリカでのある調査結果によると、オフィスワーカーの仕事を中断させる３大原因は電話、同僚からの質問、そして上司の馬鹿話である)

本プロジェクトのようにメンバーが別々の組織に属している場合には、プロジェクト・マネージャーが全てのメンバーの職場環境にまで口を出すのは不可能かもしれない。しかしその場合でもそれぞれの職場の管理職に対して、職場環境の重要性を訴えることはできる。たとえ全てのメンバーが広くて静かなオフィスを持つことはできなくても、電子メールが導入されるだけでも価値はある。

top
■■ 8-2 IMGプロジェクトのための外注管理手法

前節までで外注管理の一般論およびプロジェクト・マネジメントに関して進んだ手法を有している米国の例を紹介した。しかしプロジェクトは全て独自の特徴を持っており、普遍的な外注管理手法が存在するわけではない。本節ではこれらの成果を参考にしつつ、IMGプロジェクトのために有効であると思われる外注管理の方針を、1.1.2で述べた外注業務の流れに沿って提案する。なおIMGプロジェクトの概要については文献を参考にされたい。

1.　外注候補先の調査および評価を常におこなっておく
外注候補先の調査や評価を、プロジェクトが始まってからおこなうのでは遅すぎる。プロジェクトによらないベンダー固有の能力に関するデータをあらかじめ持っていることが、発注先選定作業の前提となる。また既に評価を行った外注先に対しても、とくに担当者の移動について把握しておく必要がある。結局のところ研究開発的なプロジェクトの成否は個々のメンバーの能力に依存しており、内部のメンバーに対するのと同じ意識で、外注先の担当者を管理しなければならない。

2.　外注候補先の調査をおこなうときには発注側が主体的におこなう
新規外注候補を捜すときには、ベンダーの営業に頼る待ちの姿勢ではよりよい外注先を見つけることは難しい。優れたベンダーは顧客を選択しようとするものである。待っていれば営業に来るベンダーではなく、営業に来てもらうベンダーを捜さねばならない。米国自動車産業界でも「顧客最適化」（Customer Optimization）と呼ばれる優良顧客への絞り込みが始まっており、発注側は自らが優良顧客となりうることを積極的にベンダーにアピールすることが求められている。

3.　基本計画策定の段階から外注を用いる
NASAの例で見られた計画定義の段階をプロジェクトに取り入れることは、プロジェクトの成功そのものに重要な役割を果たすだけでなく、企画の段階から外注を参加させることによって、その後の設計・開発段階での混乱を最小限に抑えて外注管理を容易にする効果があるとともに、早い時期に外注先の能力を判断する機会ともなる。したがって募集するベンダーは設計・開発段階での契約を念頭に置いたハードウェアおよびソフトウェア・メーカーである。

4.　外注先の選定に際しては複数社を競わせる
プロジェクトの開始時に外注先を選定するときには従来のつき合いだけに頼らず、広く候補を集めてあらためて選定作業をおこなう。明確な基準を示して公募するようにすれば、競争によってベンダーの士気が高まり自ら品質や生産性向上の努力をおこなうようになる。場合によってはプロジェクトの一部を複数社に発注して競争させることによって、よりよい成果を上げられる可能性が高い。この場合は得られた成果の長所のみをまとめて利用することができる。

5.　見積書に含まれる内容を発注側で明確に規定する
外注候補先に見積りを依頼するときは、発注側の要求をあらかじめきちんと伝えなければならない。複数の候補先にやみくもに見積を依頼しても、ベンダーによって形式の異なる見積書が提出される結果となり、外注先選定のための適切な比較検討ができない。発注側はRFPを作成してベンダーに提示し、さらに大規模プロジェクトの場合はWBS、TRM等の、ベンダー内部のプロジェクト管理体制を明らかにする資料を要求するのがよい。

6.　見積金額の安易な買いたたきは避ける
発注側はコスト見積りに関して明確な基準を整え、合理的な見積金額の査定をおこなわなければならない。提出された見積金額に対して1割まけろ式のやり方は、外注先がそれを飲めば、無理なコストダウンのために結局納入品の品質低下につながるかもしれない。またこのような値下げ交渉を毎回おこなっていると、ベンダーはやがてあらかじめ1割価格を上乗せした見積金額を提示するようになる。

7.　外注先選定のための入札方式は注意深く用いる
研究開発的要素の強いプロジェクトにおいては、まず要求される品質を指定納期で達成できるかどうかの基準で外注先を選ぶことが重要である。最低価格を追求する入札方式は各ベンダーの生産性を測る尺度になるが、ベンダー同士の談合の危険性だけでなく、無理な価格競争の結果もたらされたコストダウンを吸収しようとして、納入品の品質低下を招く恐れがある。価格のみによる外注先選定は、見積書の技術的評価を回避した結果であると言えなくもない。

8.　見積り作業を発注する
現在ほとんどの場合ベンダーの営業活動の一環として、発注側から見るとコストをかけずにおこなわれている見積りは、プロジェクト計画の定義という重要な作業を含む計画段階である。発注側にとっては見積り作業を発注し、コストをかけておこなえばプロジェクトの計画定義をきちんとおこなう機会が生まれるし、ベンダーにとっても手間をかけてよりよい見積書を作成することができるようになる。結局のところ無料に見える見積作業のコストは設計・開発契約の中で外注先によって回収されているのである。

9.　期間契約方式を導入する
日本ではプロジェクトにおける外注は設計・開発段階からおこなわれるため、多くの場合契約は一括請負契約方式でおこなわれている。しかし目標分析や計画定義段階を含めて発注する場合には、とくにプロジェクトが研究開発的要素が強い場合に、期間契約方式の導入によって発注側、受注側双方のリスクを減らすことができる。二分割期間／請負契約や多分割期間／請負契約によって、分割された各段階の契約に関して無駄なコストをかけずに済むようになる。

10.　プロジェクト過程にマイル・ストーンを設け外注先のレビューをおこなう
PPPによるプロジェクト管理をおこない、フェイズの区切りにマイルストーンをおいて外注作業をレビューする。大規模プロジェクトにおいてはWBSによって分割された多数の作業に対して外注がおこなわれるため、このレビュー時点で作業進行の同期をとることになる。問題の多い外注先に対してはその原因を追究して対策を練るとともに、場合によっては次の段階の契約を結ばないこともあり得る。

11.　プロジェクト終了後に事後分析レポートを作成する
NASAでおこなわれているように、プロジェクト終了後事後分析レポートを作成してプロジェクト全般を評価することはきわめて重要である。外注管理に関しても、事前に正確に見積もるのが困難であった納入品の品質、納期および個々の作業に要した期間、コスト内訳等は、プロジェクトが終了してしまえば数値データとして容易に得られる。外注先の能力を評価するためには格好のデータが得られるのである。プロジェクトの事後分析は次のプロジェクトの事前評価であるということを認識しなければならない。

12.　プロジェクト管理のトップを委員会ではなく１人のプロジェクト・マネージャーにする
今まで述べた外注管理の方針をプロジェクトの中で実行していくためには、しばしば強いリーダーシップが必要になる。日本では新しいプロジェクトを始める場合、まず関係機関のメンバーを集めて委員会を発足させるが、これは調査をさせて利害調整を図る組織であって、新しいことを決定できる組織ではない。本当に新しいことはたとえ二人の人間の間であっても一致は困難である。巨大プロジェクトを成功させるトップ・マネジメントは、たった１人の優秀なプロジェクト・マネージャーによる場合が多い。

top
■■ 8-3 プロジェクトのための外注評価手法

前節までに、プロジェクト・マネジメントにおける外注業務の評価手法について、システム開発と製造業およびNASAの例を紹介しながら述べた。しかしプロジェクトは全て独自の特徴を持っており、普遍的な外注業務評価手法が存在するわけではない。本章ではこれらの結果を参考にしつつ、IMGプロジェクトのために有効であると思われる外注業務評価の方針を、外注管理の流れに沿って提案する。なおIMGプロジェクトの概要については文献を参考にされたい。

1. 外注業務評価はプロジェクトのあらゆる段階でおこなう
プロジェクト終了後の事後評価だけが外注業務評価ではない。プロジェクト開始前の外注先選定のための事前評価、プロジェクト進行中におこなわれるフェイズごとの作業のチェック等もすべて外注業務評価である。プロジェクト・マネジメントの中でいったん外注を取り入れることを決定したなら、プロジェクトマネージャーは常に、評価の2文字を意識し続けなければならない。

2. 外注業務評価のための組織を作っておく
外注業務の評価や外注先企業の選定は、研究開発プロジェクトの成否を決定するほど重要で、かつ容易な作業ではない。これをプロジェクト・マネージャー１人がおこなうのは実際には不可能である。したがってプロジェクト開始前に、外注業務の評価を専門におこなう組織をプロジェクトメンバーの中に作っておく必要がある。マネージャーはこの組織の評価に基づいて決定をくだすことになる。

3. 外注業務評価作業を外注する
2.で述べた外注業務評価組織は成果の技術的評価をおこなうことを目的としているので、プロジェクトを遂行する組織の内部ではメンバーを調達できないことも考えられる。このような場合には外注業務評価作業自体を外注するのがよい。これによってむしろ客観的な評価が可能になる場合も多く、プロジェクト・マネージャーは冷静な決断者としての職務に専念できる。

4. 外注候補企業の評価を事前におこなっておく
外注候補企業のプロジェクトによらない固有の能力は、これまでの実績を調査することによって評価できる。その際の評価対象には専門技術だけでなく、その企業の経営能力やプロジェクト・マネジメント能力も含まれる。その企業が過去のプロジェクトにおいて、品質や納期、コストのマネジメントにどの程度成功したかを評価するために、成果物の調査や顧客へのインタビュー等をおこなう。

5. 複数の外注先企業間で相対的な評価をおこなう
長期にわたる大規模プロジェクトの場合、WBSによって全体の作業を細分化するのが普通であるが、その際作業ごとにできるだけ別々の企業に発注すべきである。能力評価の絶対基準が定義しにくい研究開発プロジェクトでは、複数企業同士の競争状態を含むプロジェクトの進行中および完了後に企業間の相対評価をするのが有効である。

6. プロジェクト進行中の外注業務評価計画を立てておく
いったんプロジェクトが始まってしまうと、プロジェクト・マネージャーは作業そのものの管理に気を取られて、外注評価が後回しにされがちである。これを防ぐためには、評価対象に対する評価項目を事前に設定し、実績データ収集方法、評価方法などについての詳細な外注業務評価計画を立て、機械的な作業でプロジェクト進行中の評価作業がおこなえる準備をしておくのがよい。

7. 差異分析によって結果を定量的に評価する
外注業務の結果を客観的に評価するためには、目標値と実績値の差異分析が有効である。コスト、品質、生産性のそれぞれに対してあらかじめ定量的な目標値を設定しておき、作業終了後に集められた実績値との差を1対1で対比し、分析する。このとき実績データは細分化された各作業ごとに一定の間隔で収集し、表やグラフの形に整理しておくことによって、プロジェクトの全体像やトレンドの把握が容易になる。

8. 品質の評価項目にはできるだけ数値的な定義をしておく
外注業務の管理対象の中で、成果の品質はもっとも評価が困難な対象である。「優れている」、「普通」、「劣っている」式の定性的な評価指標では客観的な評価ができず、評価者の主観に左右されやすい。システム開発におけるソフトウェアの品質評価基準等を参考にして、できるだけ数値によって定量的な評価のできるように評価項目を定義しておくべきである。

9. 品質の評価対象には「効果」の他に「効率」を含める
NASAに関する項で述べたように、先端的研究開発プロジェクトの場合は成功の尺度さえ明確でないこともあり、品質評価の指標の定量的定義が不可能な場合もある。このようなときは、それぞれの外注企業がその成果をどれだけの時間、コストあるいはどのような過程で達成したかという、品質効率によって成果を定量的に評価することが可能である。

10. コストを評価する場合には「取引コスト」も重視する
コストによって外注業務を評価する際には購買価格だけでなく、外注先企業との契約事務、進捗管理、品質評価等に関する時間的コストを考慮する必要がある。たとえ購買価格を低く抑えることができたとしても、上記の外注管理業務がスムーズに運ばなければ、結局プロジェクト推進組織の内部では高コストが発生する。優秀な外注先企業は最小の取引コストで業務をおこなえるのである。

11. 納期の評価は多数回おこなう
大規模な研究開発プロジェクトにとって、各外注業務の納期の制約はとくに厳しいが、最終納期が守れたかどうかだけで外注業務を評価するのは不十分である。途中の作業遅れを取り戻すために品質保証がなおざりにされるケースを見落とさないためには、プロジェクトの進行中に何度も目標と納期を設定して、短い間隔で納期評価をおこなうべきである。これは各フェイズでの外注先企業の生産性を評価することになる。

12. プロジェクト終了後に外注業務評価報告書を作成する
プロジェクト完了時にプロジェクト完了報告書を作成することがよくおこなわれるが、それとは別に外注業務の評価に焦点をあてた報告書を作るべきである。これまで述べた評価方法を用いて、外注の成果や外注先企業の能力を事実に基づいて評価した結果を文書にしておくことによって、次回のプロジェクトでの外注評価の客観的な根拠になるとともに、プロジェクト・マネージャーが自らの能力を洗練させていくことができる。

top
■■ 8-4 推進過程からみたIMGプロジェクトの分析　〜その理論モデル〜

前節ではプロジェクトおよび外注業務の評価手法について述べた。本節では実際のIMGプロジェクトに関して、そのマネジメントがどうおこなわれたかについての分析をおこなう。

プロジェクトの推進過程を評価するためには、まず理想的なプロジェクト推進過程を定義しておく必要がある。ここではこれまでの研究成果をもとに、IMGプロジェクトに対するマネジメントの理論モデルを提示する。以下の理論モデルはIMGプロジェクトの開始から終了までの間に、プロジェクト・メンバーがおこなう作業項目を時間順に並べたものであり、同時にプロジェクト・マネージャーのマネジメント項目でもある。

top

■■ 8-5 IMGプロジェクト推進の実態

IMGプロジェクト構想は1989年に始まった。宇宙開発事業団（NASDA）の計画した地球観測衛星ADEOS（Advanced Earth Obsearving Satellite）に搭載されるセンサの一つとして、二酸化炭素などの温室効果気体ガスの濃度を測定する目的で通商産業省（MITI）が地球体機観測を提案したのが始まりである。

MITIはIMGセンサプロジェクト全体を、センサ本体であるハードウェア開発、データ解析のためのソフトウェア開発、データ処理のための地上システム開発の3つに分けて発注する形をとった。それぞれを受注したのはハードウェア開発が（財）資源探査用観測システム研究開発機構（JAROS）、ソフトウェア開発が（財）電力中央研究所（CRIEPI）、地上システム開発が（財）資源・環境観測解析センター（ERSDAC）である。これらの組織は各部門のプロジェクト・マネジメントを担当するが、その支援を目的として各種専門委員会が付置された。専門委員会のメンバーは大学や国立研究所等の研究者で構成されており、随時会合を開いて技術的内容を検討するとともにプロジェクト推進に関わる多くの意志決定をおこなった。

ハードウェアやソフトウェア等の実際の開発はこれらの組織を通じて民間企業に発注された。JAROSから衛星本体の開発を受注したのはF社であり、CRIEPIからソフトウェア開発を受注したのはB社、またERSDACから地上システム開発を受注したのはE社である。その他、A社とC社、D社がCRIEPIからそれぞれ技術調査、ソフトウェア開発、試験センサ製作、等を受注した。

top
■■ 8-6 プロジェクト推進の理論モデルと実態の差異分析

分析範囲

IMGプロジェクト全体は多様な組織から構成されているが、MITIによってプロジェクト作業が3つに分割されているため、そのプロジェクト組織構造（OBS）としてはハードウェア開発、ソフトウェア開発、地上システム開発の各部分で同様の形態をとっている。したがって本プロジェクトの推進過程を分析する場合には、その一つに注目して調査をおこなうことにする。ここではCRIEPIを中心としたソフトウェア開発部門を取り出し、プロジェクト全体の典型例として分析をおこなうことにする。ここで分析の対象とするプロジェクト・メンバーは以下の通りである。

また分析の時間的範囲としては、プロジェクトが始まった1989年度から、ADEOSの運用が終了した1997年度までの10年間とした。

分析方法

理論モデルと実態の差算分析は3.2.1で示したIMGプロジェクト推進の理論モデルの流れに沿っておこなう。その際分析の基準は3.1.3でまとめたIMGプロジェクトの評価方針によった。ここで実態分析のための資料は、CRIEPI内で保存されているプロジェクト関連の書類を参考にした。本プロジェクトにおけるソフトウェア開発作業はMITIからCRIEPIへ、さらにCRIEPIからA社、B社、D社に発注されているので、その実態を知るには各々の間の契約関連書類を調査すればよい。また本作業のプロジェクト・マネジメントはCRIEPI担当者を中心としたIMGデータ解析手法検討委員会の承認を得ておこなわれているので、プロジェクト推進過程を示す材料として当委員会議事録を調査した。

同時に本調査では、IMGプロジェクトに携わった各組織の中でプロジェクト・マネージャーの役割を果たした人物、および各委員会の委員長を務めた人物に対してインタビューをおこなった。これによって文書として残されていないプロジェクト推進過程の実状が明らかになり、プロジェクトのマネジメントおよび成果に対する評価をする際の重要な情報が得られた。　

分析結果

(1)　プロジェクト目標設定
ここではプロジェクト開始時にどの程度明確な目標（機能、納期、コスト）を設定したかを調査した。分析対象はプロジェクト開始時において、MITIとCRIEPIの間で取り交わされたIMG研究開発計画に関する文書、および各インタビュー結果である。

分析の結果、文書およびインタビュー結果から、プロジェクト開始当時MITIの掲げた機能目標は衛星搭載センサによる大気中の二酸化炭素を中心とする温室効果気体濃度測定であったことがわかる。ただし測定解像度等の仕様に関する定量的目標は設定されていない。また納期目標に関しては3年程度と記録されているが、本プロジェクトは当時1993年に打ち上げが予定されていたADEOSに搭載されるセンサの開発であるから、実質的にはそれが納期となった。コスト目標に関しては記録は残されているが、数値の根拠は不明である。ただしインタビュー結果から、MITIが過去の衛星開発予算を参考にして設定したものと考えられる。

(2)　プロジェクト・チーム結成
ここではプロジェクト開始時にどのようなプロジェクト・チームが結成されたかを調査した。とくにプロジェクト全体およびメンバーとなる各組織の中でプロジェクト・マネージャーが正しく選定され、さらにプロジェクト遂行中様々な評価作業をおこなうメンバーが用意されたかどうかを知るのが目的である。分析対象は各委員会の委員名簿ならびにインタビュー結果である。

IMGプロジェクトにおけるソフトウェア開発部門では、CRIEPIがプロジェクト・マネージャーとなり、実際の開発作業を複数のメーカーに発注している。同時に、付置されたソフトウェア委員会が評価作業ならびに意志決定支援作業を担当しており、プロジェクト遂行上当委員会の果たす役割はたいへん大きい。

そこでプロジェクト全期間におけるソフトウェア委員会の構成メンバーの推移を調査した。その結果、委員会の委員総数21人のうち、プロジェクトのほぼ全期間を通じて委員を務めたのが8人であった。また、 IMGプロジェクトに関わったMITIの担当者はのべ17人におよんだが、最も長いメンバーでも3年間しかプロジェクトに携わっていなかった。

(3)　初期分析
ここではプロジェクトの目標が設定された後、その実現可能性が十分検討されたか、またその結果プロジェクト目標がどのように修正されて基本要求が作成されたかを調査した。分析対象は開発発注前のCRIEPIの文書およびソフト委員会議事録、さらに各インタビュー結果である。

当初、IMGプロジェクト開発発注の打診を受けたCRIEPI内ではその実現可能性を検討し、IMGセンサによるCO2濃度観測の実現性に関しては悲観的な結論を出している。これらの意見はMITIに伝えられるとともに、ソフトウェア委員会でも議論され、本プロジェクトの機能目標が、CO2にこだわらずオゾン等の大気微量成分も観測対象とすることに修正された。ただし温室効果気体濃度の測定という当初の機能目標から見て、その主な成分であるCO2濃度の高精度観測の実現可能性が疑問視されたにも関わらず、本プロジェクト実施の是非の再検討はおこなわれなかった。インタビュー結果も示すように、この段階では、MITIはプロジェクト実施の根拠を得るための研究者の意見を必要としており、その結果主に研究者の興味によって機能目標が設定された。

また納期目標、コスト目標に関しては、開発を担当するメーカー側は初期分析に参加しておらず、それらの実現可能性の検討はほとんどおこなわれなかった。全体としてソフトウェア開発の初期分析は不十分であったことがインタビュー結果にも示されている。

(4)　プロジェクト計画定義
ここではプロジェクト作業を定義するに当たって、それがどのように外注され、WBS(Work Breakdown Structure)や工程計画（PPP:Phase Project Planning）、コスト見積がどのように作成され、その結果精細な計画定義書案が作成されたかどうかを調査した。分析対象は計画定義作業を担当したA社への発注仕様書類やその成果報告書類、またCRIEPIへのインタビュー結果である。

文書およびインタビュー結果から、CRIEPIがプロジェクト計画定義のための技術調査の外注先としてA社を選定した理由は、当社がすでに資源環境技術総合研究所からIMGセンサに関する技術計算を受託していた実績によることがわかる。ただし当社の実績、能力に関してそれ以外の評価をおこなった事実はない。

ソフトウェア委員会の委員の助言を元に、1989年度にA社はソフトウェア開発のWBSを作成した。その成果を受けてCRIEPI内でプロジェクト計画定義がおこなわれ、作成された最初の計画定義が1990年に作成された。ここではソフトウェア開発の全体予算は記載されていない。

MITIでは1990年頃にプロジェクト全体予算の目標を掲げた。その比重はプロジェクト期間の前半に大きく、後半に小さいものであり、その後変更されなかった。

(5)　プロジェクト作業外注先決定
ここではプロジェクト作業を外注するに当たって、どのようにしてRFPが作成され、それに対する提案書の評価の結果どのようにして外注先の選定と契約がおこなわれたかを調査した。分析対象はCRIEPIとB社、D社との契約関連書類、外注先決定に関するソフト委員会議事録とインタビュー結果である。

航空機搭載用小型センサの開発について、CRIEPIではD社に対してRFPを提示し、その後Proposalの評価、契約をおこなった。D社の選定理由は、当時F社を含めた2社以外に実績のあるメーカーがなく、最初F社に打診したもののコスト面で折り合わなかったことにある。ただしD社の能力や実績について、あらためて評価をおこなった事実はない。

最初CRIEPIはソフトウェア開発をA社に発注することを考えていたが、CRIEPI内に常駐する専任作業チームの設置が受け入れられなかったため、理学研究能力の必要性からシンクタンクを外注先候補とし、B社に発注することを決定した。

(6)　作業進捗マネジメント（PDCA:Plan Do Check Action）
ここではプロジェクトの遂行中に、進捗評価計画の作成や進捗実績値の収集が正しくおこなわれたか、そしてその結果実績値の評価されて計画修正がおこなわれたかを調査した。　CRIEPIおよび各メーカーは単年度契約の中でプロジェクト作業をおこなっており、作業進捗度の評価は1年以内の期間に分割しておこなわれた。このとき進捗評価計画の作成や定量的な進捗実績値の収集はおこなわれず、毎月1〜2回程度おこなわれる契約者同士の定期的な打ち合わせ、および各委員会への出席と報告によって定性的な進捗実績のマネジメントがおこなわれた。

ここでソフトウェア開発期間中に作業進捗マネジメントがどの程度の頻度でおこなわれたかを明らかにするために、開発作業が始まった1992年度以降のソフトウェア委員会の開催日程を調べた。期間中34回の委員会が全期間に渡ってまんべんなく開催され、作業進捗マネジメントがおこなわれていることがわかる。

top
■■ 9 プロジェクト成果の分析ケーススタディ　〜IMGプロジェクトの場合〜

前節ではIMGプロジェクトにおけるプロジェクト推進過程に対する評価をおこない、プロジェクト・マネジメントが正しくおこなわれたかどうかを分析した。本節ではIMGプロジェクトが当初の目標に対してどの程度の成果を上げたかについて調査する。ただしIMGプロジェクトはADEOSの運用が終了したものの、取得されたデータの解析作業はこれからであり、研究成果に関する論文の公表もいまだおこなわれていないため、地球観測センサとしての定量的評価を本調査でおこなうことは困難である。

そこでここでは、プロジェクトに関わったメンバーへのインタビュー結果等から、IMGプロジェクトの地球観測センサとしての定性的評価、および各プロジェクト・メンバーにとっての成果という観点から調査をおこなうことにする。調査に際しては前節同様、プロジェクト関連資料とインタビュー結果を利用した。

top
■■ 9-1 IMGプロジェクトの目標

前節でみたように、IMGプロジェクトにおける目標は必ずしもプロジェクト開始時に明確に決められたわけではなく、プロジェクトの進行とともに徐々に具体化され、プロジェクト・チームの中で承認されていったものである。ここではプロジェクトの目標がいつ、どのようにして決められていったかに注目しつつ、機能、コスト、納期の3つの目標について分析をおこなった結果を述べる。

機能

IMGプロジェクト計画が発案された当時、 MITIによれば、このプロジェクトの目的として以下が設定されている。

「我が国としても積極的に当問題（注：地球温暖化問題）に関するデータの蓄積を図るとともに、この問題の解析をおこない得るよう、かつ国際交渉にも備えられるよう、衛星による炭酸ガス等の観測を検討する。」

また「成層圏および対流圏上層部の二酸化炭素、一酸化炭素、窒素酸化物、アンモニアの濃度および水平・垂直分布」を観測すると述べられている。

次にソフトウェア開発を受託したCRIEPIによる1991年3月付のMITIに対する報告書の中には、IMGプロジェクトの目的として「温室効果に係わる各種気体の挙動およびその知見を生かして地球温暖化と電源立地の関連を明らかにすること」と述べられている。さらに2年後の1993年3月付の報告書（平成４年度報告書）ではIMGプロジェクトの実施フレームとして、

の3項目が挙げられている。また同報告書の中ではプロジェクト実施に当たってのアクション・ガイドラインが述べられている。上記フレーム（1）に対応する項目として、

（1-1）温室効果気体の放出量について、わが国と他諸国との比較のできるデータを 取得すること

（1-2）温室効果気体の挙動に関する知見を得ること

とある。また上記フレーム（2）に対応する項目として

とある。さらに上記フレーム（3）に対応する項目として

となっている。

コスト

プロジェクトの初期には、IMGプロジェクトのうちセンサ本体の開発費用として20〜40億円という値が挙げられている。また1989年頃、開発費総額として40〜100億円と記述されている。いずれにしてもIMGプロジェクトが立案された当時、MITIの考えていたコスト目標の数値には大きな幅があった。 その後MITIはハードウェアおよびソフトウェア開発を発注したので、毎年の発注金額によってコスト目標が設定されたことになる。

納期

IMGプロジェクトが始まった1988年当時、ADEOS打ち上げは1993年8月に予定されており、ハードウェアおよびソフトウェアの開発納期は同時期とされた。その後H-IIロケットの開発が遅れたためにADEOS打ち上げが1994年、さらに1995年へと延期され、最終的には1996年8月に打ち上げられた。これに伴ってIMGプロジェクトにおけるハードウェアおよびソフトウェアの開発納期も当初の設定より3年間繰り下げられ、1996年8月となった。なおIMGプロジェクト自体はADEOSの定常運用開始後3+１年間すなわち2001年まで実施される予定であったが、1997年7月のADEOS運用中止により、1998年度をもって終了することになった。

top
■■ 9-2 IMGプロジェクトの成果

IMGプロジェクトの成果について、目標に挙げられた機能、コスト、納期、およびその他の観点から分析をおこなった。なお、すでに述べたようにIMGプロジェクトの成果は現時点では出そろっていないため、この報告書の作成時点（1998年8月末）における成果のみをまとめた。

機能

IMGプロジェクトの成果のうち、CRIEPIに委託されたソフトウェア開発分については以下の項目が列挙されている。

またインタビュー結果からは、IMGプロジェクトの機能に関する成果について次のような回答が得られている。

コスト

IMGプロジェクトに要したコストについて、その変化を図1に示した。この図から、IMGプロジェクトに要した全コストのうちCRIEPI受託額を除いたもの、すなわちハードウェアの開発コストは、プロジェクト期間の前半に集中しており、逆にソフトウェア（地上システムを含む）の開発コストはプロジェクト期間の後半に集中していることが分かる。また開発コストの総額は約86億円、ハードウェア開発とソフトウェア開発の比率は1/2ずつであった。

ここでプロジェクトのコストに関するインタビュー結果を以下に示しておく。

納期

IMGプロジェクトのうち、ソフトウェア開発部門における各作業の納期を表した作業工程表があり、1996年度までの実績値が示されている（図4）。図の横線のうち、色の濃い部分が進捗実績を示しているが、これによれば各作業項目は1996年度までは目標通りの進捗状況となっている。

その他

プロジェクトが成功したかどうかの判断基準として、成果物の機能、コスト、納期以外に、プロジェクト・チームが正しく機能したかどうかも重要な要素である。すなわちプロジェクト・マネージャーからみてメンバーは期待通りの能力を発揮したか、またメンバー自身はプロジェクトの遂行によって達成感や充足感を獲得することができたかを知ることによって、プロジェクトの潜在的な問題点を発見したり、次回のプロジェクト・マネジメントに役立つ情報を得ることができる。これらの要素はプロジェクト終了後も表面に出ることは少ないため、分析にはインタビューが有効である

top
■■ 9-3 目標と成果の差異分析

前節までにIMGプロジェクトの目標と成果に関する調査結果を述べた。ここでの目的は、得られた成果がどの程度目標を満たすものであったかについて評価をおこなうことである。分析項目は、機能、コスト、納期の3つである。

機能

IMGプロジェクトの当初の目標を一言で表すと、地球温暖化問題に関する知見を得ることであった。現段階でこの目標の達成度を評価することは困難であるが、先に述べた、IMGプロジェクト実施フレームに対するアクション・ガイドラインの各項目と現在の成果との関係を示すことは可能である。

まずガイドライン（1-1）、（1-2）および（3-4）に対しては、成果（1）および（4）によって温室効果気体の挙動や放出量に関する解析が進められている。ただしADEOSの早期運用中止のせいで、IMGセンサで得られたデータが少なかったため、諸外国のものと比較できるだけの情報が得られるかどうかは疑問である。

次にガイドライン（2-1）〜（2-4）および（3-2）、（3-3）に対しては、成果（3）および（6）によってIMGプロジェクトのデータは諸外国に公表され、また諸外国の協力を得てデータ解析がおこなわれていることから、ある程度の効果があったと考えられる。

ただしガイドライン（2-5）についてはプロジェクト開始時に十分検討されたとは言えず、またIMGセンサの定常運用の期間が短かったため、IMGの位置づけは必ずしも明らかではない。さらにガイドライン（3-1）に対しては、成果（2）および（5）によって、現在までに得られたデータについてある程度の検証がおこなわれるものと考えられる。

コスト

IMGプロジェクトは国家プロジェクトであり、プロジェクトに要するコストはすべてMITIの予算で賄われるが、MITIはプロジェクト作業を分割して3つの財団法人に発注し、それぞれの財団法人は実際の開発作業を民間企業に発注した。この場合財団法人は非営利組織であり、MITIからの予算、すなわちコスト目標に応じた作業を実施するだけなので、当然コスト実績値は目標値通りになる。

一方開発作業を担当する民間企業に対しては一括請負契約によって発注がおこなわれるので、民間企業内部の作業状況によってコスト実績値は目標値通りにはならない。結局のところ、本プロジェクトでは民間企業内部の作業状況によってMITI予算が見直されることがなかったため、プロジェクト全体のコスト実績は目標値通りであった。したがって本プロジェクトにおけるコストの目標対実績評価は、開発を担当した民間企業毎に評価しなければならない。

納期

IMGプロジェクトにおける実際の開発作業はメーカーに単年度一括請負契約として発注されているため、1年ごとの契約納期は形式的にはほぼ完全に守られた。ただしこの契約納期を守るために一部の作業を翌年に持ち越す場合があったため、プロジェクト作業としては徐々に計画よりも遅れていった。しかしADEOSの打ち上げ延期によって納期が3年繰り下げられたため、結局これらの作業遅れは吸収され、IMGプロジェクト作業の最終納期は守られた。ここで納期に関するインタビュー結果を以下に示す。

top

■■ 10 マネジメントの観点からみたプロジェクト評価　〜IMGプロジェクトの場合〜

本節ではマネジメントの観点からIMGプロジェクト全体の評価を試みることにする。すなわちプロジェクトの全期間、またプロジェクト・チーム全範囲を見渡しつつ、マネジメントにおける成功点と問題点を抽出することによって、ＩＭＧプロジェクトが適切に推進されたかどうかを確認することを目的としている。

IMGプロジェクトはMITIの主導する国家プロジェクトであったが、MITIのおこなったプロジェクト・マネジメントは、最初にプロジェクト作業をハードウェア開発、ソフトウェア開発、地上システム開発の3つに分割して、それぞれを財団法人に発注したことにある。その後MITIは各委員会にオブザーバーとして参加する立場をとったが、参加メンバーはほぼ2年ごとに交代し、MITIはプロジェクト全期間に渡ってプロジェクトの推進過程を詳細に把握していたわけではなかった。

その結果IMGプロジェクトの、プロジェクト全体に対するマネジメントの権限と責任をもつシステムが弱体化した。このため各部門間でのコミュニケーションが効率的におこなわれず、また開発作業等に関する調整が部門同士のいわば対等な交渉に任されたために手間取り、プロジェクトの納期やコストを増加させる原因になった。

ハードウェア開発、ソフトウェア開発、地上システム開発を受注したJAROS、CRIEPI、ERSDACの各財団法人にはそれぞれの部門においてプロジェクト・マネジメント機能を果たすことを期待されていた。CRIEPIでは所内からマネージャーとしての適任者を選考し、以後ソフトウェア開発部門のプロジェクト・マネージャーとして外注業務のマネジメント等をおこなった。これに対してその他2つの組織のプロジェクト・マネージャーは開発作業を外注した民間企業からの出向者をもって当てられた。

温室効果気体センサ調査検討委員会（ハードウェア委員会）、IMGデータ解析手法検討委員会（ソフトウェア委員会）、データ利用地上システム委員会（地上システム委員会）の3つは、開発作業に関する技術的助言や評価など、それぞれJAROS、CRIEPI、ERSDACによるプロジェクト・マネジメントの支援を目的として設置された。これらの委員会はとくにプロジェクト進行中の品質評価に関して大きな役割を果たした。

ただし委員会のメンバーが主に大学や国立研究所等の研究者であったためコスト評価は必ずしも適切におこなわれず、開発を担う外注先でコスト増を生じさせる要因となった。とはいえ、各委員会は1年ごとに委嘱され、他の組織との兼任メンバーからなるゆるやかな組織であり、必ずしも全員がプロジェクトの全期間を通じて委員であるわけではない。実際にはこれらの委員会にプロジェクト・マネジメントの機能を持たせるのはリーダーシップと責任感の上でも困難であろう。

実際の開発を担当した民間企業は発注者である財団法人の指示を受けてプロジェクト作業を遂行するだけでなく、委員会にオブザーバーとして出席することによって、各部門のプロジェクト・マネジメントに迅速に対応することができた。しかしIMGプロジェクトの主導者であるMITIとの接触がなかったため、プロジェクトの全体像を常に十分把握できていたわけではない。

さらにプロジェクト開始後しばらくの間は、他部門に属するプロジェクト・メンバーとコミュニケーションをおこなう仕組みが設けられていなかったため、他部門との共同作業が効率的におこなわれなかった場合があった。ただしプロジェクト後半において、ソフトウェア開発部門におけるメンバー間の情報交換のために設けられたWWWサービスは大きな効果を発揮し、コミュニケーション促進に役立った。

以上述べたように、IMGプロジェクトは、縦割りのプロジェクト・チームが組織されたために、様々な作業の非効率の問題を生んだ。この種の大規模プロジェクトの場合、プロジェクト全体を統括するプロジェクト・マネージャーの存在は不可欠である。MITI自身が長期にわたって、マネジメントを行うことは多くの困難を伴うと考えられるので、まずプロジェクト・マネジメントをおこなうことのできるただ一つの組織に対してプロジェクトを発注することが適切と考えられる。

top
■■ 10-1 プロジェクトの開発計画について

IMGプロジェクトの開始時にMITIによって設定された目標は、少なくとも機能目標に限っては明確であり、それ以後修正されることはなかった。ただしこの目標がプロジェクト全期間に渡ってプロジェクト・メンバーに意識され続け、かつあらゆるプロジェクト作業がこの目標実現のために遂行されたか、という点には疑問の余地がある。

当初の目標である温暖化問題に関する知見の獲得という観点からは、温室効果気体の主要な成分である二酸化炭素の高精度の濃度測定が不可欠の要請であったが、目標に対する初期分析の段階でその実現可能性に疑問符がついたにも関わらず、機能目標は修正されなかった。初期分析作業自体は東京大学、東海大学、資源環境技術総合研究所のプロジェクト・メンバー等によって十分におこなわれ、地球大気科学研究に関する新たな目標の可能性が認められたわけであるから、それに応じた機能目標の修正がなされるべきではなかっただろうか。

実際には、MITIの設定したものと完全には一致しない機能目標をもってプロジェクトは進行し、ある程度の成果を上げている。にもかかわらず、もしプロジェクトの完了評価が適切におこなわれるなら、得られた成果の一部は目標の達成には貢献しないという評価を受けざるを得ないことになる。

次にプロジェクトのコストおよび納期目標について。MITIの設定した目標は過去の同様の衛星開発予算や納期から推算したものである。しかしプロジェクトは2つと同じものはなく、過去の実績を修正せずに利用できる場合はほとんどない。この場合も初期分析の段階においておこなわれたWBSから、新たにコストと開発工期の見積をおこなって目標を修正する必要があった。

この段階でおこなわれた機能目標の評価にかけられた手間に比べると、コストおよび納期目標に対する評価はほとんどおこなわれていないと言ってよい。また、もし過去におこなわれ、機能目標を達成したプロジェクトと全く同じものを実施する場合があったとしても、以前のプロジェクトの予算と納期を無条件に目標として採用して良いことにはならない。

確かにそのプロジェクトはその予算で実施できたが、そのコストで実施できたかどうかは分からないからである。プロジェクト・メンバーのいずれかが赤字になっていれば、実はそのプロジェクトはコスト目標を守れなかったという意味で失敗であり、あらたにコスト目標の見直しが必要である。

開発計画においてコスト評価が十分おこなわれなかったという事実は、プロジェクト計画定義の段階にもあてはまる。本来この計画定義はプロジェクト・マネジメントにおいてもっとも重要な作業である。IMGプロジェクトの場合、ソフトウェア開発部門では技術調査を外注して1年程度の時間をかけてWBSや工程計画の作成をおこなっているが、開発に要するコストについてはほとんど検討がなされていない。

もちろんこれはMITIによる予算執行が単年度毎であり、長期的な予算配分の決定が硬直的であるという事情によるものである。この段階で計画定義作業を外注することには、開発を担当する民間企業の立場からコスト評価をおこなうことができるという利点がある。

開発計画立案の重要な作業として外注先の選択が挙げられよう。IMGプロジェクトのうちソフトウェア開発部門に関しては、主に過去のつき合いによって外注先候補が選ばれた。事前にこれらの外注先候補に対する評価はほとんどおこなわれていないものの、結果的にこれらの外注業務がほぼ成功したために問題は生じていない。

しかしながら、やはり外注先決定前の事前調査は適切におこなうべきである。そうしなければ次回のプロジェクトにおいても外注先決定の判断材料は過去のプロジェクト実績（すなわち今回のIMGプロジェクトにおける実績）しかなく、外注先変更を促す材料が手に入らないため、同じ外注先を選択せざるを得なくなる。

たとえその外注先が事実最良の組織であったとしても、なぜ最良の組織であるかという根拠を把握しておく必要がある。無批判に同じ外注先に頼り続けていくと、やがて外注業務のマネジメントにおいて外注先の言いなりになる事態がこないとも限らない。

また、外注候補先の選定はプロジェクト・マネージャーがあたるべきである。例えば、委員会等によって候補が選定された場合、この機能開発に関する外注業務の、プロジェクト・マネージャーによるマネジメントが不十分になり、外注コストの上昇などを招く可能性が生じる。

top
■■ 10-2 プロジェクトの進捗マネジメントについて

IMGプロジェクトは国の予算で遂行されたので、すべての開発作業は単年度契約で発注されており、1年ごとに設けられた契約納期が主要なマイルストーンとなった。したがってMITIおよび各財団法人が毎年の発注プロジェクトに対する検収と完了評価を適切におこなうことが必要である。

ソフトウェア開発部門ではCRIEPIの外注先企業から毎年、契約作業の終了届けと報告書が提出されており、検収に関する文書が残されている。CRIEPIのプロジェクト・マネージャーは外注先企業から1〜2ヶ月に1度の割合で進捗状況の報告を受けていたことから、これらの文書はプロジェクトマネージャーが実際に作業の進捗状況を適切に把握していた証拠として採用できる。

一方CRIEPIからMITIに対しても毎年の契約作業の報告書が提出されている。しかし各年度の途中、MITIとCRIEPIの間では作業の進捗状況を報告する会議等は開かれず、またMITI担当者はオブザーバーとして登録されているソフトウェア委員会に出席する回数が少ないため、ソフトウェア開発作業の進捗状況をMITIが適切に把握することは困難であったと考えられる。

このようにIMGプロジェクトでは、財団法人に任された各部門の中での作業進捗実績は正しく把握されていたものの、プロジェクト全体の進捗状況をまとめて把握する仕組みが公式には設けられていなかった。もちろん各部門のプロジェクト・マネージャー、および委員会のメンバーの一部は他部門の委員会のメンバーでもあったから、実際には部門同士のコミュニケーションの機会は存在した。 しかしながら委員会同士の横の連絡に頼っていては、他部門の進捗実績を知ることはできても、プロジェクト全体の進捗をマネジメントすることは困難である。

ハードウェア開発部門ではハードウェア委員会で進捗報告が行われていたが、スケジュールがクリティカルな状況において進捗管理が不十分な場合があったと思われる。また、外注先が問題の発生や作業の遅れについて正直に報告しにくい雰囲気がハードウェア委員会にあった可能性があり、外注業務マネジメントの上では大きな問題である。

進捗マネジメントにおいては正しい実績値の収集（PDCAのCheck）が最も重要な作業であり、この作業が適切におこなわれなければ、いかなる対処（PDCAのAction）も無駄になるのである。したがってプロジェクト・マネージャーは進捗実績を正直に報告できる場をつくることを強く心がけねばならない。営利企業にとって顧客だけがプロジェクト・マネージャーとして受け入れることのできる存在だということを認識しなければならない。

IMGプロジェクトにおける進捗マネジメントでは、各委員会が機能をマネジメントしようとし、開発企業はコストにつながる納期をマネジメントしようとした。両者の相反する目的を矛盾なくまとめるには、両者の上に立って機能、コスト、納期の3つに責任をもつプロジェクト・マネージャーの存在が不可欠である。IMGプロジェクトにおいても、プロジェクト・マネージャーが正しく機能したかどうかが外注先のコストに関連したと考えられる。

top
■■ 10-3 プロジェクトの完了評価について

IMGプロジェクトは当初の計画とは異なり、ADEOSの運用中止のため1998年度をもって終了することになった。本来なら10年におよぶプロジェクトの実績を評価して国家プロジェクトとしての成否を判断するとともに、今後の同種のプロジェクトの実施の際に有益な情報が得られるよう、プロジェクトの完了評価をおこなわなければならない。ところがMITIでは完了評価作業をプロジェクト実施計画に含めておらず、プロジェクト全体の評価がおこなわれる予定はない。

ソフトウェア開発部門では、CRIEPIのプロジェクト・マネージャーの判断により、IMGプロジェクトの全期間を通じたプロジェクト・マネジメントとプロジェクトの成果について、残された関連文書の分析と関係者へのインタビューによってプロジェクト完了評価がおこなわれており、本報告書はその結果を記述したものである。

この評価作業によってプロジェクト・マネージャーでさえ意識しなかったプロジェクトの実態が明らかになるなど、重要な知見が得られつつある。プロジェクト完了評価はほぼ間違いなく、かけたコスト以上の成果が得られる作業であり、是非最初からプロジェクト実施計画に含めるべきものである。評価作業が行われなければ、次回のプロジェクト実施時にも同じ失敗を繰り返したり、同じ苦労を味わったりすることになるだろう。

これが繰り返されることによって、プロジェクトに携わるメンバーの中には、プロジェクトとはこうしたものだ、とか、納期が遅れるのは当たり前だ、などという一種のあきらめに似た理解が生まれてくる。

しかしプロジェクトは自然現象ではない。人間が発案し、計画し、実行して終了させるものである。正しいマネジメントさえおこなえば、必ず成功させることができる作業なのである。このことを念頭に置いて、プロジェクト・マネジメントというきわめて人間的な行為について、もう一度その価値を認識する必要があるだろう。

この種の大規模研究開発プロジェクトにおける最も重要な完了評価の一つとして、外注先企業の成果と能力の評価が挙げられよう。MITIおよび各財団法人がプロジェクト・マネージャーの役割を果たすのに対して、開発作業を担当してプロジェクトの成果を実際に作り出していくのは外注先企業だからである。それらの外注先企業が期待通りの能力を発揮して、機能、コスト、納期の目標を達成したかどうか、またプロジェクト・マネージャーにとって外注業務のマネジメントが成功したかどうかの判断を下すことは、まさにプロジェクト全体が成功したかどうかに関わる重要な問題である。そしてこのことは外注先企業にとっても、今後受注するはずのプロジェクトの実施に対する貴重な知見を得る機会となるのである。

今回のIMGプロジェクトでは、開発されたセンサはほぼ期待された性能を発揮し、衛星に搭載された後、科学者の興味を満たす観測データが取得された。この意味ではIMGプロジェクトは品質の面で成功したと言えるだろう。だがセンサの開発作業が遅れ、ADEOS打ち上げが延期されなければ間に合わない恐れがあったこと、またハードウェアや地上システムを開発した外注先企業がコスト過大になったことを考えれば、納期やコストの面では決して成功したとは言えないのである。

top
■■ 11 プロジェクト・マネジメントに関する文献

マネジメント手法に関するもの

先端情報技術の活用に関するもの

外注管理について

その他マネジメント手法

top

■ ■ ■