やがて稼働率は開発部門を弱体化する

昔話になるがある部門のマネージャをしていたとき、引き合いが旺盛でプロジェクトを安心して任せられるだけのリソースを使い切っているつもりだったことがあった。とは言え、管理部門から見ればプロジェクトにアサインされていないメンバがいたのでなんとかしろと言ってくる。そんな都合よく案件がくるわけがないのだが、（後になっては地雷だった）案件がやってきた。この案件は、二度と繰り返したくない経験になるのだがここでは割愛する。

業務を行う上で組織には、組織という単位になるからだが、slack、つまり伸び代を持っておかなければ新しいビジネスを考えることもできないし、技術を追うこともできない。何せない袖はふれないのだから、恒常的にリソースをひねり出すことが出来ない。

それを加速するのが稼働率である。

一度稼働率を導入してしまうとエンジニアの持つ技術と案件の必要とするスキルセットの適合を鑑みることなく無理に投入しようとする。数値管理をしている側はそんな個別案件の事情は関心がない。稼働率という数字だけに関心を持つ。御構い無しに上から掛かる圧にリスクを識別し、リスクテイクをできるかどうか見極められないマネージャは流されるかリスクを見誤って手を出してしまう。上から見れば挑戦しているように見えるから受けはいい。ただ、現場の足元はバチバチと火の粉が上がり始める。

個人的には稼働率は宜しくないと思っているが、ビジネス感覚、つまりエンジニアを抱えていられるだけの案件をやらなければそのエンジニア自身を他所の本来専門でないスキルで働くことになることを気づかせるためには必要な数字ではある。

稼働率を放置、つまり管理部門に制限なしで手渡してしまうと際限なく上げようとするのは昨対での売り上げ、利益を積むことが仕事になるからである。稼働率は率だから、何らかの意思決定をサポートする指標でしかないはずなところを稼働率をあげることを仕事にしてしまうのである。

稼働率を悪魔の道具として使うのは本来の使い方を知らないからだ。考えれば、案件への直接作業と間接作業（教育、年休、組織活動など）があるから稼働率はどう計算しても70−80％などのあたりの数字が上限になるはずである。場合によってはもう少し低いかもしれない。つまり、組織全体の上限はやる前から決まっているわけだ。

目的と手段を取り違えていると誰かがバッサリと切らなければならないが、当事者である開発部門のマネージャは右肩上がりで成長を要求されるプレッシャや引き合いから鼻から考えないのである。

何が起きるかと言えば、短期的な収益改善には寄与するが長期の観点では高い稼働率を維持すると開発部門は静かに蝕まれる。余裕を自ら削るのだからじわじわと技術力は消耗し、新しいおもちゃの技術を扱えないエンジニアは離れていくのである。

それが今のあなたがいる組織である。