「強いエンジニアリング組織をつくる vol.2」
～すべてのエンジニアが輝き続ける評価・育成を考える～

最近、我が国でも「個」としてグローバルで戦えるエンジニアが増えてきたように思います。しかし、これが束になって「組織」になると、必ずしも大きなパフォーマンスが発揮されているとは言い難い。

そこで、前回に引き続いて「強いエンジニアリング組織を作る」というテーマで、今回は「評価」と「育成」に絞って議論したいと思っています。まずは「評価」からおうかがいしたいのですが、お二方の会社では、いつ、誰が、どのように評価を行っていらっしゃるのですか。

私の会社は現在100名ほどの社員を抱えており、そのうちの約半数がエンジニアです。エンジニアの組織はそれぞれ5名ほどのチームで構成されていて、組織の目標管理にはOKRを用いています。3カ月ごとに会社の目標を各チームの目標に落とし、目的と成果要素を組織に反映。事業目標が組織図と連動して毎回リファクタリングしている感じです。

個人の評価は基本的にOKRに基づきますが、完全には連動していません。OKRにE（Expectation：期待）をつけた“OKR-E”というのを独自に設けていて、『OKRを実現するためにあなたにはこんな期待をしている』ということを年度の頭に私がメンバー全員と話し合って設定しています。そして期待通りに進んでいるのか毎月One-on-Oneで追いかけ、半期ごとに見直し、その達成度合いに応じて評価をしています。

いま藤川さんから“OKR（Objectives and Key Results）”というワードが出ましたが、これはもともとインテルから始まったもので、グーグルが採用して他のシリコンバレー企業にも広まった目標管理のフレームワークです。日本でもメルカリの導入例が有名ですね。このOKRが普通の目標管理手法と異なるのは、会社のトップからボトムまですべて紐付けられること。

特にスタートアップ企業は、みんなきちんと仕事しているのに、努力の方向がバラバラで束ねられていないことが多く、結果リソースを無駄遣いして潰れてしまう。それを回避するためにもOKRは有効で、ひとつの目標にすべての組織と個人を向かわせてエンパワーできるんですね。

OKRでエンパワーするには、絶えずOne-on-Oneでコミュニケーションをとらないといけないと思うんですね。お互いにすれ違ったまま半年過ぎてしまうと、致命的になりかねない。できればリアルタイムでトラックングするのが理想。

実は昨年まで私がエンジニア全員を見ていたのですが、組織が大きくなってさすがに厳しくなり、今年からマネージャーを3名立てました。一人がOne-on-Oneで評価できるメンバーの数は限られているので、マネージャーを育てないと組織はスケールしませんから。

井原さんが率いるビットジャーニーではいかがですか。

当社は正社員2名という小さな会社なので、特に決まった評価のシステムはありません。彼らへの評価はいわば毎日行われていて、一緒にプロジェクトをやっていれば能力や業績はおのずとわかる。会社への貢献が認められれば、そのたびに「年収50万円ぐらい上げようか」「ありがとうございます」という感じで（笑）。

普通の企業って、人事評価が決まるタイミングがだいたい決まっていますよね。たとえば年1回、期末の3月31日に上司と面談して査定されたり……でも、気がついたことがあるのなら、期末にフォードバックするんじゃなくて今日指摘してくれよと（笑）、私としてはそう思うんですね。

そもそも評価というのは何のために行うのでしょう？　こんな質問を受けたら、お二方はどうお答えになりますか。

現状を改善し、個人がより成長するために行うものだと思います。そのために腹を割ってお互いに話し合う。給料を上げる下げるという話ではなく、「これから君にこうあってほしいから投資をしたい」という考えを伝えるのが評価じゃないでしょうか。

そもそも私自身、評価というのは何が正解なのかわかっていませんし……個人的には、評価というのは「私はこう思う」「あなたはどう思う？」というお互いの考えを擦り合わせて、より良い解だと思えるものを見つけるための行動だと思っています。

なるほど。お二人の話をうかがうと評価というのは本人に気づきを与えることだと。ちなみに、マネージャー以外も評価側に組み込まれる「360度評価」についてはどう思われますか。

エンジニアのエンジニアに対する評価は概ね正しいかなと思いますね。参考情報としてマネージャーが知るのにはいいんじゃないかと。よく本人の評価と周囲の評価が違うこともあるんですよね。自分は全然凄くないと思っていても、周りから能力が認められていたり、そこに気づかせて「その能力をもっと伸ばしていこう」とモチベートするにも有効だと思います。

手間をかかるけれども、周りからの評価は参考になり、使う価値はあるということですね。ここで私の「評価」に対する考えを述べさせていただくと、その組織で必要なコンピテンシーを定義し、その達成度合いを給与ではなく職位に連動させるべきではないかと。

能力というのは発揮されない限り、組織にとっての価値はゼロ。これだけの成果を出せるだろうという期待値のもとに職位を決めて、能力に対するベースサラリーは将来に向けてのその人への投資だと捉え、それを用いて上げた成果は本来、ボーナスで報いるべきだと思いますね。

続いて「育成」のテーマに移りたいと思いますが、お二方はメンバーのエンジニアを成長させるために、どんな工夫をされていますか。

正直あまり意識していなくて、基本的にやる気のある人間を集めてきて、彼らの邪魔をしないというのが私のスタンスです。組織は大きくなると、できない人のためのルールを作りがちになりますよね。ボトム層がミスしないようにと下らないルールを作ると、トップ層のモチベーションが下がっていく。

だからルールというのは、できる人間のやる気をもっと引き出すために、トップラインに合わせて設けるべき。で、私はそもそもやる気のない人間にやる気を出させるのは無理だと思っていて、はなから意欲の高い人を採り、彼らがチャレンジし続けられる燃料を投入する。たとえば難しい問題だったり、社会的な課題だったり、彼らが心から解きたいと思えることを提示すれば、おのずと成長するんじゃないかと。

意欲の高いエンジニアでも、たとえばプロジェクトが頓挫してしまった時など、いろんな要因でモチベーションがダウンすることがあるかと思います。そんな時はどう対応されているのですか。

やる気が戻ってくるまで待ちます（笑）。まあ、できることと言えば、なるべく早く気持ちを取り戻してもらうために、解決すべき新たな問題を提示することぐらいでしょうか。

私もメンバーを育成した記憶はあまりないんですね。ただ留意しているのは、向いていないことを敢えてやらせるのはやめよう、ということ。その結果、サービスの改善が遅れたという経験もあるのですが、基本的には自分が向いていることに注力してもらうマネジメントをしています。

でも、エンジニアってやっぱり好奇心が旺盛なので、自分が向いていないと思ったことでも、他の人が手がけていると興味を持って、触発されて挑戦し始めることがあるんですね。私としてはそういう環境を作ろうと努めていますし、最近はそれがいい方向に作用してきて、これまで会社が抱えていた技術的な課題が一気に解決し始めている感覚があります。

「評価」と「育成」は、表裏一体のものではないかと私は捉えています。「評価」というのは、その組織において望まれるエンジニア像を基に、現状とのギャップを示すことだという考え方もできます。

そのギャップを埋めていくことが「育成」であり、それをどう埋めていくのかを自分で考えることももちろん大切ですが、埋め方をアドバイスしてサポートしていくこともマネージャーの役割ではないかと思います。その点について、お二方はどうお考えですか。

メンバーとはよく「あなたはエンジニアとしてどこに向かいたいのか」という話をします。漠然と「マネージャーになりたい」というメンバーがいて、まだその次元に達していないと思えば、One-on-Oneで「君はプロダクトの創り上げる力はあるんだから、これから自分の影響力を発揮して後輩を導く力をつけたらいいんじゃないの？」などというアドバイスはしますね。

メンバーがその気にならないとやらないようなことを、やんわりと諭すというか……そしてある日突然、そのメンバーが「このサービスをよくするためには自分が中心に立たなければ」と行動が変わり、そんな様子を目の当たりにするとうれしいですね。

私も「エンジニアはこうあるべきだ」という正しい姿があると思っていませんので、本人がこうなりたいというビジョンがあるのなら、一緒に実現していこうという姿勢です。

お二方ともエンジニアに自立自走を求めていらっしゃいますが、事業や組織が大きくなるとなかなか難しい部分もあるかと思います。その時の育成のヒントとして、たとえばまったく新しい技術を導入しなければならなくなった際、お二人はどうされますか。

いまならその技術はAIでしょうか。Webエンジニアにはまったく馴染みのない領域で、そもそも求められる資質が全然違う。ですから、新たにチームを立ち上げる時には、AIに通じていて、羅針盤となるリーダーを採用するほかないと思いますね。

AIは確かにそうですね。もっとソフトウェア寄りで新しいテクノロジーが出てきた時などは、どのように対処されていますか。

うちでもReactやGraphQLが出てきた時に「どうする？」という話になったのですが、やりたい人がいればやればいい、と。誰もやりたくないのなら、基本的にはそのテクノロジーを選択しない。どうしても必要ならば、できる人を探してくる。やりたくないことをやらせるのではなく、やりたいことを自分たちで創る。チャレンジしたい事業と、チャレンジしたい技術の重なる部分を見つけて、それをどうすれば実現できるか設計していくことが、マネージャーとしての私の役割だと思っています。