あるエンジニアがあるプロジェクトにぜひ参画したいと思える条件は何か。ぼくの場合は「内容が適度にチャレンジングであること」が大きい気がする。簡単すぎるものでも、難しすぎるものでも、やる気が起きない。プロとしては恥ずべきことかもしれないが、人間、そんなものだとも思う。
とはいえ、やはりこれはぼくの怠慢でもある。簡単すぎるのは、自分がわりと知っている言語やOSやDBといった環境だからかもしれない。裁量範囲が広いのなら、書いたことのない言語で書いてみるとか、使ったことのないOSを使ってみるとか、難度を上げる方法は多々あるだろう。
逆に、難しすぎる場合でも、機能の一部だけなら実装できそうだとか、UI設計だけならできそうだとか、できる範囲のタスクを見つけ、何らかの貢献はできるはずだ。
プロジェクトへの参画に消極的な若手エンジニアに対しては、簡単そうだからなのか、難しそうだからなのか、聞いてみるとよさそうだ。答によっては、気持ちをほぐすことができるかもしれない。もちろん、難度以外の理由があれば、その対策を一緒に考えてあげることもできる。
技術者の求人が思うように進まない会社には、何かしら原因があるはずだ。身も蓋もない言い方だが、求人は恋愛に似ていて、自分がいくら好きになっても、相手から好かれなければ、カップルになれない。エンジニアに好かれる会社になれば、応募者は増えるだろう。求人すらしなくても、希望者が殺到するかもしれない。要は、選ぶ側でなく選ばれる側を目指すべし、ということだ。
エンジニアに好かれる会社の特長とは何か。これは難しく考える必要はなく、自分が転職するならこんな会社がよい、という判断基準を挙げれば済む。多くの場合、以下のようになるのではないか。
このような会社、チームを目指して、ぼくもできることから始めたい。
「エンジニアリングに集中できる」についてのみ考えると、エンジニア以外の人材の充実も、意外と重要だ。
「このところ気持ち悪い記事が続いているな」と思われる方がいらっしゃるかもしれませんが、このブログは自分用のメモなので、たぶん平気です。
自分を首に出来るように働く - プログラマになりたいを読み、共感したと同時に、そのような働き方が実践できていないことに気づいた。チームメンバーがみな忙しく、ぼくの業務を渡せるような状況にないのが主な理由だ。これは採用をがんばるしかない。
ただ、ぼくの業務のなかにはルーチンワークといえばいえるようなものがあり、自動化などによる改善の余地はまだまだある。小野和俊のブログ:人生のパフォーマンスチューニングにある通り、「ちょっとした工夫でも、呼び出し回数の多い処理は、その頻度に比例してパフォーマンスチューニングの効果を得やすい」。まずはそれを積み重ねていこう。
ENECHANGE株式会社VPoT兼CTO室マネージャー。AWS Community Builder (Cloud Operations)。前職はAWS Japan技術サポート。社内外を問わず開発者体験の向上に取り組んでいます
