こんにちは。SmartHRで基本機能（人事マスタ関連）を開発している hamada です。
この記事では、2026年2月20日に開催した第15回SmartHR LT大会の模様を、udzuraさん・tajimanさん・hotakaさん・namiokaさんと共にお届けします。
今回は、今年最初の開催にふさわしく、非常に盛り上がったLT大会になりました。
目次
- 目次
- SmartHR LT大会とは
- 参加者情報
- 発表レポート
- 1.【私家版】The インシデントレスポンス（udzura さん）
- 2. Redisとなかよくなりたい（shimo さん）
- 3. Dockerをドッカーン（osyoyu さん）
- 4. ５年前の自分に伝えたいスクリーンリーダーの基本（Joonas さん）
- 5. あっ、この問題、アクセシビリティ相談で見たやつだ！！（gamochan さん）
- 6. 負荷試験基盤（n9te9 さん）
- 7. 猫でもできるプロンプト改善（icchan さん）
- 8. Google ADKでDeep Researchを自作してみた（kubotaka さん）
- 9. 確率的データ構造という選択肢 〜正しさを捨てれば、世界は軽くなる〜（murakami さん）
- 10. SLOはこわくないよ（higuchi さん）
- 11. AI から没頭を取り戻す（yamo さん）
- 記念撮影
- 懇親会
- まとめ
- We Are Hiring!
SmartHR LT大会とは
SmartHR LT大会は、有志のプロダクトエンジニアがDevRelとともに隔月で企画・運営している社内イベントです。プロダクトエンジニアの中から11名の登壇者を募り、5分間のLightning Talks（LT）を行います。
プロダクトエンジニアの企画ですが、当日は職種によらず社員であれば聴講可能です。配信もしており、現地参加が難しい社員もリモートで楽しめるイベントとなっています。
参加者情報
今回の参加者数です。
- 現地参加者：71名（うち登壇者：11名）
- オンライン参加者：32名
- 懇親会参加者：56名
参加者数は昨年末の忘年会も兼ねたLT大会についでLT大会の歴史上2番目に多い会で、プロダクトエンジニア以外の参加者は過去最多となりました！
発表レポート
SmartHR LT 大会も今回で15回目！回を重ねるごとに内容の密度が増している本イベントですが、今回も個性豊かな11名の登壇者が揃いました。
インフラからアクセシビリティ、AIの活用、そしてエンジニアの「没頭」というエモーショナルなテーマまで、多岐にわたった発表内容をレポート形式でお届けします。
1.【私家版】The インシデントレスポンス（udzura さん）
1人目は udzura さんの「【私家版】The インシデントレスポンス」という発表でした。
前職でのインフラ運用経験をもとに、インシデント対応の極意が語られました。最も重要なのは「事実（ログ、メトリクス、コード）の収集」であり、特にGoogle Cloud Loggingの強力な分析機能やCSVエクスポートを活用して事実を深掘りする手法を紹介。また、平常時のメトリクスと比較する手法、問題を起こしそうなリクエストを特定するコツや、コードの変更履歴（Pull Request）等からバグを再現させるコツである「ミニマルペア」の紹介など、明日から使える実践的な知見が共有されました。
障害対応という重いトピックでありながら、すぐに役立つノウハウが盛りだくさんで、改めて内容を見返したくなる発表でした。
2. Redisとなかよくなりたい（shimo さん）
2人目は shimo さんの「Redisとなかよくなりたい」という発表でした。
以前のECサイト開発時代に直面したパフォーマンス改善の事例をベースに、Redisのデータ構造と計算量の重要性が解説されました。当初「キュー」として運用されていたものが実は計算量 のセット型（SMEMBERS）で実装されており、要素数の増加とともに遅延が発生していたとのこと。これを
で操作可能なリスト型へ移行し、さらにバッチ処理の分割やRailsの
touch: true オプションによる意図しない更新（アフターコミットの連鎖）の罠を特定・解消した経緯が語られました。
RedisだけでなくRailsの挙動も含めた深い洞察があり、可観測性の重要性を改めて認識させてくれる内容でした。
3. Dockerをドッカーン（osyoyu さん）
3人目は osyoyu さんの「Dockerをドッカーン」という発表でした。
RubyKaigiへのプロポーザル採択の報告から始まったこの発表では、「デプロイの速さ」への並々ならぬ情熱が語られました。osyoyuさんは、デプロイ時間が20分かかる現状に対し、理想の速度として「30秒」を提示。Dockerビルドやプルのオーバーヘッドを課題として挙げ、事前コンパイルが不要なRubyの利点を活かした高速デプロイの価値を強調しました。デプロイが速ければインシデントレスポンスも早まり、試行回数が増えてプロダクトの価値が向上するという熱いメッセージが届けられました。
osyoyu さんは入社直後だったのですが、入社直後とは思えない勢いのあるプレゼンで、高速デプロイがもたらす「かっこよさ」と「価値」に会場が沸きました。
4. ５年前の自分に伝えたいスクリーンリーダーの基本（Joonas さん）
4人目はアクセシビリティスペシャリスト Joonas さんの「５年前の自分に伝えたいスクリーンリーダーの基本」という発表でした。
アクセシビリティスペシャリストの視点から、スクリーンリーダーが単なる読み上げソフトではなく「パソコンを操作するためのツール」であることが解説されました。タブナビゲーションとは異なり、ほとんどのコンテンツにフォーカスを当てて役割を伝える仕組みや、見出し（Heading）を活用したスキップ機能の重要性を紹介。見た目は同じでも、適切なHTMLタグ（セマンティックHTML）を使っているかどうかで、スクリーンリーダーユーザーにとっての使い勝手が致命的に変わることを実例とともに示しました。
「基本を押さえるだけで致命的な課題を回避できる」という教えは、多くのフロントエンドエンジニアにとって目から鱗の学びとなりました。
5. あっ、この問題、アクセシビリティ相談で見たやつだ！！（gamochan さん）
5人目はアクセシビリティテスター gamochan さんの「あっ、この問題、アクセシビリティ相談で見たやつだ！！」という発表でした。
社内のSlackチャンネル「アクセシビリティ相談」の活用事例が紹介されました。ドラッグ＆ドロップ用ライブラリの選定基準や、デザインに応じた適切なマークアップ方法など、開発者が迷いやすいポイントに対して専門家が具体的に回答している様子を解説。相談を通じて開発コストが下がるだけでなく、チーム全体の「アクセシビリティ力」が高まり、最終的にはプロダクト品質の向上（ひいては総務省の選定など社会的な評価）に繋がるというメリットが語られました。
「迷ったらまずは相談」というカルチャーが浸透している様子が伝わり、積極的に活用したくなる発表でした。
6. 負荷試験基盤（n9te9 さん）
6人目は n9te9 さんの「負荷試験基盤」という発表でした。
年末調整などの大規模アクセスが予想されるイベントに向け、誰でも簡単に負荷試験を行える基盤を構築した背景が共有されました。自前でのインフラ構築の手間を省くため、k6、GKE、GitHubを活用したGitOpsベースの基盤を開発。インフラ構成をカプセル化することで、ユーザーはJavaScript（TypeScript）でシナリオを書くだけで実行でき、結果はPrometheusやGrafanaで確認できる仕組みを実現しました。
実際に多くのチームで使われ始めている実績もあり、負荷試験というハードルを大きく下げた素晴らしい取り組みでした。
7. 猫でもできるプロンプト改善（icchan さん）
7人目は icchan さんの「猫でもできるプロンプト改善」という発表でした。
AI（LLM）のシステムプロンプトを「なんとなく」ではなく、データを元に改善していく手法が提案されました。具体的には、生のデータ（質問・回答）を集めて人手で採点し、その評価傾向をAI（Gemini）に分析させて評価基準（ルーブリック）を言語化。その基準をもとに複数のプロンプト案を比較・評価するという3ステップを紹介しました。このプロセスを踏むことで、評価基準がチームの「暗黙知」から「形式知」へと変わり、積み上げ式の改善が可能になるとのこと。
すぐに試せる具体的なステップが満載で、AI活用を一段上のレベルに引き上げる有益な内容でした。
8. Google ADKでDeep Researchを自作してみた（kubotaka さん）
8人目は kubotaka さんの「Google ADKでDeep Researchを自作してみた」という発表でした。
最近話題の「Deep Research」（チャットボットが自律的に深掘り検索する機能）を、Google ADK（Agent Development Kit）を使って自作した事例です。1つの質問から検索を繰り返し、得られた結果からさらに新たな疑問を生み出して深掘りしていくエージェント構成を解説。複数の役割を持ったAI同士を議論させることで、回答の精度を高めつつ引用元（ソース）も明示する仕組みを構築しました。
「広さより深さ」を重視した設計思想が興味深く、社内ドキュメントの検索などへの応用にも期待が膨らむ内容でした。
9. 確率的データ構造という選択肢 〜正しさを捨てれば、世界は軽くなる〜（murakami さん）
9人目は murakami さんの「確率的データ構造という選択肢 〜正しさを捨てれば、世界は軽くなる〜」という発表でした。
「100%の正確さをわずかに犠牲にする代わりに、メモリ使用量を劇的に削減する」という確率的データ構造の魅力が語られました。要素の存在判定を行う「ブルームフィルター」と、ユニークユーザー数などを推定する「ハイパーログログ」の2つをピックアップ。ブルームフィルターが偽陽性を許容しつつネガティブキャッシュとして機能する仕組みや、ハイパーログログがデータの「レア度」から全体の数を推測するアルゴリズムを、モンスター図鑑の例えで分かりやすく解説しました。
複雑なアルゴリズムを直感的なイメージで説明したLTは非常に分かりやすく、設計の選択肢が広がる内容でした。
10. SLOはこわくないよ（higuchi さん）
10人目は higuchi さんの「SLOはこわくないよ」という発表でした。
SREユニットの視点から、SLO（サービスレベル目標）が単なる守りの数値ではなく「自信を持って開発を進めるための攻めの武器」であることが語られました。エラーや遅延を感覚で捉えるのではなく数値化することで、チーム内での意思決定がスムーズになり、リリースの判断根拠になるとのこと。導入をためらうチームに向けて、前提知識ゼロでも始められるワークショップやガイド、そしてSREによる伴走サポート体制が整っていることが紹介されました。
SLOの重要性と共に、SREチームの心強いサポート体制が伝わる、温かい発表でした。
11. AI から没頭を取り戻す（yamo さん）
最後、11人目は yamo さんの「AI から没頭を取り戻す」という発表でした。
AIによる自動生成が当たり前になった今、あえて「手でコーディングすること」の価値を再定義するポエム的かつ哲学的な発表でした。開発者がAIを使いこなすべきという罪悪感を感じる中で、あえて4〜5時間を確保して手作業でロジックを実装した際、深い「没頭」（フロー状態）と、それによるメンタルモデルの構築を実感したとのこと。AIは便利なツールですが、開発者の成長やパフォーマンス維持のために、あえて手を動かす価値は失われないというメッセージで締めくくられました。
AI時代におけるエンジニアの在り方を問いかける内容で、多くの参加者が自身の働き方を振り返るきっかけとなりました。
記念撮影
すべての発表が終わったあと、現地に集まった登壇者と参加者による記念撮影を行いました。
今回のLT大会も、技術的な深掘りからアクセシビリティ、エンジニアの心理まで、SmartHRらしい多様性に溢れた素晴らしい時間となりました。登壇者の皆さん、ありがとうございました！
懇親会
記念撮影の後に、懇親会を行いました！美味しい食事と飲み物を楽しみながら、職種や部署の垣根を超えて、様々な交流・情報交換を楽しみました！
まとめ
第15回SmartHR LT大会は、インフラからアクセシビリティ、AIの活用、そしてエンジニアの「没頭」というエモーショナルなテーマまで、多彩なテーマが揃った回となりました。 参加者もプロダクトエンジニアに閉じずに様々な職種の方が参加する機会となり、技術面・組織面・事業面のそれぞれにおいて、勢いと拡がりの加速を実感できるイベントとなりました。
次回の第 16 回は 2026 年 4 月 17 日に開催予定です！今後も SmartHR LT 大会を通じて、社員同士の知識共有と交流を促進していきたいと考えています。
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
撮影：tajiman
