Agile RCA with SaPID
Agile RCA with SaPID とは、永田敦さん（当時ソニー）が提唱・実践されているAgile RCA（Root Cause Analysis）を、HBA Quasol安達が提唱・実践しているSaPIDで拡張し、統合したものです。
2016年4月に2人で検討を開始し、SS2016での試行を経て、2016.9.1から初公開します。
なお、当手法は随時更新していきます。
◆2017.7.13 Embedded Technology West 2017 14:30-16:00 ルーム9
なぜなぜだけが原因分析じゃない 現場改善のあり方を見直そう Agile RCA with SaPIDのススメ
※テクニカルセッションで最大の聴講者数を記録（当日は多くの立ち見聴講者が出ました）
タイムテーブル：http://www.jasa.or.jp/etwest/conf/confpage-ts.html
セッション概要：http://www.jasa.or.jp/etwest/conf/confpage-ts05.html
Agile RCA with SaPID の全体像
左図のように「ベース情報把握」からスタートし、
「質問検討とヒアリング」→「関係する要素抽出」を繰り返します。
抽出した要素は付箋に記録し、貼り付けます。
貼り付けた要素たちとその関係性を確認しながら、明らかにすべき事項を引き出す次の質問を考え、ヒアリング、付箋に記録、要素たちの関係性を把握し・・・と徐々に対象となる問題が発生するまでの過程、そして除去すべき要因を”関係者全員で”明らかにしていきます。このように除去すべき要因から始まり問題発生に至る全体像を段階的に構築していきます。
なぜなぜ分析における課題とAgile RCA with SaPIDの特徴
| No. | うまくいかないなぜなぜ分析の課題 | Agile RCA with SaPIDの特徴 |
| 01 | うまくいかないなぜなぜ分析では不具合発生要因が直線的なつながりで表現されることが多い |
「欠陥モデリング」を活用することで ・ネットワーク上の問題発生メカニズムを明らかにする ・問題発生メカニズムを構成する要素を誘因、過失因子、欠陥、不具合で識別する |
＜解説＞
うまくいかないなぜなぜ分析では”〇→〇→〇→〇・・・”のように、不具合発生要因が直線的な連鎖で分析結果が表現されることが多いです。
組織で準備した「なぜなぜ分析用のシート（様式）」がすでに直線的な要素の連鎖を意図するものになっている場合すらあります。
この連鎖は「ある要素（だけ）が次の要素を引き起こしている」という意味になりますが、不具合は直線的な要素の連鎖ではないからくり、つまり複数の要素がいろいろ連鎖したネットワーク状の構造で発生することがほとんどです。
直線的な要因の連鎖では、解決すべき要因（除去すべき要因）の選択肢は1本のパス上にしかなく、限られたものになります。
実際には存在する可能性が高い表現されていない要因が強い影響力を持っている場合、それは改善対象から外れ、再発する可能性が高まります。
一方ネットワーク状の要因連鎖構造では、複数のパス上に主な要因がすべて表現されているため、解決できるパスと要因の選択肢も多くなります。改善対策を行う組織が持つさまざまな制約（スキル・余裕・など）により対応できるパスや要因が限られる場合もあるため、選択肢がいろいろある方が現実的に改善を進めることができます。また、再発させないために対応すべき要因をすべて把握できているため、漏れなく対応きでる可能性が高まります。
補足：欠陥モデリングについては以下の情報が参考になります。
http://www.jasst.jp/symposium/jasst13tokyo/pdf/C4.pdf
| No. |
うまくいかない なぜなぜ分析の課題 |
Agile RCA with SaPIDの特徴 |
| 02 |
なぜ？なぜ？は、担当者を問い詰めてしまう傾向がある。（意図する／しないにかかわらず） →「なぜ？」は（あなたがしたマズいことを答えよ！）的な響きを持っている |
＜Agile RCA オリジナル＞ 「モデレータ（ファシリテータ）による（なぜ？ではない）探索的質問と担当者による回答」を通じて除去すべき要因（誘因→過失）と今後同様の困り事を発生させないための方法を一緒に考える場を作る。 ※質問により丹念に“事実”を拾いながら進める＋問題対私たちの図式にする。
＜with SaPIDによる拡張＞ 以上に加え、「今回の件に関連すると思われる要因があれば教えてください」など担当者が自ら頭の中にある考えを提示してもらい、その内容を手がかりにすることで探索の容易化と担当者の誤認識（思い込みや決めつけ）を正す機会を作る。 ※関係者が持つ手がかりを広く求めてから事実を明確化し、問題対私たちの図式にする。 |
＜解説＞
いつでも、必ず、ではありませんが、「なぜ？」という問いかけは、問いかける人の意図に関わらず”問い詰める”ことになりがちです。
（とても残念なことですが）
ここでの問題は、問いかけられる側が”問い詰められている”と受け取りがちであることです。
問いかける人がたとえそのつもりがなくても、なのでとてもやっかいです。
もちろん問いかける人が”問い詰める意思・意図”を持てばなおさらです。
きっと原因を探す「なぜ？」という言葉の響きが「なぜそんな（マズい）ことをしてしまったの？」的に感じるのでしょうね。
このアプローチの結果、問いかけられた側はおもしろくない、嫌な時間を過ごし、二度とこんな想いはしたくないと感じます。
原因分析は大嫌い！二度とごめんだ！となる傾向が高くなるので、自主的・自律的な改善が進まない温床になる可能性を持っています。
そして「なぜ？」で確認しようとしているのは、ある出来事や要因の一つ手前の要因です。
「なぜ〇したの？」・・・・・「それは●だったから」を構造にして「●→〇」と書く。それを繰り返して〇→〇→〇→〇・・・とつないでいきます。
（回答者がいくつかの要因を飛び越した要素を回答する場合もありますがね）
Agile RCA with SaPIDでは、「なぜ？」の問いかけではなく、「今後われわれが同じ轍を踏まずに済むように一緒に探っていきましょう！」「担当者の目から見て、こうすれば防ぐことが出来る、という手段はありますか？」「・・・とすれば例えばこのあたりはどうだったんですか？」「こんな要因やあんな要因で今回のような不具合が起きがちですが、今回はいかがでしたか？」のように、「モデレータによる探索的質問と担当者による回答」を通じて、除去すべき要因（誘因→過失）と今後同様の困り事を発生させないための方法を一緒に考える場を作ります。
ここで確認しているのは、ある出来事や要因の一つ手前の要因（●→〇）だけではなく、連携する可能性のある要因（群）の有無とその内容です。関連する可能性のある要因を明確化し、そのあとで問題発生構造（例：矢印で結ぶ）を作ります。
| No. |
うまくいかないなぜなぜ分析の課題 |
Agile RCA with SaPIDの特徴 |
| 03 |
忙しい担当者にさらに負荷をかけてしまうことが多い
|
＜Agile RCA オリジナル＞ モデレータが質問し、その回答ややり取りの内容をモデレータがモデル化し確認する＆短時間対話を複数回に分けることで担当者の負荷を最小化する。
＜with SaPIDによる拡張＞ モデレータの質問とその回答や、上記のやり取りから関係者と一緒にモデル化する（その場にいるので担当者の負担する工数は変わらない）＆短時間対話を複数回に分けることで担当者の負荷を最小化する。複数回集中して行うため、対象領域への学習・理解が進み、回すほど対応工数が短くなる。 |
＜解説＞
原因分析を行う方（例えば、品質保証担当）が、原因分析を急ぐあまり、実務担当者を引きずりまわしてしまうことがあります。
同じ部屋で結論が出るまで延々と続くインタビュー（詰問になってしまう場合も）や、原因分析とその結果のレポートを強要するなんてこともありえます。その結果、実務担当者は嫌な思いを強め、目の前にある今日の実務が進まなくなる・・・改善なんてろくなことはない的に捉えてしまうのは避けなければなりません。
Agile RCAでは、多忙な実務担当者に可能な限り負担をかけずに分析を進めます。
1回の聞き取り・分析時間をできるだけ短く（例：30分／1回程度）し、複数日に分けて実施するなど、１度に集中して答えを出そうとしすぎない工夫をします。複数日に分けることで、混乱している頭の中がクリアされ、前回（例えば前日）までの分析結果（欠陥モデル）を客観的に見て（やっぱりこれではおかしい、など）判断することができるようになります。
また、オリジナルのAgile RCAでは、モデレータが聞き取り結果をもとに欠陥モデルを作成し、その目視確認だけを実務担当者に依頼するそうです。ここにも「忙しい実務担当者にできるだけ負担をかけずに進めたい」という永田さんの気持ちが反映されていると思います。
ここでwith SaPIDとして提案したのは、同じ部屋でヒアリングに参加している関係者全員で欠陥モデルを作り上げていく、ということです。
次(No.04)の特徴記述にもあるように、自ら分析に手を染めることが「対象への所有感」を持ちつつ「自分事化」するためにとても重要になるからです。実務担当者がヒアリングに同席している時間は同じですので、付箋に「これがあったな」などを記載してもらい、貼り付けて他の要素との関係性をモデル化しても負担する工数は変わりません。（座って話をしているよりは頭と労力を使いますが（笑））
また、自ら原因分析に手を染めることで、大事な原因分析のノウハウを身につける機会にもなります。
最終的には第三者が出てこないと原因分析できない状態を打開し、自ら自律的に原因分析するように育てる場にしてしまう、というゴールをも達成するためのアプローチです。
| No. |
うまくいかないなぜなぜ分析の課題 |
Agile RCA with SaPIDの特徴 |
| 04 |
以上の結果、担当者がやらされ感、改善嫌悪感･拒絶感を強める |
＜Agile RCA オリジナル＞ 以上のアプローチにより関係者の共通認識・理解と合意形成を促す。
＜with SaPIDによる拡張＞ 自ら手を染め答えを出すことで関係者の自分事化、共通認識・理解、および合意形成を（オリジナルAgileRCAよりさらに）促し、さらにその後の自律した原因分析を可能にする。 |
＜解説＞
関係者が改善対象に対して同じ認識を持ち、改善すべき要因、そして改善策とその実施計画に合意することは見た目ほど容易なことではありません。表面上ではＯＫを出しながらも実際の本音では「まあいいんじゃない。自分の考えとは違うけど、言えば時間がかかって面倒だし、どうせ私は関係ないし。もしうまくいかなくても私の責任を問われることも無いからね。」のような当事者意識に欠ける考え方をする人も多いのです。改善がうまくいかない主な原因の一つはここにあります。
オリジナルのAgileRCAでは、01～03のアプローチにて関係者の共通理解と合意形成を促しますが、担当者への負荷軽減を考慮に入れているため。欠陥モデルを作成するのはモデレータとなっています。その分だけ、担当者が当事者意識を持ちにくい面を併せ持っているといえます。
一方、with SaPIDでは、03に記載したとおり、担当者、関係者全員が自ら手を染めて欠陥モデルを構築していきます。
モデレータは、欠陥モデルが適切に構築されるように、質問や問いかけ、疑問の提供などを通じて分析とモデル化を支援していくことにより、関係者全員が当事者になってもらう場とします。
よくあるたとえ話の通り、「魚を釣ってあげることはせず、魚の釣り方を教える」のがwith SaPIDです。
「自分がやる方が早い」と担当者に話だけを聞き、自分で欠陥モデルを作って終わらせてしまうモデレータがいます。
確かに目先の結果はすぐに得られて早く終わるように思えます。
しかし、これを繰り返すといつまで経っても担当者や関係者はモデレータに頼らないと分析できない状況が続くだけです。
with SaPIDのアプローチを継続することで、最終的にはモデレータがいなくても担当者や関係者自らが欠陥モデルを適切に構築し、的確な改善すべき要因や改善策を導出できるようになります。つまり実務担当者により自律した原因分析が実践されるようになるのです。
「自ら手を染めること」はモノゴトを自分事にするために重要な要因だと憶えておいてください。
また、「効率化は効果を獲得できるようになってから取り組むべきもの」という原則をお忘れなく。
| No. |
うまくいかないなぜなぜ分析の課題 |
Agile RCA with SaPIDの特徴 |
| 05 |
再発防止施策の効果確認に期間を要することが多い。 その結果、改善の達成感が得られにくく、その後の改善推進力につながりにくい。 |
＜Agile RCA オリジナル＞ スコープは再発防止施策を策定するまでだが、実務上では、定期的な振り返りのプロセス（アジャイル開発におけるSCRUMでの振り返り）によって効果を確認している。
＜with SaPIDによる拡張＞ ・以下のアプローチで、改善施策の効果を確実にし、早期に把握、実感する。 －改善すべき領域はよりピンポイントに絞り込む。（抽象度の高いレベルで改善施策検討を行わない） －モデレータと関係者による対話形式シミュレート（改善ストーリー）により、意図した効果が得られることが確認できた時点で施策を確定させる。 －改善施策確定直後に、対象領域をより小さく狭い領域に絞込み、過去の同類案件を別担当者が擬似的に実践することで改善施策が意図通りの効果を獲得できるかを代替確認する。 |
＜解説＞
発生した問題や障害の再発防止施策の効果確認には長い期間を要することが多いです。
その結果、「改善施策をどこで何をやるんだったのかを忘れる」、「時間が経過しているので実施する意義や意味を感じにくい」などの影響があります。さらに「改善って意味ないよね」とか「前向きにやろうとしなくなる」などのように、その後の改善推進力が得られにくい状態を作ってしまいかねません。
再発防止施策の効果確認には長い期間を要する主な原因として以下のような事項が考えられます。
－同じ業務の同じ状況が発生するタイミングが１年後や半年後であるような場合が多い
それを理由に「再発しないかどうかを確認するタイミングは1年後・半年後とする」的な計画を立ててしまう。
－根本原因にこだわるあまり、非現実的な計画や施策を立ててしまう
中長期的実践を計画し、完結できなかったり、やったことにしてしまったりする。
－改善対象を広く捉えすぎて、抽象的な効果計測指標や多岐にわたる効果計測指標で効果を把握しようとしてしまう
急性にさまざまな面を打開する方策は実践できない、あるいは中途半端な実践に終わることが多くなり、別の悪影響も発生して終わらなくなってしまうことも。（上司への説明や外部審査で”やっていません”とは言えなくなり、やったことにする など）
改善では効果を得ることも重要ですが、継続できることがさらに重要です。
それを実現するためのアプローチとして大事なことと事例は以下の通りです。
(1)対象を小さく絞り込む
抽象度の高いレベルで改善施策検討を行わず、改善すべき領域はよりピンポイントに絞り込みます。
このことにより、改善施策実践にかかる手間を最小化し、効果の把握を容易にします。
(2)どのような”からくり”で改善が成功するのかを具体的に把握する
モデレータと関係者による対話形式シミュレート（改善ストーリー）により、意図した効果が得られることが確認できた時点で施策を確定させます。このことにより、実践する前に、成功イメージを共有し、腹落ちできるようにします。
（関係者で腹落ちできるまで施策を練りつくす）
(3)改善施策の失敗リスクを最小化し、すぐに確認（必要な場合はフィードバック）する
1年後、半年後、3ヵ月後のような先送り実践はうまくいかない。
改善施策確定直後に、対象領域をさらに小さい領域に絞込み、過去の同類案件を別担当者が擬似的に実践することで改善施策が意図通りの効果を獲得できるかをすぐに代替確認する。
以上、うまくいかないなぜなぜ分析と、Agile RCA with SaPIDの主な違いを解説しました。
とはいえ、万能な手法は存在しませんし、なぜなぜ分析で成果を上げている組織、チームもちゃんと存在していますのでご注意ください。