|
||||||||||||||
| 1 2 3 次のページ | ||||||||||||||
| イントロダクション | ||||||||||||||
|
今回はどのようなマイグレーション方式(Rehost/Rebuild方式に関わらず)のプロジェクトであっても、まず導入部において実行することが推奨されている「システム資産の棚卸」について解説する。なお、今回の連載ではメインフレーム上の情報資産の棚卸を想定する。 |
||||||||||||||
| システム資産の棚卸の必要性 | ||||||||||||||
|
レガシーシステムには長い年月の中で、新規機能の追加にともなって使われなくなっている、もしくは業務の変更などにより利用されなくなっている機能が残存していることが多い。過去の事例では、稼動しているアプリケーション資産の半分以上が不要資産だったことさえある。 このような不要資産まで移行の対象に含めると、その作業負荷は「分析→設計→製作→テスト」という開発のライフサイクルの全般にわたって影響する。そのため、コストは当初の見積りに比べて非常に大きくなるという場合がある。 また、長いシステム開発の歴史の中で初期のシステムの設計ドキュメントが存在しなかったり、残っている仕様書にもそれまでの追加・修正の履歴が正確に反映されていない場合もある。そして運用管理担当者であっても、「そのシステムの正確な規模をほとんど把握できていない」ということすらあり、不要資産の全体像を把握しきれない現状がある。 よって、ほとんどのレガシーマイグレーションのプロジェクトはシステム資産の棚卸を行い、錯綜している現状システムの中から有効資産を正しく把握することからスタートする必要があるのだ。 このシステム資産の棚卸により、有効資産を正しく把握できれば、検討範囲を有効資産の範囲に絞って無駄な検討コストを排除するとともに、システム構成の特性を把握することが可能となる。そして、ここで入手したデータは新基盤のサイジング検討の際に参考資料になる。 |
||||||||||||||
| システム資産規模を把握することの必要性 | ||||||||||||||
|
またシステム資産の棚卸を行う意義は、単にマイグレーションプロジェクトのためだけではない。自らのシステム資産規模(有効資産の規模)を正しく把握し、そして管理することはシステムの日常維持管理の効率化をはかる上でも効果がある。 不要資産を排除しておくことで、メンテナンス時の影響調査範囲を有効資産の範囲だけに絞ることができる。そうすることにより、開発・保守の効率化に繋がることはもちろん、不要システムによる無駄なハードウェアリソースの排除や標準化遵守度のチェックも可能なのである。さらにサブシステム単位の規模を把握することは、サブシステム単位でのシステム開発維持要員の配置・育成計画を立案する際に有効なデータとなる。 |
||||||||||||||
|
1 2 3 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||


