この口コミが書かれたのは2019年春ですが、2017年当時の感想となっています。実はちょうどその頃、評価制度が改善されました。それまで当社では、エンジニアもほかの職種も同じ評価方法でした。そのため当時は、売り上げに直結するような成果が評価されると思われており、公平な評価基準が浸透していませんでした。

そこで、2017年頃にエンジニアの職能責任者（VP of Engineering）が中心になって「Band制度」を職種ごとにカスタマイズしました。これにより、「エンジニアがエンジニアを評価する体制」が構築され、職種に応じた評価が明確になったのです。

Band制度では、成長段階に応じて求められるミッション・基準などを9段階で定義。 スタッフクラスが4段階、プロフェッショナルクラスが5段階あり、それぞれの段階に合わせて評価をしていきます。 プロフェッショナルクラスのエンジニアは、自分の得意領域やこれから伸ばしたいスキルの方向性に合わせて、プロダクトやチームのマネジメントをしたり、1つの技術領域に対して全社をリードしたりする役割を定義することで、納得感のある評価が得られるようにしています。

評価は、上期、下期それぞれに最低3回の面談を経て決定されます。期初めに目標設定を行い、中間で目標の達成度を確認。期末に半年間の振り返りをします。

目標設定は、大きく分けて「成果目標」と「行動目標」の2つ。成果目標は、目標に対する到達度です。例えば、いつまでにこういうプロジェクトを開発してリリースする、会員登録数を20％アップするといったものです。行動目標は、リブセンスの従業員が大切にしているポリシーである、発想・協働・徹底の3つの軸に対し、それぞれどんな行動をとれたかというものです。この2つの目標の掛け合わせで評価していきます。

このBand制度に年齢は関係なく、入社何年目でどのクラスになるといった目安もありません。新卒2年目でも優秀な成果を出した人には、チームのリーダーを任せています。当社には、20代でリーダーを任されている人が非常に多いです。

これはエンジニアがエンジニアを評価する体制を構築していることから実現しています。売り上げに直接繋がらなくとも技術的に価値があるパターンや、時間がかかったものの非常に難易度の高い取り組みを実現したパターンなどにおいても、この制度であれば適切に評価できるのです。

この制度になってから2年が経ち、面談以外にもこまめに意思疎通を図っているため、自分の評価に納得がいかない、といった不満が出ることは少なくなっています。

当社には、新卒向けの新入社員研修などを除くと、社員に参加を強制させる研修はありません。そういう点では、「研修制度は整っていない」といえるかもしれません。

では、なぜ「整っている」という意見が多数あるのでしょうか。それはおそらく、自らが「やりたい」「勉強したい」と思ったことについて全力で応援する社風と、実現させるための制度が数多くあることから生まれているのだと思います。

私たちが求めるエンジニアは、自分たちで課題を見つけ、その課題を自ら解決していくことができる人です。例えば、オープンソースのWebアプリケーションフレームワークであるRuby on Railsを扱えるエンジニアが社内に増えてほしいとしても、会社が研修会を開いて参加させる形はとりません。「勉強したいので教材は何がいいか」と質問してくる人にリードエンジニアが答え、こういうプロジェクトをやってみたらどうかと実践の場を与えます。

そのほか、自主的な勉強会のサポート、書籍購入やセミナー参加への補助はもちろんのこと、社外の優秀なエンジニアとの交流が図れる国内外のカンファレンスなどへの参加もバックアップしています。

エンジニアのキャリア開発についても2年ほど前から改革に着手。現在、Band制度のプロフェッショナル層に対し、4つのキャリアモデルを用意して、なりたいエンジニア像を考える参考にしてもらっています。

1つは、自社メディアのユーザーやクライアントのために、どのようなシステムがあればいいかを自分たちで考え解決していく「プロダクト・エンジニア」。

次に2～3年で陳腐化していく技術に対し、今後どのような計画でシステムを更新していくかを考え、周囲を引っ張っていく「テック・リード」。そして、言語や技術において社外から見ても権威となりえる知識と技術をもった「スペシャリスト」。

最後に、エンジニアが所属する組織の改善や、エンジニアの悩みを解決に導いて成長を助ける「エンジニアリング・マネージャ」です。

もちろん、この4つのどれか1つを選ばなければいけないわけではなく、「テック・リード」と「エンジニアリング・マネージャ」が半々になってもいいですし、半年ごとの目標設定時に変更しても構いません。その時々で、自分のキャリアパスを柔軟に描ける体制があります。

当社では、エンジニア職とその他ビジネス職の従業員が、1つのチームで仕事をしています。仕事を進めるためにチームワークは必要なので、自分だけがまったく異なる勤務時間帯を毎日続けるのは難しいかもしれません。しかし、他の職種やチームメンバーらとの予定を全うしている限り、自らの裁量で設定できる旨を明確にうたっています。

実際に、子供2人を保育園に預けているエンジニアは、登園させてから11時に出社していますし、子供の寝かしつけをしている人は、18時には退社しています。

仕事に合わせて生活をするのではなく、自分たちの生活の一部に仕事を組み入れるという考え方をする人が多く、チーム内で自分の働き方をオープンにすることで、周囲もその人に合わせやすくなります。例えば、会議は全員がいる午後イチの時間帯に開始するなど。参加できないメンバーのいる10時や19時スタートの会議を設定することはほとんどありません。

私自身、中途入社のため他社も経験していますが、当社は時代に合わせて敏感に制度をアレンジしていると感じています。他社が導入しているような良い制度は、どんどん取り入れようとする姿勢が見えます。

実は、導入された制度の多くが社員の発案によるもの。社員自らが「こんな制度がうちにもあったらモチベーションが上がるよね」と思える制度を提案し、導入されてきました。自分たちで会社を変えていこうというマインドを持っている人にとっては、居心地の良い会社だと思います。

私たちは、入社を希望してくださる方々と、ありのままの状態でお会いし、その方らしい意見をお聞きしたいと思っています。私たちが面接時に大切にしている2つのことをお伝えします。

1つは、技術を楽しむモチベーションがあること。「Ruby on Railsって楽しいよね」「データベースのチューニングってクールだよね」と仕事を楽しめる方は、難しいプロジェクトにアサインされても成果を出していると感じています。それが新しい技術である必要はなく、レガシーなシステムであっても過去の仕事を楽しそうに話される方とは一緒に仕事をしてみたいと私は思います。

もう1つは、自主性と課題発見能力があることです。当社は今、さらなる飛躍のフェーズにいます。そのなかで必要なのは、お客様の課題を考え、自分たちがお客様に対してどういうサービスを提供できるかを具現化し、仕事を進めていける力です。言われたことに対し、120％の力を発揮できることはとても優秀ですが、それだけではそのうちに仕事がつまらなくなり、いずれパフォーマンスが低下してしまうのではないかと危惧しています。

そのため面接では、社会人として、エンジニアとして過去に一番成果が出たものは何か。どのような取り組みをしたのか。さらに、なぜ成果が出たと思うのかをお聞きしたいですね。今後なりたいエンジニア像を聞くよりも、過去に実績を上げてこられた方が、今後当社とどう関わっていけるかを見させていただきたいと思っています。

面接は、出会いの場です。ご縁があって一緒に働いていただけたら一番ですが、そうでなかったとしても、数年後に別の形で共に仕事をさせていただくことがあるかもしれません。一期一会ではなく、エンジニアの知り合いを増やしたい。そんな気分で来ていただきたいので、服装もスーツではなく私服で構いません。多くの方とお話をさせていただきたいです。