jfluteの日記 このページをアンテナに追加

2017-07-12

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

|

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

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

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

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

実は...

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

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

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

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

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

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

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

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

...

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

理由、その一

仮説を当てずっぽうにしないため

まずはこれ。

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

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

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

理由、その二

解決方法の選択肢を洗い出すため

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

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

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

理由、その三

解決方法の選択を誤らないようにするため

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

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

理由、その四

その解決方法に論理的説得力を備えるため

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

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

...

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

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

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

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

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

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

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

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

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

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

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

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

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

あくまで...

分析のために、
解決方法にフォーカスを当てている

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

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

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

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

一方で...

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

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

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

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

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

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

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

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

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

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

いわゆる "ハマっている" 人の多くは、
分析し切れてないのに、
必死に解決方法だけを探っている

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

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

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

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

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

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

問題分析と問題解決はフェーズを明確に分ける

ことをオススメします。

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

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

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

f:id:jflute:20170529170024j:image
トラックバック - http://d.hatena.ne.jp/jflute/20170712/analysissolving