10年エンジニアが根拠のない不安から脱した自己分析法5つ

キャリア迷子だった僕が自己分析に本気で向き合った理由

ここ3年、プロジェクトの技術選定を任されることが増えたんです。だけど「俺、何ができるんだろう」という根拠のない不安がずっとあった。転職エージェントから「市場価値を高めるには」と聞かれても答えられない。同期と比べて給与が低い気がするけど、それが妥当なのかも分からない。

その時点では、自分のスキルセットを紙に書くこともしてませんでした。「10年エンジニアだから」という根拠のない自信と、根拠のない不安が同居してた状態。これはマズいと思って、2024年の夏から本気で自己分析に取り組みました。

結果として、去年1年でキャリアの方向性が明確になった。市場価値も数値化できた。転職オファーも来やすくなった。何より、日々の仕事を選ぶ時の判断軸が手に入りました。

今日は、その過程で本当に効いた5つの手法と、失敗例も正直に書きます。

手法1：スキルマップの「細粒度化」——できる/できないじゃなく、レベル分解する

まず最初に試したのが、いわゆる「スキルシート」です。ただし教科書通りじゃなくて、自分たちのプロジェクトで実際に問題になったレベル分けをしました。

例えば「Kubernetes」なら、こんな感じで分解した：

【Kubernetes スキルレベル分類】

レベル1（基礎）
- Pod・Deployment・ServiceのYAML が書ける
- kubectl で基本的な操作ができる
→ 自分の評価：✓ 2018年から触ってるので余裕

レベル2（実装）
- 本番環境のマニフェスト設計ができる
- livenessProbe・readinessProbe の設定判断ができる
- リソースリクエスト・リミット の根拠がある
→ 自分の評価：△ EKS 3年運用だけど、まだ試行錯誤している部分がある

レベル3（設計・最適化）
- マルチテナント隔離戦略を設計できる
- コスト最適化のための PDB・HPA 設定を判断できる
- CNI・kube-proxy のトラブルシューティングができる
→ 自分の評価：✗ 本当は深掘りしたいけど、まだやってない

レベル4（運用・指導）
- チーム全体の K8s 戦略を立案できる
- 外部へのメンタリング・コンサルができる
→ 自分の評価：✗ 遠い

これをPythonで自動化して、全スキルを一覧化しました。

skills = {
    "Kubernetes": {
        "level_1": "Pod・Deployment・Service の基本操作",
        "level_2": "本番マニフェスト設計・リソース最適化",
        "level_3": "マルチテナント隔離・トラブルシューティング",
        "level_4": "戦略立案・メンタリング",
        "self_eval": 2.3,  # 2と3の中間くらい
        "years": 3,
        "confidence": "△",
        "growth_direction": "level_3へ"
    },
    "Python": {
        "level_1": "基本的なスクリプト・型注釈なし",
        "level_2": "本番 API 開発・テスト・CI/CD",
        "level_3": "非同期設計・パフォーマンス最適化",
        "level_4": "標準ライブラリ理解度が深い・設計指導",
        "self_eval": 3.2,
        "years": 6,
        "confidence": "◎",
        "growth_direction": "level_4へ"
    },
    # ... 全スキル
}

# マトリクス作成
import pandas as pd
df = pd.DataFrame([
    {"skill": k, "level": v["self_eval"], "years": v["years"], "confidence": v["confidence"]}
    for k, v in skills.items()
])

これだけで気づきがありました。

「得意だと思ってたスキルが、実はレベル2で止まってた」 という現実。Kubernetes も AWS も「触ってる = 深い」と思い込んでたんです。でも実際には本番対応レベルだけで、設計・最適化の段階には達してなかった。

この「見える化」が転職エージェントとの面談で威力を発揮する。「私はレベル3のスキルを求めています」と言われて、初めて「あ、自分はまだレベル2だ」と応えられるようになったんです。

手法2：失敗ログの分析——何で失敗したのか、を因数分解する

これが一番地味だけど、一番効きました。

プロジェクトで本番障害を起こした時、復旧後には必ず RCA（根本原因分析）をするじゃないですか。でも、それは「チームの失敗」として片付いてしまう。自分は何を学び損ねたのか、まで考えて記録したことがなかった。

2024年6月、3年間で起こした「自分の判断ミス」を全部リストアップしてみました。

## 失敗ログ 2021-2024

### 案件1: Aurora PostgreSQL 接続プール設定ミス（2021年11月）
- 症状：深夜2時、本番で接続数が枯渇して 5分間ダウン
- 自分の判断ミス：PgBouncer の設定を「推奨値」をコピペで実装
- 根本原因：アプリケーションの接続パターンを理解してなかった
- 本当は必要だった知識：
  - コネクションプーリング の理論
  - psycopg2 の asyncio 対応状況
  - トランザクション分離レベルと接続の関係
- 教訓：数値設定は「根拠」を持つまで、本番環境では変更しない

### 案件2: Lambda SnapStart 導入で予想外のバグ（2024年2月）
- 症状：Java クールスタート 60% 削減したはずが、初期化エラーで fail
- 自分の判断ミス：「新機能だから効果あるだろう」で充分なテストせず導入
- 根本原因：Serializable なオブジェクトの生成タイミングを理解してなかった
- 本当は必要だった知識：
  - JVM の warm-up と static initializer の違い
  - Snapshot と restored process の状態差
- 教訓：性能改善は「理論 → テスト → 本番小規模」の順序が絶対

### 案件3: DynamoDB Single Table Design で Query 地獄（2023年8月）
- 症状：スケーリングで予想と違う Query パターンが出現、スロットル
- 自分の判断ミス：アクセスパターンの「想定」だけで設計
- 根本原因：実データでの分布を測定してなかった
- 本当は必要だった知識：
  - Hot key の検出方法
  - CloudWatch メトリクスの読み方
  - Single Table のトレードオフ（スケーラビリティ vs クエリの複雑さ）
- 教訓：設計は「理想」じゃなく「計測」から始めるべき

これを眺めてると、自分の弱点が明確になります。

失敗の 70% は「深く理解せず、パターンマッチで選択してた」 ことが原因だった。新しい技術、新しい AWS サービスが出ると、ドキュメントを速読して導入してしまう癖があったんです。

そこで「理解レベルマップ」を作りました。

# 理解度の定義
UNDERSTANDING_LEVELS = {
    "L1_読んだだけ": {
        "description": "ドキュメント・ブログで読んだ",
        "本番導入": "✗ 危険",
        "判断例": "Bedrock Flows の広告記事を読んだだけ"
    },
    "L2_試した": {
        "description": "ローカルで実装してみた",
        "本番導入": "△ 要テスト",
        "判断例": "Lambda SnapStart を dev 環境で検証済み"
    },
    "L3_本番テスト": {
        "description": "本番環境で小規模運用してみた",
        "本番導入": "◎ OK",
        "判断例": "EC2 トラフィック 5% で Aurora Zero-ETL 検証"
    },
    "L4_トラブル対応": {
        "description": "本番障害が発生して対応した",
        "本番導入": "◎◎ 確実",
        "判断例": "VPC Lattice で DNS 解決エラーを経験"
    },
    "L5_教える": {
        "description": "チーム・外部へメンタリングできる",
        "本番導入": "◎◎◎ 最高",
        "判断例": "EKS アーキテクチャ設計をコンサルタントとして指導"
    }
}

この「失敗ログ分析」をした時点で、初めて自分の本当の弱点が見えた。深さが足りない。これが全ての問題の根本だったんです。

---

手法3：360 度フィードバック（同僚・上司・部下のコメント化）

転職の時期を考えていたので、4人の同僚と、当時のマネージャー、部下 2人に「僕についてどう思う？」って聞いてみました。

ただし、下手に質問するとリップサービスばっかになるので、具体的なシーンで聞きました。

## フィードバック質問リスト

「仕事のシーンで思い当たることを教えてください」

1. 自分が「判断を下した」瞬間で、印象に残ってることは？
   → 上司からのコメント："あ、AWS の構成設計の話ですね。
      数字とトレードオフで判断する癖がある。
      でも逆に『なぜそうするのか』の説明が長い時がある"

2. 逆に「判断ミスした」と感じた瞬間は？
   → 同僚からのコメント："Lambda Cold Start 対策で
      SnapStart に飛びついたやつ。あれは 'やればいい' 
      じゃなく『なぜやるのか』をもっと深掘りする 
      べきだったと思う"

3. 新しい技術を学ぶ時、どういうスタイルに見えます？
   → 部下からのコメント："速いですね。1週間で
      Cursor の使い方をマスターしてた。でも 
      基礎からというより『これ使ったら何ができる？』
      という視点から入ってくる"

これが地味だけど、超重要。自分の自己認識と他者認識のズレが見えるんです。

僕は自分を「バランス型」だと思ってたけど、実は「速度優先のタイプ」として見られてた。深い理解より「パターンマッチ」で次々と導入する人という評価。正直、ショックでした。

でもこのフィードバックをもらったおかげで、転職先で「自分がどういう立場に向いてるのか」が明確になった。「スピード重視の開発」「パターンライブラリの構築」「新技術の検証」みたいな、自分の強みを活かせるポジションを探すことができるようになったんです。

手法4：市場価値の「定量化」——給与データから逆算する

これは 2025 年になってから本気でやりました。

転職エージェントから「年収いくら目指してますか？」と聞かれても、根拠なく答えてた。でも「市場価値」を数字で知ることは、キャリア決定で一番重要だと思ったんです。

やったのは以下：

1. 転職サイト（Wantedly・LinkedIn・企業採用ページ）の給与データを 50 件集めた

企業	年収レンジ	要件	備考
A社（Japan）	950～1,100万円	EKS運用2年以上	安定志向
B社（Startup）	1,000～1,200万円	Kubernetes本番経験	成長期
C社（大企業）	850～1,000万円	クラウド経験5年以上	年功序列傾向
D社（SaaS）	1,100～1,300万円	インフラアーキテクト	アーリー
E社（金融）	900～1,150万円	AWS認定資格有	安定志向

→ 自分の条件での相場：900 万～1200 万円

2. 転職エージェント 3 社に「市場価値」を直接聞いた

これが面白い。会社によって評価が全然違うんです。

• Agent A：「スキルセットは要件を満たしてますが、深い領域がない」→ 950 万円レンジ
• Agent B：「EKS と RDS の実装経験が珍しい」→ 1100 万円レンジ
• Agent C：「マルチクラウドは評価されます」→ 1000 万円レンジ

これで初めて「自分の強み」の見え方が会社によって違うことに気づいた。面接での話す順序や強調点を変えるだけで、評価が大きく変わるんですね。

3. 自分の市場価値スコアを作った

class MarketValue:
    def __init__(self):
        self.experience_years = 10
        self.depth_scores = {
            "Kubernetes": 3.2,   # レベル3の中程度
            "AWS": 3.5,          # レベル3の上
            "Python": 3.2,
            "Go": 2.5,
            "System Design": 3.0
        }
        self.leadership = 2      # 管理職経験なし
        self.mentoring = 1.5     # メンタリングは少なめ
    
    def calculate_base_value(self):
        """基本給与レベルを計算"""
        # 経験年数で基本値
        base = 800  # 万円
        base += self.experience_years * 20  # 年数加算
        
        # 深さでスコア加算
        depth_bonus = sum(self.depth_scores.values()) * 30
        
        # リーダーシップはいまのところボーナス無し
        leadership_bonus = self.leadership * 100
        
        return base + depth_bonus + leadership_bonus
    
    def market_range(self):
        """市場相場レンジを返す"""
        base = self.calculate_base_value()
        # 市場判定：-10% ～ +15%
        return {
            "conservative": int(base * 0.9),
            "middle": int(base),
            "optimistic": int(base * 1.15)
        }

value = MarketValue()
print(value.market_range())
# → {'conservative': 950, 'middle': 1056, 'optimistic': 1215}

これで初めて「自分は 1000 万円前後」が根拠を持った数字になった。感覚じゃなく、スキル分解 → 市場データ → 試算という流れで、ようやく説得力のある数字が出てきたんです。

手法5：3年ロードマップの策定——「今からどこへ向かうのか」を可視化する

最後は、フォワードルッキングです。

ここまでの分析で分かったのは、自分の強みと弱みがハッキリしたということ。でも「これからどうするのか」がないと、キャリアは迷い続けます。

やったのは 「3 年で何をマスターするのか」の明確化。

## キャリアロードマップ 2025-2028

### 現在地（2025年1月）
- 深さ：EKS・AWS（レベル3）Python・Go（レベル3）
- 弱さ：リーダーシップ経験・メンタリング実績がほぼ0
- 市場価値：1000万円前後（スペシャリスト領域）

### 分岐点の選択

#### Option A：スペシャリスト路線（Kubernetes・AWS 深掘り）
- Year 1（2025）：EKS コスト最適化・セキュリティ設計を深掘り
- Year 2（2026）：ブログ・OSS・カンファレンス登壇で知見発信
- Year 3（2027）：コンサルティング・アドバイザリーへ
- 市場価値：1200～1500万円（専門家領域）
- リスク：特定技術への依存

#### Option B：リーダーシップ路線（マネジメント）
- Year 1（2025）：チーム・プロジェクトリード
- Year 2（2026）：エンジニアリング・マネージャー職
- Year 3（2027）：部長職・組織構築
- 市場価値：1500～2000万円（経営層に近づく）
- リスク：コード書く時間が減る

#### Option C：ハイブリッド路線（アーキテクト）
- Year 1（2025）：複数プロジェクトの技術意思決定
- Year 2（2026）：会社全体のテック戦略参画
- Year 3（2027）：CTO補佐・テック戦略責任
- 市場価値：1400～1800万円（スペ + リード）
- リスク：両方中途半端になる

### 自分の選択：Option C（ハイブリッド）

理由：
- 今の強み（深い技術知識）を活かしたい
- でも管理スキルも磨きたい（転職時のオプション増える）
- アーキテクト領域は日本で希少＝市場価値高い

### 2025年の具体的行動

1. マルチクラウド・アーキテクチャ設計（Option A の深さ）
2. 週 1 回、チームメンバーの技術メンタリング（Option B のリード）
3. 社内テック戦略会議への参加（Option C の統合）

このロードマップで大事なのは 「選択肢を複数持つ」 ことです。

スペシャリスト路線、マネジメント路線、ハイブリッド路線——どれでもいけるような準備をしておけば、市場環境や人生環境が変わった時に、対応できるようになります。

---

自己分析を運用する——1年に1回のレビュー

これらをやった後、大事なのは「定期レビュー」です。

キャリアって静的じゃなくて、動的なもんですよ。3ヶ月前の自分の評価が、今も正しいとは限らない。新しい技術に触れたから理解レベルが変わるし、失敗ログもどんどん増えます。

僕は毎年1月に、スプレッドシート（ローカル + iCloud 同期）で以下をアップデートしてます。

## 年次 Self-Review チェックリスト

□ スキルレベルを再評価（各スキルの L1～L5 をアップデート）
□ 新規失敗ログを追加（過去12ヶ月の失敗を分類）
□ 360度フィードバック（信頼できる人2～3人に再度聞く）
□ 市場価値の再計算（給与データ・エージェント評価の更新）
□ ロードマップの修正（実績に基づき、来年の目標を更新）
□ 次の転職・昇進のタイミング判定

これをしてると、「今、動くべき時期なのか」「もう1年現職でいるべきなのか」が、はっきり見えるようになります。

まとめ

キャリアの自己分析は、感情や直感じゃなく、実務ベースでやるべき。僕が効果を感じた5つの手法：

1. スキルマップの細粒度化 ——「できる/できない」から「レベル 2/3」に分解。市場に何を売るのかが明確になる
2. 失敗ログの分析 ——失敗の 70% は「深さ不足」だった。失敗パターンから本当の弱点が見える
3. 360 度フィードバック ——自己認識とのズレが大きいほど、改善余地がある。同僚評価は転職時の強み発見に直結
4. 市場価値の定量化 ——スキル分解 → 市場データで「自分はいくら」が根拠を持つ。交渉力も上がる
5. 3 年ロードマップ ——複数選択肢を用意すれば、人生に余裕が出る。スペシャリスト / マネジメント / ハイブリッド、どれにも対応できる準備

これらは 1 回やったら終わりじゃなく、半年～1 年ごとに回すのが大事。

実務経験を積む中で、自分は変わり続けます。その変化を「データ」として記録してれば、次の決断（転職 / 昇進 / 事業化）の時に、迷わずに進めるようになります。

---

追記

このプロセスを回してて一番驚いたのが、「できてると思ってたことの 40% は、実は表面的だった」という気づき。EKS も AWS も、3 年触ってるけど、深さの面ではレベル 3 中盤くらい。本当の専門家は、失敗から学んだ深い洞察を持ってるんだと、改めて感じました。

「10 年エンジニア」という肩書は、けっこう危ないですね。その中身を定期的に検査しないと、相場より安い給与で働き続けることになる。自分の時間 = お金、という意識で、キャリアの self-check は本当に大事だと思います。