どのように素晴らしい開発手法を用いて、抜けのない（と思った）テストを行っても、不良を0にすることはできません。
社外で不良が発覚したとき（社外事故と言ったりします）、お客さまに報告書を書かなければなりません。
単なる「ごめんなさい」では誰も納得しません。
「バグを憎んで人を憎まず」と言い人もいますが、報告書がちゃんとしないと人として攻撃されます。
不良を直すことに集中するためにも、報告書には書くべきことを知っておきましょう。
以下のようなことを書きます。
書くべきことが決まっていると言っても気を使って矛盾ないように書かないといけませんから、不良の調査・解決する人とは別の人が書くことも多いです。
- 導入
- 現象、経緯
- 仮の対処方法
- （直接の）原因
- 根本原因（動機的原因、見逃し原因）
- （直接原因に対する）対策
- 関連見直し
- 再発防止策
事故報告書
イト屋です。
工業製品を世の中に出すのであれば避けて通れないのが不良です。
不良が社外で出れば、社外事故などと呼ばれ、事故報告書を書かなければなりません。
大きな事件になれば、ニュースで報道されたりもします。そこで中途半端な報告書を出すとワイドショーで叩かれたりしているのを目にしますね。
そんな大それた報告書でなくとも、迷惑をかけたお客様に出す報告書は丁寧に誠意を込めて書かないといけません。
原因に興味がある人、対策方法が知りたい人、再発防止策だけを訊きたい人など様々な方々を納得させる必要がありますので、以下のような目次になると思います。
- 導入
- 現象、経緯
- 仮の対処方法
- （直接の）原因
- 根本原因（動機的原因、見逃し原因）
- （直接原因に対する）対策
- 関連見直し
- 再発防止策
導入
冒頭で「ごめんなさい」といいます。
何度もごめんなさいを書くのは逆に失礼な感じが出るかもしれないので、冒頭だけで最大限の謝意を込めて謝っておきます。
「A年B月C日に発生したXXXの件につきましてご迷惑、ご心配をおかけし申し訳ありません。弊社製品YYYYの不良であることが判明いたしましたので報告申し上げます。」
みたいな文章です。どの会社にも冒頭のテンプレは転がっているはずなのでそれをコピペしましょう。
現象、経緯
現象
現象は、ユーザ・顧客から見てどうなるか、です。
「DBがこんな変な動きしたんです」とかは開発者から見たら現象ですが、顧客から見たら現象ではありません。
顧客から見たらどうなるか、どうなったかをきっちりと記述します。
この時点で顧客が怒り出すと大変です。小学生の家庭教師にでもなった積りで教えてあげる、という気持ちで説明します。
経緯
経緯を書いていきます。ということで、いつ何が起きたかはメモしておきましょう。
少なくとも現象発生の日時と原因判明の日時くらいは書いておきます。
- A年B月C日D時 現象発生しXXXができなくなる
- A年B月C日E時 保守員にメール発報
- A年B月C日F時 弊社サポートに連絡
- A年B月C日G時 保守員によるサーバ再起動により回復
- A年B月C日H時 ログより原因解析開始
- A年B月K日 原因判明
原因が判明したら、いつ対策するか、いつ関連見直しを終えるか、などの予定も盛り込んで書きます。
関連見直しが終わるまで「第2報」「第3報」。。と追記していくことになります。
仮の対処方法
原因が分かって対策に時間がかかる場合、仮の対処があれば書きます。原因と現象によっては、対処方法は何もないことも多いので、仮対処が存在すれば書きます。
原因が判明しないうちに何かをやると傷口を広げる可能性があります。
しかし、サーバがハングアップしてしまったときなどは再起動せざるをえません。
そういうときは神に祈りながら再起動します。
（直接の）原因
原因は、「XXXXをやっている機能のYYYY処理でZZZZをやっていたため」のように書きます。
そして、原因から現象が起こるまでの論理をお客様が分かるように説明します。
原因が起こる⇒Aが起こる⇒Bが起こる⇒。。。。⇒現象が起こる
みたいな感じかもしれません。
顧客に理解してもらうために図や表を出すのも効果的です。
学校では、物事を理解できないのは、説明している人（先生）のせいではなく、説明を受けている人（生徒）のせいでした。
社会において物事を理解できないのは、ほとんどの場合、説明している人のせいになります。説明を受けている人が顧客で、さらに不良発生時であった場合、顧客には激怒する権利が付与されるようです(T_T)。
現象の説明と同様に、小学生に説明する気持ちで資料を作ります。
あまりに分かりやすい資料を作って「何でこんな簡単なことを間違った？」と変な怒られ方をされるぐらい、サルでも分かる資料を心がけましょう。
根本原因（動機的原因、見逃し原因）
原因を作った人間がその時の気持ちを覚えていることはまれです。
原因を作ったメンバーは異動になってもうチームにいないかもしれません。
請負で作ってもらって保障期間が過ぎていて話さえ聞けないこともあります。
こんなとき根本原因が何かと訊かれても答えようがないのはそうかもしれません。
しかし、顧客が納得するものを考え出さなければなりません。
「こうであっただろう」
「こうだったに違いない」
から根本原因を探ります。
根本原因はプロセス的なものが望ましいです。
個人のせいにしても（本当にそうだったとてしても）、顧客が納得することはほとんどありません。
ここで求められているのは真実ではなく、顧客が納得する事実です。
さらに、関連見直し、再発防止に上手く繋がっていくようなものを考える必要があります。頭が痛くなります。
実は、論理的でさえなくてよいです。厳密な論理を構築するより、情緒的な納得です。多くのエンジニアが不得意とするところかもしれません。
（直接原因に対する）対策
直接原因に対する対策は、原因の裏返しです。
「XXXXをやっている機能のYYYY処理でZZZZをやっていたため」
が原因だったらなら、対策は
「XXXXをやっている機能のYYYY処理でWWWWをやる」
という感じになります。
書かなくてもいいかもしれません。
関連見直し
関連見直しと一口に言っても、レベルが3つくらいあるのを覚えておきましょう。
- 同件見直し
- 類似の見直し
- 観点を設定しての見直し
例えば、「ZZZ機能において対象XXXに対する排他処理が抜けていた」が原因だったとします。
同件見直しは、「対象XXXに対する排他処理が問題ないかどうか」を見直します。
類件見直しは、少し対象を広げて「全ての排他処理が問題ないかどうか」になるかもしれません。
観点見直しというのは「原因から思いつく何か」について見直します。
「グローバルメモリについて排他処理が必要か、必要だったら排他を行っているか」
など、話を広げすぎじゃないかというところまで行くのが観点見直しになります。
何を見直すかよく分からなくなったとき、この3つのレベルを思い出すとよいでしょう。
思考のきっかけくらいにはなるかと思います。
さて、どのレベルの見直しにしてもよいですが、大事なのは顧客の納得です。
いちばん面倒な観点見直しをやったとしても、「原因と関係ないだろ」と思われたら元も子もありません。
顧客が納得するものを想像して設定します。
できれば関連見直しを実施する前に何を見直すかについて顧客と同意をとりたいところです。頻繁に報告してこい、という顧客が多いので、原因が判明したときに何を見直すかを出して合意するのがよいです。
再発防止策
「プロセスを変える」のが模範的な回答になります。
あまり大それたことでなくてもよく、「コーディングルールにXXXを追加」や
「レビュー時チェックリストにXXXを追加」などでよいと思います。
大事なのは、根本原因から論理的に繋がることです。
社外で不良が発生して、原因判明し、対策をする、関連見直しとかやって、、、、
ここまで辿り着くためには、計り知れない苦労をしてきたことと思います。
ここで拗れたは経験ありませんが、油断してはいけません。
根本原因から直で繋がるような再発防止にして文書を終えます。
まとめ
事故報告書の書き方をまとめました。
これを書くためにいろいろ思い出して涙が出てきました。社外の不良発生に慣れる人なんているんでしょうか。
読者が社外不良発生から早く解き放たれることを祈ります。
コメント