AIは「前提」であり「相棒」。ディップ新卒1年目が語る、最先端開発現場での挑戦と成長の軌跡

ディップ株式会社の次世代を担う若手エンジニアたちは、今この瞬間、どのような環境で、どのような技術に触れているのか。今回お話を伺ったのは、2025年に新卒入社し、現在はCTO室直下のAI機能開発チーム「AI Embedded」で活躍する吉岡拓真さんです。学生時代の「動けばいい」開発から、研修を経て、100万人が使うサービスを支える「責任ある開発」へ。AIを徹底的に使いこなし、ビジネス視点をも備えたプロフェッショナルへと進化を続ける吉岡さんの1年間の軌跡に迫ります。

岩城：まずは、吉岡さんが今どのようなチームで、どんな業務に携わっているのか教えてください。

吉岡：私は現在、CTO直下の「AI Embedded」というチームに所属しています。全社横断的なレコメンドエンジンや、AIエージェントの開発を担当する部署です。バックエンドエンジニアとして採用されましたが、今のチームではPython/FastAPIの実装に留まらず、機械学習プラットフォームのVertex AIや、インフラ構成をコードで管理するPulumiなど、Google Cloudを基盤としたかなり幅広い技術スタックに触れています。

岩城：まさに最先端ですね。今のレベルに到達するまで、どのようなステップを踏んできたのでしょうか？

吉岡：実は、入社前から段階的なステップがありました。まずは2月頃までの「内定者インターン」です。『スポットバイトル』のチームに入り、実際にリリースされるコードを書く経験をさせてもらいました。そこで実務の空気感に触れた後、4月からの「エンジニア新卒研修」があり、基礎を学びました。

岩城：その研修は、どのような内容だったんですか？

吉岡：新卒エンジニア5人で、社内ツールの開発から運用まで、スクラム開発で全て自分たちで行うというものです。単に作るだけでなく、スクラム開発やDDD（ドメイン駆動設計）、クリーンアーキテクチャといった高度な設計手法を徹底的に教えていただきました。CTO協会で主催している新卒研修にも参加させてもらいましたね。さらに、ここでAIによるコーディングの試行錯誤もみんなで行ったんです。最先端の技術を詰め込んで、自分たちが作ったものが今も社内で使われている。常に先輩エンジニアからFBをいただいていたのでスキルももちろん上がりましたし、やっぱり使ってもらえるのは嬉しいですね。

岩城：学生時代はGoを使っていたとのことで、配属後はPythonを使っていますよね？キャッチアップも大変だったと思いますが、どうやって乗り越えたのですか？

吉岡：とにかく「筋トレ」のようにインプットと実装を繰り返しました。実はPythonはあまり使ったことがなかったんです。配属当初はPythonの動的型付けと、Goのような静的型付けの違いに戸惑うこともありましたが、分からないことはすぐに先輩に聞くと決めていました。単に答えを聞くのではなく、「なぜこの設計なのか」「長期的な保守性をどう考えているか」といった意図まで深掘りして聞き、それをその日のうちにコードに落とし込む。本を読んで学んだことを翌日の実装に即反映させる、というサイクルを回し続けたことで、速いスピードで実力がついていく手応えがありました。社内でみんなが情報共有しているというのもありますね。キャッチアップの機会はたくさんあったので、常に吸収するつもりでいました。

「動けばいい」から、「事業価値」へ

岩城：学生時代の開発との違いを、改めてどう感じていますか？

吉岡：一番の違いは「コードに対する責任」ですね。学生時代はとにかく「動けばよし」でした。でも社会人は、自分が書いたコードがリリースされ、何百万人のユーザーに影響を与えるという事実に、早い段階で向き合うことになります。バグが出れば100万人が困る。そう考えると、保守性やエラーハンドリング、ログ設計など、学ぶべき領域が学生時代の2倍、3倍に増えました。単に動くものを作るのではなく、「保証できるものを作る」というプロの意識への転換が最大の成長だったと感じます。

岩城：吉岡さんは、技術面だけでなく「ビジネス視点」も重要視されていますが、その思考に至った背景は？

吉岡：配属当初、ビジネスの領域がよく分からず、「何のためにこれをやるのか（Why）」が見えない状態で作業をしてしまったことがありました。その時、先輩から「それって本当に意味があるのか？」「儲かるのか、プラスになるのかを自問自答したほうがいい」と教わったんです。たとえ技術的に優れた実装でも、大元の目的を見失っていると、結局は手戻りが発生して悔しい思いをすることになる。それを痛感してからは、企画の方とのミーティングでも、背景や将来的な展望、他プロダクトとの連携を粘り強く聞くようになりました。

「AIを使う」の先。開発プロセスの全工程に「相棒」としてAIを組み込む

岩城：技術の先にある「目的」を掴むことが、プロの仕事だと気づかれたのですね。その視点は、現在のAI活用にも活かされていますか？

吉岡：もちろんです。現在は出社してから退社するまで、常にClaude Codeを立ち上げ、まさに「相棒」として協業しています。でも最初から使いこなせたわけではありません。最初はAIに丸投げしてしまい、意図しない挙動に悩むこともありました。そこから「AIにどう指示を出せば、ビジネスロジックを正確に反映できるか」を試行錯誤し、今のスタイルに辿り着きました。具体的には3つのレイヤーでAIを使い倒しています。

岩城：その「AIとの協業プロセス」について、より技術的に詳しく教えてください。

吉岡：まず1つ目は「プランニングと実装」です。Issue（タスク）が立った段階で、Claude Codeのプランニングモードを使い、既存コードのコンテキストを読み込ませた上で実装方針を議論します。人間が「本質的なロジック」を定義し、AIが「ボイラープレート（定型的なコード）や周辺の実装」を高速で行う。これにより、開発スピードは劇的に向上しました。

2つ目は「自律的なコードレビュー」です。GitHub上に常駐させているAIが、プルリクエストに対して自動で一次レビューを行います。型定義の不備や例外処理の漏れ、さらには「Issueの意図とズレていないか」までチェックしてくれる。これで人間によるレビューの負担を大幅に減らし、クリエイティブな議論に集中できる環境を作っています。

3つ目は「ドキュメントとタスクの構造化」です。仕様書やスライドだけでなく、複雑なタスクをAIと一緒にMarkdown形式で整理し、そのままIssue化する。さらにはミーティングの合間に、AIに「このIssueを参考に、既存のコードから共通化できる部分を洗い出しておいて」と指示を出し、プルリクエストの作成まで裏側で走らせておくこともあります。人間がミーティングをしている間に、AIが作業を進めてくれている状態ですね。

岩城：そこまでAIを使いこなすと、逆にエンジニアの役割はどう変わるのでしょうか？

吉岡：AIに任せても「人間がボケっとしていていいわけではない」んです。AIが生成した内容を、自分が最初から最後まで説明できるか。自分の意志が反映されているか。常に検証し続ける必要があります。実は、AIを使いこなそうとすればするほど、考える総量は変わらないか、むしろ増えている実感すらあります。技術的な作業をAIに任せられる分、人間は「この機能は本当にユーザーのためになるのか」「ビジネス的なインパクトはどこにあるのか」という本質的な問いに時間を割けるようになった、とも言えますね。

岩城：まさに、研修や現場で学んだ「設計思想」と「最新AI」、そして「ビジネス視点」が三位一体となっているわけですね。この1年を振り返って楽しい瞬間ってどこですか？

吉岡：私のチームは新卒の私を含めて3人。小人数だからこそ「誰かがやるしかない」という緊張感があります。特に機械学習モデルのインフラ設定などで複雑なエラーに直面したときは苦戦しましたが、先輩が信じて待ってくれました。自分でエラーを切り分け、解決策を導き出し、それが本番環境に載ったときは、チームを支えている実感が持てて本当に楽しかったです。

岩城：最後に、これからディップを目指す学生や候補者の方へメッセージをお願いします。

吉岡：入社して驚いたのは、思っていた何倍も「若手にチャンスを与えてくれる組織である」という部分です。研修や社内の勉強会もそうですが、日々の壁打ちだったり先輩への相談だったり…サポートもかなりありましたね。最先端のAI環境で、ビジネスを見据えた責任ある開発に挑戦したい。そんな想いを持つ人には、最高の環境だと思います。

岩城：吉岡さんの着実な成長の軌跡がよく分かりました。本日はありがとうございました！

吉岡：ありがとうございました！

————————————————————————–

【吉岡さんの1日のスケジュール】

・10:00 – 12:00　【出社し、AIの成果物検証・今日のタスク整理】
前夜にAIへ投げたタスクの成果物検証と、PR・Issue・Slackの確認。
自分とAIのアサインを決めて開発に入る。
・12:00 【ランチ・休憩】
・13:00 – 14:00 【レビュー & 資料スライド作成】
チーム向けに最適化したAIレビューでPRをブラッシュアップ。
待ち時間にスライドをNano Banana Proで自動生成。
・14:00 – 14:30 【デイリー MTG】
・14:30 – 16:30 【2タスク並行実装】
片方のウィンドウでAIとペアプロで実装し、もう片方ではAIに別タスクの調査・計画を進めさせる。
・16:30 – 17:30 【ミーティング】
AIが文字起こし・議事録を担当。会議中もGitHub上でClaude Codeを動かし、issueからPR作成を進行させる。
・17:30 – 18:30 【チームメンバーのPRをレビュー】
AIにコードの要約や懸念事項をリストアップさせ、コンテキストスイッチのコストを削減。本質的なレビューに集中する。
・18:30 – 19:00　【翌日の仕込み・退社】
翌朝に拾えるよう、AIに長めのタスクを投げておく。日報を書いて退社。