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

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

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

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

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

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

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

テーマ

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もどんどん変わっているということを知ってもらいたい

【テーマ】
・ ノーコードツールによるコードレス（=コードを書かない）開発の導入による恩恵・課題など
・ 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に「使われる側」ではなく「使う側」になるための育成です。
現場での試行錯誤から得た知見を通して、明日からチームで試せる実践的なアプローチを共有します。

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

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

多くの人々が「何かを得られる」「何か楽しいことがある」と信じ、実際にリターンがあるからこそ、富山の地でのイベントが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 は確かに効率的で、間違いを減らしてくれます。
しかし、すべてを委ねてしまえば、自分で考え、判断し、失敗から学ぶ機会が失われてしまいます。

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

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

【テーマ】
サーバーサイドレンダリング（SSR）における「クロスリクエスト状態汚染」の危険性と、その根本原因となる設計上の問題の解説。モダンWebフレームワーク「Astro」を例に、リクエストごとに状態を安全に分離するための具体的な設計パターンと実践的対策。

【想定する参加者層（前提知識）】
Webアプリケーションの開発経験がある方 (特定のフレームワーク（Astroなど）の知識は必須ではありません。)

【トーク概要】
「ローカル開発では完璧に動くのに、本番環境で時々データがおかしくなる…」 そんな経験はありませんか？その原因、もしかしたらサーバーサイドでの「状態管理」の実装にあるかもしれません。

サーバーサイドレンダリング（SSR）のような、サーバー上でリクエストごとに処理を行うアーキテクチャは、Webのパフォーマンスを向上させる強力な手法です。しかし、クライアントサイドの感覚で安易に状態管理ライブラリを導入すると、実は時限爆弾を抱えている可能性があります。

同時リクエストが多発するサーバー環境では、あるユーザーのために用意された状態が、競合によって別のユーザーに漏洩してしまう、「クロスリクエスト状態汚染」という深刻な問題を引き起こす可能性があるのです。これは単なる表示の不具合に留まらず、個人情報漏洩に直結しうる、極めて危険なセキュリティリスクです。

このセッションでは、多くのWeb開発者が見落としがちな、このサーバーサイド特有の落とし穴を深掘りします。 なぜこの問題が起こるのか？その根本原因は、サーバー上でただ一つの共有データ置き場を、複数のリクエストで使い回してしまうという、設計上の問題にあります。 セッションでは、モダンなWebフレームワーク「Astro」と状態管理ライブラリ「Nanostores」を具体的なケーススタディとして取り上げ、どのようなコードが「地雷」となり、公式ドキュメントがなぜサーバーサイドでの安易な利用に警鐘を鳴らしているのかを、実際のコードを交えて解説します。

ClaudeやChat GPTなどの生成AIでは、プロンプトを記述することで出力をコントロールします。
この際、自然言語ではなく疑似コードを用いてプロンプトを記述することで、手順や論理構造を端的に指示するテクニックが知られています。
疑似言語にはJavaScriptの文法を用いる例が多いですが、SudoLangなど専用の文法も考案されています。

この手法は一見便利そうですが、実際にどれだけ正確に意図が伝わるのでしょうか？
if文のネストは正しく解釈されるのか？ for文やwhile文によるループは正確な回数繰り返されるのか？ C言語のマクロ・Go言語のGoroutine・Prologのバックトラックなど、言語ごとの特殊な機能は正しくエミュレートされるのか？

わたし、気になります！

というわけで試した結果を共有します。

想定する参加者層
生成AIに関心を持っているエンジニア。
特にプロンプトエンジニアリングの経験は問いません。

テーマ
生成AIの疑似言語によるプロンプティングの正確性・限界を確認する

(レギュラーセッションと同内容で応募していますが、LT枠に収めるため事前説明は省いてプロンプト例と結果を出して一言解説つけるくらいのテンポ感を想定しています)

昨今のITエンジニアは求められる知識と技能が広がり続けています。私自身もWeb業界にいてその変化を強く感じてきました。これまでも新しい技術を学び、自分のできることを増やす機会は多くありましたが、生成AIの登場によって学び方は少し変わりました。

これまでバックエンドエンジニアとしてキャリアを積んできた私がフロントエンド開発に挑戦し、日々の実践と生成AIの活用を通じて成長していった過程をお話しします。
最初はTypeScriptでCLIツールやREST APIを作るところから始め、React.jsで小さなアプリを作ってアウトプット。転職後は実務でフロントエンド開発を進んで担当し、ペアプログラミングを実施することで自然と自らフロントエンド開発を進められるようになりました。

学びを支えたのは「継続して手を動かすこと」と「生成AIを学習の加速装置として使う姿勢」です。自分に無い実装の引き出しを他の人と一緒に実装することで獲得したり、AIの出力を鵜呑みにせず一次情報を調べ、実装で確かめることで理解を深めました。人との協働による実践的な成長と生成AIによる学習サイクルの高速化がうまく融合しました。

その積み重ねの結果、私はフロントエンド中心のプロジェクトに参加し、自身の責務を果たすことができました。
このセッションでは、「新しい領域を学ぶためにできる工夫」、「生成AIによって変化した自学習」、「実践を通じてどう変わっていったか」を、私自身の経験をもとにお話しします。

話すこと(変更の可能性あり)
・ 新しい領域を学ぶときの工夫
・ 生成AIによって自学習がどのように変化したのか
・ たくさんの実践を経て自分がどう変化したのか

ブレットボードで回路を組んだり、はんだ付けをしたり電子工作に慣れてくると基板を作りたくなりませんか？なりますよね。
JLCPCB を初めとした安価な中国メーカーの誕生により以前よりも基板を作るハードルはグッと下がりました。

しかしブレットボードやユニバーサル基板で試作した回路を実際どうやって基板にするかわからない方も多いことでしょう。
このセッションでは Kicad を使い、カンファレンスや勉強会などで使えるような名刺基板を作って発注するところまでを解説をしながら行います。

このセッションを聞けばすぐに皆さんも基板を作ることができるようになるでしょう。
ぜひ自分だけの基板を作ってTinyGoで遊んでみませんか。

想定する参加者層

・ 電子工作が好き、興味がある方
・ 基板を作ってみたい
・ もの作りが好き
・ TinyGoに興味がある方

概要

タイトルを見て「本当ですか？」と思われるかもしれません。事実、2024年まで登壇活動はおろか社外コミュニティへの参加はほとんど行っておりませんでした。そんな経歴の私ですが、2025年（10月時点）では社外登壇数４０件超を達成しています。今回のセッションでは「未経験でも（頑張れば）私と同じペースでアウトプットできる方法」について紹介したいと思います。

聴講者に持ち帰ってもらいたいこと

1. 一見無謀なアウトプット目標であっても工夫と努力で達成可能
2. 登壇活動を行っている方は特別な方ではない
3. 社外発信の種は周りにいくらでもある

対象聴講者

1. 技術イベントに参加しているが登壇活動を行ったことがない方
2. 登壇にチャレンジしたいがハードルの高さを感じている方
3. 定期的に登壇活動を行っているが発表ネタにマンネリ感を感じている方

セッションの流れ

はじめに（5分）

自己紹介、2024年まで発信活動について紹介します。本セクションではエンジニアとしてのキャリアスタートから登壇活動を全く行っていなかった2024年10月までをふりかえります。

登壇に目覚めたきっかけ（10分）

登壇活動を始めたきっかけ、登壇したことで得られた体験について紹介します。私が登壇活動に初めてチャレンジしたのは2024年11月に開催されたAWSコミュニティ（JAWS-UG Education支部）でした。社内でも講師として人前で発表する機会は比較的多くありましたが、社外での登壇は初めてでした。今までの社内での発表と違い、「短い時間で自分の想いを伝える」ことに非常に苦労しました。本セクションでは「はじめての登壇経験を通じて失敗したこと、失敗から得た体験」について紹介したいと考えています。

年間40件以上登壇してみて（10分）

2024年11月の初登壇から今までの登壇遍歴、登壇活動を通じて見えたナレッジについて紹介します。最初の数か月は月に1件程度登壇するのがやっとでした。そのうえで、月に2~3件登壇するために必要なアクションについて模索していました。模索する中で「多くの登壇数をこなしている方の共通項」について見出すことが出来ました。結果として、多い時には月8件以上の登壇活動を実現することが出来ました。本セクションでは未経験者でも頑張れば継続的に月2～3件以上登壇するためのポイントについて紹介したいと考えています。

まとめ（5分）

本セッションのまとめ、聴講者へ持ち帰ってもらいたいことについて紹介します。社外発信を行うなかで「人前で話せる経験なんて無い」といった不安があると思います。初登壇する前は私も同じように考えていました。登壇活動を行っていくなかで、「誰もが登壇するためのネタはある、気づいていないだけ」という事実に気づきました。本セクションでは、聴講者がこれから登壇活動してもらうための後押しにつながる話を行いたいと考えています。

プログラムを書いたり文章を入力したりする際に欠かせないキーボード。
その中には、スイッチやキーキャップなどのパーツを自分で選び、好みの打鍵感やレイアウトを追求する自作キーボードという世界があります。

自作キーボードのファームウェアは、従来は C 言語で書かれることがほとんどでした。
しかし、 Go 言語で書けるとしたらどうでしょうか？

このトークでは、組込環境で使える Go である TinyGo を使って、自作キーボードのファームウェアを作る過程を紹介します。

• 自作キーボードを作るために必要な要素
• TinyGo を選択した理由と、そのメリット
• TinyGo で実際に開発する際の流れ

さらに、セッション後半ではライブコーディングを行い、 TinyGo でシンプルなキーボードファームウェアを一から作るデモを行います。

具体的には、キー入力、レイヤー機能、 USB HID 出力を最小構成で実装します。
Go でこんなに簡単にキーボードが作れるのか、という体験をお届けします。

概要
みなさん、エンジニアになったばかりの頃の気持ち、覚えていますか？
日々の開発に追われ、いつの間にか仕事の楽しさや「手触り感」を見失っていませんか？
このトークでは、安定した公務員という“養殖場”を飛び出し、エンジニアという大海原にやってきた僕が、エンジニアになって1年半、この世界でどう泳いで、どうもがいて、どんな楽しさを発見してきたかお話しします。
自分のコードが世界を動かす手応え、お客様との対話、チームで大きな壁を越えるスリル。
僕の回遊の物語を通じて、「あ、だからこの仕事は面白いんだ！」と皆さんの日常にある輝きを再発見してもらえたら嬉しいです！

話すこと
なぜ安定の“養殖場”を飛び出したのか？
大海原で見つけた、エンジニアという仕事の楽しさ
バブルに乗った僕が辿り着いた、最高の「結果」とは

対象者
エンジニアという仕事の楽しさを改めて感じたい方
“養殖場”育ちのエンジニアが、どんな泳ぎ方をしているのか興味がある方

概要

3年目の新人エンジニアとして入社2週間で、2.5ヶ月以内の採用管理ツール（ATS）のMVP開発を一人で任されました。
既存SaaSの上に Next.js + Hono + AWS Lambda で構築し、DDDを前提に拡張可能な設計を担当。
要件定義は済んだ状態で引き継いだものの、ページデザイン未定、外部連携（A社は運用まで6週間かつ要運用実績、B社は連絡不通）など不確実性が多く、仕様確定を待たずに進める必要がありました。
既存コードのキャッチアップから設計・実装まで、短期間で並走させるために取った「考え方」と「進め方」を実体験ベースで共有します。

想定ターゲット

• 新しいプロジェクトを中途参入または単独で引き継ぐエンジニア
• 要件定義後のフェーズから設計・実装を任される中堅層（2〜5年目）
• スタートアップや小規模チームで、不確実性の高いMVP開発に関わるエンジニア
• “設計の理想と現実的な進め方”の調和方法を模索している方

数理最適化は、物流ルートの最適化やシフトの最適化などに活用される、数学の応用分野の一つです。

世間では Python による実装が標準ですが、ここは、あえて Go 言語で解きながら、Step by step で解説します

https://qiita.com/ysaito8015@github/items/087e11b940d64731b816

キャリアの話は、働く人にとって最も重要な事柄の1つにも関わらず、あまり公には話されません。
一方、思い通りの仕事をしたり、希望するロールにたどり着けるのは一握りの人です。

思い通りのキャリアを歩むには社内政治や転職が必要なのでしょうか？
はたまた計画的偶発性理論？セルフブランディング？

継続的なアウトプットをしつつ、コミュニティの運営・裏方も担当し、採用担当もするKaitouが、着実に自分の思い描くキャリアに近づくための「アウトプット」についてお話いたします。

こんな方に聞いて欲しい！

• キャリアについて考えたことがない方
• キャリアについて迷っている方
• キャリアを上手く歩めていないと感じている方
• アウトプットに勇気が出ない方
• アプトプットをついついサボってしまう方
• 若手や部下にアウトプットしてもらいたいけれど、なかなかしてもらえなくて困っている方
• 面白おかしくキャリアップしたい方