一般的にシステムというものはリリース直後が最も手間がかかり、その後、運用が落ち着いていくと思われがちですが、一概にそうとは言えないのが現実です。
現状の機能に変化を加えないのであれば問題ありませんが、まったく変わらないビジネスを提供し続けることができる会社は稀でしょう。
例えば携帯電話業界では、夏モデル/冬モデルのような年2回のビジネス変化が必ず発生しており、料金プランの変更や新サービス・機能のリリースが行われます。2009年冬のドコモの場合、GPSに関する新機能が新たに加わりました。
機能の追加や改修が生じた場合、既存業務への影響が生じないようにするため、リグレッションテスト(既存機能の正常稼動テスト)が必要になります。ドコモの場合、今までコンテンツプロバイダ側で実装されてきた個々のGPS関連サービスはそのまま稼働できる上で、オートGPSによるサービスが追加実装できなければならないため、次のようなテストが行われているはずです。
オートGPS機能の追加によって必要になる可能性のあるテスト
- オートGPS機能利用に関するテスト
- 前回リリースしたGPS関連機能に関するテスト
- 前々回リリースした・・・
テストの結果、既存のプログラムを変更しなければならないことも数多くあります。このとき、プログラムの根本的な問題箇所を修正することが望ましいのですが、手間を惜しんで、表面上のツギハギ修正にとどめて終わらせることもあります。これが繰り返されると、スパゲティ状の入り組んだプログラムが出来上がるのです。
最たるはメインフレーム上のシステムでしょう。多くの方が御存知の通り、メインフレーム上のシステムにはスパゲティ状になったプログラムが多く存在しています。これらプログラムを紐解いて再設計することは困難を極めるため、それを避けるために、例えばIBMメインフレームを採用している企業ではIBM zServerを採用する企業も少なく有りません。
ある1社では、IBM系メインフレーム上で稼動している生産管理システムをオープン系に切り替える計画を立てていましたが、現状を調査するにつれて、あまりにも複雑なプログラムの関係性に嫌気が差していたところに加えて、担当ベンダーからの「動いていることが奇跡です。ゼロから作り直した方が早いですよ」という報告を受け、zServerを使って何も丸ごと移すよう計画を変更したほどです。
先にあげた話をITILの見地で捉えなおすと、システム改修にまつわるワークアラウンド(暫定対応)が繰り返された、と考えることができます。ワークアラウンドはその場を凌ぐための一時的な対応であり、その後、根本原因を解決するために問題管理プロセスを実行するのです。
問題管理にはリアクティブとプロアクティブがあります。
リアクティブな問題管理
- #r-1: 問題の識別と記録
- #r-2: 問題の分類
- #r-3: 問題の調査と診断
- #r-4: エラーの識別と記録
- #r-5: エラーの評価
- #r-6: エラーの解決策の記録
- #r-7: エラーのクローズ
プロアクティブな問題管理
- #p-1: トレンド分析
- #p-2: サポート処置の特定
- #p-3: 関係者への情報提供
続きはEnterpriseZineを御覧下さい。
http://enterprisezine.jp/article/detail/2111
posted by 吉澤準特 at 18:01
|
Comment(0)
|
TrackBack(0)
|
業界裏話