この記事は Timee Product Advent Calendar 2024 シリーズ2の21日目の記事です。 はじめに タイミーでフロントエンドエンジニアをしている大川です。 PlaywrightでのUI自動テストを運用してきた中で学んだ、PlaywrightとMock Service Worker（以降、MSW）を組み合わせたAPIのモック方法を紹介します。 Playwrightのテスト中にモックレスポンスを定義する バックエンドと連携しているシステム全体をテストすることで正常に動作しているか確認していくことは大切ですが、普段のUI開発やUIで利用しているライブラリアップデート後の動作確認時などはAPIリクエストをモックしてPlaywrightのテストを実行するのも有効な場合があると思います。 APIリクエストをモックするためのライブラリにMSWを利用している場合は、開発中に定義したモックハンドラーを再利用してテスト実装を効率化できます。 PlaywrightとMSWを組み合わせる場合には、テストシナリオ内でレスポンスを定義するための工夫が必要です。以下にいくつかの方法をまとめました。 テスト対象のUIでMSWが動作している場合 MSWをwindowオブジェクト経由で操作可能にする 参考: Overriding MSW handlers in Playwright （GitHubディスカッションへのリンク） テスト対象のUIがバックエンドと結合している場合 playwright-msw を利用する 参考: valendres/playwright-msw （Next.js App Routerの場合）experimentalとして実装されているtest modeを利用する 参考: Experimental test mode for Playwright MSWのgetResponseを利用する（後述） 自前のフィクスチャを定義する playwright-mswでは、最後に追加されたハンドラーが最初に実行されるよう、すべてのハンドラー定義順序をリバースしている箇所があります。 参考: ハンドラーをリバースしているコード MSWにも実行順序のルールがあり、それを考慮してハンドラーを用意していると意図しないレスポンスになる場合がありました。 参考: Request handler | Execution order playwright-mswを利用せず、MSWのハンドラーをベースにモック定義するために getRespose 関数が利用できます。 参考: getResponse 以下のコードは getResponse を利用してAPIリクエストをモックしているフィクスチャと、フィクスチャの利用例としてのテストになります。 （フィクスチャの実装例） import { test as base, expect } from '@playwright/test'; import { http, HttpResponse, RequestHandler, getResponse } from 'msw'; const apiEndpoint = process.env.API_ENDPOINT; // NOTE: MSWのモックハンドラー定義の例（実際は別ファイルで管理されている想定） const initialHandlers = [ http.get(`${apiEndpoint}/user/:userId`, () => { return HttpResponse.json({ name: 'John' }); }), ]; // NOTE: テストコード中でもモック定義するためのビルダーを定義 class MockBuilder { private handlers: RequestHandler[] = initialHandlers; constructor(...overrides: RequestHandler[]) { this.handlers = [...overrides, ...initialHandlers]; } use(...additionalHandlers: RequestHandler[]) { this.handlers = [...additionalHandlers, ...this.handlers]; } reset() { this.handlers = initialHandlers; } getHandlers() { return this.handlers; } } const test = base.extend<{ mockBuilder: MockBuilder }>({ mockBuilder: [ async ({ page }, use) => { const builder = new MockBuilder(); await page.route(`${apiEndpoint}/**`, async (route) => { const actualRequest = route.request(); // NOTE: MSWとPlaywrightでRequest型が違うので再定義している const request = new Request(actualRequest.url(), { method: actualRequest.method(), headers: actualRequest.headers(), body: actualRequest.postData(), }); const response = await getResponse(builder.getHandlers(), request); if (!response) { await route.fulfill({ status: 404, }); return; } const json = await response.json(); await route.fulfill({ json, status: response.status }); }); await use(builder); // NOTE: テストコード中に上書きしたハンドラーをリセットする builder.reset(); }, // NOTE: auto: trueでmockBuilderをテストコード中に呼び出さない場合もセットアップしておく { auto: true }, ] }); export { expect, test }; （テストの実装例） test('ユーザーIDを編集できる', async ({ page, mockBuilder }) => { // NOTE: 定義済みのユーザー情報取得に加えてユーザーID編集APIをモックする mockBuilder.use( http.patch(`${apiEndpoint}/user/:userId`, () => { return HttpResponse.json({ result: 'OK' }); }), ); // NOTE: テスト開始 const newUserId = 'new_user_id'; await expect(page).toHaveURL('/user/123/edit'); const input = page.getByRole('textbox', { name: 'ユーザーID' }); await input.fill(newUserId); const button = page.getByRole('button', { name: '保存' }); await button.click(); await expect(page).toHaveURL('/user/123'); const userId = page.getByText(newUserId); await expect(userId).toBeVisible(); }); さいごに 今回はPlaywrightとMSWを組み合わせてAPIレスポンスをモックする方法を紹介しました。 PlaywrightもMSWもAPIが充実しており、いろんなテストシナリオに対応できて便利です。 弊社ではPlaywrightでのテスト以外にも静的解析、コンポーネントやフックの単体テスト、ビジュアルリグレッションテストなどを取り入れています。 自動テストを整備することで機能開発とその動作確認、ライブラリアップデートなどの運用をバランスよく実施していける仕組みをつくっていき、お客さまによりよいUI・UXをより早く提供していくことにつなげていければと考えています。

こんにちは。エンジニアリング本部 プラットフォームエンジニアリングチームの徳富です。 この記事は、 Timee Product Advent Calendar 2024 の 20 日目として、EXPLAINを使用した実行計画の見方についてご紹介します。 背景 タイミーでは、会社の成長に伴い、パフォーマンスチューニングが喫緊に求められています。このような課題に対処するため、クエリのパフォーマンスチューニングには EXPLAIN を使用した実行計画の確認が非常に重要です。しかし、実行計画の解釈には社内でばらつきがありました。この問題を解消するために、実行計画の見方を社内でまとめ、共有することにしました。ただし、この情報を社内だけに留めておくのはもったいないと考え、テックブログを通じて広く公開することに決めました。 実行計画の基本的な見方 MySQLの EXPLAIN 文は、SQLクエリがどのように実行されるかの詳細を提供します。実行計画には、以下のような重要な情報が含まれています： 項目 説明 id SELECT識別子で、クエリが複数の部分から構成されている場合（例えば、サブクエリやUNIONが使われている場合）に重要です。同一のidを持つ行は同じSELECT文に属しています。 select_type クエリのタイプを示します。例えば、 SIMPLE （単一のSELECT）、 SUBQUERY （サブクエリ内のSELECT）、 UNION （UNIONの一部）などがあります。 table クエリが参照するテーブル名。複数のテーブルが結合されるクエリでは、どのテーブルがどの順番で処理されるかを示します。 partitions クエリが参照するパーティション。指定されたパーティションを明確にすることで、クエリの実行効率が向上します。 type データへのアクセス方法のタイプ。 ALL （フルスキャン）、 index （インデックススキャン）、 range （範囲スキャン）などがあります。 possible_keys このクエリで使用可能なインデックスのリスト。適切なインデックスが選択されるかどうかの手がかりになります。 key 実際に使用されるインデックス。このインデックスがクエリのパフォーマンスに大きく影響します。 key_len 使用されるキーの長さをバイト数で示します。キーの長さは、インデックスを使用する効率に影響します。 ref インデックスに使用される列や定数。外部キーの結合や、定数との比較で使用されます。 rows 読み込まれる行数の推定値。クエリのコスト評価やパフォーマンスチューニングの際に重要です。 filtered フィルタ条件によって行がどれだけ絞り込まれるかのパーセンテージ。100%に近いほど、フィルタ条件によるデータの絞り込みが効果的です。 Extra クエリの実行に関する追加情報。例えば「Using index」はインデックスのみでデータが解決されていることを、また「Using temporary」は一時テーブルを使用していることを示します。 これらの情報を基に、実行計画を読み解き、クエリのパフォーマンスを最適化する方法を理解します。 各項目の重要な部分の説明( type, filtered, Extra ) type type はクエリがどのように実行されるかを示すもので、パフォーマンスの観点から重要です。以下は、最も効率的な順に並べた type の種類とその説明です。 項目 内容 const 単一の比較によるレコードの検索で、結果が1行だけに限定される場合に使用されます。通常、主キーやユニークキーの等価比較で見られ、非常に高速です。 eq_ref 主キーまたはユニークキーに基づくジョインで一つのレコードだけを指し示す場合に使用されます。各ジョイン段階で1行のみが処理されるため、効率的です。 ref インデックスを使用して複数の行がマッチする可能性がある検索です。非ユニークインデックスが使われることが多く、キーに基づく絞り込みが行われますが、constやeq_refほどには効率的ではありません。 range インデックスを利用した範囲検索です。特定の範囲内の値を持つ行を効率的に検索しますが、スキャンする範囲によっては処理が重くなる可能性があります。 index インデックス全体をスキャンしますが、テーブル自体は読み込まれません。これは特定のケースでは効率的ですが、全エントリの検査が必要な場合はコストが高くなります。 ALL すべての行をスキャンする必要があるテーブルスキャンです。インデックスがない場合や適切なインデックスが利用されない場合に使用され、パフォーマンスが最も悪いタイプです。避けるべきです。 filtered filtered の値が100に近いほど、行をフェッチした後に絞り込んだ量が少なかったことを意味します。一方で、この値が 100 ではない場合、インデックスが適切に設定されていない可能性があり、不要な行が多くフェッチされている可能性があります。この場合、クエリやインデックス設計の見直しが必要です。 補足情報 : インデックスが存在しないカラムの場合、MySQLのオプティマイザは統計情報を持たないため、 filtered の値は以下のように固定されることが一般的です： 等価検索（ = value ）の場合、 filtered は 10% と固定されます。 もしカラムがenum型の場合、 filtered の値は取りうる値の逆数（1/enumの値の総数）に基づいて計算され、それを100倍してパーセンテージで表示します。 より大きい（ > value ）の場合、 filtered は 33.33% と固定されます。 範囲検索（ BETWEEN start AND end ）の場合、 filtered は 11.11% と固定されます。 これらの固定値は、統計情報がない場合のオプティマイザの仮定に基づいています。したがって、適切なインデックス設計を行い、オプティマイザが正確な統計情報を基に、インデックススキャンなど適切なクエリの実行方法を選択できるようにすることが、パフォーマンスの改善につながります。 Extra 説明 : クエリの実行に関する追加情報を提供します。ここに表示される内容は、パフォーマンスのボトルネックを特定するのに役立つことがあります。 パフォーマンスが良い順に並べた内容(若干条件により前後する) : Using index : インデックスだけを使用してデータを取得し、テーブルへのアクセスを避けます。(カバリングインデックス)これはクエリが効率的であることを示す良い兆候です。 Using index condition : インデックスコンディションプッシュダウン（ICP）が使用されていることを示します。これはインデックス内でWHERE条件の一部を評価することにより、不要な行の読み込みを減少させ、クエリの全体的な実行時間を短縮します。 Using where : データを取得した後に追加の絞り込みを行っている状態を示します。この状況は、インデックスがWHERE条件をすべてカバーしていない場合や、適切なインデックス自体が存在しないに発生します。 Using filesort : MySQLが結果をソートするために一時ファイルを使用します。これはクエリのパフォーマンスに影響を及ぼす可能性がありますが、正しい結果を得るために必要な場合があります。 Using temporary : クエリ処理のために一時テーブルが使用されます。これはGROUP BYやORDER BYの処理で見られ、大量のデータを扱う際にパフォーマンスに影響を与える可能性があります。 Full scan on NULL key : ジョインやサブクエリでNULL値を持つキーをフルスキャンしています。このプロセスは非常にコストが高く、パフォーマンスに大きく影響を及ぼします。 チューニングの具体的な例 具体的なSQLのチューニング方法をご紹介します。使用する環境はこちらのGitHubリポジトリで公開されています： https://github.com/hirosi1900day/tech-blog-for-mysql レベル１: whereとgroup byを使ったクエリのチューニング 次のSQLクエリは、特定の日付における商品名ごとの総数量を求めるものです。 SELECT product_name, SUM (quantity) as total_quantity FROM orders WHERE order_date = ' 2021-01-02 ' GROUP BY product_name まず、このクエリの実行計画を確認してみましょう。 EXPLAIN SELECT product_name, SUM (quantity) as total_quantity FROM orders WHERE order_date = ' 2021-01-02 ' GROUP BY product_name; 実行計画の結果は以下の通りです： + ----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+------------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | + ----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+------------------------------+ | 1 | SIMPLE | orders | NULL | ALL | NULL | NULL | NULL | NULL | 12 | 10 . 00 | Using where ; Using temporary | + ----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+------------------------------+ 実行計画からわかるように、 ALL （全スキャン）が使用されており、インデックスが利用されていないことが明らかです。これはデータベースがテーブルの全行をスキャンしているため、データ量が多くなるとパフォーマンスが大きく低下する可能性があります。さらに、 Extra 列に Using where; Using temporary と表示されています。これは、 WHERE 句での絞り込み後に一時テーブルを使用して GROUP BY 処理が行われていることを示しており、効率的ではありません。 チューニングの実施 このクエリのパフォーマンスを向上させるためには、 order_date と product_name に複合インデックスを作成することが効果的です。複合インデックスでは、インデックスの列の順序が重要です。このケースでは、 WHERE 句で order_date を使用してデータを絞り込んでから、 GROUP BY で product_name を使うため、 order_date を第一引数に設定するのが適切です。 インデックスを追加します： CREATE INDEX idx_date_product ON orders(order_date, product_name); インデックスを追加した後の実行計画は以下のように改善されるはずです： EXPLAIN SELECT product_name, SUM (quantity) as total_quantity FROM orders WHERE order_date = ' 2021-01-02 ' GROUP BY product_name; 結果： + ----+-------------+--------+------------+------+------------------+------------------+---------+-------+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | + ----+-------------+--------+------------+------+------------------+------------------+---------+-------+------+----------+-------+ | 1 | SIMPLE | orders | NULL | ref | idx_date_product | idx_date_product | 6 | const | 2 | 100 . 00 | NULL | + ----+-------------+--------+------------+------+------------------+------------------+---------+-------+------+----------+-------+ この改善により、 type が ref に変わり、クエリはインデックスを使用してより効率的に実行されます。また、 Extra 情報もクリアされ、一時テーブルを使用することなく処理が行われていることが確認できます。 インデックスの順序の影響 SQLクエリのパフォーマンスを向上させるためには、インデックスの構成とその順序が重要な役割を果たします。ここでは、 product_name を第一引数とし、 order_date を第二引数とする複合インデックスの影響を考察します。 CREATE INDEX idx_product_date ON orders(product_name, order_date); この複合インデックスを用いたクエリの実行計画を見てみましょう： EXPLAIN SELECT product_name, SUM (quantity) as total_quantity FROM orders WHERE order_date = ' 2021-01-02 ' GROUP BY product_name; 実行計画は以下のようになります： + ----+-------------+--------+------------+-------+------------------+------------------+---------+------+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | + ----+-------------+--------+------------+-------+------------------+------------------+---------+------+------+----------+-------------+ | 1 | SIMPLE | orders | NULL | index | idx_product_date | idx_product_date | 1028 | NULL | 1 | 100 . 00 | Using where | + ----+-------------+--------+------------+-------+------------------+------------------+---------+------+------+----------+-------------+ ここで、 type index となっているため idx_product_date インデックスがフルスキャンされ、 Extra 列に Using where が表示されている点に注目します。これは、 order_date での絞り込みがインデックスを最適に活用していないことを示しています。また、 Using temporary が表示されないことから、 GROUP BY product_name 処理で複合インデックスが効果的に機能し、一時テーブルが不要になっていることがわかります。このことから、複合インデックスの第一引数の product_name だけが利用され、第二引数以降の order_date は単独でインデックスとしての機能を果たしていません。 さらに、同じ条件で product_name のみにインデックスを設定した場合の実行計画を見てみましょう： CREATE INDEX idx_product_name ON orders(product_name); EXPLAIN SELECT product_name, SUM (quantity) as total_quantity FROM orders WHERE order_date = ' 2021-01-02 ' GROUP BY product_name; 実行計画は以下の通りです： + ----+-------------+--------+------------+-------+------------------+------------------+---------+------+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | + ----+-------------+--------+------------+-------+------------------+------------------+---------+------+------+----------+-------------+ | 1 | SIMPLE | orders | NULL | index | idx_product_name | idx_product_name | 1022 | NULL | 1 | 100 . 00 | Using where | + ----+-------------+--------+------------+-------+------------------+------------------+---------+------+------+----------+-------------+ この結果から、 product_name のみのインデックスでも同じ実行計画になることがわかります。 つまり、複合インデックスを使用している場合でも、第一引数（ product_name ）が単独で使用されることがある点に注意が必要です。 レベル2: GROUP BYとHAVING、ORDER BY を使ったクエリ 次のSQLクエリは、商品がどれだけ頻繁に複数購入されるかを調べるためのものです。具体的には、商品名ごとに注文総数と平均購入数量を集計します。 SELECT product_name, COUNT (*) AS total_orders, AVG (quantity) AS average_quantity FROM orders GROUP BY product_name HAVING AVG (quantity) > 1 ORDER BY average_quantity DESC ; このクエリの実行計画を EXPLAIN を使って確認すると、以下のような結果が得られました。 + ----+-------------+--------+------------+------+------------------+------+---------+------+------+----------+---------------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | + ----+-------------+--------+------------+------+------------------+------+---------+------+------+----------+---------------------------------+ | 1 | SIMPLE | orders | NULL | ALL | idx_date_product | NULL | NULL | NULL | 1 | 100 . 00 | Using temporary; Using filesort | + ----+-------------+--------+------------+------+------------------+------+---------+------+------+----------+---------------------------------+ 全スキャンが行われており、インデックスが利用されていません。 Using temporary; Using filesort は、 GROUP BY と ORDER BY によって一時テーブルが使用され、結果がファイルソートされていることを示しています。これによりデータが多い場合、クエリのパフォーマンスが低下する可能性があります。 チューニングの実施 このクエリは product_name でグルーピングした後に quantity のカラムを使って HAVING や ORDER BY を行うため、 product_name と quantity に複合インデックスを追加することでデータそのものにアクセスすることなく、インデックスだけでデータの取得が行えそうです（カバリングインデックス）。これにより、データベースが効率的にデータにアクセスできるようになります。 インデックスを追加するSQLは次の通りです： CREATE INDEX idx_product_name_quantity ON orders(product_name, quantity); インデックス追加後、実行計画を再び確認すると、次のように改善されるはずです。 + ----+-------------+--------+------------+-------+--------------------------------------------+---------------------------+---------+------+------+----------+----------------------------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | + ----+-------------+--------+------------+-------+--------------------------------------------+---------------------------+---------+------+------+----------+----------------------------------------------+ | 1 | SIMPLE | orders | NULL | index | idx_date_product,idx_product_name_quantity | idx_product_name_quantity | 1027 | NULL | 1 | 100 . 00 | Using index ; Using temporary; Using filesort | + ----+-------------+--------+------------+-------+--------------------------------------------+---------------------------+---------+------+------+----------+----------------------------------------------+ クエリの最適化は行ったものの、 Using temporary; Using filesort がExtra情報から消えない理由は、 GROUP BY によるグループ化と ORDER BY によるソート処理が原因です。カバリングインデックスが追加されたことにより Using index が表示され、インデックスから直接必要なデータを取得しているため、全行スキャンのコストは削減されましたが、集計とソートには依然として追加のリソースが必要です。 SQLクエリでは、 GROUP BY でグルーピングした結果を ORDER BY でソートする際には、MySQLが内部的にテンポラリーテーブルを作成し、そのテーブルにデータを格納後、ソート処理を行います。このプロセスはメモリやディスクスペースを消費するため、扱うデータ量が増えるとパフォーマンスの低下が発生します。 そのため、データベースでの処理負荷を軽減するために、クエリをさらに絞り込むか、あるいはアプリケーションレベルでデータを取得後に集計やソートを行うアプローチが考慮されるべきです。（その場合アプリケーションサーバーに負荷が発生することになるのでバランスが重要） レベル3: Joinとサブクエリを使ったクエリ 次のSQLクエリは、各ユーザーが注文した商品の中で、そのユーザーが注文した商品の平均数量を超える数量を持つ商品名を取得します。 SELECT users.username, orders.product_name, orders.quantity FROM users JOIN orders ON users.id = orders.user_id WHERE orders.quantity > ( SELECT AVG (orders.quantity) FROM orders WHERE orders.user_id = users.id ); このクエリを EXPLAIN で実行計画を確認した結果、以下のような内容が得られました。 + ----+--------------------+--------+------------+--------+---------------+---------+---------+-----------------------+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | + ----+--------------------+--------+------------+--------+---------------+---------+---------+-----------------------+------+----------+-------------+ | 1 | PRIMARY | orders | NULL | ALL | user_id | NULL | NULL | NULL | 1 | 100 . 00 | NULL | | 1 | PRIMARY | users | NULL | eq_ref | PRIMARY | PRIMARY | 4 | testdb.orders.user_id | 1 | 100 . 00 | Using where | | 2 | DEPENDENT SUBQUERY | orders | NULL | ref | user_id | user_id | 4 | testdb.users.id | 1 | 100 . 00 | NULL | + ----+--------------------+--------+------------+--------+---------------+---------+---------+-----------------------+------+----------+-------------+ orders テーブルに対してフルスキャンが発生していますが、これはデータ量が少ない場合にインデックスを利用するよりも効率的だと判断されているケースです。特に注目すべきは DEPENDENT SUBQUERY という select_type で、これは外部クエリの結果に基づいて行ごとにサブクエリを繰り返し実行することを意味します。 例えば、100人のユーザーがそれぞれ5件の注文を持つ場合、サブクエリは500回実行されるため、効率が低下します。この問題を改善するためには、共通テーブル式（CTE）を使用し、ユーザーごとの平均数量を事前に計算してからメインクエリで利用する方法が有効です。 以下は、CTEを使用したクエリ例です。 WITH UserAverages AS ( SELECT user_id, AVG (quantity) AS avg_quantity FROM orders GROUP BY user_id ) SELECT u.username, o.product_name, o.quantity FROM users u JOIN orders o ON u.id = o.user_id JOIN UserAverages ua ON u.id = ua.user_id WHERE o.quantity > ua.avg_quantity; このクエリの実行計画は以下のようになります。 + ----+-------------+------------+------------+--------+---------------+-------------+---------+-----------------------+------+----------+--------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | + ----+-------------+------------+------------+--------+---------------+-------------+---------+-----------------------+------+----------+--------------------------+ | 1 | PRIMARY | orders | NULL | ALL | user_id | NULL | NULL | NULL | 1 | 100 . 00 | NULL | | 1 | PRIMARY | <derived2> | NULL | ref | <auto_key0> | <auto_key0> | 4 | testdb.orders.user_id | 2 | 50 . 00 | Using where ; Using index | | 1 | PRIMARY | users | NULL | eq_ref | PRIMARY | PRIMARY | 4 | testdb.orders.user_id | 1 | 100 . 00 | NULL | | 2 | DERIVED | orders | NULL | index | user_id | user_id | 4 | NULL | 1 | 100 . 00 | NULL | + ----+-------------+------------+------------+--------+---------------+-------------+---------+-----------------------+------+----------+--------------------------+ CTEを使用することで、サブクエリの繰り返し実行を防ぎ、一度の計算で済ませるようになりました。ただし、CTEは派生テーブルとして扱われ、実行計画では DERIVED と表示されます。これにより、一部のデータがテンポラリーテーブルとして実体化されるため、必ずしも常にサブクエリより高速になるわけではないので注意してください。 DEPENDENT SUBQUERY が実行計画に現れた場合には、データ量が増えるとパフォーマンスが大幅に劣化する可能性があるため、注意が必要です。このような場合には、クエリの設計を見直すことを検討してください。 まとめ MySQLの実行計画を利用することで、クエリのパフォーマンスを把握し、最適化の方向性を明確にできます。今回は、具体的な例を通じて、インデックスを追加する方法とクエリを変更することでの改善方法を紹介しました。しかし、クエリのチューニングは状況に応じて最適な手法が異なるため、これらの方法以外にも様々なアプローチが考えられます。これからも実際の問題に遭遇した際の解決策をブログで積極的に共有していくことで、より多くの技術者がデータベースのパフォーマンス問題に対処できるよう支援していきたいと思います。 参考 この記事の内容に関連するさらなる情報は、以下の書籍で詳しく学べます。 書籍名 : MySQL運用・管理［実践］入門 〜安全かつ高速にデータを扱う内部構造・動作原理を学ぶ 出版社 : 技術評論社 出版日 : 2024年5月22日 この書籍は、MySQLの内部構造や動作原理について深く掘り下げており、実際の運用や管理におけるパフォーマンスチューニングの実践的なアプローチが学べます。

はい、亀井です。 yykamei という名前でインターネット上では活動しています。所属はタイミーです。 今回は Timee Advent Calendar 2024 の 19 日目の記事として、Slack の Huddles を使ったプラクティスとその背後にある考え、というタイトルで、筆を取らせていただきました。 仕事におけるコミュニケーションツールはいろいろありますが、その中でも Slack を使っている組織は多いのかなと思います。その Slack の機能の一つとして Huddles が 2021 年にリリースされました。当時はコロナ禍ということもあり、リモートワークが浸透してきた中でどのようにしてオンラインでのコミュニケーションを充実させるか？をまだまだ模索している中だったと思います。そんな中、 Discord のようにクイックに会話を開始できて、かつ、他のメンバーもリアルタイムで会話に参加できる機能として Huddles がリリースされ、当時の私は少し驚きました。 これまでも Zoom だったり、 Google Meet だったりでビデオチャットは可能でしたし、それこそ Slack Apps などを使えば、簡単にそれらのビデオチャットを呼び出してインスタントに会話が可能でした。しかし、 Slack の Huddles はそれが普段使っているチャットツールに組み込まれていると言うところに大きなアドバンテージがあると思います。そして、誰がどこのチャンネルで会話しているのか？が見える、というのも魅力的なポイントかと思います。 組織のカルチャーにもよりますが、 Slack を使っていてよく Huddles を利用している環境だと、自分が join しているチャンネルのいずれかで Huddles による会話が複数並行して行われることになります。実際のオフィスにおいても会議室は複数あって同じ時間帯に複数の会議室でミーティングが行われることは普通のことですが、それが可視化され、それぞれのミーティングに誰がいるのか？を知ることができるのは意外とメリットが大きいと感じます。どういうメリットかというと「賑やかでいいなー」というメリットです。はい、実利的なメリットというよりも感情面でのメリットです。 Slack を起動すると一目で賑やかさが可視化されるわけですよね。実際に賑やかなのかどうかはわかりませんが、人と人とが会話しているのだからおそらく賑やかなはずです。 Slack Huddles を使ったプラクティスは世の中にすでにたくさんあると思いますが、ここでは私が考えるもの、またなぜそれらを使うのか？を列挙してみようと思います。 Huddles を開いて作業する Communication は大事ですよね。その Communication を extreme にやるためには会話をする機会が必要です。では会話をする機会を増やすにはどうすればよいのか？という問いに対する答えがこのプラクティスです。リモートワークが主流ではなくメンバーの多くがオフィスで働いている場合は「ちょっといいですか？」という会話ができました。とはいえ「ちょっといいですか？」という声がけ自体、ハードルが高いと感じる場合もありますよね。私はありました。そして、リモートワークが中心の働き方になるとそのハードルの高さ自体感じることなく会話する機会は失われました。特にコロナ禍でこの問題が顕著になりましたね。この問題に対して、多くの組織があの手この手でバーチャルオフィスのツールを導入したり「雑談をする」という時間をカレンダー上でセットしたりして工夫をしてきました。そうした工夫のうちの一つが Huddles を開いて作業する、です。 誰かが Huddles を開いて何かをしていると「なんだなんだ？」という感じで興味を持ってくれた人が Huddles に参加してくれます。そうなったら雑談をしてもよいですし、軽く挨拶をかわして作業を続けてもいいでしょう。 このプラクティスは、チームが継続的に会話をすることに慣れていない、あるいは、会話をすることに対して価値を感じていない場合に有効です。 Communication が大事、という価値観をチームに押し付けてもよいのですが、そうするとチームからは信頼されなくなるでしょう。 Communication も大事ですがチームからの信頼も大事です。もしかしたら、誰もその Huddles に来ないこともあるかもしれません。それでもいいのです。ただそこにいるという状態をまず作り出すこと、それ自体に価値があります。そして、何かのきっかけでチームの誰かが話しかけてくれるかもしれません。そうしたときにその会話を楽しみましょう。そのうち「ここに来れば仕事上の相談ができるかもしれない」という雰囲気を作り出せるかもしれません。そこまでいけばチームが Communication の価値に気づいている可能性があります。 注意点としては、このプラクティスを行うと、ずっと Huddles にいる、という状態になってしまいがちということです。 Communication は大事ですが、人間性も大事です。休みましょう。8時間ずっとオンラインというのはどう考えても非人間的です。無理のない範囲で実施するようにしましょう。 また、もう一つ注意点があります。 Huddles から抜けることを促す、あるいはいつでも Huddles から抜けることを奨励しましょう。というのも、一度会話に入ったら途中で抜けることに躊躇する人もいるからです。そうなると、「抜けたいのに抜けられない」というふうになってしまってせっかくの Huddles の場がその人にとっては好ましくないものに変わる可能性があります。 Huddles というのは出たり入ったりが自由なものなのだ、という雰囲気を普段から醸成しておくとよいでしょう。 他のチームの Huddles に飛び込んでみる 他のチームが複数人で楽しそうに会話しているのをみると思わず飛び込んでみたくなりますよね。飛び込みましょう。わざわざ会議用のビデオチャットではなくあえて Slack で Huddles をしているのですから、これは誘われていると言っても過言ではありません。 なぜこれをするのでしょうか？自分のチーム外のことは普段の業務に関係することは少ないでしょう。その時間を使うぐらいなら普段の業務に時間を割り当てて締め切りが迫っている自分の作業に集中したくなります。もちろん、自分のタスクが逼迫しているなら無理をしてはいけません。ただ、もし自分の作業に余裕があるのであれば、他のチームの働き方を覗いてみると意外と発見があるものです。私が最近発見したことは次のようなものです。 あるチームのリファインメントのやり方が勉強になった あるチームのタスクの切り方が勉強になった 「モブプロをやる」と言っても「モブプロ」の定義はチームによって異なるようだ スプリントレビューに対する態度が勉強になった あるチームが適用したコードが自分のチームに開発に影響することがわかった 同じ組織とはいえ隣のチームは仕事の仕方が異なります。もしかしたら文化も異なるかもしれません。同じ言葉なのに異なる意味で会話していることもあります。そうした「異なるもの」に触れることは新たな洞察を得ることにもつながり、学びになります。自分のチームをもっと効果的にアウトカムを生み出すチームにするにあたって「これなら自分のチームに取り入れるとうまくいくのではないか？」という発見があるかもしれません。もちろん、こうした学びは書籍やインターネット上の情報を活用しても得られなくはないでしょう。ただ、そうした学びの実践を目の当たりにできる機会は少ないです。 Huddles でのリアルな会話を目撃することは、そうした体系立った知識がどのように活用されているかを発見する場として活用できるのではないかと思うのです。 加えて、他のチームの Huddles に入ることで単純にいろいろな人と知り合いになれます。やはり知り合いが社内に多いと困った時に頼りやすいですよね。実際、最近 SQL のパフォーマンスについて相談させてもらって非常に助かりました。「ちょっと話したことがあるから頼ったら助けてくれるかもしれない」というぐらいには簡単に知り合いになれるのがこのプラクティスの魅力です。 とはいえ、私も嫌われたくはないので空気を読んで Huddles に入るかどうかは見ます。たとえば、 Huddles を始める前後のやりとりで何かしら深刻そうな会話がテキストで行われていたり、なんとなく 1on1 のような空気感の会話なのであれば入らないようにしています。この読みが当たっているかどうかはわかりません。もしかしたらあまり深く考えずに飛び込んでもよいのかもしれませんが、そのあたりはもともとあった人間関係も影響すると思います。 Huddles にトピックを設定する Slack Huddles でトピックをセットできるのはご存じでしょうか？このトピックをセットすると Huddles に入っている人からも入っていない人からもどのような会話が行われているのか？がわかって便利です。トピックをセットする目的は、雑談ではなく「今これについて話している」というのを宣言し、 Huddles に入っていないがそのトピックに対して興味がある人を誘い込むことにあります。このプラクティスは、特定の誰かをメンションしたいわけではないが特定のトピックについて話したい、そして、そのトピックに関心のある人を呼びたいときに有効です。 プロジェクトやタスクなどすでに実施することが決まっている業務の場合、関係者は決まっているでしょう。しかし、次に何をするか？という探索などでは、柔軟な考えを取り入れたいですし様々な人の意見を聞きたいでしょう。多種多様な職種の人たちを集めてざっくばらんに話すことができればもしかしたら新しいアイディアが生まれるかもしれません。そうしたときにどうやって人を集めるか？というのは意外と難しいです。そこで Huddles のトピックを広告のように掲げることで関心のある人を呼び込むのです。 これは、「Huddles を開いて作業する」というプラクティスと組み合わせて使うこともできるでしょう。たとえば、パフォーマンスチューニングに取り組んでいるとします。その取り組み内容である「パフォーマンスチューニング」をトピックにセットするとどうでしょうか？チューニングが好きそうな人たちを呼べそうな気がしませんか？ このように Huddles のトピックは人を呼び込むことを目的としています。呼び込んだ後に途中から雑談に変わったらトピックは変更すればよいでしょう。 最後に ここまで Slack Huddles のプラクティスをみてきました。どれも基本的なものですが、それを使う背景を考えてみると案外面白いですね。実はこれまでほとんど何も考えずにこうしたプラクティスを行ってきたのですが、こうしてアドベントカレンダーを書く機会をいただいたことでそのプラクティスの背景が言語化されました。この場を借りてアドベントカレンダーの機会をいただいたタイミーのプロダクト組織に感謝いたします。

こちらは Timee Product Advent Calendar2024 の18日目の記事です。前日は @ryopeko による「 RubyWorld Conference 2024に参加してきた 」でした。 こんにちは。タイミーでバックエンドのテックリードをしている @euglena1215 です。 タイミーではモノリスな Ruby on Rails アプリケーションに一定の規律を設けるために Packwerk を導入しています。 A Packwerk Retrospective であったように、Packwerk はあくまでツールであり鋭いナイフです。ツールは使い手が意図を持って扱わないとそれに振り回されて怪我をしてしまいます。 この記事では、それぞれのチェッカーがどんな目的を達成するために使えるものなのかを自分なりに整理してまとめてみます。 　 Packwerk 自体はあくまで依存グラフを作成するだけであり、どんな検査を行うかは決定しません。どんな検査を行うかを決定するのはパッケージごとのチェッカーの設定です。この記事を通して「Packwerk での議論が行われる際にはチェッカーの設定もセットで行われるようになるといいな」という微かな期待もあります。 前提 タイミーでは packwerk , packwerk-extensions で提供されているチェッカーのうち、Dependency Checker と Privacy Checker を利用しています。packwerk-extensions には他に Visibility Checker, Folder-Visibility Checker, Layer Checker が存在しますが、今回は省略させてください。 Dependency Checker Dependency Checkerの概要図 パッケージ間の依存関係を管理・検査するためのチェッカーです。これが唯一 Packwerk 本体が提供しているチェッカーになります。 機能の詳細は https://github.com/Shopify/packwerk/blob/main/USAGE.md#types-of-boundary-checks をご覧ください。 主な使い道 CI 上で実行するテストの枝刈りを行いテストの実行時間を削減する Dependency Checker はパッケージ間の依存関係を管理するため、全てのパッケージの依存関係を厳密に管理すれば、ある変更に対して影響を受けた可能性のあるパッケージを特定できます。影響範囲外のパッケージはテストの実行を省略可能なのでテストの実行時間を削減することが可能です。 これは Shopify のブログにもモチベーションの1つとして記述されています。 Instead of running the test suite on the whole application, we can run it on the smaller subset of components affected by a change, making the test suite faster and more stable. ref. https://shopify.engineering/shopify-monolith この用途で使うためには、全てのパッケージの enforce_dependencies を基本的には strict に設定する必要があります。 # packs/foo/package.yml enforce_dependencies : strict dependencies : - bar # bar パッケージで変更があれば foo パッケージにも影響を与える - baz # baz パッケージで変更があれば foo パッケージにも影響を与える しかし、この使い道で Dependency Checker を利用する際にはいくつかの注意点が存在します。 パッケージの循環依存をなくす必要がある 循環依存があると、全てのパッケージが影響を受ける可能性ありとしてマークされます。 例えば、A → B → C → D → A という依存があると、どのパッケージを変更しても全てのパッケージのテストを実行する必要があるため実行すべきテストを削減することができません。 循環依存があると全てのパッケージに影響が波及する図 そのため、どうやって循環依存を減らすかが重要です。 Shopify では、依存の方向を変え循環依存を減らすために ActiveSupport::Notifications の pub/sub のような機構を導入したと2020年の記事には記述されていました。 Inversion of control means to invert a dependency in such a way that control flow and source code dependency are opposed. This can be done for example through a publish/subscribe mechanism like  ActiveSupport::Notifications . ref. https://shopify.engineering/shopify-monolith が、2024年の記事では「結果としてコードが理解しにくくなったこともしばしばあった」と記述されていました。 We relied heavily on inversion of control, for example, to extract package references out of base layer code. These changes introduced indirection that, while resolving the violations, often made code harder to understand. ref. https://shopify.engineering/a-packwerk-retrospective ActiveSupport::Notifications をアプリケーションロジックで多用している Rails アプリケーションに出会ったことがないのでどのような書き味・読み味になるのかは私には分かりません。 しかし、同じように依存方向を反転させる ActiveRecord の Callback は馴染み深いのではないでしょうか。ActiveRecord の Callback は適切に使えば便利ですが、使いすぎると苦しめられることは Rails エンジニアのみなさんはよくご存知だと思います。同様のことが起きていないといいのですが果たして…。 Sorbet の利用が実質的には必須 テストの実行を省略するためには厳密な依存チェックが行えている必要があります。feature branch では CI が通っていてマージをしたのに、実は失敗するテストケースが存在していたなんて考えなくもないですよね？ Packwerk はパッケージ間のクラス・定数の呼び出しを検出するツールです。そのため、引数として他パッケージで管理しているクラスのインスタンスが渡された場合、コード上にはクラスが登場しないので検知することができません。 # packs/foo/app/models/foo.rb class Foo # 引数 bar は bar パッケージで管理している Bar クラスのインスタンス def foo (bar) # bar.bar_method を呼びだすことで bar パッケージへの依存が発生しているが # packwerk は `Bar` が登場しない限り依存を検知できない！ bar.bar_method end end Sorbet のような引数のクラスを評価するような実装があることで初めて検知することができます。 # packs/foo/app/models/foo.rb class Foo # sorbet ではランタイムで `Bar` を評価するので packwerk が依存を検知できる！ sig { params( bar : Bar ).void } def foo (bar) bar.bar_method end end これは Shopify の Rails アプリケーションでの Sorbet による型アノテーションのカバレッジが十分に高いことが前提になっているからだと思われます。 こちらに関しては実質的に Sorbet に依存せずとも厳密なチェックができるようにカスタマイズするための機能提案が行われていますが、1年以上前から動きがありません。 github.com Shopify からすると今のままで困ってないわけですし、新たな機能を追加することで保守が大変になるので困るのは理解できます。fork して自分で保守を行う覚悟がないのであれば、この用途で使うためには Sorbet の利用が実質的に必須である状態は避けられなさそうです。 基盤パッケージが他パッケージに依存していないことを維持したい 全てのパッケージに関してパッケージ間の依存管理するのは諦めて、最低限基盤パッケージのような他パッケージに依存しないパッケージのみ検査を行うという使い道もあると思います。 この使い道で Dependency Checker を利用するなら以下のような設定になります。 # packs/no_dependency_package/package.yml # 他パッケージに依存しない基盤的なパッケージ enforce_dependencies : true | strict dependencies : [] # packs/normal/package.yml # 他パッケージに依存して動作する一般的なパッケージ enforce_dependencies : false dependencies : [] タイミーでは、 ApplicationRecord や ApplicationController など Rails が提供している基盤クラスを rails_shims パッケージとしてまとめています。このパッケージが具体の機能に紐づく module を include しているのは好ましくありません。 この使い方をすることで、明らかに依存してはいけない依存を検知することができます。 どの使い道が良いと考えているのか 完全に個人的な意見にはなりますが、Shopify の状況を見るに依存グラフを作成することによるテストの実行時間の削減は現実的ではないと考えています。 そのため、基盤パッケージの意図しない他パッケージへの依存の検出など本当にパッケージ間の依存を管理したい一部のパッケージのみ Dependency Checker を有効にし、一般的なその他パッケージは無効にしておくのが良いのではないかと考えています。 Privacy Checker Privacy Checker の概要図 packwerk の文脈での private なクラス・定数への参照を管理・検査するためのチェッカーです。元々 packwerk 本体が提供するチェッカーでしたが、packwerk-extensions に切り出されました。 機能の詳細は https://github.com/rubyatscale/packwerk-extensions?tab=readme-ov-file#privacy-checker をご覧ください。 主な使い道 パッケージの利用方法を絞りたいとき パッケージで扱っているロジックが複雑で「ここを変更した際は一緒にここも変更しないと不整合が発生する」といった暗黙的な依存が発生しているときは、安全な利用方法を Public API として提供しておくのが安心です。 この使い道で Privacy Checker を利用するなら以下のような設定になります。 # Public API を提供して利用方法を絞りたいパッケージ enforce_privacy : true | strict # パッケージ外からどのクラスを参照しても構わないパッケージ enforce_privacy : false 一方、packwerk の開発元である Shopify では Privacy Checker をうまく活用できなかったために packwerk 本体からは削除され、packwerk-extensions に切り出されたのも事実です。何が起きていたのかを分かる範囲でまとめておきたいと思います。 Under Deconstruction: The State of Shopify’s Monolith では「Privacy Checker を守ることだけを目的としたほとんど意味を持たない Public ラッパークラスが量産されていたことに気付いた」との記述がありました。 When we ignored the dependency graph, in large parts of the codebase the public interface turned out to just be an added layer of indirection in the existing control flows. This made it harder to refactor these control flows because it added additional pieces that needed to be changed. It also didn’t make it a lot easier to reason about parts of the system in isolation. ref. https://shopify.engineering/shopify-monolith また、Packwerk から Privacy Checker を削除し、packwerk-extensions に切り出すことが決まった GitHub discussion での議論 では「Privacy Check に違反したコードはただ public ディレクトリに移動されるだけ、もしくは package_todo.yml に記録されて忘れ去られるだけ。これらを対処するためにより悪いコードが生み出される」との記述がありました。ここでの「悪いコード」とは上記のほとんど意味を持たない Public ラッパークラスだと予想しています。 So far at Shopify, we didn't see much value in the privacy checks. Most of our packages have this option disabled and when we do have them enabled, people mostly fix this kind of violations mostly by moving files around, without improving the APIs, or, even worse, people just record the deprecations and forget about them. Those ways to solve this violation are actually creating worse code, instead of improving it. The public folders are full of different concepts mixed together, and people are getting annoyed with "Packwerk failing on me with something I can't fix" and just avoiding the tool all together. ref. https://github.com/Shopify/packwerk/discussions/219 このような状況になった実際の原因は Shopify に直接聞かないと分かりませんが、自分なりに予想するに Public API を定義することに価値を感じていない開発者に対しても Public API の提供および運用を強制させてしまったことにあるのではないかと考えています。 投資対効果に対して効果を感じられていない場合は、投資を最小化させるのが最も効果的な行動です。 どの使い道が良いと考えているか やはり他パッケージからの利用方法を絞りたいときに活用するのが良いと考えています。しかし、Shopify の事例を踏まえるとまずは Public API を提供することに価値があると感じられるパッケージでのみ有効にするのが良いのではないでしょうか。 新規で作ったパッケージに対して Privacy Checker を有効にし、Public API の定義を頑張ってみるのも良いと思います。 最初は全てを無効にした状態から始めてもいいじゃないか、気楽に行こう 個人的には最初は全てを無効にした状態で導入を行い、機能・ドメインごとでディレクトリが分かれているだけで他は特に何もしない Rails アプリケーションとして運用してみるのも悪くないと思います。 社内でこのような運用をしているパッケージが存在しますが、「触るファイルがまとまっているのでコードリーディングがしやすくなった」とのポジティブな声もありました。一方「普通の Rails のディレクトリ構造と違うのでギョッとする」という声もあります。 ただし、チェッカーを有効にする際は意図を持って有効にしましょう。繰り返しますが、Packerk はあくまでツールであり鋭いナイフです。ツールは利用者が意図を持って扱わないとツールに振り回されて怪我をしてしまいます。 全てを有効にした状態から始めると大量の package_todo.yml の荒波に飲み込まれてしまい、気付くと package_todo.yml を空っぽにすることが目的になることがあります。何度でも言いますが Packwerk はあくまでツールです。自分たちの開発スタイルを Packwerk に合わせるのではなく、Packwerk の設定を自分たちの開発スタイルに合わせましょう。 　 明日は yykamei の「Slack の Huddles を使ったプラクティスとその背後にある考え」です。お楽しみに！

モノリス特有の運用課題 こんにちは。バックエンドエンジニアの須貝です。 タイミーのバックエンドAPIはモノリスなRuby on Railsアプリケーションです。2024年12月現在、このリポジトリ上で10程度のチームが開発しています。 モノリスは利点も多いのですが、チームが増加するにつれて運用面でモノリス特有の難しさを感じることも増えてきました。例えば、SentryやDatadogで何かエラーや問題を検知しても「これはどこのチームの持ち物なのか」という責任があいまいになってしまい改善がなかなか進まない、基盤的なチームがエラーのトリアージをするにしても調査の負担が大きい、といった課題がありました。 SentryとDatadogにコードオーナーを送る 「まずどこのチームの持ち物なのかわかりやすくしよう」ということで、SentryとDatadogにコードオーナー（リポジトリ内の特定のファイルやディレクトリに責任を持つチーム）の情報を送信するようにしました。すでにバックエンドのリポジトリではGitHubのCODEOWNERSを導入していたのでこちらを利用しました。 なお、CODEOWNERSファイルのパースと、ファイル・クラスなどからコードオーナーを取得する処理ではCodeOwnershipというgemを活用しています。 github.com やることはシンプルでSentryとDatadogに情報を送信する際に、CodeOwnership gemを使ってコードオーナー名を取得し、tagのような形で付与してあげるだけです。以下、それぞれの実装例を紹介します。 Sentry編 まず、Sentryにコードオーナーを送信するところから見ていきましょう。 CodeOwnershipはbacktraceを渡してコードオーナーを返すこともできるので、Sentryにコードオーナー情報を送信する実装も簡潔です。以下の実装例のようにsentry-ruby gemの設定に数行追加するだけで済みます。 Sentry .init do |config| # ...諸々省略 config.before_send = ->(event, hint) do if hint[ :exception ] # コードオーナー名を取得 code_owner = CodeOwnership .for_backtrace(hint[ :exception ].backtrace)&.name || ' unknown ' # code_ownerというtagでSentryに情報を送信する event.tags[ :code_owner ] = code_owner end end end CodeOwnership.for_backtrace は渡したbacktraceを先頭から見ていき、コードオーナーが見つかった場合はそのコードオーナーを返す便利なメソッドです。 これでSentry側にtagとしてコードオーナー情報を送信するようになったので、Sentryの管理画面上でも確認できるようになっています。下記の画像のようにIssueの画面のTagsにコードオーナー名（この例ではWorking Relationsというチーム）が表示されています。 Sentryの画面で見た様子 さらに便利にするためにSentryから飛んでくるSlack通知でもコードオーナー情報を見られるようにしました。SentryのAlertルールの編集で「Set conditions」の「THEN」の「and show tags」の箇所に code_owner （上記のコード例で設定したtag名）を追加するだけです。 SentryのAlertの編集画面 これでSlack通知で下記のようにコードオーナー名（この例ではIronBankというチーム）が見られるようになりました。 SentryからのSlack通知 Datadog編 続いてDatadogのAPMでもコードオーナー情報を見られるようにしていきます。Controller（APIリクエスト）とSidekiqのjob（非同期処理）の2パターンに対応します。 まずControllerです。下記のようなModuleを書いてControllerでincludeします。 module DatadogTaggable extend ActiveSupport :: Concern included do before_action :set_datadog_tags end private def set_datadog_tags span = Datadog :: Tracing .active_span return unless span code_owner = CodeOwnership .for_class( self .class)&.name || ' unknown ' span.set_tag( ' code_owner ' , code_owner) rescue StandardError => e Rails .logger.warn( " Failed to set code_owner tag to span: #{ e.message } ( #{ e.class } ) " ) end end すると下記のようにDatadogのAPMでコードオーナー名（この例ではWork Wellというチーム）が確認できるようになります。 Datadog APMのTrace 次はSidekiqです。下記のようなMiddlewareを書いて上記のModule同様にDatadogのspanにtagをセットしてあげましょう。 class SidekiqDatadogMiddleware include Sidekiq :: ServerMiddleware # loggerを使用するため def call (worker, _job, _queue) span = Datadog :: Tracing .active_span if span code_owner = CodeOwnership .for_class(worker.class)&.name || ' unknown ' span.set_tag( ' code_owner ' , code_owner) end rescue StandardError => e logger.warn( " Failed to set code_owner tag to span: #{ e.message } ( #{ e.class } ) " ) ensure yield end end あとはSidekiqの設定で上記のMiddlewareを追加してあげれば完了です。 Sidekiq .configure_server do |config| # ...略 config.server_middleware do |chain| chain.add SidekiqDatadogMiddleware end # ...略 end おわりに 実際に上記の仕組みを導入してみて、自分がSentryのエラー通知をよく見ているというのもあり、ぱっと見で担当チームがわかるのはだいぶ助かるなあと日々感じています。主要なエンドポイントやJobは自分の中に脳内マッピングができている（気がする）ものの、さすがに限界を感じ始めていたのでこれ無しではもう生きていけません。後はSentryは最終的にはSlackでメンションまでできるようにしたいのですけど、あまり賢い方法が思いつかずに困っているので良い案のある方は教えてください。 また、上記では紹介しきれなかったのですが、ログにもコードオーナー名を付与しているのでDatadog Logsでもコードオーナーを見られるようにしています。コードオーナーを条件に入れてアラートを設定したり、ダッシュボードを作ることも可能になっているので、チーム単位でのオブザーバビリティの向上にも寄与するのではないかと考えています。 最後に自分が所属しているRailway（Rails WayではなくRailway）というチームではこんな感じでバックエンドアプリケーションの横断的な課題を解いたり、他のバックエンドエンジニアの開発生産性を上げたりするような活動を行っています。なんと、いま絶賛一緒に働いてくれる方を探しているので、カジュアル面談でお話しましょう。 product-recruit.timee.co.jp

Timee Advent Calendar 2024 13日目の記事です。 こんにちは！バックエンド・エンジニアの松岡です。 僕は2024年3月にタイミーに入社して、オフショア開発チームでブリッジ・エンジニアをしています。 チームメンバーの多くはオフショア先のベトナムの方々で、僕はそんなみんなと一緒にわいわい開発しています。 そんなチームではコミュニケーションの多くが英語で行われていますが、僕の英語力は、、、、 ということで今回は、英語学習について僕の取り組みを紹介します！ 目次 過去の英語力 学習をはじめるきっかけ 目指すゴール CEFRとは B2を選ぶ理由 ゴールまでの学習量 学習方法 Speak 英語コーチ-イングリッシュおさる NHKゴガク 学習を継続する方法 現在の英語力 最後に 過去の英語力 まず以前の僕の英語力は中学生レベルでした。 どのように中学生レベルかというと、英語を学習したのが中学時代だけだったということです。最後の学習機会はきっと高校受験だったと思います。 社会人になってから何度か英語を使う機会がありましたが、今のように学習することはありませんでした。きっと当時の自分には英語学習は優先度の低いことだったのでしょう。 学習をはじめるきっかけ 僕はソフトウェア・エンジニアを20年以上やっています。 その過程でそこそこに技術力を成長させてきましたが、だんだんと自分に伸びしろを感じなくなっていました。 そこで、自分の成長に伸びしろがありそうなものを見渡したときに気になったのが英語でした。 そして次のような意欲や好奇心をもったことがはじまりでした。 伸びしろがあるとはいえ、若くない自分がいまから成長できるのか！？！？やってみるしかない！ 英語を覚えたら僕の人生の可能性はどれくらい広がるだろうか？気になる！やるしかない！ 一方で、それまで趣味としてやってきた技術の勉強をいったんやめる決断もしました。両立できるほど時間がないと感じたからで、それくらい真剣に取り組むことにしました。 目指すゴール 目指すゴールはCEFRのB2で、そのためにやることは600時間の学習です。 CEFRとは CEFRとはCommon European Framework of Reference for Languageの略で、外国語の習熟度を測る国際基準です。セファールと呼ぶようです。 ja.wikipedia.org A1からC2まで等級が6個あり、僕が目指すB2はその真ん中あたりです。 出典：「 各資格・検定試験とCEFRとの対照表 」（文部科学省） B2を選ぶ理由 B2を選んだ理由には エンジニア組織の英語化変革 EX という書籍の内容を参考にしています。 この書籍には 開発チームのすべてのコミュニケーションの英語化はB2が目安 であると書かれており、自分が目指すところはそこかなと思ったのでした。 エンジニア組織の英語化変革 EX［English Transformation］～グローバル時代に生き残る強い組織作りの鉄則～ 作者: 手島 拓也 , Marc Anderson , 水畑 建一 技術評論社 Amazon ゴールまでの学習量 次の解説によると、 英語初心者がB2を目指す場合は600時間の学習時間が必要 なようです。 prontest.co.jp 600時間は1日に1時間の学習で1.7年、1日に1時間半の学習で1.1年の長さです。 僕には適度かなという印象です！ 学習方法 いろいろな方法をためしていますが、僕がお世話になった教材を3個紹介します！ Speak www.speak.com 一番はじめに取り組んだのがSpeakというサービスでした。2023年4月 (約1年半前) にサブスクリプション契約していて、現在も続いています。 僕は勉強方法に無知だったんですが、その当時話題になっていたことが選んだきっかけでした。 diamond.jp 学習内容はAIと行う英会話レッスンです。 会話の相手がAIなのでとても気軽にできる ことがよいところです。 英語コーチ-イングリッシュおさる www.youtube.com 中学生のときは小笠原先生から英語を学びましたが、この度はイングリッシュおさる先生から英語を学びました。 下記の動画は先生の5時間の大作です。これを見て基礎を学びことによりその後の学習がより効果的になった気がします。 www.youtube.com NHKゴガク いまもっとも学習している教材はNHKゴガクです。次の2個の番組を聴いています。 ラジオ英会話 www.nhk.jp ラジオビジネス英語 www.nhk.jp 学習方法は次のとおりです。 リスニングとスピーキングはアプリ www.nhk.or.jp リーディングとライティングはNHKテキスト (本) www.nhk-book.co.jp よいところは3点です。 毎週新しいエピソードが配信されるため、学習する教材探しに困らないこと 各講座はそれぞれに毎週5個の新しいエピソードが配信されます。僕の場合は2個の番組を聴いているのでエピソードの数は合計10個です。 1個のエピソードの長さが短いため、続けやすいこと 1個のエピソードの長さは15分です。 重要な4個のスキルを学習できること 上記のとおり、リスニング、スピーキング、リーディング、ライティングの4つを学習できます。 学習を継続する方法 何事も継続することが一番難しいですよね。 僕のおすすめは 基本的に毎日やる です。 やる日とやらない日があると、やらない日の楽さを知っているのでやる日が少し辛く、よしやるぞ！と心を整えるまでにも時間がかかります。 一方で毎日にやる（やるしかない！）ということにすると上記は不要になります。 とはいえ、疲れていたり、予定があって時間がないときもあり、そんな日にはお休みします。 現在の英語力 さてさて、こんな僕ですが2024年10月に初TOEIC L&Rを受験してきました。 受験の目的は現在地を知るためです。 結果は590点で、CEFRで表すとA1です。目標は600点以上でしたのでくやしい結果でした泣。 TOEICの受験は今回で終わり、次回からはDuolingo English Testを受ける予定です。 englishtest.duolingo.com これを選ぶ理由は次のとおりです。 はやい インターネットで受験できる。 48時間以内に結果が出る。 やすい 試験料がTOEICやTOEFLより安い。 うまい 世界中の4500以上の教育機関で認められている。 最後に 現在までの学習時間はおよそ200時間でした。 ゴールまであと400時間、来年末までに達成したい！ YATTEIKI!!! 次回のAdvent Calendarで結果発表できるかもしれません。 ということで来年またお会いしましょう〜！

Timee Product Advent Calendar 2024 13日目の記事です。 MLOpsエンジニアとして10月にタイミーにジョインした、 ともっぴ です。 データエンジニアリング部 データサイエンス（以下DS）グループに所属し、ML基盤の構築・改善に取り組んでいます。 概要 本記事では、Vertex AI Pipelinesを効率的に開発するために行った 「Vertex AI Pipelinesテンプレートを管理するArtifact Registryの導入」 の取り組みを紹介します。 過去、DSグループが取り組んできたVertex AI Pipelinesの開発効率化は、以下の記事を参照ください。 tech.timee.co.jp tech.timee.co.jp 背景と課題 背景 前提としてタイミーのML基盤では、サービスレベルに応じた複数のGoogle Projectが存在し、その中で複数のMLパイプラインが動いています。( 参考記事 ) Artifact Repositoryを導入する以前は、GCSにMLパイプラインテンプレートを格納していました。 下図は簡易的に表現したその時のアーキテクチャです。 Artifact Registry導入前のアーキテクチャ 課題 この状態での課題は2点ありました。 純粋な管理の煩雑さ 複数の環境のGCSに、以下のような構成でMLパイプラインテンプレートが存在していました。 ./project-internal ├── ML_Project_A_Bucket │   └── pipeline │   ├── v0.1.0 │   │   └── pipeline-config │   │   └── pipeline.json │   └── v0.2.0 │   └── pipeline-config │   └── pipeline.json └── ML_Project_B_Bucket └── pipeline ├── v1.0.0 │   └── pipeline-config │   └── pipeline.json └── v1.1.0 └── pipeline-config └── pipeline.json こうした状況下で、パイプラインやバージョンが増えていくにつれ、見通しが悪くなっていました。 ライフサイクル管理の煩雑さ MLパイプラインテンプレートすべてのファイルを保存し続ける必要はなく、開発用は一定の期間で削除、逆に本番用はバージョン管理して一定の世代分は必ず保持する、という管理が求められます。 GCSでもオブジェクトライフサイクルが設定できるので、n世代前は削除する、n日前のパイプラインは削除する、等のルールは設定可能です。 しかし従来の構成では、一つのMLプロジェクトにつき一つのバケットを作成していたので、MLプロジェクトが増えるたびに、ライフサイクル設定が必要になってしまい、手間が増える状況でした。 GCSに集約するという方法も考えられますが、Artifact Registryの方が各種ポリシーを柔軟に設定できることから、Artifact Registryの採用に至りました。また、Artifact RegistryのKFP対応自体が最近 *1 *2 のことなので、これまで採用を見送ってきた背景もあります。 ソリューション 改善後のアーキテクチャ Artifact RegistryにKFP formatのリポジトリを作成し、そのリポジトリに対してCDでMLパイプラインテンプレートをアップロードする構成となりました。 Artifact Registry導入後のアーキテクチャ その構成にしたことで、前項で書いたような複数プロジェクト・複数のバケットで管理してきたMLパイプラインテンプレートを、一つのリポジトリの中で管理できるようになりました。 （以下のディレクトリ構成のイメージ） ./project-central-repository └── kfp-repository ├── pipeline-1 │   ├── version1.yaml │   └── version2.yaml └── pipeline-2 └── version1.yaml 実装サマリー 具体的にどのような実装を行なったのか、概要を紹介します。 CDスクリプトの変更 CDで行うパイプラインテンプレートのアップロードは、 kfpライブラリのRegistryClient を利用しました。KFP CLIから利用できたら便利なのですが、 こちらのissue を読む限り現在サポートはされていないようでした。 そのため、簡易なPythonスクリプトを用意して、 GitHub Actions上で呼び出すことにしました。 cleanup_policyを設定しパイプラインのライフサイクルを管理 Artifact Registryでは cleanup_policy を設定することで、ライフサイクルを設定できます。Artifact Registryで一元管理することで、統一的なルールでライフサイクルを、各MLパイプラインテンプレートに適用でき、管理の煩雑さが解消できました。 実装途中で詰まったところ 実装をする上で、いくつか直面した問題があったので、その概要と解決方法を紹介します。 1) GitHub Actions上でkfp.RegistryClient.upload_pipelineが通らない CDで呼び出しているアップロード用のPythonスクリプトですが、ローカルでは正常終了するにもかかわらず、GitHub Actions上では認証エラーになる現象に遭遇しました。 原因を探っていると、 LayerXさんの記事 に行き当たり、RegistryClientがWorkload Identityに対応していないことが原因と判明しました。 LayerXさんの記事の通り、 kfp.registry.ApiAuth を利用することで問題は解決しました。 2) jsonではアップロードできず、yamlが必要になる 改善前の構成では、パイプラインはjsonでGCSに格納していました。 しかし、 kfp.RegistryClient.upload_pipeline(…) を利用すると、jsonでは invalid extension type pipeline.json というエラーでBad Requestとなりました。 ドキュメントを確認すると、 Artifact Registry REST APIを利用する場合、yamlである必要があると記載 がありました。 KFP SDK v2ではyamlフォーマットが推奨 されており、かつ KFP SDK v1のサポートは2024/12/20に切れるとされている ため、徐々にyamlに移行していくこととなりそうです。 3) Cloud Composer(Airflow)のRunPipelineJobOperatorからArtifact Registryのパイプラインを利用する際にタグ指定だと権限エラーとなる 最初、以下のようなコードで動作すると思っていたところ、権限エラーとなりました。 from airflow.decorators import dag from airflow.providers.google.cloud.operators.vertex_ai.pipeline_job import RunPipelineJobOperator @ dag (...) def main (): TEMPLATE_REPOSITORY_URL= "https://asia-northeast1-kfp.pkg.dev/project-central-repository/pipelines/ml-project/v1.0.0" vertexai_pipeline = RunPipelineJobOperator( task_id=task_id, project_id=gcp_project_id, region=gcp_location, display_name=display_name, template_path=TEMPLATE_REPOSITORY_URL, # KFP Repository上のテンプレートのURL service_account=pipeline_service_account ) 発生したエラーは以下です。 Service account XXX does not have permission to get ArtifactRegistry tag projects/project-central-repository/locations/asia-northeast1/repositories/pipelines/packages/ml-project/tags/v1.0.0 in region asia-northeast1. タグを取得する権限がないと言われています。 ここで、Artifact Registryにおけるタグとバージョンの違いについて確認します。 タグとは、MLパイプラインテンプレートをアップロードする際に、任意で付与できるものです。一方バージョンは、アップロード時に自動で付与される、 sha256: で始まるハッシュ値です。 MLテンプレートのタグとバージョン 関係するサービスアカウントと、Artifact RegistryへのREAD権限は以下の通りです。 サービスアカウント Artifact RegistryへのREAD権限 Cloud Composer用のサービスアカウント あり MLパイプライン用のサービスアカウント (pipeline_service_account) なし 一時的なエラー解消方法は、2通りあります。 タグではなくバージョンハッシュを指定する MLパイプライン用のサービスアカウントにArtifact RegistryへのREAD権限を付与する。 しかし、それぞれデメリットがあり、 1.の方法では、MLパイプライン更新のたびにバージョンハッシュを指定し直す運用となり、意図せぬバージョン指定のミスや、手間がかかることがデメリットです。 2.の方法でも、既存のMLパイプライン用サービスアカウントのIAMを変更し、新規のパイプラインを作る際も権限を毎度付与する手間が発生します。タイミーのML基盤では、 MLパイプラインごとに柔軟に権限付与するために、MLパイプラインごとにサービスアカウントを作成する運用になっているため、その工数は無視できないものになります。 Airflowのソースコードを確認したところ、RunPipelineJobOperatorの内部では、 PipelineJob初期化時にArtifact Registryからyamlを取得 し、 Vertex AI Pipelinesのジョブを作成するリクエスト を送っている流れになっていることがわかりました。 上述のエラーは、 ジョブを作成するリクエストをまさに送っている部分 で発生しており、この部分でMLパイプライン用のサービスアカウントから共有リポジトリへのアクセスが発生していると判断できました。 原因を踏まえると、RunPipelineJobOperatorにバージョン付きのMLパイプラインテンプレートを渡せるようにする方法が良いと考えました。 タグからバージョンを取得するには、 kfp.RegistryClient.get_tag(…) を利用すれば良いので、最終的に以下のような実装となりました。 from airflow.decorators import dag from airflow.providers.google.cloud.operators.vertex_ai.pipeline_job import RunPipelineJobOperator @ dag (...) def main (): TEMPLATE_REPOSITORY_URL= "https://asia-northeast1-kfp.pkg.dev/project-central-repository/pipelines/ml-project/v1.0.0" # kfp.RegistryClient.get_tag(...)をもとに、タグ付きのURLからバージョン付きのURLを取得するメソッド template_url_with_version = resoleve_template_version(TEMPLATE_REPOSITORY_URL) vertexai_pipeline = RunPipelineJobOperator( task_id=task_id, project_id=gcp_project_id, region=gcp_location, display_name=display_name, template_path=template_url_with_version, # KFP Repository上のテンプレートのURL w/ version service_account=pipeline_service_account ) まとめ 取り組みの内容自体はちょっとしたものですが、ML基盤の拡張性や利便性を高められるものかと思っています。一方、当初想定したよりも特に権限周りで詰まりどころが多く、この記事の内容が誰かの参考になれば嬉しいです。 入社2ヶ月ということもあり最初は入社エントリでも書こうと思っていたのですが、せっかくなら直近取り組んできたことを書きたいと思い、本記事の執筆に至りました。 最後に、入社エントリっぽいことを簡単に書いておきたいと思います。 タイミーではデータを活用した施策が活発に行われています。 MLOpsエンジニアとして、より広く、安全で使い勝手の良いML基盤にするため、日々ワクワクしながら取り組んでいます。 We’re Hiring! タイミーのデータエンジニアリング部・データアナリティクス部では、ともに働くメンバーを募集しています！！ 現在募集中のポジションは こちら です！ 「話を聞きたい」と思われた方は、是非一度 カジュアル面談 でお話ししましょう！ *1 : Vertex AI PipelinesテンプレートがArtifact Registryに対応したのは、2022年12月です。 Release Note: https://cloud.google.com/vertex-ai/docs/release-notes#December_05_2022 *2 : kfp.RegistryClientのリリースはKFP SDK 2.0.0からで、2023年6月です。Release Note: https://github.com/kubeflow/pipelines/blob/master/sdk/RELEASE.md#200

こんにちは！ タイミーでPlatform Engineerをしている @MoneyForest です。 こちらは Timee Product Advent Calendar 2024 の10日目の記事です。 2024年8月に入社して、幸いにもチームメンバーにも恵まれて楽しく働いています。 個人的にキャッチアップがあまりできていなかった OpenTelemetry を題材にして実装をしてみたので、ここから得られた気づきや知見を共有したいと思います。 はじめに アプリケーションの可観測性（Observability）を担保する上で、APM(Application Performance Monitoring)は重要です。 現在、JaegerやPrometheusのような非商用のものから、DatadogやNew RelicやSplunkなど様々なAPMを利用できるツールが存在します。（本記事ではこれらを「Observability Backend」と呼称します。） これらのObservability BackendでAPMを利用するには、各々が提供する独自のSDKを使用してTraceやSpanを送信する必要があり、以下のような課題がありました。 アプリケーションの実装に各SDKの仕様が滲み出る Observability Backendの切り替えが困難 OpenTelemetryの登場により、オブザーバビリティに関する様々な概念が抽象化され、統一された仕様が提供されるようになりました。 これにより、アプリケーションコードとObservability Backendの実装を分離し、状況に応じて適切なツールを選択できるようになりました。 つまり、ローカルではJaegerのような非商用のツールで開発中にAPMを利用し、デプロイしたアプリケーションではDatadogのような商用ツールでリッチなUIでAPMを利用したり、モニタリングアラートを組んだりなどができるということです。 本記事では、Go言語でOpenTelemetryを活用して、環境ごとにObservability Backend（Jaeger、Datadog）を切り替える実装を行うことで、これらのメリットを体感していきたいと思います。 実装してみる 実装の全量はこちらにあります。 https://github.com/MoneyForest/advent-calender-2024 共通インターフェースの定義・初期化処理 OpenTelemetryに準拠した共通インターフェースを定義することで、各バックエンドの実装を抽象化します。（この実装では infrastructure/tracer.go に配置しています。） 共通インターフェースはOpenTelemetryのSDKの仕様に則してインターフェースを定義します。 例えばShutdownメソッドは、OpenTelemetryの仕様に基づき定められているものです。トレースデータの欠損を防ぐために必要な標準仕様となっています。 参照： https://opentelemetry.io/docs/specs/otel/trace/sdk/#shutdown また、今回は環境に応じてObservability Backendを切り替える実装のため、envを条件に初期化するProviderを切り替えています。 // infrastructure/tracer.go package infrastructure import "context" type TracerProviderWrapper interface { Shutdown(context.Context) error } func InitTracer(env string ) (TracerProviderWrapper, error ) { switch env { case "dev" : return InitDatadog() default : return InitJaeger() } } Observability Backend固有の初期化処理 次に各Observability Backendごとの初期化処理を書いていきます。 Datadog Datadogは2つの方法で送信できます。 ddotelアダプター経由 参照： https://docs.datadoghq.com/ja/tracing/trace_collection/custom_instrumentation/go/otel/ こちらではDatadogのSDKであるdd-trace-goからddotelというアダプターを通じてOtelに準拠したTraceProviderを生成します。 送信するポートはDatadog Agentのデフォルトポートである8126になります。 // infrastructure/datadog.go package infrastructure import ( "context" "os" "go.opentelemetry.io/otel" ddotel "gopkg.in/DataDog/dd-trace-go.v1/ddtrace/opentelemetry" ddtracer "gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer" ) type ddTracerProvider struct { provider *ddotel.TracerProvider } func InitDatadog() (*ddTracerProvider, error ) { tp := ddotel.NewTracerProvider( ddtracer.WithService(os.Getenv( "SERVICE" )), // MoneyForest ddtracer.WithEnv(os.Getenv( "ENV" )), ddtracer.WithServiceVersion( "1.0.0" ), ddtracer.WithAgentAddr( "localhost:8126" ), ) otel.SetTracerProvider(tp) return &ddTracerProvider{provider: tp}, nil } func (p *ddTracerProvider) Shutdown(ctx context.Context) error { return p.provider.Shutdown() } Otel SDK経由 こちらではOtel SDKを使用してTraceProviderを生成します。 参照： https://docs.datadoghq.com/ja/opentelemetry/interoperability/otlp_ingest_in_the_agent/?tab=host#enabling-otlp-ingestion-on-the-datadog-agent 送信するポートはOTLP HTTPのデフォルトポートである4318になります。 // infrastructure/datadog.go package infrastructure import ( "context" "os" "go.opentelemetry.io/otel" ddotel "gopkg.in/DataDog/dd-trace-go.v1/ddtrace/opentelemetry" ddtracer "gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer" ) type ddTracerProvider struct { provider *sdktrace.TracerProvider } func InitDatadog() (*ddTracerProvider, error ) { exporter, err := otlptracehttp.New( context.Background(), otlptracehttp.WithEndpoint( "localhost:4318" ), otlptracehttp.WithInsecure(), otlptracehttp.WithURLPath( "/v1/traces" ), ) if err != nil { return nil , err } tp := sdktrace.NewTracerProvider( sdktrace.WithBatcher(exporter), sdktrace.WithResource(resource.NewWithAttributes( semconv.SchemaURL, semconv.ServiceNameKey.String(os.Getenv( "SERVICE" )), // MoneyForest semconv.DeploymentEnvironmentKey.String(os.Getenv( "ENV" )), )), ) otel.SetTracerProvider(tp) return &ddTracerProvider{provider: tp}, nil } func (p *ddTracerProvider) Shutdown(ctx context.Context) error { return p.provider.Shutdown(ctx) } Jaeger Jaegerは jaegar-client-go のSDKがありましたが、2024/5に非推奨となっています。 今はOpenTelemetryに準拠することが推奨されているため、Otel SDKによる実装を行います。 // infrastructure/jaeger.go package infrastructure import ( "context" "os" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp" "go.opentelemetry.io/otel/sdk/resource" sdktrace "go.opentelemetry.io/otel/sdk/trace" semconv "go.opentelemetry.io/otel/semconv/v1.4.0" ) type jaegerTracerProvider struct { provider *sdktrace.TracerProvider } func InitJaeger() (jaegerTracerProvider, error ) { exporter, err := otlptracehttp.New( context.Background(), otlptracehttp.WithEndpoint( "localhost:4318" ), otlptracehttp.WithInsecure(), ) if err != nil { return jaegerTracerProvider{}, err } tp := sdktrace.NewTracerProvider( sdktrace.WithBatcher(exporter), sdktrace.WithResource(resource.NewWithAttributes( semconv.SchemaURL, semconv.ServiceNameKey.String(os.Getenv( "SERVICE" )), semconv.DeploymentEnvironmentKey.String(os.Getenv( "ENV" )), )), ) otel.SetTracerProvider(tp) return jaegerTracerProvider{provider: tp}, nil } func (p jaegerTracerProvider) Shutdown(ctx context.Context) error { return p.provider.Shutdown(ctx) } アプリケーションでの利用 アプリケーションでは、OpenTelemetryの標準APIを通じてTracerを使用することで、Observability Backendに依存しない一貫した実装が可能になります。 package main import ( "context" "crypto/rand" "fmt" "log" "os" _ "github.com/go-sql-driver/mysql" "github.com/MoneyForest/timee-advent-calender-2024/internal" "github.com/MoneyForest/timee-advent-calender-2024/internal/handler" "github.com/MoneyForest/timee-advent-calender-2024/internal/infrastructure" ) func main() { // Initialize tracer tp, err := infrastructure.InitTracer(os.Getenv( "ENV" )) if err != nil { log.Fatal(err) } defer tp.Shutdown(context.Background()) // ... } func (h *UserHandler) CreateUser(ctx context.Context, email string ) error { tracer := otel.Tracer(os.Getenv( "SERVICE" )) ctx, span := tracer.Start(ctx, "UserHandler.CreateUser" ) defer span.End() span.SetAttributes( attribute.String( "email" , email), attribute.String( "handler" , "UserHandler" ), attribute.String( "method" , "CreateUser" ), ) return h.userUsecase.CreateUser(ctx, email) } 動かしてみる これまでの実装がうまくいっていれば、JaegerとDatadogで同じようなAPMを見ることができる想定です。確認してみましょう。 Docker Composeで gcr.io/datadoghq/agent と jaegertracing/all-in-one のサイドカーを立てます。 本来はdatadog-agentはdev環境以上に必要で、ECSのサイドカーなどに定義すればよいです。 （リポジトリではMySQLやRedisのコンテナも建てていますが省略します。） JaegarはUIまでパッケージングされたイメージが公式から提供されており、こちらにトレースを送信することで、localhostのUIからAPMを確認できます。 datadog-agent : image : gcr.io/datadoghq/agent:latest environment : - DD_API_KEY=${DD_API_KEY} - DD_SITE=datadoghq.com - DD_APM_ENABLED= true - DD_APM_NON_LOCAL_TRAFFIC= true - DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT=0.0.0.0:4318 ports : - "8126:8126" - "4319:4318" # OTLP HTTP (ローカルマシンのポートはJaegarと被るのでずらしている) volumes : - /var/run/docker.sock:/var/run/docker.sock - /proc/:/host/proc/:ro - /sys/fs/cgroup:/host/sys/fs/cgroup:ro jaeger : image : jaegertracing/all-in-one:latest ports : - "16686:16686" # UI - "14250:14250" - "4318:4318" # OTLP HTTP environment : - COLLECTOR_OTLP_ENABLED= true dev環境（Datadog） https://app.datadoghq.com/apm/traces でトレース情報を見ることができます。 以下はddotelを使用して送信したメトリクスです。 以下はOtel SDKを使用して送信したメトリクスです。 1. と異なる点として、SpanのAttributeに otel の構造体があります。また、 process_id や runtime-id は存在しません。 local環境（Jaegar） http://localhost:16686/search でトレース情報を見ることができます。Datadogと一部のメタデータが異なっていたりと、完全に同一ではないものの、概ね同じ内容を見ることができます。 Datadogのトレースと異なる点としては、サービス名として与えていたMoneyForestがotel.libraryにマッピングされていましたが、こちらではotel.scopeにマッピングされているという点です。 実装してわかったこと GoのOtel SDKから生成される sdktrace.TracerProvider では Shutdown はcontextを引数に取るものの、 ddotel.TracerProvider の Shutdown はcontentを引数に取らない、などの細かな差異があり、共通インターフェースの方で吸収する必要がありました。 Datadogの実装でOtel SDKを直接使う方を採用すれば、共通インターフェースを用意する必要がなく、以下のように InitTracer は初期化の条件分岐のみを書いた実装が可能です。 func InitTracer(env string ) (*sdktrace.TracerProvider, error ) { switch env { case "dev" : return initDatadog() default : return initJaeger() } } またddotelのライブラリには added to the OpenTelemetry API will default to being a no-op until implemented by this library. のコメントがあり、新機能の利用にはGoのOtel SDKではなくDatadog Agent側での実装を待つ必要がありそうでした。 そのため、Datadogの独自機能を重視する場合はddotelを採用し、Otelへの準拠を重視する場合はOtel SDKで実装するなど、実装の際に意思決定が必要になりそうです。 また、細かなマッピングの違いも存在しそうなため、Traceを使ってモニタリングアラートを組んでいる場合は注意して切り替える必要がありそうです。（例えばDatadogからNew Relicに変更する場合など） 商用のツールでは料金体系なども異なるため、仕様が同じでもサンプリングレートの値の調整が必要になることもあるでしょう。 まとめ OpenTelemetryを活用することで、トレーシング実装でより一貫性のあるコードを実現できることがわかりました。 これにより、環境に応じて適切なObservability Backendを利用したり、移行することが容易になったりするのは間違いなさそうです。 一方で標準仕様についてはまだまだ理解が浅いので、OpenTelemetry自体の理解も深めて、さらに楽しいエンジニアライフを送りたいと思います！またね〜

こちらは Timee Product Advent Calendar 2024 の9日目の記事です。前日は平岡の スクラムマスターが常に意識するべき重要なこと でした。 タイミーでテックリードをしている @euglena1215 です。 最近、Majestic Monolith と Citadel というアーキテクチャ・考え方を知ったのですが、あまり国内では認知度が高くないように感じたので紹介してみたいと思います。 自分が見つけた日本語での記事は モノリス亜種のアーキテクチャ(Modular MonolithとかMajestic MonolithとかCitadel Architectureとか) と Rails: AppSignalが採用する「シタデルアーキテクチャ」（翻訳）｜TechRacho by BPS株式会社 の2記事のみでした（※記事執筆時点）。 Majestic Monolith Photo by Gary Walker-Jones on Unsplash signalvnoise.com Majestic Monolith の出典は Ruby on Rails の作者である DHH のブログです。2016年に書かれていてすごい。 正確な内容は出典を参照していただくとして、ここでは自分の解釈をまとめてみます。 世間では「モノリスアーキテクチャ」は劣ったアーキテクチャのような評価を受け、「マイクロサービスアーキテクチャ」が優れているような評価を受ける。 Amazon や Google、あるいは何千人もの開発者がいるような会社にとってはマイクロサービスアーキテクチャは素晴らしいアーキテクチャだが、「成功している企業で効果があったのだから、我々にも効果があるはずだ」と思い込んで小さな会社がマイクロサービスアーキテクチャを目指すのは間違い。 巨大な一握りの会社以外はモノリスを受け入れ、意図を持ってモノリスを雄大(majestic)に設計しよう。 モノリス自体が悪いと捉えてしまうと、それを解決するためにはモノリスから脱する以外の道はありません。モノリスをまず肯定することによって、初めて自分たちが抱えている様々な技術的課題の輪郭が見えてきます。 もちろんその中にはモノリスを分けなければ解決できない課題もあると思いますが、そうでないものも含まれていると思います。まずモノリスを肯定することによって、様々な技術的課題の解像度を高めることができる示唆に富んだ考え方だと感じています。 Citadel Photo by K. Mitch Hodge on Unsplash signalvnoise.com こちらも出典は Ruby on Rails の作者である DHH のブログです。2020年に書かれています。 多くのケースで Majestic Monolith はうまく機能するが、パフォーマンスや可用性の問題でモノリスでは対処が難しい課題が出てくることもある。 その際の次のステップは Citadel。Citadel とは、モノリス（Citadel = 城塞）を中央に据えて周辺に必要に応じてモノリスを補完するようなサービス（Outpost = 前哨基地）を配置する考え方。 Outpost としてモノリスとは異なる特性（パフォーマンス上の問題を対処、組織上、実装上など理由は様々）のサービスが提供できれば、アプリケーションの残りの部分は Majestic Monolith として提供し続けられる。 計らずもこの構成になっているプロダクトは多いのではないのでしょうか。タイミーのそのうちの1つです。 Citadel という名前をつけたことで、別物だと感じていた他プロダクトの構成にも共通点を見出せるようになった気がします。DHH の命名の妙だと言わざるを得ません。 状態ではなく、事象に注目している ソフトウェアアーキテクチャの文脈でよく登場するモノリス・マイクロサービス・モジュラモノリスといった分類は、あくまで「こういった状態のシステムはこのような特性を持っている」というカタログでしかありません。 理解し把握しておく分にはとても有用ですが、「（ここに任意のアーキテクチャ名が入る）化」をしたから我々が直面している様々な技術的課題が解決できるかというと、なかなか難しい面もあるかと思います。 ですが、DHH の提唱する Majestic Monolith にも Citadel にも、現場で起きている事象（問題）に対してどのように対処をしていくかという地に足のついた指針のようなものを感じました。 アーキテクチャに囚われず、きちんと目の前で起きている技術的課題を見定めよう。 目の前で起きている技術的課題を見定めたら、必要十分な対処をしよう。 隣の芝生は青いということわざがあるように、自分たちが選択していないアーキテクチャが良く見えてしまうのは人間の性だと思います。Majestic Monolith, Citadel を胸に誘惑に負けないよう努力し続けたいと思いました。 　 明日は @MoneyForest の「OpenTelemetryで環境ごとにObservability Backend（Jaeger、Datadog）を切り替えてエンジョイしてみたよ」です。お楽しみに！

Timee Advent Calendar 2024 6日目の記事です。 タイミーでスクラムマスター（以下、SM）/アジャイルコーチを担当している正義です！ この記事では 学習したことや学んだことは、どんどんアウトプットするといいよ！ どのようなアウトプット方法があるのか？ というお話をします。 なぜアウトプットをするのか？ 1. 自身への定着 それは「学習に対する能動性を向上し、自身の記憶としてより定着させるため」です。 よく見かけるラーニングピラミッドのように、能動的な活動になるにつれて定着しやすくなります。 また、活動によって学習に対するアプローチの深さが変わってきます。 https://www.mext.go.jp/b_menu/shingi/chukyo/chukyo3/004/siryo/__icsFiles/afieldfile/2015/09/04/1361407_2_4.pdf 必ずしも一定の深いアプローチをしていれば身に付くわけではなく、学習する内容によってアプローチの手法は変わってきますし、効果的に定着するかはアプローチとの相性によっても異なります。 学習を定着させるために重要なのは「多角的に、能動的に学ぶこと」です。 そのため、色々な学習に対するアプローチを積極的にしてみることで、自身への学びをより効果的にすることができます。 2. 自身の活動のログとなる 自分の学習・経験をログとなる形で残すことで、自分自身で振り返ることができます。 また、その内容は他の人にシェアできたり、自身の今後の評価材料にもできます。 どのような学びのアウトプット方法があるのか？ 1. ブログでの発信 ブログでの発信はじっくり考えを整理でき、任意のボリュームでの記述が可能です。 また、図・表・写真など、視覚的な情報も載せられます。 私の場合、ブログの記事を最後まで書くのは意外とパワーが必要となってしまうので、「やるぞ！」という気合がないとどうしても後回しにになって、投稿が遅れがちになります。 同じような状態に陥りがちな方は、期日を設ける/体験した翌日には投稿するなどの個人的なルールを設けることをおすすめします。 https://note.com/rakuraku_justice/ 2. Xでの発信 Xでの発信は文字数が限られているため、知見や考えたことの要点のみをまとめることに役立ちます（課金していない人限定）。文量が少ない分、ブログよりも気持ちのハードルを下げて投稿できます。 また、図・表・写真など、視覚的な情報も載せられます。 私の場合はカンファレンスなどで得た情報をサクッとメモがわりに投稿しています。 その情報を元に、あとあと見返してブログなど他のアウトプットにつなげたりしています。 3. カンファレンスプロポーザルでの発信 主にRSGTやスクラムフェスなど、特定のカンファレンスに限られるかもしれませんが、プロポーザルを募集していたりするので、テーマに沿った内容を記載して発信します。 ブログと違う点は、完全にフリーな場ではなくカンファレンスごとに、ある程度テーマや書き方が定まっていることです。 私の場合は、カンファレンスを一つの区切りとして、そこまでに得た知見と関連する経験を記載して投稿してみることが多いです。 （登壇につながれば、さらなるアウトプットもできる！） いざ登壇したいとなっても、うまく書けなかったり、書く内容が思い浮かばなかったりするので、ひとまずカンファレンスプロポーザルは書けそうなら書いてみることをおすすめします。 https://confengine.com/conferences/scrum-fest-osaka-2022/proposal/16594 4. 登壇する カンファレンスやコミュニティイベントでのLT会などの場で、登壇できるならば登壇してみましょう！ 登壇による学習の効果は高いと考えています。資料をまとめるだけでも一つのアウトプットですし、それを自身の言葉で発表することは更なるアウトプットや情報の整理につながります。 また、Q&Aの時間で質問してもらえたらラッキーで、瞬時に色々と考えた上で自分の言葉にする経験を得ることができます。 このように登壇では複数のアウトプットを体験できるので、機会はどんどん獲得してたくさん登壇しましょう！ 5. Podcastなどのラジオ形式での配信 1人もしくは数名でラジオ形式の収録を行い、編集と配信をします。 個人的には、一番アウトプットが楽に感じています。一緒に収録してくれる人がいれば、テーマに対し議論しているだけでアウトプットにつながります。 編集は少し時間がかかります（30minのラジオに対して1hほど）。しかし、失敗したりおかしいと感じたりする部分はカットできるので、安心して収録できます。 ブログを書くよりも準備や考えることが少なく始められるので、おすすめです！ https://creators.spotify.com/pod/show/yoriyokufm 他にも色々なアウトプット方法がある エンジニアやデザイナーであれば業務外において趣味で創作をする 仕事で得た知識を別の場で活用してみる 1on1や数名の場で議論をしてみる 一つの形に絞るのではなく、色々な形式を試してみることで自分に合う形式を見つけられるかもしれません。 最後に 臆せず、アウトプットすることが大切です。 「自分が話してもすごい経験があるわけでもないし…」 「誰かがすでに記事にしていそうだし…」 と、考えてしましい、アウトプットをしないのはもったいないです。 あなたの経験には、必ず価値があり、誰かの役に立ちます。 まずはどんな形でもよいので、発信してみて自分の学習のためのアウトプットにチャレンジしてみましょう！ いつかそれが誰かの役に立っていると気づく日がきっときます！ 私の Timee Advent Calendar 2024 Day 6は終わりです！ 引き続き、明日の記事も是非読んでみてください！

Timee Advent Calendar 2024 6日目の記事です。 タイミーでスクラムマスター（以下、SM）/アジャイルコーチを担当している正義です！ この記事では SMに求められるリーダーの性質は何か SMもプロジェクトマネジメントに関する知識を得ておくと良い というお話をします。 スクラムマスターに求められるリーダーの性質は色々ある SMはどのようなリーダーであるべきか、色々な観点で話されているのを見かけます。 スクラムガイドから読み取ろうとしたり、実践ベースで考えたり、学術的な観点などがあります。 (過去に弊社SMが登壇した際の資料もご紹介します！) https://speakerdeck.com/shinop/practical-scrum-master-vs-theoretical-scrum-researcher-d29104ff-15ed-4fcc-a0e9-9e0bef2a0d3a 私も数年間SMを担当してきたので、自分なりに考えていることをお話ししてみたいと思います。 スクラムマスターはどんなリーダーなのか？ 「スクラムマスター」というロールはスクラムガイド（2013、2017、2020年版）で定義されているので、そこから見ていきましょう。 まずは 2013年版 から。 スクラムマスター スクラムマスターは、スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。 スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。 このように、明確にリーダーのスタイルがサーバントリーダーとして説明されています。 そして責任についても、「スクラムの理解と成立に責任を持つ」とあります。そのために、理論・プラクティス・ルールをチームに落とし込み、チーム外の人々に対してスクラムチームを理解してもらう活動が中心に記載されています。 つまり、大切にすべき事柄をチームが会得し、実践していくための環境・システム作りに重きを置いていると捉えました。 続いて 2017年版 から。 スクラムマスター スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。スクラムマスターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援することで、その責任を果たす。 スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。 「スクラム」が「スクラムチーム」に変更されていますが、記載されている内容については大きな変更はありません。 責任については「SMは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ」とあります。「成立」ではなく「促進と支援」に変わったのは、スクラム成立はSMだけが責任を負うわけではなく、スクラムチームで進めていくことを意識付けているように感じました。 活動自体は、チームに落とし込む項目に「価値基準」が足されてはいますが、大枠では2013年からの変化はありません。引き続き2013年と同様の事柄に重きを置いていると解釈しました。 そして 2020年版 。 スクラムマスター スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。 スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。 スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。 これまでとは異なる点が増えています。 「責任」に触れている部分（ほぼ全体）。 スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。 スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。 スクラムマスターは、スクラムチームの有効性に責任を持つ。 スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。 責任の内容とその果たし方がセットで書かれています。 注目したい点の一つは「スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ」です。今までの「促進と支援」よりその先の変化、つまり結果にフォーカスしています。 また、「スクラムチームの有効性に責任を持つ」という点が一番大きい変化だと捉えています。スクラムチームの有効性、つまり結果に対し責任を持つことが明確に記載されました。 以前はスクラムの定着がSMの役割でしたが、スクラムが効果的に働き、有効である、結果を出すことがSMに求められるように変化しました。スクラムはあくまで方法であり、大前提となる目的を達成することとSMがそこに意識を向けるために責任が明文化されたと考えています。 そしてリーダーについて言及している部分は「スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである」です。 これまでに色々な議論のきっかけになっている「真のリーダー」、これはとても抽象的なので様々な解釈があると思います。 継続して「奉仕する」が使用されているので、これまでのサーバントリーダーは引き継いでいるように見えます。しかし、サーバントリーダーが明示的に記載されなくなったのは、それ以外にも求められるリーダーとしての役割、リーダーシップが必要であることを示唆しているようです。 パス・ゴール理論の4つのリーダータイプではありませんが、 サーバントというスタイルで、チームの自律性を促し、支援するリーダー 自身が先導し、チームがゴールへ到達することを導くリーダー という形で、自分でチームを引っ張り、目的にコミットする形も必要だと考えられます。 （結果に対し責任を持つということは、こちらに繋がってきます） スクラムマスターが向き合う”結果”とは？ 「結果」についての分解方法としては「直接的な結果」と「間接的な結果」があります。 直接的な結果：ある役割や行動が、最終的な成果やアウトプットに対して直接的に影響を与える場合を指す 間接的な結果：ある役割や行動が、最終的な成果やアウトプットに直接関与せず、それを実現するためのプロセスや環境を整備する役割を果たす場合を指す 開発においては、下記のようになります。 項目 直接的な結果 間接的な結果 対象 成果物などアウトプット プロセスや環境 影響の範囲 短期的で即時的 長期的で持続的 測定のしやすさ 測定可能（例：完成した機能の数） 測定が難しい（例：チームの生産性） 成果との距離 成果に直接結びつく 成果を間接的に支える SMはどちらの結果に向き合うべきでしょうか。 その答えはどちらか一方ではなく、アジャイルソフトウェア開発宣言のように「左記の結果を求めながら右記の結果に重きを置く」と考えています。 スクラムガイドでは、「スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす」とあります。これはスクラムチームに対して、間接的な結果および責任を果たすことに向き合うことを意味します。 しかし、SMは直接的な結果について完全に無関心でいることはできません。直接的な結果（品質、納期、成果物など）は、間接的な責任を果たす上での重要な指標であり、SMが仕事を効果的に遂行するためには、直接的な結果にどのように影響を与えるかを理解し、それを考慮する必要があります。 スクラムマスターがプロジェクトマネジメントを学ぶ必要性について SMはチームが自律的に活動していけるように、「皆さんはどうしたいですか？」を問う姿が多く見られます。 しかし、チームに問いかけ続けていれば全て問題なく進められるかというと、そうではありません。 チーム内で補える観点や知見に基づいてチーム内で考えることもできますが、それ以上の観点や知識はティーチングを主要なメタスキルとするSMが補う必要があります。 （ラーメンを構成する各材料の作り方をチームが知っていても、合わせて「美味しいラーメン」という成果物にする方法を知らなければ、想定よりもぬるかったり美味しくないラーメンができてしまうイメージ） SMがプロダクト開発に紐づく全てのことをティーチングできれば良いのですが、スクラムガイドやスクラム・アジャイルに関する知見のみでは難しいです。 スクラムガイドはスクラムを定義しており、スクラムは軽量級のフレームワークです。スクラムガイド自体も目次や用語集などを含めて全17ページ程度の少ないボリュームです。 スクラムにおける重要な情報が厳選され、抽象化して記載されていて、プロダクト開発をチームで進める上で必要な考え方や観点を全て網羅しているわけではありません。 そこで、比較的SMにとって親和性が高く、知っておくと活用しやすい知識は「プロジェクトマネジメント」だと考えています。 理由はシンプルに、「そのプロダクト開発は、いつ・どうなったら終わりなのか？」という説明責任をSMにも果たしてほしいからです。 チームが自己管理できるよう、チームの自律性を高めることを主軸にして意識していくSMだからこそ、上記の質問には答えられる必要があると考えています。 チームが自分たちで考えられる環境を求めていく一方で、チームに対してティーチングとコーチングを適切に行っていくためには、SM自身がプロダクト開発の完遂に対して必要な知見と考え方を自分で説明できるようになっていてほしいです。 そうでないと、プロダクト開発およびプロジェクトを前に進めるための適切なWhyの説明ができず、チームにとってひたすら自身の思い浮かぶプラクティスを推進しようとする人になってしまうのでしょう…（経験談） プロジェクトマネジメントから得られる観点を取り入れて知的創造を果たす 「そのプロダクト開発は、いつ・どうなったら終わりなのか？」という説明責任を果たすことは、一つのリーダーシップの体現です。 これはモノづくりをする上で行う2つの創造：知的創造と物的創造のうちの知的創造に該当します。 書籍： スティーブン・R.コヴィー『完訳 7つの習慣 人格主義の回復』（キングベアー出版） p.155 第二部「私的成功」第2の習慣「終わりを思い描くことから始める」より 簡単に説明すると、物的創造は定められた方向に向かって限られたリソースを活用し効率よく業務を遂行するための活動、つまりマネジメントと実行責任の完遂を意味します。 一方、知的創造は組織が向かう方向を定め、「終わりを思い描く」「ゴールを決める」活動となります。つまり、リーダーシップとそれに伴う説明責任の完遂です。 （ここでいう「終わり／ゴール」には抽象的なビジョンやミッションではなく、プロダクト開発のゴール、プロジェクトの終わりを当てはめています） プロダクト開発のSMが示す一つのリーダーシップであり、「自身が先導し、チームがゴールへ到達することを導くリーダー」に求められます。 では、どうやったらプロダクト開発における「終わりを思い描く」「ゴールを決める」という知的創造を果たすことができるのか？ そのための一つとして、「プロジェクトマネジメントを学ぶ」を私はおすすめしているのです。 プロジェクトマネジメントのすべてをここで紹介するのは非常に大変なので、知っておくと良い点として一つ挙げるとPMBOK第6版に記載されている「10の知識エリア」があります。 注：PMBOKは2021年に第7版が出版されています。第6版では日本語版で約780ページあったものが、第7版では約370ページになっています。また、内容としてもプロジェクトマネジメントの手順をまとめたものから、プロジェクトの方針や考え方といった原理・原則をメインにした構成になっています。今回は、観点として具体的に分かりやすくリストアップされている第6版の内容を記載します。 10の知識エリア プロジェクト統合マネジメント プロジェクトやフェーズをどのように進めるのかを定義する知識エリア プロジェクト・スコープ・マネジメント プロジェクトやフェーズにおける作業範囲や、成果物の設定に関して定義する知識エリア プロジェクト・スケジュール・マネジメント 納期管理に関する知識エリア プロジェクト・コスト・マネジメント プロジェクトで承認された予算に関する知識エリア プロジェクト・品質・マネジメント 生成される成果物やプロジェクトの品質に関する知識エリア プロジェクト・資源・マネジメント メンバーなどの人的資源や、物的資源などの管理に関する知識エリア プロジェクト・コミュニケーション・マネジメント 会議予定を調整し、適切にコミュニケーション内容や方法を管理する知識エリア プロジェクト・リスク・マネジメント プロジェクトにおけるリスクの特定・分析・対応方法、対応策の実行、リスク監視に関する知識エリア プロジェクト・調達・マネジメント 契約終結やベンダーの管理に関する知識エリア プロジェクト・ステークホルダー・マネジメント ステークホルダーの関与度の定義や管理に関する知識エリア すべてを満遍なく検討してマネジメントしましょう、というわけではありません。 ただ、これらの項目について考えてみることで、プロダクト開発をスクラムで行おうとしている現場において、スクラムガイドに記載されていない観点を補うことができると考えます。 例えば、プロジェクト・ステークホルダー・マネジメント。スクラムガイドでは、「ステークホルダー」が誰なのかをはっきりと定義していません。それはプロダクト開発におけるステークホルダーは多く存在しますし、それぞれのステークホルダーに対しての期待や重要度は常に一定ではないからでしょう。 そのため個々のプロジェクトにおいては、チームが関わるステークホルダーは誰なのかを明確にし、ステークホルダーとの関わり方を定義しないと、チームの動き方や目指すことは容易にぶれてしまいます。 ステークホルダーマネジメントでよく見るのは、影響度合いと関心度合いを2次元で表現した次の図です。 ここに、チームが関わるプロダクト開発において関連するステークホルダーを配置します。 そうすることで、ステークホルダーの洗い出しと対応方針をチームで見える化し、透明性を高めることができます。 さらに、ステークホルダーに対しての具体的な関わり方を定義していくことで、プロジェクト・コミュニケーション・マネジメント（どのような場で何を議論すれば良いのかを定義し、チームにとって必要なコミュニケーションを適切に管理する知識エリア）の一部を満たすことができます。 また、チームの中からは意識しづらいが、じつは重要なステークホルダーも存在します（例えばCTOやCPOなど予算を握っている人やチーム）。そのようなステークホルダーに対しても意識を向ける視座をSMが獲得していて、チームに気づかせることができれば、必要な報告などを行うことができるようになり、急なプロジェクトの方向転換の回避などリスクマネジメントにつながる可能性もあります。 それは、SMの支援に記載されている項目の一つ、「スクラムチームの進捗を妨げる障害物を排除するように働きかける」という項目に該当します。 このように、プロジェクトマネジメントの要素を知り、観点として身につけていくことで「スクラムガイドには記載されていないが、プロダクト開発を行う上で知っておくべきこと」を補えるようになります。 そしてその知識を活用し、チームが向き合う開発が「いつ・どのように終わるのか？」をSMなりに考え、チームに適切なティーチングを行いつつ、プロダクト開発にとって必要なことをチームで考えていける環境を作ることがSMのリーダーシップの体現だと私は思います。 最後に プロダクト開発において、知っておかないといけないこと、チームで話した方がよいことはとても多いです。チームがそのすべてを足並み揃えて一つずつ学び、ディスカッションを行い意思決定できると、チームにとって学びを多く得られて良いのかもしれませんが、プロダクト開発という点においては、その動きが最適とは限らない状況もあります。 そのため、プロダクト開発を進める上で必要な様々なことに優先順位をつけて考え、その上でスクラムの理論とプラクティスを無理なくチームに適用し、徐々にチームの自律性を高めつつ、時には自分がプロダクト開発をリードしていけるSMでありたいです。 以上、約2年間で考えていた自分のSM像を少し言語化してみました！ SMのあり方に正解はありませんが、一つのイメージとして誰かの参考になればいいなと思っています。 それでは、私の Timee Advent Calendar 2024 Day 6は終わりとなります。 明日は、SMのしほりんさんのターンですので、お楽しみに！

この記事は Timee Advent Calendar 2024 シリーズ 1 の5日目の記事です。 はじめに こんにちは。タイミーの DRE チームの chanyou です。2024年の3月に DRE チームにジョインして、社内のデータ基盤を作って運用しています。 DuckDB を使ってデータ基盤で扱うデータの品質を保証し始めたので、その内容をご紹介します。 データ品質と完全性 タイミーのデータ基盤で重視しているデータ品質 タイミーでは、DMBOK を参考に以下のデータ品質を重視して設計や日々の運用を行っています。  特性 意味 完全性 データが欠損していないか 適時性 必要なときにすぐにデータを参照できるか 一意性 データが重複していないか 一貫性 型・タイムゾーン・表記揺れなど、値の書式や意味が統一されているか 今回は完全性にフォーカスします。 完全性が損なわれるタイミング 上記の通り、完全性とは「どの程度データに欠損があるか」を意味します。 データの欠損は、主にデータ転送時に生じる場合が多いです。例えば、以下のようなケースが考えられます。 あるテーブルが転送対象から外れてしまっていた 転送元のシステムに追加されたカラムが対象に含まれていなかった パーティション分割された Parquet ファイルのうち、一部のファイルしか転送できていなかった 従来の完全性テストの実施方法 完全性を保証するということは、欠損がないことを保証することと同義です。欠損が生じやすい転送前後のデータを比較することで、欠損の有無を検知できます。 欠損を検知する仕組みのことを、タイミーでは「完全性テスト」と呼んでいます。 表形式のデータに対して厳密に完全性テストを実施するには、セル単位で比較を行う必要があります。 これまでは計算コストがかかるため、統計量を比較する手法を取っていました。 近似的に比較していたため、全レコード全カラムに対して欠損が全くないことを厳密に保証できない課題がありました。 詳細は 昨年のアドベントカレンダー記事 をご覧いただければ幸いです。 刷新した完全性テストの実施方法 今回のケース 刷新のきっかけとなったケースについて説明します。 S3 にある Parquet ファイルを BigQuery にロードする、非常にシンプルなケースでした。 S3 の Parquet ファイルと転送後の BigQuery テーブルのデータが完全に一致することを保証する必要がありました。 Parquet ファイルと BigQuery のデータ比較のためにスクリプトを実装しました。その内部のクエリエンジンとして DuckDB を採用して、セル単位の厳密なデータの比較に対応しました。 DuckDB を採用した理由 BigQuery 内のテーブル同士であれば BigQuery のクエリで完結しますが、データベースをまたいだ完全性テストは BigQuery の外側でデータの比較をする必要があります。 DuckDB は高いパフォーマンスを維持しながら、複数のデータソースに対して同様にクエリをかけることが可能で、今回のケースに非常にマッチしていました。 データの比較も EXCEPT 句が利用可能で、簡潔なクエリで表現可能でした。 他の選択肢として Pandas や Polers などの DataFrame インターフェイスのツールも候補に挙がりますが、依存モジュールのメンテナンスコストが一定かかるため、今回のケースではシングルバイナリでより手軽に実行環境を整備しやすい DuckDB に軍配が上がりました。 以上の理由で DuckDB を採用しました。 具体的な実装方針 S3 の Parquet ファイルの読み込みについては DuckDB が標準で対応しているため、DuckDB の read_parquet() 関数で簡単に読み込むことができます。 BigQuery に対するクエリは、後述の理由により BigQuery から GCS に Parquet ファイルとして出力を行い、 GCS の Parquet ファイルを DuckDB から読み込むことで対応しました。 DuckDB の EXCEPT 句を使って、片方のテーブルにしか存在しないレコードを抽出するクエリを実行します。以下がクエリの例です。 WITH source AS ( SELECT * FROM read_parquet(getenv( ' source_path ' )) ORDER BY id ), destination AS ( SELECT * FROM read_parquet(getenv( ' destination_path ' )) ORDER BY id ) SELECT ' source ' AS _location, *, FROM ( SELECT * FROM source EXCEPT SELECT * FROM destination ) UNION ALL SELECT ' destination ' AS _location, *, FROM ( SELECT * FROM destination EXCEPT SELECT * FROM source ); source だけあるレコードと destination だけにあるレコードを抽出して、連結して出力しています。 事前に DuckDB の Secret Manager で各クラウドリソースへの認証情報を設定する必要がありますが、それだけで上記のようなクエリでセル単位の厳密な完全性テストが可能となりました。 これらを実行するシェルスクリプトを実装して、Docker コンテナにまとめて実行環境に展開しました。 よかったところ 複数のデータソースに対するクエリが、非常に簡単に実行できた ローカル、S3、 GCS のどこにデータがあっても、 read_parquet() で読み込めるのは非常に体験がよかったです。 パフォーマンスが高く安定して実行できた 従来の完全性テストから実行環境が変わったため実行時間の比較ができないのですが、刷新後は 100GB 程度の Parquet ファイルの完全性テストが IO 含めて10分以内に実行できています。 デイリー程度の転送頻度であれば毎回実行しても差し支えない実行時間で、全く問題ありませんでした。 詰まったところや工夫したところ BigQuery Community Extension で読み取れないカラムがあった 当初 DuckDB の BigQuery Community Extension を使って、BigQuery に直接クエリを実行しようとしていました。 大半のデータには問題なく使えたのですが、一部の文字列型のフィールドで読み取れないカラムがありました。 エラーメッセージがなく、読み取れなかったカラムが ORDER BY で結果の順序を変えると読み取れることがあるなど、原因特定から難航しそうなので今回のケースでは Community Extension の使用は見送りました。 BigQuery 側のログではちゃんとクエリが走っていたので、 DuckDB での処理のどこかでコケてしまっていたようでした。時間があるときに内部実装を追って、修正できそうであれば PR を送りたいと思います。 jsonlines モードと jq の組み合わせが楽だった DuckDB には csv, json, html などの 出力形式 が多数あります。 今回はシェルスクリプトで DuckDB の結果を扱いたかったため、 jsonlines で出力したうえで jq で結果を処理するのが簡単でした。 柔軟に出力を切り替えられるので、あらゆるスクリプトで利用しやすいと思います。 まとめ 完全性テストを DuckDB を使って実施する内容をご紹介しました。DuckDB を使うことで、手軽にマルチクラウドな環境においても厳密な完全性テストを行えました。 DuckDB は非常に魅力的ですが、分析用途での DuckDB はガバナンスを効かせながら運用することが難しく、現状は社内で広く使ってもらうには様々なハードルがあるように思います。 一方で今回のデータテストのように、スクリプトの内部で利用するには統制を取りやすく、非常に相性がよいように感じました。分析用途の場合は DuckDB のステートを同期し続ける必要がありますが、テストの場合は同期が不要で揮発しても問題なく、カジュアルに DuckDB を使いやすかったです。 またシングルバイナリで環境整備も非常に簡単な点も運用しやすく、他のデータテストでも機会があれば利用を検討したいと思いました。 他にも dbt で CI 実行するときに、 DuckDB アダプタに切り替えることでコストを圧縮できそうです。 CI やスクリプト用途における DuckDB の活用の余地がまだまだありそうで、今後も模索したいと思いました。

こんにちは！タイミーでAndroidエンジニアとして働いている   @orerus  ことmurataです。今回は弊社のアプリ開発チームで経験した、Firebase Remote Config（以下 RemoteConfig）を使用したABテスト実装時のトラブルと、その再発防止策について共有いたします。 はじめに モバイルアプリ開発において、ABテストは機能改善の効果を測定する上で重要な手法の一つです。今回は、私たちが実装したABテストで発生した予期せぬ動作と、そこから学んだ教訓についてお話しします。 おことわり なお、今回の話はRemoteConfing自体に問題があるというものではなく、使用方法が適切でなかった為に発生した事象ですのでご留意ください！ 発生した事象 実装内容 今回の事象のきっかけとなったのは、アプリ起動時にまず表示される「さがす画面」において、検索結果のソート順切り替え機能のABテストの実装でした。 リリース後は何事も問題なく動作していたのですが、しばらく経ったある特定のタイミングで同時に複数の不具合報告が挙がりました。 報告が挙がった不具合内容は「ソート順がおかしい」「検索結果が表示されない」といった事象でした。 以下は、実際に不具合が発生していた時の画面の例です。 アプリを開いた直後に表示される一番大事な検索結果の部分が空っぽになってしまっていますね・・・。 問題の具体に入る前に、ここでこの「さがす」画面の構成について簡単に説明します。 画面構成 こちらの画面の構成としては、画面上部のカレンダーを含む画面全体、および画面下部の検索結果が表示されている部分とで異なるFragmentが使用されています。（前者をCalendarFragment、後者をResultFragmentと仮称します） 検索結果を表示するResultFragmentは日付ごとに存在しており、ViewPagerにて管理しています。 カレンダーから日付が選択されると、その日付の検索結果を表示するためのResultFragmentが生成され表示されます。 ABテスト制御 ABテストの制御にはRemoteConfigを使用しており、CalendarFragment、ResultFragment、それぞれのFragmentが生成されるタイミングでRemoteConfigからソート機能のON/OFFのConfig値をそれぞれのFragment内に保持して使用しています。 不具合発生！！！ 平穏に暮らしていた中で突如同時多発的に不具合報告が挙がったタイミング、それがABテストのロールアウトを行った時でした。 この時は全ユーザーに対してソート順切り替え機能をONにするロールアウトを行いました。 その結果、先述した「ソート順がおかしい」「検索結果が表示されない」といった不具合が複数のユーザーから報告されました。 もちろんすぐに原因調査を行いましたが、手元の環境では事象がなかなか再現せず困っていたところ、ABテストのロールアウトを行っていたことを思い出しRemoteConfigから取得したConfig値の利用箇所周りを重点的に調査した結果、その利用方法に問題があり先述のような不具合が発生する可能性があることが判明しました。 以下、その不具合発生に至った原因について解説します。 原因分析 1. RemoteConfigから取得したConfig値をFragment毎にキャッシュしていた 画面が破棄されるまでの間にConfig値が変化したとしても突然画面内で機能が変化しないように、Fragment生成時にRemoteConfigからConfig値を取得し、インスタンス変数にキャッシュしていました。 このキャッシュのやり方は画面内で1箇所のみでしか行われない場合には問題が生じませんが、画面内に複数のFragmentがある場合に不整合を生じさせる余地が発生してしまいます。 とはいえ、それだけなら不整合が発生する確率は低かったのですが、次の原因がその確率を大きく引き上げてしまいました。 2. Fragmentの生成タイミングの違い 先述した通り、この画面には複数のFragmentが存在しており、またそれぞれ生成タイミングが異なります。 CalendarFragment 「さがす画面」が表示されたタイミングで生成される ResultFragment 日付が選択されたタイミングで生成される この生成タイミングの違いにより、現実的に起こり得るケース（例えば「さがす画面」のままアプリが長時間バックグラウンドになっており、復帰後に日付が再選択されたケースなど）でCalendarFragmentおよび複数日付のResultFragmentの間でConfig値に不整合が発生してしまいました。 細かなロジックは省略しますが、この不整合が引き金となり冒頭で紹介したような不具合が発生していました。 なお、今回の事象が防げなかった原因がもう一つあります。 3. QAカバレッジの不足 今回のABテストについてももちろんQAを行っていたのですが、以下の観点が意識されておらずテストケースから見落とされてしまっていました。 アプリ起動中のRemoteConfigの値更新 Config値を複数箇所で保持することによるFragment再生成時の不整合発生の可能性 一度起きてしまえば「何故気づかなかったのだろう」と思えるようなシンプルな原因ではあるのですが、「画面が破棄されるまでは同じConfig値が使われる」という思い込みが気づきを遠ざけてしまっていました。 再発防止策 再発防止策として以下の取り組みを実施しました。 1. QAプロセスの改善 QAチェックリストのテンプレートに、RemoteConfigを用いたABテストやFeatureFlagの実装時はアプリを生存させたまま値を動的に更新するテストケースを実施する旨を追加しました。 2. RemoteConfigに関するデバッグ機能の拡充 RemoteConfigは内部でキャッシュされており、先述の動的なConfig値の更新のQAを行うことが困難であった為、デバッグ時にConfig値を容易に変更できる機能を実装しました。 3. ActivityやFragmentでのConfig値のキャッシュを止める こちらは今後の話になりますが、ActivityやFragmentでConfig値をキャッシュすると類似の問題が発生する可能性がある為、画面（または一連の機能）を構成する単位で必ず同一箇所のConfig値のキャッシュを参照するような構成への変更を検討しています。例えば、画面（または一連の機能）から参照される共通のViewModel内でのキャッシュを考えています。 なお、アプリの起動中は全てのConfig値が変化しないようにするという選択肢も考えられますが、FeatureFlag管理にもRemoteConfigを利用しており、Config値の変更は可能な限り速やかに行いたい（将来的にFirebase Realtime RemoteConfigへの置き換えも視野に入れている）為、そちらの選択肢は選択しませんでした。 まとめ 今回の経験から、以下の教訓を得ることができました。 画面または一連の機能（整合性を保ちたい単位）で必ず同一箇所のConfig値のキャッシュを参照するようにする 例えば共通のViewModel内でのキャッシュなど RemoteConfigから取得する値は変化するものという前提のうえでQAを行う RemoteConfigは非常に便利な機能ですが、適切な実装と十分なQAがないと思わぬ落とし穴に遭遇する可能性があります。今回の紹介で、自分と同じような体験をしてしまう方を少しでも減らすことができれば幸いです・・・！ 皆様安心安全な状態でクリスマスや年末を迎えましょう！

はじめに この記事は Timee Advent Calendar エンジニアリングパート 3日目 担当は Android Chapter の tick-taku です。 来月でタイミーに入社して1年になります。Rails など新しいことにチャレンジしたり DroidKaigi や RubyKaigi など様々なカンファレンスに参加させてもらったりと濃い体験をさせてもらえて、この1年長かったような短かったようなという不思議な気持ちです。 1年間何やったかなと振り返ってみて Hilt やデザインシステムの導入など開発の基盤となることをメインにやっていたな〜と思ったので、この記事では入社直後からやっていた開発における自動化や仕組み作りの一環としてリリースワークフローを整えた話を実装ベースで紹介します。 リリース作業の自動化 タイミーの Android Chapter はこの1年でチームメンバーが3人から8人に増加しました。（嬉しい） メンバーが増加するにあたって追い風となる反面、手作業で行っていたタスクも多くメンバー間で迷いなくスピーディに実行できるよう効率化する「レール」を敷く必要があると感じ、仕組み作り・自動化に取り組みました。 タイミーではストリームアラインドチームを採用しており基本的に Android エンジニアは各チームに散らばっています。その中でも1スプリントを1週間としているチームも多く、スプリント終了後にリリースを行うルールを採用しています。リリースサイクルが短いためリリース作業も頻繁に発生しており、バイナリ作成など一部 Bitrise で自動化されているものもありましたが基本的には以下のような作業を毎週繰り返していました。 リリース用のブランチ作成、アプリバージョンの変更・コミットなどの事前準備 リリース作業を行う PullRequest (以下、PR) を作成 リリース PR 上でのバイナリの作成・ストアへのアップロードタスクの実行と動作検証 「Next Release」マイルストーンに紐づくPRを目視で確認し、リンクをリリースPRの description や GitHub Releases に記載 各実装 PR に対してマージするタイミングで「Next Release」のマイルストーンを手動でアサイン これらをその週のリリース担当者（ランダムで選出）が作業 そこでこれらを一部自動化する Workflow を作成し、リリース作業の効率化を図りました。その Workflow を紹介する前に、前提となる運用やスクリプトについて紹介します。 GitHub CLI 始めに頻出する GitHub CLI を紹介しておきます。 個人的には一番お世話になっているツールです。そもそも Git 操作を CLI で行うので、その延長で GitHub 上の様々な操作をコマンドで実行できるため非常に便利です。 GitHub CLI 基本的に PR の作成や CI のステータス確認などは GitHub CLI を利用しています。 コードレビューに関してだけはビジュアライズされている方が理解が速いので Web で確認していますが、それも GitHub CLI から見たい PR をブラウザで開くことができるので捗ります。 GitHub Actions においても基本的にはランナーにインストールされており token も secrets に用意されているので利用するハードルも低く相性もいいです。今回も GitHub 上の操作を自動化するために多用しています。 リリース PR の自動作成 まずリリース作業用の PR を自動で作成するスクリプトを用意しました。 #!/bin/bash new_version = " $1 " # リリースに含まれる PR をリストアップ # クローズされた PR のリストから次のリリースの対象となる Milestone にアサインされたものをフィルタリングします release_title = " Release ${new_version} " pr_numbers = $( gh pr list -s closed -L 100 --json " milestone,number,labels " -q " [.[] | select(.milestone.title == \\ " ${release_title} \\ " )] " ) updates = $( echo " $pr_numbers " | jq -r ' { feature_updates: [.[] | select(.labels[].name == "Update") | .number], bug_fixes: [.[] | select(.labels[].name == "BugFix") | .number], development_updates: [.[] | select(.labels[].name == "DevelopmentUpdate") | .number], others: [.[] | select(all(.labels[].name; . != "Update" and . != "BugFix" and . != "DevelopmentUpdate")) | .number], } ' ) updates_body = $( echo " $updates " | jq -r ' "## Updates", (.feature_updates | map("- #" + tostring) | join("\\n")), "## Bug Fix", (.bug_fixes | map("- #" + tostring) | join("\\n")), "## Development Updates", (.development_updates | map("- #" + tostring) | join("\\n")), "## Others", (.others | map("- #" + tostring) | join("\\n")) ' ) pr_body = """ # $release_title ## Release Note \\`\\` \\ ` $( cat releasenotes/whatsnew-ja-JP ) \\` \\ `\\` $updates_body """ gh pr create \\ -B master \\ -t " $release_title " \\ -m " $release_title " \\ -b " $pr_body " \\ -l " Release " ストアに申請する際のリリースノートも description 上で確認できるようにしています。 実装 PR の分類とラベルによる自動化 タイミーでは内部へのリリースお知らせなどのために、リリース作業時に各PRを FeatureUpdate や BugFix などに分類して description に記載しています。 以前はリリース担当者が手動で振り分け作業を行っていましたが、これが大きな負担となっていました。 そこで PR 作成時に実装者が Update などのラベルをつけることでどれがどの分類なのか自動で振り分けるようにしました。それが上記のスクリプトの updates_body 作成の部分です。 また、手動でラベルをアサインするのも手間なので feature/update/ なら Update ラベルを追加するなど branch 名で自動で付与されるようにもしています。 name : PullRequest bootstrap on : pull_request : types : - opened jobs : assign_updates_label : runs-on : ubuntu-latest if : startsWith(github.head_ref, 'feature' ) env : PR_NUMBER : ${{ github.event.pull_request.number }} GITHUB_TOKEN : ${{ secrets.GITHUB_TOKEN }} steps : - uses : actions/checkout@v4 - name : Assign Update label if : startsWith(github.head_ref, 'feature/update/' ) run : | gh pr edit $PR_NUMBER --add-label "Update" - name : Assign Update label if : startsWith(github.head_ref, 'feature/bugfix/' ) run : | gh pr edit $PR_NUMBER --add-label "BugFix" - name : Assign Update label if : startsWith(github.head_ref, 'feature/development/' ) || startsWith(github.head_ref, 'feature/development_update/' ) run : | gh pr edit $PR_NUMBER --add-label "DevelopmentUpdate" バージョン管理の改善とアップデートコミットの自動化 以前は Gradle の config 内で直接アプリバージョンを管理しており、リリースのたびに build.gradle に差分が生じていました。 gradle には他にも様々なアプリのコアとなる記述があり、頻繁に gradle を触るのも嫌ですがさらに自動で差分を更新しコミットするのもハードルが高そうです。 これを改善するため、入社時のオンボーディングタスクとしてちょうど VersionCatalog を導入したこともあり、バージョン情報を toml ファイルで管理しました。 [versions] versionMajor = "1" versionMinor = "0" versionPatch = "0" versionOffset = "0" def versionMajor = libs.versions.versionMajor.get(). toInteger () def versionMinor = libs.versions.versionMinor.get(). toInteger () def versionPatch = libs.versions.versionPatch.get(). toInteger () def versionOffset = libs.versions.versionOffset.get(). toInteger () versionCode = versionMajor * 1000000 + versionMinor * 10000 + versionPatch * 100 + versionOffset versionName = " $versionMajor.$versionMinor.$versionPatch " そして toml ファイル内の各バージョンを入力値に更新するスクリプトを用意します。 #!/bin/bash libs_file_path = " gradle/libs.versions.toml " version = " $1 " versions = (${version // . / }) sed -i -e " /versionMajor/s/.*/versionMajor = \\ " ${versions[ 0 ]} \\ "/g " $libs_file_path sed -i -e " /versionMinor/s/.*/versionMinor = \\" ${versions[ 1 ]} \\ "/g " $libs_file_path sed -i -e " /versionPatch/s/.*/versionPatch = \\" ${versions[ 2 ]} \\ "/g " $libs_file_path sed -i -e " /versionOffset/s/.*/versionOffset = \\" ${versions[ 3 ]} \\ "/g " $libs_file_path rm -rf " $libs_file_path -e " これを Workflow 内で実行することでアプリバージョンのアップデート作業を自動化しました。 sed でなんとでもなると昔から教わってきたので使いがちですが、余計なファイルが出来たりもするしあんまりイケてないのではと最近気付きはじめました... QA の運用について タイミーでは PR ごとに QA チェックリストを記載し動作検証を行っています。以前はチェックリストを PR の description に直接記載して PR 単位の動作検証を行っていました。 しかしリリース時の QA でもそれを見ながら検証していたので QA の度に該当の PR を見に行く必要がありました。 非常に手間がかかってしまうので、QA を Notion のデータベースで一元管理しページ内にチェックリストを記載する運用を導入しました。 Milestone が Release となっているものがリリース時の QA 作業対象となっており、リリース時には Notion を参照するだけでQA作業を進められるようになっています。イメージはこんな感じ。 ただし PR 作成時に Notion にわざわざ移動してページを作成するのも大変だったり忘れたりするので、PR が作成されると QA ページを自動で作成し URL を PR にコメントするようにしています。 Notion API によるクエリの実装は こちらを参考に させていただきました。 #!/bin/bash pr_number = " $1 " # 既に同じ number のページが存在する場合は処理を終わらせる page_id = $( curl -X POST ' <https://api.notion.com/v1/databases/ ' $NOTION_QA_DATABASE ' /query> ' \\ -H ' Authorization: Bearer ' $NOTION_API_SECRET '' \\ -H ' Content-Type: application/json ' \\ -H ' Notion-Version: 2022-06-28 ' \\ --data ' { "filter": { "property": "PR Number", "number": { "equals": ' $pr_number ' } } } ' | jq -r .results [ 0 ] .id ) if [ $page_id != ' null ' ]; then exit 0 fi pr = $( gh pr view $pr_number --json " title,milestone,url " ) # PR のメタデータを元に QA ページを作成 title = ' "title": [ { "text": { "content": " ' $( echo " $pr " | jq -r .title ) ' " } } ] ' data = ' { "parent": { "database_id": " ' $NOTION_QA_DATABASE ' " }, "properties": { "Title": { ' $title ' }, "PR Number": { "number": ' $pr_number ' }, "PR": { "url": " ' $( echo " $pr " | jq -r .url ) ' " } } } ' qa_url = $( curl -X POST ' <https://api.notion.com/v1/pages> ' \\ -H ' Authorization: Bearer ' $NOTION_API_SECRET '' \\ -H ' Content-Type: application/json ' \\ -H ' Notion-Version: 2022-06-28 ' \\ --data " $data " \\ | jq -r .url ) # 作成できた QA ページの URL を PR にコメント gh pr comment $pr_number -b """ ## Make QA :memo: $qa_url """ PR 作成時にスクリプトが走るよう Workflow を作成します。 タイミーでは branch の名前で自動化運用しているものもあり、特定の branch の場合は必要ないので走らせないようにしています。 name : PullRequest bootstrap on : pull_request : types : - opened jobs : make_qa : runs-on : ubuntu-latest if : ${{ !startsWith(github.head_ref , 'release' ) && !startsWith(github.head_ref , 'ladr' ) && github.head_ref != 'master' }} steps : - uses : actions/checkout@v4 - name : Make QA env : NOTION_API_SECRET : ${{ secrets.NOTION_API_SECRET }} NOTION_QA_DATABASE : ${{ secrets.NOTION_QA_DATABASE }} GITHUB_TOKEN : ${{ secrets.GITHUB_TOKEN }} run : | ./.github/script/post_qa.sh ${{ github.event.pull_request.number }} 実装 PR がマージされたら Milestone をアサインする 上述しましたが、タイミーではリリースの差分を把握するために Milestone を利用しています。 なので PR を develop にマージしたら Next Release の Milestone をアサインする必要がありました。 が、これが結構忘れます。なのでリリース作業時に「あれ？これリリースの対象では...?」といった確認を慎重に行う必要があったりとりこぼしが発生したりと、精神的負荷が高い状態でした。 それを解決するために PR がマージされたらその PR に Milestone をアサインする Workflow を用意しました。同時に QA もリリースの対象として可視化されるように Milestone を変更します。すでに Milestone が付いている場合は実行しないようにしています。 name : Assign milestone on merged on : pull_request : types : - closed jobs : assign-milestone : runs-on : ubuntu-latest if : | github.event.pull_request.merged == true && !github.event.pull_request.milestone env : GITHUB_TOKEN : ${{ secrets.GITHUB_TOKEN }} PR_NUMBER : ${{ github.event.pull_request.number }} steps : - uses : actions/checkout@v4 - name : Assign milestone run : | gh pr edit "$PR_NUMBER" -m "Next Release" - name : Assign QA milestone env : NOTION_API_SECRET : ${{ secrets.NOTION_API_SECRET }} NOTION_QA_DATABASE : ${{ secrets.NOTION_QA_DATABASE }} run : | ./.github/script/update_qa_milestone.sh "$PR_NUMBER" #!/bin/bash pr_number = " $1 " page_id = $( curl -X POST ' <https://api.notion.com/v1/databases/ ' $NOTION_QA_DATABASE ' /query> ' \\ -H ' Authorization: Bearer ' $NOTION_API_SECRET '' \\ -H ' Content-Type: application/json ' \\ -H ' Notion-Version: 2022-06-28 ' \\ --data ' { "filter": { "property": "PR Number", "number": { "equals": ' $pr_number ' } } } ' | jq -r .results [ 0 ] .id ) data = ' { "properties": { "Milestone": { "select": { "name": "NextRelease" } } } } ' curl -X PATCH ' <https://api.notion.com/v1/pages/ ' $page_id ' > ' \\ -H ' Authorization: Bearer ' $NOTION_API_SECRET '' \\ -H ' Content-Type: application/json ' \\ -H ' Notion-Version: 2022-06-28 ' \\ --data " $data " リリース準備作業を実行する Workflow これらを含めリリース準備作業を実行する Workflow を用意します。 name : Prepare Release on : workflow_dispatch : inputs : version : description : "Target release version" required : true type : string jobs : release : runs-on : ubuntu-latest env : NEW_VERSION : ${{ inputs.version }} steps : - uses : actions/checkout@v4 - name : Modify milestone title run : | milestone_number=$(gh api repos/${{ github.repository }}/milestones -q ".[] | select(.title == \\ " Next Release\\") | .number") gh api repos/${{ github.repository }}/milestones/$milestone_number -X PATCH -F title="Release $NEW_VERSION" gh api repos/${{ github.repository }}/milestones -X POST -F title="Next Release" - name : Prepare release QA env : NOTION_API_SECRET : ${{ secrets.NOTION_API_SECRET }} NOTION_QA_DATABASE : ${{ secrets.NOTION_QA_DATABASE }} run : | ./.github/script/replace_qas_milestone.sh -t NextRelease -v Release - name : Make PullRequest uses : ./.github/actions/make_release_pull_request id : make_pr with : version : ${{ inputs.version }} github_token : ${{ secrets.GITHUB_TOKEN }} - name : Make release build uses : ./.github/actions/bitrise_upload_app with : pr_number : ${{ steps.make_pr.outputs.pr_number }} app_slug : ${{ secrets.APP_SLUG }} workflow_id : "upload-app-bundle-to-google-play-store" build_trigger_token : ${{ secrets.BUILD_TRIGGER_TOKEN }} github_token : ${{ secrets.GITHUB_TOKEN }} - name : Make app build uses : ./.github/actions/bitrise_upload_app with : pr_number : ${{ steps.make_pr.outputs.pr_number }} app_slug : ${{ secrets.APP_SLUG }} workflow_id : "upload-apk-firebase-app-distribution" build_trigger_token : ${{ secrets.BUILD_TRIGGER_TOKEN }} github_token : ${{ secrets.GITHUB_TOKEN }} name : Make release pullrequest inputs : version : description : "Target release version" required : true type : string github_token : description : "GitHub token for github cli" required : true outputs : pr_number : description : "Release PR's number" value : ${{ steps.make_pr.outputs.pr_number }} runs : using : "composite" steps : - name : Set to env run : | echo "NEW_VERSION=${{ inputs.version }}" >> $GITHUB_ENV echo "GITHUB_TOKEN=${{ inputs.github_token }}" >> $GITHUB_ENV shell : bash - name : Switch release branch run : | git switch -c "release/$NEW_VERSION" shell : bash - name : Increment version run : | ./.github/script/bump_version.sh "$NEW_VERSION" git config user.name "actions-user" git config user.email "action@github.com" git add . git commit -m "Bump version to $NEW_VERSION" git push origin $(git branch --show-current) shell : bash - name : Make Pull Request id : make_pr run : | ./.github/script/make_release_pr.sh "$NEW_VERSION" echo "pr_number=$(gh pr list -s open --json number,labels -q '[.[] | select(.labels.[].name == " Release")][ 0 ] | .number')" >> $GITHUB_OUTPUT shell : bash 簡単に各 step では、 Milestone のタイトルを Next Release から Release x.x.x に変更 し次のリリース用の Next Release Milestone を作成 Notion データベース上のリリース対象となる QA の Milestone を更新 してピックアップ リリース PR の作成 production のリリースバイナリを PlayStore の テストトラックにアップロード staging のデバッグバイナリを Firebase App Distribution にアップロード のようなことをやっています。 バイナリ作成のワークフローは既に Bitrise に CI が用意されておりそれを実行しています。 [!NOTE] Milestone を Next Release としているのは次のバージョンがいくつになるかリリース作業時に確定するためです。リリース作業中にバージョンを確定させ、gradle 内を更新し Milestone のタイトルを Release x.x.x のようなフォーマットに変更し次のリリース対象となる Next Release Milestone を作成します。 workflow_dispatch で次のバージョンを受け取るようにしており、GitHub Actions のタブから手動で実行することができます。 [!NOTE] 今回は長くなるので紹介していませんがリリース Workflow は通常用と hotfix でわけており、PR を作成するための step やアプリのビルドは共通で使い回すため Composite Action として切り分けています。 これで Workflow を実行すればリリース作業用の PR を勝手に作成してくれるようになり、今まで手動で時間をかけていた作業がボタンぽちーで終わるようになりました。 ちなみに GitHub CLI を利用していると以下のように実行できてとても便利です。 gh workflow run prepare_release.yml -f version=x.x.x お片づけ 最後にリリースした後についてです。 ストアにリリースし終えたら作業用 PR をマージします。その際に以下を実行する Workflow を用意しています。 GitHub Releases に該当バージョンのリリースを作成 master to develop の PR 作成 リリースしたマイルストーンのクローズ 検証した Notion の QA ページの Milestone を更新 name : Make Release on : pull_request : branches : - master types : [ closed ] jobs : release : if : github.event.pull_request.merged == true && contains(github.event.pull_request.title, 'Release' ) runs-on : ubuntu-latest env : GITHUB_TOKEN : ${{ secrets.GITHUB_TOKEN }} PR_NUMBER : "${{ github.event.number }}" steps : - uses : actions/checkout@v3 - name : Make Release run : | ./.github/script/make_release.sh "$PR_NUMBER" - name : Make Pull Request to develop run : | git switch master gh pr create -B develop -t "Master" -b "Merge master to develop" - name : Close milestone run : | milestone_number=$(gh pr view "$PR_NUMBER" --json "milestone" -q ".milestone.number" ) gh api repos/Taimee/taimee-android/milestones/$milestone_number -X PATCH -F state=closed - name : Update QA Milestone env : NOTION_API_SECRET : ${{ secrets.NOTION_API_SECRET }} NOTION_QA_DATABASE : ${{ secrets.NOTION_QA_DATABASE }} run : | version=$(gh pr view "$PR_NUMBER" --json "title" -q ".title" | awk 'match($0, /([0-9]+\\.[0-9]+\\.[0-9]+(\\.[0-9]+)?)/) {print substr($0, RSTART, RLENGTH)}' ) ./.github/script/replace_qas_milestone.sh -t Release -v $version [!NOTE] make_release のスクリプトは PR の description をそのまま GitHub Releases にコピペするだけですし、replace_qas_milestone は QA の Milestone をリリースしたバージョンのテキストに更新します。 最後に 以上がタイミー Android Chapter のリリース作業に利用している Workflow の紹介でした。 今まで手作業で30分〜1時間くらいかけて行っていたタスクが長くても10分以内には収まっていたり負担も減っていると感じています。 ただし、 - #PRNumber だけでタイトルを補完してくれるのは PR の中だけで GitHub Releases には番号しか見えてなかったりします。 またビルド関連は Bitrise で行っていて GitHub Actions から Bitrise の CI をトリガーする事が多いです。 Bitrise.io の QR からインストールできるのは非エンジニアがデモで触ってもらう際に非常に助かっているのですが、GitHub Actions の artifact で似たような事ができるなら費用面やパフォーマンス面を考慮して GitHub Actions に統一も検討できるといいかもしれません。 スクリプトがごり押しだったりまだまだ課題は残っていますし、もっと効率のいい運用がある気がしているのでメンバーのフィードバックを拾い上げて継続的に改善していきたいですね。 ぜひみなさんの オレの考えた最強のリリースワークフロー を教えてください！ 明日は我らが Android Chapter のリーダー、murata-san です！お楽しみに

このエントリは「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画面以上の機能開発、インフラの構築を含む新規アーキテクチャ構築など - まだストーリーポイントで見積もりする手法を実験中のため、これからの振り返りや次のスプリント計画にどのように役立つかを検証し、改善していきたいと考えています。新しい方法を試す中で、チーム全体の共通理解を深めながら、少しずつ改善を重ねています。 締めくくり 研修会場の中庭 スクラムを実践していく中で得られた一番の気づきは、「小さな改善の積み重ねが、チーム全体の成長に繋がる」ということです。今回受けた「アトラクタの認定スクラムマスター研修」は、理論を学ぶだけでなく、実際に手を動かしながら多くの気づきを得られる貴重な機会となりました。 ストーリーポイントの導入や見積もり基準の設定といった取り組みが、これからどのような成果に繋がるのか、さらに試行錯誤を続けていきたいと考えています！ この記事は自分自身にとっての振り返りの一環となりました。 スクラムを学び始めた方や、すでに実践している方の参考になれば幸いです！ それでは、みんなでより良いチーム作りを目指してがんばりましょう！

こんにちは、タイミーのデータアナリティクス部でデータアナリストをしているmihashiです。普段は主にタイミーのプロダクトに関する分析業務に従事しています。 今回は前期に社内で取り組んだデータ活用推進に関する事例を共有できればと思います。 前提 タイミーでは、全社のデータ利活用ツールとしてLookerを利用しています。これまでもより多くのメンバーにLookerを活用してもらうために、定期的に講習会を開催してきました（以下の記事も参照してください！） 社内向け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 というカンファレンスに参加したメンバーの内、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 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: true で UserRegistration モデルと 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

こんにちは！タイミーでデータアナリストをしているkantaと申します。 普段はマーケティングの皆様とCM施策やCRM関連の分析を担当したり、他部署向けの講習会を企画したりしております。11月から半年ほど育休を取得予定のため、育休前最後の仕事（？）として当ブログの執筆を担当いたします。 さて、今回は 「BigQuery + Looker Studioでt検定した話」 と題しまして、その方法をご紹介できればと思います。 なぜ BigQuery + Looker Studioでt検定をしたいのか？ BigQuery + Looker Studio でt検定する手順 1. UDFの作成 1-1. JavaScriptライブラリ「jStat」のダウンロード 1-2. 任意のGCSバケットにjstat.jsをアップロード 1-3. p値を算出するUDFの作成 1-4. t検定を実施するUDFの作成 2. クエリの作成 3. Looker Studioで可視化 3-1. Looker StudioのデータソースでBigQueryを選択 3-2. 先ほど作成したカスタムクエリを記述 3-3. 見た目を整えて完成！ BigQuery + Looker Studioでt検定した感想 We’re Hiring! なぜ 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_PROJECT ・ YOUR_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! 私たちは、ともに働くメンバーを募集しています！！ カジュアル面談 も行っていますので、少しでも興味がありましたら、気軽にご連絡ください。