「答え」ではなく「考え方」をー未経験エンジニアがメンターに感謝していること3つ
この記事は、ファインディエンジニア #1 Advent Calendar 2025の9日目の記事です。
はじめに
こんにちは、ファインディでエンジニアをしているなかじです。
私は、新卒から4年税関職員として空港などで薬物の取り締まりをしたのち、プログラミングスクールを経て、ちょうど1年前の12月にファインディに実務未経験のエンジニアとして入社しました。
そんなひよっこエンジニアが入社して約半年ほどお世話になったメンターに感謝していることを書いていきます。これから未経験エンジニアになる方や、受け入れる方の何らかヒントになれば嬉しいです。
目標設定
入社して初めての評価期間でたてた目標で、最も重要視していたのが「チーム開発行う上での自走力がある状態にする」でした。
「早くチームの戦力になるぞ🔥」という気持ちは満点、ただ「自走できる」だけだと、一体何ができたら「自走できてる」状態であるのかわからず、目指す方向もどうしたら評価されるのかもよくわかりません。
そこで、この「自走できる」という状態をより具体的な内容に落とし込んでいく作業をメンターと一緒に行いました。それで、より具体的な数値や状態として下記のような内容が出てきました。
- タスクの分解ができて実装ができる
- 振られたタスクを自分で分解し、実装の道筋を立てられる
- 分解したタスクを踏まえて実装できる
- 不明点があったら適切なタイミングでヘルプを出せる(大事なことです)
- マージまでの時間を短縮できる
- 自分の作ったコードに対してのレビューが減っている
- レビューしやすいようPRを小さく作ることができる
- 期末にはレビューができる
- 他のメンバーのコードをレビューし、建設的なフィードバックができる
このように数値化・具体化することで、「今自分はどこまでできているのか」「次に何を習得すべきか」が明確になりました。開発しているバックエンドのリポジトリに関する理解を深めて実装する、またそこで必要となった知識を習得していけば良いということがわかりました。
目標自体の内容もそうですし、目標設定に関して「こうやって考えればいいのか」という方法論も含めて一緒に知ることができたのがよかったと感じています。
ペアプロ
そもそもどのように実装しているのかやデバックの仕方から量の多いデータの取得や更新時に注意すべき点、開発するリポジトリのアーキテクチャなどなどたくさんのことをペアプロを通じて学びました。忙しい中、こうして時間を割いてもらったことには感謝しかないです。
目標の「タスクの分解ができて実装ができる」や「マージまでの時間を短縮できる」はそもそも既存のコードへの理解が不可欠だと感じていますが、経験あるエンジニアとのペアプロは個人的に最適解だと感じています。基底クラスの実装がどのようになっているのか、設計のパターンなど幅広い知識から次自分がどんなことを知っていけばいいのかのヒントになったという点で、ただAIに設計の説明してもらうのとは違った学びもあったのだなと今振り返って思います。
1on1
元々設定した目標の達成状況を確認していましたが、それに加えてちょっと先に目指すところに向けた準備もやっていました。例えば、期末にレビュワーになるという目標に向けて、コードレビューの基準を教えてもらったり、最初チーム内レビュワーに追加してコードを読む習慣をつけようと提案してもらったりしました。
加えて自己学習で何をしたらいいかを相談する場にもなっていました。主軸がバックエンドエンジニアということで、SQLに関する理解を深めたいとSQL 第2版 ゼロからはじめるデータベース操作を読んでいたのですが、Active Recordでそのクエリを出すにはどうしたらいいかの観点で読んでみたらおもしろそうじゃない?と提案してもらい実践してました
個人的にこの学習方法良かったのでおすすめです。参考までに一部分載せておきます。
SQLとActive Recordを関連づける
pp139~145 トランザクション
- トランザクションとはセット(ひとまとまり)で実行されるべき1つ以上の更新処理のこと
- トランザクションの処理を終わらせるコマンドは
COMMIT(処理の確定)とROLLBACK(処理の取り消し)のふたつ - DBMSのトランザクションは原子性(Atomic)、一貫性(Consistency)、独立性(Isolation)、永続性(Durabilityという4つの約束ごとがあり、ACID特性と呼ばれる
- 例えばMy SQLでカッターシャツを1,000円値引きし、Tシャツを1,000円値上げする処理は下記のように書ける
START TRANSACTION;
# カッターシャツの値下げ
UPDATE Shohin
SET hanbai_tanka = hanbai_tanka - 1000
WHERE shohin_mei = "カッターシャツ";
# Tシャツの値上げ
UPDATE Shohin
SET hanbai_tanka = hanbai_tanka + 1000
WHERE shohin_mei = "Tシャツ";
COMMIT;
デフォルトでは、MySQL は自動コミットモードが有効になった状態で動作します。 つまり、特にトランザクション内にない場合、各ステートメントは
START TRANSACTIONおよびCOMMITで囲まれているかのようにアトミックです
→明示的に指定しなくてもよい
START TRANSACTIONを使用すると、そのトランザクションをCOMMITまたはROLLBACKで終了するまで、自動コミットは無効のままになります。 そのあと、自動コミットモードはその以前の状態に戻ります。
→START TRANSACTION を指定する場合は、終了を明示的に書く必要あり
- COMMIT:処理が一直線に流れる感じ
- ROLLBACK:スタート地点に戻る
🛤️Railsでやってみる
- Active Recordでトランザクションかける
# クラス
Account.transaction do
balance.save!
account.save!
end
# モデルのインスタンスメソッド
balance.transaction do
balance.save!
account.save!
end
irb(main):030* user.transaction do
irb(main):031* user.update!(first_name: "Bob")
irb(main):032* user.projects.update!(name: "projectX")
irb(main):033> end
TRANSACTION (0.1ms) begin transaction
User Update (0.4ms) UPDATE "users" SET "updated_at" = ?, "first_name" = ? WHERE "users"."id" = ? [["updated_at", "2025-02-25 14:12:59.093669"], ["first_name", "Bob"], ["id", 22]]
Project Exists? (0.1ms) SELECT 1 AS one FROM "projects" WHERE "projects"."name" = ? AND "projects"."id" != ? AND "projects"."user_id" = ? LIMIT ? [["name", "projectX"], ["id", 2], ["user_id", 22], ["LIMIT", 1]]
Project Update (0.1ms) UPDATE "projects" SET "name" = ?, "updated_at" = ? WHERE "projects"."id" = ? [["name", "projectX"], ["updated_at", "2025-02-25 14:12:59.095749"], ["id", 2]]
TRANSACTION (0.1ms) commit transaction
=>
[#<Project:0x0000000140ffda20
id: 2,
name: "projectX",
description: "A test project.",
due_on: Mon, 03 Feb 2025,
created_at: Mon, 27 Jan 2025 12:50:26.327831000 UTC +00:00,
updated_at: Tue, 25 Feb 2025 14:12:59.095749000 UTC +00:00,
user_id: 22,
completed: nil>]
まとめ
「未経験エンジニアがメンターに感謝していること3選」という内容で、目標設定、ペアプロ、1on1と書いてきました。この3つに共通するのは、答えを教えてもらうのではなく、考え方や方向性を示してもらえたことです。「どう実装するか」よりも「どう学ぶか」「どう考えるか」を学べたことが、非常に大きな財産になったと思いますし、キャリアの最初で尊敬できるエンジニアに出会えたのはラッキーだったなと思います。
ちょっとでも参考になる内容があれば嬉しいです⭕️
Discussion