メンテナンス：システムの寿命を延ばす途中改良

変更しやすいシステムが必要な時代に

　変化の激しい現代社会においては、状況に応じて業務の形態を変える機会も多い。当然、関連する情報システムにも変更が求められる。ところが、変更の内容によっては、簡単に対応できないこともある。大切な要望へ対応できないと、情報システムが原因で業務を改善できない事態に陥る。情報システムの本来の目的は、業務の機能や効率の向上なのに、逆にネックとなってしまう。
　重要な業務を扱っているシステムほど、出てきた要望を満たさなければならない。簡単には作り替えられないので、メンテナンスによって機能を改変し、適度に変更しながら使うのが現実的な選択となる。
　システムの変更では、提供する機能を一定レベル以上に保つとともに、システムの安定度といった品質も高く維持しなければならない。そのためには、システムを変更しやすく設計するなど、最初に設計する段階からの考慮が求められる。また、適切に変更するためには、いくつかの条件を満たす必要がある。その代表的な項目を挙げてみた。

システム変更への対応するポイント

・変更の方向や箇所を適切に予測する ・変更しやすい構造でシステムを設計する ・システム仕様書などの資料をきちんと残す ・テストのシステムやデータを保存しておく ・トラブルの発生しにくい変更手順を規定する

　最初の項目は、設計する段階で注意すべき点である。どんな変更にでも対応できるシステムに仕上げるのは、構造が複雑になるので非現実的だ。ある程度の方向に絞り、変更しやすく作るのが妥当な選択となる。業界の将来を調査し、変化する箇所を見極めなければならない。
　２番目の項目は、設計に関する内容だ。調査や分析で得られた結果を生かしながら、システムの内部構造を変更しやすく設計する。この部分では、オブジェクト指向などの新しい技術が役立つ。何から何まで自作しようとせず、パッケージやユーティリティを活用するように心掛ける。開発の規模を小さくすることで、後からの変更も容易になる。ただし、システムの柔軟性を制限するような使い方だけは避けるべきだ。
　３番目と４番目の項目は、システムを変更する時点で必要な準備である。仕様書などの資料がなければ、変更の作業が極めて困難になる。設計上で変更を考慮した箇所があるなら、その内容も書類として残さなければならない。業界の調査結果など、仕様書以外の資料も、変更の内容を検討するときに役立つので保存する。変更したシステムでも、本格的なテストを経てから、実際の運用に移る。最初に用いたテストシステムやデータを残しておくと、テスト作業がラクになる。

システムの変更手順をきちんと規定する

　最後の１項目は、システムを変更する際の手順に関した内容だ。末端の作業者がきちんとテストせずに変更すると、余計なトラブルを発生させてシステムを止めてしまいかねない。また、要望を何でも受けたのでは、可能な仕事量をオーバーしてしまい、重要な変更が後回しにされる。このような状況を防ぐ意味で、変更の手順を規定するのは必須だ。
　メンテナンスで扱う変更には、大きく分けて２種類ある。細かなバグの解消と、システム機能の改良や追加だ。両方とも、別々に作業手順を規定する。
　細かなバグの解消では、やむを得ない理由がない限り、機能の変更を含まない。影響が大きなバグなら、最優先で原因を突き止めて直す。もちろん、最低限のテストを実施して、正しく動作するかを確認する。それに通ったら、運用している本番システムで入れ替える。
　機能の改変でも、問題が出ないように作業手順を規定する。この種の変更では、以下のような点を十分に考慮する。

システムの機能変更で考慮すべき点

・入れ替え回数を減らすために、できるだけまとめて変更する ・変更する価値が大きなものを、適切に評価して選ぶ ・変更でのデータの整合性を分析し、既存のデータ資産を守る

システムの入れ替えはトラブル発生の大きな原因となるので、回数を減らすことが重要だ。何度も変更するのではなく、一度にまとめて変更ことが望ましい。また、出された要望の全部を満たすのは無理なので、やる価値が本当にあるものを選ばなければならない。個々の要望ごとに必要度を設定するとともに、効果の大きさや変更作業の負荷なども明確化する。
　大きなシステム変更では、データの構造が変わることもある。変更でのデータ構造の変化を分析し、既存のデータを生かしながら整合性を確保する。貴重なデータ資産を守ることも、重要な考慮点の１つだ。

変更手順には切り替え方法まで含める

　余計な変更やトラブルを防ぐ意味から、変更での作業手順を規定したほうがよい。変更の規模が大きい場合の一般的な手順は、以下のとおりになる。

大きなシステム変更での一般的な作業手順

１、要望受付：変更の要望を受け付ける ２、要望評価：効果や負荷を考慮して実施すべき要望を決める ３、中身設計：変更の実現方法を検討して設計する ４、中身開発：設計した内容を実際に製作する ５、中身試験：開発した処理やデータをテストする ６、切替設計：システムの入れ替え方法を設計して準備する ７、切替試験：切り替え方法をテストしながら、運用担当者を教育する ８、切替実施：実際のシステムと入れ替える ９、運用観察：正常に動作するか、定められた期間で確認する

　この中で重要なのは、本番システムの切り替え方法を含める点だ。情報システムのトラブルでは、きちんとテストしないで入れ替えるといった、単純なミスが意外に多い。原因は単純でも、システムのサービスが停止したり、一部のデータを破壊するなど、大きなトラブルになってしまう。「いやぁ、単純なミスでした」では済まされないのだ。
　このようなミスを防ぐには、変更の手順を細かく規定するしかない。各作業での設計書類などを用意し、報告を義務づけて状況を把握する。切り替え方法の設計では、成功したか失敗したかの判断基準を定め、実際の切り替えたときに調べる。失敗と判断したときは、すぐに直せる場合を除いて、もとに戻したほうがよい。この種の対応方法も、切り替え手順の設計時に決めておく。
　このような各工程での確認方法は、重要度や影響度の大きなシステムでは必須である。判断基準を何項目か用意して、すべてが大丈夫なときだけ、新しいシステムを運用し始める。少し細かすぎるぐらいが、実際には丁度良い。

体質の古い組織ほど、要望の評価が不適切になりやすい

　システム変更の手順を規定したとしても、防げない問題もある。それは要望を評価する部分で、誰が評価するかで結果が違う。論理的な話が通じる人ばかりなら、適切な判断で重要な要望が選ばれる。しかし、そうでない人が多いと、政治的（＝非論理的）な判断で決まる。
　もっとも悪い状況は、体質の古い組織で起こりやすい。本当の必要性とは関係なく、発言力の大きい人の意見で採用が決まるパターンだ。そんなケースでは、変更の実現時期まで指定され、システムの細かな入れ替えを余儀なくされる。全体の効率は低下するだけでなく、トラブルも発生しやすい。旧態依然とした日本の組織、つまり論理的な説明が通じない組織では、ありがちなことだ。
　このような問題の良い解決方法は、残念ながら存在しない。組織の体質が変わるしかないからで、その種の改革は、ある意味では、情報システムの設計よりも難しい。だとしても、組織内の全員が馬鹿ではないのだから、論理的に訴え続けるしかないだろう。そのような行動が、非常にゆっくりとだが改革を後押しする。

　今後の社会では、世の中の変化がますます大きくなる。情報システムに求められる変更要望の頻度や量が増えることも、十分に予想される。その意味で、変更しやすいシステムの必要性は、時間が経過するほど高まる。遠い将来では、システムの構造を根本的に変えて、素早く変更できる仕組みが必要だろう。それが実現されるまでは、きちんとした手順で地道に変更するしかなさそうだ。

（1998年９月15日）