メンターを顧客にする
メンターを顧客にする
nishio: 100件の応募を見てたらおぼろげに浮かび上がってきた「手段Xで問題Yを解決して顧客Zを幸せにする」王道パターンに当てはめると、これは(2)の「手段が欠けてる」パターンになる。これは採択されにくい。 一方で(3)や(4)のパターンでの採択はあるので何が違いなのだろうと考えている。 https://gyazo.com/49bab0d3ae47051bc0d6e600467cbe19
nishio: 例えばこれは(1)ではなく(4)だと思う jr.mitou.org/projects/2020/… nishio: (4)であるか(3)であるかは大きな差ではなくて、このプロジェクトも「今のコンピュータはブラックボックスになっている、これは問題だ。リレーでコンピュータを作ることによって問題を解決するのだ」と主張することはできて(3)になれる。でも「それによって居合わせになる人は？」に答えてないのは同じ nishio: で「それを作ることで誰が幸せになるのか？」を明確化するように指導されたりとかしてないと思うんだな。暗黙の自明な解である「作りたいから作る、作ることによって幸せになるのは自分」を特に異論なく受け入れてる状態だと思う。 nishio: なぜそのような「自分だけが顧客」のプロジェクトでも採択されうるかというと、提案書やインタビューを通じてメンターの共感を引き出して「自分とメンターが顧客」になるからだと思う。なのでこのプロセスはメンターのフィーリング依存で運の要素が強い。 nishio: 例えば提案時点でのプロトタイプのクオリティがもっと低くて「作ると言ってるものが実際に作れるか？」に対する疑念がもっと大きければ採択確率が減っただろう。でもこの種のプロジェクト、体裁だけ(1)にしたところで無意味なので結局クオリティを上げることが最重要になる気がする nishio: 「体裁だけ(1)にしても無意味」というのは「プログラミング教育義務化でコンピュータを学ぶ小学生が増えたがコンピュータがブラックボックスなせいで彼らは困っていて、ブラックボックスで無くすためにリレーでコンピュータを作る」みたいな提案のこと。「目的に対して手段が過大では？」となる nishio: 一方で提案書の時点で既に十分すごいものを採用してそれが自走して相応の成果を出したところでメンターは付加価値を生み出してないんだよなぁ