仕事に悪影響を与えるものを徹底的に排除する、そして言い訳を与えない

ギークに気持ちよく働いてもらうための8か条ってを読んでふと。

どこまで我が儘を許すのかは会社の懐次第だと思うけど
（それこそ社食はタダにして、一流のシェフにしろ！とか）、
給与以外にモチベーションを上げる手段があるってのは極めて大事なことな気がする。
確固とした社風が社員のモチベーションに影響を与えるケースもあるにはあるだろう。
（「野武士集団」とか「紳士」みたいに社風に対する呼称とか、社風自体が社をイメージ付ける重要な要素となっている）。
その場合は「社風を損なう」という大きなデメリットがあるので、個々人の我が儘があまり許されないのだろうな、なんて思うが、
「仕事に関係ないのであれば」好きにやらせてやるというか、悪影響を与えそうなものは徹底的に排除すればいいんじゃない？とは思った。

で、「だからやる気起きないんだよね」という言い訳を与えない、と。

元の記事がギークを特別視している気がするけど、細かい部分を除けば、他の業務も変わらない気がする。
「これって仕事の結果にはあまり関係ないよね？」的な疑問を社員に抱かせる要素も少ないほうが全然よさげだけども。

ありがち。
一部の人間の「仕事はこうあるべきだ感」の押し付けがつまらない不満を呼び起こすとか。

どのみち不満は尽きることはないのだけど、つまらない不満がずっと滞留しているのではなくて、不満の質を上げる･･･改善要望の中身の質を上げることは大事じゃないかとは思うのだが。

あと、本題とはずれるのだけど、

ところで、プログラムのキレイさなどの仕事へのコダワリのレイヤーに含まれる話で、もしそれが生産性に影響するか否かのような話が出るとき、それって本人の「記憶力の悪さ」か、「理解力のなさ」か「頭が固い」か「ただの好き嫌い」のどれかが原因なんじゃねーの？と思うことは、たまに、ある。

日本語と英語と中国語が混ざったような･･･、３つぐらい違うポリシーが叩き込まれたようなソースをメンテしたことがある。
変数名の命名規則がどうのこうのとかそういう生易しいものじゃなくて、
DBへのアクセスも「あるときはトランザクションスクリプト風」「あるときはDIコンテナ風」っていう感じで、
採用されているパターンも「特に理由がなく」バラバラ。
書き手の思考パターンが掴みきれないので、リーディングにすごく時間がかかるという忌まわしい思い出があるなぁ。。。

そういうのとはむしろ逆に、クラッシュアンドビルドとかコピペで充分なシステムに対して、無理やりデザパタ当てはめようとする人もいるので（新しく手に入れた道具は早く使いたがる）、結局バランスなのかなぁ。