ゆとりの法則

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解
必要なゆとりが足りないと、組織は狂乱状態になり、恐怖感に支配され、リスクを避けようとし、大切な従業員はもっと働くのに適した場所を求めて去っていく。

トム・デマルコ著の「ゆとりの法則」からの一文ですが、どきっとした方もいるのではないでしょうか?これは昨日から読み始めたお風呂読書の本です。3年前、入社前後に買って一度は読んだのですが、組織における仕事というものについての実感が無い状態だったので、余り印象に残っていませんでした。今本棚を眺めて、この本の存在に気づきまして、最近仕事に追い立てられている状態になっている自分自身の状態について客観的に評価するための視点を増やすためにも読み直してみることにしたわけです。
今読むと、著者の伝えたかったことがすごく良く理解できます。超簡単にまとめると、円滑に業務を進める為には、人や組織にはゆとりが必要である、というお話です。以下、序盤を少し読んだ段階におけるメモです。私個人の考えも混じってますので本書がそのままこういう内容であるという保証はありません。

秘書にゆとりは必要か?

業務時間の50%が待機時間である秘書の例が挙げられています。この秘書の待機時間を「無駄」と判断していいのでしょうか。どう思いますか?
本書での答えはもちろん「否」と続きます。ゆとりのなくなった秘書は、敏捷に物事に対応できなくなる、と。対応の遅い秘書、対応の遅い総務、考えただけでいらいらしますよね。

仕事にゆとりは必要か?

一般的に仕事のスループットとレスポンスの関係についての話です。大量の仕事を抱え込むと、個人単位でみたらその人の無駄な時間は減少して効率的に働いているように見えます。しかし個々の案件に対するレスポンス能力が下がるため、業務フローに関わるほかの人間に悪影響を与えてしまうというカラクリが存在します。更には複数の仕事を抱えているときに発生するタスクスイッチングのコストも馬鹿にできません。

語源?

レスポンス
response
能力
ability
レスポンス能力
response+ ability→responsibility(責任)

とすると、レスポンス能力が低いとは…?

プログラム開発にゆとりは必要か?

ある開発者が仕事を割り当てられました。かつかつの納期です。どうやら既存のソースコードに少し修正を加えるとできあがりそうです。でも、納期はかつかつなので、綺麗に修正を行なう時間はありません。彼ががんばった甲斐が有って、納期に間に合わせることができました。ばんざい。でもソースはちょっとだけ汚くなりました。残念ながら彼はソースのクリンナップをする間も無く次の仕事に回されていきます。
再び、かつかつの納期で、以前のソースコードに修正を加えたら実現可能な仕事が発生しました。次の担当者はどうするでしょうか?なにしろ時間がないので、ちょっと汚れたソースに手を加えます。そこにはもっと汚れたソースが残ります。ソースは汚れれば汚れるほど保守、修正のコストは増大していきます。
もし、最初に、リファクタリングをするゆとりがあったら、2回目、3回目の修正のコストはどうなっていたでしょうか?

といった感じです。読み進めて気が向いたらまた書くかもしれません。