シリーズまとめ

はじめに

前回の記事では、エンジニアと作業をポケモンのタイプに分類し、
案件に対するエンジニアのアサインを考えてみました。

今回はさらに世界観を広げて、

状態異常
経験値と進化
技PP
ジムリーダー
伝説のポケモン

について整理します。

状態異常

システム開発には、ポケモンでいう「状態異常」に近いものがあります。
しかも厄介なのは、HP（工数）ではなく、行動そのものを阻害することです。

☠️ どく：技術的負債

症状

修正のたびに別の場所が壊れる
コードを読むだけで疲れる
開発速度が徐々に落ちる

特徴

すぐには致命傷になりません。

しかし、

応急処置
コピペ修正
「あとで直す」

を続けると、毎ターン継続ダメージが発生します。
しかも長期案件ほど効いてきます。

🔥 やけど：炎上状態

症状

残業増加
判断力低下
レビュー品質低下
会話が荒れる

特徴

やけど状態になると、本来の攻撃力（生産性）が下がります。
つまり、頑張っているのに火力が出ない状態になります。

さらに怖いのは、周囲へ伝染することです。

❄️ こおり：仕様凍結

症状

変更できない
改善提案が止まる
誰も触れなくなる

特徴

「安定」と「停止」は違います。
仕様凍結が進みすぎると、壊したくないから何も変えられない状態になります。

😴 ねむり：長時間会議・承認待ち

症状

思考停止
作業停止
判断待ち
仕事が進まない

特徴

行動不能になります。
さらに厄介なのは、本人たちは「仕事をしている感」があることです。

⚡ まひ：属人化

症状

あの人しか分からない
作業が止まる
レビューできない

特徴

まひ状態になると、行動確率が下がる
つまり、

担当者待ち
確認待ち
レビュー待ち

が増えていきます。
そして担当者が休むと全滅します。

😵 こんらん：仕様変更

症状

実装方針が毎回変わる
仕様が定まらない
人によって言うことが違う

特徴

混乱状態では、自分を攻撃するようになります。
つまり、「作っては壊し」「修正しては戻し」を繰り返します。

経験値と進化

エンジニアは経験値によって進化します。
ただし、レベルを上げれば自動進化するわけではありません。

進化条件

ポケモンと同じで、進化には条件があります。

レベルアップ型

CRUD開発
保守
小規模改修

など、経験を積めば進化。

通信交換型

独学だけでは進化しづらいタイプです。

レビュー文化
チーム開発
設計議論

など、他者との関わりで進化。

進化の石型

大規模障害
炎上案件
リーダー経験

など、特定イベントで急成長。
かなり痛いですが、進化効率は高いです。

進化キャンセル

現場ではよくあります。

まだ実装だけしたい
設計やりたくない
管理側へ行きたくない

結果、「レベルは高いのに未進化」の状態になります。

ただし進化しないから弱いわけではありません。
進化後では代替できない役割を持つこともあります。

技PP

開発現場で見落とされがちですが、エンジニアにもPPがあります。

PP消費

技	消費PP
障害解析	大
設計	大
レビュー	中
単純実装	小

強技ほどPP消費が重いです。
つまり、難しい仕事ほど連発できないのです。

PP切れ

PP切れすると

雑実装
思考停止
レビュー漏れ
判断ミス

つまり、技は撃てるが命中率が下がる状態になります。

強い技の危険性

強い技を持っている人に仕事を集中させると、PP切れを起こします。
その結果

最強アタッカーが機能停止
チーム全体崩壊

になります。

ジムリーダー

ジムリーダーはPMです。

PMの主な役割は、最前線で戦うことではなく、「誰をどこへ出すか」を判断することです。

良いジムリーダー

相性を見る
バランスを見る
無理な戦いを避ける

つまり、「誰をどこへ出すか」を考えています。

ダメなジムリーダー

とりあえず強そうな人を投入
全員アタッカー
相性無視

これは、レベルの高いポケモンだけで四天王に挑むようなものです。
タイプ相性で普通に負けます。

伝説のポケモン

稀に現場にいる

フロントできる
バックできる
DBできる
インフラできる
マネジメントできる

みたいな「何でもできる人」です。

扱いが難しい

伝説のポケモンと同じで

数が少ない
確保困難
過労しやすい

という特徴があります。

最大の問題

みんなこう考えます。

「この人がいれば何とかなる」

その結果

全案件へ召喚
全レビュー依頼
全障害対応

となります。

つまり、伝説のポケモンを秘伝要員にしている状態です。
さらに、伝説のポケモンを前提に設計されたチームは、その人が抜けた瞬間に崩壊します。

おわりに

ここまで整理すると、本当に強いチームが見えてきます。
それは、「伝説1人に頼るチーム」ではありません。

強いチームの特徴は

状態異常対策がある
PP管理できている
相性で編成している
控えメンバーがいる
役割分担されている

つまり、ちゃんとパーティ戦しているチームです。

こうして整理すると、システム開発はRPGや対戦ゲームに近いです。

適材適所
リソース管理
状態異常対策
パーティ編成

どれか1つ欠けるだけで、簡単に全滅します。
逆に言えば、「強い個人」より「噛み合ったパーティ」の方が強いです。

シリーズまとめ