この記事は自分のブログに書いた記事を早く読めるように短縮したものです。
エンジニアの一日は問題解決の連続です。普段は当たり前すぎて意識していませんが、気にしてみるといかにそうであるかがわかります。
- 落ちたサーバを復旧させる
- 与えられた文字列を正規化するコードを書く
- 関係者全員のスケジュールが合うようにミーティングをセッティングする
優れた解決方法を考えだすには、まず問題を正しく定義しなければいけません。
この記事では問題発見学の名著、「ライトついてますか」 から重要な点を引用して、どのようにすればより良い問題定義ができるかについて書きたいと思います。
**注：**引用が英語なのは原本しか読んでいないからです。"訳："とあるところは自分で翻訳しただけなので日本語版の実際の言い回しとは異なります。
また今回読んだKindle版にはページ情報がなかったので、引用元はページ番号ではなくその引用があった章を代わりに書いています。
問題とは何か？
A problem is a difference between things as desired and things as perceived （３章）
**訳：**問題とはそうあるべき状態と今ある状態の差である
そもそも問題とはなんでしょうか？著者は問題を上記のように定義しています。
問題をこのように定義するといいことがひとつあります。それは、見方を変えることで問題が解決する可能性があることです。
Don't take their solution method for a problem definition （４章）
**訳：**他人の解決方法を問題の定義としてはいけない
人が問題だと言っていることが本当の問題とは限りません。問題の解決方法について相談を受けた時は、本当に解決したいことは何なのかを詳しく聞くことが大事です。
問題を解決する前に
問題がきちんと定義されれば解決することはさほど難しくありません。しかし、ちょっと待ってください。その問題はあなたの問題ですか？本当にあなたが解決しないといけませんか？
まずは、次の質問を自分に問いかけてみましょう。
Whose problem is it? （１１章）
**訳：**誰の問題か？
本当にあなたが解決しなければいけませんか？もし、その問題が誰かの問題ならあなたが解決しようとするべきではありません。
もし、あなたの問題でなければ、頼まれないかぎり何もしないのがベストです。私たちは自分の問題解決に時間に忙しいはずですから。
Where does this problem come from? （１４章）
**訳：**この問題はどこから来たのか？
この問いも問題が本当に自分の問題なのか調べるのに役立ちます。なぜ自分はその問題に直面しているのか？なぜこんなことになったのか？
自分に落ち度があるか？それとも、誰か他人に巻き込まれたか？
Ignoring the problem （３章）
**訳：**問題を無視する
時には問題そのものを無視するのもありです。気づかないふりをしていまいましょう。問題は、あるべき状態と現在の状態の差ですが、
人間はすぐに適応する生き物です。最初はみんな問題だと感じてもいつの間にかそれが当たり前のようになるものです。
考えをやめない
あなたは問題を正しく定義して適切な解答を導き出しました。しかし、まだリラックスはできません。
Each solution is the source of the next problem （７章）
**訳：**あるひとつの解決方法は別の新しい問題を生む
私たちが問題を解決してもリラックスできないのは、その解決方法がまた別の問題を生み出すからです。これはエンジニアは直感的に理解していると思います。
The really important thing in dealing with problems is to know that the question is never answered, but that it doesn't matter, as long as you keep asking （第６章）
**訳：**最も重要なことは問題は解決されることがないと知ることだ。しかし、考えることを止めなければは大したことではない。
無事に解決方法を見つけても、その解決方法が最も正しかったかどうかはわかりません。それどころか、問題定義がそもそも正しくなかったかもしれません。
自分の出した答えが完璧だったと信じることが一番厄介です。なぜなら、完璧な答えなどないからです。だから、私たちは常に問題を振り返って見直さなければいけないのです。