障害の再発防止策は、
1. メカニズム
2. ツール
3. ルール
4. チェックリスト
の順番に検討せよ。
上記は、私が20年前に所属していたパッケージソフト開発会社の標語です。
※転職したので現在の所属会社ではありません。
当時はまだインターネットが今ほど普及しておらず、修正パッチはCD-Rで配布していました。
特に、データ破損系の障害の場合は、
- お客様にファックスで障害内容を報告し、
- 緊急ホットラインを開設し、
- データ異常が見られる場合はバックアップを預かって修正後に返却し、
- 上記と同時並行でバグの原因調査と修正を行い、
- パッチをCD-Rに焼いて配布する。
という障害対応を行っていました。
各パッケージの利用社数は数万〜10数万社に上りますので、大変な騒ぎでした。
そして事後に、障害の再発防止策を検討し報告する義務が課されるわけです。
メカニズム
- 仕組みとして、障害原因を封じ込める対策。
- 人手を介在せず、精神論の入る余地もない。つまり人間に依存しない。
例えば「登録ボタンを連打するとデータが重複登録されてしまう」というようなバグであれば、
- 連打されても重複登録が発生しない（あるいは連打できない）ボタン部品を開発する。
- さらに、画面のスーパークラスで、ロード時にボタンを部品に置き換えてしまう。
というような対策です。
※あくまで説明のための例示です。処理速度が〜、設計として〜、等は無視して読んでくださいね。
このカテゴリによる再発防止策が最も強固で、あるべき姿とされていました。
ツール
以下のような再発防止策がこのカテゴリになります。
- 静的コード解析ツールで、今回と同様の障害を検出する。
- 当時はOSSというものも普及していなかったので、会社内で静的コード解析ツールを作っており、それに機能追加することが多かったです。
- あるいは、テストツールに今回と同様の障害を検出できるようなスクリプトを組み込んで、リリース前に毎回それを走らせる。
人手を介在させていますので、ヒューマンエラーの可能性が残ってしまいます。
したがって、メカニズムよりも有効性が下がります。
ルール、チェックリスト
今考えると、チェックリストの方が、ルールよりも実効性がありそうに思えますが…
チェックリストの順位が一番下にきている理由は、
- ルールとは、チーム内のローカルルールではなく、全社統一の開発ルールを意味していたこと。
- 「チェックリストに項目を追加します！」という再発防止策に安易に逃げずに、メカニズム、ツールによる対策を検討するように促されていたこと。
ということだったと記憶しています。
あとがき
少なくとも、自社プロダクト/サービスのビジネスモデルでは、今でも通用する標語ではないでしょうか。
エンタープライズ系業務システム（受託開発・保守運用）では、コストや体制などのハードルはあるかもしれませんが…
しかし分野を問わず、メカニズムやツールでバグを抑え込むアイデアを考えて提案すれば、きっと技術者として良い評価に繋がるはず（私はそうあって欲しいです）。
ちなみに、当時この会社では、再発防止策の評価制度がありました。
創造的かつ効果的な再発防止策を出したチームに対しては、最高で数十万円の報奨金を出していました。
障害は出ないに越したことはないですが、「失敗から学べ」というのも、いつの時代も変わらないセオリーですよね。
なお、本稿の内容は、私の現在の所属企業における立場、戦略、意見を代表するものではありません。