Timee Product Team Blog

タイミー開発者ブログ

タイミー、CREはじめました

このエントリは「Timee Advent Calendar 2024」の12月2日分のエントリーです。

私は誰?

2024年5月入社した山田といいます。
ニックネームは「やまけん」とみんなから呼ばれています。
本名より浸透しているので、社員の中には本名を知らない方も一定いる(らしいです)。

productpr.timee.co.jp

前職では、オンライン商談システムを展開するベルフェイスでCREチームのマネージャーをやっておりました。

note.com

タイミーは現在、累計ワーカー900万人にご利用いただいているサービスとなっています。
これからも多くの方々にいいサービスを提供し続けられるよう、タイミーでは顧客満足度を技術的アプローチで高めていくためにCREチームを立ち上げることとなりました。
今日はタイミーでのCREの立ち上げから現在、そしてこれからについてお話します。

CREのはじまり

本題へ入る前に、あまり聞き慣れないであろう「CRE」についてご説明します。
CREとは、Customer Reliability Engineering(顧客信頼性エンジニアリング)の略称で、Googleが2016年に専門職種として立ち上げたことが始まりとされています。
GoogleがCREチームの重要性を初めて強調したのは、SRE(Site Reliability Engineering)が自社のインフラを安定させるための内部的な役割に特化していた一方で、顧客のシステムやアプリケーションにも同じレベルの信頼性が求められるようになったからです。
特に、クラウドサービスを提供する企業では、顧客側の環境でのダウンタイムやパフォーマンスの問題が、結果として自社のブランドイメージに影響を与える可能性が高いため、顧客と一緒に信頼性向上を目指すためにCREが生まれたとされています。

cloudplatform-jp.googleblog.com

CREの特徴

CREは、従来のサポートチームやカスタマーサクセスチームとは異なり、技術的な専門知識を持つエンジニアを主体として構成されます。
CREでは、技術的な信頼性やパフォーマンスにフォーカスし、エンジニアリングの観点からシステムの安定性を保証します。
例えば、企業内部でのSite Reliability Engineering(SRE)の原則と手法を、顧客の環境に適用することを目的とし、顧客のシステムやクラウドインフラの信頼性を保証しています。

タイミーでのCREの役割

ここからが本題になります。
前述したGoogleでのCREは、主に開発者向けにプラットフォームやAPIなどを提供する事業の中でSREから派生した役割でした。
一方で、タイミーのようなエンドユーザに機能と体験を提供する事業会社では、Googleが提唱したような役割すべてにあてはめることはできないため、以下の役割を持つこととしました。

顧客満足度向上を推進するために小〜中規模程度の開発及び改善を高速に実行する

CREが向き合うべき課題は、自社既存顧客のVoCの中から顧客満足度改善に帰結する小〜中程度の課題を取り扱います。
ここでいう小〜中程度の課題とは、1ヶ月以内で開発〜リリースのできるもの、または調査・分析、開発〜リリースまでのリードタイムが最大でもクォーター(3ヶ月)以内で対応を完結できる課題を取り扱うこととしています。

タイミーCREの提供価値

タイミーのCREのアウトカムは大きく2つあります。
1つは顧客が使っているスマホアプリや事業者向けシステムの機能改善を推し進めることで顧客満足度を高めていくことです。
もう1つは、顧客と接点のある部署(営業、カスタマーサポート etc…)が顧客に向けたサポート力を高めることです。
こちらは社内の管理システム等の機能改善を推し進め、営業やカスタマーサポートといった、顧客と接点を持つ人たちのサポートを充実化させていくことが該当します。

CREの今とこれから

現在、タイミーのCREでは社員が情報を安心安全に活用できるように今夏から情報セキュリティ強化施策を中心に、社員が利用する管理システムの利便性改善に取り組んでいます。
プロジェクトは順調に進行しており、セキュリティ強化施策も終盤に差し掛かってきたため、来年からプロダクトの顧客満足度改善の本格始動へ向けて着々と準備を進めています。
サービスが急成長している中でも、安心、安全に利用できるプロダクトを目指して、CREは顧客に寄り添う開発に取り組んでいこうと思います。

顧客の体験を良くしていくためのプロダクト開発に興味ある方は、是非一度お話しましょう!

認定スクラムマスター研修で得た気づきと、その後の歩み

タイミーのsyam(@arus4869)です。アドベントカレンダーの初日を担当します!

2024年も残りわずか。今年中にやりたかったことの一つが、6月に参加した「アトラクタの認定スクラムマスター研修」の振り返りをまとめることです。この研修では、スクラムの理論を実践しながら学び、多くの気づきと学びを得られました。

私はスクラムマスターではありませんが、チームと共にスクラムを実践する立場です。研修を通して得た知見を、開発者目線で共有したいと思います。同じようにスクラムを学んでいる方々の参考になれば幸いです。


研修の内容と学び

研修中の様子

6月に参加した「アトラクタの認定スクラムマスター研修」は、実践を通じてスクラムの考え方やイベントの進め方を学べる宿泊型の研修でした。

詳しい研修内容についてはネタバレを避けるためここでは触れませんが、興味がある方は公式サイトや同じ研修に参加された櫻井さんのレポートをご覧ください。

研修で印象的だった学びを3つのポイントにまとめてお伝えします。


1. バックログ管理の新しい視点

スプリント計画を模擬的に体験する中で、「バックログは優先度ではなく縦の順番で管理する」という考え方に触れました。このアプローチは非常に新鮮で、「今、一番解決したい課題」に集中する仕組みを整えられると感じました。

従来は優先度が高いものから進める方針が多かったため、割り込みや変更による並列作業が増えることが課題でした。 しかし、この研修での「縦に並べたバックログを順番に進めることで効率的に進行できる」というアプローチでは、順番に1つずつ進めることができるので、スイッチングコストが大幅に減り、1つの課題に集中しやすくなります。割り込み依頼が発生した場合も、既存のバックログに新しいタスクを適切に並べ直すだけで対応可能です。このシンプルな管理方法で、優先順位の変更にも柔軟に対応でき、チーム全員が次に進むべきタスクを迷わず把握できるようになります。

また、「バックログアイテムは具体的で詳細であるべき」という原則も再確認しました。特に、外部要因が絡むタスクや準備が整っていないタスクは「Readyではない」と判断し、進めないことが重要です。このルールを守ることで、不確実なタスクに時間を割くことなく、チーム全体の進捗を安定して保つことができるため、重要な考え方だと感じました。


2. チームの柔軟性を高める工夫

「スプリントゴールが変われば、バックログの順番も変わる可能性がある」という考え方はとても印象的でした。この仕組みによって、「チームが今何に集中すべきか」が自然と明確になり、計画そのものがチームの方向性を示すツールとして機能することが分かりました。特に、ゴールが具体的であるほど、チーム全体が一つの目標に向かって足並みを揃えやすくなる効果を実感しました。

さらに、「スプリントゴールは何を基準に決めるべきか」という議論では、明確な正解を求めるのではなく、その時点での最善を試す柔軟な姿勢が重要だと気づきました。このように、状況に応じてアプローチを調整できる点こそが、スクラムの持つ大きな強みだと感じました。


3. イベントごとの目的を見直す

スクラムイベントには、それぞれ明確な目的を持つことが重要だと学びました。

例えば、スプリントレビューでは、進捗を確認するだけで終わらせず、「次にどう進むか」を全員で議論する場にすることの大切さを実感しました。このように未来志向の議論を行うことで、チーム全体が次の課題に向けた共通認識を持つことができます。

さらに、模擬スプリントレビューでは、デモにサンプルデータではなくリアルなデータを使うことの効果を学びました。実際に使うデータを用いることで、ユーザー視点での具体的なフィードバックを得やすくなり、プロダクトの質を高める大きな助けになると感じました。

また、デイリースクラムでは「早期に問題の芽を摘む」という考え方に触れました。短時間であっても、全員で現状を共有することで、予期せぬ問題への迅速な対応力が身につくことを実感しました。


研修を経ての現在地

研修後、すぐに全てが変わったわけではありませんが、少しずつ改善を進めています。最近では、チーム内での見積もり方法を見直しました。

以前は「Tシャツサイズ」を使った見積もりを行っていましたが、「Mサイズが曖昧すぎる」という課題に直面していました。小さなMサイズも大きなMサイズも同じ扱いとなり、多くのタスクがMサイズに分類され、タスクの規模感がぼやけてしまうことが問題でした。

この課題を解決するため、現在は「フィボナッチ数列を使ったストーリーポイント」に切り替え、それぞれのポイントに具体的な基準を設ける方法を採用しています。これにより、リファイメントの際に基準を参照しやすくなり、チーム全体で見積もりの共通認識を持つことができるようになりました。


ストーリーポイント チームにとって必要な日数 作業例 基準となるPBI
1 0.5日以内 簡単なfunction追加、エラーハンドリングなど -
2 1日程度 クラスの作成、簡単なadmin機能の作成など。簡単な既存コードのリファクタリング -
3 2日程度 簡単なAPI作成、既存コードのリファクタリング、テストコード作成、デザインの作成、バックエンドの軽微な機能追加など。 -
5 3〜4日程度 フロントとバックエンドが絡んだ単一機能の開発 -
8 5日程度 フロントとバックエンドが絡んだ複数機能を持つ1画面程度の機能開発 -
13 10日以上(上限なし)※分割しなければならない 複数のプラットフォームが絡んだ2画面以上の機能開発、インフラの構築を含む新規アーキテクチャ構築など -

まだストーリーポイントで見積もりする手法を実験中のため、これからの振り返りや次のスプリント計画にどのように役立つかを検証し、改善していきたいと考えています。新しい方法を試す中で、チーム全体の共通理解を深めながら、少しずつ改善を重ねています。


締めくくり

研修会場の中庭

スクラムを実践していく中で得られた一番の気づきは、「小さな改善の積み重ねが、チーム全体の成長に繋がる」ということです。今回受けた「アトラクタの認定スクラムマスター研修」は、理論を学ぶだけでなく、実際に手を動かしながら多くの気づきを得られる貴重な機会となりました。

ストーリーポイントの導入や見積もり基準の設定といった取り組みが、これからどのような成果に繋がるのか、さらに試行錯誤を続けていきたいと考えています!

この記事は自分自身にとっての振り返りの一環となりました。 スクラムを学び始めた方や、すでに実践している方の参考になれば幸いです!

それでは、みんなでより良いチーム作りを目指してがんばりましょう!

Lookerで全社のデータ活用を推進した話

こんにちは、タイミーのデータアナリティクス部でデータアナリストをしているmihashiです。普段は主にタイミーのプロダクトに関する分析業務に従事しています。

今回は前期に社内で取り組んだデータ活用推進に関する事例を共有できればと思います。

前提

タイミーでは、全社のデータ利活用ツールとしてLookerを利用しています。これまでもより多くのメンバーにLookerを活用してもらうために、定期的に講習会を開催してきました(以下の記事も参照してください!)

なぜLookerでデータ活用を推進する話になったのか

1点目は、データアナリストだけでは増加するデータ関連ニーズへの対応が困難になってきたためです。タイミーでは社員数が1,000名を超え、データ活用スピードの向上が急務となっています。そのため、データアナリストだけでなく、各組織内でもデータ抽出が行える体制を構築する必要性が生じています。

2点目は、既存の取り組みだけではデータ活用の潜在能力を引き出しきれない点が課題として浮上してきたためです。各組織内での解くべき課題の難易度が増し、より高度なデータ活用が求められる中で、従来のLooker講習会だけでは対応しきれないケースが増えており、講習内容の見直しが必要なフェーズに差し掛かっていました。

そこで、社内でLookerに関するヒアリングを実施しました。その結果、「各組織にLookerを使える人材を最低1名配置することで、全社的なデータ活用を効果的に推進できるのではないか」という仮説が浮かび上がりました。この仮説に基づき、「全員がLookerの基本操作を習得するのではなく、各組織においてデータ活用の推進を担う人材がLookerを使いこなせる状態」を目指すべきという結論に至りました。

利用普及のために取り組んだこと

スキル水準の定義

社内ヒアリングの結果をもとに、タイミー独自のLookerスキル水準を策定しました。またこのスキル水準をもとに、期中でLevel2到達者を対象の3割程度を目標にして、データ活用推進の活動を実施することになりました。

スキルチェックの実施

スキル水準で定義した内容を軸としたスキルチェックの問題を作成し、対象者に受験をしてもらいました。また運営側も採点が実施しやすいよう、明確な採点基準の作成も行いました。

Looker講習会

約3ヶ月で、基礎編・応用編の2種類の講習会をオンライン・オフライン合わせて5回ずつ実施してきました。構成としてはインプット+実践で実施し、実践中はアナリストが不明点をフォローするようなハンズオン形式を採択しました。

Lookerクイズ

スキルチェックで誤答の多かった箇所を中心に、クイズ形式で解説を配信し、対象者の理解促進を実施しました。

ポータルサイトの整備

Lookerの使い方をまとめたポータルサイトを従来のものから大幅にリニューアルし、上記の講習会資料やLooker式の一覧などを掲載しました。今後もLookerを使いこなせるようになるためのさまざまなコンテンツを準備していく予定です。

やってみた振り返り

期末に再度スキルチェックを実施した結果、目標としていたLevel2到達割合には届かずでしたが、Level1到達割合は大幅に増加し、社内のLookerレベルの底上げに貢献できました。

一方で、実務でLookerを使うまで到達しにくいといった課題も新たに浮き彫りとなり、今後は実務での活用をサポートする仕組みを作ることも検討する余地がありそうです。

また副次的ではありますが、本取り組みを通じて自分自身もLookerに関する知識が向上し、業務を進める上での糧となりました。

We’re Hiring!

私たちは、ともに働くメンバーを募集しています!!

カジュアル面談も行っていますので、少しでも興味がありましたら、気軽にご連絡ください。

LeSS' Yoaké(レスの夜明け) Asia 2024に参加して感じたことをトークしてみました!

こんにちは。今回はLeSS' Yoaké(レスの夜明け) Asia 2024 というカンファレンスに参加したメンバーの内、3名で記憶に残ったセッションやトークについてざっくばらんに会話をしてみたので、その内容を一部編集したうえでブログにまとめさせていただきます。

登場人物の紹介

  • raz
    • プロダクトエンジニア。昨年まではスクラムマスターをしていました。
  • maho
    • バイブスキング。昨年からスクラムマスターをはじめました。
  • shihorin
    • スクラムマスター。2024年5月タイミーにジョイン。

印象に残ったセッションやトークはなんですか?

Last Day午前中のOST(オープン・スペース・テクノロジー)の様子。

shihorinが参加したテーブルでは「偉くないけど組織を変えたい」というテーマでディスカッションしていました。現場から組織へアプローチするにはどうすればいいのか、どんな課題がありそうなのかを話してみたかったので、このテーブルに参加。実績や感謝を積み重ねていった先で、上層部からの信頼を得て話せる機会を作っていくことが大事そう、といった内容でディスカッションをしていました。


shihorin:OSTの「偉くないけど組織を変えたい」というテーマが印象に残っています。現場は忍耐が必要だ、コツコツやろうと思っていても、それを組織の上層部と握れていないと結局覆されてしまうことがあるという話を中心にしていました。上層部が求めているのは、一般的に見えやすい数字であることが多く、実際にうまくいっているのかどうかは現場に近づかないとわかりません。だから、数字に表れるような成果をほしがってしまう一方、現場としては「数字だけじゃないんだよ」という声があって難しいという会話がありましたね。

raz:なるほどね。そのテーマ、確かにOSTでありましたね。Slackで見た記憶があります。偉いほうがやりやすいのはそうですけど、それは「トップダウンでやれ」と言っているのと同じです。深く考えずに言いますけど、アジャイルとかそういう最近の考え方で言うと、ズレている感じはしますね。

maho:場合によっては、トップダウンがあってもいいとは思うんですけどね。

raz:両方大事ですよね。

maho:うんうん。ただ、トップダウンだけだとコミットメントするのが難しいときはある気がしますね。

raz:すべての人が納得しないとうまく進められないから、推進する人が偉いかどうかはあんまり大事じゃないのかなって。もし推進する人が偉い人と会話も不可能みたいな立場だと、相当根気が必要かなとは感じます。

maho:推進する人が持っていたほうがいいもので言うと、逆に何があるといいんですかね。私は一つ、バイブスはあるのかなと思っています。

raz:おお、最近のホットトピックね。

maho:人に感情とかコミットメントする気持ちみたいなものを伝えていくうえでは、やっぱりバイブスの力って強いんですよね。その場にいるからこそ共有できるものだと思っているので、もちろんバイブスがすべてを解決するとは思っていないんですけど、大きな影響力があると感じます。推進する人にバイブスを作り出して伝えていく力があると、広がりやすく共感も得られやすいのかなと。そこからコミットメントが生まれやすい感覚を持っています。

raz:mahoさんにはぜひ、バイブスをテーマにしたブログを書いてもらって。

maho:BasのセッションでもLeSSの導入の話があったじゃないですか。あのときに同一拠点でチームメンバーが可能な限り直接会える環境にできたほうがいいって言っていたと思うんですよ。直接会えるほうがバイブスは伝わりやすいので、その場にいるっていうことが強く影響する。仕組みでそれを起こしやすくするのはオフラインなのかもなと思いました。

shihorin:確かに、オンライン上の切り取られた情報だけだとバイブスが伝わりづらいのかもしれないですね。

maho:不可能ではないとは思うんですけどね。オンライン上でもバイブスってあると思うんですけど、なかなか作り出すのが難しい。少なくとも情報は限られてしまうので、ライブ感はその場にいるほうが強いのかなと思います。

shihorin:今の推進する人の話を聞いて、私とmahoさんが座っていたテーブルにいたLINEヤフーの方たちとの会話を思い出しました。LINEヤフーではLeSSのチームの中にスクラムマスターはいない代わりに、スクラムを推進するチームがあるそうなんです。推進チームでは、開発者やPMの中から有志でスクラムを推進したい人たちを集めて、スクラムマスターの役割を共同でやっている。話をした方たちは、まずスクラムを一緒に盛り上げてくれそうな素直な人をその推進チームに引っ張ってきて、挑戦してもらっていると言っていました。最初から自分で手を上げて推進していきたいと言えると一番いいとは思うけど、いい意味で巻き込まれてみるというのも選択肢としてあるのかもしれないなと感じました。誘ってくれたので乗っかってみるみたいな。それもバイブスなのかもしれないですね。

raz:そうですね。やっぱりオンラインだと他のチームの様子がわからないじゃないですか。巻き込まれたいなとか、あっちに行きたいなっていう気持ちをあまり持てない感じはあります。

maho:そもそもわからなかったら、そういう気持ちにもなれないですよね。

raz:そういうムーブメントを起こすのがオンラインだと難しそう。オンラインだと空間的な距離が遠くて見えないから。自分から見ようとしなければ見えないので、推進をするのが難しいんだろうなと思いますね。

maho:オンラインだと「ちょっと向こうで何かやっているな」「気になるな」とかもないですもんね。

raz:たとえば、チームのSlackチャンネルを全部見て追っているとか、そこまでしている人は一定知っているかもしれない。でも、今のタイミーの規模感だと、全部見るのは逆に情報量が多すぎてノイズになるから、チャンネルを抜けている人もいると思います。僕も抜けちゃってますけど……。結果、全部の情報が遮断されるから「別のチームが何をやっているのかよくわからない」みたいな人が増えるような気がします。

maho:今のrazさんの話を聞いて思ったんですけど、オンラインだとそういうのも“情報”になりがちかなって。LeSSの夜明け初日のグループワークで、五感で学ぶ話があって、五感が使われにくいのはオンラインの弱点かもと思いましたね。他のチームが何をやっているのかは、Slackだと単に文字情報になりがちですけど、同じオフィスで隣合って仕事をしていたら会話が聞こえてきて、楽しそうな様子を感じるとかがありますよね。より五感が使われやすい。その辺は人の心を動かしやすいという意味で、やっぱり違いなのかもしれないなと思います。


続いては、初日のCraig Larman氏によるKeynote「AI & HR: Evolving Organizations in an AI World」から、AIとの向き合い方について考えさせられたことを話し合いました。


raz:僕は最初のKeynoteの「AIエージェントを使って生産性が爆上がりしていった結果エンジニアの形が変わる」という話が印象に残っていて、価値観を変えるタイミングの一つなのかなと思いました。今後は元気にデジタルデバイスを扱える人からすると「AIを使いこなせない」ことを驚かれる時代になっていくんだろうなと。きちんと「価値観のアップデートをしていかないとね」と伝えていく必要があるのではと思います。

あと、XでEbackyさんが「LeSSだから大規模で」という考え方じゃなくて、その時代や状況に合わせてちゃんと変化していくことが大事なんじゃないかなと話されていたのに共感しました。僕らはアジャイルな人間である限り、価値観のアップデートを常にしていかないといけないよなと思いました。AIで生産性が十倍百倍千倍と上がっていくのはすごいけどね。個人的には、そうなった結果として、自分たちの価値観のアップデートが必要になる時代が来ると考えています。ただのツールじゃなくて、考え方や価値観が変わるものなんじゃないかな。使いこなすことが前提みたいな感じですかね。

shihorin:そのセッションの最後で、“ヒューマンスキル”は人間だけが持っているものじゃなく、AIのスキルでもあるという話がされていました。たとえば心理カウンセリングは、人間にカウンセリングされるよりも、AIにカウンセリングされるほうを好んでいる人が多いというデータがあるそうで。ヒューマンスキルではなくなっているというのが衝撃的だったかも。

raz:バイブスはね、ヒューマンスキルですよ。きっと。

maho:AIでもできるようになるかもしれないけど、バイブスはそうであってほしいですよね。価値観のアップデートの話はとても納得したんですけど、その時代に適応して価値観をアップデートしていくうえでは、やっぱり見たいものしか見ないという姿勢はダメなんだろうなという気持ちになりましたね。別に自分に都合のいいものだけ見えているわけではないと思うけど、見たいものしか見ずに固執してしまうと、自分の頭の中で見えていると思っている世界と、現実の世界にギャップが生まれることになる。適応しているつもりでも適応できていないみたいなことが起きていくのかもなと。オープンマインドでいきたいですね。

raz:AIによって人間の仕事がなくなるとかは、どうなるかわからないですからね。なくなると言われている仕事もなんだかんだ残り続けているじゃないですか。逃げ切りマインドで「自分はこのメンタルで最後まで生き抜いて死ぬんだ」というのも考え方の一つとしてはありだと思いますね。たとえば、一生ガラケーを使っている人が悪いわけではない。変えないのが悪いわけではないですけど、選択肢が狭まる可能性はあると思いますね。

maho:確かに。選択肢が狭まっていないかどうかは気にしたい。

raz:「ガラケーでも孫とLINEできないけどいいか」となるのも適応の一つだとは思うんですけどね。

shihorin:LINEができないという悩みを解決したいから「スマートフォンに変えよう」となるのは、内発的動機づけで変えようとしているんですよね。携帯会社から「ガラケーのサービスが終わるので変えてください」と言われても内発的動機づけじゃない。

raz:サービスが終わるなんて知らんってなるんですよね。

maho:使い続けられるなら変えないという選択肢もありますもんね。

raz:そもそも新しい携帯を使いこなす気がないならね。買ってみた結果いいじゃんってなる可能性も、もちろんありますけどね。

脱線しましたが、LeSSだから大規模じゃなきゃいけないみたいなのも違くて、固まった考え方から脱することが大事かなとは思いましたね。

maho:確かに、枠を広げるっていう意味ですよね。

参加して気づいたことや学んだことはなんですか?

maho:全体を通じて思ったことはコツコツやることの大切さです。意外と他の参加者が悩んでいることも、そのコツコツができていないからの悩みなのかなと。一撃でどうにかしようとして、うまくできなくて悩んでいそう。セッションとかを聞いても、成功している人の例は地道にやるべきことを積み上げているパターンな気がするんですよね。それが結局一番の近道なんだろうなと思いました。

shihorin:それだけ長く育んでいたのに壊されちゃったという話もありました。プロフェッショナルな人でもそれぐらいの年数がかかるのだと印象に残りましたね。自分は半年スクラムマスターをしてるけど「うまくいかん」と言っているのは、おこがましいのかもしれません。

maho:時間的な遅れがあるフィードバックもありますからね。やってすぐフィードバックを得られるものでもないけれど、人ってすぐに結果を求めがちじゃないですか。

shihorin:そう、ほしくなっちゃう。

raz:でも、そこに根気強く付き合ってくれる会社というのもなかなか難しいんじゃないかな。

maho:結果を出す、実績みたいなのは大事そう。

raz:プロダクトがちゃんと作られていれば、一定大丈夫だとは思うんですけどね。物ができていれば続けられるとは思う。

shihorin:私はスクラムのカンファレンスに初めて参加して、その場だけの学びじゃなく、今こうして話しているように、後で会話をしたときに気づく学びもあるので、学びは点じゃなくて線なんだなって気づきました。

raz:大事ですよね。アフタートークじゃないですけど、セッションについて話して理解を深めること。まず、話すだけでもアウトプットになって理解を深めることになりますし、他の人からフィードバックをもらえる。自分はこう考えたなどの話をシェアしてもらえれば、より学びが強化されますからね。そういうのがオフラインカンファレンスのいいところ。オンラインでも、ちゃんと設計すればできるんでしょうけど。オフラインカンファレンスに参加してよかったですか?

shihorin:そうですね、私は参加してよかったなという気持ちになりました。

読者に伝えたいこと

shihorin:参加してみたらええやん。受け身で教えてもらうんじゃなくて、誰かと喋ったり、OSTなどのコンテンツに積極的に参加したりするのが大事!新米スクラムマスターの方にもおすすめです。

maho:参加して何を感じたか、学んだかを話して整理する。具体的なアクションをする。続けていくことが大事だと思います。アクションに対するフィードバックを得て自分のふるまいを改善していくことが、アジャイルやスクラム、LeSSに向き合っていくことかなと。継続した活動をサボることなく、甘えずにやっていきたいです。一人では対話できないし、継続もなかなか難しいので一緒にやっていくことが大切だと思います。「私がバイブスキングだ」という気持ちでバイブスを大事にしていきたいです。

raz:セッション全部を通して、オーガナイザーはこれが正解だよという言い方はしていませんでした。自分たちで対話して考えることが多かった、変わったカンファレンスだったので、人によっては「全然何も教えてくれない」と思うかもしれません。でも、それがかえって現実的というか……。実際に人の成功体験から学べることはあまり多くないし、失敗やうまくいっていないこと、今目の前で起こっていることに向き合っている時間が物事を進めていくうえでは大事です。レスの夜明けは、そこに焦点を当てたいいイベントだと思います。あのカンファレンスを受け入れられない人は、LeSSの導入が難しいかもしれないので、価値観、考え方をアップデートしていかなきゃと気づいてもらえるといいのかも。こういうイベントは、つい受け身になりがちですが、臆せず参加してみて友だちを作ったらいいと思います。


今回3名でアフタートークをして得られた学び・気づきを、今後の仕事で生かしていきたいです!

Kaigi on Rails2024 に参加しました

タイミーの新谷、亀井、甲斐、須貝です。

Kaigi on Rails 2024 が10月25日、26日の2日間で開催されました。タイミーは昨年に引き続きKaigi on Railsのスポンサーをさせていただきました。

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

productpr.timee.co.jp

この制度を使ってオフラインでは6名のエンジニアが参加しました。

ライブ感ある集合写真

参加して聞いたセッションのうち印象に残ったいくつかをピックアップしてご紹介します。

Keynote: Rails Way or the highway

https://kaigionrails.org/2024/talks/palkan/
https://evilmartians.com/events/keynote-rails-way-or-the-highway-kaigi-on-rails-2024

test-prof の作者であり Evil Martians の principal backend engineer である @palkan さんによる Rails way とは何なのか、Rails を拡張する際に考えていることについての発表でした。

Railsのレールを伸ばすときの考え方として、「カスタムアプリケーション開発者の考え方ではなく、フレームワーク作者の考え方を持とう」というメッセージは個人的に強く刺さりました。一方、Railsアプリケーション開発者にとってフレームワーク作者の考えを持つのは簡単なことではないと思います。rails/rails のコードを気軽に読むのはもちろん、main branch にあるコードだけでフレームワーク作者の意図を読み取るのには限界があるため Issue や Pull Request の議論のキャッチアップも必要だと感じます。
個人としてこの能力を持つための努力をしていきたいと思いつつ、組織としてこの能力を持ち続けるためには技術顧問の採用によってこの部分を補完するのも一つの手としてありそうだなと思いながら聞いていました。
@euglena1215

speakerdeck.com

RailsのPull requestsのレビューの時に私が考えていること

https://kaigionrails.org/2024/talks/yahonda/

Rails コミッターをされている @yahonda さんが Rails に Issue / Pull Request を出すときに押さえておいてほしいポイントと @yahonda さんがコメント・レビューするかの判断基準についての発表でした。

1つ前の基調講演で「フレームワーク作者の考えを持とう」という @palkan さんの発表から実際に Rails コミッターはどんなことを考えながらコメント・レビューをしているのかという流れで繋がりを感じながら聞いていました。
ユースケースがあるか、という観点においては自身も Real world use case? と聞かれてうまく答えられなかったことがあるため Pull Request の例が出てきたときはヒヤヒヤしながら聞いていました。「誰のどの問題を解決したいのか」「その問題はこの解決方法で解決するのが適切なのか」という観点は普段のプロダクト開発においても重要な観点であり、OSS活動においてもプロダクト開発においても意識し続けたいと思います。
@euglena1215

speakerdeck.com

Identifying User Identity

https://kaigionrails.org/2024/talks/moro/

@moroさんによる登壇です。昨年は Simplicity on Rails という話を Kaigi on Rails でされています。私の理解では昨年の登壇で地に足のついた Rails way とは?という話をされていたと思っており、そこからの流れで今年、基調講演も含めて Rails way についての言及が多く、大変にっこりしております。
そのうえで、今回の @moro さんのお話は User Identity にスコープを絞ったお話です。最初の方で「大雑多に『ユーザー』と呼びがち」という話をしてカラフルな名前について言及していたので、てっきりモデリングの文脈で言及される「よく『ユーザー』って名前をつけがちだけれど場面によってそれぞれの『ユーザー』の振る舞いが変わるんだからもう少し適切にモデリングしようよ」という話かと思ったのですが違いました。今回は User Identity です。おそらく、 Identity の話をしたかったが、「ユーザー」という表現にも納得感がない。とはいえ、伝えたい内容が Identity だから泣く泣く「ユーザー」という表現にしたかったので冒頭でエクスキューズされたのかな、と勝手に思っております。
架空のユーザー管理機能をつくるぞ、ということで、 Gem などを使わずにどうすれば適切に identify したい単位としてのユーザーをコードで表現すればいいのか?ということについて説明されておりました。ユーザーが「いる」こと = identity という説明をして、 users テーブルにはほぼ id だけあればいい、というお話です。これにはものすごく納得感があります。たしかに、ユーザーの属性としてメールアドレスだとか名前だとかをつけがちですが、システムとしてそれらが必要な場面はほとんどなく、大体の場合 association としての id (存在していること)さえわかれば十分です。そして、昨今の個人情報の扱いという点でも id とメールアドレスなどのユーザー属性のライフサイクルは異なります。そういう点でもこの主張にはとても納得感があり、かつ登壇内容も明快でわかりやすくとても参考になりました。
ユーザーの登録に関しての説明も良かったですね。「登録しようとしているコト」を表す UserRegistration モデルを用意すると Rails っぽくユーザー登録をハンドリングできる、というのは昨年の登壇を聞いているととても納得感のあるものです。個人的に面白いと思ったのは UserRegistration モデルに belongs_to :user, optional: trueUserRegistration モデルと User の association がオプショナルになりうる、ということです。これは、ユーザー登録途中で離脱した状態を表現でき、なかなかのアハ体験でした。
少しだけ懇親会でお話を伺い、こんな質問をしてみました。「ユーザー登録を表現する UserRegistration のようなイベントモデルを見つけるにはやはりチームメンバーにそれなりのスキルが必要でしょうか?」と。「いやーそうなんですよねー」という回答をいただきまして、このあたりのスキルは「一朝一夕では身につかないんだなー」と思い、今後もさらに興味を持って Rails と向き合っていきたいなと思いました。
@yykamei

speakerdeck.com

Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜

https://kaigionrails.org/2024/talks/haruna-tsujita/

私はHotwireを触ったことがなく、個人的価値観としてはそこまで重きを置いていないのですが、だからこそ、このような場で実際に向き合っている方々の知見を得られるのは有用な機会であると思い、本発表を聞かせていただきました。

登壇者の@haruna-tsujitaさんが所属される株式会社キャタルは英語4技能塾を運営されており、前々職でガッツリ関わった分野なので非常に懐かしく感じています。そして、前々職と同様の少数精鋭だからこそ、バックエンドエンジニア2人が片手間でReactの面倒見るのがしんどいというペインがあり、Reactを捨ててHotwireに至るという意思決定がされたことがわかりました。

この事情は非常に理解できて、私の前職は技術者が数人規模のスタートアップで、Railsエンジニアが片手間でVue JS2を触っていましたが非常に開発量が多くしんどい思いをしていました。また、モダンなJSはプロジェクトの基幹部分の整備が非常に重たく、私は仕組みが出来上がったVueやReactのコンポーネントつくるくらいなら書けますが、まっさらな状態からモダンJSの実行基盤をつくる、という能力を持っていないことが結構なコンプレックスになっています。そして、これは私の個人的感情だけでなくそこを触れる人材を確保し続ける、というのがスタートアップにとっては重荷であるということを経験しています。会場の挙手の反応などを見てもHotwireを利用している企業は一定数存在するらしい、という空気があり、「Railsエンジニアが片手間でフロントを見る」という選択肢においては利用できるのかもしれないという学びを得ました。幸いにして弊社においては専業でReactを書いてくれるフロントエンドエンジニアの面々がいるおかげでこのような心配をせずに済んでいるのですが…。

話を戻しますが、HotwireはSPAとはアプリケーションを構成する考え方が違う、というnay3さんの話を孫引きして解説してくれているのがまた面白い話で、SPAのコンポーネント単位の考え方から離れて、違うURLで部品の差分を表現する「Web紙芝居」と呼ばれるちょっと昔に逆行した仕組みを敢えて用いることで設計をコントロールしているのは興味深いです。

ある程度ちゃんとした組織なら私はSPAを推すでしょう。ですが、数人規模の会社でよりにもよって私がテックリードをしなければならないような危機的状況に陥った場合、もしかするとHotwireは助けとなるかもしれない。そういう示唆を得られた登壇でした。

(甲斐 宏味)

speakerdeck.com

Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -

https://kaigionrails.org/2024/talks/igaiga/

igaigaさんによるRailsらしいモデル設計とその分割についての発表でした。ご自身もおっしゃっていたようにpalkanさんのオープニングKeynoteの内容とも重なるところがあり、自分はこの手の話が好物なのでとても楽しく聞かせてもらいました。
モデリングをする際にイベント型モデルを見いだせるとRailsのレールにぴったりハマることが多いというのは自分の実感にもよく当てはまるところで、Railsアプリケーション開発者としてこのあたりのコツを掴んでいるかどうかは大きな差になると思います。イベント型モデルを発見できるとControllerはそのイベント型モデルに対するCRUDになるので基本のアクション(create, show, update, deleteなど)で表現できるようになり(いわゆる「DHH流ルーティング」)、このレールに乗せていく感覚を得られると開発が楽しくなってきます。
このあたりの話はigaigaさんが参考資料に載せられていたtexta.fmというポッドキャストでもよく議論されているので、このセッションが面白いと思った方にはぜひ聞いてほしいです。特にep3の「Low-Code Development」ではイミュータブルデータモデリングにも触れており、論理モデリング段階でupdateとdeleteをしないという思考の制約を入れるとイベントを発見しやすくなる、といったテクニックをt-wadaさんがされていて非常に勉強になります。
@sugaishun

speakerdeck.com

 


 

今回の Kaigi on Rails は Conceptual な発表が多かったように思います。そのおかげで Railsway とは何なのかをより一層理解できました。
Kaigi on Rails を運営してくださったオーガナイザーのみなさん、発表されたスピーカーのみなさん、スポンサーとして Kaigi on Rails を盛り上げてくださった各企業のみなさんありがとうございました!

今年も一昨年もスポンサーのブース抽選に外れブース出展できなかったのですが、来年こそはブース出展できることを楽しみにしています。来年はブースで会いましょう!

 

また、Kaigi on Rails の後夜祭として LT イベントを TOKIUM さんと永和システムマネジメントさんと 11/12(火)で共同開催します。Kaigi on Rails ネタや Kaigi on Rails によらない Ruby/Rails ネタなどいろいろなことをお話しする会になるかと思うので、興味があればぜひご参加ください!

tokium.connpass.com

BigQuery + Looker Studioでt検定した話

こんにちは!タイミーでデータアナリストをしているkantaと申します。

普段はマーケティングの皆様とCM施策やCRM関連の分析を担当したり、他部署向けの講習会を企画したりしております。11月から半年ほど育休を取得予定のため、育休前最後の仕事(?)として当ブログの執筆を担当いたします。

さて、今回は「BigQuery + Looker Studioでt検定した話」と題しまして、その方法をご紹介できればと思います。

なぜ BigQuery + Looker Studioでt検定をしたいのか?

タイミーでは、BIツールとしてLooker Studioを使っていますが、分析の中でいくつか機能の不足を感じる点があります。その一つが、今回のタイトルにもなっているt検定です。t検定はその施策の効果が有意であったか、有意でなかったかを推定するために非常に重要な要素です。PythonやRなどのプログラミング言語だけでなく、Excel、スプレッドシートおよびLookerでも実施できます。

しかしながら、Looker Studioではt検定がサポートされておらず、他のツールで出力した検定結果をインポートする必要があります。(2024年10月現在)

そうなると、一つの検定を実施するために以下の三つを管理しなければなりません。

これらの管理工数を少しでも削減するために、以下のような構成でLooker Studio上にt検定結果を表示したいと思います。

BigQuery + Looker Studio でt検定する手順

それでは、その手順についてご紹介します。

UDFの実装につきましては、以下のブログを参考にさせていただきました。

BigQueryで始めるt検定 - Re:ゼロから始めるML生活

1. UDFの作成

BigQueryにはユーザー定義関数(UDF)という機能があり、SQLまたはJavaScriptで関数を作成できます。この機能を利用して、JavaScriptでt検定のUDFを作成します。

1-1. JavaScriptライブラリ「jStat」のダウンロード

GitHubリポジトリからjstat.jsをダウンロードします。

https://github.com/jstat/jstat/blob/1.9.6/dist/jstat.js

1-2. 任意のGCSバケットにjstat.jsをアップロード

GCSバケットにアップロードし、バケット名とファイルパスを控えてください。

ここでは、YOUR_BUCKET 配下にlibraries/jstat.js として作成したものを記載します。

1-3. p値を算出するUDFの作成

以下のクエリをBigQueryで実行します。

YOUR_PROJECTYOUR_DATASETは事前に作成しておいてください。

CREATE OR REPLACE FUNCTION `YOUR_PROJECT.YOUR_DATASET.studentt_cdf`(t FLOAT64, dof FLOAT64)
RETURNS FLOAT64 LANGUAGE js
  OPTIONS (
    library="gs://YOUR_BUCKET/libraries/jstat.js"
  )
AS """
// スチューデントのT分布を用いて、与えられたt統計量と自由度に対する双方向のp値を計算
return jStat.studentt.cdf(-Math.abs(t), dof) *2
"""
1-4. t検定を実施するUDFの作成

1-3で作成したUDFを利用し、t検定を実施するUDFも作成します。

同様に以下のクエリを実行してください。

CREATE OR REPLACE FUNCTION `YOUR_PROJECT.YOUR_DATASET.ttest_ind`(data ARRAY<FLOAT64>, data2 ARRAY<FLOAT64>)  
AS ((
    WITH dataset1 AS (
        SELECT
            d AS A
        FROM UNNEST(data) as d
    )
    ,dataset2 AS (
        SELECT
            d AS B
        FROM UNNEST(data2) as d
    )
    , mean AS (
        SELECT 
            AVG(A) AS ma, 
            AVG(B) AS mb
        FROM dataset1, dataset2
    )
    , lena AS (
        SELECT 
            COUNT(A) AS len_a
        FROM dataset1
    )
    , lenb AS (
        SELECT 
            COUNT(B) AS len_b
        FROM dataset2
    )
    , Ama AS (
        SELECT 
            A,
            ma,
            A - ma AS A_ma,
        FROM dataset1, mean
    )
    , bmb AS (
        SELECT 
            B,
            mb,
            B - mb AS B_mb,
        FROM dataset2, mean
    )
    , pow_Ama AS (
        SELECT
            SUM(A_ma * A_ma) AS A_ma_2
        FROM Ama
    )
    , pow_Bmb AS (
        SELECT
            SUM(B_mb * B_mb) AS B_mb_2
        FROM bmb
    )
    , S2 AS (
        SELECT 
            (A_ma_2 + B_mb_2) / (len_a + len_b - 2) AS s_2
        FROM pow_Ama, pow_Bmb, lena, lenb
    )
    , t AS (
        SELECT 
            len_a,
            len_b,
            (ma - mb) / SQRT((s_2/len_a) + (s_2/len_b)) AS t_value
        FROM mean, S2, lena, lenb
    )
    SELECT 
        `YOUR_PROJECT.YOUR_DATASET.studentt_cdf`(t_value, len_a + len_b-2) AS p_value
    FROM t
))

2. クエリの作成

以下のクエリを実行し、p値を得ることができます。

実際に使用するときは各グループの数値をARRAY_AGG で配列にして扱うことが多いです。

WITH test_data AS ( 
    SELECT 
        [0.0,5.0,29.0,3.0,4.0,32.5,46.3] AS A,
        [9.0,4.0,5.0,6.0,4.0,2.0,3.0,1.0,2.0,4.0] AS B
) 
SELECT `YOUR_PROJECT.YOUR_DATASET.ttest_ind`(A, B) AS p_value FROM test_data

3. Looker Studioで可視化

3-1. Looker StudioのデータソースでBigQueryを選択

3-2. 先ほど作成したカスタムクエリを記述

定義したUDFはLooker Studioからも実行できます。

3-3. 見た目を整えて完成!

詳細は公式ドキュメントをご確認ください。

手順は以上となります。

BigQuery + Looker Studioでt検定した感想

ここまでお付き合いいただきありがとうございました。今回の最大のメリットは、すでに述べたように、管理すべきツールを減らせる点にあります。

その一方で、実際のデータだとクエリが冗長になり、レビューやメンテナンスがしづらくなってしまう場合もあります。

また、そもそも検定とBIツールによる可視化は分けて行うべきという考え方もあると思い、実装してみたものの用途は限られるという印象です。

あくまで選択肢の一つとして、分析の要件や環境に合わせた選択が必要ですね。

We’re Hiring!

私たちは、ともに働くメンバーを募集しています!!

カジュアル面談も行っていますので、少しでも興味がありましたら、気軽にご連絡ください。

タイミーデータサイエンスグループの働く環境について

自己紹介

こんにちは。タイミーのデータエンジニアリング部 データサイエンスグループ所属の吉川です。

1年前にタイミーに入社し、データサイエンティストとして日々業務に取り組んでいます。

前職では大手ゲーム会社で全社のCRMや離脱予測のモデル構築を担当していましたが、縁あってタイミーに入社することになりました。

まず入社後のミッションは「データを活用したプロジェクトの立ち上げ」でした。 立ち上げにあたり、何に取り組むか、社内の問題を探索し、下記のようなビジネス面とデータ活用面の2軸で取り組む領域やテーマの選定を行いました。

  • ビジネス面:ポテンシャルがあり、ビジネスインパクトが大きいか
  • データ活用面:データ量が多く予測モデルの活用などデータ駆動型のアプローチが取りやすいか

具体的な取り組みとして、顧客のスコアリングモデルを構築し、そのスコアを基に顧客フォローを実施するなど、仕組みの構築を行っています。

この記事の目的

ちょうど1年前にタイミーに入社したのですが、応募や内定承諾の意思決定をする時にこんな情報があったら欲しかったと思ったことを2つ、この記事で書きたいと思います。同じようにタイミーのデータサイエンティスト職への応募や内定承諾を迷われている方がいらっしゃれば、その方の一助になれば幸いです。

1. フルリモートで働けるのか?

入社時はフルリモートでしたが、あくまで一時的な状態で、そのうち出社にならないかという不安がありました。

私の転職理由は、前職は素晴らしい職場だったのですが、フル出社体制で片道1時間30分の通勤を強いられていたことが転職理由の一つでした。朝、子どもがまだ寝ている時間に出社しなければならず、子どもとの時間を確保するために転職を決意しました。そのため、新しい職場でもフル出社になれば、同じ問題の繰り返しになってしまうという懸念がありました。

実際に入社して1年経った今でも、入社直後と変わらずフルリモートで勤務できています。データサイエンスグループでは地方にお住まいの方もいらっしゃるので、フル出社になるということは、よほどの大きな経営方針がない限り今のところはなさそうです。

また、タイミーのビジョン、ミッションと照らし合わせても、この柔軟な働き方は今後も続いていくと考えています。

2. 転職をして、人間関係の資産がゼロの中、リモートで業務を進めるのは大変なのでは?

対面での関係性がある状態でのリモートワーク経験しかなかったため、上記のような不安を持ちました。

入社して1年経ちますが、データサイエンスグループをはじめ協働している他部門の心理的安全性が高く、入社前に抱いていた不安は杞憂に終わりました。

プロジェクトの実例

特に他部門との関係性がない中で多くの関係者と合意形成を図りながら業務を進めるのは、リモートだと大変なのではと考えていました。しかし、タイミーの組織はフラットで階層が少なく、コミュニケーションコストが低いため、リモートであってもプロジェクトマネジメントに大きな困難はありませんでした。

例えば、現在他部門と進めているスコアリングのプロジェクトでは、調整に必要な関係者も多くなく、MTGの場で意思決定できるため、ストレスなくプロジェクトを進行できます。

前々職で同じようなプロジェクトを経験しましたが、階層型組織にありがちな「MTGで方針決定後、さらに上位レイヤーに確認する」ということを何度も繰り返しており、意思決定から実行までにかなりの時間がかかっていました。その時との体感差でいえば、同じことが1/3くらいの期間でできたのではないかと思います。

リモート前提の組織設計

また、タイミーはリモート前提で組織が円滑に回るように仕組み化されています。従来の対面を基本とした働き方前提でリモート環境を組み込むと、情報共有の不足やコミュニケーションの断絶など、さまざまな無理が生じがちです。しかし、タイミーは最初からリモート前提での業務遂行ができるようにさまざまな制度設計がされているので、そのような問題を最小限に抑えられているように感じています。

具体的には、MTGはオンライン・オフラインどちらでも参加が可能だったり、ドキュメントを残して情報共有したりする文化が徹底されています。これにより、物理的な距離に関係なく、チーム全体で一貫性のある業務遂行が可能となっています。

データ基盤の整備

さらに、データ部門に限っていえば、タイミーではデータ基盤が整備されているため、BigQueryを叩けば必要なデータを即時に取得でき、これにより、データ利活用におけるコミュニケーションコストが抑えられていると感じています。

自律的な働き方と組織の成長

こうした環境下なので、自発的に課題を見つけ、自律的に動ける人にとってはとてもやりがいのある職場だと思います。階層が少ないことで意思決定が迅速に行われ、社員一人ひとりの意見やアイデアが直接反映されやすい。だからこそ、データサイエンティストは自身の専門知識と創造力を最大限に活かし、新しい取り組みを通じて組織全体の成長に寄与することができます。

加えて、タイミーでは最新のテクノロジーの活用にも積極的で、生成AIなどの取り組みも始まっています。社内GPTなども利用可能で、そうしたものを活用しつつ、業務効率化を進めています。実際、この記事の作成においても、誤字脱字のチェックに社内の生成AIツールを活用しました。

タイミーはデータサイエンティストにとって技術的な挑戦が可能で、組織的な柔軟性もある非常に魅力的な環境だと思います。

以上、1年前の入社時に、当時知りたかった2つのことを記事にまとめてみました。

今、タイミーへの応募や入社を検討中の方にとって、少しでも参考になれば幸いです。

We’re Hiring!


タイミーのデータエンジニアリング部・データアナリティクス部では、ともに働くメンバーを募集しています!!

現在募集中のポジションはこちらです!

「話を聞きたい」と思われた方は、是非一度カジュアル面談でお話ししましょう!