システム開発

システム開発における障害撲滅の鍵は原因の深堀にあり!なぜなぜ分析で再発を防ぐ方法


システム開発における障害撲滅の鍵は原因の深堀にあり!なぜなぜ分析で再発を防ぐ方法

システム開発を生業にするものにとって避けて通れないのが「障害の是正」である。

開発の方法論が整備されつつある現在においても、障害が0というプロジェクトはほとんどありえないと言っていい。そのため障害の発生はある程度仕方の無いところがあるが、障害が発生した際にはその障害の発生原因をきちんと調査して、再発防止策を検討する必要がある。

これは顧客に提示しなければいけない場合もあれば、内部での品質向上施策として行う場合もある。どちらにせよ全うなシステム開発会社であれば、再発防止策の検討(障害の是正)は避けて通れないのである。

障害の再発防止策がきちんと考えられていないと、再び同じような障害を引き起こし、後始末が大変になることは明らかである。特に顧客からは「なぜ同じような障害を何度も起こすのか?」と必ず言われることになり、品質に対する信頼性は失いかねない。同じミスは繰り返さないというのは基本(当たり前)ということである。

そのため障害発生時における再発防止策の検討というのは、非常に重要である。

しかし障害発生時はその障害の解決に一生懸命となり、再発防止策に手が回らないし、障害が解消した後は障害の発生原因を突き詰めるという後ろめたい行為であるためか、再発防止策の検討は後回しにされやすいのが現実的なところである。

さらに障害の原因調査は一歩間違えると犯人探しとなってしまうため、有効な再発防止策を検討できないことも多い。あくまで障害原因の深堀は、再発を防ぐためであって、犯人を捜すために行うことではないことに留意したい。

 

そしてシステム開発の第一線で活躍してきた管理人からすると、この再発防止策の検討を適切に行えるシステムエンジニアというのはかなり少ないと感じている。管理人はいわゆる大手IT企業に勤めていて、システム開発の一次請けとなっているが、二次請け・三次請けとなっているパートナー企業から出てくる再発防止策は大抵甘いといわざるを得ない。

一次的にはパートナー企業に再発防止策を検討してもらっているが、いまだかつて自社の障害撲滅会議にパートナー作成の再発防止策をそのままもっていったことはない。こればかりは自分で担当者にヒアリングし、きちんと障害発生原因の深堀をしないと有効な再発防止策を立てられないので、パートナー作成の障害是正策を丸々赤字で直すといったこともしばしばあるのである。

パートナーが出してくる再発防止策が甘い理由ははっきりとしている。それは”障害原因の深堀”が浅いのである。

障害原因の深堀が浅いと、いわゆる根本原因がわかっていないので、表層的な解決策で終わってしまっていたり、的外れな再発防止策になってしまっていることが多い。”表層的”とはその障害とドンピシャ同じことは防げるがちょっとでも事象と違うことが起きると防げないということであり、”的外れ”とは本質とは違う方向の是正になっていて、是正が是正になっていないということである。

障害原因の深堀がしっかりと出来ていれば、その発生障害の根本原因がわかり、それに対する是正策を検討することで初めて類似障害を防げるのである。さらに障害原因の深堀をしっかりと行うと、その過程で担当者の品質に対する意識も向上するといわれている。

それでは具体的に障害原因の深堀を行う方法を解説していこう。

 

言葉の定義

まずは障害原因の深堀をするにあたって登場する、言葉の定義をしていこう。

直接原因 障害の原因となったシステム上の欠陥箇所。言い換えればそれを直せば傷害が解消する箇所のこと。障害の発生時はまずこの直接原因を調査して、それを取り除くことが最優先となる。直接原因は以下のようなものである。

・ロジックの不良(バグ)(例:加算処理が漏れた)

・処理制御の不良(例:参照マスタが古かった)

作りこみ原因 障害の原因箇所(直接原因)を作り込んでしまった原因・理由。障害原因深彫りの第一歩となり、後述する”なぜなぜ分析”の第一歩となる。作りこみ原因とは以下のようなものである。

・直接原因が、設計書の誤りだとすると、その設計書を誤まって記載してしまった理由(例として、「処理ロジックの認識を誤まっていた」や「上位設計書がそもそも間違っていた」など

・直接原因が、コーディングミスだとすると、そのコーディングミスを埋め込んでしまった理由

流出原因 障害の埋め込みを発見できなかった理由。要するにレビューやテストで発見できなかった理由。
根本原因 障害の発生理由について「作りこみ原因」「流出原因」をそれぞれ個別に深堀(なぜなぜ分析を繰り返す)した結果得られる真の原因。基本的には再発防止策の検討はこの根本原因に対して行われる。

 

障害原因の深堀では、きちんと「作りこみ原因」と「流出原因」に分けて確認することが重要である。よくあるのがすぐにテストで漏れてしまった原因の確認からはじめて、それだけで終わってしまうことである。確かに障害原因の深堀ではテスト工程の問題(議論)になりがちであるが、その前にその障害を埋め込んだ原因があるはずである。

当然、すべての埋め込みを防ぐことはできないので、テストで討ち取るという考え方もできるが、一番いいのはやはり障害をそもそも埋め込まないことである。まずはきちんと作りこみ原因を確認した後に、流出原因の深堀に移るのがよい。

 

障害原因深堀りの方法~障害発生の根本原因を明確にする方法~

システム開発に限らず、障害発生の根本原因を探る方法として一般的なのが”なぜなぜ分析”である。

なぜなぜ分析とは、ある問題に対してその問題を引き起こした要因(なぜ)を考えて、さらにその要因を引き起こした要因に対して”なぜ”という問いを繰り返していく手法である。元々はトヨタ生産方式を構成する代表的な手段として有名である。

図のように、提示した原因に対して、「なぜ」が出なくなるまで「なぜ」を繰り返し、到達した原因が「根本原因」となる。

例えば「ある機械が止まってしまった」という障害が発生したとする。そのときの直接原因が「機械がオーバーロードしてヒューズが切れたため」だったとしよう。

そのときの「なぜなぜ分析」の一例は以下のようになる。

①「なぜ機械が止まってしまったか」 → 「オーバーロードしてヒューズが切れたため」(直接原因)

②「なぜオーバーロードしたのか?」 → 「軸受け部の潤滑が十分ではなかったから」

③「なぜ十分に潤滑しなかったのか」 → 「潤滑ポンプがあまり機能していなかったため」

④「なぜポンプが機能していなかったのか」 → 「ポンプの軸が磨耗して損傷していたため」

⑤「なぜポンプの軸が磨耗していたのか」 → 「ろ過器が付いていないので切粉が入ったため」(真の原因)

⑥「なぜろ過器が付いていなかったのか」 → 「切粉が発生するという認識がなかった」

⑦「なぜ認識がなかったのか」→「ポンプの説明書を読んでいなかったから」(根本原因)

直接原因であるヒューズを交換すれば、機械は再び動く。しかし根本原因を取り除かないと再びオーバーロードは発生するかもしれないし、根本原因に起因する他の障害も発生する可能性がある。

この例では、実はポンプの説明書を読んでいなかった(説明書を読むということがルールとしてなかった)ということがわかったので、知識の浅い機器や新しく導入した機器に関してはきちんと説明書を読んで、適切な整備を行うルールにするという再発防止策が打てる。説明書を読むなどということは当たり前のことかもしれないが、根本原因を突き詰めると実は単純だったということは多い。

ここで注意してほしいのは、なぜなぜ分析は人(個人)の責任の所在を明確にするものではないということである。

障害深堀は一歩間違えると、個人の責任追及の場になりやすいが、これは何も解決になっていない。根本原因は組織としていかに効率的な対策を講じて、再発を防ぐかが重要である。そのため根本原因は”体制”や”プロセス”の問題に持っていくのが通常である。

上記の例では、「説明書を読んでいなかった担当者の問題」ではなく、「説明書を読むというプロセスになっていなかった」ことを根本原因と考えるべきである。

またなぜなぜ分析は答えが一つではないので、いくらでも人の問題にすることもできてしまう。例えば上記の例では、以下のような分析でも論理としては正しい。

①「なぜ機械が止まってしまったか」 → 「オーバーロードしてヒューズが切れたため」(直接原因)

②「なぜオーバーロードしたのか?」 → 「軸受け部の潤滑が十分ではなかったから」

③「なぜ十分に潤滑しなかったのか」 → 「潤滑ポンプがあまり機能していなかったため」

④「なぜポンプが機能していなかったのか」 → 「ポンプの軸が磨耗して損傷していたため」

⑤「なぜポンプの軸が磨耗していたのか」 → 「ろ過器が付いていないので切粉が入ったため」(真の原因)

⑥「なぜろ過器が付いていなかったのか」 → Aさん(個人)が付け忘れていたから」(これって根本原因?)

ほかにも個人の責任にしてしまう悪い例としては以下のようなものがある。

①「レビューで見逃していた」 → 「レビュー者の知識が足りないから」×

            → 「知識が足りないうちにレビュー者にしなければいけない体制だった」

②「コーディングルールを守らなかった」 → 「コーディング者がルールを知らなかったから」×

                    → 「コーディングルールを周知する仕組みがなかったから」

③「間違った資料を基に設計していた」 → 「Aさんがメールを確認していなかったから」×

                       → 「重要な資料をメールだけで連携していたから」

 

言うなれば人は必ずミスを犯すものである。再発防止策では、それを仕組みやプロセスで防いでいくのが有効である。そのため個人の責任追及をしていたのでは一生解決しないのである。

障害深堀の最中に、「感情的になり始める」、「他人の悪口が始まる」、「個人の責任論が出始める」、「恫喝や押し付けが始まる」などが生じたら、そもそもなぜ障害原因を深堀しているのかという目的を思い返してほしい。

 

なぜなぜ分析をすると根本原因がわかる理由

障害の直接原因がわかったとしても、障害原因の深堀をしてみるとその根本原因は様々である。

例えば、「コーディングが間違っていた」という直接原因があった場合も、

①「コーディング者がミスしてしまった」 → 「コーディングルールが足りなかった」

②「内部(外部)設計書の記載が曖昧だった」 → 「外部設計書のチェックリストに追加」

③「誤まった内部設計書の版を元にコーディングした」 → 「最新の設計書を確認するプロセス」

というように再発防止策は根本原因によって変わってくるのである。

障害の根本原因の深堀が出来ていないと、コーディングミスをしたのがいけない!ということで終わってしまい、そこに隠れるプロセスの問題や連絡体制・仕組みなどの改善点が発見できない。深堀をしてみると原因は様々なので、根本原因を解決するために本当に有効な再発防止策を立てることができて、初めて類似障害を防げるのである。

障害原因の深堀において「なぜ?」を繰り返さないと根本原因はわからない。「なぜ?」を繰り返すことは後ろめたい行為なのでかなり精神的にはつらいのであるが、「なぜ?」が出なくなるまで繰り返すことがポイントである。

 

まとめ

障害原因の深堀と再発防止策の検討には、「なぜなぜ分析」が必要であることを解説した。

ただし、実はシステム開発において再発防止策は「チェックリストの追加」というようなものに落ち着くことが多い。これは結局ヒューマンエラーはチェックリストのようなものでしか防ぐのが難しいためであるが、一番いい方法はこういったヒューマンエラーをシステム的に防ぐ方法である。

特にコーディング規約違反などの障害は、CCT(自動コーディングチェックツール)などの活用によって、人の運用に頼らない方法を検討したいものである。

 


<スポンサーリンク>

IT虎の穴トップへ戻る

-システム開発
-

Copyright© IT虎の穴 , 2024 All Rights Reserved Powered by AFFINGER5.