問題分析と問題解決を分けることがハマらない第一歩

焦りストーリー

焦りマクラー「Sが動かない!(or Sを実現したい)」
jflute「ふむ、したらそれってもともとは...(質問しようと)」

焦りマクラー「Aで動きますかね?(質問を遮る)」
jflute「いやぁ今のところそう言い切れないような」
jflute (ふむ、例外見ると落ちた元ネタはこうか)

焦りマクラー「じゃあ、Bで動きますかね?」
jflute「Bは動きそうだけど一概にそれでいいかは...」
jflute (ふむ、業務的にはこういうことが求められてて)

焦りマクラー「Cならいいんじゃ!? Cってどうしたらできます?」
jflute「本当にC前提で話を進めちゃっていいの?」
jflute (ふむ、この状況からするとBに加えてDが必要そうだな)

実は...

ある程度の分析をするまで、
解決方法には興味がありません。

(No interesting about solution until I can get analysis)

分析まで解決方法に興味なし

焦りマクラー「なんてKYなやつなんだ、問題が出てるのに解決方法に興味がないとは!」

分析のない解決方法は、当てずっぽうでしかないからです。でも、KYであることは正しいです。あれこれ解決方法のことを言われてても、そっけなく分析を進めてたりしますから(^^。

焦りマクラー「jfluteさんは、仮説思考大事とか言ってるじゃないか!」

// My Favorite Book: 仮説思考
http://d.hatena.ne.jp/jflute/20150111/kasetsu

仮説思考って、当てずっぽうじゃないですよ。いま知り得る情報を分析した上で仮説を探して、次の検証と分析を行い、また仮説...の繰り返しで、最終的に思考のフレームワークです。

初っぱないきなり何の根拠もなく、「Aだうおー」と突き進むのは、少なくとも効率の良い仮説思考とは言えません。(そういう状況が必要になることもあるかもしれませんが、それはそれで分析なしでOKであることを分析してのこと)

...

焦りマクラー「そもそも、なんで分析しないといけないんだ?そんなもの要らないじゃないか!?」

理由、その一

仮説を当てずっぽうにしないため
(Not to make hypothesis gamble)

まずはこれ。

もともと "しらみつぶし方式" では効率がわるいから、仮説思考というフレームワークがあるわけです。

効率の良い仮説検証サイクルを繰り返し、できるだけ最短の距離で答えに辿り着くためには、それぞれの仮説から出た検証結果をしっかり分析し、次の仮説(or 答え)を導くわけです。

だから、実際には..."仮説・検証・分析サイクル" かもね。

理由、その二

解決方法の選択肢を洗い出すため
(To clarify options of solution)

何が起きたのか?根本的に何が求められているのか?ちゃんと分析しないと、選択肢が洗い出せません。

AとBしか見えてない中で、A or B でどっちかを選んでも、実は本当は C が良かったということになってしまいます。

他の選択肢を探すためには、やみくもに選択肢を探すのではなく分析をすることです。状況がわかれば選択肢は自然と導かれやすいものです。

理由、その三

解決方法の選択を誤らないようにするため
(Not to select wrong solution)

A or B or C, どれがいい?って、状況が把握できてなければわかるわけがない。

というか、状況が把握できたとしても難しいのに、わからない状態で "Aだ!" と言ってもほぼギャンブルです。

理由、その四

その解決方法に論理的説得力を備えるため
(To make solution persuasive)

仮に C が最適であるとしても、そこに "Cまでの明確な道筋" が説明できないと、C でやることの政治的な了承を得ることが難しい。

その解決方法をしっかりデビューさせるためにも、"ちゃんと選ばれてきたんだ" という論理ブランドを授けてあげましょうよと。

...

仮に、"Cまでの明確な道筋" が曖昧のままでも、いまの関係者が C で OK だよって言ってくれたとしても、数年後のエンジニアに...
「なにこれ、なんでCでやってんの?意味わかんない」
「バカだったんだな、昔これ作った人」
「Aに変えちゃおう。Aがいいに決まってんじゃんよ」
って言われてしまうかもしれません。

もし、"明確な状況からCまでの道筋" が明確であれば...
「なるほど、Cじゃなきゃダメなんだな」
「良かったぁ、Aに変えてたらあるケースで事故ってた」
と、未然に事故を防げるかもしれません。

また...
「なるほど、昔はCじゃなきゃダメなんだな」
「ただまあ状況は変わったのでいまはAだな、変えよう」
「昔は昔でそういう事情があったんだな」
という判断が伝えられるかもしれません。

逆に、そういう論理が存在しないと...
「なんで、Cなんだろー」
「Aにしたいけど、不安だ...何かあるかもしれない」
「怖いからCのままで」
と将来の人たちの判断の妨げにもなってしまいます。

なんで A なのか?なんで C なのか?それが厳密に正しいかどうかは、ある意味では二の次です。そこに辿り着いた論理が存在すること自体が大事なのです。

解決方法には真摯な気持ちを

って考えると、実は解決方法にめっちゃ興味のある人に思えません?しっかりとした分析もせず解決方法を曖昧に議論して、なんとなく対応してやり過ごすのは、逆に "解決方法" 様に対して失礼にすら思えてきます。

仮に解決方法の選択を誤っても、それっぽく先に進むことができるケースは多いです。だからこそ、分析を軽視しがちなのかもしれません。でも、何かしら効率性やレアケースへの対応などを、失っている可能性があるわけです。

その選択が誤っていること自体に、ずっと気付けないかもしれません。

解決方法からヒントを得ることも

もちろん、判明している解決方法から、分析の糸口をつかむこともあります。

解決方法というのは、背景となる問題を持っているので、それをヒントに状況を把握するというのは、人間の常套手段です。

でもそれは非常に高度です。それがあるから、解決方法に捕われやすいのかもしれません。

あくまで...

分析のために、解決方法にフォーカスを当てている
(Focus solution to analyze)

その感覚がないと、フォーカスが移った瞬間に迷子です。

時間がなければないなりの

もちろん、緊急リリースとか、切羽詰まっているとかであれば、分析する時間があまりないかもしれません。

それならそれで、限られた時間の中で分析して、その限られた分析結果から判断をするだけです。淡々と。

一方で...

「時間がないから分析をしなくても許される」なんかそんな安心を持ったりしませんでしょうか?

誰が許すのでしょうか?許してもらえたら正解という結果をくれるのでしょうか?いや、論理の神様は、論理の分だけの結果しかくれません。
人間の都合など、どうでもいいから。

時間がないから分析をしなくても責任を回避できるだけです。別に問題は解決しません。

月並みの言葉: 焦りは禁物

優秀な方でも、このパターンに陥ってしまうことがあります。それを引き起こすのは "焦り" です。

人間焦っていると、できるだけゴールに近いところにいたい欲求が生まれます。解決しないといけないプレッシャーが強いのに、「解決方法のことを考えない」なんて精神状態になれないわけです。

でもそれが罠。
その本能が判断を鈍らせるわけです。

jfluteも、その罠にハマりそうになります。そのときは意図的に...「あっ、俺いまゴールに近づきたがってるな。心が目先の安心を得ようとしてる、不安がってる」って自分の精神状態を把握して、集中力を高めてその欲求を抑えようとします。

ハマらないためのポイント

jfluteが、フォローイングの中でよく感じたこと。

いわゆる "ハマっている" 人の多くは、分析し切れてないのに、必死に解決方法だけを探っている
(Many of people who is HAMA (in trouble and addicted) find only solution without analysis)

論点があやふや、もしくは、論点が間違っているから、何かしらのギャップが壁になってハマってしまう。仮にその壁を超えたとしてもあまり幸せにはならない。

そう感じる場面が多々ありました。ヘルプが来て、jfluteが分析すると、解決方法は自然と導かれて問題は解決。

すごく感謝されるのですが、jfluteは単に分析をしただけ、そんな感覚。突拍子もない発想力で解決方法を思いついたわけでもなく、ただただ、地味ぃーに現状を整理しただけです。特別な能力は持っていません。

それだけでヘルプが終わることがすごく多いです。jfluteを分析ツールと思っている若者もいるはずです。

論理の迷子にならないために

ということで、
意識的に...

問題分析と問題解決はフェーズを明確に分ける
(Separate phases between problem analysis and problem solving)

ことをオススメします。

多少、アドリブでグチャッとしても、ちゃんとグチャッとしたことを意識していれば、論理の迷子にはなりません。「これは分析」と「これは解決探り」と意識していることが大切。

たぶん、この記事も関係あります。

// 逆にテーブルスキャンもできなきゃね
http://d.hatena.ne.jp/jflute/20150112/tablescan