Developers Summit 2025 １日目に行ってきました。
初デブサミ。念願叶う。
イベントの概要
Developers Summit（デブサミ）は、2003年から毎年開催されるITエンジニアのための祭典です。「デベロッパーをスターにし、世の中のアップデートを加速する」をミッションに、多様な開発者が一歩踏み出すきっかけとなりたく、これまで開催してきました。
生成AIに代表されるさまざまな技術が急速に普及し、社会への実装もかつてないほどに進んでいます。時には「AIにエンジニアの仕事が取って代わられるのでは」と思うことがあるかもしれません。しかし、世の中にテクノロジーが浸透している今だからこそ、生産性向上や組織マネジメント、基盤づくり、事業価値への貢献など、エンジニアに求められる役割はさらに多様に、大きくひろがっています。
エンジニアリングは、目の前の人、共に働く仲間、そして世界中のユーザーを幸せにする力。世界を変え、世の中に大きなインパクトを起こせるのは、コードを書いてものづくりをしているエンジニアたち自身です。デブサミ2025では、「ひろがるエンジニアリング」というテーマのもと、エンジニアリングの可能性を広げる技術トレンド、エンジニアの役割の多様さ、エンジニアが越境することで得られるもの、そしてエンジニアリングで社会を大きく変える力を一緒に見ていきましょう。コードを書き、変化し続けるみなさんの目の前には、無限の可能性がひろがっているのです。
引用：
イベント参加の背景
- 一昨年、人伝いでデブサミの存在を知り、いつか行きたいと待ち望んでいました。
- 昨年、行きたかったけれど超ハードワークにやられ結局いけませんでした。
- 今年、稼働が平和でやったぞやっといける！！！
持ち帰るところの多かったセッションメモ
気になるセッションが多すぎて朝１から行ってきました。
- 技術と情熱で創る未来
・デブサミが映す技術の現在地
2011年のデブサミテーマは創発。
その時の及川さんのテーマは「クラウド時代のソフトウェア開発」。
拡張の時代から成熟の時代に。データを使う時代から、AIの時代に。
できなかったことは大抵できる時代に。
・技術の成熟と「次の一手」
閉塞感を感じる。かつて標榜したいろいろなものがなくなっている。
技術はなくなったわけではなく、社会に溶け込んでいる。
但しデベロッパーに対するエンパワーメントがなくなっている。
技術の民主化と権力の集中。無限の拡張から制約との共存へ。
人のための技術からアルゴリズムのための技術に。
・生成AIとエンジニアの役割
プログラミングの進化は人間にやさしくなってきている。
結果、生成AIが生まれることは自然なこと。
コンピューターに指示を出すことは変わらない。
数学を学ぶ目的には、計算処理を行う対象が間違った処理を行った場合に直すことができるようにする、推測のための計算力を磨く、といったことがある。
プログラミングを学ぶのは、AIに結果を委ねない、といった目的がある。
ソフトウェア開発には対話が重要となる。生成AIに対する対話も同様となる。
ソフトウェアエンジニアは2極化する。
AIに任せられない・任せるべきではない仕事をする人材。
AIに任せられる領域を担当する人材。
ソフトウェア技術者は今までは従来の社会構造に対するディスラプトする側だったが、今初めて自らがディスラプトされる側になる。
ソフトウェアファーストでは、事業会社がオーナーシップを持つことを推進していた。発注側はAIに依頼する時代になり、発注側もAIになる時代が来るかもしれない。
けど、別に人の興味・好奇心を制限されているわけではない。
・技術者が未来を創るために
もともとシリコンバレーはカウンターカルチャーだった。
技術が分断、衆愚を加速させる懸念がある。
変化に適応しないといけないが、そこに人間の価値・責任を持つ。
作った先にどういった価値を生み出したいのをか考える。 - 自動テストの世界に、この5年間で起きたこと
Autify正式リリースから丸５年。
AIを用いたE2E自動化テストツール。
５年前のカスタマーペインとAutifyのソリューションを整理。
2019年。テストコードの作成面倒、メンテ大変。
それに対し、ノーコード（UIからの実現）。
環境構築が大変。それに対し、OutOfBox。
この５年間で出たツール群はテストのハードルを下げた。
cypress、Playwright、両方ともjs。フロントエンドエコシステムとの統合。
アクセシビリティベースのロケーターに。
テストはしやすくなったが、テスト設計に課題が残る。
マルチモーダルAIがテストを変える。
今後E2Eが早くなることで自動テストのベストプラクティスが変わる。 - プロセス改善による品質向上事例
開発チームが自らで品質担保できるようにするために、アジャイルテスト実践 改善 AGILE TPIが利用できる。
品質のプロが確固たる軸に沿って開発チームをイネーブリングすることが重要。 - エンジニアキャリア図鑑 ～エンジニアリングマネージャー VS テックリード～
EMになることでプルリクをあげるという直接的な価値貢献から離れたが、
メンバーの成長という価値にモチベーションが変わる。
事業の変動に沿って複数職能がその時々の状況に沿って能動的に機能することが重要。 - リアルな過去からたどり着いた、事業成長を牽引するエンジニアの在り方
各事業フェーズにおいて事業に立脚したエンジニアリングを行う。
本当に求められる用件だけを実現する。
システムだけで解決しようとせず、業務と合わせて要求を満たす。
スピードのためには計画的に返済する前提で負債も取る。
判断が感情に寄らないようにする。ファクトを確認する。決断したら躊躇はしない。 - 異能の掛け合わせが生むプロダクト開発 ～AIが支える事業開発プロセス～
複数の職能が１つのプロダクト開発に向き合うことが大事。
ビジネス、テクノロジー、クリエイティブがそれぞれの責務によりプロダクト開発を推進する。
チーム論：誰とチームを組み、どう分かり合い活かし合うか。
AIは各プロセスに取り組める。
AI導入により見積りは変動する。利用する場合は、前提に考える。
AIの品質は定期モニタリングし、信頼性を確保する。 - 業務理解の深化と実践～ドメインモデリングで基幹システムを捉える
ビジネス成長に伴う複雑性を本質的複雑性と偶発的複雑性に分ける。
本質的複雑性は事業の根幹となるドメイン。基幹システムに落とす。
偶発的複雑性は取り除き、認知負荷と予測不可能な変更コストを低減する。
ドメインはモデリングを作ることで共有知とする。
モデルを作ることは大変だからこそ、モデルを利用してどうするかを考える。 - トラシューアニマルになろう ～開発者だからこそできる、安定したサービス作りの秘訣～
トラブルシューティングは学べる。
知識定着・習得。システム全体の解像度UP。視野広がる。論理的思考が鍛えられる。
組織が大きくなると開発と運用が分離させられがち。
コードを書いた人が責任を引き受けるのが重要。
フルオーナーシップ。フルサイクルエンジニア。
コード責任を持つメリット：フィードバックループが高速化する。
運用イメージしないで開発すると、扱いづらいシステムになる。
ベロシティは悪くなるが健全なプロダクトはベロシティだけで成り立たない。
オンコールは属人化させない。SREだけがやることでもない。
エンジニアにライフサイクル全体に責任を持たせることが重要。
但し、心理的安全性は重要。心の負担を気遣える状態にする。
ポストインシデントレビューで健全な議論に推進できるようにファシリテーターを採用する。 - リーダブルテストコード～メンテナンスしやすいテストコードを作成する方法を考える～
テストのメンテナンスどこからどうすれば良いか。
・t_wadaさん
テストコードの認知負荷に気を付ける。
読みやすいテストコード、読みにくいテストコードを意識する。
アンチパターン：
・情報がすくなすぎる。例：〇〇が正しいこと※記載が曖昧
・情報が多すぎる。背景：かつてはテストコードに全部書かれるべきと言われていた。
対策：
・課題外在性負荷を下げる。名前、構造（準備、実行、検証）、情報量（テストの妥当性の説明コメント等）に気を配る。
・末村さん
E2Eのテストコードは手続き的になりがち。（ユーザー処理の検証のため）
暗黙的なコンテキストを避ける。
ファンクション名で自明とするブロックを作りコンテキストとする。
コメントに頼らない。
・ブロッコリーさん
リーダブルな行動は変更容易性であること。
変更容易性が高いということは、理解容易性、説明容易性が高いということ。
テストケース名が説明不足の場合、テストコードから意図を読み取らないといけない。
テストケース名が意図を表すようにする。そうすると仕様変更時に扱いやすい。
・ディスカッション
・コードとコメント
コメントはいずれコードとずれる。
コードで表現できるものはコードで書く。コードで書けないものはコメント書く。
・レビュアーとして
t_wadaさん
まずはテストの実行結果から見る。（実行結果は俯瞰の構造、コードは詳細）
そのあとにコードのメンテナビリティを見る。
末村さん
E2Eは長くなりがちなので、１つ１つの長さを気にする。
ブロッコリーさん
テストシナリオが何を表しているかを見る。
作成者に説明してもらう。説明してもらうことで作成者が問題に気付く。
QAはまず少ないので全部は見れない。
・作成者として
・末村さん
AIをセルフチェックとして使う。
・t_wadaさん
他の人に対するチェックと同様のことを自分のコードに対しても行う。
AIに壁打ちしてもらう。書いたコードを説明してもらう。
・ブロッコリーさん
品質保証という答えが必要なものにＡＩは不向き。
ディスカッションのように磨き上げるものに適用する。
・テストコードのＮＧワード
〇〇のテスト、ちゃんと動く、正しいこと
・何をテストしたいか、の客観性を持つためには
実装者はHOWにいきがち。テストファースト。
作るところからではなく、結果どうなるかから考える。
・トレーニング
なぜなぜではなく、なになにで思考を整理する。
出展ブース
カンファレンスに通うことが多くなったため、ご挨拶できる企業様も多くなってきました。
テックカンファレンスにブースを出す＝エンジニアリング領域での発信の企業様が多く、基本的には自分なんかはいつもお世話になっています状態になっています。
ブースにいる方とエンジニアリングについてお話できる企業様は良い企業様と思っています。
感想とまとめ
全９セッション駆け抜け、カロリー消化量がとんでもない。
働かない頭で考えるに、時流という波の上で事業という船に乗った我々が目指した方角にどう突き進むか的な話だった気がする。
そして、その比喩を具体に落とした時に現れる各領域各営みのなかでの成功譚が本日の各セッションだった気がする。
その話を持ち帰り、我々はそれぞれの持ち場でさらに船を前に漕げるといいね、という。
及川さんのお話熱かった。オーナーシップの重要性。繰り返し考え続けます。
イネーブリングチームとしてのQA。AgileTPIは必ず目を通す。
ログラスさんやっぱり素敵。改めて一つの事業で各役割の方たちが有機的に動いていることを感じます。
以前ログラスQAコタツさんが1on1でメンバーのお困りごとをキャッチアップしたら、アジャイルコーチの方やEMの方に相談を〜と言っていたことを思い出しました。
ひとつひとつの役割の方だけでもすごい印象あるのに、総体としてもすごい。
小田中はさんにご挨拶できたの嬉しい。同い年。
ウェルスナビさんの覚悟をもった進め方刺激になります。頭に残しておきたい。
AI前提の開発は目前と知り、トラブルはレベルアップの効果的なイベントと改めて思う。
逆にトラブルをチーム、組織として好機と捉えられると強いと思う。
いつか誰かが読むコードの自らのまたは誰かを通しての磨き方に熱くなりました。
明日もあるのが楽しい！！
おまけ
及川さんと米久保さんのサインうれしい！！
