siroの松山です。なんどもノートに考えたことを書こうとしては下書きにとどめるというのを続けてきましたが、深く考えずに流してみるというのをやってみます。

今の仕事の現場

弊社の仕事ぶりの紹介をしてみます。誤解を恐れず書いてみます。

弊社では、新卒採用の若いスタッフなんかもいます。実務経験というのはとても大事なことだし、プログラマー/エンジニアとしてのスキルという点では、経験時間というのはとても重要ではあります。でも、多くの仕事はグーグルで検索することで解決方法が見つかり、そこを手直ししながら実装することで達成できます。

僕たちおじさん世代は、学生の頃なんてArduinoもgithubもなくて、知識はたまに出る文献やメーカーが出してるオフィシャルな文献でのみ得られるという時代を過ごしてきましたが、今は違います。初めて使うデバイスもエンジニアコミュニティでは、使い古されたデバイスでライブラリやスタディの痕跡が山とあります。

そんな時代、検索とわずかな知識で乗り切れることは多いのです。

では、どうやって育てるのか

弊社では、責任を与えることで育てます。つまりは、任せます。やったことのないことでも、本人のやる気が見えれば大体任せます。納期よりもはるかに先に稼働し、できるだけ多くの時間を与えます。

ゼロ発進の場合エンスト起こす可能性は高いので、最初の手伝いはもちろんしますが。

どうなるのか

最初は期間中に納品クオリティにたどり着けません。デバッグもろくにできません。でも、そこは熟練の自分が教えたり直したり（間に合わなさそうならバトンタッチして仕上げますが）でなんとかします。

でも、そんなことを半年もしてるとだんだんゴールできるようになります。細かなことは教えません。調べてリンクを送るくらいです。

トラブルの学び

多くの場合書いたプログラムにはバグがあります。電子回路やなんかも大体問題があったらミスがあって直していくことになります。それはある種のトラブルと考えます。

トラブルがあった時その原因を知らないと解決できません。

例えば、あるデバイスを五台作った中で、一台にトラブルがあった時、その問題の原因はソフトなのかハードなのかわかりません。では、その時どうするのか。

エンジニアは問題を切り分けます。

ソフトの問題かハードの問題か切り分けるのに、簡単なのは、正常に動いてるものとパーツを交換することです。それで問題が出なくなればハードが疑わしいとなるわけです。

でも、それも完璧ではないかもしれません。ソフトの問題がハードの個体差を吸収できずに起こってるのかもしれません。

そんなこんなを細かく切り分けていき、問題をできる限り正確に把握するのが解決に向かう方法です。

できそうでできない

問題を切り分けるときに、先入観や固定概念が邪魔したりします。全ての可能性を洗い出すのが億劫で見落としてる中に本当の原因があることもあります。

これは、多分センスが問われるものです。そして、経験値で補えることでもあります。

問題の切り分け能力

言い過ぎになるかもしれませんが、僕はエンジニアリングとは問題の切り分けなんじゃないかと思うわけです。それができれば、すぐに問題が解決でき、そのセンスがあればいい設計、いいコードが書けます。たぶん。

これは、問題解決能力でもあるので、エンジニアリングで学んだこの能力は多方面で行かせます。全てのことを問題として考えると、それを細分化し切り分けていくことで多くのことは解決できます。どんな問題でも切り分けセンスを持ってしたら解決はできるという考え方です。

この文章を書くことで起こる問題

・クライアントが見るとなんだか不安になるかもしれない

・言ってることが全く伝わらない

・オチがないのでつまらない

さて、、ここの問題をまた切り分けていきますか。。。