この記事は Wano Group Advent Calendar 2024 の 4日目の記事となります。
概要
TuneCore Japanでフルスタックエンジニアをしている@_tachi_です。
フルスタックエンジニアって何考えているの、どう見えているの？
という部分を文章に起こしてみたいと思います。
TuneCore Japan のフルスタックエンジニアとは
フロントエンド・バックエンド両面の経験を活かし、技術設計からコーディングまで取り組むことができるエンジニアをフルスタックエンジニアと表現しています。
| 領域 | 技術 |
|---|---|
| バックエンド | Go（DDD) / Perl |
| フロントエンド | React（DDD）/ TypeScript / Tailwind CSS |
| API | OpenAPI |
| DB | MySQL |
| インフラ | AWS |
(現在フルスタックエンジニアとして活躍したい方募集中です！)
これまでの経歴
前職含めこれまでの経歴を辿るとフルスタックを目指したというより、気づいたらそのような動きをしなければならなかったことが多かったです。大抵は人が足りないとかそんな感じの理由です。
- Java / Python /C# / C++
- Webサービスの開発
- パッケージマネージャやビルド tool も選定なども
- React / JavaScript・TypeScript / HTML・CSS
- TypeScript化やReactによるフロントエンド開発など
- パッケージマネージャやビルド tool も選定なども
- Docker構築
- Composeによる全員分の開発環境の提供やマルチステージによるビルドの切り替えなど
- ECS
- アプリケーションレイヤよりのインフラ構築
- SQS * Lambda * EC2 による非同期イベント処理など
- 社内業務のDX化
- SaaS立ち上げ
- 採用 / 育成
デザインを見たら、色んなことが想起される
私はバックエンドの経歴の方が長いので、こんなクエリが必要そう 
から浮かんできます（他のフルスタックエンジニアは最初に何が浮かぶんでしょうね？）。
私が対応するにしても、対応しないにしても大体は以下のことを同時に考えているような気がします。
- DB的な部分
- バックエンドの処理ロジック
- コンポーネント
- API
- CSS的な部分
- 誰が触るためのものなのか（ユーザー,セールス,CS）
何でも観察している自分がいる
これどうやって作っているだろ？という興味関心
この間と変わった？という観察力
目に見えるものに対して分析しようとする自分がいます。
何か変化を捉えたときに脳内で想起される内容は、大体3種類くらいありそうです。
例えば普段利用しているサービスのデザインが一部変わったことを想定してみます。
A. 直球
「あれ、この間とカードのデザイン変わったな。」
B. 直球 + 観察
「あれ、この間とカードのデザイン変わったな。前回は背景白だったのに、今回は背景が透明になっているし、閉じるボタンの位置やサイズ自体も変わっているぞ。」
C. 直球 + 観察 + 想像
「あれ、この間とカードのデザイン変わったな。前回は背景が白(backgroud-colorがwhite)だったのに、今回は背景が透明(rgb調整した？)になっているし、閉じるボタンの位置(relative,absoluteで位置調整してそうな並びだな)やサイズ自体も変わっているぞ。」
私は C のように、裏側はこうなっているだろうのイメージを持つようにしています。
正解を当てるゲームをしているわけではないので当たっていなくともいいのです。
想像は、第三者的な視点ではなく「自分だったらこうする」がベースにありますから、それとの乖離を比べて better な方を自分の中に落とし込めれば良いとしています。
恐らくですが、私がファッション好きなので服装、ヘアスタイル、細かいアイテム、色使い、ブランドなど街を行き交う人々を常に観察しているが故の癖かもしれません。
あのフットウェアがかっこいいとか、案外〇〇というブランドのサイズ感でかいんだなとか、そういうアイテムの組み合わせもあるんだなとか。
ゼロから考えすぎない
なんでもやってみよう！な心意気は持ちつつも、オレオレでこんなの作ったぜ！はなるべくしないです。
担当領域が広い分専門的に対応する人より使える時間が限られていますし、脳内は割と混雑してます。
自分がやろうとしていることは大抵誰かがやっているはずなので、悩むより先に実現したいこととマッチしそうな他社の事例など調べて素直に落とし込んだり、それを持ってきて相談したりします。
とりわけAPIなどは公開されている著名なサービスから参考として引っ張ってきやすいので割と重宝しています。
ある程度信頼できる企業が公開している情報ということは一定以上のクオリティが担保されているわけですからね。
Amazon関連(何でもAPIあってすごい)
AWS - 各サービスにAPIリファレンスが用意されている
Selling Partner API (SP-API) - Amazonの出品,集荷,発送
音楽関連
Apple
Spotify
お金、決済関連
Paypay
Stripe
その他
Microsoft の Learn ページ - Microsoft製品向けだが設計の考え方が参考になる部分も
martin fowler氏 のサイト - サンプルコードの掲載もあり
little-hands の Q&A - 自分がモデリングに悩んだ時は誰かも同じ悩みすでに持っている
基礎を大事にしようとする意識が重し
今使っている〇〇てベースは何なの / 何だっけ？ といった根本の方に意識を向けるようにしています。
フルスタックエンジニアとなると、カバーしなければならない範囲が広いですし、会社によって定義がバラつくため、「どこまで理解するべきか」というのは悩みの種であります。
フルスタックエンジニアのロードマップ
例えばライブラリの使い方ばかりを勉強しても、本質が分からなければ多分すぐ忘れるか使わない場面に出会したら辛くなります。
基礎が分かれば領域が違うだけで基本全部やることは一緒と私は考えているので、基礎に重きを置いています。
バックエンドなら
- クラス設計って？
- デザインパターンって？
- DB設計って？
- 正規化
- 非正規化
フロントエンドなら
- HTMLのタグや、構造って？
- JavaScriptって？
- 非同期って？
- CSSって？
- レイアウト
- セレクタ
普遍的な部分
- REST APIって？
- サーバーって？
- キューイングって？
- Linuxって？
- 認証って？
- Gitって？
技術の進化が怖い
バックエンドはまぁそんなに変わらないかなという印象がありますが、フロントエンドは変わりすぎて追い切れないですね。
気づけば bun が ver 1.0 になっていたし、ReactやTypeScriptなんか目を離した隙にバージョン上がっている...あまり変わらないでいてくれるのはインフラくんとGoくんくらいです。
自分が使っている周辺に関しては使わなくとも概要をキャッチしておいて損はしないので、時間があれば触ります。が、プライベートの時間との兼ね合いが難しいのであまりダイナミックに変化されたり、似たようなライブラリが群雄割拠されると辛いところですね
（state管理ライブラリ、お前のことだぞ）。
もし今新たにサービス立ち上げるならバックエンドもフロントエンドもCDKも全て同じ言語の中でできたらみんなフルスタックに対応する敷居が低くなるんだろうなと思っています。
作業場所を独立させて、1つのことは1つの場所で
今したいことに集中できる環境 で作業できるような環境づくりに勤しんでいます。
エンジニアなら毎日ターミナルは開きますよね。
TuneCore Japanでは Perl, Go, React を採用しており、それぞれ独立したリポジトリで管理されています。
フルスタックエンジニアは自ずと3つ確認することが確定しています 
それ以外にもローカルDBにアクセスしたり、Dockerを確認したり、テスト環境へSSHしたり...etc
そんな私は Wezterm のワークスペース機能を使って Ctrl+A S で作業したい単位で切り替えられるようにしています。
いい感じに分離できないとターミナルのtabやインスタンスが際限なく増えてしまいますからね（経験済み）。
（閑話休題）個人的に考えるフルスタックエンジニアの素養
バックエンド、フロントエンドの得意不得意より前に、課題解決が好きなこと だと思います。
特定の領域に縛られないのが強みでありますから、技術を用いて問題を解消すること自体を楽しめるならフルスタックエンジニへの入門の扉は叩けていると思います。
何でも屋さんなのでサービス立ち上げなどのメンバーにアサインされやすい特性もありますね。
ゼロから何か作る経験はフルスタックエンジニアの方がチャンスが多いかもしれません。
最後に
私の頭の中を覗いてみました。
あまりフルスタックエンジニアとか関係ない内容ですね。
言い換えれば (私観でありますが) フルスタックだろうが、そうでなかろうが特別な違いはなくポジションの違いでしかないということです。
ということで、バックエンドもフロントエンドも挑戦したい！という方応募お待ちしてます！