焦りストーリー
焦りマクラー「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 stagnating) find only solution without analysis)
論点があやふや、もしくは、論点が間違っているから、何かしらのギャップが壁になってハマってしまう。仮にその壁を超えたとしてもあまり幸せにはならない。
そう感じる場面が多々ありました。ヘルプが来て、jfluteが分析すると、解決方法は自然と導かれて問題は解決。
すごく感謝されるのですが、jfluteは単に分析をしただけ、そんな感覚。突拍子もない発想力で解決方法を思いついたわけでもなく、ただただ、地味ぃーに現状を整理しただけです。特別な能力は持っていません。
それだけでヘルプが終わることがすごく多いです。jfluteを分析ツールと思っている若者もいるはずです。
論理の迷子にならないために
ということで、
意識的に...
問題分析と問題解決はフェーズを明確に分ける
(Separate phases between problem analysis and problem solving)
ことをオススメします。
多少、アドリブでグチャッとしても、ちゃんとグチャッとしたことを意識していれば、論理の迷子にはなりません。「これは分析」と「これは解決探り」と意識していることが大切。
たぶん、この記事も関係あります。
// 逆にテーブルスキャンもできなきゃね
http://d.hatena.ne.jp/jflute/20150112/tablescan