<-- mermaid -->

エンジニア従業員エンゲージメント向上への道

はじめに

こんにちは!NewsPicksのVP Of Mobile Engineeringの石井です。
約1年前にPharmaXさん主催の「事例で学ぶ!エンジニア組織文化を作る採用・評価の仕組み」というイベントでPharmaX 取締役・エンジニアリング責任者の上野さん、カオナビCTOの松下さんと私の3人で事例発表やパネルディスカッションをしました。(そのときの記事は、PharmaXさんのこちらの記事にあります)

このときに私が話したエンゲージメントに関することは、「採用とオンボーディングを頑張った結果、エンゲージメントもよくなりました」的な話もしました。
ただ、それ以外にも多くのことをしています。今回はそこを深掘りしたいと思います。

以前の状態との比較

当時、発表した時のモバイルチームのエンゲージメントは次の通りでした。(NewsPicksでは半期に一度、サーベイをしています)

で、2024年度は、次の通りです。

見方は、縦列が人で横がサーベイの分類です。濃い赤の部分が評価が低い部分で、濃い青の部分が評価が高い部分です。

2022年度は、真っ赤でしたが、2023年度は、青く改善されており、2024年度は引き続き悪くなさそうです。

何をしたのか

先に結論を書くと、「これをしたからエンゲージメントが上がりました〜」などの相関関係はわかってません。
ただし、さまざまな改善をし続けていることが大事なんだと思います。という前提で羅列します。(最初の4つはイベントでも話した内容です)

採用時に組織文化や評価される観点をしっかりと説明して、完全に理解・納得をして入社して貰うこと

これは、もっとも基本的なことですね。
イベントでも話しましたが、これをしない / 足りないと「採用された側が不幸になる」という点が問題です。
NewsPicksの組織に合う人が優秀というわけでは、もちろんありません。人はそれぞれ個性があり、活躍できる土壌が違います。
その人が自社の組織で将来活躍できるか、本人が思ったように評価されるか、などをお互いが心底、齟齬ない状態で入社して貰うことは大事です。

ちなみにNewsPicks(ユーザベースも)は、「7つのバリュー」とそれを詳細に落とし込んだ「34の約束」(31からアップデートされてます)というものがあります。
組織文化として、非常に大事にしているものです。また、評価にも大きく影響をする事柄です。
それぞれの組織でも同じように明文化されたあるべき姿があるのではないでしょうか。
なければ、まずはそこから作成した方がいいと個人的には思います。

採用プロセスで必ずプログラムを書いて貰う

これも技術者採用としては当たり前ですね。

書いたプログラムで技術を判断するのは当たり前なのですが、1つだけ、世の中であまり語られてない重要なことがあります。
それは採用した側としてのオンボーディング時の心理です。「あのプログラムを書いた人だから、絶対にできる」という信頼感を寄せることができるのが非常に大事です。
たとえ、オンボーディング時に想定通りのパフォーマンスが出ていなくとも、「時間が経てば必ず活躍する人」と思えることです。(なので簡単な課題だとあまり効果がないかもしれません)
これがあるのとないのでは、担当者の気持ちは全然違うと思います。

評価のフェアネスも基本中の基本

「あの人が評価されてるのに、なんで自分が・・・」と不満を募らせていくことはよくあることではないでしょうか?
評価基準のオープン化と評価そのもののオープン化、そして、その実行は大事です。
NewsPicksでは、明確な評価基準があり、360度フィードバックで多角的に評価します。
明確な分、しっかりと納得感を持って貰うためにたくさんのコミュニケーションが必要です。
人間がやることなので、完璧に評価できるわけではありませんが、フェアであろうとする姿勢は大事です。

1on1のスキルを身につける

世の中的に1on1のスキルとして口酸っぱく言われている「傾聴」ですね。それ以前に意識の問題もあります。
私はいまも得意とは思ってませんが、2022年ぐらいの頃は、スキルも低いし意識も低くて、月1もやらないことがあったりしていました。 その状態でしたが、方法を勉強し、当時に比べると1on1によって問題解決へ向かうことが増えたと思います。
最近では、ほとんど不満らしい不満も聞かなくなり、チームとしてもいい状態になっていることを感じています。
相手が現状に不満がなくても将来、出てくることはあります。そのため、信頼関係を築いていき、しっかりと成長支援ができるように1on1のスキルを磨くのが良いと思います。

ちなみにNewsPicksのサービス内でも、1on1の仕方を掲載している(有料)のでよければみてください。検索すると他にもたくさん出てきます。

実践!仕事術 | 【保存版】チームが劇的に伸びる「フィードバック」の鉄則

開発者体験の向上をし続ける

どんなに組織文化や評価方式が良くても以下の状態だったら、エンジニアとしてストレスが溜まりますよね。

  • コードが負債だらけ(少し触ると簡単にデグレ発生)で、負債解消する時間が取れない
  • 新しい技術を試せない
  • ビルド時間が長い
  • リリース前の手動でのテストが多いなど、とにかく面倒なことが多い

NewsPicksモバイルチームでは、稼働の2割を開発者体験向上のための時間に使っています。

過去からある負債は当然、どんどん修正していくし、新しく作った箇所も将来の負債になりそうなところは早めに潰す運用をしています。
ポイントは、気づいたらすぐにタスク化することです。
毎週のスプリント計画時にどの負債を先に解消すべきかを決めて、着実に負債を返済しています。

新しい技術の採用は、上でリンクを貼った7つのバリューにある「迷ったら挑戦する道を選ぶ」「自由主義」に則って、チームとしての責任のもと採用しております。
iOSではTCA、AndroidではComposeを使うなど進めております。
特にTCAは、業界でも先駆者としての自負もあり、アピール下手な割には技術力の高さが世の中に漏れ出しているのではないでしょうか。
TCAの記事は弊社メンバーがたくさん記事やブログに書いているのでぜひ見てください。

tech.uzabase.com

その他、面倒ごとはどんどん自動化によって解消をしています。

さまざまな施策をすることで、生産性がどんどん上がっています。
開発者体験の向上は、間違いなくエンジニアの従業員エンゲージメントに直結しているはずです。
以下は過去の記事です。

tech.uzabase.com

tech.uzabase.com

外部品質を上げる

エンジニアとして、自分が作っているアプリがバグだらけでクラッシュを繰り返していたらどうでしょう。
これも放置され続けていたら、モチベーションが下がるのではないでしょうか?

NewsPicksでは、2割をバグ解消や問い合わせ対応に使っています。
また、1 ~ 2ヶ月に1度、優先度をあげてバグ解消するスプリントを作っています。
バグ解消スプリントでは、優先度が高いプロジェクトがあってもそのときばかりは、バグ解消を優先しています。そうしないとバグ解消が進まなかったためにそうしています。

結果、数えきれないほどあったバグチケット(余裕で100以上)が、Androidの場合は両手で数えられるほど減っています(どうしても根本対応しないといけないもの以外です)。
根本対応しないと直せない大きな負債がある箇所も計画を立てて、何ヶ月か先になりますが解消に向けて実装しています。

もちろん認識できていないバグも存在し、ユーザに迷惑をかけているはずですが、それでもユーザからの指摘や問い合わせが減っているのは目に見えてわかるのは、エンゲージメントにも影響しているはずです。

Goolge Playの評価もめちゃくちゃ上がっているのは、外部品質を上げた結果も影響しているのではないかと思います。

tech.uzabase.com

サービスの成長にコミットする

開発環境が良く品質もよいとしても、成長してないサービスだとやはり微妙です。ニュースピックスの場合はサービス開始して10年過ぎています。
10年もののサービスの場合は、当初のように急激な成長はなく、常に横ばいのサービスもあるのではないでしょうか?

NewsPicksでは、サービスを成長させるために様々な施策を行っています。
モバイルチームの場合は、稼働の6割は施策のために使っています。

施策をする際は、ユーザの行動を理解するためにABテストをたくさん行っています。

tech.uzabase.com

ちなみに色々な施策をすることで、少しづつユーザアクティビティが増えております。
以下は、今年度のモバイルのユーザアクティビティの推移です。少しづつ伸びているのがわかると思います。
左がiOSで右がAndroidです。iOSは微増に見えますが、ユーザ数が多く単位も違うので、それなりに増えています。
この数値が一時的なものかはわかりませんが、よい傾向に見えます。
ただ、一番、大事なのは施策の結果が数字で出せることです。施策の結果がたとえ悪くてもユーザ理解が増えることで、先に進んでいる実感があります。
それらの理解の積み重ねの先に数値が向上するのだと思います。

見積もり精度の向上にコミットする

サービスの成長にコミットするということは残業が多くなり、疲弊していくように思えるかもしれません。それもエンゲージメントに関係するでしょう。
2022年度ごろは確かにそういう状態でした。
しかし、上記でも述べたように生産性を向上させ、同じ時間でできることが格段増えました。
それでも残業が増えることがあるとすれば、それは見積もり精度が低いということです。
目標のリリース日に関しては、PdMやBizサイドや他エンジニアチームとの信頼関係で仕事をしているし、不確実性を許容しているのでリリース日を変更することはよくあります。
しかし、毎回リリース日が遅れたり、もしくは、逆に見積もりにバッファが多く積まれていることがわかると信頼関係が崩れていきます。
そうならないために、見積もり精度の向上を意識するようにしています。
具体的な例としては、フィーチャーバッファを使ったり、不確実性の高いタスクを早めに解決することで、最初にスケジュールを精緻に決めていく手法を取ったりしています。
いずれも、見積もり精度が向上すると全ての関係者がハッピーになるので、これも大事です。
機会があれば、こちらの話もどこかでしたいと思います。

おわりに

ここまで読んで頂いた方は気付いていると思います。「従業員エンゲージメントを高めるには、めちゃくちゃ時間かかるじゃん」ということです。
その通りなのです。やることは多いし、これをやれば上がるというものではなく、問題ごとを着実に解決していくしかないのです。
NewsPicksモバイルチームの2022年度の散々な結果から、2年かけて行なっていたことはサーベイ結果を見る限りエンゲージメントに効果があったと言えるでしょう。
この記事が、エンジニアの従業員エンゲージメントが低いと感じている人々に参考になれば幸いです。

Page top