はじめに

エンジニア 1 年めを振り返って思うことは、他人にどう言われようとよくやったと言えること。まぁ、強気に攻められてお前あれできていなかっただろう！！と詰められれば、自分は「もうしません！！許して！」という。 とにかく、誰が何を言おうが自分は頑張ったという。そういう自己暗示的なものをかけることが大事。

話がそれそうなので、エンジニア 1 年目に話しを戻す。とはいえ、エンジニア 1 年を振り返ると長いので配属されてからの半年を振り返ろうと思う。さて、何を記載しようかなと思った時、自分ができたことを振り返ればいいのかできなかったことを振り返ればいいのかそれとも自画自賛をすればいいのかわからなかったので、ふと思うことから記載したいと思う。

ふと思うこと

1 年目を振り返りたいと思ったが、なぜ振り返る必要があるのか。他の人の振り返りを見たいと思った

• 1 つめ

1 年目でやらないといけないことがあったんですね

• 2 つめ

キラキラして眩しくて途中で読むのやめた！

• 3 つめ

ふーん

正味他人の振り返りを読んでもあまり楽しくない。その人の感想しかないのだから当然だろう。必要なことも会社それぞれだろうし、チームの雰囲気もそれぞれだろうから。だから、比較する意味はないし自分がいうことも正しいとか間違いとか関係ない。振り返りとはポエムだし感想。 さて、とりあえず感想を書くとして、記憶を辿ってできるようになったことってなんだろうーって思っても元からできていたように思えるしできなかったように思える。ただ間違いなくできる、あるいは意識するようになったことはいくつかある。それらがふと浮かんだので箇条書きをする

• 業務ロジックの理解
• 日々のサボり方

上記 2 点は意識するようになった。

業務ロジックの理解

極端な話し、プログラムがわからなくても業務で必要な用語や考え方が理解できていたらあとはなんとかなる、というのを自分は理解した。だって、人が書いたのを真似ればいいから。他で記載されていることを理解し真似ていればそうそうおかしなことはないし、ふとわからなくても調べればなんとかなる。OJT の期間にお邪魔した場所で、自分が触ったことのなかった C++や go 言語のプログラムの改修を沢山した経験によるものだ。ぶっちゃけ自分がやったことのプログラムの意味をさほど理解していなかったが、調べて手を動かして意図通りになっていたことはわかった。それは業務ロジックを把握していたため。

ここの関数がこうなって、クラスがあって。。。みたいなことは触ったことのない言語でも雰囲気でわかる。文法は知らんが、雰囲気。だいたいプログラムとは良い書き方を意識しない限り、だいたい書ける。良い書き方をやりたい場合は、Effective 系を読めばいい。ただチームの人がそれ相応の実力をもたなければ話にならないと思う。スポーツと一緒。

業務ロジックの理解に必要なプロセスは何か？ → とりあえず自分ならどうするかを適当に考えること。大きなプロジェクトや小さなプロジェクトがあった時、それをどういう風に分解すればいいか適当に考えてみる。あるいは〇〇というシステムがあり、それがどういう風に実現できているか。適当で良い、考えてみる。メモを記載することはやっている時としない時があるが、頭だけでも動かしてみるようにしている。最終的に出てくる output を見ていくとだいたい外れていることが多い。当たっていようが外れていようがどうでもいい。そういうプロセスを楽しめば良いと自分は思う。という感じで、いきなり業務ロジックを見てもつまらないし楽しくない。遊び心の気持ちで、適当にやる。理解するとはそれが始まり。数学の数式でも、いきなり難しい数式見てもわからないし嫌気が差す。一方で、わかるところから見ていけばそれなりに面白い。ただ飽きてくるので、適当に数式を展開してみたり混ぜてみたりする。そうすることで一気に時間が削られ没頭する。

この没頭することが、業務ロジックを理解し、設計に時間をかけられるようになれば一人前なのではないだろうか。自分はそこまでに至っていないが、設計を考えて書き出すまでは自分はできるようになってきた。だから、思うのは開発を一番に考えるのではなくその過程の、設計や業務を推進するためのロジックのプロセスを考える方が真に有用で楽しいプロセスであると。それが大事だと理解した

ぶっちゃけ、開発はベンダーに任せたりする方がスピード的に早いし綺麗に書いてくれる。彼らはそういうプロだから。

日々のサボり方

自分は午前中あまり仕事をしない。眠いし頭がボーッとするから。だいたい、いつも深夜 1~4 時に寝る。業務は 10 時ぐらいから。しんどい。朝が始まると適当にパンを食べつつ、業務をするときもある。そういうことをしながら、今日することを大方整理する。以下のように箇条書きで記載しメモをする

• 〇〇の開発
• 〇〇を少し進める
• 〇〇の MTG

という感じ。どんなに早く終わろうが自分はそれ以上やらない。一方で、やりきるまで終わらない。早く終われば退勤することもなく、適当に git を検索し社内のコードをみる。いい書き方やこういう書き方があるのかと発見があるからだ。自分はそうやってサボり方を覚えた。

技術的なことを話せばポエムになる

今まではポエムだ(書いてみればこれもポエムだった)。ここで記載することは技術の話。自分が持っていたスキルと得たスキルの比較をしよう

typescript
javascript
 - nuxt(このサイトはnuxt)
 - vue2
html
css(このサイトのcssは98%ほど自作しライブラリは使っていない)
機械学習(kaggle 少し)
統計学(統計検定2級)
python
 - django
論文作成
 - 一応賞は2回ほどもらった

というのが入社する前のスペックだ。以下が自分

typescript
javascript
 - nuxt(このサイトはnuxt)
 - vue2
html
css(このサイトのcssは98%ほど自作しライブラリは使っていない)
機械学習(kaggle expert)
統計学(統計検定2級)
python
 - django
論文作成
 - 一応賞は2回ほどもらった

java
 - springboot
mysql
hive
batch処理
設計
 - シーケンス図、クラス図、状態遷移図、その他

というぐらい。配属されてから、一番触っているのは集計の作業の sql 力である。ぶっちゃけ集計は嫌いだからこれ以上やりたくないので、勉強はしない。する必要がきたらするかもだがやりたくない。java は面白い。batch 処理は嫌いな部類の考え。

何が言いたいかというと、自分は配属されてから自分が好きな部類の技術は多く触れることができていないことだ。好きなのは、web であったり API であったりするものだ。集計作業なんて聞いていない。batch 処理なんて聞いていない。配属は望んだ場所での配属とは違ったというのが本音だ。ただまぁ、嫌いなものを触れば触るほどなんだかんだで愛着が湧くもの。集計は嫌いだが、何をどうしたらいいか考えられるようになったし自分が出したいものはサーチして答えは出せている。合っているかは別問題だ。要は、嫌いなものと上手く付き合えていることだ。それが大事。自分がやりたいものをやらせてくれないのは仕方がない。ボスは強いし、逆らえない。世の定めだし、それが嫌ならやめればいい。配属を希望するのもいいだろう。が、やめてそこもやりたいことでなければ無意味だ。さて、問おう。やりたいことはなんだろうか？web か api か。違うところでやれなかったらまた移動するのか。こういうのは時と運だ。うまいこといけばいいのだろうし、そうでなければ違うのだろう。だが、会社が自分を選ぶのではなく自分が会社を選んでいる、ということは忘れてはないけない。ジンクスは大事に。

最後に

できるようになったことなんてしれている。ただ、自分は常にできる人間だと考えている。周りがなんと言おうが自分はできる人間だ。そう考えておく方が楽だし、自分以外はできないと考えれば優越感に浸れる。別に人と比較する必要もない。振り返りはポエム。振り返りをして考えることで自分は色々やってこれたと改めて認識できた。