Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

koluku
March 19, 2023

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

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

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

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

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

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

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

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

koluku

March 19, 2023
Tweet

More Decks by koluku

Other Decks in Programming

Transcript

  1. 本セッションの背景 • カイゼンでやった結果 ◦ チームメンバーを5人から4人に縮小(20%の改善) ▪ メンバーを希望の別チームへ配属させることができた ▪ チームの人数減少前と同様に負担がない体制になった ◦

    休日にサーバーを見守る以外の作業をしないで済むようになった ◦ 各職能間の責任が明確になり作業に集中できるようになった • これらをどう実現したのかを話します 3
  2. 仕事を減らす方法 • 仕事をもらわない ◦ 拒絶する ◦ 他の人に任せる ◦ AIに任せる •

    作業を減らす ◦ 複数人で分担する ◦ 作業ステップを減らす ◦ 複数の作業をまとめる • 仕事を苦痛ではないと思いこむ
  3. 作業したくないことを書き出す • 昼寝してても呼び出されない状態とは何か考える • 時間かかっているよというのを書き出すとなお良い ◦ 現実の話をすると説得しやすい ◦ 3時間ぐらい消えてそうだなと体感ベースでも良い •

    困ってないなら技術記事を眺めて視野を広げる ◦ 例) このツールに置き換えたら4倍速くなりそう? ◦ 例) ドキュメントをGPT-4に書かせて修正すれば良さそう 7
  4. ソシャゲ開発の特徴 • 機能開発以外の運営リリースが多い ◦ ガチャ、新規キャラ、イベント、etc… ◦ 半年前から準備を開始 ◦ 数十個の開発が同時並行する •

    リリース頻度が早い ◦ 1日置きにイベントやガチャが入れ替わったりする ◦ 細かいデータ更新も頻繁に行われる
  5. やらなきゃと思ったこといくつか • デプロイ作業が高コスト ◦ 1回のデプロイで担当者が4〜6時間拘束され, 他のメンバーが1~2時間程度拘束される作業を 毎日行っていたが、それだと毎週最低でも30時間前後が消える • 運営作業のコミュニケーションが高コスト ◦

    アイテム配布やデータ反映などが運営チームから開発チームに依頼されていたが、内容が 合っているのか、反映するしたなどコミュニケーションコストがチリツモで高かった ◦ データ変更のレビュー依頼がきても意図が読み取れないことが多い • なぜか手動で実行しているスクリプト実行が多い ◦ 定期的に行われているスクリプト実行が手動で行われていた ◦ また自動化しようと思ったまま放置、手が慣れてしまったなどがある
  6. じゃあどうしようか 11 • デプロイの効率化 ◦ デプロイを自動化する ◦ 週に行うデプロイ回数を減らす • 運営作業の分担化

    ◦ 運営チームでもスクリプト実行できるようにする ◦ 運営チームだけでデータ変更ができる状態にする • 定期スクリプトの自動化 ◦ 人の判断の余地が無いものは問答無用でバッチにする
  7. デプロイの効率化編 • デプロイ頻度を下げる ◦ 「デプロイがだるいんですよね〜」など1on1でPMに話していたところ、運営チームと調整 をしてもらえた • デプロイを自動化する ◦ 途中で止まっても再開・巻き戻せることを確認した上で1ワークフローのまとめ、デプロイに

    かかる時間を短縮 ◦ ステージング環境の自動デプロイも本番環境のデプロイの前提条件として取り入れる • 1つのファイルに全員で書き込むのをやめる ◦ 複数のPRで同じファイルを並行で変更してPRのコンフリクトが高頻度で発生していた ◦ PRごとにCSVを分割して最終的に結合する仕組みを採用 ◦ 最近GitHubでpublic betaとなったMerge Queueを使うことを検討できそう 15
  8. • 進捗が出にくい ◦ 1個1個解かないといけないが、表面上改善しない ◦ そもそも手がつけれないことが発覚することもある • 影響が甚大 ◦ 具体的にはデプロイイメージを作るのに1時間程度かかるのが解消できていない

    ▪ マスターデータの整合性チェックが1PRにつき15分 ▪ 更新ファイルを生成するのにファイルを全部検査 ▪ git自体が大きすぎてCIでcloneに時間がかかる ◦ 運営・アプリチームにも影響があるため1大プロジェクトにせざるを得ない 技術的負債 23
  9. • デプロイ関係 ◦ 30時間/週→4時間に短縮! • 運営作業の分担化 ◦ 7時間/週→1時間に短縮 ◦ 差し込み依頼の撲滅

    • スクリプトの自動化・管理画面化編 ◦ 休みの日に人員を割り当てて実行する必要がなくなった • 副産物 ◦ 公開作業が早くなった ◦ コードが読みやすくなった 結果どれくらい改善されたのか
  10. 社内で発表 • 他の部署でもやるぞという雰囲気を促すことが できる ◦ できたということを聞くだけで人はモチベーションが 上がりやすい • こういうことができる人ですよという属性を得 られる

    ◦ 主張しないことには才能は埋没しやすい • お悩み相談を受けやすくなる ◦ それぞれの立場での悩みがあるので自分の場合ならど うするかという考えを研究することができる 30