memo/20110830
created 2011-08-30 modified 2011-08-30
なんかとても大事なことに改めて気づかされた気がする。
リンク | 備考 |
---|---|
善良で空気の読める人たちがブラック企業をつくる | |
世の中の仕事の絶対量に対して人が多すぎるのか | |
Wikipedia ラッダイト運動 |
自分も一所懸命に「空気を読んで」ブラック環境を作っていた。世の中の大変なことを自分が背負い込むことはできないし、ソレをやったところで結局、誰も幸せにならないんだね、と気づいた。頑張ることは必ずしも正義じゃない、と。
ソフトウェア開発プロジェクトでは、マネジメント(の担当者)によって、バグ検出目標値やら、さまざまな指標値が定められる。
くだんの目標値・指標値ってのはある意味では、ある工程で、100%の仕上がりを待たずに次へ進んだほうが、全体として効率がよい、という経験則を含んでる。
単体試験工程ですべてのバグを出して、結合試験・総合試験でゼロを目指すのも非効率だし、単体試験を拙速にやって結合・総合試験で苦労するのも、非効率。「一番効率がいいどこか」を、過去の経験からエイヤで選んで、そこまでできていたら次へ進もうよ、というもの。
なんだけど、マネジメントが計画したテスト方法や手順・人数・時間数と、バグ検出目標が、あっていないことが、よくある。そういう状況で、現場のメンバーが独自の判断で休日出勤や自主的な超過残業で追加の作業をやって品質を高めてしまうようなことがあるけど、それをやってしまうと、マネジメントの失敗が数字に出てこなくなってしまう。現場の職人の行過ぎた職人根性は、プロジェクト全体でのマネジメントの失敗を隠してしまって、次のプロジェクトの投入工費の見積もりを、悪化させてしまう。
だから私は、マネジメントの計画が悪いときには、プロジェクトをコケさせることも、重要だと思う。
マネジメントの失敗をプログラマが全部背負い込むことは、ないんだよね。
その行過ぎた職人根性が、先のアノニマスダイヤリーで指摘されてる「善良な労働者がブラック環境を作り出してしまう」ということじゃないかと、思ったことですよ。
特に、
一定レベル以上のマネジメントに自分がクチを出せないような場合は。