更新日：2026-07-12
このガイドラインは、フロントエンドエンジニアを中心とした技術面談および職務経歴書のレビューで、技術名や実装量ではなく、事業課題に対する判断、責任範囲、実装能力、持続可能性を評価するためのものです。
職務経歴書は、過去の作業一覧ではありません。採用側が次の意思決定を行うための資料です。
- どの案件を任せられるか
- どこまで責任を持たせられるか
- 通常時と問題発生時に、どのような判断をするか
- 直接経験のない課題へ、どのように対応するか
- 入社後にどの役割へ広げられるか
中心となる考え方は次です。
技術は、事業機会を増やすと同時に、保守・運用・安全性・依存関係の責任も増やす。技術面談では、何を作れるかだけでなく、何を作らず、何を外部へ任せ、いつ見直し、いつ撤退するかを説明する。
技術経験は、次の三つに分けて評価します。
- 実務 — 現在の案件を成立させ、利益や業務改善につなげる活動
- 技術投資 — 将来の案件や事業機会に備えて、選択肢と判断基準を増やす活動
- 能力投資 — コード、仕様、テスト、レビュー、チーム開発などの能力を伸ばす活動
また、実務経験は問題解決能力を示す有力な証拠ですが、問題解決能力そのものではありません。直接経験がない場合でも、隣接経験、パターン知識、類推、検証によって解決できる問題があります。
一方、適切なアーキテクチャを選べることと、その設計を安全に実装できることは別の能力です。職務経歴書と面談では、判断能力と実装能力を別々の証拠で確認します。
最初に確認するのは、コード上の問題ではなく、事業上の問題です。
- 売上機会を増やしたい
- 問い合わせ対応を効率化したい
- 更新作業を社内で完結させたい
- 障害やセキュリティ事故を減らしたい
- 特定担当者への依存を下げたい
実装課題は、これらを解決するための手段として扱います。
悪い説明
Reactで管理画面を実装しました。
改善後
更新頻度が高く、複数画面で同じ状態を扱う管理業務だったため、画面間の整合性と改修速度を優先してReactを採用しました。一方、運用担当者が少なかったため、依存ライブラリと状態管理の範囲は限定しました。
「何を使ったか」より、次を確認します。
- なぜ必要だったか
- 代替案は何だったか
- 何を優先したか
- 何をあきらめたか
- どの責任を引き受けたか
- どの条件で見直すか
技術選定では、採用した案だけでなく、見送った案も評価対象です。
手札が多いとは、使える技術が多いことではない。採用条件と不採用条件を多く持っていることである。
AIやオープンソースによって実装開始のコストは下がります。しかし、次の責任は残ります。
- 更新
- 脆弱性対応
- 障害調査
- データ保全
- 権限管理
- 利用者への説明
- 担当者交代
- サービス終了時の移行
「作れる」だけでなく、「持ち続けられる」ことを確認します。
技術活動を一つの尺度で評価しません。
現在の案件を、納期、予算、保守体制の中で成立させる活動です。
確認する項目：
- 顧客や会社の利益につながったか
- チームが運用できるか
- 障害時に復旧できるか
- 維持費が利益に見合うか
将来の案件や事業機会に備えて、選択肢を増やす活動です。
確認する項目：
- どのビジネス課題を想定したか
- 採用条件と不採用条件を整理したか
- 既存手段との差を検証したか
- 導入、移行、撤退の条件を定義したか
個人またはチームの仕事能力を伸ばす活動です。
確認する項目：
- コードを書いたか
- 仕様を作成したか
- テストや障害再現を行ったか
- レビューやチーム開発を経験したか
- 判断理由を記録したか
- 他者が引き継げる成果物にしたか
現在の仕事で利益を生む技術、将来の選択肢を増やす技術、能力を伸ばす活動が一致するとは限らない。それぞれの目的と成果を分けて評価する。
すべての業種、業務、障害、システム構成を直接経験することはできません。
問題解決に利用できる材料を、次の段階に分けて確認します。
- 直接経験 — 同じ製品や業務を本番環境で扱った経験
- 隣接経験 — 異なる製品や業務で、同じ問題構造を扱った経験
- パターン知識 — アーキテクチャパターン、事例、標準仕様、障害事例から得た知識
- 検証経験 — プロトタイプ、再現コード、テスト、仕様作成による確認
- 実務投入能力 — 組織、予算、運用、セキュリティを含めて本番へ導入する能力
「実務経験なし」という記述だけで評価を終えず、どの段階まで到達しているかを確認します。
評価すべきなのは、同じ案件を経験したかだけではない。未知の問題を既知の構造へ変換し、追加検証が必要な差分を発見できるかである。
- ビジネス課題を分解する
- 前提と制約を確認する
- 複数の選択肢を比較する
- 技術やサービスの責任範囲を決める
- リスク、運用、撤退を説明する
- 条件変更に応じて判断を修正する
- 既存コードを読む
- 小さく安全に変更する
- 入力検証や例外処理を書く
- 外部APIと連携する
- テストとデバッグを行う
- セキュリティ上の前提を確認する
- 保守可能な形で引き渡す
システム設計の説明が優れていても、実装能力を証明したことにはなりません。コード量が多くても、適切な技術判断ができることを証明したことにはなりません。
技術選定は、製品名から始めません。次の順序で整理します。
- ビジネスモデル — 誰に、何を、どのように提供し、どこで利益を得るか
- 顧客と関係者 — 利用者、運用担当者、管理者、外部事業者
- 業務イベント — 何が起き、どの順序で状態が変わるか
- 正常系と異常系 — 成功だけでなく、失敗、重複、競合、停止時を扱う
- 必要な業務能力 — 商品、注文、決済、在庫などへ分解する
- データの所有者 — どのシステムを正とするか
- 非機能要件 — セキュリティ、性能、復旧、監査、保守体制
- 実現方法の比較 — 現状維持、運用改善、SaaS、パッケージ、独自実装
- アーキテクチャの決定 — 責任境界と依存関係を定める
- 追加検証と実装範囲 — 未知の部分と担当範囲を明確にする
画面一覧や製品機能の前に、業務で起きる出来事を整理します。
ECサイトの例：
- 商品が登録された
- 販売価格が決まった
- 在庫が入荷した
- 顧客が注文した
- 決済が承認された
- 在庫が引き当てられた
- 商品が出荷された
- 返品が申請された
- 返金が実行された
異常系の例：
- 決済は成功したが、注文登録に失敗した
- 注文後に在庫不足が判明した
- 一部商品だけ出荷できない
- 返品処理は完了したが、返金に失敗した
- 外部サービスから同じ通知が複数回届いた
ECサイトを一つの機能として扱わず、次の業務能力へ分けます。
- 商品管理
- 価格管理
- 注文管理
- 決済
- 在庫管理
- 出荷管理
- 返品・返金
- 会員管理
- 会計連携
- 問い合わせ対応
アーキテクチャパターンは、製品やクラウドサービスの組み合わせを暗記するためのものではありません。構成が必要になった背景を読み取ります。
| パターン | 背景にある問題 | ECサイトでの例 |
|---|---|---|
| 非同期処理 | 利用者を長時間待たせられない | 注文後のメール送信 |
| キュー | 一時的な処理集中を吸収したい | セール時の注文処理 |
| 冪等性 | 同じ要求が複数回届く | 決済Webhook |
| 状態遷移 | 処理の順序や許可条件がある | 注文・出荷・返金 |
| 監査ログ | 後から変更理由を確認したい | 受注状態の変更 |
| キャッシュ | 読み取り負荷を抑えたい | 商品一覧 |
| 外部サービス分離 | 専門的な責任を移したい | 決済・不正検知 |
パターンを適用するときは、業務規模、失敗時の損失、担当者、予算、復旧時間の違いを確認します。
EC-CUBEを例にすると、各業務能力について次を比較します。
- EC-CUBEの標準機能を使う
- 既存プラグインを使う
- 独自プラグインまたはカスタマイズで実装する
- 外部SaaSまたはAPIへ任せる
- 独立したシステムへ分離する
在庫管理の責任配置の例：
- 単一店舗ならEC-CUBEを正とする
- 実店舗併売ならPOSや在庫管理システムを正とする
- 複数倉庫や複数モールならWMSや在庫連携サービスを正とする
EC-CUBEで実装できるかと、EC-CUBEへ責任を持たせるべきかは別の問いである。
確認する項目：
- データを正として管理するシステム
- 障害時の影響
- 更新頻度
- バージョンアップ
- 運用担当者
- 開発・保守予算
- 外部サービス終了時の移行
- セキュリティ対応
- 顧客への説明責任
各案件や成果について、次の順序で記述されているか確認します。
- 顧客や利用者は誰か
- どの業務や売上に関係するか
- 納期、予算、体制、既存環境などの制約は何か
- 放置すると何が起きるか
- 誰が困っていたか
- 問題の大きさをどのように把握したか
最低でも次を比較します。
- 現状維持
- 運用改善
- SaaSや外部サービス
- オープンソースやパッケージの導入
- 独自実装
- 期待するリターン
- 初期費用
- 維持費用
- セキュリティ
- 保守体制
- 人材の確保
- 依存リスク
- 移行・撤退可能性
- 実装
- テスト
- 運用
- 障害対応
- 顧客説明
- データ管理
- 外部サービスとの調整
「自分が担当した作業」だけでなく、「チームや会社が新たに持つことになった責任」も記述します。
実装は、判断結果として説明します。
- アーキテクチャ
- 利用技術
- 責務の分離
- 依存関係
- テスト戦略
- 監視・復旧方法
- 見送った機能
- 採用しなかった技術
- 対応対象外とした環境
- 自前で持たなかった責任
- 売上、作業時間、障害件数などの変化
- 定量化できない場合は、判断や運用がどう改善したか
- 残った課題
案件固有の経験を、次回にも使える形へ変換します。
更新頻度が低く状態管理も少ない画面では、大規模なフレームワークを導入しない。
外部サービスで責任を移せる領域は、自前実装の自由度より運用継続を優先する。
案件固有の製品名だけでなく、扱った問題構造を記述します。
確認する項目：
- どの業務イベントを扱ったか
- どの状態遷移を管理したか
- どの外部システムと連携したか
- どの失敗、重複、競合を想定したか
- 別の業務へ転用できる知識は何か
製品名中心の説明
WordPressで問い合わせフォームを実装した。
改善後
問い合わせ受付について、入力検証、迷惑送信対策、外部メールサービス障害時の処理、送信記録の保持を設計しました。画面と受付処理の責任を分け、将来的に独立した受付基盤へ移行できる構成を検討しました。
一つの成果だけですべての能力を証明しません。
- 要件整理
- 選択肢の比較表
- Fit & Gap
- アーキテクチャ図
- ADR
- 技術調査
- 撤退条件
- 運用設計
- コード
- テスト
- 再現手順
- コードレビュー
- コミットログ
- デバッグ記録
- リリース手順
技術的な質問には、次の順序で回答します。
- 前提 — 顧客、利用者、体制、制約
- 本来の進め方 — 通常ならどう進めるか
- 起きた問題 — 想定との差分
- 優先したこと — 売上、納期、安全性、運用など
- やったこと — 調査、選定、実装、調整
- やらなかったこと — 見送った案と理由
- 着地 — 結果と残課題
- 次回も使える判断基準 — 判断の再利用
問い合わせフォームの導入が必要でしたが、社内にサーバー運用担当者がいませんでした。本来は個人情報の管理、迷惑送信対策、障害時の受付経路まで設計します。自前実装も可能でしたが、保守責任が利益に見合わないと判断し、フォームSaaSを採用しました。独自デザインが必要な画面だけを自社で実装し、受付処理とスパム対策は外部へ任せました。今後も、競争力にならない運用責任は外部へ移す方針です。
製品や業務の直接経験がない場合は、次の順序で説明します。
- 直接経験がある範囲
- 隣接領域で扱った問題
- 利用できるパターン知識
- 製品・業務固有として確認する範囲
- 小さく検証する方法
- 自分が実装できる範囲
- 外部サービスや専門家へ任せる範囲
EC-CUBEを使った本番案件の経験は多くありません。一方で、商品データ、フォーム受付、外部API連携、入力検証、状態管理、障害再現は別のシステムで扱ってきました。ECサイトについては、注文、決済、在庫、出荷、返品を別々の業務能力として整理し、どこをEC-CUBEへ持たせるかを判断します。EC-CUBE固有のイベント、プラグイン構造、更新手順は検証環境で確認します。設計判断に利用できる知識と、実装確認が必要な範囲を分けて進めます。
- 事業目的 — 何を改善し、どの損失を避けたいか
- 利用者と関係者 — 顧客、運用担当者、管理者、外部事業者
- 業務イベント — 何が起き、どの順序で状態が変わるか
- 異常系 — 失敗、重複、競合、外部サービス停止時
- 制約条件 — 予算、納期、人数、既存環境、保守能力
- 業務能力と責任境界 — どのシステムが何を正として持つか
- 選択肢 — 現状維持、運用改善、SaaS、パッケージ、独自実装
- 採用案と不採用案 — 判断基準とトレードオフ
- 検証方法 — 未知の部分をどのように小さく確認するか
- 実装範囲 — 自分、チーム、外部サービスが担当する範囲
- 運用と撤退 — 障害対応、更新、移行、終了条件
小規模ウェブ制作会社では、実装手段がWordPress、EC-CUBE、PHP、JavaScript、既存プラグイン、外部SaaSなどに限られることがあります。
その場合、複雑なアルゴリズム問題だけで評価するより、実案件型の設計面接と短いコード読解・修正課題を組み合わせるほうが、入社後の仕事を評価しやすくなります。
確認する能力：
- 顧客要望を業務課題へ変換できるか
- 制約条件を質問できるか
- 作るものと作らないものを判断できるか
- CMS、SaaS、外部サービス、独自実装を比較できるか
- 運用担当者と保守費用を考慮できるか
- 顧客や経営者へ判断理由を説明できるか
確認する能力：
- 既存コードを読めるか
- 変更範囲を限定できるか
- 入力検証、例外処理、セキュリティを考慮できるか
- 異常系のテストを追加できるか
- 副作用と本番確認項目を説明できるか
設計面接で判断能力を確認し、コード読解と修正で実装能力を確認する。
オープンソースへの貢献は、コード量ではなく、次の能力として評価します。
- 課題に対して機能が過剰ではないか
- 標準機能やSaaSで代替できないか
- 導入後の依存範囲を限定できるか
- メンテナーの人数と属人性
- リリース状況
- 脆弱性対応
- 企業や団体の支援
- IssueやPull Requestの滞留
- 代替手段
- 再現コードを作る
- バグ報告を整理する
- テストを追加する
- パッチを提供する
- 独自フォークを避ける
- 仕様と互換性の議論に参加する
利用者が望む便利な機能でも、次の場合は追加しない判断が必要です。
- 設計を複雑化する
- 誤用や脆弱性の原因になる
- 利用範囲が狭い
- メンテナーの将来負担が大きい
- ユーザーランドや外部ライブラリで実現できる
旧版サポートは既存利用者の事業継続に役立ちます。一方で、新版への移行、安全性向上、開発速度を阻害します。
確認する項目：
- サポート期限
- セキュリティ対応範囲
- 移行手順
- 互換レイヤー
- 顧客への告知
- 終了条件
オープンソース活動では、採用されたコードだけを成果にしません。
- 仕様を読んだ
- 再現条件を分離した
- 互換性を調査した
- 代替案を比較した
- テストで期待する挙動を定義した
- メンテナーと責任範囲を調整した
これらを、次の案件へ持ち運べる能力として説明します。
AIで生成したこと自体を成果にも問題にもせず、次を評価します。
- 要件と受入条件を誰が定義したか
- 生成物を誰が検証したか
- 依存関係を把握しているか
- 正常系と異常系を確認したか
- セキュリティ上の前提を確認したか
- 障害時に修正できるか
- 説明可能な状態で引き渡せるか
AIで実装できる範囲が広がるほど、「何を作らないか」「誰が維持するか」の判断が重要になる。
AIによる試作は、実務投入と区別します。
- 試作で確認したこと
- 本番投入前に追加確認すること
- 人間が責任を持つ判断
- 自動化しない範囲
を明示します。
成果物ごとに、説明する内容を分けます。
- コードには How — どのように実現したか
- テストコードには What — 何を保証するか
- コミットログには Why — なぜ変更したか
- コードコメントには Why not — なぜ別の方法を採らなかったか
- 要件・仕様書には Preconditions — どの前提で成立するか
- ADR・比較表には Trade-offs — 何を比較し、何を優先したか
- 運用手順には Recovery — 問題発生時にどう復旧するか
- 職務経歴書には Business value — 何の事業課題を解決したか
- 技術面談には Judgment — 何を基準に選び、何を捨てたか
コードだけですべてを説明しようとせず、前提、判断、検証、復旧を適切な成果物へ配置します。
次の記述は、追加確認が必要です。
React、Vue、Next.js、WordPress、Docker、AWSを使用。
確認事項：どの技術が現在の主力か、どの案件で必要だったか、保守できる範囲はどこか。
確認事項：優先順位、責任範囲、断る条件、専門外を扱う方法。
確認事項：問題発生時の対応、見送った案、失敗から得た判断基準。
確認事項：そのコードは何の価値を生み、どの維持費を増やしたか。
確認事項：既存手段では不足した理由、教育費、移行費、撤退条件。
確認事項：誰の何の問題を解決し、利用者とメンテナーの負担をどう変えたか。
確認事項：隣接経験、パターン知識、検証経験、実務投入に必要な追加確認。
確認事項：コード、テスト、デバッグ、既存システムへの安全な変更実績。
確認事項：代替案、制約条件、不採用理由、運用と撤退の設計。
確認事項：製品の機能境界と事業の責任境界が一致する根拠。
- 顧客、利用者、事業上の目的が分かる
- 放置した場合のリスクが説明されている
- 技術課題と事業課題が分離されている
- 複数の選択肢を比較している
- 採用理由と不採用理由がある
- 現状維持や外部サービスも候補に含めている
- 流行や個人の好みだけで選んでいない
- 実装後の保守担当が明確である
- 依存先の停止や変更を考慮している
- セキュリティ、障害、データ管理を考慮している
- 移行または撤退の条件がある
- 実装が事業上の判断と接続している
- 正常系と異常系を確認している
- テスト、監視、復旧方法が説明されている
- やらなかったことが明示されている
- 実務、技術投資、能力投資が分けて説明されている
- 学習した製品名ではなく、獲得した判断基準が分かる
- コード、仕様、テスト、チーム開発のどの能力を伸ばしたか分かる
- 直接経験と隣接経験が区別されている
- 既知のパターンをどこへ転用したか分かる
- 類推できない差分を特定している
- 未経験部分の検証方法が示されている
- ビジネス課題から技術選択までの過程が説明されている
- 業務イベントと異常系が整理されている
- データを正として持つシステムが明確である
- パッケージ、SaaS、独自実装の責任分担が明確である
- 製品の機能境界と事業の責任境界を混同していない
- 判断能力を示す成果物がある
- 実装能力を示す成果物がある
- 設計説明だけで実装能力を過大評価していない
- 実装量だけで判断能力を過大評価していない
- 面接者が「どんな判断をする人か」を説明できる
- 技術に詳しくない管理職や経営者にも価値が伝わる
- 案件固有の経験が、再利用可能な判断基準になっている
- 未知の課題に対する進め方が説明されている
技術名と実装内容は分かるが、目的や判断基準が分からない。
技術的な採用理由、代替案、テスト方法が説明されている。
ビジネス課題、リターン、リスク、責任範囲、運用体制まで説明されている。
撤退条件、移行、上流との関係、次回も使える判断基準まで整理されている。
直接経験がない問題についても、次を説明できる。
- 問題を業務能力へ分解する
- 隣接経験やパターンから類推する
- 類推が成立しない差分を発見する
- 小さな検証を設計する
- 判断と実装の証拠を分ける
- 組織が責任を持てる構成へ着地させる
職務経歴書と一般的な技術面談ではレベル3以上を目標とします。スタッフエンジニア、テックリード、顧客への提案を担う役割では、レベル4から5を評価対象とします。
レビューの最後に、次の質問へ一文で答えられるか確認します。
この人は、どのような課題に対して、どのような基準で技術を選び、どこまで責任を引き受ける人か。
この人は、直接経験がない課題に対して、どの知識や隣接経験を使い、何を追加検証する人か。
この人の技術判断と実装能力は、それぞれどの成果物によって確認できるか。
現在の案件を遂行する能力、将来の選択肢を増やす能力、個人やチームの能力を伸ばす活動が区別されているか。
回答例：
事業課題を先に整理し、自前実装と外部サービスを比較したうえで、保守可能な範囲に責任を限定できる人。
オープンソースやAIを活用して選択肢を増やしつつ、維持コストと撤退条件まで含めて技術投資を判断できる人。
事業課題を業務イベントと責任境界へ分解し、直接経験がない領域でもパターンと隣接経験から選択肢を作り、未知の部分だけを小さく検証できる人。
パッケージや外部サービスの機能をそのまま採用するのではなく、事業が必要とする責任と会社が維持できる範囲を照合して、実装、委託、撤退を判断できる人。
設計判断を比較表やADRで示し、実装能力をコード、テスト、デバッグ記録で別に証明できる人。