その場しのぎを繰り返していませんか？
一般的にシステムというものはリリース直後が最も手間がかかり、その後、運用が落ち着いていくと思われがちですが、一概にそうとは言えないのが現実です。現状の機能に変化を加えないのであれば問題ありませんが、まったく変わらないビジネスを提供し続けることができる会社は稀でしょう。
例えば携帯電話業界では、夏モデル／冬モデルのような年2回のビジネス変化が必ず発生しており、料金プランの変更や新サービス・機能のリリースが行われます。2009年冬のドコモの場合、GPSに関する新機能が新たに加わりました。
機能の追加や改修が生じた場合、既存業務への影響が生じないようにするため、リグレッションテスト（既存機能の正常稼動テスト）が必要になります。ドコモの場合、今までコンテンツプロバイダ側で実装されてきた個々のGPS関連サービスはそのまま稼働できる上で、オートGPSによるサービスが追加実装できなければならないため、次のようなテストが行われているはずです。
- オートGPS機能利用に関するテスト
- 前回リリースしたGPS関連機能に関するテスト
- 前々回リリースした・・・
テストの結果、既存のプログラムを変更しなければならないことも数多くあります。このとき、プログラムの根本的な問題箇所を修正することが望ましいのですが、手間を惜しんで、表面上のツギハギ修正にとどめて終わらせることもあります。これが繰り返されると、スパゲティ状の入り組んだプログラムが出来上がるのです。
最たるはメインフレーム上のシステムでしょう。多くの方が御存知の通り、メインフレーム上のシステムにはスパゲティ状になったプログラムが多く存在しています。これらプログラムを紐解いて再設計することは困難を極めるため、それを避けるために、例えばIBMメインフレームを採用している企業ではIBM zServerを採用する企業も少なく有りません。
従来のIBM系ホストで稼働させてきたアプリケーションをそのまま移行できるというのがzServerの利点の一つです。実際、私が知る8件のzServer採用のケースのうち、6件がこれを理由にしたものでした。
ある1社では、IBM系メインフレーム上で稼動している生産管理システムをオープン系に切り替える計画を立てていましたが、現状を調査するにつれて、あまりにも複雑なプログラムの関係性に嫌気が差していたところに加えて、担当ベンダーからの「動いていることが奇跡です。ゼロから作り直した方が早いですよ」という報告を受け、zServerを使って何も丸ごと移すよう計画を変更したほどです。
システムとは常に変化し続けるものであり、その場限りの改修の繰り返しは別の問題を引き起こすことがよくあります。これを認識した上で、今回の本題である問題管理に入りたいと思います。
