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に更新後の数字の変更を禁止する、など）
・二重処理のチェック
・処理漏れをチェックする
・データの整合性（合計値など）が取れているか

なども使います。

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

などの技も使います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

②削除・上書き対策

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

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

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

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

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

③システムデータの確保

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

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

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

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

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

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

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

IT道場その３ ～素人とプロの違い～

前回と話は変わって、今回は「ITの素人とプロの一番の違い」について話します。

ITに限った事ではありませんが、表面だけを見ていれば、素人とプロには大きな違いはありません。

動くプログラムをつくるだけであれば、素人もプロも同じようなものを作ることができると思います。

では、何が一番違うのか？

プログラムを作成する時間でしょうか？

確かに、慣れてくればプログラムは速くつくることができるようになります。

ただし、それでも与えられた条件で１つのプログラムをつくる場合、素人とプロで時間に大きな差はありません。

一番違うのは、「可用性」です。

具体的には、「データのバックアップ・確保」「エラーチェックの仕組み」「確認メッセージ」「不具合があったときのログ調査」「プログラムのコメント」などです。

ここが大きく異なるところです。

素人に一番多いのが、「ボタンを押したらなんのメッセージもなくプログラムが開始し、何のメッセージもなく終了する」「ミスをしてデータを消した、あるいはインストールされたパソコンが壊れたらデータを復旧できない」「正常な入力しか想定していない（そのため頻繁にエラーで落ちる）」「プログラム文の羅列となっておりコメントがないため、何をしているかがわからない」「ログをとっていないため、エラーの再現ができない」といったものです。

「帳票にIDと時間を印字する」ことや「データベースに入力・更新日時を持たせる」などの工夫は、よほど経験がないと省略してしまいがちですが、その違いが調査やメンテナンスに大きく影響します。

プロは動くプログラムをつくるのに時間をかけず、可用性の確保に時間をかけます。
そして、不十分だと感じたら改善するのを躊躇なく行います。

素人は、エラーが発生すると、ユーザーが入力が悪いせいだとします。

そして、その違いが大きな効率の差となっているのです。

これは大事な事であり、私自身が一番工夫をこらした事でもあるので、次回以降１つずつ説明します。

IT道場その２～８年間の時代の変化～

私が情報システム部に来た８年前は、一言でいえば「紙からデータへの転換期」でした。

当時は、パソコンが一人一台ではなく、部署で共有して使うのが普通でした。

そのため、仕事は紙ベースで行い、EXCELは表計算というよりは印刷物として使われていました。

「CSV」という言葉はIT関係者以外では聞いたことのある人間を探す方が大変で、「PDF」は今でこそMicrosoft Officeで標準機能として出力機能がついていますが、当時は「Adobe Acrobat」を購入する以外に作成する方法はありませんでした。

フラッシュメモリは128MBが最大容量で、それでも持っている人が少なく、ポータブルメディアの主役は3.5インチフロッピーディスクでした(容量は1.44MB)。

ホームページに動画を載せるなどもってのほかで、画像ファイルをいかに小さくするかを工夫していました。

メールも500MBを超える添付ファイルは送れなかったと記憶しています。

ファイルサーバーは存在こそしていたものの、限られた人が限られた業務で利用する程度でした。

会社で使っているホストコンピュータもパソコンとの連携は重視されず、完全に別物として動いていました。

データのバックアップには数十分～数時間かかり、それを復元するのにもやはり数十分かかっていました。

全体がそのような時代だったため、データに対する需要もそれほど大きくなく、「目の前の業務をこなす」ことが最大の関心でした。

今では、CSVでデータを出力してフィルタを使って抽出・集計して、必要であればピボットテーブルを使って数字をまとめる、という事は個人レベルで行われるようになっています。

また、「過去3年分のデータをCSVで欲しい」という要望も、当時は考えられなかったくらいですが、今では日常茶飯事です。

逆にいえば、その程度の期間のデータ提供を個人レベルでできるようにしなければ話にならない、という段階になっています。

この時代の変化にいかに対応するか、が暗に求められる課題となっていました。

IT道場その１～Information Technology～

物流の世界に身を置いて11年を超えました。そのうち8年を情報システムの部署で過ごしたことになり、年数だけでみればもうベテランの域に入ってきました。

そこで、私の過ごした８年間を振り返り、ITの役割や必要とされるノウハウについて語りたいと思います。

まず、ITとは「Information Technology」であり、「情報を扱う技術」ということです。

情報システム部は、コンピュータを扱う部署で、それ専用の技術を持った人間が集まる、普通の会社員とはかけ離れた特殊な部署だ、というイメージを持たれがちです。
それゆえ、コンピュータの取り扱いのような間接業務に専門の人間を時間をかけて育てることを躊躇する風潮も強まっています。

勿論、コンピュータや通信の仕組みやプログラム技術は必須のものですし、知識があればあるほど効率もあがります。

しかし、情報システムの本質はそこではありません。

情報システムが扱うのは、入力されたデータや入力する画面ではなく、情報を効率的に回す仕組みです。

データや入力画面は、情報の一形式にすぎず、それが全体というわけではありません。

昔はよく、一つのプログラム言語については詳しいが他の言語は知らない、という事がまかりとおっていました。

「COBOLはわかるけどEXCELのマクロはわからない。ましてはWORDの段組や文字修飾などは門外漢」という人が多かったように思えます。

しかし、情報システムの本質が「情報を扱う事」であり、「そのための仕組みをつくる事」という事がわかっていれば、プログラム言語は二の次だ、ということがわかると思います。

実際、ビジネスで使うレベルの情報処理であれば、どの言語を使っていてもやっている事にそう大きな違いはありません。
「プログラムの構文がわからない」というレベルで苦悩するのは半年から長くても２～３年までです。

それ以降は、プログラムの構文よりは、それが表しているビジネスの背景であり、業務知識や人間工学、リスクマネジメントなどの理解の方が重要になってきます。

大型書店戸田オープン

先日7月29日に地元である埼玉県のJR埼京線戸田駅前に明文堂書店がオープンしました。
戸田にあるとは思えない規模で、ワンフロアといえども、空間、品揃えの規模とも、東京の一流書店並みです。
書店で感動したことはそれほどありませんが、この書店は「感動」の一言でした。
英語に関して言えば、棚の１列が丸々英語であり、英検は１級の、しかもほぼすべての出版社の参考書が揃っており、TOEFL、IELTS、国連英検も私が見たことあるものはすべて揃っていました。
勿論、通関士の参考書も揃っています。
さらに、棚と棚の間の通路が広く、圧迫感のない状態で本を選べるのがよいです。
また、TSUTAYAとタリーズコーヒーも隣接しており、買った本をカフェで読めるという理想的な環境です。（調べてみたら、その組み合わせでプロデュースをする会社のようです）

「その街が栄るかどうかは本屋があるかどうかを見ればわかる」と、（池上彰さんだと思いますが）言われています。
お近くに来られた際は、是非お立ち寄りください。