WEBエンジニアがどのように各工程に上がっていくのか具体例(詳細設計～要件定義)をまとめました＆今後起きる「フルスタック化とAI普及のバッティング」について

現在、多くのWEBエンジニアが「フロントエンドもバックエンドもインフラも、すべて一人でこなせるフルスタックエンジニア」を目指して日々の学習や業務に励んでいます。
プレゼンテーション層・アプリケーション層・DB層を横断し、一人でサービスを立ち上げられるエンジニアは市場価値が高く、将来安泰のように思えます。

しかし、激変する現代のIT業界、特に生成AIが驚異的な進化を遂げている現状において、「コードを書くプロフェッショナルとしてのフルスタックエンジニア」を目指すことは、年収アップや長期的なキャリア生存戦略の観点から、おすすめできなくなりつつあります。

これからの時代にエンジニアとして高年収を獲得し、市場に求められ続けるために最も重要なのは、実装力（コードを書く力）ではなく「設計工程以上のスキル」。
具体的には、生成されたコードの設計に対する「整合性・保守性・脆弱性や技術負債を見抜く力」です。

なぜフルスタックを目指すのが危険なのか、AIが開発現場にもたらす構造変化を紐解いた上で、エンジニアが「上流工程（詳細設計・基本設計・要件定義）」へとステップアップするための具体的なロードマップと、各工程における成果物・面接での評価ポイントを解説します。

1. 「実装だけのフルスタック」の終焉とAIがもたらす「理解負債」の恐れ

1-1. 年収の壁を突破できない、何でも屋

多くのエンジニアが誤解していますが、コードが書ける領域を「横」に広げてフロントエンドとバックエンドの双方をマスターしても、年収は劇的には上がりません。
なぜなら、給与や案件単価の決定決定要因は「習得したプログラミング言語の数が多いか」ではなく、「ビジネスの課題をいかにシステムの構造に落とし込み、課題解決に導けるか」という「縦」の深さ（上流工程の遂行能力）にあるからです。

「仕様書通りに綺麗にコードが書ける領域が広いだけのエンジニア」は、AIの進化によって最も早く代替される領域に位置しています。

1-2. AIは万能ではない（今のところ）

「AIがコードを書くなら、エンジニアは要らなくなるのか？」というと、それは明確に「否」です。
現在の生成AIは、確かに人間を遥かに凌駕するスピードでソースコードを生成します。
しかし、AIには決定的な弱点があります。それは「コンテキスト（システム全体の設計思想やドメイン知識）の欠如」です。

AIは、与えられたプロンプトに対して「部分的な最適化」を行うことは得意ですが、システム全体の複雑な依存関係や、5年後・10年後を見据えた保守性まで考慮してコードを組み立てることは（今のところ）できません。

AI時代の新たなリスク：「理解負債」の誕生
生成AIを使えば、わずか10秒で100行の見事なコードが生成されます。しかし、その100行のコードが「なぜそのように動いているのか」「既存のモジュールとどう影響し合っているのか」を完璧に理解し、説明できる人間は現場にいるでしょうか？ 生産性が爆発的に向上する代償として、中身を誰も説明できないブラックボックス、すなわち「理解負債」がシステム内に急速に蓄積されていきます。

動くけれども誰も中身を説明できないシステムは、障害が発生した瞬間に文字通りの「爆弾」と化します。
そのため、品質と説明責任が極限まで求められる大規模案件や基幹システムにおいて、コンテキストを持たないAIに丸投げしたコードはリスクが高すぎて採用されにくいのが実態です。

1-3. 近未来に起こる「プロンプトオペレーター」の買い叩きと仮説検証力の空洞化

しかし、技術の進化スピードを考えれば、詳細設計書をインプットすれば正確な実装コードを出力するレベルには、極めて近い将来（あるいはすでに部分的に）到達するでしょう。
その時、コードを書くことしかできないエンジニアの価値は暴落するはずです。

おそらく、近い将来の労働市場には「プロンプトオペレーター」という新たな低単価職種が生まれるでしょう。
「IT業界未経験OK」と謳う求人に募集すると、1ヶ月ほどのプロンプト発行研修を受けさせられ、用意された設計書をAIに投入してコードを出力させ、テストを実行するだけの現場に大量に送り込まれるようになります。

ここで深刻なのは、エンジニアの「仮説検証力の空洞化」です。
従来の開発では、以下のような泥臭いプロセスが存在しました。

• 仕様を読み込み、コードの挙動を「仮説」を立てて推測する。
• 実際にコードを書き、エラーと格闘する。
• デバッグを通じて、言語の仕様やフレームワークの内部構造を深く「理解」する。

この試行錯誤の過程こそが、エンジニアの思考力と基礎スキルを育てていました。
しかし、AIに依存しすぎると「とりあえずAIに投げる」「動かなければ、何が悪いか考えずに別のプロンプトを投げる」という、いわば「AIガチャ」を繰り返すようになります。
これでは、エラーの本質を見抜く力も、システムを組み立てる思考力も一切育ちません。

1-4. これからの時代、エンジニアの生存戦略はどうなる

AI利用が前提（マスト）となるこれからの時代において、エンジニアが生き残り、高年収を獲得するために必要な能力は、コードを書くスピードではありません。

• 生成されたコードが、システム全体の設計に対する整合性を保っているか見抜く力
• 将来的な拡張に耐えうる保守性があるか評価する力
• 予期せぬ脆弱性や技術負債が埋め込まれていないかレビューする力

これらの能力を養うためには、泥臭い基礎スキルを身につけた上で、難易度の高い案件に参画し、「基本設計」「要件定義」といった上流工程の経験を積むことが唯一無二の近道です。
システム開発における本質的な思考力を養って初めて、AIを正しく使いこなす「指示役」になれるのです。

2. 上流工程に上がっていくためのロードマップと各成果物

では、現場の実装担当（製造工程）から、詳細設計、基本設計、そして要件定義へとステップアップしていくには、どのような成果物作成スキルを身に着ければよいのでしょうか。
各工程の具体的な業務内容、生み出すべき成果物、そして転職活動でチェックされるポイントをご説明します。

製造（コーディング～単体テスト）

エンジニアの出発点であり、AIによる代替圧力が最も強いレイヤーです。
ここでは「言われた通りに書く」だけでなく、上位の設計意図をコードに正確に反映する力が求められます。

［成果物］

製造工程におけるアウトプットは、動作するソフトウェアそのものと、その品質を担保するエビデンスです。

• ソースコード / SQL: 読みやすく、拡張性の高いクリーンコード。複雑なデータ抽出・更新を行うSQLクエリ。
• バッチプログラム / Shell: 定期処理やデータ移行を自動化するためのスクリプト。
• API実装: 設計書に基づいたRESTfulまたはGraphQLなどのエンドポイント実装。
• 単体テスト仕様書・結果: カバレッジ（網羅率）を満たし、正常系・異常系が正しく検証されたテストコードおよびエビデンス。

［面接で確認されるポイント（次の工程へ上がるために）］

面接官は、単に「コードが書けるか」ではなく、チーム開発の規律を守り、バグの少ないコードを自立して書けるかを見ています。

• コーディング規約の遵守: チームや言語のベストプラクティス（リーダブルコードなど）を意識して書いているか。
• コードレビュー経験: 指摘を受けるだけでなく、他人のコードに対して建設的なレビュー（リファクタリングの提案など）を行っているか。
• Git運用経験: Git-flowやGitHub Flowを理解し、コンフリクトの解消や適切なコミット粒度でプルリクエストを作成できるか。
• デバッグ方法: エラーが発生した際、ログを追いかけ、ブレークポイントを活用して原因を論理的に特定できるか（AIガチャに頼っていないか）。

詳細設計（内部設計）

詳細設計は、基本設計で決まった「システムの振る舞い」を、「どのようなプログラム構造（クラス、関数、データベース）で実現するか」という、実装の直前のレイヤーまで落とし込む工程です。

［主な成果物］

詳細設計書：基本設計をもとに、プログラマが迷わずコードを書けるレベルまで具体的なプログラムの処理ロジックを落とし込んだ設計書。

クラス図：オブジェクト指向設計において、システムを構成するクラス（プログラムの部品）の構造や、クラス間の関係性を表現した図。

モジュール構成図：プログラムを機能単位（モジュール）に分割し、それらがどのように組み合わさってシステムが構成されているかを示した図。

パッケージ構成図：大量のソースコードやクラスを、役割ごとにフォルダ分け（パッケージ化）する際のディレクトリ構造を定義した図。

シーケンス図：プログラム内部のオブジェクトや関数間で、どのような順序でメソッドが呼び出され、データが処理されるかを時系列で表した図。

内部API仕様書：システム内の特定のコンポーネント間や、同一サーバー内の非公開な処理同士がデータをやり取りするための通信仕様書。

メソッド定義書：クラス内に定義する具体的な関数（メソッド）の名称、引数（受け取るデータ）、戻り値（返すデータ）、および処理内容を定義した書面。

SQL設計書：データベースからデータを取得・更新する際、パフォーマンスを考慮して事前に組み立てた具体的なSQLクエリ文の設計書。

物理DB設計書：論理設計をもとに、特定のデータベース製品（MySQLやPostgreSQLなど）に合わせて、インデックス設定やデータ型、容量を最適化した設計書。

バッチ詳細設計書：裏側で動く一括処理プログラムについて、ループ処理の条件、エラー時のリトライ回数、例外発生時の挙動などを含めて詳細に定義した設計書。

例外処理設計書：プログラム実行中に予期せぬエラー（通信遮断やデータ不正など）が起きた際、システムを安全に停止・復旧させ、ログをどう残すかを定めた設計書。

状態遷移詳細図：プログラム内部の変数やフラグ、オブジェクトが、具体的な内部処理（メソッド実行など）によってどう変化するかを細かく表した図。

単体テスト仕様書：作成したプログラムの最小単位（関数やクラス）が、設計通りに正しく動くかを検証するためのテスト項目や期待される結果をまとめた仕様書。

［面接で確認されるポイント］

詳細設計ができるエンジニアとして評価されるには、上記を一人称で作成できるか、変更に強くバグが起きにくい構造を意図的に作れるか、が問われます。

• クラス分割方針・コンポーネント設計：オブジェクト指向の原則を理解し、1つのクラスに処理が集中しないよう疎結合な設計ができるか。
• 例外処理・ログ設計：システムが異常事態に陥った際の防御策を網羅し、障害原因を特定しやすいログ出力ルールを定めているか。
• トランザクション設計：複数のテーブルをまたぐ更新処理において、データの不整合を絶対に防ぐ境界をロジカルに決定できるか。
• SQL設計とパフォーマンス考慮：大量データやアクセス集中を想定し、インデックスやクエリを最適化してボトルネックを先回りして排除したか。
• 共通部品設計・再利用性：システム全体の開発効率を高め、未来の技術負債や理解負債を減らすための共通化の基準を持っているか。

基本設計（外部設計）

基本設計は「システムが何をするのか（画面、インターフェース、データ構造）」という外見と振る舞いを決める工程です。

［主な成果物］

機能一覧表：システムが提供するすべての機能を網羅し、開発範囲（スコープ）の全体像を把握するための管理表。

画面一覧：システムに存在するすべての画面を洗い出し、画面IDや画面名で全体の画面数を把握するための表。

画面設計書：各画面のレイアウト（ワイヤーフレーム）、ボタン配置、表示項目、入力制限（バリデーション）ルールを定めた設計書。

画面遷移図：ユーザーの操作によって「どの画面からどの画面へ移動するか」という、画面間の繋がりを示した図。

業務フロー図：ユーザーの業務全体の流れを記述し、システムがその業務のどの部分を自動化・サポートするかを明確にした図。

処理フロー図：システム内部や機能単位で、データがどのような手順で処理・条件分岐されていくかの大まかな流れを表した図。

状態遷移図：データ（例：受注、出荷済、キャンセルなど）やシステムの状態が、ユーザーの操作やイベントによってどう変化するかを表した図。

シーケンス図：画面、サーバー、データベース、外部システムの間で、処理やデータがどのような順序（時系列）でやり取りされるかを示した図。

API仕様書：フロントエンドとバックエンド、またはシステム間で通信する際のリクエスト・レスポンスのデータ形式やルールを定めた仕様書。

バッチ一覧：夜間集計や定期自動処理など、画面を介さずに裏側で一括処理を行う機能の一覧表。

バッチ設計書：各バッチ処理の起動タイミング（トリガー）、処理対象データ、およびデータ加工・計算ロジックの概要をまとめた設計書。

帳票設計書：システムから出力・ダウンロードされるPDFやExcelなどのレイアウトや印字項目、改ページルールなどを定義した設計書。

メール設計書：システムから自動送信されるメールの送信条件（タイミング）、件名、本文、および動的なデータの埋め込みルールを定めた設計書。

ER図：システムで扱うデータ（実体＝エンティティ）と、データ同士の繋がり（リレーション）を視覚的に表した図。

テーブル定義書（論理）：データベースに保存するデータの日本語名、論理的なデータ型、主キーや外部キーの関係を論理レベルで定義した設計書。

権限設計書：ユーザーの役割（管理者、一般社員、閲覧のみなど）ごとに、どの画面や機能の操作を許可するかをまとめたマトリクス表。

コード体系設計：商品IDや会員番号など、システム全体で使用する各種識別子（コード）の採番ルールや各桁の持つ意味を定義したもの。

非機能要件定義書：処理速度（レスポンス時間）、セキュリティ基準、稼働率、バックアップ体制など、機能面以外で満たすべき品質基準をまとめた文書。

3階層構造図：WEBサーバー、AP（アプリケーション）サーバー、DB（データベース）サーバーなど、インフラやシステムの物理的・論理的な配置構成を表した図。

外部インターフェース設計書：他社システムや既存の基幹システムなど、自社システムの外側にある環境とデータ連携するための接続方法や仕様を定めた設計書。

［面接で確認されるポイント］

基本設計レイヤーの面接では、ユーザー目線とシステム制約の双方をバランスよく考慮できる「思考の柔軟性と正確性」が問われます。

• 画面設計をゼロから作成したか: 既存のテンプレートの流用ではなく、ユーザーの操作性を考慮してワイヤーフレームや項目定義を自ら組み立てた経験があるか。
• 項目定義・バリデーションの網羅性: 必須チェック、文字数制限、文字種チェック（半角・全角）などを漏れなく定義したか。
• 権限制御の設計経験: セキュリティリスクを排除するために、URLの直叩きやAPIの不正呼び出しを防ぐ権限制御を仕様に組み込めたか。
• テーブル設計（正規化）の経験: 第3正規化まで正しく行い、データの重複を排除した論理的なデータ構造を構築できるか。

要件定義

顧客の「こんなシステムが欲しい（あるいは、業務のここが困っている）」という曖昧な言葉から、「開発すべきシステムの仕様とスコープ」を決定します。
ここでは技術力以上に、高いコミュニケーション能力と顧客の求めているシステムを正しく理解する力が求められます。

［成果物］

業務フロー図：現行または新規のビジネスプロセスにおいて、「誰が・いつ・何を・どのような手順で」行うのか、業務全体の流れを視覚的に表した図。

As-Is/To-Be業務フロー：システム導入前の「現在の業務の姿（As-Is）」と、システム導入によって改善された「理想の業務の姿（To-Be）」を対比して表現した図。

機能一覧：ビジネス上の要求を満たすために、システムが実装しなければならない機能（画面処理、バッチ処理など）を網羅したリスト。

ユースケース一覧：システムを利用するアクター（ユーザーや外部システム）と、システムが提供する振る舞い（ユースケース）の組み合わせを網羅した一覧。

業務要件定義書：顧客が解決したい経営課題や業務上の目的、システム化の背景、および新システムで実現したい業務要求をまとめた文書。

システム要件定義書：業務要求（業務要件）を実現するために、システムとしてどのような機能や性能を持たせるべきかを技術者向けに定義した文書。

非機能要件定義書：処理性能（レスポンス速度）、セキュリティ、可用性（稼働率）、移行、運用保守など、機能面以外でシステムが満たすべき品質基準を定めた文書。

用語集：顧客の業界固有のビジネス用語や、プロジェクト内で使われるシステム用語の定義を共有し、関係者間の認識のズレを防ぐための辞書。

概念モデル：業務で扱う主要なオブジェクト（例：顧客、注文、商品など）とその関係性を、技術的な詳細（DB設計など）を排除して大まかに可視化した図。

システム構成図：サーバー、ネットワーク、外部サービス、およびそれらの接続関係など、新システムを構築するインフラの全体像を俯瞰した図。

データフロー図（DFD）：システム内外で「データがどこから発生し、どこで加工され、どこに保存・出力されるか」という、データの流れに着目して表現した図。

画面一覧：要件定義の段階で想定される、システムに必要な画面（ログイン、一覧、詳細など）を大まかに洗い出した管理表。

帳票一覧：システムから出力（印刷・ダウンロード）する必要がある請求書やレポートなどの書類を洗い出した管理表。

インターフェース一覧：既存の社内システムや他社の外部サービスなど、新システムとデータを連携・同期させる対象をまとめた一覧表。

［面接で確認されるポイント］

要件定義ができる人材の面接では、技術の他に「顧客のビジネスの味方でありながら、開発プロジェクトをコントロールできるか」というビジネス理解力が見られます。

• 顧客との要件調整・ネゴシエーション経験: 顧客の「あれもこれもやりたい」という無理な要望に対し、予算と期間を考慮してどのように説得し、スコープ（実装範囲）を決定したか。
• 要件の優先順位付け（マスト/ウォントの切り分け）: プロジェクトを成功させるために、どの機能をフェーズ1に組み込み、どれを後回しにするかの判断基準をロジカルに説明できるか。
• 複雑な業務ルールの整理: 顧客自身も言語化できていない複雑な社内規定や業務プロセスをヒアリングで紐解き、綺麗なフロー図に落とし込めるか。
• 非機能要件の定義経験: 「画面が3秒以内に開くこと」「アクセス集中時にサーバーが落ちないこと」といった、顧客が口にしない潜在的なシステム品質を先回りして握る力があるか。

3. AIを使いこなすエンジニアへ

WEBエンジニアとしてキャリアをスタートした人の多くは、コードを書く楽しさに魅了され、技術の幅を広げることに熱中します。
しかし、本コラムで述べた通り、AIが爆発的なスピードで進化するこれからの時代、「書けるコードの数増やすだけのフルスタック化」は、生存確率を著しく下げます。

目指すべきは、AIが10秒で出力した100行のコードに対して、 「このクラス分割は、今回の基本設計のエンティティ構造と矛盾している」 「この例外処理では、トランザクションのロールバックが漏れているため、将来の理解負債になる」 と見抜き、軌道修正できるエンジニアです。

そのためには、まず【製造】の現場で徹底的に基礎を叩き込み、AIの出力の嘘を見破る力を養った上で、一歩ずつ【詳細設計】→【基本設計】→【要件定義】→【PM】へとステップアップしていく必要があります。

システム開発における本質的な思考力は、顧客のビジネスを理解し、それを美しい構造（アーキテクチャ）へと落とし込む上流工程の経験によってのみ養われます。技術の流行り廃りに振り回され、AIに仕事を奪われるプロンプトオペレーターになるのか、それともAIを強力な武器として従え、大規模案件を設計からコントロールする高年収エンジニアになるのか。

その分かれ道は、あなたが今「設計工程」から逃げずに、思考力を磨く打席に立ち続けるかどうかにかかっています。ぜひ、AI時代に真の価値を持つ「設計ができる高付加価値エンジニア」への道を、力強く突き進んでください。