タイミーQA Enabling Gのkishikenです。 「 Tokyo Test Fest 2025 」が11月14日に大崎ブライトコアホールにて開催されました。 タイミーには世界中で開催されているすべての技術カンファレンスに無制限で参加できる「Kaigi Pass」という制度があります。詳しくは以下をご覧ください。 productpr.timee.co.jp 今回はこの制度を使って参加しました。 参加して 聴いたセッションのうち印象に残ったいくつかをピックアップしてご紹介します。 Zen of Testing Mesut Durukal 日本の「禅」の心。禅のような日本の文化がソフトウェア品質とどのようにつながるのか、ユーモアを交えて講演されていました。 例えば、ゲートQAという品質のチェックポイントは神社の「鳥居」であり、探索的テストは誰にも仕えず旅をする「浪人」のようであると言ったものです。いくつか「流石に厳しくないか……？」と感じたものもありましたが、日本の文化と品質活動を結びつけていこうという試みが非常に面白く、ユニークな講演でした。 個人的にはテストという活動を「折り紙」の繊細さや精緻さに例えたところが印象に残りました。テストは細やかな技術が必要でありつつ、一種のアートでもあるという考えは私も同意見です。 Make Testing a Team Sport: Bug Bash for Better Software Prashant Hegde バグバッシュを「チームスポーツ」として捉え、チーム全体で品質を高めていく手法についての講演でした。 冒頭で「Blind men and an elephant」の寓話が引用され、異なる視点からプロダクトを見ることの重要性が語られました。開発者・デザイナー・プロダクトオーナーさらには開発部以外の方など、異なる役割の人々が集まってテストすることで、一人では見つけられない問題を発見できるという考え方です。 バグバッシュを成功させるためには準備ミーティングが重要であり、また参加者のモチベーションを高めるために勝者の表彰といった工夫も効果的だと紹介されていました。特に準備についてフォーカスしており、ただ人を集めてプロダクトを触ればバグバッシュになるのではなく、役割分担やタイムボックスを決め、テストが専門でない人には事前にレクチャーをし、そして飲み物やおやつをしっかり用意しておくのが重要だと説明していました。 私自身はバグバッシュについて企画も参加もあまりやったことがないのですが、開発以外の部門の方との交流も含めて実施してみるのも面白そうだなと思いました。 Be a Better Test Friend Martijn Goossens 基調講演です。QAと開発に関わる他のロールとの関係性について、「友達」という視点から語られた講演でした。 ソフトウェア開発はQAだけでなく、プロダクトオーナー・UXデザイナー・開発者・運用担当者といった多くロールの人がチームを組んで行います。QAエンジニアは時に孤独な役割になりがちですが、品質を「シェア」し、チーム全体で取り組むマインドセットを持つことで、より良い協力関係を築けるという考え方について紹介されていました。 例えば、プロダクトオーナーはビジネスを技術に翻訳するエキスパートです。プロダクトオーナーからはドメイン知識やステークホルダーを教えてもらい、QAからは受け入れ基準やユーザーストーリーの書き方をサポートしていきます。このようにQAと他ロールとで協調をして、お互いに足りないものを補っていくことの重要性をお話ししていました。 特に、QAは批評家ではなく編集者であるべきだという指摘が心に残りました。批評家は問題を指摘するだけですが、編集者は一緒により良いものを作り上げていく存在です。「品質のアンバサダー」として、異なる役割の人々と「友達」として協力し、仕事に取り組んでいくことの大切さを学びました。 まとめ Tokyo Test Festは今回が2回目の開催です。私は昨年参加できなかったため、今年が初参加でした。このカンファレンスは都内での開催ですが、日本で働く海外のエンジニアの方々が主催しており、さながら国際カンファレンスのような雰囲気です。ほとんどの講演が英語で行われ、 聴く側としても貴重な機会になりました。 ピックアップには含めませんでしたが、品質保証においても生成AIに関わる多くのトピックが語られています。生成AIの登場によるソフトウェア開発の大きな変化は日本も海外も変わらず、皆悩みながら日々向き合っているというのが実感できました。 生成AIの活用からチーム協働まで、QAの未来について多くの示唆を与えてくれるカンファレンスでした。今回学んだ「品質をシェアする」という考え方を、タイミーのチームでも実践していきたいと思います。

こんにちは、タイミーでバックエンドのテックリードをしている新谷 ( @euglena1215 ) です。 タイミーのバックエンドでは、Feature Flagの管理に Flipper を使用しており、そのデータストアとしてRedisを利用しています。本記事では、Flipperの値をインメモリキャッシュする機構を導入することで、Redisへのアクセスを90%削減し、毎時発生していた突発的なスパイクを解消した事例を紹介します。 本記事が、Feature Flagシステムの負荷やパフォーマンスに課題を抱えているチームの参考になれば幸いです。 Redisで突発的なspikeとエラーが発生していた タイミーのモノリスRailsリポジトリでは、Feature Flagを活用して新機能の段階的なリリースやA/Bテストを実施しています。しかし、運用を続ける中で、いくつかの問題が顕在化してきました。 毎時0分台に発生する突発的なspike DatadogでRedisのメトリクスを監視していたところ、毎時0分台に突発的なspikeが発生していることが確認されました。このspikeでは、平常時の約5倍ものアクセスが集中していました。 Redisアクセスが毎時0分台に跳ねてました これはどうやら毎時0分に実行されるcronにより非同期ジョブが大量にenqueueされ、各ジョブの処理でFeature Flagが参照されることによる RedisへのN+1アクセスが発生しているようでした。 そもそもFeature Flagの値はほとんどのケースで変化せず、毎回データストアであるRedisにアクセスする必要はないのではないかと考えました。数秒くらいの期間であれば各プロセスでFlagをキャッシュしておいても、実用上は問題ないはずです。 そこで、プロセス内キャッシュとRedisの値を同期してくれる便利な仕組みを実現しようと考えました。 解決策：Flipper::Adapters::Syncの導入 Flipperには、remoteのデータとlocalのデータをいい感じに同期してくれる Flipper::Adapters::Sync が存在します。このアダプターを使うことで、指定した間隔（interval）でのみremoteからデータを取得し、それ以外はlocalのキャッシュから値を読み取る、という振る舞いを実現できます。 実装の詳細 実装の主なポイントは以下の通りです： 1. Sync Adapterの導入 # config/initializers/flipper.rb require ' connection_pool ' require ' flipper/adapters/sync ' Flipper .configure do |config| redis_pool = ConnectionPool .new( size : 5 , timeout : 5 ) do Redis .new( url : REDIS_URL ) end remote_adapter = Flipper :: Adapters :: Redis .new(redis_pool) local_adapter = Flipper :: Adapters :: Memory .new sync_adapter = Flipper :: Adapters :: Sync .new(local_adapter, remote_adapter, interval : 10 ) config.adapter do sync_adapter end end Sync Adapterは、localのMemory adapterとremoteのRedis adapterを組み合わせて使用します。 interval: 10 と指定することで、10秒間はlocalのキャッシュから値を読み取り、10秒経過後に再度Redisから最新の値を取得します。 2. Adapter初期化の最適化 重要なポイントとして、Sync Adapterのインスタンスを config.adapter do ~ end ブロックの 外で作成 しています。これには理由があります： ブロック内に記述すると、リクエスト毎にアダプターが初期化されてしまう 外で作成することで、プロセス内で単一のインスタンスを共有できる 結果として、プロセス内で同じローカルキャッシュが使われる 3. Redis Connection Poolの導入 gem ' connection_pool ' これまでは毎リクエストでRedis接続を確立していましたが、Sync Adapterを導入することで接続が長期間保持されるようになります。そのため、接続が切れた場合の耐障害性を高めるため、Flipper 1.3.3から導入された Redis Connection Pools の機能を使ってconnection poolを持つようにしました。 4. リクエスト毎のメモ化を無効化 Rails .application.configure do # Sync adapter の @local (Memory) がプロセス内キャッシュとして機能するため、 # リクエストごとのメモ化は不要 config.flipper.memoize = false end Flipperではデフォルトでリクエスト毎に同一flagを参照した際にメモ化する最適化が有効になっていますが、これを無効にしました。メモ化が有効になっていると、リクエスト毎にSync adapterのlocalデータが揮発してしまう問題があったためです。Sync adapterが導入されたことで、そもそもメモ化は不要になりました。 導入前後の効果 検証環境での検証結果 本番導入前に、demo環境で動作確認を行いました。社内管理画面に全てのfeature flagに対して Flipper.enabled? を呼び出すテストボタンを用意し、導入前後の挙動を比較しました。 Before：全リクエストでFlag数回のRedisアクセス 全てのリクエストでFlag数回（21回）のRedisアクセスが発生している After：10秒中の最初のリクエストのみRedisアクセス 同一プロセスにおける10秒中の最初のリクエストを除き、Redisアクセスが発生しなくなった 元の実装では、全てのリクエストでFlag数回（21回）のRedisアクセスが発生していましたが、変更後は同一プロセスにおける10秒中の最初のリクエストを除き、Redisアクセスが発生しなくなったことを確認しました。 本番環境での効果 本番環境に導入した結果、以下の効果が確認できました： 平常時のRedisアクセスが90%削減 リクエスト毎のRedisアクセスがほぼ不要になり、大幅なアクセス削減を実現 毎時0分台のspikeが完全に解消 平常時の5倍のアクセスが発生していたspikeが消滅 Redisの負荷が安定し、インスタンスサイズダウンの可能性も見えてきた まとめ Flipperに Flipper::Adapters::Sync を導入することで、Feature FlagシステムのRedis負荷を90%削減し、毎時発生していた突発的なspikeを解消することができました。 この改善により、以下のメリットが得られました： 安定性の向上 ：timeout errorの減少、spike解消による安定した動作 パフォーマンスの向上 ：Redis I/Oの削減による応答速度の改善 コスト削減の可能性 ：Redis負荷の削減によるインスタンスサイズダウンの検討 Feature Flagの値が頻繁に変更されない特性を活かし、適切にキャッシュすることで、大きな改善効果を得ることができました。同様の課題を抱えているチームの参考になれば幸いです。 参考資料 Flipper GitHub Repository Flipper 1.3.3 Release Notes - Redis Connection Pools Flipper::Adapters::Sync Documentation

こんにちは、タイミーでAndroidエンジニアをしている ふなち（@_hunachi） です 😆 タイミーの Kaigi Pass という制度を使い、 Kotlin Fest 2025 に参加してきたので、その感想などを紹介します！ ちなみに、弊社からは @tick_taku と私の2名で参加しました。 聞いたセッション紹介 @tick_taku と 私、それぞれが特に印象に残ったセッションをご紹介します！ tick_taku 「動く」サンプルでスムーズなコミュニケーションを 〜CMP時代のKotlinPlayground活用最前線〜 2025.kotlinfest.dev KotlinPlayground のプラットフォームに Compose Multiplatform が選択できるため、Web 上でサクッと画面を構築して URL を共有することで動くものベースにチームコミュニケーションを活性化しよう、というセッションです。 KotlinPlayground は Kotlin 勉強し始めのころに「このコードはどういう動きをするのか？」を確認するために利用したことはありましたが、まさか UI を共有することができるようになっているとは...明日から使ってみたい tips な内容でした！ 自分は Android アプリエンジニアなのでさっそく Android 向けの UI を構築して共有したいなと思いました。ですが実際触ってみると activity package は import できそうになかったので、基本は Web 向けで Android アプリ的にはコンポーネント単位の挙動の確認などに利用できるのかなと感じました。 またWeb上の環境なのでプロダクトコードをそのまま載せるのはやめておいた方が無難かもしれません。 こちらのセッションで Firebase Studio なる存在を初めて聞ききました。AI による vibe coding をベースとしたノーコード開発向けのプラットフォームでしょうか。 UI 共有に利用するだけだとオーバースペック気味そうですが、テキストからモックを作らせてコミュニケーションを図るという目的であれば有用そうですね。 フルKotlinで作る！MCPサーバー、AIエージェント、UIまで一気通貫したAIエージェントシステム 2025.kotlinfest.dev もともと Kotlin で MCP サーバー作れないかな〜と思っていたところに Koog による AI エージェント作成までを紹介されていて、フルスタック Kotlin の可能性を見せていただき、とてもワクワクしました。やはり Kotlin は素晴らしい言語！！ チャットのチェックポイントにおけるハマったポイントなど、経験者の少ないフレームワークの実体験に基づくナレッジの共有はとても貴重でありがたいです。 公式 SDK が Streamable HTTP をサポートしていないというのは MCP サーバーを作成する上でネックになりそうですね。 このセッションを聞いた後に上記の KotlinPlayground のセッションを聞いていて思ったのですが、LLM を利用して仕様書や要点から KotlinPlayground 使ってモックを作らせて短縮リンク発行するエージェント作れないかな〜🤔 アイデアを話してまとめているだけで動作が見られる簡単なモックができ、よりプロダクトのコミュニケーションを円滑にできるのではと期待値が高まりました。 とは言え、 Firebase Studio が想像している通りであれば、用途が被りそうなので情報を集めていきたいです。 内部実装から理解するCoroutines ー Continuation・Structured Concurrency・Dispatcher 2025.kotlinfest.dev 普段何気なく利用している Coroutines の詳細な内部処理をコードと図解を用いて詳細に解説していてとても勉強になりました。 実際この辺りの内部仕様を把握していなくてもなんとなくで使えてしまい非常に便利ですが、ディテールを理解することでより深く・効率的に使いこなせるようになるのだと実感しました。 少しハードルの高いデコンパイルやライブラリのソースコードを読んでみることに挑戦しようと思える素晴らしいセッションだと思います。 余談ですが解説記事が事前に公開されており、進行に合わせて読み進めながらセッションに集中できたこともとても良い体験でした。ありがとうございます！ ふなち Kotlinを支える技術：言語設計と縁の下の力持ち 2025.kotlinfest.dev このセッションでは、Kotlinの言語設計の裏側と、この一年でKotlinがどのように進化してきたのかについて深く知ることができました。 言語設計に関しては Companion object の話を聞くことができました。 Kotlinの Companion object は、その使用の95%がJavaでいう static を宣言する場として使われています。しかし、実際には Class.Companion という 型 を生成しており柔軟な使い方ができる点や、クラスに一つしか作れない点などの問題があるそうです。 この問題を解決するため、過去には namespace や static などさまざまなプロポーザルが検討されましたが、 Companion object との併用時の課題などから、全てリジェクトされてしまったそうです。しかし、現在は companion 構文を使えるようにすることで、これらの課題を解決しようとしているという話でした。 また、この話の中で「一度リリースしてしまうと、それは本や動画、ネット上の記事として末長く残ってしまう。だから、簡単にDeprecatedにはできない。新しい機能を作る際には、とても慎重にならざるを得ない。」とおっしゃっていたのが特に印象に残りました。 他にもセッション内では、Kotlin 2.2や2.3、そしてAndroid Studioのアップデートについても触れられており、Kotlinは更に年々便利になっているなと改めて実感しました。 また、 Kotlinのロードマップ が年に2回ほど更新されているとのことだったため、Kotlin Fest の数日後にAndroidのメンバー全員で、最新のロードマップを確認する時間を作りました。Kotlin Notebookの開発が進んでいることなどを知れて、とても有意義な時間となりました。半年後にも、またメンバー全員で読もうと思います！ せめて、ネイティブらしく - マルチプラットフォームと撤退戦略 2025.kotlinfest.dev KMP（Kotlin Multiplatform）をあまり触ったことがない自分としては、「KMPを導入した場合の欠点」や「万が一、撤退する場合にどうすべきか？」という点が気になり、このセッションを聞きに行きました。 KMPをほぼ触ったことがないのですが、このセッションは主にiOSアプリ開発を行う際の内容だったため、FlutterやAndroidを触っている自分にとって、比較的分かりやすい内容でした。 KMP iOSのStableリリースもあり、KMPでのiOSアプリ開発はどんどんしやすくなっていることや、KMPでは実現が難しいこともKotlin/Nativeで頑張ればほとんど実現できると知れ、KMP導入のハードルはかなり下がっているんだなと感じました。 「撤退戦略」に関しても、実装時にレイヤーを分けるといった具体的なTipsが紹介されており、とても勉強になりました。 Rewind & Replay: Kotlin 2.2 が変えるCoroutine デバッグ最前線 2025.kotlinfest.dev 最近はCoroutinesの深いデバッグをする機会が減っていましたが、このセッションでCoroutinesのデバッグがこんなにも進化していることを知ることができました。 ただ、新しいデバッグ機能をAndroid Studioではまだ使えないそうなので、早くAndroid Studioでも対応してほしいなと思いました😢 一緒に紹介されていた stacktrace-decoroutinator というライブラリ は、Android Studioでも使用可能とのことだったので、いざという時に頼らせてもらおうと思います！ KoogではじめるAIエージェント開発 2025.kotlinfest.dev 現在のAI Agent開発の状況や、 Koog がいかに便利かを知ることができました。 カレンダーに予定を追加してくれるようなAgentも作れるという実例を見て、これは社内ツールや外部サービスとの連携など、色々な用途で使えそうだと感じました。 細かな実装のコツも色々紹介されており、Koogを使って、社内・社外問わず、AIエージェント開発にチャレンジしてみたいというモチベーションが高まりました！ 全体を通して 全体的な雰囲気は、セッションもブースもたくさんあり、賑わっていて楽しかったです。 お弁当やPCを持ってきていた関係で荷物が多かったため、クロークがあったのも本当に助かりました！ 懇談会では、サーバーサイドでKotlinを使っている企業の方ともお話ができたり、Kotlin Fest ならではの交流ができていい刺激になりました！弊社のサーバーサイドもKotlinになればいいのに…（小声）🤫 Kotlin Fest で学んだことや得られたモチベーションを活かして、明日からの開発に繋げていきたいと思います！ 推しのあすけんのお姉さんとのツーショに喜ぶ tick_taku

こんにちは。タイミーでデータサイエンティストをしている吉川です。 最近、生成AIを使ったプロジェクト管理の仕組みを試しているのですが、想像以上に働き方が変わったので、その体験を共有したいと思います。 TL;DR 「進捗を更新して」の一言で、5つの管理ファイルが自動更新される仕組みを作った 成果物作成時間が約50%削減（6.5時間→3.25時間）※体感ベース・タスクにより削減率は異なる LLMが「外部ツール」から「チームメンバー」に変わる感覚 秘訣は、Git管理されたMarkdownファイルにドキュメントを集約し、自動化ルールを作成すること はじめに：もっと本質的な仕事に時間を使いたかった プロジェクト管理をしていて、こんなふうに感じたことはありませんか？ デイリースクラム準備 - タスク管理ツールを開く - 「昨日のタスク、進捗率どうなった？」 - 完了タスクを目視でカウント（1, 2, 3...） - 電卓で進捗計算「40/45...88.9%か」 - 手動で更新 今日のタスクを決める - 「タスクAとB、どっちを先にやるべき？」 - 依存関係を確認しようとする - 複数のツールを参照して判断（15分） タスク決定、作業開始 - 「前提となる仕様、どこだっけ？」 - 「前に決めた内容、何だっけ？」 - 複数のツールやドキュメントを探索（30分） 文書を書き始める - 構造を考え、内容を練り上げる（4時間） 週次報告の準備（金曜日） - 完了タスクを手作業でカウント - Sprint切り替え準備：未完了タスクを整理 - 次週の準備（30分） 日常的な進捗管理や情報収集に時間を使うより、 もっと創造的で本質的な仕事に時間を使いたい 。そう考えるようになりました。 やったこと：Git + Markdown + LLM自動化ルールで進捗管理を自動化 そこで、以下のような仕組みを作りました。 1. すべてのドキュメントをGit管理されたMarkdownファイルに集約 プロジェクトに関するドキュメントをすべてMarkdown形式でGitリポジトリに格納しました。 requirements/ ├── A_現状分析/（5ファイル） │ ├── p01_a_01_high_level_kpi_analysis.md │ └── ... ├── B_詳細分析/（5ファイル） ├── C_ビジネス要件/（5ファイル） ├── D_データ要件/（5ファイル） ├── F_機能要件/（4ファイル） ├── S_詳細設計/（7ファイル） └── execution_management/ ├── sprint_plans/sprint6.md ├── phase1_issues.md ├── project_epics.md ├── project_dashboard.md └── project_roadmap.md なぜMarkdownなのか？ ファイルベースなので、LLMがコンテキストを取得しやすい 相対リンクで、ファイル間の関連性をLLMが自動理解できる Git管理により、変更履歴を追跡できる grep による高速全文検索が可能 2. 「進捗を更新して」というトリガーワードで自動処理 次に、Cursor（AIエディタ）のルール機能を使って、自動化フローを定義しました。 なぜLLMなのか？ Git管理のMarkdownに集約された全体の文脈を横断的に理解できる 関連ドキュメントを自動収集し、依存関係を把握して不足情報だけ質問できる 叩き台の生成と整合性検証を自動化し、人はLLMと壁打ちしながら仕上げに集中できる 「進捗を更新して」と入力すると、以下の処理が自動実行されます： 実際の動作例 ※以下は実際の出力を読みやすく簡略化したものです。 私: 進捗を更新して Claude: ╔══════════════════════════════════════════════════════╗ ║ 📊 進捗更新の自動処理を開始 ╚══════════════════════════════════════════════════════╝ ┌──────────────────────────────────────────────────┐ │ 🗂️ ステップ1: エビデンス確認結果 ├──────────────────────────────────────────────────┤ │ A.現状分析（5個全完了） │ ├─ p01_a_01_high_level_kpi_analysis.md ✅ │ ├─ p01_a_02_stakeholder_hearing_summary.md ✅ │ ... │ │ D.データ要件（1個） │ └─ p01_d_01_data_sources_list.md ✅ └──────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────┐ │ 📈 ステップ2: 進捗率算出 ├──────────────────────────────────────────────────┤ │ 完了Sub-issue数: 17 → 18（+1） │ 全Sub-issue数: 54 │ │ 進捗率 = (18 / 54) × 100 = 33.3% │ 進捗バー: ███░░░░░░░ 33.3% └──────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────┐ │ 📝 ステップ3: 5ファイル同時更新 ├──────────────────────────────────────────────────┤ │ 1️⃣ sprint6.md ✅ 更新完了 │ 2️⃣ phase1_issues.md ✅ 更新完了 │ 3️⃣ project_epics.md ✅ 更新完了 │ 4️⃣ project_dashboard.md ✅ 更新完了 │ 5️⃣ project_roadmap.md ✅ 更新完了 └──────────────────────────────────────────────────┘ ✅ 進捗更新処理が完了しました 3. エビデンスベース管理 進捗の判定は「実ファイルが真実」という哲学に基づいています。 そのため、あらかじめ生成される成果物のファイル名や置き場所などを決めておく必要があります。 タスク一覧： - A-1: API設計書 → ファイルあり、ただし [WIP] タグ付き - A-2: DB設計書 → ファイルあり ✓ - A-3: 画面設計書 → ファイルあり ✓ - A-4: テスト計画書 → ファイルあり ✓ - A-5: 運用手順書 → ファイルなし（未着手） LLMの判定：「WIPは除外、未着手1個、実際は60%完了」 → 進捗率 = 完了数（3） ÷ 全体数（5） × 100 = 60% → 成果物ベースの進捗把握で進捗率を明確化 推測や自己申告を排除し、実成果物ファイルの存在で作業完了を判定します。 効果：体感で成果物作成時間が50%削減、そして仕事の質が変わった Before（従来の方法） 10:45 要件定義を開始 - 「前提となる仕様、どこだっけ？」 - 「前に決めた内容、何だっけ？」 - 複数のツールやドキュメントを確認（30分） 11:15 材料が揃って、ゼロから文書を書き始める - 構造を考えながら、内容を練り上げる（4時間） 15:15 レビュー依頼 - レビュー指摘を受けて、修正対応 17:15 初稿完成（合計6.5時間） After（LLMとの協働） 11:00 「タスクCに取り組んで」と指示 11:05 LLMがタスクの本質を理解・必要情報を一覧化（5分） - 「このタスクの目的は〇〇ですね」 - 「必要な情報：A, B, C。不足：Dを教えてください」 11:10 不足情報を提供（20分） 11:30 LLMが叩き台作成（5分） - 関連ドキュメント自動収集済み - 7割完成の初稿を生成 11:35 LLMと壁打ちしながらじっくり詰めていく（2時間30分） - 私：「UIの表示項目これで全部？」 - LLM：「〇〇の観点が抜けています。追加しましょうか？」 - 私：「エラーハンドリングのパターンは？」 - LLM：「A, B, Cの3パターン。それぞれメリット・デメリットは...」 14:05 最終調整（10分） 14:15 高品質な成果物が完成！ Before: 6.5時間 After: 3.25時間 - 50%削減、しかも品質向上 ！ 体感的に変わったこと 指標 Before After 変化 進捗更新作業 手動で5分～30分 LLM作業10分～30分＋人の確認1分～5分 50%削減 成果物作成 人10割 LLM叩き台5～7割＋人仕上げ3～5割 50%削減 視点の網羅性 人の経験に依存 多角的な視点で抜け漏れ減 抜け漏れ減 ※ 上記の50%削減は体感ベースであり、タスクの性質によって削減率は変動します。 削減率が高かったタスク（60-80%削減） ： 一般的な知識で構成されるタスク テンプレート化・パターン化しやすい LLMの事前学習データに豊富な事例がある 例：技術調査、API設計書作成、一般的なテスト計画書 削減率が低かったタスク（20-40%削減） ： 組織固有の知識が必要なタスク LLMに与えるコンテキストが膨大 人間の判断・確認が必要 例：既存システムの設計意図の理解、複雑なビジネスロジックの要件定義 その他の副次効果 Markdown集約による「組織の記憶」は、進捗管理と成果物作成以外にも、様々な場面で価値を発揮します。 1. コンテキストを渡さずに、即座に壁打ちができる ※以下は実際の出力を読みやすく簡略化したものです。 私: 機能Xのユーザー認証、どう実装すればいい？ Claude: S-1で決定した認証方式を使用してください 【認証方式】 - JWT + OAuth 2.0（Google認証） - トークン有効期限：24時間 【実装制約】 - 共通ライブラリ：@/lib/auth.ts を使用 - エラーハンドリング：共通形式（S-7：ログ・エラー設計） 【依存関係】 - ログイン機能：完了済み - API仕様：S-3（API設計）に記載 LLMが過去の意思決定（S-1で決定した認証方式）を記憶しているので、すぐに実装方針がわかります。 2. 属人化の排除 「組織の記憶」があることで、特定メンバーへの依存が最小になります。 ※以下は実際の出力を読みやすく簡略化したものです。 私: 担当メンバーが突然退職することになった。 引き継ぐため機能Xの実装状況を把握したい。 Claude: 機能X（ユーザー認証）の進捗状況 【完了したIssue】 ✅ N-1: セキュリティ基盤設計（100%完了） - Cloud IAP + NextAuth.js設計 - 決定日: 2025-09-15（CTO承認済み） 【次のIssue】 🟡 N-2: ユーザー認証機能実装（進捗 60%） ✅ 完了: LoginForm基本実装 ⏳ 残タスク: エラーハンドリング実装 従来では、担当者のアサイン変更時に情報の引き継ぎに時間がかかっていました。 LLMによる組織の記憶があれば、即座に状況を把握し、スムーズに作業を引き継げます。 3. 思考の深まり（LLMとの壁打ち） 下準備（情報収集・構造化）をLLMに任せることで、本質的な思考に集中できます LLMと壁打ちすることで多角的な視点を獲得できます（要件の漏れ、エラーハンドリング、セキュリティ等） 一人では気づかなかった観点をLLMが補完してくれます 結果：最大の価値は時間削減ではなく品質向上にあります 運用してわかったこと 始めるのは簡単だが、期待通りに動かすには それなりの試行錯誤が必要でした プロンプトの調整、ルールの修正を何度も繰り返す必要がある しかし、一度作れば継続的に価値を生み出し続ける 長期的な投資対効果が初期の手間を上回る まとめ この記事では、「進捗を更新して」で進捗管理が自動化され、LLMとの壁打ちで成果物作成が効率化される仕組みを紹介しました。 実現の基盤となる3つのポイント 1. Git管理のMarkdownに集約 LLMが「組織の記憶」として機能 関連ドキュメントを自動収集・整理 進捗管理と成果物作成の両方を支える基盤 2. 自動化ルール（トリガーワード） 「進捗を更新して」で5ファイル同時更新 Sprint期限超過の自動検出 3. エビデンスベース管理 実成果物ファイルの存在で進捗を判定 推測や自己申告を排除 得られた効果 事務作業の負荷が半減し、品質は安定化 創造的な仕事に時間を使え、アウトプットの質が向上 LLMは「外部のツール」から「内部のチームメンバー」に変化 最後までお読みいただき、ありがとうございました！

MLOpsエンジニアの tomoppi です。 データエンジニアリング部 データサイエンスグループ（以下、DS G）に所属し、ML/LLM基盤の構築・改善に取り組んでいます。 概要 2025年4月、タイミーPlatform EngineerのMoneyForestさんが、 「タイミーにおけるProduction Readiness Checkの取り組み」 という記事を公開しました。サブシステムや新規サービスのリリースに際しての評価基準を定めたもので、MLOpsとしても参考になる部分が非常に多くありました。 その記事に触発され、DS Gとしても再現性高くLLM Applicationを構築・運用するための評価基準を定めたいと思うようになり、本記事で言及する Production Readiness Checklist for LLM Applicationの策定に至りました。 背景 2024年以降、DS Gでは複数のLLMを活用したプロダクト開発に取り組んできました。しかし、前述のチェックリストをDS Gが構築・運用する LLM Applicationに適用しようとすると、以下のような課題に直面しました。 AWS前提で書かれているため、DS Gで利用しているGoogle Cloud用に読み替える必要がある LLM特有の非決定性への考慮が必要 継続的評価やGenerative AI ライフサイクルの観点が不足している チェックリスト策定の方針 技術に依存しない普遍的な原則と、タイミーDS Gでの具体的な実装に基づいたガイドの2部構成としました。 理由としては、現在はCloud Runをベースとした運用となっていますが、将来的にGKEの採用やECSへの移行などが十分に可能性としてあるためです。 また、RAG、Agentic Workflow、tool useなどのより高度なLLM利用は対象外としました。 それらを利用するアプリケーション設計・構築の際は、本記事で紹介するチェックリストを土台とし、新たにより専門性の高いチェックリストやそれに準ずる評価基準を設ける想定です。 ビジネス目標に関してはスコープアウトすることも考えましたが、ROIは大事にしていきたいというDS Gの意思として入れ込むことにしました。 チェックリスト 0. 戦略的目標とビジネスアライメント LLM導入の目的と期待される成果を明確にします。 0-1. ビジネス目標の明確化 [ ] 測定可能なビジネスゴール（コスト削減率、顧客満足度向上、処理時間短縮等）が設定されている [ ] ユースケースに対する期待される精度・応答速度が定義されている 0-2. 成功指標（KPI）の設定 [ ] ユースケース固有のKPIが定義されている [ ] KPIの測定方法とダッシュボードが整備されている 1. 安定性・信頼性 システムを再現可能かつ自動化された方法でデプロイ・運用できるようにします。 1-1. 構成管理 [ ] すべてのコードがバージョン管理システムで管理されている [ ] プロンプト（システムプロンプト、テンプレート等）がバージョン管理されており、変更履歴が追跡可能（監査可能）な状態になっている 1-2. CI/CD [ ] Lint、単体テスト、セキュリティスキャン（静的解析）がCIパイプラインで自動化されている [ ] 開発(dev)、ステージング(stg)、本番(prod)環境へのデプロイがCDパイプラインで自動化されている 1-3. リリースプロセス [ ] プロンプトやモデルの変更が、ステージング環境で品質評価を実行した後に本番にデプロイされるプロセスになっている [ ] カナリアリリースや段階的ロールアウトで、主要メトリクス（エラーレート、精度、コスト）を監視しながらリリースされる仕組みが確立している 1-4. LLM選定と継続性 [ ] 利用モデルのSLA/SLOを踏まえたフォールバック戦略が定義されている プライマリLLM APIが利用不可時のフォールバック先（別モデル/静的レスポンス/エラー表示） リトライポリシー（回数、待機時間、指数バックオフ等） タイムアウト設定 [ ] モデル非推奨・廃止のスケジュールを把握しており、利用不可能になる前にモデルを更新するプロセスが確立している 2. スケーラビリティとパフォーマンス トラフィックの増減に対応し、効率的なリソース利用を目指します。 2-1. キャパシティプランニング [ ] コンテナ実行環境でオートスケーリングが設定されている [ ] 利用するLLM APIプロバイダーのレート制限（TPM: Tokens Per Minute / RPM: Requests Per Minute）を把握し、自システムのキャパシティプランに反映されている プロバイダー側の制限値を文書化 制限値を超えないための流量制御（レートリミッター）の実装 2-2. トラフィック・トークン管理 [ ] ビジネス要求の変化に伴うトラフィック増加とその影響について、ステークホルダーと認識を揃えている [ ] リリース時点で必要なスループットと、システムの最大許容スループットを算出している [ ] 1セッションあたりの消費トークン数の見積もりを算出している 入力トークン数（プロンプト + ユーザー入力 + コンテキスト） 出力トークン数（予想される生成テキスト長） 3. 耐障害性と大惨事対応 システムの一部が故障しても、サービス全体が停止しないようにします。 3-1. 障害シナリオ [ ] 想定される障害シナリオが洗い出され、文書化されている LLM API障害（タイムアウト、5xx エラー、レート制限超過） 依存サービス障害（データベース、外部APIなど） ネットワーク障害 リソース枯渇（メモリ、CPU、ディスク） [ ] 各障害シナリオに対応したRunbook（対応手順書）が作成されている [ ] 障害発生時の影響（ビジネス損失、ユーザー影響等）を見積もっている [ ] LLM API起因による長時間の回復困難な障害が発生した場合の対応方針についてステークホルダーと合意されている 3-2. LLM APIの可用性 [ ] システム要求（即時性、UX等）とLLM APIの可用性を踏まえたLLM処理コンポーネントの呼び出し方式（同期/非同期）が選択され、システムアーキテクチャに反映されている。 [ ] LLM API障害時のフォールバック・リトライ戦略が実装されている エラー種別ごとのリトライ可否判定（429はリトライ、4xxの多くはリトライ不可等） Exponential Backoffによるリトライ間隔の調整 Circuit Breakerパターンの導入（連続失敗時に一時的にリクエストを停止） [ ] LLM APIの冗長化が検討され、必要に応じて実装されている 複数のLLMプロバイダーまたは複数のモデルを利用可能にする フェイルオーバーの仕組みを実装 3-3. 回復性テスト [ ] 負荷テストを実施し、想定トラフィック下での挙動を確認している [ ] 主要な障害シナリオを再現させた際、その障害が検知・アラートされることを確認している（カオステスト） 4. 安全性 LLMが生成する有害なコンテンツや不適切な振る舞いを防ぎます。 4-1. リスク分類とインシデント対応 [ ] ユースケースに合わせた安全性リスク分類が定義されている 例: 誤情報、バイアス、プライバシー侵害、非倫理的なアドバイス、有害コンテンツ（ヘイトスピーチ、暴力的表現等） [ ] 安全性に関するインシデント発生時の対応プロセス（Runbook）が定義されている インシデントの検知方法 エスカレーションフロー 緊急時の対応（プロンプトの切り戻し、機能の一時停止等） 4-2. ガードレール [ ] 安全性リスク分類がガードレールのルールに反映されている [ ] 入力ガードレールが実装されており、以下を検知・ブロックできる プロンプトインジェクション攻撃 不適切なトピック（暴力、ヘイト、性的コンテンツ等） 機密情報（PII等）を含む入力 [ ] 出力ガードレールが実装されており、モデルが生成した以下のコンテンツをユーザーに届ける前に検知・フィルタリングできる 有害コンテンツ（ヘイトスピーチ、暴力的表現等） 機密情報（PII、APIキー等） 明らかなハルシネーション（事実と異なる情報） [ ] ガードレールで検知された違反はすべて記録されている 4-3. Red Teaming [ ] 定期的なレッドチーミング（敵対的テスト）が計画・実行されており、新たな脆弱性を継続的に探索するプロセスが確立している ジェイルブレイク（システム制約の回避） 巧妙なプロンプトインジェクション 複数ターンにわたる対話での安全性回避 5. 監視 システムの状態を可視化し、問題に迅速に対応できるようにします。 5-1. アプリケーションロギング・トレーシング [ ] アプリケーションログが構造化ログ（JSON等）で出力されている [ ] リクエストごとに一意のIDが生成され、ログとトレースに出力されている 分散トレーシング対応（トレースID、スパンIDの伝播） 上流サービスから受け取ったIDを継承 [ ] APM（Application Performance Monitoring）ツールでエンドツーエンドのトレースが可能になっている 5-2. 可視化とアラート [ ] 主要メトリクスを一覧できるダッシュボードが整備されている システムメトリクス: CPU、メモリ、リクエスト数、レイテンシ ビジネスメトリクス: 利用回数、成功率、ユーザー満足度 LLM固有メトリクス: トークン消費量、API利用料金、エラーレート [ ] サービスレベル指標(SLI)と目標(SLO)が定義されている 例: 可用性 99.9%、P95 レイテンシ < 3 秒、エラーレート < 1% [ ] SLO違反やシステム異常（エラーレート急増やリソース逼迫）時にアラートが発報される [ ] LLMガードレール違反検知数や検知率をダッシュボードで確認できる [ ] LLMガードレールにより検知された違反を重大度に応じてアラート通知する仕組みが確立している 5-3. LLM Observability [ ] LLM APIへのリクエストが分散トレーシングシステムと統合されており、同一リクエスト内のLLM呼び出しがスパンとして関連づけられている [ ] LLM APIへのリクエスト単位で以下の情報がトレース可能になっている 入力プロンプト（機密情報をマスキング済み） 出力レスポンス（機密情報をマスキング済み） 利用モデルとパラメータ（temperature、max_tokens等） レイテンシ（TTFB: Time To First Byte、全体レスポンス時間） 消費トークン数（入力/出力） 概算コスト [ ] トークン消費量とコストの急増を検知するアラートが設定されている 6. 品質保証(QA)と評価プロセス LLMの出力品質と安定性を客観的に担保します。 6-1. オフライン評価セット [ ] LLM出力を評価するためのデータセット（ゴールデンセット）が定義・管理されている 代表的なユースケースをカバーする入力と期待される出力のペア データセットの保存場所と管理方法が明確 [ ] エッジケース、既知の失敗パターン、敵対的入力を評価するデータセットが定義・管理されている 6-2. オフライン評価指標 [ ] タスクの目的に沿った具体的な評価指標が定義されている 分類タスク: Accuracy、Precision、Recall、F1-score 生成タスク: BLEU、ROUGE、人手評価（流暢性、正確性、関連性） 安全性: 有害コンテンツ検出率、PII漏洩率 6-3. オンライン評価 [ ] 本番環境での評価項目について導入の必要性を検討し、適切に導入している Direct Feedback: ユーザーからの明示的なフィードバック（👍/👎等） Functional Correctness: 生成結果が機能的に正しいか User Acceptance: ユーザーが結果を採用したか（コピー、編集、実行等） Achieved Impact: ビジネスKPIへの影響 Incidental Metrics: レイテンシ、エラーレート、コスト等 6-4. 継続的改善 [ ] 評価データセットを継続的に更新するための仕組みが整っている 本番トラフィックから評価データセットへのサンプリング 失敗ケースの追加プロセス [ ] 評価データセットのバージョン管理がされている [ ] プロンプトバージョン・モデルバージョン・評価データセットバージョン・パラメータを1単位として評価結果を管理する仕組みが整っている 実験管理ツールで各バージョンの組み合わせと評価結果を記録 6-5. 自動テスト [ ] LLM API呼び出しを含む主要なE2Eテスト（正常系）が自動化されている [ ] プロンプトやモデル変更時に、品質評価セットを用いた回帰テストが自動化または半自動化されている [ ] 負荷テストが自動化または半自動化されており、リリース前に負荷テストを行う基準がチーム内で合意されている 7. セキュリティとコンプライアンス 不正アクセスやデータ漏洩、意図しないモデルの振る舞いを防ぎます。 7-1. データ保護 [ ] LLMへの入力データのうち、PII等のセンシティブ情報が分類され、マスキング対象が特定されている 分類基準（例: PII、機密情報、公開情報）が定義されている マスキング対象のデータ種別（例: 氏名、メールアドレス、電話番号、住所等）がリスト化されている [ ] 転送中および保存データが暗号化されている 転送中: TLS/HTTPS 保存時: ディスク暗号化、データベース暗号化 7-2. プロンプトインジェクション対策 [ ] プロンプトインジェクション対策として、多層防御の仕組みが実装されている 入力検証・サニタイゼーション プロンプトテンプレートの使用（ユーザー入力を直接連結しない） 出力の検証・パース [ ] ユーザー入力とシステム指示が明確に分離されている システムプロンプトとユーザー入力の役割分離（system role / user role） 7-3. アクセス制御 [ ] LLM APIの認証に、長期的なAPIキーやサービスアカウントキーを使用せず、一時クレデンシャルによる認証方式を利用している [ ] APIへのアクセスが適切に認証・認可されている ユーザー認証（必要に応じて） リクエスト元の検証 7-4. モデルのリスク管理 [ ] ユーザー入力がLLMの学習データとして利用されないよう設定されているか、リスクが評価・受容されている LLMプロバイダーのデータ利用ポリシーを確認 オプトアウト設定（必要に応じて） [ ] 社内のモデル利用ポリシーに沿って利用モデルを選定している [ ] Open‑weightモデルを利用する場合、Pickle形式ではなくsafetensors形式を利用している 8. ドキュメントと組織運営 チームメンバーがシステムを理解し、スムーズに運用できるようにします。 [ ] システム概要・システム構成図・依存関係図が最新の状態に保たれている [ ] 主要なアラートへの対応手順（Runbook）や障害対応プロセスがドキュメント化されている [ ] 障害発生時のインシデント対応プロセスが定義されており、インシデント発生後のポストモーテム（振り返り）を実施し、再発防止策を講じるプロセスが確立している タイミーでの実装ガイド 本ガイドは、上記チェックリストを踏まえ、DS Gの技術スタック（Google Cloud、Datadog等）を踏まえた具体の実装例に落とし込んだものです。 1. 安定性・信頼性 構成管理 コード管理 : Git（GitHub）でコード管理 プロンプト管理 : Gitでプロンプトファイルを管理、またはプロンプトバージョニング機能を持つツールを使用 CI/CD CI : GitHub ActionsでLint・テスト・SASTを実行 CD : GitHub ActionsからGoogle Cloud（Cloud Run）へ自動デプロイ リリースプロセス 段階的ロールアウト : Cloud Runのトラフィック分割機能、またはリリース管理ツールを使用 2. スケーラビリティとパフォーマンス キャパシティプランニング オートスケーリング : Cloud Runの「最大インスタンス数」「最小インスタンス数」「同時実行数（concurrency）」を設定 3. 耐障害性と大惨事対応 回復性テスト 負荷テスト : Locustを負荷テストツールとして使用 4. 安全性 ガードレール 違反記録 : 構造化ログまたはDatadogイベントとして記録 5. 監視 アプリケーションロギング・トレーシング APM : Datadog APM（Cloud Runのサイドカーに datadog/serverless-init を設定） 可視化とアラート ダッシュボード : Datadog Dashboard、Looker アラート : Datadog Monitor、Slack連携 LLM Observability LLM監視 : Datadog LLM Observability 6. 品質保証(QA)と評価プロセス オフライン評価セット データセット管理 : Datadog LLM ObservabilityのDatasets機能の利用、またはBigQuery・GCSをベースとしたデータセットのバージョン管理 継続的改善 実験管理 : MLflow、Datadog LLM Observability 7. セキュリティとコンプライアンス アクセス制御 認証 : Workload Identity Federation（GCP）等 モデルのリスク管理 タイミー社内の基準を満たすモデルを利用している 振り返りと今後の取り組み これまでDS Gでは、データサイエンティスト中心のCSチーム（Complicated Subsystem Team）とMLOps（Platform Team）がCollaborationモード（Embedded SREに近い形）の関わり方で、LLMアプリケーションの構築・運用に取り組んできました。これは初期の知見蓄積と開発のアジリティ確保の点で、不可欠で有効なものでした。 しかし、今後サービスが増加するにつれ、この密な連携体制が組織全体のスケールのボトルネックになる懸念がありました。そうした課題を乗り越えるため、MLOpsチームは、CSチームが高速に高品質なアプリケーションを構築できるようなゴールデンパスの整備を進めています。 今回のチェックリスト作成は、その一つの取り組みとして知見を整理し、また現状の課題を再認識するものになったと考えています。 今後DS Gでは、RAGやAgentic Workflowのような、より複雑性の高いアプリケーションの構築や、LLM Gatewayといった基盤導入が控えています。 そうした複雑な課題に対し、CSチームとMLOpsチームがそれぞれの強みを発揮し、協調しながらスケールしていける体制が不可欠だと考えています。 本チェックリストの活用・改善を含め、常により良い協業の形を模索し、再現性高く信頼性のあるML/LLMアプリケーションによる価値創出にチャレンジしていきたいと思っています。

こんにちは！株式会社タイミーでアナリティクスエンジニアをしているひろろと、データエンジニアをしているつざきです。 本記事は、二人の共同執筆という形式でお届けします！ 現在、私たちはアメリカ・ラスベガスで開催されているdbtの祭典 「Coalesce 2025」 に現地参加しています！ Coalesce 2025 は、年に一度世界中のdbtユーザーが集まり、機能アップデートや事例発表、ハンズオンなどが行われるdbtの技術カンファレンスです。 当社ではデータ基盤にdbtを採用しているため、最新技術のキャッチアップを積極的に行っています。Coalesceへの参加もその一環として決まりました。 ※アーキテクチャのついて詳しくは こちら また、今回はカンファレンス参加支援制度 「KaigiPass」 を利用して参加しております！ 速報を現地の熱気とともにお届けします。ぜひご覧ください。 Day 1 初日には有料のトレーニング中心で、夕方からカンファレンスのキックオフとウェルカムパーティーが開催されます。 キックオフでは近くにいる人との自己紹介タイムがあり、最初は焦りましたが、みんな技術者同士。英語が苦手でも温かく受け入れてもらえる優しい雰囲気でした。 Coalesceのイベント内容や会場案内などを中心に紹介され、これから始まるセッションへの期待が高まる良い時間でした。 （決してモーニングやランチが出ることに喜んでいるだけではありません笑） キックオフの後は、ウェルカムパーティーの開催です！立食パーティーの形式で実施され、パートナーブースで話を聞いたり、他の来場者との会話を楽しんだりできます。 同じ日本人の参加者とも交流することができ、データに関する話題で盛り上がりました。日本開催のカンファレンスとは違い、日本人が少ない分、数少ない日本人同士で仲間意識が芽生え、より深い話ができたように感じます。 また、パートナーブースの方も熱気がすごく盛り上がっていました。日本で開催されるカンファレンスよりも、皆さんのテンションが高いです。実際にブースへ行ってみてデモをみせてもらうだけでもためになります。どのブースにもAIという文字が記載されているのが印象的でした！ Day2 初日はKeynoteや数多くのセッションに参加しました。セッションの数がとても多いため、吟味するのがとても大変です。また、ランチの時は同じテーブルに座った方が気兼ねなく話しかけてくるので、そこでの会話も貴重な時間でした！ Opening Keynote Keynoteはホテル内のシアター会場で行われました。前方席に座ったのですが、両サイドのスクリーンにリアルタイム字幕が表示されていたため、後方の方が見やすかったと後で気づきました。 Opening Keynoteでは「 Rewrite 」というキーワードが繰り返し登場し、印象的でした。dbt LabsのCEO、Tristan Handy氏をはじめとした登壇者たちが、AI時代におけるデータワークの再定義について語りました。 まず大きな話題として取り上げられたのが、Fivetranとの合併についてです！前日の10/13に発表されたばかりのため、この場で話を聞けることを楽しみにしていたのが、歓声から伝わってきます。 その流れで呼ばれたのが、FivetranのCo-Founder & CEOであるGeorge Fraser氏。Fivetranのコネクタバグ修正の話から始まり、dbtに対して初めは懐疑的だったが変わっていったこと、dbtをAIが今後重要となっていく中で将来性や相互運用性が合併の背景としてあること、dbtへの破壊的な変更はないことなどをトーク形式で語っていき、dbtユーザーを安心させ一緒にdbtを盛り上げていきたいという気持ちがとても伝わる内容でした。 次に、Metric Flowついて大きな発表がありました。 MetricFlowは、dbt Labsが提供するメトリクス管理の製品です。今回、Apache 2ライセンスでのオープンソース化が発表され、会場から大きな拍手が起こりました。 「ベンダーロックインが懸念で導入に踏み切れなかった」という声も多く、まさにその課題に応える発表でした。 参考URL： https://www.getdbt.com/blog/dbt-labs-affirms-commitment-to-open-semantic-interchange-by-open-sourcing-metricflow その次に語られたのが、 dbt Fusion エンジン になります。 dbt Fusionエンジンは「Rewrite Developer Experience」をテーマに、開発体験の抜本的な刷新を目指した機能群として紹介されました。 実際のデモでは、従来より最大30倍のコンパイル高速化や、CTEプレビュー・カラムレベルのエラー検知などが披露され、歓声が上がる場面もありました。 機能についての詳細は 公式ドキュメント をご覧ください。 SDF Labsの共同創業者で、dbt Fusionエンジンのプロダクトリーダーを務めているElias DeFaria氏によるライブデモでは、dbt Fusionエンジンがもたらす多くの開発支援機能が実際に披露され、会場からは何度も歓声が上がりました！ 「Column rename propagation」など機能が発表される度にドヤ顔をしている担当者を近くで見られることは現地参加の醍醐味ですね！ 特に、新たに発表された「Compare changes」は、変更を本番環境に適用する前にデータへの影響を確認することができます。本番にマージしてからデータがおかしくなってしまっていることに気がつく、といった肝が冷えるやらかしを削減できる素晴らしい機能だと思いました！ 次に発表されたのは、State-aware orchestration です。 State-aware orchestrationは、Fusionの機能を活かしたインテリジェントな実行制御機能です。依存関係の入力データが変更されたモデルのみを再構築することで、無駄な再実行を防ぎます。 発表によると、この機能を有効化するだけで約10%のコンピュートコスト削減が見込まれるとのことです。（すごい！） また、State-aware orchestrationのさらなる最適化として、Tuned configurationが紹介されました。 Tuned configurationでは、ユーザーは「Freshness要件の宣言」をすることができ、年間コンピュートコストを少なくとも29%削減できる見込みが示されました。 dbt内部ではこれらの最適化を導入することで最終的に64%もコストを削減できたとのことです。すごすぎる！ そして、最後に発表されたのがdbt Agentsです。 dbt Agentsでは4つの新しいサービスが発表されました。 サービス名 　機能・コメント 状態 Developer Agent (開発者エージェント) 変更内容を記述するだけで、エージェントがそのタスクを実行し、SQLファイルの作成、テスト、ドキュメント化を自動で実行してくれるとのこと！アツイ！ 近日公開 Observability Agent (可観測性エージェント) パイプラインの障害箇所を特定し、修正を支援してくれるエージェントです。これによってトラブルシューティングに費やす時間を削減しアラートの削減につながることが期待されます 近日公開 Discovery Agent (発見エージェント) カタログやドキュメントから承認済みのデータセットと定義を識別し、なぜそのデータが信頼できるのかを示します。ただの検索ではなく信頼性の高いデータを見つけるまでの時間が削減できるとのことです ベータ版 Analyst Agent (アナリストエージェント) 会話型分析（conversational analytics）の構築を支援し、複雑な質問に対してガバナンスされた回答を提供してくれるとのことです ベータ版 全てのAgentが、データ分析開発における「あったらいいな」を実現できる機能のように思えました。特に個人的には、Developer Agentは、テキストで指示するだけで自律的に実装を行ってくれる、おそらくDevinのような開発体験ができるのかなと感じていて期待が膨らみます。 まとめ 本記事では、Coalesce 2025の現地の様子とOpening Keynoteの内容を中心に紹介しました！ dbt LabsとFivetranの合併、Metric FlowのOSS化、Fusionエンジンによる高速化、State-aware orchestrationによるコスト最適化など、「Rewrite（書き換え）」というテーマにふさわしい革新が詰まったセッションでした。 今後、残りのセッションで各機能の詳細や導入事例を調査し、続報をお届けする予定です。ぜひご期待ください！

はじめに こんにちは！今回は（ @arus4869 、 @yoshi_engineer_ ）の2人で執筆しました！ この記事では、私達のチームが『スプリントゴールで価値を駆動しよう』 という書籍の輪読会をきっかけに、形骸化しがちだったスプリントゴールを 「チームの羅針盤」 として機能させ、スプリントの達成率を 体感値で50%から80%に向上させた具体的な実践記録をご紹介します。 この記事は、特に以下のような課題を感じている方に読んでいただきたいです。 スプリントゴールが「タスクリスト」になりがちで、なぜやるのか（Why）やどんな価値が生まれるのか（Outcome）が曖昧になっている。 スクラムを実践中で、スプリントゴールの質に悩んでいる。 ステークホルダーやチームメンバーと機能の話はできても、 「価値」についての会話 がしづらい。 なぜこの本を選んだのか 私達のチームも、まさに上記のような課題に直面していました。 スクラム開発を長く続けているものの、いつしか「フィーチャーファクトリー」のようになり、スプリントゴールが単なるタスクリストになっていました。チームとしてやりたいことが多すぎて常にバックログを積みすぎる傾向があり、「レビューで何を学んだか」をアウトカムで語ることが難しく、アウトプットの話に終始しがちでした。 この「なんとなくこなすだけ」の状態を脱却したい。そんな思いで、スプリントゴールを考え直すヒントを与えてくれそうな本書を、輪読会のテーマとして選びました。 そもそもスプリントゴールとは何か？ スプリントゴールはなぜ設定されるのか知っていますか？私は説明することができませんでした。 スクラムガイドでは以下のように定義されています。 スプリントゴールはスプリントの唯⼀の⽬的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。スプリントゴールはまた、⼀貫性と集中を⽣み出し、スクラムチームに⼀致団結した作業を促すものでもある。 スプリントゴールは、スプリントプランニングで作成され、スプリントバックログに追加される。開発者がスプリントで作業するときには、スプリントゴールを念頭に置く。作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。 スプリントゴールはスプリントの 唯一の目的 。 スプリントにおいて、この目標を達成することこそが大本命なわけです。 では、その重要性を深ぼっていきましょう。 スプリントゴールがなぜ必要なのか？ スプリントゴールの重要性、まず挙げられるのは「チームの思考をタスクベースの 「アウトプット」から、ユーザーに提供する「アウトカム」へと転換 させる」ことです。 チームは 「ユーザーへの価値の提供」を本来の目的として行っています。実際のチームを稼働していく際に、いつの間にかタスクリストのみを指針として作業を進んでしまう 可能性があります。 例えば、「ユーザー登録画面の実装」や「データベース登録処理」といったタスクの羅列だけでは、開発者はなぜその作業を行っているのか、その作業が最終的にどのようなユーザー価値に貢献するのかがチームメンバーが共通して理解しにくい場合があります。 スプリントゴールがあることで、ユーザーに届けたい価値,アウトカムがタスクと連結して、一つの具体的なインクリメントを生み出すという明確な意図が共有されます。 このようにチームは 「タスクの進捗」 だけでなく、 ゴールへの貢献度 を常に意識できるようになり、より良い意思決定と協調性を生み出す。 スプリントゴールの効能 スプリントゴールがチームに対してもたらす効能は他にもあります。それは 「集中」 と 「一貫性」です。 チームに明確なゴールがなければ、チームはプロダクトバックログアイテム（PBI）がスプリントバックログに含まれる場合、それぞれのPBIが独立した作業として捉えられ、チームがばらばらに作業するリスクがあります 。このような状況では、チームとしての協調性が生まれず、特定のPBIを担当する個人が孤立したり、作業の詰まりが発生したりする可能性があります 。 スプリントゴールは、これらのPBIを「なぜ我々はこれらを同時に進めるのか」という 共通の目的に集約します 。共通の目的を持つことで、チーム全員が同じ目標に向かって努力し、一体感を高めることができます。 これにより、チームメンバーは 「ゴール達成のために誰かを助ける」 という動機付けが生まれ、協力して問題を解決する姿勢が自然に育まれます。個々のタスクの完了ではなく、チーム全体のゴール達成に焦点を当てるという、スクラムの本質を体現します。 良いスプリントゴールを建てるために ここでは タスクベースのゴール設定 と 状態ベースのゴール設定 についてお話しします。タスクベースのゴールでは、チームメンバーが「自分のタスクが終わらなかった」という個人の反省に終始し、ネガティブな内省に陥りやすい可能性があります。 スプリントゴールを「モヤモヤが解消された状態」や「特定の価値が提供された状態」といった「状態」ベースで設定すると、チームはプレッシャーから解放され、より前向きな振り返りがしやすくなります。 また、ゴールが未達成であっても、チームは 「なぜその状態に至らなかったのか」という根本的な原因を客観的に分析する ことができ、これを次のスプリントでの改善点として捉えることができます 。 このようなプロセスは、チームメンバー間の信頼関係を深め、失敗を学習の機会と捉える健全な文化を醸成します。スプリントゴールの達成に向けて互いに助け合う習慣は、 チーム全体の協力体制を強化 し、 個々のモチベーションを維持する 上で重要な役割を果たします 。 スプリントゴールを駆動して成功の鍵として活用していくために スプリントゴールが単なるタスク管理ツールではなく、 チームの集中力、柔軟性、そして価値創出を最大化するための不可欠な要素 です スプリントゴールを 「タスクのリスト」 から 「成果を示す羅針盤」 へと進化させることで、 チームは「何をするか」から「何を成し遂げるか」へと意識を変えることができます。 何を実践したのか（輪読会での取り組み） 輪読会での学びを元に、私達は以下の3つの具体的なアクションをチームに導入しました。 1. スプリントゴールの「決め方」を合意形成のプロセスに変えた これまで曖昧だったスプリントゴールの決め方を、チームで合意を形成するための明確なプロセスに変更しました。具体的には、スプリントプランニングで以下のステップを踏んでいます。 全員でスプリントゴール案を1つ考える： まず、POだけでなくチーム全員でスプリントゴール案を出します。 自信度の可視化と投票： そのスプリントゴール案に対して、達成できる自信度を各自が表明し、参考情報として投票を行います（多数決でスプリントゴールを決めるわけではありません）。 対話と議論： なぜその自信度なのか、なぜその案が良いと思うのかを全員で対話し、納得解を探ります。 「FOCUS」で最終チェック： 最後に、そのスプリントゴール案が良いゴールの特性（※）を満たしているか、チームでチェックし、最終決定します。 ※FOCUSとは？ 良いスプリントゴールの特性を示した頭字語。Fun（楽しい）, Outcome-based（アウトカムベース）, Collaborative（協調的）, Ultimate（究極的）, Singular（単一）の5つの観点。 このプロセスにより、スプリントゴールが「誰かが決めた目標」から「自分たちが合意した目標」に変わりました。 2. 「やること」を勇気をもって絞り込んだ 過去の私達は、スプリントゴールに集中できずに品質を低下させたり、ゴール自体を達成できない経験がありました。本から「同時に多くの作業に取り組むことは、協働を妨げ、価値提供を減少させる」 という原則を学び、輪読会中にチームの 合意として以下のルールを決めました。 「スプリントプランニングでスプリントバックログに入れるのは、スプリントゴール達成に直接貢献するPBIだけにする」 これにより、チームのエネルギーが分散することなく、全員がゴール達成に集中できるようになりました。 3. レビューで「データ」を語ることを始めた 価値（アウトカム）を意識するため、スプリントレビューで関連するプロダクトのダッシュボードを参加者で見ることから始めました。まだ道半ばですが、これにより会話が「何を作ったか（Output）」から「それによって何が変わりそうか（Outcome）」へと少しずつシフトするきっかけになっています。 やった結果どうだったか（輪読会の成果） これらの取り組みの結果、チームには明確な変化が生まれました。 スプリントゴール達成率が向上： あくまで体感値ですが、スプリントゴールの達成率は 約50%から80%へと向上 しました。 プランニングの質が向上： 「このPBIはスプリントゴール達成にどう繋がるんだっけ？」という問いかけが自然に生まれ、バックログ選択の迷いが減少しました。 デイリースクラムの会話が変わった： 単なる進捗報告ではなく、「スプリントゴールを達成するために、今日は〇〇をしようと思う」といった、ゴールを意識した会話が中心になりました。 参加者の声 輪読会の参加者の声を抜粋します。 総合的に輪読会に参加して良かったという感想になりました。 「不確実性への対処」における説明やそれに対するソリューションが大変学びになった。 一人で読むとインプットだけで終わりがちですが、チームですぐに実践できるのが輪読会の良いところだと感じました。 FOCUSは一つのHOWに過ぎないと思いつつ、輪読会から具体的なアクションが生まれたのはとても良いな〜と思いました。 価値提供を重視し、FOCUSの考え方でゴールを打ち立てることが本を通じて印象に残りました。 まとめ 今回の輪読会と実践を通して、私達は重要な学びと気づきを得ることができました。 経験からの学び： 良いスプリントゴールとは、優れた文章以上に、 チームで『何に集中し、何を顧客に届けるのか』を合意するプロセスそのもの でした。 気づき： チームが共通のゴールに集中することで初めて、 日々の行動が価値ある「得点」に繋がる のだと気づきました。 この記事で紹介した私達の「スプリントゴールの決め方プロセス」が、その一助となれば幸いです。 最後までお読みいただき、ありがとうございました。

こんにちは、iOSエンジニアの大塚、山崎、早川( @hykwtmyk )、前田( @naoya_maeda ) です。 2025年9月19-21日に有明セントラルタワーホール＆カンファレンスで開催されたiOSDC Japan 2025に、タイミーもゴールドスポンサーとして協賛させていただきました。 イベントは以下のように、3日間連続で行われました。 9月19日（木）：day0（前夜祭） 9月20日（金）：day1（本編1日目） 9月21日（土）：day2（本編2日目） 私たちもイベントに参加したので、メンバーそれぞれが気になったセッションや感想をご紹介します。 大塚 編 先日、iOSDC Japan 2025に参加しました。今年は会場が例年とは異なり、カンファレンス全体の雰囲気にいつもと違った新鮮な印象を受けました。私は毎年iOSDCに参加していますが、日々の業務や自己学習だけでは触れる機会の少ない、高度でニッチな領域の知識を集中的に得られる点が、本カンファレンスの最大の魅力だと感じています。本レポートでは、その中でも特に印象に残った「金融サービスの成長を支える "本人確認フロー" の改善と取り巻く環境の変化」のセッションについてご報告いたします。 概要 セッションは、1. 本人確認フローの改善と2. 法令改正など取り巻く環境の変化についての発表でした。 1. 本人確認フローの改善 前半は、JPKI方式を用いた本人確認の実装戦略についての解説でした。リードタイムを短縮するため、マイナンバーカードの読み取りおよび電子証明書の検証といった機能は、外部ベンダーが提供する SDK を用いて実装しているそうです。一方で、ユーザーが直接触れるUI部分はあえて自社で開発するという戦略を採っています。UIを自社で開発することで、離脱率を改善するための様々な実験的な施策をスピーディーに導入し、その最適化のメリットを享受されているそうです。 2. 法令改正など取り巻く環境の変化 後半は、金融サービスを取り巻く犯収法などの法令改正がいかにアプリ開発に影響するかについてです。特にJPKIの署名用電子証明書を用いる方式やカード代替電磁的記録を用いる方式など、外部環境の変化にエンジニアがどう対応すべきかに焦点を当て解説されていました。 感想 私が所属するチームで担当している本人確認フローに関する発表だったため、特に強い関心を持って拝見しました。他社ではどのようにJPKI方式を実装し、離脱率の改善という難しい課題に対し、どのような観点で技術やプロダクト設計の選択を行っているのかを具体的に知ることができ、大変勉強になりました。 山崎 編 iOSDCは今回初めて参加させていただきました! 初参加だからこそ感じた現地の熱気やセッションの感想などをレポートします。ちなみに、私はday0とday2の2日間参加しました。 day0：カンファレンスの熱気に触れる day0ではまず、プレオープニングセッションに参加し、iOSDCの歴史やコミュニティの成り立ちについて知ることができました。多くの開発者の情熱によってこの素晴らしい場が作られていることを知り、参加できることへの感謝の気持ちで胸がいっぱいになりました。 その後は、弊社の岐部さん（ @beryu ）の発表を応援しに行ったり、興味のあるセッションをいくつか拝見しました。どれもレベルが高く、知的好奇心を強く刺激される内容ばかりでした。 day2：ブースでの交流 day2では、弊社のブースに立ち、たくさんの参加者の方々とコミュニケーションを取らせていただきました。 私たちのブースでは、「最近うまくいったこと」をテーマに付箋を書いてもらう、という企画を実施していました。これをきっかけに会話が弾み、「最近、SwiftUI化がうまくいったんです」「AIをこう活用して業務改善しました」といった具体的なお話をたくさん伺うことができました。特にAI活用のトピックは多くの方の関心事のようで、他社さんのユニークな取り組みを聞けたのは大きな収穫でした。 心に残ったセッション 業務で直接関わる機会の少ない領域でのセッションを機会が多かったのですが、どれも新鮮で非常に面白かったです。 手話ジェスチャーの検知と翻訳~ハンドトラッキングの可能性と限界~ fortee.jp Apple Vision Proでの立体動画アプリの実装と40の工夫 fortee.jp プログラマのための作曲入門 fortee.jp 「iPhoneのマイナンバーカード」のすべて fortee.jp 特に、Apple Vision Pro関連のセッションは、従来のアプリ開発とは異なり、3D空間上でUIやUXをいかに自然に見せるかという点に多くの工夫が凝らされており、大変興味深かったです。オブジェクトを空間に違和感なく配置することの難しさを改めて感じました。 マイナンバーカードの話は、実際にどのようなAPIが使われているのかという技術的な解説が非常にためになりました。アプリ内、対面、ブラウザの3種類のVerifier APIの具体的な使い方やユースケース、さらにはmdocのデータ構造や日本のために作られたAPIの紹介など、普段は知ることのできない実装の詳細に触れることができ、とても貴重な体験でした。 SwiftコードバトルとLT大会の熱気 Swiftコードバトルは、制限時間内に要件を満たすプログラムを、Swiftでいかに短く書くかという競技で、緊張感のある中、参加者の方々のコーディングスピードと発想力に圧倒されました。 LT大会は、参加者がサイリウムを振って会場全体が一体となる、ライブのような賑やかな雰囲気でした！特に印象的だったのは、課金周りのLTが続いた時間帯です。各社それぞれの知見や工夫が凝縮されており、とても勉強になりました。 初めてのiOSDCは、技術的な学びはもちろん、何よりもコミュニティの温かさと熱量を肌で感じられる最高の体験でした。ブースでの交流、刺激的なセッション、そしてユニークな企画までとても熱狂感のある素晴らしいイベントでした！ 早川 編 タイミーでiOSエンジニアをしている早川です。 一昨年ぶりにiOSDC Japan 2025にオフライン参加してきました！今年から会場が変わり、またいつもと違う雰囲気でしたね（個人的には、自宅から近くなったので嬉しいです）。 さて、いくつかのセッションを聴講した中で、特に学びが多かったのが、デスクスさんが発表された「 5000万ダウンロードを超える漫画サービスを支えるログ基盤の設計開発の全て 」です。 speakerdeck.com 大規模サービスにおけるログ基盤という、普段なかなか知ることのできない領域について、詳細なコードベースでの解説や実践的な知見が共有されており、多くの学びがありました。本記事では、発表内容の要点と特に印象に残った点についてまとめていきます。 発表の要点 1. 新ログ基盤「Tracker」の設計思想と特徴 パフォーマンスと柔軟性の向上を目的とし、モダンな技術スタックを全面的に採用。Swift 6の Sendable に準拠した設計をベースに、並行処理による高いパフォーマンス、gzip/deflateによるデータ圧縮、そしてモバイル環境の不安定なネットワークを考慮したExponential Backoffによる堅牢なリトライ戦略が主な特徴として挙げられていました。 2. Clean Architectureによる責務の分離 アーキテクチャにはClean Architectureを採用。Entity、Use Case、Data Layer、Public Interfaceを明確に分離することで、各コンポーネントが独立して機能し、テスト容易性や変更容易性が格段に向上したとのことでした。これにより、全体で80%以上という高いテストカバレッジも実現していました。 3. Firebase Remote Configを活用した安全な移行戦略 Firebase Remote Configをフラグとして利用し、旧基盤と新基盤を並行稼働させ、いつでも切り戻しが可能な状態で段階的に移行を進めるという、非常に現実的でリスク管理に優れたアプローチが紹介されました。 特に印象に残った点・感想 この発表では、ログ基盤というテーマに留まらず、大規模なモバイルアプリ開発全般に役立つ知見が随所に見られました。 ログの送信自体はユーザーの目に見えない部分ですが、メインスレッドをブロックしない、メモリを圧迫しないといった ユーザーファーストな視点 と、テスト容易性を高めるアーキテクチャ設計や高いテストカバレッジといった 開発者としてのこだわり が見事に両立されており、まさにユーザーと開発者の双方にとって「Win-Win」な内容だと感じました。 また、Firebase Remote Configの活用法も非常に印象的でした。特に「 将来的に全体公開する前提のConfigは、デフォルト値をtrueにしておくことで、移行完了後にConfigを削除できる 」という知見は、私自身も過去に逆の設計で失敗した経験があるからこそ、大変共感しました。 このように、自身の業務でもぜひ参考にさせていただきたい学びの多い、素晴らしい発表でした。 前田 編 僕は今年が二回目のiOSDCへの参加でした。今回も幅広いジャンルで興味深いトークがたくさんありました。その中で、僕が最も面白いと感じたセッションは、 かっくん さんの「独自UIで実現する外部ストレージデバイスの読み書き」でした。 fortee.jp 偶然なのですが、ちょうどこのトークの前日に、僕が個人的に調査を始めたトピックでした。 僕にとってはすごくホットなトピックだったこと、デモを交えた聴講者を惹きつけるトークが魅力的に感じたのでこちらのトークを選びました。 このトークは、iPhoneで撮影した写真や・ビデオデータを外部ストレージに直接保存する方法を紹介する内容です。まだ情報自体が少ないこともあり、Appleのエヴァンジェリストの方と一緒に調査を進めて、実装を実現したエピソードを交えたトークになります。 iPhoneのカメラで撮影した写真や・ビデオデータを保存する場所や方法は、大きく2パターンが用意されています。 一つ目の方法は、iPhoneのストレージに保存する方法ですね。こちらの方法は最もよく知られており、サンプルコードも豊富で難易度はそこまで高くありません。 PhotoKit フレームワークを使用することで、10行程度のコードで実現することができます。 zenn.dev 二つ目の方法は、iPhoneに接続している外部ストレージに保存する方法です。こちらの方法は、さらに2パターンに分かれています。 一つ目の方法は、 UIDocumentPickerViewController または、.fileExporter モディファイアを使用する方法です。これらのAPIを使用することで、データを外部ストレージに保存することができます。しかし、これらの方法では、ユーザーにデータの保存先を選んでもらう必要があります。ユーザーは、データの保存先を選択することができるメリットがある一方、ユーザーの操作数を増やしてしまうことになります。 そこで今回のトークで登場したAPIが、 AVExternalStorageDevice です。iOS 17から使用可能な比較的新しいAPIです。このAPIと関連APIを使用することで、iPhoneに接続している外部ストレージに、データを直接保存できます。実装コストも高くなく、数十行程度のコードで本機能を実現できることを知れて、僕にとっては学びが多いトークでした。 本トークでは、実際に会場で撮影した写真を、iPhoneに接続されている外部ストレージに直接保存し、保存したデータ一覧を表示するといったデモもあり、楽しくトークを聴くことができました。 最近では、高ストレージ端末を除いては、ProRes Logデータを撮影する時に外部ストレージとの接続が必須になってきています。今後、外部ストレージ接続が必須になる機能が増えるかもしれない状況になる可能性もあるので、さらに深掘りを進めてみたいと思います。 最後に この3日間を通して技術的な知見を深めたり、久しい友人に会って話をすることができ、すごく有意義な時間を過ごせました。この場を用意してくださったiOSDCスタッフの方々、参加者のみなさん本当にありがとうございました！ 上記で紹介したセッション以外にも非常に興味深いセッションが多くありました。 記事にある内容や、その他の内容についても、もしタイミーのエンジニアと話したいという方がいらっしゃればぜひお気軽にお話ししましょう！

タイミーの江田、徳富、神山、亀井、桑原、志賀です。 KaigiPass という制度を利用して Kaigi on Rails 2025 に参加してきました。タイミーは昨年に引き続きスポンサーをさせていただき、今年はなんと幸いなことにブースも出させていただきました。今回はそんな Kaigi on Rails 2025 の参加レポートを KaigiPass を利用したメンバーで記述していこうと思います。 2分台で1500 examples 完走！爆速 CI を支える環境構築術 Hiroshi Tokudomi https://kaigionrails.org/2025/talks/falcon8823/#day1 「2分台で1500 examples 完走！爆速 CI を支える環境構築術」というタイトル通り、CI をどのように高速化していくかについての発表でした。 弊社でも現在 self-host runner を使って GitHub Actions 上で CI を回しており、2 万 2 千件のテストを平均 9〜10 分程度で実行しています。CI は短ければ短いほどいいものなので、このセッションタイトルを見たときに「これは絶対に見に行こう」と思ったのですが、まさに期待通り参考になる内容でした。 テストを並列に分割して実行する方法として Knapsack Pro が紹介されており、自分たちが使っている split-test と比較しながら聞くことができました。Knapsack Pro は実行時間の履歴をもとに分割を最適化できるとのことで、今後検討してみたいと思います。 また、EBS の I/O がボトルネックになることで CI が遅くなる話も印象的でした。弊社でも CI 実行が重なると I/O 使用率がギリギリまで上がることがあり、tmpfs を使うことで改善できる可能性があるのでは、とワクワクしながら聞いていました。 ちょうど最近 CI 基盤を self-host runner に移行したばかり（ 参考 ）ということもあり、「次はどこをチューニングできるか」と考えていたタイミングでのセッションだったので、個人的にはかなり刺さりました。CI をどう速くするかは日々の開発体験に直結するテーマなので、今回の学びを持ち帰って改善につなげていきたいです。 https://speakerdeck.com/falcon8823/2fen-tai-de1500exampleswan-zou-bao-su-ciwozhi-eruhuan-jing-gou-zhu-shu-kaigi-on-rails-2025 dynamic! Keisuke Kuwahara https://kaigionrails.org/2025/talks/moro/#day1 https://speakerdeck.com/moro/dynamic 1日目のキーノート「dynamic!」は、静的なアプローチとは対照的に、最初から完璧なゴールを目指すのではなく、継続的に変化していくプロセスを重視するテーマでした。 セッションでは、開発を細かく進めるための第一歩として、「ハッピーパス」の実装が重要だと強調されていました。ハッピーパスとは、ユーザーが使える「最小限かつ最もシンプルな機能」のことであり、これをまず実装することで、早い段階でフィードバックを得て、改善サイクルを回すことが可能になります。 特に印象的だったのは、開発者だけでなく、チーム全体で変化を起こしていくという考え方です。私自身、複雑な機能を実装する際、最初からすべてを網羅しようと時間をかけた結果、いざデモをしてみると多くのフィードバックをもらった、という経験があります。その時はできるだけ指摘をもらわないように実装しよう、という気持ちになっていましたが、今回の話を聞いて、動くものをいち早くチームメンバーやステークホルダーに確認してもらい、早くフィードバックを得ることの重要性を再認識しました。 またこれまでは、優秀なエンジニアほど、一発で完璧なプロダクトを作るものだ、と漠然と思っていましたが、実際は逆でした。経験豊富なエンジニアほど、最小限の開発から始め、段階的な改善を積み重ねていくのだと気づきました。 アジャイル開発は今のチームでは当たり前になっていますが、「動的に変化し続けること」の重要性を改めて深く感じました。完璧主義にとらわれて最初の実装に時間をかけるのではなく、変化を恐れずに、その時々で最もシンプルな方法を実践していきたいと思います。 「技術負債にならない・間違えない」 権限管理の設計と実装 Akitoshi Shiga https://kaigionrails.org/2025/talks/naro143/#day2 https://speakerdeck.com/naro143/ji-shu-fu-zhai-ninaranaijian-wei-enai-quan-xian-guan-li-noshe-ji-toshi-zhuang Webサービスにおいて頻出の課題である権限管理に対して、自社のプロダクトで行った取り組みを発表されていました。 権限管理のありがちなアンチパターンとして、権限の判定が必要な場所で操作者の役割を判定するような実装についてあげられていました。 例: あるControllerのcreateアクション内で if admin? 役割を判定する場合は、判定する箇所が役割ごとに何ができるかを把握する必要があります。 役割ごとの権限は、サービス内容や事業環境の変化が激しい状況においてはすぐに複雑化します。 その上、この実装では権限を変更するたびに、すべての判定箇所に手を加えなければいけません。 その結果としてすぐに保守が困難になります。 そこで、役割=何者であるかではなく権限=何ができるか に依存すること、その上で、権限管理に必要な要素である「対象」「操作」「役割」「条件」に対する記述を分離・明文化した設計を発表されていました。 具体的には、module分けした「対象」ごとに「役割」のクラスを作り、「操作」に紐づいたメソッド内で「条件」を判定する実装を行っていました。 これによって、対象ごとに役割が操作を行うための条件が非常にシンプルになりました。 https://speakerdeck.com/naro143/ji-shu-fu-zhai-ninaranaijian-wei-enai-quan-xian-guan-li-noshe-ji-toshi-zhuang?slide=64 その結果、カスタマーサポートやプロダクトマネージャーがGitHubでコードを読んで理解できるようになり、社内からのエンジニアへの権限に関する問い合わせが0になったそうです。 所感として、操作する対象が増えるたびにすべての役割のクラスを作成する必要があるものの、条件というコアなロジックは一箇所に集中されるので保守しやすそうだと感じました。 また、権限という複雑なビジネスロジックを非エンジニアが理解できるほどシンプルにコードで表現されていることに感銘を受けました。 複雑なビジネスロジックにちゃんと向き合ってシンプルな表現を目指すことの効果と大切さを今一度実感しました。 Railsによる人工的「設計」入門 Yutaka Kamei https://kaigionrails.org/2025/talks/nay/#day1 亀井です。万葉の大場さんのこちらのセッションが素敵だなと思ったので、このセクションを書かせていただいています。私なりにこの発表を解釈すると、設計がうまくなる方法について深掘りした内容だったのかなと思います。この AI 時代にコーディングを AI に任せることは増えてきた中で、人間が設計をできることの重要性がとても高まっています。そんな中で、どのようにしてもっとうまく設計ができるようになるのか？というのをご自身の偶然の経験から形式知にしてまとめてくださった内容でした。 完成したシステムを思い浮かべてそこから「逆算」して考えていくとよいのではないか？というのが重要そうでした。私の経験でも、ゴールを思い浮かべてそこに至るまでのマイルストーンを描きステップを重ねるというやり方がよいのではないか？ということを 思っていた ので非常に納得感があります。まさに全体から部分へ、という思考を行うことによってうまく設計ができる、という考え方ですね。たしかに、 Ruby on Rails が MVC をベースにしたフレームワークだからといって、モデル→コントローラー→ビューという順番に書く必要もないですし、むしろその順番で書くと全体が見えない状態で開発をすることになるので、次第につぎはぎだらけのコードが生成されてしまいます。その場しのぎのコードになってしまうと、やはりそれはそれで今後のメンテナンス性に影響してくるわけです。あるべき状態、あるいは本質的なゴールを描いてそこから「逆算」する、という考え方の言語化がとても素敵でした。 また、名付けの重要性について語っておられたのもよかったですね。 Ruby 界隈では「名前重要」というのはよく知られていると思いますが、設計の上でなぜ名付けが重要なのか？ということについての言語化もクリアでわかりやすかったです。たしか、コードのレベルではなく、抽象度の高いレベルで短い名前をつけながら考えを進めて「デザインパーツ」を取捨選択し「仮置き」することが重要というようなこともおっしゃっていたと思います。「仮置き」というワーディングがよいですね。たしかに、「決定」というと後戻りができない感じがしますが、「仮置き」というのは「変更の余地があること」を示唆する感じがして、日本人としてこういう日本語表現を利用できるのはとてもラッキーだなと思います。そういえば、「仮置き」で思い出しましたし、このセッションで参照されたキーノートの dynamic! にもあったように、オプショナリティーについて言及が最近増えましたね。「仮置き」という用語にもオプションというニュアンスを感じます。『Tidy First?』を読んで私なりにオプションについて理解をしているつもりでしたが、こうしていろいろな登壇を聞いて私なりの解釈もそこそこあってそうな予感がしてうれしさを感じています。みんな Kent Beck が好きですよね。私もです。 今改めてServiceクラスについて考える 〜あるRails開発者の10年〜 Yuki Eda (edy) https://kaigionrails.org/2025/talks/joker1007/#day1 Ruby on Railsでアプリケーション開発に従事しているエンジニアであれば一度は通るであろうServiceクラス。2025年のこのタイミングでjokerさんがこのタイミングで発表を行う理由も気になり視聴しました。 冒頭で歴史的な経緯を含めて日本国内で布教した背景の考察や、『パーフェクトRuby on Rails』にてServiceクラスを題材に執筆された当時の意図、執筆後数年経ってからの[Qiitaでのエントリ]( https://qiita.com/joker1007/items/25de535cd8bb2857a685 )などに触れられつつ、Serviceクラスに対しては出来る限り使わない方が良いと結論づけられていました。理由は「開発統制の困難さを上回るメリットが得られない」とのこと。 この点、私も思い当たる節はあり、例えばFat Modelを解消する手段としてServiceクラスを選択していた過去があります。適切な命名付けをしたとしても、アプリケーションの成長や数年間の運用の過程で特定のドメインだけの処理で留まらずに肥大化したトランザクションスクリプトになる傾向があると思います。これはjokerさんも言及されていた「基準の作りにくさ」から来る部分や、適切なドメインモデリングを怠った結果の2つが大きな原因だと、発表を聞きながら改めて考えさせられました。 結局のところ、ビジネスにおける関心事を顧客やチームメンバーを交えながらシステム内でうまい具合に表現できるするか、その丁寧な抽象化と具体化の繰り返し作業が大事で、Serviceクラスもそうですし対抗馬として挙げられることの多いFormクラスも含めて、デザイン方法は表現技法の一つに過ぎないということですね。 発表の末尾のスライドの「正解はない、一緒に考え続けましょう」「ソフトウェア設計は継続的な営み」が非常に印象的で心に留めておきたいと思いました。 履歴 on Rails : Bitemporal Data Modelで実現する履歴管理 Daichi Kamiyama - dak2 https://kaigionrails.org/2025/talks/hypermkt/#day2 https://speakerdeck.com/hypermkt/history-on-rails-with-bitemporal-data-model 直近で履歴を残すかどうかの設計に頭を悩ませたことがあり、Bitemporal Data Model での履歴管理の良し悪しが気になったので、拝見させてもらいました。 履歴テーブルのパターンとして参考になるのは、一休さんの https://user-first.ikyu.co.jp/entry/history-table このスライドが非常に参考になると思っています。普通に“履歴”という概念を表現するのであれば、このスライドの内容に沿って場合分けしていけば多くの場合は網羅できるんじゃないかと思っています。 ただ、SmartHR さんが扱うドメインとして “従業員を起点とした変化” に向き合っていく場合、「あとから分かった出来事も正しい日付で反映したい」というニーズがあるようです。確かに言われてみればそうですよね。 レコードとして有効な期間（ex. 2025/09/26 までに役職が部長だった）と、操作時間の2つの時間軸で履歴を管理するコンセプトが Bitemporal Data Model です。有効な期間だけだと、そのレコードがいつ登録/無効になったかの事実が抜け落ちるので、2つの時間軸で管理しようという話のようです。 パッと直感的に思ったのは2つの時間軸を考慮しないといけないので、考えることが掛け算で増えてしまう懸念を持ちました。SQL も複雑になりそうですしね。後から有効な期間を追加したい場合に、有効期間が重複してはいけないと思うので、そこの制約を Model のバリデーション、Database の制約ともに考慮する必要はあるんだろうなとか。 スライドでも想定外の履歴データが作られていることがあり、原因調査に丸一日かかったという言及がされていました。基本的に INSERT されるはずなので、そこから問題となっているデータを特定するのに時間がかかるというのはあるんだろうなと。activerecord-bitemporal gem では visualizer 機能があり、レコードの履歴を可視化してくれるそうです。 有効期間の日付管理が timestamp だと時分秒の管理があるから、date 型に変更して運用容易性を担保したという話も興味深かったです。この部分で意図しないレコードが生まれるケースはありそうだなと思っていたところ、 https://tech.smarthr.jp/entry/2025/09/12/115617 も拝見し、まさにその問題があったようですね。“履歴の一括出力後、Excelで適用日を編集するとExcelの仕様で時分秒の情報が「00:00:00」に丸められてしまう”、“例えば部署マスターの更新、並べ替え、削除、従業員部署の登録、更新などでは多数のモデルが同一トランザクションで更新されます。 このとき、適用日の時刻を固定して揃えないと、処理タイミングの僅かなズレによって適用日が秒未満の精度で異なった履歴が作成されてしまう” 、“同一適用日の更新において、社員番号と適用日の組み合わせでレコードを特定する際、ユーザーから秒未満を切り上げた日時を受け取り、秒未満を考慮して対象の履歴を探す” などなど、かなり負の側面を抱えていたようです。大変な移行だったようですが、とても意味のある移行だなと思いながら拝見しました。date 型だと unique 制約によって重複を弾きやすくなりますしね。 “履歴” を表現する1つの手段として Bitemporal Data Model を使ったリアルな声が公開されているのは、本当に嬉しいですね。とても参考になる話を聞けました。今後モデリングする際は、1つの手段として頭の片隅にインデックスを貼っておこうと思いました。 Kaigi on Rails 2025 に参加したタイミーのメンバー

こんにちは! タイミーでデータアナリストをしているtakahideです。 突然ですが、「この事業を成功させるにはどうすれば？」といった、ふんわりと大きなテーマを渡されて、「さて、どこから手をつけようか...」 と悩んだ経験はありませんか？ タイミーでも、今後より会社の重要課題に関わる分析プロジェクトが増える中で、こうした上流の課題を見つけ、精度の高い仮説を立てる力、いわゆる「課題発見・仮説思考力」の重要性が高まると考えています。 本記事では、「仮説向上プロジェクト」での取り組みを元に、複雑な課題を構造化し、具体的なアクションに繋げるための思考整理術をご紹介します。 この記事が、同じように課題発見に悩む方々の助けに少しでもなれば幸いです。 「知っている」と「できる」の壁 思考のプロセスを可視化する「仮説向上プロジェクト」 思考整理の「3つのステップ」 1. 「問い」から「5W1H」への整理 2. 「5W1H」から「Flywheel」への落とし込み 3. 「Flywheel」から「定義」の再整理へ 今後の展望:思考プロセスをAIを用いてスケールさせる We’re Hiring! 「知っている」と「できる」の壁 これまでもデータアナリティクス部では、事業部のメンバー向けに仮説構築の勉強会を開いてきました。1回目は仮説のタネから仮説の木を育てる「仮説構築」の全体像を、2回目では論理を整理するための「便利な道具 (フレームワーク)」について行いました。 おかげで、チーム内で「仮説」という言葉の目線は一定揃ったのかな、と思っています。一方、知識として「知っている」ことと、実践で「使いこなせる」ことの間には、思った以上に大きな隔たりがありました(当たり前ではありますが、、)。 思考のプロセスを可視化する「仮説向上プロジェクト」 そこで、この壁を乗り越えるために、実験的な「仮説向上プロジェクト」を立ち上げました。 このプロジェクトの目的は、とてもシンプルです。 「問いを立てる力を引き上げること」。 分析の精度は、最初の「問い」の質でそのほとんどが決まってしまいます。MECE (モレなく、ダブりなく) やロジックツリーといったフレームワークといった調理器具を使う前に、「そもそもどの食材をどう料理するべきか?」 という「見立てる力 (素材の目利き)」を鍛えることにフォーカスしてみました。 具体的には、会社としての重要テーマを題材に、メンバーと1on1形式でディスカッションを重ねました。この抽象的なお題を、どう整理し、具体的な分析テーマに落とし込んでいくか。その思考プロセスを繰り返しました。 思考整理の「3つのステップ」 この実験的な取り組みを数回繰り返す中で、手応えのある思考整理のプロセスが見えてきました。 1. 「問い」から「5W1H」への整理 すべては、一つの大きな「問い」から始まります。特に会社の重要課題につながるような抽象的な問いの場合、そのままでは、どこから手をつければ良いか判断がしづらいです。 そこで、まずは問いを具体的な要素に分解することで、その後のプロセスがスムーズに進むことが分かりました。 特に、5W1Hは問いを具体化する初期段階において、シンプルですが便利なフレームでした。 Who (誰が) まず、「誰にとっての成功なのか?」を定義します。特に私たちのようなプラットフォーム事業では、関わるプレイヤーが複数存在します。例えば、「ワーカー」と「事業者」です。 What (何を) 次に、この新しい事業が「具体的に何を価値として提供するのか」を、それぞれのプレイヤーの目線で定義します。 Why (なぜ) そして、それぞれのプレイヤーが「なぜ、提供された価値に関心を持って、関わりうるか？」という動機を深掘りします。提供者が抱える「不安定さへの不満」や、利用者が感じる「既存サービスへのコストや品質面の課題」など。 一つの問いを様々な視点から分解していくことで、漠然としていたテーマの輪郭が見えてきます。チーム全員の目線を合わせ、分析のブレをなくすための最も重要な土台作りと考えています。 2. 「5W1H」から「Flywheel」への落とし込み 5W1Hで事業の構成要素を洗い出したら、次に行うのがFlywheel (はずみ車)への落とし込みです。 Flywheelとは、事業を「一度回れば自律的に成長していくサイクル」として捉えるための思考ツールです。「何がどう作用して、次のどんな結果に繋がるのか？」 という一連の因果関係のループとして可視化することで、事業成長のエンジンがどこにあるのかを特定しやすくなります。 私たちのようなプラットフォーム事業を例に考えてみます。 1. まず、事業の成長を促すためのアクションがあります。例えば、マーケティング施策や営業活動によって、ワーカーの集客を強化したとします。 2. プラットフォーム上のワーカーが増えると、人材を探している事業者にとっての魅力が増し、「ここなら良い人が見つかりそうだ」と事業者の利用が増加します。 3. 事業者の利用が増えれば、仕事の募集件数も増えます。 4. 仕事が増えることで、ワーカーはより多くの就業機会を得ることができ、満足度が高まります。 5. 満足したワーカーがリピートすると、事業者の満足度にも繋がります。満足した事業者は継続的に利用し、さらに多くの仕事を募集してくれます。 このように、「ワーカーの増加 → 事業者の増加 → 仕事の増加 → ワーカーの満足度向上 → 事業者の満足度向上 → さらなるワーカーと事業者の増加...」 というように、片方の満足がもう片方の満足を呼び、雪だるま式に事業が成長していく好循環が生まれます。 この図を描いて共通認識を得ることで、「このサイクルのどこにエネルギーを注げば、最も効率的に全体を加速させられるのか?」 という、事業戦略の勘所が見えてきます。 3. 「Flywheel」から「定義」の再整理へ 最後のステップは、Flywheelで事業全体のサイクルを俯瞰しながら、もう一度最初の問いに立ち返る、「定義の再整理」です。 5W1Hで各要素を分解し(点の理解)、Flywheelでそれらの因果関係を繋ぎ合わせる(線の理解) ことで、事業を一つの動的なシステムとして捉えられるようになります。この視点を持つと、当初ぼんやりと設定していた言葉の定義が、より解像度の高い、具体的なものに変化していることに気づきます。 特に、求められている「成功」が「Flywheelのどの部分を、どのように回すことなのか?」という問いに変わります。 「短期的な売上」を成功とすれば、新規獲得やマッチング率といった回転数を上げるための分析に集中します。 一方、「長期的な成長」が成功であれば、リピート率や評価といった質を高め、遠心力を強めるための分析に注力します。 このように、抽象的な言葉が、具体的な指標やアクションと結びつきやすくなります。 このステップを行うことで、分析が向かうべきゴールが明確になり、その精度が高まると思います。 今後の展望:思考プロセスをAIを用いてスケールさせる 今後は、本プロジェクトで得られた知見を基に、AIとの対話を通じて同様のワークが誰でも実現できる仕組みを作りたいと考えています(例えば以下のようなものを想定しています)。 1. 分析したい「問い」をAIに入力する 2. AIが対話形式で分析テーマをサポートする 3. 仮説を選択・編集する 4. 最終的な分析プランが提案される 私たちの挑戦はまだ始まったばかりです。データから価値を生み出すために、これからもアナリスト自身の「考える力」を磨き続けていきたいと思います。 We’re Hiring! タイミーのデータアナリティクス部では、ともに働くメンバーを募集しています！！ カジュアル面談 も行っていますので、少しでも興味がありましたら、気軽にご連絡ください。

はじめに タイミーでAndroidエンジニアをしているふなちです。 本記事は、 「DroidKaigi 2025 参加レポート〜Part 1〜」 の記事の続きになります！ まだPart 1を読んでないよ！と言う方は、ぜひPart 1も読んでいただけると嬉しいです。 本記事（Part 2）では、Part 1から続いてエンジニアメンバーによるセッションレポートと、タイミーのブース出展の様子をお届けします 📣 エンジニアによるセッションレポート nakagawa 紹介するセッション： Gemini エージェントで Android Studio 開発を高速化 タイミーではdroidkaigiでブースを出しており、多く方に足を止めていただくことができました。 ブースに立っている中で初日にどこか見覚えのある方がいらっしゃり、「お会いしたことありましたっけ？」と聞いてみたら、特に面識はないとのこと… 翌日に聴講したセッションでその方が登壇しており、その時に気づきました。 「あの人、YouTubeのGeminiでE2Eテストの動画に出てた人だ！！」 www.youtube.com セッションではYouTubeで見て未来に思いを馳せていたGeminiが自然言語で記述されたテストを実行するJourneyのライブデモを見ることができ、ちょうど当日にAndroid Studio Canaryでリリースされたばかりとのことでした。 デモでは日本語で記述して実行結果のスクリーンショットとその結果とその根拠をテキストで出力しており、メンテナンスコストが低いE2Eテストの実装ができそうだと感じました。 後にAsk the speakerに質問をしにいき、見覚えがあった理由の話もしたのですが、「彼はYouTube Famousだからね」と一緒に登壇されていたMandaさんも笑っていました。 「CIで動くようになるのはいつですか？」と伺ったところ、絶賛開発中とのことでした、期待です。 DroidKaigiから帰ってさっそくタイミーのプロジェクトで試してみましたが、まだ動かなそう…？Build Logic使っているせいか、まだうまく読めてないような気がしていますが、まだしっかりとは見れていません。安定的に使えるようになったら実際の運用で使えるか試してみたいと思いました。 murata（ @murata ） 紹介するセッション： Cache Me If You Can RyuNen344さんによる「Cache Me If You Can」は、多くのAndroid開発者が"何となく"で使ってしまいがちな Gradleのキャッシュ機構 に深く迫るセッションでした。 私自身、Gradleはブラックボックス同然で、ビルドエラーが起きるたびにStack Overflowを彷徨う…そんな場当たり的な対応を繰り返していました。このセッションは、そんな私のGradleに対する苦手意識を打ち破る、まさに目から鱗の内容でした！ セッションで得た知識を元にさっそくプロジェクトのGradle設定を見直したところ、ビルドパフォーマンスにつながる以下の改善を実現できました。 Configuration Cacheと並列実行の有効化 （ org.gradle.configuration-cache.parallel=true ） 環境変数を参照していた System.env() を Provider API に置き換え 通常のビルドでは不要なタスクを提供するプラグインの適用方法を最適化 これまではConfiguration Cacheが効かずに頭を悩ませることも多々ありましたが、今ではこのセッションで学んだ知識を武器に、自信を持って原因を調査できる気がしています👍 「Gradleのビルド遅いな…でもよくらからないから後回し！」となっている、そこのあなた！ ぜひ本セッションのアーカイブ動画を視聴して、一緒にGradleの世界を切り拓いてみませんか？😊 スポンサーブースも大盛況でした🎉 DevRelのみーた（ @earlgrayMK ）です。 今回タイミーではゴールドスポンサーとしてブースを出展しました。 多くの方にお立ち寄りいただき、ありがとうございます！ スキマバイトとしてアンケートのお仕事をみなさんにお願いし、たくさんの回答をいただいたのでご紹介します。 みなさんのご投票の結果、Android開発において最も困難だと感じられているのは、「既存コードベースの保守・改善」と「OSバージョン・デバイスの多様性」であることが明らかになりました。 この根深い課題に対して、タイミーのAndroidエンジニアがどのように向き合っているのか、具体的な取り組みをまとめました。 1. OSバージョン・デバイスの多様性への対応 自動テストの活用 テスト自動化ツール「MagicPod」を導入し、サポート対象OSの上下限バージョンで毎日テストを実行。広範囲の環境を効率的にカバーしています。 多様な物理デバイスでの検証 外部のQAチームや、クラウド型検証サービス「RemoteTestKit」を活用。さらに、社内Slackで特定端末を持つメンバーに協力を仰ぐなど、物理デバイスでの実機検証を徹底しています。個人的に折りたたみスマホを購入し、検証に活かす開発者もいます。 2. 既存コードベースの保守・改善 進捗の「見える化」と「仕組み化」 リファクタリングの進捗をLinterのwarning数やモジュールの分割状況などで定量的に可視化し、チーム全体で課題意識を共有する仕組みを重視しています。デザインシステムの構築やEdge-to-Edge対応もその一環です。 プロダクトオーナー（PO）との共通理解 技術的負債の解消がプロダクトの価値向上に不可欠であるという点をPOと共有。これにより、計画的なリファクタリングを実現しています。 適切なエンジニアリソースの確保 リソース不足が負債の蓄積と開発の悪循環を招かないよう、Androidエンジニアの適切なリソース確保に努めています。 バランスの取れた技術選定 新技術の導入時は、必ずその妥当性をチームで議論し、合意形成を図ります。これにより、将来の負債化を防ぎ、技術的なバランスを保っています。（この領域では、特にエンジニアの村田が重要な役割を担っています。） 高いサービスレベル目標（SLO）の維持 プロダクトの品質目標を高く設定し、それを維持する文化が、コードベースの健全性を保つ動機付けにもなっています。 両課題に共通する、タイミーの強み 厚いチーム体制 チームメンバーが多いため、新規のプロダクト開発と並行しながら、検証やリファクタリングといった改善活動を分担して進められる体制が強みです。 「地道な努力」の文化 メンバー全員が「地道に改善を続けるしかない」という共通認識を持っており、日々の継続的な取り組みを大切にしています。 Day2「開発している中でAIをどのように活用していますか？」 Day2では様々なご回答をいただいたので、特に多かったものや面白いと思ったものをまとめました。 おわりに DroidKaigi 2025では、各セッションや参加者の方々との交流から、日々の開発の参考になる知見を得ることができました。ここで得た学びは、今後のプロダクト開発につなげていきたいと思います💪 また、10月21日(火)にココナラ社、アンドパッド社、令和トラベル社、そしてタイミーの4社共催で「 After iOSDC & DroidKaigi 2025 」を開催します。 当日は弊社からAndroidエンジニアの tick-taku が登壇します 🎉 ハイブリッド開催 となっておりますので、ご興味のある方はぜひ気軽にご参加ください 🙌  reiwatravel.connpass.com 最後に、本カンファレンスを支えた運営・登壇者のみなさん、ならびにタイミーブースにお越しいただいた方々、ありがとうございました！

はじめに タイミーでAndroidエンジニアをしているみかみです。 2025年9月10日から12日にかけて、Androidの技術カンファレンスである「 DroidKaigi 2025 」が開催されました。タイミーからはAndroidチームをはじめとする複数のメンバーが現地に参加し、今年も昨年に続いてゴールドスポンサーとしてブースを出展しました。 セッションでは最新の知見に触れる機会が多く、日々の業務にもつながる具体的な学びを得ることができました。また、会期を通しては立ち話や展示をきっかけに参加者同士が議論を深める場面も多くあり、交流の広がりも強く感じました。そのような様子は会場にとどまらず、XなどのSNSを通じて、オンラインでも盛り上がりをみせていたのが印象的です。 Part1、Part2の2記事に渡り、エンジニアメンバーによるセッションレポートと、ブース出展の様子をお届けします。 本記事（Part 1）では、エンジニアメンバーによるセッションレポートをご紹介します！ エンジニアによるセッションレポート まずは、DroidKaigiに参加したエンジニアメンバーによるセッションレポートを紹介します。 Hunachi（ @_hunachi ） 紹介するセッション： Androidライブラリアンの手引き：堅牢なライブラリとSDKの構築 私はライブラリを公開した経験はないのですが、このセッションはライブラリ開発者だけでなく、マルチモジュール構成で開発している人、そしてライブラリを利用する人にも多くの学びがある、非常に有益な内容でした。 このセッションで特に印象的だった、新しく学べた点をいくつかご紹介します。 公開範囲の制御の重要性について internal を正しく使うことはもちろん、 Explicit API mode を有効にすることで、意図せずパブリックAPIが公開されてしまうのを防げると知りました。これによって、モジュールの責任範囲が明確になり、APIの健全性を保つことができます。 親切なAPIの非推奨化ついて クラスや関数を非推奨（Deprecated）にする際、 @Deprecated アノテーションの message や replaceWith 引数に具体的な説明を記述することで、利用者がスムーズに新しい実装に移行できる配慮が大切だと学びました。 破壊的変更の自動検知について パブリックAPIを変更、特に削除する際には、 binary-compatibility-validator を導入して自動的にチェックをかける手法が紹介されていました。うっかり互換性を壊してしまうミスを防ぐための仕組みは、特にライブラリのメンテナンスにおいて非常に重要だと感じました。ライブラリを作成する機会があったら利用するようにしたいです。 また、ライブラリとそれを利用するプロジェクト間でリソース名が衝突するという問題についても話がありました。マルチモジュールでの問題においては弊社でも対応は済んでいるものの、ライブラリ使用者として予期せぬ挙動に悩まされた経験が何度かあるので自分がライブラリを作る側になった時は気をつけようと思いました。 ライブラリの裏側で何が起きているのかを知ることで、利用者としてもより賢く付き合っていくことができると再認識しました。今後、マルチモジュールでの開発やライブラリを利用する際に、今回学んだ知識を活かしていきたいです。 tick-taku 紹介するセッション： EncryptedSharedPreferences が deprecated になっちゃった！どうしよう！ タイトルの通りで、なぜ deprecated になったかなどの背景を含め紹介し覚悟を決めさせてくれる素晴らしいセッションでした。 タイミーでは KeyStore + Cipher + DataStore を利用していましたが、別のブログで Tink を利用するといい感じに wrap されて、複雑な暗号化周りをライブラリに任せつつ実行速度が速くなると知りました。特定端末でのみクラッシュしてそうな気配を Crashlytics から観測しており、「もしや自前の実装が悪く Tink であれば Google 提供だしその辺も対処してくれているのでは…?」と思い移行しようとちょうど DroidKaigi 直前に Issue を作成して検討していたところ、このセッションの存在を知りました。 結論からですがやめた方がいいとのことです 😇 どうやら観測していたクラッシュは OEM デバイスの KeyStore のバグでどうしようもないとバッサリでした。これは security-crypto が deprecated になった要因の1つらしく、Tink に移行したところで解決せず、むしろアプリ側でのハンドリングが難しくなるそうです。こうなったらどうしようもないのでデータは捨てましょうと割り切るしかないとのことでした… また、クラッシュの要因としてもう1つバックアップ設定の話がありました。 allowBackup=false に設定しているため大丈夫と考えていたのですが、Android 12 からメーカーによっては device-transfer によるバックアップは allowBackup の設定を無視するようになっているそうです。おかげでデータは移行されるのに key が異なるので復号に失敗するというものでした。 本当にちゃんと作ってくれメーカー… また EncryptedSharedPreference が存在してしまうが故に我々はなんでもかんでもデバイスのストレージに保存してしまうという思想のもと deprecated にした背景もあるらしく、「そもそもそのデータをデバイスに保存する必要があるのか？」は設計時に常に意識したい事項だと感じました。 紹介するセッション： OAuthを正しく実装する：Androidアプリのためのセキュアな認証 OAuth を導入するための基礎知識や歴史が理解できる内容でした。 一度実装したり触れたりしたことがある人はそうだよねとなる内容も多く OAuth の入門として非常に勉強になると思います。 気になった点としては、多くのアプリでは access token をデバイス上に保存していると思いますが、その際は変に暗号化せずにシンプルに SharedPreference を使ってデバイスを信頼しましょうといった趣旨の内容が話されていて、Android は root 化したら引き抜けると思ったのですが大丈夫なんでしょうか… また、 PKCE がベストプラクティスらしいですが、そこまで実装しているアプリはどれだけあるのか気になります。 haru 紹介するセッション： スマホ新法って何？１２月施行？アプリビジネスに影響あるの？ DroidKaigi初の公正取引委員会の人による発表で、主にこれから施行される新しい法律に関する話でした。 対象になるのは基本的にAppleやGoogleなどのプラットフォーム事業者で、In App Biilingなどの機能に対して影響があるようでした。 とはいえ、一般デベロッパーに開放していない機能を開放して欲しいなどのリクエストを送ることもできるようになるらしいので、今後どうなっていくか目が離せない法律の1つでもありますね。 みかみ 紹介するセッション： Be a Business-Driven Android Engineer DroidKaigi 2025に参加して、特に印象に残ったセッションの1つが、ohzonoさんの「 Be a Business-Driven Android Engineer 」です。Androidエンジニアがどのようにビジネスの成長に貢献できるのかを解きほぐした内容で、今の自分が所属するストリームアラインドチーム（価値提供チーム）の状況とも重なり、とても心に残りました。 特に共感したのは「越境」という考え方です。現在所属するチームは少人数のため、エンジニアがデータ分析を担ったり、専門外の実装に挑戦したりと、役割の垣根を越えた働き方が自然に行われています。そのため、「越境」という言葉はもともとチーム内でもキーワードになっていました。今回のセッションは、そうした取り組みを価値あるものとして肯定してくれる内容であり、大きな励みになりました。AIの進化によって専門外の領域に踏み込みやすくなっている今、「越境」はこれからますます重要になると感じます。 また、開発チームが売上を直接的なKPIとして持つという話も新鮮でした。私はこれまで、パフォーマンス改善やエラー率の低減、ユーザー行動に基づく指標といったプロダクト内部の成果に注目することが多かったのですが、このセッションではそれに加えて、自分たちのアウトプットを事業全体の成果と結びつけて考える視点が提示されました。自分の仕事がどうビジネスインパクトにつながるのかを意識することで、エンジニアとしてもっと広い視野で取り組んでいきたいと感じました。 さらに、この考え方を技術面から支える手段として、Kotlin Multiplatform (KMP) の存在感も改めて実感しました。副業や別プロジェクトでKMPを利用してきた経験からも、その有効性を強く感じています。もちろん、ビルド速度やKMPそのものの複雑さ、iOSとAndroidエンジニア間の連携といった課題はまだあります。ドメインレイヤーの共通化によるメリットは大きく、KMPはAndroidエンジニアがiOS開発へと「越境」する後押しとなり、チーム全体の生産性を高める現実的な選択肢だと思います。今後も注目していきたい技術です。 syam 紹介するセッション： KotlinでのAI活用による開発 JetBrains の Sebastian Aigner さんと Márton Braun さんによる「 KotlinでのAI活用による開発 」というセッションが気になったので聴講しました！ Kotlin と AI の関わり方を「コード補完のような軽い支援」から「エージェントに任せる自動実装」まで段階的に紹介しており、JetBrains の AI エージェント Junie を使ったデモでは、新しい画面追加や UI の改良を自動で行っていて、既存コードのパターンも踏まえた修正が印象的でした。 また、Kotlin 製のフレームワーク Koog も紹介され、マルチプラットフォームで AI エージェントを組み込める仕組みとして活用できるとのことでした。 nshiba（ @nshiba310 ） 紹介するセッション： ユーザーも開発者も悩ませない TV アプリ開発 - Compose の内部実装から学ぶフォーカス制御 AndroidTVアプリを Compose を使って実装方法を紹介するセッションでした。 Compose 以前の時代に存在していた leanback library という Google 製のライブラリがありましたが、これは Compose には対応していません。 Compose で AndroidTV を実装しようと思ったら、どういったライブラリを使ったら良いかと行った基礎的なことから始まり、leanback library ではデフォルトでライブラリが対応してくれていた、フォーカス周りの制御やいまどのUIにフォーカスがあったているかがわかりやすくなるUIの制御などを Compose では自前で実装する必要がありどういった対応が必要かについても詳しく解説されていました。 また AndroidTV アプリでは、スクロールの制御についても通常のモバイルアプリとは異なる実装方法が必要になり、これについても詳しく解説されていました。 セッションタイトルの通りどのセクションでも Compose の内部実装までちゃんと処理を追って説明されていてとてもわかりやすく、これから Compose で AndroidTV アプリを作成する方にとって必見の内容がつまっていました！ 続きはPart 2の記事で！ 引き続き、Part 2の記事にて他のエンジニアメンバーによるセッションレポートと、ブース出展の様子をお届けします。 ぜひ読んでください！ tech.timee.co.jp

こんにちは、タイミーでエンジニアをしている徳富です。 今回は、 EKS上にGitHub Actions Self-hosted Runner基盤を構築した話 をお届けします。 背景：GitHub Actionsへの移行と、新たに見えてきた課題 2024年10月に公開した CI基盤をGitHub Actionsへ移行した記事 で紹介したとおり、 CircleCIからGitHub Actionsへの移行によって、私たちのCI体験は大きく改善しました。 しかし、開発者やテストケースが増え、時間が経つにつれて 新たな課題 も見えてきました。 実行回数の急増によるコスト高騰 2025年2月頃からDevinをはじめとしたAIエージェントの利用が進み、PRやpushの回数が一気に増加 開発者数の増加も重なり、ワークフロー実行回数が比例して伸びていった GitHub-hosted Runnerは料金や安定性の面である程度最適化されているため、Self-hostedに切り替えれば必ずしもコスト削減につながるとは限らない。 しかし、割引オプションが少なく、コストコントロールが難しい という課題もある 一方AWSならSavings PlansやSpotインスタンスなどの仕組みを活用でき、柔軟に最適化が可能。開発者やエージェントの利用増加で実行回数が急増するタイミーのユースケースにおいては、この「柔軟に最適化できる」という点が大きなメリットであることがわかってきました テスト時間のじわじわとした増加 テストケース数の増加により、全体の実行時間も長くなってきている apt install などのセットアップ処理にも時間がかかっている 「ランナーイメージに事前インストールしておけばもっと速くできるのでは？」という声も出始めた 「コストをコントロールしながら、テストももっと速くしたい」 そんな思いから、私たちは Self-hosted Runner基盤の構築 を検討し始めました。 最初のアプローチ：ECS + Lambda構成 当初は ECS + Lambda + API Gateway を組み合わせて、ランナー基盤を構築しようとしました。 しかし実際に検証してみると、すぐにいくつかの課題に直面しました。 レートリミットの考慮 1回のCI実行で最大35並列のランナーを起動してます。 　日中は多いときで 1時間に60回以上 実行されることもあり、GitHub API の レートリミット を意識した設計が必要になります。 → これを Lambda 側で考慮して実装するのはかなり複雑。 ランナーは30秒以内に立ち上がってほしい という要件がある。 Lambda のコードを継続的にメンテナンスするコスト も無視できない。 「長期的に運用するには、この構成は少し複雑すぎるかもしれない」 そう判断し、よりシンプルに運用できる別のアプローチを探すことにしました。 選んだのは EKS(auto mode) × Actions Runner Controller そこで目をつけたのが、GitHub公式が提供する **Actions Runner Controller (ARC)**。 ARCはGitHub ActionsとKubernetesをつなぎ、必要なときだけランナーPodを動的に起動してくれます。 さらにクラスタ基盤には EKS Auto Mode を採用しました。 ノード管理やスケーリング設定をほとんど自前で持たずに済むため、運用の手間を大幅に減らせるのが魅力です。 「EKS Auto Mode × ARC であれば、管理コストを抑えつつ柔軟なSelf-hosted Runnerが作れるのでは？」 そう考え、この構成で進めることにしました。 アーキテクチャ概要 ざっくりとした構成はこんなイメージです。 アーキテクチャー図 ARC : GitHub APIと連携し、ランナーPodを自動的に作成・削除 EKS Auto Mode : クラスタ管理を最小限に抑えつつ、柔軟なスケーリングが可能 Karpenter : Auto Modeの裏側で働くプロビジョナー。従来のCluster Autoscalerよりnode起動が速い 特にCIのように時間帯によって必要リソースが大きく変動するワークロードでは、 Auto Mode＋Karpenterの組み合わせが非常に相性が良く、メンテナンス性・柔軟性の両立 ができました。 導入時に直面した課題と解決策 ここからが本番です。 実際に導入を進めていくと、次々と問題が発生しました。 1. Spotインスタンスの安定性問題 当初はコスト削減を狙って、停止率の低いインスタンスタイプの Spotインスタンス を採用していました。 しかし、弊社のCIは 35並列で高頻度に実行 されるため、必要なインスタンス数が多くなり、停止確率が低いタイプでも 1日あたり5〜10回ほどノードが落ちる ことがありました。 その結果、CIが途中で失敗するケースが頻発し、 開発者体験を大きく損ねる要因 となってしまいました。 対策 そこで思い切って オンデマンドインスタンスに切り替え 、必要に応じて Savings Plans を適用する方針にしました。 オンデマンドにしたことで、ランナーが突然落ちるリスクがなくなり、安定してCIを回せるようになった 安定性が向上したことで、CIだけでなく デプロイなど他のワークフローもSelf-hosted Runnerに寄せる ことが可能に これによりEC2のアイドル時間を減らし、稼働率を高めることでコスト効率も改善できました 2. スケールインでランナーPodが強制終了する問題 次に直面したのは「EC2のスケールインによって、ランナーPodがCI実行中に突然落ちる」という問題です。 原因は、Karpenterの設定でした。 デフォルトでは disruption.consolidationPolicy が WhenEmptyOrUnderutilized になっており、 ノードのリソース使用率が低いと、 Podが稼働中でも容赦なくノードを落としてしまう のです。 (参考: https://karpenter.sh/docs/concepts/disruption/) 対策 consolidationPolicy を WhenEmpty に変更 Podがないノードのみスケールイン対象とするよう設定 spec : disruption : consolidationPolicy : WhenEmpty これでランナーPodが実行中に消える問題は解消しました。 3. ノードが全然スケールインしない問題 しかし、ここで別の問題が発生します。 「一度スケールアウトすると、ノードがほとんど減らない」という現象です。 原因は Kubernetes のスケジューリング。 Kubernetes のスケジューラには、Pod をできるだけ均等に配置しようとする仕組みがあります。 そのため Pod が複数のノードに分散して配置されやすく、 ノード上の Pod が 0 になるケースが少ない ため、スケールインがなかなか進まなくなります。 対策 Pod Affinity を利用し、ランナーPodはなるべく同じノードに詰めるよう設定 Pod配置の断片化を防ぎ、スケールインしやすくしました affinity : podAffinity : preferredDuringSchedulingIgnoredDuringExecution : - weight : 100 podAffinityTerm : labelSelector : matchLabels : actions.github.com/scale-set-namespace : arc-runners topologyKey : kubernetes.io/hostname これによりリソース効率が大きく改善されました。 4. 夜間にリソースを最適化する作戦 リソース効率をさらに高めるため、 日中は安定性を優先し、夜間だけ段階的にノードを整理する仕組み を導入しました。 具体的には、 disruption.consolidationPolicy を WhenEmptyOrUnderutilized に設定したうえで、夜間に 一定間隔で15分だけpodが存在するノードのスケールインを許可 → その後は再び禁止 というサイクルを繰り返します。 これにより、ノード上にPodが残っていても一気に消されることはなく、 「急にPodが落ちてCIが止まる」といったリスクを避けながら、少しずつリソースを最適化 できるようになります。 spec : disruption : consolidationPolicy : WhenEmptyOrUnderutilized consolidateAfter : 5m budgets : - nodes : "0" reasons : - Underutilized schedule : "0 0 * * *" # 0:00〜11:45 UTC 禁止 (JST 9:00〜20:45) duration : "11h45m" - nodes : "0" reasons : - Underutilized schedule : "0 12 * * *" # 12:00〜15:00 UTC 禁止 (JST 21:00〜翌0:15) duration : "3h15m" - nodes : "0" reasons : - Underutilized schedule : "30 15 * * *" # 15:30〜17:00 UTC 禁止 (JST 翌0:30〜翌2:15) duration : "1h45m" - nodes : "0" reasons : - Underutilized schedule : "30 17 * * *" # 17:30〜20:00 UTC 禁止 (JST 翌2:30〜翌5:15) duration : "2h45m" - nodes : "0" reasons : - Underutilized schedule : "30 20 * * *" # 20:30〜24:00 UTC 禁止 (JST 翌5:30〜翌9:00) duration : "3h30m" この仕組みによって、 日中は安定してCIを回しつつ、夜間は少しずつノードを整理してリソースを効率的に活用 できるようになりました。 5. コールドスタート問題をランナープールで解消 弊社では 35並列 のランナーを利用しています。 そのため、完全なオンデマンド起動では間に合わず、 ランナー起動待ちが発生してしまうこともありました。 そこで、ARCの minRunners 設定を活用し、 ランナープールを作成 。 あらかじめ一定数のランナーを起動しておくことで、 要求があればすぐに割り当てられるようになり、 GitHub-hosted runnerと同じ快適な使い心地を実現しました。 5 Runner PodでDockerを使う工夫 最後のハードルは「ランナーPodでDockerをどう使うか」です。 私たちのCIではMySQLやRedisなどの service container を多用しているため、RunnerコンテナからDockerを操作できる仕組みが必要でした。 選んだ方法 RunnerでDockerを扱う方法は大きく分けて DooD (Docker outside of Docker) と DinD (Docker in Docker) の2種類があります。(参考: GitHub Actions の self-hosted runner で Docker を使う際のパターン整理 )。 今回は DinD を採用しましたが、その中でもさらに実現方法が2パターン存在します。 Runnerコンテナ内で直接Dockerデーモンを起動する方式 Runnerコンテナ自身が dockerd を立ち上げ、 docker build や docker run を自己完結的に実行する。 シンプルですが、Runnerコンテナに 特権モードや大量の権限 を付与する必要があるため、セキュリティ面での懸念が残ります。 また、RunnerコンテナとDockerデーモンが同居することでリソース管理が複雑化しやすく、トラブルシュートもしづらいという課題があります。 Dockerデーモンをサイドカーとして起動する方式 Pod内で Runner と dockerd を分離し、 emptyDir などを介して ソケット通信 させる。 Dockerの実行環境はサイドカーに閉じるため、Runnerコンテナは通常権限で動かせる。 CIジョブ終了とともにPodごと削除されるため、イメージやボリュームなどの作業痕が自動的に掃除される点もメリットです。 私たちは Runnerコンテナに強い権限を持たせないことを重視 し、後者の DinDサイドカー方式 を選択しました。 まとめと次回予告 今回、 EKS × ARC を使ってGitHub Actions Self-hosted Runner基盤を構築し、 コスト・パフォーマンス・柔軟性のいいバランスで実現できました。 ただ、これで終わりではありません。 次回は、この基盤の上で テスト実行時間をさらに短縮するために行ったチューニング について詳しく紹介する予定です。 「GitHub-hosted runnerで限界を感じている」 「EKSでSelf-hosted Runnerを検討している」 そんな方の参考になればうれしいです。

こんにちは！
タイミーでBackendEngineerをしている志賀( @akitoshiga )です！
 2025年9月6（土）に開催された「ながらRuby会議01」に行ってきましたので、その様子を振り返りたいと思います！ ながらRuby会議には、「Kaigi Pass」という社内制度を利用して参加しました。
 「Kaigi Pass」とは、世界中で開催されているすべての技術カンファレンスに無制限で参加できる制度です。 productpr.timee.co.jp 会場の様子 当日は長良川沿いにある「 長良うかいミュージアム 」というとても素敵な場所で開催されました。 会場内にはスポンサーノベルティや展示などもありました。 セッションの様子 refinementsのメソッド定義を4000倍速くした話 alpaca-tc さん Ruby3.2以降、refinementsにおけるメソッド定義は約1万倍低速化していました。 社内サービスの開発でこの事態に直面した際に、原因の究明からRubyへのコントリビュートまでを行った過程をお話しされていました。 refinementsとはRuby2.0から導入された安全にRubyを拡張する仕組みのことで、モンキーパッチを当てたクラスのスコープを限定させることが可能です。 きっかけは、社内サービスのRubyのアップデートの際にRuby on Railsのアプリケーションの起動に数十秒かかるようになってしまったことでした。　　 Vernier とMiddlewareを利用して計測を行ったところ、ボトルネックとなっている処理が判明しました。 そこにrefinementsのメソッド Module#refine が存在していました。 Ruby3.3では、 Module#refine を呼び出した際にrefineのcallcacheがクリアされる処理が追加されます。 このcallcacheが削除されたことが低速化の原因でした。 これを Ruby Issue Tracking System で報告したところアドバイスをもらいました。 しかし、alpaca-tcさんはRubyの実装であるC言語には馴染みがありませんでした。 この問題に対してはChat-GPTや ko1/rubyhackchallenge を活用したりコミュニティでアドバイスを得ることで解決していきました。 最終的にプルリクエストを作成してRuby本体へのマージが実現したそうです。 技術的なギャップを埋めるためにAIを活用したのは素晴らしい解決方法ですし、粘り強く取り組みRubyへのコントリビュートを実現する姿は素晴らしいと思いました！   知っているようで知らないrails newの世界 luccafortさん speakerdeck.com   Ruby on Railsではプロジェクトの初期化の際に rails new というコマンドを実行します。 しかし、このコマンドの裏側でどのような処理が行われているかは多くは知られていません。 そこで、コマンドはどのような実行フローを行っているか、また使われている技術がどのような設計の組み合わせによって実現しているかについて深掘りしてお話しされていました。 luccafortさんの今回の発表の動機の一つには、オーガナイザーを務められた「 関西Ruby会議08 」での体験から、個人開発以外の成長の選択肢を模索したかったという想いがあったそうです。 rails new で実行される処理は以下の流れになっています。 コマンド解析 ジェネレータ初期化 オプション処理 ディレクトリ作成 ファイル生成 bundle install これだけでも長大な処理なので、本発表ではコマンドの解析からジェネレータの初期化まで中心に説明していました。 rails new を実行すると Rails::Command によってargの解析やエラーチェックが行われます。 その後、 Rails::Command.invoke によって入力したコマンドの内容から Rails::Command の適切なサブクラスが呼び出されます。 今回の場合は Rails::Command::ApplicationCommand が読み込まれます。 Rails::Command::ApplicationCommand#perform によって無効なコマンドチェックなどが行われた後、 Rails::Generators::AppGenerator.start で定義された各種ファイルの生成タスクが実行されます。 その後、 Rails::Generators::AppGenerator#bundle_command によって bundle install が実行され最終的にコールバックが呼び出されます。 rails new に関する説明は以上です。 この取り組みを通してluccafortさんは仕組みを理解する重要性について気づきがあったそうです。 仕組みを理解していなくてもRuby on Railsは使えるものの、深く理解することで新しい発想や新たな気づきのきっかけになるとお話しされていました。 Ruby × iOSアプリ開発：共に歩んだエコシステムの物語 Tomoki Kobayashi さん speakerdeck.com Kobayashiさんは普段は主にモバイルエンジニアとして活動されています。 RubyはiOS開発の歴史において過去大きな役割を担っており、またiOS開発コミュニティもRubyに大きく貢献しています。 iOS開発とRubyが今までどう関わってきたかの歴史をお話しされていました。 2010年ごろのiOSアプリ開発はObjective-Cが使用されていましたが、サードパーティのライブラリのインストールが大変だったそうです。 ライブラリによってインストールの仕方が異なっており、Xcodeのビルド設定を行う際にもAppleの非公開の独自仕様のために保守性が非常に低いものでした。 この問題を解決するために CocoaPods というパッケージマネージャーが登場しました。 これによりライブラリの依存性解決・ダウンロード・Xcodeへのプロジェクト統合まで自動できるようになりました。 CocoaPodsはRubyでライブラリ管理に使用されるRubyGemsとBundlerを参考に作成されており、本体の実装もRubyで書かれています。 その他も nomad-cli や fastlane といったRubyを参考にしたツールが登場してきました。 この背景はツールの作成者が元々RubyやRuby on Railsのエンジニアが多かったことにあるそうです。 そして、CocoaPodsの依存関係リゾルバーである Molinillo（モリニージョ） はBundler1.9, RubyGems2.9に搭載されるようになりました。 しかしながら、iOS開発とRubyの関わりは薄れつつあるそうです。 2014年のSwiftの登場を機にSwiftが公式のパッケージマネージャーを発表したりBundler2.4でMolinilloが引退しています。 Ruby Mini Language作成記 〜ハンズオンで学ぶインタプリタの世界〜 haruguchi さん Rubyを用いてインタプリタを作成した経験をもとに、字句解析、構文解析、評価とった処理の実装方法や設計上の注意点についてお話しされていました。 インタプリタを作ろうと思ったのはharuguchiさんがRubyKaigi2025に参加したことがきっかけだそうで、RubyKaigiでよく発表される言語処理の話の理解を深めたいと思った時にインタプリタの実装を思いついたそうです。 haruguchiさんが参加されている勉強会でこの話を持ち込み、他のメンバーと実装していくことになりました。 インタプリタはFizzBuzzが動くものをゴールとして、単純な2項演算の実装からはじめることにしました。 最初は単純なパーサーのみで実装することとし、インタプリタの機能を追加していくにつれてレキサーを実装したり構文解析方法を工夫したりと実装を進めていきました。 自身で実装することを面白くするポイントとしてif文の条件式の区切りを < > にしたりとオリジナルの要素を追加していったそうです。 5ヶ月ほどでFizz Buzzの実装まで完了して、途中デモで実践していました。 会場のみんなでモブプロしてるの良すぎる #nagara01 pic.twitter.com/PX9v0mA3k2 — しが あきとし (@akitoshiga) 2025年9月6日 当初のゴールとしては達成したのですが、ここから配列やハッシュといったデータ構造も行ってみたいとのことでした。 言語処理の話題はRubyではよく出てくるのですが、その理解のためにインタプリタを自前で実践するところに尊敬しました。また、自分も挑戦してみたいと思いました。 💡Ruby（ひかるびー） 川辺で灯すPicoRubyからの光 bash さん speakerdeck.com PicoRubyという組み込み向けの軽量なRubyを使ってLEDを点灯させるところから、音声や加速度といったセンサーを追加して様々なことに挑戦することでRubyで組み込み開発をする楽しさについてお話しされていました。 最初の機材は「 ATOM Matrix 」という開発ボードで、内蔵のLEDを点灯させるところから始まりました。 また、基本的なアーキテクチャは「Super Loop Architecture」というものを用いていました。 Super Loop Architectureとは、初期化の後に発生させた無限ループの中でLEDに対しての操作を行うものです。 LEDの点灯に成功させたあとは、ランダムに点灯させたり自分の動きに合わせて点灯させたりといった試みを行っていきました。 最終的には棒状のLEDやMIDIシンセサイザーといった他の機材と連携させる試みを行っていました。 ライトセイバーを振り回すbashさん #nagara01 pic.twitter.com/SSv6g6SMAE — すぎうり (@uproad3) 2025年9月6日 365日のOSS開発を続ける舞台裏 Koichi ITO(Koic) さん speakerdeck.com   RuboCopのコミッターであり、365日OSSにコントリビュートを行っているITOさんの普段の開発環境やOSSに対する心構えについてお話しされていました。 開発環境は業務のコードとOSSのコードを透過的に扱えるようにすることをテーマとしていました。 そのためのツールとして ghq や gem-src の使用を推奨されていました。 OSS活動をするとローカルリポジトリが大量に増えるのですが、その点については peco や fzf を用いた対策を紹介されていました。 印象的だったのは、gitコマンドの扱い方でコミット権のないリポジトリとリポジトリでの振る舞いを合わせるためにFork先のリポジトリをoriginとして、upstreamをForkした方のリポジトリとすることを推奨されていた点です。 これによってどの環境にプッシュする際も git push upstream head と同一のコマンドにできる利点について強調されていました。 心構えについては、コードの内容だけではなく発言やレビューについても恥ずかしくない振る舞いをしようという「ソーシャルコーディング」という考え方や、OSSを地球全体での非同期開発と捉えて自己完結したコードのみのPRを出さずにコンテキストを文章化して伝えることの重要性にも触れられていました。 　 アフターイベント 懇親会の後にはアフターイベントとして鵜飼漁の観覧がありました！ 鵜呑みです。 #nagara01 pic.twitter.com/EPTU5bsiJ3 — どみにをん525 (@Dominion525) 2025年9月6日 残念ながら自分は参加できなかったのですが、大変盛り上がったみたいです。 まとめ スポンサーLTも含めてどのセッションも大変面白かったです。 発表者の「これがやりたいからやる！」といった気持ちに基づいた発表が多かったのですが、その姿勢をとても尊敬しました。 また小規模の開催だったこともあり、アットホームで参加者間でのコミュニケーションもとりやすくたくさんの方と交流できました。 また、自身は今回初めて岐阜に行ったのですが、自然と人々の生活が調和したとても素晴らしい場所でした。 大変心に残る素晴らしい会だったので、次回開催される際はまたぜひ伺いたいなと思いました！  

はじめに こんにちは。タイミーでデータエンジニアをしている chanyou です。 先日、おそらく関西圏で初めてのデータエンジニアリング・アナリティクスエンジニアリングをテーマとしたイベント、 関西データエンジニア/アナリティクスエンジニアMeetup に参加してきました！ https://monotaro.connpass.com/event/360460/ monotaro.connpass.com このミートアップは、株式会社MonotaRO主催のもと、「関西に住みながらデータ関連の仕事をしたい」「関西で同じ職種の仲間と繋がりたい」という想いを持つデータ専門職向けに開催されました。 当日は株式会社10X、株式会社MonotaRO、ダイハツ工業株式会社、そして当社タイミーの4社の発表と、最後にパネルディスカッションがありました。 非常に熱量あるイベントでしたので、内容をまとめてお伝えします。 会社にデータエンジニアがいることでできるようになること まずは株式会社10X 吉田さんの発表です。 speakerdeck.com マネージドサービスが普及し、誰でもある程度のデータ基盤を構築できるようになった現代において、改めて「なぜデータエンジニアが必要なのか」という問いに、具体的な事例で答えていく内容でした。 特に印象的だったのは、以下の2つの取り組みです。 アセスメントの実施とデータ品質の改善 DMBOKを拠り所にデータ品質を定義し、データセットごとに可視化する仕組みを構築されているとのこと。 正直データ品質の継続的なモニタリングまでされていて、見習っていかねばと思いました。 Data Contractによるデータソース仕様の確立 データの生産者とデータの消費者の橋渡し役として、連携のプロトコルを取り決めて運用されているとのこと。 これもまたマネージドサービスだけでは実現できない、人間に残された仕事のうちのひとつだなと思いました。 セッション全体を通して、「データエンジニアの本質とは何か？」という問いを突きつけられたような感覚で、身が引き締まる思いでした…！！ 組織的データ活用をスケールさせる、アナリティクスエンジニアリングの実践 続いて株式会社MonotaRO 小谷さんの発表です。 アナリティクスエンジニアリングに特化した部署を立ち上げ、組織的なデータ活用をスケールさせている実践例が共有されました。 今回発表された小谷さんは、営業専門のアナリティクスエンジニアとして、営業組織にフルコミット。深く入り込んで課題の特定からソリューションの実装・運用までされているそうです。 印象的だったのは営業組織に本当に深く入り込んでいる点で、営業管理部署の定例に参加するのはもちろん、作業も同じ部屋で行うなど、徹底的に現場に寄り添っていました。これにより真の課題を特定して、成果につながったとのことでした。 さらに 縦に伸ばして横に広げる という、アナリティクスエンジニアが深さを探求して、データエンジニアがそれを横展開する思想が語られており、非常に共感できる考え方だなと思いました！！ 具体的なソリューションについても、セマンティックレイヤーを整備したり、生成AIによる議事録作成の自動化をしたりと、踏み込んだデータ活用をされていて勉強になりました。 AnalyticsEngineeringがもたらした実インパクトと未来のロードマップ 当社 okodoon さんによる発表です。 speakerdeck.com タイミーにおけるアナリティクスエンジニアリングを「データ活用UXの改善」と定義し、これまで行ってきたデータモデリングやデータアプリケーション開発が、実際にどのようなインパクトをもたらしたかを紹介しました。具体的には以下の事例を紹介しました。 Looker整備によるアナリストの負荷軽減と指標統一 個人情報を含むデータのアウトプット申請フローのセルフサービス化 また、後半ではさらにデータ活用体験を向上させるために行っているヒアリング活動についても触れました。 データ利用者の業務理解には、ジョブ理論とユーザーストーリーマッピングを組み合わせた独自のフレームワークでヒアリングを実施。いざモデリングを行うとなった際にはアジャイルデータモデリングを実践しています。 またアナリティクスエンジニアリングの魅力に注目して語っていて、okodoonさんは 飽きないことも重要 と話していたのが同僚ながら面白かったです。 製造業におけるデジタル人材の活躍ポイント ダイハツ工業株式会社 太古さんによる発表です。写真NGのスライドでしたので文章のみでお伝えします！ 自動車メーカーということで他の3社とは、データを取り巻く環境が全く異なっていました。AI、BI、アプリ開発の3軸で、トップダウンとボトムアップの両面で変革を推進しているとのことでした。 AI に関しては、スキルあるメンバーが現場に入り込み、たった2ヶ月でリリースして回っているとのことでした。スタートアップ顔負けなスピード感に驚きました…！ BI に関しては、ちょっとダッシュボード作れるレベルの方を増やすのではなく、人に教えられるレベルの方を増やすことに注力した戦略を取られているとのことでした。 アプリ開発軸に関しては、手を挙げたキャリアチェンジしたい方などにプログラミング教育を実施して、元の部署や異動後の部署で現場の課題を解決する動きを取ってもらっているとのことでした。実際に人手で行っていた作業を自動化する内製アプリがポツポツと開発されていて、現場の課題をそのまますぐに解決できる環境が実現されているんだなと思いました…すごい。 パネルディスカッション セッション後は、登壇者全員によるパネルディスカッションが行われました。多岐にわたるテーマで議論が交わされ、特に印象に残った点をいくつかご紹介します。 Q. ジョブ理論の活用といった知識のインプットや、チームでの議論はどう進めている？ okodoon(タイミー): 「プロダクト開発の知見を参考にしている。社内のプロダクトマネージャーが実践しているジョブ理論やユーザーストーリーマッピングの手法を、データ基盤の利用者ヒアリングに応用した。」 吉田さん(10X): 「X(旧Twitter)など外部からの情報収集に加え、ソフトウェアエンジニアリングの知見を参考にすることが多い。ただし、単に新しい技術を導入するのではなく、自分たちの組織のフェーズに合っているかが重要。経営陣にも年単位で繰り返し伝え続ける粘り強さも必要。」 Q. 大人数がデータを触る中でのガバナンスや管理体制はどのように担保してる？ 太古さん(ダイハツ): 「まずはセキュリティを固めたセキュアな環境を構築し、その中で自由に使えるようにしている。新しい技術を試すためのSandbox環境を用意するなど、目的で使い分けている。」 Q. データ品質改善の副作用や、他部署への説得はどう乗り越えた？ 吉田さん(10X): 「オペレーション部門などとの連携は課題になりやすい。まずは現状の定義がなぜ正しくないのかを紐解き、あるべき姿(to-be)を考える。元データの作りが良くないなら、データ基盤側で吸収するアプローチも取る。」 小谷さん(モノタロウ): 「営業組織などは特に指標が変わることに敏感だが、丁寧に説明することで理解を得やすい文化がある。」 Q. 何を作るかの意思決定、どこにベットする？ okodoon(タイミー): 「投資しても腐らない領域にベットする。AEが担う指標の定義などは、やればやるだけ人間もAIも喜ぶ領域。」 吉田さん(10X): 「ビジネスプロセスをどう定義するか。枯れたフレームワークはLLMも解釈しやすい。」 Q. アナリティクスエンジニアというロールはどうやって生まれた？ okodoon(タイミー): 「アナリストが闇堕ちして誕生した（笑）。『分析テーブルが汚い』といった憎しみを解決したいという想いが原動力。」 吉田さん(10X): 「ロールはなんでもよくて、執念をどこに捧げられるかの違い。」 おわりに 今回のミートアップを通じて、関西のデータコミュニティの熱量を肌で感じることができました。 各社の発表が刺激になったのはもちろん、パネルディスカッション後の懇親会では様々な領域の企業の方とお話できて、本当に西日本における盛り上がりを感じました…！ このような素晴らしい場を設けてくださった運営・登壇者の皆様、そして当日お話しさせていただいた参加者の皆様、本当にありがとうございました！ 今回得た学びを日々の業務に活かし、タイミーのデータ活用をさらに前進させていきたいと思います。

こんにちは、タイミーでバックエンドのテックリードをしている新谷 ( @euglena1215 ) です。 タイミーでは、開発効率を向上させるため、Devin や Claude Code Action といった AI ツールを活用してコードレビューの自動化を進めています。 Claude Code は「インラインコメントでレビューして」と伝えるとインラインでのレビューをしてくれるのですが、Devin は同じ指示をうまく解釈できずインラインでレビューしてくれません。 この能力の差は GitHub MCP が使えるかどうかの差ではあると思うのですが、Devin と Claude Code Action でのレビュー内容の精度を比較しようとした際に、レビューフォーマットが異なっていると純粋な性能比較が難しくなります。 そこで、今回は Devin でもインラインコメントによるレビューを実現するための方法を調べてみたので紹介したいと思います。 方法 方法は簡単で、以下の GitHub API を使ってインラインコメントを投稿する方法を記したドキュメントを Devin の knowledge として登録するだけです。 トリガー設定は登録時に Devin が提案してくるデフォルトの内容で問題なく動作しました。 How to post comments with code embedded: 1. Create JSON file for each comment you want to post. Example 1: { "body": "Security Issue: Hardcoded API key. Recommendation: Use environment variables", "commit_id": "954...12312", "path": "file.py", "line": 11, "side": "RIGHT" } Example 2: { "body": "Multiple issues found:\n1. Hardcoded API key should be in environment variables\n2. Inconsistent class naming (userAccount vs Product)\n3. Inconsistent parameter casing (Password vs username)\n4. Missing docstrings and type hints\n5. Inconsistent spacing around operators", "commit_id": "323......87686", "path": "code.py", "start_line": 11, "start_side": "RIGHT", "line": 25, "side": "RIGHT" } body: The text of the review comment. Include markdown code blocks for snippets commit_id: SHA of the commit you're reviewing. Not using the latest commit SHA may render your comment outdated if a subsequent commit modifies the line you specify as the position. path: Relative file path in repo line (integer): Specifies the exact line in the pull request’s diff view to which your comment should attach. Required unless using subject_type:file. The line of the blob in the pull request diff that the comment applies to. For a multi-line comment, the last line of the range that your comment applies to. side: In a split diff view, the side of the diff that the pull request's changes appear on. Can be LEFT or RIGHT. Use LEFT for deletions that appear in red. Use RIGHT for additions that appear in green or unchanged lines that appear in white and are shown for context. For a multi-line comment, side represents whether the last line of the comment range is a deletion or addition. subject_type: The level at which the comment is targeted. Either "line" or "file". Use "line" for inline comments. Use "file" for file-level comments. start_line (integer): Required when using multi-line comments unless using in_reply_to. The start_line is the first line in the pull request diff that your multi-line comment applies to. start_side: Required when using multi-line comments unless using in_reply_to. The start_side is the starting side of the diff that the comment applies to. Can be LEFT or RIGHT. A pull request diff may not match the original file's absolute line numbering. That is, if the PR contains additions or deletions before the line you’re commenting on, the line indices shown in the “Files changed” tab can shift from the original file’s line numbers. For example: In the pre-PR state, line 231 might refer to a completely different section of code than line 231 in the post-PR diff (because code added or removed above it shifts everything down or up). Therefore, you must use the line numbers as shown in the PR diff rather than the original file’s line numbers. If you have issues, visit the docs: https://docs.github.com/en/rest/pulls/comments?apiVersion=2022-11-28#create-a-review-comment-for-a-pull-request 2. Use gh api command. gh api \\ --method POST \\ -H "Accept: application/vnd.github+json" \\ /repos/owner/repo/pulls/4/comments \\ --input comment.json owner: the account owner of the repository. The name is not case sensitive. repo: The name of the repository without the .git extension. The name is not case sensitive. pull number: The number of the pull request. Key points: use "line" instead of "position", include code snippets in body using markdown, , set side="RIGHT" for additions この knowledge を登録することで Devin に「インラインコメントでレビューして」と一言伝えると、安定して正しくインラインコメントでレビューしてくれるようになりました！ 🎉 実は、上記の knowledge の内容は Devin の開発元である Cognition 社の記事にそのまま掲載されています。 cognition.ai 公式ドキュメントを読みましょう、以上。の内容ではありますが、あまり日本語の文献が見つからなかったので記事にしてみました。 この記事が、同じように AI コードレビューに取り組む方々の助けになれば幸いです。

はい、亀井です。 インターネット上では、yykamei（わいわいかめい）という名前で活動しています。所属はタイミーです。 Kaigi Pass を利用して スクラムフェス仙台2025 に行ってきましたので、参加レポートという形でこちらに投稿しています。 まずは、スクラムフェス仙台の運営の皆さん、スポンサーの皆さん、会場提供をしてくださった enspace さん、そして、登壇者や参加者を始めとする関わってくださった皆さん、ありがとうございます。皆さんのおかげで終始楽しめました。 1日目はキーノートが行われます。今回は モンテディオ山形 の相田さんがキーノートスピーカーとして登壇されました。モンテディオ山形に入ってから相田さんが実施した取り組みを中心に、今後の展望についても話されていました。もともと楽天イーグルスやヴィッセル神戸などに関わっていたこともあり、クラブ運営についての知見などがあったと思うのですが「色々と変えてくれ」というオーダーを受けてモンテディオ山形にジョインされ、「色々」されたようです。たとえば、オフィスがあまりにも「オープン」すぎるがゆえに情報が筒抜けになっているので「これ、チームとしてまずいね」ということでオフィスの改善をしてセキュリティーレベルの向上をされたり、クラブも結局は売上が大事なので「試合をしていないときにどのようにして売上をあげていくか？」ということを考えてスタジアムの周辺の環境を整備されたりしたようです。印象的だったのは「地域にあってくれてよかった！」と言ってもらえること、そして、「このチームに入りたい！」と選手に思わせることを目指している、ということでした。スクラムフェスのように各地域で行われているスクラムフェスはそれぞれの地域で運営メンバーが異なりますし、同じスクラムフェスという名前を冠していても特色が異なります。そのような独自性をもつ地域スクラムフェスですが、みんな「地域に貢献したい」という思いがあるのではないかと私は思っています。そうした中で、スクラムフェス仙台で相田さんをキーノートにお招きしたのは何か感じるものがありますね。また、相田さんの話をよくよく聞いているとたくさんの 改善 をされたのですが、その 改善 の裏には丁寧な 観察 があったのではないかと推察します。というのも、先ほどのオフィスの話にしても現場に入ってよくよく見てみないと状況はわからないですからね。そのうえで対策を行うという話がまさにスクラムでいうというところの検査と適応なのだなと。 キーノートのあとにネットワーキングパーティーがありました。ここで写真を撮っておかなかったことを後悔していますが、とにかくわいわいやらせていただきました。特に印象に残っているのは、おーのAさんに「お、これは... 『かめり』さんですか？」といういじりですかね。ひらがなで「かめい」と書いたつもりなのですが、字が汚かったようで「い」が「り」に見えたようです。どうですかね？そんなに「り」ですか？ 「かめり」？「かめい」？ 2日目はいろいろと登壇セッションがありますね。初回は我らが ShinoP の登壇ということで聞いておりました。私はいわゆる「中の人」なので知っている内容ではあったのですが、あらためて聞いてみるとよくまとまっている話でしたね。さっそく 資料 もアップロードしていただいたみたいです。面白かったのはこれまでの行動を改めて言語化して、「共感性」「透明性」「一貫性」というものにまとめたところですね。誰かがその後質問をされていたのを盗み聞きしたところ、実際に行動を行っていた時はその言語化したことを意識してやっていたわけではない、とのことでした。改めてふりかえって言語化してみた結果、そうした概念にたどりついた、ということのようです。おもしろいですね。もちろん、内容自体の学びもあるのですが、登壇をきっかけに深いふりかえりによる内省が行われ自身の行動が明確化された、というところにも学びがありますね。別に登壇する機会がなくてもこういう内省自体には価値がありそうです。こういう気づきを与えてくれた盗み聞きの会話があるのもカンファレンスの醍醐味ですね。 続いて、りんさんの どうやら人って変われるらしい。一年半コーチングを受けて見つけたコンフォートゾーンの超え方。 という登壇を拝見しました。個人的に最近コーチングに興味があって学んでいる最中なのですが、クライアント視点でどう行動変容が行われたのか？という話は非常に学びがあります。コーチ視点だとクライアントの話を聞きながら適切なコーチングのスキルを活用していくことが求められるのではないかと思うのですが、そのコーチのあり方がクライアント側からはどう見えるのか？が垣間見えました。コーチングは共同関係だと思うのですが、まさにコーチだけではなくクライアントの努力があってこその行動変容なんだなと思いました。 お昼の時間帯は「はじめまして！」な方々とランチに行きました。厳密にはみんながみんな「はじめまして！」ではないのですが、まあいいでしょう。たまたま同じグループに地元の方がいらっしゃいましたので「いい感じの」ラーメン屋さんに行きました。おいしかったですね。その後、 鯛きち というおみせに行ってずんだ餅のたい焼きを食べました。 午後の時間帯はやはり登壇が行われるのですが、登壇と並行してコーチズクリニック、ワークショップ、フォトブース、OSTが行われます。なお、ワークショップは午前中からありました。本当はでたいワークショップがあったのですが、1日目の時点でほとんどのワークショップが定員に達してしまったので諦めました。私はほとんどOSTを行う部屋で過ごしていましたが、OSTとはいいつつもずっと誰かが話したいテーマを熱く語り合っていたり、たまにリーンコーヒーで構造的に話題を切り替えながら話をしていました。ここではかなりディープな内容を話していたのかなと思います。それこそ登壇では言えないような話とかがあるので、実は結構学びになる場だったかもな、と。 そういえば、スクラムフェス仙台が開催された会場である enspace さんについて話していませんでした。もともと最初のオーガナイザーだった天野さんが「スクラムフェス仙台やりたいなー」という構想段階で「じゃあうちでやりなよ！」と声をかけてくれたのが enspace さんだそうです。場所も日程も決まっていないし、なんならどういうコンセプトで何をやるのかすら決まっていない状態で声をかけてもらった感じみたいですね。 enspace さんはこのように初回からかなり協力的なのですが、実際のスクラムフェス仙台当日の動きについてもかなり協力的です。スクラムフェス仙台ではだいたい運営の方が紫色のTシャツをきていらっしゃるのですが、 enspace のスタッフの皆さんも同じ運営のTシャツをきています。つまり、 enspace のスタッフの方々もスクラムフェス仙台の運営として全面的に協力されていました。 enspace のスタッフさんお二人と話す機会がありました。一人目の方は大学4年生だとのことで、 enspace には大学1年生の頃からインターンとしてお仕事をされているとのことでした。「ここのお仕事はものすごく楽しい」と言っていたのが印象的です。来年からは新社会人として東京の会社に就職されるそうで enspace から離れるのを名残惜しそうに話しておりました。もう一人の方は大学3年生で enspace には大学2年生の頃から関わっているようです。こちらの方も「もうすごく楽しくてくるのが楽しみなんです」ということを言っていました。そして、スクラムフェス仙台が開催される日程が決まると、自分のシフトをそこに合わせるようにしたとのことでした。いわく、「スクラムフェスは楽しい」とのことです。会場を提供しているスタッフの方がこういう風に言ってくれるのは、ただの参加者である私にとってもとてもうれしいですよね。そして、そういう協力を惜しみなく提供する enspace のスタッフの皆さんにも本当に感謝したいです。 ここまでつらつらとスクラムフェス仙台の感想を書いてみました。もちろん、それぞれの登壇にも学びがありましたが、この場自体に存在することそれだけでも学びがありました。スクラムフェス仙台は今回が初めての参加でしたが、また来年も機会があれば行きたいですね。最後に、タイミーのメンバーで撮った写真をはっておわろうと思います。 タイミーからきた参加者の皆さん

8月6日、タイミー、UPSIDER、カケハシの3社共催による「 生成AI時代のPdM - 活用と未来戦略 」と題したイベントが開催されました。本イベントでは、プロダクトマネジメントにおける生成AIの活用と、それに伴うPdMの役割の変化に焦点が当てられました。本レポートでは、タイミーのプロダクトマネージャーである柿谷 樹の講演「AIで変わるPdMの役割 — 思考する力が武器になる」を書き起こし形式でお伝えします。 はい、株式会社タイミーの柿谷と申します。よろしくお願いします。 本日は『生成AI時代のPdM』というテーマで、『AIで変わるPdMの役割 — 思考する力が武器になる』という、少々仰々しいタイトルでお話しします。今回は『思考』をテーマにしたいと思います。 改めまして自己紹介をさせてください。株式会社タイミーでプロダクトマネージャーをしている柿谷です。バックグラウンドとしては、リクルートで新規事業開発を経験後、主にtoB領域のプロダクトマネジメントを5年ほど経験しました。昨年タイミーにジョインし、現在はバーティカルな市場での売上拡大を担当しています。タイミーは2-side-platformですが、toB担当・toC担当のように線を引かず、バリューストリーム（ユーザーに価値が届く一連の流れ）を単位に開発チームを組成しています。そのため、1人のPdMがプラットフォームの両面を横断して見ることが多いです。 それでは本題に入ります。このテーマを考えるにあたり、プロダクト開発の前提が大きく変わる中で、結局PdMに何が残るのかを突き詰めた結果、PdMの価値は『思考』へシフトするのではないかという結論に至りました。本日はその点について重点的にお話しできればと思います。 アジェンダは『思考する』『思考を止めない』『思考環境を整える』の3つです。 1. 思考する ── 文脈を設計し、出力を見極め、対話で共有する まず『思考する』についてです。『思考とは何か』という話ですが、デカルトの『我思う、故に我あり』といった話ではなく、私が読んだ本の中で非常に的確だと感じた説明を引用します。『思考とは、思考対象に対して何らかの意味を得るために、頭の中で情報・知識を加工すること』です。これは関数的な処理と捉えることができ、事象と知識というインプットからメッセージや意味合いというアウトプットを出すプロセスです。 この構造はAIの処理と似ていますが、本質的に異なる点があります。AIは不完全な入力に対しても、ハルシネーション（もっともらしい嘘）によってそれらしい出力を生成してしまいます。そのため、結局は人間による品質担保が不可欠です。ここに人間の価値が残ると考えており、プロダクトマネージャーには『コンテキスト設計能力』と『出力に対する審美眼』が求められるようになります。 この変化に伴い、ドキュメントの位置づけも変わってきます。アジャイル開発宣言では『ドキュメンテーションよりも対話』とされていましたが、AIに読み込ませるコンテキストが重要になる今、ドキュメントがAIへの重要なインプットとなり、PdMには『Why』を構造化するスキルが求められるようになります。これはPdMの役割が『コンテキストデザイナー』に変わることを意味します。ただ、これはドキュメント主義への回帰ではなく、コミュニケーションの重要性は普遍です。最終的にPdMには『思考の構造化』と『納得を生む対話力』が求められるようになると考えています。 2. 思考を止めない ── 継続的ディスカバリーが競争力の源泉に 次に『思考を止めない』についてです。これからの時代、継続的なディスカバリーこそが競争力の源泉になると考えています。一次情報が非常に重要になります。開発のデリバリー速度が爆発的に向上する中で、ディスカバリーも同じ速度で回す必要があります。そのためには、高速で一次情報に触れられる環境を構築し、そこから得た情報をもとに思考を常にアップデートし続ける仕組みが不可欠です。 では、何が大事かというと、これもAIとは直接関係ない部分もありますが、インタビューのリードタイムを極限まで短縮することです。明日インタビューしたいと思ったら、明日実行できるようなオペレーションを構築することが重要です。その上で、議事録の下書き作成などはAIに任せ、人間は考察に集中できる環境を作ります。そして『 オポチュニティ・ソリューション・ツリー（OST） 』のような思考フレームワークを活用し、論点を常にアップデートし続けることが重要です。 3. 思考環境を整える ── Bullshit Jobを減らし、意味ある仕事に集中する 最後に『思考環境を整える』についてです。PdMの仕事は『意味を作る仕事』へとシフトしていきます。AIの進化により、議事録作成や会議要約といった戦術的な労働から解放され、PdMは『意味の創造』という、より本質的な価値に時間を充てられるようになります。そのためには、いわゆる『ブルシット・ジョブ（無意味な仕事）』を減らし、思考しやすい環境を整えることが重要です。 チームや組織でAIを活用する方向性は、大きく2つに分けられると考えています。一つは、個人の成功事例を横展開し、チーム全体の生産性を底上げする試み。もう一つは、AI前提のオペレーションを抜本的に設計し直す試みです。まずは個人がアドホックにAIを活用し、そこで得たコンテキストや優れたプロンプトをチームで共有するなど、ボトムアップで進めていくのが現実的でしょう。 まとめ まとめになりますが、これからのPdMに求められることは、『思考する』『思考を止めない』『思考環境を整える』という3点です。 タイミーは積極採用中です。ご興味のある方は、カジュアル面談からでもぜひお声がけください。ありがとうございました。 hrmos.co 本講演のアーカイブはこちら 本講演の登壇資料はこちら speakerdeck.com

タイミーQAEnablingチームの松田( @yoshi_engineer_ )です。 先日、私の地元で開催されたスクフェス大阪に参加してきました！ スクラムフェスに初めて参加したのは去年のスクラムフェス大阪24でして、その時の感動と熱が忘れられず、25年度も参加することに決めました。 www.scrumosaka.org 去年は個人で参加したのですが、今回は弊社のTED10というエンジニアの成長を支える制度を利用して参加させていただきました。 productpr.timee.co.jp 今年のスクラム大阪は去年とはまた違った取り組みも多く、参加者としてはとても満足しておりその取り組みも紹介できればと思います。 コーチーズクリニック ～経験豊富なコーチに相談してみよう～ 今回スクフェス大阪初の試みのコーチーズクリニック。 他のスクフェスでは何度か開催され、大変好評だったことから今回大阪でも採用されたとのことです。 そして今回はありがたいことにyoh nakamura( @yohhatu ) さんとのコーチーズクリニックを受けることができました。 以前から個人的に知っており、大変尊敬するお方でもあったので、とてつもなく緊張していたのですが、温かな笑顔で迎えてくださり、安心して対話し始めることができました。 私のスクラムに関する悩みを傾聴していただき、温かな空気の中、自分でも驚くほど話すことができました。 yohさんが寄り添いながら相槌を重ね、「どうして松田さんはそう思ったのかなー？」「松田さんの中でどうやったらもう少し良くできるだろう？」私が悩みを伝える中で、的確なタイミングで問いをいただきました。その答えも「あ,,,,じゃあ、こうしたら良いかも…！」と1人では気付けなかった(確信が持てなかった)仮説に自分から気づき言葉にすることができました。 ほとんど私の話だけで終えてしまったコーチングの時間でしたが、yohさんから「スクラムをする時、大事なのは、強い情熱持つことだよ。」と一言いただきました。 その言葉を聞いて、私はグーっと体の芯から力が湧き起こるような感覚になりました。 自分が困難な時、挫けそうになった時、yohさんからもらった言葉をお守りに頑張ろうと思います。 yohさん、有意義なお時間いただき本当にありがとうございました！ 私の心を打ったsession アジャイル、諦めなかった10年 JTC,SIer,受託で挑んだリアル confengine.com JTC,SIer,受託会社の3社でアジャイル開発を推進を試みてきたOshikata( @oshikata200 )さん。この登壇はまさに理想と現実の中で泥臭く実践を行ってきたOshikataさんの10年間の軌跡を赤裸々に語っていただきました。 このセッションで話された内容は一言で言えば「組織改革への実践知」です。 「置かれた場所で咲く」よりも「咲ける場所を探す」べきなのか Oshikataさんはこれまで組織にアジャイルを導入すべく何度も奮闘してこられたのですが、組織の習慣や形態により導入するにあたって何度も壁にぶつかりました。 しかし、Oshikataさんの気づきはこうでした。 ソリューションやプラクティスを導入することを重視するのではなく、まずチーム、そして組織文化へのアプローチが必要。また、それは長い時間をかけて少しずつ行うことが重要。 失敗を恐れず、「増やす」から、「手放す」へ 企業の特性上、ドキュメントやルールが加速度的に増える現状があります。その背景には「過剰な失敗への回避」がそうせてる可能性があります。 しかし、そこで増えたドキュメントやルールは逆にメンバーやチームへの足枷になり速度と自立性を失わせます。 資産と思い積み重ねたものは、いつの間にか負債に変容。 現状を打破するためにも、形骸化されたルールやドキュメントを減らすことを推進されました。 負債を大きくするよりも、動きやすくするために手放すことを実践されました。 詰め込みすぎた制度,ルールがあるとそこから試行錯誤する姿勢が損なわれていきます。 “人を囲う”より,”みんなで空気を耕す” 「メンバーへの執着を手放す。そうではなく組織の空気を耕す」メンバーに執着することで自分のチームだけを囲うことは、長期的に見れば組織の衰退を助長します。 そうではなく、できる人材こそどんどん他の部署やチームに手放す。そしてまた新たなメンバーと対話し、組織の空気を耕していく。 それを体現するためにも、個人への信頼関係の構築が肝になる。 信頼関係の気付けた組織を耕し、メンバーがある範疇の制度の中でワークすることで工夫が行わられる。 「“強い個”を集めるのではなく、“みんな”で空気を耕す。 少しずつ、一歩一歩確実にみんなで進むことから風土が醸成されていく」 一朝一夕で組織は変わらないが、その一つ一つの積み重ねを愚直に行うことで芽が開く。とてつもなく大きい情熱を持って歩んでこられたOshikataさんのsessionは大きな学びと気づきを与えてくださいました。 困難な状態も、組織の実態もマイナスな要素をあげればキリがない状態であったとしても、少しずつ改善を重ね進まれていく姿が、今度は自分も頑張ろう！と心に火が灯るような感覚を覚えました。 おわりに 今回のスクラムフェスでも大変大きな気づきと学びを得ることができました。 この気づきと学びを活かして、より精進していきたいと思います！ いつか私も聴講者としてではなく、登壇者としてスクラムフェスに寄与できればと思います！

こんにちは。データアナリストのtomitaです。 先日、社内のPdM（プロダクトマネージャー）とアナリストが中心となり、当社にとって重要な業界の一つである物流業界に関する勉強会を開催しました。 今回は、その内容と、そこで見えてきた当社の魅力についてご紹介したいと思います！ 生成AIを駆使した『AI駆動勉強会』 今回の勉強会で最も特徴的だったのが、生成AIを活用した新しい学習スタイル『AI駆動勉強会』です。 これは、参加者各自がリサーチクエスチョンを設定し、それに対して生成AIを使って調査を行い、アウトプットと深掘りを行うスタイルです。 生成AIを使うことで、これまで何時間もかかっていた情報収集を短縮し、より本質的な議論に時間を割けるようにしました。 勉強会の様子 『AI駆動勉強会』の進め方 リサーチクエスチョンを立てる (5分)：各自が知りたいテーマについて具体的な問いを立てます。 AIで調査する (15分)：生成AIを使い、設定した問いについて効率的に情報を収集します。 アウトプット＆質問深掘り (2分)：調査結果を簡潔にまとめ、参加者と共有。疑問点やさらなる深掘りについて議論します。 このセッションを1.5〜2時間で2〜3回繰り返すことで、短時間で多くの学びを得ることができました。 参加者からの声 「リサーチクエスチョンを先に立てることで、集中して学習できた！」 「アウトプットと質問深掘りの時間で、学習内容がより深く定着した」 「AI活用の練度が上がり、効果的なプロンプトなどの知見が共有されたのが良かった」 「他の人のリサーチクエスチョン自体に学びがあり、視野が広がった」 部署を超えたメンバーとの交流 今回の勉強会には、アナリストだけでなく、PdMや元CSM（カスタマーサクセスマネージャー）で物流業界に詳しいメンバーまで、幅広い職種のメンバーが参加しました。 例えば、元CSMのメンバーからは、物流現場でのリアルな課題が共有され、AIによるリサーチだけでは得られない学びがありました。 多角的な視点からの議論は、私たちデータアナリストがデータから導き出したインサイトを、プロダクト改善やビジネス戦略に繋げる上で不可欠です。異なる専門性を持つメンバーと気軽に意見交換できる環境は、当社で働く大きな魅力の一つだと改めて感じました。 リモート参加も可能な柔軟な働き方 今回の勉強会では、多くのメンバーがオフィスに集まりました。私自身は家庭の事情でリモートでの参加でしたが、オフィスにいるメンバーと変わらず、活発な議論ができました。 当社のプロダクト組織では、働き方の柔軟性を担保する観点から、リモートワークOKとなっています。場所や時間にとらわれずに質の高いインプットとアウトプットができるのは、非常にありがたい環境です。 終わりに 今回の物流業界勉強会は、当社のPdMとアナリストが中心となり、生成AIを駆使した独自のスタイルで実施しました。AIで調査を進め、その結果をアウトプット・深掘りすることで効率的に物流業界への理解を深めることができました。 また、部署を超えて様々な職種のメンバーが参加することで、AIだけでは得られない物流現場でのリアルな課題が得られたり、多角的な視点からの議論ができたりしました。 We’re Hiring! 私たちは、ともに働くメンバーを募集しています！！ カジュアル面談 も行っていますので、少しでも興味がありましたら、気軽にご連絡ください。