情報システムの構築プロジェクトに多少のトラブルは付き物。
とはいえ解決に手間取ると、プロジェクトそのものが破綻してしまう。
危機的状況に陥ったプロジェクトを救うにはどうすればよいのか。
敏腕プロジェクト・マネジャたちに“火消し”の極意を聞いた。
| Part1：これが火消しのプロだ | ||||||||
| ||||||||
| Part2：危機はこう乗り切れ | ||||||||
|
本記事は日経コンピュータ2002年12月16日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。なお本号のご購入はバックナンバー、または日経コンピュータの定期ご購読をご利用ください。
主要サブシステムの詳細設計が遅れている」、「結合テストで性能が出ない」、「顧客側の責任者とプロジェクト・マネジャのソリが合わない」――。
情報システムの構築プロジェクトには、さまざまな困難がつきまとう。ひとたび問題に火がつくと、“鎮火”は容易ではない。稼働遅れや予算オーバーですむならまだマシだ。強行突破を試みた挙げ句、稼働直後から大トラブルを引き起こし、企業経営に深刻な影響を与える「動かないコンピュータ」も珍しくはない。
システム構築の現場は、問題プロジェクトをぼく滅するため、さまざまな手を打ってきた。「大失敗はもちろんだが、大成功があってもいけない。すべて計画どおりに進むのが一番」（日本IBMでプロジェクトの品質管理を担当する大久保隆氏）というのが基本的な考え方だ。
システム・インテグレータ各社にとっても、ごく一部の“問題プロジェクト”が残りの案件の利益を食いつぶす構図は避けたいところ。「問題プロジェクトが発生すること自体が問題」というスタンスで、プロジェクトマネジメント体系の確立や品質/進捗管理の徹底に力を入れている。プロジェクトマネジメントの国際的な知識体系「PMBOK」を全社規模で導入したり、プロジェクトマネジメントの国際資格「PMP」の有資格者を増やそうと躍起になっている。
こうした取り組みを続けていけば、問題プロジェクトの発生件数は確かに減るだろう。だが、決してゼロにはならないはずだ。人間がやる以上、「すべてのプロジェクトが何の問題もなく整然と進むことなどあり得ない」（NTTデータの青木富夫 第三公共システム事業部長）。
一大ブームを起こしているPMBOKにしても過度な期待は禁物だ。「PMBOKは最低限習得しておくべき知識をまとめた教科書。それを使いこなせるかどうかはマネジャの能力次第」。第一線のプロジェクト・マネジャたちは、異口同音にこう指摘する。
教科書に書いてない“極意”を学べ
それでは不幸にして、危機的状況に陥りかけたプロジェクトを救うにはどうすればよいのだろうか。
「プロジェクトの火消し人」。IT業界には、周囲から尊敬の念を込めてこう呼ばれる人々がいる。問題プロジェクトの収拾を得意とする敏腕マネジャたちの異名である。
彼・彼女の多くは普段、プロジェクト・マネジャとして、任されたプロジェクトを着実にこなしている。だが、いざ声がかかると即座に火消し人に変身する。暗礁に乗り上げかけた別のプロジェクトに急きょ乗り込み、事態を好転させる。短時間で問題が発生した原因を見極め、的確な対策を講じる。もつれかけた顧客との関係を修復したり、沈みがちなメンバーに自信を取り戻させるなど、それこそ八面六臂の活躍をする。
火消し人の活動は、なかなか表に出ない。だが、教科書には決して記述されない火消し人の極意を学ぶのは決してムダではない。
以下、Part1では火消しのプロ4人の奮闘ぶりを紹介する。続いてPart2では、火消し人たちが明かす危機からの脱出の極意をまとめた。
――（中略）――
特集：問題プロジェクトを救え
| |
| 危機はこう乗り切れ |
当初の目論見が大きく狂い、赤信号が灯った問題プロジェクト。立て直しの秘策を記した“教科書”はどこにもない。混乱の渦中に乗り込んで、一気に状況を好転させる火消し人たちも、特別なことをしているわけではない。基本に従って、目の前の問題を着実に解決しているだけだ。しかし、火消し人たちの証言を積み重ねていくと、通常のプロジェクトマネジメントの枠を超えた“極意”が浮かび上がってきた。
危機的状況に陥ったプロジェクトの立て直しは、並大抵の作業ではない。成功までの道のりは険しい。
「火消しは勝ち抜き戦。すべての局面で失敗は許されない」。問題プロジェクトの救済を得意とするローリーコンサルティングの文山伊織代表パートナーはこう指摘する。火消し人は限られた時間の中で、やるべきことを着実にこなし、ゴールを目指さなければならない。その足跡自体が“火消しのマニュアル”とも言える。
もちろん火消し人たちは魔法を使うわけではない。その行動の大半は、通常のプロジェクトマネジメントの基本を忠実に押さえたものだ。当たり前のことを当たり前のように実行していく。
それでも、第一線の火消し人たちの話を聞くと、一般のプロジェクト・マネジャが忘れがちな“技”を駆使していることがわかった。
プロジェクト・マネジャやシステム・エンジニアは、いつ問題プロジェクトに遭遇するかわからない（「あなたのプロジェクトは大丈夫？ 敏腕マネジャが明かす『火が噴く兆候10』」を参照[拡大表示]）。システム構築に携わるすべてのITプロフェッショナルは、火消しの術を知っておいて損はない。その極意は、通常のプロジェクトにおいても十分参考になるはずだ。
 |
| ●あなたのプロジェクトは大丈夫？ 敏腕マネジャが明かす『火が噴く兆候10』 |
極意 1
火元を見抜け
問題プロジェクトと、通常のプロジェクトの違いは何か。それは「問題プロジェクトが何らかのトラブルを抱えている」ことに尽きる。
当たり前のように聞こえるかもしれないが、このことは重要な意味を持つ。「トラブルの内容を正確に把握することなしに、危機的状況に陥ったプロジェクトを立て直すことはできない」（NTTデータの青木富夫 第三公共システム事業部長）。
「火消し人の極意その1」は、トラブルの所在と原因を正しく突き止める方法、そしてそのスピードにある。
問題プロジェクトが抱えるトラブルの内容はさまざまだ。「仕様を絞りきれない」、「進捗を正確に把握できない」といったプロジェクトマネジメントに起因するトラブルもあれば、「システムの応答性能が上がらない」、「バグが一向に減らない」といった技術面のトラブルもあるだろう。
途中からプロジェクトに参加した人間にとって、トラブルの所在やその原因を突き止めるのは簡単ではない。大抵のトラブルは複数の問題が複雑に絡み合って起こるからだ。プロジェクトの利害関係者（ステークホルダー）に事情を聞いても、だれ一人として本当の原因を知らないこともある。
そもそもすぐに原因がわかるようなトラブルなら、とっくに解決できているはずだ。トラブルの火が燃え広がったということは、それまでのプロジェクト・マネジャが原因をきちんと把握できなかった証拠でもある。
そこで問題プロジェクトの現場に駆けつけた火消し人は、まっさきに状況の把握に取りかかる。ベリングポイントの赤曽部克美ディレクターは「問題プロジェクトを立て直すには、初動が肝心。火消しに入ってから2～3日でトラブルの原因を突き止める」と言ってのける。別に赤曽部ディレクターが特別なわけではない。取材した火消し人たちは、ほぼ全員が同様の証言をする。この問題把握能力こそが、火消し人のコア・スキルの一つである。
謙虚に徹し、失敗を責めない
それでは火消し人たちはどうやって、複雑に絡み合ったトラブルの糸を解きほぐし、真の原因を突き止めていくのか。まず土台になるのは論理思考力。「現状の把握」には、設計書や議事録などのドキュメントを注意深くチェックし、矛盾やムリがないかどうかを論理的に検証する能力が求められる。この過程では「PMBOK」のような、プロジェクトマネジメントの国際的な知識体系に基づいて、状況を見直すことも有効だろう。レベルの差はもちろんあるが、ここまでは通常のプロジェクト・マネジャに求められる能力と質的な違いはない。
ただし、問題プロジェクトではドキュメントがきちんと整備されている保証はない。ドキュメントがそろっていたとしても、記述されている内容が現状を正確に反映しているとは限らない。「うまくいかないプロジェクトほど、ドキュメントの質が低い」（富士通の三浦壽男システムインテグレーション事業本部SIプロフェッショナル室長）。
多くの場合、火消し人たちは、以前からいるプロジェクト・メンバーから状況を聞き出し、ドキュメントの不備をカバーする。この“事情聴取”の巧拙が火消し人の力量を左右する。
火消し人たちは皆、事情聴取のテクニックを身に付けている。その内容は千差万別だが、共通点もある。
それは「責任追及をしないこと」だ。火消し人たちは、メンバーから状況を聞き出す際、淡々と事実だけを確認する。「ミスを含め、プロジェクトの問題点を正直に明かしてくれたメンバーを、『なんでこんなミスを犯したのか』と怒鳴りつけたなら、もう2度と本当のことを話してもらえなくなる」と富士通の三浦室長は説明する。
マイクロソフト日本法人でシステム導入支援部隊を率いる細澤幸重コンサルティング本部部長も同意見だ。「重要なのは危機に陥った原因を把握し、その対策を考えること。責任の所在を明らかにすることではない」。
“犯人探し”をしたくなる気持ちをぐっと抑えて、メンバーの話に耳を傾けるのは、口で言うほど簡単ではない。だが、「ミスを責めてしまうと、その後の立て直し作業に悪影響を及ぼす」。かつて大手メーカーで火消し人として鳴らした、ウィンアンドウィンの近藤哲生代表取締役は指摘する。「危機的状況に陥ったプロジェクトのメンバーは、だれしも責任を感じている。そこでさらに落ち度を問いただしたら、メンバーは立て直しを前に意気消沈してしまう」と説明する。
そうした意味で、現状の把握には何よりも謙虚な姿勢が求められる。「いくら立て直しの大任を背負って現場に乗り込んだとしても、それを鼻にかけるようなそぶりを少しでも見せるようでは、火消し人として失格」（新日鉄ソリューションズの大城卓システム研究開発センター システム基盤技術研究部長）である。
開発規模を正確に把握
火消し人たちは、プロジェクトの現状を把握すると、休む間もなく立て直し策の検討に入る。ここでもスピードが要求される。問題を把握してから2～3日で計画を立てる。つまり問題プロジェクトの現場に出動してから、長くても1週間で顧客に消火計画を提示できる状態にまで持っていく。火消し人にとって最初の1週間は、その後の成功を左右する最も重要な時期である。
立て直し策を練る際は、理想を追求しても「絵に描いた餅」になってしまう。稼働までに残された期間や、動員できるメンバーの数には限りがある。無数の制約条件の中で、いかに現実的な立て直し策を見いだすかが火消し人の腕の見せどころである。
プロジェクトの立て直しに、特効薬はない。一つひとつの問題に対して、基本通り解決策を考えていくしかない。「システムの要求仕様が固まっていないのなら要件定義を急ぐ」、「データベースの設計がまずくて性能が出ない時は、設計をやり直す」といった具合である。
残された時間、盛り込まなければならない機能、そして動員できるメンバーを考えると、どこかで妥協が必要になる。火消し人たちはシステム全体の開発規模を念頭に置いて、ギリギリの着地点を探っていく。
そのためにも火消し人たちは、開発規模の正確な把握に努める。大半の火消し人は、人任せにせず、自分でシステム全体の開発規模の見積もりをやり直す。「開発規模を正確に把握できるかどうかは、立て直しの成否を左右する」と考えているからだ。日立製作所金融ソリューション事業部の山崎一ITソリューション本部長は「開発規模の見積もりを誤ったために火を噴くプロジェクトも少なくない。惨事を繰り返さないためには、立て直し規模の正確な見積もりが欠かせない」と説明する。ウィンアンドウィンの近藤代表取締役も「開発規模を見誤れば、さらに進捗が遅れ、消火できないぐらい火が燃え広がってしまう」と警告する。
リスク項目の再チェックも、火消し人の重要な任務だ。実際に消火を始める前に、立て直し策に潜むリスクを洗い出しておく。「リスクの洗い出しを怠ると、いざ問題が起きた際に素早い対処ができない」と、野村総合研究所（NRI）の栗原良行プロジェクト監理部長は強調する。プロジェクト監理部は、NRIが手がける主要プロジェクトの進捗管理を担当する専門組織である。
続きは日経コンピュータ2002年12月16日号をお読み下さい。この号のご購入はバックナンバー、または日経コンピュータの定期ご購読をご利用ください。
「火消し人は、危機に直面したシステム開発プロジェクトを任されるとき、相当なプレッシャーを感じるのではないか」。特集の取材前、記者はこう考えていました。
その予想は外れました。「問題プロジェクトの立て直しでは、それほどプレッシャーを感じない。プロジェクトはすでに危機を迎えているので、現状よりも悪くなることはないからだ」。こう話す火消し人がほとんどでした。
とはいえ、やはり火消し人には、「問題プロジェクトを成功させなければ」という重圧がかかるのは間違いありません。実際のところ、火消し人はプレッシャーを感じないというよりも、「プレッシャーを感じていても事態は好転しない。いい意味で開き直りながら、前だけを見て突き進む」と腹をくくっているのだなという感じを受けました。「自分自身にかかるプレッシャーを制御できてこそ、火消し人なのだな」と、納得しました。
そんな火消し人は、プレッシャーよりもむしろ「火消しに慣れてしまうこと」のほうが怖いと話します。「火消しプロジェクトは、社内のSE要員や費用が比較的自由に使える。上司もいろいろと融通を利かせてくれる。こうした特別な環境に慣れてしまうと危険。通常のプロジェクトを担当できなくなってしまう」。なるほど。これまた納得させられました。（大和田）
