デスマーチが起きる理由 - 3つの指標
これは結城浩さんの運用されていた YukiWiki に当時 Coffee 様 (青い鴉(ぶるくろ)さん)がかかれていた文章です。 ただ 2018 年 3 月 7 日に YukiWiki が運用停止したため消えてしまいました。その記事のバックアップです。
損益 = 売上 - 費用(変動費 + 固定費)でプロジェクトを評価することは誤っている 正社員の人件費を含めるなら、固定費はコントロールできないから
スループット = 売上 - 変動費を用いる
仕掛品や完成品の在庫をどれだけ作っても、『納品できなければマネジメントが成功したとは言えない』ため
『在庫』はスループットを生み出す前の状態であり、将来的にスループットに変わる可能性はあるが、 しかし、現時点ではスループットにはなっていない
開発者の稼働率を上げるために今すぐ必要でない作業を行わせても、在庫を増やすことにしかならない。 見た目の効率を重視したマネジメントでは、スループットを増やすという目標は達成できない
在庫をスループットに変えるためのコスト
納品しないドキュメントなど
マネジメントの手段は明らかだ。『在庫を減らし、経費を減らし、スループットを増やす』。これが、マネジメントの全てだ
3つを同時に考えるのが重要
コスト削減を重視しすぎて、在庫を増やし、スループットを減少させてしまうケースがある
社員に休憩時間を与えず、残業をさせて稼働率を上げる。マネージャーは時間当たりの人件費を節約したように錯覚する。 しかし実際には、企業が支払う金額はこれっぽっちも減ってはいないし、むしろ残業代などで増えている。コスト削減は妄想だ。
開発者にひたすらコードだけを書かせて稼働率を増やし、マネージャーは開発の効率を上げたように思い込む。 これも実際には、在庫が増えただけだ。生産能力を在庫の作成と管理に振り向けたわけだから、スループットは激減している。
スループットを増大させるには、『書きかけ・未テストのコードを減らし(在庫削減)、分納などで納品を早める(スループット増加)』ことが最良だということになる。 しかしそのためには、『スループットが大きく増えるのであれば、経費が多少増えても良い』という、考え方の転換も必要になる