エンジニアの評価は“頑張りを見逃さない”ことが大事──マネージャー陣の哲学

私の場合は、これまで目標を低く出すメンバーはあまりいなかったのですが、逆に目標が高すぎて、「これでは、達成できないのでは？」と思うことがありました。

壮大な目標は、ムーンショットだと考えるようにしています。つまり、“月に向かってロケットを打ち上げる”ような大胆な目標や挑戦ということですね。こういう考え方が、世界を変えるイノベーションにつながるはずです。

私は内発的動機付けを大事にしていて、本人が「やりたい」と思った目標を書き換えさせることの方がネガティブだという考えです。具体的には、「半年後にここまでできたら合格」と決めて、達成具合を見てメンバーと話し合いながら判断をしています。

「報酬がいいから」とか「やらないと罰が与えられるから」といった外部からの動機付けで立てられた目標では、短期的にうまくいっても、そのモチベーションをずっと高く維持していくのは難しいと思うんです。

それよりも、自分の内側から湧き起こる「やりたい！」という強い動機に基づいて活動するほうが、自ら進んで仕事に取り組むことができ、成果にもつながりやすい。

だから、たとえ目標時点で「達成するのは難しそうだ」とマネージャー目線で感じたとしても、書き換えてもらうかどうかは、かなり慎重に考えます。

Productivityグループは、生産性向上がミッションのため、評価の基準も数字で判断することが多いです。なので、私は必ず、「自分がやりたいこと」と合わせて、数値目標を出してもらいます。

しかし、目標として数値を書くことが難しいと感じてしまうメンバーもいますし、当初想定していた目標が達成できないことも、往々にしてあると思うんです。業務上もっと重要なことが出てきたり、割り込み業務によってどうしても工数が足りなくなったり。目標が達成できない場合は、できなかった合理的な理由を書いてもらえれば、大きな問題はありません。目標設定ではメンバーが本当にやりたいと思っている事が可視化されていればそれでよいと考えています。

目標を立てる際、メンバーには「目標が達成できなくても必ずマイナスになるというわけではないし、そのほかにできたことがあればプラスになることも多くある。だから心配しないで」と毎回伝えているんです。それでもなお、目標を低く出すメンバーがいれば、「あなたならもっとできるでしょう」とメンバーの背中を押すようにしていますね。

インフラグループでは、「カオナビ」をいつでも使える状態にしておくことが仕事なので、それに対して評価しようとするとどうしても減点法になりがちです。また、オペレーショングループと同じように割り込み業務が多いので、最初に立てた目標と実際に残した成果が異なっていることも少なくありません。

そういった理由から、誤解を恐れずに言えば、インフラグループでは最初に立てた目標に対しての評価にあまり重きを置いていないんです。それよりも、その人が半年間で何をやってきたのかを見る。それが目標と全然違っていても、その人はその仕事をしてきたわけです。その人が何をどう考えて仕事をしてきたのかを一緒に言語化していくのがマネージャーとしての私の仕事です。

だから私は、その人が「やってきたこと」に対して、なぜそれをやったのか、どうしてそうしようと思ったのか、結果何が出来たのか、次はどうするのか等、その人の仕事の歴史が本人の納得感含めて可視化されていくようにしたいと思っています。

私も似た考えのもとに対応しています。メンバーとの対話の中で必要であれば目標を再検討していますね。

個人の評価というのは、目標の達成が1つの指標になりますが、目標だけにとらわれ過ぎてしまうと柔軟に動けなくなってしまいます。そうなるとチームのパフォーマンスにも影響が出てしまう。そういった事態を避けるためにも、「状況に応じて、目標設定を調整できる」という環境を用意するだけで、メンバーの心理的な負担が少なくなると私は思っています。

特に、SRE部側では、「何ができたか」「何ができなかったのか」といった目に見える成果だけで評価することが難しいんですよね。そのため、メンバーが半年間「どういった動きをしていたか、何を考えて仕事をしていたのか」を可視化することを重視しています。

そういう意味では、リモート環境の今、メンバーとのコミュニケーションの重要性をより強く感じていますね。

結局のところ、評価は上長とメンバーとのコミュニケーションによってすり合わせられるものですからね。1on1のような特別な場だけでなく、普段からメンバーとどのようなやりとりをするかを考えて、良好な関係性を築いておくことも大切ですよね。メンバーの仕事の状況はもちろんですが、パーソナルな部分を把握しておくことも大事にしています。

私は1on1ミーティングの時に、メンバーのやっていることを全部記録に残すようにしています。そして、評価のタイミングで2人で見直して、「この時、こんなことをやっていたね。これを評価に追記しておこう」と話して、プラスαで加点して評価をできるようにしています。

例えば、エンジニアメンバーがデザインのアイデアを出した場合、コラボレーションの範囲を広げた活動として評価できます。実際に取り入れられていなくてもいいんです。その意識自体が大事なので。

また、タスクに対して、やらなくていい方法を見つけた場合、タスクを消化したことにはなりませんが、作業しなくても成果が上がることを突き詰めたこと自体が大きな成果です。このように目に見える成果だけではなく、メンバー一人ひとりがやってきたことは見逃さないように心がけています。

私自身は、マネージャーになってからまだ間もないため、皆さんのお話を聞いて、気づかされることが多くあります。日頃からメンバーの細かい貢献を、意識して見ていこうと気が引き締まる思いです。

メンバーのことをよく観る、メンバーの話をよく聴く、というのを日頃からマネージャーとしての立場から広く意識していきたいな、と思います。

石川さんは特に効率化や業務改善に力を入れていたので、そこは引き続き重視していきます。また、「カオナビ」は新しい機能やサービスがこれから順次増えていきますので、オペレーショングループとしては、安全面にも考慮しながらスムーズな運用ができるようにオペレーション業務を行えるように心がけていきたいと思います。

社内には多くのエンジニアがいますが、インフラエンジニアの社員は圧倒的に少なくてレアキャラなんです。さらに、インフラグループでは、「カオナビ」がいつでも使えて当たり前を目指しているので、傍から見ればまるで“空気”のように、何もしていないかのように見えることが理想。普段はあまり存在感を出さないようにしているんですね。

一方で、インフラエンジニアのチームとしてはいい仕事をしたい。そのためにそれぞれの強みを発揮しながら楽しく仕事をしてほしい。だから、“何もしなくても、業務が回っていく時間”を増やし、空いた時間で新しいプロジェクトをガンガン立ち上げていきたいと思っています。かける時間に対する質を変えていくことが生産性向上に繋がるでしょうから。

インフラエンジニアとしては存在感がないことが一番ですが、逆に居るのか居ないのか分からないというのもまずいので、その意味で存在感がなくならないよう、自分たちから活動内容をもっと積極的に発信していきたいと思っています。私が考えているインフラグループの理想は「運用しない運用」、つまり、何もしなくてもうまく運用が回る仕組みを、先回りして高いレベルでエンジニアリングし続けることなので、こういう取り組みを社内外に発信していける文化を作っていきたいなと考えています。

Productivityグループとしては、今後、組織間の壁をなくして、情報連携や作業連携がスムーズにできる環境作りに取り組んでいきたいと思っています。というのも、業務上、他の部署とのやり取りが多いのですが、グループ内と比較するとやはりぎくしゃくしてしまうことが少なくないんです。

特に、他のグループのマネージャーに相談する際のハードルは高く、必要以上にお伺いを立てるモードになってしまう様子も見えます。そういった時間があること自体、あまり効率的ではないですよね。こうした組織間のコミュニケーションを円滑に進められる環境を作っていきたいですね。

理想は、その都度連携や作業依頼をしなくても、やりたい作業・使いたい機能が利用できる状態になっている「セルフサービス化」の実現ですが、ハードルは非常に高いです。

そのゴールに向けた第一歩として、まずは部門間で“連携し合う”ところから始め、開発環境やフローの最適化を行い、部門間連携の仕組み化を進めていきたいと考えています。

サービス開発部側のマネージャーの数をもっと増やしたいですね。以前と比べて、徐々にマネージャーの数が増えてきましたが、今も1人のマネージャーが、エンジニアからデザイナーまで全ての領域を見ないといけないため、多くの役割がマネージャーに集中している状態なんです。

その領域をもっと絞っていき、よりメンバーと向き合える時間を増やしていきたいですね。企業としてより大きく成長していくために、必要なことだと思います。

例えば現場でトラブルが起きた場合、まずはマネージャーが招集されるのですが、マネージャーが自ら手を動かしたり考えたりできることは限られており、現場のエンジニアでないと解決できないことが多いんです。エンジニアの裁量がもっと明確になれば、彼らも主体的に動きやすくなると思っています。

エンジニアに限らないと思いますが、「実際にグループ内で開発を遂行しているメンバーが担当した方がよりスムーズになる」場面も多いと感じています。だから、グループ内ではメンバーに渡せる役割はどんどん渡していくようにしています。

立場上は「組織の責任者」であるマネージャーが何でもやってしまうと、メンバーができるはずの仕事まで奪ってしまって、成長を妨げると思います。

一人ひとりの得意なことを活かしながら、チームで効率よく動ける仕組みをこれからも考えていきたいですね。

メンバーには、自分たちが開発に関わっている「カオナビ」をもっと好きになってもらいたいと思っているんです。実際に私たちも「カオナビ」をユーザーとして使っているのですが、ユーザー視点で「カオナビ」に触れることで、「こうしたらもっと使いやすいのでは」といったアイデアが生まれることがあります。

プロダクトの品質をさらに高めていくためにも、「カオナビ」というプロダクトに愛着を持ってメンバーが活躍できる、そんな環境作りを意識していきたいと思っています。