10
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

株式会社うるる(ULURU)Advent Calendar 2024

Day 20

未経験からエンジニアになって半年。半年前の自分に届けたい"3つのこと"

Last updated at Posted at 2024-12-19

はじめに

この記事は株式会社うるる(ULURU)Advent Calendar 2024 の20日目の記事です。

株式会社うるるでバックエンドエンジニアをしている松下です!
今年の4月に営業職からエンジニアへ転向し、気がつけば半年ほど経ちました。エンジニアとして働く中で「大切だな」と思ったことや「もっとこうしておけば‥」などの反省を実体験を元に書いてみました。実際に従事したプロジェクトの具体的な中身や、技術的な話は本記事には含めず、あくまでポエム・自己の振り返り記事となります。

本記事の主な対象者

  • 未経験からエンジニアに転向したばかりの方
  • これからエンジニアを目指す方
  • 職種問わず、新卒1〜2年目の方

書かないこと

  • 技術的なノウハウや内容
  • 何かの事象に対する答え
  • あるべき論や絶対的な正解

あくまで、私自身の原体験をもとに書いたものです。ごくごく当たり前のことが多いですが、同じような境遇の方に少しでも参考になれば幸いです。

簡単な自己紹介

  • 文系学部卒 → 2021年4月に営業職(カスタマーサクセス)として新卒入社
  • あるきっかけを機に2023年6月から本格的にプログラミング学習をスタート
    • 社内VPoEと毎週1on1
    • 定期で簡易試験を実施(SPAを作成し成果物を提出)
  • 2024年4月から同社内のバックエンドエンジニアに転向
  • ジョイン後、主に以下に従事
    • LLMを使用した新機能の開発
    • GraphQLへの移行
    • 障害対応 など
  • 現在はユーザーから頂いた声を元に新機能の仕様決定や開発をメインに担当

結論(お伝えしたいこと)

  • 適切にアラートを出す
  • 今の自分でできることをやる、強みを作る
  • 目的意識を持ち続ける

適切にアラートを出す

困難なタスクに直面した時、自分で抱え込みすぎてしまった経験、ありませんか?
かくいう私も、エンジニアになって3ヶ月のタイミングで、大きな壁にぶつかりました。

ある日、急遽「LLM(Gemini)を使用した社内向けの新規機構の開発」のタスクを自分に任せてもらうことになりました。多少の不安はあったものの、「よっしゃ!!やったるぞ!!」と意気こんでいたのは束の間、他の先輩メンバーらはメインの大型プロジェクトで手一杯。
つまり、設計から実装まですべて一人で進める必要がありました。

そんな当時の私の技術レベルはというと、

  • 簡単なCRUD処理なら調べつつなんとかこなせるレベル
  • イチからの設計経験ゼロ
  • 「queue?? なにそれ美味しいの??」といった開発基礎知識もおぼつかない

言わずもがな、上記の状態の自分にとってはとても高いハードルで、そもそもの設計段階から躓いていました。

● 焦りと不安で押しつぶされた「25(歳)の夏」

それでも、周りのメンバーにアドバイスやフォローいただきながら、「PostmanでAPIを叩き、Geminiへリクエストを送りレスポンスを確認できる」ところまでは到達したものの、

  • そもそも仕様や運用が不明瞭で、自ら関係者とのすり合わせをして決めていくことが必要
  • 社内向け機能とはいえ、明確な納期がある
  • 同時期に別の新機能のバックエンド側の設計・実装も並行して担当予定

といったように、まだまだ経験も浅く独力で業務が遂行できない当時の私にとっては苦しい状況が続き、常に「本当に自分で全てやりきることができるのか?」といった焦りと不安に毎日かられていました。

そんなある日、上司からこう告げられます。
「新規実装PJの担当からは外すので、目の前の個人PJは完遂しきってほしい」

この結果は客観的に見ると妥当でしかなく、むしろその判断を早めに自分から提案や相談ができず、周りのメンバーにまで気を遣わせてしまっていました。それに対する周囲への申し訳なさや、自分自身に対しての不甲斐なさや悔しさの感情でいっぱいでした。

● 早めのアラートは恥ずかしいことではない

この実体験から、「適切にアラートを出す」ことの重要性を痛感しました。
特に自分のような、まだ経験が浅いうちは特に大切だと感じます。もちろん、分からないものを自分で考えたり調べずに、すぐ聞くのは避けた方が良いと思います。

ただ、「一人で抱え込んでかなりの時間を溶かすくらいなら、早めに相談やアラートを出して間違った努力に時間を割かないようにする」のは非常に大切です。

環境や状況によって多少なりとも左右されるので、塩梅は難しいところですが、少なくとも自分のような抱え込みすぎてしまう状態は、結果的にプロジェクト全体の進捗が止まり、納期に影響を及ぼしてしまいます。そのようなことは避けた方が良いのは言わずもがなです。

まとめ

  • 適切にアラートを出すのも仕事の1つ
  • 自分なりに考えた上で困難を感じたなら、早めに周囲へ相談し、正しい方向へ進む努力をする

幸いにも私の周りには相談しやすい人ばかりです。
今後は遠慮せず、「困ったら早めに声を上げる」 ことを徹底していきます。

今の自分にできることをやる(=強みを作る)

2つ目は「今の自分が組織にどう貢献できるのか?」 を常に問い続けることです。
私は営業職から未経験でエンジニアとしてジョインしたバックグラウンドがあったため、「今の自分にできること」に人一倍こだわりを持っていました。

この半年間、私が重きを置いて意識的に取り組んだのは以下の2つです。

リリースや障害発生時の各種営業部との主連携
営業サイドから頂く社内問い合わせへの早期キャッチアップ、対応巻取り

「いやいや、そんなの誰でもできるでしょ?」と思われるような当たり前なことではありますが、ここに自分だからこその強みを見出すことができました。

自分はもともと営業組織に身をおいていたバックグラウンドから、
・各部署とのメンバーとコミュニケーションが取りやすい
・合意形成の勘所やキーマンがなんとなく分かる
・障害や問い合わせ内容に対し、過去の対応記憶を頼りにできる
といった武器を持っていたので、率先して得意な領域の対応を巻取りさせてもらっていました。

● なぜこの動きを大切にしたのか?

組織を軸に自分を客観視した時に、「他のメンバーが実装に集中できるように、自分がなるべく簡易な問い合わせ対応や各種連携対応の巻き取りを行うべきだ」と自分では思っていたからです。(決して誰かからそう言われたわけではありません)

少し自虐的な表現になりますが、納期が迫っている大型PJ前に近づくにつれ、組織全体を考えた時に、自分は「上記の動きを率先的にやることが、一番最適である」と思い、自分を客観視した上で行動していました。

その結果、PJ終わりには自分のその動きを褒めてくれたり、感謝の意を頂く機会がありました。少しでも組織に貢献できたという点で、個人的には嬉しかったです。
※ もちろん、今後もずっと問い合わせ対応に全振りするのは避けたいところです。

まとめ

  • 「今の自分が組織にどう貢献できるのか?」 を常に問い続けること
  • 今の自分にできることを積み重ねること

「これくらい誰でもできるし…」と自分の貢献を軽視してしまうこと、ありませんか?(自分はかなりありました)しかし、小さな誰でもできそうなタスクを率先して動く人は意外と少ないと思います。今、目の前にある小さなタスクにも「自分なりの付加価値」 を加えながら取り組んでいけば、自然と自分の強みになっていくはずです。

目的意識を持ち続ける

最後は、「自分の目の前のタスクや出来事に対して、常に目的意識を持つこと」 です。
(エンジニアに限らず、全職種共通の大切な考え方ですね!)

● 「なんとなく」でコードを書いてしまっていたあの日

エンジニアとして働き始めてから、スプリントごとに実装タスクが明確になり、それに対し手を動かす日々。そんなある日、自分が対応した実装タスクのレビュー時に、レビュアーからこう言われました。

「なんでこの実装方針にしましたか?」

お恥ずかしながら、「なんで?」という質問に、自分の言葉で説明できませんでした。
「▲▲を〇〇にする」という完了の定義しか捉えておらず、そもそもの目的やタスクの全体像がぼんやりしたまま不明瞭な状態で進めたことが原因です。その結果、チーム全体の時間をそのレビューに多く割いてしまったり、結果的に手戻りになったりする事象がありました。

● 「Why So?」で目的を掘り下げる

こうした実体験から、 先輩エンジニアたちがよく使っている「Why So?」を自分も改めて意識して、取り入れるようにしました。
============
・なぜこのタスクやるんだっけ?
・そもそもの〇〇の目的って何だっけ?
・なぜこの実装にしたんだっけ?
etc...
============

上記を常に自問自答して納得いくまで自分の中で掘り下げるようにすると、軸がブレずに仕事が進みやすくなります。実装タスクなどの場合は、まず着手する前にタスクの目的などをnotionにバッとなぐり書きし、全体像をある程度掴んだ状態で進めるようにしたり、MTGなどは、議論が進む中でも「なぜ?」「そもそも〜?」のフレーズを念頭に置きながら話を進めるようにしています。

そうすることで、目的がそもそも理解できてない場合は早めに聞きに行ったり、「〇〇で実装という風に他の人から言われてたけど、そもそもの目的を考えると▲▲で進めた方が、ユーザーへの価値提供が高まりそうだな、提案してみよう。」のように、より視野を広げながら仕事を進められるケースが以前より増えました。(まだまだ思考の深さや幅は狭いですが...)

● よくある注意点

最初に「考えすぎて手が止まる」ことはなるべく避けるように気をつけましょう!
考えた気になって、「意識したけども行動に移してない」となると、あまり効果的ではないので、この点は特に注意が必要です。(実際、私自身も「考えた気になって満足する罠」に何度もハマっています…!)
目的を掘り下げるのは重要ですが、行動をセットにすることが何より大切だと思います。

まとめ

  • 手を動かす前に目的を明確にする
  • 「Why So?」を自分に何度も問う

「なんとなくやる」「言われたまま動く」ではなく、トヨタ式のなぜなぜ分析のように「なぜ?」 を問い続けることで、仕事の質は確実に変わります。

自分の技術的な力不足でタスクの全体像を掴むのが難しかったり、時間がかかる場合もありますが、そもそも目的を把握していないと、目的から逸れた部分に時間を使ってしまうような、意味のない努力をしてしまうケースが増えると思います。

この「目的思考を持って仕事をする」ことは、営業時代でもよく言われていたことだったので、自分もできているつもりだったのですが、職種が変わり新しい動き方になると、ついつい目の前の狭い領域内のみの考えになりがちでした。どの職種でも当てはまる、社会人としてのイロハ的な要素なので、ぜひ「そういえば自分も目的思考できてないかも...」という方がいれば、ぜひ参考にしてみてください。

さいごに

改めて、この記事でお伝えしたい3つのポイントを振り返ります。

  • 適切にアラートを出す
  • 今の自分にできることをやる
  • 目的意識を持ち続ける

どれも「当たり前」と言われがちなことですが、これらは私自身がこの半年間で学んだ原体験に基づく教訓です。

未経験からエンジニアへジョブチェンジしてからの期間は、「自分の技術力、まだまだ足りない…」「チームに貢献できているのかな?」と、自分の力不足に悩む日々が続きました。(正直、今でも悩みは尽きません…笑)

しかし、今の自分にできることを愚直に積み重ねることで、少しずつ前進している実感があります。周りのメンバーや恵まれた環境に感謝しながら、楽しく成長していく姿勢を忘れず、これからも精進していきたいと思います。

この記事が、自分と似た境遇で悩んでいる方や、これからエンジニアを目指そうとしている方にとって、少しでも共感や参考になる部分があれば、これ以上嬉しいことはありません。
最後までお読みいただきありがとうございました!

明日は期待の超大型新人(物理)の @moke_web 君です!
お楽しみに!✨️

10
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
10
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?