一昨年来のトラブル・プロジェクトをようやく収束させたこともあり、次のプロジェクトの提案活動や、案件立ち上げに業務をシフトし始めています。なにはともあれ、今回の反省を一言でいうと、プロジェクト受注以前の体制組成時に、スコープの見極め、対象業務・システム内容の把握が十分にできない状態で、プロジェクトを推進してしまったことです。
業務知識が不足し、対象業務領域の経験が不十分であったため、何が問題かの把握そのものが遅れ、リカバリー範囲が拡大してしまいました。
一番良いのは、業務・システム知識など、必要なスキルをもっている要員で体制を構築してスタートすることです。必要なスキルをもった要員が最初から十分に揃ってスタートできるプロジェクトの方がまれであることを考えると、次は、この不足の状況をプロマネやライン長が理解した上で、さまざまな手を打つことです。
プロジェクトの推進と並行して、社内外から必要要員の調達を図ること。特に、他のプロジェクトからメンバーの捻出をいかに計画的に行うかがポイントになります。また、プロジェクトに先行してアサインしたメンバーの業務・システム知識の底上げや、開発のライフサイクルに対応した育成計画を実施することも必要になります。また、必要要員の調達できるまでの時間、タスクの組み換えや、場合によっては、スコープの切り下げ、その代替案等について、顧客との交渉などを行う必要があります。
以上のことを、プロジェクト開始以前に決めておくことができていれば、通常のプロジェクトの運営に持ち込めたのだと考えています。予防に勝るリスク・マネジメントはないということを改めて認識しています。
トラブル・プロジェクトの怖さは、全体の１割が破たんすると、プロジェクト全体の利益の大半を食いつぶすことにあります。もし３割近くがバーストすると、プロジェクトの総予算近くを持ち出すおそれもあります。また、コスト面だけではなく、リカバリーに投入される人材は、プロマネやリーダーをはじめ、業務に関して知見をもっている人、アーキテクト、ＰＭＯなど広範なメンバーになります。他のプロジェクトであれば活躍できるメンバーをリカバリーのために優先してアサインすることが多くなるため、その機会損失も大きい。また、リカバリーのプロセスは、通常のプロジェクトの運営より厳しいため、心身いずれかの不調を訴えるメンバーも急増します。
だからこそ、予防のためにも、スコープの見極め、体制組成、プロセスの確立が重要になると思います。
そうはいいながら、プロジェクトが不調に陥った時、どう対応するか、リカバリー・マネジメントも大切であると考えています。
プロジェクトが不調に陥ると、その兆候が、進捗遅れ・期日管理遅れ、成果物の品質低下などに現れるため、プロジェクト管理のプロセスに問題があると思われがちです。
プロセス改善が効果的なのは、軽傷から中傷のレベルの場合です。
プロセスの改善は、基礎体力をつけるようなものであり、薬なども利用しながら、自然治癒力による回復を待てるようなプロジェクトの場合、効果があるし、根本的な対策になります。
ところが、大怪我をした重傷レベルであれば、入院や外科手術のような緊急の処置が必要になります。たとえば、性能問題であれば、プロダクトが初物で、その品質が悪すぎたり、プロダクト同士の組み合わせが初物である場合、プロダクトのチューニングや、アプリケーション側の利用方法の見直しなどの回避策がなければ、アーキテクチャそのものの作り変え、Ｈ／Ｗの大幅な増強が必要になります。プロジェクトの初期にフィージビリティ・スタディで課題が明確に把握でき、手が打てるとよいのですが、大量データや高負荷によるストレステストなどを行うプロジェクトでは終盤に発覚することの多いのが実状です。プロダクトの品質が悪いことが判明した場合でも、プロダクトのコアの部分に問題がある場合、修正パッチでは解決できず、メジャー・バージョンアップでしか対応できないこともあります。そうなると、メジャー・バージョンアップを行い、アプリケーション側にも大幅な変更を加えるか、メジャー・バージョンアップを諦め、制約付きの回避策に止め、運用への負担を増やしてカバーすることを覚悟するか、厳しい選択を迫られることになります。
プロジェクトのリカバリーにおいて、初動はとても大切です。しかし、初動での見極めと、社内外への対応を並行して行う必要があるため、非常に難しいものになります。
リカバリー・マネジメントの手順は、以下のとおりです。
１．問題の把握
２．原因分析・把握
３．リカバリー・プランの策定
４．社内のプロジェクト・オーナーの了解
５．リカバリー体制の組成
６．顧客の承認
７．リカバリーの実施
８．リカバリー状況のモニタリング
１．問題の把握
定量評価：ＱＣＤをメトリックスに基づき把握する。許容範囲を超えた指標を確認する。
定性評価：アンテナをいかに張るかがポイントになります。
様々な兆候を見逃し続け、手の打ちようがなくなってからトラブルが組織内で顕在化します。定例報告時のプロマネやリーダー層からのヘルプの声は、その表現方法がよほど上手くないと、無視されることが多いかもしれません。また、顧客経営層からのクレームで、はじめて組織として認識されることも多いと思います。
そして、はじめて
・ユーザーからの不満やクレームの事実確認
・プロジェクト・メンバーの問題認識の確認
がはじまります。
そのヒアリングの際は、「できているはず」「やっているはず」という思い込みをやめ、三現主義・・現場・現物・現実そのものを確認する必要があります。
２．原因分析・把握
問題の把握によって、大規模でトラブルの度合いが大きいほど、大小・高低さまざまな問題がでてきます。この問題群からいかに原因を突き止めるか。
長尾清一さんの『問題プロジェクトの火消し術―究極のプロジェクト・コントロール』（＊１）において、仮説検証により問題を定義することの重要性が指摘されています。
≪火消しに必要なのは、目的思考型アプローチである。
現場で発生している現象を感度よく観察し、問題を構造化することで、
問題や要因への見当（仮説）をつけ、「何を検証したいのか」の目的を
見失うことなく、仮説を検証していく。≫（＊１）
事実を基に、仮説を見直す。
≪必要なのは、問題を漏れなく多層的に構造化してとらえるスキルである。
問題プロジェクトで表出している現象に対し、“Ｗｈｙ”による問いかけを
繰り返していく。≫（＊１）
現象と本質的な問題を切り離す。
問題を構造化し、全体像を俯瞰して仮説を立てる。
そして、間違った犯人探しをしない。錯覚に陥らない。
≪先入観、ステレオタイプ型認識、既成概念、過去の経験、職種、立場、
会社のカルチャー、社会通念、価値観、理解力、信念、新聞・雑誌・テレビなど、
さまざまな要素によって、我々の深層には、外部からの情報の質・量を取捨選択
するフィルターが形成されている。・・
フィルターに対する無意識・無自覚こそが、本質的な問題の発見にとって最大の
阻害要因となっている。≫（＊１）
３．リカバリー・プランの策定
そもそもの目的に立ちかえることが大切です。
プロジェクト当初にできなかった、業務・システム知識など必要なスキルの確保された要員体制を再構築して、リスタートする。そのための制約事項、前提事項を再度、明確にする。
プロジェクトの工程が複数並走しているため、工程毎の対応策に優先順位をつけます。
４．社内のプロジェクト・オーナーの了解
事実に基づき、問題と根本原因、リカバリーに必要な対応策を説明し、了解してもらいます。稲垣哲也・一柳隆芳『ＩＴプロジェクト実践リカバリーマネジメント』に、この説明の際の注意点があります。
≪プロジェクトのプレッシャーに負けてしまい、できそうにもないことを約束したり、
情報を隠蔽したり、分からないにもかかわらず分かったと言ったりすると、
必ず後になって齟齬が出ることになる≫（＊２）
そうなると、リカバリー・マネジャーは、プロジェクト・オーナーの信頼を損なってしまう。
決してむちゃな計画に妥協してはいけない。バースト・プロジェクトには「魔法」がかかっているため、その「魔法」を解くために、リカバリー・マネジャーがアサインされたにもかかわらず、妥協してしまうと、リカバリー・マネジャー自らが「魔法」にかかってしまいます。
５．リカバリー体制の組成
リカバリー・プランを推進する要員の調達を行う。
社内の他部署や他プロジェクトからの必要要員のシフトを行う。
社外からは、パートナーのトップに申し入れ、必要要員をアサインしてもらう。
プロダクト・ベンダーとのステアリング・コミッティを開催し、技術支援の協力を取り付ける。
６．顧客の承認
リカバリー遂行のためには、顧客の協力も必須である。そのための時間・リソースの協力を取り付ける必要があります。
≪火消し役にとって勝負所の１つが、リカバリー・プランをユーザーから正式に承認
してもらうことである。
承認が得られなければ、場当たり的に方向性と解決策を決める“パッチワーク的”な
リカバリーに陥る。≫（＊１）
≪火消し役には自分が「捨て石」になる覚悟で積極的に問題をさばいていく姿勢が
求められる。ベンダー上層部も、ユーザーからの圧力による振り戻しを防ぐために
現場の問題を理解し、組織レベルで火消し役を擁護する姿勢を持ちたい≫（＊１）
７．リカバリーの実施
リカバリー・プランに基づき、プロジェクトを運営する。
リカバリー対策を実施した結果、新たに判明した問題に対する対策を行う。
８．リカバリー状況のモニタリング
プロジェクトが、リカバリー・プラン通りに実行・運営されているか、
週次、月次にてモニタリングする。
ところで、リカバリー・マネジメントの手順は、程度の差はあれ、以上のプロセスを踏むと考えていますが、リカバリー・マネジャーをはじめとするリカバリーの主体は誰か、がポイントになります。
当初のプロジェクトのリーダーやメンバーが継続して主体となるのか。それとも、入れ替えてしまうのか。その判断基準は、リカバリーするプロジェクトのトラブル・レベルによります。
軽傷の場合、
・オーバーワークのところを巻き取る。
顧客とスケジュールの調整をし、業務の平準化を図るか、
スポットの追加投入を行います。
・不足しているスキルを補完する。
特定の要素技術の知見者のフォローを行う。
・各種管理（進捗管理、品質管理、課題管理など）の棚卸しを支援する。
交通整理・整理整頓を支援する。
スポットの支援や数か月以内のフォローで、当初メンバー主体で、
プロジェクトがリカバリーする。
中傷の場合、
・プロマネやリーダー補佐として、ＰＭＯ同等のスキルや経験を持つメンバーを
アサインし、継続支援する。
・それまで忙しすぎてできていなかったプロジェクトチーム内の会話、情報共有の
機会をもうける。
・チームとして問題解決できる仕組みをつくる。
重傷の場合、
・トップガン（第一人者）部隊の投入
業務面、ＩＴ面で重大なトラブルを抱えている場合、トップガン部隊の投入が必要になります。
いつまでたっても、業務要件が固まらない場合、対象業務の知識が不足しているため、 必要な調査やヒアリングそのものが進まないことが多い。その場合、問題を紐解ける知見者のアサインが必須となります。
アーキテクチャ面で問題を抱えている場合、個々のアプリケーションでは解決できないため、フレームワークの作り直しなどアーキテクチャそのものの見直しが必要となります。
そうでなければ、進捗管理や品質管理などの管理プロセスを回したとしても、プロジェクトは正常化しません。
・従来メンバーの交替
重傷まで陥ったプロジェクトの場合、従来メンバーは心身ともに疲弊しきっています。
残しても立ち直らず、十分なパフォーマンスを出せず機能しないことが多い。
顧客の了承が得られるのであれば、いったん中断した方が、体制の再構築にあたってもよいのでしょうが、中断できないプロジェクトにおいては、ずるずると従来メンバーを引きずることとなり、メンバー自身は疲弊し、また、チームとしてもダメージは大きくなります。
・リカバリー予算の承認の取り付け
システムのカットオーバー時期を、プレスリリースしている中で、プロジェクトの中断やプロジェクト全体計画の変更が行えるか。また、延伸に伴う費用負担は、大規模プロジェクトであれば、数千万円から数十億円かかるため、顧客企業の経営層の決断が必要となります。
リカバリー・マネジメントを行いながら痛感するのは、健康管理と同じく、病気になってからの治療より、日頃の予防がいかに大切か、を再認識することです。
リカバリー・マネジャーとしてはもちろんのこと、組織としてここまで苦労した経験を、次のプロジェクトに活かせるかが、個人・組織としての成長につながるのだと思います。
（＊１）長尾清一『問題プロジェクトの火消し術―究極のプロジェクト・コントロール』日経BP社 ２００７年刊
（＊２）稲垣哲也・一柳隆芳『ＩＴプロジェクト実践リカバリーマネジメント』ソフトリサーチセンター ２００９年刊