Developers Summit 2025 ２日目に行ってきました。
２日間とも行ける幸せ。
イベントの概要
Developers Summit（デブサミ）は、2003年から毎年開催されるITエンジニアのための祭典です。「デベロッパーをスターにし、世の中のアップデートを加速する」をミッションに、多様な開発者が一歩踏み出すきっかけとなりたく、これまで開催してきました。
生成AIに代表されるさまざまな技術が急速に普及し、社会への実装もかつてないほどに進んでいます。時には「AIにエンジニアの仕事が取って代わられるのでは」と思うことがあるかもしれません。しかし、世の中にテクノロジーが浸透している今だからこそ、生産性向上や組織マネジメント、基盤づくり、事業価値への貢献など、エンジニアに求められる役割はさらに多様に、大きくひろがっています。
エンジニアリングは、目の前の人、共に働く仲間、そして世界中のユーザーを幸せにする力。世界を変え、世の中に大きなインパクトを起こせるのは、コードを書いてものづくりをしているエンジニアたち自身です。デブサミ2025では、「ひろがるエンジニアリング」というテーマのもと、エンジニアリングの可能性を広げる技術トレンド、エンジニアの役割の多様さ、エンジニアが越境することで得られるもの、そしてエンジニアリングで社会を大きく変える力を一緒に見ていきましょう。コードを書き、変化し続けるみなさんの目の前には、無限の可能性がひろがっているのです。
引用：
イベント参加の背景
- いつも書籍や登壇などでのアウトプットにお世話になっている方たちが登壇している。
- リアルでそんな方たちのお話を聞けるだなんて幸せ過ぎる。
- まさか連日行けるだなんて！！！
１日目の内容
持ち帰るところの多かったセッションメモ
本日も朝一からがっつりセッションを浴びてきました。
- チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング
プロダクト開発は小さいチームから始まる。
事業拡大に伴いチームも大きくなる。
プロダクトの成功を考えると安定した速いフローが必要。
そのためには、組織構造を状況に合わせて変える必要がある。（チーム・トポロジー）
構造は性的なものではなく、状況に応じて変化させる。
コンウェイの法則にどう対処するか。（コンウェイの法則の誕生は1968年）
組織設計がソフトウェア設計を決める。職能別組織は複雑なシステムを生む。
コンウェイの法則からは逃れられないので、逆コンウェイ。
望ましいアーキテクチャと同型の組織設計をする。効率より効果。
チームを中心に考える。チームファースト。
たくさん作ることが目的ではなく、効果を目指す。
権限とスキルを持つチームが顧客の一番間近にいる。アジリティの土台となる。
メンバーの入れ替えを許さないわけではなく、チームの機能を壊さないことが重要。
チームの認知負荷を考慮する。
チームが扱うソフトウェアのサイズを制限する。
コミュニケーションや調整にコストがかかるモデルはスケールしない。
チームの認知負荷にあわせてソフトウェアの境界を選ぶ。
チームトポロジーにより、共通言語となり、見える化でき、共通理解を持てるようになった。
・プロダクト初期
少人数でやる。必要に応じたコミュニケーション。
・プロダクト開発始まる
人増える。１チームでなんでもやる。
アーキテクチャーはモノシリックになるのが普通。（モノリスファースト）
・プロダクト成長
人増える。やることの種類も増え認知負荷高くなる。パフォーマンスあがらない。
組織構造の変更を考える。
・複数チームでの開発
１ストリームアラインドチームに複数のサブチームが。
スキルベースでチームを分けてはだめ。E2Eで開発できるフィーチャーチームとする。
最終的には統合が必要となる。
・そのままスケールするのは難しい
全チームが集まってのコミュニケーションし、足ナビ揃えるモデルはスケールしにくい。
アジリティのために依存関係を小さくし、チームが自律的に動ける状態にする必要がある。
・ドメインやサービスで分離
アーキテクチャーを見直し、チームを独立してリリースできるようにする。
但し、そのためのコストを支払えることが前提。（プロダクトの一定の成功）
チームの分け方にもいろいろな観点がある。
プロダクトと事業の進化に伴いチーム構造を緩やかに進化させ続ける。
但し、メンバーの感情を考慮する。チーム構造の設計にメンバーも加える。
チーム構造を変えるときには、必ずキャリブレーションを行う。
すぐに機能することを期待せず、コンテキストも含めた調整を行う。
チーム構造を変えた後には検査する。レトロスペクティブをおこなう。
フィードバックを基に次の構造変化に備える。 - 「mixi2の舞台裏」 TiDBで実現するSNSのスケーラビリティとパフォーマンス
スケーラビリティ、フェイルオーバー、レイテンシー、コスト⇒NewSQL
リリース直後や年末年始などのカレンダー上のイベントを想定した非機能にも適合。
無停止での運用継続、急激な負荷にもスケールアウトで対応が可能。
ドキュメントも整っているためキャッチアップも容易。 - 開発現場を盛り上げたらいつの間にかトラブルがめっちゃ減ったんだが ～エンジニアリングの力を引き出すプロジェクトマネージャーの秘訣～
Excelに限界。Redmineを導入。結果、品質大幅向上。
チームパフォーマンスに、ツールだけが効果を生むわけではない。
目的を持ったツール導入。ツール利用のためのコミュニケーションが必要。
納得して業務に取り組んでもらう。恐れず前向きに行動してもらう。
ツールによる成功体験はメリット感じる⇒情報一元化する⇒運用を継続的に改善することで築く。 - プロダクトエンジニアから学ぶ、ユーザーにより高い価値を届ける技術
私たちエンジニアの仕事とは？
プロダクトを通じて顧客課題を解決すること。
エンジニア自身の幸せを守ることでもある。
プロダクトエンジニアという単語は2018年ごろから使われ始めている。
プロダクトの価値はエンジニア、デザイナー、プロダクトマネージャーの領域のはざまで失われる。
担当者間のコンテキストの不一致、開発プロセスの受け渡しで失われる。
機能開発の全体に一人格としてのオーナーシップを持つ。
課題解決に対する強いオーナーシップを持つ。
プロダクトエンジニアはかつてからいた存在だが、明瞭かはされていなかった。
今日からプロダクトエンジニアを始めるには。
・２つの検証のはやさをあげる。顧客検証を早める。実装を速める。
・課題の再定義をする。表面的課題から深掘り課題に。
・リリースした機能に対する顧客の声を聴く。
・ドメイン駆動設計を活かす。越境のための業務フロー理解、ユビキタス言語理解の助けとなる。
越境により、各専門家とのコラボレーションの実現、技術と知識の掛け算が生まれる。
プロダクトエンジニアには、オーナーシップ、顧客理解、検証スピードが重視される。
※丹羽さんの登壇は以下でもまとめています。
- 現場で役立つAPIデザイン
なぜAPIデザインが重要か。
よくある仕様書作成フローは作りながら。負債になることが多い。
APIファーストの進め方が良い。
APIデザインのアプローチ
・インサイドアウト：バックエンド起点
・アウトサイドイン：フロントエンド起点
・アジャイル
APIファーストでは実装を先に行う。
良いAPIは、HTTP標準、Restfulの原則に従う。現実解にも目を向ける。
APIはバージョン管理する。後方互換性のないメジャーバージョンアップには気を付ける。
キャッシングのコントロールは重要。Cache-Controlヘッダーでキャッシュの挙動を制御。
APIドキュメントにはOpenAPI仕様（OAS）という標準がある。 - テスト自動化、苦しかったときの話をしようか―これからの開発現場を効率化するためのベストプラクティス
課題：
いつでも繰り返し実行できなかった。
テスト自動化の運用ができなかった。
対応：
毎日リグレッションすることを目的に、
ツール選定・実装し、運用作業の洗い出しと工数確保した。
課題：
テスト観点、検証方法がバラバラ。テスト品質に一貫性が無くメンテ大変。
ローコードなのに保守が大変。カスタム関数。
対策：
テスト基準を設けた。
コーディングルールを設けた。
課題：
ステークホルダーと調整できていなかった。
運用コストがすりあっていなかった。手動テストチームに信頼が無かった。
対策：
ステークホルダとの密な話し合いを行った。 - 目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる
能力とはアビリティ（能力）とキャパシティ（容量）
能力には、才能、技能、熟練がある。
伸ばせるものはスキル・技能。
知識 * 経験 = 知恵
知らないことは想像できない。知るだけでは情報。
実体験と紐づくことで知識になる。経験が知恵に繋がる。
会社が育ててくれる時代は終わった。だからこそ、主体的になる必要がある。
計画実行力、言語化力、問題解決能力を磨く。
内省とフィーバックサイクルを利用する。
ストレッチなタスクをし、振り返り、抽象化し、次につなげる。
日報、週報で仮説検証のフィードバックを作る。３つの能力が磨かれる。
問題の未知、既知、その条件を分解をする。
要望⇒仕様までの落とし込みで実現できる。
問題を理解したら仕事をする。仕事は問題をタスクに分解することから。
タスクの終了の定義と完了の定義が大事。
PDCAのサイクルを回す。
聞いた情報をどう現場で実行し経験としていくか。
遅くてもやった方がよい。１つずつ手を動かして積み上げていく。 - SaaSの次なる潮流BPaaS ゼロイチの事業づくりと伴走するプロダクト開発の裏側
BPaaSへの挑戦背景。
DXに向けた中小企業の課題：ヒト不足。
業務代行しながらSaaS利用⇒BPaaSに。
ASIS=>TOBEへのGAPを明確にし、可能な限り早く登れる方法を考える。
将来的にチャットをタスク発注プラットフォーム化したい。
プロダクト構想：顧客窓口となるBPaaS窓口、自動化エンジン、業務関連SaaS。
意思決定の迅速化のため、各プロダクトチームを持ち、横断チームでベースライン担保。
事業、プロダクト、技術３領域が協調できるようにする。
新規事業×新規組織で、立ち上げながら走る必要があった。
少人数で幅広く適切なスピード感で。他サービスとの連携も考慮した。
バックエンド、フロントエンドの必要な人数が分からなかったので両方ともTypeScriptにした。
１年で組織は３倍の拡大。プロダクトも組織も0->1で立ち上げるのは大変だった。
開発プロセスも作り上げる必要があった。メンバーの成長も実感できた。
今後、市場志向のチームを作っていく。 - エンジニアリングで目の前の人を幸せに！「ちいさなDX」リレーセッション
・奥瀬さん
住友商事には0→1チャレンジ（社内起業制度）がある。
身近な課題からアプリ開発。マッチングアプリのUIを模倣。
現状はピボットが求められている。
・沖中さん
ボトムアップのDX。
現場課題を自分たちで解決できる状態に。
結果、新しいものを作る発想も。
例：無人店舗、テイクアウトアプリ
低コストによってできたことで、スケールできたり、身軽な検証ができた。
・藤吉さん
新規事業でつけていたノートをアプリ化。
毎日送っていたメールもAppSheetで実現。
・磯根さん
デイサービスは送迎業務の負担が大きい。
送迎が必要なポイントを登録することで、送迎ルートを作る。
・北城さん
医療現場の課題を自分で解決する実装力を育てる。
例：診断書自動作成ツール、目安箱bot、踏力日誌アプリ。
copy-of-tokyo-shibau-ny63.glide.page
・日吉さん
田んぼに入って収穫するという困難さに対策した。
農業は課題が多い。95%のコメ農家は赤字。
自分たちの対策が、より広い解決策に繋がっていっている。
出展ブース
昨日回れなかったブースを中心に。
名前だけ知っていて興味のあった企業様のお話を聞けるのは勉強になります。
今までの自分達の主戦場から領域を拡張したサービスに挑戦している企業様のお話が興味深い。
書籍販売コーナー
もう少しするとPythonでの開発が始まるので勉強する！
感想とまとめ
本日も本気で良い刺激を浴び続けていました。
有機的にチームを進化させていく文脈から始まり、事業を推進するプロダクトにオーナーシップを持つエンジニアの在り方を経由し、もっと身近で課題に向き合うちいさなDXで締まる１日。
最高でした。。
最近、誰かのアウトプットによって、エンジニアとしての課題と挑戦のサイクルが前より速く回せることができていることを感じます。
AskTheSpeakerやサイン会、いつも気恥ずかしくなってしまいスルーがちですが、今回は感謝をお伝えしたいのと、少しでもコミュニケーションを取ることで自分のサイクルを回せたらと挑戦しました。
サービスの在り方、プロダクトの在り方にすごく刺激を受けている企業様にもブースで感謝をお伝えできました。
知ると知らないだと違う。知ったことによって自分の価値観が変わり、何をしたいかどうなりたいかがより濃度があがった気がします。
ひろがるエンジニアリング。
技術、領域、そして視野。そのうえで自分がどうありたいかのビジョン。
１年後の自分はどうなっていたら最高のバクアゲか。ひとつずつ積み上げる。
２日間とも参加できて嬉しかったです。来年も参加したいです。
