多額のロスコストを発生させるプロジェクトの典型を示すアンチパターン。特に出現頻度の高いアンチパターンはロスコスト防止に威力を発揮する。今回はマイグレーションプロジェクトにおける3つのパターンと対策を示す。

 今号から、アンチパターンの具体例を参照しながらロスコストに至る背景や予兆の見つけ方、対処方法について解説していきます。今回のテーマは「マイグレーション起因のロスコスト」です。

 図1にマイグレーションのイメージを示しました。マイグレーションは、ハードウエア製品や基盤ソフトウエア(OSやデータベースソフトウエアなど)の入れ替えに伴い、業務アプリケーションを新しい環境で動作するように移行することです。アプリケーションに実装されている業務プロセスは変更しません。ハードウエアやソフトウエアの販売やサポートの終了(EOL:End Of Life)など老朽化に伴うプラットフォームの更改、性能対策やデジタル化に備えたプラットフォームの切り替え、トータルコスト削減を狙ったクラウド環境への移行などが主な狙いです。

図1●マイグレーションとは
[画像のクリックで拡大表示]

 業務プロセスや業務要件が変わらないので、難易度は高くなさそうに見えますが、そうではありません。業務を変えずにプラットフォームを切り替えるというニーズは基幹システムに多く、かつマイグレーションを行う背景は、ITに関連する事情によることが多いので、必ずしも業務部門の理解が得られるとは限りません。マイグレーションにより業務に支障が出ると、情報システム部門が信頼を失う事態にもなりかねません。

 確実に切り替えなければならないのですが、基幹システムのマイグレーションは、移行対象となる資産が膨大で大規模プロジェクトになりがちです。あるいは長く稼働していて現行システムの詳細が判らなくなっていたり、継ぎ足し継ぎ足しエンハンスされてきて構造がいびつになっていたりするなど、様々なリスク要因があります。

 では、どのようなところに気をつければよいか、マイグレーションプロジェクトで最も出現頻度が高い3つのアンチパターンを基に、ロスコストに至る現象と対応策について見ていきましょう。

パターン1:移行作業の役割分担が不明確

 最初のアンチパターンを図2に示しました。識別番号をM001とします。タイトルは、「マイグレーション×役割分担不明確→メンバーの調整できず」です。マイグレーションを行うプロジェクトでは、移行作業に伴うロスコストが多いようです。移行作業とは、現行システムから新システムに切り替える作業のことです。ロスコストに至る経緯は、以下のような流れです。

図2●役割分担が不明確なパターン
[画像のクリックで拡大表示]

経緯

 要件定義でプロジェクト計画を作成したが、移行作業の役割分担が不明確で、移行手順を作成する段階になって役割分担の認識齟齬が判明。お互い相手が実施すると思っていた作業があることが分かり、その作業を実施した側が追加作業によりロスコストとなった。

 また、参加必須メンバーのアサインが漏れていて調整しようとしたが、プロジェクトが希望する時期に参加できず、移行スケジュールの見直しにより、納期遅延となりロスコストとなった。

 マイグレーションプロジェクトには、システムを利用する各業務部門や複数のITベンダーなど、多くのステークホルダーが関係してきます。一般的には、こうしたステークホルダー間の調整は、ITベンダー側が行うには無理がありますので、ユーザー主体で行い、ITベンダーは準委任でサポートします。

 しかし、ステークホルダー間のコネクションの強さはケースバイケースです。例えば現行システムを担当するITベンダーは、関連する業務部門と良好な関係を保っていて調整できたかもしれませんが、新システムを担当するITベンダーが調整できるとは限りません。役割分担は、従来通りでよいだろうと思い込むのは危険です。

 役割分担が不明確なことに起因して、アンチパターンの「参加必須メンバーの調整が難航し、アサインできず」という状態になるとさらに深刻です。即、納期遅延となります。

 納期遅延が逸失利益やプロジェクト要員の期間延長などのロスコストにつながることはもちろんですが、プラットフォームの老朽化対応を目的としていた場合、現行システムの利用延長に伴い支払わなければならない保守費など、余分にかかったコストはすべてロスコストになります。さらに、サポート切れの製品を利用して障害対応にリスクを抱えるようだと、事業の継続性を脅かすことにもなりかねません。

対応策

 このように大きなリスクを伴う役割分担の認識齟齬を防ぐには、WBS(Work Breakdown Structure)を作成し、その中で役割分担を明確化することが肝要です(図3)。WBSは、移行に関連する作業項目を抜き出したものです。

図3●マイグレーションプロジェクトでのWBS
[画像のクリックで拡大表示]

 実際に問題になるのは、カットオーバー直前に行う「O 移行」フェーズの各作業がうまくいかなかったときですが、リスク対策は要件定義段階の「A.5.x 移行方式検討」から始まります。ソースプログラムと業務データの移行方式を決め、決めた移行方式に基づいてプロジェクト計画を立案します。役割分担もプロジェクト計画で設計します。

 この段階での役割分担は、図3のWBSに示すように組織単位で決めていきます。WBSに基づいて役割分担を合意することが、ステークホルダーの洗い出し漏れや、相手がやってくれるという思い込みを防ぐための最大の対応策になります。

 特にマイグレーションでは、「B.4.x 移行方式設計」で行う業務データの移行方式の設計や「O.3 移行リハーサル」での品質の確認、「O.4 移行」での移行作業や業務データの確認テスト、カットオーバーの可否判定など、業務部門の参加を確実にすることが重要です。業務プロセスは変わりませんので、業務部門のメンバーがプロジェクトに専任することはまれです。このため、プロジェクト計画の段階で見落としてしまうとプロジェクト内でフィードバックがかかることは期待できず、気付くのが遅れてしまいます。

 ステークホルダー分析は、表面的に行うのではなく、「業務を管轄する業務部門はA部門だが、B部門も関連するし、実際のオペレーションはC部門に聞かないとわからない」など詳細な情報を集めて、必要となる業務部門を洗い出し参画を要請します。以上が役割分担の認識齟齬を防ぐために、要件定義段階でなすべきことです。

 次の基本設計であるシステム方式設計の段階では、「B.4.x 移行方式設計」で移行作業を詳細化し、どのタイミングで各ステークホルダーが参加するかを決め、移行リハーサルの計画を立てます。組織単位で決めた役割を誰が行うか、個人名を確定させます。WBSに記述する役割分担も、組織名から個人名にブレークダウンします。システム詳細設計段階の「G.8 移行詳細設計」では、作業内容をオペレーションレベルで確定させ、移行所要時間を見積もり、移行作業の実現性を検証します。

 基本設計/詳細設計の段階でのリスクは、実際に移行作業を行うのはもっと後なので、移行手順は作業が始まる前に作成すればよいと考え、後回しになってしまうことです。せっかくプロジェクト計画で役割分担を明確にしても個人名の特定が遅れ、参加メンバーのスケジュールが確保できなければ納期遅延につながります。スケジュールを優先して、必須メンバーの参加なしに無理やりプロジェクトを進めれば品質問題を引き起こしかねません。移行手順の作成の優先度を下げることなく進めることが大切です。

 業務部門の巻き込みについては、役割分担を明確にしたからといって安心してはいけません。業務部門のメンバーが業務上の理由で参加できなくなる、あるいはスキルが不足しているということも考えられます。移行当日に参加できなくなってカットオーバー延期という事態になると、そこまでの過程がうまくいっていても失敗プロジェクトになってしまいます。カットオーバーまで気を抜かずリスク連鎖モデルのノードが活性化しないよう監視する必要があります。

 また、今回は移行について取り上げましたが、業務部門が参加する運用テストについても同じことが言えますので、「移行」を「運用テスト」に読み替えてアンチパターンを読んでください。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら