はじめに
普段はスタートアップでSaaSの開発をしているtaroと申します。
私事ですが、2022年11月2日でソフトウェアエンジニアになってちょうど2年になります。
ちょうど良い機会ということで振り返りをした内容を、せっかくなので記事にしてみました。
自己紹介
本題に入る前に「お前だれだよ」ってことで少しだけ自己紹介です。
僕はシェルフィーという50名ほどのスタートアップで建設業界向けのSaaSを作っている、歴2年、26歳のエンジニアです。
修士まで理論系の物理学を専攻、その後新卒で半年ほど営業職を経験後、現職に転職して現在に至ります。
業務はフロントエンドやバックエンド等で分かれておらず、機能の仕様やデザインを考える段階から、設計、実装、テスト、リリースまで一通り担当していて、時々採用にも顔を出したりしています。
技術は特にフロントエンド、Reactが好きで、たまに記事を書いたりLTで話したりしています。
（よかったら覗いてみてください！）
では2年間を振り返っていきます！
入社後からの半年間
まずは入社後からの半年間です。
入社時の技術力
当時はいわゆる実務未経験勢で入社時の技術力はこんな感じでした。
- HTML, CSSは調べながら本当に簡単なWebページが作れるくらい
- Pythonのみ一通りの文法がわかりロジックが書ける（Paiza Sランク程度）
- フレームワークはDjangoだけ触ったことがある
- DBはデータを保存する場所くらいの理解度、SQLは書いたことがない
- コンピュータサイエンスの知識はほぼゼロ
今思い返すと「よく転職できたな…」というピヨピヨ感でした🐣笑
ちなみに転職活動時にポートフォリオとして公開していたサイトはこちらです。
当時はDjangoで作って必死にVPSに乗せてデプロイした記憶がありますが、静的サイトのためGitHub Pagesで十分だったことを入社後に知りました。
何もわからないまま当日から開発に合流
こんな右も左もわからないレベルでしたが、入社した11月が年明けの大型リリースを控えた直前だったこともあり研修期間はありませんでした。（現在はちゃんとあります！）
入社当日の流れは
- 午前10時に初出社
- 午前中に環境構築
- 午後から開発に参加
そして夕方には僕の書いたコードが大型リリース用のマスターブランチにマージされていました。
（たしか数行の文言変更とかだった気がします。）
当時は「開発ってこういうもんなんだ」と思っていましたが、今思い返すととんでもない状況です笑
その後も簡単なタスクにアサインされ、行き詰まったら先輩に質問して進めるといったスタイルで開発に合流しました。
ただ当然、何を任されてもどこから手をつけて良いかわからず、また先輩に教わっても会話中に登場する言葉の意味がわからないといった状態で、以下のような会話の毎日でした。
僕：「すみません、DBからデータを取りたいんですけどどうすれば良いんですか？」
先輩：「普通にクエリを書けばいいよー！」
僕：「クエリ…？クエリってなんですか？」
先輩：「あ、そっかー、えーっとDjangoのobjectsってのをこうやって書いてー」
僕：「ありがとうございます！（なるほど、これをクエリって呼ぶのかー）」
先輩はみんな優しく、遠慮なく質問できるのが本当に救いでした。ありがとうございます。
今思うと、調べたらすぐに解決できる気もするんですが、正しい用語がわからないためググることすらまともにできなかったのを覚えています。
バグでユーザーと仲間に迷惑をかけマネージャーに直してもらう
そんなこんなで訪れた大型リリースは、大きなバグが頻発する結果となりました。
僕が開発した機能も、他機能への影響がまったく考慮されておらずバグデータによる不具合を生みユーザーの業務を止めてしまいました。
そしてその影響範囲は広く緊急性も高かったため、当時の自分では対応できずマネージャーが対応するのを見ていることしかできませんでした。
自分のミスによってユーザー、問い合わせに対応するbizメンバー、対応するマネージャーや他エンジニアに多大な迷惑をかけた上にその尻拭いを自分でできないことがとても悔しかったです。
また当時、先輩エンジニアが僕を含めた若手エンジニアに向けた言葉が今でも心に残っています。
「お金を払っているユーザーがプロダクトを使っていることを忘れないでください」
至極当たり前のことなんですが、当時の自分はたしかにプロダクトの先にいるユーザーのことが見えていませんでした。
もしちゃんとユーザーやプロダクトを理解していれば、自分が作る機能がどのように使われどこに影響を与えるか想像し、影響範囲を考慮できたかと思います。
入社当初からマネージャーが 「技術も大事だけどまずは業界とユーザーのことをしっかり知ろう！プロダクトをちゃんと理解しよう！」 と話していたことの大切さを、この頃にやっと痛みとともに理解できました。
仕事としてエンジニアをする上で最も大切なことを学んだ半年間
入社からは怒涛の半年間でした。
そしてこの期間に仕事としてエンジニアをやる上で、とてもとても大切なことを学びました。
- ユーザーを第一に開発すること
- ドメイン理解が大切であること
この頃から実装前に
- 仕様をしっかりすり合わせる
- 影響範囲を洗い出す
- 事前にテストケースを作る
など、バグを生まないように仕事を進めるようになりました。
また日常的に書籍や動画、SNS、bizメンバーとの会話からドメインの理解を深め、ドキュメントやissueを読む、触り倒すなどで、プロダクト理解を深めるようになりました。
ちなみにこの時点での技術力はこんな感じです。
- コード品質は皆無だが任された機能を実現できるようになった
- React, TypeScript, reduxを使って画面が作れる
- Django, Pythonを使ってCRUDのAPIが作れる
- SQLでパフォーマンスを無視したCRUDのクエリが書ける
- Web開発に必要な道具が最低限使える
- git
- VSCode
- 開発者ツール
入社6ヶ月後からの半年間
次は入社6ヶ月後からの半年間です。
はじめてのプロジェクトマネジメント
入社してから約半年、バグ対応も少し落ち着いてきた4月から新しいプロジェクトにアサインされ、初めてPjMを任せていただきました。
プロジェクトの概要
- 期間：2ヶ月
- 人数：3人
- PjM×1
- エンジニア×2（内1人は1ヶ月ほど参加）
- 内容：法律に沿った書類電子化サービスの法改正対応
まず躓いたのは「やることの多さと優先度の付け方」です。
アサインされた時点でPdMが改正後の法律の内容と、ざっくりとした修正箇所はまとめてくれていたのですが、それでも
- 修正箇所を開発タスクに落とし込みアサインを決める
- 全体のスケジュールを引く
- 詳細な仕様決めとそのための調査
- 各所への共有
などやることが盛りだくさんですぐに管理しきれなくなりました。
その時にPdMからアドバイスを受けたのが複雑性との戦い方です。
（詳しくは「エンジニアリング組織論への招待」を参照）
当時の状況であれば、仕様が不確実だったり間違っていたりすると開発タスクがズレて全体スケジュールに影響が出てしまうので、まずやるべきは改正後の法律を念入りに調査して仕様を固めることでした。
他にも
- 1つのタスクが大きくなるとそれだけ不確実性が高まるので可能な限り小さくタスクを切る
- 実装に入る前にしっかりと設計や検証を行う
- 進め方の段階、モックの段階などの早い段階でステークホルダーと認識を合わせる
など、PjMやエンジニアとしてだけでなく全ての仕事を進める上で大切な「複雑性との戦い方」の基本をこの時に学びました。
ちなみにプロジェクト自体は多少の残業を除けば、人員の追加やスケジュールの遅れ、リリース後のバグが発生することもなく終わりとても嬉しかったです！
バグ対応最前線
上記のPJが終わった後は、当時社内で特急対応と呼ばれていた締切が当日〜1週間以内のバグ対応を担当していました。
業務の流れ
- ユーザーからの問い合わせにbizメンバーが対応
- バグの可能性があるものは特急担当(僕)に共有
- 原因を調査し、データやコードを修正後、bizメンバーを通してユーザーに連絡
バグ対応をする上で特に大切にしていたのは以下の2つです。
- すでに不具合を被っているユーザーへの対応のため、絶対に失敗しない
- ユーザーがやりたいことを正確に理解し、最短で業務を再開できるようにしてから根本解決
一見、精神的負荷が高く大変な仕事のようですが、その反面bizメンバーやユーザーから感謝される役割で個人的にはとても楽しくやっていました。
プロダクト全体に対するバグの対応をする中で自然とプロダクトのソースコードの理解も深まり、また1人で受け持っていたため優先順位や対応方法、バグ対応の仕組みなどを全て自分の責任範囲で決めて改善を回せたのがとても楽しかったです。
一人で色んなことができるようになった半年間
入社後半年から1年の間は、PjMをやバグ対応と一人で色んなことを考えてできるようになった半年間でした。
この期間に学んだことは
- 複雑性との戦い方
- ユーザーがどんな風にプロダクトを利用しているかの実態
- プロダクト全体のソースコードの状態
などです。特に複雑性との戦い方は本当に色んな場面で生きる考え方で、今でも悩む度に「エンジニアリング組織論への招待」を見返しています。
またバグを直し続ける中で徐々に「そもそもバグを生まず、修正のしやすい綺麗なコードを書けるようになりたい」とコード品質への気持ちが高まっていきました。
当時の技術力は半年前とさほど大きな変化はなかったと思いますので省略です。
入社1年後からの1年間
最後は入社1年後からの1年間です。
負債の解消をはじめる
特急担当としてのバグ対応が一段落ついた後は、1年ほど負債を解消するプロジェクトにアサインされ
- 概念が正しく反映されていない仕様の変更
- 再モデリング
- 画面の変更
- コードのリファクタリング
- バグデータの修正
を担当していました。
アサインされた当初の僕は「単一責任にする」「命名で嘘をつかない」くらいしかコード品質への理解がなく、テストコードもほとんど書いたことがありませんでした。
最初のissueではテックリードからペアプロでオブジェクト指向でのプログラミングを教わり、モデリングをする際にはバグ対応などで身につけた知識が活かされ、ドメイン理解の重要性を再認識したのを覚えています。
またこの頃から必要に応じてではなく体系的に技術を学ぶようになりました。
フロントエンドへのモチベーションが高まる
今ではフロントエンドがとても好きでよく勉強しているのですが、興味を持ったのはこの時期からでした。（2021年12月くらい）
きっかけは負債を解消するためにおこなった巨大なComponentや無理に共通化された型、stateのリファクタリングです。
弊社はReact,TypeScript,reduxを使っているので、公式ドキュメントやりあクト！シリーズを再度読み直したり、技術記事を読み漁ったり、Reactや関連ライブラリのソースコードを読んだりしていました。
社内のフロントエンド状況を改善できる方法をたくさん知り、それを他のメンバーにぶつけてみたり社内LTで話したりするようになりました。
社内LTで話した内容の一部
フロントエンドのリファクタリング自体は、当時の僕ができる限りで責任を分けて可読性を高め元々の状況と比較すると変更容易性を高めることができました。
そしてリファクタリングや社内での発信を通じて、他のプロジェクトのメンバーから「taroのコードをフロントエンドの実装の参考にしてる」と言ってもらえたり、「swrいいね！」「Suspense早く使いたい！」と言った声が聞こえるようになったのが何よりも嬉しかったです！
実務未経験で入った自分としては技術力への不安がずっとあり、初めての自信となる出来事でした。
技術記事の投稿や社外LTへの登壇を始める
記事投稿をはじめたきっかけは、社内LTでフロントエンドの話をする中で「せっかくまとめたんだし公開してみるか！」といった軽い気持ちです。
記事を投稿する中で少しずつ反応が増え、Twitterを通して社外のエンジニアの方々から少しずつ絡んでいただけるようになりました。
特にReactのmemo化に関する記事はいつも記事などの発信を参考にしている有名なエンジニアの方にも読んでいただけてとても嬉しかったです。
社外LTへの参加も「社内でやってる人いないし、試しにやってみるか！」と勢いで申し込んだのがきっかけでした。LTでは交流会などで他社のエンジニアの方々と開発の話をできるのがとても刺激的で楽しかったです。
またQiita Engineer FestaというイベントではReactのSuspenseに関する記事で賞とQiitanのぬいぐるみをいただきました。
学んだ知識を業務へと昇華する
直近は、既存アプリケーションの機能刷新＆負債解消のプロジェクトにアサインしていただき、今まで学んだ知識を実務で試しています。
直近1~2ヶ月は機能要件を進める傍ら、フロントエンドのコード品質と開発者体験を高めるために
- UIの単位で分けられ単一責任で疎結合なComponent設計の浸透
- ライフサイクルを軸とした状態管理設計の浸透
- Reactの思想に基づいた宣言的な実装の浸透
- Custom Hooksの導入
- ESLintとPrettierの設定
- hygenによる雛形生成の導入
- 機能ベースのディレクトリ設計を整える
- JavaScriptのTypeScript化
などをやってきました。（もちろん同じプロジェクトのメンバーの力を借りながら進めています）
これまではアプリケーション内の統一性や優先度が理由で、学んだ知識を中々活かせずもどかしいところもありましたが、現プロジェクトで一気に昇華でき実践経験によって解像度も高まりました。
最近は同じプロジェクトのメンバーが「フロントエンドの開発楽しい！」「やっとReact使ってるって自信持って言える！」と伝えてくれるのが何よりも嬉しいです！
採用にも参加した
開発とは少し離れますが、この1年間は面談やスカウトを通して採用にも参加していました。
特にエンジニアの1次面談のメイン担当として、会社や事業、組織、プロダクトといった上流の話から現場の実情までを正しく伝え候補者をアトラクトする役割は、社内の最新の情報を高い解像度で理解する必要があり、本当に学びが多かったです。
またスカウトでは、候補者に向き合いレジュメから「これまで何を考えてきて、これから何をしたいのか」に思いを馳せながら、一球入魂のメッセージを書いていました。
実際にやってみると候補者一人一人に向き合ったメッセージを書くのはとても大変です。
しかしその分自分が書いたスカウトメッセージが選考に繋がった時は本当に嬉しいです。
現在の開発チームには僕が書いたスカウトメッセージがきっかけで入社してくれたメンバーもいて、その内定が承諾された瞬間がこの2年間で1番嬉しかった瞬間だったかもしれません。
やりたいことや目指す地点が見えてきた1年間
エンジニアになって2年目の1年間は、フロントエンドという自分が好きで伸ばしたいと思う領域が見えてきた1年間でした。
1年前にはそんなことは全く思わず、なんなら「ものづくりに楽しく関われるならエンジニアじゃなくてもいいかなー」と考えていました。（1on1でPdMやりたいとか言ってたような気がします）
またフロントエンドを含む技術全般に関しては、知れば知るほど今はもっと基礎をしっかりと学ばなければと感じ日々勉強を続けています。
そして社外の情報に多く触れたことにより、何事においても目指す状態がとても高くなったと感じています。
入社当初からマネージャーが「俺らや既存メンバーを目標にするな、世界にいるもっと強いやつらを目指せ」と言っていた言葉を、2年経ってやっと自然な行動に移せるようになりました。(すみません笑)
目標としては事業会社でフロントエンドを一任できるエンジニアになりたいと考えています。
そのためにはフロントエンドだけでなく他領域も一通りわからないと務まらないので、得意領域を伸ばしつつも一定レベルまでは他の領域もしっかりと力をつけていきたいです。
そして優れたユーザー体験と楽しい開発者体験のものづくりができる人になっていきたいです。
おわりに
最後に2年間を振り返って感じたことですが、とにかく環境に恵まれていました。
- 長期で大切なことを伝えてくれるマネージャーや先輩エンジニア
- 安心して挑戦できる会社
- 優秀な同期(偶然ですが中途にも関わらず同期が4人いました)
- bizチームと開発チームの高い信頼関係
本当に恵まれています。
今思うと本当にピヨピヨだった自分がよくこんな環境に拾ってもらえたなと思います。
（採用されていなかったらどうなっていたんでしょうか笑）
これからはエンジニア3年目として段々責任も大きくなってきますが、引き続きがんばっていこうと思います！
Twitterでも開発や技術の話をつぶやいているので、気軽にフォローしていただけるととても嬉しいです！
記事の内容に関する感想や質問等もぜひお待ちしてますー！
以上、最後まで読んでいただきありがとうございました！