日本情報システム・ユーザー協会（JUAS）が毎年実施している「企業IT動向調査」。その2006年版によれば，「500人月以上の大規模プロジェクトでは相変わらず5割近くで工期遅れが発生」，「大規模プロジェクトでは未だ4割近くで予算超過」，「大規模プロジェクトでは3割近くがシステムの出来上がりの品質に不満」と，企業情報システム開発では，納期，コスト，品質が予定通りに終わらない“失敗プロジェクト”がいまだに多い。

　なぜ，企業情報システム開発では，失敗プロジェクトが多いのか。この点を，プロジェクトマネジメントを支援しているベテラン・コンサルタントや製造企業のCIO（最高情報責任者）と議論したことがある。その結論は，理由はいろいろあるが，プロジェクトマネジメントの観点で見れば「オーナーの弱さ」に尽きる，というものだった。

　企業情報システム開発プロジェクトの「オーナー（持ち主）」は誰か。言うまでもなく発注者であるユーザー企業だ。そのオーナーが弱く，ベンダーに任せきりでは，プロジェクトがうまくいくはずがない。

　もちろん，設計・実装・テストをすべてオーナーが実施するわけにはいかない。これらはITのプロが実施した方が効率的だし，それだけの人的リソースもユーザー企業にはない。では，オーナーは，何をすべきなのか。

「超上流」はオーナーの責任

　エンジニアリング業界のノウハウが盛り込まれた日本発のプロジェクトマネジメント標準「P2M」では，設計・構築以前のフェーズを「スキーム・モデル」と定義している。P2Mにおける「スキーム・モデル」とは，（1）プロジェクト目的・目標，（2）基本運営方針，（3）基本要求仕様書，（4）プロジェクト協調関係，（5）期待成果，（6）制約条件，（7）調査研究により，プロジェクトの基本構想文書，基本方針書，基本図面を策定する活動である。プラントを作るエンジニアリング業界では，原則としてオーナー自身が，このスキーム・モデルを作成する。ITにたとえれば，要件定義以前の「超上流」フェーズは，ユーザー企業自身が実施するということだ。

　プロジェクトのオーナーはユーザー企業自身であり，「システム化で何をしたいのか」はユーザー企業にしか決められない。そう考えれば，本来，要件定義以前の「超上流」フェーズはユーザー企業自身が主導すべきだ。しかしこれまでは，ユーザー企業側に，この意識が弱かったのではないだろうか。

　前述のCIOには，「ITプロジェクトマネジメントの問題点」というテーマで講演してもらったことがある。そのときに「経営者が参画する要求品質の確保」（独立行政法人 情報処理推進機構　ソフトウェア・エンジニアリング・センター編，オーム社発行）という本を「非常に良い本なのでぜひ読んでください」と，壇上で推薦されていた。

　この本は，サブタイトルに「超上流から攻めるIT化の勘どころ」とあるように，要件定義以前のフェーズ（システム化の方向性，システム化の計画，要件定義）を「超上流」工程と定義し，超上流での「ユーザー企業の積極的な関与がプロジェクトを成功に導く」としている。企業情報システム開発で，「超上流」工程における「オーナーの強さ」がいかに重要かがよく分かる良書である。特にユーザー企業でシステム化にかかわる人にはぜひ読んでほしい。

　なお同書には，超上流工程をうまく進めるための「原理原則17ヶ条」が書いてある。なかなか含蓄に富むよくできた原理原則なので，紹介しておきたい。じっくりと見てほしい。

原理原則[1]　ユーザとベンダの想いは相反する
原理原則[2]　取り決めは合意と承認によって成り立つ
原理原則[3]　プロジェクトの成否を左右する要件確定の先送りは
　　　　　　　　 厳禁である
原理原則[4]　ステークホルダ間の合意を得ないまま，次工程に入らない
原理原則[5]　多段階の見積りは双方のリスクを低減する
原理原則[6]　システム化実現の費用はソフトウェア開発だけではない
原理原則[7]　ライフサイクルコストを重視する
原理原則[8]　システム化方針・狙いの周知徹底が成功の鍵となる
原理原則[9]　要件定義は発注者の責任である
原理原則[10]　要件定義書はバイブルであり，事あらばここへ立ち返るもの
原理原則[11]　優れた要件定義書とは
　　　　　　　　　システム開発を精緻にあらわしたもの
原理原則[12]　表現されない要件はシステムとして実現されない
原理原則[13]　数値化されない要件は人によって基準が異なる
原理原則[14]　「今と同じ」という要件定義はありえない
原理原則[15]　要件定義は「使える」業務システムを定義すること
原理原則[16]　機能要求は膨張する。コスト，納期が抑制する
原理原則[17]　要件定義は説明責任を伴う