diniiに入社していました＆就職活動、キャリアについて

8月1日に株式会社diniiに入社していました。前回の投稿 ののち、5月頃から就職活動を始めており、多くの会社の方やエージェントの方に面談の機会を作っていただきました。最終的にdiniiに入社することを決めましたが、自分の体がたくさんあれば入社したいと思う会社も多く、とても悩みながら決断しました。お時間を取っていただいたのに辞退した会社の方にはとても申し訳ないですが、自分のエンジニア人生の中で何かまたご縁があればと思っています。

就職活動について

今回の就職活動では、LinkedIn, Findy, Wantedly, リクルートダイレクトスカウトを主に利用していました。以前の転職活動では元々関心のあった企業の中からすぐに選考に進んでいたのですが、今回は幅広く企業の情報を集めた上で選考に進む企業を選んでいきたいと思っていたため、少しでも気になる企業や案件があれば積極的に面談を依頼していました。

企業の方と直接やり取りを行なってカジュアル面談や選考を行うケースと、エージェントの方を通じてカジュアル面談や選考を行うケースがありました。エージェントを経由した場合の利点として、求人の給与など条件面も教えていただけるので企業を比較しやすいこと、非公開の求人を紹介していただけるケースも多いことなどが挙げられます。欠点としては、エージェントの方との面談を通じて求人内容の詳細を教えていただけるという場合が多く、その求人内容が期待に合わないものであれば無駄な時間となってしまう点や、選考に関するやり取りが直接企業の方とできないため、伝言ゲーム的なコミュニケーションになってしまうという点があります。まとめると、エージェントを利用することで時間効率やコミュニケーションの精度は下がる部分がありますが、時間をかけても幅広く情報収集する場合には適していると考えます。

また、今回はスタートアップを中心に見ていました。当初は無数の企業からどうやって絞り込んでみていくかに苦労し、「すごいベンチャー100」などで企業情報を集めましたが、有力なベンチャーキャピタルの投資先となっている企業を一つ一つ見ていくというやり方もありかと感じました (これは後から思いついたものなので、今回はあまり実践できませんでしたが)。

キャリアについて

前職を退職後、チャレンジしていきたいと思ったのは「良いプロダクトを作ること」「良いプロダクトを作る組織を作ること」の2点でした。「良いプロダクトを作ること」については Duck の個人開発を通じて前に進めていますが、「良いプロダクトを作る組織を作ること」についても関心がありました。そこで、エンジニア組織全体、技術全体を見ることにチャレンジできるかという視点で就職活動を行いました。

入社時点において、diniiではフルタイムのエンジニアが10名前後で2つの開発チームを持っていました。この規模であれば各チーム、エンジニアの動きをある程度高い解像度で見ることができます。成長中の会社であり、チーム数が増えていくと自分から見える範囲も限られてきて組織の課題も変わっていくと考えられるため、組織の成長に合わせて自分も成長していく必要があり、それが面白そうだと思ったことが入社理由の一つにあります。

エンジニアのキャリアについて、ある程度キャリアを積むとIndivisual ContributorかManagerかという選択肢が挙がってくるかと思います。今回の自分の選択はどちらかといえばManager側になるのですが、今後ずっとManager的な動きをするかはわかりませんし、あまり決めたくないというのが正直なところです。自分が最も重みを置いている価値は「学び」であり、キャリアを限定せずにどちらにもなれるという感覚を持ち、その時点でより面白そうな選択をし続けることが最もモチベーションを高く維持でき、高いモチベーションによって学習効率が上がると考えているためです。

diniiに入社して、もしくはスタートアップについて

入社してからやってきたことについてはdiniiの技術ブログの方に書いていきたいと思いますが、1エンジニアとしても全社的な動きが見えやすく、自分のアクションが組織全体の課題解決に直結しているという実感を得られています。また、飲食店のオペレーションを支えるプロダクトを提供しており、セールスの方を通じてお客様からのフィードバックがよく届きますし、大きいインシデントが起きると飲食店のオペレーションが止まってしまうという緊張感もあります。

組織の規模が大きくなるほど、1エンジニアとしてのアクションが組織全体に与えるインパクトやプロダクトに与えるインパクトは相対的に小さくなるように感じます。もちろん組織規模や事業規模が大きければ、1メンバーや1ユーザーあたりから見たインパクトが小さくても全体のインパクトとしては大きくなるのですが、実感としては感じにくいということです。 技術を使って事業を成長させている、課題を解決しているという実感を得られることがモチベーションに大きく左右するという方には、スタートアップはお勧めだと言えるでしょう。

diniiでも絶賛採用中ですので、興味のある方はぜひこちらの採用情報を参照ください。 https://diniinote.notion.site/dinii-4f1f4687b47a48ee9de7abbe5a1f3814

メルカリを退職し、個人で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アプリケーションを運用した経験はなく、単純にやってみたかったのです。

また、自分が使いたいアプリケーションのアイデアもありました。異なる用途のために複数のメモ用アプリケーションを利用していたのですが、１つのアプリケーションで大部分の用途に使えるものが欲しいと思っていました。 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は生計を立てるために作ったものではないですが、自分自身がヘビーユーザーになっているアプリでもあるので、仕事をしながらプライベートの時間で開発・運用を続けていきます。