はじめに

BASE の Product Dev Division で Advanced Engineer のプログラミングをするパンダ（@Panda_Program）です。2年半間 Senior Engineer をやって、今は Advanced Engineer になりました。

今回ご縁を頂きまして Developers Summit（デブサミ）2025 に参加・登壇しました。登壇内容はスライドを公開しておりますのでこちらをご覧ください。

バックエンドエンジニアのためのフロントエンド入門

speakerdeck.com

スライドの公開後にはてブのトレンド入りをしたり、スライドのPVが7,000 view に迫ったりと好評だったようで胸を撫で下ろしました。また、同内容は記事として CodeZine 様でも連載中ですので、よければこちらもご覧ください。

codezine.jp

本記事では自分が参加したセッションのまとめと感想を書いていきます。自分が参加したセッションの中から、各日ともに現場で役立つテーマのセッションを3つずつピックアップしています。なお、各セッションの資料は「Developers Summit 2025」講演スライド・参加ブログまとめよりご覧ください。なお、自分が登壇した感想は別の記事で書く予定です。

初日のセッション

自動テストの世界に、この5年間で起きたこと

Autify の末村さんのセッションです。直近5年間で自動テストを取り巻く環境が変わったことを紹介されています。

発表によると、ツールと開発者のマインドセットに大きな変化がありました。CypressやPlaywright、Testing Libraryといった便利なツールを利用することでテストのハードルが下がりました。また、ソフトウェアの品質が高いと開発スピードが上がるという考え方が浸透した結果、自動テストは当たり前になりました。

自動テストが普及してきた世の中で次なる課題は「E2Eのカバレッジを増やしたい」「どんなテストがあれば障害の予防ができるのか」などのテスト設計です。これらは定型化できなかったのですが、LLMのおかげで仕様書からテストを設計するなど、非定型的なテスト設計のコストが下がるであろうとのことでした。

顧客のニーズは変化するものの、常にテストを行うことでさまざまなニーズに迅速に対応し、高速なリリースを実現できることが強調されていました。

BASE ではバックエンドのテストは単体テスト、結合テストともに当たり前に書いています。一方、フロントエンドについてはしっかり守られている部分とそうでない部分があります。例えばカートという決済に関するコア機能ではE2Eテストがしっかり書かれていたり、主要な機能で Mabl を使ったE2Eテストが定期実行されているのですが、ショップオーナー向けの管理画面ではコンポーネントテストやユニットテストがちらほら書かれ始めてきたという印象なので、この流れを推し進められたらなと思います。

エンジニアキャリア図鑑　～エンジニアリングマネージャー VS テックリード～

カケハシの小田中さん、ログラスの塩谷さん、村本さんのディスカッションでした。小田中さんがエンジニアキャリア図鑑という取り組みで、エンジニアが自分のロールモデルを見つけて、キャリア形成のヒントを得る機会を作るのを目指されているとのこと。

そこで、ログラスでエンジニアリングマネージャーとテックリードをされているお二人に話を聞くというのが本セッションです。

マネージャーとテックリードの違いとして、マネージャーはメンバーのキャリアを支援し、彼らのやりたいことを見つける手助けをする役割がある一方で、テックリードは、チームが会社全体の方向性に沿っているかを確認し、事業に貢献できる道筋を引くことの重要性が語られていました。

キャリアを広げるためには事業の視点を持ち、視座を高く持って自分の責任範囲を広げることが肝心だと理解しました。

なお、BASEではEM（People軸）とテックリード（Tech軸）以外にEPM（Engineering Program Manager。PJ軸）という役職、ラダーが設定されており、技術か人かの二者択一ではなく、サービス志向というキャリアも歩むことができます。

業務理解の深化と実践～ドメインモデリングで基幹システムを捉える

MonotaRO の CTO-Office シニアアーキテクトの尾髙さんによる発表です。BASE社ではモノリスからモジュラーモノリスへのリアーキテクチャが進んでいるため、初日のセッションの中では自分にとって一番学びが大きかったセッションでした。

まず複雑性には2つあるのだと語られました。競合他社と差別化を図るためには、本質的な複雑性に集中的に取り組み、偶有的な複雑性を排除することが重要であるとのことです。事業自体は複雑なものなので、ソフトウェアが本質的な複雑性を持つことは免れません。しかし、偶有的な複雑性が増すことにより、ソフトウェアの変更が容易ではなくなるため、これは排除しなければならないという話に共感していた方も多く見られました。なお、本質的/偶有的は essential/accidental の訳語なので必須の複雑性/付随的な複雑性ということもできます（参考: 必須／付随分割 (Essential/Accidental Split)）。

また、事業や業務を理解するために、ドメイン全体と業務領域、流れと構造のマトリクスで分類した4種類の手法を採用しているとのこと。それぞれビッグピクチャ、コンテキストマップ、プロセスモデル、ドメインモデルというモデリング手法です（詳細はスライドをご覧ください）。コンテキストマップやドメインモデルは知っていたり実践していたのですが、これが事業を理解する活動のどこに位置づけられるのかわかって学びになりました。

これらは一度実施するだけではダメで、継続的に開催する必要があるということも印象に残りました。確かに会社は人の入れ替わりもありますし、事業も変化し続けます。大規模なイベントストーミングは１日かかることもあるそうですが、エンジニアのみならず職種を超えてみんなで認識を合わせることで、その後のコミュニケーションやソフトウェア設計、コーディングがスムーズになるのであれば払うべきコストだ、むしろ健全な投資だと思いました。

2日目のセッション

開発スピードは上がっている…品質はどうする？～スピードと品質を両立させるためのプロダクト開発の進め方とは～

Graatの鈴木さん、SReEE の安達さん、10X/B-Testing の風間さん（ブロッコリーさん）によるパネルディスカッションです。

ソフトウェアの品質はプロセス品質、内部品質、外部品質、利用時の品質の4つあると冒頭で語られました。

スピードと品質を両立させるためには、適切な設計とテストプロセスが必要であるということが語られていました。アジャイル開発では、外部品質の維持だけでなく、内部品質の向上が利用時の品質向上に繋がるため、プロセスや構造の改善が重要であるとのことです。

また、アジャイル開発では、QAエンジニアが早い段階から開発チームに参加して、段階的なテスト活動を行うことのメリットがあるとのこと。プロダクトオーナーと開発者がテストの受け入れ基準を作る際に、コードや仕様について詳しく知っていないことを逆に強みとしているQAエンジニアと話すことで、実装前に視点の抜け漏れに気づくことができる。結果的に、テストのシフトレフトが実現できるのだということでした。

なお、チームにQAエンジニアがいない場合は、「今日はあなたがテストの視点を持つ人」というように順番にロールプレイをしても効果があると紹介されていました。

自分が今所属しているチームではQAエンジニアの方が、プロジェクト組成時点から参加しています。しかし、大体こういうものを作るという共有はしているのですが、テストの観点はスプリントレビューで作って動くところから考え始めてもらうという流れになっていました。

このため、仕様決めの段階でうまく頼れなかったな、もっと密に関わってもらう方法があるのではと思いながら参加したため、まさに受け入れ基準を一緒に作っていくという点で関わって貰えばいいんだという答えを教えてもらった気持ちになったセッションでした。

ソフトウェア開発プロセス全体で、AIがモチベーション高く働くために必要なものは「バレンタインデーのチョコ」ではなく「GitLabによる一貫したコンテクスト」だったという話

GitLab の佐々木さんによる発表です。

AIをフル活用するためには、一貫したコンテクストを提供することが重要であり、GitLab ではフルリモートワークを実現するために徹底したドキュメンテーションが行われていた。また、GitLab を使うとコードの管理だけでなくチケット管理やCI/CDなどが可能。開発にまつわる幅広いコンテキストを GitLab 上に集めていると、GiaLab の AI が経験豊富で、横断的なコンテキストを知っているメンバーとして働いてくれるとのことです。

会場では、CIが失敗した時のエラーメッセージを GitLab の AI が読み取って、どんなコミットでエラーになったか、どうやったら修正できるのかを回答するデモが実施されていました。前職では2年半 GitLab を使っていたことがあるのですが、コンテキストが分断されない統合プラットフォームの強みがAIによってさらに強化されていることを感じました。

弊社では GitHub Copilot はもちろん、Notion AI も活用しています。Notion AI は仕様、Copilot はコードというように用途を分けて使っているので、GitLab の AI のようにこれらのコンテキストが統合できるAIがあるとより開発速度が上がるのだろうなと思ってセッションを見ていました。

トヨタ×モブ×AI：ハードウェア開発でのモブ活用と、AI時代のソフトウェア「チーム開発」

トヨタ自動車の竹内さん、名古屋大学の森崎さん、GitHub Japanの服部さんのディスカッションでした（司会はYesNoButの川口さんと翔泳社の小玉さん）。

トヨタの竹内さんから主に顧客のニーズの変化に対応するために、ハードウェア開発でもアジャイル開発を導入したこと、モブワークを導入することで全員参加の共同作業が促進され、待ち時間がなくなって作業の効率が向上したことが語られました。また、社内にいる「達人」たちのようにAIを達人に育てるためには、暗黙知を形式知に変換し、過去のトラブルなど必要なデータをインプットすることが重要だと話されていました。

他にもいくつか話題がありましたが、特にモブ作業、モブプログラミングでの心理的安全性の重要性は勉強になりました。謙虚さとは一人では何もできないと認めることであると定義されていたり、成長のステップを humility（謙虚になる） → Respect & Collaboration（リスペクトを持ち協働する） → Growth（成長する） → Fearless（恐れずに挑戦する）に分解されていたり学ぶところが多かったです。特に開発プロセスや心理的安全性のような人口に膾炙した概念と改めて向き合い、深掘りし、定義する姿勢にトヨタ社のカルチャーを垣間見た気がしました。

BASEではペアプロもモブプロもチームごとに取り入れたり取り入れなかったり、自由に選択することができます。経験上、プロジェクトの立ち上がりフェーズや複雑な箇所の開発の時にスポットでペアプロを取り入れている印象です。お互いに意思疎通ができた結果、思った通りのコードが出てくるようになる開発の終盤では発展的解消という形でペアプロをしなくなるケースも多々あります。開発者自身がペアプロの利点を意識してそれが最大になる場面で自発的に取り入れています。