仕掛かり中のお仕事フローを把握せよ

仕掛かり中を増やすと作業負荷が見えなくなり更に仕事が増えるんですよ。だって、ギブアップしないんですから。で、大抵は溢れかえった状態で誰かが見つけるんです。ボトルネックになっているって。

いや、それボトルネックじゃないし。

そうなった原因を、ギブアップしないエンジニアに対して「ギブアップする前に教えてよ」というのは間違った助言ですし、無責任だし、もはや無茶振りでしかないです。

ギブアップしないのは出来るからならこういった問題は起こさないのでそういうエンジニア以外の、ギブアップを自らできないエンジニアは自分のキャパシティを知らないのです。

というか、キャパシティという概念さえ持っていないのです。だから、都合よく仕事を振られると今自分の容量に対してどのくらいの作業の嵩があってあとどのくらいならアップアップしないで処理できるかを確かめることをしないのです。

原因はどこにある

なんでもトラブルを人にあるとするのは間違いです。それがギブアップしないエンジニアが仕事を溢れさせても。

どうして溢れるまで仕事を回したのかという判断を何を持ってしたかを解明しなければならないのです。

結局、だれかれを問わず「仕事を振る」という判断をした基準があってその基準が間違っていたから目に見えている事象が起きているわけです。

その誤った判断基準はなんであるか。

今どれだけお仕事中の仕掛かりがあるかをエンジニア別にキャパシティがわかっていないから容量を超えた作業を振ってしまっているんです。

原因は、仕掛かり中のお仕事をどれだけ抱えているかフローを見ずに振っているからです。

そりゃもう少しで溢れそうなところに入れようとすれば何かが溢れるのは当然ですし。

複数のお仕事を同時に抱え込ませればエンジニアは気になる仕事を優先するけれどそれも進まず、あっちをやって、こっちを手につけてと、手を掛けた成果の形にする前に他の抱えているタスクが気になったり、周りからせっつかれたりしてどれも中途半端になるんですよ。

で、気持ちだけ焦って何も進まず…と。

そうはいっても、いくつかの仕事を抱えることが業務スタイルのお仕事もあります。

そうした時にはどうすればいいか。

担当した塊としての作業はまるっとしていても、自分がやるときには作業を成果の出る単位に分割するのが最良です。中間生産物でもいいので、アウトプットできる最小のタスクに分解してから手をつける。

他の仕掛かりにスイッチする場合は、最小の作業が終わってから。

これ、TSSですよね。リソースは自分ですけど。