デスマーチに加担しているのはシステムエンジニア自身である

効率の良いチームとはなんだろう。わからないときは辞書を引く。

こう‐りつ〔カウ‐〕【効率】
１機械などの、仕事量と消費されたエネルギーとの比率。「―のよい機械」「熱―」
２使った労力に対する、得られた成果の割合。「―のよい投資」
引用　こうりつ【効率】の意味 - goo国語辞書

効率の良いチームの効率であるから、チームメンバの仕事量とチームメンバの費やしたエネルギー、つまり、リソースに当たるから、人件費や時間に当たる。仕事量は結果だから、アウトになる。

比較しやすくするために、エネルギーは時間であると定義する。すると次の式が得られる。

効率＝アウトプット：メンバの時間

見覚えのある形式になった。そう、生産性の指標だ。でも、この式で得られる数値には消費した仕事を行う順序や手順は考量されていない。つまり、生産性で得られる数値には、順序や手順は考量さずに投下された時間で得られたアウトプットの計算値しか得られていない。

さらに言えば、得られたアウトプットの品質についても考慮されていない。得られたアウトプットの出来が良くても悪くても、投下されたリソースに対し、得られたアウトプットが量的に多ければ生産性は高いと判断されてしまう。

正しくは次の式で得られるアウトプット以外はリリースされてはいけない。

得たい品質の性質を持つアウトプット　＝　品質を確保するしくみ　＊　投下するリソース

これが正しいとするならば、

効率的なチーム　＝　得たい品質の性質を持つアウトプットを必要なリソースだけ投下できるチームとなる。

さて、システム開発の現場で言われる効率的なチームは上記の定義が成り立っているのかと問えばそうではなく、バジェットや外部からの制約条件としてプロジェクトを外から縛りをかけてくる。

工夫せいよ、予算の中で実現せよ、が常套句である。

であれば、式の投下するリソースが変化するので「品質を確保するしくみ」もまた変えなければならない。

得たい品質の性質を持つアウトプット　＝　品質を確保するしくみの置き換え　＊　投下するリソース

これは「品質を確保するしくみ」を小改良する程度では式が成り立たないことを意味している。つまり、発想自体を変えないと式が成り立たないということを意味している。これを認識も理解もせずに無理をするからデスマーチが起きるのだ。

つまり、デスマーチは、起きるべくして起きているし、デスマーチを加担しているのはシステムエンジニア自身であることに気づかなければならない。