1. はじめに
レガシーなサイトの HTML・CSS コーディング業務に約2年間従事したのち、いわゆるモダンな Web アプリケーション開発現場へフロントエンド開発者としてアサインされました。
この記事はその際の立ち上がりとして意識したことの備忘録として、また同じような境遇の方への何かしらのアドバイスになればと思い、書き残すものです。✍️
記事中でおすすめの書籍をいくつか例示していますが、これらはあくまで私が実際に読んだことがある本の中から選んでいます。そのため、他にもっと適した素晴らしい書籍がたくさんあるとは思います。
1.1. この記事で書かないこと
- 特定の技術スタックについての具体的なナレッジ
- 組織論やキャリアパスの絶対的な正解
2. 技術面
まずは技術面で意識したことをまとめます。なお「プロダクトで使われている技術スタックのキャッチアップ」などは大前提なので、ここでは明示はしていません。
2.1. プロダクトコードを理解する
まず何を置いても アサインされたサービスのプロダクトコードを理解すること から始めました。
実務で稼働しているプロダクトコードは、本や動画の入門ハンズオンで作るサービスのコードとはワケが違います。複雑な業務ロジック、保守性や信頼性を担保するための設計など、初学者には理解するだけで大きな学習になります。
具体的な行動
- すべての画面のデータフローを把握する（データのインプット・アウトプットの流れ）
- Figma や Canvas を利用して図解する
- 設計やアーキテクチャの意図を理解する
- その共通化によってどのような恩恵があるのか、なぜこのようなディレクトリ構成なのか
- 上記の理解のために AI Agent を利用する（もちろん、許可は必要）
2.2. サービスのシステム全体を理解する
フロントエンドはアプリケーションの表層、いわゆるインターフェイスのみであり、その裏に広がっているバックエンド・インフラ・外部サービスといった、サービス全体を理解すること が大事です。
HTML・CSS コーディング業務が中心だと表層部分にしか携われないため、意識的に視点を広げ、視点を深める必要がありました。
具体的な行動
- バックエンドの実装をなんとなくでよいので理解する
- インフラ構成図を理解する
- 構成図が存在しなければ、インフラ担当メンバーと協力して簡易なものからでも作成してみる
2.3. 担当大臣になる
自分が興味や関心のある分野を深く勉強することで、チーム内において 特定の技術分野について秀でた「xx担当大臣」になる ことができるとよいです。
担当についてはなんでもよいです。Git、ネットワーク、React、a11y、HTML・CSS 標準、etc.
「この点についてはxxさんに相談しよう」とチーム内で認識されることは、自信にも繋がりますし、明確なアピールにもなります。👍
具体的な行動
- 自分が興味や関心のある分野を見つけ、勉強し、チーム内に発信する
- その分野に関連した会話がなされていた場合、積極的に首を突っ込む（煙たがられない程度に）
2.4. 技術書を読む
2.1. プロダクトコードを理解する で既述の通り、まずはプロダクトコードを理解することが大前提ですが、慣れてくると今度は既存コードが自分の中の「聖書（絶対的な正解）」になってしまいがちです。そうなると、既存の実装がアンチパターンであった場合に気づけなかったり、レビューの際によりよい改善・指摘ができなくなってしまいます。
プロダクトコードだけでは得られない技術スタックのナレッジを外部から体系的に学ぶために、技術書を読むことが大事 であると考えています。自分のプロダクトコードを理解した上で、その技術スタックのデファクトスタンダードやアンチパターンへの理解を深めましょう。
具体的な行動
- 使われている技術スタックについて、体系的に学べる技術書をまずは1冊読み切る
- まずは zenn などにある無料の書籍でも構いません。良著はたくさんあります。
3. ソフトスキル面
技術スタックを追いかけると同時に、マインドセットやチーム内での立ち振る舞いについても意識的に変えていく必要がありました。
もちろん、これらはモダンな開発現場に限った話ばかりではありませんが、特に重要だと私が感じた点をまとめていきます。
3.1. 「わからない」をスタックして潰す
モダンな開発現場、特にテック集団の会話は早いものです。
ドメイン固有の用語だけでなく、ソフトウェア開発における一般用語が飛び交います。
同じインプットを受けているにも関わらず、理解の速さや深さがまったく違うメンバーの多さに絶望するかもしれません（私はしました😇）。
ですがこれはドメインへの理解が進めばある程度はその差は縮まるため、「時間が解決する」と割り切りましょう。肝心なことは、「わからない」をひとつずつ潰していく ことです。
具体的な行動
- 日々のミーティングや会話で感じた「わからない」は、その場で聞けなくともすべてメモする
- 疑問点をスタックしておける基盤（なるべくパブリックな場で既存メンバーに見える化されている基盤）を作り、そこにどんどんスタックして順番に解消（調べる・聞く）していく
- （もし質問しづらいチームなのであれば、それはチーム側の課題でもあるので、リーダー陣やメンターに適宜相談しましょう）
3.2. できることを増やし、浮き玉を拾う
アサイン直後は右も左もわからない「なにもできない」状態です。初めてのモダン開発現場なのであれば無論そうです。
まずは簡単な業務フローや、いわゆるトイルでも構いません。誰でもできる作業をひとつ覚え自信を持って自走できる ようになります。
そしてそれが浮き玉タスクになった時、積極的に取りに行きましょう。チームへ自分の主体性をアピールすることは大事であり、チームへの明確な貢献にもなります。
具体的な行動
- 簡単な業務（トイル）をまずはひとつ覚えて自走できるようになる
- そのタスクが「浮き玉（誰も拾わないタスク）」になった時、積極的に拾いに行く
- それ だけ をやり続けて「トイル担当大臣」になってしまうのではなく、常に新しい「できること」を増やし続ける意識を持ち続ける
3.3. 技術者として自分の思想を持つ
モダンな開発現場の技術者は日常的に技術的な会話をするだけでなく、コードでコミュニケーションを取ります。
技術者として自分自身の「思想」がないとそういった会話に参加できないだけでなく、既存メンバーのレビューに対して「YESマン」になってしまったり、既存のコードや新たな変更に対して改善点を提示できなくなってしまいます。
技術者として自分の思想を持つ ことで、レビュー指摘に対して「なぜ私はこのコードを書いたのか」が説明でき、また他メンバーのPRに対して「なぜ私はこの改善点を提示するのか」を説明できるようになります。
ただし、思想の押し付けをしたいわけではなければ、ましてや口論がしたいわけでもないです。あくまで建設的な議論を加速させ、プロダクトを改善することが目的です。
具体的な行動
- 自身のすべてのコードに対して「私はこう考えた（こういうメリット/デメリットを比較した）から、このコードを書いた」と、理由と目的を言語化できるように努める
- 自身のすべてのコードに対して責任を持つ1（「愛着を持つ」でもよい）
3.4. 技術書を読む
前述している「思想を持つ」ことは、モダン開発現場に入りたての場合は特に難しいです。
そのため自身の思想を持つための手っ取り早い方法は、外部からインストールすることであり、つまりは 技術書を読む ことです。
2.4. 技術書を読む で述べている、特定の技術スタックのナレッジを深めるための技術書だけでなく、エンジニアとしての思想や開発の原理原則に関する書籍を読むことがおすすめです。
具体的な行動
- エンジニアとしての思想や設計の原理原則に関する書籍を読む
- まずは zenn などにある無料の書籍でも構いません。良著はたくさんあります。
4. さいごに
ここまで HTML・CSS コーディング中心の業務からモダンな開発現場へ移った際に、私自身が意識したこと・やったことを「技術面」「ソフトスキル面」に分けてまとめてきました。✍️
もちろん、この記事に書いた行動リストが絶対的な正解だとは考えていません。あくまで私個人の実体験のアプローチであり、現場やチームが変われば、最適な立ち上がり方も変わってくるはずです。（マサカリケア）
ですが、もし過去の私と同じように「マークアップ業務からモダンな開発現場へ」というステップを踏もうとしている方、あるいは今まさにそのギャップに悩んでいる方にとって、何かしらのヒントや「自分もできるかも」という少しの安心材料になれば幸いです。