「フルスタックエンジニア」という言葉が流行っては廃れる、を繰り返している。 全部書ける人が偉い、という話ではないが、「私はフロントだけです」で済むかというと、たぶん済まない。
エンジニアと作業者を分けているのは担当範囲ではなく、問題を最初から最後まで見通せるかどうかだ。 そういう人を育てるには、全員が全領域を 8 割わかっている状態を最低ラインに置くしかない、というのがこの記事の話だ。
エンジニアかどうかは、担当範囲では決まらない
エンジニアと作業者の線引きを、担当技術やポジションでやろうとすると、たいてい失敗する。 フロントエンジニア、バックエンドエンジニア、インフラエンジニア、といった分類は、扱う技術の話をしているだけだ。 その人がエンジニアなのかどうかの判定にはなっていない。
もう少し実態に近い線引きは、扱う問題の抽象レイヤを上下に自由に移動できるかどうか、で切ることだ。
- エンジニア
- 顧客の状況、事業の狙い、システムの制約、実装の詳細、運用の実情までを繋いで見て、その全部に噛み合う解を作れる人
- 作業者
- 与えられた局所仕様を、その背景を問うことなく実装する人
この線引きだと、フロント専業でも、顧客の行動、API の設計、状態管理、計測、運用まで読めるならエンジニアだ。 逆にバックエンドもインフラも触れる人でも、事業や顧客と切れているなら作業者になる。 担当技術は、実は関係ない。
なぜこの線引きにこだわるかというと、局所解を積み上げただけでは、プロダクトとしては噛み合わないことが多いからだ。 バックエンドだけ、フロントだけ、インフラだけ、データだけ、と切ると、そのレイヤ内では綺麗に見えても、ユーザー体験、事業制約、運用負荷、開発速度との接続が切れる。
プロダクトの品質は、全レイヤの制約を同時に満たす近似解が出せているかで決まる。 視野が狭いと、そもそも最適化する対象を間違えやすい。 担当だけを完璧にやっても、プロダクトとして噛み合わなければ、そのぶんの成果は目減りしてしまう。
「LLM がいるから書けなくていい」は、かなづち使えない棟梁と同じ
「LLM が実装をやってくれる時代なんだから、もう自分では書けなくていい」という論が最近よく出る。 気持ちはわかるが、これは棟梁が「もうかなづちは使えなくていい」と言っているのと構造が同じだ。
棟梁がかなづちを「振らないこと」と「使えないこと」は、まったく違う。
振らない棟梁は、自分で家を建てはしない。 だが、どこが難しいかも、どのくらい時間がかかるかも、どこで手を抜けば後で崩れるかも、身体でわかっている。 だから設計判断ができるし、職人にどこまで任せて良いかも判断できる。
かなづちを振ったことがない棟梁は、これができにくい。 設計が現場で通らなかったり、見積もりが実態から乖離したりしがちで、任せる相手の見極めも難しくなる。 結果として、判断が上滑りしやすくなる。
ソフトウェアでも同じことが起きる。 実装ができないまま設計判断だけをやると、こうなる。
- 仕様の乖離
- 作れないものを作れと言い出す
- 部分は動くが全体は壊れる
- 局所的には動くが、システム全体としては崩壊している
- 本質と慣習の混同
- 何が本質的な制約で、何がただの慣習なのかの区別がつかない
- LLM 出力の評価不能
- LLM が出してきたコードが良いのか悪いのかを判断できない
LLM が実装を代わりにやってくれる時代でも、「書ける」は最低ラインで、「構造を見て判断できる」がその上に乗る本体だ、というのはこの意味で成り立つ。 書けない棟梁が、ハンマーの代わりに LLM を持っただけでは、判断精度は上がらない。 判断のための身体感覚は、自分で書いてしか身につかない。
全員が全領域を 8 割わかっていて、自分の中核だけ突き抜けている
以上を踏まえて、じゃあどういうチームなら成立するのか、を書く。 結論を先に置くと、こういう状態が理想になる。
全員が、プロダクトに関わる全領域を「実務判断に使えるレベル」で理解している。その上で、自分の中核領域だけは、周囲に対して圧倒的に深い。
「実務判断に使えるレベル」の中身は、次の領域を、会話でわかったフリをするのではなく、自分の判断根拠として使える、という意味だ。
- 顧客と業務
- 市場と競合
- UI と UX
- データと計測
- 実装と設計
- インフラと運用
- セキュリティ
- 法務・コンプライアンス
- 収益構造
ここが 8 割ある、というのが最低ラインになる。
その上で、自分の役割に応じた中核領域だけ、突き抜けて深い。
- エンジニアなら
- 実装・設計・DB・インフラ・監視・性能・データ・UX・ドメイン理解・顧客理解あたりが、一つのまとまった塊として深い
- デザイナーなら
- 体験設計まわりの塊が深い
- 事業側なら
- 市場と顧客と収益の塊が深い
大事なのは、この「深い部分」が単発のスキルの尖りではなく、関連する領域がまとまった塊として深いことだ。 よく言われる T 字型（一つだけ深い）では、実は足りない。 もっと山脈のような、隣接する領域がひと繋がりで盛り上がっている形が要る。
この状態になっていると、チーム内の会話が「相手にゼロから説明する場」ではなく「差分だけ同期する場」になる。 それぞれが全体を持っているので、通訳が要らない。
逆に、各人が 3 割ずつしか持っていない島同士だと、毎回プロトコル変換が必要になる。 組織全体が、細い口頭パイプで繋がる低帯域バスになる。
フロントに座る PdM を「情報の窓口」として細い帯域で叩き続けている状態は、その典型だ。 分業ではなく、本来自分で取りに行くべき情報を、他人経由で受け取ろうとしているだけの、情報の外注になっている。
「全部わかっていないといけない」は厳密には無限で無理だ。 だが、「自分の出すものに影響する情報を、自分で取りに行く責任がある」の方は、かなり素直に成り立つ。 ここを人任せにしてしまうと、実装者として部分問題だけを解いている状態に寄りやすい。 オーバーヘッドではなく、出力の質のための必要条件と捉えた方がしっくり来る。
「作業者でいる」は、実は自分を守っていない
「そこまで責任を負いたくない」「担当範囲だけやりたい」という選択肢は、当然ある。 ただ、それが自分を守るかというと、たぶん長期では守らない、というのがここまでの流れの帰結だ。
作業者のポジションを取ると、責任範囲は狭くできる。 だが、そのぶん納得感・裁量・学習速度・市場価値も一緒に狭くなる。
短期的には「言われたことをやっただけです」で痛みを避けられる。 だが、プロダクトが滑ったときの無力感は残るし、成果が出ても、それが自分の判断で勝ち取ったものにはならない。 責任から逃げた分だけ、達成感も同じ量だけ逃げていく。
作業者でいるのは防具に見えるが、実際には視界を少し狭めている面もある。 理解していない領域に依存しながら仕事をしている状態は、構造的にどうしても不安定になりやすい。 不安の発生源に触れないことで、その場は落ち着くが、根元は残る、ということが起きがちだ。
とはいえ、人は安きに流れる。 これは意志の弱さではなく、コスト構造の問題だ。
- 全領域 8 割の維持
- 毎日コストが発生する。しかも見返りが見えにくい
- 担当だけやります
- 短期の見返りは、はるかに見えやすい
- 責任範囲の限定
- 「そこは PdM が」「そこはインフラが」と言えるので、心理的にも楽
ほうっておくと、意図的に逆らわない限り、人は作業者側に流れていく。
裏を返せば、意図的に逆らって、全領域 8 割の維持を続けられる人ほど、長期でエンジニアであり続けやすい。
プロダクト作りは総合格闘技に近い。 派手な技術ではなく、地味な基礎練の積み重ねの方が、最終的には効いてくる。