MASTER / ANALYSIS & THINKING
問題の本質を見つける
目先の対症療法で終わらせないために、問題の定義、原因候補の分解、検証、対策の選択を、問い合わせ増加のケースで学びます。
問い合わせ総数(1
+30%
ログイン関連(200件→500件)
+300件
その他(800件→800件)
±0件
約30分基礎〜発展演習 4問講義をはじめる
※ 本レッスンの学習サービス「StudyFlow」と、問い合わせ件数などの数値は、教材用の架空の例です。実在のサービスの実績ではありません。
この講義でできるようになること
- 現状と望ましい状態の差として、問題を定義できる
- 症状と原因を分け、複数の原因が重なり得ることを踏まえて分解できる
- 影響の大きさと変えられる範囲で、対策の優先順位を考えられる
- 緊急の暫定対処と、再発防止を分けて整理できる
00:00 / 11:45
1第1章導入:問い合わせが増えたから人を増やす?
Space 再生/停止・← → 10秒移動・N / P で章を移動・C で字幕。右の「文字で読む」で、話している内容を文字で追えます。
演習:手を動かして確かめる
講義を見終えたら取り組みましょう。入力した内容はこの画面の中で使うだけで、どこにも送信されません。
問い合わせ総数の増加率、ログイン関連の増えた件数、ログイン関連の増加率を求めてください。
問題の本質を探る確認リスト
- 現状・望ましい状態・差・影響・期限を、具体的に書いたか
- 総数だけでなく、種別・日時・対象などに分解して見たか
- 原因は一つと決めつけず、複数の候補と確かめるデータを挙げたか
- 事業への影響が大きく、自分たちが変えられる原因を選んだか
- 緊急の暫定対処と、再発防止を分けたか
- 更新などの出来事を、検証の前に原因と断定していないか
次に学ぶなら
テキストで読む(文字起こし)
第1章 導入:問い合わせが増えたから人を増やす?
問い合わせが急増したときすぐに人員を増やすべきでしょうか 忙しい現場では自然な判断です しかし問い合わせが増えた原因が分かりにくい案内やシステムの不具合だったなら 増員だけでは根本的な改善にならないかもしれません 問題の本質を見つけるとは見えている症状と原因を分け 何を変えれば望ましい状態に近づくかを確かめることです 演習です 問い合わせが多いことの何が困るのかを具体的にしてみてください 動画を止めて考えてみましょう 例えば回答が遅れること 顧客が離れてしまうこと 担当者の負荷が増えることなどです
第2章 問題を定義する:現状と望ましい状態の差
問題があると感じたらまず基準を確認します 問題は現在の状態と目標期待する状態の差として捉えることができます 例えば返信が遅いだけではどれくらい遅くどの顧客が困り いつまでに何を達成したいのかが分かりません 平日の初回返信に平均24時間かかっている 顧客への案内目標は8時間以内というように定義すれば 改善の方向が明確になります ここで理想を高く置けば問題は増えることも意識してください 目標が事業上妥当か誰にとって価値があるかを確かめます 指標だけを改善しても顧客の困りごとが変わらなければ本末転倒です 演習です 会議が長いという問題を現状望ましい状態 その差、影響、期限の5つの項目で定義し直してみてください 動画を止めて考えてみましょう 回答の一例です 今の会議がどれくらいの長さか、どれくらいにしたいのか その差はどれくらいか 長いことで誰にどんな影響があるのか そしていつまでに変えたいのかを書きます
第3章 症状と原因:なぜを繰り返す前に分解する
原因を調べる有名な方法になぜを繰り返す考え方があります ただしなぜを5回言えば必ず真因に到達するわけではありません 同じ現象に複数の原因が重なることがあるからです 例えば問い合わせが増えた理由は利用者数の増加 特定画面のエラー、ヘルプページの見つけにくさ 案内文の曖昧さなどが同時に存在し得ます まず、件数を問い合わせ種別、発生日時、対象サービス、顧客属性などで分解します その上で、因果関係の候補を図にし、どの証拠で確かめるか決めます ワークです! ミスが多いという問題の原因を 人、手順、情報、環境の4つの観点で挙げてみてください 動画を止めて考えてみましょう 4つの観点に分けて挙げられたでしょうか 大切なのは個人の資質のせいだと決めつけないことです
第4章 優先順位:影響と変えられる範囲
問題の本質は必ずしも最も深い原因とは限りません 事業上大きな影響があり 自分たちが変えられる原因を見つけることが重要です 例えば市場環境の変化をすぐ止めることはできません しかしその変化を早期に検知する仕組みや 顧客への説明方法は改善できるかもしれません 打ち手を選ぶときは、影響度、実行可能性、必要な時間、副作用を比較します すべてを一気に直すのではなく、現場への影響が小さく、根拠があり、 検証しやすいところから着手するのが合理的です また、原因を完全に特定してからでないと動けないというわけでもありません 障害のような緊急事態では 暫定対処と原因調査を並行します 小さな演習です FAQの案内の改善 担当者の増員 システムの修正 この3つの役割を分けてみてください 動画を止めて考えてみましょう 分け方の一例です 担当者の増員とFAQの案内の改善は 今起きている被害を減らす応急処置です システムの修正は発生源を減らす再発防止です
第5章 ケース:StudyFlowで問い合わせが30%増加
今月の問い合わせが1000件から1300件へ30%増えました 総件数だけ見ると人員が足りないという話になりそうです しかし内訳を見るとログイン関連だけが200件から500件へ増え その他は800件のままです ここでログイン関連に絞って調べるのは合理的です ただし更新があったから必ず更新が原因とは言えません エラー率、問い合わせ文面、更新前後の環境差を確認します 緊急の顧客対応として案内を追加する一方 認証画面の不具合の有無を検証します もし認証画面が原因なら修正後に問い合わせ率が下がるはずです 問題を問い合わせ30%増からログイン関連問い合わせが300件増加に具体化すると 調査も打ち手も変わります ワークです 症状、有力な原因の仮説、検証するデータ、短期の対策、 再発防止策の5つを書いてみてください 動画を止めて考えてみましょう 回答の一例です 症状は、総数が300件増えたこと 有力な原因の仮説は、ログインの動線に問題があること 検証するデータは、エラーログ、リリースの履歴、問い合わせの内容、端末別の傾向です 短期の対策は、すでに分かっている回避の手順を案内すること 再発防止策は不具合の修正、リリースの監視、事前テストの強化です ただし、現段階では原因が確定したとは書かないようにしましょう
第6章 まとめとコース総復習
このコースで学んだ4つをつなげましょう 第1に問い・結論・根拠・前提の筋道を確かめる 第2に事実・意見・推測を分ける 第3に仮説を検証できる形にする 第4に症状と原因を区別し 影響の大きい改善から進める 答えを急がないことは 意思決定が遅いことではありません 判断に必要な情報を絞り、手戻りを減らすための技術です 最後の、演習です 身近な業務課題を一つ選び、問題の定義、確かめた事実、原因仮説、検証方法、 暫定策の5行で書いてみてください 動画を止めて取り組んでみましょう 続いて、確認問題です ある画面を更新した後に問い合わせが増えた この時最も適切な判断は何でしょうか 動画を止めて考えてみましょう 更新は原因の候補ですがログや問い合わせの内訳で検証します 必要であれば暫定的な対応も同時に進めます
