今回は「不具合が埋め込まれて見つかるまで」どのような仕組みになっているかを解き明かしていきます。
プロジェクトにおける「不具合管理」やテストフェーズでの「不具合対応フロー」などを考えるためのベースとなる情報になるハズです。
プロセス全体像
現実、現場で働いている状況踏まえての感覚や前述の内容を踏まえてまとめると以下のような構造が作れる気がします。 作りとしては不具合発生のプロセスと不具合管理フローを組み合わせたようなものになっています。
- 根本原因
環境や組織、ソフト、ハードといった面でシステム開発にとって適切でない状態となっていると、そこが原因となって次の誤りを誘発します。
- 誤り
前述の根本原因がもととなって間違った認識や間違った行動を行い、次の欠陥を埋め込みます。
- 直接原因(欠陥)
埋め込まれた欠陥は直接的な不具合の原因となるため、直接原因と呼ばれたりもします。 埋め込まれる場所はどこにでもありうるものです。
- 障害
埋め込まれた欠陥は利用、実行されるとその不備が発現して問題へと発展していきます。 このとき、特に設計や実装に埋め込まれた欠陥のことを障害と呼びます。
- 問題
埋め込まれた欠陥は最終的にエンドユーザーが期待する動作と異なる動作として表出してきます。
根本原因
すべての出発点になります。 根本原因の分析方法はいくつかありますが、図では「m-SHELL」という考え方を示しています。 m-SHELL はもともと航空分野で使われていたもののようですが、IT分野でも使えそうなものです。
「m-SHELL」を使った原因分析では以下の6パターンに分類して考えます。
観点 | 例 | ||
---|---|---|---|
m | Management | 管理 | 経営方針、安全管理など |
S | Software | ソフトウェア | プロセス、手順書、マニュアル、規則など |
H | Hardware | ハードウェア | 機器、機材、設備、施設の構造など |
E | Environment | 環境 | 温度、湿度、照明など |
L | Liveware | 当事者 | 欠陥を埋め込んだ本人 |
L | Liveware | 関係者 | 当事者以外の関係者、同僚など |
誤り
さまざまな根本原因が積み重なった結果、人はミスを犯します。 そして、人が誤った行動をとった結果として欠陥が生み出されます。 (何もしなければミスも起こさないし、欠陥も生み出さないです。そもそもそんな人は何も生み出していないですが…)
では、その「行為の誤り」はなぜ起こるのでしょうか。 よくあるのは「認識の誤り」や「判断の誤り」といったところが考えられます。
直接原因(欠陥)
直接原因は「欠陥」であることが多いです。 ドキュメントの不備であったり、実装の誤りといった分かりやすいものです。
「問題(=あるべき姿と現状のギャップ)」を生み出しているのがどこかを特定すると、この欠陥になります。
障害
「ケアレスミス」「単純ミス」などが「欠陥」をドキュメントやコードに埋め込みます。 埋め込まれた「欠陥」の箇所のうち特に「設計」や「実装」に埋め込まれた「欠陥」のことを特別に「障害」と呼びます。
「運用障害」とも呼ばれるような、実運用中に発生するネットワーク障害や外部攻撃など運用上の問題、ハードウェア上の問題もあります。 要件として定義されていたにもかかわらず対応できていないのであれば何かしらの「運用設計」や「運用を考慮した実装」ができていないという「障害」となります。 実際は問題発生を想定できていないことが多く要件が存在しないことが多い感覚です。 要件が定義できていないのであれば「要件不備」で要件元の問題(=今回の定義では「障害」ではない)ですが… 「エンドユーザーに対するサービス影響は出さない」という暗黙の要件があるので、何かサービス影響ある問題起こせばすべて「障害」というカタチでくくられてしまう気がします。
「ユーザーに対するサービス影響有無」で「障害」かどうかを判断するケースもあるようです。 実際の感覚だと「ユーザーに対するサービス影響有無」には関係なく「システムに問題がある(=設計か実装に欠陥が混入している)」状態であれば「障害」と呼んでいる気がします。 「ユーザーに対するサービス影響有無」はどちらかと言うと、障害対応時の優先度を考えるための判断材料になる気がします。
問題
「障害」のあるシステムを動かすとシステムはユーザーの期待と異なる動作をします。 この「 "ユーザーが期待する動作" と "システムの実際の動作" のギャップ」を問題と呼びます。 不具合管理システム上だと「不具合」と呼んだりすることもあります。
テスト実施や運用でまず上がるのは「問題」です。 「問題」は「障害」以外も含んでいるので、最初に「障害」かどうかの判定(または切り分け)が必要になります。
「期待と異なる動作」だけであれば、本来は「問題(="あるべき姿"と"現状"のギャップ)」であって、障害(=設計または実装の不備)とまでは言えない状態です。 ただ、現場の感覚だと「問題(= "あるべき姿" と "現状" のギャップ)」と「障害(=設計/実装の不備)」のあたりを混同して話されることが多く見受けられます。
今回は「不具合が埋め込まれて見つかるまでのプロセス」についてまとめました。 参考になったでしょうか? 本記事がお役に立っていると嬉しいです!!
最後に… このブログに興味を持っていただけた方は、 ぜひ 「Facebookページ に いいね!」または 「Twitter の フォロー」 お願いします!!