問題解決よりも問題定義に携わりたい

自分の志向と適性は問題定義らしい

ここを数週間深堀りしていて、ありきたりだけどこの言葉に

比較

問題解決：設定された問題を解決することに注力。問題は疑わない

問題定義：問題を設定することに注力。疑う

問題解決マンが集まるチーム

顧客や上司が言っているタスクをいかにして解くかを考える

問題定義マンな僕

そもそも真の問題は何かを考えるところから始める

顧客や上司の意見は情報の一つでしかない

し、経験的にたっぷり時間使って頭手足動かして深堀りする僕らの方が詳しくなるのは当たり前

sta.icon

問題定義こそ必要と思うんだが、現状空白なんだよなぁ

立場上、

現場は問題解決ばかりやらされるし、当事者たちも解決の視座しか持ってない

仕事を与える側は問題定義の視座に立ってるけど、忙しくてマルチタスクでかけてる時間と思考がしょぼいので定義も甘い

この二つだけだと問題定義を深堀りしていけない

無論、あらゆる組織がこうなってるわけではなくて、うまいR&Dや出島であればこの程度はできてるだろう

だからこそもっと身近にしていきたさ

sta.icon

この構図をほぐすソリューションはいくつかある、というかつくれる

意思決定層が（問題定義は素人のくせに）なぜか抱える構図になってるから、ぶんどらないといけない

ただし、ぶんどったところで、じゃあどうやってやるの問題がある

「問題定義エンジニアリング」なるものが未開拓なのも事実なので、整備が急務

といっても使えそうな理論や事例は山ほど転がってる（が、これらを整備して一つのエンジニアリングに仕上げないと誰も使えない）

俺ならつくれるけど、さすがに本業しながらはきついので専任にならねば……

趣味だと人巻き込んで検証する部分で詰む

描くだけの解像度がない

特性的にも、そういう解決に向けた細かい解像度がないっぽいんだよなぁ

もっと言えば目標を据えて、それに向けて行動する、が苦手。ウォーターフォールが苦手

むしろ得意なのはアジャイル的に、とりあえずやってみて学びを得てそれから次を考える

だから仕事でしばしば出てくる「先に計画と予算決めて臨もう」に適応できない

構造的にこれが必要なのはわかってるので、この部分は誰かに任せるしかない