Timee Product Team Blog

タイミー開発者ブログ

NLP 2025の参加記録

はじめに

こんにちは、株式会社タイミーでデータサイエンティストとして働いている貝出です。直近はカスタマーサポートの業務改善に向けたLLM活用のPoCやシステム開発を行っております。

さて、今回は2025年3月10日(月)~3月14日(金)に開催された「言語処理学会第31回年次大会(NLP2025)」に昨年に続き参加してきましたので、その参加レポートを執筆させていただきます。

言語処理学会年次大会について

www.anlp.jp

言語処理学会年次大会は言語処理学会が主催する学術会議であり、国内における言語処理の研究成果発表の場として、また国際的な研究交流の場としての国内最大規模のイベントとなっています。

今年で第31回を迎え、オープニングで共有されたスライドによると、発表件数は777件、事前・直前参加登録者数は2248人と過去最大となっており、年々大会が盛り上がっていることが伺えました。昨今のLLMの盛り上がりを反映し、発表内容はLLMに関連するものが大多数を占めており、業務でLLMを活用している身としては、大変学びの多い会となりました。

言語処理学会第31回年次大会に参加できなかった方でも、こちらから発表論文が閲覧できます。

興味深かった発表

初日のチュートリアルから最終日のワークショップまで興味深い発表がたくさんありました。その中から、個人的に気になった発表をいくつかピックアップします。

[T1] チュートリアル1: 言語モデルの内部機序:解析と解釈

概要

本チュートリアルでは、大規模言語モデル(LLM)の内部機序を解析・解釈するための方法論が紹介されました。モデルの入出力のみではその振る舞いを十分に理解できないため、内部の表現や計算過程を詳細に検討する必要があります。LLMの複雑さと高次元性が主要な課題であるため、抽象化と単純化による解析に加え、内部表現や計算を言語、世界、知識と結びつける解釈が重要であると述べられました。

内部表現の解析・解釈の手法としては、まず特徴量に基づくアプローチ(ニューロン分析、プローブ、疎なオートエンコーダーなど)が紹介され、さらにベクトルに基づいたアプローチ(表現の分布観察、ベクトル代数、木構造、階層構造、円形構造、グラフ構造の分析)についても解説されました。また、内部表現が持つ情報とその情報が実際にモデルの予測に利用されているかどうかを検証するため、因果的介入の手法(Activation Patchingなど)の重要性も示されました。

計算過程の解析・解釈に関しては、注意パターンの観察(構文情報や意味情報との関連、長文脈への対応、ゴミ箱機能など)、語彙空間への射影(重みパラメータや中間表現と語彙の関連付け、フィードフォワードネットによる知識記憶の分析)、出力への影響度の測定(数学的分解や介入による評価)、さらには特徴的なサブネットワーク(回路)の同定(コピー機能や事実知識の予測を実現する回路の発見)といった多角的な手法が取り上げられました。

さらに、言語や世界の構造がどのようにモデルに転写されるのかという根源的な問いにも議論が及び、「プラトン的表現」仮説や「集合的予測符号化」仮説が紹介されました。これにより、モデルの内部表現が世界の構造を捉えることによる予測の汎化への貢献や、言語学的仮説の検証の可能性が示唆されました。

最後に、内部機序の解析と解釈というアプローチ自体の限界についても言及され、概念の局所性や内部表現と対応物の一対一対応という暗黙の仮定への懐疑、「表現と計算」という視点そのものの妥当性への疑問が議論されていました。

発表資料はこちらのスライドに公開されているので、詳しい内容についてはこちらをご参照ください。

speakerdeck.com

感想

発表資料は全144ページと非常にボリューミーな内容でしたが、その魅力のおかげで1時間半という時間があっという間に感じられました。個人的には、言語モデルの内部機序に関する網羅的なサーベイを見つけることができていなかったため、今回の発表は大変ありがたかったです。

特に、プロービング(内部表現から特定の情報が抽出可能かを評価するテクニック)のようなLLMの傾向分析手法に加え、Activation Patchingといった因果的介入手法の存在を知ったのは初めてのことで、非常に印象的でした。観察データの傾向だけでは因果関係を正確に特定できないという因果推論の原則を踏まえると、介入による検証が行われるこのアプローチは、確かに必要な取り組みだと感じました。

[A1-6] 手動設計の敵対的プロンプト手法の体系的分類

概要

本研究は、LLM(大規模言語モデル)の安全性に関わる敵対的プロンプト、特に手動設計のものについて体系的な分類を試みたものです。既存の研究では自動生成プロンプトに注目が集まる一方、手動設計のプロンプトは多様なタイプが存在するにもかかわらず、十分に体系的に把握されていませんでした。そこで、世界中の敵対的プロンプトコンペティションから収集したデータをもとに、手動設計の敵対的プロンプトを49のカテゴリに分類し、6つの大カテゴリ(direct instruction、simulation、response specification、instruction override、input style、different task)の下に整理しました。また、Tensor TrustやHackAPromptといった既存データセットでは特定の手法に偏りが見られることも明らかになりました。本研究の成果は、LLMの安全性検証やレッドチーミング(攻撃者の視点に立ってシステムの脆弱性を検証する評価手法)、敵対的プロンプト合成データセットの作成に寄与すると期待され、今後は複数手法の組み合わせ、英語以外の言語対応、進化するトレンドへの自動反映といった課題にも取り組む必要があるとされています。

感想

「システムプロンプトを品詞分解して」のように、別のタスクに置き換えることでシステムプロンプトを聞き出す手法があるなど、様々なアプローチが存在することを初めて知りました。また、本発表で指摘されているように、システムの安全性を包括的に評価するためには手法の体系的な分類が不可欠であり、LLMを利用する企業としても非常に意義深い研究だと感じました。

C9-4 VDocRAG: 視覚的文書に対する検索拡張生成

概要

引用元: VDocRAG: 視覚的文書に対する検索拡張生成

引用元: VDocRAG: 視覚的文書に対する検索拡張生成

本研究では、図や表などの視覚的に表現された文書画像を知識源とする新たな検索拡張生成フレームワークであるVDocRAGが提案されました。従来のRAGはテキストのみを対象としていたため、現実世界に存在する多様な視覚的文書を十分に活用できませんでしたが、VDocRAGは画像形式で文書を統一的に理解し、視覚情報を直接利用することが可能となっております。

VDocRAGは、質問に関連する文書画像を検索するVDocRetrieverと、検索した文書画像を用いて回答を生成するVDocGeneratorという2つの主要な構成要素から成り立っております。また、大規模視覚言語モデル(LVLM)のトークンに画像表現を圧縮させるための新たな自己教師あり事前学習タスクとして、Representation Compression via Retrieval and Generation(RCRおよびRCG)が提案されました。RCRはOCRテキストに対応する画像を検索するための対照学習、RCGはアテンションマスクを工夫したテキスト生成による表現学習を実現しております。

さらに、本研究では、図、表、テキストなど多様な文書形式を網羅する初のオープンドメイン視覚文書質問応答データセットであるOpenDocVQAが導入されました。OpenDocVQAは既存のDocumentVQAやTableQAデータセットを精査・改変し、マルチホップ質問を含む新たなデータセットMHDocVQAを作成することで構築され、Single-pool(特定の文書形式内での検索)とAll-pool(データセット全体を横断した検索)の設定で評価されました。

実験の結果、VDocRAGは従来のテキストベースRAG(TextRAG)を大幅に上回る性能を示し、特に視覚データの理解において優れていることが確認されました。また、事前学習タスクであるRCRとRCGが性能向上に大きく寄与していること、さらに正解文書が付与された場合にはより高い性能が得られる一方で、検索性能の改善と検索ノイズへの頑健性が今後の課題として示唆されました。

こちらの内容は arXiv 上でも公開されています。

arxiv.org

感想

当日の発表にて、提案されたモデルでは図表などの視覚情報をOCRを介さずにテキストを抽出できる仕組みにより、テキスト主体の画像に対する精度が低くなる傾向が示されていました。 検索で使用する[EOS]トークンの隠れ状態に画像表現を圧縮されているそうだったので、ある程度テキスト情報が多いと情報が入り切らないなどの事象が発生しているかもしれないと想像しました。しかし、OCRを用いないエンドツーエンドの構成は大幅に処理時間の効率化にも寄与するとのことでしたので、今後の発展と、より多様な画像への対応に期待したいです。

おわりに

NLP2025では、多くの魅力的な研究が発表され、数々の刺激的なアイデアに圧倒されました。今回の報告ではご紹介しきれなかったものの、LLMの安全性検証や評価、ベンチマーク構築に向けた多様な取り組みも進められており、タイミーを安心・安全なプラットフォームとして維持するためのLLM活用法について、重要な示唆を得ることができました。

現在、タイミーでは、データサイエンスやエンジニアリングの分野で、共に成長し、革新を推し進めてくれる新たなチームメンバーを積極的に探しています!

product-recruit.timee.co.jp

また、気軽な雰囲気でのカジュアル面談も随時行っておりますので、ぜひお気軽にエントリーしてください。↓

hrmos.co

hrmos.co

Rubyを3.4.2+YJITにアップデートしました

こんにちは、Timee でバックエンドエンジニアとして働いている id:ryopeko です。 今回は Timee で使っている API サーバーの Ruby を最新の 3.4.2 (+YJIT) にアップデートしたことについての記事をお届けします。

1. 概要

今回の記事では、Ruby 3.3.6 から 3.4.2 へのバージョンアップについて、パフォーマンスへの影響、Devin を使った実作業、rubocop.yml の対応など、具体的な取り組みをご紹介します。安定性を重視した今回のアップデートの背景や、今後の展望についても触れていきます。

2. バージョンアップによるパフォーマンスへの影響

今回の Ruby 3.4.2 へのアップデートでは、YJITについては以前のバージョンから引き続き有効であるものの、我々のアプリケーションでは目立った変化はありませんでした。

計測方法とアプリについて

計測には日々活用している Datadog を使用しました。アップデートしたアプリケーションは、スマホアプリ、Web フロントエンドから使われる API で、サービスのメイントラフィックを担う部分です。また、ActiveAdmin によって作られた内部向け管理機能群も含まれています。

Datadog を用いて、CPU 使用率、メモリ使用量と使用率、リクエスト処理時間の各指標を計測しました。計測期間や時間帯などの計測条件についても確認を行いました。

計測結果

各指標の推移を比較した結果、バージョンアップ前後で大きな変動は見られず、安定した状態を維持していることを確認しました。時間帯ごとの変動パターンについても、目立った変化は見られませんでした。

メモリ使用量についても、大きな増加や減少は見られず、メモリリークなどの兆候も見られませんでした。リクエスト処理時間も、バージョンアップ前後で大きな変化は見られませんでした。

今回のアップデートで私たちは、パフォーマンスの維持と最新のバージョンを使い続けることを主な目的としていたため、これらの結果は想定内であり、安定性を重視したアップデートとして成功したと言えます。YJIT の効果は、我々のアプリケーションの特性上からか、これらの指標に顕著には現れなかったようです。

3. Devin を使った実作業について

また、今回のバージョンアップでは AI Agent ツールの Devin を活用しました。

Devin を利用した背景

Devin を利用した背景として、事前に作業の概要が把握できていたこと、動作確認に必要な Unit test が大量に存在していたこと、RuboCop のルールが整備されており、常にパスする状態が維持されていたこと、そしてアップデートの情報収集が AI の得意な分野であると考えたことが挙げられます。

Devin を利用した作業内容

Devin を利用した作業内容は以下です。

  • Pull Request の作成
  • 現在のバージョン間の主な差分情報の収集とサマリー生成
  • Ruby アップデートに必要な差分生成
  • Unit test の実施と確認
  • RuboCop の実施と必要な変更のサマリー生成(修正内容の提案、提案とは違う内容の修正の指示を含む)
  • アップデート可能な bundled gem のアップデート指示と対象の調査方法などが挙げられます。

プロンプトで指示したこと

Devin にはプロンプトで以下の指示をしました。

  • commit する前に作成する予定の差分と Pull request 用のサマリーを人間が確認すること
  • Unit test の実施
  • RuboCop の実施
  • アップデート可能な bundled gem のアップデート指示と対象の調査
  • 必要な rubocop.yml の修正指示と具体的な修正内容の指示
  • Pull request の作成

うまくいったこと

Devin を利用してうまくいったこととしては、情報の収集とサマリー生成、修正とテスト等のインクリメンタルな実施と確認が挙げられます。

うまくいかなかったこと

Devin を利用してうまくいかなかったこととしては、Ruby のアップデートと同時に実施した bundled gem のアップデートが挙げられます。これについて Devin は初め、bundle update で全ての gem をアップデートすることで対処していたため、具体的な指示を出す必要がありました。また、bundled gem に関する情報収集がうまく処理できなかったため、具体的な調査方法を指示する必要がありました。

Devin は情報収集や単純作業の自動化において、高いパフォーマンスを発揮しました。一方で、複雑な依存関係の解析や、具体的な指示がない場合のタスク実行には、改善の余地があると感じました。プロンプトの工夫や、Devin の得意分野と人間の得意分野を組み合わせることで、より効率的な開発が可能になるでしょう。

今後は、プロンプトのテンプレート化や、具体的な指示方法の研究、Devin の得意分野と人間の得意分野を組み合わせた効率的な開発フローの確立、Devin のバージョンアップや新たな AI ツールの導入による効率化を検討していきます。

4. rubocop.yml の対応

Ruby 3.4.x で有効になった以下のスタイルルールを、Enabled: false に設定しました。

  • Naming/BlockForwarding
  • Style/ArgumentsForwarding

これらのルールは既存のコードと競合するため、一時的に無効化しました。将来的には、これらのルールに準拠するようにコードを修正し、rubocop.yml の設定を見直すことを検討しています。

まとめ

今回の Ruby 3.4.2 へのアップデートでは、安定性を重視し、パフォーマンスの維持を主な目的としました。Datadog を用いたパフォーマンス計測では、CPU 使用率、メモリ使用量、リクエスト処理時間などの主要な指標において、バージョンアップ前後で大きな変化は見られず、安定した状態を維持していることを確認しました。

また、開発効率化のため、AI ツールである Devin を活用し、Pull Request の作成、差分情報の収集、テストの実施など、様々な作業を Devin に任せることで、開発者の負担を軽減し、効率的な開発を実現しました。

今回のバージョンアップを通して、安定性と効率性を両立させるための具体的な取り組みをご紹介しました。今後も技術の変化に柔軟に対応し、より良い開発環境を構築していきたいと考えています。

Women in Agile Tokyo 2025に参加してきました!

こんにちは、shihorinとmahoです。

先日、Women in Agile Tokyo 2025というカンファレンスに参加してきました!

参加した感想や気づきを対談形式でお届けします。

登場人物の紹介

  • shihorin
    • 2024年5月タイミーにジョインして専任スクラムマスターになりました。
  • maho
    • HRから社内転職でスクラムマスターになりました。スクラムマスター歴2年目に突入。

参加して思ったこと

shihorin: mahoさん、Women in Agileお疲れ様でした!参加してみてどうでしたか?私は、RSGTでWomen in Agileの運営に携わっている方々の座談会を聞いて興味を持ったのが参加のきっかけだったんです。

maho: shihorinさんもお疲れ様でした!私は、去年メンターの方から勧めてもらいつつ参加できなかったので、今年は行ってみようというのがきっかけでした。もともと多様性に関心が強いほうではあったんですけど、最近は「多様性=女性」と括られることに違和感があって…。

shihorin: わかります。「Women」というワードがついているので、女性限定のカンファレンスなのかな、と最初は勘違いしていました。

maho: そうそう。多様性への違和感については「多様性を活かすチームの作り方」というセッションを聴いて、腑に落ちたことがあるんです。

shihorin: どんなことですか?

maho: 目に見える違い(visible differences)だけじゃなく、性格や経験、価値観など目に見えない違い(invisible differences)も多様性に含まれるというお話があって。特にIT業界は女性が少ないという特徴もあって、多様性を考えるときに、自分の中でも目に見える違い、特にジェンダーが先行しすぎていたな、と。

shihorin: なるほど。

maho: 違和感の正体は、invisible differencesを考慮せずに、visible differencesが必要以上に強調された枠組みの中に入れられる(女性〇〇みたいな)ところにあったのかもしれないと思います。

shihorin: 確かに。visible differencesのほうが、多様性と聞いたときに先に想起されやすそうだし、invisible differencesは考慮から抜けがちなのかもしれない。

maho: もちろんどちらのdifferencesも大事ではありますが、visible differencesだけを多様性のように捉えると表面的なアプローチになりがちで、歪みが生じやすい気がしますね。あと、セッションでは本質的に多様性のあるチームや組織は成果を出しやすいという研究結果も紹介されていました。多様性のあるチームは、事実をより重視し、より慎重に処理し、より革新的であるというのです。

shihorin: へー!

maho: つまり、対話ができ、お互いに異なる意見を尊重できる環境においては、ユニークなアイデアが生まれやすいのだと思います。スクラムマスターとしては、チームや組織においてそういった場作りをしていくことが重要であると改めて認識しました。

shihorin: Women in Agile 自体は、参加してみて安心感がありましたね。「あらゆる多様性を尊重できる安全で健全な職場作りを自分たちの手で作るため」に開催されているだけあって、お互いを尊重し合おうというマインドが会場全体に溢れているなと感じました。

maho: 確かに。Women in Agile って、良い意味で意図的に敷居を低くして、誰に対してもウェルカムな雰囲気があると思いました。

shihorin: うんうん。個人的には、RSGT や他のイベントで知り合った人たちが増えてきて、知らない人に囲まれている感覚が薄かったのも安心感につながっていました。

maho: 知り合いがいると心強いですよね。

shihorin: そうなんですよね。それに、これまで自分が参加した Agile 関連のイベントと比較して、女性の参加比率がとても高かったので、自分に近そうな属性の人のほうが話しかけやすい・話しかけられたときの緊張感が少ないと体感しました。一方で、それって多様性を否定しているんじゃないか?ともどかしい気持ちもありました。

maho: 属性が似ていると居心地が良い反面、気をつけないと排他的になってしまうこともありますね。でも、そうやって色々考えること自体が、多様性を受け入れるうえで大切なプロセスなのかも。

shihorin: そうですね。Women in Agile に参加して、改めて多様性について深く考えることができました。

印象に残ったセッション

maho: 今回のカンファレンスで、特に印象に残ったセッションは「アジャイルのない地域でアジャイルを根付かせる〜三島物語〜」でした。

shihorin: ああ、あのセッションですね!

maho: このセッションでは、他者を巻き込んで文化を生み出していった実体験についてのお話がありましたよね。

shihorin: まさに体当たりでアジャイルを広めていくお話、面白かったです。

maho: 自分が良いと思っているものをそのまま伝えても、なかなか相手に伝わらない。他者を巻き込んで文化を生み出していく、良いと思ってもらうだけでなく実際に行動に移してもらう。これはとても難しいことですが、相手の文化に寄り添い、その世界観に合った伝え方をすることが、興味関心を持ってもらうための第一歩だと感じました。

shihorin: 押し付けではなく、相手に寄り添うことが大事ですね。

maho: そうなんです。とても基本的なことではあるんですけど。あとは、何かアクションを起こすときには一緒に楽しむ気持ちも、文化を根付かせていくうえでは無視できない要素な気がします。

shihorin: 私は「Art of Hostingから学ぶ 〜askとofferで現れる自分自身も尊重される運営〜」が印象に残りました。このセッションを聞いて、Art of Hostingという概念を初めて知りました。

maho: 私もです。

shihorin: 自分の心の内側が整っていないと、話し合いの中に不要な複雑さ・煩雑さを持ち込んでしまう、あることないこと言ってしまう、という話に共感しました。

maho: 焦って余計なことを言ってしまうことはよくある気がします。

shihorin: そうなんです。対話の中で本当はモヤモヤしているのに言葉に落とし込めなくて、モヤモヤを飲み込んだまま相手の話に同意してしまう、といった経験はたまにありますね。「まず自分自身をホストしよう」という話の中で、自分の気持ちに気づく、大切にするというワードが出てきましたが、具体的にどういうことなのかもっと詳しく聞いてみたいと思いました。

shihorin: Closing Keynote も印象的でしたね。

maho: WAKE Career を運営している bgrass 株式会社の代表、だむはさんの話、良かったですよね。

shihorin: 地道に一歩ずつ模索しながら、時には失敗も経験しながらリーダーになっていった話を聞いて、共感できました。若くして起業したカリスマ、自分とは遠い存在のスーパーマンみたいなイメージを勝手に持っていたので、自分が共感できたことに驚きました。

maho: だむはさんが乗り越えてきた壁についてのエピソードを聞いてみたら、すごく人間味があって、親近感が湧きました。今までのマッチョなリーダー像に必ずしも寄せていく必要性はない。それに代わる新しいリーダー像をそれぞれが作っていってもいいのではないかという視点には、とても考えさせられるものがありました。

shihorin: そうですよね。誰かが言っている・作ったリーダー像が絶対的な正というわけではなく、自分なりのリーダー像を目指したいと私も思いました。

maho: 私も同じ気持ちです!

shihorin: もう一つ良いなと思ったポイントがあります。ジェンダーギャップを解消したい、という軸が最初から一貫してぶれていなかったことに加えて、自分の中だけでなく周囲に伝わっていたことです。やっぱり熱量を持って伝えることって大事ですね。

maho: Closing Keynoteのお話からも熱量の高さを感じました。

shihorin: 頑張っている人をみて自分も頑張ろうって思えるのが、カンファレンスにいく一つの目的だなと特に思いました。今までも「カンファレンスに参加すると登壇者や他の参加者から熱量を受け取れるよ」といった話を周囲から聞いてきましたが、徐々にわかり始めた気がしました。

OSTに参加した感想

maho: OST はどうでした?

shihorin: 1回目は「対話の練習場」がテーマのテーブルに参加しました。「Art of Hostingから学ぶ 〜askとofferで現れる自分自身も尊重される運営〜」で登壇されたガオリュウさんがこのテーマを挙げられていて、対話の練習をしたいなと純粋に考えたためです。

maho: 私も同じテーマに参加しました!

対話や関係性について持論を話した際に、自分が思っていた以上に共感や、気づきにつながりましたというリアクションをもらえたのが嬉しかったです。

shihorin: 反応があると嬉しいですよね。

maho: また、この OST が終わった後にも、常に向き合っているからこそ言語化できているとお話いただいて、自分の意見や考えに対して色々なフィードバックがあるという機会が、これまでの私にとっては多くなかったので、とても刺激になりました。

shihorin: OST が終わった後もフィードバックがあったんですね!

maho: shihorinさんはどうでした?

shihorin: 私は「誰かの経験談を聞くのって結局n=1の話だし、直接的に参考にはならないんじゃないか」と今まで悩んでいましたが、経験談を抽象化することで「あるあるだよね」「自分も昔似たような経験をした」というように共通点が見つかって、n=2、n=3……になっていく。その中から、自分の仕事に活かせる気づきやヒントを得られそうだと今回の OST で感じました。抽象化って大事なんだなという気持ちになりました。

最後に

maho: 今回のカンファレンスに参加して、誰かの話から新しい発見を求める純粋なゲスト感覚でいるだけではなく、自分の経験や考えを発信してフィードバックをもらい、またあわよくば少しでもコミュニティにインスピレーションを与えられるようチャレンジをしていくフェーズに移っていくべきかもと思えたのは良かったです。

shihorin: いいですね! 確かに、今まで誰かの話を聞いて「勉強になったな」で終わることが多かったかもしれない。

maho: そうなんですよね。せっかく貴重な経験をしてきたのに、それを発信しないのはもったいないなと思って。

shihorin: 自分の経験や考えを発信することで、誰かの役に立つかもしれないし、コミュニティ全体の活性化にもつながりますもんね。

maho: だから、これからはもっと積極的に発信していきたいと思っています。

shihorin: 私も自分の経験や考えの発信にチャレンジしてみたいです。まずは OST の参加テーマ選びのときに「このテーマなら自分の経験や考えが他の参加者の役に立ちそう」という観点を持ってみようと思いました。

maho: 良さそう! ぜひ、試してみてください。

shihorin: 今までは「このテーマ私も相談したい、私も悩んでいる」という観点でテーマを選んでいたので、発信するという観点がありませんでした。

maho: どうしても自分の悩みを相談したいって気持ちが優先されがちですよね。

shihorin: ですね。これからは発信する側にもなってみたいです。

DatadogのAWSメトリクス収集をCloudWatch GetMetric APIからMetric Streamsに移行してMTTDを短縮した話

はじめに

こんにちは! タイミーでPlatform Engineerをしている @MoneyForest です。

今回は、弊社のDatadogにおけるAWSメトリクス収集を、従来のCloudWatch GetMetric APIからCloudWatch Metric Streams方式に移行することで高速化した取り組みについて紹介します。

背景

タイミーのワーカー様向けアプリケーションは、ピーク時に1分あたり十数万リクエストを処理するような規模で運用されています。そのため、システムの異常を素早く検知し、対応することが求められます。

主にシステムの異常検知は、メトリクス、ログ、APMをソースとしてエラーレートやレイテンシーの異常を判断し、DatadogのモニタリングアラートでSlackに通知することにより行われます。

DatadogによるAWSメトリクス収集の仕組み

Datadogでは、AWSのメトリクスを収集する方式として2つの方法があります。

  1. CloudWatch GetMetric API方式
    • CloudWatchのAPIを定期的にポーリングしてメトリクスを収集
    • メトリクスの遅延が15-20分程度発生する可能性がある
      • CloudWatch側の遅延(5-10分)
      • Datadogのポーリング間隔(10分)
      • APIレート制限による追加遅延(最大5分)
  2. CloudWatch Metric Streams方式
    • ストリーミングしたメトリクスをAmazon Data Firehoseを介してDatadogに送信
    • aws.s3.bucket_size_bytesaws.billing.estimated_chargesのような2時間以上遅れてレポートされるメトリクスは取れないので、GetMetric APIも設定する必要がある
    • 2-3分程度の遅延

それぞれの方式をポンチ絵で書くと以下のようになります。

GetMetric APIはまとめて取ってくるPull型、Metric Streamsは継続的に送信するPush型というイメージです。

タイミーではGetMetric API方式のみでAWSメトリクスの連携を行っていましたが、最悪のケースでは20分近い遅延が発生する可能性があり、問題の検知が大幅に遅れる可能性がありました(実績ベースではALBのメトリクスなどが10-12分程度遅延している状態でした)。

タイミーのトラフィック規模では、メトリクス送信の遅延が大きすぎるとして、CloudWatch Metric Streams方式の検討を始めました。

CloudWatch Metric Streams方式への移行

検証環境を活用しながら実装、コスト、切り替えの流れを検討し、移行を進めました。

実装面の考慮

タイミーではIaCとしてTerraformを採用しています。

一方で、CloudWatch Metric Streams方式を実装する手段として、AWSのIntegration画面からCloudFormationテンプレートが提供されています。

CloudFormationテンプレートの内容を全てTerraformに書き換えるのはコストが高いため、aws_cloudformation_stack リソースでCloudFormationスタックのApplyを行うことにしました。

# Datadog CloudWatch Metics Streams の設定
# CloudFormationのテンプレートがDatadog側で提供されているため、そのまま利用する
resource "aws_cloudformation_stack" "datadog" {
  name         = "datadog"
  template_url = "https://datadog-cloudformation-stream-template.s3.amazonaws.com/aws/streams_main.yaml"

  # テンプレート内部で名前指定をしたIAM Roleを作成するのでオプション指定が必要
  capabilities = ["CAPABILITY_NAMED_IAM"]

  parameters = {
    ApiKey = data.aws_ssm_parameter.datadog_api_key.value
    Regions = join(",", [
      "us-east-1",
      data.aws_region.current.name
    ])
  }

  lifecycle {
    ignore_changes = [
      parameters["ApiKey"], # ApiKeyの変更を無視
    ]
  }
}

コスト面の考慮

CloudWatch Metric Streamsの料金体系は、AWSのPricingページのExample 21に以下のように書かれています。

アプリケーションが 30 日間休まず毎日 24 時間稼働し、毎分 10,000 メトリクスを更新し、CloudWatch メトリクスストリームが、米国東部の Kinesis Data Firehose 配信ストリームを経由してパートナーの HTTP エンドポイントにデータを送信する場合、月額料金は次のようになります。

CloudWatch Metric Streams
メトリクス更新の合計数 = 10,000 メトリクス更新/分 x 43,200 分/月 = 432,000,000 メトリクス更新/月
432,000,000 メトリクス更新 (1,000 メトリクス更新あたり 0.003 USD) = 1,296 USD/月
CloudWatch の月額料金 =1,296 USD/月

許容できないほど高くなることはなさそうなため、検証環境に数日反映して実績ベースで確認することにしました。

結果として、日次で$20ほどかかっていたCW:GMD-Metrics がなくなり、代わりに$50ほどCW:MetricStreamUsage にかかるようになりました。

タイミーでは本番環境より検証環境の方がAWSリソースが多いため、このコスト増を最大値と見込み、許容範囲と判断しました。

切り替え時の考慮

切り替えに関しては、CloudWatch Metric Streamsを有効化することによるメトリクスの変化を検証環境で確認しました。

結果として以下2点の問題が明らかになり、それぞれ対応を行いました。

  1. CloudFormationスタックの適応中(8分程度)はダッシュボードで一部のメトリクスが重複して計上されてしまっている
    • Datadogのドキュメントには以下の記載があり、特別なケアは必要ないものの、キレイに切り替わるわけではなさそうなことがわかりました。
      • API ポーリングメソッドを通じて特定の CloudWatch ネームスペースのメトリクスを既に受け取っている場合、Datadog は自動的にこれを検出し、ストリーミングを開始するとそのネームスペースのメトリクスポーリングを停止します。
    • こちらは反映が完了すると元通りになるため、許容範囲と判断し、念のため開発者へリリースタイミングを周知するにとどまりました。
  2. aws.applicationelb.httpcode_elb_5xx など一部のメトリクスにおいて、CloudWatch Metricsのデータポイントがなかった場合はNO DATAになる
    • GetMetric APIの場合は、CloudWatch Metricsにデータポイントがなかった場合、Datadog側には0のデータポイントが入りましたが、CloudWatch Metric Streamsの場合は、0のデータポイントが入らないという仕様差異がありました。
    • こちらはモニタリングアラートがRecoverしなくなるなど明確な問題があったため、事前に該当するモニタリングアラートにdefault_zeroをつけて回る修正を行いました。

まとめ

CloudWatch Metric Streams方式への移行により、メトリクスの収集が高速化され、MTTDを約10分ほど短縮できました(まだリリースしたばかりなので、本当のところはMTTDが短縮される見込み、です)。

これからも高トラフィックなアプリケーションで信頼性を担保するための地道な改善を続けていきたいと思います!またね〜

東京Ruby会議12に参加しました

みんなでパシャリ

タイミーの新谷、神山です。

東京Ruby会議12 が1月18日に開催されました。タイミーは Gold Sponsor として協賛をさせていたただき、ブースを出展していました。ブースに来ていただいたみなさんありがとうございます!

盛況なブースの様子

タイミーからは @ryopeko が「functionalなアプローチで動的要素を排除する」というタイトルで登壇しました。

speakerdeck.com

また、タイミーには世界中で開催されているすべての技術カンファレンスに無制限で参加できる「Kaigi Pass」という制度があります。

productpr.timee.co.jp

この制度を使って2名のエンジニアが参加しました。 参加して聞いたセッションのうち印象に残ったいくつかをピックアップしてご紹介します。

Keynote "Scaling Ruby @ GitHub"

GitHub 社の John Hawthorn さんによる GitHub というプロダクトがどのようにして規模を拡大し、高可用性とパフォーマンスを維持しながら、アプリケーションを効率的に運用しているかについて紹介するセッションでした。

セッションの中ではたくさんのノウハウの紹介がありました。

  1. 大量の Pull Request のデプロイを効率的に管理するためのマージキュー
  2. 問題が発生した際に素早く切り戻すための Feature Flag flipper gem
  3. パフォーマンスチューニングを行う際の性能比較を行いやすくするためのツール scientist gem
  4. データベースレプリケーションを最適化するためのツール freno gem
  5. DB再接続の機構と過度に再接続を行わないようにするための Circuit Breaker の仕組み

発表の中で GitHub はモノリスな Rails で運用されていて、コード行数は380万行弱、テストコードは200万行弱という話がありました。単純な引き算をするとテストを抜いた実装に関するコードは180万行弱ということになります。これは現在のタイミーのモノリスの10倍以上ものコード行数です。

モノリスであること自体がスケールのボトルネックになるわけではなく、モノリスを取り巻く周辺環境の整備さえできればこれだけ組織がスケールするという点は大きな励みになりました。

また、発表の中での「GitHub 社に入社後、GitHub が普通の Rails アプリケーションだったことに驚いた」という話も印象的でした。飛び道具を使うわけではなく、実直に目の前の課題に対処することへの重要さを再認識しました。

発表の中でいくつかの GitHub 社のテックブログが引用されていたと思うので、こちらを参考にさせていただこうと思います。

github.blog

心のどこかで遠い存在のように感じていた GitHub が我々の開発の延長線の先にいるように感じられた、そんな発表でした。

(@euglena1215)

新谷が書いているように、GitHub が弊社の開発の延長線上にいるように感じました。 特に scientist の gem は変更に対して堅牢さをもたらしてくれるなと感じているので、結構気になっています。 スライドが公開されたら見返したい。

(@dak2)

Writing PDFs in Ruby DSL

Cookpad Inc. の Hiromi Ogawa さんによる Ruby DSL で PDF 書こうぜというセッションでした。

github.com

私は前職で thinreports で PDF に出力する項目を修正していたことがありました。

github.com

そのため、個人的にセッションの内容が気になっていました。

PDF の構造は知らなかったので、自分にとっては知見だなあと思いつつ自分だったらどう書くんだろうかと思いながら楽しく拝見しました。

業務で使っているツールなどをハックして再実装するなどの試みは、そのツールとの機能差分が比較できてより理解が深まりますよね。

何か Ruby で再実装できないかなあと意識する良いきっかけになりました。

セッションのスライドの PDF 自体も Ruby DSL で自作されていたという最後の伏線回収まで綺麗でお見事だなと思いました(笑)。

(@dak2)

Simple組み合わせ村から大都会Railsにやってきた俺は

これまで軽量なライブラリの組み合わせによって Web サービスを開発してきた(≒ シンプル組み合わせ村に住んでいた)ところから、フルスタックな Rails を書くようになった(≒ 大都会Railsに移り住んできた) moznion さんによるシンプル組み合わせと大都会Railsの比較を行うセッションでした。

speakerdeck.com

私は業務でちゃんと使ったことがあるのが Rails のみでSimple組み合わせ村に住んだことがないシティーボーイだったということもあり、興味深く拝見しました。

Simple組み合わせ村も大都会も「どちらも正解だよね」と結論だったのですが、Simple組み合わせ村に住んだことがない自分としては適材適所の具体例を一歩踏み込んで聞けると尚良かったなと感じました。

また、これは発表と直接関係ないのですが、Simple組み合わせ村が発達している言語においてはDI(Dependency Injection)も同様に発達しているような印象があり、それは組み合わせの差し替えを容易にするためだったりするんだろうか…と聞きながら考えていました。

(@euglena1215)

私も production 利用のコードベースで触ったことがあるのは Rails のみな都会っ子です。

セッション内容を聞きながら、20年経っても Rails が当初の価値観を崩さず、Rails でいつづけられるのは、Easy であるからこそなのではないかなと思っていました。

Simple 組み合わせ村は「俺の考えた最強のxxxx」が乱立するんだろうなと思いますし、すべてのプロジェクトでそれが通用するかと言われると微妙なところがあると思っています。

Rails は Rails Way という言葉があるようにレールに乗った開発を推奨しているので、同じコンテキストの情報が Web にたくさん落ちていますし、そういった面からもクイックにやりたいことを実現できる素養があって、ここまで使われているんじゃないかなあと考えていました。

(@dak2)

Regional.rb and the Tokyo Metropolis

広義の “Tokyo” の地域.rbのオーガナイザーが一堂に会し、色々なことに対してガヤガヤと話す RubyKaigi の Ruby Committers and the World 的な会でした。

東京近辺にこんなに地域.rbがあるのかという驚きが第一印象でした。他の言語のコミュニティにあまり参加したことがないのですが、ここまで地域コミュニティが発展している言語はあまり多くないのではと予想します。Asakusa.rb のようなOSS活動などでアウトプットすることを目的とした地域.rbもあれば、しんめ.rb のような初学者向けの地域.rbがあったりと裾野が広さを改めて感じることができました。

たくさんの地域.rb オーガナイザーたち

私は普段 omotesando.rb に参加することが多いのですが、地域.rbがあることで普段の業務や趣味で取り組んでいることを対外的に発表する機会が生まれ、登壇資料を作る中で自分の中でも理解の整理が進み、発表した内容を元に懇親会で興味ある人とざっくばらんに話すという一粒で三度美味しい経験をしているので、地域.rbのオーガナイザーには感謝してもしきれません。本当にありがとうございます。

(@euglena1215)

三浦半島.rb が立ち上がったのを聞いて Kaigi Effect を感じました! 私は自宅近くの地域.rbにしか参加していなかったので、これを機に他の地域.rbにも顔を出してみようかなあと思いました。私なりの Kaigi Effect です(笑)

(@dak2)

Keynote “Ruby と Rust と私”

Cookpad Inc. の Suzuki Kohei さんによる Ruby と Rust の実装を比較しながら感想を述べていくセッションでした。個人的には最近趣味で Rust を触ってみているので、どういう違いがあるのだろうかと気になっていました。

speakerdeck.com

並行処理の文脈で「Ruby だと工夫が必要なところが、Rust では普通に書くだけで達成できる」という言葉が印象に残っています。メンテなども考えると、この間の距離って強い気持ちがないと埋めづらいなと聞きながら思っていました。

Result 型の question operator によるエラーハンドリング便利ですよねとか、SQLx で DB の row をデータ型にマッピングできるのかとか共感や発見が得られて面白かったです。

余談ですが @euglena1215 が Suzuki さんと ISUCON の Ruby 実装に型を付けたいという話をされたようで、ISUCON の Ruby 実装にも型がつくかもしれません。

(@dak2)


今回のコンセプトは「Ruby と Class」ではなく「Rubyと暮らす」でした。

発表としても業務で Ruby を使っている、というよりももう一歩生活の中に Ruby が溶け込んでいるような印象を受ける発表が多かったような気がします。

RubyKaigi とも Kaigi on Rails とも異なる、アットホームな味のある楽しいカンファレンスでした。東京Ruby会議12のオーガナイザー、ヘルパーのみなさんありがとうございました!

ファインディ株式会社 x 株式会社タイミー 合同勉強会

「エンドユーザーのためのデータ品質向上への取り組みと展望」というタイトルでファインディさんとクローズドな合同勉強会を実施しましたので、タイミー目線でのレポート記事をお届けします。

きっかけ

以前同じ企業に所属していた両社の社員の間で合同勉強会の話が持ち上がったのがきっかけです。

両社共にデータ品質向上のための取り組みを進めており、参考になることが多いのではということで合同勉強会を開催する運びとなりました。

勉強会当日の流れ

勉強会はファインディさんのオフィスにて開催いただき、タイミーからはデータアナリスト、アナリティクスエンジニア、データエンジニア等のメンバーでお邪魔しました。

各社でLTを行った後、データに関連する話題を中心とした懇親会を行うという流れです。

LTの発表内容

各社からの発表のタイトルと概要についてご紹介します。

ファインディ

マルチプロダクトのデータ基盤にデータメッシュを採用した話 / ファインディ ひらきさん

データ基盤チームの発足から、データメッシュを採用するに至った経緯や運用についてお話いただきました。特にマルチプロダクトにおけるデータ基盤の運用の難しさや、データメッシュにおけるデータプロダクトをどのように定義するかについて、興味深く拝聴しました。

PII保護のためのDLP運用 / ファインディ tagashiraさん

データ権限の管理方針や、DLP(Cloud Data Loss Prevention)を利用した個人情報保護に関する取り組みについて共有していただきました。DLPを使い込んでいないと出てこない課題感が多く含まれており、大変勉強になりました。

タイミー

各発表者からコメントを貰いましたので、合わせてご紹介します。

ユースケースに合わせたデータ品質 / タイミー atshsy

タイミーでは、2024年3月にデータ品質の向上を目的として、RDBからデータ基盤へのパイプラインを刷新しました。刷新からしばらく経ち、データ品質について改めて評価したところ、完全性の観点で新たな課題が見えてきました。この発表では、改善に向けて取り組んでいる内容と、ユースケースごとに求められるデータ品質の違いについて共有いたしました。

ユーザーニーズに合わせたデータ鮮度の提供 / タイミー okodoon

アナリティクスエンジニアのokodoonです。

複数レイヤーを保持しているデータ基盤の更新を、ユーザーの求める更新頻度で更新されるように全体の更新戦略を構築していく話をしました。レイヤーごとに求められる鮮度の概念が異なることを説明しつつ、dbtコマンドを用いて「どのように最適な更新頻度を実現するのか」現時点で弊社が考えているデザインを発表した形です。

基盤の信頼性を活かした 全社データ活用推進の取り組み / タイミー kuritama

データアナリストのkuritamaです。

私からは、データ基盤の信頼性を活かして、全社のデータ活用推進に取り組んでいる話をしました。タイミーではディメンショナルモデリングを運用し安定したDWH・データマートを提供しており、そのデータマートへのアクセス手段として全社的にlookerを導入しています。データアナリストは分析業務と並行してlookerの全社活用推進を担っており、勉強会ではその活動内容の一部を紹介いたしました。

懇親会の様子

ファインディさんに食事をご用意いただき、大変美味しくいただきました!

各所で小さなグループが自然発生的に出来上がり、LTの内容に限らずデータに関する課題についての議論が行われていたのが印象的でした。

振り返って

初の取り組みということもあって緊張の面持ちでお伺いしましたが、蓋を開けてみると終了時間を過ぎても話題が尽きず、和やかな勉強会となりました。ファインディの皆様が暖かく迎えてくださったお陰と感じています。

開催をリードしてくださったひらきさん、ファインディの皆様、本当にありがとうございました!

勉強会の内容については、事前に想像していたよりも両社が似た課題を感じていることに驚きました。データ品質に関する課題について、他社がどのように捉え対応しているのかを知る機会は多くありませんので、とても貴重な機会となりました。

他のタイミーのメンバーからは、オープンな勉強会と比較して話しやすかったという感想がありました。共通の課題について率直に意見交換できるのは、クローズドな勉強会ならではの良さがあったように感じています。

終わりに

タイミーでは、今後もこうした形式で他社のデータ関係者と交流を図っていければと考えています。ご興味がありましたら、気軽にお声がけください!

yykamei が Regional Scrum Gathering Tokyo 2025 に参加してきました

はい、亀井です。 yykamei という名前でインターネット上ではやらせてもらっています。所属はタイミーです。

今回、 Kaigi Pass という制度を利用して Regional Scrum Gathering Tokyo 2025 (RSGT 2025) にボランティアスタッフとして参加させていただきました。ShinoP さんと takakazu さんに「RSGT 2025 でボランティアスタッフをやるのですが、スタッフでも Kaigi Pass 使えます?」と相談したところ「いいね!」というお声がけをもらい、晴れて Kaigi Pass を利用して参加することができました。お二人に感謝。

Day 0

RSGT への参加自体は今回が2回目です。2回目の今回はスタッフとしての参加で「なんもわからん」という状態で若干の不安を抱えながら Day 0 を迎えました。

この Day 0 というのは、つまり「前日」の意味ですね。 RSGT 自体は 2025 年 1 月 8 日に始まりますが、その前日からいろいろと活動をするわけです。

Day 0 の日に会場についたところ、誰かから「ここはふわっと始まるんで」と言われ、たしかに、「ふわっと」作業が始まりました。到着時点ですでになんらかの作業をしていたメンバーが数人いたのですが、やることがわからないので観察するしかありません。観察していると、だんだんと「なるほど、これをここに持っていくのね」「ブースの荷物を持っていくのね」などがわかってきますし、「誰か◯◯をやってー」という感じのヘルプ(指示ではない)が発生するので慣れないながらもそういう作業をします。

とはいえ、今回のボランティアスタッフはそれなりの人数がいらっしゃったようで、すぐに誰かがなにかしらの作業をしてくれるので、やはり観察する時間が長かったです。

Day 0 のメイン作業といえばノベルティーの準備でしょうか。参加した方はわかるかもしれませんが、トートバッグみたいなものがそれぞれに配られます。

その中にステッカーだったりペンだったりが含まれていますが、そうした内容物をトートバッグに入れる、という単純な作業を行なっていました。これ、それなりに大変でして、現地参加者の数が結構いらっしゃいますので単純に量が多くて大変です。

ただ、そこはさすがというべきか、スタッフがこの単純作業の中で自分の役割を見出し、途中から流れるようにノベルティーが完成していきました。まさしく自己組織的な何かを垣間見たような気がします。

ノベルティー準備の様子

この単純作業の最中にトラブルもありまして、作業がいい感じにスムーズに進み始めたあとに「これもトートバッグに入れる必要がでましたー」ということになり、その時点まで完成させていたノベルティーをもう一度点検してやり直す羽目になりました。こういうスクラム関連のワークショップ、ありますよね。もう擦られ続けた VUCA というワードですが、こんなところにもその片鱗が見えました。

Day 0 では、夕方以降に Speakers Dinner というものが開催されました。こちらは登壇者とスポンサーの方々、そしてスタッフが和気藹々と話す場です。やはりここも「ふわっと」始まります。ただし、会場を借りている時間の関係もあるので終了時間はきっちり守ります。それが終わったら各々二次会などに行っているようでした。

Day 1

そして、いよいよ Day 1 を迎えます。ここからが本番ですね。 Day 1 での主な私の役割は Room B での部屋付きです。The way through data to quality “Measuring Quality”Untangle your team with a new approach. (プロポーザルの段階では "A new innovative way to manage the complexity of a team.” でしたが、タイトルを変更したようです))という二つの登壇を担当しました。

これらの登壇は海外から来てくれたスピーカーがやってくれたので、メイン言語は英語でそれを日本語に通訳してくれます。質疑応答についても日本語で質問をすれば英語に通訳され、英語で質問されれば日本語に通訳される、という感じで通訳の方々が大活躍する現場です。

また、通訳の皆さんは別の部屋で行うので、もしスピーカーや質問者がマイクを使わずに話してしまうと通訳の方々にオリジナルの音声を届けられず、部屋付きは意外と気を抜けません。当初は「のんびり登壇を聞いていようか」ぐらいに思っていたのですが、部屋付きに入ると「これは参加者や登壇者の満足度に影響しそうだ」ということに気づきました。

そのため、マイクに音が入っているか確認しながら会場の様子に気を配る、ということをしたので、登壇内容はほとんど理解できませんでした。あとで録画を見ようと思います。 Untangle your team with a new approach. という登壇をしてくれた Teemu に同じ部屋付きだった松下さんが「Last name はどうやって発音するの?」と聞いていてさすがだな、と思いました。その問いに対して Teemu は「そうなんだよ。みんな、このスペルからは発音の仕方がわかる人はなかなかいないよね」的なことを回答していました。部屋付きだと登壇者とこういう会話ができていいですよね。

Day 2

Day 2 も引き続き部屋付きでした。この日の担当は Cowtopia: Designing Agility Through Playful Innovation で、こちらはワークショップになります。 1 時間 40 分の時間を使ったワークショップでクネビンフレームワークを体験してチームを改善していくためにはどうすればいいのか?というような内容だったように思えます。部屋付きで見ていると参加者同士で交流をされていてとてもよかったですね。登壇を聞くのもいいですが、ワークショップに行くと半ば強制的に人と交流することになってそれはそれで Gathering ができてよいのではないでしょうか。

Day 2 にもなってくるとスタッフ業もだんだん慣れてきてようやく廊下を楽しむ、ということができるようになってきました。ただ、人と話している時にもトランシーバーの音声に注意していたので 100% 会話を楽しめたか?というとそこは課題がありそうです。

次回、チャンスがあればいかにうまくトランシーバーを扱っていくか?ということを研究したいと思います。そういえば、 Day 2 で正義さんに「30 秒ピッチやりたいんですけどどこに行けばいいですか?」と質問され「え!なにそれ!?」という感じで Confengine を見たところたしかに “Lunch Time (with 30 seconds pitch from anyone @ Terrace Room)” というのがあり、あわてて実行委員の永瀬さんに聞きに行きました。

そしたら永瀬さんも「え!なにそれ!?」という感じで急遽連携を取り合ってなんとか 30 秒ピッチを開催することになりました。スタッフの新さんがきっちり 30 秒はかって、肉声でドラを叩くということをやってくれて急ごしらえの割には面白いコンテンツになったのかもしれません。

Day 3

Day 3 はメインホールで Open Space Technology (OST))を行い、事前に募集している人たちは別の部屋でワークショップに参加する感じです。この日は特に私に役割があったわけではないのですが、とりあえず、 OST の部屋で入り口付近にみなさん座りがちだったので、奥のほうに誘導していました。

OSTが始まるときの様子 — 円形に並んで座ります

OST は始まるタイミングでは全員が円形に並んで座ってインストラクションを聞いて、各自持ち寄りたいトピックを書いていくのですが、その円形の並びがどうしても手前に偏ってしまったんですね。その偏りの修正をやっていました。 OST が始まる前に OST の寸劇があったのですが、私は廊下にいたので見られませんでした。あとで録画を見て楽しもうと思います。

OST では相変わらず熱量を持った参加者がテーマを持ち寄り、いたるところで活発な議論が行われていたようです。熱量が凄すぎてその日は寒かったはずですが、会場内は熱気が凄かったですね。私はなんとなくフラフラしていたのですが、途中から furoshiki.fm のテーマについてのテーブルにお邪魔しました。実はリスナーなのですが、ここぞとばかりに「お世話になっております」というフィードバックを出させていただきました。これが役に立つのかわかりませんがこれからもファンでいさせていただこうと思います。

Day 3 の OST とワークショップが終わるといよいよクロージングキーノートです。本間さんのお話です。最初の導入部で、現在、本間さんがされている子供たちとのお仕事の話をします。「ホンダの話じゃなかったっけ?」と思ったのですが、この導入部がないと実はホンダでのワイガヤの話がすっと入ってこないんです。ある意味焦らすような感じなのですが、全体を通して振り返ってみると「めちゃくちゃいい話だな!」という感想になります。さすがです。

ホンダの話になってくると City の開発の裏話?的なお話がされますが、とにかく「ワイガヤ」というのがキーワードですね。そして、本間さんは最後のほうで RSGT の OST に「ワイガヤ」を見出していただいたようで、ちょっと嬉しいですよね。そういえば、先日 Slack の Huddles を使ったプラクティスとその背後にある考え という記事を書きましたが、このワイガヤにも通じるな、と一人でにっこりしておりました。

まとめ

ということで、つらつらとボランティアスタッフとしての RSGT 2025 を書いてみました。ボランティアスタッフだとあまり RSGT を楽しめないかも?などと思っていたのですが終わってみるともう一度やりたいな、という気持ちになっています。

スタッフとしての仕事に慣れてくるとだんだんカンファレンス全体を俯瞰して見られるようになりわずか 4 日ながら自分の成長を実感しました。こんな感じで正統的周辺参加をしてコミュニティーに関わっていくのか、と実感しております。

オーガナイザーとスタッフの皆さんで最後に記念撮影