フィクスチャのアーカイブ機能実装による業務改善

こんにちは、駅メモ！チームの id:charines です。今回は駅メモ！のデータ管理におけるフィクスチャ関連の改善の事例を通じて、駅メモ！チームの改善業務への取り組みを紹介します。

課題の背景と目的

駅メモ！ではゲームに必要なマスターデータをフィクスチャファイルとして管理しており、開発環境での書き出しと本番環境での読み込みによって日々データの更新を行なっています。しかしサービスも開始 10 年を超え、定期開催されるガチャやイベントを始めとしたデータが肥大化していき、フィクスチャの書き出しがタイムアウトするなど更新業務に支障をきたす場面が増えてきていました。

これを解決するために、今後更新予定のない古いデータをアーカイブし、読み書きの対象外とする実装を行いました。

実装

核となる実装はシンプルで、フィクスチャ管理に利用しているライブラリの処理に、管理対象のレコードを限定するような処理を追加しています。具体的には Perl のモジュール DBIx::Fixture::Admin のクラスを継承し、アーカイブ機能のための追加の実装を行いました。 DB 上のデータを取得する処理を含むプライベートメソッド _dump_yaml において、

+    my $active_record_conditions = $config->{active_record_conditions};
+    if (exists $active_record_conditions->{$schema}) {
+        $sql .= ' WHERE ' . $active_record_conditions->{$schema};
+    }
     my $rows = $dbh->selectall_arrayref( $sql, +{ Slice => +{} } );

のように config ファイルから取得した条件をクエリとして差し込むことで、アーカイブ範囲でないレコードのみが対象となるようにしています。

（クエリ文字列を直接連結しているためプロダクトに使うには安全でない実装ですが、今回は社内システム向けの実装なので簡易的なものにしています。）

config ファイルには

+{
    # `テーブル名 => 条件` の形で記載する
    active_record_conditions => +{
        # 10 と 25 は常設のガチャ
        gacha => '`id` >= 1234 OR `id` IN (10, 25)',
    },
}

のように、一定以上新しいものや常設されているガチャをクエリの形式で記載しています。

この実装によって、単純なフィクスチャファイルの書き出しでは最も重いテーブルで 7.0 秒ほどかかっていたものを 3.7 秒ほどに短縮し、より複雑な処理が伴う箇所では 10 分以上かかっていたものを数秒まで短縮することでタイムアウトの問題を解決できました。

駅メモ！チームにおける改善タスクへの取り組み

駅メモ！チームにおけるデータの更新はエンジニアよりもプランナーが中心に行うことも多く、今回の改善タスクもプランナーの困りごとを技術的に解決した例の一つでした。

このように駅メモ！チームではエンジニアでは気づきにくい業務改善を取りこぼさないようにするために、プランナーとエンジニアが一緒に参加する改善タスクを共有するための場を設けたり、時にはエンジニアが普段プランナーが行う業務を代わって行い、エンジニア視点でないと気づきにくい改善点を探すなどの取り組みをしています。

他にもプランナーの業務効率化をいつまでにどの程度達成するか具体的に目標を定めるなど、チームとして積極的にエンジニア以外が対象の業務改善も進めることで、よりスムーズにミスのないコンテンツを作成できるよう継続的に取り組んでいます。