【問題解決管理】問題が発生したら

まずは「問題」の定義からしっかりとしておきます。

問題とは、

　「理想」と「現実」が不適切に乖離しており、
　現実（現状）に対して修正が必要と認められる状態

のことを言います。

たとえば、設計書をレビューしていたり、プログラムをテストしていたりすると、チェックリスト上には「〇〇していること」と記載されているのが、理想の結果となります。ですが、実際にはそうなっていない場合、理想と現実との間で乖離（GAP）が出てきます。

そうした乖離が発生した時点で、「それが本当に問題なのか」「チェックリストに問題があるのか」「チェック対象に問題があるのか」と言ったことがわからなくても、まずは記録に明記します。そうすることで、関係者全員が認識、識別できるようになります。

この時、必ずすべきことは「各問題を一意に識別し、記述し、記録する」ということです。口頭で終わらせてはいけません。人の記憶だけに頼った運用は必ず、別の問題を引き起こします。性善説で進行してはならないのです。常に「人は不完全な生き物」「人は過ちを犯すもの」と言う性悪説に従って運用しなければリスクを低減することは叶いません。

そして、記録化する際には、問題を再現および診断するための支援情報は、原則として提供することが肝要です。一般的には、

　第三者が再現させるために必要な情報
　　・実行するまでの準備手順
　　・実行時に、実際に行った詳細な手順
　　・実行時に取り扱ったデータ

などは、できるだけ加筆しておくと良いでしょう。

識別

問題の発見者は、いかなる事象であっても、必ず〔問題記録〕に起票し、問題解決管理責任者へ提出しましょう。発見者が、勝手に独自の判断で問題の切り分けをしたり、思い込みによる分析をしても良いことは何もありません。第三者が実施するからこそ、「思い込み」や「うっかり漏れ」などが発生しにくくなるのです。

問題解決管理責任者は、〔問題記録〕を受領するにあたり、次の事項が漏れなく記述されていることを確認してください。

問題解決管理責任者は、一意に識別できる管理番号を発行し、〔問題記録〕を更新します。もし、台帳などで管理されている場合は、１列目に項番があったりすると思うので、それで十分ですね。

これで、たとえばチーム内で「おい、アレ…問題５番の対策どーなった？」なんて会話が行われても、話し手と聞き手の間で認識の齟齬が起きません。「識別」とは一意に特定できる状況にする、ということです。

また、もしも必要情報が記載されていない場合は、問題発見者に差し戻します。この時、テキトーな運用をしてしまうと、後々誰も解決できずにずっと残り続けてしまうことになりかねません。問題味解決のまま次へ次へとプロセス（工程）が進むと、いずれ大きな手戻りを生み出すことにもなりかねませんので、注意が必要です。

ここまでが問題解決管理のスタートラインです。

こうして記録化され、管理するところまでが適切に行われていないと、その後の分析や対策などのどこかのステータスで、誤った運用になってしまいかねません。

先ほど例に挙げた台帳のような管理をしている場合は、定期報告会などの場でユーザーやオーナーに対して現状報告する機会もあるでしょう。そうした時に、正しく状況を説明するためには、ここでの管理を杜撰にするわけにはいかないのです。

もしも、問題が１つでも管理から漏れていた場合、その問題は解決されることがないまま、プロダクトはリリースされてしまうことになります。そのたった１つの抜け・漏れのせいで、大惨事になってしまうことも珍しくありません。

日経コンピュータ「動かないコンピュータ」

日経コンピュータで取り上げられる大惨事のトラブル情報も、一つひとつの原因は他愛の無いことが多いものです。

　「ある検討が漏れていた」
　「ある部分にバグがあった」

でも、その些細な問題１つがきちんと解決されていなかったがために、「システムの停止」「丸一日以上業務がストップ」「〇万人の利用者に影響」なんてことになりかねません。その損失は１億２億程度では済まないものとなることも珍しくはないのです。