川村渇真の「知性の泉」

システム運用:使えるシステムに仕上げる大切な要素


運用を考慮して設計やテストを実施する

 どんなシステムでも、実際に運用しなければ価値はない。運用を軌道に乗せて初めて、システム開発が成功したと言える。
 システムをきちんと運用するためには、いろいろな面から十分に考えて、設計や準備をしなければならない。作業段階ごとに、代表的な考慮点を挙げてみよう。

システムの運用に関する考慮点
・システム設計:運用しやすく設計し、運用に必要なツールなども用意する
・システムテスト:実際の運用時と同じ形でシステム全体をテストする
・運用準備:運用に必要な記入書類や説明書を用意し、ユーザーを教育する
・運用中:トラブルの発生や対処、処理件数などの運用結果を毎日記録する

 まず、設計の段階では、運用する際に必要な機能を組み込む。続くテストの段階では、実際の運用に近い形でシステムをテストする。一般に運用テストと呼び、テスト工程の最終段階で実施する。システムの機能が正常に動くかどうかだけでなく、ユーザーから見た使い勝手も調べる。あまりにも使いにくい場合は、システムの変更が求められる。
 運用する前には、記録する書類、バックアップ媒体、操作方法の説明書などを用意しなければならない。それを用いてユーザーを教育する。実際には、ユーザーの中から誰かを選び、テスト前に教育して、運用テストを実施する。その段階で発見された問題点を、システムや使用説明書などに反映し、改善にできるだけ役立てる。最初に教えられたユーザーは、別なユーザーに教育することになる。
 システムの運用に関わる人は、2種類に分けれらる。マシンやシステムの起動や終了を担当するシステム管理者と、実際の業務でシステムを使用するエンドユーザーだ。小さな組織では、エンドユーザーがシステム管理者の仕事も受け持つ。大きな組織では明確に分かれていることが多いが、部門内で作った小さなシステムだと、エンドユーザーがシステム管理者を兼ねる。
 担当が分かれているか兼務かにより、運用方法は大きく変わる。しかし、どちらであっても、運用ルールをきちんと決めて、間違いなく作業できるようにする。また、設計の段階では、運用面での使いやすさを向上させるように、いろいろと工夫しながら機能を仕上げる。運用に関しては、設計から運用体制作りまでの全体の整合性を考慮して、総合的に検討することが求められる。

運用を考慮してシステムを設計する

 きちんと運用するためには、システム設計での考慮が非常に大切だ。システム全体を運用しやすく設計しないと、最終的に使えないシステムが出来上がる。そこまでには達しなくても、運用を考慮しない設計だと、最終段階での手直しが多く発生する。運用開始が遅れるばかりか、システムの信頼性も低下し、悲惨な状態へと近づく。そうならないように、運用まで考えてシステムを設計すべきである。
 では、どんな点を考慮すべきだろうか。これは範囲が広いため意外に難しい。コンピュータ側に絞って代表的な項目を挙げると、次のようになる。

システム設計での運用に関する考慮点(コンピュータ側)
・操作方法の提示:目的から操作方法を調べられるように
・メッセージ:現象の重要度を利用者に知らせる
       重要な場合は、対処者の連絡先などを知らせる
・誤操作の防止:誤った操作ができないか、それに気付くように
        一連の作業などを、迷わずに操作できるように
・誤入力の防止:間違ったデータが入力されないように
・処理の確認:一定の単位ごとに処理が正常かを確認できるように
       重要なデータなどを後で調べられるように
       システムが正常に起動したことを知らせる
・問題点の調査:処理が正常でないとき、問題点や原因を調べられるように
・状況の把握:業務上の全体状況を把握できるように
       システム管理上でシステム状況を把握できるように
・管理情報の記録:処理件数などの運用管理に必要な情報を自動的に記録する
・例外処理への対処:予想外の例外処理に対し、できるだけ対処できるように
・データの保護:データのバックアップや復旧を簡単にできるように
        もし最悪の状態になっても、データなどを失わないように
・安全性の確保:データや機能ごとに、許された人以外の使用を禁止する

 これらの考慮点は、システム管理者向けとエンドユーザー向けの2種類があり、両方に関係する項目も含まれる。設計する場合は、どちらが使用するのか考え、メッセージの出し方などを分かりやすく工夫する。
 重要な機能ほど、誤操作などの影響を考慮し、十分な対策を組み込む。たとえば、1日に1回しか処理しない機能なら、2度目だと実行前に何度かの警告を発し、簡単には実行できないようにする。もし実行した場合でも、前の状態のデータを別に保存しておくとか、最悪のケースで元に戻せるような対処も組み込んでおく。
 システム管理者やエンドユーザーの負荷を減らすためには、管理上のデータを自動的に記録することが大切だ。エラーや警告の場合でも、メッセージを出すとともに、その内容をどこかへ記録する。個々のシステムごとに作成するのは無駄なので、共通のシステムとして用意したほうがよい。
 いろいろな状況を考慮すると、数多くの対処が必要となる。しかし、開発に割ける工数、人材、資金は限られているので、重要なものだけに絞るしかない。最初は考えられる項目をすべて挙げ、その全項目に対して、機能の重要度と開発の負荷を求める。その結果を見て、システムに組み込むかどうかを判断するのが現実的だ。適切なものを選べるかは、システム設計者の能力の1つである。できるだけ多くの項目を実現するには、新しくプログラムを作成するのではなく、既存のツールを最大限に活用したい。

人間側の作業手順やルールも設計する

 以上は、コンピュータ側の考慮点だが、人間が関わる部分のシステム設計も忘れてはならない。正常時やトラブル対処での作業手順やルールはもちろん、管理用の記入用紙、決定の権限を持つ人など、どれも運用しやすいように設計する。当然、人間側とコンピュータ側の整合性が取れていて、全体として最適化されていなければならない。
 設計が終わると制作段階に入るが、ソフトウェアだけでなく、人間側の部品も作成する。書類関係では、毎日記入する管理用の記録用紙、データの登録用紙、トラブル報告用紙などだ。加えて、一連の作業全体を管理するための用紙なども用意する。これらも、システム管理者向けとエンドユーザー向けを分けて作成する。
 作業手順を説明した紙のマニュアル類も必要となる。この種の書類は、詳しく書くと非常に大変なので、どこまで説明すべきかを十分に検討する。できるだけ減らす方向で考えたほうがよい。ユーザーが他のシステムを使っていれば、細かな説明は不要である。さらに、入力データのチェック内容などは、オンラインヘルプとして提供し、紙のマニュアルでは触れない。これを基本としてマニュアルを作成し、基礎的な知識に関しては知っている人が教える方針で進めたい。ユーザー部門に知っている人がいれば、この方針で何とかなる。
 現実的に重要なのは、システムで表示する画面の設計だ。入力レイアウトなら、チェック内容が簡単に表示できると、ユーザーが困ることは少ない。できるだけマニュアルを必要としない形で、画面や機能を設計する。
 以上の考え方が適さない部分もある。バックアップやリカバリーなど、重要な作業の手順書だ。この種のマニュアルは、できる限り丁寧に説明したほうがよい。手順を細かく示すだけでなく、正常に終了したかの判断方法、ダメだったときの対処方法など、幅広い視点で記述する。業務システムが違っても共通する部分が多いので、システムごとに個別に作るものの、書き方や内容は標準化しておく。
 コンピュータ側と人間側の道具が揃ったら、運用テストで実際に試す。通常の操作をきちんと調べるのはもちろんだが、リカバリーのように、普段はできない処理を重点的に試す。機能が正しく動くかに加え、マニュアルが正確に書かれているかどうかも確認する。登録用紙などは比較的簡単に修正できるので、この段階で可能な限り良くしたほうがよい。

運用時には処理状況や問題点を記録する

 実際に運用し始めると、いろいろなトラブルが発生する。原因は、機器の故障、ソフトウェアのバグ、設定ミス、操作ミス、人間の勘違いなど様々だ。トラブルはどんなに小さくても記録すべきである。大きなトラブルの発生を防ぐだけでなく、使いにくい点を発見する資料にもなる。小さなトラブルが何度も発生する機能は、使いやすくない可能性が高いからだ。
 トラブルかどうか判断するためには、正常に作業できたかを確認できなければならない。システム設計での考慮点に含まれているように、どの機能でも正しく処理できたか確認する機能を用意する。たとえば、500件のデータを入力したら、本当に500件が登録できたかどうか、一定の周期(半日とか1日ごと)で確かめる。登録用紙の枚数と登録件数を比較し、同じであれば正常に終了したと判断する。正常に終了したとしても、件数などを用紙に毎日書き、確認したことを記録として残す。
 登録件数以外でも、業務上で重要と思える値はできるだけ表示して、ユーザーが確かめる機会を提供する。加えて、処理の開始や終了でメッセージを出し、正常に開始したとか終了したことを知らせる。要所要所で確認できると、ユーザーが安心して作業を進められる。これは非常に重要なことだ。また、トラブルを早目に発見する手助けにもなる。
 ただし、確認のための作業はできるだけ簡単にしたい。毎日の登録件数の記録などは自動的に保存し、ユーザーがいつでも見れるようにする。ただし、これらの機能を1つのシステムに組み込まなくても構わない。件数などの情報をパソコン側に送るとか、確認用の共通システムを用意するなどの方法で、開発の負荷を減らすように努力する。
 自動記録の機能は、システム管理者向けにも用意する。システムを起動したり終了した時刻、サービスが開始可能になった時刻を自動的に記録できれば、記録する必要はない。トラブルでシステムが停止すれば、再起動などの時刻が残り、後から調べるのにも役立つ。
 長く使うシステムでは、ユーザーが使いにくいと感じたり、直してほしいと思う部分を出してもらう。専用の記入用紙を用意し、書いて提出してもらう。全部の要望を満たすのは無理だが、システムの改善にとって貴重な情報になる。
 運用の途中で、システムやツールの設定を気軽に変更する人もいる。しかし、きちんとテストせずに変更すると、トラブルを発生させやすく、システムの停止につながる。この種の初歩的なミスは、絶対にやってはならない。

 システム運用で大切なのは、人間側の作業も含めてきちんとルール化し、個々の作業の結果を確認できるような仕組みを提供することだ。また、重要な情報は記録を残し、問題点などを発見しやすくする。運用に関して幅広く考慮することは、システム開発での重要な点の1つである。

(1998年7月31日)


下の飾り