「AIによって、ただ動く機能を作るだけのエンジニアは淘汰されるかもしれない」 ── 。 そんな強い危機感を抱き、クラシル株式会社のバックエンドエンジニアへと転職した久保寺さん。 久保寺さんが思う、AI時代でも価値を出せるエンジニアとは。 そして、「新規サービスの立ち上げ」と「大規模サービスの運用」の両輪を回す、クラシルならではの「フルサイクル開発」とは一体どのようなものなのか。 インフラから開発までを一気通貫で担うことで得られる圧倒的な成長や、ビジネス視点を持って開発に挑む面白さについて、リアルなストーリーを語っていただきました。
久保寺 勘太(くぼでら かんた) 新卒でUUUM株式会社に入社し、フルスタックエンジニアとして自社プラットフォームのリプレイスなどに従事。2024年9月にバックエンドエンジニアとしてクラシル株式会社に入社し、「レシチャレ」のサーバーサイド開発や運用、新機能開発チームに配属された後、「うさぽ」開発責任者として立ち上げを牽引する。好きなYouTuberは「東海オンエア」。ニックネームはkantyさん。
旅先の出会いからフルスタックエンジニアへ。そしてAIへの危機感 ── まずは、kantyさんがエンジニアになったキッカケから教えてください。
kanty: 学生時代に2ヶ月ほどバックパッカーとして旅をしていたのですが、パソコン1つ抱えて旅をしながら稼いでいるエンジニアの人たちに出会い「旅をしながら仕事をするなんて、その働き方がかっこいいな」と思ったのがキッカケでした。 実際にコードを書いてみると、自分はロジックを組み立てるプログラミングそのものが好きだと気付き、エンジニアに向いているかもと思ったんです。 そこから、現役エンジニアの方にメンターになってもらえる教育サービスを利用して、実践的なサポートを受けながらプログラミングのスキルを磨いていきました。
── 新卒でUUUM株式会社に入社した理由と、当時の業務について教えてください。
kanty: もともと好きだったクリエイターが所属していたこともあり、まずはインターンに参加したんです。その流れでありがたいことに声をかけてもらい、フルスタックエンジニアとして入社しました。
ただ、フルスタックと言っても新卒だったので、“全部が強いオールラウンダー”ではなく、 “広く浅く全部を触る器用貧乏” のような状態でした。 最初に参加したプロジェクトは、PHP5系のSymfonyで作られていたクリエイター向けの社内プラットフォームを、PHP8系のLaravelへと乗せ替えるフルリプレイス案件です。 その後は、YouTubeの膨大なインサイトデータをAPIで取得し蓄積していくようなデータ基盤の構築なども経験しました。 ── そこから転職を考えたのはなぜですか? 次のキャリアで「これを実現したい」という想いは何だったのでしょうか。
kanty: 転職を考えた一番の理由は、ChatGPTをはじめとする“AIの台頭”に対する強い危機感でした。僕がエンジニアになって1〜2年目の頃にAI技術が一気に普及し、コンテキストさえ渡せばかなり精度の高いコードをAIが出力してくれるようになり…。 AIがコードを書ける時代だからこそ、言われたものをそのまま作るだけではなく、 機能を求める人が本当に実現したいことを能動的に引き出し、より本質的なプロダクトを形にしていく力 が必要になる。 もともと自分は、データの流れを把握してロジックを深く考えたり、泥臭くパフォーマンスチューニングを行ってユーザー体験を改善したりと、サーバーサイド領域の開発が好きだったので、そこに絞って専門性を磨ける環境へ行きたいと思い、転職を決意しました。
圧倒的なトラフィックと、ビジネスサイドの「近さ」を求めてクラシルに ── 多くの選択肢がある中で、なぜクラシルを選んだのでしょうか?
kanty: 一番の理由は、転職動機の通りAIに代替されないスキルと専門性を身につけられると思ったからです。その上で、決め手は大きく2つあります。 1つ目は、 「toC向けの大規模トラフィックを持つサービス」 であること。 前職で開発していた社内用システムはユーザーが限られているので、シビアなパフォーマンスチューニングを求められる場面は多くありません。だからこそ転職先では、トラフィックが膨大で高度なインフラ設計やパフォーマンス改善が必須となる「toCサービス」に携わりたいと考えていました。
転職活動では2、3社受けましたが、国内でもこれほど大規模なユーザーを抱えるtoCサービスを経験できる会社はそもそも少なく、その環境自体にとても希少価値があると思いクラシルへの入社を決めました。 ── AIでは代替しきれない複雑なチューニングや設計を大規模トラフィックの中で経験できるのは、エンジニアとして非常に魅力的ですね。2つ目の理由は何でしたか?
kanty: 「ビジネスサイドとの距離が圧倒的に近い」 ことです。 クラシルでは、自分が開発する機能に関わるビジネスサイドのメンバーが近くの席に配置されることが多く、経営陣とも気軽に話すことができます。 また、ビジネスサイドのメンバーが自らSQLのクエリを書いてデータ分析をしていることにも驚きました。本来ならバックエンドエンジニアがデータを出すような場面でも、自らクエリを書けるほど。 こうした 物理的な距離やエンジニアリングやプロダクトへの理解 も含め、ビジネスサイドと密に連携しながら開発できる環境で、技術力だけでなくソフトスキルも磨いていきたいという思いも、転職の動機のひとつでした。
開発からインフラ、障害対応までやり切る。クラシルの「フルサイクル開発」 ── 実際にクラシルへ入社されていかがでしょうか?また具体的にはどのような業務に携わってきましたか。
kanty: バックエンドエンジニアとして、「Ruby on Rails」を使った開発に携わっています。最初は「レシチャレ」のアフィリエイト機能などを担当し、その後はアプリ利用継続率の向上に向けた機能開発チームで約3ヶ月間、開発を担っていました。 クラシルでは開発からリリース後のインフラ運用までを一気通貫で担う「フルサイクル開発」を導入しているので、その経験を積むことができました。 ── クラシルの「フルサイクル開発」は、どこからどこまでを担当するのでしょうか?
kanty: 基本的には、「全て」です(笑)。 設計や実装はもちろん、フェーズに応じてデータベース設計やインフラ構築も行います。そして機能をリリースして終わりではなく、「New Relic」や 「AWS CloudWatch」のダッシュボードを使って、クエリの発行数やパフォーマンス、レスポンスタイム、CPUやメモリ使用率などリリース後のメトリクスの監視も行います。
異常を検知したら、スロークエリのログやメトリクスのスパイク、エラーの増加傾向などを追って 自ら障害調査までを担うのがクラシルのフルサイクル開発です。
原因を特定し、自分でパッと直せるものはその場で実装して修正し、難しそうであれば関連チームにエスカレーションする。障害が起きた際の対応や、その後のポストモーテムまで、バックエンドエンジニアが主体で担っています。 ── インフラ周りの対応や運用範囲は組織よって異なると思いますが、kantyさんは運用経験があったのでしょうか?
kanty: インフラ構築や運用周りは未経験です。なので、 joeさん(SREチームリーダー) を含む、SREチームにサポートしてもらいながら技術領域を広げていきました。
クラシルには「まずは自分で考えてやってみる」という文化がありますが、開発者が未経験領域にもスピード感を持って挑戦できるのは「SREが全力で支えくれる」という、強い文化・土壌があるからだと思っています。 ── 実際にプロセスを回してみて、どんなところに「難しさ」を感じますか?
kanty: 「レシチャレ」は複数のチームが関わる大きなプロダクトなので、日々発生しているすべてのアラートを完璧に調査し切るのは難しいです。だからこそ、「検知したアラートに対してどこまで優先順位をつけて対応するか」の意思決定が一番大変だと感じます。 属人性を排除し透明性を保ちながら、現状を開発メンバー全員に伝え、自分たちだけで解決できない問題はSREチームの力を借りながら、バックエンドが主体となって進める。 泥臭い努力ではありますが、こうした改善を会社としてしっかり評価してくれるのもクラシルの良いところです。 ── では、「やりがい」や「魅力」はどうですか?
kanty: 「ECS」や「DynamoDB」、「Terraform」を用いたIaC運用、「New Relic」でのパフォーマンスチューニングなど、多岐にわたる技術を実務で身につけ、バックエンドとインフラの両方を俯瞰で見られるようになれたことは、エンジニアキャリアでの大きなやりがいでありメリットだと思います。 インフラのメトリクスを日常的に見ていると、「このコードだとインフラのパフォーマンスにAのような影響がある」という因果関係がわかるようになり、システム全体のアーキテクチャを深く理解することができます。 クラシルでフルサイクル開発を経験してから、 開発や設計への思考がドラスティックに変わりましたね。
わずか2ヶ月での新規立ち上げ。0→1フェーズの技術的決断 ── 直近では、新規サービス 「うさぽ」 の開発責任者も担当されたそうですね。0→1の立ち上げフェーズはいかがでしたか?
kanty: ある日突然、 funzinさん(開発BU マネージャー) から「新規サービスの開発責任者、やってみます?」と声をかけていただいたのがキッカケです。
正直、サーバーサイドの経験もまだまだ発展途上だったので不安はありましたが、「こんなチャンスは二度と来ないかもしれない」と思い挑戦してみました。 チームは私を含め、各領域(サーバー、iOS、Android、デザイナー)が1名ずつの少人数編成で、そこで私は開発責任者として、サーバーやインフラの技術選定や設計を行い、PdMと仕様のすり合わせをしながら意思決定をする役割を任された形ですね。 ── 立ち上げにおいて、最も苦労した技術的・組織的な課題は何でしたか?
kanty: 要件を聞いてからリリースするまでのスケジュールがタイトだったのが大変でしたね。 技術的な面でも、非同期処理基盤の新規構築などインフラの専門領域における挑戦が多かったので、チーム外のバックエンドエンジニアにも意見をもらいながら設計を固めつつ、SREチームにも手厚くサポートしていただきました。 ── 非常にタイトなスケジュールだったとのことですが、リリースに向けた「スピード」についてはどのように意識されていましたか?
kanty: 前提としてクラシルの開発において、「検証可能な最低限の機能で速くリリースし、ユーザーの反応を確認しながら効果検証・改善をする」という方針をとっています。 実際、予定していたリリース日に間に合わせるため「初期に見積もった機能の中から優先度が低いものは初期リリースから落とす」という決断もしました。
ただこの判断をするには、事業インパクトから逆算する必要があるので、PdMに頼り切るのではなく、 エンジニア自身が「なぜこの機能は一旦落とすべきか」という意見 を持ち、主体的に提案しながら進めていきました。
ただし、すべてにおいてスピードを最優先するわけではありません。
例えば、影響範囲が大きいホーム画面への機能実装などは入念な準備を行います。定期的にABテストも実施して極限まで負荷を減らすチューニングをしてから限定公開し、データを見ながら徐々に調整するという慎重なアプローチも使い分けています。 ── メリハリをつけて進めているのですね。「スピード」を追求しつつも「品質」を担保するために、チームで何か工夫をされていたのでしょうか。
kanty: クラシルでは、品質を担保するためにいくつかの取り決めがあります。 まず、 運用監視として「Warningチャンネル」と「Alertチャンネル」を設けること 。
Alertチャンネル ここに上がったものはインシデント扱いとなり、即座に担当者を選定して対応することが必須です。 Warningチャンネル: パフォーマンスの劣化や、放置するとインシデントに発展しうる要因を早期に検知するためのチャンネルです。ここに上がったものは即時対応までは求めないものの、担当者と対応期限を明確にすることが義務づけられています。
また、新機能の開発時には設計書の作成も必須です。 DB設計・データフロー・レスポンスフォーマットなどを詳細に記載する所定のフォーマットがあり、設計レビューのプロセスなども組み込まれているので、それに沿って設計書を作成する。 これらの仕組みによって、品質上の問題を確実に後追いで改善するサイクルが回るだけでなく、実装前の段階でもしっかりと品質を担保できています。
ビジネス視点を持つ「野心的なエンジニア」へ ── クラシルに入社されてから、ご自身の仕事への向き合い方やスキルセットはどう変化しましたか? 前職の経験が活きた部分と、新たに身につけたことを教えてください。 kanty: クラシルでは「Ruby on Rails」を使っていますが、前職では同じMVCモデルの「Laravel」を使っていたので、API開発の業務自体はスムーズに入ることができました。また、前職でレガシーコードのフルリプレイスを経験したことで、「将来のエンジニアを苦しめる技術的負債は極力生まない」というマインドが根付き、それが今の設計にも活きています。 逆にクラシルで新たに身につけたのは、 大規模トラフィックを考慮したスケーラブルな設計やインフラのスキル です。多重リクエストへの対策や、ホーム画面のようにアクセスが集中する機能での泥臭いパフォーマンスチューニングなどは、先輩社員に聞きながら実践で習得していきました。 先ほどお話した「うさぽ」立ち上げなどのスピード感や、ビジネスサイドと密に関わりながら開発する姿勢も、クラシルで大きく変わった部分ですね。 ── 新規サービス「うさぽ」の立ち上げも経験されましたが、今後、プロダクトやご自身のキャリアをどのように育てていきたいですか?
kanty: これまでは、いち機能の開発が中心でしたが、「うさぽ」の立ち上げでアプリ全体を見るようになり視座が上がりました。 今後プロダクトとしては、「レシチャレ」や「うさぽ」の過去の技術的負債を定期的に解消しながら、ビジネスの成長を止めないよう新機能などもスピーディーに投入し続けていきたいです。 例えば、ホーム画面に載る機能などは非常に負荷が高いため、アプリの特性を熟知した上で、泥臭くパフォーマンスチューニングやアーキテクチャの改善を続け、より良いプロダクトに進化させていきたいです。 ── 最後に、今のクラシルでは、どのような意識を持つエンジニアが合うと思いますか?
kanty: 知的好奇心を持って、新しい技術にアンテナを持ち、積極的に提案しプロダクトやチームに取り入れられるような人が合うと思います。 そして何より重要なのは、 「エンジニアでありながら、ビジネス視点を持てる」 こと。プロダクトを通じた売上向上やKPI達成を、「自分ゴト」として捉えられるかどうかだと思っています。
AIがコードを書いてくれる時代だからこそ、ビジネスコンテキストを深く理解し、インフラからアプリケーションまで横断的に設計・運用できるエンジニアの価値は高まり続けます。
「AI時代に負けないキャリアを創る」という野心を持った方と、圧倒的なスピード感の中で一緒にプロダクトを成長させていきたいです!
── kantyさん、ありがとうございました!
ーーーーーーーーーーーーーーーーーーーー
エンジニア採用情報 ーーーーーーーーーーーーーーーーーーーー
エンジニア部門では、下記の職種を採用中です。 ご応募お待ちしております!