every Tech Blog

株式会社エブリーのTech Blogです。

新卒二人で Developers Summit (デブサミ) 2025 に参加してきました!

はじめに

デリッシュキッチン 開発部でエンジニアをしている24新卒の新谷と@きょーです。

2025年2月13-14日に開催されたDevelopers Summit 2025に参加してきましたので、イベントの様子や印象に残ったセッションをいくつかご紹介します。

イベント概要

Developers Summit(デブサミ)は、2003年から続くITエンジニアのための祭典です。 ソフトウェア開発者が今知っておきたいトピックや、ロールモデルとなるデベロッパーとのさまざまな出会いがあるイベントです。

2025年のテーマは「ひろがるエンジニアリング」で、技術革新が進む中でのエンジニアの可能性や社会への影響について紹介されました。

会場は、ホテル雅叙園東京で開催されましたが、室内に鯉が泳ぐ池があるなど、豪華な雰囲気でした。

また、会場内には多くのブースが出展されており、最新の技術やサービスを紹介されていたり、書籍の販売も設けられていました。

以下ブースの紹介となります。各社自社プロダクトを使った展示だったり、通りすがっただけで目を引くような展示、ホットなトピックについてアンケートをとっている企業もありました。プロダクトや組織についてお話を聞くこともできとても楽しかったです!

参加レポート

リアルな過去からたどり着いた、事業を成長を牽引するエンジニアの在り方

発表者: ウェルスナビ株式会社 保科 智秀 さん
レポート: 新谷

www.docswell.com

こちらのセッションでは、事業成長を支えるエンジニアリングの在り方について語られました。

事業成長のフェーズは「超初期(クローズドβ)」「初期(一般公開)」「成長期(1→10)」「成長期(10→100)」の4段階に分けられ、それぞれの課題とエンジニアの役割が説明されました。

  • 超初期フェーズ
    • 限られたリソースの中、期間で目的達成するために真のMUST要件を引き出す。
  • 初期フェーズ
    • 安易な解決策に飛びつかず、高確率で予測される継続した改善を考慮することが大事。
    • だが遠すぎる未来は切り捨てる。
  • 成長期(1→10)
    • 今後の負債解消のプランを持ちつつ、負債を受け入れる覚悟を持って機能開発を優先。
  • 成長期(10→100)
    • 負債解消と新規事業展開に向けたアーキテクチャ変更が必要となり、将来に向けた成長加速のプランを提案。

各フェーズでエンジニアは異なる判断を求められ、スピード感・柔軟性・将来の展望を考慮した選択が重要であることが強調されていました。 特に、負債を受け入れながらも成長を加速させるための意思決定が鍵となるという点が印象的でした。

目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる

発表者: 株式会社リンケージ そーだいさん(https://x.com/soudai1025)
レポート: 新谷

speakerdeck.com

このセッションでは、仕事を通じてスキルを広げ、能力を高める方法が紹介されました。

まず、能力を伸ばすためには「知識」と「経験」を掛け合わせて「知恵」とすることが重要であると語られました。 スキルを習得する過程では、「知る」「やる」「わかる」「できる」「している」といったステップを踏むことで、実践を通じた学びが深まるという考えが示されました。

また、「仕事の中で成長する」ためには、計画実行力、言語化力、問題解決能力を鍛えることが重要であり、それには「内省」と「フィードバックサイクル」が必要であると説明されました。 具体的には、タスクを細分化し、適切な問題設定を行い、日報や週報を活用して振り返りを行うことが推奨されていました。

最後に、「一日ひとつでも知らないことを見つける」ということが紹介されており、日々の積み重ねがスキルアップにつながるということを改めて認識しました。

生成 AI 時代のプロダクトの現在地点

発表者: 株式会社 LayerX 松本さん(https://x.com/y_matsuwitter)
レポート: きょー

speakerdeck.com

このセッションでは、LLM(大規模言語モデル)時代におけるプロダクト開発の在り方について松本さんに紹介いただきました。

LLMが人間と同程度の情報量で仕事を習得できるこの時代、LLMのポテンシャルを引き出すために「AIをオンボーディングする」意識が大切になるとのことでした。 LLMが活躍できるように適切な情報、ツールを提供し、継続的に学習させていける仕組みが必要になってくるわけです。 特に以下の5つの点が重要だと説明いただきました。

  • Context
    • LLMが問題を解決するために必要な情報
  • Knowledge
    • LLMが参照する知識データベース
  • Workflow
    • LLMが業務を遂行するためのプロセス
  • Planning
    • LLMがタスクを計画するための仕組み
  • Evaluation
    • LLMの出力結果を評価するための仕組み

また、LLMを使う箇所を見極めることも重要だと発表で触れていました。LLMを組み込める箇所全て組み込むのではなく、適切な品質・体験となるようにソフトウェア・LLM・人間の誰が何をやるかバランスを決めるのが重要とのことでした。

「LLM中心の時代のプロダクトを作り直すならどう構成していくか」松本さんから最後に問いかけられたテーマです。理想のプロダクトを常に考え、現実とのギャップをどう埋めていくかを考えながら開発をしていこうと思いました。

リーダブルテストコード~メンテナンスしやすいテストコードを作成する方法を考える~

発表者: twadaさん(https://x.com/t_wada)、オーティファイ株式会社 末村さん(https://x.com/tsueeemura)、株式会社10X / B-Testing ブロッコリーさん(https://x.com/nihonbuson
レポート: きょー

speakerdeck.com

このセッションでは、読みやすくメンテナンスしやすいテストコードの書き方について上記で記載している3名の専門家より紹介いただきました。

twadaさんからは、テストコードの認知負荷を下げるための方法として、名前、構造、情報量に気を配ることが重要であると説明がありました。 具体的には、テストの意図が明確に伝わるように、テストコードの命名や構造を工夫すること、そして、テストに必要な情報だけを記述することが重要とのことでした。

末村さんからは、E2Eテストコードを例に、コンテキストを明示することでテストコードを自己説明的にする方法を紹介いただきました。 テストコードに「いま、どのページにいるのか」「どんなデータがあるはずなのか」といったコンテキストを明示することで、コードの可読性が向上し、メンテナンス性も高まるとのことでした。

ブロッコリーさんからは、テストコードにテストの意図を込めることの重要性について紹介いただきました。 テストの意図を明確にすることで、コードの理解容易性や説明容易性が向上し、ひいては保守性も向上すると説明がありました。 また、テストの意図をテストメソッド名に記述することで、特別な設定値がどれなのかが分かりやすくなり、仕様変更時の対応もしやすくなるという利点も紹介されました。

メンテナンスしやすいテストコードを書く上で大切なことは、読み手を意識した命名や認知負荷を下げるための構造化ということでした。また、AIが発展してきたこの時代、AIをうまく使いこなしより良いテストコードを模索していくことも大事ということを紹介されていました。

まとめ

Developers Summit 2025は、エンジニアリングのトレンドや事例を知ることができる貴重な機会でした。

特定の技術にフォーカスしたセッションから、エンジニアとしてのキャリアやスキルアップについて学べるセッションまで、幅広い内容に触れることができました。

今後も、新しい技術や知識を取り入れ、エンジニアとしての成長を続けていきたいと思います。