IT道場その７ ～ログの調査～

ITでエラーを調査する際に欠かせないのがログの調査です。

すなわち、いつ誰がどういう処理を行って、その結果どういうことが起こったか、の記録です。

そして、当然ですが、ログには「いつ」「誰が」「どういう処理（通常はプログラムのIDやタイプインの記録）」「どういう結果（正常終了の場合でも入力・出力件数、エラーの場合はエラーコードと詳細メッセージ）」が記録されている必要があります。

また、ログはすぐに調査できるものでなくてはなりません。

また、ログに関連したものとして、処理の中間結果を記録するワークファイルを用意すると、途中の経過がわかりやすくなります。

エラーに関してはエラーのワークファイルを専用に用意してもよいでしょう。

エラーの原因の大半は、ボタンの押し間違いとタイプインの間違いです。

そういう意味では、タイプインの記録と入力件数・出力件数の記録は非常に有用で、それを見ただけでエラーが特定できる場合がほとんどです。

たとえば、データがあることを想定した集計プログラムで、抽出結果が0件だったために（集計項目や数字が編集されずに）異常終了する、という現象はよく発生します。

長い処理を行う際は、途中経過が見えた方が精神衛生上よいでしょう。ボタンを押して数十分反応がなかったら不安になるものです。

また、自動更新処理を行う場合は、ログとは別に「更新結果リスト」を出力するようにしたほうがよいでしょう。


また、ログは分量にもよりますが、１日単位でバックアップをとり、最大１～２ヶ月分程度保管すれば実用上は困らないでしょう。

それ以上の分は定期的に外部媒体にでも保管すればよいと思います。

なお、ログを利用した解析として、開発環境で１レコードの１ステップレベルでログを出力するようにすることでエラー箇所を特定する、という事もよく行います。

ログの情報が少なければ、プログラムを端から端まで読まなければならず、原因の特定に時間がかかります。

IT道場その６ ～確認メッセージ～

素人とプロで大きく異なる箇所の１つが「確認メッセージ」です。

ボタンを押したらプログラムが走る、というのは当たり前の事ですが、開発者が見落としがちな視点として、「想定外のボタンを押してしまった」（しかも、得てして当事者はその自覚がない）というのがあります。

発生するエラーの小さくない一定割合は、この種の単純な運用ミスです。

ボタンを押したら、まずユーザーがどのボタンを押したのかを認識しなければいけません。

従って、「〇〇の処理をします。よろしいですか？」のメッセージはボタンを押した際に必須となります。（少なくとも大量印刷、および更新処理時は必須）

更に、人間心理として「何も考えずに続行ボタンを押す」（ひどい場合はマニュアルに「続行」ボタンを押す、としか書かれていない）というものがあるので、特に重要な更新時は「２回再確認のメッセージを出す」ことや、「入力値を表示した上で確認メッセージを出す」ことが、ボタン運用ミスを防ぐ上で大切なこととなります。

注意点として、コピー＆ペーストで作成すると、確認メッセージがタイトルと合っていない、あるいは複数のプログラムで同じ確認メッセージが出力される（単に「続行しますか？」や「在庫報告　印刷？」など）例がよく発生し、運用エラーを誘発したりエラー特定に手間取ったりします。

また、「印刷」か「更新」か、ははっきりと示した方がよいでしょう。

私が作った更新プログラムの例では、
「ボタンを押した直後に業務名の確認メッセージ」⇒「前提条件のチェック」⇒「更新前データチェック」⇒｛「エラーがあればエラーリスト出力とエラーメッセージ」/「警告があればリストと警告メッセージ」⇒「それでも続行する場合は再確認メッセージ」/「エラーがなければそのまま」}　⇒　「更新処理」　⇒「更新結果リストの出力」　⇒　「更新結果メッセージ」
の流れとなっています。

また、テストプログラムやメンテナンスプログラムの場合、使用者が自分自身のため、「エラーは発生しない」前提で設計しがちですが、「似たような名前のプログラムやボタンが並ぶ」ため、想定外のプログラムを実行してしまうリスクは決して低くありません。

私自身の例で言えば、重要なデータメンテナンスを行う場合は、使うのが自分だけであっても、必ず確認メッセージを出力し、また、特定の日付・時刻以外ではエラーとなるように制御を入れるようにしています。

この一手間をどれだけしっかりできるか、によってエラーの発生率が大きく変わってくるのです。

IT道場その５補足 ～エラーチェック実例～

前回の記事で紹介したエラーチェックについての実例を紹介します。

請求入力画面　＝＞　請求データ　＝＞　支店締め処理　＝＞　実績データ　＝＞　全支店更新処理　＝＞　会計仕訳データ　

という流れにおいて、
会計仕訳データに不正なデータを入れないために、必須チェックを全支店更新処理にて行っていましたが、
・この段階は最終段階であり、締切日当日の夜の処理となる
・エラーに引っかかってから原因を特定した頃には支店担当者は既に帰宅している
・従って、修正が翌日となり、データ連携が遅れる

という問題がありました。

必須チェックは、請求入力画面では行っていましたが、
請求入力画面にも、
　他システム１　＝＞　請求データ
　他システム２　＝＞　請求データ
　請求データ　＝＞　自動作成の請求データ
の流れがあり、入力画面で制御を行っていても他のシステムから入ってくるデータに同様の制御がされている保証はありませんでした。

そこで、その中間であり、その後の工程が一本である「支店締め処理」の段階で必須チェックを追加しました。

これを行うことで、仮にエラーとなっても、その場でわかるため、担当者が既に帰ってしまっていた、という問題を防ぐことができます。

さて、この実例を通じて得られる鉄則を列挙します。

①　エラーチェックは工程の前段階に置く。ただし、工程の分岐・合流を考えて、たとえ冗長となっても必須のロジックは主要なポイントすべてに配置する。（多重チェック）

②　エラーチェックの目的は「早期発見」である。一般にエラー対応は時間がかかるため、締切までの時間は長ければ長いほどよい。
　　特に、締切が業務時間外となる場合は、エラー対応が業務時間内か時間外かで、効率・効果が大幅に異なる。
　　最低でも昼間、できれば締切の１日以上前に特定、解決することを目指すべき。

③　当然であるが、エラーチェックを行うためには、プログラム・システム的な視点はもとより、業務の流れについての一定以上の知識・理解が必要である。

IT道場その５ ～エラーチェックの仕組み～

素人とプロとの違いで最も大きいものの１つがエラーチェックの仕組みです。

何も考えないで作成すると、想定通りの正しいデータが流れる前提で動くノーエラーチェックのプログラムをつくりますが、プロはデータを扱うあらゆる箇所にエラー判定を設けます。

よく使う箇所は、
・文字の桁数
・入力された文字が数字が否か
・ファイルを読む場合、そこにファイルが存在するか
・データを更新する際は、必須項目が入っているか、キーが重複していないか
・データがゼロ件か否か

また、
・そもそもデータにアクセスする権限があるか
・ビジネスロジック上禁止されていないか（例えば、締切処理後に入力することを禁止する、他DBに更新後の数字の変更を禁止する、など）
・二重処理のチェック
・処理漏れをチェックする
・データの整合性（合計値など）が取れているか

なども使います。

上級者になると、
・データのフラグを更新直前に判定し、二重処理のトランザクションエラーを見抜く（通常は、レコードをはじめに１度だけ読み込み、手動または自動で項目を編集してから最後に更新する）

などの技も使います。

「エラーチェックは流れの中で１度だけ行う」のではなく、「可能性のある箇所は２度手間になってでも行う」（たとえば、入力時のチェックの他、更新前にも同じチェックをする、など）ことも重要です。

また、エラーにしても、
・強制停止する
・メッセージを出力して止める
・警告を発する

の種類があり、場合によってうまく使い分けないといけません。

プロはこの３つをうまく使い分け、かつ、エラーメッセージもどこでどういうエラーがあったのかがユーザーレベルでわかるようなメッセージ文面を考えます。
特に、合計値をチェックする、キー違反をチェックする、ファイルパスをチェックする、
などは、エラーになった値も一緒に表示する必要があります。

エラーを判定するのは、判定しないプログラムに比べて面倒ですが、ここに手をかけることで、後工程が楽になり、信頼性が違ってくるのです。

IT道場その４ ～データの確保とバックアップ～

IT業務を行うのにあたって欠かせない技術がデータの確保です。

慣れていない人は、すべて自分のパソコンのデスクトップまたはマイドキュメントにすべての書類をおいてそこで作業をします。

しかし、パソコンは数年のスパンで考えれば、一定の割合でどこかしらのパソコンが壊れるものです。

また、「間違って削除した」「間違って上書きしてしまった」などのヒューマンエラーはパソコンが壊れるよりも多くの頻度で発生します。

このような時に、「データがすべて失われてしまった」というのは、20年前ならともかく、今日のビジネスでは許されません。

更に、情報システムで使用しているデータについては、「過去の特定の状態を再現する」「システムのテストに使う」などの用途でデータを確保する必要があります。

これらは、特に意識して行動しないと、データを確保しないまま動いてしまいます。

従って、普段から意識して行う必要があります。

①パソコンのクラッシュ対策

　可能な限り、ローカル（自分のパソコン）に書類をおくのではなく、共有サーバーにおいて作業するべきでしょう。

　個人のパソコンと比較して壊れる可能性が圧倒的に低い上に、万が一壊れてもデータの確保は保証されます（通常システム管理者が別の媒体にバックアップをとっています）。

　また、共有サーバーが使えない環境では、外部媒体に定期的にバックアップをとる必要があります。

　これも、自分でやると結構大変なので、オートバックアップが可能であれば、オートバックアップの設定が望ましいです。

　手動でバックアップする場合、タイミングは、「書類作成時」「最終（大幅な）更新時」がよいでしょう。

　頻繁に更新するような書類やデータ系の書類はそもそもローカルには置かないようにしましょう。

②削除・上書き対策

　ファイルを手動でコピーしてバージョン管理をするのがよいでしょう。

　たとえば「〇〇報告」というタイトルの書類であれば、「〇〇報告_20170209」という名前で保存し、「〇〇報告」の書類を編集し、「〇〇報告_20170209」の書類は以後編集しないようにします。

　何らかの理由で以前のバージョンを見たい場合などに役に立ちます。

　EXCELのマクロやACCESSを管理する際に、よく利用しています。

　さらに、「OLD」というフォルダを作成して、以前のバージョンをすべてそこに移動すれば、見た目がすっきりする上にバージョン管理も可能となります。

③システムデータの確保

　システムデータの確保は、システムによって様々な手法があります。

　ただし、共通して言えるのは、「バックアップしたデータは復元できなくては意味がない」ということです。

　よくあるのが、「環境を丸々１つのファイルにバックアップする」という手法ですが、「復元するのに数時間かかる」「そもそも復元することを想定していないため、手順書を確認するところからはじめなければならない」という欠点があります。
　
　復元は１０分以内、できれば５分以内で、ファイル・プログラム単位で行えるべきです。

　また、これも重要なことですが、「復元できる環境」を用意することが必要です。

　「復元する事は可能であるが、本番環境で復元することしかできない」というのでは意味がありません。

　本番環境とは別に復元環境を用意する事はコストがかかりますが、その効果を考えれば十分な投資といえるでしょう。

　なお、復元環境を複数用意できると使い勝手が向上します。