「フルスタック」は二重に都合がいい——企業の人材コストと、エンジニアの万能感が出会う場所

Full-Stack Is Convenient Twice Over — Where Corporate Staffing Costs Meet the Engineer's Sense of Omnipotence

著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info)

1. 「フルスタックエンジニア」という言葉

フロントエンドもできる。バックエンドもできる。DBも触れるし、クラウドも扱える。TerraformやCDKでインフラも書ける。CI/CDも組めるし、コンテナも動かせる。

「フルスタックエンジニア」はおおむね、こういう人を指すことになっている。
この言葉は、求人票にも、自己紹介にも、登壇者のプロフィールにも出てくる。ほとんどの場合は褒め言葉として使われていて、否定的な意味で使われる場面はあまり見ない。

扱える技術が増えていくこと自体には、問題はない。一つの言語から始めて、隣のレイヤーに手を伸ばし、気づけば守備範囲が広がっている。技術者の成長として、これはごく自然な経路だと思う。

ただ、この言葉は 「知っている範囲の広さ」と「責任を持つ範囲の広さ」を区別しないまま使われている ことが多い。では、この二つが混ざったまま言葉が流通しているのはなぜだろう。

それは、混ざっていたほうが都合のいい人がいるからではないか。しかもその都合は、企業とエンジニアの両方にあるのではないか。

この記事では、フルスタックという概念の善し悪しより、それが誰にとってどう都合よく機能しているか、そしてその過程で何が数えられずに残っているかを見ていきたいと思う。

2. 企業から見た「フルスタック」

配置の自由度の高い人材

まずは、フルスタックエンジニアという人材を、募集する企業がどう活用するつもりで採用しようとしているかを考えてみよう。

たとえば、フロントエンド担当、バックエンド担当、DB担当、インフラ担当などの、職能ごとに専門家を置けば、そのぶん人数が要ることになる。小さなチームやプロダクトの初期では、各領域の仕事量が一人分に満たないことも多いだろうから、一人が複数領域を担当できれば、採用人数を減らせるし、配置も柔軟になる。人材不足が続く状況では、専門家を四人探すより、広く扱える人を二人探すほうが現実的に見える。専門家を常時置かなくても、必要なときだけ詳しい人に確認すればいい、という発想も出てくる。

ここまでは分かりやすい経済合理性で、悪い話でもない。

境界の「調整」への期待

もう少し見えにくいのが、領域と領域の境界で発生する仕事だ。

専門分業をすると、境界では必ず調整が要る。誰がどこまで担当するのか。障害が起きたとき、原因はアプリ側かインフラ側か。仕様変更はどちらに確認すればいいのか。意見が割れたら誰が決めるのか。

こうした調整は、会議、チケット、問い合わせ、エスカレーションとして目に見える形で現れる。工数として数えられ、ときには「コミュニケーションコスト」として問題視される。

フルスタックという考え方は、この調整コストを消したように見せることができる。一人が両側を分かっているなら、その人の頭の中で解決できるはずだ、という理屈だ。実際には境界面の仕事が一人の人間の内側に移っただけなのだが、外から見ると会議もチケットも減るので、消えたように見える。

企業にとってのフルスタックは、技術能力の呼び名であると同時に、人材コスト・採用コスト・調整コストを圧縮できるという物語にもなっている。

3. エンジニアから見た「フルスタック」

今度は、エンジニア個人の方からこの言葉を見てみよう。

「自分は全体を扱える」という自己像

フルスタックの概念は、エンジニア自身にとっても魅力がある。

「JavaScriptを書いています」「DBを見ています」と名乗るより、「サービス全体を理解していて、設計から実装、デプロイ、運用まで扱えます」と名乗るほうが強い。部分を担う人より全体を見渡せる人でありたいという欲求は、技術者にかぎらず多くの職業人が持っているものだ。

「フル」という言い方

それにしても、なぜ「複数の領域に経験があります」では足りないのだろうか。

経験の範囲を説明するだけなら、それで十分なはずだ。わざわざ「フル」と言うとき、そこには技術の説明以上のものが含まれている。自分は技術の一部分だけを見る人間ではない。システム全体を理解している。どこでも仕事ができる。特定の専門家に依存しない。

「フルスタック」は能力の記述であると同時に、技術者としてのアイデンティティの表明にもなっている。

境界をつなぐ技術

ここ十数年でIT業界に広がった技術や概念の多くは、この自己像と相性がいい。

DevOpsは開発と運用の壁を取り払うことを掲げた。IaCはインフラをコードとして扱えるようにした。クラウドはハードウェアの調達や配線をAPI呼び出しに置き換えた。コンテナは実行環境ごとアプリケーションに同梱できるようにした。Platform Engineeringは社内基盤を開発者向けのセルフサービスとして差し出す。AIエージェントは、知らない言語やツールでもひとまず動くものを出してくれる。

どれも、従来別々だった領域を一つにつなげて見せる技術だ。それ自体はよいことで、実際に生産性は上がった。

ただ、境界が見えにくくなると、次のような推論が起こりやすくなる。

境界がなくなった。-> だから自分の担当領域が広がった。-> だから自分はシステム全体を扱える。

しかし、一段目と二段目、二段目と三段目のあいだには、それぞれ飛躍があるのである。

4. 「コードで書けること」と「設計できること」

IaCの場合

特にIaCは、この飛躍が見えやすい例だ。

TerraformでSecurity Groupを書くことはできる。その通信を許可してよいかどうかは、ネットワークとセキュリティの知識で判断することになる。

IAM Roleを書くことはできる。どの操作を、どのリソースに対して、どの条件で許可するのが適切かを決めるには、権限設計の知識が要る。

RDSのインスタンスを定義することはできる。マルチAZにするか、バックアップをどう取るか、障害時にどう切り替わり、どこまで戻せるのか。そこを決めるのはDBと可用性設計の知識だ。

IaCが変えたのは主に記述と再現の方法で、何を記述すべきかの判断は以前と同じ専門知識に依存している。

表現形式が「近づいた」ことの影響

それでも混同が起きやすいのは、その表現形式が開発者に馴染みのあるものになったからだと思う。

以前のインフラ作業は、管理画面、コンソール、手順書、パラメータシートといった、開発者から見ると「よその道具」で行われていた。道具が違えば、そこが別の領域であることは自然と意識されるものだ。

しかし、いまはそれがコードになり、同じエディタで書かれ、同じリポジトリに入り、同じプルリクエストでレビューされる。こうなると、書き方を知っていれば書けてしまうし、terraform plan が通れば動いてしまう。文法上正しいことと設計上妥当であることの区別が、見た目からはつきにくくなったのである。

道具の表現形式が近づいたことで、開発者が専門領域そのものまで自分の領域になったように感じやすくなっている可能性はあるだろう。

5. 能力は加算されるが、責任を同じ尺度で数えない

数えられるものと数えられないもの

フルスタックという言葉は、基本的に「できること」を足していく。フロントエンド、バックエンド、DB、AWS、IaC、CI/CD、コンテナ。扱えるものが増えるほど「フル」に近づく。

この数え方には一つ欠けている軸がある。その領域で問題が起きたとき、どこまで引き受けられるのか、という軸だ。

AWSを触れること、Terraformを書けること、DBを扱えることは、自分の能力として加算される。その先にある本番障害時の判断、IAMの最終判断、データ保護、バックアップからの復旧、性能劣化の原因分析、長期の保守、事故が起きたときの説明までが、同じように自分の責務として加算されるとはかぎらない。

軽い越境と重い責務

難しくなったところで、そこは切り離すことができる。

Terraformを書いた。AWSを使った。コンテナをデプロイした。これらは自分のスキルになる。そのIAM設計が安全かどうかはセキュリティチームに確認する。障害時にどう復旧するかはSREに見てもらう。バックアップが本当に戻るかは基盤担当が知っている。24時間の運用は運用担当がいる。

軽い越境は能力として自分に取り込み、重い責務は専門性として外部化する。こうなると「フルスタック」は、責任範囲の広さを示す言葉から、触った技術の種類を示す言葉に変わっていく。

本人に悪意があるわけではない。できることをやり、できないことを人に頼むのは、個人の行動としてはまっとうだ。問題が起きるのは、組織がその前提で人員を減らしているときだ。

気づかない領域

もう一つ厄介なのは、本人が知識不足に気づいていない領域だ。

過剰なIAM権限。不必要に公開されたポート。認証はあるが認可が甘いAPI。リポジトリや環境変数に置かれたままのSecret。取ってはいるが戻せるか試したことのないバックアップ。単一AZに寄った構成。

どれも、通常の動作確認では問題が出ない。正常系は正しく動き、テストも通る。表に出るのは、攻撃を受けたとき、障害が起きたとき、データを戻そうとしたときだ。

難しいと分かっている部分は専門家に回せる。難しいと分かっていない部分は回せない。セキュリティは、触れることと安全に設計できることの差がいちばんはっきり出る領域で、しかもその差は平常時にはほとんど見えないものだ。

こうして、広く扱える人が増え専門分業を減らせるはずだった組織の中に、「広く触る人がいて、難しい部分と事故のリスクは専門家に流れていく構造」ができあがるのである。

6. 「専門家の仕事」の行き先

フルスタック化が進んだ組織で専門家が不要になったかというと、そうはなっていないことが多い。

組織図から職種が消え、工程表から担当者の欄が消えても、専門知識が必要になる瞬間はなくならない。その仕事は別の形で、結局「詳しい人」のところに集まる。

• プルリクエストのレビュー依頼
• チャットでの「ちょっと聞いていいですか」
• 実装後に見つかった設計の手直し
• 障害対応
• リリース前のセキュリティ確認
• 性能が出ない原因の調査
• 「これで大丈夫ですか？」への回答

これらは正式な担当として割り当てられていないことが多く、工数にも評価にも乗りにくくなる。頼む側にも、相手の本来の仕事の合間に頼んでいるという意識がある。

ここでは、この状態を仮に「専門性の非公式化」と呼んでみたい。専門家の職務は組織図から消えたが、専門家の仕事は残り、名前のつかない相談やレビューや事故処理として流れ続けている状態のことだ。

この状態では専門家の負荷が可視化されない。見えないので増員の根拠にならない。依頼が特定の人に集中しても、その人の評価は割り当てられた業務の範囲で測られるようになる。
そして、その人が疲れて辞めたとき、組織はどれだけ依存していたかを、障害やインシデントを通じて知ることになるわけだ。

7. 「触れること」と「引き受けること」

ある技術との関わり方には、少なくとも次のような段階がある。

1. 触ったことがある
2. 実装できる
3. 設計できる
4. リスクを判断できる
5. 失敗時に対処できる
6. 継続的に運用できる
7. その領域について責任を負える

「フルスタック」という能力表現では、1から3あたりが確認できるだけで、4から7まで含んでいるような印象が作られやすい。 クラウドやIaCによって、1から3に到達するコストは以前よりかなり下がり、触れる範囲は広がりやすくなったが、実は4から7に到達するコストはそれほど変わっていない。

Terraformの書き方を知っている人が、VPC設計の妥当性を判断できるとはかぎらない。判断できる人が、その領域を日常的に担当すべきだともかぎらない。担当している人が、事故が起きたときの最終責任まで負うべきかどうかは、また別の話だ。

「できます」と「担当します」は違う言葉で、「担当します」と「責任を持ちます」もまた違う。...はずなのだが、フルスタックという言葉は、この距離を一気に縮めて見せるようなところがある。

8. エンジニアの成長：能力の見方が変わるとき

「失敗する可能性を持ったもの」としての技術

何ができるか、何を触れるかを中心に能力を数えているあいだは、扱える技術が増えるほど自分が拡張されたと感じる。その能力観にとって、「フルスタック」はとても魅力的な言葉だ。

しかし、しっかり実務経験を積むと、技術の後ろにあるものが見えてくる。

DBを扱えるなら、データを失ったときどうするのか。IAMを設定できるなら、過剰権限による事故をどう防ぐのか。ネットワークを設定できるなら、公開範囲を間違えたら何が起きるのか。コンテナを動かせるなら、障害時にどこまで切り分けられるのか。RDSを作れるなら、障害・性能・バックアップ・復旧まで設計できるのか。

技術が、使えるもの/便利なものから、失敗する可能性を持ったものとして見えるようになる。そうなると能力の数え方も変わる。何を触れるかより、何について判断できるか、何について責任を引き受けられるかが中心になっていく。

知るほど「慎重」になる

各領域について知るほど、その分野に自分の知らないことが大量にあることも分かってくる。

ネットワークを知れば、ネットワーク専門家の深さが見える。DBを知れば、DB専門家の深さが見える。セキュリティを知れば、セキュリティを軽く扱う危険が見える。クラウドを知れば、サービスを組み合わせることと本番システムを設計することの違いが見える。

それが見えている人ほど、全部を一人の責任範囲に入れることの危うさにも気づく。 自分が全部を知っているかどうかとは別に、一人の判断が全領域を通過する構造そのものが、見落としの単一障害点になるからだ。

広い知識は、責務を際限なく広げる根拠にもなるが、責務を適切に分けるための材料にもなる。どこに境界を引けば調整が少なくすむか。どこは必ずレビューを通すべきか。どこには専門家を正式に置くべきか。その判断にこそ広い知識が要る。

だから、これは逆説的なのだが、本当にフルスタックに近い知識を持つ人ほど、フルスタックとして働くことには慎重になる。フルスタックに近づいた結果、フルスタックという職務設計から遠ざかっていくようなところがあるのである。

9. なぜこの言葉は強いのか

二つの欲望の一致

それでも、業界からフルスタックという言葉はなくならないだろう。

企業にとっては、少ない人数で広い領域をカバーできるという経済の物語になる。
エンジニアにとっては、自分はシステム全体を理解できるという自己実現の物語になる。

雇う側と働く側の利害は、たいてい別の方向を向いている。給与、労働時間、評価、配置。多くの論点で両者は綱を引き合う。
しかし、フルスタックは、企業の人材コスト削減への欲望とエンジニアの万能感への欲望が、めずらしく同じ方向を向く概念なのである。

両側から支持されている言葉は、片側が疑いを持っても、簡単には揺らぎにくい。企業が「この人に全部任せると危ないのでは」と思っても、本人が「全部やれます」と言えば、懸念についての議論は止まる。本人が「これは自分の手に余る」と感じても、組織が「フルスタックなんだから」と期待していれば、言い出しにくいだろう。

両方の物語から「抜け落ちるもの」

フルスタックという言葉の中では、企業は、その人が何人分の仕事をできるかを見る。エンジニアは、自分が何種類の技術を扱えるかを見る。どちらも能力の広さには関心がある。

それぞれの領域で失敗したとき、最終的に誰が責任を持つのか。この問いは、どちらの物語の中でも目立たない。ここがいちばんの問題である。

企業は人員を減らせる。エンジニアは万能感を得られる。重い責務は、インフラ、SRE、セキュリティ、DBといった「詳しい人」のところへ戻っていく。フルスタックが二重に都合がいいのは、この「重い責務」の行き先が、どちらの勘定にも入っていないからでもある。

10. おわりに

フルスタックという言葉を否定するような必要はない。
広く技術を理解することには価値があり、領域をまたいで問題を考えられる人はどの組織にも必要なことだ。

ただ、この言葉が扱える技術の広さを称賛する一方で、引き受けられる責任の広さをほとんど問わないことには、能力の数え方として、やや未熟なところがあると思う。
これはフルスタックを名乗る個人の問題というより、フルスタックに対する業界やコミュニティの評価軸の問題だ。

フルスタックとは、何ができるかの一覧なのか。
それとも、何が起きたときに自分が最後まで引き受けられるかの一覧なのか。

後者で数え直したとき、その人に「フル」と言える範囲はどれくらい残るだろうか。

☕️よかったらコーヒー一杯。 https://buymeacoffee.com/mink_obs

著：霧星礼知(min.k) / リサーチ・構造支援：Claude Opus 5.5、ChatGPT / AI-assisted / Structure observation

For international readers

"Full-stack engineer" is usually treated as a compliment: someone who can handle frontend, backend, databases, cloud, and infrastructure-as-code. This essay argues that the term stays popular because it is convenient for two parties at once. For companies, it promises fewer hires and makes the coordination cost between specialties appear to vanish by folding it into a single person. For engineers, it offers a self-image of understanding the whole system, reinforced by DevOps, IaC, cloud, containers, platform engineering, and AI agents, all of which make the boundaries between domains look thinner.

The way "full stack" counts ability is additive: each technology one can touch is added to the list. What is rarely added is responsibility—who decides during a production outage, who owns IAM, who guarantees that backups can actually be restored. Light boundary-crossing is absorbed as personal skill, while heavy responsibility is handed back to specialists, often as informal reviews, quick questions, and incident response that never appear on the org chart. The essay calls this the informalization of expertise. It distinguishes stages from "have touched it" to "can bear responsibility for it," noting that cloud and IaC lowered the cost of the early stages far more than the later ones. Paradoxically, those whose knowledge truly approaches "full stack" tend to be most cautious about working as one. The essay closes by asking how much of "full" would remain if the stack were counted by what one can see through to the end when something fails.

Keywords

full-stack engineer, division of labor, responsibility, professional maturity, DevOps, infrastructure as code, Terraform, cloud security, IAM, informal expertise, coordination cost, organizational design

フルスタックエンジニア、専門分業、責任範囲、職業的成熟、DevOps、IaC、Terraform、クラウドセキュリティ、IAM、専門性の非公式化、調整コスト、組織設計