初めに(自己紹介)
2022年7月1日に入社したQAの金丸です。前職ではITメーカー系の企業でQAとして勤務していました。 今回は前職の経験を活かした5W（なぜなぜ分析）による障害分析の取り組みと効果について紹介したいと思います。
障害分析
QAチームとしてテスト品質の向上を継続していくことはもちろんなのでが、私は障害分析について特に注力しました。 理由は私の前職での経験があります。前職では障害が生じた際に障害分析を必ず実施するルールとなっており、大企業のQAだったこともあって障害分析に関わる機会が多くありました。
その際、障害分析をするのですが、過去数年前と同じような原因での障害発生が殆どでした。 さらに要因を調査すると、以前は同じ開発チームのため防げていたが体制変更により引継ぎで不足が生じたため同様の障害を発生させてしまったと言う経緯があることがわかりました。
これは開発チームが悪いのではなく、数年経ってチームが変化した時でも同じ要因で障害発生をさせない造り込みが大事だと言うことになります。 コミューンは成長中の会社であり、会社の成長に伴って人数が増え続けています。ですので、人数が増えることによる開発チームの変更が大企業よりも早いスパンで行われていきます。
そのため、今の段階で障害分析をしっかりと実施してチーム体制が変更となった時でも問題ないような障害再発防止策を考える必要があると思いました。
再発防止策の基準
再発防止策の基準として、これまでの経験より私は以下の3項目を厳守する必要があると考えています。
特に3において特筆すると、理想的な再発防止策を考えたとしても継続的に実施できないと意味がありません。 前述したように、数年経ってチームが変更したとしても実施し続けることができる再発防止策が望ましいです。
この部分についてはいつも悩むポイントで、継続的に実施するためには『開発プロセスに組み込むと効果的であるけれどそのためには各チームの合意や工数との兼ね合いがあるためなかなか実現しない(継続性はあるが実現性が少ない)』というジレンマに陥りがちです。
そのため、QAとしてどのような採決を下すかを障害毎に常に考える必要があります。
未来の障害を防止する
障害分析を実施する際は、発生した障害を今後も防ぐことは勿論ですが、同様の原因で発生する障害についても再発防止策を考えることによって未来の障害を防止できます。
例えば、『エアコンのスイッチを消し忘れて外出してしまった』という障害が発生したときに、『外出時はエアコンのスイッチを必ず確認する』とすると、エアコンのスイッチ周りの障害は防げてもテレビのスイッチ周りの障害を防止することができません。
ここで障害について分析を行うと、1つの障害から以下のようなさまざまな要因を洗い出すことができます。
- 何故外出時にエアコンのスイッチを確認しなかったのか
- そもそも外出時に勝手にエアコンのスイッチが切れた方が良いのでは?
- エアコンスイッチ以外にもスイッチがあるけどこれについてはどうだろうか
この例のように、効果的な障害分析手法を用いることができれば未来の障害の1例である『テレビのスイッチを消し忘れて外出してしまった』を防止することができます。
従来の手法
従来、コミューンでは障害分析手法としてポストモーテムを採用しております。
ポストモーテム概要
ポストモーテム(postmortem=事後検証)は障害原因/その影響/解決時にとった行動/再発防止策などの項目をあらかじめテンプレート化しておき、障害発生時にそれぞれの項目をドキュメントに落とすことで障害に対して多角的に振り返り、同じ障害を繰り返さないことを目的とした手法です。 予め決定しておくべき項目は色々ありますが、有名なテンプレートとしてPagerDuty版があります。 コミューンはこれまでの障害から最適な項目を選出して運用してます。
コミューンにおけるポストモーテムの改良点
ポストモーテムは事象を多角的に捉えることができるという反面、担当者が項目を埋めていくスタイルのため、その項目をどの部分まで記述するかが属人的になりやすいという側面があります。 そのため、障害原因をどこまで突き詰めるのかが担当者によって異なり、原因深掘りの粒度がバラバラになってしまいます。
5Wの導入
コミューンではQAの障害分析手法として5W(なぜなぜ分析)を採用しました、その経緯と実績について記述したいと思います。
5W導入の背景
前章の通り、ポストモーテムが属人的になりやすいという側面があったため、誰が担当しても同じレベル感で障害原因追求ができる障害分析手法があれば良いなと思いました。 そこで、障害原因に対してWhy?を5回繰り返すことで真の原因を突き止める5W法を採用しました。
5W概要
5Wは障害原因に対して、「なぜそれが発生してしまったのか?」を繰り返し実施します。 1W目では、障害が発生した直接の原因に対して「なぜそれが発生してしまったのか?」を考え、その結果に対して2W目で「なぜそれが発生してしまったのか?」を問いていきます。 その後3W目、4W目と繰り返し問うことによって、5W目で真の原因に辿り着くことができるという手法です。
5Wで導出できたそれぞれWの原因に対して、再発防止策を考え適用することによって、直接の障害・未来の障害の防止を実現できます。
5Wの例
前章の例「エアコンのスイッチを消し忘れて外出してしまった」に対して5Wを適用すると、
- 1W：「なぜエアコンのスイッチを入れて外出してしまったのか?」
- ⇨「外出時にエアコンのスイッチを確認しなかったから」
- 2W：「なぜ外出時にエアコンのスイッチを確認しなかったのか?」
- ⇨「外出時に何を確認すれば良いのかわからなかった」
- 3W：「なぜ外出時に何を確認すれば良いのかわからなかったのか?」
- ⇨「外出時に確認する項目を洗い出せていなかった」
- 4W：「なぜ外出時に確認する項目を洗い出せていなかったのか?」
- ⇨「外出時に外に出るという行動以外への関心が抜けていたので確認項目を作らなかった」
- 5W：「なぜ外出時に外に出るという行動以外への関心が抜けていたので確認項目を作らなかったのか?」
- ⇨「行動に対して確認項目を作成すると言うプロセスが抜けていた」
となります。ここで導出したそれぞれの原因に対して再発防止策を考えると、
- 1W：「外出時にエアコンのスイッチを確認しなかったから」
- ⇨「外出時には必ずエアコンのスイッチを確認する」
- 2W：「外出時に何を確認すれば良いのかわからなかった」
- ⇨「外出する時の確認項目(やるべきリスト)を作成する」
- 3W：「外出時に確認する項目を洗い出せていなかった」
- ⇨「外出する時の確認項目(やるべきリスト)を作成する」
- 4W：「外出時に外に出るという行動以外への関心が抜けていたので確認項目を作らなかった」
- ⇨「外出する時の確認項目(やるべきリスト)を作成する」
- 5W：「行動に対して確認項目を作成すると言うプロセスが抜けていた」
- ⇨「外出や留守番や入室など、何かしらの行動を行う際にはその行動に対する確認項目を作成して実施する」
となり、5WのWhyに対する再発防止策によって、外出以外の行動に対する再発防止策を策定でき未来の障害を防止できます。
5Wの注意点(1つ目)
ここでの注意点としては、Why?から原因を考える時に人を責める内容を考えてはいけません。 理由としては、人を責めた原因を取ってしまうと解決法も人に対してのものになってしまうため、チーム全体への効果が薄いからになります。人はどうやってもミスをするものなので、その人の状態や能力不足を原因としてしまうと良い障害分析をすることができません。
【悪い例】
1W「外出時にエアコンのスイッチを確認しなかったから」 ⇨「その日は寝不足で確認が漏れていた」⇨「外出する前はよく寝るようにする」
人によってはよく睡眠をとっていようがエアコンのスイッチを消し忘れてしまうことがあるため、これでは効果的な再発防止策と言うことができません。
5Wの注意点(2つ目)
2つ目の注意点は、最後までWhyを考えることにこだわらないことです。5Wという名前から必ずWhyを5回繰り返す必要があると認識されるかと思いますが、事象によっては2回や3回目のWhyで原因に辿り着くことができます。ここで必ず5回やろうとすると、その後のWhyでこじつけのような原因を考えてしまい当初の目的とは異なる再発防止策を導いてしまいます。
また、Whyが重なるにつれて真の原因が明らかになりますが、システム開発の現場での真の原因は往々にしてプロジェクトやビジネスの問題といったものになりやすいです。そのため、『真の原因はコレであるが、この解決の為にはビジネスモデルを変える必要があるため実現性が薄い』といったケースが多々あります。なので、QAはどの解決法が効果的かつ実現性が高いかを模索しながらWhyのコントロール、解決法の考案に注力する必要があります。
5W実施ケースと効果
チーム全体の障害分析手法をいきなり変更することは適切ではなく、ポストモーテムはポストモーテムの良い部分があるため先ずは5WをQA内で実施することとなりました。 これにより一定の効果を挙げることができれば全体共有の後にポストモーテムに加えて5Wを運用していく予定です。
5Wを運用し初めて現在1ヶ月が経とうとしていますが、過去の障害含めて週に一度QAチームで障害分析をおこなっています。 その結果をテスト観点に追加することによって、直接の障害防止・未来の障害防止を目的に取り組んでいます。 その成果もあり、直近で追加したテスト観点で1つのバグをテスト段階で摘出することができました。これは、5Wを実施する中でどのようにすれば類似の障害を防げるかを考えた結果だと思います。
現状はテスト観点の追加に留まっていますが、QAとしてはバグを作り込ませない開発についても考えたいと思い、そちらの方面でも模索する日々です。
5Wの改善点と今後の展望
ここまで5Wについて述べてきましたが、まだ5Wには改善点があると考えています。
現状の5Wの改良点
システム開発は様々な工程を経てリリースしています。
コミューンでは主にスクラム開発を採用しています、スクラム開発はウォータフォールとは異なっており短期間で複数の工程を回しており、このスクラム開発に対して効果的な再発防止策を考えるのであれば開発工程だけに目を向けるのではなく、開発の前の段階(プロジェクト検討やプランニング)の工程にも着目して再発防止策を考えた方が良いと思っています。
ですので、5Wを更に工程を意識した障害分析手法に派生できないかと考えおり、直近で手法のβ版を策定できたのでこちらについても継続的に実施していく予定です。
後書き
QAは直接開発することはありませんが、開発の全体像を見られるからこそ1つのアクションで開発に対する大きな効果を与えることができる唯一の要員だと思っています。 今回の障害分析手法の施策もそうですが、システム開発に絶対なる品質の特効薬があるわけではありません。 そのため、QAとして現状の問題点の解決策を常に考え、安定的に品質の高い開発ができるよう私含めてQAチーム一丸となって取り組んでいく所存です。
