創業期を経て拡大期を迎えるスタートアップでは、大規模な組織体制の見直しによって混乱が起こることがある。

そんな急拡大期ならではの悩みを、エンジニアリングの力で解決するのがメルカリだ。１年で200人以上の技術者を採用した同社では、社内組織用のシステム開発に、社内トップクラスのエンジニアを約20名配置したという。

2020年に「エンジニア1000人体制」を目指すというメルカリが、‟組織改革”に技術でどう向き合っていくのか。『Mercari Tech Conf 2018』でCorporate Solutions Engineering マネージャーの柄沢 聡太郎さんが話した内容を一部紹介しよう。

３年でエンジニアが300人増！
急拡大する組織を支えた“一人部署”

私がメルカリにジョインした2015年当時は、エンジニアはまだ20人くらいの小さな組織でした。そこから2017年11月時点でで社員数は1000人近くになり、今ではエンジニアだけで約350人に。プロダクトの成長と共に、コーポレートの規模もものすごいスピードで大きくなってきています。

急速に人が増えていく中で、COOの小泉（文明氏）と話をしたところ、急拡大のひずみが組織に如実に現れていると。さまざまなところで最適化や効率化が必要であることが分かってきました。

そこで、私はこれまで『メルカリ』を中心としたプロダクト開発で培ってきたさまざまな知見や改善のプロセスを、コーポレートにも応用しようとCorporate Engineering（コーポレートソリューションエンジニアリング）というチームを発足させたのです。

立ち上げたのは2017年11月。当初は私一人だけのチームでした。自社プロダクトを持つ事業会社がなぜ、コーポレートのためにエンジニアリング部署をつくり、社内の課題を解決する必要があるのか――それは、急拡大によって起こる組織・人事体制の変化に素早く対応するため、そして人材を大切にすることで、これから先もより一層スケールしていくためでした。

優秀なメンバーは青天井で評価したい。
独自の人事評価制度をシステムで支えた

こうしてたった一人で始めたチームですが、翌2018年１月にはさらに２人のエンジニアを迎え、２月には、人事評価ツール『Reviews』という初めてのプロダクトのMVP（ミニマム・バリアブル・プロダクト：プロジェクトの初期段階でローンチする最小だが価値のあるプロダクト）をローンチすることができました。

そこから半年以上経った今は、人事評価、会計、コーポレートサイト、社内コミュニケーションツールという４領域で、メルカリの組織課題を約20人のメンバーが支えています。

中でも最も大きいのが、人事評価に関するプロダクトをつくる『People Products』というチームです。このチームでは、社内の評価イベントを回す人事評価ツール『Reviews』と、社員とチームの情報が全て詰まったデータベース『Teams』を開発しています。

『Reviews』でできることは、OKR（目標）の設定や、自己評価を行う『Performance Review』、『Peer Review』と呼ばれる360度評価、マネジャー同士の目線合わせを行う『Calibration』、本人への『Feedback』。一連の人事評価サイクルをこのシステムの中で完結させ、それらは全て社員データベース『Teams』と連携しています。

なぜここまで徹底して自社ツールをつくったかというと、理由はメルカリ独自の‟少し特殊な評価制度”にあります。一般的には、S評価、A評価など、成果に伴うレートと昇給を紐づける企業が多いと思いますが、当社ではそういう方式を取っていません。

それは活躍しているメンバーを、社内のグレードやレーティングにしばられることなくダイナミックに評価したいから。本当はもっと昇給できるはずのメンバーを、適性に評価できなくなってしまうのは避けたいと考えています。

変化の激しい「課題」の解決に、都度対応できる社内システムが必要だった

こう聞くと、「既存の人事評価システムや社員データベースなどのソフトウェアを導入すれば良いのでは？」と思う人もいるでしょう。確かに、10～100人規模までは、既存のツールを駆使することで問題は解決できたかもしれません。

実際、私たちも、過去にはスプレッドシートや他社製のSaaSで人事評価をしていたこともありました。しかし人事評価の部分は、経営の意思がもっとも強く反映される場所。人事制度も、その意思を反映して変化を続けています。そうした変化に合わせてその都度、適したツールを選定して、導入してというプロセスを踏んでいたら、本当にやりたいことができなくなってしまいます。これからより人材に投資し、クイックに適切な手を打っていくために、メルカリにはオリジナルの人事評価プロダクトが必要でした。

会社の抱える本質的な課題にフォーカスして、それをいかに早く見つけ、解決するのか。そこに対応していくために自社プロダクトとは別にコーポレート専属のエンジニアリング組織を持つことが、大きな価値を発揮できると考えたのです。

社内用のプロダクト開発者が気を付けたい
「便利屋になるな」「既存のツールをすぐに放棄するな」

これはやってみて分かったことですが、コーポ－レートの課題を解決するエンジニアリング組織を立ち上げるときには、陥りがちな落とし穴があります。

まずは、社内のシステムを扱うエンジニアは、便利屋さんになりがちだということ。これまでエンジニアリングの入っていなかった領域にエンジニアリングチームが入ると、あれも自動化したい、これも効率化したいという要望が無限に寄せられてきます。それ自体は悪いことではありませんが、全ての事柄に対して「How」から入ると、それが本当に本質的な課題かどうか見失ってしまいがちです。何でもかんでも御用聞きになるのではなく、そこをまず「課題は一体何なのか」をしっかり見極めるべきだと思います。

もう一つは、先ほどの話とは矛盾するかも知れませんが、「既存のツールは使い倒したのか？」ということです。世の中には、多くの人が知恵と叡智を結集させたさまざまなツールがあります。それを、ほんのちょっと使い勝手が悪いだけで、「自分たちで開発しよう」と考えるのは甘いかもしれません。

新しいプロダクトを開発することよりも、それを社内の業務フローに組み込んで運用することのほうがよほど難しいからです。本当に、今直面している課題を解決しているのか、さらに、変化し続けていく要件に今後も対応していけるのか。自分たちで改善のプロセスをつくっていかねばなりません。

今後CSEチームは、メルカリの経営課題にフォーカスしながら、このような知見や取り組み、ツールを広くみなさんと共有していきたいと思っています。良いプロダクトをメルカリの中だけに留めていてはもったいない。公開して、似たような悩みを抱える企業の役に立ちたいと思っています。そして業界における新しいエンジニアリング組織のあり方を定義していきたいですね。

取材・文／石川香苗子