実践 エンジニアリングマネージャー at エス・エム・エス

2022年10月、介護事業者向け経営支援サービス「カイポケ」のエンジニアリングマネージャー (以下、EM)としてエス・エム・エスに入社した酒井( @_atsushisakai )です。先日、転職活動については 個人のブログ の方に書いてみましたが、入社エントリとしてエス・エム・エスの入社までの経緯と、EMとして実際にどのような仕事をしているかも簡単にご紹介します。これから「EMとして」転職を控えている方で、不安を持たれている方にとっての指針になったりすると嬉しいです。

私のバックグラウンド

前職では、株式会社 MIXI で「家族アルバム みてね」というプロダクトを、創業メンバーとして立ち上げからグロースまで8年以上に渡り開発を続けていました。ソフトウェアエンジニアとしては、iOS/Android のネイティブアプリ開発、Ruby on Rails でのバックエンド開発や AWS でインフラを構築・運用するなど、少人数チームならではの領域を越えまくるスリリングな開発を行なっていました。 また、後半数年間は EM として、ピープルマネジメントとプロダクト開発チームのスケールのための組織作り・プロセス作り・採用活動などに取り組んでいました。

エス・エム・エスとの出会い

そんな中、エス・エム・エスに出会ったのは転職のおよそ1年前、YOUTRUST でのスカウトメッセージでした。メッセージを受け取った後、コーポレートサイトを見てミッションや事業内容が非常に特徴的に感じ、その時は転職を全く考えていなかったのですが「面白そうだし一回話を聞かせてもらおう。自分の組織のために学びも得たいし!」くらいの軽い気持ちでカジュアル面談を申し込み、技術責任者の @sunaot と話をしました。 カジュアル面談では、エス・エム・エスの ミッション を中心に、展開しているサービスの課題、開発組織の課題などを広く聞かせてもらいつつ、自身の組織マネジメントの悩みなどを話して共感してもらったりなど、とても楽しく会話したのを思い出します。

なぜエス・エム・エスに入社を決めたのか

その後、何度か @sunaot と話をさせてもらう中で私は転職する決意をし、最終的にエス・エム・エスを選びました。転職先としてエス・エム・エスを選んだ理由はいくつかあります。

エンジニアリング組織をより大きくスケールさせていくフェーズであること

私はこれまで、比較的小〜中規模 (50名くらい) の規模でプロダクト開発を中心とする組織のEMとして活動していました。自身の中には、EMとしてより成長していくためには、さらに大きな規模の組織で発生する課題に向き合い、そこから得られる経験が必要であると感じており、その規模感とエス・エム・エスのプロダクト開発組織がこれからスケールしていくであろう規模感のイメージが合致していたことが、この会社を選んだ一つの理由です。

戦略を特に重要視していること

カジュアル面談で何度も話を聞いていく中で感じたのは、エス・エム・エスが一貫して「戦略」をとても重要視していることでした。社会課題に対してどのような視点からペインを解決しなければいけないかという Why の部分と、それをいつまでに解決すべきかという When の部分が徹底的に言語化されており、それに沿った形で非常に多くの事業やプロダクトに紐づいています。自分自身、事業における戦略が明確かつ相応な分量で言語化されていることは、迷った時に立ち返ることができる安心材料になるのでマネジメントの観点からも非常に業務が進めやすそうな魅力的な会社だと感じました。

子ども世代への影響度が大きいこと

最後は当然、解決しようとしている課題とそのための事業についてです。エス・エム・エスが展開している非常に多くの事業は、2040年問題と呼ばれる高齢者人口がピークに達する時代を見据えた課題解決の方向性を示そうとしています。2040年といえば、現在3歳の自分の子どもがちょうど社会に出る時代です。それを考えた時に、ひとつのプロダクトをじっくり作っていくことも重要ですが、多くの観点から社会の根本的な課題を解決するために自分の能力を使い、少しでも生きやすい社会に変化させていくことが、今の自分にとっては納得度も高く、何より我が子の未来のためになるのではないかと考え、最終的にこの会社に入社することを決めました。

入社してどうだったか?

入社後、最初の一週間は非常に戸惑いました。それは、「EMとして会社にジョインする」ということが初めてだったことが一番大きな理由だと今振り返って思います。膨大な情報量と日々目まぐるしく動くプロジェクトの状況など、プロダクトの立ち上げからほとんど全てを把握していた前職の環境からは一変し、自分自身がどの情報を選択し、深くインプットした上でチームやメンバーに影響を与えていくことができるかを判断するのがとても苦労しました(これは正直、今でも苦労しています)。

ただ、チームメンバーは非常にオープンマインドの方が多いので、積極的に1on1を申し込んだりなどを重ねて、コミュニケーションを取る機会を増やしていったことで思ったよりも早く溶け込むことができました。そうすることで、EMとしてコミットできる小さな課題を徐々に見つけることができるようになっていったのを思い出します。エス・エム・エスの開発カルチャーとして、モブプログラミングや意識的なオンライン雑談の時間などが充実しており、新しい人を受け入れやすいマインドが備わっているのも影響が大きいと感じています。

入社後にやった仕事

現在は介護事業者向け経営支援サービス「カイポケ」の開発プロジェクトにおいて、フロントエンドチームの EM としてアサインしてもらっています。また、エンジニアやデザイナーのプロダクト開発に必要な人材の採用活動も幅広く扱わせてもらったり、プロジェクト全体のエンジニアリング部門におけるマネージャーとして、課題の集約や情報共有の結節点となるなど、現場に近いところでプロジェクト推進のためにできることを徐々に増やしていっています。

この中でもいくつか、入社後にフロントエンドチームの EM として取り組んだ仕事をご紹介します。私が EM を務めるフロントエンドチームは、私が入社する1ヶ月前に新たなチームとして発足しており、様々な整備やチームビルディングを行っていかなければいけない状況でした。以下は、そういう状況で私が EM として取り組んだ課題解決のいくつかの事例となります。

チームの価値観や暗黙知を言語化する

私がジョインしたタイミングでは、徐々に技術選定は進んでおり、チームがコードを書き始められるような土台は出来上がってきていました。ただ、立ち上がったばかりのチームなので、複数人でコードを書いていく上でそれぞれのメンバーが持つ開発の価値観を揃えたり、暗黙知となっている事柄を言語化することなどがまだそれほど出来ていない状態であったことに気づきました。これらを言語化することが長期的なパフォーマンス向上を実現する土台となるという経験はこれまでもあったので、まずはここに取り組ませてもらいました。そのひとつの成果として「コードレビューガイドライン」を GitHub リポジトリ上に立ち上げたり、同様に「コーディングガイドライン」も叩きとして作り、今後コードを書いていく中で何か取り決めがあった方が良いだろうというものをガイドラインとして言語化し、明確に共有していく流れを作りました。

コードレビューガイドライン
コードレビューガイドライン

スクラムの導入

コードベースが徐々に整理されていくのと同時に、ユーザー価値の実現プロセスとしては、スクラムを取り入れていくことが初期に決まっていました。スクラムのフレームワークを使い、どのようにプロダクトバックログアイテムを管理・見積もりを行うか、チーム内でスクラム関連のイベントをどのタイミングで、どのぐらいのタイムスケールで実施するかなどを PdM とじっくり話しながらプロセスを構築していきました。プロセス全体においては自身がスクラムマスターとして、チームがスクラムにおけるメリットをしっかりと享受できるよう、まずは教科書的に必要な要素をしっかり実践していくことを徹底しています。このあたりは、前職で長年スクラムを実践してきた経験がとても活かされていると感じています。

フロントエンドチームのMission/Vison策定

開発が安定的に進み始め、新たにメンバーがジョインした頃に、より細かくお互いの価値観を揃え、チームとして目指したい姿を共有するために、今後数年を見据えた Mission/Vision をメンバーみんなで作ることにしました。プロジェクト全体のミッションを達成するためにチームとしてどのような貢献をするべきか (Mission)、また「組織・技術・採用・プロダクト」の様々な観点で、チームがどのような状態になっていたいか (Vision) を複数回ディスカッションを重ね、言語化し、将来像をメンバー間で共有しました。

フロントエンドチームのMission/Vision
フロントエンドチームのMission/Vision

フロントエンドチームの分割

チームが立ち上がり数ヶ月経つと、様々な方面からチームにメンバーがアサインされるようになり、人員のボリューム感も出てきました。今後開発対象となるアプリケーションも複数あるため、チームを分割していく流れを作っていくことが自然な状況になってきました。チームをどういう単位で分割するか、また分割していく上で事前に考える必要がある様々な事柄を整理し、ガイドライン化しながら、チーム内外で認識合わせをしたりなどをしてきました。主に実施したことは以下のようなものです。

  • 誰をどのチームにアサインするかの決定
  • メンバー間での役割分担 (マネジメント、プロジェクトリードなど)
  • 複数チームの情報流通のためのドキュメントや会議体の整備
  • 複数チームで行うコードレビューのためのガイドラインのアップデート
  • 事前のコードベースのリファクタリング
  • 共通コンポーネントの整理

現在は、ふたつのフロントエンドチームがお互いに連携しながら、アプリケーションを開発しています。

おわりに

以上が、入社の経緯や入社して以降の実際の仕事の内容でした。まだ入社して数ヶ月ではありますが、EMとして大きな裁量を持ち、自分自身が一番レバレッジを効かせられる場所を見つけ、自由に動いて良いということを技術責任者の @sunaot から言ってもらえています。そういう中で、徐々に転職した理由であるEMとしての「マネジメントの規模感」を大きくしていけるような視点も増えてきており、これから EM としてエス・エム・エスでプロダクト開発と事業に全力投球できることを非常にワクワクしながら過ごしています。

EMとしてこれから転職を考えている方は「どのように既存の開発組織に入っていくのが良いだろうか?」ということを悩まれると思いますが、今回の私のポストの内容が少しでも役に立つと嬉しいです。

最後になりますが、エス・エム・エスでは社会の課題解決を一緒にやっていただける様々なプロダクト開発の人材を募集しておりますので、気になった方は、ぜひ一緒によりプロダクト開発に取り組んでいきましょう!