その原因分析、本当にその『問題』を解いていますか？ 答えを考える前に、まずは問いを決めよう！

仕事で問題が起きたとき、原因を探すことから始めていないでしょうか。

「なぜ遅れているんだろう」
「誰の作業で止まっているんだろう」
「やり方を変えた方がいいのではないか」

こうして調べたり話し合ったりしているうちに、話がどんどん広がってしまって、最後には「そもそも何について考えていたんだっけ？」となる。そんな経験は珍しくないと思います。

原因分析の方法を知らないからとは限りません。ロジックツリーやなぜなぜ分析を知っていても、その前に「今回、何を解くのか」が曖昧なら、何を分解するのか、何の原因を探すのかも定まりません。

たとえば、「仕事が遅れている」という状況を見て、すぐに「人手不足ではないか」と考え、「担当者を増やそう」と対策まで進んだとします。

でも、この時点ではまだ、

• 何が遅れているのか

• 本来どうなっているべきなのか

• どのくらい差があるのか

• 人手不足が本当に原因なのか

が分かっていません。

「人手不足」は原因の仮説であり、「担当者を増やす」は解決策の候補です。その前に決めたいのが、今回何を問題として扱うのかです。
ここは時間をかけてでも、しっかり定義しておかないと最終的に方向性を大きく誤ってしまうこともあります。

この記事では、そんな「問題設定」に絞って説明していきたいと思います

前半で考え方を簡単に整理したあと、2つの架空ケースを使います。
ですので、1つ目では問題設定の作り方を見ながら確認し、2つ目では情報が足りない状況からご自分でも少し考えていただければと思います。

目指すのは、問題文の内容ではなく、

「原因や対策を考える前に、まず今回何を解くのか整理してみよう」

と、自分で一度立ち止まって考えることの必要性と、その問題を定義する流れを理解いただければと思います。

1. 原因を考える前に、「問題」を分けて考える

まず押さえておきたいのは、「問題」という言葉の中に、いろいろなものを混ぜないことです。

この記事では、次の4つを分けて考えます。

たとえば、「締切を超えている仕事がある」は、確認できている現象にあたります。

そこから「情報共有が遅いことが原因だ」と考えたとしても、事実情報を確認できていなければ、それはまだ原因仮説です。そして「入力項目を減らそう」は解決策です。

どれも仕事を進めるうえでは必要な情報ですが、同じものではありません。

特に注意したいのは、原因らしい事象が見つかると、それをそのまま「問題」と呼んでしまうことです。

「情報共有が悪いのが問題だ」
「人手不足が問題だ」
「フォーマットが複雑なのが問題だ」

こうした表現は、すでに原因を決めてしまっている可能性があります。

では、原因を決める前に、何を確認すれば「今回の問題」を置けるのでしょうか。

2. 問題を7つの順番で整理してみる

この記事では、問題を考えるときに、まず今の状態と目指す状態（あるべき状態）を比べるところから問題を定義していきます。

考える順番は次の7つです。

1. 今、何が起きているか

まずは、確認できている事実です。「○○が悪いと思う」ではなく、実際に何が起きているのかを確認します。

2. 本来、どうなっていたいか

次に、目指す状態を確認します。期限や基準があるなら、それが比較対象になります。

3. どんな差があるか

「本来こうなっていたい」と「実際はこうなっている」を比べます。この差が、問題を考える材料になります。

4. 今回はどこまで扱うか

困りごと全体を「問題」としてしまうと、分析対象が広すぎることがあります。一方、根拠がないのに細かく絞りすぎれば、まだ分かっていないことまで決めつけることになります。

そのため、現時点で確認できている情報から言える範囲にいったん区切ります。

5. 原因として確認できていることはあるか

「たぶん○○だ」は、まだ原因仮説かもしれません。確認できていないなら、問題設定の中で原因として断定しないようにしましょう。

6. まだ何が分からないのか

分からないことを無理に埋める必要はありません。「ここから先は分からない」と明確に区分しておくことが大事です。事実と推測、あるいは想像が混在しないようにしましょう。

7. 現時点の問題を一度、言葉にする

ここまで整理したら、確認できている情報を使って「今回は何を問題として扱うのか」を一度設定してみます。

そのうえで、原因分析へ進めるのか、その前にもう少し追加情報が必要なのかを判断します。

ここまで読んでも、まだ少し抽象的だと思います。

ですので、ここからは具体的なケースを使います。最初は問題設定の作り方を見るためのケースです。すべて自力で解こうとせず、「何を問題に入れて、何を入れないのか」に注目してください。

3. ケース1：週次会議資料の共有遅れ

※以下は架空ケースです）

あなたは、週次会議に参加しているチームメンバーです。チームリーダーから、「すぐに対策を決める前に、まず何が問題なのか整理してほしい」と求められています。

チームでは毎週火曜日の10時から進捗会議を行い、会議資料は前日の月曜日15時までに共有することになっています。

直近6回を確認すると、期限までに共有できたのは2回、期限を超えたのは4回でした。ただし、期限を超えた4回も、資料自体は火曜日10時の会議開始前には共有されています。

さらに、チームでは「入力項目が多い」という意見も出ており、リーダーからは「フォーマットを簡単にしてはどうか」という案も出ています。

期限超過は6回中4回なので、66.7％です。

ここで注目したいのは、「どれが事実で、どこからがまだ推測なのか」です。

まず、目標は「月曜日15時までに資料を共有すること」。現状は「直近6回のうち4回で、その期限を超えていること」です。ここまでは確認できています。

では、次のように問題を設定してよいでしょうか。

一見もっともらしく見えますが、「入力項目が多い」という意見が出ていることと、それが遅れの原因であることは別です。まだ確認していない原因を、問題設定の中に入れてしまっています。

では、

ならどうでしょうか。

これだと解決策になってしまいます。「何が問題か」を決める前に、「どう直すか」を決めているのです。

そこで一度、原因の推測と解決策を外します。残すのは、今確認できている対象・目標・現状・範囲です。

すると、たとえば次のように整理できます。

これが唯一の言い方というわけではないです。

大切なのは、「入力項目が多いから」「フォーマットを変えるべき」といった未確認の原因や解決策を入れず、今分かっている範囲で問題を置いていることです。

もう一つ注意したいのは、「会議までに資料が間に合っていない」とも書いていない点です。期限を超えた4回も、火曜日10時の会議開始前には共有されています。

事実はあくまで、月曜日15時という共有期限を超えていることです。

では、この次に何をするか。

原因を調べるなら、どの工程で時間がかかっているのか、特定の担当者や項目に偏っているのか、作成開始が遅いのか、必要な情報が揃うのが遅いのか、といった追加情報を確認する余地があります。

ただし、現時点ではどれが原因かは分かりません。

このケースでは、まずここまで整理したうえで、リーダーに「この問題設定で原因分析へ進むか、それとも先に追加情報を確認するか」を判断してもらうことになるでしょう。

ケース1では、目標と現状が比較的はっきりした状況で、問題から原因仮説と解決策を外すところを確認しました。

次は、もう少し情報が曖昧なケースです。今度は整理例を見るだけではなく、どこまで問題と言えるかを実際に考えてみてください。

4. ケース2：情報が足りないとき、どこまでを問題と言えるのか

あなたは、社内問い合わせを担当するチームのメンバーです。3営業日後の業務改善ミーティングに向けて、上司から「対策を考える前に、何を問題として扱うべきか整理してほしい」と求められています。

チームでは、問い合わせを受け付けてから2営業日以内に最初の回答を返すことを目標にしています。

最近の状況は次のとおりです。

今月は、担当メンバーの1人が3営業日不在でした。また、「最近は問い合わせ内容が難しくなったのではないか」「FAQを増やした方がよいのではないか」という意見も出ています。

ここで、一度考えてみてください。

現時点で確実に言えることは何でしょうか。そして、まだ言えないことは何でしょうか。

見るポイントは7つです。

• 今、数字から確認できる変化は何か

• 目標と現状にはどんな差があるか

• 「問い合わせ内容が難しくなった」は事実か仮説か

• 担当者の不在を原因として確定できるか

• FAQ追加は問題なのか、解決策なのか

• 今ある情報で、どこまで問題を置けるか

• さらに絞るなら何を確認する必要があるか

自分なりに一度考えてから、続きを見てみましょう。

今分かっていることと、分からないことを分ける

確実に言えるのは、今月は54件中17件、31.5％が2営業日の目標を超えたことです。

過去3か月の超過率は10.0％、11.5％、8.2％なので、今月の31.5％はそれぞれを上回っています。

一方で、「問い合わせが難しくなったから遅れた」とはまだ言えません。そういう意見が出たことは事実ですが、本当に問い合わせ内容が以前より難しくなったかは確認できていないからです。

担当者が3営業日不在だったことも同じです。不在したことは事実ですが、それが回答遅れの原因だったかは分かりません。

FAQを増やす案についても、現時点では解決策の候補です。

そのため、問題設定の一例としては、

と設定することができます。

ここでも重要なのは、文章を完全に一致させることではありません。

確認できている事実に基づき、未確認の原因や解決策を混ぜていないか。

それを見ます。

さらに原因を絞り込むなら、まだ確認したい情報があります。17件の問い合わせ内容、担当者別の偏り、実際の遅延日数、どの工程で待っているのか、他部署への確認待ちがあるのか、といった情報です。

問い合わせが本当に難しくなったのか、不在がどの程度影響したのかも、まだ分かりません。

つまり、情報不足だから何もできないわけではありません。今回のケースのように、現在確認できている範囲で問題を置き、その先は「まだ分からないこと」として切り分けられる場合があります。

上司には、現時点の範囲で原因分析へ進むのか、追加情報を確認してから問題をさらに絞るのか、どの情報を優先して確認するのかを判断してもらいます。

ここまでで、

ケース1では作り方を見て、ケース2では自分で考える

ところまで進みました。

最後は、この考え方を自分の仕事に移してみます。

5. 自分の仕事で問題を整理してみる

今、仕事の中で「何とかしたい」と感じていることを一つ思い浮かべてください。

ここからは、以下の9つの問いをポイントとして整理します。

1. 今、実際に何が起きているのか？

推測ではなく、確認できている状態や出来事を書きます。

2. 本来、どうなっていたいのか？

期限や基準など、現状と比較できる目標を確認します。

3. 現状と目指す状態には、どんな差があるのか？

何が満たせていないのかを整理します。

4. 今回は、どこまでを扱うのか？

困りごと全体ではなく、今確認できている範囲で今回分析する対象を決めます。

5. 原因として確認できていることはあるのか？

「原因だと思うこと」と「原因だと確認できたこと」を分けます。

6. まだ分かっていないことは何なのか？

判断に必要なのに未確認の情報を書き出します。

7. すでに考えている解決策はあるのか？

案があるなら一度分けて書いてみて、問題そのものと混ざっていないかを明確にします。

8. 現時点で、「今回解く問題」をどう表現するのか？

現状・目標・差・今回扱う範囲を使って、一度文章にします。

9. 次に何を確認・分析するのか？

この問題設定で原因分析へ進むのか、先に不足情報を確認するのかを決めます。

9問すべてを立派な文章で埋める必要はありません。

目的は、きれいな資料を作ることではなく、自分の頭の中で「事実」「原因の推測」「解決策」が混ざっていないかを確認することです。

6. 原因分析へ進む前のチェックリスト

最後に、作った問題設定を確認してみてください。

• □ 確認できている事実から始めている

• □ 本来どうなっていたいかが分かる

• □ 現状と目指す状態の差が分かる

• □ まだ確認していない原因を決めつけていない

• □ 解決策を問題そのものにしていない

• □ 何を分析すればよいか分からないほど範囲を広げていない

• □ 根拠がないのに特定の原因や対象へ絞り込んでいない

• □ まだ分からない情報を分けている

• □ 次に「追加確認」か「原因分析」のどちらへ進むか考えられる

全部にYESでなければ失敗、というものではありません。

NOになったところがあれば、そこを見直せばよいだけです。

問題が起きると、どうしても「なぜ？」や「どう直す？」へ意識が向きます。しかし、その前に一度だけ、

「そもそも、自分はいま何を解こうとしているのか？」

を確認してみてください。

今回のケースのように、原因がまだ分からなくても、確認できている事実から問題を置ける場合があります。逆に、原因らしいものが見えていても、それがまだ仮説なら、いったん問題から分けておく方が整理しやすくなります。

問題を設定できたら、その次に問題を分解したり、原因を深掘りしたりします。

問題を分解して整理したい場合は、ロジックツリーの記事へ。

原因を深掘りしたい場合は、なぜなぜ分析の記事へ。

まずは一つ、今抱えている困りごとを選んで、9つの問いのうち「今何が起きているか」と「本来どうなっていたいか」から書き出してみてください。

問題設定を明確にするだけでも格段に仕事はやりやすくなります。
ぜひ試してみてください！

最後までお読みいただき、ありがとうございます。 この記事が役に立った！と感じたら、ぜひ「スキ」（ハートマーク）を押していただけると励みになります。