私の所属するプロダクトは開発者が数十名まで拡大していましたが、SREは長らく2名体制のままでした。この状況で、問い合わせが来るたびにSREが情報共有ツールのKibela上で関連ドキュメントを探し出し、繰り返し同じ説明をすることに時間を費やすことが発生していました。
解決策としてNotebookLMの導入を試みましたが、KibelaのMarkdown形式を直接NotebookLMに取り込むと、回答の根拠となるソース表示が崩れる問題に直面。NotebookLMの回答における情報ソースとしての信頼性を担保できませんでした。この課題を解決したのが、NotebookLMと相性の良いGoogle Docsです。本トークでは、私の専門外のApps ScriptをGeminiと対話しながら構築し、KibelaからGoogle Docsへのドキュメント同期ツールを自動で作成し、NotebookLMに取り込むまでの一連のプロセスを共有します。この対応により問い合わせ工数の削減だけでなく、多国籍チームの開発生産性向上という思わぬ価値も発見しました。AI活用の障壁を乗り越えた実践的な問い合わせ削減の実例をお話しします。

[想定する参加者層]
・社内ドキュメントの管理や活用に課題を持つエンジニア
・Gemini、NotebookLMの具体的な業務活用事例に興味がある方
・多国籍な開発チームの生産性向上に関心がある方

[前提知識]
・ドキュメント管理ツール（Kibela, Google Docsなど）の利用経験
・AIチャット（Gemini, NotebookLMなど）への基本的な関心
※Apps ScriptやJavaScriptの深い知識は不要です。

Goは、Kubernetesやコンテナランタイムをはじめクラウドネイティブ基盤の中核を担っている言語です。
しかし、Goは決して「何でもできる」万能言語ではありません。

Goの非常に扱いやすい並行処理モデルは、OSプロセスを直接扱うような低レベルな領域との相性が悪いという側面を持ちます。
このような処理は、実際にOSに干渉してコンテナを生成する、低レベルコンテナランタイムに欠かせない技術です。
現在低レベルランタイムのデファクトスタンダートであるruncはGoで書かれていますが、そのプロセス制御はCGoという仕組みで呼び出されるC言語のロジックに強く依存しています。

このセッションでは、上で述べたGoの設計と低レベルランタイムのギャップを紐解きながら、以下のようなトピックを深掘りします。

• コンテナとは何か、OSプロセスとsyscallの基礎
• コンテナランタイムの構造 (高レベル/低レベル)
• Go特有の並行処理、goroutineとプロセス作成に及ぼす影響
• CとGoの2言語で簡素なコンテナを作るライブコーディング
• 代替ランタイムであるyouki、crunの紹介

コンテナランタイムやGo言語の並行処理の仕組みを理解し、プロジェクトに適した言語を選ぶ重要性を一緒に再確認していきましょう。

[対象者]

• コンテナを日常的に使っており、その裏側を理解したい方
• Go言語の並行処理(goroutineとその中身)に興味がある方
• 普段はアプリケーション開発が中心だが、OSの動きを学んでみたい方
  • OSやシステムプログラミングに興味があるアプリケーションエンジニアが、言語・OSやコンテナの裏側を覗く第一歩として最適です。

[アウトライン]

1. コンテナとは何か/OSプロセスとsyscall
2. コンテナランタイムのアーキテクチャ
3. ライブコーディング: Cで作る簡素なコンテナ
4. Goの並行処理、goroutineとその実行モデル
5. ライブコーディング: Goで作る簡素なコンテナ
6. runcにおけるCGoでのプロセス管理
7. 代替ランタイム: youki、crun、etc...

2025年後半は、ランサムウェア感染、データ損害、クラウド障害という話題がIT業界を震撼させました。
クラウドはスケーラブルな一方で、障害・攻撃・設定ミスなどのリスクを正しく評価できていないことは問題です。いま求められているのは、単なる高可用性ではなく「レジリエンス＝回復力」を備えた設計です。本セッションでは、マルチクラウド（AWS/Azure/GCP/OCI）におけるレジリエンス可視化について考え、システム障害・サイバー攻撃の両面から耐性を強化するアプローチを解説します。四大クラウドにおけるベストプラクティス比較も行い、設計・評価・運用を一体化した継続的レジリエンス向上の手法を紹介します。
想定対象は、クラウドアーキテクト、セキュリティ担当者、システム企画担当。中級者以上を主な対象とします。

【テーマ】
生成AI (Claude Code) を活用した開発リードタイムの劇的な短縮。工数不足で放置されがちだった施策を高速で実行し、アイデアをすぐに形にして検証する手法と、それにより実現したチーム間の信頼関係の向上について扱います。

【想定する参加者層】
・ソフトウェアに関する新規事業や価値検証に携わっているエンジニア、プロダクトオーナー、デザイナー、マネージャーなど
・生成AIを具体的な現場の課題解決に役立てたいと考えている全ての方

【トーク概要】
あなたのチームで「やりたいけど時間がない」と諦めているアイデアはありませんか？
私たちの開発現場も同じ悩みを抱えていました。ビジネスサイドからの要望や、デザイナーによる良いデザインの修正など、事業にとって素晴らしい施策があると分かっていても、他に優先すべきタスクが多く、工数不足からなかなか着手できない状況でした。
このまま対応を先延ばしにすれば、プロダクトはユーザーの離脱を防げないままとなり、さらに「せっかくの提案が開発に回してもらえない」という不満から、チーム間の信頼関係が損なわれてしまうというリスクがありました。

「やりたいけど時間がない」。そんな理由で見送られていた施策を、生成AI Claude Codeの活用によって一変させました。
本セッションでは、PR自動生成ワークフローを構築し、アイデアを即座に実装・検証できるようにした実践事例を紹介します。

この仕組みにより、1週間以上かかっていたデザイン・開発タスクを1時間以内で完了させることが可能になり、チーム間の信頼関係やモチベーションも向上しました。
「AIがコードを書く」だけではなく、「チームがより良い形で連携する」ための仕組みとしてClaude Codeをどう活かしたのか。
現場での課題感から、実際の構築プロセス、そして得られた変化までをリアルにお伝えします。
生成AIを使って“やりたいことを諦めない”開発サイクルを作りたい方におすすめのセッションです。

ソフトウェアが複雑になるにつれ、安全に扱うことができ、バグが発生しにくいイミュータブル性の重要性が増しています。Javaでイミュータブルなデータといえばレコードですが、自作のクラスであってもイミュータブルにすることができます。

そこで、本セッションではミュータブルとイミュータブルとはどういうことなのかを解説し、ミュータブルなデータの問題点と、その解決法としてのイミュータブルについて紹介していきます。さらに、イミュータブルなコレクションなどについても紹介します。

2025年9月にリリースされたJava 25は2年ぶりのLTSということもあり、様々な機能が取り込まれています。また、1つ前のLTSであるJava 21からJava 25までにも多くの機能が導入されています。これらの機能を俯瞰することにより今のJavaが向かっている方向も見えてきます。

そこで、本セッションでは、Java 22からJava 25の機能の中から代表的なものを紹介すると共に、Javaが向かっている方向性について考えていきます。

本セッションでは、Amazon Aurora を題材に、SQLの実行計画分析とパフォーマンスチューニングを
AWSサービスと生成AIの力で効率化するアプローチを紹介します。

従来の手作業による実行計画の読み解きでは、時間がかかり、知識の属人化も起きがちです。
しかし、Aurora Performance InsightsやCloudWatch LogsなどのAWSサービスを活用し、
さらに Amazon Bedrock や Claude 3 などの生成AIモデルに実行計画を要約・分析させることで、
より直感的かつスピーディーにチューニングを進めることが可能になります。

◼️テーマ
データベース最適化／SQLチューニング／生成AI活用／Aurora／パフォーマンス可視化

◼️想定する参加者層（前提知識）
中級者以上のエンジニア向け
• SQLを日常的に書いている方
• クエリのパフォーマンスチューニングに苦手がある方
• チューニングの「調査・分析」を効率化したい」方
• 生成AIを業務活用してみたいクラウドエンジニア
初心者も歓迎
• 実行計画を読んだことがない方でも理解できるよう、最初に基礎概念を解説します。

◼️トーク概要
「SQLが動くけれど遅い。何をどう直せばいいか分からない。」
──そんな経験をしたことはありませんか？

SQLのチューニングには“実行計画”という最強の手がかりがあります。
しかし、EXPLAINを見ても「Index Scan」「Nested Loop」などの言葉の意味が分からず、
“結局どこが遅いのか”が掴めないという声を多く聞きます。

このセッションでは、Amazon Aurora（MySQL/PostgreSQL互換）を実際に操作しながら、
実行計画を「読む」「比べる」「直す」プロセスをリアルタイムで紹介します。
• 実行計画から何が分かるのか？
• フルスキャン・インデックススキャン・結合順序の違い
• Aurora特有のチューニングポイント（キャッシュ・パラメータ・I/O最適化）
• 実際にパフォーマンスを改善した事例（Before/After）

理論だけでなく、“目で見て速くなる”デモを通して、
実行計画がただのテキストではなく「データベースの会話」に見えてくる瞬間を体感してもらいます。

テーマ

webフロントエンドにおいて、実用的なプラグインシステム(ユーザーの書いたコードを安全に実行する環境)をどのように実現するか

想定する参加者層（前提知識）

• JavaScriptの実行環境自体に興味があるようなフロントエンドの中上級者の方
• CORSやCSPなどのブラウザのセキュリティ機構について最低限の知識がある方
• 「プラグインシステム」や「ユーザーカスタマイズ」といったユーザーの書いたコードを実行する機能を提供するサービスを開発してる・したい方

トーク概要

SaaSなどのWebサービスには画面や挙動をユーザでカスタマイズできる機能を提供するものがあり、Webフロントエンドにおいてはユーザの作成したJavaScriptを実行することでこれらの機能を実現することが多いです。

一方で、ユーザーの作成したコードを無責任に実行することは重大なセキュリティリスクに繋がります。また仮に悪意がないコードだとしても、以下のような問題を容易に発生させます。

• 過大な権限による不可逆な操作を行えてしまう / 逆に権限を制限しすぎるとプラグインで実行したいことができない
• 追加したコードによって製品本体の挙動が不安定になる
• 製品の挙動や構造に強く依存するコードが原因で製品自体のアップデートがしづらくなる

これらの問題を避けるためには、ユーザーの作成したコードを安全に隔離しつつ、細かく権限を設定できる仕組みが必要です。

このセッションでは、「ユーザーが追加したスクリプトを実行する機能」や「プラグイン/カスタマイズ機能」の開発における課題と、その解決策となる関連技術について解説します。より具体的には、実際にtoBのSaaSサービスで「ユーザーの作成したコードを実行する新しいプラグイン機能」を設計・開発した経験をもとに、以下のような内容について話します。

• ユーザーの作成するコードを実行する難しさについて
  • セキュリティ上の問題だけでなく、製品の可用性などにも関わる
• 現状考えられる隔離の方式とメリット・デメリット
  • iframe / web worker / JSEngine on WASM / Realm Shims
• iframeを選択した理由と注意すべきこと
  • オリジンによるリソースアクセス制限やCookieについて
• 機能やアクセス先を制限するための仕組み
  • CSPの設定・Channel Messaging APIによる疎通と注意点
• これから期待される関連仕様
  • ShadowRealm について

これらの「プラグイン/カスタマイズ機能」開発に携わる方々をサポートするとともに、「JavaScriptを安全に実行する」という観点から、ブラウザのセキュリティ機構やJavaScriptエンジンの仕組みへの理解を深めるきっかけを提供することを目指します。

テーマ

4つの異なる言語・フレームワークにおける「列挙型（Enum）」の比較から学ぶ、設計思想の多様性と型安全性の未来

想定する参加者層（前提知識）

中級者以上を対象 （複数の言語のいずれかで開発経験があり、基本的な型システムやデータベース連携の概念を理解しているエンジニア）
Java、C#、Ruby、JavaScript（TypeScript）を想定しています。異なるコミュニティが集まるこの場所で、あえてすべての言語に共通する、そして最も設計思想の違いが表れる機能の一つ、「列挙型（Enum）」を徹底的に解剖します。

一見シンプルなEnumですが、その実装は言語の哲学そのものです。本セッションでは、この共通概念が各言語でどのように進化し、開発者にどのような設計上の恩恵と制約をもたらしているのかを、実用的なコード例を交えて比較・考察します。

トーク詳細

本トークでは次の内容について話を進めます。

1. Enumとは一般的にどのようなものか？
2. Enumはクラスか定数か
   　2.1. JavaとC#でのEnumの比較
   　2.2. 後発言語、PHPでの扱い
3. ネイティブでEnumを持たない言語のアプローチ比較
   　3.1. TypeScriptでのEnumの工夫
   　3.2. Ruby on RailsでのEnumの使われ方
4. 全体への洞察
   　4.1. Enumの役割を改めて見直す
   　　4.1.1. 多値の表現力、振る舞いのカプセル化、永続化やリファクタリングといった観点からそれぞれのEnumについてまとめ直します
   　4.2. 言語の思想への考察

Enumは「クラス」か「定数」か？

まず、JavaとC#という兄弟のような言語におけるEnumの根本的な違いを明確にします。

JavaのEnumはEnum定数がフィールドとコンストラクタを持つ「クラスインスタンス」です。これにより状態と振る舞いをカプセル化し、ポリモーフィズムを実現する設計哲学を解説します。

C#のEnumは「名前付きの整数定数」として扱います。拡張メソッドや[Flags]属性による実用的な拡張に焦点を当てます。

そして後発のPHPのEnumはJavaのメソッドとC#のバッキング値の良いところを取り入れ、特にDB連携を意識したモダンな設計になっている点を紹介します。

ネイティブでEnumを持たない言語のアプローチ比較

ネイティブでEnumを持たない言語が、いかにしてこの概念を取り込んだかを探ります。

TypeScriptのEnumは開発時の型安全性と、それがJavaScriptにトランスパイルされた際の挙動の危うさ（数値の型安全性の問題など）を示します。最近のJavaScriptへのネイティブEnum導入に関するTC39の議論にも触れ、この機能の未来を予測します。

一方、Ruby on Railsのenumは言語本体ではなく、フレームワーク（Rails）の機能としてDB連携に特化することで、生産性と利便性を極限まで高めたアプローチを考察します。静的型付けの世界では見られない、Rails特有の「規約の力」を強調します。

全体への洞察

最後に、これらの比較を通して得られる重要な知見を共有します。

多値の表現力としてJavaの複数のフィールド vs PHPの単一のバッキング値 vs TSの柔軟性。
振る舞いのカプセル化としてEnum自身にロジックを持たせるべきか、外側でswitchで分岐すべきか。
永続化とリファクタリングとしてDBに依存するRailsのenumと、依存しないJava/C#のEnum、どちらが長期的な保守性に優れるのか。
など、Enumを基準として各言語ごとにどのように「列挙型」と向き合っていくべきかを示します。

このセッションは、単なる機能紹介に留まらず、あなたの日常的なコーディングにおける「良い設計とは何か」「型安全性とは何か」という問いに、複数の視点から答えを与えます。他言語のEnumを知ることで、あなたのメイン言語のEnumが持つ強みと制約を再認識し、より深く、より保守性の高いコードを書くための新たな視点と熱意を持ち帰ってください。

テーマ

ORMやフレームワークに依存しない、SQL主導のDBマイグレーション。
スキーマを長期的に管理するための合理的アプローチを、ツールと思想の両面から考察します。

想定する参加者層（前提知識）

• Webサービス等のDB設計や運用に関わるエンジニア
• ORMやフレームワークのマイグレーション機能を使った経験がある方

トーク概要

ある程度経験を積んだエンジニアなら誰しも一度は「これはSQLで書いたほうが早い」と感じたことがあるでしょう。
ORMやDSLによるDB操作は安全面など様々なメリットがある一方で、RDBMSの機能や性能を限界まで引き出すことはできません。
DBのマイグレーションに関しても同様に、SQLで書きたい、あるいは書かざるを得ない場面が稀によくあります。

データの寿命がサービスのそれよりはるかに長いことはよく知られています。ではスキーマの寿命はどうでしょう。
スキーマはDBと共に生きるものであり、フレームワークやライブラリ、ツールといった周辺技術よりもずっと長命なのです。
寿命の短いものでスキーマを管理するより、DBと寿命をともにするSQLを用いるのが合理的ではないでしょうか。

一方で、SQLだけでDBマイグレーションを運用するには多くの課題があります。
本セッションでは、SQLだけで安全かつ確実にDBマイグレーションを行うために必要な要素を整理し、それを支えるためのツール「migy」とそのコンセプトを紹介します。
SQLをマイグレーションの中心に据えてRDBMSの力を最大限に活かしつつ、長期的な信頼性を実現するためのアプローチを提案します。

ゴール

• 熟練エンジニアがSQLに立ち返る理由を、技術要素の寿命構造から理解する
• スキーマ・データ・アプリ・ツールのライフサイクル関係を整理し、SQLで管理する合理性を掴む
• SQLによるマイグレーションの課題とその克服方法を通じて、ORMやFWに依存しない持続的なデータ管理の視点を得る

2025年5月、Java 25がリリースされました。

「えっ、Javaってもう25まで進んでるの？」――そう驚いた方、実はJavaはその間、驚くほど大きく変わりました。
あなたのイメージするJavaのバージョンはいくつでしょうか？
Java 11ですか？それとも8ですか？まさか7以前なんてこと…。

Java 8/11の時代から、Javaは6ヶ月ごとに新バージョンをリリースしながら着実に進化を続けてきました。
型推論、レコード、パターンマッチング、仮想スレッドなど、新しい機能が次々と投入されており、昔の知識のままで最新のコードを見たら、「これ、本当にJava？」と二度見してしまうことでしょう。
Java仮想マシンやガベージコレクタの改善、AOTコンパイラのサポートなどによって、実行時のパフォーマンスも劇的に向上しました。

本講演では、「懐かしのJava」から「モダンなJava」への変化を、実際のコード例とともに紹介します。
「Javaは古い」「冗長で書きにくい」というイメージを持っている人にこそ、変貌したJavaを見ていただきたいです。

対象者

• Javaの最近の動向が知りたい人
• 古いバージョンのJavaを使っていて、時代に置いていかれたくない人
• Javaは随分触ってないけど今どうなっているのか気になる人

テーマ

Javaもどんどん変わっているということを知ってもらいたい

---私はこんな人！---
私は日頃、QA（テストエンジニア）として案件にアサインされています。

作業範囲はIT、ST、リグレッションなど状況に応じて様々。
管理ツールなどは利用しつつ、未だテスト設計そのものはほぼ手書きになっているのが現状です。
そんな中、社内外ともに積極的なAI利用が求められ、苦手なAIと真正面から向き合わないといけない日々が到来してしまいました。。

---こんな方に聞いて欲しい---
開発に関わるすべての方。
現場でバリバリ開発やテストをしている方も、案件管理などマネジメントラインの方も、すべてが対象です。

---テスト設計とAI---
私はテスト設計（≒QA）とAIはとても「相性が悪いもの」だと思っています。

本当は気軽にあれもこれもAIに読み込んで処理してもらいたい・・・
でも現実はそうはいかず、ただ資料を読み込ませたりルールを指定するだけだと、結果を出力する度に内容が変わっていたり、あるものを「ない！」と元気に返してくれたり、なんだかんだで使い物にならず頭を抱えます。

仕様書／設計書は基本的に日本語で書かれていますので、時に書き手により文体や表現の違う文章を処理しないといけません。
フローチャートなど、AIが苦手とする図表などがふんだんに含まれている場合も多々あります。
そもそも、昨今アジャイル開発が増えている中、仕様書がちゃんと作成されていないことも・・・

そう、テスト設計はAIと相性の良さそうなプログラミング言語ではなく「自然言語」、ひいては「人」を相手にしないといけない、という大きな壁が立ちはだかるのです。

また、利用できるAIには制限があります。
できれば日本語の処理に強いものを利用したいのですが、予算や会社都合が発生したりします。

私はいまcursorを利用しているのですが、そもそも開発者ではないのでエディタ系の画面がまず見慣れない・・・
こんな思わぬ落とし穴もあったりします。

---この登壇でお伝えしたいこと---
近年、AI活用をテーマにした有効なお話はたくさんありますが、たまには扱いが下手な人が、苦手なりに頑張るお話があっても良いんじゃないかな？と思い、この内容で応募させて頂きました。
特に開発とQAではAIが作業効率に寄与する割合に大きな差があるものの、現場目線だとそれが伝わりにくく「やりたくないだけでしょう？」と思われてしまうこともしばしば。
そんな誤解を少しでも解消すべく、どのようなことに苦戦し、試行錯誤しているのか・・・をお話する予定です。
また、この問題の解決にはエンジニアの協力がとても重要だと感じていることもお伝えできればと思っています。

※政治に関する話題は最低限にしている、あくまで技術的な視点でのトークです。
※特定の政治家・政治団体・政党のお名前を一切お話しません。

テーマ

テクノロジー × デモクラシー

想定する参加者層（前提知識）

何かを作ってみたい、アウトプットをしてみたい方
政治なんてさっぱりわからない！という方（政治の知識は不要です。私も無いです）
学生の発表なので難しい話はしません、できません！

トーク概要

みなさんは「デジタル民主主義2030プロジェクト」をご存知でしょうか。
「デジタル民主主義2030」は、技術の力で市民の声を活かし、政治をより良い形に進化させることを目指したプロジェクトです。透明性と信頼を重視し、多くの人々が政策に参加できる未来を目指しています。
今回は、このプロジェクトから生まれたオープンソースソフトウェア（OSS）である "Polimoney" について、技術的な視点からご紹介します。

「Polimoney」は、政治とお金にまつわる「複雑なデータ」や「アナログな業務フロー」といった課題を、テクノロジーの力でボトムアップに解決しようとする「シビックテック」（※）の取り組みです。
（※市民がテクノロジーを活用して社会課題を解決する活動）
このプロジェクトは誰でも活動に参加できるのが特徴で、学生である私もcontributorとして開発に参加しています。

「なぜ今、この領域にエンジニアリング（OSS）が必要なのか？」という視点から、私たちが直面している課題と、それをどう乗り越えようとしているかをお話しします。

• 「政治とカネ」の現場にある「技術的負債」
• なぜデータ活用が進まないのか？制度と実務のギャップ
• Polimoneyによる課題解決のアプローチ
• 学生エンジニアが政治系OSSに参加したリアルな体験
• 「コードを書く」だけじゃない！ OSSへの貢献方法

デジタル民主主義2030 https://dd2030.org/
polimoney https://polimoney.dd2030.org/

【テーマ】
・ ノーコードツールによるコードレス（=コードを書かない）開発の導入による恩恵・課題など
・ Lambdaレス（=コードレス）アーキテクチャの特徴
※以後「コードレスアーキテクチャ」について「Lambdaレスアーキテクチャ」と記載します。

【想定する参加者層】
・ ノーコードツールやLambdaレスアーキテクチャについて興味を持っている方、知りたい方
・ 業務改善に興味を持っている方、業務改善が課題となっている方
・ AWS Step Functionsについて興味を持っている方、知りたい方（使用経験は必須ではありませんが、経験があるとなお一層理解が深まります）
※ エンジニアである必要は全くありません。非IT部門の方にとっても十分役に立つ内容となっています。

【トーク概要】
私は今年、KDDIグループ約4000人が使用するJira/Confluenceのオンプレ→クラウド移行を実施しました。
そしてその際、業務改善として実施したオペレーションの自動化において、AWS Step FunctionsおよびJira Automationなどノーコードツールによる「Lambdaレスアーキテクチャ」を導入しました。

もともとアプリ開発といえば「コードを書く」ものであり、AIが台頭した現在は「AIにコードを書かせる」という流れになっていますが、やはり現在でも「コードを書く」のが主流だと思います。
しかし近年は運用工数削減や非エンジニアの方でもアプリ開発ができる事、そして「Lambdaレスアーキテクチャ」の普及もあり、AWS Step Functionsのようなノーコードツールによる「コードを書かない」開発を導入するケースも増えています。

はたして「コードを書かない」開発は「コードを書く」開発と比較して何が良いのでしょうか？
そして、何が課題になるのでしょうか？

そこでこのセッションでは、先ほどの業務でのLambdaレスアーキテクチャの導入経験から学んだ
・ Lambdaレスアーキテクチャの特徴
・ ノーコードツールの恩恵と課題
・ AWS Step Functionsを導入する際の注意点・ノウハウ

について、エンジニアおよび非エンジニア、両方の観点からお話ししたいと思います。

【セッションゴール】
・ Lambdaレスアーキテクチャ、ノーコードツールの概要、およびノーコードツール導入によるメリット・注意点をエンジニアと非エンジニア、両方の観点から理解できるようになる
・ AWS Step Functionsを導入する際のノウハウや注意点を理解できる

【テーマ】
・ システムやデータベースなどの大規模マイグレーションを担当する際、それをどう実施するか（=担当者観点）
・ 大規模マイグレーションが発生した際、それに対して何をすべきか（=ユーザー観点）

【想定する参加者層】
・ 大規模マイグレーションを担当する可能性のある方（インフラ管理、IT資産管理者など）
・ システムやデータベースなどを利用したアプリケーションを開発・運用使用している方（アプリケーションエンジニア、クラウドエンジニアなど）
※自分が大規模マイグレーションの担当者でなくても、十分役に立つ内容となっています。

【トーク概要】
皆さんが普段使用しているシステム・データベースなどのリソースは、いつの日か必ずEoL(End of Life)がやってきます。
そしてその際、もしかしたら会社並びにアプリユーザー全体に影響を及ぼすような大規模なマイグレーションが発生するかもしれません。

もし自分がそんな大規模マイグレーションの担当になったとしたら、皆さん何をすればいいのか、何に気を付けたらいいのか、お分かりになるでしょうか？
またそうでなくても、大規模マイグレーションが発生したリソースを使ったアプリを開発・運用していた場合に、何を対応すればいいでしょうか？

このセッションでは、某有名決済アプリ関連のデータベースマイグレーション、そして弊社にてKDDIグループ4000人以上が使用するJira/Confluenceの大規模マイグレーションの経験から、
・ 自分が大規模マイグレーションの担当になった際、何に注意し、何をすればいいのか
・ 大規模マイグレーションが発生したリソースを使ったアプリを開発・運用していた場合に、どんな対応をすればいいのか

についてお話したいと思います。

また大規模マイグレーションの担当者観点から見た「大規模マイグレーションが発生した際のアドバイス」もお話しする予定です。

【セッションゴール】
・ 大規模マイグレーションの担当になった際に注意すべきこと、意識すべきこと、実施すべきことを理解できる
・ 大規模マイグレーションが発生した際に対応すべきこと、意識すべきことが理解できるようになる

HTMLのbuttonタグはWebサイトに必ずと言っていいほどあるとても重要なUIとして存在します。

しかし、ボタンを押すという一見単純なUIでありながら、HTMLのbuttonタグとしてみると現代では、様々なContent attributesが存在しています。　またフロントエンドエンジニアとしてボタンUIをコンポーネント化する際の設計時に、責務について頭を悩ます存在でもあります。

このLightning TalkではHTMLのbuttonタグの仕様を紹介します。　内容を聴いてWebUIのボタンについて一緒に理解しましょう！

生成AIの普及により、エンジニアの開発スタイルは劇的に変化しました。
Claude CodeやCodexなどのコーディングエージェントを利用することで、誰でもある程度のコードを書けるようになり、知らないことの調査やエラー解決も短時間で可能になりました。
しかし、その一方で「生成されたコードを理解できていない」や「AIの回答の成否を判断できていない」といった課題も顕在化してきており、AIに使われる側に回ってしまうケースも増えています。

だからといって、AIを禁止にするのはナンセンスです。
むしろ、これからの時代、AIを使いこなす力は不可欠なスキルとなります。
そのために必要なのは、AIに依存するのではなく、AIを活用して成長するための新しい育成デザインです。
開発スタイルが変化したのと同じように、育成のアプローチも変化させる必要があります。

本セッションでは、AI時代のエンジニア育成において実際に遭遇した課題と、それに対する実践的なアプローチを紹介します。
実際にチームで試行錯誤しながら取り組んでいる施策として、AIを使わずに問題解決を考える「No AI Day」や、AIとの対話を通じて理解を深める「learnコマンド」、「パーソナライズされたAIコードレビュー」などを共有します。

AI時代に求められるのは、AIに「使われる側」ではなく「使う側」になるための育成です。
現場での試行錯誤から得た知見を通して、明日からチームで試せる実践的なアプローチを共有します。

■ 対象聴衆／前提スキル

• Webエンジニア、インフラエンジニア、AI・音声認識技術に関心のある技術者
• 普段はHTTPやWebSocket、クラウドAPIを扱っているが「電話通信」にはあまり触れたことがない方
• 難易度：初中級（通信や音声処理の基礎から実例まで）

■ 登壇者プロフィール
通信事業者向けの研修事業を経て、2013年からCPaaS領域に携わる。
2016年よりTwilioのエバンジェリストとして活動し、現在はVonageのエバンジェリスト。
電話・WebRTC・生成AIを組み合わせた音声アプリケーションの開発・普及に取り組むフルスタックエンジニア。
年間100件以上登壇し、APIと音声の融合領域でコミュニティ啓発を行っている。
元、赤い芸人。

■ セッション概要
Web技術の進化により「電話」はいま、APIで自在に制御できる時代を迎えています。
さらに生成AIの登場によって、音声の世界にも新しい開発体験が生まれました。
本セッションでは、電話の基本構造からVoIP／WebRTC、STT・TTS、生成AI連携まで、Webエンジニアにも馴染みのある技術を軸にわかりやすく解説。
デモでは「AIがリアルタイムに電話対応する」仕組みを紹介し、音声通信の新しい可能性を体感していただきます。

■ 学び・持ち帰りポイント（Take-aways）
HTTP／WebSocketなどWeb標準技術で“電話”を扱う基本概念を理解できる
VoIP／WebRTC／STT／TTS／生成AIを組み合わせた音声アプリ構成をイメージできる
通話のリアルタイム処理（音声ストリーミング・LLM連携）の仕組みを知る
「電話×AI×Web」領域の開発ネタ・実験アイデアを持ち帰れる

登壇や記事執筆といった発信活動は、エンジニアのキャリアアップに良い影響をもたらします。

発信活動を通して、自身の知見・経験が言語化され、誰かの課題を解決し、キャリアの可能性が広がる。発信活動を継続することで、新たな仲間との出会いも生まれ、活動そのものが「楽しい！」と感じるようになる。

多くの人々が「何かを得られる」「何か楽しいことがある」と信じ、実際にリターンがあるからこそ、富山の地でのイベントが10年も続くのだと思います。

そんな発信への熱い想いを持つであろうみなさんの組織に、発信文化は根付いているでしょうか？

発信が組織の文化として根付くには、自分以外のメンバーも継続的に発信へと取り組んでいる必要があります。一方で見落としがちですが、発信活動（特に外部への発信）は、しばし多くの労力を伴います。自身の思考整理にはじまり、情報の裏取り、執筆作業、発表練習などなど。発信をしたことのない誰かに、発信活動を通して「何かを得られる」「何か楽しいことがある」と感じてもらい、能動的な行動へとつなげるには、様々な壁を超えなければなりません。

本セッションでは、長らく個人で発信活動を続けつつ、業務ではDevHRとして試行錯誤を積み重ね、組織全体の発信数が年間10件にも満たなかった状態から、直近半年で50件を超えるまで引き上げた実績も交えつつ、「組織全体で壁を超え、発信を文化として根付かせる」ために必要なことについて、シェアできたらと思います。

Learning Outcome

• 発信活動のモチベーションは、大きく3つに分類できる
  • 「発信そのものが楽しいから」
  • 「個人の成長・ブランディングのため」
  • 「組織の成長・ブランディングのため」
• 人を発信活動へと向かわせるには、「腹落ちする理由」と「機会」が必要である
• 発信活動の継続に必要なのは、外部露出を増やすことではなく、言語化習慣を身につけ、発信に対するFBが得られる環境を用意すること

想定する聴講者

• 身近に発信活動の仲間が欲しいと感じる方
• 三日坊主になりがちな発信活動を長く継続させたいと感じる方
• 組織に発信文化が根付かず困っている、または根付かせたいが何から着手すればいいか分からないマネージャーの方

セッションの流れ

1. 我々はなぜ発信するのか？

• 発信活動のモチベーションの3分類について
• もし誰かを発信へと向かわせるのなら、発信以外の活動を上回る楽しさ、あるいは意義を提示しなければならない

2. 我々は発信活動から何を得るのか？

• 発信活動の継続に最も重要なのは、言語化の習慣を身につけることである
• そして、発信活動によって得られる最大のメリットは、自身の言語化に対するレスポンス・FBを通して、言語化の精度が発信を繰り返すたびに上がっていくことである

3. 我々は発信文化を広めるために何をすべきなのか？

• そもそも、1や2の考えに至ったのは、7年以上続けている自身の登壇活動から得た成功体験と、自身が所属する組織に発信文化を持ち込もうとして頓挫し続けた失敗経験が背景にある

成功体験

• 外部への発信を継続することで、エンジニアとしての成長の天井を自ら引き上げることに成功した
• いつしか「組織の顔」として社内で認識されるようになり、人事職という新しいキャリアのルートを切り拓いた

失敗体験

• 「発信そのものが楽しい」という自身のモチベーションを自分以外の人にも当てはめてしまい、最初の一歩すら踏ませることができない
• 「個人の成長・ブランディング」につながるメリットを示すも、組織が「他者や組織に対する貢献・ホスピタリティを重視する」カルチャーであるために、高い心理的ハードルを超えるほどの価値を感じてもらえない

転機

• 難航するエンジニア採用へのテコ入れのため、これまで殆ど注力してこなかった採用広報・技術広報の領域に大きな投資をすることが決まる
  • そして、その予算編成と年間の活動計画の立案を突然任される
• 上位スポンサーを決めたカンファレンスのうち、3件はスポンサーセッションをもらえることに
  • ここで初めて「登壇を業務として、自分以外の誰かに依頼する」経験をする
  • 登壇のネタは、依頼先のメンバーとすり合わせしつつ、こちらから提案
  • 結果、「組織の成長・ブランディングのため」にお願いした登壇は、自分では絶対に生み出すことのできない素晴らしい内容のものとなった

※以降、直近の発信文化醸成の試行錯誤を交えつつ、Learning Outcomeへとつなげていきます。

概要

エンジニアとして実務に携わり始めた私は、最初の数ヶ月で数々の"しくじり"を経験しました。
例えば、SQL の条件指定ミスでスコープ外のデータが見える危険なバグを作成したり、「善意のリファクタリング」が先輩の変更とコンフリクトして修復不能に陥ったり...。さらには、AI レビューツールの提案を鵜呑みにして無駄な修正を繰り返すという、しくじりも経験しました。
しかし今となって思うのは、これらの失敗こそが最高の学習材料でした。特に AI ツールを活用するようになってから学んだのは、AI やツールが答えをくれる時代だからこそ、「自分の頭で考え、判断する力」が重要であるということです。
このセッションでは、ジュニアエンジニアが現場で直面する様々な課題と、そこから学んだ「AI 時代に必要な判断力」について等身大でお話することで、これから同じ壁にぶつかるジュニアエンジニアや、彼らを支える先輩エンジニアの助けになる時間にしたいと思います。

対象者

• 実務 1 年目前後のジュニアエンジニア
• ジュニアエンジニアを育成・レビューするメンター
• チーム開発に慣れず悩んでいる初学者
  ※主な言語は Ruby ですが、特定技術の知識は不要です

トーク構成
第 1 章：新米エンジニアの洗礼

• 初めて直面する膨大なソースコードに戦々恐々

第 2 章：俺のしくじりを超えてゆけ

• データ流出寸前！SQL 条件指定の落とし穴
• これが車輪の再発明！？
• 「それ…AI がやりました！」問題
• 原因は…エラーメッセージに書いてありました
• 善意のリファクタリングが招いた大惨事

第 3 章：AI レビューツール導入編

• 激突！！CodeRabbit vs Rubocop
• AI 君の嘘つき…！

第 4 章：失敗から得た学び編

• 自分の頭で考えて言語化してみよう
• 失敗を恐れず挑戦しよう
• コードレビューは最高の成長機会

伝えたいこと
AI やツールが正答を示してくれる時代だからこそ、私たちは「判断する力」を磨かなければならないと感じています。
AI は確かに効率的で、間違いを減らしてくれます。
しかし、すべてを委ねてしまえば、自分で考え、判断し、失敗から学ぶ機会が失われてしまいます。

ツールは答えをくれますが、どの答えを採用するかは、最終的に自分が決めなければなりません。
このセッションで伝えたいのは、「失敗を恐れず、自分の考えで決めること」の大切さです。

優秀なエンジニアの成功談ではなく、“何度もしくじりながら少しずつ判断力を磨いてきた ジュニアエンジニア”として、同じように悩む誰かの背中をそっと押せる時間にしたいと思います。