皆さま、こんにちは！ 駅メモ！開発チームエンジニアの 
id:szeto です。
今回は、毎月行う報酬配布作業について、これまで行っていた本番環境のCLIでのスクリプト実行から、管理画面（運営が駅メモ！のゲーム設定を閲覧・更新できるシステム）の操作に変更した事例を皆さまに共有したいと思います。この取り組みのおかげで、運用効率が約66%改善されました！
これまでは本番サーバーにSSHでログインし、スクリプトを実行していましたが、Webブラウザから安全に、いくつかのクリックで操作できるように改善しました。この記事では、その背景、実装方法、そして得られた効果についてご紹介します。
目次
背景・当時の課題
駅メモ！では、特定のイベント形式にランキング要素があるため、イベント終了後に上位プレイヤーの皆さまへ報酬配布を行っています。従来、この作業は本番環境でエンジニアが直接CLIでスクリプト実行により実施していました。
従来の運用フロー
従来の作業フローは、ドキュメント作成から作業の見守り募集、DBバックアップ、本番サーバーのCLIでのスクリプト実行、ログ確認、告知作成まで、多くのステップと時間を要していました。
【改善前】本番サーバーのCLIでスクリプト実行
━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. ドキュメント管理サイトで手順書作成
2. 作業の見守り募集
3. DBスナップショット作成 (x3)
⏱️ 15分
━━━━━━━━━━━━━━━━━━━━━━━━━━━
↓
━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. 本番サーバーにSSH接続
5. CLIでのスクリプト実行 ⚠️ ヒューマンエラーリスク
$ script1 --dry-run
$ script2 --dry-run
6. 結果確認
7. 本番実行 ⚠️ ヒューマンエラーリスク
$ script1 --execute
$ script2 --execute
8. ログ確認・アーカイブ
⏱️ 75分 x 2人 = 150分
━━━━━━━━━━━━━━━━━━━━━━━━━━━
↓
━━━━━━━━━━━━━━━━━━━━━━━━━━━
9. 告知文章作成
10. レビュー・公開
⏱️ 25分
━━━━━━━━━━━━━━━━━━━━━━━━━━━
合計: 190分 (約3時間10分)
具体的な課題
この運用方法には、いくつかの課題がありました。
まず、操作の記録についてです。SSHによる本番サーバーへの直接ログインが必要で、操作ログの閲覧に手間がかかり、後から見返しづらい状況でした。
次に、ヒューマンエラーのリスクです。本番環境でスクリプトを実行する前には、パラメータやコマンドの内容を何度も確認する必要があり、1つのミスも許されないという大きな責任とプレッシャーが常につきまとっていました。
そして作業効率の問題です。
特に以下の作業に手間がかかっていました。
- DBバックアップ
- 3プラットフォーム（コロプラ版駅メモ！・駅メモ！・アワメモ！）それぞれでAWSマネジメントコンソールを開いて手動操作が必要でした。各プラットフォームごとにコンソールを開き、スナップショット作成を実行し、完了するまで画面を確認し続ける…という作業を3回繰り返していました。完了通知もないため、定期的にコンソールを確認する必要があり、待ち時間が発生していました。
- CLIでのスクリプト実行
- 対象イベントや配布環境の指定、ログファイルの作成など、すべて手動でコマンドに入力する必要がありました。本番環境での実行のため、実行前に何回もコマンドを再確認する必要があり、また手動操作でのミスを防ぐため同時実行が基本禁止となっており、スクリプト実行だけで毎回75分 x 2人という作業時間がかかっていました。
- 告知文章作成
- 報酬配布後、毎回お知らせ文章を手動で作成し、レビュー・公開する作業が必要でした。
これらの課題により、運用担当者の負担も大きく、より安全かつ作業負荷を軽減できる仕組みが求められていました。
解決アプローチ
これらの課題を解決するため、報酬配布作業を管理画面から実行できるようにする方針を立てました。これにより、エンジニアだけでなく、プランナーも安全に作業を実行できることを目指しました。
改善方針の検討
改善方針を検討しました。
1つ目は報酬配布専用のスタンドアロンツールを開発する案です。しかしこれは認証基盤などを新規に構築する必要が生じます。2つ目は既存の管理画面に機能を追加する方法です。
また、プランナーから「自分たちで報酬配布を実行できるようにしたい」という要望がありました。実現できれば、エンジニアの作業時間をほぼゼロにすることも可能になります。
検討の結果、管理画面への統合を採用しました。理由は、まずエンジニアの作業効率化から始め、将来的にプランナーへの権限開放も検討できるという段階的な改善が可能なためです。また、既存の認証・認可機能を活用できるため新規にセキュリティ基盤を構築する必要がない点も大きな決め手となりました。
UI化の基本方針
まず、報酬配布に関連する自動化機能として、DBバックアップを実行するSlackワークフローを作成しました。従来は3プラットフォームそれぞれでAWSコンソールを開いて手動操作していましたが、Slackワークフローから1回の操作で3プラットフォーム全てのバックアップを実行できるようになりました。ワークフローが裏側でAWS APIを呼び出してスナップショットを作成し、完了するとSlackに通知が届きます。実行状況と結果はログとして保存されます。
次に、管理画面に以下の機能を追加しました。
ドライラン機能を実装しました。実行前に配布対象者と配布アイテムを確認でき、既存スクリプトの標準出力と同等の内容を表示します。プランナーでも理解できる形式にしました。
本実行機能では、ドライランの結果を確認後に本実行ボタンを有効化します。実行ログはJSON形式でダウンロード可能で、Slack通知機能も備えています。
また、従来は複数のスクリプトに分かれていた報酬配布作業を1つの機能に統合しました。
最後に、報酬を配布した後にお知らせを非公開状態で自動作成する機能を追加しました。テンプレート文言を使用するため、プランナーはレビュー・公開のみ実施すれば作業は完了です。
期待される効果
この改善により、以下の工数削減を見込んでいました。
| 作業項目 | 改善前 | 改善後 | 削減 |
|---|---|---|---|
| エンジニア準備 | 15分 | 0分 | -15分 |
| エンジニアx2実行 | 150分 | 60分 | -90分 |
| プランナー告知 | 25分 | 5分 | -20分 |
| 合計 | 190分 | 65分 | -125分（約66%削減） |
【改善後】管理画面でUI操作
━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. Slackワークフローでバックアップ実行
⏱️ 自動化
━━━━━━━━━━━━━━━━━━━━━━━━━━━
↓
━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. 管理画面にアクセス ✅ SSH不要
3. イベント選択
4. [ドライラン実行] クリック ✅ 誤操作防止
5. 画面で結果確認
6. [実行を確認] クリック ✅ 操作記録
7. Slack通知を確認
⏱️ 30分 x 2人 = 60分
━━━━━━━━━━━━━━━━━━━━━━━━━━━
↓
━━━━━━━━━━━━━━━━━━━━━━━━━━━
8. お知らせ下書き自動生成済み
9. レビュー・公開
⏱️ 5分
━━━━━━━━━━━━━━━━━━━━━━━━━━━
合計: 65分 (約1時間)
💡 125分削減 (約66%の時間削減)
実装詳細
UI設計
管理画面に専用のランキング報酬配布ページを追加しました。
ワークフロー
操作の流れは3ステップで明確化しました。
Step 1: イベント選択
Step 2: ドライラン結果確認
Step 3: 実行リクエスト送信完了
実装で遭遇した課題と対応
実装中にいくつかの課題に直面しました。
課題1: 配布対象者数が多く画面表示に課題
ランキング報酬の配布対象者が数千人規模になると、ユーザーリストが非常に長くなります。その結果、画面の可読性が低下しました。
【対応前】スクロールが大変
━━━━━━━━━━━━━━━━━━━━━
イベント情報
配る報酬
配布結果
1位: 太郎
2位: 花子
...
999位: 健太 <- スクロールが大変
1000位: さくら
実行ボタン <- 遠い！
━━━━━━━━━━━━━━━━━━━━━
対応策として、画面右側に固定のナビゲーションメニューを追加し、各セクションへワンクリックでジャンプできるようにしました。
課題2: 本実行結果の表示によるブラウザのパフォーマンス問題
本実行の結果表示では、数千件の配布対象ユーザーを配列からフィルタリングし、それぞれに対応する個別リンクをマッピングして画面に出力する必要がありました。初回の本番配布時、この結果をそのまま画面上にレンダリングしたところ、ブラウザが長時間フリーズしてしまいました。配布自体は成功していたものの、フリーズが解消されるまで長時間待つ必要があり、運用担当者の作業時間を削減するという本来の改善目的に反する状態でした。
【対応前】 実行完了！ 配布結果: 1位: 太郎 - ✅ 配布完了 2位: 花子 - ✅ 配布完了 ... 999位: 健太 - ✅ 配布完了 <- 数千件のデータで 1000位: さくら - ✅ 配布完了 ブラウザがフリーズ 【対応後】 実行中 - Slackで通知します 報酬配布結果確認リンク: 🔗 1位 [ランキング] <- 新しいタブで開く 🔗 50位〜51位 [ランキング] <- ボーダーラインのみ 🔗 100位〜101位 [ランキング] リンク提供 🔗 1000位〜1001位 [ランキング]
対応策として、詳細な配布結果は個別ページへのリンクとして提供しました。これにより、確認が必要なときに新しいタブで開けるようにしました。
バックエンド実装
既存の配布スクリプトを活用しつつ、管理画面から呼び出せるようAPI化しました。
既存の報酬配布スクリプトが安定して動作していたため、ゼロから作り直すのではなく、既存資産を活かす方針を採用しました。
API設計
管理画面からのリクエストを受け付け、報酬配布処理を実行するAPIを実装しました。
運用担当者
↓
━━━━━━━━━━━━━━━━━━━━━━━━━━━
管理画面
・イベント選択
・ドライラン実行
・本実行
━━━━━━━━━━━━━━━━━━━━━━━━━━━
↓ API呼び出し
━━━━━━━━━━━━━━━━━━━━━━━━━━━
バックエンドAPI
・dry_run: true -> 即座に結果
・dry_run: false -> 非同期実行
━━━━━━━━━━━━━━━━━━━━━━━━━━━
↓ スクリプト実行
━━━━━━━━━━━━━━━━━━━━━━━━━━━
既存スクリプト群
・報酬配布
・勲章付与
━━━━━━━━━━━━━━━━━━━━━━━━━━━
↓ DB操作
━━━━━━━━━━━━━━━━━━━━━━━━━━━
データベース
・報酬データ
・ランキングデータ
━━━━━━━━━━━━━━━━━━━━━━━━━━━
↓ 完了通知
━━━━━━━━━━━━━━━━━━━━━━━━━━━
Slack
「報酬配布が完了しました」
━━━━━━━━━━━━━━━━━━━━━━━━━━━
報酬配布APIでは、既存スクリプトを呼び出して報酬を配布します。APIが呼ばれると従来の配布スクリプトを順次実行します。スクリプトの実行順序は従来の運用フローと同じです。実行完了時にはSlackへ通知を送信するようにしています。
お知らせ下書き自動作成機能では、工数削減を目的として報酬を配布した後に自動的にお知らせの下書きを作成します。配布完了直後に非公開状態のお知らせを自動生成し、テンプレート文言を使用するためプランナーはレビュー・公開のみ対応すれば完了します。これにより、告知作成の工数を約80%削減できました。
ログ管理も改善しました。従来の標準出力形式から構造化されたJSON形式へ変更し、ログファイルを自動生成して管理画面からダウンロード可能にしました。JSON形式のためプログラムでの解析が容易で、トラブルシューティング時の調査が効率化されました。
また、ログ管理をサポートする補助的なAPIも実装しました。過去の実行ログ一覧を取得するAPIと、指定したログファイルをダウンロードするAPIです。これにより管理画面から実行履歴を簡単に確認できます。
運用・効果測定
実際に運用を開始し、期待される効果で見込んでいた内容と比較してみました。
作業時間の削減については、ほぼ期待通りの結果となりました。UI化により手動操作のミスリスクが軽減されたことで、従来禁止していた3プラットフォーム同時配布が可能になり、作業時間は60分×2人から30分×2人に短縮されました。お知らせ文章を作成する作業も省けるようになっています。
一方、期待以上の効果だったのは、配布実施者の心理的なプレッシャーの軽減です。もうコマンドを打つ必要がないため、本番環境での操作に対する緊張感が和らぎました。これは当初の工数削減という目的を超えた、想定外のメリットでした。
まとめ
今回は、ランキング報酬配布作業のUI化についてご紹介しました。
本番環境のCLIでのスクリプト実行から管理画面操作への変更により、作業時間を約66%削減できました。しかし、最も大きな効果は数値では測れないものでした。それは「本番環境でコマンドを打つ必要がなくなった」ことによる心理的なプレッシャーの軽減です。
エンジニアとしてCLI操作に慣れていたため、当初は「UI化してもそんなに変わらないだろう」と効果に疑問を持っていました。しかし実際に運用してみると、ボタンをクリックするだけで済む安心感は想像以上でした。技術的には単純な変更でも、手作業を減らすことで運用の質は大きく変わります。もし似たような定型的な手作業がチームにある場合、ぜひUI化を検討してみてください。
今まで報酬配布は全てエンジニアが担当していましたが、将来的には他のメンバーも実行できる可能性が見えてきました。運用の効率化を実現できた本プロジェクトは、チーム全体にとって大きな前進となったと感じています！
