
NotionAIでなぜなぜ分析してみた
今回はNotionに搭載されたAIをつかって「なぜなぜ分析」なるものをやってみました。なかなかの優秀さを見せているNotionAIですが果たしてシステム障害分析の世界でもチームを助けることができるのでしょうか?
NotionAIとは?
もはや説明が必要がないほど一般的になっているNotionですが、超簡単に説明してみます。Wikipediaにはメモ取りウェブアプリなんて書かれていますが、チームで創造的な仕事を進めるために有効なメモ機能、タスク管理、データベースなど様々な機能をオールインワンで揃えたサービスです。しかもメモの中に画像からテーブル、チェックリスト、Webサイトを埋めこむことができ、職場にある何でも書いたり貼ったりすることができるスペシャルなホワイトボードといった感じになっています。
最近はSaaS各社も似たような機能を提供し始めてはいますが、Notionはその中でも先頭を走っている感じで、どんどん新しい機能が提供されています。
「なぜなぜ分析」とは?
「なぜなぜ分析」とはトヨタ生産方式を代表する手法のひとつで、問題が生じた際に、提示された問題に対して、さらに「なぜ」を提示するプロセスを繰り返すことによって真の原因を導き出すという手法です。
アウトラインだけを見ると単純に問いを繰り返すだけなので簡単と錯覚されやすいのですが、何も考えず実際にやってみると、単なる詳細化に終わってしまい真の原因にたどり着いていないケースも発生する、それなりにノウハウが必要な呪法でもあります。
プロンプトを考えてみる
今回の場合、おそらくは最初の設定付けが必要なのでプロンプトについてはきちんと考えてみました。ポイントは以下のとおりです。
・「なぜなぜ分析」のエキスパートと定義する。
・障害内容の技術的な部分はわかっている前提で詳細の説明をする。
使うケースはプログラムリリースの作業でで権限の設定が漏れていたため、その機能を必要とするユーザーが使用できない状態になってしまったという障害で、手順書には大きな問題はなく、必要な手順を飛ばして実行してしまったのが表向きの原因。
いわゆる作業ミスであるが真の原因はチームのコミュニケーションが欠落していた状態だったので、インフルエンザで欠勤した作業者の代替要員が準備されず、それでも作業を1人でやったこが原因だったケースを想定しました。
最初マネージャーは担当者のミスとして責め立てていましたが、実際に一番悪いのは、悪い事態を報告させない雰囲気を作っていた、そのマネージャーだったというオチです。
実際のプロンプトはこんな感じにしました。
あならはトヨタ生産方式の手法の一つである「なぜなぜ分析」のエキスパートです。以下にあるシステム運用チームで発生した障害について、私が「なぜなぜ分析」を行う手助けをしてください。
発生した障害
発生日:2025年1月15日
障害内容:新機能が経理部門に操作権限がなく利用できない状態になった。
原因区分:作業ミス
原因:プログラムリリース作業を指定された手順書に沿って実行をした、リリース作業はエラーも発生せずに終了したのだが、手順の一部である「権限ファイルのメンテナンス」を実行せずに飛ばしてしまったため、経理部門に必要な参照・更新権限が付与されなかった。
対応:障害報告後すぐに権限ファイルを正しくメンテナンスし回復
障害時間:2時間
まずはプロンプトを投入してみる
投入するプロンプトが出来上がったのでさっそく実行してみます。
まずはNotionAIのメニューの中から最も近そうな「アイデアをブレーンストーミング」を選択します。

「何をブレインストーミングしたいですか?アイデアを考え出すお手伝いをします。」と聞かれますが、スルーしてそのまんまプロンプトを投入してみます。

以下のような回答が返ってきました。すでになぜなぜが5回掘り上げられた状態の回答で推奨される対策まで返ってきました。この時点で「なぜなぜ分析やったふり」はクリアできます。このまま出せばメンバー5人が1時間かけたとして5時間の時間短縮です。(笑)
今回は本当の原因を探りたいので返答を確認していきます。
「なぜなぜ分析」を一緒に進めていきましょう。この分析では、問題の根本原因を特定するために「なぜ?」を5回程度繰り返し掘り下げていきます。
問題:経理部門が新機能を利用できない状態が発生
第1のなぜ:なぜ経理部門は新機能を利用できなかったのか?
→ 権限ファイルのメンテナンスが実行されていなかったため
第2のなぜ:なぜ権限ファイルのメンテナンスが実行されなかったのか?
→ 作業者が手順の一部を飛ばしてしまったため
第3のなぜ:なぜ作業者は手順を飛ばしてしまったのか?
考えられる要因:
手順書の重要性の認識が不足していた
時間的なプレッシャーがあった
作業の確認プロセスが不十分だった
手順書の見やすさ・わかりやすさに問題があった
第4のなぜ:なぜ手順のスキップが事前に防げなかったのか?
考えられる要因:
チェックリストがなかった
作業の二重確認プロセスがなかった
自動化されていない手作業が多かった
作業完了の検証プロセスが不足していた
第5のなぜ:なぜ作業の品質を保証する仕組みが不十分だったのか?
考えられる要因:
品質管理プロセスの設計が不十分
リスク評価が適切に行われていなかった
過去の類似インシデントからの学習が活かされていない
作業プロセスの標準化が不十分
推奨される対策:
作業手順書の改善
チェックリストの導入
重要手順の視覚的な強調
手順間の依存関係の明確化
プロセスの改善
作業の二重確認制度の導入
自動化可能な作業の特定と実装
完了確認テストの導入
品質管理の強化
リリース前の品質チェックリストの作成
定期的な作業手順の見直しと更新
インシデント事例の共有と教育への活用
第1のなぜ、第2のなぜまでは投入したプロンプトの内容を整理しているだけなのでそのまま採用として、第3のなぜが選択式というか問いになっていることがわかります。
ここで回答をしてみます。
第3のなぜに付いて確認をしたところ、作業の二重確認プロセスは定義されていたものの、今回は1人で作業していたとのことで、二重確認が実施されていないことがわかりました。
すぐに第3のなぜが更新されその後の第4のなぜの選択肢が変わりました。
新しい情報をもとに、「なぜなぜ分析」を深めていきましょう。
第3のなぜ(改訂):なぜ作業者は手順を飛ばしてしまったのか?
→ 二重確認プロセスが実施されていなかったため、作業の抜け漏れを事前に発見できなかった
第4のなぜ:なぜ二重確認プロセスが実施されなかったのか?
考えられる要因:
1人での作業を許容してしまった
二重確認の重要性が十分に認識されていなかった
作業者が不足している可能性がある
緊急性や時間的制約があった可能性がある
第5のなぜ:なぜ1人での作業が行われてしまったのか?(以降略)
これに対して調査してみた前提で回答します。
担当者に聞き取り調査をした結果、本当は2人で作業をして二重確認を行う必要性は理解していたのですが、このときは担当者の独断で作業を開始してしまったとのことでした。
これを投入sるとすぐに以下の内容で返ってきます。第4のなぜが更新されて返ってきました。
AIの回答もなんだか本当のエキスパートのようです。
新しい情報により、さらに分析を深めていきましょう。
第4のなぜ(改訂):なぜ担当者は独断で作業を開始してしまったのか?
考えられる要因:
作業完了への焦りがあった
他の担当者の都合を確認・調整する手間を避けたかった
ルール違反の重大性を軽視していた
過去に問題なく作業できた経験から、自信過剰になっていた
コンプライアンス意識が不足していた
(以下省略)
提示された「考えられる要因」をもとに、聞き取りをした前提で回答をしてみます。
第4のなぜに回答するために、さらに担当者を詰問してきました。
・ルール違反やコンプライアンス意識はあった。
・過去にこの作業を実施した経験はなく自信過剰はない
・作業への焦りなはかった
・他の担当者をアサインするためにはマネージャーへの報告が必要との認識
・もうひとりの作業者の欠勤をマネージャーに話すのには躊躇があった
回答が来ました。第4のなぜについては確定した感じの結果になりました。次は第5のなぜに答えてみます。
新しい情報に基づいて、「なぜなぜ分析」をさらに深めていきましょう。
第4のなぜ(改訂):なぜ担当者は独断で作業を開始してしまったのか?
→ マネージャーへの報告を躊躇したため
第5のなぜ:なぜマネージャーへの報告を躊躇したのか?
考えられる要因:
欠勤者が出たことを報告することへの心理的な抵抗
マネージャーとの関係性や心理的安全性の課題
人員不足の状況を報告することへの懸念
作業遅延につながることへの不安
(以下省略)
聞き取った結果をもとにさらにプロンプトを作成します。
今度は1つ1つの問いにそれぞれ回答してみました。
第5のなぜについて更に聞き取りをしました。それぞれの問いについては以下の通りになりました。
欠勤者が出たことを報告することへの心理的な抵抗
→あまり報告することがないので報告することに抵抗があった。マネージャーとの関係性や心理的安全性の課題
→マネージャーとは月に1回位しか話をしない人員不足の状況を報告することへの懸念
→たしかに文句を言うみたいで、どう思われるかは不安だった作業遅延につながることへの不安
→特にその意識はありませんでした
回答が来ました。これで5回のなぜが最後まで終わった状態になりました。
聞き取り結果から、第5のなぜについてさらに深掘りができました。根本的な原因として以下のような構造的な問題が見えてきました:
コミュニケーション頻度の不足
マネージャーとの対話が月1回程度と少ない
日常的なコミュニケーション機会の不足により報告の心理的ハードルが上がっている
報告文化の未成熟
普段から報告する機会が少ないため、報告すること自体に抵抗感がある
問題提起が「文句を言う」ように受け取られるのではという不安がある
推奨される追加対策:
コミュニケーション機会の増加
週次の短時間1on1ミーティングの導入
デイリースタンドアップなど、日常的な状況共有の場の設定
非公式な対話の機会創出
報告プロセスの標準化
日常的な報告の仕組み作り
報告テンプレートの整備
報告すべき事項の明確化
心理的安全性の向上施策
報告は改善のための重要なインプットであることの周知
良い報告の事例共有
建設的なフィードバックの促進
ここまでの聞き取りから、チーム、とくにマネージャーとのコミュニケーションの問題があって、そのために欠員があって二重確認ができない状態であったにも関わらず、エスカレーションをしなかったという構図まで掘り下げられました。
まとめ・感想
実際の人間がなぜなぜ分析をしても、下手をすると「担当者のミス」とか「担当者の意識不足」みたいな表面的な掘り下げに終わりがちなのですが、みごと組織のコミュニケーションの問題にたどりついたのは正直驚きです
少なくとも「なぜなぜ分析」をしっかり勉強したメンバーであれば別ですが、そういう勉強もしていない平均的なメンバーに「なぜなぜ分析」を丸投げするよりは遥かに高いクオリティーかつ、非常に低いコストで行うことができました。
へんな自衛意識みたいなのが邪魔をしないのも利点かもしれません。
ぶっちゃけ電話3本くらいの工数なので2人✕10分✕3回、まとめ30分としても1.5H・人の工数で解決です。5人で1時間のミーティングの1/3のコストです。(実際にはこの機能を使って全員で30分くらいのミーティングをするのが有効だとは思いますが)
いやいやたいしたもんです
いいなと思ったら応援しよう!
