プロジェクトマネジメントは、はやぶさプロジェクト（以下、ＰＪ）のように
１０数年もかかるものや学園祭の新規イベントの企画から当日を迎えるまでの半
年くらいのプロジェクト、そしてIT関連ＰＪでは半年から３年くらいまでのもの
と期間は様々です。はやぶさＰＪは、色々な障害や挫折を過去に経験したノウ
ハウ・技術をもって着実に乗り越えた成功ＰＪです。学園祭などでは集客面や採
算面などで成功したかどうか判断されます。
IT関連ＰＪでは成功事例も多くありますが、失敗（or課題／泥沼）ＰＪも後を
絶ちません。この中でもお客様とベンダー双方が不幸になる事例として、失敗
ＰＪに対して訴訟に至るケースがあります。
最近発生した某銀行とITベンダーとの間の訴訟では１審では某銀行がITベンダ
ーに支払った数十億円の費用を某銀行に返却するように裁判所は命じています。
すぐ控訴されたため、最終結論はまだ分かりませんが、お互いがこの裁判に対応
するために多大な労力と多くの機会損失を被っていることは言うまでもありませ
ん。これらの事象は大企業だけでなく中小企業においても金額の大小にかかわら
ず発生しうるリスクコストです。
今回はプロジェクトマネジメント（以下、ＰＭ）の危機管理について考えてみ
たいと思います。
■ユーザー企業の協力義務とITベンダーのＰＭ義務
ITシステム開発ＰＪはユーザーとITベンダーが協力してプロジェクトのゴール
を目指すものです。「システム開発はITベンダーとユーザー企業との共同プロジ
ェクトである」との考えに基づき、双方が義務を負います。
ユーザー企業には、協力義務として、
・資料の提供や必要に応じて帳票や画面の絞り込みそして各種レビューなど
システム開発のために必要な協力を行う。
もう一方のＩＴベンダーにはＰＭ義務として、
・ユーザーとの間で合意された開発手順や開発手法、作業工程等に従って開発
作業を進める。
・常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切
に対処する。
・専門知識を有しないユーザーによって開発作業を阻害する行為がされること
のないようユーザーに働きかける。
等、双方に義務が発生します。
ただ、ユーザー企業の力量や発注形態（一括アウトソーシングやパッケージソ
フトを利用した基幹系システムの全面刷新など）によってＰＭ義務の重さが変わ
ります。プロジェクト立上げ時のキックオフミーティングにおいて進捗報告や議
事録の取り扱いそして会議体や役割分担について充分調整します。実務者会議だ
けでなくユーザーの役員も参加するステアリングコミッティーの設定も重要です。
■なぜ、プロジェクトの失敗が絶えないのか？
プロジェクトは開発・導入規模が大きくなればなるほど、級数的に難易度が高
まります。人の管理スパンには限りがあり、サブリーダーを設定して任せるため、
開発規模に応じてコミュニケーションパスが増えていきます。プロジェクトの成
功には、多くの利害関係者が関係し、そこでのコミュニケーションやチームの雰
囲気という人間系に係るものが大きな要素を占めます。情報共有やコミュニケー
ションが滞るとプロジェクト失敗の危機に瀕します。
また、新技術や新パッケージ適用におけるリスクがあります。新しいものはプ
ロジェクトマネージャ自身が良く見えない状況なので、事前評価のステップや時
間を充分に考慮し、その技術やパッケージを熟知している開発者や技術者との充
分な連携が必要となります。ユーザーにその旨の理解を得ることも重要です。
プロジェクトには然るべき体制構築や事前評価など必須のものがあり、これら
を省略するとプロジェクトの失敗リスクが大きく跳ね上がります。
■プロジェクトの成功に向けて
プロジェクトが成功したというのは何を持って判断するのでしょうか。
１）ＰＪコスト
２）ＰＪのスケジュール
３）開発・導入システムの品質（性能含む）
４）目標とした業務とインフラの定量、定性効果の実現
５）ＰＪを通じて会社の技術・ノウハウの継承
６）エンドユーザの満足度
等が挙げられます。その中でもユーザーの満足度がプロジェクトの成功度を測る
尺度の中で最も測定が難しく、長期間意味を持つものです。
二度と失敗を繰り返さないために、
１）上流工程でのユーザーレビューの徹底
２）守れるスケジュールの作成（開発工程を削除、重複させない）
＝＞開発規模、新技術、人的要素を考慮
３）契約書、覚書でのユーザー／ＩＴベンダー間の責任分担の明確化
４）概要設計終了時点での開発規模／スケジュールの徹底的調整
５）チームワークの良い体制作り（ユーザー、ＩＴベンダー双方）
６）開発工程における様々な局面で臨機応変の対応を取ること
等をプロジェクト成功に向けて、ユーザーとＩＴベンダー間で腹を割って話合う
ことのできる環境作りが不可欠となります。人間がマネジメントしている限り、
失敗は付き物ですが、ゼロにはならないにしても極小化することが重要です。
（参考）
・日経コンピュータ 2012.8.16号
------------------------------------------------------------------------
■執筆者プロフィール
下村 敏和
ヒーリング テクノロジー ラボ代表
ＩＴコーディネータ京都 理事
ＩＴコーディネータ
コメントをお書きください