こんにちわ。組織開発がミッションの人事グループ・組織開発室に所属しているてぃーびーです。
利用者からのシステムへの問題提起。チームのふりかえりのミーティングで寄せられた仕事の進め方に関する問題提起。部門横断の活動に関わる問題提起。
仕事において、大小さまざまな問題が存在します。そして、誰かが問題提起をしてくれた場合、その問題の解決に向けてすぐに取り組むことがベストとは限りません。問題を解決していく前に、問題の明確化が必要なケースがあるためです。
この記事では、「問題の明確化」に関する全体像を説明します。
問題の明確化の全体像
誰かが解決したほうがよいと考える問題があった場合、すぐに解決策の検討にとりかかることができる場合もあれば、事前に「問題の明確化」が必要なケースもあります。
典型的なパターンを図にすると以下のようになります。(以降、図を拡大してみたい場合は、図をクリックしてください)
そのうち、事前に「問題の明確化」が必要なケースは以下の部分です。
システム開発との対比
「問題提起」と「解決策」の内容に関するここまでの話は、システム開発における「ニーズ」と「実現方法」の関係に通ずるところがあります。
システムのニーズが曖昧な状態で提示されたり、ニーズが何かわからない状態で実現方法のみを提案されているとして、そのまま開発を開始しているような状態を想像してみてください。このようなことを繰り返していると、そのシステムは価値を生み出さないような機能で溢れかえってしまうことになりますし、本来は価値を生むために必要だった時間を浪費してしまうことになります。
極端な例を2つ考えてみると
- 「システムが使いにくいから使いやすくしてください」という要望を受け、その要望を掘り下げることなく、推測だけで実装に着手しているような状態
- 「ユーザー一覧画面がバグっている」という情報を元に、バグの原因や正しく動作している場合の仕様を調べることなく、思いつきの解決策で実装に着手しているような状態
のようなものです。これらと同じことが、問題の解決に関しても起こり得えるということです。システム開発において、このような選択肢をとるケースは少ないと思いますが、ひとたび開発外の問題を取り扱うとなると無意識にこれらの選択肢を選ぶということは珍しくありません。
不明確な問題の影響
不明確な問題には、大きく分けて2つのマイナス影響があります。
1 - 問題にマッチしない解決策を選ぶ可能性が高まる
問題が不明確だと、問題に合わない解決策を選ぶ可能性が高まります。結果として、
- 本来解決したい問題を解決できない解決策を選ぶ
- 理想の解決策よりも効果が薄い解決策を選ぶ
- 理想の解決策よりも時間がかかる解決策を選ぶ
- 理想の解決策よりもコストがかかる解決策を選ぶ
という可能性があります。
2 - 取り組む重要度が低い問題の解決に時間を使う可能性がある
問題が不明確だと、取り組む重要度が低い問題の解決に時間を使う可能性が高まります。結果として、
- 本来は単なる勘違いで解決する必要がない問題の解決に時間を使う
- 解決したら利益はあるが、重要度を考えると優先して対応する必要がない問題の解決にすぐ取り組んでしまう
という可能性があります。
問題の明確化が必要な個別ケースについて
問題の明確化が必要な3つのケースに関する詳細は以下を確認ください。
まとめ
「問題の明確化」に関する全体像を説明しました。
冒頭でも触れましたが、仕事には大小さまざまな問題が存在します。人によって取り扱う問題の大小は異なると思いますが、手順書に基づいた定型業務だけを担当しているのでなければ、多くの人は日常的に問題を取り扱うことになります。
問題の取り扱いについて、ふりかえる機会を用意し、明確化が必要な場面の判別と明確化の対応ができているか確認してみるとよいでしょう。