関西例会レポート

秋の特別セミナー　講演 2 「ソフトウェアの障害の根本原因分析をアジャイルにやってみませんか」 ～アジャイルRCAの紹介～   永田　敦様

1．はじめに

エンジニアを活かし、現場を活かす根本原因の分析手法について、PM向けにアレンジして頂いた。 　盛り沢山の内容を60分に濃密に纏めて頂き、熱く、丁寧に、受講者の方に語りかけるようにお話し頂いた。

2．概要
2-1．なぜなぜ分析の問題点

① 時間がかかる 　なぜなぜ分析に慣れていないエンジニア(開発担当者)に説明資料を作らせ、エンジニアの周りの関係者たちが、資料の不備を見つけて、エンジニアに何度も資料の作り直しをさせる。 　エンジニアが説明資料を作成することに、平均8時間かかる。期間では、長くなると、半年程度かかることもある。こうして、分析の専門家でないエンジニアの時間をどんどん奪っていく。 ② エンジニアが責められる 　TPSでのなぜなぜ分析は、工場の製造ラインで適用されてきた分析である。この場合、分析対象は、現場の“もの”である。 　しかし、ソフトウェアに適用する場合、対象は“もの”ではなく、“エンジニア”となる。分析対象であるエンジニア自身に「なぜ」と問うのである。 　「なぜ」は最強の質問であるが、心理学的に「なぜ」は、ストレスがかかる質問であると言われている(The Art and Architecture of Powerful Questions, Eric E Vogt, Juanita Brown and David lsaacs, 2003)。意図せず、過ちを犯した人を攻撃してしまう質問である。 　エンジニアは、間違いを起こしたくて、起こしているのではない。質問する側も責めるつもりはなくても、「なぜ」と問うと、エンジニアは攻撃されていると感じる。 　ソフトウェアの間違いは、エンジニアの判断で、作り込んだり、見逃したりしたものである。エンジニアに「なぜ」と問うことは、エンジニア自身の判断基準を分析させていることになる。これは、価値観を評価させていることにもなりかねない。 　このようになぜなぜ分析は、エンジニアが責められている感じ、ストレスを感じる分析である。 ③ 分析力が育たない 　エンジニアは、「なぜ」と問われただけで委縮し、正しい分析が行えない心理状態となる。「なぜ」「なぜ」と繰り返すごとに、根本原因からどんどん離れていく。 　また、エンジニアと聞き手との間で、議論が空中戦に陥りやすい。 　このため、個人の分析力も育たないし、障害の再発防止、未然防止のノウハウも蓄積しない結果となる。 　出てくる原因と思い込んでいるものが、中途半端な内容である。 　例えば、“テストが漏れた”“設計間違いだった” 、“レビューが不十分だった”、“ コーディングミスだった”などの中途半端な内容を原因に採用してしまう。 　これらの原因への対策も中途半端となり、絆創膏を貼るだけとなる。テストやレビューを増やすことが対策になりがちである。このように、仕事が増えるが、根本原因に辿りついていないため、絆創膏を貼り続けなければならない。 　ぼやけた原因にぼやけた対策で、工夫したことが見えない。

2-2．根本原因の引き出し

① ファシリテーションスキル・質問力 　エンジニアに対して、「なぜ」しか問わないなぜなぜでは、ファシリテーションのスキルは上がらない。 　貴重な情報を持っているのは、エンジニアであり、一番の専門家は、エンジニアである。まずは、エンジニアを尊敬することが、大切である。 　「なぜ」を使用せず、エンジニアへ適切な質問を考えて、エンジニアから教えてもらう。ここで重要となるスキルが、ファシリテーションである。 　汎用的に適用できる適切な質問があればよいが、組織文化とドメインによって異なってくるため、組織で質問力・ファシリテーション力を訓練して、育んでいくしかない。 ② 欠陥モデル 　なぜなぜシートは、直線的に掘り下げていくので、複合要因を探るには適していない。たいていは複合要因なので、根本原因分析には、欠陥モデルを採用する。 誘発因子：人間の思考や判断の誤りを誘発するトリガーとなる要素 過失因子：人間の思考や判断の誤りそのもの 増幅因子：過失の連鎖を助長し、欠陥の混入確率を増幅させる要素 欠陥：人間の思考や判断の誤りが表出化したもの 表出現象：欠陥が引き起こした障害 　欠陥モデルは、各因子が相互に関連し、直線的ではなく、網目状になる。これを適用することで、エンジニアに間違いを起こさせた罠(根本原因)に辿り着ける。 　また、分析対象は、“エンジニア”ではなく、“欠陥モデル”となる。 　もし、この分析と同じ状況、条件、環境、タイミングにおかれたら、同じ間違いを起こすことを痛烈に認識したら、分析は成功である。

2-3．イテレーションと適切な質問

エンジニアに負担をかけないため、分析が完了するまで、エンジニアは、手ぶらで会議に来てもらう。分析チームは、エンジニアへの質問を準備し、イテレーション1日目は、“事実”、“背景”、“状況”、“起きたこと”だけを聞いて、15分以内で質問のみで終了する。分析は我慢する。ファシリテーションスキルとしては、“傾聴”と“パラフレージング”が有効である。その後、分析チームは、欠陥モデルを作成して、モデルから次の質問を考える。 　2日目は、分析チームが準備した質問をベースとして、探索的にエンジニアへの質問とエンジニアからの回答を繰り返す。その後、仮設を立てながら、欠陥モデルに修正を加えていき、次の質問を考える。 　3日目は、欠陥モデルを使用して、エンジニアに質問し、欠陥モデルの合意まで目指す。 　4日目は、対策まで立案して最終形を完成させる。 　“質問”→“回答”→“分析”→“兆候”または“推論”→“探索”→“質問”とアジャイルRCAループを回して、欠陥モデルの合意に至る。 　これを繰り返すと、分析チームは、貴重な情報を持っているエンジニアに対し、尊敬するようになる。 　この欠陥モデルのレビューにて、開発チームと分析チームともに、学びや気づきが出てくる。 　会議は、1回30分以内厳守と決めて実施することが重要である。最大でも、イテレーションは、8回以内で解決策まで導けるので、エンジニアは、合計4時間以内時間をかけることで、根本原因と対策まで導ける。

3．まとめ

アジャイルRCAの効果として、“継続性”、“分析スキル改善”、“分析チームと開発チームとの信頼関係”、“人間を責めない分析”、“現場から品質改善のモチベーションが高まる”など、さまざま効果がある。 　もし、あなたたちが、この分析と同じ状況、条件、環境、タイミングにおかれたら、同じ間違いを起こすことを痛烈に認識したら、分析は成功である。 　ここまで分析して、再発防止と未然防止が可能となる。

4．感想

ソフトウェアの現場では、分析対象は、エンジニアではなく、欠陥モデルであると認識できた。 　なぜなぜ分析で苦労している、ソフトウェア開発の現場に対し、このアジャイルRCAが導入され、活気のある職場が広がっていくと、どれほどよいかと想像した。