問題プロジェクト化する要因の一つに、現行のシステムを再構築する際に「現行踏襲」という言葉があります。SierやITベンダ、ユーザ企業で多くのプロジェクトの課題検討を行ってきました。新規のお客様や技術に取り組む場合ももちろん問題プロジェクトになるのですが、本来現行のシステムが動いていて、そのシステム通りに動かす現行踏襲であれば、そんなに問題が起きるわけがないと考えてしまいがちです。
ところが、現行のシステムは長年使用してきているので、様々なユーザや利用者や開発者が関わってきている「細分化」、体制が変更になったり、担当している人が変わったりして全体がわからなくなっている「断片化」、ビジネスや技術が外部環境の変化に応じて、仕様変更が繰り返されており、その情報がわからなくなっている「領域の変化」などによって、問題プロジェクトになるケースが多いようです。
このようなシステム再構築を成功に導くために、情報処理推進機構（IPA）で、「システム再構築を成功に導くユーザガイド」が2017年にまとめられています。本日(2018.02.15)、このガイドの第2版(2018年2月末予定)が発刊されるにあたり、セミナーが開催されましたので、参加してまいりました。
▼システム再構築を成功に導くための手法選択と計画立案
～再構築におけるリスクの正確な把握と対策の合意手順を解説～
セミナーでは、まずIPA/SECの研究員である山本英明氏から、全体像のお話があり、その後、ガイドの執筆をされた委員の皆さんから、ガイドの解説とガイドの後半に記載されている事例についてご説明をいただきました。ITベンダの方だけでなく、ユーザ企業の方からもお話がありました。
このガイドでは、再構築のテーマを決めた上で、最適な再構築手法を選択するプロセスを４つのステップでまとめています。(第2章)
① 現行システムの調査・分析
② 新システムの要求事項分析
③ 再構築手法の候補を選択する
④ 再構築手法の決定
それぞれのステップごとにインプット、手法や考え方、アウトプットが定義されています。
第3章の計画策定編では、システム化計画の策定時に検討する際に考慮すべき観点を8つに分けて、定義しています。各々の観点ごとに留意すべき点が整理されています。
観点A：要求の確認
観点B：現行踏襲内容の明確化
観点C：現行資産活用方針の検討
観点D：現行業務知識不足への対応
観点Ｅ：品質保証の検討
観点Ｆ：意思決定プロセスの策定
観点Ｇ：データ移行の計画
観点Ｈ：再構築の計画と見積もり
なお、第2版では、上記に「業務要件の変更／追加への対応」が追加されるとのことです。
事例については、2つの事例を紹介いただきました。一つは、「現行資産活用方針の検討」の事例、二つ目は、「意思決定プロセスの策定」の事例です。
最初の事例は、ベンダ企業の事例です。ツールを利用して一括自動変換ができればよいが、そのようなツールはなかなかないので、移行元のどの部分をどのように移行するかを決めて、現行資産活用を行う事例です。例えば、画面は新規作成するが、プレゼンテーション層は現行資産の一部利用する。さらにアプリケーション層は移行元、移行先ともにＪａｖａだったので、ソースをそのまま活用するといった事例でした。
2番目の事例は、ユーザ企業の事例です。ここでは、2つの事例を紹介いただきました。ＥＲＰパッケージの追加開発方針について、ステアリングコミッティでどのように意思決定を行ったかの事例と事故対応システムにおいて、イテレーション開発において、実務担当者レベルでは、ユーザ部門とＩＴ部門で折り合いがつけられない場合のエスカレーションルールを決めていった事例です。
いつも問題プロジェクトで振り返ってみると、やるべきプロセスや役割をきちんと果たせていなかったということが多いのです。やるべきことがわからなかったという点については、今回のようなガイドが整備されることは重要だなと感じます。
しかし、事例をお聞きすると、やるべきことがわかったときに、それを実施できるようにしていることがポイントです。一方、問題プロジェクトになった事例では、「なんとかなる」、「がんばる」で進めてしまうことが多いようです。その差はどこにあるのでしょうか。ここが明確にできると、問題プロジェクトを減らせると常に考えております。
以下は資料のリンクです。
▼「システム再構築を成功に導くユーザガイド～ユーザとベンダで共有する再構築のリスクと対策～」
https://www.ipa.go.jp/files/000057294.pdf
▼「デジタル変革に向けたITモダナイゼーション企画のポイント集」
https://www.ipa.go.jp/files/000063997.pdf
0コメント