こんにちは！タイミーでAndroidを主軸にしながらプロダクトエンジニアをしている中川です。 6月25, 26日の2日間、ニューヨークのブルックリンで開催された droidcon 2025 NYCに参加してきました。 今回の参加には、個人的に強い動機がありました。 30歳になる節目に、日本だけでなく世界で自分がエンジニアとしてどの位置にいるのかを確かめたかったのです。 今回このような貴重な機会をいただけたのは、日頃から支えてくださっている社内の関係者の皆さまのご理解とご支援、そして不在の間、現場を支えてくれたチームメンバーのおかげです。心より感謝しています。 タイミーには、世界中で開催されているすべての技術カンファレンスに無制限で参加できる「Kaigi Pass」という制度があり、今回はこの制度を利用してカンファレンスに参加しました。詳しくは以下をご覧ください。 productpr.timee.co.jp 私自身も、入社する前にタイミーのエンジニア組織について調べており、2023年にも現在の同僚が droidcon San Francisco に参加した記事を読み、これらのエンジニアの成長を強く後押ししてくれる制度に魅力を感じ、実際に入社を決める一つの大きな要因となりました。 productpr.timee.co.jp 今回のdroidcon 2025 NYCはニューヨークの Brooklyn Storehouse で開催されました。会場はStorehouseという名の通り倉庫の形をしており、およそ10,000㎡の広大なスペースでセッションごとに仕切りを設けずに開催されました。 カンファレンス会場には高さ5メートルほどの巨大なドロイドくんが設置されており、初めての人でも「ここが droidcon だ」と感じさせてくれる象徴的な存在でした。 しかし、それ以上に存在感を放っていた“見えない 象 ”がいました──それは AIとレイオフ です。 You’re Not an Android Developer Anymore (Keynote) Stacy Devino 全米のみならず世界中からAndroidエンジニアが集まるカンファレンスの初っ端から、いきなり核心を突くタイトルが登場しました。"こういうの待ってたぜ…USA…" とタイトルを見た時から感じていました。 今、アメリカには大きなレイオフの波が来ており、実際にレイオフをされて仕事を探している人が周りにいるかという質問に対し約7割の人が挙手しており、アメリカのIT業界の現状を肌で感じる機会になりました。 セッションではStacyが長年にわたり、さまざまな企業で Android エンジニアとして活躍してきた経験をもとに、これからの時代に生き残るための戦略を語りました。 AIの進化によって、プロダクトマネージャーやデザイナーなどのエンジニア以外の職種でもある程度の機能を作れる環境になってきています。 そして今後、モデルが進化したら誰でもソフトウェアを作れる時代が来るかもしれない──その中で、Androidエンジニア、ソフトウェアエンジニアはどうあるべきか？を問いかけるセッションでした。 セッションの中で語られていた 問題解決にフォーカスすること 自分の専門領域にとらわれず越境をすること 小さな職能横断チームでゴールに向かって動くこと これらはまさに、タイミーにおけるSAチームのプロダクトエンジニアのスタイルと強く重なる部分で、聴いていて非常に共感しました。 docs.google.com "Ask Android" Office Hours Google's Android DevRel team さまざまなセッションの裏で自由にGoogleのAndroid DevRel teamのメンバーになんでも質問をすることができる"Ask Android"にも参加をしました。この会は特にファシリテーターやルールなどはなく、その場にいるGoogleのAndroid DevRel teamのメンバーを捕まえていろんな質問をぶつけることができました。 実際にComposeに注力をしているAlexに話を聞く機会があり、Edge to edge対応やLarge Screen Device, Material Designについてさまざまな話（ここには書けない裏話も含めて）を聞くことができ、貴重な時間になりました。 彼らのようなライブラリを提供する側からすると、逆にアプリケーションを開発するエンジニアがどんなことを考えながらアプリを作っているかに興味があり、お互いに情報交換をする機会にもなりました。 AlexはHandling configuration changes in Composeというタイトルで2日目のセッションにも登壇をしており、この"Ask Android" Office Hoursをきっかけに彼のセッションを聴講したのですが、なんとComposeの動作に関する例で実際にUIがスライド内で動作しており、これはもしや…と思いながら最後まで聞いていると、やはりスライド自体もComposeでできており、Composeを提供している側ならではの、圧倒的な熱量に驚かされました。 https://alex.vanyo.dev/talks/configurationchanges/ Career Office Hours with Stacy Devino 先述したStacyと参加者が円になって座り、キャリアの相談をする会でした。このセッションにはスライドやアジェンダもなく録画もされません。純粋にそれぞれのキャリアの相談をStacyと一緒に考える会でした。 相談の内容はレイオフの波もあり、かなり深刻なものが多かったです。個々人の話であるのであまり詳細には触れないのですが 実際にレイオフにあった マネージャーからICに戻ることに対する葛藤 Native/Flutter/React Nativeなどさまざまなモバイル開発手法に手を出したがどれも深掘りできておらず自信を持てずに悩んでいる 大学でCSを学んだが入学時と卒業時でマーケットが激変していて就職に苦しんでいる など聞いていて胸が苦しくなるような話題が多くありました。そのような困難な相談に対してもStacyの持ち前のポジティブさと、これまでの経験に基づく的確なアドバイスによって40分間のセッションでしたが、参加者はセッション後には前よりは明るい顔になっていくのをその場で感じました。 なぜ「現地に行く」ことが大きな意味を持つのか？ この記事の執筆時点では公開されていませんが、今回のdroidconの動画は例年通りであればインターネット上に公開されます。しかしながら実際に足を運ばなければ得られない体験をたくさん経験することができました。 カンファレンスはセッションを聞くだけの場所ではなくコミュニティが存在する場所である 動画が後からアップロードされるカンファレンスでも現地でしか得られない体験が多く存在し、例えば以下のようなものが挙げられます。 現地での出会いをきっかけに、実際に仕事が決まることもある セッション外でスピーカーにさまざまな質問をぶつけることができる 朝早く会場に入ってStacyのような有名なエンジニアを見つけて会場で朝食を食べながら話をすることができる 有名な人を捕まえると自然と人が集まってきて、さまざまな議論が始まったりする セッション後にスピーカーにセッションに関連することも、それ以外の気になることも質問することができる Androidという共通の話題をベースにキャリアだけでなくプライベートについても話をすることができる Jake Whartonと話をして記念写真を撮ることができる 世界中のエンジニアが集まる場で感じたこと 世界と比べても、タイミーのエンジニアたちは十分に戦えていると感じました 有名OSSやJetpackライブラリの開発者など、世界的に活躍しているエンジニアたちは、やはり圧倒的でした jakewharton.com すべてのセッションが上記のJakeのセッションのようなAdvancedな内容ではなく、自分がある程度知っている内容のセッションも一定数あり、自分もいつか、この舞台に立てるかもしれないという希望を持てました 雇用について改めて考え直すきっかけに 今回のカンファレンスを通じて、自分自身のキャリアだけでなく、「雇用」そのものについても考え直す機会になりました。 アメリカの大規模なレイオフの波を目の当たりにし、これまで安定だと思っていた“正社員”という立場も、企業の方針や市況の影響を受けて簡単に変わりうる現実を実感しました。一方で、個人として武器を持ち、どこにいても価値を発揮できる状態でいることの重要性も強く感じました。 タイミーという「働き方」に向き合っている会社で働く自分が、 “雇用とは何か” をアメリカの現地で問い直すというのは、とても象徴的な体験だったように思います。 おまけ 時差ボケを考慮してスケジュールを組ませていただき、カンファレンスのない日は、せっかくニューヨークまで行ったので、観光を楽しむこともできました（もちろん仕事もちゃんとしていました）。 ナイトミュージアムの舞台になったアメリカ自然史博物館 ブロードウェイにてマイケルジャクソンの半生をミュージカルにしたMJ the Musical

こんにちは！タイミーでBackend Engineerをしている @akitoshiga です！ 7月3日（木）、7月4日（金）に東京の丸の内で開催された「開発生産性Conference2025」に参加してきました！🙌 dev-productivity-con.findy-code.io 自身は7月3日（木）のDay1に現地参加したので、その時の様子を振り返ってみたいと思います！ 当日の様子 関西在住の自分は「Kaigi Pass」という社内制度を利用して参加しました。 「Kaigi Pass」とは、世界中で開催されているすべての技術カンファレンスに無制限で参加できる制度です。 productpr.timee.co.jp 会場はJPタワーホール&カンファレンスという東京駅近くにある会場で行われました。 最初のセッションで基調講演を行ったのはケント・ベック氏でした。 彼のファンである自身は今回聴講できて感無量でした。 Day1 Keynote、Kent Beck @KentBeck 氏 11時からはサイン会も実施します！✒️ #開発生産性con_findy #開発生産性con_findy_A pic.twitter.com/s0COYqZCY2 — 開発生産性Conference/Developer Productivity Engineering (@dpe_findy) 2025年7月3日 その後のサイン会でケント・ベック氏にサインをもらいました！ サイン会の場で彼に対する想いと感謝を直接伝えることができて嬉しかったです。 サイン会の後、スポンサーブースを回ってみたのですが、非常に盛況でした。 ブースもたくさんありましたが、それ以上に参加者の多さに圧倒されました。 タイミーのブースもこんな感じで出展していました！ ＼ #開発生産性con_findy ブース紹介✨ ／ 株式会社タイミー様 @TimeeDev pic.twitter.com/lq9LWwyE8y — 開発生産性Conference/Developer Productivity Engineering (@dpe_findy) 2025年7月3日 また、タイミーからはプラットフォームエンジニアリング部部長の恩田が登壇しました。 参加したセッション 自身が参加したセッションについてもいくつか紹介をしたいと思います。 基調講演：開発生産性測定のトレードオフ 「グッドハートの法則」はもっと悲観的に捉えるべきだった ケント・ベック氏 冒頭で「物事をより良くしようとしてかえって結果が悪くなってしまう」という旨のドイツのことわざを紹介しており、要所要所でこちらに言及しているのが印象的でした。 「グッドハートの法則」とは「指標が目的になった途端それは良い指標ではなくなる」ことを言うそうで、これを提唱した英国の経済学者の名前にちなんで名付けられたそうです。 生産性向上のために指標を設け測定したとしても、開発者にプレッシャーをかけるとその指標を達成することが目的になってしまうと主張していました。 タイトルに「もっと悲観的に捉えるべきだった」とありますが、このような指標の目的化現象は我々の想像以上に起こりやすく、またいろいろなところでそのような場面にケント・ベックは直面していたようです。 実際にこのような事態は誰しもが一度は経験があるのではないでしょうか。 このことについて、開発者にはプレッシャーをかけるのではなく目的意識を共有することが重要だと主張されていました。 また、測定すること自体は良いが、決して目標にしてはならず測定のポイントにも注意が必要だと主張していました。 ケント・ベック氏は「Path of Value」として以下の4つのプロセスを紹介しました Effort コードを書くこと Output 具体的な成果物（画面上のボタンなど） Outcome ユーザーの価値変容 Impact ユーザーの行動変容 1から4に行くほど測定はしづらいが、ユーザーの価値につながるため、測定の判断は先送りにしてなるべく後ろのプロセスで測定することを推奨していました。 最後にグッドハートの法則に対応する形で以下を結論づけました。 Observe later（計測はなるべく遅らせ後ろの段階で行う） Encourage awareness（気づきを奨励する） Avoid pressure（プレッシャーをかけること避ける） Instill purpose（目的意識を共有する） 「グッドハートの法則」に基づくケント・ベック氏の主張は、ある種当然と言えば当然のようにも思われるのですが、彼がこの主張をすることにものすごく意味があると感じました。 開発プロセスにおける本質的な部分をテーマにした彼らしい発表だと感じました！ NTTデータによる生成AI活用：開発効率化とビジネス変革 株式会社NTTデータグループ 海浦 隆一氏 NTTデータは2025年7月にApps&Data技術部からAI技術部へと組織改編して生成AIの活用を本格的に推進しており、これまでのミッションクリティカルなシステム構築で培った生産性向上ノウハウを基盤に、開発スピード向上と品質維持の両立を目指しているそうです。 取り組みのロードマップとしては自動化の段階的推進: 2023年のタスク自動化から始まり、2025年にはプロセス自動化、2027年にはビジネス全体の自動化を目指しており、既に250以上のプロジェクトでAIを活用しているとのことでした。 主な取り組みと成果として以下について紹介していました（一部） モダナイゼーションとレガシーシステムの解明 FigmaからのReactコード生成（Locofy） ソースコードからの開発ドキュメントのリバースエンジニアリング OSSからのマニュアル生成などにより、システムの理解と保守にかかる工数を削減 属人化防止とドキュメント作成の効率化 有識者の暗黙知を形式知化し、独自様式の設計書を標準形式に変換する「Coding by NTT DATA」の活用 ExcelからMarkdownへの変換など、AIが読み取りやすいフォーマットを採用 開発プロセスの各段階でのAI活用 GitHub CopilotやAzure OpenAIを利用 設計書からの結合テスト項目を作成 さらなる生産性向上への展望として開発工程全体の生産性向上を目指し、要求分析から直接コードを生成し、その後設計書をリバースエンジニアリングする「逆Wモデル」といった新しい開発プロセスの実現を模索していることが非常に印象的でした。 全体的にAIを中心に据えて最大限AIの恩恵を受けられるように開発プロセスを設計しているように見受けられ興味深かったです。 また、多種多様なプロジェクトに携わっている強みを活かしてシステム開発における全域に渡って実践・フィードバック・形式知化・横展開を行えているのが組織として非常に魅力的に感じました！ 生成AI時代の品質保証：自動化とAIによるテスト改善 speakerdeck.com mabl株式会社 小田 祥平氏 現状を取り巻くQAの問題点と、そのソリューションとしてAIエージェントによる自律型テストを紹介されていました。 QAに関して課題を抱えているところは多いそうで、独自アンケートによると対象者の6割が手動でのテスト対応を行っているとのことでした。 この背景には以下の問題があるそうです。 保守コスト 基盤の構築と実施コスト ナレッジ不足 特にAIの台頭によりデプロイ頻度の増加と品質維持の要求が高まる中で、テストの自動化とAIの活用が不可欠であるということを強調されていました。 これらの課題のソリューションとしてAIを活用したテストマネージドツールの提案をされており、「mabl」というサービスをベースとして以下のようなテストマネージドツールの機能について紹介されていました。 マネージドツールの活用 生成AIによるテスト自動修復機能でメンテナンスコストを削減 AIによるデータ分析・推論 テストログからの原因分析、flakyテストへの対応 自然言語でのテスト構築 ユーザーストーリーからテストケースを自動生成 CI/CD環境との統合 シームレスなテストプロセスを実現 AIを活用したテストツールはこれまで詳しく追っていなかったので想像以上の多機能・高機能さに驚きました！ 開発速度の向上に伴い迅速なQAは今後より求められていくので、こういったツールが不可欠になっていきそうだと感じました。 楽天のAI戦略：70以上のサービス運営と開発生産性向上 楽天グループ株式会社 久田 直次郎氏 楽天グループの展開する70以上サービスの中で、AIを事業成長と開発生産性向上の両輪として活用している現状を紹介されていました。 楽天グループのAI推進戦略として「トリプル20」を打ち出しています。 この戦略はAIを活用してマーケティング・オペレーション・カスタマーサポートの利益をそれぞれ20%向上させることで、年間105億円の利益貢献を目標としています。 社内でのAI活用は非常に効果が出ているそうで、既に16,000個以上のAIツール・テンプレートが作成され、営業資料の作成時間は48%減、ビジネスメール作成時間54%減などの効果が出ているとのことでした。 また、新たな事業として「Rakuten AI for Business」を開始しており一般ユーザー向けに事務・営業・企画/マーケティング・エンジニア向けサービスを提供しているそうです。 それだけでなく、「Rakuten AI LLM」という自社LLMの開発も行っており、用途に合わせた最適化・日本企業に合わせた設計・日本語性能の高さを強みとしているそうです 開発におけるAI活用ではコーディングが最も多く、GitHub Copilotなどの生成AIコーディングツールの導入PoCで一定の効果を確認しているとのこと。 開発サイクルタイムのデータ収集と標準的な可視化を進めており、30%～80%の開発効率削減を目指しているそうです。 楽天グループには約30,000人の従業員の方がいるそうで、AIによる業務効率化のインパクトは非常に大きいと思いました。 また、自社で日本語性能を強みにしたLLMを開発されているのが非常に興味深く、どういったところで活用されていくのかについても興味が湧きました。 まとめ 開発生産性Conferenceには今回初めて参加したのですが、各社の開発生産性に対する様々な取り組みや参加者の熱量を感じました。 今回参加して得た知見を自身や周りの開発にも活かし、より生産的なプロダクト開発を行ってまいります！ お知らせ 開発生産性Conference2025でタイミーと同じく登壇されたログラスさん、DELTAさんと合同で「生産性改善しNight」と題したアフターイベントを開催します！ 「開発生産性 Conference 2025」に参加された方はもちろん、開発生産性の向上や、社外のエンジニアとの交流に興味がある方も大歓迎ですのでぜひ遊びに来てください！ timeedev.connpass.com

こんにちは！タイミーでバックエンドのテックリードをしている新谷（ @euglena1215 ）です。 最近、私たちのチームでは自律型 AI エージェント Devinの活用が広がっています。特に、GitHub Actionsのスケジュール実行や特定のイベントをトリガーに、定型的なタスクをDevinに任せるといった使い方を試しています。 しかし、Devinを使いこなそうとすると、多くの方がこんな課題に直面するのではないでしょうか。 「最初に作ったプロンプトでは、なかなか期待通りのアウトプットが出てこない…」 結局、何度か追加の指示を繰り返して、ようやく望む結果にたどり着く。これは「AIあるある」とも言える状況ですよね。そして、本当に大変なのはここからです。今回のやり取りで得た知見や改善点を、次回の実行のために元のプロンプトへ手動でフィードバックする作業。これが地味に面倒で、つい後回しにしてしまいがちです。 そこで私たちは、このプロンプトの改善作業自体をDevinに任せるという、面白い試みを始めました。今回はその具体的な手法と、それによって得られるメリットについてご紹介します。 面倒なプロンプト修正は、Devin自身にお任せ Devinとの数回のラリーを経て、タスクが無事に完了したとします。ここで、Devinに次のようなプロンプトを投げかけます。 今回私が行った指摘を、次回以降はしなくて済むように、{ここにGitHub ActionsのYAMLファイルのパス} に記載しているプロンプトに変更を加えてください。 たったこれだけです。これにより、Devinは今までのやり取りをすべて学習し、人間からのフィードバックを反映した新しいプロンプトを自ら生成してくれます。 Pull Requestによる変更提案で、レビューも簡単 さらに、私たちはDevinに次の条件を追加で指示しています。 条件 変更内容は、新しいPull Requestとして作成してください。 今回のやり取りで追加した指示と、既存のプロンプトに意味的に重複する部分があれば、それらを統合してプロンプト全体を最適化してください。 この指示により、Devinはプロンプトの変更内容をまとめたPull Requestを自動で作成してくれます。 Devinが作ってくれたPull Request エンジニアは、そのPull RequestをレビューするだけでOKです。 新しいプロンプトでテスト: 実際に新しいプロンプトを使ってDevinにタスクを依頼し、意図通りのアウトプットが出るかを確認します。 評価とマージ: 改善された場合: Pull Requestをマージし、プロンプトをアップデートします。 変わらない・悪化した場合: マージはせず、なぜ期待通りにならなかったのかをDevinに再度フィードバックします。このサイクルを繰り返すことで、プロンプトは継続的に洗練されていきます。 AIが生成したコードを見なくて良い時代はまだ先か。でも… 「AIエージェントが書いたコードを、人間が一切レビューしなくて良い」という未来は、まだ少し先かもしれません。しかし、AIエージェントに与えるプロンプトを、人間が逐一メンテナンスしなくても良い時代は、もう目の前に来ていると感じています。 Devinにプロンプト自身を改善させるアプローチは、単なる作業効率化に留まりません。これは、AIを単なるツールとして使うのではなく、 対話とフィードバックを通じてAIを育てる という、新しい協業の形と言えるのではないでしょうか。 最後に 今回は、DevinのプロンプトをDevin自身に改善させるという、私たちのチームの取り組みについてご紹介しました。この小さな工夫が、皆さんの開発プロセスをよりスムーズにする一助となれば幸いです。 皆さんなりのDevin活用術や面白いアイデアがあれば、ぜひ教えてもらえると嬉しいです。

はじめに まずPFEや開発者との関わりを整理 背景：DevOpsと認知負荷の増大 そこでPFE 開発者との関わり方 我々PFEチームの現状・課題 PFE1Gの立ち位置と現状 懸念とは？ 提供サービスの整理 AWS周りを分解 現状は問題ない？ XaaSやEnablingへの移行が鍵ではあるが Embeddedでチームが劣化してしまうかも 今までのお話をまとめると AI Coding Agent x PFEの青写真 AI Coding Agent技術の現状と可能性 理想のかたち：AI Enablingの実現 宣言的なインフラ変更の実現 余談ですが EnablingモードのAI化イメージ 現実的な課題：コードの外側のコンテキスト 事業要件とコードのギャップ 解決アプローチ：コンテキスト注入とドキュメント化 必要なドキュメント化 AIによるEmbeddedモード連発からの脱却 PFEの役割 この話のまとめ 最後に はじめに プラットフォームエンジニアリング1G Managerの橋本です。チームの名前の通り、私達はクラウドインフラ（AWS）やCI/CDパイプライン、Observability、クラウドセキュリティを軸としてタイミーのサービスプラットフォームを開発者へ提供しています。 昨今、AI Coding Agentの発展は目覚ましく、弊社でもCursorやDevinなどを日常的に利用して開発が行われています。そんな中、AIとPlatformEngineering（PFE）の交差によって、よりビジネスに資するPFEの推進ができるのではないかと"妄想"しました。その青写真や取り組む方向性について記事にします。 まずPFEや開発者との関わりを整理 jacopenさんの以下の登壇スライドが分かりやすいため、本記事に関わるポイントを抜粋します。 speakerdeck.com 背景：DevOpsと認知負荷の増大 クラウドの登場とDevOpsにより、開発とデリバリーの継続的な実施を目指すアプローチが広まった。DevOpsのプロセスにセキュリティ対策を組み込むDevSecOpsも登場 扱う技術スタックの激増により 開発者の認知負荷が非常に高くなった（特にこの10年） これをやり切れる人材は少なく「 真の DevOps」（開発者が フルサイクル でデプロイ・実行を行う）の実現は多くの組織で 現実的ではない そこでPFE 開発者体験と生産性を向上させるために、セルフサービスで利用できるツールチェーンとワークフローを設計・構築する分野 本質は、 開発者体験と開発生産性を高める取り組み PFEの始め方は、 開発フローの「ペイン」（辛いところ）を洗い出し言語化し、 必要な対応を行うこと 例えば、セルフサービス化やInternal Developer Portal/Platform（IDP）構築などがある（が、これが必須でもないと資料では言及されています） 開発者との関わり方 Team Topologiesの整理で、ビジネス価値に一気通貫で関わる Stream-aligned team（ストリームアラインド・チーム） と、その道のプロである Platform team などが定義されている チーム間のインタラクションモードとして以下があり関わりの濃淡で捉えている Collaboration (Embedded) ゴールを共有して一緒に動く（ガッツリ関わる） Facilitating (Enabling) 障害を取り除くためにその道のプロとして支援する（中程度の関わり） X-as-a-Service (XaaS) ツールを提供する（関わりが最も薄い） Platform Teamは、まず Collaboration から始めるのが良い。Stream-aligned Teamと1:1で協力し、必要なものを理解して作ることで、誰得なものを作り込むことを防ぐ Collaborationで得た知見をもとに、より多くのチームを助けられる XaaS モード（プラットフォーム提供）を構築していく。ここでIDPの要素が出てくる 我々PFEチームの現状・課題 先の認識をもとに私達の組織の現状認識や課題感について書きます。 PFE1Gの立ち位置と現状 我々が所属するプラットフォームエンジニアリング部では、開発ライフサイクルの各所でドメイン知識を持ったチームやメンバーにより支援を行っています。（以下の図の 開発プラットフォーム Tribe ） 私達1Gはその中でもサービス実行環境であるAWS基盤全般、リリースツール(CI/CD)や運用(observabilityやAWSに関わるOps)の一部に責務を持ち、開発生産性に寄与するための業務を担っています。実態としてインフラチーム + SREチームの混合というイメージです。 なお、PFEの文脈で出てくるセルフサービスやIDPの提供はしていません。これらの仕組みがなくても価値提供の大きなボトルネックやブロッカーになる状況が観測されていなかったためです。 しかし、将来的に我々自身がボトルネックとなりうる懸念がありました。 開発組織イメージ図 懸念とは？ 提供サービスの整理 主な領域に切り出した場合、以下のような整理になり、AWSという大きな領域以外はおおよそXaaS的なサービス提供ができており、関わりが薄い状態で開発者体験や生産性に寄与できている状態と考えています。 領域 提供方法 提供詳細 AWS いろいろ(後述) - Observability Datadog 関連記事1 , 関連記事2 ダッシュボード化など XaaS的な提供ができていそう CI/CD GitHub Actions 関連記事3 CI/CDパイプライン XaaS的な提供ができていそう AWS周りを分解 AWS環境はTerraform/IaCによる管理をしています。GitHub上でコード管理されており、おおよそのCODEOWNERは1Gになっています。開発者は必要な変更があればPullRequestを作成し、1Gのエンジニアが問題ないことを確認してmergeができます。これは、XaaS的な提供と言えそうです。 ベースラインの運用は先の通りXaaS化がなされています。しかし、必要となるAWSに関する知識、設計難易度やドメイン知識に応じてTeam Topologiesでいう、FacilitatingやCollaborationが必要となるケースがあります。なお、用語的にイメージしやすいFacilitating → Enabling、Collaboration → Embedded として以降は表記します。 なお、例としてバケット追加にXaaS or Enablingと書いていますが、ほぼ依頼をもらって我々が作業を行うことがほとんどです。頻度があまりなく、対して要件によって必要なパラメータが変わるため、Terraform Module化や詳細な手順書を書いていたとしても、結局聞いて我々が考えて設定した方が提供が早く認知負荷も低かったためです。 要件 難易度・範囲 例 Team Topologiesのモード 実装済へ軽微なもの 簡略的・限定的 既存のバケットpolicy変更 XaaS 明確な要件/定型化可能なもの 繰り返し・限定的 バケット追加 XaaS or Enabling もしくは依頼作業型 新しいAWS機能の利用開始 新規・不確定 AWS 〇〇を新規構築 Enabling or Embedded 新サービス/サブシステム構築 新規・広範囲 - Embedded 現状は問題ない？ 先の整理が現状ですが、今時点は大きな問題は起きていません。 しかし、将来への課題感がありました。 Embeddedのチームへの負荷の高さ です。XaaS, Enabling, Embeddedのチーム間の距離感や工数感をイメージにした画像を示します。この絵のようにEmbeddedはほぼ対象チームに人を派遣する形になり、比例して工数的にも他パターンよりも大きくなる傾向があります。Embeddedは、例として新しいサブシステム構築プロジェクトが発生した場合にチームから人を送り込むようなものになります。数ヶ月にわたってヘッドカウントが減ることになり、チームの計画に影響があります。 もちろん、組織全体のビジネス達成観点ではプラスなので間違っていませんが、Embeddedが継続的に発生したり、複数発生した場合はチームが機能不全に陥るリスクがあります。結果、組織全体へ悪影響や我々がボトルネックになるリスクが発生しうると考えました。 XaaS/Enabling/Embeddedの距離感・工数感のイメージ XaaSやEnablingへの移行が鍵ではあるが リスク回避のアプローチはPFEの考えに沿えば、XaaS化やEnablingによって関わり（≒ 工数）を減らし開発者生産性向上を目指すことです。しかし、先に述べた バケット追加が依頼作業型になる ように、現実としては インフラ領域のドメイン知識は多岐にわたるため簡略化・手順化することが困難なケースが多くあります。 仮にenablingパターンで進めたとしても、あれこれお手伝いをしているうちにEmbeddedになってしまうことが想像されました。 Embeddedでチームが劣化してしまうかも Embeddedが多発すると、チームへの負担が増すと述べました。例えば、1人から2人、瞬間的には3人がサブシステム構築プロジェクトに関わることがあります。こうなると、チーム（だいたい1pizza的な人数で構成しています）の半数が出払ってしまうことにもなり、定常的な業務遂行が劣後してしまいます。 サブシステム構築が1つだけであれば「暫く待てば皆戻って来る」という期待が持てますが、2つ以上並走した時点で詰みになります。まだ2以上の並走プロジェクトはありません。しかし、弊社の今後の事業成長・加速に応じて発生する可能性があります。 複数のembeddedパターンが走るケース こうなると、PFEチームがスケールできない = 事業開発への遅延となってしまいます。 このリスクを如何に回避できるか？を考えていた中でAI Coding Agentの急激な成長を見てできることがありそうだと思い至ったこと。これが本ブログの趣旨になります（やっと本題です） 今までのお話をまとめると 以下のようになります 新システム開発のようなEmbeddedでなければならない（XaaSやEnablingでは限界がある）ケースがある 理想はEnablingではあるものの、インフラ領域自体のドメインが巨大であり一朝一夕で開発者が自走できるものではない 結局、巨大なドメイン知識に対応しうる人材が張り付く（Embedded）する必要があり、このスケーラビリティが事業成長のボトルネックになりうる AI Coding Agent x PFEの青写真 AI Coding Agent技術の現状と可能性 我々はIaC/TerraformによりAWS環境を扱うことが多いため、AI Coding Agentのコード生成についてはHCLの記述性に着目することが多いです。 AIのHCL記述力は急速に改善されています。以前はHCLを扱うのが苦手で、古いAWSプロバイダー仕様や新しく出たサービス定義に対応できないケースが多発していました。ウェブなどの情報からでは正しい一次情報をAIがピックアップできないからだと思われます。 しかし、 Terraform MCP Server や AWS MCP Servers によって正しい一次情報へアクセスした上で生成するようになるなど、以前のような課題は解決されつつあります。 これら改善により、CursorやDevinなどのAI Coding Agentを活用して、開発者が直接AWS基盤に変更や追加を加えることが現実的になってきました。とはいえギャップが大きいのも事実です。 理想のかたち：AI Enablingの実現 宣言的なインフラ変更の実現 現状では「terraformのリソース○○に○○なパラメータで追加して」のようなかなり明示的・指示的なプロンプトになりがちです。しかし理想は「○○な要件でバケットがほしい。追加して」といった 宣言的な自然言語での要求を実現 することです。 また、「〇〇な要件では〇〇への考慮が必要なので、以下の質問に答えてくれますか？」といったAIからの打ち返しを通じて、特にセキュリティ的なガードレールが満たされる実装まで開発者とAIの対話によってなされることが理想です。 開発者とAIのインタラクションの図 最終形としてこれが達成されれば、簡単な自然言語によるAWS基盤の変更がXaaS的に提供できそうです。また、変更適用までは難しくてもAWS基盤に関する壁打ち相手としてAIが提案をしてくれ、気にすべき点を開発者が適切に認知できるようになればEnablingとして機能していると言えそうです。 余談ですが 我々のチームではDevinに対してIaCの変更を依頼することが多くあります。一例として以下の画像のような、とても指示的な依頼になってしまいがちであったります。 指示的・明示的なプロンプトになる例 これをできる限り 宣言的に行える ようにすること、 AWSやTerrafromリソースに対して知識がなくても依頼できる ようにすることが目指すかたちだと言えます。 EnablingモードのAI化イメージ 例として、開発者が「○○な用途で○○したいけれどどうしたらいい？」といった質問を、従来PFEエンジニアに問い合わせていた内容をAIに対して行い、適切な回答を得られるようになります。 副次的効果として、PFEチームのエンジニア自身も当然AIに質問できるので、 PFEエンジニア間のドメイン知識のばらつき解消やSPOF防止 （Aの領域はXさんしかしらない。Bの領域はYさんしかしらない）が期待できます。 現実的な課題：コードの外側のコンテキスト 事業要件とコードのギャップ AWS基盤はほぼコード化されていますが、コード化されていること＝事業要件ではないケースが存在します。 例えば、S3バケットのセキュリティ要件は、保存するデータが個人情報かどうか、グローバル公開するかどうかなど、事業要件によって変わります。また、IAM Roleなども組織体制や運用要件によって大きく変わります。しかし、コードにはそこまでの要件が細かく記述されていることは少ないのではないでしょうか。IAM Roleであれば、どのRoleが付与されているかと追加・変更理由ぐらいまではコメントにあっても、なぜこのRoleが存在するのか、どのような使われ方をするのかについては別のドキュメント・手順書にコンテキストがあるのではないかと思います。 つまり、 コードの外側に事業や運用に関わるコンテキストが存在することが多いと考えています。 解決アプローチ：コンテキスト注入とドキュメント化 必要なドキュメント化 コードの外側にあるコンテキストをAIに理解してもらうため、例えば以下のようなドキュメント化が必要になりそうです。 サービス仕様のドキュメント化 アプリケーションの仕様 ユビキタス言語などのローカル言語定義 Devinを賢くする秘訣は「ユビキタス言語」にあり？ NotionとTerraformで実現する半自動ナレッジ更新術 実行に関わる運用ルール・実装方法・GitHubコメントの書き方などのナレッジ 気づけばDevinのナレッジが山積みに。Terraformで片づけてみた 技術仕様に応じたAWSリソースのドキュメント化 コードの外側にある情報（人間が補足する情報） 例えば、 特定のIAM Roleに付与された権限の文脈や運用ドキュメントとのリンクなど AIによるEmbeddedモード連発からの脱却 上記が達成されれば、現状Embeddedモードで人が大きく関わっている新規サブシステム構築プロジェクトでも、XaaSやEnablingのような薄い関わりで遂行できると期待されます。開発者とPFEの関わり方・分担は以下のようなイメージになれば良いと考えています。 開発者の作業フロー Devin, CursorなどのAI Coding Agentに並走してもらい、作りたいサービスのTerraformコードを生成 インフラ構築を実行 PFEチームの関わり方 コードや変更の正しさ・ガードレールが必要かなどレビューで関わる 誤りや複雑性・危険な操作の予兆を発見した場合は訂正・ガードレールの規し修正事項をドキュメントに反映する 新しい設計などコンテキストに存在しないものがあれば 一時的なEmbedded モードで並走 開発者・PFE・AI・ドキュメントの相関の絵 PFEの役割 先の絵を見るとHCLの記述やIaC・クラウドインフラのメンテナンスはAIによって行われることがより効率的であるという未来が見えます。その時、 我々PFEは何を責務とすべき なのでしょうか。 絵を見ると、 コード外のコンテキスト・ドキュメントを充実させること にあるかもしれません。大まかなイメージではありますが 日々の開発・運用・ビジネス変化を観測・メトリクス/KPIの計測から問題を発見する 問題を解決するための議論・必要に応じてルールメイキングを行う 解決策・ルールをドキュメントに反映してAIが正しい出力をできるようにする 言うなれば、ビジネスを観測し経験などに基づいて課題抽出を正しく行ったり、目まぐるしく変わる優先順位を整理して、 AIに"気持ちよく"仕事をしてもらう ために必要な情報やルールメイキングをドキュメントに反映したり、 "お願い"することが仕事 になるかもしれません。なんだか、エンジニアリングマネージャーっぽいですね。 この話のまとめ 新システム開発のようなEmbeddedモードでなければならないケースが連発するとPFEのスケーリングが事業ボトルネックになるリスクがある リソースが限られるのでEmbeddedの連発は不可能。しかしながら、AIによってEnabling + 最小限のEmbeddedで事業のスケーリングに対応できるプラットフォームエンジニアリングができるのではないか、と、現在は"妄想"段階 コードに表現されていない様々な要件をAIに与える必要があり、ドキュメント化や入力方法を工夫してAI Coding Agentに正しい出力をしてもらうことが鍵になりそう。AIに気持ちよく仕事をしてもらう工夫をすることに労力を費やすことになるかもしれない。 最後に 既に弊社の他の方々がブログに取り組みを書いているように、先の取り組みが始まりつつある状態です。また、AI Coding Agent界隈の変化が激しく1〜2週間でも目まぐるしく注目の話題が生まれてくる状況にあります。（2025年6月現在） 変化によってやり方が全く変わる可能性がありますが、2〜3ヶ月後にはある程度の目処が見えてくるのではないかと思います。過去半年のAI Coding Agentの発達を思えば、今年中にはさらに大きな発展をしている期待感もあります。 不確実なことが多い取り組みではありますが、もし達成できればPFEがビジネス上のボトルネックになるリスクを回避できる、少ない人数で最大のアウトカムを得るチャンスだと思うので、力を入れて取り組んでいきたいと思います。 長い文章になりましたが、最後まで読んでいただいてありがとうございました。

読んで欲しいと思っている人 スクラムイベントがうまくいかない感じがして困っている方 スクラムイベントをもっと良くしたいと思っている方 読むとわかること スクラムイベントを改善するための1つのアイデア スクラムイベントは互いにインプットとアウトプットとなりながら循環していること スクラムを改善したい時はシステム思考を勉強するとちょっと助けになること はじめに バックエンドエンジニアを務めている @Juju_62q です。スクラムでのロールとしては「開発者」を務めています。突然ですが質問です。 スクラムイベントがうまく改善できないという経験はありませんか？ 例えば「スプリントプランニングが時間内に終わらない」という問題があるとします。この時にスプリントプランニングで効率的に意思決定を行うための実験を開始してもどうにもうまく問題が解決していかないことがあります。時間内に収めるために強引な意思決定手法を導入することもできますが、それだと開発者のコミットメントをうまく引き出せないこともしばしばあります。 こういった時に自分が気をつけていることの1つを紹介させていただければと思います。 スクラムイベントが何かうまくいかないと感じている方はスクラムをやめる前にぜひ考えてみて欲しいです。 結論 まず結論から紹介させてください。 スクラムイベントがうまくいっていない時は、大抵の場合別のイベント等に原因があります。要は準備やインプットが足りていません。事前条件が整っていないがゆえにチームメンバーがそれぞれ別のことを志向して意思決定がしにくかったり、不確定要素が多くてコミットメントがしにくいという現象が発生します。 それぞれのイベントがうまくいかない場合に対応して改善を試みるイベントとして自分は下記を意識しています。 うまくいかないイベント 改善を試みるイベント スプリントプランニング リファインメント、スプリントレビュー スプリントレビュー スプリントプランニング、リファインメント スプリントレトロスペクティブ スプリントプランニング、スプリント（スプリント中の活動全般） デイリースクラム スプリントプランニング スクラムイベントではありませんが、リファインメントがうまくいかない場合は大抵プロダクトゴール周辺に問題があります。 スクラムイベントは相互に関連している スクラムガイドではスクラムイベント一つひとつの解説が載っています。しかし、それぞれのイベントは独立して存在しているわけではありません。それらはスクラムイベントのインプットとアウトプットを通じて、互いに深く関連し、循環的なフィードバックループを形成しています。 スクラムイベントを個別の事柄として捉えるのではなく、相互にインプットとアウトプットを持つシステムとして理解することが、スクラムイベントを効果的に改善する鍵となります。この循環がうまく機能しない時にスクラムイベントは機能不全に陥ります。したがって、スクラムイベントの改善を試みる際にはそのイベントが何に依存しているのかを考えることが重要です。 具体的に考えてみましょう。 スプリントプランニングがうまくいかない時 例として「スプリントプランニングが時間内に終わらない」という問題を考えてみます。時間内に終わらない原因のほとんどはチームでの意思決定がうまくできないからでしょう。 ここで、過去の自分のチームでは「どうしたらいろんな意見がある中で1つの意見にまとめられるか」という観点で実験を実施していました。例えば「スプリントプランニングで意見が割れたら最終的にはプロダクトオーナーが決める」というアイデアを採用した場合「スプリントプランニングが時間内に終わらない」という課題は解決できそうです。 しかしながらこのアイデア、実はあまり賢明ではありません。なぜかというとうまくいかなかった場合に、チームで原因を究明し改善するのが困難であるためです。この意思決定方法でスプリントに問題があった場合、レトロスペクティブでは何を振り返るのかを考えるとわかりやすいです。プロダクトオーナーの意思決定が原因だとすれば、責任を特定するのは容易ですが、チームとしての学びにはつながりにくいです。チーム全体で問題に向き合う機会が失われ、根本的な改善が見送られてしまうことになります。 一方で「なぜ意思決定ができないのか」という問いを立てると別の解決策が見えてきます。スプリントプランニングでの意思決定が滞る主な原因として、プロダクトバックログアイテム（PBI）が「生煮え」の状態であることや、チームメンバー間でプロダクトや開発の方向性に対する「目線が揃っていない」という状況が挙げられます。例えば、PBIの目的や詳細が曖昧であれば、開発者は具体的な計画を立てにくく、コミットメントも困難になります。また、チームが共通のゴールを明確に認識していなければ、どのPBIから着手するのが良いのか、プロダクトゴール達成のためのアプローチについて意見が分かれやすくなります。 これらの課題は、スプリントプランニングよりも前の段階、すなわちリファインメントが適切に行われていない、あるいはスプリントレビューで顧客から良いフィードバックが得られていないことに起因している可能性が高いです。スプリントプランニングに必要なインプットが不足しているために、その場で多くの議論が必要となり、結果として時間超過につながっています。自分のチームではそれまで任意参加だったリファインメントを必須参加とすることでプランニング時点での疑問を抑制し、スムーズに進めることができました。最適な対応かはわからないですが、スプリントプランニングの問題を解決するためにはリファインメントを改善する必要があるという一例だと考えています。 このブログを書いたきっかけ これまでスクラムチームで開発者として活動する中で、上記のような「スクラムイベントがうまくいかない」という課題にしばしば直面してきました。当時の自分は考え方として「とにかく問題を小さくして対策を試みる」というのが癖になっていました。これを続けてもどうもうまく問題が解決していきませんでした。今思えば、この考え方はスクラムイベントが相互に関連していて互いが互いのインプットであり、アウトプットになっていることを無視していたのだろうと思います。ある時チームのスクラムマスターからひとつ前の段階の改善を提案されて実施したところ驚くほど上手に問題が解決したことをよく覚えています。 この経験を通じて、スクラムイベントは単独で存在するのではなく、インプットとアウトプットで繋がれた一つのシステムとして捉えることの重要性を強く感じました。この視点を持つことで、問題の原因を見つけやすくなり対症療法でない対策を講じることができるようになりました。 この考え方は、システム思考と呼ばれています。もしスクラムをやっていて何か改善が行き詰まっている方がいればぜひ一冊で良いので本を読んでみてください。自分が読んだ書籍を一冊紹介しておきます。 https://www.amazon.co.jp/dp/B00SUT1ODK 終わりに もし今、あなたのチームのスクラムイベントが何らかの課題を抱えているのであれば、ぜひ一度、そのイベント単体を見るのではなく、「そのイベントへのインプットは何だったか？」「そのインプットは適切だったか？」 というシステム的な視点で振り返ってみてください。 もしかしたら問題の根本は、あなたのチームが普段意識していないような少し前のフェーズに潜んでいるかもしれません。「相互依存関係」という視点を取り入れて、改めてスクラムの改善に取り組んでみるのもおすすめです。

タイミーでバックエンドのテックリードをしている新谷（ @euglena1215 ）です。 タイミーでは自律型 AI エージェント Devin を活用した開発を行っています。 Devin を効果的に活用する上で鍵となるのが、どのような「knowledge（知識）」を与えるかです。Devin を活用している各社で、試行錯誤が進められているのではないでしょうか。 もし Devin に一つだけ知識を与えて賢くするとしたら、何が最適でしょうか？ 私は「会社固有の知識であり、かつ社員にとっては当たり前すぎて、AIに教えるという発想に至らない情報」が、AIの精度を向上させる鍵になるのではないかと考えています。 　 社員は知っているが Devin は知らない、そんな情報の代表格として思いついたのが「ユビキタス言語」です。実際に Devin にユビキタス言語を knowledge として教えてみたところ、抽象的な概念に対する理解度が向上する手応えがあったため、その TIPS を共有します。 また、Devin に教えるユビキタス言語が古くなっては逆効果です。そこで、ユビキタス言語の knowledge を半自動で更新する仕組みも作ってみたので、合わせて紹介したいと思います。 前提 私たちタイミーの環境における、2つの重要な前提について説明します。 1. Notion DBによるユビキタス言語の管理 タイミーでは、ユビキタス言語を Notion のデータベースで一元管理し、常に最新の状態に保つワークフローが確立されています。このデータベースには、以下の情報が含まれています。 表現（事業者向け）： 企業向けの表現。企業向けとワーカー向けで指すものが同じでも表現が異なることがあるため分けています。 （例：求人を公開） 表現（ワーカー向け）： ワーカー向けの表現。（例：募集を公開） 意味： 用語の意味 NG表現： 誤って使われやすい用語例 実装の英語表記： 用語に対応する実装上のキーワード 備考： 用語を使用する際の注意事項 こちらに関して詳しく知りたい方は以下の記事をご覧ください。 note.com 2. TerraformによるDevin knowledgeの管理 次に、タイミーでは Devin の knowledge を Terraform で管理しています。 以下のような Terraform ファイルを記述することで、knowledge を登録できます。 resource " devin_knowledge " " this_is_knowledge_1 " { body = << EOT Pull Requestの説明には、.github /PULL_REQUEST_TEMPLATE .md のテンプレートをベースとして使用してください。 このテンプレートは、このリポジトリのすべてのPull Requestで使用する必要があります。 EOT name = " PR作成時のテンプレート利用 " parent_folder_id = data.devin_folder.this_is_folder_name.id trigger_description = " foo リポジトリで Pull Request を作成する場合 " } こちらに関して詳しく知りたい方は、以下の記事をご覧ください。 tech.timee.co.jp 実装 運用されているユビキタス言語の Notion DB と Devin の knowledge を Terraform で管理する仕組みが整備されているので、あとはそれらをつなぎこむだけです。 今回 Notion DB を CSV Export し、Terraform ファイルとして出力する Shell スクリプトを用意しました。 Shell スクリプトを生成するプロンプトは以下です。参考にしてみてください。 ユビキタス言語CSVからDevin KnowledgeのTerraformファイルを生成するスクリプト === 生成プロンプト === 以下の要件でユビキタス言語データベース（CSV）からDevin knowledgeのTerraformファイルを 自動生成するBashスクリプトを作成してください: 【目的】 - CSVに定義されたユビキタス言語をDevin Knowledgeに変換 - Devinが「お仕事リクエスト」→「offeringRequest」のような用語対応を理解できるようにする - 用語について質問された際に適切な検索指示を提供するナレッジベースを構築 【CSVファイル構造】 - ファイルパス: source/ubiquitous.csv - 列構成: 事業者向け表現, ワーカー向け表現, 意味・定義, 避けるべき表現, 実装上の英語表記, 備考 - 文字エンコーディング: UTF-8 - 引用符内の改行やカンマを含むデータあり（CSVパーサーで適切に処理が必要） 【処理要件】 1. CSVパーサー: Rubyの標準CSVライブラリを使用（引用符内改行問題を解決済み） 2. フィルタリング: 意味・定義がある全エントリを処理対象（実装向け表記の有無は問わない） 3. primary_expr決定: 事業者向け表現 → ワーカー向け表現 → "用語N" の優先順位 4. カウンター管理: 正しいインクリメントでリソース名重複を防止 5. 動的トリガー生成: 実装向け表記の有無でトリガー記述を分岐 【ナレッジ内容構造】 - タイトル: 「ユビキタス言語「XX」の用語対応ガイド:」（検索指示中心） - 【用語の定義】: 意味・定義の内容 - 【実装・開発時の検索キーワード】: * 実装向け表記がある場合: 「コードや実装: 「XX」」 * 事業者向け・ワーカー向け表現も追加 * 実装向け表記がない場合: 「概念・ドキュメント用語として使用」を追加 - 【避けるべき表現】: 避けるべき表現がある場合のみ - 【使用ガイダンス】: 実用的な使用方法の3項目リスト - 【補足情報】: 備考がある場合のみ 【トリガー記述】 - 実装向け表記あり: 「「XX」やその関連用語（YY等）に関する質問、実装、ドキュメント作成を行う場合」 - 実装向け表記なし: 「「XX」に関する質問やドキュメント作成を行う場合」 【出力ファイル】 - パス: envs/knowledge/ubiquitous_language.tf - 自動生成ヘッダー付き - terraform fmt で自動フォーマット - data.devin_folder.ubiquitous_language.id 参照（data.tfで定義済み） 【エラーハンドリング】 - CSVファイル存在チェック - 一時ファイル管理（trap使用） - 処理結果の統計表示 === 生成プロンプト終了 === 上記によって生成した Shell スクリプトを実行すると、以下のような Terraform リソースが作成されます。 resource " devin_knowledge " " ubiquitous_language_53 " { body = << EOT ユビキタス言語「グループ限定公開」の用語対応ガイド : 【用語の定義】 グループ機能で作成したグループに所属する、特定のワーカーのみに求人を公開する機能 【実装・開発時の検索キーワード】 - コードや実装 : 「limited」 - 事業者向け文書 : 「グループ限定公開」 【使用ガイダンス】 この用語やその関連概念について質問・実装・ドキュメント作成を行う際は： 1 . 上記の適切なキーワードで検索してください 2 . 文脈に応じて事業者向け・ワーカー向け・実装用の表現を使い分けてください 3 . 避けるべき表現は使用しないでください EOT name = " ユビキタス言語: グループ限定公開 " parent_folder_id = data.devin_folder.ubiquitous_language.id trigger_description = " 「グループ限定公開」やその関連用語（limited等）に関する質問、実装、ドキュメント作成を行う場合 " } 更新手順 更新ステップは以下の通りです。 Notion DB を CSV としてエクスポートし、Terraform を管理しているリポジトリに配置 CSV から tf ファイルを生成する Shell スクリプトを実行し、Pull Request を作成 terraform plan & apply を実行 現状は手動での CSV エクスポートが必要ですが、 Notion API・MCP などを活用すれば、この更新フローの完全自動化も可能だと考えています。 Devin がどのように賢くなったか このナレッジを与えたことで、Devin の振る舞いにどのような変化があったかを見ていきましょう。 まず、Devin が knowledge を適切に参照できているかを確認します。 Devin スクリーンショット 確認した結果、数あるユビキタス言語の中から、本当に関連するユビキタス言語のみを参照することに成功していました 🎉 　 次に、質問に対する回答の精度を比較します。上記のスクリーンショットにあるように、「“limited”という単語は何を意味しますか？」と質問してみました。 【ユビキタス言語 knowledge なしの場合】 「limited」は 求人の公開範囲を制限する包括的な機能 を表します。 【ユビキタス言語 knowledge ありの場合】 「limited」は求人の 限定公開機能 を指し、特定の条件を満たしたワーカーのみに求人を表示する仕組みです。 どちらも内容は似ていますが、 よりタイミーの社員らしい、解像度の高い回答になったのは「ユビキタス言語あり」のパターンだと感じました。 ナレッジがない場合、Devin はコードベースを広範囲に検索・抽象化して回答を生成するためか、少し曖昧な表現に留まっています。一方、ナレッジを与えた後は、 私たちが定義した「意味」に沿って、より的確な言葉で回答できるようになりました。 最後に 生成 AI ツールの進化によって、これまでチームの暗黙知とされてきたものを、いかに形式知として AI に与えていくかが、これまで以上に重要になってきています。 タイミーのエンジニアリング組織はフルリモートという特性もあり、以前からドキュメント化の文化が根付いています。今回の取り組みは、その文化をさらに一歩進めるものになりました。 これからも、AI との協業を前提とした開発体制の構築を進めていきたいと思います。

はじめに タイミーでPlatform Engineerをしている 徳富(@ yannKazu1 )です。 2025年2月、私たちの開発組織にAIエージェント「Devin」が導入されました。 Devinは、機能開発のサポートやテストケースの提案など、日々の開発に自然と溶け込む形で活躍してくれていて、今では月に数十〜数百件のマージに関わる頼もしい存在になっています（2025年4月17日時点で489件マージ！）。 そんなDevinと一緒に開発を進めるなかで、ある悩みが浮かび上がってきました。それが「ナレッジの管理が難しくなってきた」ということです。 ナレッジが増えてうれしい、でも…… Devinには「ナレッジ」と呼ばれる、ルールや指針のような情報を登録する機能があります。 「こういうときはこう書く」「こう判断する」など、チームの経験や判断基準をDevinに覚えてもらうことで、より実用的な回答を得ることができます。 ですが、チーム内のいろんなメンバーがナレッジを追加するようになると、次第にこんな状況が生まれてきました： どのナレッジが誰の意図で変更されたのかわからない 重複したり矛盾した内容が出てきてしまう Devinの提案にブレが出るようになった このままだと、Devinの力を活かしきれない。そう感じた私たちは「ナレッジにもレビューと履歴の管理が必要だ」と考えるようになりました。 Terraformで「Knowledge as Code」を実現してみる インフラをコードで管理する「Infrastructure as Code（IaC）」のように、ナレッジもコードで管理できたらどうだろう？ そうしてたどり着いたのが、 「Knowledge as Code」 というアプローチでした。 Terraformを使えば、ナレッジの追加・変更・削除をコードとして記述でき、次のような良いことがあります： Gitで履歴が追える ：誰がどんな意図で変更したかを残せる Pull Requestでレビューできる ：ナレッジにブレが出るのを防げる terraform plan で差分が見える ：意図しない変更に気づける 他のAIエージェントに移行しても再利用しやすい 「これならナレッジの質も保てるし、チーム全体での共有もしやすくなるはず」——そんな期待を込めて、Terraformによる管理に挑戦することにしました。 でも、Terraform Providerがない……！ とはいえ、Terraformで管理するには専用のProviderが必要です。 調べてみたところ、Devin用のTerraform Providerは世の中に存在していませんでした。 そこで、私は思いました。「それなら、作ってみよう」 Devin Terraform Provider を作ってみた 自作したTerraform Providerでは、以下のような操作が可能です： 👉 Devin Terraform Provider — Terraform Registry Devinへのナレッジの作成・更新・削除 （ devin_knowledge リソース） フォルダー一覧の取得 （ data "devin_folders" ） 既存ナレッジの参照 （ data "devin_knowledge" ） ナレッジの作成 resource "devin_knowledge" "example" { name = "Example Knowledge" body = "This is an example knowledge resource." trigger_description = "Use this knowledge when talking about examples." parent_folder_id = "optional-folder-id" } フォルダー一覧の取得 data "devin_folders" "example" { name = "example" } ナレッジの参照 data "devin_knowledge" "existing" { name = "Example Knowledge" } これにより、ナレッジの変更内容をコードで管理しつつ、レビューを通して安心して運用できるようになりました。 これからのこと Terraformでのナレッジ管理は、私たちにとってとても大きな一歩でした。 でも、それは「Devinの管理がしやすくなった」だけの話ではありません。 私たちは今、AIエージェントが自然とチームにいる時代に生きています。 そのなかで、単なる効率化ではなく「人とAIが一緒に考え、一緒に働く」開発のあり方をどう作っていくかが重要だと感じています。 タイミーでは日頃から、Notion上にユビキタス言語やチームごとのナレッジが丁寧にまとめられており、ドキュメンテーションの文化が根付いています。 こうした文化があるからこそ、今回のような取り組みも自然な流れとして始められましたし、ナレッジを「コードとして残す」ことにもチーム全体で前向きに取り組むことができました。 これからの開発の現場では、Devinだけでなく、Jules、Cursor、Copilotといった様々なツールが活躍するようになるかもしれません。 そうした多様なAIと気持ちよく協力していくために、私たちは次のような基盤づくりを進めていきたいと思っています： Devin以外のAIでも参照できる、再利用しやすいドキュメントとその自動更新の仕組みを整える ナレッジを「読み物」ではなく「役立つデータ」として整理し、どのエージェントでも活用できるようにする 「Knowledge as Code」から「Project as Code」へと視野を広げる スプリントの運用方法、CI/CDの流れ、ドキュメントの構成や技術方針までをコードで一元管理し AIがそれらを理解した上で、プロジェクトの流れに沿った提案をしてくれるような世界へ 全社的にナレッジを育てていける運用の仕組みを整える 各チームがそれぞれルールを持つのではなく、共通のガイドラインと形式で蓄積・再利用できるようにし 自動化と人のレビューをうまく組み合わせて、 スピード感と品質の両立 を目指す こうした取り組みを通じて、ただAIを活用するだけでなく、 チームの一員としてAIと一緒に働ける環境 を整えていきたいと考えています。

2025年4月16日から18日の3日間 、 愛媛県松山市 にて、RubyKaigi 2025 が開催されました。 https://rubykaigi.org/2025/ タイミーでは、昨年に続き、世界中で開催される技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度を活用し、 新卒内定者やインターン生を含む総勢16名 が現地でカンファレンスに参加しました。 この記事では、現地参加した各エンジニアの印象に残ったセッションとその感想をまとめてお届けします。 今回はその第4回で、Day3の内容をまとめています。 Day1, Day2のセッションに関する内容についてもぜひ合わせてお読みください！ tech.timee.co.jp tech.timee.co.jp tech.timee.co.jp 各セッションごとに内容を整理し、参加者自身の視点から学びや気づきをまとめています。読者の皆様にとって、今後の学びの参考になれば幸いです。 On-the-fly Suggestions of Rewriting Method Deprecations 発表 rubykaigi.org speakerdeck.com 概要 deprecated への対応は開発者にとって時間と手間がかかる作業であり、本来の開発から注意を逸らします。ドキュメントの作成や警告表示、静的解析ツールなどを用いた既存の対応策には限界があり、特に Ruby のような動的型付け言語では、静的解析による検知や修正には過不足が生じてしまいます。そこでコードの実行時に自動書き換えまで行うアプローチを提唱し、それを実現するため deprewriter-ruby Gem を開発したという発表でした。これは deprecated なメソッド呼び出しを検知して、規定したルールに則って上書きをするというもので、ライブラリ開発者が非推奨化するメソッドに「どのように書き換えるべきか」という変換ルールを定義することで、利用者がテストなどでそのメソッドを呼び出すと、Gemが変換ルールに則り自動で書き換えてくれるようになります。 gem の説明の中ではメソッド呼び出しのインターセプト、呼び出し元情報の取得（caller_locations）、ソースコード解析（Prism/SyntaxTree）、AST変換（Synvertベース）、ファイル書き換え/差分出力といった技術要素を解説してくださいました。また、ファイルを直接上書きするだけではなく、ログ出力モード、差分（パッチ）出力モード、直接書き換えモード（主にテスト環境向け）を提供しているそうです。 この gem は各言語の deprecation の対応状況を調べていく中で、Pharo言語の自動リファクタリング機能に影響を受けて開発されました。 Pharo での deprecated なメソッドの置き換え等は Deprewriter と呼ばれていますが、それを Ruby でも実装してみて、実際にどのように利用できるか、動くのかを紹介してくださいました。 将来的には、 Ruby エコシステム全体で非推奨対応の負担を軽減し、開発者がより本質的な作業に集中できる環境を目指したいというビジョンを示してくださいました。 感想 メソッドの Deprecation（非推奨化）に関して、ドキュメントを参照しながら開発の過程で修正していくというプロセスは、自分にとってあまりに当たり前なものでした。本番環境で実際に適用するかどうかはさておき、実行中にそれらが自動で修正されるという体験は、自分にとって非常に斬新かつ素晴らしい開発者体験だと感じ、プログラミング言語にはまだまだ進化の余地があるのだと改めて実感できました。何らかのアップデートに伴いCIが実行され、差分があった場合に別途PR（Pull Request）が作成されるという状況は、開発者体験を大きく向上させそうです。また、言語やライブラリの開発者にとっても、互換性の問題を発生させにくい優れた仕組みだと感じています。最近論文を読んでいないことも思い出したので、自分も改めて論文を読み直してみたいと思います。 （ @Juju_62q ） Rails などの著名なライブラリに対して RuboCop がいわば「肩代わりして」行っているようなことを、ライブラリ自身の責任で行えるようになるというのは、ライブラリ開発者としても理想的な機能ではないでしょうか。とはいえ、実際のコードでよく起こりうる「同じメソッド名で挙動が異なる」という場合（例えば引数のキー名が変わったなど）は、「現在どのような状態なのか」の判定が難しいため、うまく実現するのは大変そうだという予感がします。今後の発展に期待しています。 （ @masarakki ） 非推奨メソッドへの対応は、特に Rails のバージョンアップの際に度々発生します。その度にリリースノートを読み込み、ソースコードの差分を確認して対応しますが、コストのかかる作業だと常々感じており、そのような状況下でこの発表を聞き、自動で修正されるというアプローチに感銘を受けました。 この Gem は、ライブラリの利用者にとっては夢のような機能を提供する一方で、利用者が便利になるためのコストをライブラリ作成者に強いる設計だと思います。これは RBS にも言えることですが、こういった設計の機能が広く浸透するには時間がかかるでしょう。浸透させるためには、この Gem を利用するユーザーが増え、よりスタンダードな機能にしていくことが重要ですが、そう簡単ではないだろうとも感じました。 個人的には是非とも普及してほしい Gem だと思うので、自分でライブラリを作成する際や、deprecation の自動修正に共感してくれるライブラリを見つけた際には、積極的に活用していきたいと思いました。 （@rhiroe） Matz Keynote - Programming Language for AI age（Day3） 発表 rubykaigi.org 概要 毎年恒例の Matz による Closing Keynote です。今年は「AIとプログラミング言語」をテーマに、言語デザイナーの視点からプログラミング言語について論じられました。 犬における「アルファシンドローム」（ペットが自分がリーダーだと勘違いする現象）を紹介し、それを AI に当てはめ、「逆アルファシンドローム」という概念を提唱しました。これは、人間が AI のできない「面倒な」あるいは「望ましくない」タスクのみを担当し、AI ができる（そして人間にとって楽しいかもしれない創造的な）部分を AI に任せてしまうことで、人間が AI に従属してしまう危険性を指摘するものです。全体を通して、人間が主人であり続け、AI は奉仕者であるべきとし、プログラミングの楽しさや主導権を失わないために、どのタスクを AI に委任するかを意識的に選択する必要があると主張していました。 AI 時代に望ましい言語の特性として「簡潔さ（Conciseness）」「表現力（Expressiveness）」「拡張性（Extensibility）」の3点を挙げ、Ruby が全てを満たしている素晴らしい言語だとしました。AI 時代にはプログラミング言語ではなく、人間の話す自然言語が最適なのではないか、という可能性については、数式を例に挙げ、自然言語は形式言語に比べて正確性に限界があることにも触れました。 近年話題の静的型付けについて、不可欠かどうかについては疑問を呈し、役立つ場面もあるが、第一に必要なものではないかもしれず、過度に複雑なシステムは簡潔さや楽しさを損なう可能性があると指摘しました。 またセッションの最後に、今年は Ruby 4.0 がリリースされる（かもしれない）というサプライズもありました。 感想 今回の RubyKaigi では AI の話題がほとんどなかったなと思っていたところ、最後に Matz が話してくださいました。タイトルは「Programming Language for AI age（ AI 時代のプログラミング言語）」（「Programming Language for AI（ AI のためのプログラミング言語）」ではない点がポイント）。これは Matz にしか語れない内容だ！と、わくわくしながら聞いていました。途中、いつもの「静的型付き言語 vs 動的型付き言語」の話になっていったのも、風物詩の趣があり良かったです。 さて、Matz によれば AI 時代に求められるプログラミング言語とは「Concise, Expressive and Extendible」、つまり簡潔で表現力が高く、拡張しやすい言語であるべきだと。それは、つまり Ruby のことだ、というオチでした。 また、本題の前に語られていた「人間（プログラマ）と AI の関係」の話も非常に印象的でした。主従関係としては人間が主人であり、人間が AI に従うべきではないという考えです。この考え方は過去にも語られており、当時は「コンピュータ」だったものが、今回は「AI」に置き換わっている形です。何にせよ、主役は人間であるということを改めて再確認しました。AI を使えば色々便利になり、あれもこれも置き換えられると考えていた自分としては、ハッとする内容でした。 （ @sugaishun ） 途中、「AI 支援を使っている人は挙手してください」という質問があり、半数くらいが手を上げていました。これは個人的には想像以上に多いという印象です。 Ruby は「たのしい」を重視している言語なので、我々ユーザーも「たのしい」から Ruby を選んでいて、それほど AI 支援に興味を持っていないのではないかと思っていたからです。（AI に仕事を奪われるのはもう仕方ないとしても、AI に「たのしい」ことを奪われるのは我慢ならないですよね。） 「人間が主人、AI が従者」という主張も、それが成り立つのは「Ruby がたのしい」という前提があってのことだと思います。AI の利用が拡大することで「たのしい」の価値や意味が無くなってしまうのではないかと危惧しています。 （ @masarakki ） AI のサポートはこれまでそれなりに試しましたが、「よくある機能の作成」や「簡単な雑務」、「実装からテストの作成」くらいしかまともに使えていません。個人的には「要求から要件と仕様を作る」、「仕様からテストを作る」部分を AI でできるようになれば嬉しいなぁと思いつつ、普段の業務では自分がテストを書くしかない状況で、世の中の「AI すごい!!」みたいな空気に若干違和感がありました。 今回の話の中で、AI は奉仕者に過ぎず人間がプログラミングの楽しい部分を担うべきだという話には、共感しかありませんでした。自分にとって楽しい部分は「設計」と「実装」なので、その部分は自分でやりつつ、その他を AI がやってくれる未来がやってくると嬉しいなぁと思いながら聞いていました。 一方で、AI を駆使した方が工数やコストを削減できるという話もちらほら聞くことがあり、その影響で AI にできる部分を AI にやらせ、AI ができないことを人間がする、まさにこの話の中での逆アルファシンドロームが実現された未来がやってくる可能性もないとは言えません。そうならないためにも全てのプログラマには、人間が主導権を持つための AI に委任する作業の選択を意識的に行うようにしてほしいなと切に願います。 （@rhiroe） The Ruby One-Binary Tool, Enhanced with Kompo 発表 rubykaigi.org speakerdeck.com 概要 Kompo というツールを開発されている @ahogappa さんによる発表です。 Ruby のプログラムをワンバイナリにまとめるためのツール「Kompo」の開発とその進捗についての発表でした。 以前の発表（RubyKaigi 2024）時点では、 require をオーバーライドして必要な Ruby スクリプトやライブラリを実行ファイルに埋め込む方式でしたが、Sinatra と SQLite 程度の規模のアプリケーションでしか動作しないという課題がありました。 今回の発表では、仮想ファイルシステムを構築することで以前の課題を解決し、Rails アプリケーションのワンバイナリ化に成功したことが報告されました。 感想 Ruby で実装したゲームをクロスプラットフォームで配布したいという背景から Kompo の実装を始めたとのことで、2日目に発表された「How to make the Groovebox」と同様に自身の趣味と結びついたセッションでした。 Kompo に関しては今回の発表で初めて知りましたが、Rails で作られたアプリケーションをワンバイナリにできるという発想がなく、単純に驚きました。 この技術が発展することで、Ruby のアプリケーションがより手軽に、より多くの環境で利用できるようになり、Ruby の発展に繋がりそうだと思いました。 クロスプラットフォーム化の部分に関してはまだ達成されていないとのことでしたので、今後の進展に期待しています。 （@Keisuke Kuwahara） Analyzing Ruby Code in IRB 発表 rubykaigi.org drive.google.com 概要 2024年から Ruby Committer となった @tompng さんによる、IRB における「解析」に関する発表でした。IRB の内部動作において、特にシンタックスハイライト、オートインデント、コード補完、コードの終了判定といった機能は、これまで主に Ripper というツールを使用して実装されてきました。それを、Ruby のパーサーである Prism への移行を進めることで、これらの機能の精度と堅牢性向上を図っているという内容でした。また、IRB でエッジケース的な “weird-code”（奇妙なコード）を受け取った際の挙動が、具体的な事例を交えて紹介されていました。 感想 普段何気なく自分が使用している IRB の奥深さ、シンプルなインターフェースの奥底にある課題に触れることができました。本セッションに限らず RubyKaigi ではパーサーにフォーカスした内容が多く、個人的に好きなテーマです。 def を入力するとハイライトされる、 end を入力するとオートインデントされるといった基本的な動作すら誰かがメンテナンスしてくれているんだな…と改めて感慨深い気持ちになったと共に、表現力が高く奇妙な構文を書ける Ruby ならではの様々な入力ケースが披露され、苦悩の歴史が垣間見えました。特に Nesting Analysis（ネスト解析）の内容に入ってからは「こんなコードも想定しなきゃいけないの？」と勝手に絶望的な気持ちになりながら見ていました。Prism への本格移行の道のりはまだまだ長いと思いますが、従来のトークンベース解析に比べて、AST（抽象構文木）ベースの Prism を使えば、IRB が担っていた独自の構文解析を委譲できる点が魅力的だと感じました。Ruby における楽しみがまた一つ増えた感覚があり、今後の RubyKaigi でも動向をウォッチしていきたいと思います。 （ @edy629s ） 終わりに さて、本ブログにてタイミーによる RubyKaigi 2025 の参加レポートも終了となります。Day1やDay2に関してもブログを書いているのでよろしければそちらも併せてご覧ください。 今後も Ruby を利用する会社の一員としていろんな発信、貢献をしていけたらと考えているので、今後お会いした際にぜひ一緒にお話ができると嬉しいです！それではまた来年函館でお会いしましょう！

2025年4月16日から18日の3日間 、 愛媛県松山市 にて、RubyKaigi 2025が開催されました。 rubykaigi.org タイミーでは、昨年に続き、世界中で開催される技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度を活用し、 新卒内定者やインターン生を含む総勢16名 が現地でカンファレンスに参加しました。 この記事では、現地参加した各エンジニアの印象に残ったセッションとその感想をまとめてお届けします。 今回はその第3回で、 前回 に引き続きDay2の内容をまとめています。Day3のレポートも近日中に公開予定です。 読者の皆様にとって、今後の学びの参考になれば幸いです。 Day2開始前の様子。緞帳の絵柄は毎日変化していてちょっとした楽しみでした。 RuboCop: Modularity and AST Insights rubykaigi.org 概要 セッションでは、主に以下の 3 つの主要なテーマについて掘り下げられました : Ruby LSP Add-on : Ruby Language Server Protocol (LSP) のアドオン機能に関する議論がなされました。Shopify製のruby-lspをRails開発コンテナで使用している現状を踏まえ 、RuboCop、StandardRuby、Ruby LSPがそれぞれ独自のLSP実装を持っている非効率性を指摘し 、RuboCopのLSPランタイムの統一が提案されました。Ruby-LSPのAdd-on機能を利用し、RuboCopの組み込みLSPランタイムを再利用する実験的な試みが紹介されました。これにより、複数の開発ツールと連携するRuby LSPの利点を活かしつつ、各ツールでのコード解析の重複を避けることが期待されます。 Plugin System : RuboCopのプラグインシステムの刷新について詳細な説明がありました。従来、非公式なモンキーパッチである "Inject" ハックが拡張機能の事実上の標準となっていましたが、設定の衝突やロード順序による不整合などの問題点がありました。この課題を解決するため、公式の拡張APIとなりうるプラグインシステムがRuboCop 1.28で導入されました。この新しいプラグインシステムは、Linterプラグインの仕様に基づいており、安定した抽象インターフェースを提供し、RuboCop内部で設定を管理します。プラグインの利用者と開発者向けに、具体的な移行方法や実装方法が解説されました。 AST Insights : Abstract Syntax Tree (AST) に関する洞察として、特にParser gemとPrismという2つのRubyパーサーに焦点が当てられました。メンテナンスの課題を抱えるParser gem に対し、Shopifyが開発するPrismがより将来性のあるパーサーとして紹介されました。RuboCop 1.27からPrismをオプションのバックエンドとして利用可能であり、RuboCop 1.28以降では Ruby 3.4以降のデフォルトパーサーとしてPrismの変換レイヤーを使用することで、構文の互換性を確保し、メンテナンスコストを削減しています。PrismのASTを直接利用することの利点と課題についても議論されました 。 全体として、このセッションは、RuboCopの拡張性とRubyエコシステムとの連携を強化するための重要なアップデートと、Rubyコード解析の基盤となるASTパーサーの進化について、最新の情報と将来の展望を提供するものでした。 感想 今回のセッションは、RuboCopが単なるコードフォーマッター、リンターから、より広範な Ruby開発エコシステムの中核となるツールへと進化しようとしている意欲を感じさせる内容でした。 特に印象的だったのは、 公式のプラグインシステムの導入 です。これまで、サードパーティの拡張機能は "Inject" ハックという、やや不安定で保守性の低い方法に依存していたため、今回の刷新はRuboCopのエコシステム全体の健全性を高める上で非常に大きな進歩と言えるでしょう。プラグイン開発者にとっては、より安定したAPIを利用できることはもちろん、設定管理がRuboCop側で統合されることで、より本質的なCopの開発に集中できるようになるのではないでしょうか。 また、 Ruby LSPとの連携 も注目すべき点です。異なるツールが個別にLSP機能を持つのではなく、RuboCopの持つ強力な解析能力をRuby LSP経由で他のエディタやIDEでも活用できるようになることは、開発者体験の向上に大きく貢献すると感じました。まだ実験的な段階とのことですが、今後の発展が非常に楽しみです。 そして、 ASTパーサーをParser gemからPrismへと移行する動き は、Rubyの進化に追従し、より現代的な構文をサポートするための必然的な流れだと感じました。Parser gemのメンテナンスが困難になっている現状を踏まえると、Shopifyが積極的に開発しているPrismを採用することは、RuboCopの将来的な安定性と機能拡張にとって重要な決断と言えるでしょう。翻訳レイヤーを介してParser gemのAPIを維持しつつPrismを利用するというアプローチは 、既存のRuboCopのエコシステムへの影響を最小限に抑えながら、最新のRuby構文への対応を進めるための賢明な戦略だと感じました。ただし、将来的にはPrismネイティブのASTへの移行も視野に入れているような議論もあり、その際の移行コストや互換性維持が重要な課題となるでしょう。 全体として、このセッションは、RuboCopの内部構造のモジュール化を進め、より多くの開発者やツールとの連携を強化し、そしてRuby言語の進化に柔軟に対応しようとするKoichi ITO氏をはじめとするRuboCopチームの強い意気込みを感じさせるものでした。今後のRuboCopの発展がますます楽しみになる発表でした。 （@hiroshi） 概要 本登壇はRubocopに関するトピックを三本立てで提供する。最初にRubocopプラグインシステムの導入により、拡張性を持たせるとともに、非公式なモンキーパッチが横行することで安全でない書き方を一掃することを目指している。 次に、Ruby LSPアドオンは、RubocopのデフォルトのLSPにアドオンとしてRuby LSPを組み込めるようにした。これは、Ruby本体、Rubocop、Ruby LSPが今までバラバラにLSP実装を持っていたものを統合することを狙いとしている。ステータスとしてはまだExperimentalでデバッグの最中である。 最後に、Rubocopの内部ASTとしてPrismを採用したことと、それまでの検討についての発表を行っている。Prismに関しては今年のRubyKaigiでも様々な活用が発表されたが、並行してparser gemのメンテナンスが縮小しているという背景もあり、Rubocop 1.75からはRuby 3.4以降のバージョンではデフォルトのパーサーがPrismとなる。また、Prismとparser gemでASTの互換性を保つためにPrism::Translation::Parserというクラスを用いている。 感想 思い出話をしますが、私は2社前、7年ほど前は超Rubocopアンチでした。 時間をかけてじっくり適応して今となっては当たり前のものとして使用できていますが、ルール同士が競合し合ってダブルバインドしてくることにブチ切れたのも懐かしい話です。 さて、登壇者のkoicさんには「なんか毎年RubyKaigiで登壇してんな」という印象を持っていますが、実際その通りで私が初めて参加した2018年仙台から登壇が途切れておらず、私がひよっこのRailsエンジニアとして「Rubocop使いづれー！」と叫んでいた頃からこのように持続的なアウトプットを続けていることが、Rubocopをデファクトスタンダードの開発ツールとしての立場を揺るぎないものにしているんだなという敬意を覚えます。 そして今回の発表内容である、プラグインシステムやデフォルトパーサの変更もまさしくプロダクトの鮮度を保つための持続的な開発であると言えます。 gemのちょっと込み入った利用方法になってくると途端に情報が少なくなって、書いている人も意味がよくわかっていないような秘伝のタレ化したスニペットが出回る、ということは利用側としてあるあるだなという実感がありますが、そのような状況を提供側として問題視してモンキーパッチが必要ないように仕組みで解消したのは素晴らしいことだと思いました。 (@Hiromi Kai) speakerdeck.com Keeping Secrets: Lessons Learned From Securing GitHub rubykaigi.org 概要 GitHubでの重大なセキュリティ脆弱性の発見や原因調査プロセス、教訓などが語られました。特にRubyコードにおける send メソッドの危険性を深堀りする内容となっていました。登壇スタイルも珍しい2名体制となっており、GitHub社のシニアプロダクトセキュリティエンジニアの Dennis Pacewicz 氏ならびにPraetorian社のスタッフセキュリティエンジニアの Wei Lin Ngo 氏が登壇していました。 感想 ソフトウェアエンジニアであれば誰しもがお世話になっている GitHub。それが Ruby on Rails 製のサービスであることは有名な話だと思います。Rubyistである私も以前から GitHub 社の取り組みには関心はあったものの、実はこのようなカンファレンスや技術イベントでも直接内部の開発者の発表を聞いたことはありませんでした。更に2名体制での登壇スタイルは RubyKaigi では珍しかったので興味を持って視聴しました。 まず、冒頭で GitHub のコンテナ上のすべての本番環境シークレットにアクセスできる可能性があった と語られました。非常に恐ろしい話ですね…。 具体的な原因となるプログラムでは Ruby で時折見かける send メソッドの利用がありました。私もプロダクションのコードで利用したことがあり、耳が痛い話になりそうだなと身構えました。send メソッドは強力な動的メソッドディスパッチですが、GitHub では特定のControllerにてユーザー入力された値を検証なしに send メソッドに引き渡すことで最終的にすべてのプロダクションシークレットを含むハッシュが返される処理が存在していたとのことです。紐解いていくと必ずしも send メソッドの柔軟性が必要な訳ではなく便宜上の理由程度で使用されていたようです。対応後は動的なメソッドコールは消え、特定条件に基づいてメソッドを直接呼び出すより静的で安全なコードに置き換えられました。 今回の事例で登場した send のように Ruby には便利で柔軟性のあるメソッドが存在していると思います。GitHub 社においても今回の脆弱性に繋がった事例が存在するため、業務利用する場合にはメソッドの特性や利用ケースに対するリスクの理解及びそれを検知する仕組みづくりが改めて重要だと身を引き締める機会になりました。脆弱性が見つかった場合も特定個人を非難するのではなく組織全体として学びを得て改善していくブラムレスカルチャーや、発見された脆弱性を起点に類似パターンを探すバリアント分析など、今回の脆弱性発見から恒久対応までに GitHub にて取られたアプローチも学びとして得られました。 （@edy629s） Making TCPSocket.new "Happy"! rubykaigi.org 概要 このセッションでは、Rubyの標準ライブラリであるSocketにおける TCPSocket.new メソッドへのHappy Eyeballs Version 2 (HEv2) の導入 について解説されました。 まず、導入の背景として、IPv4とIPv6が共存する環境での従来の接続処理の問題点、すなわち逐次的なアドレス解決と接続試行による遅延の可能性が挙げられました。これに対し、より効率的な接続確立を目指すHappy Eyeballs Version 2 (HEv2) アルゴリズムの概要、特に 並行したアドレス解決と接続試行 、IPv6の優先、遅延タイマーなどの特徴が説明されました。 次に、Rubyで実装された Socket.tcp へのHEv2導入がRuby 3.4で完了したことを踏まえ、より多くのユーザーが利用するC言語実装の TCPSocket.new への導入における 技術的な課題 が詳細に語られました。主な課題として、状態管理の複雑さ、割り込み可能な名前解決の必要性、スレッド数の違い、完了検出方法の違い、そして select(2) システムコールの上限による問題と poll(2) への移行などが挙げられました。 これらの課題に対し、状態管理を排除した新しい Socket.tcp の実装を参考に、 TCPSocket.new では 新しいスレッドを作成して並行して名前解決を行い、パイプで結果を通知する 仕組みや、GVLなしで待機する関数の利用、 rb_thread_fd_select() という内部APIを活用して必要最小限の修正で対応したことが説明されました。 その結果、HEv2がデフォルトで有効になった Ruby 3.4 がリリースされ、ベンチマークテストでは大幅な接続時間短縮が確認されたことが示されました。また、HEv2の有効/無効を切り替える方法や、利用上の注意点なども解説されました。 最後に、この開発に貢献した多くのRubyコミッターへの感謝の言葉で締めくくられました。 感想 この発表では、ネットワークの低レイヤーに関わる重要な機能であるHappy Eyeballs Version 2の TCPSocket.new への導入という、非常に興味深いテーマについて深く掘り下げた解説を聞くことができました。IPv4/IPv6の共存という現代のネットワーク環境における課題に対し、ユーザーが意識することなく恩恵を受けられるような改善が、標準ライブラリに地道に積み重ねられていることに感銘を受けました。 特に、C言語での実装における並行処理の実現や、システムコールの選定、そしてそれに伴う複雑な課題を一つ一つ解決していく過程が、具体的なコードやアーキテクチャの変化と共に示されており、非常にわかりやすかったです。 select(2) の制約という普段意識しないような問題に直面し、 poll(2) への移行という大きな決断と実装を行った点など、技術的な深さと熱意を感じました。 RubyKaigiという場で、このような基盤となる技術の進化について知る機会が得られたことは、今後のRubyを使った開発においても大いに役立つと感じました。HEv2がデフォルトで有効になったRuby 3.3.0を積極的に利用していきたいと思いました。 （@hiroshi） Happy Eyeballs V2 を TCPSocket.new に導入する過程で直面した課題と、それらの解決策を段階的に解説してくださる、非常にわかりやすい発表でした。 Happy Eyeballs V2 が、IPv4 と IPv6 の両方に対応した環境において、より高速かつ効率的な接続確立を実現するために導入された背景についても触れられており、その必要性を理解できました。 また、RFC などの標準仕様への準拠は、これまで Ruby が対応してくれるのを待っているような感覚でしたが、この発表を通してその裏側で Ruby コミッターの方々が尽力してくださっていることを改めて認識しました。 塩井さんのご発表は、過去の RubyKaigi でも拝聴しており、そのわかりやすさを楽しみにしていました。今回の発表も期待を裏切らず、大変理解しやすく、興味深い内容でした。 (@nissy325) speakerdeck.com おわりに 今回の記事では、RubyKaigi 2025 Day2の3つのセッション、RuboCopの進化、GitHubのセキュリティ教訓、そしてTCPSocket.newへのHappy Eyeballs V2導入について、参加者の視点からの学びと感想をお届けしました。 次回はDay3のレポートを公開しますので、どうぞお楽しみに！ Day2では弊社主催でDrinkUpイベントも開催しました！@味ふく

2025年4月16日から18日の3日間 、 愛媛県松山市 にて、RubyKaigi 2025が開催されました。 rubykaigi.org タイミーでは、昨年に続き、世界中で開催される技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度を活用し、 新卒内定者やインターン生を含む総勢16名 が現地でカンファレンスに参加しました。 前回 に引き続き参加レポートの第2回として、Day2 vol.1と題し、Day2で現地参加した各エンジニアの印象に残ったセッションとその感想をまとめてお届けします。 今後も、 Day2 vol.2 、 Day3 と続けてレポートを公開予定です。 各セッションごとに内容を整理し、参加者自身の視点から学びや気づきをまとめています。読者の皆様にとって、今後の学びの参考になれば幸いです。 Performance Bugs and Low-Level Ruby Observability APIs rubykaigi.org 概要 「遅すぎて不具合に感じる」というパフォーマンスの問題をPerformance Bugsとして紹介し、その問題は「遅さ」ではなく、CPU、メモリ、時間といったリソースの過剰消費の問題として捉えるべきとしました。その問題が本番環境やユーザー体験、コストに与える影響を評価することが重要とした上で、そのための調査にはRubyのObservability APIを使うと良いということが紹介されました。発表ではTracePoint APIやPostponed Job APIなど具体的なAPIと簡単なプロファイラの作り方を紹介していました。最後にPerformance Bugsとの向き合い方を紹介して終わっています。 主要APIの解説と活用例: low_level_toolkit gem:  低レベルAPIの利用例と簡単なツール群を提供。 TracePoint API （内部イベント含む）:  メソッド呼び出し、クラス定義、例外発生に加え、オブジェクト生成(new_object)やGCの開始/終了(gc_start, gc_end)といったVM内部イベントもフック可能。オブジェクト割り当ての追跡やGCタイミングの計測デモが示された。コールバック内での制限（オブジェクト生成不可など）にも言及。 Postponed Job API:  低レベルAPIのコールバック内で安全にRubyコード（オブジェクト生成やAPI呼び出しを含む）を実行させるための仕組み。「セーフポイント」と呼ばれるVMが安全な状態になったタイミングで実行される。GC完了時にRubyコードで情報を記録するデモが示された。 Frame Profiling API:  低オーバーヘッドで現在のバックトレース（コールスタック）を取得できる。プロファイラ構築の基礎。 Debugger Inspector API:  フレームプロファイリングより高コストだが、はるかに詳細な情報（呼び出し元のオブジェクト、メソッド引数、ローカル変数、バインディング、命令シーケンスなど）にアクセスできる。デバッガ構築に利用される。呼び出し元のオブジェクトやそのバインディングを取得するデモが示された。 GVL Instrumentation API:  Global VM Lock (GVL)の取得・解放、スレッドの実行・待機状態遷移を追跡できる。スレッドがGVL待ちでどれだけ時間を費やしているかを計測するデモが示された。 感想 タイミー入社からの約5年間、自分はそれなりにパフォーマンスとは向き合ってきたと思っています。弊社でもDatadogを利用しているのですが、これまでのパフォーマンス改善でとても役に立ちました。パフォーマンス改善の話をすると、昔は超簡単なn+1の改善をすれば2倍3倍と早くすることができました。しかしながら明らかに低速な部分が減るとちょっとずつ丁寧な観測が要求されます。その際にメソッドコールやオブジェクト生成などが観測できるととても便利です。今回の発表では、そんな際に利用しているプロファイラがどうやって作られているのかを紹介しているものでした。言語やプロファイラの理解を深めるために一回触ったり作ったりしてみようと思います。プロファイラは小さいものを含めてまだ作ったことがないので楽しみです。 （@Juju_62q） RubyKaigi前に #Rubygemsコードリーディング部で dd-trace-rb のソースコードを読んでいました。各Rubyバージョンへのパッチ対応をしつつ、C実装も独自に拡張しており、尚且つ型を書いていたので、とても練度の高いgemだなと。 発表では、TracePoint API、Postponed Job APIなどRuby VM内のAPIにはどんなものがあって、どのように活用できてどんなデータが取得できるのかという話がありました。 これらのAPIを使ってRelease GVL profilerをわずか107行で作ったという話がありましたね。 普段からモニタリングやログ探索の場面でDatadogにはかなりお世話になっており、便利に使っていました。内部実装に関しては知見がなかったので、プロファイラの実装に関してイメージが湧いたのは自分にとって有意義でした。 プロファイラは使うだけで作ったことはないのですが、イメージが湧いたので自分で作ってみようと思います。 P.S. IvoにセッションやDatadogへの感謝を直接伝えて、一緒に写真を撮ってもらいました！ありがとうございました！ (@ dak2 ) サービスの規模が大きくなっていくほどパフォーマンスの問題とも真摯に向き合っていく必要があります。自分はタイミーで初めて規模の大きいソフトウェア開発を経験したこともあり、パフォーマンスの問題との付き合い方は勉強中です。 これまではとにかく「遅ければ遅いほど問題だ」と考えていましたが、そうではなくパフォーマンス劣化によって「ユーザー体験や自社のコスト増にどの程度影響しているか」という視点が大事なんだという学びを得られました。 監視ツールでは純粋に処理に時間がかかっているものはわかりますが、それぞれがどの程度ユーザー体験やコスト増に繋がっているかはパッと見わからないです。この辺りの判断を行えるようになるためには各リソースにかかるコストを把握する必要があり、また様々あるドメインについて、レスポンスが悪化することによってどの程度ユーザーに不便をかけるのかも把握しておく必要がありそうだなと思いました。一人で全部把握するのは大変ですが、組織全体として誰かが知っていれば評価はできると思うので、誰がどの領域に詳しいか、誰も知らないものはどれかをきちんと把握し、これからもパフォーマンス問題に向き合っていきたいです。 今回紹介していただいたツールもパフォーマンス劣化の原因を特定するのに役立ちそうなので、一通り使えるようになりたいと思います。 (@rhiroe) プロダクト開発は作って終わりではなく、日々モニタリングを行い改善していく必要があります。今までもdatadogを使ってモニタリングは行っていましたが、どのような仕組みでモニタリングを可能にしているのかは理解できていない状態でした。 発表では、低レベルなRubyの可観測性 (Observability) APIについての解説があり、複数のAPIが紹介されていました。また、パフォーマンスの問題をどう捉えるかという視点についても言及がされており、どれくらいユーザーやコストに対して影響を与えているかが大事であるというものでした。パフォーマンスは良い方が良い、というのは間違いないかなとは思っているのですが、どこからが修正すべき問題として捉えるのかどうか、というのは新しい観点であり新鮮でした。 今回の発表でプロファイラのイメージが少しだけ湧いたため、紹介されていたAPIやサンプルコードを用いてプロファイラの作成にも取り組んでみようと思いますし、今後の改善においては、ユーザーやコスト面の影響などを考えて優先度をつけていきたいです。 (@nissy325) docs.google.com ZJIT: Building a Next Generation Ruby JIT rubykaigi.org 概要 ShopifyのRuby & Rails infrastructure teamのMaximeによるセッションでは、新しいRubyのJIT コンパイラであるZJITの開発概要が説明されました。ZJITは、 将来20年以上にわたる利用を見据え 、高性能、高保守性、高拡張性を目指しているようです。ZJITはメソッドベースのコンパイルと SSAに基づく中間表現を採用し、高速な関数呼び出しの実現を目指しています。初期のマイクロベンチマークでは、インタプリタやYJITよりも高速な結果が出ています。Ruby 3.5でオプショナルで利用可能になるとのこと。4.0では実験的に取り込まれる予定らしいです。今後は、より現実的なベンチマークでの性能向上とコンパイラの最適化に注力していくとのことです。 感想 一番気になっていたMaximeのセッション。このセッションではRubyの次の20年を見据えたZJITという新しいコンパイラや、YJITとの違いについて発表がなされました。 近年、Rubyのバージョンが上がるごとにYJITの性能も良くなっており、Rubyのバージョンを上げたら速くなった…！という体験をされている方も多いかと思います。 ただ、性能の伸びは徐々に鈍化しているようです。 Rubyは良い言語だけど、もし速度が遅ければ、パフォーマンス最適化要求の波に飲まれていずれ滅ぶという趣旨の発言もありました。 そういったモチベーションからZJITに取り組まれているとのこと。 ZJITはSSA（Static Single Assignment Form）に基づく中間表現を採用しているようです。SSAとは「すべての変数の使用に対して、その値を定義（代入）している場所がプログラム上で一箇所しかないように変数の名前を付け替えた中間表現形式」のようです。これは多くのコンパイラで広く使われている中間表現です。これによってコンパイラの設計が理解しやすくなり、拡張も容易になるとのこと。コンパイラについては何もわからないので、Deep Diveしてみようと思いました。 高速なJIT-to-JITの呼び出し、ポリモーフィックインラインキャッシュなどYJITでは難しかった高度な最適化機能の実装になるらしいです。 セッションの中で弊社のブログが紹介されましたね！これからも発信し続けていきたいです。 tech.timee.co.jp この記事にもあるようにRuby 3.4.2のYJITによる高速化の恩恵は受けられませんでしたが、次の YJIT、並びにZJITの動向に目が離せません。（ZJITのPRマージされたみたいですね！） 参考資料 https://www.jstage.jst.go.jp/article/jssst/25/1/25_1_1_19/_pdf https://bugs.ruby-lang.org/issues/21221 https://github.com/ruby/ruby/pull/13131 (@ dak2 ) Dissecting and Reconstructing Ruby Syntactic Structures rubykaigi.org 概要 Rubyの柔軟性と表現力を裏側で支えるParser（特にparse.y）が抱える課題と、解決アプローチを通して、Rubyの構文構造の根底にある原則とパターンについて学ぶことができます。 感想 これまでRubyでアプリケーション開発を行う上で、Parserの存在を特に意識することはありませんでした。しかし、この発表を通して、Rubyのシンプルに見える見た目の内部には、非常に複雑な構文構造が存在し、それがRubyの持つ柔軟性や豊かな表現力を支えていると実感することができ、発表者の@ydah_ さんの熱意も相まって、一気にこの分野への興味が出てきました。 重複した部分を特定し共通構造を抽出して抽象化するというアプローチは、日々のアプリケーション開発でも行われているものですが、それを長年にわたり多くのRubyコミッターによって開発されてきたparse.yに対して行うのは非常に困難だったのではと想像します。今回、Lramaの新しい記法を用いることで構造の抽象化を実現し、Rubyの柔軟な文法を維持しながら、保守性と可読性の向上を可能にしている点にとても感銘を受けました。 (@creamstew) speakerdeck.com Speeding up Class#new rubykaigi.org 概要 このセッションでは、 RubyのClass.newのパフォーマンス改善について解説していました。現状のC言語実装では、RubyとCの呼び出し規約の切り替えなどにコストがかかる点が課題でした。このオーバーヘッドを解消するため、Ruby自身でClass.newを実装する新しい試みが紹介されました。これにより、多くの場合で高速化を実現しましたが、メモリ使用量の増加やスタックトレースのわずかな変化といったトレードオフも存在するとのことです。 感想 普段Railsアプリケーションの開発に携わる中で、Rubyのコードがどう動いているかについて気にすることはほとんどありません。ましてや、パフォーマンスを改善しようと考えたことはなかったので、Class.newのような基本的な部分に改善の余地があるとは想像もしていませんでした。このような改善に取り組む熱意を尊敬するとともに、こういった方々に我々は支えられているのだなと改めて感じました。 また、RubyとCがどのようにデータをやり取りしているかの深い部分を知ることができ（完全には理解できませんでしたが…）、よりRubyに詳しくなれたような気がします。 今後は、感謝の気持ちを忘れずに開発に臨むとともに、パフォーマンス改善をする際には「実は Rubyのコード自体にボトルネックがあるのでは？」という視点を持ちたいと思います。 (@otaksy) “Class.newをCじゃなくRubyで動かす”、とだけ聞くと「Cの方が速いでしょ？Rubyで動かすと遅くならない？」と思いましたが、話を聞くとClass.newの呼び出し箇所が非常に多く、オブジェクト生成の部分だけを見た場合の速度はCで動かした方が速いが、RubyからCに切り替えるためのコストも含めるとRubyだけで動いた方が速いという説明を聞いて納得しました。 この改善によって一般的なユースケースではパフォーマンスの有意な改善が見られるそうなので楽しみです。Ruby3.5にこの変更が含まれる予定だそうですが、次はRuby4.0になるかもみたいな話もあり、楽しみが2倍です。 (@rhiroe) Benchmark and profile every single change rubykaigi.org 概要 このセッションでは、Benchmark-Driven Development（ベンチマーク駆動開発）という手法が紹介されていました。その内容は、コーディングする前にベンチマークを設計し、コーディング前後でベンチマークの実行結果を比較することで、変更によるパフォーマンスの悪化を早期に発見できるというものです。ベンチマーク駆動開発を用いて、RubyフレームワークのSinatraを100倍高速化させたXinatraを実装する取り組みについても紹介されていました。 感想 これまでパフォーマンス改善を何度か経験してきましたが、多くの場合、パフォーマンスが無視できないほど悪化してから改善に着手していました。そのため、コーディング段階でベンチマークを実行し、パフォーマンスの悪化を防ぐというアプローチは、斬新でありながらも有効だと感じました。 また、N+1のような明確なボトルネックを解消した後に、チリツモでパフォーマンスが悪化している状態を何度も見てきたため、チリをツモらせないための解決策としても活用できそうです。 ただし、すべての開発にこの手法を適用すると、開発効率が落ちる可能性があるため、そのトレードオフは考慮する必要がありそうです。そのため、まずはパフォーマンスが特に重要な機能に絞って、この手法を実践してみようと思いました。 (@otaksy) おわりに RubyKaigi 2025 Day2 vol.1レポートでは、低レベルAPIやパフォーマンス改善などRubyの深層に迫るセッションを中心に、現地参加したエンジニアそれぞれの視点からの学びや気づきをお届けしました。 本レポートで取り上げたセッションでは、普段は見えないRubyの仕組みやパフォーマンスへの深い知見を得られたことで、Rubyの奥深さに一層興味が湧きました。 今後もDay2 vol.2、Day3とレポートを公開しますので、どうぞお楽しみに！ Day1の前日に立ち寄った松山市内の海岸

2025年4月16日から18日の3日間 、 愛媛県松山市 にて、RubyKaigi 2025が開催されました。 rubykaigi.org タイミーでは、昨年に続き、世界中で開催される技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度を活用し、 新卒内定者やインターン生を含む総勢16名 が現地でカンファレンスに参加しました。 本レポートでは、 Day1の様子を 、参加したエンジニアが注目したセッションごとに、ポイントや得た知見をまとめてご紹介します。 今後も、 Day2 vol.1 、 Day2 vol.2 、 Day3 と続けてレポートを公開予定です。 各セッションごとに内容を整理し、参加者自身の視点から学びや気づきをまとめています。読者の皆様にとって、今後の学びの参考になれば幸いです。 Make Parsers Compatible Using Automata Learning rubykaigi.org 概要 Ruby のパーサーである parse.y と Prism には非互換性が存在するが、それを検知するためには本来膨大なテストが必要になる。筆者はオートマトン理論を応用することでそれぞれのパーサーの不一致性を定量的に検出できるのではないかという仮説を立て、限定的な条件を当てはめて試行してみた結果、見事にバグを検出して修正することができた。 感想 若いうちから才覚を発揮して個人的に敬愛している makenowjust さんの発表です。内容は概要の通り。 研究とかだとよくある話ですが、現実世界の複雑性に対して理論をそのまま適応できずにより限定されたスコープにのみ理論を適用する、というアプローチがしばしば見受けられます。 今回もそのケースで、Ruby の文法全体は文脈自由言語なので今回の定式をそのまま適用することはできないため、Visibly Push-down Automaton の適用範囲に限定しています。 今回の発表で私が意義深いと思ったのは、その限定されたスコープにおいてもバグの検出に成功したこと、そして、そのバグの修正をコミットすることで言語コミュニティに成果をきちんと還元していることです。 10年近く前に私が大学で卒論を書いたときには研究室のアウトプットがコミュニティから断絶されていて論文を書いたあとも放ったらかしになっていたことを嘆きましたが、こうやってきちんと行動している人物がいることを考えると日常の忙しさに逃げていた私は視座が低かったなと恥じる思いです。 (@Hiromi Kai) speakerdeck.com Ruby's Line Breaks rubykaigi.org 概要 Ruby における改行の扱いと例外、そしてその背景にある技術的な複雑さを紹介してより理解しやすい解決策を提案しています。 感想 Ruby における改行の背後に潜む lexer state という「混沌への扉」といかに向き合って克服していくかという、周辺知識のあまりない自分には中々難しい話ではありましたが、発表者の @spikeolaf さんが、分かりやすく、かつ引き込まれる語り口で解説してくれたので興味を持つことができました。他の Ruby コミッターの方も「理解不能」「怖い」「完全に理解できる人はいない」と語るほど複雑な lexer state をモデル化して最終的には完全に排除したいという壮大な目標を掲げており、いつか「混沌への扉」が閉じることを楽しみにしたいと思います。 (@ creamstew) speakerdeck.com Introducing Type Guard to Steep rubykaigi.org 概要 RBS のエコシステムに積極的に contribute されている @tk0miya さんによる、RBS の Type Guard による Type Narrowing（型の絞り込み）をより便利にしたよ、という発表でした。 Ruby の型チェッカーSteepは型の絞り込みをサポートしていますが、is_a? や nil? などの基本的なメソッド以外（例: Active Support の present? やユーザー定義の判定メソッド）では、開発者の意図通りに型が絞り込まれず、冗長なコードや誤った型エラーが発生することがありましたが、この問題がある程度解消されます。 既に本体に取り込み済みの Union Type に対する Type Guard と提案中の User-Defined な Type Guard の紹介がメインになっています。 感想 タイミーでも実際に RBS/Steep を使っていて、意図した挙動とは異なる挙動を Steep がとることは稀によくあります。そのときは社内にいる soutaro さんに共有し、手元の実装を修正するか本体に変更を入れてもらうかを相談することがちょくちょくあるのですが komiya さんは自ら提案をしパッチを送る活動をされていて流石だなと感じました。 User-Defined な Type Guard も大変魅力的でこれが導入されると、Ruby での静的型付けの表現力の幅がグッと広がるのではないかと感じています。タイミーの中でも状態に応じてメソッドの返す値が異なるものは存在します。それらに対して User-Defined Typed Guard がどう活用できるのかを改めて考えてみたいと思いました。 （@euglena1215） 発表の主旨とは少しずれますが、この機能を使ってメソッドの呼び出し順序を表現することもできそうだなぁと思って興味深く聞かせていただきました。 型の絞り込みが期待通りできず、コードが冗長になる(e.g. something || raise )という経験は多いですが、多過ぎて慣れてしまったので、この発表を聞いてそういえばそうかもなぁという気持ちになりました。この辺りを表現するために複雑な型を書くことを要求されると、なかなか普及はしないかもしれないですが、Union Type に対するものについては、開発者が特に複雑な何かをする必要がなさそうなので純粋に嬉しいなぁと思いました。 (@rhiroe) docs.google.com Deoptimization: How YJIT Speeds Up Ruby by Slowing Down rubykaigi.org 概要 YJIT を開発されている @k0kubun さんによる発表。 YJIT が Ruby のコードを最適化するために、あえて一部の処理を非最適化しているという内容でした。 YJIT の最適化されたコードが、場合によっては逆に効率が悪くなってしまうため、必要に応じて元のインタープリタ実行に戻すということを行っているとのことです。 またCで実装されたメソッドと、Ruby で実装されたメソッドの比較も行われ、C と Ruby のコードの境界を複数またぐ場合にはボトルネックが発生し、YJIT の特性を考慮した実装戦略が必要であることに触れられていました。 感想 YJIT は有効にするだけで使い方を意識する必要なく Ruby アプリケーションが高速化される魔法のような技術だと考えていましたが、その裏側では非常に複雑な技術基盤のもと成り立っているということを感じました。 タイトルにあるとおり高速化を行うためにあえて非最適化を行うという、直感と反する実装が行われていることが興味深かったです。 低レイヤーの知識に触れる機会がこれまでなかったのですが、コンパイラの実装に興味を持つきっかけとなりました。 (@Keisuke Kuwahara) speakerdeck.com Ruby Taught Me About Under the Hood rubykaigi.org 概要 このセッションでは、文字エンコードの歴史から発表者である @ima1zumi さんの運命的な(?)出会いをした EBCDIC、そこから Ruby と出会い Ruby の文字エンコードに貢献していくまでの道のりと対応の苦労が紹介されていました。 感想 私はプログラミングを始めてから、そこまで文字コードに深く思い入れを持たずこれまでのエンジニアキャリアを過ごしてきました。 そのため、コメントでエンコーディングがおかしくなることを避けるために半角カタカナしか使わないことがあったというのは衝撃でしたし、Code Point と UTF-8 byte sequence が別物というのもあまり考えたことがありませんでした。 複数の Code Point で構成される絵文字 🧑‍🧑‍🧒‍🧒 が存在し、Unicode 15.1.0 からは Indic_Conjunct_Break for Devanagari をサポートするために新たなハンドリングのルールを実装する必要があったことなど、文字コードの奥深い世界を垣間見れてとても面白かったです。まさか Unicode アップグレード対応をするためには世界の言語体系に精通している必要があるとは思ってもいませんでした…。 （@euglena1215） Opening Keynote が文字コードという、なかなか通好みなテーマだったのに自分は驚きましたが、蓋を開けてみれば @ima1zumi さんの文字コード愛にあふれる技術的な解説の面白さと、その愛を突き詰めた結果として Ruby のコミッターになったというストーリーのエモさがクロスオーバーする、最高のセッションでした。 セッションに登場した EBCDIC については、自分はメインフレームの経験がないため知らなかったのですが、銀行システムで半角カナが多く使われる理由に関係しているのかもしれない、などと想像がふくらみ、非常に興味を持ちました。（とはいえ業務で扱いたいとはあまり思いません） セッションを通して、文字コードは「文化」と「技術」の交差点であることを改めて実感しました。人間の曖昧で多様な文字を、コンピュータの厳密で機械的なルールに落とし込むという課題は、非常にエキサイティングだと思います。 とりあえず『プログラマのための文字コード技術入門』をもう一度読み直そうと思います。 （@sugaishun） speakerdeck.com Automatically generating types by running tests rubykaigi.org 概要 テストを実行するだけで、メソッドの引数や戻り値の型情報を収集し、RBS 形式のコメントをRuby コードに自動挿入するツール rbs-trace gem を開発したという内容です。 技術的には、Ruby の TracePoint API を利用し、メソッド呼び出し時（:call）とリターン時（:return）の情報をフックして引数や戻り値のクラスを取得し、それを型情報にしてコメントを挿入します。 Model::ActiveRecord_Relation.name で ActiveRecord::Relation が取得されてしまうといったような例を挙げ、klass.name では正確なクラス名が取得できず、UnboundMethod を利用して実際のクラス名を取得するといった工夫も披露してくださいました。 また void 判定にも苦労されたそうで、Prism ライブラリでコードをパースし、AST（抽象構文木）を解析。メソッド呼び出しがdef直下かつメソッド定義の最後の処理でない場合に、戻り値が利用されていないと判断し void 型とするとしたそうです。 感想 型の導入については、特に既存のRailsアプリケーションへの導入のハードルが高く、不完全なものであっても一通り型情報を用意するというだけでも大変なコストがかかります。 この rbs-trace を使えば、テストを実行するだけである程度の型コメントが手に入るので、これから型を導入しようと考えているものについてはとても助かるライブラリだろうなと思いました。 rbs-inline と併用することを前提とされている点もよく、rbs-inline は型コメントがなければuntyped で RBS が生成されるので、これで（不完全な）型情報が（動的に生成されたものや移譲されたメソッドを除いて）一通り揃うことになります。型導入の最初の一歩としては十分すぎるくらい型情報が揃うので、型導入やってみたいけどハードルが高いと感じていそうな組織があれば推していこうと思いました。 (@rhiroe) speakerdeck.com おわりに RubyKaigi 2025のDay1も、実践と研究の境界線を行き来するような深い技術セッションが続き、Ruby という言語が進化を続けていることを改めて実感する一日でした。 低レイヤの最適化、型システムの発展、文字コードという文化的テーマまで、まさに“Ruby らしさ”が詰まったセッションばかりで、各登壇者の情熱や貢献から多くの刺激を受けました。 Day2、Day3にも魅力的なセッションが数多く控えています。今後公開予定のレポートも、引き続きどうぞご期待ください！

はじめに こんにちは！タイミーでPlatform Engineerをしている @MoneyForest です。 本記事では、タイミーで実施したProduction Readiness Checkの取り組みを紹介します。 Production Readiness Checkとは プロダクションレディネスチェック（Production Readiness Check）とは、 「サービスが本番環境で安定して運用できる状態にあるかどうかを評価」 するプロセスのことです。 UberのSREの知見から書かれた書籍 プロダクションレディマイクロサービス には、以下のように書かれています。 Uberのすべてのマイクロサービスは、安定性、信頼性、スケーラビリティ、耐 障害性、パフォーマンス、監視、ドキュメント、大惨事（カタストロフィ）対応を備 えていなければならないという8つの原則を考え出しました。そして、サービスが安 定性、信頼性、スケーラビリティ、耐障害性、パフォーマンス、監視、ドキュメント、 大惨事対応を備えているとはどういうことかを定義する基準を考えていきました。大 切なのは、どの基準も定量化できるものにすることでした。そうすれば、マイクロサー ビスの可用性が飛躍的に向上したという測定可能な結果が得られます。我々は、これ らの基準を満たし、要件を備えたサービスを本番対応（プロダクションレディ）と表 現することにしました。 背景 株式会社タイミーはマイクロサービスを採用しておらず、主要事業であるスキマバイトサービス「タイミー」のアプリケーションは主に1つのRailsアプリケーションで構築されています。 モジュラモノリスという形でシステムのドメインとオーナーシップを論理的に分割してきました。 一方で直近は事業戦略、ガバナンス、クォータの観点から一部機能をサブシステムに分割する動きもあります。 つまり「マイクロサービスアーキテクチャほど頻繁にサービスは新規に立ち上がらないが、定期的にサービスは新規に立ち上がっている」という状態です。 なぜやるか タイミーではマルチテナントのコンテナオーケストレーション基盤は存在せず、システム・サブシステムごとにECSクラスターを構築しています。 アプリケーションもRuby on Railsが採用されることが多いものの、言語およびフレームワークは都度選定されています。 また、サービス開発はアプリケーション、インフラ合わせてストリームアラインドチーム（Squad）のスクラム開発によって行われています。 上記の通り、現状ではゼロベースに近い状態から開発を行うため、信頼性などの様々な観点で注意すべき点が出てきます。 そのため、サブシステムや関連サービスのリリースに際して「 本番環境で安定して運用できる状態にあるか 」を評価点検する仕組みは一定の価値を発揮すると考えます。 タイミーのProduction Readiness Checklist プロダクションレディマイクロサービス の内容をベースに、タイミーの技術選定に合わせ、より具体的な内容に落とし込み、チェックリストを作成しました。 書籍には以下の考慮がなされていますが、タイミーではクラウドインフラはAWS、オブザーバビリティツールはDatadog、と限られたものを活用しており、より具体的な記述になっているほうがチェックしやすいと判断しました。 テクノロジーはものすごい速さで動き、変化しています。私は可能な限り、 読者を既存のテクノロジーに縛り付けるようなことは書かないようにしました。たと えば、すべてのマイクロサービスは、ロギングのためにKafkaを使うべきだとは言わ ず、本番対応のロギングの重要な要素を説明し、実際にどのテクノロジーを選んで使 うかは読者に委ねるようにしました。 また、内容についてはClient-Server-Databaseの3層アーキテクチャを前提としています。 サーバレスアーキテクチャの場合は対象外です。 チェックの各項目は書籍を参考に以下の観点に分類しています。 観点 主なキーワード 安定性・信頼性 開発サイクル、デプロイパイプライン、依存関係処理、unhealthyなホストの検出、healthyなホストへのルーティング、グレースフルシャットダウン、APIバージョニング スケーラビリティとパフォーマンス リソースの効率的な使い方、リソースの把握、キャパシティプランニング、依存関係のスケーリング、トラフィック管理、タスクの処理、スケーラブルなデータストレージ 耐障害性・大惨事対応 冗長化、一般的な大惨事と障害シナリオ、障害の検出と修正の方法、回復性テストの詳細、インシデントと機能停止の処理方法 監視 監視、構造化ロギング、ダッシュボード、アラートのトリアージ ドキュメント・組織運営 サービスの適切なドキュメントの問題と、開発チームと技術組織全体でアーキテクチャと組織運営の理解 タイミーのProduction Readiness Checklistの詳細 実際のチェックリストの内容を観点ごとに紹介します。 1. 安定性・信頼性 コード管理 コードがGitHubリポジトリで適切に管理されている 環境構築方法がdevcontainerやdocker-composeなどをベースに、環境差異が少なく導入工数が低い構成になっている CI/CD GitHub Flowによる開発の場合、以下のいずれかの設定が実装されている CDの依存にCIのPass状態があること ブランチ保護ルールの「Require branches to be up to date before merging」が有効化されていること CIでコードの静的解析（Lintチェック）、セキュリティチェック、テストを実施している 特別な理由がない限り、CI/CDパイプラインにGitHub Actionsを採用している 各環境のCDパイプラインが自動化されている CDの成功/失敗がSlackに通知される仕組みがある インフラストラクチャ AWSアカウントのサポートレベルがエンタープライズに設定されている ALBのヘルスチェックにアプリケーションのヘルスチェックエンドポイントが使用されている ECSでアプリケーションコンテナの依存関係にDatadog Agent、AWS for Fluent Bitが指定されており、アプリケーションコンテナが最後に立ち上がるよう依存関係が設定されている アプリケーション設計 アプリケーションのAPIエンドポイントがバージョニング可能なURIパターンに設計されている Deep Health Check パターンに基づいたヘルスチェックエンドポイントが実装されている ECSのコンテナライフサイクルの仕様 を踏まえたグレースフルシャットダウンが実装されている ALBのスティッキーセッション が無効でも正常に動作する設計になっている ローリングデプロイ により新旧バージョンにトラフィックが分散しても問題ない設計になっている アプリケーションがマルチスレッドで動作する場合、スレッドセーフになっている 2. スケーラビリティとパフォーマンス オートスケーリング ECSでCPUベースのオートスケーリングが設定されている ECSでCPUスパイク時のオートスケーリングが設定されている スケーラブルなデータストレージの選択 データベースにAurora MySQLのLTSバージョンを使用している キャッシュにAmazon ElastiCache for Valkeyを採用している パフォーマンステスト 負荷テストが実施されており、想定されるトラフィック量に対する性能が検証されている 3. 耐障害性・大惨事対応 ロールバック ECSでデプロイサーキットブレーカーが有効化されており、サービス更新失敗時に自動的にロールバックする仕組みがある 可用性 Aurora MySQLで2台以上のリーダーインスタンスが配置されている Auroraのサブネットグループに3AZを指定し、インスタンスが異なるAZに分散配置されている Aurora MySQLの自動バックアップが有効化されており、ポイントインタイムリカバリ（PITR）による復元が可能になっている Aurora MySQLのバックトラック機能が有効化されている ElastiCacheレプリケーショングループでのマルチAZ化が有効化されている 障害対応 SPOF（単一障害点）となりうる箇所が洗い出され、ドキュメント化されている 想定される障害シナリオがRunbookとしてドキュメント化されている 社内で定められたインシデント・障害対応フローに準じた障害対応手順が整備されている 4. 監視 ロギングとトレーシング ALBのリクエストログがS3に保存され、日時でパーティショニングされており、Athenaでクエリ可能な状態になっている ECSのサイドカーにDatadog Agent、AWS for Fluent Bitが設定されている アプリケーションにDatadog APM Tracingが計装されている ヘルスチェックエンドポイントで、正常時のログとTraceの出力が抑制されている APM Tracingでリクエスト単位でTraceが出力され、最低でもDB、キャッシュ、外部サービスへのHTTPリクエストの単位でSpanを確認できる アプリケーションのログが構造化されており、採用言語に応じてDatadogのドキュメントに準拠した実装がされている ログとトレースの相関付けがされており、採用言語に応じて Datadogのドキュメント に準拠した実装がされている アプリケーションがミドルウェアでリクエストログを出力するようになっている リクエストごとに一意となるIDを生成または上流から受け取り、リクエストログとTraceに出力している リクエストログを識別するためのフィールドが定義されている（Datadogでリクエストログ用のログインデックスに保存するため） Sentryによるエラートラッキングが設定されている データストア監視 Aurora MySQLのPerformance Insightsが有効化されている Aurora MySQLで以下のパラメータが有効化されている binlog_format = ROW Datadog DBM 関連パラメータ slow_query_log long_query_time innodb_print_all_deadlocks performance_schema ダッシュボードとアラート Datadogにシステムメトリクスを監視できるダッシュボードが整備されている Datadogにユーザー影響が発生した場合のモニタリングアラートが設定されている Warning/Criticalの閾値が適切に定められている オーナーチームが定義されている Runbookへのリンクが添付されている ビジネスメトリクス（ログインや課金の成功率など）を監視できるダッシュボードまたはウィジェットがある モニタリングダッシュボードを定点観測するスキームがある 5. ドキュメント・組織運営 ドキュメンテーション システムの概要説明とアーキテクチャ図が整備されている システムの連絡先とコンタクト方法を記載したドキュメントがある AWSやSaaSなど依存サービスのクォータが洗い出されており、クォータの引き上げ手順が整理されている DBスキーマを元に最新のER図を生成する仕組みがある GitHubリポジトリにREADMEが作成されている READMEに以下が記載されている（リンクでも可） リポジトリの概要 環境構築手順 ディレクトリマップ すべての依存サービス（関連社内サービス、外部SaaS）が洗い出され一覧化されている まとめ 今回はProduction Readiness Checkの取り組みを紹介しました。 この取り組みはボトムアップ的に始めたものではありますが、全社的に当たり前のように行われるものにしていきたいです。 また書籍にはないですが、セキュリティやデータ連携もプロダクションレディの重要な要素になると思っているので、DREやセキュリティ部門と連携してチェックリストを拡充していきたいという思いもあります。 もっと知見を深めて、さらに楽しいエンジニアライフを送りたいと思います！またね〜

タイミーでiOSアプリエンジニアをしている前田 ( @naoya )と申します。 2024年4月9日〜11日に開催された「try! Swift Tokyo」に参加してきました。 try! Swift Tokyo try! Swift Tokyoとは Swiftに関わる開発者が世界中から集まる年に一度の国際カンファレンスです。最新技術や開発の知見をシェアするトークセッションが開催される他に、エンジニア同士が交流する場としても毎年大きな盛り上がりを見せています。 今年のアップデート ロケーション 昨年は渋谷の「ベルサール渋谷ファースト」での開催でしたが、今年は立川の「立川ステージガーデン」に場所を移しての開催でした。 立川ステージガーデン 会場のすぐ近くには昭和記念公園があり、落ち着いた空気感の中で、カンファレンス参加者同士でリラックスして交流できました。また、今回の会場はライブ会場としても使用される場所で、椅子の座り心地がすごく良かったのが印象的でした。 会場内の様子 try! Tokyo 2025アプリ 公式アプリも進化していて、今年はリアルタイム翻訳機能が搭載されました。これまで通りの翻訳レシーバーも用意されていましたが、アプリ上でもスピーカーの話が即座に日本語表示されるようになっており、翻訳精度も非常に高くて驚きました。多言語の壁を超えて楽しめる、素晴らしい体験でした。 try! Tokyo 2025アプリの翻訳機能 アーカイブ動画が即日公開 なんと、イベント終了当日にYouTubeにトークセッションのアーカイブ動画がアップロードされました。会場では理解しきれなかったトークも、すぐに振り返ることができるのは本当にありがたかったです。 try! Swift Tokyo 2025 - YouTube 印象に残ったセッション紹介 三日間に渡り、さまざまなトークを聴くことができました。その中でも、僕が気になったトークをいくつかご紹介します。 iOS 17, 16, 15などの新機能 www.youtube.com iOS 15〜17で追加されたAPIを改めて紹介するトークです。毎年のWWDCで膨大なAPIが発表されますが、実際のプロダクト開発で使われずに、APIの存在を忘れてしまうことはよくあります。本トークでは、そういった開発者に向けて、iOS 15〜17で追加されたいくつかのAPIを紹介するトークです。僕が全く知らなかったAPIを各OSバージョンごとに一つずつご紹介します。 privacySensitive(_:) (iOS 15.0+) developer.apple.com privacySensitive(_:) は、プライバシー保護のための修飾子です。個人情報や機密データを含むViewにこのモデイフィアを付加することで、アプリがバックグラウンドに移行した時、該当のViewをマスクすることができます。 privacySensitive(_:) UIHostingConfiguration (iOS 16.0+) developer.apple.com UIHostingConfiguration は、 UITableViewCell や UICollectionViewCell など、UIKitのセル内でSwiftUIのViewを直接使えるようにできる構造体です。セル内のUIのコードを、モダンで簡潔に記述することができます。 UIHostingConfiguration ContentUnavailableView (iOS 17.0+) developer.apple.com ContentUnavailableView は、「表示する内容がない」状態を、ユーザーにわかりやすく伝えるためのViewです。 ContentUnavailableView 40万以上DLされた個人開発アプリをサービス終了するためにしたこと www.youtube.com 40万DLを達成した個人開発iOSアプリ「WebCollector」のサービスを終了するにあたり、実施した対応や、その際に考慮したことについてのトークです。WebCollectorは、フルサイズでWebページのスクリーンショットを撮影できるアプリです。スクリーンショット画像は、クラウド上に保存できます。 たくさんのユーザーにDLされていたアプリですが、Safariの標準機能でページ全体のスクリーンショット画像を記録する機能が追加されたり、AdMobの広告が掲載されなくなったことで、サービスの運営が難しくなってしまい、サービスのクロージングをご決断されたとのことでした。 Firebase Remote Configで、サービス終了ページの表示をコントロールしたり、Firebase Cloud Messagingで、Push通知を受け取れるようにすることで、サービスの終了を丁寧に周知した事例をご紹介されていました。 僕も長く個人アプリを開発しているので、思い入れがあるアプリをクロージングすることはかなり辛いことだろうなと思いました。そのような中でも、丁寧にサービスをクロージングをされたことは本当に素晴らしいと感じました。 以下の記事で内容の詳細が語られているので、ぜひご覧ください。 note.com Swift × Android: Skipが切り拓くクロスプラットフォーム開発の未来 www.youtube.com Skipは、Swift / SwiftUIだけでiOSとAndroidの両方に対応したアプリを開発できる、クロスプラットフォーム開発を行うためのツールです。SwiftUIをJetpack Composeに変換したり、SwiftコードをKotlinに変換したりできます (Transpiled Mode)。さらに、SwiftコードをAndroid上でそのまま動かすこともできます (Native Mode)。 iOSのネイティブアプリ開発には、開発ツールはXcodeを使い、Swift / SwiftUIコードを記述します。一方、Androidでは、開発ツールはAndroid Studioを使い、KotlinまたはJavaコードを記述します。iOS・Android両プラットフォームでアプリをリリースする場合、それぞれの開発ツール・プログラム言語を習得する必要があり、学習コストが膨大でした。 しかし、Skipを使用することで、単一のソースコードで両プラットフォームのアプリを開発できます。こちらのトークでは、スピーカーの方が実際にSkipを使用してアプリ開発を行なった実体験についてのトークです。主なトークポイントは以下の三つです。 Androidアプリ側は期待通りのUIになるか。 Transpiled ModeとNative Modeどちらを選択すべきか。 既存のアプリをSkipに移行することが可能かどうか。 「1」については、期待通りのUIを生成できているとのことでした。ただし、ナビゲーションバーのように、SwiftUIとJetpack Compose間で表示仕様が異なる箇所があるので、それらの仕様差異を理解しておいたほうが良いとのことでした。 「2」については、Native Modeがおすすめとのことでした。Transpiled Modeでは、Swiftで書かれたコードをターゲットプラットフォーム向けに変換 (トランスパイル)してビルドします。現在は、変換に対応していないAPIが多くあり、Android用のコードを書いたり、別APIの使用を検討する必要があるようです。ただ、Native Modeにもデメリットがあり、アプリサイズが大きくなったり、ビルド時間が長くなったりするので、それぞれのメリット・デメリットを考えた上で、アプリの特性に合わせて選択したほうが良さそうとのことでした。 「3」については、不可能ではないが、かなりチャレンジングになるとのことでした。理由としては以下の二つです。 ・iOS側で使用しているライブラリがAndroidに対応していないものがある。 ・AndroidのAPIに変換できないiOSのAPIがまだたくさんあり、場合によっては膨大なAndroid用のコードを記述する必要がある。 まだ実用面で課題はたくさんあるものの、最近では、SwiftUIで記述したコードをAndroid用にもコンパイルすることが可能になったり、 APIのサポート範囲が拡大していることもあり、今後かなり期待できるツールとのことでした。 本記事では一部のトークについて書きましたが、その他にもさまざまな分野のトークがありました。今回はvisionOSについてのトークが多かった印象を受けました。このように、普段の業務では耳にしない内容のトークを聞くことができ、非常に有意義な三日間でした。 最後に try! Swift Tokyoでは、久しぶりに再会できた友人との時間や、普段関わることのない社外エンジニアの方々との出会いがあり、本当に充実した三日間を過ごせました。 今回紹介できなかったトークの他にも、面白いトークがたくさんありました。 記事にある内容や、その他の内容についても、もしタイミーのエンジニアと話したいという方がいらっしゃればぜひお気軽にお話ししましょう！ product-recruit.timee.co.jp

こんにちは！株式会社タイミーの貝出です。データサイエンティストとして働いており、主にカスタマーサポートの業務改善に向けたPoCやシステム開発など行っております。 先日、2025年4月9日～11日にラスベガスで開催された「Google Cloud Next '25」に、Data Science Group の小関と貝出で現地参加してきました！ 業務でも Gemini を利用することが多く、今回はAgent関連の発表も多いとのことで大変楽しみにしていました！ 今回のブログでは、現地の様子や注目した発表・セッション、そしてイベント全体の雰囲気について共有させていただきます。 イベント概要 イベント名: Google Cloud Next '25 開催地: アメリカ合衆国、ラスベガス 開催期間: 2025年4月9日～11日 参加目的: Google Cloudの最新技術（特にLLMやAgentまわり）のキャッチアップ、事例調査、ネットワーキング 会場はMandalay Bay Convention Centerで、世界中から多くの参加者が集まり、活気に満ち溢れていました。 Google Cloud Next '25 Expo会場の入口 事前準備 アメリカへの海外出張が決まり、国内出張とは異なる手続きや準備が必要となりました。私自身パスポートの有効期限が切れていたため、まずはパスポートの申請から始めることに。併せて、渡米に必要なESTAの申請も行いました。 タイミーでは、海外出張の手続きがNotionで体系的にまとめられており、非常に助かりました。航空券やホテルの手配も社内のシステムを通じてスムーズに申請できました。特にフライト時間は税関検査の所要時間も考慮されているようで、大変ありがたかったです。 ホテル選びに関しては、Data Science Group の菊地さんからおすすめのホテル情報を教えていただき、効率的に検討を進めることができました。大変感謝しています。 今回の海外出張準備にあたり、参考になったウェブサイトを以下に記載します。 www.hyperbilling.jp iret.media 渡航スケジュール 日本からの参加ということで、参考までに今回の私の渡航スケジュールをご紹介します。時差調整も含め、余裕を持った日程を組みました。 日付 (2025年) 時間 (現地時間) 移動/内容 4月8日 09:20 サンフランシスコ国際空港 着 13:00 サンフランシスコ国際空港 発 15:00 ハリーリード国際空港 着 15:50 ホテルチェックイン 4月9日 (Day 1) 終日 Google Cloud Next '25 参加 (セッション、Expo等) 4月10日 (Day 2) 終日 Google Cloud Next '25 参加 (セッション、Expo等) 4月11日 (Day 3) 終日 Google Cloud Next '25 参加 (セッション、Expo等) 4月12日 3:30 ホテルチェックアウト 6:00 ハリーリード国際空港 発 8:00 サンフランシスコ国際空港 着 13:30 サンフランシスコ国際空港 発 4月13日 14:00(日本時間) 羽田空港 着 初日ハリーリード空港に到着すると、Lyftを利用してホテルへ向かいました。今までUber/Lyftを利用したことはなく、本当に利用できるかドキドキしましたが、無事ホテルまで到着できました。アプリの仕様もわかりやすく、ドライバーも親切だったため、満足度はとても高かったです！マッチングプラットフォームを運営しているタイミーとしても大変参考になりました。 Lyftを利用し、目的のホテルへ Google Cloud Next '25 Keynote Day 1の朝にOpening Keynote、Day 2の昼にDeveloper Keynoteがあり、どちらも大盛況でした。特にOpening Keynoteは会場が満席で入れず、モニターのある別室で視聴することに。会場の熱気とは対照的に、別室はやや落ち着いた雰囲気でした。 どちらのKeynoteでもAgentに関するサービスが大きく取り上げられ、特に Agent2Agent 、 ADK 、 AgentSpace が今回の目玉として紹介されていました。概要は以下です。 Agent2Agent Agent2Agent（A2A）は、2025年4月9日にGoogleから発表されたオープンプロトコルで、異なるベンダーやフレームワークで構築されたAIエージェント同士が安全に情報を交換し、企業全体のアプリケーションやプラットフォーム上で連携できる相互運用性を提供する。 ADK Agent Development Kit（ADK）とは、GeminiやGoogleのAIツールと統合されたオープンソースのAIエージェント開発フレームワークである。ワークフローエージェント、マルチエージェントシステム、関数ツールやカスタムツールの組み込み、デプロイ（Cloud Run/DockerやVertex AI Agent Engine）など、柔軟かつモジュール式の構造でエージェントの設計・実装・評価をサポートする。 AgentSpace Google Agentspaceは、社内の主要アプリケーション（Confluence、Google Drive、Jira、SharePointなど）へのセキュアな接続、Google品質のマルチモーダル検索、Geminiを活用したレポート生成やオートメーション機能を備えたエンタープライズ向けエージェントハブである。直感的なエージェントデザイナーでのカスタムエージェント作成や、パートナー提供エージェントの統合も可能で、組織全体で安全かつコンプライアンス遵守のもとAIエージェントを展開できる。 Opening Keynoteの朝の光景。人がめちゃ多い Developer Keynote は会場に入れた Expo & Startup Hub Expo会場は大盛況で、Anthropic のブースやNeo4jのブースに訪問しました。すっかり写真を撮るのを忘れてしまい、記録はありませんが…。 個人的には、Anthropic のブースが印象に残っています。Claude 3.7 Sonnet が Agent として初代ポケモンの攻略に挑戦した実験に関するポスターが紹介されていました（参考: https://www.anthropic.com/research/visible-extended-thinking ）。プロンプトには、AgentがActionするためのツールの定義やシステムプロンプト、ポケモンに関する知識ベース、Action履歴などが盛り込まれており、非常に長い（Long Contextな）内容となっていました。個人的に、このようなプロンプトをどのように制御し、どう最適化したかに興味があり質問したところ「色々なTipsはあるものの、タスクやモデルによって変わるため、結局は実験と分析のイテレーションを繰り返すことが重要だ」というお話をいただきました。 また、Expo会場の一角にはStartup Hubがありました。そこで朝食を取っていると、他の会社の方々とコミュニケーションを取ることができました。セキュリティの会社や自動テストツールを開発している会社の方と会話し、何にGoogle Cloudを使っているか、なぜGoogle Cloud Nextに来たのか、といった話を聞くことができました。皆さん、やはりGeminiやAgentをどのように自社製品に活かしていくかについて興味をお持ちで、生成AIへの関心の高さを感じました。 Startup Hub での朝食 Next’25 Party イベントはMandalay Bayから徒歩10分程度の場所にあるAllegiant Stadiumで開催されました。ガンガンのクラブミュージックがかかる場内のテンションは最高潮でしたが、自分はスタジアムの端でビールを飲みながら、少し離れて眺めていました。 隣に座っていたシンガポールのデータ分析企業に勤務する方が声をかけてくださり、Looker と Tableau の違いやAgentSpaceについて話すことができました。「Looker は使いやすいけど可視化に少し弱点があるので、そのあたりはTableauがいいよ」とのことでした。 Allegiant Stadiumの外観 Next’25 Partyの様子 気になった発表 How good is your AI? Evaluate it at every stage. 概要 Google Cloud AIが提供する GenAI Eval Service は、多様なモデル（Proprietary、Open、Google、Customized）に対応可能なAIモデル評価サービスです。Pairwise/Pointwise といった評価モードや、Computation（計算ベース）/Autorater（モデルベース）といった評価方法を選択できます。 Google Cloudユーザーからの要望に基づき、本サービスを活用した以下のアプローチに関する紹介とデモが行われました。 GenAIバッチ評価 (Autorater) : Autorater（モデルベース評価）をバッチ処理で実行し、評価プロセスを効率的にスケールさせる手法。 Autoraterの性能評価・カスタマイズ : ベンチマークデータに対する人間の評価結果を用いて、Autorater自体の評価精度を測定・改善するアプローチ。評価結果を利用し、プロンプトの改善、設定調整、追加データによるチューニングを通じて、Autoraterの信頼性向上が可能になります。 Rubrics-driven評価 : 多様なデータセットや複雑なユースケースに適した評価手法。特に、評価基準（ルーブリック）の自動生成機能により、迅速かつカスタマイズ性の高い評価が可能になります。 Agentの評価 : 応答の質、推論・計画能力、ツール利用など、さまざまな評価対象が存在します。推論・計画能力や、記憶、Self-Reflection の評価はまだ研究中とのことでした。 感想 Google CloudにGenAI Eval Serviceという評価に特化したサービスが存在することを今回初めて知りました。紹介された機能が現状で利用可能かはわかりませんが、今後のPoCフェーズで検証したいと考えています。特に、評価基準（ルーブリック）を自動生成できる点は、効率化の観点から個人的に大きな可能性を感じます。 また、プレゼンテーションの冒頭では、効果的な評価のためのステップとして「(1)具体的な評価目標の設定、(2)ユースケースに合ったデータセットの選択 、(3)適切な評価方法の選択、(4)評価結果の分析」の重要性が強調されていました。GenAI Eval Serviceを利用することで、これらのステップを体系的かつ効率的に進めることが可能になると感じました。 Long context is all you need 概要 本発表では、Google DeepMindのResearch ScientistであるNikolay Savinov氏が、GeminiのLong Contextに関する成果と応用先を紹介しました。 LLMはパラメータ記憶だけでは最新情報やプライベート情報に関して正確な出力ができないため、プロンプトに過去のやり取りや提供されたPDFなどのデータ、背景情報を含めたインコンテキスト記憶の活用が重要です。 最新モデルである Gemini 2.5 Pro は、Long Contextでの性能を評価する各種ベンチマークデータセットにおいてo3‑mini‑high、GPT‑4.5、DeepSeek R1、Claude Sonnet 3.7などと比較して高い性能を示していました。また、コンテキストウィンドウが1Mトークン（将来的には2Mトークン）に拡大していることも紹介されました。2Mトークンとは、約10万行のコードを扱える規模とのことです。 Long Contextの応用例としては、動画・音声分析（情報抽出や要約）、大規模文書分析（比較やQA）、コード理解（リポジトリ把握や機能特定）、エージェント（過去行動や文脈に基づく動作）、少数ショットのインコンテキスト学習などが挙げられていました。 さらに、実利用のTipsとしてコンテキストキャッシュによるコスト削減、RAGとの組み合わせによる知識活用、無関係コンテキストの排除、クエリ長とレイテンシの考慮、Proモデルやプロンプト工夫の重要性が示され、Long ContextがLLMの可能性を大きく広げるとの結論で締めくくられました。 質疑応答では、コンテキストキャッシュの最適化方法について「プロンプト冒頭にできるだけ固定部分を置くのがいいと思うが、実際にはさまざまなバリエーションを検証してほしい」とのアドバイスがあり、またlost in the middleの緩和度合いについては「ベンチマーク性能が向上しており、他モデルより緩和されている」との回答がありました。 感想 業務においても、プロンプトに多くの情報を詰め込むアプローチを検討しているため、Long Contextの取り組みは大変ありがたいです。また、LLMによってはシステム指示の記述位置によってモデルが指示を無視したり従ったりする傾向があるため、Geminiの最新モデルを積極的に利用したいと思います。さらに「Long Contextが可能になればRAGは不要か？」という問いには、レイテンシや無関係コンテキストの問題から使い分けが必要だという説明も非常に納得できました。 おわりに 4月8日に日本を発ち、13日に帰国するまでの約5日間、短い期間ではありましたが、刺激的な新サービスの発表や多くの方々との貴重な出会いに恵まれ、あっという間の充実した時間でした。 現地では、Google Cloud Japanの皆様に大変手厚くサポートいただき、慣れない土地でも安心して過ごせました。他の日本企業の方々との交流の機会を設けていただいたり、興味深いデモをご紹介いただいたりと、細やかなお心遣いに深く感謝しております。さらに最終日には、イベント全体のまとめセッション「Next ’25 Highlight」を開催いただき、見逃してしまったセッションの情報もしっかりとキャッチアップすることができました。皆様の温かいサポートに、心より感謝申し上げます。 今回の素晴らしい経験から、次回もぜひ参加したいと強く感じております。また、特に社内のデータ関連チームにとって非常に有益なカンファレンスでしたので、その価値を社内で広く共有していきたいと考えております。 「ウェルカム・トゥ・ラスベガス」の看板 現在、タイミーでは、データサイエンスやエンジニアリングの分野で、共に成長し、革新を推し進めてくれる新たなチームメンバーを積極的に探しています！ product-recruit.timee.co.jp また、気軽な雰囲気での カジュアル面談 も随時行っておりますので、ぜひお気軽にエントリーしてください。↓ hrmos.co hrmos.co

こんにちは！ タイミーでPlatform Engineerをしている @MoneyForest です。 ObservabilityCON on the Road Tokyo 2025に参加してきました。 参加した感想や気づきなどをお届けします。 はじめに 普段は Datadog をメインに利用している弊社ですが、他のツールなどを知ることで深まる知見もあると考え、先日開催された Grafana Labs 主催の「ObservabilityCON on the Road Tokyo」に参加してきました。本記事では、Grafana エコシステムの印象や、イベントで得られた気づきについて共有したいと思います。 イベントアーカイブ 日本語吹替版の全セッションのアーカイブが以下のリンクで配信されています。 Webinars and videos | Grafana Labs ObservabilityCON on the Road 基調講演 ObservabilityCON on the Road 基調講演 | Grafana Labs 基調講演で特に気になった点は「OpenTelemetry Datadog Receiver」でした。 Grafana エコシステムの強みは、オープンソースをベースにしている点です。ベンダーロックインを避けつつ、必要に応じてマネージドサービスであるGrafana Cloudを利用するという手法を取ることができます。 そのため、GrafanaはOpenTelemetryを推しており、その流れからOpenTelemetryエコシステムのコントリビュートと競合製品から自社製品への誘導を同時に行う一手だなと思い、驚きました。具体的には、このレシーバーによりDatadogのメトリクス形式をOpenTelemetryのネイティブ形式（OTLP）に変換できるため、既存のDatadog Agentをそのまま使いながら、データをGrafana CloudやPrometheusなどに送信できるようになります。 また、OpenTelemetry Datadog receiver のコードの公開をGrafanaが発表しているという点についても意外でした。てっきりこういった内容はDatadog社が発表すると思っていたのですが、競合が発表を行っているという点も興味深いです。 Grafana Labsの「ビッグテント」思想の「データがどこにあっても、どのようなツールを使っていても、アクセスできるようにすべき」という考え方は、特にマルチクラウド環境やハイブリッド環境が当たり前になっている現在、非常に共感できるポイントでした。 弊社でもオブザーバビリティにかけるコストはサービスの成長に伴い増大しており、ロックインは主にコスト面でリスクになりえると考えています。OpenTelemetryベースの実装にすることで、製品、OSSの乗り換えや、セルフホストなどコスト最適化で幅広い手段を取ることができるようになると思います。 計測とデータ取り込みを一瞬で実現：Grafana Alloy、Grafana Beyla、OpenTelemetryのデモ 計測とデータ取り込みを一瞬で実現：Grafana Alloy、Grafana Beyla、OpenTelemetryのデモ | Grafana Labs こちらのセッションではGrafana AlloyというOpenTelemetryの100%互換のコレクターや、Grafana Beylaという計装ライブラリの紹介がありました。 Grafana Beylaは、eBPFベースのアプリケーション自動計測ツールで、実行中のサービスのメトリクスやトレースを自動的に取得できます。Go言語でOpenTelemetry SDKで計装する場合、通常はコード上で明示的にトレーサーの開始やスパンを切る必要があると思っていたのですが、Beylaではそれらのコードレベルでのインストルメンテーションなしに観測データを収集できることに驚きました。 これは、OpenTelemetryのドキュメントにある「Zero-code Instrumentation」というコンセプトに沿ったものです。 OpenTelemetry Zero-code Instrumentation Grafana Beyla Documentation このアプローチは、アプリケーションを修正せずに計装できるというメリットがあります。 DatadogでもRubyはRailsフレームワークに基づいた自動計装機能があり、Goでも DataDog/orchestrion などのOSSが発表されています。 この辺りは言語やライブラリごとに自動計装のやり方が異なる点があるため、どこかで実装のPoCを行ってみたいなと思いました。 合成テスト、負荷テスト、実ユーザーモニタリングでエンドユーザー体験を把握する方法 合成テスト、負荷テスト、実ユーザーモニタリングでエンドユーザー体験を把握する方法 | Grafana Labs k6はGrafanaが提供するJavaScriptでテストシナリオなどを記述できるGo製のツールです。 自分も負荷テストツールとしてはよく使っていて、使いやすいツールくらいの認識だったのですが、あらためて本セッションを見ることでk6のメンテナがGrafanaであることのメリットを感じることができました。 このツールが生成するレポートを、Grafana Cloudおよび周辺のエコシステムと組み合わせることでよりリッチなインサイトを得られることがセッションのデモを通じてわかりました。例えば、負荷テスト時のバックエンドの挙動をTraceやProfileと組み合わせて分析することで、ボトルネックの特定が容易になります。 Core Web Vitalの測定やSynthetics Test、ユーザージャーニーベースの観測はどのオブザーバビリティツールでもできると思いますが、メジャーな負荷テストツールを持っているのはGrafanaの強みだと思いました。 まとめ オブザーバビリティの分野はOpenTelemetryというエコシステムを中心に日々変化していっているため、定期的にイベントに参加して体系的なキャッチアップを行う必要があると思いました。 Grafanaはオープンソースをベースにしているため、ベンダーにとどまらない汎用的な知識を各セッションから学ぶことができました。弊社でも引き続きオブザーバビリティに関する情報キャッチアップを行っていきます。

タイミーQAEnablingチームの矢尻、岸、片野、山下、松田です。 ソフトウェアテストに関する国内最大級のカンファレンス「 JaSST (Japan Symposium on Software Testing) 」が2025/03/27、28の2日間にわたって開催されました。 speakerdeck.com 本レポートでは、印象に残ったセッションの内容を中心に、2日間の会の様子をお伝えします。 「タイミーQAの挑戦」JaSST登壇レポート：品質文化と開発生産性の両立を目指して タイミーでQAコーチを担当している矢尻です。 今年のJaSSTは、タイミーとして「タイミーQAのリアルな挑戦：DevOps時代の開発生産性と品質文化を創造する」というセッションで登壇させていただきました。QA Enablingチームの立ち上げから約1年間の試行錯誤を経て得た学びや課題を、チームメンバー全員でパネルディスカッション形式で共有しました。短いセッションでしたが、「品質文化をどのように組織に根付かせていくのか」「開発生産性を保ちながら品質を向上させるには？」など、多くの参加者の皆さんから具体的で深い質問や意見をいただき、学び合いが生まれる貴重な場になりました。この場を借りて御礼申し上げます。 また、全体のセッションを通じて印象的だったのは「チーム組成」や「品質基準」、そして「開発プロセスへのQAの適応」といったテーマへの関心の高さです。QAを単なるテスト業務としてではなく「品質文化を醸成する存在」として位置付け、チームや組織をどう巻き込み、どう改善していくのかについて議論が活発だったのが印象深かったです。QAがビジネス価値にどう貢献できるかを考えるヒントが多く、特に他社が品質基準の明確化やプロセス改善にどのように取り組んでいるかを知ることで、自分たちの現状や課題を改めて客観視できました。 今回のJaSSTをきっかけに、今後もタイミーのQA Enablingチームとして、開発現場により深く寄り添いながら、品質と開発生産性の両立、そしてさらなる品質文化の浸透を目指していきたいと思います。 大規模プロジェクトにおける品質管理の要点と実践 タイミーでSETをしています岸です。JaSSTは昨年に引き続きオフラインでの参加でした。知人と久しぶりに話もできたりで良い2日間を過ごせたと思います。 私が聴講したセッションからは「 大規模プロジェクトにおける品質管理の要点と実践 」のレポートをお届けします。 第三者検証のSHIFT社から2名でインタビュー形式の発表でした。ここでの「大規模」はリリースまでに10年、参画人数は数千人を想定とのことで、なかなか経験する機会のないものです。とにかくプロジェクト初期からステークホルダーが多いので、関係者間でどのように調整するのか、いわゆる隠れた仕様をどのように拾い上げるのかが焦点になりました。回答としては、リスト化やスケジュール調整をまずしっかりすること、現場に足を運んでユーザーの声をしっかり聞くことを挙げていました。その上で「100%を目指すといつまでも要件定義が終わらない。90%くらいを目指し、漏れたものは次のフェーズへ回すようにする」ことがとても重要だとおっしゃっていました。 私たちタイミーの開発では10年がかりで続くような長期プロジェクトはなく、小さいリリースを何度も繰り返すスタイルをとっています。一見違う世界の話のようにも感じられますが「100%を目指すと終わらない」という話は私たちにも共通するものだと感じました。 ネット銀行におけるスマートフォン実機でのテスト自動化について SETの片野です。 今年のJaSST TokyoはタイミーのQAチームとして登壇する機会をいただき、私個人としては初めての現地参加となりました。 たくさんの素晴らしいセッションの中で、特に印象に残ったのは「 銀行におけるスマートフォン実機でのテスト自動化について 」（坂本豪志さん） です。 このセッションでは、BaaS （Banking as a Service）としてパートナー企業にスマートフォンアプリを提供するネット銀行における、スマートフォン実機を用いたテスト自動化の取り組みについて語られました。 スマートフォンの実機を用いた受入テスト、リグレッションテスト等を一部自動化することで、パートナー企業1社導入につき数十人日規模だったテスト工数を80%近く削減されたそうです。その過程で直面した課題と解決の事例として、事前データの準備、テスト端末同士の相性による接続性の問題、特定のロケーターで要素がつかめなくなる不安定なテストへの対応などが紹介されました。 特に興味深かったのは事前データの準備に関する取り組みです。テスト対象システムのユーザーデータは属性や関連データ（多岐に渡る金融商品とそれらの契約状態など）が多く、加えて複数のサブシステム間で整合性を取る必要があるため、データ準備に手間がかかったりテストの繰り返し実行が難しかったそうです。これらの問題に対して、データ駆動テスト的なアプローチの適用や、テスト再実行時のデータリセット要否に基づくテストシナリオの整理などを行い自動化に向けた改善を実現したそうです。様々な事情で手動オペレーションや運用でカバーせざるを得ない部分を残しつつも、ご本人の言葉を借りれば「泥臭く」取り組まれたとのことでした。 この「泥臭く」という言葉に象徴されるように、セッション全体を通じて理想論や教科書的な内容にとどまらず、現実の課題に真正面から向き合い、解決策を模索する姿勢が強く伝わってきました。それは、まさに私たちが日々の業務で直面している状況とも重なり、深く共感する点がありました。また、当日のセッションで語られた内容はどれも現場の経験から得られた現実的かつ有用な情報ばかりでした。私自身もテスト環境の改善に携わっており、今後の業務に直接活かせる具体的な内容が数多くありました。 テスト環境の改善では、時にスマートな解決策を見いだせず泥臭い作業の連続になることがあります。しかし、このセッションを通じて、理想と現実のバランスを取りながら、粘り強く課題解決に取り組むことの大切さを改めて認識しました。 QAが売上に貢献できることはなんだろう？ タイミーでQAコーチをしている山下です。（入社して半年たったばかりでまだまだ見習いQAコーチという気持ちです。） 久しぶりにオフラインでJaSSTに参加をしてきました。新しい会場でとても綺麗で快適でした！が、オフラインだと会場が満席で聞きたいセッションを聞けない…！ということもあり、オフラインの難しさを思い出したりもしました。 今回私が参加した中で、特に印象に残ったセッションは「 ソフトウェアがJISマーク認証される時代に！～標準化がもたらすソフトウェア品質の確保や市場への信頼性向上～ 」でした。 タイトルの通り、ソフトウェア製品でJISマークの認証を取るためのプロセスなどを紹介してくださっていたのですが、一番刺さったのは「なぜJISを取ろうと思ったのか？」という質問に対する登壇者の伊藤さんの「QAが売上に貢献できるのはなんだろうとよく考えていて、JISがあることで選んでもらえることがあるんじゃないかと考えた」という回答でした。 だいぶ昔にWACATEに参加した際に「一生懸命たくさんテストしたとして、そのプロダクトは売れるの？」と問いかけをしてもらったことがあり、それが確かにそうだ…と当時の自分には衝撃的で時折思い出しては考えるテーマだったので、JISマークの取得が競合との差別化につながるのかー！と目から鱗、明るい気持ちになりました。 機能追加があった場合には追加の認証試験が必要なため、実際にスピードの速い開発で適用することは難しそうでしたが、これからも引き続きQAが売上に貢献できることは何か？は考え続けたいテーマだと思いを新たにできました。 その他にも、このセッションに引き続き品質基準に対するテーマにしたセッションなど多くの発表や、昔の同僚と久しぶりに再開しどんなところでAIを活用しているか話したりと多くの刺激をもらえた2日間でした。 私がJaSSTで心を奪われた,組織を強くするマネジメント術 2024年の9月に入社したSETの松田です。 先日参加したJaSSTは、私にとって初参加・初登壇の機会となり、非常に特別な2日間となりました。 特に印象に残ったセッションは、SmartHR平田さんによる 「スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み」 です。 セッションでは、主にマネージャーとしての目標設定やチームの仕組みづくりについて語られていました。平田さんが、マネージャーとして取り組むべき「チームの現状課題」「チームが目指すべき目標」「目標達成のための具体的なタスク」を明確に言語化されていた点が非常に印象的でした。これは、QA/SETチームだけでなく、あらゆる部署やチームにも共通して当てはまる内容だと感じました。 メンバーの能力を最大限に引き出すために、チームの先頭に立ってあらゆるステークホルダーと交渉・調整を行い、障害となる壁を次々と取り除いていく平田様の姿勢に「こんなマネージャーがいるのか！」と深く感銘を受けました。 ぜひまた機会があれば、品質保証部のセッションをお聞きしたいです。 スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み | ドクセル JaSSTは、テストに関する知見を深めるだけでなく、多くの素晴らしい方々と出会える貴重な機会でした。来年は、私もコミュニティの一員として、何か貢献できるよう準備して参加したいと思います。来年も皆様とJaSSTでお会いできることを楽しみにしております！！！！！！！ おわりに 弊社は今回2度目のゴールドスポンサーとしてJaSST Tokyoに協賛させていただきました。次回以降もなんらかの形で貢献して一緒にコミュニティを盛り上げていければと思います。 タイミーのQA、ソフトウェアテストについてもっと知りたいという方はぜひカジュアル面談でお話ししましょう。 product-recruit.timee.co.jp

はじめに こんにちは、株式会社タイミーでデータサイエンティストとして働いている貝出です。直近はカスタマーサポートの業務改善に向けたLLM活用のPoCやシステム開発を行っております。 さて、今回は2025年3月10日（月）～3月14日（金）に開催された「言語処理学会第31回年次大会(NLP2025)」に昨年に続き参加してきましたので、その参加レポートを執筆させていただきます。 言語処理学会年次大会について www.anlp.jp 言語処理学会年次大会は 言語処理学会 が主催する学術会議であり、国内における言語処理の研究成果発表の場として、また国際的な研究交流の場としての国内最大規模のイベントとなっています。 今年で第31回を迎え、オープニングで共有されたスライドによると、発表件数は777件、事前・直前参加登録者数は2248人と過去最大となっており、年々大会が盛り上がっていることが伺えました。昨今のLLMの盛り上がりを反映し、発表内容はLLMに関連するものが大多数を占めており、業務でLLMを活用している身としては、大変学びの多い会となりました。 言語処理学会第31回年次大会に参加できなかった方でも、 こちら から発表論文が閲覧できます。 興味深かった発表 初日のチュートリアルから最終日のワークショップまで興味深い発表がたくさんありました。その中から、個人的に気になった発表をいくつかピックアップします。 [T1] チュートリアル１: 言語モデルの内部機序：解析と解釈 概要 本チュートリアルでは、大規模言語モデル（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

こんにちは、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 に任せることで、開発者の負担を軽減し、効率的な開発を実現しました。 今回のバージョンアップを通して、安定性と効率性を両立させるための具体的な取り組みをご紹介しました。今後も技術の変化に柔軟に対応し、より良い開発環境を構築していきたいと考えています。

こんにちは、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: ですね。これからは発信する側にもなってみたいです。

はじめに こんにちは！ タイミーでPlatform Engineerをしている @MoneyForest です。 今回は、弊社のDatadogにおけるAWSメトリクス収集を、従来のCloudWatch GetMetric APIからCloudWatch Metric Streams方式に移行することで高速化した取り組みについて紹介します。 背景 タイミーのワーカー様向けアプリケーションは、ピーク時に1分あたり十数万リクエストを処理するような規模で運用されています。そのため、システムの異常を素早く検知し、対応することが求められます。 主にシステムの異常検知は、メトリクス、ログ、APMをソースとしてエラーレートやレイテンシーの異常を判断し、DatadogのモニタリングアラートでSlackに通知することにより行われます。 DatadogによるAWSメトリクス収集の仕組み Datadogでは、AWSのメトリクスを収集する方式として2つの方法があります。 CloudWatch GetMetric API方式 CloudWatchのAPIを定期的にポーリングしてメトリクスを収集 メトリクスの遅延が15-20分程度発生する可能性がある CloudWatch側の遅延（5-10分） Datadogのポーリング間隔（10分） APIレート制限による追加遅延（最大5分） CloudWatch Metric Streams方式 ストリーミングしたメトリクスをAmazon Data Firehoseを介してDatadogに送信 aws.s3.bucket_size_bytes や aws.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点の問題が明らかになり、それぞれ対応を行いました。 CloudFormationスタックの適応中（8分程度）はダッシュボードで一部のメトリクスが重複して計上されてしまっている Datadogのドキュメント には以下の記載があり、特別なケアは必要ないものの、キレイに切り替わるわけではなさそうなことがわかりました。 API ポーリングメソッドを通じて特定の CloudWatch ネームスペースのメトリクスを既に受け取っている場合、Datadog は自動的にこれを検出し、ストリーミングを開始するとそのネームスペースのメトリクスポーリングを停止します。 こちらは反映が完了すると元通りになるため、許容範囲と判断し、念のため開発者へリリースタイミングを周知するにとどまりました。 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が短縮される見込み、です）。 これからも高トラフィックなアプリケーションで信頼性を担保するための地道な改善を続けていきたいと思います！またね〜