大きくなるチームを支える技術 / Technology to support a growing SCX team

EC Tech Talk -カラーミーショップとSTORESを支えるチームづくりと開発の裏側
https://pepabo.connpass.com/event/245104/

Transcript

1. 大きくなるチームを 支える技術 須田 健太郎 / GMO PEPABO inc. 2022.05.26 EC Tech Talk -カラーミーショップとSTORESを支えるチームづくりと開発の裏側- 1
2. 2 自己紹介 EC事業部　SCX (Shopping Customer eXperience) チーム 2015年 新卒入社 須田 健太郎 Kentaro Suda Angularが好きなペパボ新卒5期生エンジニア。 バックエンドもフロントエンドも両方やります。 最近の趣味は原神の聖遺物厳選とリングフィットア ドベンチャーです。 • GitHub : @ku00 • https://scrapbox.io/ku00/ku00
3. あらすじ 3 • 自分の所属当初と比べてチームにどのような変化があったか改めて振り返る • エンジニアの視点からチームを支えるための技術・施策について話します 話すこと
4. チームが大きくなると どんな問題が起こるのか 4
5. チームが大きくなるとどんな問題が起こるのか 5 • チームのエンジニアの数が5人 → 11人まで増加 ◦ 業務委託メンバーを含む • 機能の開発や施策を実施する数が増加 ◦ 現在は5つほどの開発プロジェクトが並行している 所属チームの変化
6. チームが大きくなるとどんな問題が起こるのか 6 • エンジニアが増えればコーディングの総量が増える？ • コーディング量が増えれば、機能の開発や施策の実施の速度も上がる？ • そううまくはいかなかった.. チームメンバーが増えるとできることが増える？
7. チームが大きくなるとどんな問題が起こるのか 7 • コーディング以外の業務の増加 ◦ コードレビュー ◦ 機能の開発や施策の実施に関するMTG ◦ ログ調査依頼 ◦ 承認・デプロイ作業の依頼 • プロジェクト管理の複雑化 ◦ スイッチングコストの増加 • 社内外の環境の違いも要因となる ◦ 開発チームに業務委託メンバーが参加している場合 一方で問題も増える
8. 複数のプロジェクトを うまく並行するためには 8
9. 複数のプロジェクトをうまく並行するためには 9 • 業務が増えるほど負担が増加する ◦ コーディング以外の定型業務はその内容が簡単であっても間に挟まると時間を取られる ◦ 複数のプロジェクトを掛け持ちするようになるとその負担はさらに増える プロジェクトの規模に合わせたメンバー編成を実施する コードレビュー MTG プロジェクトA コードレビュー MTG プロジェクトC コードレビュー ログ調査依頼 プロジェクトB コーディング ログ調査依頼 MTG プロジェクト外の何か
10. 複数のプロジェクトをうまく並行するためには 10 • プロジェクトメンバーを再編し、一人あたりの掛け持ち業務を減らした ◦ スイッチングコストの低減 ◦ 本来注力したい自分の業務に専念できるようになった プロジェクトの規模に合わせたメンバー編成を実施する コードレビュー MTG プロジェクトA コードレビュー MTG プロジェクトC コードレビュー ログ調査依頼 プロジェクトB コーディング
11. 複数のプロジェクトをうまく並行するためには 11 • プロジェクト関係なく技術的なレビューが必要な場合は誰が見るのか ◦ 引き続き横断的に見ていくしかない ◦ 私の場合はAngularのコードレビューは全て見ている • 人が少ない中で適切なメンバー編成を行うのは難しい ◦ そもそも人が少ない状態で複数のプロジェクトを動かすべきではない.. プロジェクトの規模に合わせたメンバー編成を実施する
12. 複数のプロジェクトをうまく並行するためには 12 • デプロイ作業 → Slack ワークフロー x GitHub Actions ◦ 「Slack ワークフロー × GitHub Actions で何時でも誰でも楽なステージングデプロイを実現する」 ◦ https://tech.pepabo.com/2021/04/09/slack-and-github-actions/ • 議事録作成 → テンプレートから作成 定型業務は自動化して手間を省く
13. 複数のプロジェクトをうまく並行するためには 13 • 一度自動化できれば多くの人の作業時間を削減することができる ◦ 一つひとつは小さな業務でも積もれば大きくなる • 誰でも実行可能になっていることが望ましい ◦ 一部のメンバーが使えるだけだと属人化してしまう ◦ この業務はこの人に頼むという状況をいつまでも解消できない • 自動化した手段が定着するように働きかける ◦ 便利な手段を提供しても使ってもらえなければ意味がない ◦ 提供者が地道に伝えていくしかない 定型業務は自動化して手間を省く
14. 複数のプロジェクトをうまく並行するためには 14 • 業務のほとんどがリモートになっているとプロジェクト外の情報が入ってきづらい ◦ 今のチームは渋谷本社だけでなく鹿児島オフィスなど遠方のメンバーもいるため、気軽に オフラインで会って話すことが難しい • チームのエンジニアが集う「お茶会」を定期開催している ◦ 週に2回、30分の枠 ◦ 各々のプロジェクトの進捗・相談などを共有する ▪ 困りごとでなくても気になることがあればその場で拾うようにする ▪ 雑談もOK 定期的な接点を用意する
15. 業務委託メンバーとの関わり方 15
16. 業務委託メンバーとの関わり方 16 • 機能開発のフローのどこかでつまずき支障が出ることがあった ◦ 「環境構築がうまくいきません..」 ◦ 「このPull Requestのデプロイをお願いします..」 • 主な要因として社内エンジニアとの権限の差が挙げられる • 一連の機能開発のフローが滑らかに進むように、ある程度の権限委譲を実施する ◦ 仕様書やリポジトリの共有 ◦ デプロイ・リリース作業 適切な権限の委譲を実施する
17. 業務委託メンバーとの関わり方 17 • 社内システムの全てにアクセスできるわけではないため、社内エンジニアの対応が 一部必要となるケースがある ◦ ログ調査、仕様調査 ◦ ドキュメントやリポジトリへの権限追加 ◦ DBマイグレーション • 依頼内容が多岐にわたるため、issueで一括管理するのが難しいケースがある ◦ 緊急度の高い依頼ではissueのメンションだけではすぐに気づけない ◦ 開発に関する質問など2往復ほどのコミュニケーションで終わる内容ならissueにするまで もない 依頼を受けやすい体制を整える
18. 業務委託メンバーとの関わり方 18 • 相談窓口を設置する ◦ 相談窓口をSlack ワークフローで用意する ◦ ワークフローでフォーマットを用意することで依頼内容を明確にし、 スレッドに分離することで依頼者とのやり取りに注目しやすくなる 依頼を受けやすい体制を整える
19. 業務委託メンバーとの関わり方 19 • 相談窓口に来た依頼の確認も忘れずにやる ◦ Slackなので依頼が流れてしまったり、誰かがアサインされたけど日が経ってしまうなど して依頼が完了していないことが起こらないようにリマインドを設定する 依頼を受けやすい体制を整える
20. 業務委託メンバーとの関わり方 20 • 相談窓口以外の手段もあるとよりよい ◦ 依頼ではない困りごとの共有など ◦ 毎日の昼会、スプリントMTG 依頼を受けやすい体制を整える
21. 21 まとめ
22. 22 まとめ • チームが大きくなるほど一人ひとりの負荷を減らすような仕組み・環境づくりが求 められる ◦ 人を増やすだけでは開発はうまくまわらない ◦ プロジェクトの規模に合わせてメンバーを再編したり、業務の効率化が必要となる • 業務委託メンバーとの仕事では、社内エンジニアの仕事とは異なる問題が起こる ◦ 業務委託メンバーとの連携には一工夫が必要 伝えたいこと
23. 23 今後の課題・展望
24. 24 今後の課題・展望 • 上の立場になるほど見えるものが多くなる（権限によるものが大きい） • 見える範囲のものを全て一人でカバーするのは不可能 ◦ 本来自分がすべき業務に取り組めなくなってしまう • とはいえプロジェクトと関係ない技術的なレビューなどは必要 掛け持ち業務はゼロにならない？
25. 25 今後の課題・展望 • チームが抱えるタスクの負荷に気づけるようにする ◦ 一つのタスクに時間がかかり過ぎていないか → タスクのCycle Time ◦ ふりかえりからタスクの障害となるものがないか → KPTA (Keep, Problem, Try, Action) • タスクの負荷を下げるような取り組みを継続的に実施する ◦ 定型業務の自動化 ◦ ドキュメント整備 ◦ ドメイン知識を共有するためのペア・モブプロ 今後意識したいチームづくりについて
26. 26 Thank You! チームをうまくまわしたい！ ⇄ 気持ちよく開発をしたい！