1.PMBOKへの共感
最初に、筆者はIT業界に身をおき、お客様のシステム・インテグレ−ションを請け負ってきた立場からの意見であることをお断りしておきます。
PMBOKの中に、いくつか共感を覚える、「我が意を得たり」と感じる記述があります。
その代表的な記述は次の三つです。

(1)	「プロジェクトがプロジェクト計画どおりに実行されることはほとんどないので、変更管理は必要である。」(統合マネジメント)
	共感：	変更に振り回されるな。変更は避けるのではなく、発生することを前提にコントロ−ルする。
(2)	「プロジェクト・スコ−プ・マネジメントでは、まず、プロジェクトに何が含まれ、何が含まれないかを明確にし、それをコントロ−ルすることが主要な関心事である。」 (スコ−プ・マネジメント)
	共感：	通常、発注者側、受注者側でスコ−プが異なる。プロジェクトに含まれるものだけでなく、含まれないものも明確にすることにより、抜けがなくなり、関係するステ−クホルダとその役割や責任も明確にすることができる。
(3)	「早期の対応は、リスクが発生後のその損害修復よりもはるかに効果的である。」 　　　(リスク・マネジメント)
	共感：	先手必勝。前兆を見過ごさないで、タイミングを逸せず行動する。気になることを放っておかない。

PMBOKには多くの成功プロジェクトと失敗プロジェクトから得られた教訓が整理されていると思われます。上記の三つは、筆者が経験から学び、実践を心がけていたことでもあります。実際のプロジェクトの中でなんとか解決しようと悪戦苦闘した結果の教訓に違いないと思われることがPMBOKに書かれていることを発見した時は、思わず苦笑すると共に、この苦労は自分だけではないという親近感が得られて、精神的にも強くなれる気がします。
今回は、「プロジェクト・スコ−プ・マネジメントでは、まず、プロジェクトに何が含まれ、何が含まれないかを明確にし、それをコントロ−ルすることが主要な関心事である。」を取り上げて、実際の業務に置き換えて考えてみます。PMPOKは一般化して記述されているので、それを実際にどう自分の業務に適用するかは、それぞれが業務合わせて解釈し、具体化していくことが必要になります。
ここで、注目すべきキ−ワ−ドは「何が含まれないか」です。

2.スコ−プの検討範囲
システム・インテグレ−ションにおいては、スコ−プに何が含まれるかを明確にし、発注側と受注側が合意することがプロジェクトの成功にとって重要であることは認識されています。その一方、スコ−プが不明確なまま、合意がないままプロジェクトが進行し、破綻に至るものが多いことも事実です。システムは業務の中に組み込まれ、運用されることにより効果を発揮します。この当たり前のことを考えれば、システムのアプリケ−ション開発を請け負っただけだとしても、顧客の業務におけるシステム運用までのことをスコ−プとして考え、その上でそれが誰の役割、責任であるかを割り振っていく必要があります。それで初めて�@プロジェクト・スコ−プの境界、�Aプロジェクトに含まれる範囲、が明確になります。プロジェクトに含まれない定常業務でも、プロジェクトと関連づけ、場合によっては組織改革まで実施しないと、効果のあがるシステム運用ができません。
受注側の場合、受託範囲がプロジェクト・スコ−プになります。発注側のプロジェクトから見ると、これはサブ・プロジェクトになります。したがって、他のサブ・プロジェクト、既存システム、関連業務といったものとの関係を考慮して必要作業を検討しておかないと、プロジェクトの目的を達成できない恐れがあります。このように幅広い視点でスコ−プを検討するために、「何が含まれないか」までを含んで考えることが役に立ちます。

3.プロジェクトの目的と要求事項に対する優先度
プロジェクトには目的があります。そもそも、目的を達成するためにプロジェクトを発足させたのであり、そのプロジェクトの成功は即ち当初の目的に結びつくものでなければなりません。要求事項を検討するときは、この目的からみて、「何をやるか」と同時に「何をやらないか」を明確にすべきです。これがシステムの肥大化を防ぐことにもなります。
　ところが、これがなかなか簡単ではありません。目的を達成するには通常複数のやり方があります。どれを選択し、そのどの範囲をIT化するのが最も効果的を検討し、優先順位の高いものから着手する必要があります。ここでも、「何をやるか」と共に「何をやらないか」を明確にしておかないと、IT化の範囲がプロジェクト開始後に大きく変わる可能性があります。
　「スコ−プに何が含まれないかを明確にせよ」などと言うと、「・・・はしない」、「・・・もしない」と否定文を並べることかと思われるかもしれませんが、そうではありません。プロジェクトを成功させる(即ち、プロジェクトの目的・目標を達成する)ために何をなすべきかを、自分の属すグル−プや組織にとらわれず、検討し洗い出すことが必要です。それがプロジェクトの目的を達成するためのスコ−プ定義ということになります。
また、「何をするか」と共に「何をしないか」を明確にするには、要求事項の優先順位付けおよびそれを採用する理由、却下する理由を明確にすることでもあります。採否の根拠が明確になっていれば、同様の要件について蒸し返しの議論が起き、時間を空費することを防ぐ効果もあります。

4.プロジェクトの立上げ段階の重要性
　システム・インテグレ−ションに関しては、プロジェクトの失敗要因はスコ−プや役割分担があいまいなままプロジェクトを発足し、途中でスコ−プの変更や膨張を招くに至る事例が多く見られます。このような事態に陥ることを防ぐためには、商談・見積り段階から契約に至るまでのマネジメントを重視すべきという認識はあるのですが、必ずしも上手く行っているとはいえません。この段階では通常スコ−プが固まっておらず、曖昧であることが多いのが実情です。契約時までに、目的・目標の明確化と要求事項の優先順位付けを行い、スコ−プに何を含むか、何を含まないかの認識をステ−クホルダ−間で共有することが肝要です。
PMBOKでは、立上げ段階でのアウトプットはプロジェクト憲章とプロジェクト・スコ−プ記述書暫定版です。ここでプロジェクトの目的、プロダクトやサ−ビスに対する要求事項と特性、プロジェクトに対する要求事項と要素成果物、プロジェクトの境界等を記述します。この段階では不確定要素を内在しており、コスト見積りは超概算であるとしています。しかし、システム・インテグレ−ションでは、この段階で一括請負契約することが多いことが現実です。その結果、スコ−プの変更や膨張に予算内で対応できず、打つ手が後手に回り、プロジェクトに破綻を来たすプロジェクトが発生しています。スコ−プの曖昧さを低減するために、受注条件やスコ−プを明確にした合意文書の作成や一括請負契約ではなく多段階契約の締結(要件定義、設計、製造・テスト、運用・保守といったフェ−ズ毎に契約する)等の対策がとられています。こう書いてみて、こんなことは対策というより当たり前のことではないかと思い至りました。プロジェクトマネジメントはかなりの部分が当たり前のことを確実に実施するということでもあります。少なくとも、要件定義完了前のコスト見積りやプロジェクトマネジメント計画書は暫定版と認識し、要件定義完了後に再見積り、再計画を実施すべきです。これは、プロジェクトのリスクを軽減することに役立ち、発注側、受注側いずれにとっても好ましいことです。

5.PMBOKは役に立つか
　最初はPMBOKの中にいくつかの共感する記述を見つけたことから、PMBOKは実務に役に立つのではないかと感じたのですが、今は、次のステップを踏んで実務に活かすことができると確信しています。
　�@PMBOKを実際の業務に当てはめて理解する。　⇒　�A考え方や実行していることを体系的に整理する。　⇒　�Bプロジェクトの各フェ−ズでなにをすべきかについて確信が持てる。　⇒　�Cプロジェクトの様々な局面で適切な行動がとれる。

次回担当者に続く