「表現したい」から「チームで創る」へ。好奇心と当事者意識が導いた、エンジニアの軌跡

はい。「ディップのサービスの未来を支える」という目標のもと、その技術基盤を作るチームにいます。今はテックリードとして、チームとしてのアウトプットを最大化することに挑戦しているところです。

原点は中学時代の情報の授業ですね。HTMLで自己紹介サイトを作ったのが、なんだか楽しくて。それで大学はコンピューターサイエンスを選んだんですが…いざ入ってみたら、メモリとかCPUとか、基礎理論ばかりで。正直、全然楽しくなかったんです（笑）

単位は取らなきゃいけないので授業は受けつつも、「このままでいいのか？」とモヤモヤしていて。そんな時にふと、「あ、そういえば自分、サイトとか選手名鑑作るのが楽しかったんだ」と思い出したんです。

それで大学とは別に、自分で「Railsチュートリアル」を始めてみました。そしたら、これが衝撃的で。自分の書いたコードで、Webアプリケーションが実際に動いて、ブラウザに表示される。「これだ！」と思いました。

まさに。自分の考えたものを表現できるのがとにかく嬉しかった。それに、作ったものを人に見せた時の反応が、自分にとってすごく重要だったんだと気づきました。

例えば、Google MapのAPIを使って、「レビュー数順で場所を検索できるアプリ」のアイデアを思いついて作ってみたんです。それを文系の友達に話したら、「そのアイデアいいね」「そんなことできるんだ、すごい」って言われて。それがすごく気持ちよかったんです。

そうなんです。「技術を使って何かを表現し、価値を届けること」が好きなんだな、と気が付いたんです。だから就職活動の軸も明確でした。toC（一般消費者向け）でユーザーさんの反応がダイレクトに見えること。そして、自社サービスを開発していること。

はい。中でもディップを選んだのは、ちょっと逆張り的な視点もあって。『バイトル』という非常に大規模なサービスでありながら、当時は開発組織としてはまだ成熟しきっていない、発展途上の部分があると感じたんです。

はい。「ここなら、新卒でもオーナーシップを持って色々やらせてもらえるんじゃないか」と期待しました。実際、入社してみてその予感は当たっていましたね。

そうですね。1年目に配属された『バイトル』のチームでは、フロントエンドの技術的な提案を積極的に行っていました。当時の『バイトル』のCSSは、いわゆるスパゲティコードになっていて、歴史的経緯もあって「1個直したらどこに影響が出るか分からない」という状態だったんです。

はい。これでは改修スピードも上がらないし、何より品質が担保できない。そこで、デザイナーさんが作ったカンプデザインと1ピクセルのずれも許さないように、「ビジュアルリグレッションテスト（画像回帰テスト）」の導入を提案しました。

技術的に可能だという確信はありましたし、これがチームの課題解決につながると信じていました。その仕組みを入れたことで、変更による意図しない表示崩れを機械的に検知できるようになりました。「これで安心してリリースできるようになった」とチームメイトからも言われましたし、社内の表彰もいただけたので、やって良かったなと思っています。

根底にある思いは同じですね。「人にきっかけを与えたい」「ポジティブな影響を与えたい」という気持ちが強いんだと思います。自分の知見を技術発信することで、チーム全体の底上げにもなりますし、何より「横山はこの辺の領域に詳しいらしいぞ」と周りに認識してもらえる。

はい（笑）そうやって自分の得意領域を認知してもらうと、「今度困ったら聞いてみよう」と声をかけてもらえるようになって、結果的に「自分のやりたいことをやりやすくなる」んです。社外のLT会で登壇したり、テックブログを書いたりすることも、全部自分のやりたい仕事や挑戦につながっている感覚がありますね。

はい。当時いた『バイトル』のチームが成果を出していたこともあり、「『スポットバイトル』のWebもこのチームで」と任せてもらえることになりました。すごく雰囲気の良いチームで、技術的にも優秀な先輩たちに囲まれて充実していました。

はい。ただ、その後に大きな転機があって。事業部が分離することになったんです。それはつまり、今まで一緒にやってきた『バイトル』のチームメンバーと離れる可能性があるということでした。

すごく悩みました。でも、『スポットバイトル』の開発を続けることへの好奇心やパッションが強くて。「自分のフロントエンドの知見を活かして、この新しいサービスをもっと成長させたい」と。最終的には自分のパッションを信じて、自ら「『スポットバイトル』チームに残りたい」と希望を出しました。

まず、技術的なキャッチアップももちろんありましたが、それ以上に大変だったのが「プロダクトの仕様理解」ですね。それまでユーザー向けのWeb開発をしていたのが、今度はクライアント（企業側）が使う「管理画面」のチームに合流したんです。

まったく違いました。管理画面は、ユーザー向けWebとは比べ物にならないほど機能が爆裂に多くて…。急に複雑なシステムを扱うことになり、技術的な側面よりも、スポットワークのドメイン知識やプロダクトの仕様をキャッチアップするのが本当に大変でした。

もう、ひたすらプロダクトを触り倒しました。コードを読んで理解しようとしても、前提知識がなさすぎて追えないんです。だから、ステージ環境で、自分がクライアントや営業担当になりきって、「求人を登録する」「事業主を作る」「店舗を作成する」「じゃあこの店舗を消したらどうなるんだ？」と、考えられる限りの操作を実験し続けました。

そうやって「体験」することで、コードだけでは分からなかった「なぜこの実装があるのか」という意味が、ようやく繋がっていきました。

はい。Webのフロントエンド（React）で学んだ宣言的UIの考え方がFlutterにも応用できたので、技術的なキャッチアップは意外と苦しまずに済みました。ただ…『スポットバイトル』のプロジェクト全体を振り返ると、自分としては「やり切った」という感覚はなくて。

はい。リリースはできたものの、「もっと自分の力を発揮したかった」「自分が引っ張ってリリースに導いた感覚がない」という悔しさが強く残りました。

振り返ってみると、当時の自分には「圧倒的な当事者意識が足りなかった」んだと思います。とにかくリリースを最優先するスピード感の中で、ついていくのに必死だった。もちろんスピードは大事なんですが、「今は技術的な提案をするタイミングじゃないかも」「チームのスピードを落とさないようにうまくやろう」と、自分で勝手にリミットをかけて、提案を飲み込んでしまっていたんです。

そうなんです。でも、後から思えば「もっと発言しなきゃダメだったな」と。Webは重要じゃないんだと諦めるんじゃなくて、同じWebでもクライアント管理画面の方で技術提案するとか、技術に囚われず「事業価値」に貢献する提案とか、もっとできたはずなんです。その悔しさが、今もすごく強く残っています。

間違いなくそうです。『スポットバイトル』で感じた「当事者意識が足りなかった」という悔しさがあるからこそ、今のテックリードとしての役割に活かしたいと思っています。

正直、最初は「自分が頑張るだけじゃ、期待する成果にまったく及ばないんだ」ということを痛感しました。『スポットバイトル』から異動してきたばかりで『バイトル』の仕様も深くはわかっていなかったですし、自分だけでは歯が立たない。

でも、そこが面白いところで。個人の成果を追っていた時は、自分が褒められるのが一番でしたけど、今はチームとして褒められると、なんというか…個人の時とは違う「チームの成果を喜べる」という感覚があるんです。学生時代に感じた「表現する楽しさ」とはまた違う、チームで大きな価値を創り上げる楽しさを今、すごく感じています。

ディップは、正直に言って「課題が山積み」です。『バイトル』は歴史のあるシステムなので、老朽化したコードも多く、新しく入る方は「こんなシステムなんだ」と驚くこともあるかもしれません。

でも、大事なのはそこからです。「良くないよね」と嘆くだけで終わるのではなく、「だからもっとこうした方がいいと思う」と、自分で解決策を出せる人。そういう人がディップには合っているし、楽しめると思います。

はい。新人のうちは「足を引っ張らないように」と考えてしまいがちですが、そんなことはなくて。「自分が引っ張るんだ」「自分が圧倒的な当事者意識を持つんだ」という姿勢が、本当に一番大事だと思います。僕自身、スポバでの悔しさがあったからこそ、今そう強く思っています。そういう熱量のある方と、ご一緒できると嬉しいですね。