システムを扱う際には、障害が発生することが避けられません。
プログラムは人間が開発・管理するものである限り、どんなに慎重に開発していても、障害は避けられないものとなります。
システムエンジニアは、障害が発生した場合にはさまざまな対応に追われます。
もちろん最優先は障害の収束と解決ですが、その後には障害の原因や対応内容を詳細にまとめた報告書を作成する必要があります。
特に、社内向けシステムであればまだしも、顧客から依頼されたシステムや個人情報や金融情報を扱うシステムの場合、報告書は大きな意味を持ちます。
今回の記事では、報告書の記載において特に重要な点である「再発防止策」について詳しくご説明します。
この記事を通じて、障害が発生した際の対応だけでなく、その後の報告書作成においても重要な要素である再発防止策のポイントを学ぶことができるでしょう。
内容は以下です。
システム障害の原因
今回は、ある特定のシステムにおいて次のような問題が発生した事例についてお話しします。
（この内容は抽象的なものですが、さまざまなシステムに適用できる考え方です。）
あるシステムに対して改修の要望があり、その内容を設計、実装、試験を経てシステムにリリースしました。
しかし、その改修によって導入された新機能の一部が、予期せず正しく動作しないという問題が発生しました。
このシステムの障害がどのような原因で発生したのか、その背後にある事象に迫ってみましょう。
もちろん、システム的な観点からは〇〇関数のｘｘの動作が△△を引き起こすなどの具体的な技術的要因が考えられます。
これらの事象についての詳細は報告書などで扱われるべきです。
しかし、それ以上に重要なのは、なぜそのような事象が起こったのかという根本的な疑問です。
どうして改修が正常に機能しなかったのか、その背後にはどのような要因があるのでしょうか。
この手の障害発生について、以下の2パータンの原因について説明を深堀します。
設計の誤り
発生した問題は、設計段階で考慮されていなかったために生じました。
もし設計時に問題が予測されていれば、その問題を未然に防ぐ方法を設計段階で検討できたはずです。
このような対策を取ることで、実装を進める前に問題を回避することが可能でした。
問題が発生した背景には、設計段階で発生する可能性のある問題を見逃してしまったことがあります。
このようなケースでは、設計段階での慎重な検討や事前の影響調査などが、後の工程における問題の予防に大いに役立つことがわかります。
試験漏れ
ほとんどの障害は、この手法で未然に防げることがあります。
具体的な事象のパターンを試験していないことが主な原因です。
例えば、設計段階で何かを見落としてしまった場合、設計書から試験すべき項目を洗い出して、試験漏れを防ぐことができます。
ただし、試験の際にも事象を防ぐ方法をきちんと考慮する必要があります。
原因に対する再発防止対策
大きく２パターンの原因についてお話してきました。
それでは、それぞれのパターンについて対となるように再発防止を考えていきます。
設計の誤りに対しての再発防止
こうした再発防止策として一般的な手法は、設計書のレビューを強化することです。
問題が見落とされたのは、設計時にそれを考慮しなかったためです。
このような問題を防ぐためには、設計書のレビューの際に対処できるようにすることが必要です。
経験豊富な複数のメンバーが、こうした問題を見逃さないように設計書を見直すことが重要です。
設計書のレビューを実施して、問題を早期に発見しましょう。
試験漏れに対しての再発防止
こちらも設計時と同じく試験項目書のレビューという再発防止が１つ手としては考えられます。
また、障害内容によっては以下の内容での試験についての実施を再発防止とするのもよいでしょう。
さらに本質的な問題への対策
以下2点の原因と再発防止についてお話してきました。
それでは、より詳しく見ていきましょう。
これらの問題がなぜ発生してしまったのか、その背後にある理由は何でしょうか。
要するに、なぜ設計書のレビューが十分に行われなかったのか、そしてなぜ試験のレビューもしっかり行われなかったのか、考えてみましょう。
ここまで深く掘り下げると、異なるプロジェクトによって理由は多岐にわたることがあります。
予算の制約や人員変動（引き継ぎの課題）など、様々な要因が影響する可能性があります。
ただ、こうした要因を徹底的に分析し、改善策を導入することが本質的な問題の解決につながります。
こうした本質的な改善策に取り組む価値は、関連するプロジェクトの特性や効果を考慮して判断すべきです。
再発防止の仕組化
再発防止について以下２点でお話しました。
こちらの再発防止について実施することなりますが、より良い再発防止としてはこれを仕組化することです。
単純に「設計書レビューやります」という再発防止では、また上記に話した本質的な問題などが起因して、設計書レビューが薄くなっていた。できていなかった。など同様の事象が発生する可能性があります。
従ってできるだけ人の判断に依存せずに仕組化を行うべきです。
例えば以下です。
そしてこれらをルールとして、ドキュメントや課題管理システム（要するに通常業務で利用しているドキュメントやツール）にしっかりと明記しておきましょう。
真に理想的なことは、仕組みを完全にシステム化できることです。
人の手がまったく入らずに再発防止チェックが働く。
これができればよいですが、実際にはなかなか難しいかと思います。
まとめ
システムを開発・運用していく中で必ず発生する障害。
それに対しての原因の深堀や再発防止についてお話してきました。
内容としては以下でしたね。
このあたりの話が発生するのは、携わっている業務や、役割によってあるかないかかと思います。
ただシステムに関係する仕事をする以上、障害はあります。
また、仕事をする以上、人とのコミュニケーション（状況説明など）は発生します。
そして何よりも、障害に対する自分たちの見識を深めるために、原因の追究と再発防止を行っていきましょう。
以上です。
コメント