お仕事」タグアーカイブ

新人のモチベーション

モチベーションという言葉自体あまり好きではありませんが。

労働は本質的に集団の営みであり、努力の成果が正確に個人宛に報酬として戻されるということは起こらない。
報酬はつねに集団によって共有される。
個人的努力にたいして個人的報酬は戻されないというのが労働するということである。

http://blog.tatsuru.com/2007/06/30_1039.php

内田先生の文章は相変わらず上手い。僕が読んでるブログの中では最も読ませるブログだ。そして今回の相当興味深いことを書いている(ちなみにこのエントリを書いている時点ではてブが223に対し、コメントとトラバは2つずつ。うーん、アンバランス)。文章が上手いと言っても、適当な事を文才でごまかしているとかそういう話ではなくて、単純に博学であり、かつ洞察が深く、そして自分の頭の中にあるものを上手くアウトプットする能力を持っていると思っている。
さて新人のモチベーションだけど、結局内田先生の言うとおり個人的努力は個人的に報酬に還元されないのは確かな話で、評価制度にどんな手を打ったとしてもそこに不満を感じる社員は消えないだろう(僕も勿論例外ではない)。だから個人的には新人には、会社から与えられる報酬、つまり収入や地位を軸に自分の仕事を考えるのではなく、客観的に見て自分の能力が仕事を通して上がっているのかどうなのかを中心に自分の仕事を考えて欲しい。例え見合った報酬は得られなかったとしても、仕事を通して能力が伸びたというのであれば良しと考えて欲しい。逆に報酬は得られたが、まったくもって能力の伸びない仕事を与えられたとしたら「げっ」と思って欲しい。
まあ上手く書けないけれど、自分が属している分野の中ではグローバルに高い評価を得られる様な人材になって欲しい。そうすれば報酬だっていずれついて来るだろう。

吐露

何をやっているんだろう。

元々何か凄いものを開発したいと思って開発者になった。別にそれはソフトウェアじゃなく、ハードウェアでも良かったんだけど、趣味趣向が自然と僕にプログラミングを選択させた。何か凄いものってなんだろうっていう定義は出来ないけれど、例えばGoogleの検索とかiPodとかトヨタのプリウスだとか、とにかくそういう世界的に大きなインパクトを与えた製品やサービスに心を惹かれたし、そういった製品やサービスの開発物語(プロジェクトXみたいなイメージ)を読んだり聞いたりすると心が震えたものだ。「自分もいつかそんな製品やサービスを世に送り出したい」、そう思った。僕の仕事の目標はシンプルにただそれだけだと思う。すんげぇもんつくる。

でも最近の僕は何をやっているんだろう。1年前くらいにチームリーダーになった。そこから工数の調整だとか上への報告だとかそういう仕事が増えた。会社がそう決めている訳ではないけれど、チームリーダーはコードなんか書かない存在になるべきだという考え方はかなり会社に浸透している様に思う。そんな存在にはなりたくない。しかし正直言えば、一旦なってしまったこのチームリーダーという存在に恋々としている自分が存在する。チームリーダーの給与幅は一般社員より広いのだ。僕にも家族はいる。そんなことを言い訳にしながらどっちつかずの毎日を過ごしている気がする。

この間会社の評価制度が変わった。自分の成果をプレゼンテーションで評価者に発表し、採点するというもの。プレゼンする相手、プレゼンをされる相手は普段一緒に仕事をしていない人達だった。15分のプレゼンテーションでは何も評価できなかった。一部の人はとてもプレゼンテーションを上手くこなしていた。言い訳がましいけれど、僕はプレゼンテーションなるものは得意だと思う。人前も得意。でもだ、終わると思った。ここで素晴らしいプレゼンテーションをして、自分の評価を上げる真似をしてしまったら開発者として終わると思った。その方法論から抜け出せなくなると思った。高評価に恋々としてしまうだろうと思った。開発者として技能を向上させることを馬鹿馬鹿しく思うようになるだろうと思った。だから僕は単調なプレゼンテーションをした。立ってプレゼンテーションをした方が印象が強いだろうというプレゼンテクニックの話が終わったあとに出たけど、僕は来年以降も座りながら単調なプレゼンテーションを行うだろう。無論、自分が凄いものを作れたときにはその凄さを必死でアピールしたいと思っている。開発者ってそういうもんだと思う(実際は、チームリーダーとしてチームメンバーをどの様にマネジメントしたのかを中心にプレゼンテーションするのだが…)。

今僕は不安であり、そして頭に来ている。頭に来ている?何に対して。それは間違いなく自分に対して。会社の評価制度も周りの社員もどうのこうの言ってはいるものの、僕にもっと素晴らしい技術があれば、アイデアがあれば、能力があれば、会社がどんなことを言ってこようとも、どんなことをこちらにさせようとも、世間が僕を評価してくれるはずだから。だから自分の能力の無さに頭が来る。だったら世渡り上手になって能力の無さを隠しながら生きようと思ってしまう弱い自分にも頭が来る。不安なのも結局自分の能力が自分が思う十分なレベルに達していないからだ。全ては自分に起因する。

凄いものじゃなくてもいい。とにかく何かを作ろう。何かを生み出そう。結果それがクソでも構わない。次に繋がればそれでいい。超簡単なゲームでも構わない。意味の無いものでも構わない。会社で作れないなら自分で作るしかない。最終的にも凄いものは作れないかもしれない。でもそれでも構わない。世渡り上手なカスエンジニアになるよりましだ。もし自分には凄いものは産み出せないという結論に辿り着くようだったら、そのときは潔くエンジニアをやめよう。僕にはお金を稼ぐための技能がプログラミングの他にもある。

まとめ

開発者としての自分の能力とのみきちんと向き合う。能力が無いようだったら潔く止める。世渡り上手開発者にはならない。以上。

あー、よく分からないエントリになったけどすっきりした。会社の人間も一部読んでるかもしれないけど、まあいっか。

コミュニケーション能力の正体

僕は「コミュニケーション能力が売りです」とか「エンジニアにもコミュニケーション能力が求められる時代」とかそういう意見があまり好きではない。勿論最低限のラインというものは存在するだろうし、第人数の聴衆を相手に自分の意図を明確に伝えれられるとか、相手がどんな人間であっても取り入ることが出来るだとか、そういう人より優れた能力を持っている人間もいるだろうと思う。
でも1エンジニアとしては、世間一般でコミュニケーション能力なんて呼ばれて評価されるような人間の行動なんてのは以下の様などうでもいいことだろうと斜めに構えてしまう。
例えばある事象Aが起きて、それを部長に伝えなければならないとする。

—–

続きを読む

汎用的なマネジメントメソッド

先日勤め先でマネジメント研修なるものを受講する機会があった。講師はあるベストセラーの著者であり、今はその本に書いてある内容をコンサルタントすることを生業にしているようだが、以前はアメリカで起業し、その企業を売却するところまで持っていったことがあるそうな。
予想通りと言えば予想通りだし、当たり前と言えば当たり前のことだが、あの手の汎用的なマネジメントのメソッドなどというものは、あまりにも抽象化されすぎていて何の役にも立たないのではないかという感想を持った。「何も役に立たない」という意見が少し強すぎるのなら、「役に立つけれど、わざわざ言われるまでのことではない」という意見にしておく。

プログラマの権利宣言

  1. すべてのプログラマは2つのモニタを持つ権利を有する
  2. すべてのプログラマは高性能なPCを持つべきである
  3. すべてのプログラマはマウスとキーボードの選択の権利を有する
  4. すべてのプログラマは快適な椅子を持つべきである
  5. すべてのプログラマは高速なインターネット接続を持つべきである
  6. すべてのプログラマは静かなる仕事環境を持つべきである

プログラマの権利宣言

「OSやエディタなど開発時に利用するソフトウェアを自由に選ぶ権利」も欲しいが書いていない。もしかして、そんなのは当たり前のことなのだろうか。僕の職場では当たり前ではないのだが。

「静かなる仕事環境」っていうのはこの中で唯一コストがかからない内容だけど、一番手に入りづらいのではないかと思う。

会社は自分という商品の取引相手

「個と組織の関係や距離感」における「個の強さ」みたいなことを議論したい気がしている。またその観点で、具体的に何をしたらいいかという話に、だんだんにつなげられたらいいと思う。

「「個」として強く生きること」と「ウェブ・リテラシーを持つこと」の関係 – My Life Between Silicon Valley and Japan

「個と組織の関係や距離感」と言えば、僕が「アメリカ人と日本人の感覚って違うなあ」と感じたことのひとつがまさにその「距離感」。上手く言葉でまとめられないかもしれないが、一般的に言ってアメリカ人は会社を「取引相手」と見ている気がする。商品は自分。だから自分という商品の値段(つまり給料)の交渉もしっかりとする。一方日本では取引相手とはならず、自分がその主体の一部となる場合が多いように思う。つまり会社というのが自分を含む存在となる。
昔アメリカ人の友達の何気ない一言に驚いた。

—–

続きを読む

エンジニアが志向するべき問題解決方法

問題解決の方法には何通りもある。何通りもあるが、その方法の中で「エンジニアが志向すべき問題解決方法」が存在する。同じ様に「エンジニアがなるべく志向すべきではない問題解決方法」も存在する。エンジニアが志向すべき方法とは「技術による解決」である。
ひとつ例示してみよう。

—–

続きを読む

バグに対する態度

バグが発生すると「プログラマの意識が低い」という話になりがちである。特にコードを書かない人からこの話は出易い。しかし「バグを作りこもう」と思ってコードを書いているプログラマはいない。またバグを出すまいとして開発するスピードが遅くなるようであれば、それはもっと大きな問題になるだろう。そこにはトレードオフがあったはずである。
バグは無くならない。バグは必ず発生する。しかしバグを少なくすることは出来る。バグが発見し易いコードを書くことは出来る。バグがあっても修正し易いコードを書くことも出来る。そしてそれらはプログラマの意識などで実現されるものではなく、あくまでプログラマの知識や技能によるものである。プログラマはそれらの知識の吸収や技能の習得に対する意識は高くなければならない。

使われない自社パッケージ

耳が痛い話だ。

自社でパッケージ製品として開発しているグループウェアがあるが、
社内では自社のパッケージはあまり使われず、他社のパッケージが使われている。
理由は自社のパッケージが使いにくいから。

IT業界の大企業での生々しい話を5つほど : 小野和俊のブログ

情報共有やプロジェクト管理のパッケージを作っている企業であれば見に覚えのある話だろう。自社パッケージを差し置いて、社内の情報共有がWikiで行われているなんてのもきっとよくある話に違いない。ちなみに使われない理由として、自社パッケージが使いにくいという問題の前に導入があまりにも面倒だという事情もあったりする。

「技術に強いだけじゃ駄目」という言い回しはおかしい

随所で見たり聞いたりするけど「技術に強いだけじゃ駄目だよね」という言い方はおかしい。廃止すべきだ。なぜなら技術に強い時点で○だからである。「技術に強い上に何か他に長所があれば◎」というのが実際のところだと思うので「技術+αがあると素晴らしい」という言い方にすべき。少なくとも技術に疎い人間の使ってよい言い回しではない。
エンジニアはまず、技術的に精進すべき。