前回、基幹系システムの再構築で発生しがちな問題を、事例をベースに紹介した。主な問題には次の三つがあった。
(1)「現行踏襲+仕様変更」というスコープの中、現行システムの仕様が把握し切れていないまま着手したこと
(2)開発段階で、ソースの自動変換だけでは済まない場合があったこと
(3)事前調査不足によって、テストの完了条件が不明だったこと
事例では、プロジェクトの着手段階で現行システムの仕様を把握できてなく、それに伴うリスクを勘案していない計画となっていた。そのため、開発途中で(1)~(3)のような問題が発生したのだ。
これらの問題を未然に防ぐためには、再構築プロジェクトの企画・計画段階で、
現行システムの状態とそれに伴う再構築時のリスクを把握しておくことが重要になる。
それを実現するには、
(1)現状システムの状態の把握
(2)新システムへの要求を勘案して最適な再構築手法の選択
(3)再構築を実施するためのリスク把握、対応方針の決定
(4)再構築プロジェクトの計画(工数、工期)策定
(5)上記に対するステークホルダー間での合意
の五つが必要になる。
問題化した事例では、「設計書は存在する」「有識者は存在する」との前提で開発を進めたものの、実際には存在しない状態であった。要件が正しく把握できるか否かは、発注者すなわちユーザー側が責任を持って判断すべきものである。また、再構築後のシステムの最終確認もユーザーの責任であり、上流からの積極的な参画が必須といえる。
再構築したシステムによって実現されるのはユーザー企業の経営課題の達成だ。企画・計画工程はユーザーにとって自社の経営資産であるシステムの今後を決める重要な工程であり、システムオーナーであるユーザーが主体となって活動しなければならない。
今回は、(1)~(3)までを実施するためのリスク把握までの実施方法を解説しよう。再構築手法の決定までの流れは、次の四つのステップとなる(図1)。
ステップ1:現行システムの調査・分析(現状システムの状態の把握)
ステップ2:新システムの要求の整理(新システムへの要求を勘案)
ステップ3:再構築手法の選択
ステップ4:再構築手法の決定とリスクの抽出