日常業務のカイゼンで図る開発チームへの貢献 - YAPC::Kyoto 2023

YAPC::Kyoto 2023
https://yapcjapan.org/2023kyoto/timetable.html#talk-125

「カイゼン」は業務や作業に対して今ある状態の問題やより良くなるアイデアに気付き、解決し続けることでより良い状態へ昇華し続けることを指し、一般的に改善とは区別されます。

私たちエンジニアがカイゼンを行うにあたって何に取り組むべきでしょうか。この悩みについて、新卒3年目が1年間かけて行った日常業務における業務負荷の調査と、そのカイゼンのために行った活動、その影響について紹介します。

このトークでは8年以上運用が続いているPerlで作られたソーシャルゲーム運用を題材に、1回のデプロイに数時間かかる作業の工数の削減や、週に何度も行われる定形作業の自動化、エンジニア以外にも作業できる人を増やした資料の整備など話す予定です。

これにより、メンバーを希望の別チームへ配属させるなど、チームの人数減少に耐えられる体制を築きました。

以下の悩みを持つ方に聞いて欲しいテーマとなっています。

- 運用の手作業が多くて開発の時間が取れなくて困っている
- どこからをカイゼンすれば良いのかわからなくて始めから躓いている
- 自主的にチームと関わるにはどうすればいいのかわからないといった悩みがある

Transcript

1. 日常業務のカイゼンで図る
   開発チームへの貢献
   YAPC::Kyoto 2023 / 篠田 大地 @koluku
   1
   

   View Slide

2. 自己紹介
   ● 篠田 大地 / koluku(コルク)
   ● 2020/04〜
   ● ゲーム・エンタメ事業部所属
   ● サーバーサイドエンジニア
   ● 新卒3年目
   2
   

   View Slide

3. 本セッションの背景
   ● カイゼンでやった結果
   ○ チームメンバーを5人から4人に縮小（20%の改善）
   ■ メンバーを希望の別チームへ配属させることができた
   ■ チームの人数減少前と同様に負担がない体制になった
   ○ 休日にサーバーを見守る以外の作業をしないで済むようになった
   ○ 各職能間の責任が明確になり作業に集中できるようになった
   ● これらをどう実現したのかを話します
   3
   

   View Slide

4. みなさん仕事したいですか？
   

   View Slide

5. みなさん仕事したいですか？
   ● 僕はしたくないです
   ○ できれば不労所得でいたい
   ● でも現実はそうもいかない…
   ○ 働かないことにはお金がもらえない
   ● なら、なるべく仕事を減らすしかない
   

   View Slide

6. 仕事を減らす方法
   ● 仕事をもらわない
   ○ 拒絶する
   ○ 他の人に任せる
   ○ AIに任せる
   ● 作業を減らす
   ○ 複数人で分担する
   ○ 作業ステップを減らす
   ○ 複数の作業をまとめる
   ● 仕事を苦痛ではないと思いこむ
   

   View Slide

7. 作業したくないことを書き出す
   ● 昼寝してても呼び出されない状態とは何か考える
   ● 時間かかっているよというのを書き出すとなお良い
   ○ 現実の話をすると説得しやすい
   ○ 3時間ぐらい消えてそうだなと体感ベースでも良い
   ● 困ってないなら技術記事を眺めて視野を広げる
   ○ 例) このツールに置き換えたら4倍速くなりそう？
   ○ 例) ドキュメントをGPT-4に書かせて修正すれば良さそう
   7
   

   View Slide

8. それらカイゼン方針をIssueにまとめる
   8
   

   View Slide

9. ソシャゲ開発の特徴
   ● 機能開発以外の運営リリースが多い
   ○ ガチャ、新規キャラ、イベント、etc…
   ○ 半年前から準備を開始
   ○ 数十個の開発が同時並行する
   ● リリース頻度が早い
   ○ 1日置きにイベントやガチャが入れ替わったりする
   ○ 細かいデータ更新も頻繁に行われる
   

   View Slide

10. やらなきゃと思ったこといくつか
    ● デプロイ作業が高コスト
    ○ 1回のデプロイで担当者が4〜6時間拘束され, 他のメンバーが1~2時間程度拘束される作業を
    毎日行っていたが、それだと毎週最低でも30時間前後が消える
    ● 運営作業のコミュニケーションが高コスト
    ○ アイテム配布やデータ反映などが運営チームから開発チームに依頼されていたが、内容が
    合っているのか、反映するしたなどコミュニケーションコストがチリツモで高かった
    ○ データ変更のレビュー依頼がきても意図が読み取れないことが多い
    ● なぜか手動で実行しているスクリプト実行が多い
    ○ 定期的に行われているスクリプト実行が手動で行われていた
    ○ また自動化しようと思ったまま放置、手が慣れてしまったなどがある
    

    View Slide

11. じゃあどうしようか
    11
    ● デプロイの効率化
    ○ デプロイを自動化する
    ○ 週に行うデプロイ回数を減らす
    ● 運営作業の分担化
    ○ 運営チームでもスクリプト実行できるようにする
    ○ 運営チームだけでデータ変更ができる状態にする
    ● 定期スクリプトの自動化
    ○ 人の判断の余地が無いものは問答無用でバッチにする
    

    View Slide

12. カイゼン方法に問題ないかを聞いてみる
    ● チームからもっといい方法が提案してもらえるかも
    ○ 実はそれ古い手法だからこっちが良いよ
    ○ 最近出たこれがイケてそうだから検証してもらえない？
    ○ こうすればいいのはわかってるけど作業時間が確保できなくて…
    12
    

    View Slide

13. ● 関係者に話を通しておく
    ○ 急に変更されすると作業者が困る
    ○ コードに手を加えなくてもお願いして終わることもある
    ● PMにも話を通しておくのもアリ
    ○ カイゼンの工数に対して改善する時間をコスパを見積もっておいて、1プロジェクトにするの
    を検討してもらう
    ■ スキマ時間にやるより早く終らせることができる
    事前に色んな人に根回しておく
    13
    

    View Slide

14. カイゼン作業する
    

    View Slide

15. デプロイの効率化編
    ● デプロイ頻度を下げる
    ○ 「デプロイがだるいんですよね〜」など1on1でPMに話していたところ、運営チームと調整
    をしてもらえた
    ● デプロイを自動化する
    ○ 途中で止まっても再開・巻き戻せることを確認した上で1ワークフローのまとめ、デプロイに
    かかる時間を短縮
    ○ ステージング環境の自動デプロイも本番環境のデプロイの前提条件として取り入れる
    ● 1つのファイルに全員で書き込むのをやめる
    ○ 複数のPRで同じファイルを並行で変更してPRのコンフリクトが高頻度で発生していた
    ○ PRごとにCSVを分割して最終的に結合する仕組みを採用
    ○ 最近GitHubでpublic betaとなったMerge Queueを使うことを検討できそう
    15
    

    View Slide

16. ジョブ管理ツールRundeck
    ● 乱暴に説明するとブラウザからスクリプトを実行するツール
    ● job同士を逐次・並列に実行、スケジュール実行も可能
    ● GitHub Actionsでも可能だが、GitHubのアクセス権がある人とデプロイや
    コマンドの実行が可能な環境・人を分けたい事情で採用している
    

    View Slide

17. 30時間/週→4時間に短縮！
    

    View Slide

18. 運営作業の分担化編
    18
    ● 運営チームでもスクリプト実行できるようにする
    ○ Rundeckに権限を絞ったロールを用意する
    ○ 誤ってアイテム大量配布によるインフレなどが起きないように値チェックを挟む
    ● 運営チームだけでデータ変更ができる状態にする
    ○ 開発チームがCSVを目視でチェックするのをやめる
    ○ 運営チーム内のレビューとCIによるチェックで担保する
    

    View Slide

19. 差し込み依頼の撲滅
    

    View Slide

20. スクリプトの自動化・管理画面化編
    ● 特に理由のない手作業をやめる
    ○ オートスケーリングを手動から自動設定にする
    ○ 特定の時間に手動で叩いていたスクリプトをバッチ化
    ● 手動が必要なものでもRundeckに置く
    ○ カジュアルに実行しても良いものはコンソールじゃなくてもいい
    ○ 大いなる力が伴うものはコンソールという意識分けにして置くほうが安全
    

    View Slide

21. 出先でも対応可能に
    土日の出勤対応がなくなった
    

    View Slide

22. うまくいかないこともある
    

    View Slide

23. ● 進捗が出にくい
    ○ 1個1個解かないといけないが、表面上改善しない
    ○ そもそも手がつけれないことが発覚することもある
    ● 影響が甚大
    ○ 具体的にはデプロイイメージを作るのに1時間程度かかるのが解消できていない
    ■ マスターデータの整合性チェックが1PRにつき15分
    ■ 更新ファイルを生成するのにファイルを全部検査
    ■ git自体が大きすぎてCIでcloneに時間がかかる
    ○ 運営・アプリチームにも影響があるため1大プロジェクトにせざるを得ない
    技術的負債
    23
    

    View Slide

24. ● アプリチームとの連携が必要
    ○ つまり自分以外を巻き込むので高コスト
    ● 運営チームとの合意が必要
    ○ コンテキストを理解してもらうのに時間がかかる
    ○ 逆にこちらが理解するのも時間かかる
    チームが密結合
    24
    

    View Slide

25. 色々進めた結果としては…
    

    View Slide

26. ● デプロイ関係
    ○ 30時間/週→4時間に短縮！
    ● 運営作業の分担化
    ○ 7時間/週→1時間に短縮
    ○ 差し込み依頼の撲滅
    ● スクリプトの自動化・管理画面化編
    ○ 休みの日に人員を割り当てて実行する必要がなくなった
    ● 副産物
    ○ 公開作業が早くなった
    ○ コードが読みやすくなった
    結果どれくらい改善されたのか
    

    View Slide

27. よし、これで半日は昼寝できるな！
    

    View Slide

28. カイゼンしただけで終わらせない
    

    View Slide

29. ● 感謝されよう
    ○ おこがましいと思わず、みんなが楽になるようにカイゼン
    したので褒められよう
    ○ 逆にやって当然だと思われてもお互いのためにならないの
    で苦労したならそれを言うべき
    ● 良くしていきたいという雰囲気にもっていける
    ○ 誰か一人が実践すると後の人がついてきやすい
    ○ そうなるとカイゼンに対する議論が活発になって好循環に
    なる
    カイゼンできたらでアピールをしよう
    29
    

    View Slide

30. 社内で発表
    ● 他の部署でもやるぞという雰囲気を促すことが
    できる
    ○ できたということを聞くだけで人はモチベーションが
    上がりやすい
    ● こういうことができる人ですよという属性を得
    られる
    ○ 主張しないことには才能は埋没しやすい
    ● お悩み相談を受けやすくなる
    ○ それぞれの立場での悩みがあるので自分の場合ならど
    うするかという考えを研究することができる
    30
    

    View Slide

31. そして社外にも…
    31
    ● ブログに投稿、カンファレンス登壇してみよう
    ○ 他の人にとって問題にアプローチをしてみたというのは面白いし参考になる
    ○ 発表した内容に対して人や知見が集まりやすいのでより次の活動が洗練されていきやすい
    ○ もちろん社外秘を含む場合があるのでリーダーやCTOに許可を取ろう
    なんか既視感ある
    

    View Slide

32. まとめ
    ● カイゼンは自分が楽になりたいという気持ちが大事
    ● 面倒だと思っても関係者と相談を済ませよう
    ● やること・やったことをアピールして次につなげていこう
    32
    

    View Slide