ブレットボードで回路を組んだり、はんだ付けをしたり電子工作に慣れてくると基板を作りたくなりませんか？なりますよね。
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分）

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

厳しい現実のクラウドインフラに遭遇したことはありますか？ぼくはあります。

誰もわからない全貌、オフショアメンバーしか入り方を知らないサーバー、本番しかない環境、デプロイはもちろんぬくもりある手動、ユーザーからの問い合わせでわかる機能停止、・・・

とある急成長企業のSRE支援に入った自分は、この状況からの改善に取り組みました。
スタートダッシュで試用を数日で終わりと言わせ半月後には本契約を取り、未知のサーバーを見つけては構成図に落とし込み、通信を洗い出し、一方でガラ空きのポートを塞ぐなど、１つ１つカオスを潰す日々を過ごしました。

前任の会社が実現できなかった、本番環境からステージング環境を作ることも、不完全ながらある程度成功し、CI/CD整備やIaC化に着手できる地点まで数ヶ月というスピードで進めました。
が、そのくらいで突然告げられた「契約終了」。

こんなことある？

あれからまだ４ヶ月。もう４ヶ月。あれどうなったんだろうな？と思いたまーに様子を見ると、LP(Landing Page)はこれまで通りにあって、しかし10/31には終わることがわかっている。風の便りで。

このトークでは、この現場で自分が感じ・学び・向き合っていたさまざまなカオスと対応を、成長とともに呼び名を変える鰤になぞらえて物語的に語ってみたいと思います。
途中で終わりにせざるを得なくなった時に感じた諸行無常と共に。

概要
みなさん、エンジニアになったばかりの頃の気持ち、覚えていますか？
日々の開発に追われ、いつの間にか仕事の楽しさや「手触り感」を見失っていませんか？
このトークでは、安定した公務員という“養殖場”を飛び出し、エンジニアという大海原にやってきた僕が、エンジニアになって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

AI時代の今、あえて「ライブラリを使い倒す」経験は必要なのか？

キャッチコピー: バイブコーディングが教えてくれないこと 〜なぜ私はReact Hook Formに“育てられた”のか〜

ターゲット: AIコーディングに慣れ始めた若手・中堅エンジニア、技術選定を行うテックリード

概要:

（導入）昨今の開発はAIアシスタントの登場で劇的に変化した。「バイブコーディング」でそれなりの実装が瞬時に手に入る。

（過去）しかし、私（発表者）が学んだ時代は違った。特にフロントエンドは「正解」がなく、React Hook FormやFullCalendarのような複雑なライブラリを、文字通り「片っ端から試し」ながら使い倒す必要があった。

（対比）この「使い倒す」泥臭い経験は、単にライブラリの使い方を覚えるだけでなく、「なぜこのAPI設計なのか」「状態管理のどのパターンが最適か」といった実装の裏にある『Why』を深く理解するプロセスだった。

（問い）AIが最適なコードを提示してくれる今、この「苦しみながら使い倒す」経験は不要になったのか？ AIが提示するコードの「意味」を真に理解できているか？

（結論）「使い倒した」経験こそが、AIの出力を鵜呑みにせず、より良い設計を判断・選択できるエンジニアの「幹」となる。バイブコーディングの時代だからこそ、意識的に「使い倒す」経験が重要である。

みなさん好きなスポーツはありますか？
そのスポーツの放送をDXしたいと思ったことはありませんか？
デジタルのデータを使って、その情報を即時でTV画面にプロットできたら、さらに放送やスポーツ観戦が盛り上がると思いませんか？

JavaScript（＋Vue.js）とCanvas、Chromeを使って実際のTV放映で使われている字幕の自動生成について解説いたします。

今回は単なる表示だけではなく、サイクルロードレースの場合をベースに、どのように元のデータを引っ張ってくるのか？PCと放送機材のつなぎ込み方、実際に使用している機材の紹介まで、細かすぎて伝わらない粒度と、そのスポーツへの熱量でオーバーエンジニアリングした記録をお話いたします。

こんなお話をします。

• どんな画面構成？
• どんな機材を使うの？
• どんなJSを書いているの？
• 競技センサーからデータを取得する手法の歴史
• レースの残り距離を表示するための仕組み
• 選手の位置情報はどう取得する？

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

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

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

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

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

Baseline Tooling Hackathon に参加し、インストール不要で npx で実行出来る baseline-search というツールを作成しました。
Baseline とは何なのかにも触れつつ、私が作成したツールのご紹介と、ハッカソンに参加して得られた経験を共有出来ればと思います。

概要

近年、アクセシビリティの重要性が高まってきています。普段携わっているWebサービスやプロダクトでアクセシビリティのテストを自動で行うツールはいくつかあります。その中でもAxeはとても有名なツールの一つです。

本セッションでは、Axeのコアエンジンであるaxe-coreの中でアクセシビリティの自動テストがどのように行われているのかを、具体的なJavaScriptのコードを追いながら確認します。

アクセシビリティのテストは100%自動で検出できるものではありません。しかし、AIの登場によってできることも増えてきました。axe-coreの処理を一緒に探索した後に、自動テストでは何ができて何ができないのかについても考察します。アクセシビリティの理解を一緒に深めていきましょう！

こんな人に聴いてほしい

• アクセシビリティに興味がある方
• フロントエンドエンジニアの方
• HTMLで一度でもコーディングしたことがある方

RAGだけでは解決できないIoTサービスに関する問い合わせに対応するため、Bedrockのmulti-agentで“行動するAIサポート担当”をつくってみた話です。

IoTサービスの運用では「通信が切れた」「データが届かない」といった問い合わせが日常的に発生します。原因はデバイス設定／通信回線／クラウド構成など多岐にわたり、担当者はドキュメントを参照しつつAPIで現状を確認して総合的に判断します。本セッションでは、この“調べて→判断して→提案する”プロセスを支援するために、Amazon Bedrock上で動作するマルチエージェント構成を試作した知見を紹介します。

「通信が切れた」などのケースで、一般的な確認手順と実ステータスの両面から原因候補と対応を導く流れを解説します。エージェント間のコンテキスト共有、RAG結果とAPIレスポンスの整合、失敗時のハンドリングなど、設計と運用での工夫も共有します。

最終的には、自分が日常的に行っている問い合わせ対応をどこまでAIに任せられるかを評価しました。

Bunでバックエンドを構築する際、可観測性確保のためにDatadog APMを導入しました。
dd-trace ライブラリはBunを正式サポートしていませんが、工夫次第で本番環境での運用が可能です。

実際に導入を進める中で、スパンは取得できるものの、スパンが関連付けされず、トレースとしてまとまらない問題に直面しました。
Node.jsでは自動で行われるリクエストコンテキストの伝播が、BunとHonoの組み合わせでは効かないことが原因でした。

本セッションでは、この問題の「なぜ」を技術的に深掘りします。
Node.jsでの自動計装の内部メカニズム(モジュールパッチング、AsyncLocalStorageによるコンテキスト管理)を解説し、Bunとの違いがどう影響するかを分析します。
また、Bunでもdd-traceサポートの対応がなされていますが、何をカバーし、何が不足していたのかも明らかにした上で、解決策を紹介します。

対象者: BunやHonoに興味がある方、APM導入を検討している方、ランタイムの内部動作や自動計装の仕組みに関心がある方

エンジニアは技術的負債、レガシーコードの刷新、そしてリポジトリの統合といった、避けては通れない大規模なリファクタリング課題に直面します。

私はMOSHというクリエイター向けプラットフォームの開発において、8年近く運用されてきた（自らが積み上げた）負債「旧リポジトリ」の撲滅という大きな挑戦に直面しました。

膨大なコード量、複雑に絡み合った依存関係、そして不足したドキュメント。
従来の手法では数年かかると思われた作業を、AI（Claude + Cursor）とのペアプログラミングによって約100日で完遂しました。

この取り組みを通じて、「AIは単なる補助ツールではなく、最高のペアプログラミングパートナーであり、心の友である」という確信を得ました。

本セッションでは、AIの活用術ではなく、私がなぜ「旧リポジトリからもう逃げない」と決めたのか。

AIという存在がそれを可能にしてくれたわけですが、なぜその意思決定をすることができたのか。

10年近く前のコードに対する私の恐怖をどう変えたのか。

実コードと実データ、そして率直な失敗談を交えて語ります。

レガシーコードから目を背けてきたエンジニア、技術的負債の返済を諦めかけているチーム、そしてAIが開発組織の意思決定をどう変えるのか知りたいリーダーにとって、明日からの判断基準を変える内容を提供します。

エンジニアは新規技術の採用や組織課題など、さまざまな問題に直面します。

私は LINE API を利用した新規プロダクト開発や技術組織の拡大に伴う課題に直面した際、LINE Developers Community や EM Oasis といったコミュニティに参加することで活路を見出してきました。
そして、活動は課題解決に留まらず、現在は LINE API Expert としての初学者支援や EM Oasis の運営という形で、コミュニティへ貢献する活動へと繋がっています。

これらの経験は、「コミュニティがエンジニアの成長と課題解決に極めて有効である」という確信を与えてくれました。

本セッションでは、この実体験に基づき、以下の実践的なプロセスと技術を解説します。

• 課題発生から解決の糸口を見つけるまでのプロセス
• コミュニティ内で信頼を得て、より深い情報を得るための技術
• インプットをアウトプットに繋げ、自身の専門性を確立する方法

私がなぜ技術的な課題に直面した際にコミュニティに参加をするのか、私はなぜ課題が解決した今でもコミュニティ活動を続けているのか、LINE API Expert や EM Oasis 運営の活動を通して何を感じているのか、実体験を元にコミュニティ活動の素晴らしさを語りたいと考えています！

技術コミュニティへの参加を検討している方、また既に参加しているがより効果的に活用したい方にとって、具体的な行動指針となる内容を提供します。

YoY300%成長のクリエイター向けオールインワンプラットフォームの成長に伴い、複数プロダクトでの通知機能共通化が急務となりました。
メール・LINE・アプリ内通知を統一基盤として提供しつつ、将来の事業拡大を見据えた拡張性と、ミッションクリティカルな通知の確実な配信を両立する必要がありました。

本セッションでは最終的なインフラ・アーキテクチャ構成を共有したのち、その設計の過程でどのような制約や判断軸の中で候補として上がった技術について触れてなぜそれを採用しなかったのかという生々しい設計のリアル話をお伝えるすることが出来ます。
作成した成果物やその結果を伝えるセッションではなく、そこに至る技術的な判断や思考をみなさんに共有して今後の設計に役立つようなものにしたいと考えております！

主な内容

マルチプロダクト戦略での基盤設計思想

• なぜ通知を共通化したのか、将来を見据えた設計判断
• 今後様々なプロダクトが利用することを考慮した責務の分離とインターフェイスの設計についてどう考えたか

技術スタック選定

• StepFunctions vs SQS/SNS vs Fluent での可用性・柔軟性・一覧性との比較
• DynamoDB vs RDS vs Redis - 冪等性におけるデータストアの検討
• TypeScript統一による認知負荷軽減の判断

冪等性設計の技術判断

• DynamoDB条件付き書き込みによる排他制御の選択理由

聴講者が得られる価値

• マルチプロダクト環境での共通基盤設計における技術選定の判断基準
• 高可用性システムでの冪等性実装における具体的な技術選択肢と評価軸
• 将来の拡張性と現在の要件のバランスを取る設計判断の考え方

■概要
生成AIの台頭により、GitHub Copilot（GHCP）の企業活用が急増しています。Copilotをセキュアかつ組織統制下で活かすには、その基盤となる GitHub Enterprise Cloud（GHEC）の整備が実質的に必須です。
現場では「試用 → 本番」や「通常アカウント → EMU（Enterprise Managed Users）」への段階移行が増加中。本セッションでは、実案件およびコミュニティでの知見（※GitHub Stars受賞者としての最新動向も踏まえ）から、GEI / GitHub Migration Analyzer / gh-repo-stats等の実運用ノウハウを整理します。
“移せる／移せない”の線引き、ガバナンスを崩さないCopilot活用の判断軸、スモールスタートの実例まで、明日から使えるチェックリストとともに解説します。

■こんな人におすすめ
・企業内でGitHub導入・統合・再編をリードするDevOps／プラットフォーム担当
・既存GitHub資産を落とさず移行したい技術責任者・PM
・Copilot導入を見据え、まず基盤とガバナンスを整えたい方

■前提知識
・GitHub Enterpriseの基本概念（Org／Repo／Teams／Policies）の基礎理解（薄くでOK）
・IaCやCI/CDの一般知識があると理解が早い（なくても可）

■持ち帰れること
・「計画 → 解析 → 検証 → 本番」の実務フレーム＆チェックリスト
・GEI／Migration Analyzer／gh-repo-statsの使いどころと限界
・“移せないもの”の代表例と代替策（再作成・自動化・割り切りの判断）
・EMU移行時のセキュリティ／ガバナンス観点（ID、監査、ポリシー）の勘所

■発表者プロフィール（短）
外資系コンサルのDevOpsエンジニア／マネージャー。GitHub Stars。GitHub Enterprise／EMUの導入・統合・運用、Copilot展開、監査ログ連携やセキュリティ統制の実装支援に従事。