システム障害の予防策などを作っていると、ついつい「チェックリスト」というものに頼りたくなる。要するに見落としがあって障害が起こった場合、二度と見落としがないように、見落とした項目のリストを作って、その後のシステム開発の際そのリストに挙げられた項目とチェックするわけだ。しかしどうしてもこの方法に違和感を感じてしまう。 まずはこの制度、いつか必ず破綻する。なにか問題が発見されるたびにチェックリストの項目が増える一方ということは、永遠に続けることが物理的に不可能であるからだ。それに、チェックリストという形式自体妙だ。チェックリストというもの、通常は別の使われ方をする。コンピュータネタ、目次へ
典型的には「持ち物チェクリスト」である。例えば朝出かけるとき、定期券と財布とハンカチを持っているかを確認するのに使う。要するに備忘録である、ここで重要なのはチェックリストの項目が満たされているかは客観的に判断でき、項目自身も事前に用意できることである。
ところがシステム開発に使われるチェックリストはそうではない。客観的に判断できるかは極めて怪しいし、項目が事前に用意できるかも疑わしい。だいたい事前に用意できないからシステム障害が起こるのだ。
まあプログラマーが、文末のセミコロンを忘れたりしないためのチェックリストくらいは使えるかもしれないがな。せいぜいそんなもんだ。ではチェックしなくてよいかというと、そうでもない。しかしチェックリストは使いたくない、どうすればよいか、何かないかな、と考えていたところとあるフレーズに行き当たった「ルールセット」である。
「インスペクション」という本で出てくる概念らしい。ただしこの本はどうも組込用システムを対象にしているらしく、例として出されているルールセットはまるで納得できるものではない（私はアプリケーション専門）。しかし設計が「ルール」に基づいているかどうかは確認する必要があるという気はしてきた。ではチェックリストとルールセットはどうちがうか。解釈学的円環にあえてはまりこんでみる。多分バッチプログラムの設計チェックリストには必ずと言っていいくらいあるであろう項目を取り上げる。「データが０件の時の対応を行ったか」というやつである。プログラムの処理は入力データを加工して出力データを作るという単純なものとする。
これをルールとして書き直すことを試みた。データが０件のときの対応がなされているかどうかは比較的簡単に判断できる。しかも客観的に。チェックリストとしてこれくらい適切な項目はないくらいだが、どのように対応するべきかは使われている部分で著しく異なる。
まずはデータレコード０件の場合がどの程度発生するかでやり方が変わってくる。普通はあり得ない事象である場合、メッセージを出してプログラムを止めてしまうのが適当だろう。データが０件ということは上流での処理がおかしいと判断できるからだ。従ってルールはこのようになる「データ０件という事象が、データ作成元の異常を示す場合はプログラムを停止させる」。
しかし、１年に１回くらいはあるかもしれないような場合、これは複雑である。無いとは言い切れないということで通常は処理を完了させる。出力ファイルも０件になるかもしれないがこれはこれでいい。ただし注意を促す意味で「入力ファイルにレコードがありません」というメッセージは出力させ、運用マニュアルに出力メッセージをチェックするように、という但し書きを付ける。
しかし、データ０件となるのがありはするが非常に希な場合、そしてそこで加工したデータを後続処理に投げた場合で、あとでデータ作成元がおかしいのだと分かった場合、リカバリーが極めて大変だとしたならば、ちょっとやり方が変わってくる。メッセージを出して処理を中断させてもいいかもしれない。特に日中に走るバッチだった場合。つまり次のような運用が可能だった場合だ。
データが０件でプログラムが止まる→連絡が来る→データの作成元に問い合わせる→問題無い旨の回答を受ける→プログラムを次のステップから実行する。
変則運用ではあるが必ずしも禁止技というわけでもない。場合によっては有効かもしれない。（多分工数も減る。）
ただしこの技を使うと、あとで高くつくことがある。当初は日中のバッチであったが、いつの間にか夜間バッチになっていたときだ。夜中に自宅に連絡が来る。まあ仕方がない。ところが問い合わせようにもデータの作成元が捕まらない。どうしようもないまま時間だけが過ぎる。
あるいはセキュリティの向上策として、開発と運用が完全分離になり「プログラムを次のステップから実行する」ことが即座に出来なくなったりすると悲劇である。
またこんな事も考えられる、当初はデータ０件はありえないからということであったはずが、業務の内容が変わってある日突然０件に。あるいはシステムが変更になる移行期間だけ０件に。（まあ移行期間中と割り切れば、出力結果に影響のないダミーデータを食わせるという手法もあるが。）要するにデータ０件というシンプルな事象であっても、対応は条件によって異なるということだ。つまり汎用的なルールは作れなかった。ましてやYes/Noで割り切れるチェックリストなど作れるわけがない。「対応をしたか」はチェックできても、その対応が正しいかはチェックできない。従ってたいした意味がない。
強いてルールを作るなら「データ０件時の処理内容を判断理由とともに記載すること」くらいであろう。このルールには上で書いたような典型的判断例をガイドとしてくっつけておく。
ルールとしては弱々しいがこれがあるとめちゃくちゃ便利だぞ。バッチの時間を日中から夜間に変えたときの影響調査の心強い味方だ。それに次のようなルールが昔からあって、それが守られていたと考えてみてくれ「日付関数が返す年号が西暦下２桁であった場合の処理内容を判断理由とともに記載すること」。まあ考えを変えればデータが０件であった場合の対処ルールの作り方があるかもしれない。「入力データは全て正しいとして処理を続行する」である。バートランド＝メイヤー（理想的なオブジェクト指向言語といわれるEffelの設計者）なんかは、正しいデータを渡すことはモジュール同士の契約だ、としてこのような設計を推奨している。
シンプルだし工数も減るし悪くないかなと思う。特にメイヤーの場合はEffelに閉じた世界でのことを言っているわけだからそれでいいんだと思う。しかしこれをシステム設計一般に適用するととんでもないことになる。入力データの日付項目に対してさきほどのルール「入力は正しいとして処理を続行」を適用してみよう。データの出力は汎用機が行う。レコードの日付は2038年1月18日のもの。受けたのはUNIXサーバー。処理は指定日の月末営業日を求める。やったことはないが多分異常終了するか、暴走する。ようするに汎用機には存在しないがUNIXに存在する2038年問題に引っかかったのだ。
それはプラットフォームが違うから・・・と思うかもしれない。でも似たような問題はUNIX同士でもありうるぞ。ファイルを送る／受ける。受けた方の処理が停止。あれ、同じOSなんだけどなあ。理由は細かいバージョンの違いで送り手は4GBまでのファイルを扱えるが受け手は2GBの制限があったこと。理論的にはあり得る。まーこれは送り手の方で制御しなければなりませんが。
なお、こんな事象があったとして報告をうけた人の反応、だいたい想像できる。「えー、ファイルサイズが２ＧＢ超えるなんてありえな〜い」。
こういう障害の予防策としてならチェックリストが有効かもしれないな。