ユニバーサルゲーム事業部でサーバーエンジニアをしている五田です。
今回は、エンジニアがプロダクトの「業務改善」に取り組んだ話をしようと思います。
やろうと思ったきっかけ
私が担当しているプロジェクトでは、特に周年施策が始まる時期になるとプランナーやデザイナーの負担がどんどん増えていき、工数をどんどん圧迫していっていました。
そんな状況を見ていると、なんとかしてエンジニアとして工数を減らしてあげることは出来ないのかと自然に考えるようになっていました。
自分自身、ツール開発が好きというのもあり、プランナー・デザイナーの工数削減を目標にトライしてみることにしました。
さて、どこから手を付けるか
まずは、とにかく情報を集めて「ボトルネックを探し出す」ことから始めることにしました。
ボトルネックを、自分なりに以下の4つの軸に定義することとしました。
- 毎日繰り返すもの
- 不定期だけど回数が多い・オーバーヘッドの大きいもの
- イテレーションに時間がかかるもの
- 属人化しているもの
実際に情報を集める際にはこれを分かりやすく言い換えて、
- 毎日繰り返し行っているタスク
- 不定期だけど、回数やチーム跨ぎが多いタスク
- 結果が出るまで時間がかかるもの
- その人しか出来ないもの（その人が休むと止まるもの）
として、広くメンバーに情報提供を求めました。
また並行して、自分から実際の業務を見学しにいくことで、チーム状況の把握やタスク量・内容のチェックを行いました。
特に初動では「こんな些細なことでもいいのかな」と考える方もいらっしゃったので、積極的に立ち回ってまずは状況を聞くことに徹しました。
自分の主観で「インパクト度」をつける
情報がある程度集まったところで、自分なり「インパクト度（やばい度）」を付けることにしました。
予め定義したボトルネックの4軸に照らし合わせて、業務が滞る原因になっているものになっているものには「★3」、あまり深刻ではなければ「★1」というような形です。
インパクト度をつけたあとは、インパクト度が高く自分だけで解決できるものから着手しました。
特に少ない工数で出来るものというのは、さくっと実装してしまって解決し、並行して自分だけで解決できないものは当事者にヒアリングしたりしながら深堀りしていきました。
深堀りで足止めされる感じであれば、他のインパクト度が低いものをやる、といった形で進行しました。
実例
1ヶ月ほどトライしてみて、実際にあった事例（一部）としては、
- Slackで、プロデューサーの承認リアクションが付くまで待っている
→ リアクションが付いたら投稿者に通知してくれるSlackワークフローを整備して、別のタスクに集中出来るように - データ収集を手動で行っている
→ 自動でデータを取り込むように整備して工数削減 - イベントの効果測定が週1回の定例でしか見ることができない
→ いつでも見られるように管理画面を整備して、イテレーションの高速化 - 毎日、特定の人がKPI数値を手動でSlackに投稿している
→ 日時バッチで自動化して、属人化も解消
といったものでした。
理由には「自動化する工数がなかった」というものもありましたが、意外と多かったのが「これがボトルネックになっているとは思いもしなかった」というものでした。
普段エンジニアが見えていないところに手作業で行っているタスクが結構あり、それが毎日・毎週と積み重なることで、大きな工数の損失になっていると感じました。
やってみてどうだったか
実際やってみると「視野を広く持つ」ことが一番大事だと感じました。
点で改善しても他のチームが割を食う形になってしまいがちです。
問題が起こっているタスクに対して、前後を含めて広く確認し、必要に応じて前後を含めてまるっと改善してあげる必要も出てきます。
PDCAを意識しながら、自分の改善によって本当に効果が出ているかを確認しつつ、次のアクションにつなげていくのが大切です。
また、属人化しているタスクに関しては、「本当にその人がやるべきタスクなのか」を考えて、プログラムに任せられるならどんどん任せるべきだと感じました。
そうすることで、本来人間が行うべき「考える・判断する」タスクに専念出来るようになり、業務の質がどんどん上がっていくと考えています。
まとめ
他職種の業務をまじまじと見ることが元々ほとんど無かったため、実際に見てみると、エンジニア観点で自動化出来る作業が結構多かった印象でした。
こういうことを手作業でやっていたのか、と感じることもあり、不定期でもいいのでエンジニアが入って見てあげるのが良いと感じました。
改善に当たっては普段の業務であまり触らない言語・サービスを積極的に触ることになり、ある日はPythonでLambdaを作り、ある日はGASを書いたりと、エンジニアとしても非常に刺激的でした。
また、改善して実際に効果が出たときの「ありがとう」「めっちゃ助かりました」という声が、自分の大きなモチベーションにもなりました。
エンジニア観点で始める「業務改善」、思った以上に楽しいのでオススメです！