問題解決よりも問題定義に携わりたい
自分の志向と適性は問題定義らしい
典型的なエンジニアとは異なっていてそりの合わなさが増えてきたsta.icon
ここを数週間深堀りしていて、ありきたりだけどこの言葉に
比較
問題解決：設定された問題を解決することに注力。問題は疑わない
問題定義：問題を設定することに注力。疑う
問題解決マンが集まるチーム
顧客や上司が言っているタスクをいかにして解くかを考える
問題定義マンな僕
そもそも真の問題は何かを考えるところから始める
顧客や上司の意見は情報の一つでしかない
し、経験的にたっぷり時間使って頭手足動かして深堀りする僕らの方が詳しくなるのは当たり前
sta.icon
問題定義こそ必要と思うんだが、現状空白なんだよなぁ
立場上、
現場は問題解決ばかりやらされるし、当事者たちも解決の視座しか持ってない
仕事を与える側は問題定義の視座に立ってるけど、忙しくてマルチタスクでかけてる時間と思考がしょぼいので定義も甘い
この二つだけだと問題定義を深堀りしていけない
無論、あらゆる組織がこうなってるわけではなくて、うまいR&Dや出島であればこの程度はできてるだろう
が、sta.iconは見たことないし、例外的だと思う
だからこそもっと身近にしていきたさ
sta.icon
この構図をほぐすソリューションはいくつかある、というかつくれる
意思決定層が（問題定義は素人のくせに）なぜか抱える構図になってるから、ぶんどらないといけない
ただし、ぶんどったところで、じゃあどうやってやるの問題がある
「問題定義エンジニアリング」なるものが未開拓なのも事実なので、整備が急務
といっても使えそうな理論や事例は山ほど転がってる（が、これらを整備して一つのエンジニアリングに仕上げないと誰も使えない）
俺ならつくれるけど、さすがに本業しながらはきついので専任にならねば……
趣味だと人巻き込んで検証する部分で詰む