はじめに
こんにちは、株式会社 COUNTERWORKS のいない(@yusuke_blog1026)です
先月（2023 年 11 月）で COUNTERWORKS に入社してちょうど半年が経ちました。
できることの幅は少しずつ広がっていますが、先輩エンジニアと比べるとまだまだだなぁと感じる部分が多く、日々実力不足を痛感しています。
ただ実力不足とはいえ、会社になんとか貢献しようと自分の中で色々と工夫してここまでやってきました。
今回はそうして試行錯誤してやってきたことの中で 「これはやっておいてよかったなぁ」 と思う取り組みを、簡単にではありますがいくつか紹介したいと思います。
すぐに真似できるようなものばかりですので、
- 入社したばかりの駆け出しエンジニア
- まだ入社していないけど、エンジニアとしてやっていけるか不安を感じている方
- Web 系エンジニアを目指そうと思っている方
などの参考になれば幸いです。ぜひ最後までご覧ください。
🧑💻 入社前の技術レベル
本題に入る前に、簡単に入社前の技術レベルと入社して半年間でどのようなことを行ってきたのか？について軽く書いておきます。
いわゆるプログラミングスクール卒の実務未経験勢で
- 基本情報は取得済み
- Rails ちょっとわかる（スクールのカリキュラムに毛が生えた程度）
- TypeScript, React, Next.js といったフロントエンド周りは Rails よりは多少わかっているつもり
- Git, GitHub, Docker などのチーム開発で必要な知識は最低限知っている
- インフラは AWS のクラウドプラクティショナー、Linux の LPIC1 を取得済み
- コンピュータサイエンス領域に関しては、CPU, コンパイラ, OS の自作をしたことがあるくらい
こんな感じのレベル感でした。
特に React の「宣言的 UI」「関数型プログラミング(ちっく）」な思想がとても好きだったこともあり、フロントエンドエンジニアとして就職活動を行い、採用していただきました。
ちなみに就職活動時に作成した個人開発アプリはこちらです。
（現在記事の更新は止まっています。）
📌 半年間どんなことをやっていたの？
そんなこんなで今年 6 月から COUNTERWORKS にてフロントエンドエンジニアとして働き始めたわけですが、この半年間は主に商業施設向けリーシング DX システム「SHOPCOUNTER Enterprise」の開発に携わっていました。
いわゆる「管理システム」のようなものを開発しており、その特性上入力フォームの実装などに主に取り組んでいます。日々の機能開発においては、具体的には入力フォームの新規実装や機能拡張、EFO（フォーム最適化）、その他 UI/UX 向上のための画面づくりなども行っています。
また実装面だけでなく、 運用保守に関わる部分やリリース作業、基盤（インフラ）、果ては採用にも関わらせていただき、「フロントエンド」という枠組みを超えた様々なことを日々経験させていただいています。
以上が前置きです。ここからが本題です。
このように様々なことを経験させていただく中で、普段の業務や業務外の学習にどのように自分が取り組んでいるのか、ここからは話していければと思います。
💻 技術力・実装力を上げるために（ハードスキル）
まずエンジニアとして採用されている以上、 （ある程度）自走できるだけの技術力・実装力がなければ話になりません。
ここではそれらを身につけるため、どういったことを意識していたのか？についてまとめていきます。
1. 継続的なインプット
兎にも角にも最低限実務についていけるだけの知識を身につける必要があります。
幸いにも（？）入社前にある程度習得していたスキルと社内で必要とされるスキルに互換性があったため、「0 からライブラリ・FW をキャッチアップする必要性」 はありませんでした。
とはいえ
- コードを深く理解し、よりよい書き方がないか模索する
- テストコードを増やす
- 負債を生み出さないために統一されたコンポーネント設計・状態管理の方針を定める
- Next.js に関連する新しい機能のキャッチアップ
- （デザインシステムを通じて、基盤コンポーネントを作成する）
といったフロントエンド開発の少し踏み込んだ実装をしたかったため、インプットの時間は業務外でなるべく確保するようにしました。
以下に、ここ半年でインプット目的として読んで良かった本やドキュメントをいくつか紹介しておきます。
（1）TypeScript と React/Next.js でつくる 実践 Web アプリケーション開発
実務レベルにおける Next.js のプロジェクトはどんな感じなのか？イメージを掴みたかったため読みました。
結論からいうと、TypeScript, React, Next.js というスタックの大ざっぱな概観を掴むのには非常に良い本でした。
前半では、TypeScript や React, Next.js についての基本的な説明がなされていて、後半（6 章以降）になると実際に Next.js を使ってアプリケーションを作ってみるという流れになっています。 特に後半は実務さながらのライブラリを取り入れて使用する実践的なものとなっているため、非常に学びが多かったです。
一応テストや Storybook などについても最低限？知れるようになっているのですが、ここに関しては別途ちゃんと学習が必要だなぁと思いました。
（あとは App Router に関しては当然ながら説明皆無です。出たのがだいぶ前なので...）
（2）フロントエンド開発のためのテスト入門 今からでも知っておきたい自動テスト戦略の必須知識
次に自分が入社したあたりから 「フロントエンドも E2E 含め徐々にテストを増やしていこう！」 という流れになっていたため、こちらの本を読みました。
フロントエンド開発をやっていると戸惑いがちなテスト手法の種類の多さやテスト戦略についても整理されていて非常に参考になりました。
またこちらはサンプルコードが非常に豊富で、チームでテストを書いていくぞ！となった場合につまずきがちな「参考コード不足問題」をある程度解消できるようになっています。
詳細は以下のリポジトリを参考にしてください。
（3）Learn Next.js
次にまだ現在進行中なのですが、Next.js 14.0 リリースと同時に Vercel から公開されたこちらのドキュメントを読みながら、App Router で開発していく上で必要となる知識について学んでいます。
後半になるにつれてどんどん難しくなってくるので、結構大変です。
誰か輪読会を開いてくれ。。.（１人じゃきつい）
（4）Git 入門コマンドライン演習 80
次に Git, GitHub の込み入った操作に自信がなかったため、ハンズオン形式で進められるこちらの書籍を読みました。
cherry-pick や reset, rebase, merge --squash, Git オブジェクトといった今まで曖昧だった部分について理解が深められて、実際の実務でも非常に役立ちました。
（とはいえ Git は気を抜いて作業をするとすぐにやらかしてしまう...）
（5）武器になる HTML
次に HTML についてもう少し深く知りたいと思ったため、こちらの本を読みました。
フロントエンドエンジニアにとって知っておくべ HTML の知識が丁寧に説明されており、なぜそれらに気をつけなければいけないのか？といったとこまで踏み込んで説明がされているため、非常に参考になりました。
今まで雰囲気でタグを使ってマークアップしていたのですが、この本を読んでからは表示させたい情報に対して
- どの要素が適切か？
- どういう構造をしているのか？
- アクセシビリティに配慮できているか？
といったことを考えるようになりました。
また、各要素や各属性の必要性・使い方も深く掘り下げて解説してあるため、リファレンス的な形で今も度々見返しています。
「なんやかんや言っても Web の根幹には HTML が存在しているんだなぁ」とこの本を読んで改めて思いました。
（6）人が増えても速くならない
最後にアジャイルやスクラムに関連する本もいくつか読んだのですが、1 番印象に残ったのがこちらの本です。
どちらかというと非エンジニア向けに「ソフトウェア開発とはなんぞや？」を説明している本ですが、エンジニアの自分でも学びになる部分が多かったです。
特に 6 章の見積もりとコミットメントあたりの話は思い当たる節が多くかなり記憶に残っております...😅
あとこのあたりの本でいうと、最近読んでいる 「エンジニアリング組織論への招待」も面白いです。
※おまけ：入社前に読んでよかった資料
おまけで入社前に読んで参考になったなと思う資料についても軽く紹介しておきます。
実務に入る前に目を通しておくことで、エンジニアがどのように日々の業務をこなしているのか？、エンジニアに必要な心構えを多少なりとも学ぶことができると思いますので、よければ参考にしてください。
-
【新人プログラマ応援】開発タスクをアサインされたらどういう手順で進めるべきか
- 「プロを目指す人のための Ruby 入門 」でおなじみの伊藤淳一さんの記事です。
- 「タスクにアサインされたときに具体的に何をすればよいのか？」 が書かれていて、バックエンド・フロントエンド問わずに参考になりました
-
1 年目エンジニアがバリューを出すためにした工夫、結果が出たモノのみ具体的にまとめてみる。
- （今回の記事を書くうえで大いに参考にさせていただいたものです...）
- 実際に効果が出たもののみがまとまっていて、かつ取るべきアクションが明確に示されているのでわかりやすいです。
-
初心者エンジニアにおすすめしたい「進捗どうなった？」と言われないための仕事の進め方
- エンジニアとして仕事を進めるうえで必ず守っておきたい約束事がまとめられています
- マインド的な話から実際の仕事の進め方まで幅広く書かれていて、非常に参考になりました。
-
良い質問をして自己成長に繋げるためのあれこれ
- 質問する際の姿勢やその方法が具体的にまとまっていました
- どういう質問が良い質問なのか？を改めて整理でき、今でも役立っています。
- （質問については後で詳細に説明しています）
-
ソフトウェアエンジニアとしての姿勢と心構え
- 有名な@t_wadaさんの新卒研修資料
- エンジニアとして生きていくためにどういったことを学び続ければよいのか？、そして何をしていけばよいのか？が丁寧に書かれています。
2. 最低月 1 以上の技術記事を書く
次に 1 でインプットしたり、実務で学んだ知識については技術記事やアプリづくりを通じて積極的にアウトプットするように心がけていました。
技術記事は入社当初は「最低でも月 2 以上は書く 🔥」と意気込んでいたのですが、諸々のバランスを考えた結果、月 1 以上に落ち着きました。
入社以降に書いた記事や作ったアプリについては、以下にまとめておきます。
▼ 技術記事
- ひよっこエンジニアが Node のアップデートに立ち向かったら Zod でハマった話
- React Hook Form は非制御コンポーネントからどのように変更を検知しているのか？
- React で再レンダリングを抑えるシンプルな方法
- Plop を使って React コンポーネントの雛形を自動作成する
- React Hook Form で非同期の値を扱う場合はこれに統一しませんか？
- 「React Journey」から学ぶ React のレンダリングの仕組み
- 親から渡ってきた props を「あえて」useState の初期値に設定してみる
- 【Next.js × @vercel/og】セミナー登壇者風に誰でも予定を告知できるアプリを作りました
▼ 個人開発
次に実際の開発業務で意識していることです。
3. ログを積極的に残しながら開発を進める（＝ログ駆動開発）
まず自分の times（分報）チャンネルに積極的にログ（例えば、疑問に思っていることや現状把握など）を残しながら開発を進めるよう意識しています。
（＝ ログ駆動開発[1]）
これを行っている理由としては以下の 3 つです。
- 進捗感が得やすいため
- チームメンバーへ進捗具合を共有できるようにするため
- 質問のハードルを下げるため
まず 「進捗感が得やすい」 についてです。
通常のタスク管理法だと与えられたチケットを作業単位で分解して、その作業単位の完了を元に進捗を管理するのが一般的だと思います。
ただこれだと、例えば「何から手を付けるべきか？」すら把握できないチケット（スクラム的に言うとスパイク）などを振られた際には、進捗としてなかなか計上できないため、進捗感が得られずダレがちになってしまうかと思います。
しかし、積極的にログを残していく「ログ駆動開発」なら、作業ログが書き込まれた時点で進捗が発生するため、こういったカオスな状況下でも進捗感が得やすいです。
また他にもこまめに自分の現状や考え、疑問に思う点を書き記していくことで、そのログ自体がチームメンバーへの現状報告や質問の役割も兼ねてくれます。
実際何気なくつぶやいた一言を先輩エンジニアが拾ってくださって問題解決までつながった...というケースはこの半年間で何度もありました。
同じ実装で何時間も悩むくらいなら、自分の現状や何がわからないのか？などを積極的にログとして残していくことをおすすめします。
ちなみに、自分は以下のようなログを残しています。
4. 入念なセルフレビュー
最後にこれはまだまだ意識できていないことも多いのですが、プルリクエストを出す前に「セルフレビュー」を行うよう心がけています。
同じ指摘を何度もレビュワーの方にさせるのは負担になりますし、またレビュワーが気になりそうな箇所や実装の意図が把握しづらい箇所については事前にコメントとして残しておくことで、レビュワーの認知負荷を下げることにもつながります。
他にもファイルの変更数が多い場合などは、もう少し細かく分けてプルリクを投げれないか？など検討することも重要です。
実際自分が所属しているフロントエンドチームでも最近プルリクエスト用のテンプレートを導入し、事前にチェック項目を設けて、こういったことを意識できているか？確認するようにしています。
🗣️ 技術面以外で貢献するために（ソフトスキル）
次に技術・実装面以外の、いわゆる「ソフトスキル」についてです。
1. 回答者のコストを意識した質問
まず意識していたのが、「回答者ができる限り低コストで答えれるような質問を用意する」 ということです。
入社したての頃は右も左もわからないため、とにかく質問することが多いです。
答えをそのまま求める丸投げ質問をしているようでは、回答者側の負担になりますし、印象も悪いです。
そのため質問をする際には 「相手にどのくらいコストがかかる質問だろうか？」 ということを常に考え、コストが高い場合はなるべく負担を下げれるよう工夫できないか検討するようにしています。
具体的には、まずこれからする質問が以下のどれにあたるのか？を整理します。
- 自己解決
- YES/NO
- 選択肢
- 単語
- 文章
- 議論が必要
その後コストが高い質問に対しては、回答者側が状況を把握しやすいようなるべく前提や（自身の）仮説を共有するようにしています。
自分の場合は、以下のようなテンプレートを用意し、各項目ごとに内容を整理してから質問しています。
① 聞きたいことの一行まとめ（質問なのか相談なのか確認なのか提案なのかなども同時に伝える）
② 質問したい箇所の概要
③ 問題点(理想と現実)
④ 質問、相談、確認、提案の本題を言う。
⑤ スクショやコードの URL を添付する。
① 【相談】◯◯◯の不具合の対処法に関するご相談
② 現在◯◯◯の不具合に対処しています。
③ △△△をした際に☓☓☓な挙動をさせたいのですが、元の画面とAPIの仕様上☓☓☓な動作を実現させることが難しいです。
④ そのため、以下の3つのどちらかで対応しようと考えているのですが、どちらで進めらよいかご相談したいです。よろしくお願いします。
・ aaa
・ bbb
・ ccc
⑤ スクショやコードを貼る。
// ログを追うのに邪魔になる場合があるので、適宜スレッドに貼るか、コードならスニペットにまとめたりする
2. 「わからないこと」を恥じない（＝プライドを捨てる）
最初の頃は自分をよく見せたいがために、多少理解できないことがあってもついわかったふりをしがちですよね。（何を隠そう自分もそうだった 👍）
ただチームとして働いていく以上、そのような「独りよがりなプライド」は邪魔でしかありません。
エンジニアというのは常に不確実性と向き合う職種ですので、わからないことや疑問に感じたことがあればどんな些細なことでも聞くよう自分は意識しています。
特に最初のうちは「わからなくて当たり前」という認識をチームメンバーの方も共通して持っていると思いますので、疑問に思ったことは遠慮なく聞きまくることをおすすめします。
（自分は若干聞きそびれた部分があった 😅）
ただ「気軽に質問していいよ ♪」と言われてもなかなかできないのが人間の性です。
「恥ずかしいな」とか「今はさすがに聞きづらいな....」と思うことも当然出てくるでしょう。
そういったときは 「あくまで自分は分からない役を担っているだけ ✌️」と考えるよう自分は心がけています。
イメージとしては、「自分がわからないということはどーせ自分以外にもわからない人いるっしょ！」という感じです。
「自分のためでもあり、周りのためでもある」 と思うようにすると、多少は恥を捨てやすくなるのではないでしょうか？
3. 自分自身をよく知る（メタ認知）
自分自身についてある程度、客観視しておくことも大切です。
どんなことが得意で、どういった思考の癖があるのか？ということを知っておくと仕事だけでなく、チームメンバーとのコミュニケーションにも役立ちます。
自分の場合は昔コーチングに興味を持って資格を取った経験があるため、このあたりの自己分析については結構やってきました。
無料でできる範囲なら「16personalities」、有料だと「ストレングスファインダー」や「世界一やさしい「やりたいこと」の見つけ方」などがおすすめです。
🔁 課題を知り、改善していくために（振り返り）
1. 週末 KPT 振り返り
週末にプライベート・仕事も含めてその週に起こった出来事を KPT で振り返るようにしていました。[2]
基本的には以下の記事を参考に Notion を用いて管理しています。
約半年ほど続けてきて、現在 K が 90 個、P が 201 個、T が 173 個ほど溜まりました。（やっぱり P とか T が多くなりがちですよね〜）
「T」については、ただ羅列していくだけだとわかりづらいので優先順位をつけるようにしています。
具体的には、以下のように３つに分類して優先度の高い上 2 つについては 5 つだけ選択し、翌週以降で気にかけるようにしていました。
2. アジャイル勉強法
業務外の時間で何を学習をしていくのか？整理するため、以下記事にもある 「アジャイル勉強法」 と呼ばれるものを 3 ヶ月ほど前から導入し始めました。
詳細は各自で読んでほしいのですが、ざっくり説明すると以下のサイクルを回し続けていくイメージです。
- 四半期単位で計画を立てる
- タスクに細分化して GitHub Project に登録していく
- 月単位で消化するタスクの目標を立てる
- タスクを消化(=勉強する)
- 月単位での達成状況を振り返る
- 四半期の振り返りを行う
以前は iPad のメモアプリを利用しタスク管理を行っていたのですが、手書きが面倒くさくなってきたため、こちらの管理法に切り替えました。
個人的には GitHub Project でタスクを管理する方法が結構気に入っていたりします。（草も生えるし、進捗状況も可視化しやすい）
✅ その他
1. 強みを活かし、弱みを抑える
ソフトスキルでもお話した「3. 自分自身をよく知る（メタ認知）」に関連して、自身の強みを活かす or 弱みを抑える行動を取っていくことも意識していました。
例えば自分の場合「情報をわかりやすく構造化して整理すること」に対し苦手意識がそこまでなく、むしろ整理する過程で喜びを覚えるタイプだったため、ドキュメント作成などの機会が転がっていたら積極的に行うようにしています。
地道に続けた甲斐もあり、今ではドキュメント系のタスクがあったら自然と自分に振られるようにもなってきていますので、強みは積極的にアピールしたほうがお得です。
逆に弱みに関しては、意識的に抑えることが大切です。
例えば、自分の弱みの１つに「細部にまでこだわりすぎてしまう」ということがあります。
これにより、例えば実装する際に少し気になってしまった部分の修正を突然始めてしまったり、最終的な成果物にさほど影響ない部分に時間をかけて実装してしまったりということが度々起きて、開発スケジュールが遅れてしまう...なんてことがありました。
ただこういった部分も振り返りなどで自覚的になっていくことで、対応策を取ることが可能です。
例えば、プルリクをなるべく早く出したり（実装に粗があっても）、実装方針の相談を実装前にしてしまい優先度を決める...といった対策をとるよう心がけています。
誰にでも弱みは必ずありますので、そこを抑えつつなるべくパフォーマンスに影響が出ないよう立ち回ることが大切です。
2. キャパオーバーギリギリを攻める
最後に「成長」という点で意識していることとして、基本的に自分は 「キャパオーバーギリギリのライン」 を保つようにしています。
この辺は感覚値でしかないのですが、ちょっと普段の生活に余裕がなくなるくらいが自分の中ではちょうどよいです。
（逆に余裕がなくなりすぎるのもありすぎるのもきつい。）
「今の自分にとっては少し厳しいかもしれない」と思うようなタスクがあったら、（自身のキャパと相談しながらではありますが）積極的に手を上げて取り組むよう意識しています。
おわりに
ということで、エンジニアになって半年間で意識してきたことを簡単にまとめてみました。
この半年間色々と大変なこともありましたが、基本的に「楽しく」「伸び伸び」とエンジニアライフを送れています。これもひとえにCOUNTERWORKS で一緒に働いている方々のおかげです。
現状に満足せず、さらに会社に貢献していけるようこれからも頑張っていきたいと思います。
最後までご覧いただきありがとうございました！
COUNTERWORKS では絶賛エンジニア募集中です。
今回の記事を読んで COUNTERWORKS に興味を持った方がいらっしゃったら、ぜひ以下のリンクよりご応募ください！！
ポップアップストアや催事イベント向けの商業スペースを簡単に予約できる「SHOPCOUNTER」と商業施設向けリーシングDXシステム「SHOPCOUNTER Enterprise」を運営しています。エンジニア採用強化中ですので、興味ある方はお気軽にご連絡ください！ counterworks.co.jp/
Discussion