ボトムアップで価値を提供できるエンジニアを目指して。自ら取りに行った学び

はじめに

はじめまして。日本工学院専門学校ITスペシャリスト科3年の天野滉瑛です。
私は7日間、ディップ株式会社のインターンシップに参加しました。エンジニアとして、任された仕事を進めるだけでなく、現場で見つけた課題の改善にも自分から関わり、事業やユーザーに価値を届けられるようになりたいと考えています。
今回のインターンでは、担当する改修に取り組みながら、興味を持った調査にも自分から手を挙げました。この記事では、開発とレビューを通じて得た学びと、目標に対する振り返りを紹介します。

インターンでの目標

主な目標は、CPC移行に関わるタスクを速度感を持って進めることでした。CPCはクリック数に応じて課金する方式です。私は、この移行に関連する連携データの前処理などを担当しました。
私にとって速く進めるとは、作業を急いで終わらせることだけではありません。完了条件の認識がずれて手戻りが起きたり、後から読む人が意図をつかめない実装になったりすれば、チーム全体ではかえって時間がかかります。そこで、着手前に何ができれば完了かを具体的にし、分からない点は早めに確認することを意識しました。時間のかかるタスクでは、実装を最後まで進めてから見せるのではなく、先に方針や草案を共有するようにしました。
もう一つの目標は、任されたタスクを進めながら、自分の担当範囲を少しずつ広げることです。既存のタスクの中から、自分にも取り組めそうなものや、学びにつながりそうなものを探し、手を挙げることを意識しました。

取り組んだこと

連携データの前処理まわりの改修

インターン中は、連携データの前処理に関する改修を担当しました。中でも印象に残っているのは、AIを使って実装した処理に対するレビューです。
そのタスクでは、入力に応じて処理をどう分けるかを自分で考え、その方針をもとにAIを使って実装しました。生成されたコードを確認してPRを出しましたが、レビューでは、想定していなかった形の入力が来ると意図した結果にならないことを指摘されました。そこで、分岐を増やすのではなく、処理の入口で入力を正規化する設計に変えました。これにより、その入力にも対応でき、後続の条件分岐も単純にできました。
振り返ると、自分の中に方針はあったのに、それをAIが書いたコードを確かめる基準として使えていませんでした。コードには目を通していたものの、入力ごとにどの条件を通り、どんな結果になるかまでは十分に追えていなかったのです。次からは、自分が考えた方針と実際の動きを、想定外の入力も含めて照らし合わせたいです。
同じレビューでは、条件式だけでは何を判断しているか伝わりにくいとも指摘されました。私はコーディング規則を参考にする一方、少し読みにくいという自分の違和感を見過ごしていました。規則に沿っているかだけでなく、Issueの背景を知らない人にも意図が伝わり、後から直しやすいかを確かめる必要があると学びました。

変更の理由と作業状況を次の人に残す

別の改修では、コードの変更理由をドキュメントにも残すようレビューで指摘を受けました。私は変更理由を書けばよいと捉えていましたが、依頼の意図を詳しく聞くと、後から別の人が判断の背景をたどり、作業を続けられる状態にすることまで求められていました。その視点を踏まえ、変更理由を設計ドキュメントに反映しました。
同じ改修では、不正データを除外し、正常なデータは残すことを確認するテストコードを追加しました。変更の理由や検証結果に加えて、関連するIssue・PR、作業の進捗と残件も残しておくと、次の担当者が判断の背景をたどって作業を続けられます。自分の変更を記録するだけでなく、次に誰が何を判断するのかまで意識する必要があると学びました。

NULLと値ありの条件で実行計画を比較する

求人情報の連携対象を選ぶSQLのレビューで、除外対象かどうかを示す項目が、通常の求人情報ではNULLになっていることが話題になりました。値が入っている場合のほうがインデックスを使いやすいのではないかという仮説が出ましたが、今回のSQLでもそうなるかは未確認でした。この一次調査は当初私の担当ではありませんでしたが、検証方法を考えるところから取り組みたいと思い、手を挙げました。
まず、CPC移行時にデータを最初に取り込むSQLと、移行後に変更分を定期的に取り込むSQLを確認し、NULLと値ありを比較する条件を整理しました。ほかの検索条件まで変わると、差が出ても原因を判断できません。検証の進め方をまとめてレビューに出したうえで、比較用のSQLを用意して実行計画を取得し、検証環境のインデックス構成も調べました。
対象は数百万件規模の求人データで、この項目は約98％がNULLでした。検証環境には対象項目を含むインデックスがなかったため、NULLと値ありでそのインデックスの効き方が変わるかは、今回の検証では判断できません。一方、現状の索引構成のまま値を入れても、対象項目のインデックスによる絞り込みは起きないと分かりました。
定期取り込みのSQLでは、NULL条件と値あり条件で実行計画とコストが同一でした。初回取り込みのSQLでは値あり条件のほうが推定コストの高い計画になりましたが、これは別のインデックスから読み始めたためで、対象項目のインデックスによる効果ではありません。SQLの形によって計画が変わることも確認できました。
また、ある検証環境ではNULL条件の抽出がタイムアウトしたため、別環境に切り替えて計測しました。値あり条件は短時間で結果が返りましたが、NULL条件では長時間待っても返らない場面がありました。ただし、両条件では取得対象の件数が大きく異なります。この時間差の原因は今回の結果だけでは特定できず、追加の調査が必要だと考えました。
今回の調査では、現状の索引構成について確認できたことまでを結論としました。そのうえで、索引を追加した場合の検証条件や実行計画の比較方法を整理し、次の調査用Issueの本文案として現行Issueのコメントに残しました。自分から手を挙げ、検証方法の設計から結果の報告、次の調査への引き継ぎまで経験できました。

目標に対する結果と学び

CPC移行に関わるタスクでは、7日間で9本のPRをすべてマージまで進めました。完了条件や背景を先に確認し、曖昧な点を早めに共有したことが、手戻りを抑えて進められた一因だと考えています。また、自分の作業範囲が終わった後、別の担当者にお願いする部分を切り分けて伝えることも、タスクを前へ進めるために必要でした。
レビューを通じて、AIを使って速く形にできても、入力ごとの動作やコードの読みやすさは自分で確かめなければならないと学びました。今後はPRを出す前に、想定外の入力でどう動くか、背景を知らない人にも意図が伝わるかを確認します。
自分から担当範囲を広げるという目標については、SQLの調査に手を挙げ、比較条件の整理から実行計画の確認、結論の報告まで進められました。一方で、やりたいことをもっと早く具体的に伝える余地もありました。関心のあるタスクとあわせて、今の自分にできることや、まだ分からないことを共有できれば、メンターとも仕事の進め方を相談しやすくなったと思います。
不慣れな言語やアーキテクチャのコードを読むときも、すべてを一度に把握しようとせず、今何を判断したいのかを明らかにすると理解が進みました。調査で比較条件を先に決めた経験にも共通しますが、作業を速く進めるためには、まず問いを具体的にすることが大切だと学びました。

おわりに

今回のインターンでは、任された改修を通じて、実装の正しさだけでなく、意図の伝わりやすさや変更理由の残し方を学びました。興味のある調査に手を挙げたことで、担当した改修だけでは得られなかった経験もできました。
ボトムアップで価値を提供できるエンジニアになるために、まずは目の前の仕事を理解し、確かめ、周囲が次の判断をしやすい形で残していきたいです。これからは、関心のある課題と自分にできることを早めに伝え、チームの改善にも自分から関われるようになりたいです。