エンジニアが悩んでいる時にブレークスルーする方法

カンファレンスで自分の講演やワークショップをするときは、前後の時間はこれまで講演者の控え室にいることが多い。スライドを見直して、話す内容を心に留めたりして時間を潰しているわけだ。

終わったら終わったで、一仕事終えてぐったりとして何もする気になれないのでやはり控え室で甘いものでも口にしている。

ところが、あるカンファレンスでワークショップが終わった後、知り合いの方がワークショップをするのを思い出して、それに参加しようと思った。

珍しい。

ワークショップの内容は、今市場に出ているいくつものプロダクト集め、それぞれのプロダクトで想定している顧客セグメントとしている設定が、それが本当にそのセグメントで良いかを評価して欲しいというものだった。また、イチ押しのプロダクトを選んで欲しい、とオーダーがあった。

気楽にやって欲しい。そういうことで、プロダクトに触れてみて、依頼されている内容を評価票に記入していく。

終わった翌日、ふと、これは現状に対する疑問（上記の場合は想定している顧客セグメントが実は違うのではないか）があって、それを自分だけで判断せず、想定しているセグメントの顧客に評価させてしまえばいいと思い至ったのではないか、と気づいたのだった。

エンジニアが仕事をしているとやっていることが正しいかどうか、進む方向がわからなくなるときが多々ある。それは、エンジニアの仕事が決められたプロシージャで決められた通りに処理すれば片付く仕事ではないからだ。

そうしたとき、上記のように早い段階で、実験をしてみるのが良いのだ。実験といっても選んでもらうとか、行動として現れる方法を取ればいい。

実験で得られた結果は、1つのサンプルでしかないから、それが神様というわけではない。それは注意した方が良い。

ただ、実験をしなかったら、気づくことができないことに気づけるだろう。それを実験しないでて早くやりたければ、いくつも視点の違う帽子を自分で着替えられるようにスキルとなりきりに必要なペルソナを持つことだ。

それはそれでそこにたどり着くまでが大変なので、聞いてしまった方が手っ取り早いのである。

この手っ取り早く聞いてしまうも、実際は、1人でくよくよ悩む時間は何も得られないので、それを止める方法が聴く、ということだけの話なのである。

ブレークスルーする方法なんて実は大したことではない。