デスマと穀潰しエンジニア
なんだろうと思って読んみでみたら随分前に読んだ物のような気がするのだが、果たして記憶違いだろうか。
ちょうど、過去に作成したスライドを探していて見つけられず、諦めた後、ひょんなことからスライドを見つけられたのでそれをまじまじと眺め直してみた。
そのスライドは、冒頭でリンクを貼ったデスマを書いたものではないのだが、スライドに書いたプロジェクトも立て直しに入らずに、あのまま進行していたらです待っていたのかもしれない。少なくともあのプロマネは持たなかっただろう。
リンクの先のエントリの最後に書いていあるのはこれからの抜粋だと思うのだが、そりゃ色々とリソースが半減だったらデスマになるのはほぼ確実だろう。ほぼと書いたのは、見積もりが甘くて1.5倍以上の予算が確保できていれば、まあどんなプロジェクトでも収まるからだ。
世の中にはQCDSと言う考え方がある。個人的にはSはQの母体であるから不要だと思っているが、単にQで捉えていることが多いし、固執することでもないので（要は面倒で）Sを加えて話すようにしている。
そのQCDSがブレれば見積もりのパラメータが変わるのだから尋常でない事態が起きたことになる。QCDSの調整ができないのであれば、あとはデスマとはならなくても異常事態に陥るのは必須だ。
よくよく見直すと、Qは備えていなければならない要素だし、Cは実現に必要な費用だし、Dは約束可能であるかだし、Sは前提のようなものだ。
その裏にある、それら4つを支えるのは実現するリソースだが8割はエンジニアである。それもエンジニアがいればいいと言う次元では意味をなさない。必要とされる技量を持ったエンジニアという条件が付く。
スライドを眺めているとそのプロジェクトでもエンジニアをほぼ総取っ替えしていたということは、QCDSの以前の話でエンジニアの調達が間違っていたということだ。
ここでサンクコストを忘れてはいけない。やっとの思いで調達したエンジニアを切るのかと必ず言われるだろう。
でもそこで怯んではいけない。機能しないエンジニアはそのプロジェクトでは無能と同じで更に予算を食いつぶすだけの穀潰しエンジニアである。
その上での選択肢は2つある。
- 穀潰しエンジニアを切る。
- （素養を見極めた上で）育て、将来機能させる。
さてどちらを選ぶか。そレより、プロジェクトで機能しないエンジニアを調達するようなマネージャを切る選択肢が絶大な効果を得られるのだが。
