Hatena::ブログ(Diary)

今日とは違う明日 このページをアンテナに追加 RSSフィード Twitter

2008-09-07

技術力の高いエンジニアをどこまで特別扱いすればいいのだろう

malaがはてなを退職したって事で、原因は何だろう?

個性や創造性を発揮できない普通の会社「はてな」

malaさんがはてなを辞めた理由は知らないけども、このエントリーを読んでて思い出したことがあった。


3年ほど前に私が15名ほどのチームでプロジェクトリーダーをしていたとき、一人だけずば抜けて技術力のあるエンジニアがいた(Aさんとする)。Aさんは私の1つ上の先輩で、その技術力の高さを見込んで、ライブラリだのフレームワークだのの開発や改善をお願いしていた。それについては、当然ながらチームに多大な貢献をしてくれたと思っているし、技術に意識の高いメンバーを彼に付けて作業させたので、他のメンバーの成長にも役立ったのは間違いない。

しかし、その時プロジェクトには、もっと単純だけど、時間がかかって根気の必要な、欠かすことの出来ない作業もあって、ほとんどのメンバーはそれに従事していた。多分、ライブラリだのをプログラミングするよりも、ずっとツマラナイ作業だっただろうと思う。みんな、最後まで頑張ってくれたので、それにはとても感謝している。


さて、本題はここからだ。

当時、私が非常に恐れていたことがある。幸い、現実化することはなかったが。それは、他のメンバーが「Aさんだけ特別扱いでずるい」と不満を露わにすることだった。

プロジェクトがピークの時も、Aさんの労働時間は相対的に周囲より短かった。もちろん、それはAさんが効率良く作業を進めているからであって、努力と行動の結果としてそうなっているのだけど。ただ、分からない人には、それは分からないのだろうと思う(もちろん分かっている人もいた)。

求めている高いハードルをクリアしてくれている以上、Aさんの能力が発揮できるようにすることは、あのチームの1つのポイントであったことは間違いなかった。

しかし、Aさん一人が動けばプロジェクトが成功するわけではない。他のメンバーがやってくれている作業も、ゴールへ到達するためには欠かすことができないものなのだ。

要は全員がそれなりに力を発揮して貰わなければ、ゴールへ到達することができない状況だったわけである。

もし、Aさんのやり方と他のメンバーの不満が衝突していたら、どうすれば良かったのだろうか。未だに結論が見出せない。


個人的には、エース級のエンジニアや社員には、最低限のことを守ってもらえれば、とことん自由にやってもらっても良いんじゃないかと思う。しかし、一方ではルールに従ってもらうことを要求する人たちもいたとき、そこに衝突のリスクを感じざるを得ない。


関連しているかもしれないエントリー


追記

ぶくまコメントを眺めながら幾つか追記したことが出てきた。

ホッテントリに載るとは思ってなかったので、ちょっとドキドキしながら以下へ。


まず、Aさん以外のその他メンバーについて。

繰り返しになるけども、彼らは実際に不満を表明したわけでないのです。寧ろ、文句も言わずにしっかりと仕事をしてくれた。

私は彼らに対して感謝しているのです。(Aさんにも)

#えっと、何となく擁護しておきたくなったので。私は彼らのことも好きなのです。


不満を露わにしたらどうしよう、というのは私が感じていた「顕在化していないリスク」だった。

なんでこんなリスクを感じたのかということについて、ハッとさせられたぶくまコメントが

atawi 労働 本題とは別の、日本の労働観のいびつさが指摘されててわろた。

だった。なるほど、これは私の根っこの部分に、日本の労働観が染み付いているのだな、と。表層意識の部分で否定はするけど、それが「日本での働き方だ」って脳のどこかにインストールされているかのようだ。だから、他の人もそう思っているのではないか、と想像してしまったのかもしれない。

しかし、この件を私と同じように「難しい問題」と捉える人達もいるようなので、やはりリスクとしては存在するのだな、とも思った。


作業の量と質を定量化できれば、一番分かりやすいのだろうけど、なかなか難しい。

Aさんのやった作業は、他のメンバーの作業負荷を軽減するものでもあった(そのためのフレームワークライブラリ)。

でも、実際どのくらい軽減できたのかを比較することはできない。それを比較にするには、Aさんが居なかった場合と比べることになるけど、同条件でプロジェクトを実施することなどあり得ないし。

ちなみに、このプロジェクトは2フェーズに分かれていて、Aさんは第1フェーズの終了と共にプロジェクトを去った。Aさんの居なくなった後の第2フェーズは、工数見積上は第1フェーズよりも大きいにも関わらず、大したトラブルもなく、スムーズに作業が進んでいった。

これはAさんが残してくれたフレームワークライブラリに対して、各メンバーの学習が進んだから、というのも1つの要因だったと思う(もちろん他にも要因があるが)。


組織的な仕組みでカバーするような意見もあって、それはそれで面白いと思うのだけど、プロジェクトリーダーという立場においては、結局のところ、Aさんの位置付けを明確にした上で、その理由について地道に語っていく方法が一番なのかな、と思った。

そういう意味では、コメント欄に記入してもらったcyphertec_asakawaさんの

能力差はあって当り前だし、それをどのように知らしめることができるかとか、個々の不満を個々に吸収する以外に手はないと思います。そういった意味で、プロジェクトリーダにはどうしてもコミュニケーション力というのが要求されるのも当然なので、日々チームを見渡す気遣いが要は大切なのです

という意見にはてなスターを付けたいところ。


#今回、自分のエントリーに対して、たくさんの意見を目にすることができたのは、新鮮な体験でした。ぶくま&コメント&トラバ、ありがとうございます。

なまえなまえ 2008/09/08 15:46 大筋その通りだと思いますが、
「最低限のこと」というのが、人によって(特にいわゆる”スーツ”と”ギーク”間)考えが違うので、なかなか難しい問題だと思います。
”スーツ”が「これくらい最低限のこと守ってよ」と言うことが、”ギーク”の常識にはなかったり。

cyphertec_asakawacyphertec_asakawa 2008/09/08 16:57 チームで仕事する場合には、当り前のようにあるリスクですネ。
能力差はあって当り前だし、それをどのように知らしめることができるかとか、個々の不満を個々に吸収する以外に手はないと思います。そういった意味で、プロジェクトリーダにはどうしてもコミュニケーション力というのが要求されるのも当然なので、日々チームを見渡す気遣いが要は大切なのですが、そこが実はうまく行っていたのではないですか?それともたまたまだったのでしょうか?今後もありえる話とは思いますので、ちょっと振り返りしてみるといいと思います。
勝手なこと言ってすいません。

h-yanoh-yano 2008/09/08 18:13 >なまえさん、cyphertec_asakawaさん

コメントありがとうございます。
常識やベースとなる考えの溝を埋めるのは、恐らく地道で手を抜かないコミュニケーションなのでしょうね。
今後の参考にさせていただきます。

通りすがり通りすがり 2008/09/08 19:35 別に優秀ってわけでないけど、同じような件でゴタって会社辞めました。

昔勤めていた会社のあるプロジェクトでインフラ周りを担当していました。そのプロジェクトはプログラマーがそれなりに忙しく定時以降もみんなサービス残業していました。自分はちゃちゃっと仕事を効率よく片付けて定時に帰っていたのですが、、、ある日、プロジェクトリーダーに呼び出されました。

みんなが頑張ってる中で、ひとりだけ定時に帰るのはどうなの?チームワーク乱すなよっと。でも、自分の仕事終わっているのに、ダラダラWebでも巡回して暇潰ししているのも時間が勿体無いし、そもそも、プログラマーでもないので手伝えることないんですよね。それとも、何か手伝うことありませんか?とでも聞けばよかったのか。

結局、残業代貰えるんだったら残りますよといったら、それはできないと、じゃあ条件面が合わないので、会社辞めますといったらそれは困るという。

転職先には特に困ってない状態だったのでちゃちゃっと引継ぎして辞めました。

僕も元々は一人だけちゃちゃっと仕事終わらせて帰る人に『まだ俺は仕事しているのに先に帰るんじゃねー』ともの言わぬ視線を浴びせてた人だったので気持ちは分かるんだけど、でも、今は本当は自分の能力が足りないだけか、あるいはそもそも、サービス残業という法律に違反していることが当たり前になってる状況の方がおかしいと自分は思っています。

コメ汚し失礼しました。

h-yanoh-yano 2008/09/08 23:22 >通りすがりさん

プロジェクトリーダーからそれを言われると、やはり辛いですね。
貴重な経験談、ありがとうございます。
参考になりました。

残業が当たり前となっている状況がおかしい、というのは私も同意です。(少なくとも表層意識上では)

通りすがり通りすがり 2008/09/09 15:21 返信ありがとうございます。

上記のようにプロジェクトリーダーに、
精神論を言われちゃった場合は、転職という選択肢が複数あって
しかも待遇がよいというのであれば、やっぱり抜けちゃいますね。

技術力の高いエンジニアが抜けるかどうかは
やっぱりプロジェクトリーダー次第な気がします。

特別扱いをする必要はないけど、技術力の高いエンジニアは、
少なからず他社からオファーがあることが多いと思うので、
他のメンバーが不満を露にした場合、転職という選択肢を持っている点は留意する。

「Aさんだけ特別扱いでずるい」と不満を露わにするメンバーが仮にいた場合、
そのメンバーに実際にAさんの仕事であるライブラリだのフレームワークの開発を
やらせてみるのが一番いい解決方法だと思います。
意外と『隣の芝生は青い』ではないですが、実際にやってみたら結構大変だったりします。
自分の場合、そのプロジェクトリーダー・他メンバーは、『インフラが簡単そうに見えた』らしく、
引継ぎの際に、自ら勉強したいと名乗り出て地獄みてました。
自分が定時に帰れるようになったのは、3年間担当してきたノウハウで
効率化して来た結果であって、自分も最初の頃は1ヵ月間会社から帰れないなんて事はザラでした。
でも、そんなことははた目から見てる分には分からない。
理解してもらうには、やっぱり本人に実際にやってもらうのが一番かなと思います。

とはいえ、実際に担当させることはできないことも多いと思うので、
例えば、通常の業務を終わらせたうえで、空き時間をライブラリや
フレームワークの勉強の時間に充ててもいいと許可を出すとか
やりようはあると思います。

それができなければ、h-yanoさんのおっしゃるように
事前に各メンバーにそれぞれの役割を説明しておくのが最善策ですかね。
やっぱり難しい問題だとは思います。

何かの参考になれば幸いです。

h-yanoh-yano 2008/09/09 17:53 >通りすがりさん

再び貴重な体験談をありがとうございます。

「やらせてみる」というのは、それが可能であれば確実なアプローチですよね。
想像するのと、実際やってみることの差は、仰る通り大きいと思います。

今回、色んな方から意見を頂いて、状況や制約によって
実に様々なケースがありそうだな、と感じました。
その時々に合わせて最適なアプローチをとるのも、
リーダーの責務なのでしょうね。

それぞれのメンバーが、それぞれに気持ちよく力を発揮できりょうに
プロジェクトの環境を整えることができるようになれれば、
と思いました。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証