エンジニア2年目になって学んだこと
エンジニア2年目になって学んだこと
どうも、Flutterエンジニア2年目のピヨ助です。
この記事では、自分がエンジニアになってから「これは大事だな」と感じたこと、日々の仕事の中で学んだことをまとめてみました!
ざっくり経歴
まずは軽く自分の経歴を。
- 大学でプログラミングの基礎を勉強
- Flutterでアプリを個人開発したり、技術記事を書いたり
- そのアウトプットをもとに就職
- Flutterエンジニアとしてキャリアスタート🏃♂️
こんな感じで、最初からFlutterメインでやってきました。
正直、バリバリ競プロやってた！とか、他言語も触れます！ってタイプじゃなくて、
「Flutterにハマって、アプリ開発って楽しい🤪」って感じでここまで来たタイプです。
AIのコード、説明できないなら使うな！
ChatGPTとかでコード書いてもらうの、めちゃくちゃ便利ですよね。
自分も入社したての時はバンバン使ってました。というか、使いすぎてました。
で、ある日こんなことが起きました。
🥸(上司)「このコード書いてくれたの君？ちょっと説明してもらっていい？」
🤪(自分)「えーと、コメントに書いてる通りで……（内心：動作確認で動いたし…）」
🥸(上司)「……やり直し。理解してないコードは使わないで。」
🔥「説明できないコード = 理解してないコード」
これ、めちゃくちゃ危ないです。
たとえば、自分の書いたコードで重大なバグが起きたときに
「え、これAIが書いたんで」って言い訳できますか？絶対ダメですよね。
もちろんAIは便利だし、自分も今でも普通に使ってます。
でも、生成されたコードは理解できるコードしか採用しない
人に説明できないコードは使わない。これが大事です。
AIがすごいからコードの勉強なんてそんなしなくていいや🤪
絶対ダメです。
コードの書き方を学んでおくと、AIへの指示（プロンプト）の質も上がって回答の精度も高くなります。
✍️ AIが書いたコードを「使う」のと「理解して使う」のは全然違う！
入社したてのメンティーの時にやってました。今思い返すと恐ろしい💀
他の人が関わるタスクは、最優先で！
タスクをいくつか振られたとき、
「どれからやろう…とりあえず簡単そうなやつから手をつけよ！」
ってなりがちじゃないですか？
あなたならどんな進め方でタスクを消化していきますでしょうか？
💡 他の人が関わるタスクは、なるべく最優先で進めたほうがいい！
たとえば、こんなタスクありません？
- 先方に確認が必要そうなやつ
- バックエンドの人に調査をお願いしないと進まないやつ
- バグの起因がアプリじゃなくて、そもそも別のチームの問題かも…？ってやつ
こういうのって、自分ひとりで完結できないので、確認とか返事待ちが発生します。
で、ギリギリに依頼するとこうなります↓
「調査お願いしてたやつ、まだ返ってこなくて…それで遅れました🤪」
これ、言われた側はたぶんこう思うんですよね：
「いや、それもっと早く依頼しといてくれよ😡」
だから、タスクもらったらまず最初に
「これ、誰かと連携しないと進まないやつある？」 って視点で見てみるのがおすすめです。
依頼系・確認系を先に片付けておくと、
その間に自分でできるタスクも進められるし、結果的にスムーズに進みます。
🚀 自分だけで完結しないタスクこそ、早めに動いておこう！
これ、地味だけどめちゃくちゃ効きます📚
タスク期限は“逆算”して考えよう！
「このタスク、金曜日までにお願いします〜」
って言われたとき、
「じゃあ金曜に間に合えばOKっしょ！」って思ったこと、ありません？
でも、それだとだいたい間に合わなくなります笑
自分のチームでは、タスク完了の定義が「QA（テスト）通ってOKもらうまで」なんですよね。
だから、動作確認してもらう時間とか、PR（コードレビュー）での修正も含めると…
⏰ 実際の“自分の作業リミット”はもっと早い！
たとえば：
- 金曜が本当の締切だとしたら
- 木曜にはQAさんに渡したい(バグあった時にまだ間に合う！)
- 水曜にはPR出してレビューしてもらいたい(FB対応があるとしたら最低でも水曜の午前くらい！)
- 月・火の間に相談・調査を終わらせておきたい
こんな感じで逆算スケジュールを頭の中に作って動くようにしてます。
あと、もしタスクをやっていてスケジュール的にキツそうなら、
できるだけ早めにPMやリーダーに相談！
「このペースだと厳しいかもです…」って早めに伝えておくと、
スケジュールの調整も効くし、何より印象が全然違います。
💡ギリギリで「間に合いません🤪」より、
早めに「ちょっと期限だと厳しいかもです」って言える方が100倍信頼される！
スケジュールは、自分だけじゃなくチーム全体に影響するんで、
逆算で動く癖つけとくとめちゃくちゃ楽になりますよ！
リカバリー案って大事！
開発してると「こういうの作ってほしいんだけど〜」って
先方やPMからふわっとした要望をもらうこと、結構あります。
で、その中にはたまに
「え、それ結構むずいな💦」
「技術的には可能だけど、めっちゃ時間かかるぞ…」
ってやつも混ざってるんですよね。
そんなとき、昔の自分はこう言ってました。
「その実装はちょっと難しいです🤪」
「この仕様は厳しいかもです🤪」
これだけだとちょっと残念な印象になります。
💡 大事なのは“代わりにこうならできます！”って伝えること！
たとえば：
- 「〇〇って仕様は難しそうですが、こういうパターンなら対応できます」
- 「こっちのUIなら簡単に実装できます、こんな感じです（スクショ付き）」
って感じでリカバリー案（代替案） を出すと、相手もめっちゃ助かります。
「なるほど、じゃあその案でいきましょう！」ってなるし、
もしそれもダメだったとしても、建設的な会話ができます。
🙌 “実装できる or できない”だけじゃなくて、
“どうすれば実装できそうか”をセットで伝える
これができると、信頼してもらえるようになります！
自分もまだまだなんですけど、
「できません」じゃなく「こっちならできます！」って提案できるようになるのを目指してます😤
おわりに 〜まだまだ勉強中だけど、伝えたいこと〜
ここまで読んでいただき、ありがとうございました！
今回書いたことって、正直「当たり前やん」って思う人もいるかもしれません。
でも、実際に現場で働いてみて、その“当たり前”をちゃんとやるのって意外とむずい…！
って感じたことばかりです。
エンジニア2年目の自分が、実際に体験して
「これは大事だな〜」「これはもっと早く知りたかったな〜」って思ったことを
なるべくリアルに、素直に書いてみました。
まだまだ未熟なところも多いですが、
この記事がこれからエンジニアになる人や、1年目の方のヒントになったらめっちゃ嬉しいです！
✅ 最後に大事なことまとめとくと…
- AIのコードは理解してから使う！
- 他の人が絡むタスクは即・先に動く！
- 期限は逆算して動く！
- 難しい要望にはリカバリー案を出す！
エンジニアって、ずっと学びの連続だけど、
ちょっとずつ「できること」が増えていくのがめっちゃ楽しい仕事だな〜って思ってます。
これからも一緒にがんばっていきましょう！💪🔥
Discussion