AIによって、エンジニアが扱える範囲は広がった。
従来は実装経験を中心に説明すればよかったが、現在は次の工程まで一人で扱える。
- ビジネス課題の調査
- 要件整理
- 技術選定
- 実装
- テスト
- コードレビュー
- 顧客説明
- 運用手順の作成
- 障害対応
- 改善計画
一方で、面接時間と面接官の認知容量は増えていない。
そのため、職務経歴書、スキル欄、面接では、知っている技術をすべて説明するのではなく、次の一連の流れを再現できることを示す。
ビジネス課題 → 制約と優先順位 → 技術的な問題構造 → 選択肢とトレードオフ → 開発計画 → アーキテクチャと実装 → 検証と人間の監査範囲 → 説明 → 導入・運用・撤退
このガイドラインでは、職務経歴書を「経歴の一覧」ではなく、面接で共有する前提条件と評価プロトコルとして扱う。
次のような記述だけでは、何を任せられるか判断できない。
- PHP経験10年
- Symfony経験5年
- ChatGPTを利用
- EC-CUBEのカスタマイズ経験
- DDDを学習
技術名は、判断能力の証拠として使う。
中心に置くのは、次の内容である。
- どの課題を扱ったか
- 何を優先したか
- どの案を採用したか
- 何を採用しなかったか
- どこを人間が監査したか
- どう検証したか
- 誰にどう説明したか
- 問題時にどう戻したか
AI利用をコード生成だけで説明しない。
AI支援開発は、次の工程として示す。
課題整理 → 選択肢の生成 → 実装支援 → 検証 → 相手別説明 → 運用・改善
AIが担当した作業と、人間が保持した判断を分ける。
- 情報探索
- 既存コードの調査
- 選択肢の列挙
- 定型コードの生成
- テストケース候補の抽出
- 静的解析エラーの整理
- 差分の要約
- 説明資料の初稿
- 運用手順の雛形
- ビジネス課題の定義
- 制約と優先順位
- 業務ルール
- 責務境界
- 品質水準
- 監査範囲
- 受入条件
- 採用・不採用判断
- リリース判断
- 撤退判断
すべての案件へ同じ品質水準を適用しない。
プロトタイプ、社内ツール、短期キャンペーン、決済処理では、必要な品質が異なる。
品質水準は、次の条件から決める。
- 利用者数
- 利用期間
- 障害時の影響
- 扱うデータ
- 金銭への影響
- 外部サービスとの連携
- 復旧可能性
- 変更頻度
- 保守期間
面接では、常に最高品質を目指すと答えるのではなく、どの領域へ先に品質投資するかを説明する。
AI生成コードをすべて一行ずつ確認する運用は成立しない。
人間の監査資源は、重大事故につながる境界へ集中する。
監査範囲は、次の6項目で決める。
- 権限
- 守る資産
- 副作用
- 可逆性
- 検知可能性
- 被害範囲
- 認証・認可
- 決済・返金
- 個人情報
- 在庫
- 受注状態
- 会計
- データ削除
- 一括更新
- マイグレーション
- 外部APIの更新処理
- ファイルアップロード
- 本番バッチ
- ログへの機密情報出力
- コードスタイル
- 型
- Lint
- ビルド
- 定型的な表示変更
- 既存テストで覆われた処理
- 破棄可能なプロトタイプ
ただし、ファイル種別だけで判断しない。
テンプレート変更でも、個人情報表示、URL生成、raw 出力を含む場合は監査レベルを上げる。
職務要約では、技術スタックの列挙より、仕事の進め方を示す。
Web開発において、ビジネス課題、制約、技術的な問題構造を整理し、実装、検証、説明、運用までを一連の工程として扱う。 AIは調査、選択肢整理、コード生成、テスト観点抽出、説明資料作成に利用し、業務ルール、責務境界、受入条件、監査範囲、リリース判断は人間側で管理する。 コードだけでなく、テスト、検証記録、顧客説明、運用手順を成果物として残す。
個別案件ごとに同じ工程を繰り返さず、職務経歴書の前半に共通ワークフローを置く。
- ビジネス課題を整理する
- 制約と優先順位を決める
- 技術的な問題構造を分解する
- 選択肢とトレードオフを比較する
- 開発計画を段階化する
- 責務境界を決めて実装する
- 自動検証と人間の監査範囲を分ける
- 顧客、経営者、開発者、運用担当者向けに説明を分ける
- 導入、監視、復旧、撤退方法を定義する
- 判断を次回へ再利用できる形で記録する
各案件では、工程全体を繰り返さず、重要な判断を中心に書く。
何に困っていたか。
何を優先し、何を後回しにしたか。
どのデータ、状態、外部サービスが関係したか。
何を比較し、なぜその案を選んだか。
どの層・機能へ何を配置したか。
正常系、異常系、権限、障害、復旧をどう確認したか。
どこを必ず人間が確認したか。
誰に何を説明し、どのように導入したか。
EC-CUBE 4系のサイト固有カスタマイズについて、コア改変、
app/Customize、プラグイン、イベント、PurchaseFlowの使い分けを整理した。 AIを既存コード調査、実装案比較、テスト観点抽出、説明資料作成に利用した。 人間側では、受注、在庫、決済、ポイント、メールへの影響範囲と責務境界を整理し、Controllerへ業務判断を流出させない方針を設定した。 決済、在庫、認可、状態遷移、二重実行防止を人間の重点監査対象とし、定型的なControllerやフォーム実装は自動テストと静的解析を中心に確認した。 顧客向けには業務影響と保守リスク、開発者向けにはSymfony・EC-CUBEの拡張方法として説明を分けた。
- ChatGPT
- Claude
- Codex
- Symfony
- EC-CUBE
- PHPUnit
これでは利用範囲と責任範囲が分からない。
- 要件整理、影響分析、実装案比較
- 既存コード調査、コード生成、リファクタリング支援
- テストケースと異常系の抽出
- 静的解析、自動テスト、手動確認による受入
- 顧客、経営者、開発者、運用担当者向け資料の作成
- 業務ルール、責務境界、受入条件、監査範囲は人間側で管理
app/Customize、Plugin、EventSubscriber、PurchaseFlowの適用判断- Controller、Service、Repository、FormTypeの責務分離
- 受注、在庫、決済、ポイント、メールへの影響分析
- 認可、CSRF、状態遷移、二重実行防止の確認
- PHPUnit、Playwright、PHPStanによる検証
- 顧客向け業務説明と開発者向け技術資料の作成
同じスキルを、相手の理解度に合わせて説明する。
ECサイトの変更が在庫や決済へ与える影響を整理し、事故を防ぐ。
画面処理、業務処理、データアクセスを分離する。
Controller、Service、Repository、PurchaseFlow、EventSubscriberを責務に応じて使い分ける。
最初からレベル3で説明しない。
面接では、複数のビジネス課題に対して、同じ判断手順を再現できるかを示す。
- ビジネス課題
- 制約と優先順位
- 技術的な問題構造
- 選択肢とトレードオフ
- 開発計画
- アーキテクチャと実装
- 検証
- 人間の監査範囲
- 導入・運用・撤退
最初からフレームワーク固有の用語を出さない。
注文キャンセルでは、画面上の状態だけでなく、決済、在庫、ポイントが連動します。 そのため、表示変更と業務処理を分け、部分失敗と二重実行を検証します。
面接官が詳細を求めた場合だけ、次の段階へ進む。
実装では、Controllerを入力と応答に限定し、業務処理をServiceへ集約します。
さらにEC-CUBE固有の質問があれば説明する。
EC-CUBEでは
app/CustomizeとPurchaseFlowを責務に応じて使い分けます。
- 課題
- 優先順位
- 採用方針
- 検証
- 問題構造
- 選択肢
- 実装
- 監査範囲
- 導入・撤退
- クラス構成
- 状態遷移
- テスト
- セキュリティ
- ログ
- 運用
- AI制御
- 調査
- 選択肢整理
- 実装支援
- テスト観点抽出
- 説明資料作成
AIは、既存コードの探索、実装案の比較、定型コード生成、テストケース候補、説明資料の初稿に使います。 業務ルール、責務境界、受入条件、監査範囲、リリース判断は人間側で持ちます。
すべてを同じ深さでは確認しません。 権限、決済、個人情報、在庫、削除、外部API更新のような高リスク領域は人間が必ず監査します。 コードスタイル、型、定型的な表示処理は自動検証へ寄せます。 判断基準は、資産、副作用、可逆性、検知可能性、被害範囲です。
すべての案件へ同じ品質水準は適用しません。 試作品や社内ツールでは、まず動くものを作り、利用価値を確認します。 一方で、決済、個人情報、在庫、認可は初期段階から検証を厚くします。 後回しにした設計課題には、改善または撤退の条件を付けます。
- 守る資産を特定する
- 重大事故を挙げる
- 必須監査範囲を決める
- 自動化する範囲を決める
- 受入条件を示す
- 復旧方法を示す
重要資産は、注文、決済、在庫、ポイント、顧客情報です。 決済取消、状態遷移、在庫復元、権限、二重実行防止は人間が監査します。 定型的な画面実装や型チェックはAIと自動検証へ寄せます。 決済失敗、通信切断、再実行、権限不足を受入試験に含めます。 問題時は自動処理を止め、手動運用へ戻せるようにします。
一つの成功事例だけでは、再現性を判断しにくい。
異なる性質の事例を三つ以上用意する。
例：
- EC-CUBEの注文キャンセル
- 在庫連携
- 決済
- ポイント
- 予約管理
示す能力：
- 状態遷移
- データ整合性
- 部分失敗
- 二重実行
- 監査証跡
例：
- 問い合わせフォーム
- 資料請求
- CRM連携
- メール送信
- スパム対策
示す能力：
- 個人情報
- 入力境界
- 外部サービス
- 障害時の運用
- 顧客説明
例：
- WordPress更新
- 表示速度改善
- セキュリティ対応
- PHP更新
- テスト導入
示す能力：
- 影響分析
- 品質基準
- 段階導入
- ロールバック
- 運用手順
例：
- データ整理
- 社内検索
- レポート生成
- 定型業務支援
示す能力：
- 品質水準の調整
- 利用範囲の制限
- 捨てる条件
- 本番システム化の境界
- 制約は3点まで
- 選択肢は2案、最大3案
- アーキテクチャの責務は3領域程度
- 監査対象は重要なものから示す
- AI利用の説明は最後に置く
主線はビジネス課題とアーキテクチャに置く。
- 業務課題
- 制約
- 設計
- 検証
- 運用
- AIをどこで使ったか
- 人間が何を判断したか
- AI出力をどう検証したか
AI制御は、アーキテクチャの代替ではなく、決めた設計を守らせる開発プロセス上の仕組みとして説明する。
- 標準ワークフロー
- AIと人間の責任境界
- 代表的なビジネス課題
- 品質水準の決め方
- 人間の監査範囲
- 成果物
- 面接で深掘り可能な論点
- なぜその案を採用したか
- 何を採用しなかったか
- どこを人間が監査したか
- 何を自動検証へ任せたか
- どの異常系を確認したか
- 問題時にどう戻すか
- 別の課題でも同じ判断を再現できるか
AI時代は、コードだけを成果物としない。
次をセットで示す。
- 実装コード
- テストコード
- 受入条件
- 検証記録
- 設計判断記録
- 採用しなかった案
- 顧客向け説明
- 開発者向け技術資料
- 運用手順
- ロールバック手順
成果物ごとに役割を分ける。
コードには How テストには What 判断記録には Why コメントや設計記録には Why not 運用手順には When and Who
ChatGPT、Claude、Codexを利用できます。
何を任せ、何を人間が判断したかを追加する。
AI生成コードは必ずすべてレビューします。
現実性がなく、監査資源の配分能力も示せない。
必ずDDDとクリーンアーキテクチャを採用します。
課題、規模、寿命、事故コストに応じた判断を示す。
PurchaseFlowとEventSubscriberを使います。
先に業務上の意味を説明する。
注文処理と画面変更を分け、在庫や決済への影響を限定します。
AIで開発速度を10倍にしました。
前提、品質、監査、検証、運用が分からない。
- ビジネス課題から説明している
- 共通ワークフローを記載している
- AIと人間の役割を分けている
- 人間の監査範囲を示している
- 検証方法を示している
- 顧客・開発者・運用担当者への説明を示している
- 導入・撤退方法を示している
- 技術名だけの列挙になっていない
- 面接で深掘りできる論点を残している
- ツール名ではなく利用工程を示している
- 一般向け・技術者向けに説明粒度を変えられる
- 業務上の意味を説明できる
- 人間が保持する判断を明確にしている
- 成果物と検証方法を示している
- 最初は30秒から2分で全体を説明できる
- 技術詳細は質問されたら追加する
- 制約と優先順位を示している
- 採用しなかった案を説明できる
- 人間の監査範囲を説明できる
- AIと自動検証へ任せる範囲を説明できる
- 正常系だけでなく異常系を示している
- 撤退・復旧方法を説明できる
- 異なるビジネス課題でも同じ型を再現できる
AI時代の職務経歴書と面接で重要なのは、生成AIを使えること自体ではない。
評価すべきなのは、次の能力である。
- ビジネス課題を技術課題へ変換する
- 制約と優先順位を決める
- 品質水準を案件ごとに変える
- 責務境界を設計する
- AIへ任せる範囲を決める
- 人間が監査すべき境界を特定する
- 検証と受入条件を定義する
- 相手に合わせて説明する
- 小さく導入し、問題時に撤退する
- 判断を次の案件へ再利用する
職務経歴書を工程説明の正典にし、面接では、何を判断し、何を監査し、何をAIへ任せたかを確認する。
AI時代のエンジニア面接は、候補者がすべてを知っているかを確認する場ではない。
限られた人間の判断と監査を、どこへ配分するかを確認する場である。