会社が火消し屋に「頼る」危険性

思わず脊髄反射。・・・ん？「思わず」と「脊髄反射」は同じ意味か。まあそんなことはどうでもいい。

仕事が慢性的に過度に集中している人は、一度じっくり考えてみたほうが良い。会社は、「あなた」のことを頼りにしてるけど、実際のところはこき使ってるわけですよ。俺なら、ピンチのときにできる人に仕事をいっぱい頼むことはあっても、それを慢性的には行なわない。だって、その人に壊れて欲しくないから。

会社から「頼りにされる」危険性 - yvsu pron. yas

仕事が過度に集中している場合というのは、何らかのピンチの場合であって、要するに火消しを頼まれている場合が多いのだと思う。で、慢性的に集中しているってコトは、慢性的にその会社がピンチだってコトで、これは相当まずいコトだと思う。

ここでいう「危険性」ってのは、その仕事が集中している「出来る人」にとっても危険なんだけど、その会社にとっても危険なのだ。出来る人を火消し屋として使うというのは、非常に危険な人材の使い方だと思う。

火消しというのは、要するにデバッグだ。火消し仕事に奔走する人というのは、デバッグばかりをしていることになる。あるいは、急場しのぎの修正プログラムばかりを作っていることになる。

では、誰が新しいコードを書いているのか。

「出来ない人」だ。

で、当然「出来ない人」のコードは問題を生む。火事を起こす。

そうして、再び「出来る人」が火消しに駆り出される訳で、忌むべき悪循環がここに発生する。

「出来ない人」に火遊びをさせたら火事が起こるのは当然の話で、解決策は「出来る人」がきちんと火元を管理する以外にない。「火事が多いから消防隊を強化する」というのはあまりにナンセンスな解決策である。病気は治療よりも予防に努めるほうが、社会的コストが小さく済む。

もうひとつの問題は、この悪循環の中では「出来る人」が本当の意味での「出来る人」になれないことだ。そして、「出来ない人」が「出来る人」に成長することも難しい。

火消しばかりの仕事では、急場しのぎの修正プログラムをササッと書き上げるスキルは上達するかもしれないが、じっくりとアーキテクチャを設計しメンテナンスを続けていくような、真のアーキテクトとしてのスキルは得られないのではないかと思う。この手のスキルを得るには、どうしてもトライ＆エラーが必要であり、それは即ちコードをあーでもないこーでもないと弄りながら良い設計を考えることであり、それは即ちヒマがなくては出来ないことなのだ。

そして、こういったアーキテクトの元に師事してこそ、「出来ない人」も「出来る人」へと成長できるのだと思う。

つまり言いたいのは、火消しに奔走している状態というのは「仕事が仕事を生む」状態ということであり、目指すべきはその悪循環から脱却して逆に「ゆとりがゆとりを生む」状態を作り出すことであり、それが経営というものなのだ。