難しいときほど用意周到になろう
「たやすい仕事は思慮深く、難しい仕事はたやすいつもりで臨め」
バルタザール・グラシアン 前掲・原則第6条コラム参照
しばらく前の事になりますが、損害保険会社で発生したシステムトラブルの原因を分析したことがあります。結果は、プログラムを数十本以上開発するような、中規模、大規模なシステム開発においては、要件定義からシステム設計に起因するものが75％を占めました。これに対しプログラム数本、臨時作業によるデータの修正、移行実施といった小規模なシステム開発については、63％がシステム完成時の本番移行（主にプログラムの本番ライブラリー反映やファイルの定義等）、各種登録に係る作業等のミスが原因でした。
明らかに、大きなシステム開発では、上流工程に起因するトラブル発生が多く、小規模な開発では下流作業での手作業上のヒューマンエラーが多いということがわかります。
大規模開発では、一般的にリスクが大きいと認識されていて、テストもしっかりと行われますし、管理体制もしっかりしたものが作られ、チェックも確実に行われるのが普通です。結果、発生するトラブルの原因は主に要件に係る決め事、設計といったものに絞られるのでしょう。一方、小規模な開発の場合は、要件は、明確で具体的である場合が多く、定義ミスや、伝言ゲーム的了解違いがおこりにくいといえます。代わりに、発生するのは仕事を甘く見た結果のヒューマンエラーということになるようです。
ところで、システムトラブルの大きさや、業務への影響度は、原因となったシステムの大きさや、開発の難易度とは無関係です。ほんの些細なミスが、大きな事故を生みます。これもしばらく前のことでしたが、中央線の工事で作業員が配線作業を間違っただけで、終日中央線を大混乱させることになった事故と似ています（2003年9月28日）。小さな開発といっても馬鹿に出来ないわけです。
「いつもと同じだから…」「先月と同じものを流すだけだったので…」「量が少ないから…」「急いでいたので…」「簡単な作業でしたから…」「聞きませんでした」「テストしませんでした」「チェックしませんでした…」
トラブル発生後に聞く理由です。理由にならないですよね。
人は難しいものを相手にする時は、頭を使います。用意周到にもなります。しかし、手の内にあると認識していることについては、流し作業になりがちで頭を使って用意周到とはなりにくいのです。しかし、結果は無残です。
頭を使わない時こそ、
JCL（Job Control Language）修正のみでも、修正規模が小規模でも、テスト、レビューを必ず実施する。
を原則にしなければいけませんね。
交通事故は遠出でも、近所でも遠慮なく発生します。家の近くだから事故がおこらないなどということはありません。しかし、近くだからシートベルトをしなかった、という人は意外に多いと聞いたことがあります。結果、軽症ですむものが、大事故になってしまいます。
誰だって、疲れていることもあるし、眠い時もあります。そういう時に手を抜きたくなるのです。そして、ヒューマンエラーは程度の差こそあれ、誰にでもおこるのです。どんな時でも、用意周到、基本動作を決めて、ルールに従い愚直に実行する。これが身を守る基本です。
