こんにちは、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つの方法があります。

1. CloudWatch GetMetric API方式
   • CloudWatchのAPIを定期的にポーリングしてメトリクスを収集
   • メトリクスの遅延が15-20分程度発生する可能性がある
     • CloudWatch側の遅延（5-10分）
     • Datadogのポーリング間隔（10分）
     • APIレート制限による追加遅延（最大5分）
2. CloudWatch Metric Streams方式
   • ストリーミングしたメトリクスをAmazon Data Firehoseを介してDatadogに送信
   • aws.s3.bucket_size_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.valueRegions =join(",",["us-east-1",      data.aws_region.current.name])}lifecycle{ignore_changes =[      parameters["ApiKey"],# ApiKeyの変更を無視]}}

コスト面の考慮

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

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

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

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

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

切り替え時の考慮

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

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

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

まとめ

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

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

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

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

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

speakerdeck.com

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

productpr.timee.co.jp

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

Keynote "Scaling Ruby @ GitHub"

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

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

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

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

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

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

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

github.blog

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

（@euglena1215）

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

(@dak2)

Writing PDFs in Ruby DSL

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

github.com

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

github.com

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

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

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

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

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

(@dak2)

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

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

speakerdeck.com

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

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

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

（@euglena1215）

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

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

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

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

(@dak2)

Regional.rb and the Tokyo Metropolis

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

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

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

（@euglena1215）

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

(@dak2)

Keynote “Ruby と Rust と私”

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

speakerdeck.com

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

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

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

(@dak2)

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

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

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

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

きっかけ

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

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

勉強会当日の流れ

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

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

LTの発表内容

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

ファインディ

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

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

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

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

タイミー

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

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

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

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

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

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

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

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

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

懇親会の様子

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

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

振り返って

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

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

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

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

終わりに

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

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

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

Day 0

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

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

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

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

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

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

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

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

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

Day 1

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

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

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

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

Day 2

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

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

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

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

Day 3

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

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

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

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

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

まとめ

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

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

こんにちは。タイミーのデータアナリティクス部でデータアナリストをしている亀山です。担当業務としては、主に営業部門のデータ分析を行っています。

今日はA/Bテストと※DIDの効果検証がより信用できるように仕組みづくりをした話を紹介したいと思います。

※DID（Difference in Differences、差分の差分法）は、ある施策の実施前後で、影響を受けたグループ（比較群）と影響を受けなかったグループ（対照群）の変化を比較することで、介入の効果を推定する手法です。

取り組んだ背景

以前同じ部署の夏目さんがブログで取り上げている通り、データアナリティクス部では過去に、効果検証の事前設計と結果を管理できるような仕組みを作成しました。その後、効果検証のテンプレートは多く使用されるようになり、知見も貯まってきましたが、残課題としては以下がありました。

• 汎用性の高いシンプルなテンプレートを作成したため、A/Bテストなど特定の手法を駆使した効果検証では入力項目に不足がある
• 特定の効果検証の手法も積極的に使っていきたいが、手法に関する知識が人によって差があるため、効果検証のクオリティにばらつきが出てきてしまう

やったこと

今回は、これらの課題を解消するために、よく使われる効果検証の方法論のドキュメント化とその手法に特化したテンプレートの作成を行いました。

1. よく使われる効果検証の方法論のドキュメント化

社内でよく使われる効果検証としてA/BテストとDIDがあげられたため、それらの方法論のドキュメント化を行いました。

ドキュメントは以下のようにNotion上にデータベースを作成して、A/BテストとDIDが一覧ですぐに参照できる形式にしました。

これらのドキュメント整備で工夫した点は2点あります。一つ目は概論や設計方法だけでなく、社内事例を参照した解説まで記載したことです。ただの効果検証手法の説明であれば、ネット検索をすれば参照できますが、社内事例も含めることで、タイミーで行う効果検証だからこそ、考慮するポイントなどを記載しました。

二つ目は社内事例の解説の箇所で、Pythonなどのサンプルコードも記載したことです。説明だけでなくサンプルコードも載せることで、コードの転用につなげ、作業効率の向上を図りました。

1. 特定の手法に特化したテンプレートの作成

A/BテストとDIDのそれぞれの手法に特化したテンプレートも作成しました。背景でもお話しした通り、それまでのテンプレートは汎用性が高くシンプルな形式でしたが、今回作成したテンプレートはそれぞれの手法ならではの入力項目を追加しました。

例えば以下の画像のように、A/Bテストならば「Randomizeの単位」や「割り当てタイミング」などA/Bテストで考慮すべきポイントをテンプレに含ませるようにしました。

まとめ

新しいテンプレートを作成してから2ヶ月弱経ちましたが、従来のテンプレートに加えて、今回作成したテンプレートも使ってもらえているようです。今後の展望としては、他の効果検証の方法の追加や既存のドキュメントのブラッシュアップも行っていき、より信用できる効果検証を行える仕組みを作っていきたいです。

また、個人的な感想ですが、私はDIDを担当することで、今までの知識の整理ができてとても良かったです。知識は入れるだけでなく、外に出すことも必要だなあと思います。今後もインプット・アウトプットを繰り返すことで、自身の分析スキルも引き上げていきたいです！

We’re Hiring!

タイミーでは、一緒に働くメンバーを募集しています。

https://hrmos.co/pages/timee/jobs

カジュアル面談も実施していますので、少しでも興味を持っていただけましたら気軽にお申し込みください！

タイミーのプロダクトマネージャー（以下、PM）の 柿谷（@_kacky）、 高石（@tktktks10）、吉池、大歳 です。

今回は、タイミーの「Kaigi Pass」制度を利用し、12/6にオンサイト開催されたプロダクトマネージャーカンファレンス（以下pmconf）のDAY2に参加してきました。

この制度を通じて、非常に有意義な学びを得ることができましたので、その内容を共有します。

2024.pmconf.jp

productpr.timee.co.jp

プログラム概要

1. パネルディスカッション

   テーマ：「プロダクトマネージャーと仮説/戦略」

   登壇者：FoundX 馬田さん、Zen and Company 宮田さん

2. OST（Open Space Technology）

   参加者持ち込みテーマでのディスカッション

3. 懇親会

   他社のPMと交流するネットワーキングの場

パネルディスカッションからの学び

「プロダクトマネージャーと仮説/戦略」というテーマで行われたセッションでは、戦略の現状や仮説構築におけるポイントが深く掘り下げられました。

戦略のコモディティ化

宮田さんが指摘した「戦略のコモディティ化」という現状に対し、差別化の重要性が議論されました。タイミーにおいては、プロダクトマネジメントや戦略を担う立場でもあるため、プロダクトマネージャーがどこにエッジを立てるべきかを再考するきっかけとなりました。

実はSaaSって、国内だと取れる戦略少なくて、4パターンぐらいに集約されるんじゃないか。

・会計、人事や契約レビューや契約書管理などは垣根を超えて、Multi-Horizontal化
・Verticalは参入障壁高くて、じっくりAll-in-Oneを作り込む…

— Yoshitaka Miyata / 宮田善孝 (@zenkou_1211)2024年7月22日

仮説構築の重要性

宮田さんは、仮説は地道なインプットを重ねた結果として生まれるものであり、見栄えの良さを求めるべきではないと強調していました。また、日本のプロダクトマネージャーが海外事例を十分に収集せず、国内のプラクティスに偏っていることや、議論テーマが数年間変化していない点に警鐘を鳴らしていました。

近年は、ChatGPTのようなツールやX（Twitter）を活用して、海外の著名なPMの投稿や事例を簡単に収集できる環境が整っています。

私自身も、海外事例を意識的に取り入れる姿勢を持ちたいと感じました。

AI経済の構造改革

馬田さんからは、書籍『AI経済の勝者』のフレームワークを用い、AIを活用した3つのソリューションレイヤー（ポイントソリューション、アプリケーションソリューション、システムソリューション）についての説明がありました。特に、リスクを取りながらシステムソリューションレイヤーに挑戦し、構造的な変革を進めることの重要性が強調されていました。AIを前提とした新しいルールや戦略については、まだ理解が浅い部分も多いため、該当の書籍を読み、知識を深めたいと思います。

productpr.timee.co.jp

OSTでのディスカッション

OSTセッションの開始に先立ち、pmconfスタッフから進行方法の説明がありました。その後、会場から話したいテーマを募り、16の分科会に分かれて合計3回のディスカッションが行われました。

それでは、実際に、我々が参加したOSTで取り上げられたトピックに触れたいと思います。

プロダクトマネジメントに関する海外事例や書籍について知りたい

このテーマでは、パネルディスカッションで取り上げられた海外事例をもとに議論が行われました。プロダクトマネジメントにおけるプロセスや役割の定義など、海外事例をどのように参考にし、実践しているのかが話題に上りました。しかし、参加者の環境や事業フェーズ、提供するサービス内容が異なるため、議論は各自の事例紹介にとどまりました。

さらに、プロダクトの海外展開時におけるPMの役割や、プロダクト開発体制、国内と海外のカルチャーの違いへの対応についても議論が広がり、非常に興味深い内容となりました。

LLMの活用事例

「LLMの活用事例」では、以下の点について議論が行われました。

• AI投資の方向性:

  トップダウンで進める企業が多い一方、エンジニア主導でボトムアップに進めるケースも見られました。特にアーリーフェーズでは投資家の影響が強く、AIへの投資は手段が目的化しているように見える場合もありました。

• ROIの課題:

  ROIの可視化が難しい中でも、AIへの投資は不可欠であるという意見が多く出ました。

個人的には、どんなユースケースで活用できるのか考える営みは、プロダクトマネージャーとして最低限要求されるべきなのかなと思いました。改めて、自社のプロダクトマネージャーや戦略部門のメンバーとも議論してみたいなと思いました。

リテンション施策の効果検証

「リテンション施策の効果検証がしづらい」というテーマでは、多くのPMが同じ課題を抱えていることが分かりました。他社のPMからは、データアナリストが充実している弊社の環境について羨ましいという声をいただき、自社の強みを改めて実感しました。

一方で、効果が測れない施策については、測定の努力を続けながらも「やるべきことを決める仕組み」が重要だと考えています。

BtoBtoCのプロダクトはCにどのように向き合うか

多くのBtoBtoCプロダクトにおいては、キャッシュポイントがBにあるためにCに対する体験改善がどうしても後回しになってしまう課題感について各社の意見交換が行われました。

各社の知見を寄せ集める中で「Cの声を現場までインタビューしにいく」ようなすぐできるアプローチから「Cの体験が良くなることでKPIが達成され、売上があがるようなビジネスモデルに変更する」といった根源的なアプローチまで、さまざまなアイデアが生まれました。

個人的には、顧客が満足するポイントとキャッシュポイントの距離の近さは、優秀なビジネスモデルを構築する上で重要な要素の一つだと考えています。今後自分がプライシングに関わることがあれば、意識したいですね。

メンバーへのスケジュール意識を高める

PMとしてはスピード感を持ってプロジェクトを進めていきたいと考えているが、その温度感・危機感のようなものがどうもチームメンバーに伝わらない….。そんな課題について掘り下げるグループでした。

会話の中では「そもそもどうしてスケジュール感が必要なのか」といった課題の発端について意見交換が行われ、

• 経営陣がプロジェクトの進捗に不透明さを感じており状況を把握したいため
• 顧客の不便を早期に解消したいため
• 確定申告など、1年に1度しか訪れない外部イベントに間に合わせる必要があるため

など、多種多様なきっかけがあることが分かりました。

基本的なアプローチとしては、PMが情報を包み隠さずチーム全体で情報の非対称性を減らしていくことが大事そうです。しかし、元の課題によっては単にチームの計画をオープンにしたり、開発する機能のスコープを削ったりと、スケジュール意識を高める以外の解決方法もありそうだと感じています。

非エンジニアPMの生存戦略

「非エンジニアPMの生存戦略」では、以下の点について議論が行われました。

• 活躍するために必要なケイパビリティについて

  まずは圧倒的に自身の強みであると言えるだけのスキルや経験、ドメイン知識を獲得すること。その自身の強み＝ケイパビリティが顧客価値の拡大に寄与する実績を積み上げて深さを出すこと。そのあとに、抽象化と転用でケイパビリティをさらに広げていくと良い、という意見がその場の総論となりました。

• 結局、エンジニア経験を積むべきか？

  主張の一つとしては、見積もりに対する妥当性評価をするためにも一定のエンジニア経験は積むべきという意見がありました。 しかし、その意見は内製の開発組織ではなく、発注元企業の企画担当と請負または準委任の受託企業の関係性を前提としているものでした。ビジネスパートナー関係による利害関係が発生する場合についてであったため、PM とエンジニアが同じ顧客に向かって利害関係なく動く組織においては、必ずしもエンジニア経験は必要ではないといった対比の意見も出ており、開発体制や文化、事業フェーズなどによるという結論となりました。

PM組織の構造

「PM組織の構造」では、以下の点について議論が行われました。

• 事業部制における PM 組織のあり方

  事業部長がトップにいる中での PM 組織におけるレポートラインの妥当性 （CPO といった機能職種としてのトップより PL 責任を持つ事業部長のキャリアしか道がなさそう）と、その組織のマネージャーの振る舞いをどうするかといった議論がなされました。 事業フェーズや経営上、事業上の課題により適切な組織デザインが思考されるべきで、一義的なものはないという意見が多く出ました。

懇親会での交流

懇親会では、他社のPMとリアルに交流する機会がありました。Xで知っていた方々と直接話せたのは特に有意義でした。数年ぶりに再会する方もちらほらいたりして、楽しい時間でした。

異なる環境や課題を持つ企業の話を聞くことで、自社の環境や課題を相対的に捉え、視野を広げる良い機会となりました。

最後に

今回のカンファレンスを通じて、多くの刺激を受けると同時に、自分自身のキャリアや現在の課題について深く考える時間を持つことができました。特に、大量のインプットを通じて質の高い仮説を構築する重要性や、AI時代におけるプロダクトマネージャーの役割について再認識しました。

Kaigi Passを活用して得たこの学びを、今後の業務にしっかり活かしていきたいと思います。