元霞ヶ関の官僚がエンジニアに転身して下町のスタートアップに入社するまで
はじめまして。
バックエンド開発を中心に仕事をしておりますm-ysk(@myskjp)と申します。
今月から、キャディ株式会社でエンジニアとして働いています。
まだ入社したばかりのタイミングではありますが、転職の経緯や、入社して見えてきたキャディの姿について振り返ってみたいと思います。キャディで働くことに関心を持っていただくきっかけとなれば幸いです。
キャディの話をする前に、まずは自己紹介をさせて頂きます。なお、私は、新卒で総務省という役所に入り、国家公務員として働いた後、ソフトウェアエンジニアに転身したという、少しだけ変わった経歴をしています。そのため、自己紹介は少々長くなってしまいます。
新卒で総務省へ
私は、大学を卒業後、国家公務員の採用試験を受けて総務省に入省し、いわゆる官僚として政策の企画立案や法律の原案作成などの仕事をしていました。
総務省という組織は、その名前の通り多岐にわたる分野を所管しているのですが、私はその中でも、通信サービスの競争促進や電波の割り当てといった情報通信政策に携わりたいと考えたのが、最初の職場として総務省を選んだ理由でした。
私が大学を卒業した当時は、ちょうどスマートフォンやSNSが普及し始めた頃で、インターネットが一部の先進的ユーザや若者の遊び場から、人類全体のインフラへと変貌しつつある過渡期でした。そのような時代の中、情報通信政策という分野はレバレッジが大きく、興味深い仕事であると考えたのです。
総務省では当初の希望通り、情報通信政策に携わることができ、FTTHサービスの競争促進のための政策立案プロセスに携わったり、電気通信事業法という法律の改正を担当したりしていました。特に法改正の際は、条文案の審査を受けるため、内閣法制局という審査専門の組織に連日深夜まで通い詰めたりしたのがとても懐かしいです。（なお、内閣法制局というのは、法律の条文案に対する静的コード解析やテストを人力で行ってくれる偉い人が集まった組織です。人力で行っているがゆえ、審査は連日深夜に及ぶのです。）
余談ですが、法律とプログラムのソースコードというのは実はとても良く似ています。実際、エンジニアの世界で名著として知られる『リーダブルコード』と、ある意味同じことが、総務省時代の机の上に置かれていた『ワークブック法制執務』に書かれていた、と言っても過言ではありません。そのため、公務員として法律を扱っていた経験は、エンジニアとしてコードを書く上でもとても役立っています。
総務省での仕事はとてもスケールが大きく、知的刺激とやりがいに満ちたものでした。しかし、その一方で、国の政策というスケールが大きく抽象度の高い対象を扱っているがゆえ、自分の仕事の成果が世の中にどのような影響を及ぼしているのか、具体的に見えにくいという物足りなさもありました。
一方、私は趣味でプログラミングに取り組んでいたのですが、プログラミングというのは個人の作業の結果が具体的な成果物に直結するものであり、完成したソフトウェアが誰にどのような価値をもたらすかも明確であるという点で、中央省庁の仕事とは真逆のものでした。そのため、日々の仕事で感じる漠然とした物足りなさを埋めるように、趣味のプログラミングにのめり込んで行くことになりました。
そうしてプログラミングに熱中し続けたある日、これならいっそのこと平日の昼間からプログラミングに没頭できる仕事に就いたほうが幸せなのでは、ということに気付き、エンジニアへの転職活動を開始することになりました。
エンジニアへの転職活動
転職活動といっても、エンジニアとしての業務経験もない私は何をすれば良いか分からず、とりあえず、GeeklyさんというIT業界専門の転職エージェントさんを利用することにしました。
転職活動といっても、エンジニアとしての業務経験もない私は何をすれば良いか分からず、とりあえずIT業界専門の転職エージェントさんを利用することにしました。
エージェントさんからは、「m-yskさんは学歴も良いし技術学習にも積極的に取り組んでいるので、きっと採用したい企業さんもありますよ〜」とおだてられ、そういうものかと思ってとりあえず20社ほど応募してみました。しかし、書類選考通過はそのうちの3社ほどという結果で、現実の厳しさを感じることになります。
この3社のうちの1社が、前職の職場でした。前職は企業ブランディングにあまり力を入れていなかったため、社名で検索しても情報が少なく、面接に行くまでは不安しかありませんでした。しかしながら、代表や、後に私のメンター的な立場になるエンジニアの方とお会いした結果、技術的に成長できそうな環境だと感じたため、即決で入社を決めました。やはり、ネット上の情報だけでなく、実際に人と会って判断するのは重要ですね。
民泊スタートアップでエンジニアとしてのキャリアを開始
エンジニアとしての初めての職場だった前職は、民泊施設の管理運営を支援するソフトウェアの開発と、自社製ソフトウェアを活用した民泊施設の運営といった事業を展開するスタートアップでした。
前職では1年ちょっとの間、Goによるバックエンド開発を中心に、AWS上のインフラの構築、React/TypeScriptによる社内向け管理画面の開発といった業務を行っていました。その他、たったの2週間ほどでしたが、Rustによるバックエンド開発を行ったりもしていました。
運営する全プロダクトの合計でエンジニアの人数が10名弱という小規模なチームだったため、経営陣やビジネスチームとの間でのプロダクトの企画立案から技術的なアーキテクチャ設計、コードの実装までプロダクト開発の全工程を裁量高く行うことができました。これは、ジェネラリスト指向で事業にも関心のある私にとっては理想的な環境でした。
また、ただ目の前のタスクに取り組むだけでなく、各メンバーの興味関心に基づいてコンピュータサイエンスやソフトウェア設計理論といった理論的なトピックを探求するとともに、それらの知見を積極的に業務に取り入れていく気風があったのも前職の特徴でした。そのような環境に身を置いた結果、もともとプログラミングを単なるモノづくりの手段として捉えていた私が、技術そのものの探求の面白さに目覚めることとなりました。
実際、キャディの選考プロセスにおいては、「経歴から想像していたよりも技術的に深い議論ができた」「抽象度の高いレイヤでドメインロジックを整理する能力が高い」といったフィードバックを受けましたが、そのバックグラウンドとなる知識の多くは、前職のチームメンバーとの議論の中で獲得したものでした。
コロナの影響で転職を意識
そのような理想的な環境に満足していた私が転職を決意したのは、ひとえにコロナが原因でした。
前職の勤務先は、昨年末に資金調達を終え、急成長中の局面ではありましたが、コロナ禍による外国人観光客の事実上の受入停止という非常事態の中、民泊フィールドで事業展開する前職にもその影響は及びました。幸い、経営陣の迅速な経営判断が功を奏し、経営へのダメージは軽微なものに留まったのですが、コロナ以前のアクセル全開の時期と比較すれば、エンジニアとして業務に取り組む上で感じるスピード感が一時的に少し減速してしまった感覚は否めませんでした。
前述したように会社の環境には満足していたため、前職に留まりつつコロナの影響から脱するのを待つという選択肢もあったのですが、私の場合、新卒でエンジニアとして就職した方と比較するとほぼ10年遅れの状態であり、一般的なエンジニアの数倍の速度でキャッチアップできなければ死あるのみと考えていたので、成長速度について妥協することはできませんでした。
また、コロナ以降、自粛により空いた時間を利用してひたすら競技プログラミングの精進に取り組んでいたのですが、AtCoderのレートが当初の第一目標だった水色に到達し、ここから先（青、黄色……）は道が長そうだから競プロ以外の目標も欲しいな、と思ったのも、転職を意識する心理的なきっかけだったように思います。
キャディのことを思い出す
転職活動を意識し始めたとき、最初に思い出したのがキャディでした。
キャディの名前を最初に認識したのがいつだったかは覚えていませんが、AtCoderのCADDiコンテストに参加していたこと、Rustの勉強会を開催している企業であることなど、複数の観点を経由して、キャディの名前は以前から知っていました。
キャディについてご存じでない方は、以下スライドを是非ご覧ください。
そこで、早速キャディのエンジニア採用ページにアクセスしてみたところ、「むずかしいということをおもしろがる」というフレーズが掲げられており、問題を解くことが大好きな私は俄然興味を惹かれました。
また、キャディの技術スタックとエンジニア文化がまとまっている「The letter from CTO」の最終ページには、「こんな方、ぜひお声がけください」というメッセージとともに、「課題に向き合い続けるのに、課題を疑う」「技術が好きだけど、人も気になる」「一人で走るのが好きなのに、誰かと何かを成したい」「武器を磨き続けるのに、武器にこだわらない」という人物像が掲げられています。これを見た私は、これはまさしく私（が目指している人物像）なのでは、と直感しました。
この他にも、経営陣のインタビュー、社員が書いたnoteの記事（この記事もその一つとして追加されます）といった多くの記事を読み漁ってリサーチを行いました。その結果、技術だけでなく事業、組織カルチャーの面でも共感できる会社であることを感じました。また、採用媒体に掲げられた文言が単なる美辞麗句ではなく、メンバーの一人ひとりに共有され、実践されているものであることを確信しました。
この会社で働いてみたい！と思った私はその日のうちにエントリーしていました、と書ければ熱い感じになるのですが、実際には、その日はちょうどお盆休みの前日だったので、とりあえずお盆休み中にじっくりと考えることにして、お盆休み明けにカジュアル面談に応募しました。
キャディ一本に絞って転職活動
情報収集の時点でキャディに対し高い魅力を感じていた私は、とりあえずキャディ一本に絞って転職活動を開始することにしました。
キャディの選考プロセスでは、エンジニアを中心に合計6名と会いました。その中で、経営陣から現場のエンジニアまで全員に共通する、事業へのコミットメントの強さを感じました。
特に印象的だったのは、代表の加藤さん、CTOの小橋さんとの最終面接で、キャディのコーポレートサイト（いかにもスタートアップという感じのモダンなデザイン）とお客様向けのサイト（昔懐かしい安心感を感じるデザイン）でデザインのコンセプトが違っているのが興味深いと思った、という話をしたときのことです。
私が、デザインを区別している理由について質問したところ、代表の加藤さんから、「お客様にとって最もcomfortableな表現を追求した結果そうなった」という話がありました。
これは当たり前の話のようにも聞こえますが、単にモダンなデザインのサイトを作って良しとするのではなく、事業上の目的達成に徹底的にフォーカスする姿勢が感じられる言葉だったと思っており、とても印象に残っています。
なお、この話の前提として、キャディには、会社情報や採用情報を掲載するコーポレートサイトと、キャディに対して製品の製作をご依頼くださいお客様向けのサイトが別々に存在するのですが、この2つはデザインが大きく異なっています。ご覧になったことがない方はぜひ見比べてみてください。
また、余談ですが、面接の中で一番驚いたのは、代表の加藤さんに、「AtCoderでは何色を目指してるんですか」と聞かれたので、「黄色までは目指したいです。えーと、黄色というのは、上から数えて……」と説明しようとしたところ、「知ってます」と言われたことです。自社でコンテストの主催経験があるとはいえ、AtCoderの色の並び順まで覚えている経営者（エンジニア出身者以外）はなかなかいないのではないでしょうか。
と、面接の本筋ではない雑談的な部分の思い出ばかり書いてしまいましたが、肝心の技術的な質問については、前職での経験を活かして的確に答えられたものもあれば、回答方針を誤って途中でグダグダになってしまったものや、基礎知識が足りておらず答えに窮してしまったものもありました。そのため、内定の連絡を受けるまでは結果が不安でしたが、無事内定となり安心しました。
フランクな姿勢で常に「いいですね〜」とアメリカンな相槌を打ってくれるCTOの小橋さんを始め、面接で会ったエンジニアのみなさんは、候補者の魅力を最大限に引き出そうとする姿勢で面接を行ってくださったので、心理的安全性高く面接を受けることができました。
入社してみてどうだったか
入社後は、社内で利用するサプライチェーン管理システムの開発チームにジョインしました。このシステムは、お客様から頂いた部品製作の発注を最適なパートナー工場に振り分けて発注し、パートナー工場から受領した成果物をキャディ拠点で検品してお客様に納品するという、キャディのサービスを構成する一連のサプライチェーンの管理を担っています。
入社前からオンボーディングの機会が積極的に提供されていたこともあり、入社初日からプロダクトのコードにコミットし、即日リリースまでを達成することができました。
入社からまだ2週間というタイミングではありますが、ここで、入社してみて感じたキャディの魅力を、かいつまんでご紹介したいと思います。
息を吸うように勉強する風土
本当にみんな息を吸うように勉強しています。
エンジニア組織全体としての技術学習の場としては、毎週月曜日と火曜日の午前にSTDDiという社内勉強会があり、クローズドでやっているのがもったいないような濃密な内容の発表が行われています。
また、有志での勉強会も、日々色々なものが立ち上がっており、私も、スクラム開発について学ぶ会やアルゴリズム勉強会などに参加したり、これから参加予定だったりしています。
こういった勉強会に限らず、各自が自身の目的意識と興味関心に応じて、常に勉強しています。
徹底したチーム開発
個人プレーの単なる総和をチームの成果とするのではなく、チームとしての成果の最大化を第一に考える業務スタイルが定着しています。
その帰結として、業務時間に占めるミーティング時間の比率は結構長いのですが、どのミーティングも目的が明確であり、個人としてもチームとしても明確な成果が得られるため、無駄と感じることがありません。
私自身、入社以前は、ミーティングに長い時間を割くことに否定的な感覚を持っていましたが、キャディで仕事をしていく中で、実装に着手する前にきちんと時間を割いてチーム内での意識合わせを徹底することが、結果としてその後の実装作業のパフォーマンスを最大化することに繋がっているのを感じています。
また、チーム内でのコミュニケーションが徹底されている結果、チームメンバー全員が、チーム内で進行している全てのタスクについて当事者意識を持つ風土が根付いています。そのため、実装を進める中で分からないことを他のチームメンバーに相談すると物凄い勢いで有益な知見が集まってきますし、業務の属人化も防止されています。
TechとBizの絶妙なバランス
キャディの組織は、単なるTech優位でもBiz優位でもない、絶妙なバランス感覚の上で成立しているように感じます。
例えば、キャディでは、開発現場でのコーディングに従事するエンジニアのひとりひとりが、Biz部門のSlackチャンネルに勝手にJoinしてプロダクト開発に活かせる課題を発掘したり、実際にプロダクトを利用しているBiz部門メンバーの業務を見学に行ったりといった、ビジネスに食い込んだ動きを当たり前のように行っています。
一方、Biz部門のメンバーも、単にシステムのここが使いにくいといったユーザー目線でのフィードバックにとどまらず、システムを活用することでキャディ全体としてどうすれば価値を最大化できるのかという全体観のある目線でTech部門と関わっています。
そして、強力なPdM陣が、TechとBizを俯瞰する立場から、日々、プロダクトのあるべき姿について思索し、開発チームを牽引しています。
このように、Tech部門とBiz部門が当たり前のように相互の領域に食い込む風土を前提として、Tech部門とBiz部門が対等な関係で事業に取り組んでいます。
無限に勉強できる
経営陣から現場のメンバーまで、TechもBizも、熱量の高いメンバーが日々新たな挑戦をし、その結果得られた知見が社内にフィードバックされているので、日々の業務に取り組んでいるだけでも、技術から事業、組織運営まで、無限に勉強することができます。
生きていく上で何よりも恐ろしいのは退屈だと思いますが、キャディで働いていれば、仕事に飽きるということは当分なさそうです。
そして何より嬉しいのは、勉強したことを活かす場所もまた無限に存在するということですね。
このような環境に身をおけることは最大の福利厚生であると感じます。
積極募集中です
色々と魅力を述べましたが、魅力的な環境にただフリーライドしているだけではつまらないので、これから頑張って成果を出していきたいなと思っています。
さて、キャディでは、TechもBizも職種を問わず、ミッションとバリューに共感して参画してくださる皆様を積極募集中です。
私自身と関係の深いエンジニア職について言えば、フロントエンド、バックエンド、インフラ/SRE、アルゴリズムなどの全領域で、経験豊富なシニアエンジニア/EMの方から、私と同じく経験は浅いがこれからどんどん勉強していきたい、という方まで、幅広く募集しています。
ご興味を持ってくださった方は、是非お気軽にご連絡ください！
この記事が気に入ったらサポートをしてみませんか？