ユーザー企業側プロジェクトマネージャの勘違い：超現場主義！ 失敗しないITプロジェクトマネジメント（2）

[玉木栄三郎, 須永啓太 ，イー・キャッシュ株式会社]

常に潜在化しているリスクをチェックしながら、プロジェクト進行中の早い段階でリスクマネジメントを行う。これが、「失敗を前提としたプロジェクトマネジメント」の本質である。「ヒト」という点でプロジェクトのリスクファクターをとらえた場合、それはプロジェクトにかかわるすべてのステークスホルダー（利害関係者）の利害を認識し、それぞれのステークスホルダーとビジネスの落としどころを交渉するということにほかならない。

リスクを早い段階から摘み取るためのマネジメント

　プロジェクトのステークスホルダーは大きく分けて4つにカテゴライズすることができる。

1. ユーザー企業側最高システム責任者
2. ユーザー企業側プロジェクトチーム
3. ユーザー企業側その他システム関係者（他部門のシステム責任者）
4. システム開発業者

　2回目は「ヒト」に起因するリスクファクターとマネジメント方法、すなわちユーザー企業側のプロジェクトチームを統括するプロジェクトマネージャ向けに、システム開発会社との関係におけるリスクファクターとそのマネジメント方法をプロジェクト現場によくある事例を挙げながら紹介していきたい。

ITプロジェクトの現場でよくある風景

開発企業側プロジェクトマネージャ　「今日の開発定例ミーティングですが、先日受けた経理用帳票の項目周りの確認を中心に行いたいと……」

ユーザー企業側プロジェクトマネージャ　（遮るように）「あ〜、その件なんだけどさ。実は経理側システムもリプレースをやっていてさ、その関係でうちのシステムで経理帳票を出すのではなくて、経理システム側に必要なデータをCSVで送るように変更してほしいんだよね」

開発企業側プロジェクトマネージャ　「仕様変更の件は承りましたが、この場合仕様変更のインパクト次第では納期と予算に関して再度検討させていただかないとならない可能性が……」

ユーザー企業側プロジェクトマネージャ　「そんなに大したことないよ。帳票で出すものをCSVに変えるだけだよ」

開発企業側プロジェクトマネージャ　「文字コードの問題や通信形式など確認しなければならない事項がございますので、経理システム側の担当者様とのお打ち合わせの機会をセッティングしていただけますでしょうか？」

ユーザー企業側プロジェクトマネージャ　「あーでも担当者は今週、来週と夏休みなんだよー。取りあえず適当にCSVで開発進めておいてくんない？」

開発企業側プロジェクトマネージャ　「では、取りあえず納期については再スケジュール案を提出させていただいてもよろしいでしょうか？」

ユーザー企業側プロジェクトマネージャ　「納期と予算は変えられないよ。そっちで調整してよ」

　この一連のやりとりを見てどのように読者は感じられるだろうか？ ユーザー企業側のプロジェクトマネージャが、うまく仕様変更を巧みな（強引な？）交渉術によって開発企業側のプロジェクトマネージャに押し込んだシーンと感じられただろうか？ 本当にそう思われた方がいたとすれば、いますぐ考えを改める必要があると思われるので、ぜひ最後まで本文を読んでいただきたい。

　ユーザー企業側のプロジェクトマネージャの中で、いかに安い発注金額と短納期で開発業者に発注させるかがユーザー企業側のプロジェクトマネージャの仕事だと勘違いしている方が多いのは大変嘆かわしいことである。結局のところ開発業者がユーザー企業側に提示している金額や納期は、この金額と納期であればプロジェクトを安全に終結させることができるとコミットメントしたものであり、交渉で発注金額を下げたり、納期を短くすることはプロジェクトの成功という点においては何の意味ももたらさない。このような一方的な譲歩を迫る交渉を、プロジェクトを共同で運営する立場の「ヒト」に対して適用し続ければ、プロジェクトのリスクを肥大化させるだけである。

　プロジェクトの失敗とはそもそも何であろうか？ 開発会社への仕様変更の調整依頼に失敗して上司に怒られることが失敗だろうか？ それとも開発会社に仕様変更をのませて納期直前になって開発会社からバンザイされて、訴訟問題に発展するような事態を招くことであろうか？

相互利益の関係を開発会社と築くこと

　本件の事象を例に取れば、まずユーザー企業側のプロジェクトマネージャは以下の対処を考えるべきだったろう。

1. 仕様変更のスケジュールに与えるインパクトを開発会社へ提供できるような資料を何とか経理システム担当者をつかまえて速やかに入手し、開発会社へ状況を提供し、仕様変更のインパクトをヒアリングする
2. 開発会社から報告を受けた再スケジュール案を自社内で協議に掛け、システムの納期の延長や、仕様変更部分の分割リリース案など対策を講じる。再スケジュールが難しい場合は予算増額による開発会社の増員要請を行うなどの代替案を考案する
3. 開発会社に対してユーザー企業側からの要望・協議の経緯を伝え、対応を依頼する

　前回述べたとおり、プロジェクトマネジメントの本質は「失敗を前提とする」ということである。このケースの場合、納期と予算を変更せずに開発企業側に仕様変更をのませるということに固執したあまり、最大の目的であるプロジェクトを成功させるという点が疎かになってしまっているのである。開発業者に無理な納期や予算を押し付ける前に、まずはシステムにかかわるステークスホルダーに対して予算の交渉やシステムのサービスインの時期を交渉して、安全なプロジェクトマネジメントを行う方がプロジェクトを成功させるという本来の目的にかなう行為だということの認識がユーザー企業側のプロジェクトマネージャの認識に足りなかったのである。

　また具体的に例として挙げた事象以外にも、たくさんの「ヒト」にまつわる課題がITプロジェクトを襲うかもしれない。それこそ、提案時に来てくれた開発会社のプロジェクトマネージャから受注した途端経験の浅いプロジェクトマネージャに代わったといった事態から、情報システム部門側の担当者が代わってSLAの見直しをシステムサービスイン1週間前にせざるを得ないなど、著者が経験したものだけでも1冊の本にできるほど数多くある。大切なことはこのようなリスクが招く最悪の事態を認識し、早期に対処を行うことである。開発会社のプロジェクトマネージャが変わってしまったなら、引き継ぎが無事終わっているかを確認し、どうしてもプロジェクトを任せられないほど経験が浅い場合にはプロジェクトマネージャのチェンジを営業担当に申し出るべきだし、SLAの見直しをせざるを得ない場合には、それがスケジュールの遅延につながるかどうかを把握して早い段階でステークスホルダーと交渉するべきである。

　要はプロジェクトマネジメントにおけるリスクマネジメントはリスクとなり得ると認識された時点で、事態が深刻になる前に先行して対処を行い、リスクを早い段階で摘み取ることの繰り返しなのである。そういわれると「至極当たり前のことをしているだけではないか！」と思われるかもしれないが、実際にそのとおり至極当たり前のことである。しかし、そのような当たり前のことが行われず、今日もまた失敗プロジェクトは増え続けている……、その本質的な原因はいったいどうしてなのだろうか？

ユーザー企業自身がリスクファクター

　昨今のプロジェクトマネジメントブームに乗って数々の書籍が出版されているが、顧客つまりはユーザー企業側の無理難題に対してどのように自分たち開発会社側の事情を説明し譲歩を引き出すかの交渉術と、無理難題に対してリスクヘッジとして契約や変更履歴を残すテクニックなどが内容の中心のようである。

　つまり、開発会社は今日のITプロジェクトにおいて最もリスクファクターとなっている要因はユーザー企業自身の体質であると認識しているのである。ユーザー企業自身が「開発会社へ丸投げ」「プロジェクトへの非協力的な体制」「仕様の取りまとめを行わない」などという大きなリスクファクターを抱えてしまっており、それを解決することが開発会社側にとって大きなリスクヘッジになると認識しているのである。

　ユーザー企業のプロジェクトマネージャはユーザー企業側、業者側つまりはお金を払う側、払われる側という意識を忘れて、いま一度プロジェクトを共同で運営し、自社のビジネスを成功に導くためのパートナーとして開発会社を扱うことがITプロジェクトを成功に導くための最適解であるということを認識する必要があるのである。

　ユーザー企業側のプロジェクトマネージャはプロジェクトの成功がどこにあるのかを常に考えながら、リスクの芽を事前に摘み、プロジェクトにかかわる利害関係者の利害や思惑を常に調整しながらプロジェクトを運営していく義務があるのである。

---

　プロジェクトの最大のボトルネックが実はユーザー企業側の当事者意識の薄さにあるという主張は、ユーザー企業側のプロジェクトマネージャにとっては寝耳に水の主張であるかもしれない。事実、プロジェクトの成功率が低い要因として開発会社のプロジェクトマネジメントがうまく機能していないということも事実であろう。

　しかしながら、前回の連載でも書いたとおり、ITプロジェクトのマネジメントの義務はあくまでも、ユーザー企業側にあることを忘れないでほしい。発注者であるユーザー企業側がITプロジェクトを成功させるために最善のマネジメントの方策を取ることが、ITプロジェクト成功の最大の鍵なのである。

　次回は「モノ」に起因する失敗のリスクファクターとしてシステムのアーキテクチャとプロジェクトの関連性について紹介していきたい。「WindowsなのかLinuxなのか？」「Javaなのか.NETなのか？」。IT系雑誌で語られているような議論と実際の現場での議論とのギャップを交えながら紹介をしていく予定である。最後までお付き合いいただきたい。

筆者プロフィール

玉木 栄三郎（たまき えいざぶろう）

イー・キャッシュ株式会社 代表取締役社長

1972年香川県生まれ。

麻布大学獣医学部卒業。

東京医科歯科大学医学部博士課程修了。

大学院在学中から、大手企業のCTOなどを歴任。

2005年5月より現職。

2006年 Microsoft Regional Director になる。

須永 啓太（すなが けいた）

イー・キャッシュ株式会社

取締役　ビジネスデザイン事業部

インターネットベンチャー企業などで大手ポータルサイトのEコマースサイト構築におけるプロジェクトマネージャーなどを歴任後、イー・キャッシュ株式会社に入社。主にRFID システムのコンサルティング業務を担当。実はモノ作りが大好きで、最近プログラミングをまったくできないのが悩み。

「“失敗しない”データセンター選定法」バックナンバー

• いまさら聞けない、データセンターの基礎知識