やりたいことを仕事にするために、やりたいことを見抜くプロセス主義な質問

概要

過去にも「やりたいこと」の言語化の失敗についても考えたが、やりたいことを仕事にすると言っても、 「やりたいこと」には2種類存在することに気がついた。 今回は、自分がやる必要があるかということを焦点に、結果が欲しいのかプロセスが欲しいのか問うことで 「やりたいこと」の勘違いを減らして、本当にやりたいことが得られるようにしたい。

結論から言うと、プロセスが好きな場合は自分でやってもいいし、結果が欲しい場合は人に任せればいいということである。

どうするのか

人は、「やりたいこと」を説明するときに結果が欲しい場合と、プロセスが欲しい場合がある。

例えば、やりたいことの中に「プログラミング」があった場合に、プログラミングをやった結果どうなるのか確認する。 プログラミングをやった結果として自分のサービスを作れるという場合、「自分のサービスを作れれば自分でプログラミングをしなくてもいいか？」（結果だけ得られればいいのか）、「同じプログラミングレベルの人が喜んでやるなら任せたいのはどれくらいか？是非ともなのか、任せたくないのか」（どのくらい人に任せられるなら任せたいのか）

これを聞くことで、その本人がやりたいことか、他の人に任せて実現したいことか、が分かる。

結論

なので、プロセスが好きな場合は自分でやってもいいし、結果が欲しい場合は人に任せればいいということである。

もちろん、経営の事を考えるとコストの関係で自分がやったほうが良いものもある。 例えば、単価の高い仕事の結果だけが欲しい場合は、外注する場合も、雇用する場合もコストがかかる。 なので、すぐにプロセスが好きなものだけやればいいというわけではなく、将来的に任せたり、コストのかかる場合はやらずにすむ選択を考える。

もちろん、将来的に任せるわけだがリスクを取りたくないから自分でやる方がいい場合もある。 例えば、サービスを考えて課題を解決したいが、プログラミングがあまり好きではなかったりすることもある。 そのとき、自分の作りたいサービスを作るために将来永劫プログラミングをするというわけではなく、 コストやリスクを下げるために自分でプログラミングをしてサービスを作る。 そして、そこから得た利益で他の人にプログラミングをお願いするなど。

IT系の就職活動で何人か話を聞いたことがあるが、企画をやりたいが最初から企画で入社するためにはハードルが高いため、 エンジニアとして入社するために、プログラミングを勉強するみたいなものである。