この記事は、Merpay Tech Openness Month 2020 の20日目の記事です。
こんにちは。メルペイのVP of Engineeringの木村（@hidek）です。
はじめに
メルペイでは VP of Engineering と Engineering Manager (EM)が HR と連携をしながら、エンジニア組織のピープルマネジメントにコミットしています。ピープルマネジメントとは、 採用 → 育成 → 評価 → リテンション → 外へのアウトプット → より良い採用… というサイクルを好循環させながら、組織全体に貢献することと定義しています。
その中で、今回リテンションという観点で EM 間で議論を行い、「ローテーションプログラム」というものを作ったので、その紹介をしたいと思います。
「チャレンジ」のプロセス化
メルペイもプロダクトがリリースされて１年半以上が経ちました。リリース前の開発期間を入れると2年半以上経っています。
その中でチームが固定化してしまって、Go Bold なチャレンジをする機会提供ができていない、結果として「飽き」を生んでしまっているという課題が EM 間でありました。
また、それらを解消させるために「チャレンジ」をする仕組みがプロセスとして存在しないため、EM がメンバーとの 1on1 などで、新たにチャレンジしたいことを吸い上げるなどをしていたのですが、やはり漏れてしまったことも多くあり、正直それらが原因で外へチャレンジの場を求めてしまったメンバーも少なからずいるという課題がありました。
今回はそれらを解決するために、メンバーのチャレンジを能動的に促す仕組みとして「ローテーションプログラム」を整理してプロセス化して社内に展開しました。
「ローテーションプログラム」は以下の3つに分類しています。
- ロールローテーション
- アサインローテーション
- スキルローテーション
ロールローテーション
これはわかりやすく、例えば Tech Lead (TL) から EM への役割変更などです。このローテーションに関してはすでにプロセス化されていました。
ちなみにメルカリ・メルペイでは EM は職位ではなく役割となっています。EM も役割であり、チャレンジして合わなかったり、またより現場にコミットしたくなったら、TL / IC (Individual Contributor) に戻れるという心理的安全性を担保してあげることにより、エンジニアの多くがマネージャーへのチャレンジに否定的になりがちな心理的ハードルを下げてチャレンジを促進するという利点があります。
TL や EM へのアサインは、それなりに適正等もあるので、本人の意思表示から EM に推薦してもらって、合議でアサインという仕組みを取っています。
アサインローテーション
役割もスキルも変えないでアサイン先を変えるローテーションです。例えばメルペイでは Backend は Micoreservices アーキテクチャを採用しているのですが、同じ人が同じドメインで開発していると、ドメインナレッジが蓄積されることによって新規開発、改善、運用においてこなれてスピードや品質が上がるメリットがあります。
一方で、組織的には属人化が進んでしまったり、アサインされている人も飽きてしまってモチベーションが下がってしまうこともあると思います。会社のフェーズで注力領域に人を寄せることもあるのですが、そうではなくボトムアップで新たなチャレンジができるようにすることが目的です。
プロセスとしては、まずはどのようなチームがあるのかを知って貰う必要があるので、EM が Team Description (TD) をポータルに記載して誰もがどのようなチームがどのようなミッションで存在するのか、メンバーを募集しているのか否かを透明化しています。ちなみに、この TD は細分化された組織の中で、横のチームが何をやっているのかを相互理解することにも役に立つと思っています。
その上で本人からの意思表明があったらプロセスに入ります。ただし、社内ジョブホッパーになってしまうことを防ぐために、直近で同じチームへの半年以上在籍が条件と、対象チームはチーム内で人が溢れてしまうことを防ぐために先のメンバーを募集しているチームのみになります。その上で、異動先の EM と面談をしてもらってマッチングを判断します。異動が決まった場合には異動元と異動先のEM間で1四半期を目処に引き継ぎを計画して調整をします。
スキルローテーション
サービスまたはプロダクトが肥大化すると、フルスタックエンジニアのように一人の人が多くの機能の開発をカバーすることは難しいですし、昨今の技術の複雑化を鑑みると各技術領域での深い知識が求められています。結果としてスキルの細分化が起きてしまう弊害が起こります。
その中で新たな技術領域にチャレンジしたいという要求に答えるために、スキルローテーションを設けました。例えば Backend エンジニアが iOS にチャレンジしたり、Frontend エンジニアが Backend にチャレンジする機会のプロセス化を行いました。
プロセスとしては、外部からの一般選考と同じになります。技術課題があるスキルに関しては技術課題を受けて貰う必要があります。
スキルローテーションで難しいのは評価だと思います。あるスキルのシニアエンジニアが新たなスキルにチャレンジするとギャップが生まれると思います。その結果評価が下がってしまっては「チャレンジ」を引き出せなくなってしまいます。
メルペイでは新たなスキルを身につけることは、その人のスキル面積が増えるという評価をすることにしました。一定期間は今までのスキル評価を尊重して評価することとしています。また、試用期間を設けて、マッチしなかったときには元のチームに戻れるセーフティーネットを用意することによって、チャレンジを促しています。
「ゆとり」と「チャレンジ」の重要性
このような施策は、メンバーのモチベーションを維持することができる一方で、新たな「チャレンジ」をする以上、全体としては一時的にスピードが落ちる可能性があります。
が、中長期的には「チャレンジ」を通じて、個人の成長を促すことができ、結果として組織としても成長できると信じています。故にこれからの課題は、この「チャレンジ」ができるように、いかに「ゆとり (Slack)」を作れるかということが組織課題になると思っています。
一方で、事業優先度を無視したり、過剰な人的余裕をもたせり、プロダクトや事業につながらないチャレンジをするのではなく、計画性を保った意味のある「チャレンジ」をするための適切な「ゆとり」を作り出すことを意識することが重要だと思います。
そのために、例えば省力化・自動化による時間の捻出、プロジェクトの標準化によるコミュニケーションの円滑化、などなどトライできることが沢山あると思っています。それらで生まれた時間を、意味のある「チャレンジ」ができる、意味のある「ゆとり」に投資できるチームでありたいと、改めて思っています。
社内でも CTO の @sowawa が最近改めて「ゆとり」の重要性を唱えていて、トム・デマルコの「ゆとりの法則」を紹介したところ社内でプチブームになりました。今回の話とは少し違う切り口なのですが、面白いので是非読んでみてください。
最後に
このような施策はもともと暗黙的に共有されていて、都度都度で対応していました。が、組織が大きくなるに従って、社内にこのような機会があることを知らずに、メンバーが外に目を向けてしまうことは残念に思っていました。
至極当たり前のことですが、暗黙知を整理し、可視化してナレッジシェアを進めることはリモートワークが一般的になった現在ではより重要なプロセスになっていると思います。全員の理解度を上げることが、様々な機会の活用・モチベーションの向上につながり、個人としてもチームとしても成長できる環境作りにつながるのではないでしょうか。是非試してみてください。
