“従業員体験”を向上させることがプロダクトの成長につながる。コーポレートの仕組みを高度化する仕事の価値 #メルカリのイシューを分解する

私たちメルカリグループは「新たな価値を生みだす世界的なマーケットプレイスを創る」をミッションに掲げています。このミッション達成に向けて奮闘するメンバーたちをメルカンではフォーカスしてきました。しかし、私たちは現在、スタートアップから「グローバルテックカンパニー」へと変化する挑戦の真っ只中にいます。そして、そこには当然さまざまな「イシュー（課題）」が偏在しています。このイシューは“向き合うべき”ものであり、同時に“解きがい”のあるものでもあります。

そこでメルカンでは、メルカリの現在地と今後の展望を示すべく、あえて「イシュー」にフォーカスした連載「メルカリのイシューを分解する」をスタートさせました。第2回のテーマは「Employee Experience（従業員体験）」です！

メルカリには、メルカリグループで利用する社内向けシステム各種の立案、導入、構築、改善を行うCorporate Engineering Teamが存在します。同チームは「最高のProduct Experience実現のために、最高のEmployee Experienceを実現させる」ことを目指して活動していますが、必ずしもそれが実現できているわけではありません。

メルカリはこれまで非連続な成長を続けてきました。それは、プロダクトの成長の方が開発よりも早いという状態がずっと続いていたことを意味します。お客様の体験を向上させるためにプロダクトの成長に集中してきたため、プロダクト側に経営資源や開発リソースが集中し、コーポレートシステムの部分はやりきれていない部分が多々あったことは事実です。

今回、このCorporate Engineering Teamに焦点を当て、実際にどのようなイシューに向き合っているのか、そのイシューの先に何をみているのか、新井啓太（@cocoiti）、角尚美（@sumi703）、小泉剛（@ISSA）の3人の話から紐解いていきます。

情報システムからオフィス構築まで、幅広い領域をつなぐ

──まず、皆さんの簡単な経歴から教えてください。

@cocoiti：私はメルカリに入社する前は、バックエンドエンジニアとしてキャリアを積んできました。メルカリに入社したのは2014年12月ですので、今年で8年目になります。入社後も2年ほどはバックエンドエンジニアとして働いていたのですが、その後はエンジニアリングマネージャーも経験しました。メルペイの立ち上げに加えて、システムリスクに関する仕事も経験し、1年半前からCorporate Engineering Teamで働いています。

新井啓太（@cocoiti）

@sumi703：私は新卒から​​QA（Quality Assurance）エンジニアとしてキャリアを積んできました。メルカリに入社したのは2021年7月で、1年間はQAエンジニアとして働いていました。具体的にはテスト以外にも仕様の検討をするなど、エンジニアとして開発の上流工程に携わっていたという感じです。2022年7月からEM（Engineering Manager）になりました。

@ISSA：私は商品企画やエンジニアとして、法人向けのプロダクト開発に携わってきました。最初はエンジニアとしてグループウェアを開発し、その後は商品企画という立場で事業者向けのメンタルヘルスケアサービスに関わり、メルカリ入社前は経費精算、勤怠管理のバックオフィスプロダクトに関わっていました。そして2020年9月にプロダクトマネジャーとして入社し、2022年7月にCorporate IT Platformの所属になりました。

──Corporate Engineering Teamは、現在どのような組織体制となっているのでしょうか？

@cocoiti：この図を見てもらうと分かりやすいと思います。Corporate IT Platformの下にSystem EngineeringとAccounting Productがあり、その隣にIT Serviceがあります。IT ServiceとSystem Engineeringの役割は似ており、一般的な会社では「情報システム部門」と呼ばれる部署です。IT Serviceでは社内IT問い合わせなどのヘルプデスクを中心に運用し、System Engineeringはシステムの比較検討や導入、SaaS連携などをやっていきます。

Accounting Productは内製のCorporate Productの開発、運用、改善をやっていきます。具体的にはメルカリはエスクロー（第三者寄託）の仕組みがあり会計システムが複雑なため、会計システムの開発やCorporateの会計システムとの繋ぎ込みなどを担当している感じです。

People Productはチャットボットなどの人材関係ツールの開発や社内ナレッジシステムの運用などを、System Planningは全社のITシステムの可視化や戦略立案を担当しています。他社のCorporate Engineeringと比べてメルカリ独自だと思うのは、Workplaceという部署があることです。このチームはオフィスの構築やファシリティを担当しています。

もともと、Corporate Engineeringは階層化はせず、フラットな組織にしていたのですが、人数が増えてきたこともあり、階層化を進めています。

集約化は従業員体験を良くするための一つの道筋

──メルカリにおける、Employee Experienceの現状はどのように捉えていますか？

@ISSA：「最高のProduct Experience実現のために、最高のEmployee Experienceを実現させる」というチームとしてのミッションはあるのですが、ロードマップをもとに具体的な戦略を進めてこられたかというと、まだそこまで進められていないのが実情です。ミッションを達成するためには具体的に何をすべきなのか、1年後、2年後どうなっているかというロードマップを描き、形作っていく必要があると思います。

また、メルカリ自体がボトムアップの文化で育ってきたということもあり、各ファンクションが窓口を持って仕事をしているんです。そのため、新しく入社してきたメンバーがどこに何があって、誰に問い合わせればいいのかわからない。「情報の迷子」になってしまいがちなんです。

コロナ前のみんながオフィスで働いていた頃は、隣の人に聞くなどして何とかなっていたのですが、コロナ禍でリモートワークになってからはその手法が機能しなくなりました。

今後はServiceDeskなど問い合わせ先を一本化していくといったことに取り組んでいかなければ、と思っています。たとえば、Slackにあがってきた質問に対して、回答できるメンバーが素早く対応する文化はメルカリの良さではあるのですが、みんなの時間が細切れになって負荷がかかることに加え、なかなか集中して業務に取り組めないということになりがちです。こうしたことの効率化を進め、生産性を上げていくことが私たちの仕事だと思っているので、そこの課題を解決していきたいです。

小泉剛（@ISSA）

@sumi703：Accounting Productは基本的にはプロダクトの会計的な動きを集約し、経理の人たちが便利に使えるシステムを開発しています。そのため直接的に全社員が使うシステムの開発や運用をしているかと言われると難しい部分があります。ただ、経理メンバーの日常業務の生産性が向上していったり、マイクロサービスのメンバーがお金のことを気にせずに新しいサービスの開発ができるようにしたり、間接的に仕事に取り組みやすい状態をつくることに貢献できているのかな、と感じているところです。

その一方で、現時点はメルカリとメルペイで会計のシステムが違うなど、レガシーな部分が残ったままになっているので、そこの最適化は進めていきたいと思っています。

@cocoiti：もともとメルカリは急拡大・急成長してきた会社です。そのため、プロダクトの成長の方が開発よりも早いという状態がずっと続いていました。お客様の増加にあわせて必死にプロダクトを成長させていくことに集中していたので、プロダクト側に経営資源が集中し、コーポレートシステムなどはやりきれていない部分が多々ありました。

ただ、今はあらゆる業務システムを統合するため、ServiceNowの「App Engine」を全体最適化のプラットフォームとして採用したこともあり、バラバラの状態から統一化が進んでいる。また、従業員が社内の各種手続きに関する手順や規約を閲覧するためのポータルサイト「merportal（メルポータル）」などもあります。

集約化が従業員体験を良くするための一つの道筋ではありますが、ツールの導入に関しては「エンタープライズ＋グローバル」という軸での選別は難しく、導入しても使いにくかったりします。Corporate Engineeringではより使いやすいツールの提供に加え、最適化のための開発（既存で賄えないところは自社開発）もしていく必要があると思っています。

──いま、このタイミングでServiceNowを導入したことのメリットは何でしょうか？

@cocoiti：ServiceNowはプラットフォームですので、この基盤の上にさまざまなシステムを作っていこうと思っています。セキュリティでも申請やデータのやり取りのシステム、お金周りでもワークフローをつくっています。そういう意味では、ServiceNowがあらゆる業務システムの中核になってきている。ServiceNowがなければ、いろんなツールを比較検討し導入することになっていたと思います。ただ、ServiceNowによってひとつのツールに統一できる。またデータを1箇所に集めることで、それをどう活用するかも考えられます。

@ISSA：統一化することでUI/UXが1つになります。メルカリグループの全メンバーにとっては覚えることが少なくなり、業務を進める上での負荷が少なくなります。さまざまなツールを学習するのはコストがかかってしまう。体験を統一することで、従業員体験が向上していくと考えています。

また、ServiceNowのプラットフォーム性を生かし、作業の自動化が推進しやすくなります。IT Serviceの人たちは現在アカウントを手動で作成していますが、ServiceNowからアカウントの作成やソフトウェアライセンスの追加などの自動化をすすめることで、メンバーが作業時間を費やすのではなく、ITで解決したいことを考える時間を捻出できるようになるのではないか、と思います。

最初の課題に立ち返えるため、一つひとつのWhyを残していく

──先ほど社内開発をしている部分もあると仰っていますが、その部分はどのように社内のナレッジとして残していくのでしょうか？

@cocoiti：これは社内開発だけではなくSaaSの導入でも起こりやすい問題です。SaaS導入はわかりやすい成果になるので、やりたがる傾向にあるのですが、導入した後に「なぜ導入したのか？」ということになりがちです。

そのため、プロジェクトのレビュー体制、プロジェクトの始まったとき、終わった時で「何をすればいいのかを確認する」というルール決めをしてノウハウを蓄積していきたいと思っている。これはCorporate Engineering Teamだけではなく会社全体として進められたらと思います。

@sumi703：Accounting Productはこの1年間でチーム体制やメンバーがかなり変わりました。そのため、自チームのプロダクトの背景について詳しく知っているメンバーが少ないために「なぜこういう仕様になっているのか？」という課題が出てくることが多い。そのため、チームのカルチャーとしてドキュメントを残し、そのドキュメントには「なぜこうなっているのか」を明記するようにしています。後から来た人もわかるように目的と形を残すことは部門を超えて大切です。

角尚美（@sumi703）

@ISSA：自分は「Why（なぜ？）」がすごく重要だと思っています。一つひとつのWhyを残すことで解決したい課題に対してどのソリューションが最適かを突き止めやすい。物事は進めていく中で課題意識が薄れやすくなるからこそ、その都度振り返られることが大事。やっているうちにそれ自体が目的化してしまい、最初の課題に立ち返れないことがあります。

その点、メルカリは毎週All Handsが開催されており、そこで目的やどの課題の解決に向き合っているかを確認できます。これは、メルカリに組み込まれた重要な「行動デザイン」のひとつだと私は思っています。

──Corporate Engineeringチーム全体として、優先度の高い課題にどう向き合っていく予定ですか？

@cocoiti：優先すべき課題はセキュリティ・リスクに関わる部分です。事業拡大によって、さまざまなことをする中でより高いセキュリティ基準が求められていく。アカウントやIDの管理には注力していく必要がありますし、グローバル展開や新事業の立ち上げの中でお金周りの部分はより高度化していく必要があると思います。より大きな運用コストを払わなければいけない部分をシステム化していくことは早急にやるべきだと思っています。

その次に手が出しにくいところではありますが、情報の集約、ナレッジ、データ周りの整備をやっていきたいです。まずはナレッジに関する取り組みですかね。

@sumi703：そうした課題に間接的にアプローチする一つの手段としてD&Iの文脈がありますよね。

@cocoiti：そう、D&Iは進めたいことのひとつですね。やっぱり開発している側に多様性がなかったりするので、いかに使う側の目線に立てるかを重視していかなければいけない。いろんな目線が入って完成品を出さないと結局は「使いにくい」となり、作り直したり、新しいツールを入れたりしなければいけなくなる。物事が進んでいかないんです。

「作る→完成→使う→よかった！」という、良い循環を構築するためにもD&Iを追求していきたいです。いかにいろんな意見を取り入れられるかが大事になります。

──最後に、課題に立ち向かうことの醍醐味や、メルカリで働くことの意義を教えてください。

@sumi703：テストや品質保証などQAエンジニアの領域は速いスピードで変化が起きています。昔は手でやっていたのが自動化しており、それに加えてML（機械学習）応用してAIを使ってテストをしていくなどの発展もあります。学習を止めると自分がレガシーになってしまうのではないか、という危機感があるんです。

エンジニア個人としても、マネジメントする立場としても、王道にとらわれず世の中の動き、トレンドに沿って自分をバージョンアップさせていく。それが働くモチベーションになっています。またメルカリはマネジメントのプロもいるし、プレーヤーとしてのプロもいる、いろんな領域のプロがメルカリのミッション達成に向けてがんばっていこうという雰囲気がある。その中で自分が責任をもって進める領域において力を発揮していかなければ、と心から思えるのがメルカリの良さだと思います。

@cocoiti：私はメルカリというプロダクト自体が好きです。メルカリで売る人も買う人も得になり、メルカリも安心・安全を提供して収益を得られる。関係者全員が幸せになるシステムですので、それをもっと伸ばしていきたい、というのが働くモチベーションです。

また、メルカリが安心・安全を提供するためには、コーポレートの仕組みなどを高度化していく必要がある。例えば、お金の部分でも新しい決済手段が入ることで、お客様の体験を向上させられる。会社を良くすることが、結果的にプロダクトを良くしていくことになる。間接的ですが、プロダクトがよくなっていることに貢献できるのが醍醐味ですね。

@ISSA：私は「ユーザーの要望通りには作らない」ことを心がけています。ITの世界では要望を実現することだけになってしまっては良くないと思っています。

よい建築家は、お客に皿洗い機の場所について決してお客に相談しません。それはお客さんがどう思おうとシンクの隣です。皿洗い機をどこに置くか議論して時間を潰す意味はなく、それはシンクの隣に置く必要があり、それについては話題にすらしません。

システム開発でも同じです。システム開発の専門家として課題や「こうしたい」という思いを聞き、それをもとに思いもよらなかった解決策を出す必要があります。システムは業務を単に置き換えるものではなく、新しい革新的な業務を作っていくものだと思います。メルカリというサービスによって新しい生活が生まれたように、そういった体験をメルカリで働く人にも提供したいと思っています。