ソリューション仮説
なぜ「ソリューション」ではなく「ソリューション仮説」なのか？
そもそもやりたいことって何だっけ？
(課題が正しいという前提で)それがソリューションとして正しいのかどうかを速く確かめたい
逆に、網羅思考的にソリューションを考えるとどうなるだろうかmrsekut.icon 具体的なソリューションを出しまくるイメージ？
e.g. 社内課題に対し「研修もやる、評価制度も変える、配置転換も考える…」と全部案を出す
最初から細かいところまで考慮してソリューションを出すイメージ？
技術的に実現可能か、データ的に最も有効な手段はなにか、など
となり、「良さげなソリューションを出す」までに膨大な時間を要してしまう
仮説を立てて、最初にスコープを絞り込みたい
だから、初手は抽象度の高いソリューションモデルを提示することになるだろうmrsekut.icon
最初から、UIとか実現手段とか具体的なことを考えてはいけない
言葉とdiagramで表現できるぐらいのモデルで、コンセプトを固める
もっと正確に言えば、課題の抽象度に合ったソリューションの提示が初手になるかmrsekut.icon
例えば、文字入力の課題のような狭いスコープの話なら、フリップ入力みたいなUIと直結したコンセプトにもなるだろう
逆に、「個人でもモノを手軽に売りたい」みたいな抽象的なスコープの課題なら、ビジネスモデルというのがコンセプトになるだろう
これを考えているときに、どういう技術を使うか、どういうプライシングにするかなどはどうでもいい
どう仮説を立てるか
まずは課題の整理と理解が必要
前段で課題仮説の検証が終わっているはず
最も大きな課題と、小さい課題が見つかっているはず
抽象度を整理し、スコープを絞り込む
その抽象度に合った、ソリューション的コンセプトを挙げる
実現可能性などは意識的に無視しても良さそう
この想起法は、問題の種類や、人によって色々方法はあると思うので省略
とにかく大事なのは、課題との抽象度を揃えて思考することだろうかmrsekut.icon
方向性を提示する
モデルを提示する
難しいポイントでいうと、
そのための検証とも言える
それ課題仮説では？mrsekut.icon
課題をかなり細かく分解できれば、それに対処する最小のソリューションを小さく作る事ができる UXの良さとしてはある程度の抽象度で、そのスコープ内の課題を全部解消できれば良いのはそうだが、
逆に、ソリューションが発散してしまいがちになるのは、課題が鋭利でないから、というのはありそう
まずは課題を鋭利にして解くべきもののスコープを狭めましょうということかもしれない