エンジニア立ち居振舞いで意識する3点
エンジニア立ち振る舞いについて、できるだけエンジニアだけではなく、他の職種にも通じるような内容を意識してメモしておく。
正直、俺自身エンジニアなのかよく分からない道を歩んできたということもあって、エンジニアこうあるべきなものってむしろこっちが教えてもらいたいくらい。
俺は主に以下の３つを日々意識しているかなあと。
- 基礎を蔑ろにしない
- 質問できるタイミングならどんな小さなレベルでも聞いてみる
- わかりやすさを意識する
至極当たり前のものばかりでホントアレだけども。
事前情報として俺はパッケージ系のエンジニア経験から上流工程に行き、データサイエンティストなる職種に移行しようとおもったらインフラエンジニアをやっているという状況です。
基礎を蔑ろにしない
学生の時に先生がよく言うやつ。正直基礎なんてしなくても日々の業務こなせば勝手に基礎力なんて上がるのでやらなくてもよくね？みたいな感じだったんだけど、それだと網羅できないところってホント出てくる。
例えば用語とかは最たる例で、分かるけどこれってなんていうのか分からないから説明できない。あれをそうやってあーやるみたいな指示語前押しで全然通じない。
向こうが何言ってるかもよく分からないので、認識合わせるのにも時間がかかってしまい工数を奪われ互いに不幸になる。
業務こなしていくと小手先で対応って意外にできたりするし、やってたりするんだけどそれやると自分のスキルって意外に上がらなくて、別システムで同様の事象が発生した時に対応できなかったりする。
そういうときってよく分かんねえからスタートするからハードルが高くなって、こんなの俺できねえよってマインドになりがち。
ある程度基礎とか地盤固めていたりすると、きっとこれができるはずからからスタートできるので精神安定的によいかなと。
きっとこれができるはずっていうのは、基礎だけではなかなかたどり着かないとは思う。
だけど基礎持っているのともっていないのでは、基礎以降の広がりというか「あるべき」論できるかできないかって時点で変わってくるのかなと。
俺はホントそんなことに気付くのですら遅くて、今更意識している時点でお察しなんだが、意識している内容としては
- 入門書読んで知見を広げる
- ネットで技術の情報を目にする機会を広げる
なんてことをやってる。
入門書読んで知見を広げる
毎月1冊必ず買って読むようにしてる。俺こんなの今読んでるんですよーで、俺の教務ある内容を他の人に認識してもらえたり、情報交換できたりするのでやってて損なかったかなあと思ってる。
入門書読んでも何言ってるかよく分からないこともあったりするんだけど、あとあと読み返すと理解できたりする。
なんつうか、アトリエシリーズで自分のスキル上がった時に既存の書籍で新たな知識仕入れる感あって好き。
ネットで技術の情報を目にする機会を広げる
TechFeedやRSSを使って技術の情報を毎朝30分程度確認するというのをやってる。
プロジェクト作業でやると視野が狭くなる傾向があるので、それを回避するためにこういうのもあるんだな程度で抑えてる。
意外にこれQiitaで見た！的な進研ゼミ的な展開もあったりする。
質問できるタイミングならどんな小さなレベルでも聞いてみる
経験上、このレベル質問したらガイジだと思われると思って質問しないと大体特大ブーメラン飛んでくる。すげえ困る。そもそも俺が理解できてないんだからそりゃそうなんだけども。
そういうところの微妙な認識齟齬が少しずつ大きくなって自分に跳ね返ってくる傾向にある気がする。
じゃあどうするかって、とにかくガイジだと思われるの覚悟で質問する。たまにその質問が実はクリティカルな問題でみたいになったりする。
大概はガイジだと思われる（と被害妄想している）。
質問せずに「はい。はい」みたいな頷きだけだと、ホントにこいつ理解してんのか？みたいに思われるし思う。
クソしょうもない質問でも、俺は質問してこないよりはいいかなと思うので、質問するように心がける。気持ちを強く持つ。
ただ全投げな「これ分かんねえっす」みたいなのは当然NGで、どこまでわかっている（つもり）なのか、分からないのは何なのかっていうのはちゃんと言わないと、質問丸投げニキだと思われる。
「俺こう思ってるんですけど、あってます？」的な感じでやると、ガイジだと思われない（でほしい）。
わかりやすさを意識する
自分だけで仕事してんじゃねえんだぞってこと。自分の思っていることや考えていることを伝える局面ってあるんだけど、どのように伝えるのかっていうのは考えた方がいい。
このブログもそうだけど極力分かりやすくみたいなものを意識して、図表で情報を伝えるようにしている。
確かに工数はかかるんだけど、口頭や文章のみで説明した場合より整理されるし、頭に入りやすくなる。
あと図表にまとめておくと、別プロジェクトで転用できたりするので結果的に工数削減につながったりする。
相手は自分の思っていることなんて何一つ分かってないって認識しておくってのは必要だと思う。
だからこそ一発で分かるものを用意しなきゃって思えるし、そのためには図表を用意してこういう思いを伝えなきゃって思える。
エンジニア的な側面でなぜ必要なのかという点を具体的に述べると、単体テストをやるときにどういうテストやろうとしているのかというのが第3者、というか1週間後の俺に分かるようにしないと、説明したり思い出したりするのに余計な工数がかかる。
それってホント無駄なので、最初に時間かかっても図にしておいて、そもそも質問されない、見返してすぐ思い出せるを意識したほうがいい。
テストレビュー時に「何のテストやってるか分からないけど、君を信じてOKにする」とか遠回しにお前のテストクソやなって書かれるの結構心にくる。
さいごに
ホント今更感あふれる内容で全然参考にならんと思うが、俺は今日もそう思うし、それでなんか今日は上手くいったなーみたいな気持ちで幸せになる。口頭で質問されても恐らく同じことを言うし、言ってるかなと。
