SIerからディップのテックリードに。入社間もなくプロダクト共通のクライアント認証基盤を開発、きっかけはアーキテクトハックでした。

新卒入社した大手商社系SIerからディップに転職。テックリードとして活躍する佐草さん。未経験分野だった認証基盤の開発に「やりたいです」と挑戦を希望し、手がけたクライアント認証基盤が間もなくリリースに。部署を越えて社内システムの見直しを行うアーキテクトハックへの参加が、そのきっかけでした。 

入社してすぐ、社内システムを横断的に見直す場に参加

吉牟田：入社当初はバイトルPROのAPI開発プロジェクトに携わっていて、アーキテクトハックへの参加をきっかけにクライアント認証基盤の開発を手がけるようになったと聞きました。 

 佐草：ディップでは「役職を問わず誰でも参加できる、社内のシステムを横断的に見渡して改善する取り組みがある」という話を入社前の面談時から聞いていて、興味がありました。それで入ってすぐにグロースエンジニアリング課の先輩である栗生（和明）さんに質問したところ「アーキテクトハックのことだね。参加してみる？」となり、早速参加することを決めました。 

 吉牟田：どういった内容で開催されていたのでしょうか。 

 佐草：開催は月曜日と木曜日の週2回。CTO、テックリード、スマホアプリエンジニア、インフラエンジニアなど、技術に興味関心の高いさまざまな人が集まっています。いくつかの大きい課題ごとのタスクフォースがあって、20～30人が集まり、その進捗を発表して共有するのが月曜日。木曜日は5～6人と少人数での雑談に近くて「この点が難しくて困っています」と個別に相談したり、「いよいよガラケーのサービスが終了するね」みたいな会話から派生して、トランシーバーの話になったり、自由に話題が広がっていく集まりでした。 

 吉牟田：佐草さんがクライアント認証基盤の開発に携わることになった経緯は？ 

 佐草：木曜日の集まりで、クライアント認証の課題が話題になりました。現状ではプロダクトごとにそれぞれ開発しているものの、いっそ共有で使える基盤をつくったほうが良いのではないかとなったのです。 

 吉牟田：アーキテクトハックに参加したのはいつ頃からだったのですか？ 

 佐草：入社1ヵ月も経たない2021年の7月に認証基盤の話になって、取り組み出したのは12月頃だったと思います。その時点ではバイトルPROのAPI開発に1人月で入っていたので、並行してゴリゴリやっていました。それから4月の人事異動にあわせて、バイトルPROのAPI開発からは離れました。 

 アーキテクトハックのタスクを誰がやるかはルールで決まっているわけではなく、やりたい人が手を挙げて携われ、自分で時間を見つけて取り組んでいく方式でした。クライアント認証を手がけるにあたっては、担当業務との配分を考え、上司と相談して、その割合をコミットし、課長の山崎（麻衣子）さんやマネジャーの石川（大祐）さんには「次は認証をやりたい」と希望を伝えていました。 

 吉牟田：プロダクトごとにそれぞれクライアント認証機能を開発しているとは、どういった状況だったのでしょう。 

 佐草：たとえば募集原稿を入力して公開するシステム、応募管理のシステムなど、さまざまなサブシステムの開発チームが、それぞれ認証機能をつくっていて、これから先のプロジェクトでも同じようになる見通しでした。そこで共通のプラットフォームをつくり、ひとつのID・パスワードでログインできるようになれば、クライアント様の二度手間三度手間が省けます。結果的に新しいシステムを開発するうえで、認証を気にすることなく、プロダクトのコアの機能に注力でき、効率的に進められます。 

 吉牟田：今、2022年7月末ですが、現時点での進捗状況は？ 

 佐草：リリースする準備が整い、9月末の稼働を予定しています。それまでは待機しながら、さらに改善を加えてブラッシュアップしていく段階です。 

 吉牟田：開発にあたって、苦労した点はどこでしょう？ 

 佐草：一人のクライアント担当者様がA店とB店と異なる店舗の両方を応募管理している場合もあり、それをスムーズに認証するのがなかなか大変でした。 

 吉牟田：クライアント認証基盤を共通化する目的は、これで達成できることになります。その次は？ 

 佐草：もう少し先の話になりますが、バイトル、はたらこねっと、コボットのアカウントも統合したいと考えています。今は複数のサービスにご契約いただいているクライアント様がログインするにあたって、異なるID・パスワードを設定して入力していただいていますが、SSO（Single Sign On）ができれば、ユーザビリティがぐっと高まります。異なるサービスでアカウント統合をするとなると、登録されているデータも異なりますので、どのように整理するかなどを、これから考えていかなければなりません。 

 SIerからディップへ。転職するにあたって感じた魅力は？ 

吉牟田：転職先として、どういう理由でディップを選ばれたのでしょうか。 

 佐草：新卒でSIerに入ったのは大規模システム開発を手がけたいと考えたからでした。とくに金融システムに興味があり、24時間365日稼働する、絶対に停止させてはいけないインフラに携わることで技術力を高められると期待しました。実際に入社して6年間働くなかで金融システムの開発を手がけ、その後は海外ベンチャーとの協業でSaaSのSRE（Site Reliability Engineering）に従事しました。しかし次第に自分で手を動かす機会が減っていき、「技術者として、もっと挑戦したい」という思いが募って、転職を意識するようになりました。 

 そこで次の転職先として希望したのが、他社のサービスを請け負って開発するSIerではなく、自社のプロダクトを手がけるテック企業。転職エージェントにキャリア相談するなかで「だったらディップさんが良いかもしれませんね」と言われたのです。正直、最初はあまりIT人材が活躍しているイメージを持てませんでしたが、調べてみたら、エンジニアの内製化に力を入れて「ガンガン作れる200人体制」を掲げていて、テック企業としての組織の拡大期を体感できる貴重なチャンスだと思えました。それが魅力で入社を希望したのです。 

 吉牟田：実際に入ってみて、どう感じましたか？ 

 佐草：議論を重ねて、しっかりと精査したうえで、システム課題の解決に論理的に取り組んでいる点に驚きました。それとSIer出身の中途社員が想像以上に多かったことも意外でした。 

 吉牟田：前職のSIerでの経験が役立っていることはありますか？ 

 佐草：金融システムに携わった経験から、大規模システムの仕組みを理解できているので、基礎的な知識として活かせています。海外ベンチャーとのプロジェクトで採用したSaaSのクラウド技術は、そのまま目に見える形で役立っていますね。クライアント認証基盤の開発経験はありませんでしたし、私自身、何か特定のスキルが尖っているというわけでありません。アプリとインフラが両方できて、クラウドの知識もあったので、その総合的なスキルを見込まれたのかな、と思います。 

 吉牟田：クライアント認証基盤の開発は未経験だったものの、面白そうだと感じて、手を挙げたわけですね。勉強も必要だったのではないでしょうか？ 

 佐草：認証基盤プラットフォームとして、Auth0（オースゼロ）をメインに使うことになっていましたが、それで正解なのかわからず、GoogleのFirebaseなど同種のサービスもあったので比較から入りました。これまでに認証機能を手がけてきて、詳しい人も社内にいるとは思いましたが、いずれにせよ専門知識が必要になるし、人に聞くよりも、自分で調べて覚えたほうが良いだろうと判断して、独学で頑張って勉強しました。 

20代のうちに新しい技術知識をどんどん吸収していきたい。そんな気持ちがあったので、アーキテクトハックに参加して、手を挙げて挑戦できたことは大きいです。勇気はいりましたが、任せてもらえた。こういう議論への参加は普通、管理職に限定されることも多いと思いますが、一つのプロダクトに関してではなく、全体を俯瞰する議論に入社したばかりの社員でも参加できるのは、ディップならでは面白さだと思います。今は週1回、テックリードが中心となって集まっている「ディップの理想のシステムを考えよう」という会があって、そこに参加しています。 

 社内の新しい取り組みに挑戦していくのがR&Dユニット 

吉牟田：一緒に働くなら、やはりご自身と同じように挑戦意欲の高い人が良いですか？ 

 佐草：システムも組織も、ディップはまさに今、変革期。どんどん新しくなっているタイミングで、意見を言えば反映されやすい。ですから挑戦したい人にはおすすめです。転職先を考えるにあたって、私が理想としたのが、自学する習慣のある優秀なエンジニア同士が一緒に仕事をして、吸収し合う環境でした。ディップには若手からベテランまで、技術の追求に貪欲な人が周りにたくさんいます。技術を愛していて目的を果たすための手段として活かせる。マネジメント職など、どんな立場になっても新しい技術を学ぼうとする。そんな人と一緒に働きたいですね。 

 吉牟田：クライアント認証基盤をリリースして運用フェーズに入るのは間もなくです。バイトル、はたらこねっと、コボットのアカウント統合はもう少し先の話ということですが、次は何をやるか決まっているのでしょうか？ 

 佐草：R&Dユニットは社内の新しい取り組みに挑戦していく集団です。稼働後のプロダクト改善は別のチームに引き継ぐことを考えていて、次の取り組みとして考えているのは生産性の計測。どの施策にどのくらいのコスト、人数、時間がかかり、どういった結果が出たか。具体的にはPV数、応募数、システム関連なら処理速度、節約できたコストを定量的に見られるようにしたい。そして、ゆくゆくはエンジニアの生産性を可視化したいと考えています。これはエンジニアを評価するためというよりも、効率良く開発する体制をどのように築けるかが目的です。CTOの豊濱（吉庸）さんと、Slackのtimesでワンツーワンの雑談をしていて「面白そうですね」みたいな話をしたことから動き出しました。まずはちょっとやってみる感じで、やってみて「全然意味がない」となる可能性もありますが、それも一つの成果だと思います。ほかにも面白そうなテーマはたくさんありますので、どんどん手を挙げて、挑戦していきたいですね。 

取材・執筆・撮影／吉牟田 祐司（文章舎 ）