プロジェクト管理手法(フレームワーク)

筆者が勤務する会社(日立コンサルティング)はコンサルティングファームということもあり、プロジェクト管理については、方法論(HCJ PM-Methodology)を保有している。その中で規定しているプロジェクト管理のフレームワークは、図1のようになっている。

図1 プロジェクト管理の9つの領域

このフレームワークは、当然のことながら、国際標準のプロジェクト管理体系であるPMBOK※に準拠しており、さらにコンサルティングファームとしてのナレッジやノウハウを付加したものとなっている(CMMIや、COBITも参照)。

※PMBOK(the project management body of knowledge)
米国プロジェクトマネジメント協会(PMI)が提唱する、プロジェクトマネジメントのための標準的なフレームワーク(知識体系: body of knowledge)。プロジェクトを実施する際の基本的な考え方、手順をまとめたもの。事実上の国際標準となっている。

開発現場でよく見かける風景

さて、まずは弊社のフレームワークをご紹介した上で、話を少し戻し、ほんの一例ではあるが失敗プロジェクトの事例を見てみよう。

図2は、よく見かけるシステム開発現場での会話のやり取りである。

図2 プロジェクト現場でよくある風景

このやり取りをご覧になって、読者の皆様はどうお感じになったであろうか? ユーザー企業のプロジェクトマネージャーが、仕様変更を、半ば強引な交渉術によって開発会社のプロジェクトマネージャーにやらせるよう、巧く押し込んだ場面とでも思われただろうか？そう、思われた方は、ユーザー企業のプロジェクトマネージャーの方であれば、特に認識を改める必要があると思われるので、是非この続きも、読んでいただきたい。

ユーザー企業のプロジェクトマネージャや、プロジェクトオーナーを標榜する方々の中で、「いかに安い発注金額と短い納期で開発業者に受託させるか」が自分の仕事だと勘違いしている向きが多いのは、非常に情けないことである。つまるところ、開発受託会社がユーザー企業側に提示している納期や金額は、プロジェクトを安全に終結させることができると保証する前提のものであり、むやみに強引な交渉で発注金額を下げたり、納期を短くすることはプロジェクトの成功という点においては何の意義ももたらさない。このように一方的に譲歩を迫る交渉を、プロジェクトを共同で運営する立場のパートナー(開発会社)に対して適用し続ければ、プロジェクトのリスクを増加させるだけである。

プロジェクトの成功とは、そもそも何であろうか? 開発会社へ仕様変更の追加費用を無償対応させる調整依頼を押し込んで、上司に褒められることが成功だろうか? 開発会社に仕様変更を無理やり呑ませて、納期直前になって開発会社から白旗が揚がり、ひいては訴訟問題に発展するような事態を招くことになったとき、その上司は何と言うだろうか?