（いたみん）プロジェクトでの運用改善について

Transcript

1. プロジェクトの 運用改善について Akatsuki Geek Live Vol.1
2. 名前：伊丹琢人（いたみ たくと） あだ名：いたみん
 
 • 役職
 ◦ 19卒クライアントエンジニア
 ◦ 八月のシンデレラナイン urakataチーム所属
 
 • 趣味
 ◦ fpsやアクションのゲームをする
 ◦ Vtuberの放送を見たり
 最近便利家電を揃えててなるべく楽をしようとしてます
 自己紹介
3. urakataチームとは 新機能などユーザーに価値を提供するチームではなく
 運用メンバーに対して価値を提供するチームになります。
 現在:クライアント1人、サーバー2人の体制
 
 ハチナイの運用メンバーは主に以下の職種の方がいます
 • プランナー
 • 検証
 • デザイナー

4. なぜ運用メンバーに価値を提供するのか？
5. なぜ運用メンバーに価値を提供するのか？ • 手作業による工数の増大
 • ヒューマンエラーによる不具合
 ユーザーへの還元、最終的にプロジェクトの利益に繋がる
 解決

6. どうやって問題を見つけるか？ • まずはヒアリングしてみる
 → そもそも解決できる問題として認識していないこともあるため
 色々と引き出す必要がある。
 
 • 運用改善のslackチャンネルを作成・要望シートに記載を促す
 → 改善の文化形成、ふとした要望も受け入れるようにして
 問題の浮上をしやすく。

7. • 改善仕様のヒアリングを行う。
 → その仕様よりも良いことはないか？
 実装工数と工数や不具合の削減量でやるやらないを決定していく
 
 • ものによって、コンフルを整備したり
 → 改善したのに使われないままになったり、引き継ぎができないのを防止
 問題解決へ
8. 運用改善 1例の紹介 マスターデータの移行を自動化
9. ハチナイではマスターデータはスプレで管理されていて
 各環境毎にシートがあり、環境によってシートを結合して使います
 
 
 マスターデータの移行作業: 概要 develop
 sandnext
 sandbox
 feature
 develop
 sandbox
 develop
 feature
 sandbox
 feature
 sandnext
 sandbox
 sandnext
 sandbox
 sandbox
 ※これは一部です

10. 今回はここでの改善
 
 
 マスターデータの移行作業: 概要 develop
 sandnext
 sandbox
 feature
 develop
 sandbox
 develop
 feature
 sandbox
 feature
 sandnext
 sandbox
 sandnext
 sandbox
 sandbox

11. sandnext: 本番で使うが、まだ出さないデータで出す日付もバラバラ
 sandbox : 本番で使うデータでここにあるデータを本番やstagingといった環境に反映 します
 マスターデータの移行作業: 概要 sandnext
 sandbox
 sandnext
 sandbox
 sandnext
 sandbox
 sandbox

12. マスターデータの移行作業: 概要 本番で出すにはsandnextからsandboxへ移動させる必要があり
 今まで手作業で移動をさせていた。
 また全部ではなく基本次回で出るデータのみ
 sandnext
 sandbox
 手作業

13. マスターデータの移行作業: 現状の問題把握 • データ不備の発生
 • シートが大量にあるため複数人が最大1時間かかる。しかも増えていく
 • 当時手作業が当たり前という意識の状態だった
 
 
 不具合発生・必要工数ともに大きい問題
 解決しないとマズイ！

14. マスターデータの移行作業: 解決への実装と仕様 • 言語はプロジェクトに合わせてrubyを選択
 • 実行はjenkins上。パラメータに移動対象の日付を指定してポチるだけ！
 • 実行結果はslack上に通知
 

15. マスターデータの移行作業: 移動の判定 • マスターデータの一番右の列に”デプロイ”を追加して日付を指定
 • デプロイ列までを移動対象に
 • 入れ込むデータは元々判断できるようでデプロイ列はそこに含めない
 
 実際にデータ化されるシート
 操作するシート
 参照

16. マスターデータの移行作業: 実装の注意 • 100秒あたり100リクエストの制限
 → 制限が来たら待機・リトライ処理を追加
 • シートごとにリクエストすると重いのでまとめて処理をする
 → batch_update_valuesやbatch_get_spreadsheet_valuesを使用
 運用していくとシートが増えて制限に引っかかるのも
 sheets apiの制限についてこちらから
 https://developers.google.com/sheets/api/reference/limits
17. マスターデータの移行作業: 作業と結果 • デプロイ日を入れて実行
 • 実行結果をslackへ 各マスターで移動ができたら成功アイコン表示

18. マスターデータの移行作業: 改善効果 • 工数
 → 2~4人 x 30 ~ 60分 x 2 ~ 3回デプロイ/1ヶ月 = 最大12時間くらい削減
 → + 作業は非同期なので本来の作業に集中可能 通知も平均６分ほどで来る
 • 不具合
 → 処理がデータによっては不具合が発生することがある。
 行を手動で追加しないといけなかったりとか・・・
 とはいえ手作業でほぼ毎回発生していた不具合は削減

19. • プロジェクトにspineを導入し、anima2dからspineへの移行
 • photoshopスクリプトで必要なspineアトラスを出力するもの
 • iosのテクスチャ圧縮の更新 PVTRC -> ASTC
 • 実機内デバッグ機能で検証コストの低減
 • github actionでチェッカーを入れたり
 他運用改善で行ったものの例
20. • 運用を続けるプロジェクトは運用を改善していくことも重要
 運用し続け肥大化したプロジェクトはどこか負担になっている箇所があり
 本来注力すべき業務の時間が減って結果として利益に影響が発生します。
 機能実装の攻めと改善の守りで攻守兼ね備えたプロジェクトへ
 
 • 改善できるのか？を言いやすい環境へ
 負担になって辛いけどしょうがない・・から改善できるかも？に繋げるため
 チームでコミュニケーションを取ってよりよいチームビルディングへ
 まとめ
21. • iosのPVTRC -> ASTCへの移行 
 元々PVTRCは縦横ともにサイズが2の累乗だけ対応なので 
 いくつか圧縮されていなかった。-> アセットバンドルの サイズ増大
 ASTCに関してはそこが緩和されており置き換えてサイズ削減へ 
 ただしiphone6以降が対応
 
 • anima2dからspineへの移行はアニメーション周りの方からの要望 
 業界的にspineのほうが扱える方が多くやりやすいというのと、anima2dはもうサポート的にどうなの？ という感じだったので移行をしています。 
 spineはcanvas用とmesh renderer用の2パターンあるので相性が良かった 
 appendix
22. • 実機内デバッグではSRDebugger経由でアクセスするものが多いです 
 例えばローディング演出の確認デバッグとか 
 試合開始のVSが出てるところの確認デバッグとかのキャラ表示チェックとか 
 
 • photoshopスクリプトはspineのスケルトンデータ1つに対して 
 キャラのテクスチャを切り替えて表示する形を取っているので 
 同じ配置になるようphotoshopから自動で配置して出力する機能を作成 
 appendix