非情報系のエンジニアが新卒1年目に学んだ重要な価値観/考え方

こんにちは、エンジニアのやましたです。

私は、2021年に大学を卒業し新卒研修を終えた後はSUPER DELIVERYの開発エンジニアとして働き始めました。
大学の授業ではC言語で簡単なアルゴリズムや、HTML、JavaScriptを軽く学び、基本情報技術者試験を取った程度でエンジニアとして未経験で入社しました。
同期の中では唯一、情報系を専攻していない私がこの1年間で学んだこと、コードを書くときに気を付けていることについて書きたいと思います。

新卒入社すると1年間は新卒1人に、先輩エンジニア1人がメンターとしてつきます。
研修ではメンターに午前と午後、振り返りをしてもらいました。「自分がどのような作業を行って、何に詰まったか」を深堀してもらいました。
技術的なこと以上に「エンジニアとして重要な価値観/考え方」をメンターから学びました。

学んだ価値観/考え方は以下の通りです。

イエスマンにならない
自分の記憶を信じない
最低でもアプローチは2つ考える
悩んでいることを単純化する
その場しのぎのコードをかかない
出来るだけ焦らないようにする
内部で何が起きているか調べる

弊社では新卒エンジニアを対象に、「はばたけエンジニア」という研修プログラムを実施しています。
学んだ場面と一緒に詳しく解説します。

1. イエスマンにならない

学んだ場面は、私が研修中にはじめて弊社の営業職から売上データの集計用のSQLクエリ作成を依頼されたときです。
依頼内容には必要なカラムは全て指定されていたので、「何を行えばいいのか」はわかりましたが「なぜ、このクエリを作成したいのか」がよくわかりませんでした。
ただ、この理由として「自分が担当しているサービスに対して知識がないからだ。依頼者に言われた通りやればいいだろう。」と結論付けとりあえず依頼通りに実装しようと思っていました。
その際にメンターから「何のためにこのクエリ書こうとしているか自分で説明できるの？」と聞かれ答えられませんでした。
メンターから教えてもらったことが「イエスマンにならないこと」でした。

学びを活かして依頼者になぜこの売上データ集計用のクエリが必要なのかをお聞きしました。
依頼者の依頼目的が分かったので「このカラムをグループ化した方がいいのでは？」など依頼者の目的を達成する方法を一緒に考えることが出来ました。

2. 自分の記憶を信じない

研修で使っていたTomcatが何度も起動に失敗し、自分では解決方法がわからずメンターに解決法をお聞きしたことがありました。
メンターには解決法だけではなく、Tomcatで問題が発生したときにどこを確認すれば早く問題解決が出来るかも含めて教えてもらいました。
しかし、その時にメモを取っていなかったので、再度Tomcatが起動に失敗し自分では解決方法がわからなかったとき同じことを再度メンター聞く必要がありました。
その時の学びが、「メモを取ること」です。

この出来事以降は毎日、メンターから教わったことはメモに残しています。
そのおかげで、同じことを聞く頻度は下がりました。
私は、Visual Studio Codeでメモを取っていますが「VSNotes」という拡張機能を使うと、開いているプロジェクトに依存せず同じメモを参照出来て便利なのでおすすめです。

また、先輩から実装を進めていてエラーが起きた場合は下記のテンプレートを使うと人に相談するときも会話がスムーズに進むと教えてもらいました。
このテンプレートを使うと自分の考えも整理出来るので役に立っています。

# どの課題をやっているか(Where)
# 何が問題か(What)
# いつから発生しているか(When)
# どのクラス/ライブラリが問題だと考えているか(Who)
# なぜここが問題だと考えたか？(Why)
# どのように解決しようと試したか(How)
# 聞きたいこと

3. 最低でもアプローチは2つ考える

研修の中でjspファイルをフォーム作り、ユーザーから入力されたテキストをサニタイズする必要がありました。
私はとりあえず、Controllerクラスでライブラリを使ってサニタイズする方法が思いついたのでその方法で実装を進めていました。
その時にメンターから「なんで、この方法を取ったの？」と聞かれ、「ぱっと思いついたから」としか答えられませんでした。
そしてメンターには「最低でもアプローチを2つ考えてみたら？」と言われました。

複数のアプローチを考えるために、他の方法でサニタイジングできないか調べているとJSTL(JSP標準タグライブラリ)にはエスケープ処理を行ってくれるc:outタグが存在していました。
アプローチ方法を複数考えなかったため、自分が車輪の再発明を行っていたことに気付きました。
ぱっと思いついたアプローチに飛びつかず、他のアプローチを探していると今回のように既に存在する機能に気付けるのでよりより方法が選べると学びました。
また、複数の選択肢を持っていると、選んだアプローチで実装を進めていて問題が起こってもすぐ他の方法に切り替えられるので1つの実装にかける時間が減りました。

4. 悩んでいることを単純化する

研修の課題の1つにバッチ処理の作成がありました。
このバッチ処理のために排他制御を行う必要があり、私は楽観ロックを使って排他制御を実現しようとしていました。
実装後、確認のためにバッチを走らせるとSQLIntegrityConstraintViolationExceptionという例外が発生してしまいました。
そこで、私は「バッチ処理 SQLIntegrityConstraintViolationException」でググったり、表示されるエラーメッセージをコピペしググって解決の手がかりを探していました。
しかし、検索結果に表示されるものはエラーメッセージは同じでも根本的な原因が違う情報ばかりでした。
そのときにメンターから学んだことは「悩んでいることを単純化すること」です。
さらにメンターから、「悩んでいることを単純化するためにまず、やりたいことを1行で表現してみたら？」と教えてもらいました。

今回、自分がやりたかったことを整理すると「楽観ロックを使って排他制御を実現したい」です。
さらに、デバッガーを置いてどのタイミングでSQLIntegrityConstraintViolationExceptionが発生するか調べると楽観ロックのVersionを管理するカラムにUpdateを実行するときと分かりました。
そこで、Versionを管理するカラムの値を見てみると初期値を0に設定し忘れていたためNullが入っていたことが例外が発生する原因だと分かりました。
エラーが起きたときに、デバッガーなどを使いエラーの原因を絞り込むと起きているエラーが大抵、「自分が対処法を知っているエラー」であることが多いことに気付きました。
その結果、エラーメッセージでググる機会が減りました。

5. その場しのぎのコードをかかない

私は研修中、「早めに研修を終わらせたい！」ととりあえずその場しのぎのコードで「とりあえず動く！」状態にしてある程度作ってからコードを修正していました。
その後に、コードのテストを行いメンターにコードレビューをお願いしたとき、コードレビューには修正し忘れたその場しのぎのコードに修正指摘が書かれていました。
メンターには「その場しのぎのコードで書かれたものは将来的に負債になる」ことを教えてもらいました。

また、「研修は自分に足りていない知識を身に着ける時間なので焦る必要はないよ」と教えてもらいました。
この言葉で研修に対して焦りがなくなり、リファクタリング前提のコードを書くことを出来るだけやめることができました。

6. 出来るだけ焦らないようにする

初めてのリリース作業で、リリース後に自分が加えたはずの変更が本番環境に反映が確認できずかなり焦ったことがありました。
実際には本番環境には変更が反映されており、見ているページが違っただけでしたが焦り過ぎて自分では気づくことが出来ませんでした。
その時の学びが、「出来るだけ焦らないようにする」 です。

まだまだ焦ることがありますが、焦ったら5分程度休憩して心を落ち着かせることで初歩的なミスには気づくことが出来るようになりました。

7. 内部で何が起きているか調べる

研修中に既にDBに登録されたメールアドレスが入力されたときはエラーを返すような入力フォームを作成しました。
私は、DBがどのように「入力されたメールアドレスが既にDBに登録されたメールアドレスかどうか確認しているのか」を考えずにクエリを作成していました。
その結果、DBのデータ量が増えた場合にサイトの表示速度が遅くなってしまいました。
その時にメンターから「このクエリは何スキャンになるか想像できてる？」と聞かれ答えられませんでした。

検証してみると、テーブルフルスキャンになっていました。
メールアドレスの重複チェックのために作られたクエリは、全てのデータを取得して重複チェックを行っていたため遅かったです。
重複チェックの速度をどうすればより早くできるかを考え、2分探索などのアルゴリズムを使えないかと考えました。
DBにインデックスを貼ることで、B-Treeインデックスというデータ構造を使い早くできることが分かりました。
メールアドレスのカラムにインデックスを張ることで、計算量が下がりメールアドレスの重複チェックが効率的に行えるようになりました。
その結果、インデックスユニークスキャンにすることができました。
そして、サイトの表示速度も速くなりました。

まとめ

ここまで書いたメンターからの教えをまとめると常に自分の行動に疑いの目を持つ必要があるということです。
具体例としては、「そのコードの裏で何が起こっていることを自分が本当にわかっているのか、それとも感覚的に書いているのか」などです。

新卒入社から1年がたち、メンターと二人での振り返りの時間はなくなりました。
「エンジニアとしてどのように考えればいいか」を教わったことで自分の過去の行動を振り返るときに改善点が分かるようになりました。
失敗はまだまだありますが、このメモを読み返すことで対処法を自分で気づくことが出来ることが増えてきました。

今後も、メンターから教わった学びを振り返りエンジニアとして成長していきたいと思っています。

最後にラクーングループは一緒に働く仲間を絶賛大募集中です！
情報系・非情報系でもエンジニアを目指している新卒の方、中途の方も少しでも興味を持っていただけたら
是非こちらからエントリーお待ちしています！