プロポーザル

福岡に在住していた学生時代のイベント参加で感銘を受け、以降は参加者としても運営としてもカンファレンスに関わってきた。

TSKaigiなど複数回カンファレンスで登壇し、自身の日々の具体的な技術の考察が、抽象化された学びとなった。また、本業の技術的な成果の可視化と社内外での認知向上に寄与したと実感している。

私はアウトプットの形式として登壇を好んでいる。その場で得られる反応を踏まえ説明を調整できる点や、懇親会でテーマの議論が継続する点に価値を感じている。AIが開発プロセスに組み込まれる時代でも、「整理して伝え、議論する」営みは技術理解を深め、仕事の成果にも繋がり得ると考えている。

本発表では、登壇の魅力と、プロポーザル作成に備えた技術の棚卸しの手法、そしてそれを聴衆へ効果的に持って帰ってもらうための登壇に特化したアウトプットの作り方について、過去登壇した具体例を元に紹介する。

登壇はブログなどのテキスト媒体とはまた別の魅力に溢れている。ブログなどの作成時に考慮が必要な、ワントピックへ絞る制約や、ストーリーテリングしながら詳細な実装説明まで行う難しさを回避することができる。
登壇の魅力は、15〜30分の枠であれば、聴衆に最後まで聞いてもらえる中で、課題発見から成果が出るところまでを、具体的なコードを見せながらでも伝えられる点にある。
日々の個別具体の技術的な議論や取り組みを抽象化し、学びに変えやすい。
最近だと、AIによるDevOpsの構築といったテーマは登壇形式と相性が良く、今こそ積極的に登壇する意義を示す。

登壇は、本業での成果の証明にも大きく寄与する。日々の成果を抽象的なパターンや技術的示唆へと棚下ろしをし、評価面談用のテキストに留めずプロポーザルとして提出・登壇・発表することで、現地のエンジニアからの反響を得て成果を明確化し、技術力の発露を証明しやすくする。

皆さん、システム障害はログとアラートで気づけるようにしていることと思います。
一方で、リリース後の予期しない不具合や連携サービス側のエラーにならない障害などの場合にはシステムで検知しきれず、CSチームから「こういう問合せが増えてるんですが調査をお願いできますか」といった形で"急"に知ることになる場面もあります。
CSチームから不具合を拾ってもらうこと自体には感謝しつつも、ソフトウェアエンジニアとしては非常に悔しい状況です。

昨今のAIの"急"速な発展に伴い、こういった状況も技術で改善できるようになってきました。
この発表では、単位時間あたりのユーザーからの問合せの傾向から不具合らしきものを自動検知する事例を話します。「不具合が出てしまった」、「システムで検知しきれなかった」、そういう状況でもいち早く我々エンジニアが察知できるように、ユーザーからの問合せも技術で監視していきましょう。

概要

約10年前、私はVBA製のアクションゲームでU-22プログラミング・コンテスト 2015で入賞しました。その後、電車の運転士という異色のキャリアを経て、現在はWebエンジニアとして働いています。
本セッションは、そんな私が10年前に書いた「僕が考えた最強のコード」と向き合い、さらにこのプロポーザル投稿からYAPC本番までに作り直して、当時の自分との比較を行います。また、複数言語でのリビルドに挑戦する予定です。

▼このトークでお見せするもの

• 【Before】10年前のVBAコードに見る、珠玉のアンチパターン集
  • 引数は一切使わない
  • 動作確認は手動テストがすべて
  • バージョン管理はファイル名
  • 脳内の記憶が全て。リファレンスは頼らない
  • etc …
• 【After】2ヶ月でリビルドしたゲームのアーキテクチャとデモ
  • 当時の自分に教えてあげたい、現代的な設計思想と開発プロセス
• 【比較】新旧ゲームから振り返る、この10年の環境と自身の変化
  • なぜ当時は、「あのコード」を最善と思いながら書いていたのか？
  • なぜ当時は、「あのコード」でコードを書き続けられたのか？
  • どうやって自分は変化してきたのか

Webエンジニアになり当時に比べスキルを積んだ自分が、コードを通じて過去の自分と対話し、得られた気づきや学びをみなさんに共有します。

Ruby用のバックグラウンドジョブ処理ライブラリ「shoryuken」。
このgemを、弊社では複数の機能で愛用していました。しかし、ある日突然アーカイブされていることに気づき、将来の開発に支障をきたす可能性が浮上しました。

「このgemを失うわけにはいかない！」そんな思いから、作者の連絡先を調べてLinkedInで直接連絡。交渉の結果、アーカイブを解除してもらうことに成功しました。
その後、新しいメンテナーとの協力体制を築き、現在はgemの刷新作業を進めています。

今回は、LinkedInでの交渉から現在進行形のメンテナンス作業まで、愛用gemを救うためにやったこと・学んだことを実体験ベースでお話しします。
また、shoryukenの事例を通じて見えてきた「アーカイブされた/メンテナンスが止まったOSSを救うために私たちができること」についても考察したいと思います。

Web サイトの JavaScript や CSS はブラウザから閲覧できます。従ってそれらに機密情報が入らないよう、細心の注意を払わなければなりません。なになに? 「minify してるから大丈夫。」「モダンなフレームワーク使ってるから大丈夫。」...だって? 本当にそうですか?

機密情報の漏洩を招くポイントは、様々な場所に潜んでいます。このトークでは、一般的なWebフロントエンド開発で意識すべき漏洩ポイント、そしてその対策についてお話します。

• Source Map 経由での漏洩
• Client Component 経由での漏洩
• Next.js Pages Router の _buildManifest.json
• その他注意すべき漏洩ポイント
• 漏洩の確認方法
• 漏洩を防ぐには

DNS Full ResolverはIDCやISPなど多くの環境で構築/運用されています。
Office NetworkやIDC内での利用ではあまり問題にはなりませんが、ISPやさらに大きいスケールでの運用では問題が発生する事があります。
このセッションでは、小規模から中規模でどのような運用パターンが実施されているのかを解説し、また、大規模な環境ではどのようにDNS Full Resolverをスケーリングさせているのかについてまず解説します。
その後、さらに巨大なPublic DNSのようなHyper-Scalerは巨大なDNS Full Resolverをどのように構築しているのかを、PublicなDocumentから分かる範囲で調査した内容を解説します。
また、Hyper-Scalerが実際に行って居るDNS Full Resolverをどのように実装するのかの簡単なPoCを実装し解説します。
DNSという長く開発、運用されているシステムを調査/開発する楽しさを共有します。

「ふりかえりって何？」という方や、「なんとなくKPTばかりでマンネリ化している…」という方に向けて、ふりかえりの基本と、現場ですぐに使える実践的な手法を紹介します。
「なぜ振り返るのか」「どのように進めるのか」「そこから何を得るのか」に焦点をあて、明日から実践できる具体的なヒントをお持ち帰りいただけます。

さらに、YAPC::Fukuoka 2025のテーマ「きゅう」にちなみ、以下の視点を織り込みます。

• 急：技術や環境が“急速”に変化する時代だからこそ、“すぐ実践できる小さな振り返り”の効果を解説します。
• Q： “Question＝問い” を出発点に、「なぜそれを行うのか？」を考えることで、振り返りの意義を深めます。
• 休：“休＝立ち止まり”を振り返りのタイミングとして意識し、忙しい日常の中でも意図的に立ち止まる場の重要性を考えます。

【セッションで扱う内容】

1. 「ふりかえりとは？」を整理し、その効果と意義を再確認
2. 実際にふりかえりを導入する際のステップを具体的に紹介
3. 「DPA」「Starfish」「象、死んだ魚、嘔吐」など様々なふりかえり手法の紹介
4. 私がチームで普段実践しているふりかえりを具体的な事例として共有

【このセッションがもたらす価値】

• "なんとなく"で実施していたふりかえりを見直す機会になる
• 効果的なふりかえりのための実践的なヒントや手順を持ち帰れる
• ふりかえり文化がないチームにとって、ふりかえりを始める際の指針となる
• 知らなかったふりかえり手法を知れる

ふりかえりは、地図にピンを打つように“現在地”を確かめ、歩んできた経路を整理し、未来への道筋を描くための営みです。
本セッションが、そのピンを打つきっかけとなれば幸いです！

35歳になる目前、私はそれまで当たり前のように身を置いていたプロダクト開発の現場から離れ、人事担当として急転身しました。
エンジニアにとって、近いようで遠い存在である人事。果たして、お互いのことをどれくらい理解しているのでしょうか？
エンジニアから見た人事、人事から見たエンジニア。両方を経験したからこそ分かる、お互いの誤解と理解。人事の日常業務のリアル、エンジニア組織への貢献の仕方、そして技術者と人事の間に橋を架ける意味について、転身してからの4年間の体験をもとにお話しします。

アウトライン

• 「コードを書かない」決断と「急」転身の理由
  • EMキャリアから「またコードを書く？」に対する違和感
  • 技術者アイデンティティ・クライシス
• 両方やったからこそ見えた世界
  • エンジニア時代に持っていた人事への誤解
    • 「人事って面接だけやってるんでしょ？」
    • 「技術のことなんて分からないでしょ？」
• 人事になって分かった人事の世界
  • 実際の日常業務とその深さ
  • 組織課題解決への真剣な取り組み
  • HR業界のプロフェッショナリズムとは
• 技術者出身だからできること
  • エンジニアとの信頼関係構築
  • 技術組織の課題理解と解決への貢献
  • 両方の言葉で話せることの価値
• 4年経った今の率直な感想と学び
  • コミュニティとの新しい関わり方
  • 「技術者 vs 人事」ではなく「技術者 & 人事」という視点
• 橋を架ける意味
  • 技術者のキャリアパスの多様性
  • 組織をより良くするための協働の可能性

聴衆が得られるアウトカム

• 人事という職種への理解
• キャリアチェンジの現実的な体験談
• 技術者と人事の協働の可能性

自分がマネジメントで体験した学びを残していきたいけれど、いざ書こうとすると「何を題材にすればいいかわからない」、「あらゆる方面に気も遣うし発信が難しい」といった感じで断念してしまうという人は多いのではないでしょうか。
そう、こういう話は"急"に改まって書こうとしてもなかなか書けないものです。私はマネジメントで感じたことや学んだことを小さく文章やスライドに残していくことが多く、どう題材を選定していつどのように書いているのかとよく聞かれます。慣れも必要ですが、わりと再現性がある部分もあります。

この発表では、日々のマネジメントの悩みや学びをいかに小出しに残していくか、その自分なりの"技術"をお伝えします。
以下のような内容を盛り込む予定です。

• キーワードをすぐにメモしておく
• 思考の吐き出しとまとめるタイミングを分ける
• 自分がうまくできていないことを書く
• 脳内リベンジマッチを繰り返す
• 雑に学びを残す書き方のパターン分け
• ツッコミや炎上が起きにくい発信の仕方

概要

オブザーバビリティ（可観測性）という言葉をよく聞くけど、どこから始めたらいいかよくわからない。このハンズオンはそんなあなたのために、オブザーバビリティのためのフレームワークである OpenTelemetry を用い、OpenTelemetry の主要なシグナルのうち「トレース」にフォーカスをし、Perl で作られた Web アプリケーションのエラーの解消、処理時間の改善、N+1問題の解消などをトレースを活用しながら体験していただきます。

OpenTelemetry は概念や仕様、API がベンダーニュートラルに定められているため、ここで学んだ知識は Perl 以外の言語やさまざまなオブザーバビリティバックエンドに応用できます。

得られるもの

• 分散トレーシングを使った Web アプリケーションの改善ができる
• OpenTelemetry を用いた Perl での計装の仕方がわかる　

アジェンダ

• イントロダクション
  • 分散トレーシングとは
  • OpenTelemetry とは
• トレースを用いて Perl アプリケーションを改善してみよう
  • Perl で計装する
  • 改善のシナリオ
    • エラーの解消
    • 処理時間の改善
    • N+1 問題の解消

必要なもの

• Git, Docker が動く環境
• お好きなエディター

マイクロサービス設計でこんな課題に直面していませんか？

「なぜ一方のサービスの変更が、全く関係ないはずの他のサービスまで影響するのか？」
「同じデータなのに、なぜ更新処理は500ms、参照処理は50msと10倍差が生まれるのか？」
「システム障害時、現在の状態は分かるのに、なぜその状態になったかが全く追跡できないのか？」

本セッションでは、これらの現実的な課題から出発して、DDD/CQRS/ESという3つの境界設計に辿り着く過程を探求します。

1. 責務の境界（DDD）
   なぜ変更が波及するのかドメインモデル散在が引き起こすサービス間結合を、境界付けられたコンテキストで解決する道筋

2. 処理の境界（CQRS）
   なぜ更新と参照で異なる仕組みが必要なのかトランザクション要件と参照要件の根本的違いから、コマンドとクエリ分離への発想転換

3. 因果の境界（Event Sourcing）
   なぜ結果だけでなく経緯も必要なのか状態変化をイベント記録することで開ける、システム振る舞い追跡と因果関係管理への扉

課題に直面したエンジニアがどのようにしてDDD/CQRS/ESという境界設計に辿り着くのか、その思考プロセスを追体験しましょう

例えば、ガワネイティブアプリを開発しているとき、セッションIDを返したのに次の起動時にはログアウトされている。なんていう経験があるかもしれません。
ちゃんとSet-Cookieヘッダを返しているのに、ネイティブアプリ側が保存してくれないのはどうしてでしょうか。
このトークでは、Set-Cookieのレスポンスを返した時に、モバイルアプリのWebViewがどのように振る舞うかを解説します。

サーバサイドのエンジニアの視点だと、モバイルアプリのWebViewは、挙動がわかりにくくデバッグが難しく感じられているのではないでしょうか。WebViewの性質について、できるだけ噛み砕いてお伝えしつつ、簡単なデバッグ方法にも触れたいと思います。

フロントエンドのエンジニアにとっても、モバイルアプリのWebViewが対応しているAPIが気になるところ。独自WebViewで対応した場合に、基本的なあのコードが動かない、なんていうことも。モバイルアプリ向けに実装するときに気を付けておきたいポイントも、合わせて盛り込みたいと思います。

妻が2人目の子を妊娠したことから、家族のサポートを増やしたい、そういう生き方をしたいと思って始めたフリーランス。
それまでの会社員という肩書きを捨て、武者修行の気持ちで始めたフリーランス。
そうこうしているうちに、2人の子どもたちは小学生へ。
自分もそろそろ、フリーランスは引き際かと、再び会社員へ。そしてUターン。

このトークは、家族を支えることを優先しながら生きてきた5年半の経験をもとにした、エンジニア人生の、1つのケーススタディです。

5年半にわたるフリーランス生活を通して、生き方を軸足に据えたキャリアも、選択可能だという気づきがありました。生まれてから今日まで培ってきた知識や人脈のおかげで生きのびた5年半。仕事を引き受けすぎたり、納期が重なってしまったり、体を壊したり、いろんなことがありました。

どうも世知辛い世の中ではありますが、自分の大切にしたい生き方が見つかったら、その生き方にあった働き方を模索・追求するというのも、エンジニアらしい生き方なのかもしれません。生き方に悩むエンジニアの助けになったら幸いです。

マイクロサービス設計でこんな課題に直面していませんか？
「なぜ一方のサービスの変更が、全く関係ないはずの他のサービスまで影響するのか？」サービスAの修正が、なぜか別のサービスBまで壊す。ドメインロジックが散在し、変更の影響範囲が予測できません。
「同じデータなのに、なぜ更新処理は500ms、参照処理は50msと10倍差が生まれるのか？」整合性重視の更新と速度重視の参照では、根本的に異なる最適化が必要です。
「システム障害時、現在の状態は分かるのに、なぜその状態になったかが全く追跡できないのか？」結果だけでは原因究明できず、同じ問題の再発を防げません。

本セッションでは、これらの課題を解決するために現場で「求められた」3つの境界設計を技術的に探求します。

1. 責務の境界（DDD）
   なぜ変更が波及するのかドメインモデル散在による意図しないサービス間結合を、境界付けられたコンテキストで解決する必然性を考察します
2. 処理の境界（CQRS）
   なぜ更新と参照で異なる仕組みが必要なのかトランザクション要件と参照要件の根本的違いを分析し、コマンドとクエリ分離による性能と整合性の両立を検討します。
3. 因果の境界（Event Sourcing）
   なぜ結果だけでなく経緯も必要なのか状態変化をイベント記録することで、システム振る舞いの追跡と分散システムでの因果関係管理を実現する価値を分析します。

なぜその技術が「求められる」のか、問題から出発してDDD/CQRS/ESの組み合わせが生み出す境界設計の必然性について、実装パターンとトレードオフを含めて考察します。

• 対象者
  • マイクロサービス設計に携わるエンジニア
  • アーキテクチャ選択の判断基準を模索する方

最近 Claude Code Actions の 1.0 がリリースされました。その時のロードマップには乗っておりましたが、結局まだ実現してない cross-repo support というものがあります。
繋がってる複数のレポジトリが存在している会社の環境上、どうしてもこれが欲しかったので実際やってみました。 Devin でいいじゃんと言われるかもですが、 Cluade Code Actions で自作してみたかったんです...

本セッションでは、 Claude Code Actions を社内の複数リポジトリをまたいで使い倒す環境を実際作り、その成功と失敗、そして得られた知見を共有します。
聞いて得られるものは以下のようなものを想定してます。

• 複数レポジトリを操作する Claude Code Actions の構成例
• ぼちぼち汎用 AI Agent を作る大変さ

【概要】
私は新卒1年目のWebエンジニアです。
大学院在学中は機械学習を専攻していましたが、Web開発はほぼ未経験の状態で入社しました。

いまや、AIはエンジニアに限らず当たり前に使われる時代だと感じています。
私が受けた新卒エンジニア研修でも、技術のキャッチアップや開発をAIに支えられながら進めていきました。
Web未経験からのスタートでしたが、限られた期間でキャッチアップできたのは、AIを活用したことが大きな要因だと感じます。

一方で、AIにすべてを任せてしまうと自分自身の成長を妨げる危うさもあると実感しました。
プロジェクト構成の判断やモジュールの切り分けなど、人間がやるべき仕事も存在すると感じます。
この発表では、研修や配属後の業務で、どのようにAIを活用したのか・何を感じたのか・どんな課題に直面したのかを新卒視点でお話しします。

【お話したいこと】

• 新卒エンジニアが実践している『AIを使ったキャッチアップ』
• 未経験から経験した『AI駆動開発』のリアルな感想
• 実際に使ってみて感じた『AIのメリットとデメリット』
• 新卒目線で考える『AIとの付き合い方』

AIを使ったことで得られた成功体験と、逆に失敗して学んだこと。
その両方を通じて見えてきた『AIとの現実的な関わり方』を、新卒エンジニアの目線から共有したいと思います！

Perl は「There's More Than One Way To Do It (TMTOWTDI)」を掲げ、同じ処理に複数の実現手段を許容してきました。この自由さはときに自らの足を撃ち抜くほどの危うさを伴いますが、同時に、強烈な表現力と柔軟性をもたらします。

このトークでは、Perl メタプログラミングの「黒魔術」と呼ばれるテクニック——プロトタイプ宣言やシンボルテーブル、AUTOLOAD、ソースフィルタ等——を紹介し、これらを用いた共通機能の抽出や DSL の構築といった実用的な利用例を見ていきます。

同時に、開発を急加速させるその便利さと表裏一体のリスクにも目を向けます。メタプログラミングを素朴に扱うと、急坂を転がり落ちるように読みづらさやテスト困難さを招きます。そこで、直感的に見えるメタプログラミング実装と、慎重に設計されたアプローチとを比較し、その違いを整理します。

メタプログラミングは忌避すべきトリック集ではありません。正しく扱うことで、日常で使う強力な武器となります。リスクを最小化しながらメタプログラミングと付き合うための考え方と具体的な指針を持ち帰ってください。

Cotomo というAIキャラクターと会話するサービスを開発しています。会話体験はいくつもの要素で成り立ちますが、その中でもユーザが強く感じるのが「声の表現品質」です。同じ「はい」でも言い方やテンションで印象は大きく変わり、これをどう検証し続けるかが課題でした。

最初はスプレッドシートに音声を貼り付けて管理していましたが、数が増えるほど評価やフィードバックが滞り、検証速度が落ちていきました。そこでサービスを支える検証やオペレーションの生産性を最大化するために、AI時代だからこそ自前で0からツールを作りました。このツールは単なる管理ではなく、利用者であるMLエンジニアやオペレータが自分でUIを変えたり試行錯誤できる仕組みを持ち、使いやすい形に育てていくことにも繋がりました。

本セッションでは、「AIを前提にした試行錯誤の仕組みづくり」について、現場で積み上げてきた工夫と学びを紹介します。
Vibe Codingだけではなく、Vive Codingでの生産性を高める為のアーキテクチャや仕組みなどをお話できればと思います

筆者は20年以上前の大学生の頃から「自分のサイト」というのを立ち上げて、雑記のような記事を書いていました。
当時はまだウェブログという言葉もない頃で、ざっくりいうとWeb日記といった感じでサイトを更新していました。

その時々の興味により、テクノロジーの話、旅行の話、ゲームの話、近況の話などいろいろなことを書いてきて、
(多分に黒歴史のようなものも含まれますが)今も20年以上前の記事が読めるようにデータを保持しています。

StrictなHTML4.01 / XHTML 1.0やCSS2をメモ帳でちまちま手打ちすることからはじめたサイト作りも、
月日の流れと自分の技術力の向上によりC++でCGIをかいてHTMLを生成するようにしたり、
Perlの会社に入社してPSGIアプリケーションとして書き直したり、その後Goの流れが来たので
Goで書き直したり…とサイトを生成するプログラムをその時の技術的興味に合わせて書き換えてきました。

記事のデータ自体も最初は生のHTMLのフラグメントを書く方式で18年くらい書いていて、さすがに
今時生のHTMLはないだろう、ということで2020年くらいにマークダウンで書けるように改修しました。
それでも、旧記事はデータに手を入れず生HTMLのままにしていました。

今般、そんな趣味全開で維持してきたサイトをまた久々に書き直そうと思い立ち、
GoのHugoというツールで静的生成する方向に舵を切りました。

今回の発表では、そんな20年以上続くサイトのマイグレーション作業として、旧記事を生HTMLから
マークダウンに変換したり、メタデータを生成したり、その他いろいろ雑多な移行作業をコーディングエージェントとともに
サクサク進めて1週間弱で終わらせたときに得られた、「コードをゴリゴリ書かせる以外のコーディングエージェントの使い方」を話します。

普段から業務でPerlのWebアプリケーションを開発・運用している方であっても「cpanfileに ::XS とついたモジュールがいくつか並んでいるところまではわかっているが、難解そうで、実装を追ったりするのはなんとなく避けてしまっている」というような方は少なくないのではないでしょうか (かくいう私もそのような時期がありました……)。

そんなXS、Perlにおけるネイティブ拡張のための仕組みは、

• データベースクライアントなど既存のCライブラリへのラッパー
  • （libmysqlclientに対応するDBD::mysqlや、ImageMagickに対応するPerlMagickなど）
• ネイティブコードによる最適化がウリのライブラリ
  • （JSON::XS、Type::Tiny::XS、……）

など、Webアプリケーション開発において必須とも言えるモジュール群で使われている技術です。一方で、とっつきにくく思われている節があり、なかなか手ほどきを受ける機会もないように思います。

本セッションでは、普段Perlを読み書きしているがXSにはあまり触れたことがない方を主な対象に、XSモジュールに対する心理的なハードルを下げ、リファレンスなどを参照しながら既存のライブラリなどの実装を理解したり、トラブルシューティングができるようになることを目指します。また、Perlに馴染みがない方にとっても、スクリプト言語におけるネイティブ拡張の仕組みのケーススタディとして楽しんでいただければと思います。

トーク内容

• CPANモジュールを取り巻くツールチェインのおさらい
• XS "急"速入門
  • 「XS言語」の基本的な文法・構造から、外部ライブラリの呼び出しなど
• XSモジュール探訪
  • 実際のXSモジュールのコード読解