メルカリで働くソフトウェアエンジニアにちょこっとお話を聞いていく本シリーズ。第29回では、メルカリCSToolチームのBackendエンジニア@ichikawa_0829（@icchy）にちょこっとお話を聞きました。聞き手は、同じくBackendエンジニアの@naoprです。

カスタマーサービス業務効率化のためのCSツールを開発しているCSToolチーム。入社以来、CSツール開発を担当し続けている@icchyが語った、「社内向け」ならではの楽しさ、そして挑戦とは？

ちょっとヘッドフォンを外してもらっていいですか？

@naopr：@icchyさーん、ちょっとお話いいですか？

@naopr（メルカリBackendエンジニア）

@icchy：………………？

@icchy（メルカリBackendエンジニア）

@naopr：あの、ちょっとヘッドフォンを外してもらっていいですか？

@icchy：（ヘッドフォンを外して）はい、何ですか？

@naopr：入社時期を教えてください。

@icchy：はい。僕がメルカリに入社したのは2017年7月です。学生時代はバンドマンで成功する夢を見ていたのですが、仲間から「プロでやっていくモチベーションがない」と言われてしまいまして。慌てて就職活動をスタートし、入社したのがJavaを使ってサービス開発をする小さな会社でした。その後、アルバイト事業の行う会社に入社。開発チームのリーダー的な役割をしつつ、エンジニア採用や教育などをしていました。退職後はしばらくフリーランスのエンジニアとして働いていましたが、技術面での勉強不足が気になり始めて。

@naopr：一人だけで開発していると、そうなってしまいがちですよね。

@icchy：そうなんです。もっといろいろな技術を学びたくてカンファレンスに参加していたら、@kazeburoさんや@hirakuさんをはじめとしたメルカリエンジニアの登壇を見る機会があり、魅力を感じました。そして、現在に至ります。

@naopr：なぜメルカリだったんですか？

@icchy：もともとメルカリに対して、技術的なところでの興味があったんです。先ほども話したとおり、カンファレンスに登壇していた@kazeburoさんや@hirakuさんなど、僕から見てスーパーエンジニアが揃っていましたし。あと、採用会食のときに会社として実現しようとしている世界観を改めて知り、面白そうだと思ったんですよね。一方で「僕みたいなエンジニアは受からないかも」と思ったりしていましたけれど。

@naopr：その気持ち、わかる気がする（笑）。

CSツール開発の魅力は、技術的な挑戦ができること！

@naopr：入社してからは、ずっとCSToolチームに？

@icchy：入社当時からずっと、CSToolチームでCSメンバーが使うツール開発をしてきました。なかでも一番大変だったのが、KYC（Know Your Customer、本人確認）のためのAPI実装でしたね。当時もCSToolチームだったのですが、このときだけはFrontendからリクエストされるAPIを含めたBackend側すべての実装を行っていました。

@naopr：KYCは、お客さまを守るために重要なもの。各開発チームやCSメンバーはもちろん、外部のステークホルダーと連携するための調整も必要ですよね？

@icchy：そのとおりです。サービスの根幹に関わる部分なので、特にCSメンバーとオペレーション運営に関する確認などを密にやりとりしながら進めていました。また、KYCが制度として問題ないかどうかを、Frontendチームのほか、プロダクトマネージャーやリーガルなど幅広い範囲で連携して動くようにしていました。今は、ちょうどCSツールをモノリシックから、複数の小さなサービスを連携させて管理、運営を行うマイクロサービスに移行中なので、BackendとFrontendの両方をフルスクラッチで書き直しているところです。そして、メルカリではマイクロサービス化とともに、技術スタックをGoへ切り替えようとしています。僕にとって今回が初めてのGoなので、そのあたりもキャッチアップしながら開発を進めているんです。

@naopr：CSツールは、いわば社内向けにつくられているものです。場合によっては片手間な管理にされがちなところがあると思うのですけれど？

@icchy：アプリ開発がメインになると、よくあることですよね。そのため、会社によっては外部ツールを取り入れているところもあります。しかし、メルカリは創業当時からCSに注力してきたこともあり、中長期的にツールの内製と管理をしていくため、僕らCSToolチームが存在しています。それに、社内向けだからこそ、技術的にもいろいろなチャレンジができたりするんです。

@naopr：「GraphQLを使っていくぞ！」みたいな？

@icchy：ですです。もちろん、社内だからと言って技術選定や運営、管理を疎かにしていいわけではないですし、当然ながら慎重になるべきシーンはたくさんあるのですが。僕らが担当しているCSツールは、アプリやWeb側に負けないくらいさまざまなチャレンジができていると感じますし、社内で開発しているため方向転換をする場合も小回りが効きやすいと思っています。社内向けであれば「こうしたほうがより効率的になるはずだから、試してみていいですか？」とメンバー間で合意を得られればすぐに行動可能。それでもし良くなかった場合も、素早く次のアクションへの決断を下せます。何より、メルカリのCS組織はそれほど小さな規模ではありません。つまり、わりと大勢のメンバーが使うCSツールをつくれていることも魅力ですね。

@naopr：ある程度の規模があるサービスをつくっている感じなんですね。

@icchy：そうなんです。それに、CSツールはちょっとした動線を変えたりするだけで作業効率が大きく変わります。CSメンバーからのフィードバックもすぐにもらえるので、PDCAをスピーディーに回せるところもいいですね。あと、改善するたびにメルチップもたくさんもらえます！

半期ごとで各エンジニアがTLを担うCSToolチーム

@naopr：先ほど、前職でエンジニアの採用や育成をしていたと話していましたが、今は？

@icchy：いちエンジニアです。「CSToolチームのテックリード（TL）をやらないか？」と声をかけてもらったこともありますが、今のところは断っているんです。

@naopr：なぜ？

@icchy：CSToolチームでは今、マイクロサービス化への移行を進めているところ。僕自身、GCPやKubernetesなど、マイクロサービス関連の技術スタックをしっかりキャッチアップしておきたいんです。

@naopr：なるほど。

@icchy：あと、マネジメントを経験したくてシステム責任者をやっていたこともありますが、レポート的な業務が多く、開発する時間をとれなくなってしまった過去もあって。僕個人としてはまだまだ技術と向き合いたいので、しばらくはメンバーとして、CSツール開発を進めていくつもりです。

@naopr：僕は@icchyさんと同じCSToolチームにいますが、ここでは「TLの視座で仕事をできるメンバーを増やす」「TL業務を属人化させない」を目的に、TLを固定化せずに半期程度で交代しています。@icchyさんはエンジニアリングマネージャーよりTL？

@icchy：僕は技術にフォーカスしたポジションのほうが合っているし、価値を出せると感じています。今は、先ほどお話しした理由で断らせてもらってますけれど。TLじゃないとは言え、CSツールのマイクロサービス化を進めるうえで必要な技術スタックは、その都度チーム内で共有し、メンバーに還元できるようにしています。TLに関してはチームごとで定義が若干異なりますが、「視座が上がる」というのはそのとおりだと思うので、技術を追及する意味では、エンジニアとして一度やってみるのはいいですよね。

@naopr：ですね！

「どうやっていくか」を決められるエンジニアが合っている

@naopr：CSツール開発となると、どういったエンジニアが合っているんでしょうか？

@icchy：CSツールの面白さがわかる渋い系エンジニアかなと（笑）。

@naopr：渋い（笑）。

@icchy：いやでも、CSツール開発はけっこう楽しいんですよ。それに僕、CSツール開発のもう1つの面白さは「どうやっていくか」を自分たちで決められることだと思っているんです。例えば、CSメンバーへのヒアリングや実際の作業を見ることで、自分で非効率な部分を見つけて修正完了まで進められます。このあたりは、アプリ開発ではなかなかできないところでもあります。なので、「何をつくればいいですか？」と指示をあおがないと動けないタイプには向いていないかもしれないですね。

@naopr：自ら問題を発見し、改善できる人が合っている？

@icchy：ですね。あの、そろそろ仕事に戻っていいですか？

@naopr：はいどうぞ！