概要

タイトルを見て「本当ですか？」と思われるかもしれません。事実、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 でこんなに簡単にキーボードが作れるのか、という体験をお届けします。

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

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

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

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

こんなことある？

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

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

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

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

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

テーマ

例外とResult型の解説、エラーハンドリング設計

想定する参加者層

例外処理やエラーハンドリングについて関心がある初級〜中級の開発者

トーク概要

例外処理は、単なるコード上の仕組みではなく “失敗とどう向き合うか” を決める設計上の意思決定です。
エラー対応が「起きた後の対処」だけに偏ると、再発と手戻りは減りません。

Result型は、失敗の可能性を型で表し、例外に頼らずエラーを設計する手法です。
これにより、エラーの種類や処理責任が明確になり、設計の一貫性を保ちながら保守性を高められます。

本セッションでは、例外（try-catch）を用いる言語のプロジェクトにResult型を取り入れる設計方法を紹介します。
実務での知見を踏まえ、例外の扱いをより明確にし、エラー処理を改善するためのヒントと指針をお持ち帰りください！

概要

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が、着実に自分の思い描くキャリアに近づくための「アウトプット」についてお話いたします。

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

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

テーマ

ドメインイベント導入と責務分離の実践

想定する参加者層

保守・機能追加で副作用や依存の整理に悩む初級〜中級の開発者

トーク概要

ドメインイベント、使っていますか？
これは、注文完了やユーザー登録などビジネス上の“出来事”を表すモデルです。
状態変化を出来事として切り出すことで、副作用が見える場所にまとまり、設計の見通しが良くなります。

本セッションでは、既存コードに潜むイベントの見つけ方から始めて、責務分離から非同期処理への段階的なリファクタリング手順を紹介します。
小さな一歩から始められる実践に絞るので、無理なく取り入れられます。
ぜひ「あ、こう設計すればいいのか」という発見を持ち帰ってください！

近年のWindows OSに実装されているデバッグ機能について解説します。デバッグは、ソフトウェア開発者がプログラムの複愛を特定したり、動作を確認したりするための一般的な動的解析技術であり、その特性から近年ではサイバーセキュリティでの問題分析や攻撃検知にも活用されています。Windows OSでの動的デバッグに用いられるソフトウェアとしてはWinDbgが広く知られていますが、Windows OS自体にもプログラムの動的解析を支える複数の機能が実装されています。本講演では、Windows OS自体に実装されている動的解析を支援する機能の中から、いくつかの機能に焦点を当てて、デモンストレーションを交えて解説します。

「暗号化って難しそう...」そんな方でも大丈夫！GoでECC（楕円曲線暗号）を簡単に実装してみましょう。
RSAより軽くて速いECCを、Goの標準ライブラリでサクッと実装。
鍵を作って、署名して、検証する。

たったこれだけで暗号化の世界に足を踏み入れられます。

• テーマ：Go言語によるECC（楕円曲線暗号）の実装と理解
• 想定層：Goでの実装経験がある初級〜中級者。暗号理論の知識は不要。
• 狙い：ECCを難解な理論でなく、コード実行を通じて直感的に理解してもらう。

PHPのコミッターをしています。
主にUnicode周り(intl、grapheme関数)、レガシー文字エンコーディング周り(mbstring)のメンテナンスを行っています。

最近、PHPでgrapheme関数という、Unicodeで言う拡張書記素クラスター（以下、書記素クラスター）に対応した関数を作成しています。
RubyでString.grapheme_clustersの性質を持ったgrapheme_str_split関数、
書記素クラスター単位で2文字列間のレーベンシュタイン距離を測るgrapheme_levenshtein関数などを作ってきました。

JavaScriptでIntl.Segmenterのようなものもアイデアとしてありますが、
他言語での書記素クラスターの対応はどうなっているのでしょうというのを伺いたいと思い、本プロポーザルに応募いたします。

想定する参加者としましては、Unicodeで文字が読み書きできるのであればどなたでもよく、
またPHPを使っている方でも、そうでない方でも歓迎します。
ただし、レーベンシュタイン距離と言ったように、少し技術的に難しかったり、Unicodeについてマニアックな内容も含まれているかと思われます。

2024 年の re:Invent で発表され、2025 年 5 月に GA（一般提供開始）となった Aurora DSQL。Google Spanner 対抗（？）のサーバーレス分散 SQL データベースとして注目を集めた割に、（2025 年 10 月中旬時点では）具体的な採用事例の話はほとんど聞きません。その一方で「従来の Aurora PostgreSQL から移行する形で採用しようとして失敗した」というネガティブな話は聞こえてきたりします。

（たぶんそれ、目的・用途に合わせたデータベース選定になっていなかったんじゃないかと…？）

私自身は、これまで「ゲームで体感！Aurora DSQL の OCC」（JAWS ミート 2025）や「攻略！Aurora DSQL の OCC」（JAWS FESTA 2025 in 金沢）などのセッションを通じて、Aurora DSQL のキモである OCC（楽観的同時実行制御）の特性を紹介・説明してきましたが、参加者の反応などから、やはり具体的なアプリケーションの実装例が示されないと理解が難しい印象を受けました。

というわけで、今回は架空の予約サイト（例：宿泊予約）の実装に Aurora DSQL を使い、

• 対象（例：人数・日程・プラン）の選択（仮確定）を先着順に処理する【⭐︎1】
• 対象選択後、必要事項（例：氏名・連絡先など）の入力および決済完了まで一時確保する【⭐︎2】
• 必要事項入力・決済完了後に予約を成立させる
• 一時確保の状態のまま一定時間経過したら予約不成立として在庫に戻す

という一連の流れを、NG 実装例と比較しながら説明していきます。

【⭐︎1】 Aurora DSQL では OCC の特性上、同一キーを持つ行を挿入または更新する処理の実行（成功）が「必ずしもトランザクションの開始順・コミット順にならない」という問題があります。
　→参考 : https://www.docswell.com/s/hmatsu47/ZJQYXX-aurora-occ-jaws-festa-20251011#p36

【⭐︎2】 Aurora DSQL には一般的な RDBMS が持つ行ロックの機構がないので、DBMS レベルでのロックを使わず、かつ一時確保した側が優先されるよう排他制御する必要があります。

■想定する参加者

• データベースが好きな方
• データベースは好きじゃないけれど、アプリケーション開発でデータベース周りの処理の実装から逃れられない方
• Aurora DSQL が気になる方
• 業務案件で Aurora DSQL を扱わないといけなくなりそうな方

一見難しそうですが、実際にはあまり高度な技術は使わない想定です。

（実装言語やフレームワーク・ORM（利用有無を含め）などは検討中です）

■注

• こちら↓の記事で扱っている内容とは全く別物・別趣旨です（ちなみにこの記事の著者の方とは知り合いです）
  • https://blog.serverworks.co.jp/_dsql-reservation

レビュー文化を根づかせることは、多くの組織が抱える永遠の課題です。
しかも、そのチームがエンジニアだけでなく、多職種で構成されているとしたらどうでしょうか。成果物も、SQL や Goole Apps Script のコード、Salesforce の設定、業務ドキュメントなど多岐にわたる。
この環境でレビューを機能させるには、「文化」ではなく「構造」と「スキルの定義」が必要でした。
本セッションでは、チームがゼロからレビュー文化を設計・実装し、非エンジニアを含む多様な職能のメンバーとともに運用可能にしたプロセスを紹介します。
話の中心はコードレビューの技術論ではなく、「レビューを通じて組織がどう変わるか」という組織デザインの話です。

「レビューは品質担保のため」では足りなかった

わたしたちのチームでは、日々のアウトプットが事業運営の中枢を支えています。品質を守ることは単なる「きちんとした設計・コード」を超えて、事業そのものの信頼を守る行為でした。
わたしたちはまず、レビューを「品質の最終防衛線」ではなく、「リスクと知識の共有装置」として位置づけ直しました。
つまりレビューとは、属人化を防ぎ、チームの継続性と透明性を保つための仕組みです。
レビューを “誰かが見る” ではなく、“チームで引き受ける” 行為へと再定義した瞬間、ようやく文化づくりのスタートラインに立てました。

レビューを仕組みに落とし込む

レビュー文化は「がんばってやろう」では定着しません。人によって判断が揺れ、レビューの粒度や責任の範囲がばらつくからです。
そのためわたしたちはまず、「どの成果物をどの粒度で、誰がレビューすべきか」を体系化しました。
レビューの種類は、実施可否、方針、成果物、実行の4段階。
単にコードを読むだけでなく、「そもそもこの業務をやるべきか」「どう設計するか」「どのように実行するか」までレビューを拡張しました。その上で、職能ごとにレビュー観点を明文化しています。
エンジニアは品質と再現性、マネージャーは優先度と工数、事業責任者はリスクと価値のバランス。法務・会計・税務といった専門家はそれぞれの観点でレビューに関与します。
こうした役割の整理によって、「誰がどの段階で判断するか」が明確になり、結果として、属人化のリスクが減少しました。

多様な職能を束ねるための「スキルと期待値の見える化」

しかし、レビューの仕組みが整っただけでは十分ではありません。
チームの中には、エンジニアバックグラウンドを持つ人もいれば、業務設計や分析が得意なメンバー、ドキュメンテーションを中心に支えるメンバーもいる。
職能もバックグラウンドも違う彼らが「レビューにどう関わるべきか」を共有する必要がありました。
そこで導入したのが、スキルレベルと組織の Value をかけ合わせたマッピングです。それぞれの Value ごとに、個人がどのステップにいるのかを可視化できます。

これにより、「どのスキルが不足しているか」「次にどの段階を目指すべきか」を、レビューの中で対話できるようになり、レビューは単なる承認の場ではなく、成長と育成の場へと変わっていくのです。

文化を根づかせる「レビューの設計思想」

レビューを日常の一部にするために、意識した設計思想が三つあります。

一つ目は、レビューの優先度を高く置くこと。
自分のタスクよりもレビューを優先する。
レビュー時間を毎日スケジュールに組み込み、チーム全体でレビューを止めないルールを明確にしました。
レビューはスピードを遅らせるものではなく、スピードを維持するための基盤です。

二つ目は、レビューを「会話」ではなく「仕組み」に落とすこと。
Design Doc のテンプレート、チケットの項目設計、リスクレベルの自動分類など、誰がやっても同じ流れになるよう設計します。
これにより、メンバーの習熟度に左右されず、レビューが安定的に回るようになりました。

三つ目は、レビューを個人の責任からチームの責任に変えること。
「誰がミスしたか」ではなく、「どの段階でリスクを拾えたか」を見る。
レビューの失敗を咎めるのではなく、次の改善サイクルに活かす。
こうして、レビューは「チェック」から「共創」に変わっていきます。

セッションで伝えたいこと

このセッションでは、チームが実際に取り組んだ「レビュー文化の仕組み化」と「スキルの可視化」の設計思想を、実例を交えて紹介します。

• 多職種混在チームでレビューを成立させるための設計と運用のリアル
• レビューを成長・育成の仕組みに変えるスキル階層の考え方

これまでの経験の蓄積から見えた、文化のつくり方を共有したいと思います。

想定する参加者層

• レビュー文化を強化したいエンジニア、EM、SRE、テックリード
• BizOps や事業チームと協働するエンジニア・マネージャー
• 属人化や品質リスクに悩むプロジェクトリーダー

「本当にメモリ管理は難しすぎてわからなぁぁぁい‼︎」と思っているみなさん！
メモリ管理への理解を深めるために、その発展の歴史を学んでみませんか？

たった一つのメモリ確保処理を見直しただけでCPU使用率を57%、メモリ使用量を99%も削減できた例があるほど、メモリ管理の知識はアプリケーションのパフォーマンス向上に直結します。
しかしメモリ管理に関する教材の多くは、ガベージコレクションの具体的なアルゴリズムやコンパイラ内部のメモリ構造といった複雑な機能が「どのように(How)」動作するのかに焦点を当てており、初学者向けとは言えません。
本来「How」を理解するためには、「なぜ(Why)」その機能が必要とされ、「何を(What)」実現するかの理解が不可欠です。
そうした土台がないまま「How」の議論を追うのは困難でしょう。

ヒープ、スタック、ガベージコレクションのような仕組みは、プログラミング言語におけるデータ管理をわかりやすくするために進化してきたものです。
動機を知ることでこれらの仕組みをより深く理解し、メモリ管理を語れるエンジニアになりましょう！
本セッションでは、特にGo言語のメモリ管理機能を取り上げてその進化の軌跡を紐解きつつ、発展的なメモリ管理の知識を修得するにあたって強固な土台となる知識を提供します。

[対象者]

• メモリ管理という言葉すら知らない方
• メモリ管理について学びたいが、理解に苦しんでいる方

[話すこと]
以下のメモリ管理機能がなぜ必要とされ、何を実現するかについて、それぞれの相関関係を強調しながら話します。

• ヒープ・スタックのメモリ構造
• GC (ガベージコレクション)
• ヒープエスケープ・エスケープ解析 (Go特有)
• スタックコピーによる可変サイズスタック (Go特有)
• メモリ管理の知識がプロダクション環境のパフォーマンスに大きな影響を与えた例とその解説

[話さないこと]
メモリ管理機能の詳細な処理ロジックや実装

[アウトライン]

1. はじめに (5分)
   • 自己紹介
   • メモリ管理はパフォーマンス向上のため非常に重要
     • たった1か所のメモリ確保処理の見直しで、CPU使用率が57%、メモリ使用量が99%も削減された事例が存在
   • メモリ管理に関するセッションは難しい
     • 実装の詳細やロジック (How) に関する技術的な内容が多い
     • 処理の抽象的な解釈や、必要性に対する理解 (What, Why) が不足している
   • Goの高度なメモリ管理を学ぶには、幅広い機能の基礎知識が必要
     • 各機能が「何を」して「なぜ」あるのかを理解することで初めて習得できる
     • 「How」の前に「What」と「Why」に焦点を当てるのが、修得の最短ルート
2. メモリとは何か / 古のメモリ管理 (2分)
   • メモリ＝プロセスの一時的なデータ保存領域
   • メモリへの直接的なデータ挿入 (アセンブリのデータ管理)
3. 変数の誕生 / スタックとヒープ (5分)
   • 【課題】人間が全てのメモリアドレスを把握する必要がある
   • 高級プログラミング言語の登場
     • 変数＝データの抽象化
     • 人間はアドレスを気にしなくてよくなるが、言語側が代わりにアドレスを管理する必要がある
   • スタックの発明
     • 関数呼び出しのネスト構造や変数スコープをメモリ空間上でうまく表現できる
   • スタックの図解説明
     • 【例】Goでの変数定義や関数呼び出し
   • 直接的な挿入も可能にする、ヒープとポインタ
     • 大きいデータ・サイズ不定のデータ
     • 関数をまたいで利用されるデータ
     • 【例】C言語のmalloc / free
4. ヒープの自動管理 / ガベージコレクション (2分)
   • 【課題】ヒープ上の使い終わったデータは人間が削除する必要がある
     • メモリリークやOOM Killのリスクが高まる
   • ガベージコレクション (GC)
     • ヒープ上の未使用データを検出
     • 未使用データを自動的に削除
5. Goのヒープエスケープ (6分)
   • 【課題】ヒープに大量のデータを置くとGCの負荷が高くなる
     • 【例】構造体や配列をすべてヒープに置く→半分以上の変数がGC対象に
   • ヒープエスケープの導入
     • できるだけスタックにデータを置く
     • 型で判断するのではなく、必要なものだけヒープへ「逃がす」
   • エスケープ解析
     • ヒープへ逃すか決まるのは、実行時ではなくビルドの段階
     • どの変数がエスケープするか見るためのビルドオプションがある
   • ゼロアロケーションライブラリ
     • 関数内でヒープに置かれるデータを一切出さないパッケージ
     • 非常に効率的で、基本的にパフォーマンスが向上する
     • 実装はやや複雑で、コードリーディングが難しい
6. スタックコピーによる、可変サイズスタック (4分)
   • 【課題】通常の言語ではスタックには上限が設けられ、スタックオーバーフローが起きる
   • あらかじめ大きなスタックを確保しておくか…？
   • 【課題】常に大きなスタックを持つと、ヒープが小さくなって不便
   • 可変サイズのスタックにより、効率的なメモリ利用を実現
     • セグメント化スタック (旧実装)
     • スタックコピー (現行の実装)
7. はじめに紹介した事例の解説 (4分)
   • 参考: https://developers.cyberagent.co.jp/blog/archives/54653/
   • フィルタリング関数が呼び出されるたびにヒープ上にスライスを1つ作成
     • このヒープに置かれた変数がボトルネックになっていた
   • 既存のスライスを利用することで割り当てを無くし、メモリ使用量99%削減
     • たった1つのアロケーションがパフォーマンスに大きく影響することを示している
   • CPU使用率57%削減
     • アロケーションとGCコストの削減の合計
8. まとめ (2分)
   • 今回のセッションはあくまで出発点
   • 他のセッションや資料で、各機能を深堀りしてみよう！
9. 次に見るべきおすすめの過去セッション紹介 (時間が余ったら)
   • このセッションで得た基礎知識を土台に、次のステップに進もう！
   • ヒープエスケープとエスケープ解析: "Escape Analysis in Go: Understanding and Optimizing Memory Allocation" - Go Conference 2023 Online
   • GCの条件: "Go1.19から始めるGCのチューニング方法" - Go Conference 2023 Online
   • pprofを使ったパフォーマンスチューニング: "Memory Management in Go: The good, the bad and the ugly" - GopherCon UK 2023
   • 【発展】ヒープ・スタックの、OSレベルでの割り当て: "Goのメモリ管理" - Go Conference 2023 Online
   • 並行処理に対するメモリ設計 (memory model): "よくわかるThe Go Memory Model - 行間を図解で埋め尽くす" - Go Conference 2023 Online

概要

ソフトウェア設計を学び始めたとき、設計原則として「責務を分けよう」「疎結合にしよう」と言われても、実際にどのような設計・実装をすればよいのか、具体的なイメージが湧きづらいと感じたことはありませんか？本セッションは、マインスイーパという身近なゲームを題材に、具体的な設計とコードを通じて、これらの設計原則への解像度を高める体験を提供します。

マインスイーパには、セルやその状態、ボード（座標平面）、プレイヤー操作、難易度など様々な概念が存在し、設計を思考しながら学ぶ題材として適切なゲームであると考えています。セルの開封のように単純なロジックに見えても、「セルは状態を持つのか？」「セルは座標平面に依存するのか？」「セルからその近傍のセルを隠蔽するべきなのか？」など考慮点が多く、設計次第でコードの拡張性や可読性が大きく変わります。

本セッションでは、そんなマインスイーパをRubyによる純粋なオブジェクト指向で設計していきたいと思います。主な設計トピックは下記の通りです。

• 責務の境界線を定義し、情報隠蔽をする
• 具体よりも抽象的なインターフェースへ依存して、疎結合にする
• シンプルなインターフェースで強力な機能を提供する”深い”モジュールを目指す

これから設計を学びたい初学者や、日々の業務で「なんとなく設計している」中級者に向けて、責務と疎結合への解像度を高め、もう一歩深く設計を理解するヒントを持ち帰れるセッションを目指します。

詳細

対象とするターゲット

• 初学者
  • AIに設計を任せ切ってしまっている方
  • 設計の指針を持てていない方
  • 設計の技術書籍を読んで学んだが、あまりピンと来ていない方
• 中級者
  • 設計の技術書籍を読んで学んだが、より実践的に学びたい方
  • Ruby on Railsなどのフレームワークに従っての設計はできるが、そのレールからはみ出た設計に自信のない方
  • GoFのデザインパターンなどを学んだが、暗記になってしまいその本質が掴めていない方

トーク構成

• マインスイーパとは(3min)
  • ルール
• ER図の全体像(2min)
  • クラス図
• セル(3-4min)
  • 責務の境界線を定義し、情報隠蔽をする
    • 座標平面に依存する？
    • 状態を露出させる？
• セルの近傍(4min)
  • 具体よりも抽象的なインターフェースへ依存して、疎結合にする
• グリッド(3min)
  • 二次元配列を隠蔽する
• グリッドのファクトリ(3min)
  • シンプルなインターフェースで強力な機能を提供する”深い”モジュールを目指す
    • 複雑なロジックは隠蔽し、シンプルなインターフェースでグリッドを作成するインターフェース
    • シンプルファクトリパターン
• マインスイーパークラス(3min)
  • 多数のモジュールを利用するメインモジュール
• テスト容易性(3min)

このトークの意義

昨今のAI時代において、私は初学者がAIに取って代わられないために重要なのは「設計」であると考えています。 しかし同時に、初学者がその設計力を育む経験を得づらい環境に置かれていることを危惧しています。

インターフェースを定める「設計」と、その実体である「実装」を比較したとき、事業へのインパクトがより大きいのは明らかに「設計」です。実装は情報が適切に隠蔽され、副作用がなければ容易に差し替え可能ですが、設計は他のモジュールにも波及し、システム全体の構造を左右します。

しかし近年、AIネイティブ世代の初学者が、この重要な「設計」までもAIに全面的に委ねてしまう傾向があると感じています。答えが定まらない中でも試行錯誤し、概念を言語化しながら思考を深める、そうした経験を経ずに、AIに舵を預けてしまっているのです。

私はその原因を、初学者が「設計のポイント」や「思考の取っかかり」を持たないことにあると考えています。

本トークは、そうした初学者の方々に対し、設計を自ら考え始めるための“思考の種”を提供するものです。設計入門の資料は数多くありますが、本トークでは具体的な事例と思考プロセスの両面から、より実践的に「設計」を掘り下げます。

【テーマ】
・ Amazon Simple Email Service（以下「Amazon SES」）でのメール受信についての話

【想定する参加者層】
・ Amazon Web Service（AWS）を扱っている方（主に業務で）
・ Amazon SESを扱った経験、およびAmazon SESでのメール受信の経験は不問です。（経験がない方でも十分理解できる内容となっています）

【トーク概要】
AWSでメールを扱う際にAmazon Simple Email Service（以下「Amazon SES」）を使用することが多いと思います。
「メール送信は経験があるが、受信についてはなかなか扱うことが少ない」という方もいるかもしれませんが、2023年に東京リージョンでもAmazon SESがメール受信に対応したことで、これからAmazon SESでのメール受信に対応するケースも増えてくると思います。

そして受信メールはAmazon SNS/AWS Lambda/Amazon S3で扱えるのですが、これらサービスごとの仕様・制約が大きく異なっており、ビジネスアプリなどで受信メールを扱うのはなかなか一筋縄ではいかないのも事実です。

そこでこのセッションでは、実際に私がAmazon SESでのメール受信をビジネスアプリに組み込んだ経験から
・ Amazon SESでのメールの受信方法
・ Amazon SNS/AWS Lambda/Amazon S3それぞれで受信メールを扱う際の注意点
・どういうケースでどの手法を選択するのが良いのか

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

【セッションゴール】
・ Amazon SESについて、「受信メールの受信方法」および「受信メールを扱うサービスごとの仕様・制約」を理解できるようになる
・ ビジネスアプリにAmazon SESでのメール受信を組み込む際に「どういう点に気を付けた上で、どういうケースでどの手法を選択するのかが良いか」がある程度理解できるようになる

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