IT道場その８ ～プログラムのコメント～

おそらく、コメントの部分が最も人による差が大きい部分だと思います。

どこにどれだけのコメントを入れるかはある意味感性となりますが、あえてリストアップすると、

①　そのプログラムがどのようなプログラムであるかの概略説明
　　特徴的な処理があれば、その概要
　　大きい変更点があれば、その概要
　　用途が限られているなら明記する
　　親プログラム、前段・後続プログラムが決まっているなら明記する
　　※上記内容はプログラム名の直前直後に記載するのがわかりやすい
②　作成者、初回作成日時、最終作成日時、バージョン等
③　特筆すべき変数があれば、その説明
　　似たような名前の変数があれば、その使い分けの説明（IX,IX2,IXWなど）
　　なお、変数の命名と使い方はある程度統一したほうが後の混乱を避けるためにもよいでしょう。
　　逆に、説明しなくてもわかる変数は説明を省略した方がすっきりします。(ReadCount, ExecuteTimeなど）
④　ステップで管理しているなら各ステップの説明
⑤　特殊処理、場合わけ
⑥　受け渡し変数の説明と条件
⑦　インプットとアウトプット（データベース、レポート名）
⑧　追加した処理は追加日と概要を処理の手前に記述
⑨　コメントアウトする場合は、コメントアウトされたことが一見でわかるような内容
　　たとえば、/. ~ ./ ではじまるコメントで複数行をまたぐ場合、
　　/. syori-1
syori-2
if a = 1 then syori-3
./
　　などと記述すると、syori-1はコメントアウトされていることが明白ですが、その下の２行はコメントアウトされていることがわかりづらくなります。
　　この場合、
　　/.##syori-1
####syori-2
####if a = 1 then syori-3
./
　　とすると、全体がコメントアウトされていることが明白となります。さらに、/.(2017.04. ○○によりコメントアウト) ./などと書くとわかりやすいでしょう。

また、コメントの様式も統一すると（たとえば作成者は「#作成者：」の形式で左から２文字目から記述する、など）、自動テキスト解析などで分析しやすくなります（ログについても同様）。

最後に、注意点として、プログラムはよくコピー＆ペーストで新しいプログラムとなります。その際、旧プログラムのコメントも引き継ぐため、実際の内容とコメントの内容が合わない場合があります。
（たとえば、作成日が2017/04なのにコメントの日付が2016/12など）
この場合は、たとえば、 #(Program-Bより複写)などのコメントを入れ、旧プログラムのコメントは一新することを忘れずに行ったほうがよいでしょう。


　

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なども使います。

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

などの技も使います。

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

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

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

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

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