こんにちは。
泡アハです。
エンジニアになったのは、2016年なので、
かれこれ、7年エンジニアをやっています。
(本当にあっという間だった。。。)
そんな自分がエンジニアとして、意識していることをつらつらと書いていきたいと思います。
個人的には、今回まとめたことは、エンジニアとして他者より一歩抜きんでるためには、
大事なことなのでは？と考えています。
結論
- わからないことをそのままにしない
- わからないことをそのままにすると、いつまでたっても成長しない
- わからないことはそのままにせず、自分で調べたり、人に質問するなりすると、少しずついろんなことがわかるようになる
- 同じミスはしない
- 初めてのミスは仕方がない
- そのミスをどうやったら防げるかを振り返ることが大切
- 疑問に持つ
- 小さなことでも疑問に持つ。そうすれば、エンジニアとしての知識の幅が広がり、やれることも増えるはず
- 人に聞くときは、自分で限界まで調べてから質問する
- 人に聞くときは、自分でできることはすべてやる
- 人に聞くということは、相手の時間をいただく行為なので、事前に調べるなどして、相手の時間を減らす努力をする
- 方針を聞くときは、漠然と聞くのではなく、根拠とyes、noで答えられる質問にする
わからないことをそのままにしない
エンジニアとして、意識してきたこと一つ目は、わからないことはそのままにしないです。
エンジニアという職業は、一生学び続ける必要があるといわれますが、
全くもってその通りだと思います。
IT技術の進歩は早く、去年には、最新と言われていた技術やライブラリが古くなって、
こっちのライブラリの方がモダンと言われることもざらにあるし、
技術の守備範囲もどんどん広がっていくことが多いので、
仕事中に知らない単語が急に出てくることがよくあります。
私は、2016年に中堅Sierでエンジニアのキャリアを開始しましたが、
2022年11月に暗号資産ベンチャー企業に転職したときは、わからないことだらけでした。
言語は、Rubyだし、ブロックチェーンのことはわからないし、自社開発の企業なので文化が違うし、
様々なことがわかりませんでした。
（元々は、JavaやC#、Typescriptなどをメインに放送業界のシステムをメインにやっていました。）
しかし、何もわからない状態でも本当に一つずつ、自分の腑に落ちるまで理解することが大事だと考えています。
一つずつでもしっかり理解することで、どんどんとわかることが増えていきます。
ある一定を超えると、複雑な問題であっても、
今までの理解がつながって、解決できるようになります。
これは、わからないことをそのままにしていては、
到達できない領域だと考えています。
エンジニアとしてこれからもやっていきたいのであれば、
わからないことをわかるようにする努力が必要だと考えます。
同じミスはしない
次は、同じミスはしないということです。
エンジニアたるもの、誰もが一つ以上は大きな失敗をした経験があるのではないでしょうか？
かくいう私もエンジニア3年目の時に、
・リリース時に検証環境用の資材を本番環境にリリースした
・その1週間後、自分の開発箇所でバグが見つかった。という失敗がありました。
(上司3人でお客様にあやまりにいってもらったり、不具合報告書を書いたり、今でも思い出すだけで、胸がくるしくなります。。。。)
ここまで大きな失敗は、そこまで多くないにしろ、小さな失敗は、常日頃たくさんあると思います。
例えば、レビュー時に同じ指摘をもらうなどがあげられます。
レビューのときとはいえ、同じ指摘をもらうことは、レビューアに対して、とても失礼だと感じます。
レビューアは、貴重な時間を割いて、レビューしているのに、またこいつこれやっているよと思われ、レビューする気持ちが薄れてしまいます。
ミスをしたときにできることは、どうやったらそのミスをしないか振り返ることだと思います。
そのミスをしてしまった原因は何なのか。
その原因を防ぐにはどのようなことをやればよかったのか。
どんなに小さなミスでもそういった振り返りを繰り返し行うことが大事だと思います。
昨日の自分より0.1%でも賢くなることができれば、1年後にはほぼミスをしない、もしくはミスをしてもリカバリーできる人間になっているはずです。
疑問に持つ
疑問に持つ姿勢というのは、エンジニアにとってとても大事だと思います。
Rubyのrspecには、letとlet!がありますが、
似てるようで、微妙に用途が異なります。
また、バグが起きた時、こうやれば直るということだけでなく、何が原因でなぜ直るのかを理解したりする視点はとても大事だと思います。
このようにプログラミング言語に限らず、すべての事象において自分自身で疑問を持ち、
それを調べて解決する能力は、エンジニアにはとても大切だし、
自分自身疑問に持つということを意識して、知識の幅が広がったように感じます。
人に聞くときは、自分で限界まで調べてから質問する
エンジニアは、基本的にチームで作業を行うことが多いですが、
わからないことを人に聞く機会は多いです。
(これは、エンジニアというよりはサラリーマン一般にいえることかもしれません。)
わからないことを聞くこと自体は問題ないと考えていますが、
たまに漠然とわからないことを聞いてくる人がいます。
例えば、
こういうエラーがでてるんだけど、どう解決したらいいでしょうか？
や
こういう仕様にしたいらしいんだけど、どうしたらいいでしょう？
といった感じです。
こういう質問をしてしまうと、相手に質問を丸投げしてしまっているし、
質問者自体の成長がありません。
そこで私は、極限まで自分で調べることを意識しています。
エラーがでているのであれば、
なぜエラーがでているのか、ぐぐったり、ChatGPTに聞いたり、
社内のSlackを検索して、同じようなエラーを解決している人はいないかを探したり、
といった具合です。
極限まで調べたうえで、
今このエラーが出ていて、ぐぐったら、こういう記事が出てきて、
これは試したのですが、うまくいきません。
個人的には、～あたりがおかしいと思うのですが、
どなたか解決策をご存じの方はいますかね？というような質問をするようにしています。
こうすることで、この人は、自分なりにやれることはやったみたいだと回答する側も気持ちよく回答することができる気がします。
また、方針を聞くときは、自分なりの根拠とできるだけyes、noで答えられる質問にすることを心がけています。
先ほどのこういう仕様にしたいらしいんだけど、どうしたらいいでしょう？の場合であれば、
こういう仕様にしたいようなので、いくつか案を検討しました。
個人的には、A案がいいと思っています。
([根拠]~なため。)
ご意見いただけると助かります！
A案:
B案:
C案:みたいな形です。
このような形であれば、質問された側もA案にしよう(yes)、このケースならD案も考えられる(no)みたいに思考回数を減らすことができます。
漠然とどうしたらいいでしょうと聞いてしまうと、回答者は、ゼロから考える必要があるため、負担が大きいです。
まとめ
いかがでしたでしょうか？
自分が7年間エンジニアをやってきて、
意識していることを言語化してみました。
改めて書き出すと、
いろいろな視点が見えて面白いですね。
コメント