エンジニアマネジメントとプロダクトを分け、新たなエンジニア組織へ
――入社からCTOになられて約2年間、どのようにエンジニア組織が変わってきたのでしょうか。
入社した頃は、エンジニアリングマネージャーと呼ばれる職種がなく、プロジェクトベースでチームを作っていました。四半期ごとの目標に対してプロジェクトとプロダクトマネージャーが決まり、エンジニアがアサインされていました。そのため、プロジェクトのオーナーがエンジニアのマネジメントもする形で、その組み合わせが四半期ごとに変わっていたんですね。立ち上げの成長期であればそれもよかったのですが、人が増えて「テックカンパニー」を標榜し、エンジニアが成果を出せる組織を目指そうとすれば、各人の成長やキャリア形成も重要な課題となります。
当然ながら四半期ごとにマネージャーが変わるようではうまくいかないので、1年ほど前より、エンジニアリングマネージャーという役割を作って、エンジニアの評価や育成を担当するようになりました。プロダクトのチームと分けることでプロダクトオーナーはプロダクトに集中し、エンジニアリングマネージャーはエンジニアに集中できるような組織に変えたわけです。
プロダクトマネージャーはプロジェクトを成功させることに全身全霊を注いでいているのに、エンジニアのキャリアを見るとなると、責任範囲が広すぎる可能性があります。たとえば、あるエンジニアにとっては他のプロジェクトを経験させた方がキャリアとしては正しいと思われたとしても、プロジェクトを成功させるという責任があるため、判断が鈍るところがあります。そもそもエンジニアのキャリアを考える人は、エンジニアの経験がある、共感が持てる人が望ましいでしょう。それでマネジメントラインを設けて、マネージャーを置いたわけです。
――エンジニアリングマネージャーというのは、教育やキャリアを考える役割というわけですね。具体的にはどのような業務をなされているのでしょうか。
最大8人のエンジニアに対して1人のマネージャーがついています。このくらいが1人で見るのにちょうどいい人数なのではないかと。でも、1on1のミーティングをすると8人でも多いくらいですね。マネージャーと話せるのが1週間に1回位になりますから。
以前はプロジェクト単位でチームを構成していましたが、今はプロジェクトチームと、役割ごとにドメイン単位で分かれたチームがあります。最初は「バックエンドで数チーム」という感じでざっくりと分かれていましたが、より細かくドメインで分かれた方がよいのではないかという仮説のもと現在の組織になっています。クライアントサイドについては、Webはフロントエンドチームが担当し、モバイルはかつてiOSとAndroidが分かれていたのですが、今はモバイルチームという統合されたチームです。まだ過渡期なので、試行錯誤を繰り返しており、1か月後には変わっているかもしれません。
エンジニアリングマネージャーのミッションは、チームの成果を最大化することですね。採用も権限を持っていますし、メンバーの育成にキャリア形成、プロジェクトに必要な人材をアサインすること、トラブルがあれば介入・調整もします。成果を最大化するために何でもするのがエンジニアリングマネージャーの役割です。
プロジェクトが始まる前に、エンジニアリングマネージャーはプロダクトマネージャーとアサインディスカッションを行い、人選などの相談をします。この方法も最適かどうかはわからないので、まずは試しているところです。なお、プロダクト以外にも、テクニカルプロジェクトとしてリファクタリングなどもあるので、一人ひとりの技量やキャリアなどを考えながら、エンジニアリングマネージャーが仕事を振り分けていくことになります。これもまだまだ試運転中ですね。
マイクロサービス化と新しい組織づくりの連携
――組織をドラスティックに改革するにあたり、マイクロサービス化が大きな意味を持つと思われます。どのように導入し、展開していかれたのでしょうか。
実はマイクロサービス化については、必ずしも完全にコミットしているわけではなく、スケーラブルな組織のためにマイクロサービスが必須なのではないかという仮説のもと、本格的には2018年1月に取り組み始めたばかりです。
以前から「マイクロサービスを進めていこう」という話は出ていましたが、プロダクト開発を優先していたこともあって、しばらく停滞していたんです。しかし、そろそろ本腰をいれようということになり、VP of Engineeringの是澤、CPOの濱田とディスカッションしたところ、やはりマイクロサービス化を強く推進するべきという結論に至りました。そして、そのためには「コードフリーズ」という意思決定を行ったのです。
「コードフリーズ」というのは、その当時のモノリシックになっているコードベースの変更を禁止するというものです。凍結させることで、マイクロサービスでロジックを実装する強制力を持たせ、メンバーにマイクロサービス化について積極的に考えてもらうことが目的でした。ビジネスに影響をかけない方法を検証しながら、ロジックのマイクロサービス化を進めていったわけです。これを全社にむけて2018年の6月に宣言し、変更期限を2018年12月までとしました。
――大きく変えようとすると現場の反発も予想されます。それに対してはどのように対処されてきたのでしょうか。
100％対処できたどうかは自分ではわかりませんが、「する必要があるんですか」という議論は必ずでてくると思っていたので、それに対しては理解をしてもらえるよう真摯に伝えてきました。とはいえ、必ずしもマイクロサービスが正解とは限らないわけで、最終的には「現在は正しいと信じているので、進めていきたい」という説明をしてきました。決して技術的にはモノリシックが悪いのではない。ただ、組織としてこうなりたいから、マイクロサービスを選択するわけですからね。
幸いマイクロサービスを理解している人はわりとすぐに受け入れてもらえました。技術的には複雑性が増すというデメリットもあるのですが、それを凌駕するメリットがたくさんありますから。私自身は、前職（サイバーエージェント）でマイクロサービスを体験していて、その良さを実感していたのですが、だからこそ「やってみないとわからないという領域が多い」というのも知っていました。経験しないうちは複雑でめんどくさいというイメージが先行するので、懐疑的な人に対しては「まずやってみて判断しよう」と半ば押し切った感じですね。実際に自分が携わって「こういうことか」を感じてもらえるよう、できるだけマイクロサービスに関わる人を増やすようにしました。
現在は、新しい機能はマイクロサービスで開発しつつ、変更が多くてビジネス上重要な機能から移行を進めています。そのためにテックプロジェクトを立ち上げ、手順書の作成から実際の移行までを担当し、ようやく一部のコアな機能の移行が完了したところです。なかなか難しい部分もあり、ちょっと時間がかかりそうですが、本年中にはロジックの8割は移行させたいと考えています。
――エンジニア組織の改革とマイクロサービス化について、今後はどのように展開されていかれるのでしょうか。
目指す組織をつくる上で、重要性を感じつつあるのが「フェアな判断」です。発言権のある人が判断したから、仲間が多いから、アピールが上手いから、いずれもそれで判断されるようではダメでしょう。「誰が見ても正しい判断」をするのに、やはり数値化は必要だと思うので、早いうちにデータドリブンな意思決定ができるような状態にしたいですね。
データドリブン状態になったところで、何をもって良し悪しを決定するのか。そこにAIのようなデータをもって判断をするメカニズムが求められるのだと思います。たとえば、あらゆる行動がデータ化され、それを主観が混じらない状態で分析し、判断できれば理想的ですね。それはもちろん、最大公約数をとっていくというわけではありません。「シニア層によいけど若い人には刺さらない」というような分析結果が出たら、シニアに向けたサービスとして特化するという判断がなされるというイメージです。
好き嫌いや思い込み、もしくは保守的な感情などに邪魔されず、それぞれのお客さまにとって望ましいものを見極めた人が評価される。それが実現できれば、どんなにエンジニアが増えても、一人ひとりが力を発揮できる組織になるのではないかと考えています。
――メルカリは既に多くのエンジニアにとって憧れの存在のように思いますが、さらに評価やキャリアなど働く環境としての望ましさが加れば「グローバルテックカンパニー」の目標達成も近そうです。大変興味深いお話をありがとうございました。
