問題を定義してから解決策

2022.06.01
こんにちわ。従業員体験( EX ) の向上がミッションのエンジニアリング統括室に所属しているてぃーびーです。
仕事は大小様々あれど、基本は問題解決です。何らかの理想状態と現状にギャップがあり、それを解決していく活動です。
問題解決において、問題を定義してから解決策の検討に進むことが重要です。なぜ重要化か、問題解決とは何かを整理し、そのプロセスを整理した上で、問題定義をスキップした際の影響をまとめます。

問題解決とは?

問題解決とは理想と現状の差であるギャップを問題として捉え、それを解決するまでの活動全体です。
問題解決という名称から解決する部分のみを想像される場合もありますが、問題を明確にする部分も含みます。

問題解決の構造

問題解決の構造について整理します。

理想と現実

問題は、理想と現実のギャップです。
問題というとマイナスのイメージがあるかもしれませんが、
  • マイナスの現状からプラスマイナスゼロの状態にする
  • プラスマイナスゼロの現状からプラスの状態にする
のどちらもありえます。

問題解決の構成要素

問題解決に関わる要素として以下のようなものがあります。

要因

要因問題を発生させている個別の要素です。1〜N個あります。
問題と要因を整理する段階を問題定義と呼びます。

解決策

解決策問題を解決するための施策です。1〜N個起案し、その中から1つずつ試していくことになります。
解決策が明らかに1つに絞れそうなら1つのみのこともあります。

アクション

アクションとは、解決策を実施に移す際に必要となる個々の行動です。短いものだと個人タスクのチェックリストで表現するようなものであり、長いものではマイルストーンをおきつつ取り組むような場合もあります。

想定結果

想定結果とは解決策によって問題が理想状態に至った、と考えられる結果です。
仮に、ここで想定される結果に至らない場合は
  • 次の施策を検討して再度アクションに移す
  • 諦める意思決定をする
のどちらかを選ぶことになります。

問題解決のプロセス

問題解決は、以下のようなプロセスですすみます。
  1. 取り組む対象となる問題を選ぶ
  2. 問題定義
    1. 理想を明確にする
    2. 現状を明確にする
    3. 差から問題が明らかになる
    4. 問題を引き起こしている要因を整理する
  3. 解決
    1. 解決策を1〜N個立案する
    2. 解決策を選定する
    3. 解決策をアクションに分割する
    4. アクションを実施する
  4. 解決確認
    1. 結果が理想状態に至ったか確認する
    2. 解決の場合
      1. 終了
    3. 未解決の場合の選択肢
      1. 別の解決策を立案・実施
      2. 諦めて対応を打ち切る
1 の「取り組む対象となる問題を選ぶ」についてですが、場のテーマによっては最初から明確に1つの問題に絞った話の場合と、複数の問題が混ざりあった話の場合があります。複数混ざり合っている場合、まずはどれを扱うのかを決める必要がある、という意味になります。

問題定義を飛ばして解決策を検討する影響

ようやく前提が整い本題です。
問題定義を飛ばして解決策を検討するとき、以下のような影響が考えられます。

ゴールが不明確な取り組みになる

問題を定義しないで行う解決策はゴールが存在しません。
存在しない問題や曖昧な問題に対する解決策を作ってしまうことになり、大きな成果にはつながりにくい面があります。
たまたま当てずっぽうの施策が好ましい影響を与えることもありますが、あくまでたまたまです。

取り組む必要がない対象に時間を使う

問題を定義しないで行う解決策は、本来解決が不要な対象に対するものになる可能性があります。
例えば、話していく中で結局その問題は扱わない事になった場合、解決策の検討に使った時間が無駄になります。

例外

問題を整理するまでもなく、理想状態・現状とそのギャップが明らかな場合はすぐに解決策の検討に入っても問題ありません。
ただ、これは最初から問題定義ができている、ということであり、問題定義が不要ということではありません。

まとめ

問題定義を飛ばして解決策の検討に進めることの影響についてまとめました。
仕事は問題解決の連続であり、問題解決は問題を発見し、定義し、それを解決していく取り組みです。
そこで、問題を定義する前に解決することは、存在しない問題や曖昧な問題に対する解決策に時間を使うことになります。
こうまとめてみると当たり前ではあるのですが、現実世界では
  • ミーティングで複数の人が集まって問題に向き合う際に問題を定義する前に解決策に話が進んでしまう
  • 業務の依頼のやりとりで前提となる問題に関する情報の共有がなく、アクションの一部のみを依頼している。いざ確認してみると問題があいまい
  • 社外から便利そうな解決策の How を仕入れて、自社の問題の存在を確認せず適用する
というように、問題の定義を飛ばしてしまうケースは珍しくありません。
今取り扱っている対象の問題の定義を意識しつつやりとりできると本当に効果のある活動に時間を使えるようになります。

関連情報