シリーズまとめはじめに
システム開発の現場では、よくこんな会話があります。
- この人はフロント向き
- この案件はインフラ強い人が必要
- レガシー案件にモダン特化の人を入れると危ない
- 優秀な人なのに案件と噛み合っていない
これらは感覚的に語られることが多く、体系的に整理されることはあまりありません。
そこで、ポケモンに例えて整理してみます。
前提ルール
本記事では以下のルールで統一します。
| 要素 | 意味 |
|---|---|
| エンジニア | 攻撃側 |
| 作業 | 防御側 |
| 得意 | 効果はばつぐん |
| 苦手 | 効果はいまひとつ |
作業 → 防御タイプ割当
「作業の性質」をタイプ別に分類します。
| 作業 | 防御タイプ | 理由 |
|---|---|---|
| UI修正 | 🌱 くさ | 画面変更が枝分かれ的に広がりやすいため |
| レガシー制約 | 🪨 いわ | 長年積み重なり硬直化しているため |
| 基盤制約 | 🌍 じめん | OS・NW・ハードなど土台部分の問題のため |
| 技術的負債 | ☠️ どく | 放置すると継続的に悪影響を及ぼすため |
| 複雑ロジック | 🧠 エスパー | 抽象度が高く認知負荷が大きいため |
| 原因不明障害 | 👻 ゴースト | 実体が掴めず再現も困難なため |
| セキュリティ課題 | 🕶 あく | 攻撃・悪意・不正利用を前提とするため |
| 品質問題 | 🛠 はがね | 厳密性・整合性・変更耐性が求められるため |
| 高難度統合 | 🐉 ドラゴン | 複数領域を跨ぐ極めて難易度の高い問題のため |
| 短納期対応 | 🥊 かくとう | 精神力・速度・突破力が要求されるため |
| UX問題 | 🧚 フェアリー | 使いやすさや心理的体験が重要になるため |
| リアルタイム処理 | ⚡ でんき | 即時応答や低遅延が重要となるため |
| 分散システム | 🌪 ひこう | システムやデータが広範囲へ分散するため |
| データ肥大化 | 💧 みず | データ量が流動的かつ大量に蓄積するため |
| 運用作業過多 | 🐛 むし | 小さな定型作業が大量発生するため |
| 仕様凍結 | ❄️ こおり | 変更不能な状態で固定化されるため |
| 古いUI/UX | 🔥 ほのお | 古さが目立ち刷新圧力が高まるため |
| 汎用雑務 | 🐦 ノーマル | 特徴が薄く広範囲に存在する作業のため |
エンジニア → 攻撃タイプ割当
「どんな作業が得意か」をタイプ別に分類します。
| エンジニア | 攻撃タイプ | 理由 |
|---|---|---|
| フロントエンド | 🔥 ほのお | 画面や体験を目に見える形で刷新するため |
| バックエンド / レガシー保守 | 💧 みず | 既存システムやデータを安定的に流し続けるため |
| インフラ / SRE | ⚡ でんき | 通信・監視・即応対応を得意とするため |
| データエンジニア | 🌱 くさ | データを増殖・加工・循環させる基盤を扱うため |
| アルゴリズム / 最適化 | ❄️ こおり | 複雑な問題を冷静に整理・最適化するため |
| 実装特化 | 🛠 はがね | 堅牢で壊れにくい実装を構築するため |
| 物理基盤 / クラウド基盤 | 🌍 じめん | ハードウェアや低レイヤを直接扱うため |
| アーキテクト | 🌪 ひこう | 全体構造を俯瞰しシステムを整理するため |
| 技術的負債管理 | 🧠 エスパー | 本質分析や構造改善を得意とするため |
| 自動化 / スクリプト | 🐛 むし | 小さな作業を大量に自動処理するため |
| ドメイン知識特化 | 🪨 いわ | 長年蓄積された業務知識で支えるため |
| デバッグ | 👻 ゴースト | 見えない不具合や再現困難障害を追跡するため |
| フルスタック | 🐉 ドラゴン | 複数領域を横断して高難度問題へ対応するため |
| セキュリティ | 🥊 かくとう | 攻撃や脅威へ対抗し、堅牢性を高めるため |
| QA / テスト | 🕶 あく | 想定外や仕様の穴を発見し、不正ケースを暴くため |
| UI/UXデザイナー | ☠️ どく | ストレス・混乱・圧迫感など負の体験を取り除くため |
| AI / R&D | 🧚 フェアリー | 既存常識を超える新しい価値や発想を生み出すため |
| ジュニア / 汎用 | 🐦 ノーマル | 幅広い作業へ柔軟に対応するため |
相性
ここまで整理すると、タイプ相性で適性を説明できるようになります。
◯＝効果はばつぐん！
△＝効果はいまひとつ
×＝効果がない
無印＝通常の効果
効果はばつぐん
「どのタイプをぶつけるべきか」という視点になります。
| 作業(防御) | エンジニア(攻撃) |
|---|---|
| UI修正（🌱 くさ） | フロントエンド（🔥 ほのお） |
| レガシー制約（🪨 いわ） | バックエンド / レガシー保守（💧 みず） |
| 技術的負債（☠️ どく） | 技術的負債管理（🧠 エスパー） |
| 原因不明障害（👻 ゴースト） | デバッグ（👻 ゴースト） |
| セキュリティ課題（🕶 あく） | セキュリティ（🥊 かくとう） |
効果はいまひとつ
このモデルは「優秀な人が失敗する理由」が説明できます。
相性が悪いと、能力が低いわけではないのに苦戦します。
つまり、エンジニアの能力は絶対値ではなく「相性」で決まります。
| 作業(防御) | エンジニア(攻撃) |
|---|---|
| UI修正（🌱 くさ） | バックエンド / レガシー保守（💧 みず） |
| レガシー制約（🪨 いわ） | フロントエンド（🔥 ほのお） |
| 技術的負債（☠️ どく） | セキュリティ（🥊 かくとう） |
| 原因不明障害（👻 ゴースト） | 自動化 / スクリプト（🐛 むし） |
| セキュリティ課題（🕶 あく） | 技術的負債管理（🧠 エスパー） |
おわりに
今回は、
- エンジニア
- 作業
をポケモンのタイプとして分類してみました。
もちろん実際の現場はもっと複雑ですが、
- 得意不得意
- 向き不向き
- アサインミス
- 炎上原因
を考える上では、意外としっくり来る気がしています。
次回予告
次回は、
- 案件を「敵パーティ」として考える
- タイプ相性に基づく最適なエンジニア編成
- 炎上プロジェクトはなぜ発生するのか
を整理します。