Team Geek読んでたら仕事辞めたくなった
Team Geekを読み終えた。
この本を読むのは何度目かで、読む度に失ったモチベーションを取り戻すことができて良い。
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
posted with amazlet at 16.07.11
感想
読む度に今のSIの自分の仕事が本当に意味のあることなのか疑問に思う。
今の仕事では如何に工数を付けるかが大事になっていて、そこにソフトウェアの価値によってお金を稼ごうというものは無い。そして、良いチームを作って結果を残そうという雰囲気もない。
例えばこの本の中では、「悪い組織」の例としてコード行数で生産性を計測する会社が出てくる。まさに自分が今働いている会社のことだ。コードは少ないほうが良いに決まっている。
SI案件でもユーザーのことを考えられないわけでは無いと思うけれど、それにしてはエンドユーザーへの距離が遠く実感を得るのは難しいように感じる。
本書では以下のように言われている
ソフトウェア開発はチームスポーツである
人月単位の自分の時間の切り売りではなく、個人の力でなく優れたチームワークによって開発したソフトウェア、サービスを通してユーザーに価値を届けるような刺激のある仕事をしたいものである。
参加するプロジェクトが頻繁に変わることで技術が身につかない問題
普段、仕事では.NetでC#を書いているのですが今月からJavaを書くプロジェクトに投入された。
このことで思うのは、もう少し扱う技術を固定したいということ。
エンタープライズなSIerであれば色々な現場に行ってそこで開発するようなこともあると思う。会社によると思うが私の場合、入社して約2年経つがおよそ3ヶ月単位でプロジェクトが変わっている。これは会社のやりかたや上司のリソース計画によるものだと思う。
しかし、3ヶ月ごとに扱う技術が変わって得られるものは何なんだろう。
色々な技術に触れることができるという面もあると思うが、それ以前にこれから力が伸びていくというフェーズになるとそれが断たれて次の現場に行くことになる。
すごいエンジニアなら3ヶ月もあればキャッチアップして開発もどんどん進めていけることもあるだろう。しかし、残念ながら私はそのような優れたエンジニアというわけでは無いのでブレークスルーが来るまでは時間がかかる。
私のように技術の取得に時間がかかるようなタイプは、なるべくひとつのプロジェクトに長く携わったほうがいいのではないだろうか。
最近では、このプロジェクトでJava頑張っても3ヶ月後には使わなくなるんだよな……なんてネガティブなことも思った。
愚痴っぽくなってしまったが、新入社員も入った季節なので上司となる人には今一度、足りないプロジェクトに人材投入するだけでなく部下の成長ロードマップを考えてみてアサインを決定してみてはどうでしょうか。
