メルカリを退職し、個人でWebアプリを作りました

メルカリでやっていたこと

自分がメルカリに入社したのは2017年12月で、SET(Software Engineer in Test)というポジションに応募して採用されました。 SETはその名の通りテストに対する課題を解決するための役割なのですが、当時のSETチームはテストの実装を行うわけではなく、開発環境や検証環境の運用やCI/CDツールの導入・サポートなどを主な役割としていました。

自分がSETとして応募したのは、前職までの経験で機能開発にやや飽きており、エンジニアとして品質の改善をテーマとして扱っていきたいと考えていたためでした。通常の機能開発ではプロジェクトの要件や期日に沿って開発することが求められますが、SETの業務には要件や期日はなく、何をいつどのように解決するかを自分で判断する必要がありました。チームメンバーやプロジェクトメンバーと話し合い、コードを見ながら現在の開発・運用状況を把握し、アプローチを提案して大まかな合意が取れれば実装し、詳細はPull Request中で議論するというような流れでした。

また、全社的な開発環境を運用しているため、社内のメンバーから開発環境に関するトラブルの報告があれば、そのメンバーと連絡を取ってトラブルシューティングや対策を行っていました。SETが行った設定変更等に原因があれば申し訳ないと感じるのですが、トラブルが解消するとメンバーからは感謝の言葉を述べられることが多く、若干複雑な気持ちになりつつも、積極的に感謝の言葉を言い合う文化なんだなあと感銘を受けていました。

しかし、入社して半年を過ぎたころにSETは独立した組織として解散する方針となり、自分はFrontendチーム所属となりました。同じタイミングでメルカリWeb版のre-architectureプロジェクトが開始しており、これに合わせてインフラもマイクロサービス化していく方針となりました。この時は想像していなかったのですが、このときに始まったマイクロサービス化が完了するまで4年かかり、その詳細は メルカリのエンジニアブログに記述しています。興味がある方はそちらを参照ください。

Web re-architectureプロジェクトでは、インフラ構築を主として担当しました。マイクロサービス化するにあたって、サービスの開発チームが運用も行っていくという方針を立てたため、SETでやっていたようなCI/CDの設定や開発環境の構築に加えて、本番環境のインフラ構築や運用ツールの設定、運用フローの構築なども行いました。会社としてもマイクロサービス化の事例があまりないタイミングでしたが、Kubernetesのインフラ上でHTTPリクエストをProxyするWeb Gatewayというマイクロサービスを作り、3-stepsリリースという段階的なリリースフロー を導入するなど、多くのチャレンジができました。

こうした業務は最初は一人で担当していましたが、メンバーが増えてDevOpsというチームになりました。その後、プロジェクトのリリースを経て育児休暇を取っていたのですが、育児休暇が明けた2019年9月にはWeb Backendのマイクロサービスを扱っていたチームと統合してWeb Platformチームとなり、自分の役割も一エンジニアからTech Leadとなりました。それからは自分で手を動かすだけでなく、チームの技術的なロードマップや開発・運用体制を作っていくようになりました。 扱っている技術範囲が広いチームだったので、チームが扱っているマイクロサービスや技術領域を分割し、それぞれの領域にMaintainerを割り当てるような体制にしたり、モブプログラミングや読書会を定期的に開いて学びあえる環境を作っていきました。新しい開発プロジェクトも始まり、サービスのインフラ構成を設計・構築したり、メルカリWebの認証画面を提供するマイクロサービスを立ち上げるなど、Webのフロントエンド・バックエンド・インフラをまたがって開発を行っていました。

2021年からはチームのEngineering Managerとなり、チームメンバーとの1on1や評価といったPeople Managementの役割や、チームのOKR作成や開発プロセスの運用を行うProject Managementの役割を持ちました。といっても、Managerになったタイミングではチームメンバーが少なくなっていたうえにプロジェクトの開発が佳境に入っていたため、手が足りない部分は自分が担当するなど、実質的にPlaying Managerとして働いていました。人手不足の状況を打開するため、チームのミッションを再定義し、新しいミッションに沿った形で採用の選考フローを見直し、採用活動を強化しました。Web Platformチームのミッションや役割については、メルカリのエンジニアブログから参照できます。チームメンバーの退職などもあり苦しい時期もありましたが、幸運にも素晴らしいメンバーたちを新たに採用でき、チームの活動も徐々に安定していきました。

退職

退職理由の一つはキャリアパスについてでした。Managerの方向でキャリアを伸ばすのであればManager of ManagerやDirectorなどがより上位の管理職となるのですが、現在のメルカリの規模のような会社で、より多くのチームやメンバーをマネジメントしていくことにあまり魅力を感じていませんでした。そこで、チームが安定したらEngineering Managerの役割を移譲し、Indivisual Contributer(IC)に戻ろうと考えていました。 しかし、チームが安定し、Engineering Managerの役割を移譲していく中で、「今が自分のキャリアを考える良いタイミングではないか」という考えが頭をよぎりました。Web Platformチームの業務には精通しており、チームとしても会社としても成熟度が高まっていましたが、自分からは入社当時の熱量がなくなっていると感じていました。改めて自分の今後のキャリアやチャレンジについて考える時間を取りたいと思い、退職を決めました。

メルカリでは、入社したときには予想できなかったほどの多くの経験を積むことができ、チームメンバーやマネージャーにも恵まれました。入社当時は初歩的な英語しか話せなかったのですが、メルカリのエンジニアチームがグローバル化する中で英語力も鍛えられ、業務であまり支障なく英語が使えるまで上達することができました。また、小さい子供を持つ親としてもとても働きやすい職場でもありました。誰もが当たり前のように育児休暇を取っており、自分が育児休暇を取ったときもチームメンバーからも暖かいメッセージを頂きました。コロナウイルスの流行後には100%リモートワークができる環境となり、長男を毎朝幼稚園のバス停まで送っていくのが日課になるなど、家族との時間を多く過ごすことができました。 自分は一度退職することを決めましたが、それは5年間の充実した時間の後に今後のキャリアを考えて決断したものであり、就職先として検討している方には自信を持って薦めることができます。

個人でのWebアプリケーション開発

退職後に何をしたいかと考えた際に、個人で何かWebアプリケーションの開発・運用をしたいと考えました。自分は業務としてWebアプリケーションの開発や運用をやっていましたが、個人としてWebアプリケーションを運用した経験はなく、単純にやってみたかったのです。

また、自分が使いたいアプリケーションのアイデアもありました。異なる用途のために複数のメモ用アプリケーションを利用していたのですが、1つのアプリケーションで大部分の用途に使えるものが欲しいと思っていました。 PC上でメモを記述する場合はコードブロックを利用できるMarkdown形式のメモ帳を好みましたが、メモを書く前に「ノートを作成する」もしくは「適切なノートを見つける」といった行為をする必要があるのが手間で、1-数行程度のちょっとしたメモを残す用途には適していないと感じていました。 Google Keepのようにさっとメモをつけられるアプリケーションも利用していましたが、メモを見つけるのが検索とタグ頼りになるのでしばしば過去のメモを見失いました。また、Markdown形式での記述はできません。 Workflowyという箇条書きでメモを書けるアプリケーションも利用していました。TODO管理がしやすいほか、特定のテーマについて箇条書きで階層構造をつけ、テーマについて考えたり調べたりしたことを掘り下げながら書いていくことができるツールで気に入っていましたが、すべての用途をカバーできるアプリケーションではありませんでした。

Slackをメモ用途に利用したときに、これはメモ用のアプリとして最適ではないかと考えました。短文のメモをさっと書くことができ、スレッドを利用することで一つのテーマについて多くの情報を記載でき、Markdown(っぽい構文)が使え、チャンネル、スレッド、検索機能などによりメモを見つけるのも容易でした。しかし残念なことに、Slackは基本的にメモアプリではなくコミュニケーション用のアプリであり、自分が投稿したデータは自分の管理下にはありません。また、Slackでは無料プランを利用していると一定期間しかメッセージを保持できません。データをexportするような機能もありません。これは自分の作成したメモをずっと使い続けたいと考えた場合のリスクでした。

そこで、Slackのように高機能なチャット形式のインターフェースを持ちつつも、個人のメモ用途に使えるアプリケーションを作れないかと考えました。メモという用途だと、オフラインでも完全に動作させたいと考えました。これをWebの技術で作ることは技術的にも多くのチャレンジがあるように感じ、このアイデアを実現したWebアプリケーションを作成することを決めました。

開発は、まず大まかなアーキテクチャや要素技術を決め、それから機能の設計・実装を行っていきました。アーキテクチャの方針として "Offline First" を掲げました。オフラインでも動作するローカルデータベースと、データ同期用のリモートデータベースを利用しますが、リモートデータベースの送受信はすべてService Workerを通じてバックグラウンドで行い、ユーザーのデータ操作はすべてローカルデータベースを通じて行いました。 ローカルデータベースにはIndexedDBを利用しましたが、通常のデータベースのように1レコードあたり1データを登録していくと、データ数が10万件などある程度大規模になるとデータ追加やインデックスのないレコードの探索時の時間がかかりすぎたため、1レコードあたりに多数のデータを含むなどして最適化したデータ構造にしました。代案としてWebAssembly版のSQLiteも試したのですが、公式のものは大量のデータを保存するために Origin-Private FileSystem APIが必要であり、Safariが対応していなかったため採用しませんでした。また、Third-Party製のものでabsurd-sqlも試しましたが、IndexedDBのデータ構造を最適化した構成のほうがパフォーマンスが優れていた点や、メンテナンスに不安があった点からこちらも採用しませんでした。

また、リモートデータベースにはGoogle Driveを利用しています。これはメモアプリであるため、データのオーナーシップはあくまでユーザーにある形にしたいと考え、サーバー側でデータベースを持たない構成にしました。これはインフラのコストを下げ、サービスを無料で提供し続けても金銭的な負担にならないようにするためのものでもありました。 アプリケーションとしてどのようなデータを取り扱っているかについてはプライバシーポリシーに掲載しています。

利用規約やプライバシーポリシーの作成についても苦労した点であり、良いウェブサービスを支える「利用規約」の作り方 という本を読んだり、他のサービスの記述を参照したりしながら作成し、弁護士の方にも見ていただきました。弁護士や行政書士の方にプライバシーポリシーの作成やレビューを依頼することもできるのですが、今回の場合は初回無料で相談を受け付けている弁護士事務所に連絡し、初回の相談の中で修正箇所を指摘していただいたため、幸い金銭的な負担はかかりませんでした。

その他にも開発中苦労した点などは無数にあるのですが、それはまた別の機会に記述できればと思います。

Webアプリケーション "Duck" のリリース

作成したWebアプリケーションは "Duck" と名付けました。"Duck" は "Rubber Duck Debugging" から取った単語であり、チャット形式のメモアプリにより「何かについて説明/記述するという過程で、よりよいアイデアが生まれる」というコンセプトが実現できると考えたためです。

DuckのWebサイトは https://site.ducknote.app/ からアクセスできます。現在は英語版のみ提供していますが、興味があればぜひ使ってみていただけると嬉しいです。 サイト上の Open Duck ボタンをクリックしてアプリケーションのURLに遷移すると、Welcomeダイアログの後にGoogleログインのダイアログが出ますが、いきなりGoogleログインするのは抵抗のある方もいるかと思います。その場合はログインせずにダイアログを閉じればオフラインの挙動になるため、そのまま試しに使ってみてもらえばと思います。オフラインでローカルに保存したデータは、GoogleログインしたタイミングでGoogle Driveにアップロードでき、他の端末でも利用できるようになります。 もしアプリケーションの挙動などでに何か問題があれば @urahiroshi まで報告ください。

今後何をやっていくか

個人としては、そろそろ次の仕事探しを始めようかと考えています。 Duckは生計を立てるために作ったものではないですが、自分自身がヘビーユーザーになっているアプリでもあるので、仕事をしながらプライベートの時間で開発・運用を続けていきます。