大企業の総合職からスタートアップのエンジニアリングマネージャーになった理由

urahiroshiと申します。

自分はもともと大学卒業後に大企業の総合職として入社したのですが、それからいくつかの変遷・転職を経て、現在はダイニーという飲食スタートアップでエンジニアリングマネージャー（EM）をしています。

この記事では、自分の経験をお話することで、自分と同様にキャリアチェンジを考えている方や、今まさにキャリアチェンジをしている方になにかヒントとなる情報が提供できればと思っています。また、これまで様々な規模の企業・様々な役割を担ってきた中で、自分が得られた学びについても共有できればと思います。

1.大企業の総合職からソフトウェアエンジニアになるまで

自分が大学を卒業し、新卒で入社したのは警備会社のセコムでした。理系の学部で、周りの同級生がほとんど大学院に進む中、学部で卒業してセコムの総合職を選んだのは珍しいケースだったと思います。大学時代は演劇部などで活動しており、当時は研究開発系の分野に進路を定めることに躊躇いがあったのと、「世の中に対してネガティブな影響を与えていない」という理由で事業に魅力を感じました。

当時、セコムの総合職の最初の配属は、必ずビートエンジニア（機械警備）となっていました。ビートエンジニアは、契約先で何か異常を検知した場合にまず駆けつける役割です。実際に犯罪者に遭遇するという緊張感もありながら、勤務時間が不安定だったり、異常検知が相次ぐと休む間もなかったりと、体力的にもなかなか大変な現場でした。多くの異常検知は誤発報によるものなのですが、新しいシステムを導入している現場だとほとんど誤発報がなかったりと、提供しているシステム・サービスによって運用負荷が異なることを身にしみて感じました。これは、Webサービスの運用についても通じるものだと感じています。

半年ほどビートエンジニアを担当した後、非接触ICカードリーダーの開発を行っている部門に異動しました。カードリーダー本体の開発だけでなくカードリーダーのUSB通信ドライバやPC上で操作するためのアプリケーション開発なども行っており、ここで初めて業務としてソフトウェア開発に携わることができました。ハードウェアの開発はいわゆる上流工程のみ担当していたのですが、ソフトウェアの開発では自分で書籍やWebサイトなどを参照しながら実装を進め、「学んだことが仕事に活かせる」という感覚が新鮮でやりがいを感じました。

しばらく経ってからハードウェア開発が中心となる部門に異動したのですが、ソフトウェア開発から離れたことでより一層ソフトウェア開発に対する意欲が高まります。実は当時、NPO団体のボランティアメンバーとしても活動していたのですが、活動の中でGoogle App Engineを用いたWebサービスを開発したり、応用情報処理技術者やデータベーススペシャリストといった資格の取得などを行ったりすることで、業務外の時間を用いてソフトウェア開発に関連する学びの機会を作っていました。そうした努力が実って（？）、社内でソフトウェア開発系の部門に異動することができました。業務外の時間でしかソフトウェア開発のスキルを身に着けられない期間が数年ほどあったため、晴れて業務内の時間でソフトウェア開発のスキルを学べる環境に身を置けたことが嬉しく、「これは夢じゃないか？」とたびたび思っていたことが記憶に残っています。

2. 最初の転職、新しい技術習得へのチャレンジ

しばらくはセコムのソフトウェア開発系の部門で楽しくやっていたのですが、自分が専門的に扱っていたのはWindows系のアプリケーション開発だった一方で、Linuxの経験をより積みたいという気持ちや、よりソフトウェア開発における専門性を高めたいという気持ちが徐々に高まりました。その勢いで転職活動を行い、株式会社インターネットイニシアティブ（以下、IIJ）に入社することができました。

IIJではいわゆるIaaSにあたるクラウドサービスを開発する部署に配属され、Windows系の開発に専門性を持っていたこともありWindowsサーバ専用のIaaSサービスの開発に携わりました。一方で、Linuxの経験を積みたいという意欲も汲んでいただき、Linuxサーバ上で稼働するサービスの開発も徐々に任せていただきました。

IaaSのサービス開発を行うことは当時の自分にとってこれ以上ない学習経験となりました。プロダクトのドメイン知識＝インフラの知識となるため、Virtual Machineやネットワークなどのインフラ基盤に関する知識の理解が必要となりますし、他の開発メンバーもアプリケーション開発からインフラの運用まで精通したメンバーが多く、入社当初は「この環境でやっていけるのだろうか…」と不安にも感じました。入社後はLPICやCCNAなどの資格取得で基礎知識をつけ、その上で実務にあたりながら徐々に技術を身に付けていきました。また、チーム内でフロントエンドの領域に専門性を持っているメンバーがあまりいなかったため、Angular（当時はまだv1）について調べて社内で発表するなどいくつかの経験を経て、大規模なIaaSサービスの開発時にフロントエンド部分の実装を担当することになるなど、自分の専門領域の一つとすることができました。

当時のIIJでは基本的にフロントエンドエンジニア・バックエンドエンジニア・インフラエンジニアといった区切りがなく、自分の専門分野もWindowsだったりフロントエンドだったりロードバランサだったりと様々な領域に手をつけることができました。いま振り返って思うと、一つの領域に特化したほうが短期的な成長やインパクトにつなげやすいと思いますが、一つの領域で成果を出してそのままリーダーやマネージャーの役割になっていくと、なかなか他の技術領域について一から学ぶ機会は取れなくなってくると思います。個々人の志向や環境にもよるかと思いますが、自分の場合はこうして複数の領域に経験があることが視野や可能性を広げ、自分のキャリアにプラスとなっていたように感じます。

3. 2回目の転職、リーダー・マネージャーの経験

IIJでは自社のIaaSサービスを開発していたからこそ、逆にGCPやAWSといった他社のIaaSサービスをプロダクト開発で利用することはなく、IaaSサービスを作る側ではなく利用する側としてプロダクト開発をしてみたいという気持ちがありました。また、様々な技術分野に関わり、ある程度機能開発の経験をしてきたこともあり、単純な機能開発とは違う目線で開発に携わりたいという気持ちも出てきました。

その中で、株式会社メルカリでSET (Software Engineer in Test)という職種での募集を見つけました。実はIIJでもE2Eテストの実行基盤や実装・運用を行っていたり、個人としてE2Eテスト用のライブラリやサービスを開発したりと、自動テストや品質改善といった部分には関心がありました。これは、と思い選考を受け、メルカリにSETエンジニアとして入社することになりました。

当時のSETは2つのサブチームに分かれており、1つのチームがE2Eテストの実装や実行基盤の提供を行っているチーム、もう一つがCI/CDやUnit Test、開発環境やテスト環境の整備など広い意味で「生産性の向上と品質改善」をテーマとして何でもやっているチームでした。入社前はE2Eテストをやっていくんだ！と思ってメルカリが使っていたテスト自動化ツールであるAppiumなどを試したりしていたのですが、実際に自分が所属したのは後者のチームで、入社後にAppiumを触ることはありませんでした。しかし、入社後は複数のフロントエンドチームと連携してフロントエンドのCI/CDジョブの整備やモニタリングツールの導入に携わったり、開発チーム全体で利用されている開発環境・テスト環境の改善やサポートをする中で、機能開発とはまた異なった楽しさを感じました。

徐々にフロントエンドチーム内のSETの立ち位置から、“フロントエンドののインフラに詳しいメンバー” のような立ち位置となり、メルカリWeb版のマイクロサービス化などのプロジェクトが立ち上がったタイミングで、メルカリWeb版のマイクロサービスのインフラ管理・運用を行う “Web DevOpsチーム” が立ち上がり、そのテックリードとなりました。最初は2名ほどの小さいチームでしたが、Webのバックエンド部分のオーナーシップも持った “Web Platformチーム”となり、規模としても6名のチームになりました。

また、当時のメルカリでは急速なグローバル化も進んでおり、最初のチームメンバーは全員日本人だったのですが、自分の退職時にはグローバルメンバー6名・日本人2名となっており、コミュニケーションも完全に英語化していました。英語については、もともと会話の経験は全くなかったものの、会社がグローバル化していく直前のタイミングで入社したこともあり、社内のグローバル化にともなって徐々に会話スキルを身につけられていったように思います。

役割も最初はテックリードでしたが後にエンジニアリングマネージャーとなりました。メルカリではエンジニアリングマネージャーは単に役割 (Role) であり、昇進ではなく役割の変更、といった位置付けになります。通常のエンジニアからテックリードはある程度活動の延長線上にありますが、エンジニアリングマネージャーは求められる専門性が異なり、特に評価やフィードバックは苦労しました。それでも、自分がSETであるときに志した「生産性の向上と品質改善」という目標に対し、エンジニアリングではなくマネジメント面からアプローチしていると考え、役割やアクションは変わりながらも自分の中では地続きの活動をしていたように感じています。

4. 3回目の転職、スタートアップのエンジニアリングマネージャーとして

メルカリにはある程度長く在籍し、チームも安定した状態になってきたため、新しいチャレンジをしたいと思っていました。1つ目のチャレンジは「個人としてWebサービスを開発・運用すること」であり、退職後しばらくWebサービスの個人開発を行っており、Duck という Webサービスを立ち上げました。特にマネタイズする予定がなかったサービスのため、それから転職活動を始めました。

2つ目のチャレンジとしてやりたかったのは「組織全体を見て生産性の向上・品質改善のための意思決定を行っていく」という点です。これまでメルカリではあくまで1チームのエンジニアリングマネージャーとして活動してきましたが、どうしてもコントロールできるスコープや見える範囲がチームに限られるため、より小さい規模の組織で、組織全体を見ながら意思決定を行うことに対してチャレンジしたかったのです。

様々な会社の話を聞くなかで、最終的にダイニーを選んだのは以下の理由からです。

当時のエンジニア組織規模は10名前後であり、組織拡大も検討されていたので、組織全体を見て意思決定を行っていきながら組織拡大を行っていくことにチャレンジできる環境があった
元々知っているメンバーも多く、話を聞く中で技術力の高さや成長性を感じた
通常のスタートアップでは品質よりも開発スピードに比重が置かれやすいため、「生産性の向上と品質改善」のバランスを取りたいという自分の関心・経験を活かせられるかが懸念だったが、ダイニーのプロダクトは飲食店のオペレーションの根幹を担っているためインシデントのインパクトが大きく、信頼性の向上にもかなり力を入れていた

そうしてダイニーに入社し、最初はエンジニアとして4ヶ月ほど活動した後、エンジニアリングマネージャーの役割となりました。エンジニアリングマネージャーといっても、メルカリの頃のように一つのチームのエンジニアリングマネージャーではなく、全エンジニアチーム・メンバーを見る必要がある点や、システムの知識については自分よりもメンバーのほうが圧倒的に知識があるという点が異なっています。メルカリの頃はある程度自分の技術力や知識を活かしてマネジメントできていたと思いますが、同じようにはできないため、どのように自分のValueを出していくかについては苦心しました。

そんな中で、エンジニア組織全体を眺めた時に、一番課題に感じたのは採用でした。在籍していたメンバー、一人ひとりが高いパフォーマンスを出しており技術水準も高いことには驚きましたが、より事業を拡大・成長させていくためには組織拡大が必須である一方で、エンジニアの新規採用には苦戦していました。もともと採用はHRチームがリードしていましたが、エンジニア側としても自分がオーナーシップを持ち、採用戦略や選考フローの改善、技術広報のための施策の実施などにより徐々に採用状況が改善していきました。今も採用は優先度の高い課題ですが、組織が拡大していく中でどのようにチームを形成していくか、メンバーを成長させていくかといった課題にもチャレンジしており、当初イメージしていた「組織全体を見て意思決定を行っていきながら組織拡大を行っていく」ことに全力で取り組めているように思います。

5. 最後に

最後に、こうして経験を振り返ってみて、キャリア形成に関する学びをいくつかまとめたいと思います。

ソフトウェアエンジニアとしてキャリアチェンジしたいと思ったら、何よりもまず人に見せるソフトウェアを作ってみること

自分の場合は比較的幸運な環境で、専門的なソフトウェアエンジニアでないにせよソフトウェア開発を扱う部署に配属され、開発を行う過程で「自分がソフトウェアエンジニアに合っている」ことが確かめられました
また、NPOでの活動でWebサービスの開発を始めて経験し、自分自身の学びや自信になっただけでなく、転職活動時のネタにもなりました

手段ではなく目的を自分の専門分野として考える

エンジニアとしてのキャリアの中で、「専門分野を作りたい / 伸ばしたい」と考えている方は多いかと思います
一方で、「xxx の技術で多くの経験を得たが、目的もなく xxx の最新情報を継続的にキャッチアップするモチベーションは湧かない」という方は多いのではないでしょうか。そういう場合に専門分野を伸ばせないのかというとそうではなく、自分のお勧めは「手段ではなく目的を専門分野にする」ことです
例えば自分の場合、技術的にはWebやインフラが専門分野にあたりますが、それよりも「品質と開発速度の向上」というテーマが最も関心があります。そのため、エンジニアリングマネージャーというキャリアとなり、技術的な専門性が高められなくても「品質と開発速度の向上」に対して異なるアプローチを学ぶ経験が得られます

勉強できる環境があること自体が幸運

自分は特にキャリアの初期において、プライベートの可処分時間の多くを勉強に割いてきて、それによってキャリアチェンジを行ってきました
一方で、結婚して子供ができてからは可処分時間が圧倒的に減りました。例えば今のような環境でソフトウェアエンジニア以外の職務からソフトウェアエンジニアにキャリアチェンジするのは難しいと感じます
育児だけでなく、介護や自身の健康上の理由などで、本人の意志とは関係なくプライベートの可処分時間が取れなくなる可能性はいつでもあります。その時にどうするかという回答は自分で持ち合わせておらず、ただ言えるのは「勉強できる環境があること自体が幸運であり、できる時にやらないとずっとできないかもしれない」ということです

以上の学びが、自分とは別の誰かの学びとなれば幸甚です。