シリーズまとめはじめに
前回の記事では、エンジニアと作業をポケモンのタイプに分類し、
案件に対するエンジニアのアサインを考えてみました。
今回はさらに世界観を広げて、
- 状態異常
- 経験値と進化
- 技PP
- ジムリーダー
- 伝説のポケモン
について整理します。
状態異常
システム開発には、ポケモンでいう「状態異常」に近いものがあります。
しかも厄介なのは、HP（工数）ではなく、行動そのものを阻害することです。
☠️ どく：技術的負債
症状
- 修正のたびに別の場所が壊れる
- コードを読むだけで疲れる
- 開発速度が徐々に落ちる
特徴
すぐには致命傷になりません。
しかし、
- 応急処置
- コピペ修正
- 「あとで直す」
を続けると、毎ターン継続ダメージが発生します。
しかも長期案件ほど効いてきます。
🔥 やけど：炎上状態
症状
- 残業増加
- 判断力低下
- レビュー品質低下
- 会話が荒れる
特徴
やけど状態になると、本来の攻撃力（生産性）が下がります。
つまり、頑張っているのに火力が出ない状態になります。
さらに怖いのは、周囲へ伝染することです。
❄️ こおり：仕様凍結
症状
- 変更できない
- 改善提案が止まる
- 誰も触れなくなる
特徴
「安定」と「停止」は違います。
仕様凍結が進みすぎると、壊したくないから何も変えられない状態になります。
😴 ねむり：長時間会議・承認待ち
症状
- 思考停止
- 作業停止
- 判断待ち
- 仕事が進まない
特徴
行動不能になります。
さらに厄介なのは、本人たちは「仕事をしている感」があることです。
⚡ まひ：属人化
症状
- あの人しか分からない
- 作業が止まる
- レビューできない
特徴
まひ状態になると、行動確率が下がる
つまり、
- 担当者待ち
- 確認待ち
- レビュー待ち
が増えていきます。
そして担当者が休むと全滅します。
😵 こんらん：仕様変更
症状
- 実装方針が毎回変わる
- 仕様が定まらない
- 人によって言うことが違う
特徴
混乱状態では、自分を攻撃するようになります。
つまり、「作っては壊し」「修正しては戻し」を繰り返します。
経験値と進化
エンジニアは経験値によって進化します。
ただし、レベルを上げれば自動進化するわけではありません。
進化条件
ポケモンと同じで、進化には条件があります。
レベルアップ型
- CRUD開発
- 保守
- 小規模改修
など、経験を積めば進化。
通信交換型
独学だけでは進化しづらいタイプです。
- レビュー文化
- チーム開発
- 設計議論
など、他者との関わりで進化。
進化の石型
- 大規模障害
- 炎上案件
- リーダー経験
など、特定イベントで急成長。
かなり痛いですが、進化効率は高いです。
進化キャンセル
現場ではよくあります。
- まだ実装だけしたい
- 設計やりたくない
- 管理側へ行きたくない
結果、「レベルは高いのに未進化」の状態になります。
ただし進化しないから弱いわけではありません。
進化後では代替できない役割を持つこともあります。
技PP
開発現場で見落とされがちですが、エンジニアにもPPがあります。
PP消費
| 技 | 消費PP |
|---|---|
| 障害解析 | 大 |
| 設計 | 大 |
| レビュー | 中 |
| 単純実装 | 小 |
強技ほどPP消費が重いです。
つまり、難しい仕事ほど連発できないのです。
PP切れ
PP切れすると
- 雑実装
- 思考停止
- レビュー漏れ
- 判断ミス
つまり、技は撃てるが命中率が下がる状態になります。
強い技の危険性
強い技を持っている人に仕事を集中させると、PP切れを起こします。
その結果
- 最強アタッカーが機能停止
- チーム全体崩壊
になります。
ジムリーダー
ジムリーダーはPMです。
PMの主な役割は、最前線で戦うことではなく、「誰をどこへ出すか」を判断することです。
良いジムリーダー
- 相性を見る
- バランスを見る
- 無理な戦いを避ける
つまり、「誰をどこへ出すか」を考えています。
ダメなジムリーダー
- とりあえず強そうな人を投入
- 全員アタッカー
- 相性無視
これは、レベルの高いポケモンだけで四天王に挑むようなものです。
タイプ相性で普通に負けます。
伝説のポケモン
稀に現場にいる
- フロントできる
- バックできる
- DBできる
- インフラできる
- マネジメントできる
みたいな「何でもできる人」です。
扱いが難しい
伝説のポケモンと同じで
- 数が少ない
- 確保困難
- 過労しやすい
という特徴があります。
最大の問題
みんなこう考えます。
「この人がいれば何とかなる」
その結果
- 全案件へ召喚
- 全レビュー依頼
- 全障害対応
となります。
つまり、伝説のポケモンを秘伝要員にしている状態です。
さらに、伝説のポケモンを前提に設計されたチームは、その人が抜けた瞬間に崩壊します。
おわりに
ここまで整理すると、本当に強いチームが見えてきます。
それは、「伝説1人に頼るチーム」ではありません。
強いチームの特徴は
- 状態異常対策がある
- PP管理できている
- 相性で編成している
- 控えメンバーがいる
- 役割分担されている
つまり、ちゃんとパーティ戦しているチームです。
こうして整理すると、システム開発はRPGや対戦ゲームに近いです。
- 適材適所
- リソース管理
- 状態異常対策
- パーティ編成
どれか1つ欠けるだけで、簡単に全滅します。
逆に言えば、「強い個人」より「噛み合ったパーティ」の方が強いです。