A Day In The Boy's Life -36ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

確かに身も蓋も無い話ではあるが。

 

「できない人」にいくら教えても「できる人」にならないのか @ ITpro

 

突き詰めれば「できる人」というのは「やる人(やる気のある人)」であったりもします。

 

ただ、「やる人」であったとしても「できる人」であるとは限りません。

まぁ、仕事においては論外という扱いなのかもしれませんが、「できる人」を育てるよりも「やる人」を育てるという方がずっと厄介だったりもします。

 

 

みんなできる人にしようという幻想

 

やる気があるのに空回りするとか失敗ばかりするという人は周りにもいることでしょう。

しかし、本人のやる気がある分、こちらも教える気にもなりますし、どこかしら失敗ばかり繰り返すその姿に(たまにイラっとしながらも)どこか愛嬌を感じたりもします。

一方でやらない人は、自分の領域を作り何を言ってもそれ以上のことはせず、それ以下であることがしばしば目立ちます。

 

この記事にあるできる人の長年のカンというやつも、実はできない人も持ち合わせているのかもしれないんですが、そもそもやる気が無いためそのカンを働かそうとしません。

何れにせよやらないわけですから、周りから見れば「できない人」というレッテルを貼られることは違いありませんが。

 

「できない人」に教えることである程度のルーチンをこなせるようにはなるかもしれませんが、「やらない人」を動かすのは一苦労です。

「これは僕の仕事ではありません」とばりに自ら仕事の幅を広げようとしなかったりもするので、その殻を破るのは方法論の論理だけではどうにもならなかったりもしますから。

 

まぁ、持論としていってしまえば「できない人」全員を「できる人」にしようというのは幻想で、せいぜいその組織としての役割の一部を担えればよいという感じで、その人はその人のポジションが組織の中にはごろごろと空いてたりもしますからうまく割り当てていけばよい、という考えだったりもします。

もちろん人には得て不得手があるわけですから、何でもかんでも特別なポジションとしてやる気があって優秀な人を割り当てればよいというわけでもなく、その戦力の中から誰がどの役割を一番うまくこなせるのかをみて、その適応能力が高いところにひたすら当てはめていけばよいという考えです。

 

できない人(または凡庸)をできる人に仕立てなくてはならない、という風潮があったりして、ビジネス本とかでもそういった組織を作るにはどう人を育てればいいのか、何てこと書いてたりしますけどそんなことができたら苦労をしませんし、理想を追い求めた果ての現実として組織が崩壊するというのは過去の経験でも目にしていたりもします。

ですから、ある意味開き直ってやる気が無い人がいるってことを認め、その人に最低限の役割をこなしてもらうためにはどうすればよいのか、またはそのポジションとは何なのかってことを考えた方が健全な気がしています。

自分が社長で簡単に人を異動したり切ったりするのができるのであれば楽なんでしょうけど、こういった悩みを抱えているのは中間管理職の人やチームリーダーだったりもするので、今ある戦力でどう戦うのかってことを考えていった方がよいと思うわけです。

 

 

働きアリが働かないアリになる現実

 

働きアリの法則(パレートの法則)というのがあります。

働きアリというのはみんなが働いているわけではなく、2割が熱心に働き、残り8割が怠けているというものです(実際にはよく働くアリが2割、普通に働くアリが6割、怠けているアリが2割といった具合になるそうです)。

そして面白いのが、2割の働きアリを別の場所に移動すると、残りの8割から熱心に働くアリが2割出てくる、または逆に2割の熱心に働いていたアリの中からも8割が怠けだすというところです。

 

実際の組織の中でもこういった現象は起きているのではないでしょうか。

アリの世界でこのような現象が起きる理由は知る由もありませんが、組織の中において「やらない人」が出てくるのは見ていて想像がついたりもします。


1つは、やる気がでるポジションがないということです。
大抵の組織は人が多すぎるように思えます。
業務を遂行する上で実際には人が足りてなかったりするのですが、大人数の中で自分に与えられる役割というのは細分化された作業の一部であり、そこにモチベーションを見出すのは難しくなってきます
「君はこのモジュールを作る責任者だ」と言われたところで、それは途方もなく大きな機械の一歯車を作る作業であったりして、そこの責任者なりリーダーなり良いような名前のポジションを貰ったところで単に責任を押し付けられているだけのようにも感じたりします。

 

課長なり部長なりその組織の大きな責任を担うポジションであれば、その責任を全うするために否応なくやる気を出さざるを得ないという場合がありますけど、そんなポジションがごろごろあるわけではありません。
ですから、毎年毎年余計な組織が増えてはそこに割り当てるポジションを捻出するというようなことがされたりして、それを貰った人は良いにしても、その下で働く人はその人を割り当てるためだけの組織で働いているわけですから仕事の楽しさを見出せるはずもなかったりします。
もしかしたら、アリ自体も他の一生懸命働くアリを見たら「俺がやらなくても良いんじゃね?」って感づいてしまうのかもしれません。

 

もう1つは、効率化された環境になればなるほど、その人が担う役割が単純化されてしまうということです。
「みんな仕事大変だよね。だからもっと効率化してみんなの仕事を楽にしよう!」って意義で始まったPJも、その過程はみなで考え、やることも多いので充実するかもしれません。
しかし、出来上がった完璧な環境(絶対そうはなりませんけど)は、作業をひどく効率化した一方でそこでやる仕事は単純になりつまらくなってしまいます。

 

CASEツールを使って完全なプログラムが作れたとしたら、極論言えばシステム部門でなくてもプログラムを書けるわけで、そうなってくるとプログラマとしての面白みは失われていくでしょうし、変わりに与えられるのは上流工程だったりして、こういうことって昔から言われているんですが「今の仕事を効率化して空いた時間でより上のレベルの仕事をしてもらいたい」という言葉の「上のレベルの仕事」というのはたいていの場合、会社から見れば単価が高い仕事って意味だったりもするので、レベルが高いかどうか関係なかったりするわけです。

 

 

「やる人」を作る組織

 

これも身も蓋もない話ですが、みんなが「できる人」になるのは幻想と書いたようにみんなが「やる人」になるのもまた幻想だと思います。


先ほど書いたアリの世界と逆のことをすればうまくいくかもしれませんが、誰もがモチベーションを持てるポジションを作るというのは縦割りの世界をなくした完全フラットで誰もが重要なポジションにいる組織を作るということになり、その中で誰かに押し付けたいような仕事を自分でがんばるみたいなことを皆が思っているか、割り切って無駄ややりたくないことをアウトソースしてしまうというような割りきりが必要なんでしょうけど、コスト面で見合うかという問題も出てきたりします。

そして、効率化しない組織を作るというのは組織の成長としてあり得ないので、ひたすら成長し変改し続ける状態を保つにしてもそれってきつい状況でもあるわけですから、その人が忙殺される毎日に耐えれなくなったり、ふとした合間で燃え尽きてしまう可能性もあります。

 

小さな組織であればこれは少し見込みがあるわけですが、規模が大きくなり人が多くなればなるほど絶望的な状況になりかねません。
極論言えば「やる人はやるけどやらない人は幾ら言ってもやらない」ってことになるわけですけど、できない人をできるようにするよりも前に、やらない人をやる人に変えていくことをしないと成長もしないよ、と思ったりします。


で、やる人に少しでもやる気を持ってもらう方法としてですが、以前に読んだ「小さなチーム、大きな仕事 」の中に書かれているような組織作りのイメージを持っているのですが、これは組織としての常識を覆すものが多いので、なかなか今の組織の中に取り入れるというのは難しい場合が多いかもしれません。
組織としての急速な成長というものを捨て去る必要がありますし、そもそもができる人を育てるということすら考えていません。

 

組織がコンパクトであればあるほど、担う役割というのは大きくなります
そしてやることも当然多い分、その人にとっての充実感が増すことにはなるでしょう(一歩間違えればブラックですけど)。

 

結局のところ、会社という枠組みの中で、その企業のトップダウンとしてそういった文化を創れるのであればよいでしょうけど、大抵はそんなことはなく小さな組織として成り立たせても、会社の言い分と組織の言い分でのギャップができて板ばさみにあう組織長は心が折れてしまう気がします。


言ってしまえば、やる人を作るというのはその企業命題の中にどれだけ本気で従業員のやる気にさせる組み込めるかってことになり、それって売上犠牲にしてまでやるってことでいいんですよね?という質問にきちんと「はい」って答えられる人が運営しないと作れないと思うわけです。

ですので、アリと同じく8割が仕事をしていないという状況でも、2割で組織が持っているなら良いじゃんという究極的な答えが出てくるのだろうと思います。


ここで、「やる人」が育ったとしても「できる人」にするためには更なる変化が必要なわけで原点回帰して最初の問題に戻るわけですが、「やらない人」が多くいる環境では幾ら「できる人になれ」と言ったところで成長は見込めないと思うわけです。

 

 

 

今月でこのブログを始めてから7年間が経過しました。

よく飽きもせずに続けられたものだと我ながら感心したりもするのですが、よくよく思い返してみるとブログを始める前と始めた後では自分の考え方であったりライフスタイルも随分と変わってきたな、と感じたりしています。

先にまとめてしまうと、その変化は今の自分にとってよい方向性に導いてくれたものが多かったと思いますし、ブログを書かなかったら普通のおじさんとして返ってネットには疎く、ここまでエンジニア志望として仕事もしていなかったように思えます。



1. 他人のブログに興味を持ち始めた


それまで自分自身、エンジニアという仕事をしながらあまりネットに興味を持つことがありませんでした。

どちらかというとネットは調べ物をするところという感じで、それ以上でも以下でもない使い方をしていたと思います。

ネットから拾う情報というのはひどく自分にとって偏りがあったので、他人の考えなんてものにはあまり興味がありませんでしたし、今ほど多種多様な考え方が毎日どころか毎分埋もれるほど発信されるということも無かったので、他人の発現に目を留めること自体が少なかったと思います。


ただ、ブログを書くようになってからはひどく他人の意見というものが気になりだしました

単に人の目を気にするという以上に、自分の考え方とのずれというのが気になりだしたというか、もちろんブログのネタとして情報を探していたというのもあるのですが、他人のブログを見ることでこういう事を言ってもいいんだ、言うのは止めた方がいい、そんなこと考えている人もいるんだ、このアイデアは誰でも思いつくことなんだな、と色々気づく点も多かったりします。


最初の頃はわき目も降らずにひたすら書いていたりもしましたが、そのうち毎月書くエントリより全然多い本数の他人の記事を読み出すようになりました。

ブログは書くものですが読むためのものでもあるわけです。

当たり前ですけど人様のブログを読んでいるとそんなことがはっきりわかるわけで、じゃあブログの書き方ってなんだろうという視点に回帰していきます。


こういうことって、他人に興味を持つというところで、仕事でも私生活でも相手の真意を気にすることで会話がうまくいったり、自然と気を回せたりというところにつながってくるかなとか思ってたりもします。



2. 35歳を過ぎてもエンジニアとしての情熱を持っていられた


プログラマ定年説の年齢を超えても技術的なことに興味を持ち続けられたのは、ブログのネタとしてでもプログラミングであったりツールの使い方であったりと言うことを発信し続けたからというのが大きいと思っています。


多分、ブログ書いてなかったら元々そこまで深追いするエンジニアでもないのでそのうち頭の片隅に追いやられていって技術力も無く、どちらかというと社内でどううまく立ち振る舞うかみたいなところばかり気にしていたのかもしれません。

情報システム部門ということで、得る情報はよりいっそう少ないですしレガシー化した環境に囲まれて「俺のコードはちゃんと動くしこれでいいんだ」って辺に納得する井の中の蛙になってたような気がします。


自分の記憶のまとめという役割でもこのブログに集約されることで、「前にこれやったな」ってことを引き出すことも容易になりましたし、過去の情報に触れることで興味が薄れていくことを断ち切れますし、ブログにまとめるついでにもう一歩踏み込んでみるというようなことでより新しい知識も得られますし、その過程で読んだ他人のブログとかで「この人スゲー」という憧れを得てそれがモチベーションにつながることもありますし、よりいっそうの興味も拡大していったりもしますし、ここまでまとめておけば自分のエンジニアとしての履歴書のようなものが簡単に示せたりもします。


元々子供の頃からプログラマになりたいなと漠然と思ってたけど大学とかまで大して情熱を持てずにいた自分をここまでずるずるとでも引っ張ってこれたのはこのブログの影響が大きいと感じています。



3. 本を読むようになった


それまで活字嫌いだったりして、子供の頃はおろか社会人に出るまでろくに本を読んだことが無かった自分ですが、ブログを書き始めてからその苦手意識のようなものはなくなりました。

これだけ文章を書いていたら書く楽しさというものにどっぷりつかる様になりましたし、他人のブログへの興味同様に本も読んでみようかと自然と考えるようになって、少ないながらも手にする機会が増えました


本はどちらかというと技術よりな話よりも考え方であったりビジネス本が多かったりするんですが、エンジニアとしてキャリアを考える一方で、違った側面も伸ばしていきたいという考え方もあって、昔親からよく言われた「本を読め!ってことわかるわー」なんて漠然と思ったりしてます。

まぁ、先に書いたように活字嫌いが克服されなかったらそんな本なんて読まなかったでしょうし、自分の中にある不安や疑問というものを何時までも抱え込んで「まぁどうにかなるでしょう」という楽観主義のひどくレベルの高いところで生活していたのかもしれません。


それが本を読むことで全て解消されるなんてことまで言えるほど読んでも無いですし、実際そうではないのでしょうけど自分には無い新たな知識を頭に入れることでそれをどう自分なりに昇華させようか考えてみるというのは視野を広げたりするきっかけになるかと思います。



4. 面倒くさがり屋から抜け出した


結構めんどくさがり屋だったんですよ。飽きっぽいですし。
ですが、流石にここまでブログ続けてればそういった敷居がかなり低くなったように思えます。


ブログ書くこと自体とても手間なわけです。
技術ネタとか書き出すと1エントリで早くても2、3時間かかったりしますし、凝り出すと丸1日ぐらいの時間を費やしたりしてます。
まぁ、それで大きな反響があるかといわれるとあまりそうでもなかったりするのでがっかりすることも多いのですが、自分の知識を集約する延長上にはあるのでその辺は置いとくとしても、過去のエントリを保守したりコメントがあった間違いの指摘を自分で再検証して修正したりと細々としたところで手間もかかりますから、そういったことを続けることでそんなぐらいの手間であれば仕事であれなんであれあまり面倒だと思わずに作業できたりもします。


特に文章でまとめるというのは活字に慣れたということも相まって仕事でも全然気にならなくなったりします。
が、弊害としてはメールなり長文になりがちだというのはあるかもしれませんが。
あとは、このブログ自体、アクセスアップだ!このブログで食っていくんだ!みたいなガツガツした感じは本人的に持っていないので、平穏無事をモットーとして長く続けることで忍耐力というのも鍛えられたかなと思います。



5. 趣味ができた


それまで趣味らしい趣味というのがなかったんですが、日常的にブログを書くようになってからは、空いた時間でブログ書くかというように趣味として確立ができました。
毎日毎日書いたりしているわけではないのですが、仕事をしてたり日常の中でも「このネタを書いてみるかな」って思ったりしてEvernoteとかにメモったりしています。


自分の中に根付いたものなので自然とそういう考えになってしまいましたし、他人に「ブログ書くことが趣味です」とか言うと「じゃあ読みたい!」とか言われるのが面倒くさいので口外してませんけど、人に言える趣味かどうかなんてものはそんなに重要ではなく、取りあえず自分の中での時間を忘れさせてくれることとしてブログを書くというのが根付いたりしています。


趣味ができるというのは要は何か大事なものが他にできるということだったりします。
どんな趣味であれ、それをすることが楽しくライフスタイルの中に当たり前にある存在を見つけられたというのはラッキーだったなと感じています。



おわりのまとめ


先に書いたようにブログを始めなかったらここに書いたことは変わらなかったと思いますし、自分の性格上ではそれは良い方向に転がったのではないかなと思っています。


だからみんなブログ書こうぜ!見たいなことは当然その人それぞれのライフスタイルにあった書き方があるわけですが、少なからず長く続けることで自分の中に変化をもたらすのは当然あると思います。

その変化がよいものになるかどうかブログとの付き合い方によっても変わってくるわけですけど、あまりガツガツせずにただ長く付き合うという中でも色々な考えや行動がそれ以前と以後では違いが出てくるので変わるきっかけでもあったよな、と今改めて感じたりします。




いまさらなネタでもあるんですが、RedHatとかのデーモンの自動起動・自動停止の管理はchkconfigを使うというのが一般的ですが、後で追加したパッケージの起動のランレベルをいきなり変えるとサーバーの再起動や停止時にちゃんと自動停止してくれないかもよ、ってお話です。



chkconfigの仕組み


この辺は、ググれば情報はたくさん出てくるので簡単にしか書きませんが、init.dの下に配置されている各デーモン用のスクリプトのヘッダ部分で起動するランレベルが定義されています。


#!/bin/bash
#
# httpd        Startup script for the Apache HTTP Server
#
# chkconfig: 345 85 15
# description: Apache is a World Wide Web server.  It is used to serve \
#          HTML files and CGI.
# processname: httpd


「chkconfig:」って書かれた箇所が該当のところで、「起動するランレベル」「起動時のプライオリティ」「停止時のプライオリティ」の順番で書いていきます。
ランレベル345の時に起動させ、起動する際のプライオリティは85、停止時のプライオリティは15としています。

この設定でchkconfigに登録されていれば、


# chkconfig --list httpd
httpd           0:off   1:off   2:off   3:on    4:on    5:on    6:off

って状態になり、rc3.d~rc5.dの中にシンボリックリンクが作成されます。


# ls -la /etc/rc3.d/S85httpd
lrwxrwxrwx 1 root root 15  8月 22 09:51 /etc/rc3.d/S85httpd -> ../init.d/httpd

停止の場合はランレベル0なのでrc0.dですね。


# ls -la /etc/rc0.d/K15httpd
lrwxrwxrwx 1 root root 15  8月 22 09:51 /etc/rc0.d/K15httpd -> ../init.d/httpd

同様に再起動した場合はランレベル6なのでrc6.dの下に自動停止用のスクリプト(シンボリックリンク)が作成されます。

chkconfigの起動するデーモンの管理は、rcX.dの下にシンボリックリンクが存在しているかどうかで管理しています。
コマンド実行時に毎回見に行っているようです。
ですので、このシンボリックリンクを消すことでも起動するランレベルを変更することができます。


# rm S85httpd
rm: remove シンボリックリンク `S85httpd'? y
# chkconfig --list httpd
httpd           0:off   1:off   2:off   3:off   4:on    5:on    6:off

は、

# chkconfig --level 3 httpd off

と、同義になります。



chkconfigに登録していないデーモンのランレベルをいきなり変えると自動停止してくれない


で今回の問題ですが、新しく追加したパッケージなどをデーモンとして自動起動させたいような場合、chkconfigに登録されていない状況で起動するランレベルをいきなり変更すると、自動起動はするようになるのですが自動停止はしてくれません。


# chkconfig --del httpd
# chkconfig --list httpd
サービス httpd は chkconfig をサポートしますが実行レベルで参照されていません (run 'chkconfig --add httpd')
# chkconfig --level 345 httpd on
# cd /etc/rc3.d/
# ls -la S85httpd
lrwxrwxrwx 1 root root 15  8月 22 10:13 S85httpd -> ../init.d/httpd
# chkconfig --list httpd
httpd           0:off   1:off   2:off   3:on    4:on    5:on    6:off


上記のように自動起動はちゃんと行えていますが、rc0.dの下を覗いてみると自動停止のスクリプトが配置されていません。


# ls -la /etc/rc0.d/S15httpd
ls: /etc/rc0.d/S15httpd: そのようなファイルやディレクトリはありません

ってことで、Apacheの自動停止が正常に行われません。
まぁ、最終的にはkillallでプロセスが殺されますけどお行儀のいいやりかたではありませんし、場合によっては障害となる可能性もあります。

で、正式なやり方としてはちゃんとchkconfigにaddしてから起動するランレベル変えましょうねってやり方になります。


# chkconfig --add httpd
# ls -la /etc/rc0.d/K15httpd
lrwxrwxrwx 1 root root 15  8月 22 10:30 /etc/rc0.d/K15httpd -> ../init.d/httpd

または、resetオプションを実行しても問題ありません。


# chkconfig --del httpd
# chkconfig --level 345 httpd on
# ls -la /etc/rc0.d/K15httpd
ls: /etc/rc0.d/K15httpd: そのようなファイルやディレクトリはありません
# chkconfig httpd reset
# ls -la /etc/rc0.d/K15httpd
lrwxrwxrwx 1 root root 15  8月 22 10:34 /etc/rc0.d/K15httpd -> ../init.d/httpd


resetオプションを実行するとinitスクリプトのヘッダを読み直してその通りに設定しなおしてくれます


こう考えると、よくサーバー立てたら不要なデーモンは動かさないようにしましょうとか言われますけど、chkconfigコマンドで指定のレベルでOn/Offするよりは、initスクリプトのヘッダで本当に必要なレベルで動かすように定義しておいた方がadd/del/resetで管理できるので確実なのかもしれません。
まぁ、スクリプトの数は多いので手間といえば手間なのですが。


不安があるのであれば一旦各スクリプトをresetさせるのも良いかと思います。