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

by Kentaro Suda

Slide 1

Slide 1 text

大きくなるチームを支える技術須田健太郎 / GMO PEPABO inc. 2022.05.26 EC Tech Talk -カラーミーショップとSTORESを支えるチームづくりと開発の裏側- 1

Slide 2

Slide 2 text

2 自己紹介 EC事業部　SCX (Shopping Customer eXperience) チーム 2015年新卒入社須田健太郎 Kentaro Suda Angularが好きなペパボ新卒5期生エンジニア。バックエンドもフロントエンドも両方やります。最近の趣味は原神の聖遺物厳選とリングフィットアドベンチャーです。 ● GitHub : @ku00 ● https://scrapbox.io/ku00/ku00

Slide 3

Slide 3 text

あらすじ 3 ● 自分の所属当初と比べてチームにどのような変化があったか改めて振り返る ● エンジニアの視点からチームを支えるための技術・施策について話します話すこと

Slide 4

Slide 4 text

チームが大きくなるとどんな問題が起こるのか 4

Slide 5

Slide 5 text

チームが大きくなるとどんな問題が起こるのか 5 ● チームのエンジニアの数が5人 → 11人まで増加 ○ 業務委託メンバーを含む ● 機能の開発や施策を実施する数が増加 ○ 現在は5つほどの開発プロジェクトが並行している所属チームの変化

Slide 6

Slide 6 text

チームが大きくなるとどんな問題が起こるのか 6 ● エンジニアが増えればコーディングの総量が増える？ ● コーディング量が増えれば、機能の開発や施策の実施の速度も上がる？ ● そううまくはいかなかった.. チームメンバーが増えるとできることが増える？

Slide 7

Slide 7 text

チームが大きくなるとどんな問題が起こるのか 7 ● コーディング以外の業務の増加 ○ コードレビュー ○ 機能の開発や施策の実施に関するMTG ○ ログ調査依頼 ○ 承認・デプロイ作業の依頼 ● プロジェクト管理の複雑化 ○ スイッチングコストの増加 ● 社内外の環境の違いも要因となる ○ 開発チームに業務委託メンバーが参加している場合一方で問題も増える

Slide 8

Slide 8 text

複数のプロジェクトをうまく並行するためには 8

Slide 9

Slide 9 text

複数のプロジェクトをうまく並行するためには 9 ● 業務が増えるほど負担が増加する ○ コーディング以外の定型業務はその内容が簡単であっても間に挟まると時間を取られる ○ 複数のプロジェクトを掛け持ちするようになるとその負担はさらに増えるプロジェクトの規模に合わせたメンバー編成を実施するコードレビュー MTG プロジェクトA コードレビュー MTG プロジェクトC コードレビューログ調査依頼プロジェクトB コーディングログ調査依頼 MTG プロジェクト外の何か

Slide 10

Slide 10 text

複数のプロジェクトをうまく並行するためには 10 ● プロジェクトメンバーを再編し、一人あたりの掛け持ち業務を減らした ○ スイッチングコストの低減 ○ 本来注力したい自分の業務に専念できるようになったプロジェクトの規模に合わせたメンバー編成を実施するコードレビュー MTG プロジェクトA コードレビュー MTG プロジェクトC コードレビューログ調査依頼プロジェクトB コーディング

Slide 11

Slide 11 text

複数のプロジェクトをうまく並行するためには 11 ● プロジェクト関係なく技術的なレビューが必要な場合は誰が見るのか ○ 引き続き横断的に見ていくしかない ○ 私の場合はAngularのコードレビューは全て見ている ● 人が少ない中で適切なメンバー編成を行うのは難しい ○ そもそも人が少ない状態で複数のプロジェクトを動かすべきではない.. プロジェクトの規模に合わせたメンバー編成を実施する

Slide 12

Slide 12 text

複数のプロジェクトをうまく並行するためには 12 ● デプロイ作業 → Slack ワークフロー x GitHub Actions ○ 「Slack ワークフロー × GitHub Actions で何時でも誰でも楽なステージングデプロイを実現する」 ○ https://tech.pepabo.com/2021/04/09/slack-and-github-actions/ ● 議事録作成 → テンプレートから作成定型業務は自動化して手間を省く

Slide 13

Slide 13 text

複数のプロジェクトをうまく並行するためには 13 ● 一度自動化できれば多くの人の作業時間を削減することができる ○ 一つひとつは小さな業務でも積もれば大きくなる ● 誰でも実行可能になっていることが望ましい ○ 一部のメンバーが使えるだけだと属人化してしまう ○ この業務はこの人に頼むという状況をいつまでも解消できない ● 自動化した手段が定着するように働きかける ○ 便利な手段を提供しても使ってもらえなければ意味がない ○ 提供者が地道に伝えていくしかない定型業務は自動化して手間を省く

Slide 14

Slide 14 text

複数のプロジェクトをうまく並行するためには 14 ● 業務のほとんどがリモートになっているとプロジェクト外の情報が入ってきづらい ○ 今のチームは渋谷本社だけでなく鹿児島オフィスなど遠方のメンバーもいるため、気軽にオフラインで会って話すことが難しい ● チームのエンジニアが集う「お茶会」を定期開催している ○ 週に2回、30分の枠 ○ 各々のプロジェクトの進捗・相談などを共有する ■ 困りごとでなくても気になることがあればその場で拾うようにする ■ 雑談もOK 定期的な接点を用意する

Slide 15

Slide 15 text

業務委託メンバーとの関わり方 15

Slide 16

Slide 16 text

業務委託メンバーとの関わり方 16 ● 機能開発のフローのどこかでつまずき支障が出ることがあった ○ 「環境構築がうまくいきません..」 ○ 「このPull Requestのデプロイをお願いします..」 ● 主な要因として社内エンジニアとの権限の差が挙げられる ● 一連の機能開発のフローが滑らかに進むように、ある程度の権限委譲を実施する ○ 仕様書やリポジトリの共有 ○ デプロイ・リリース作業適切な権限の委譲を実施する

Slide 17

Slide 17 text

業務委託メンバーとの関わり方 17 ● 社内システムの全てにアクセスできるわけではないため、社内エンジニアの対応が一部必要となるケースがある ○ ログ調査、仕様調査 ○ ドキュメントやリポジトリへの権限追加 ○ DBマイグレーション ● 依頼内容が多岐にわたるため、issueで一括管理するのが難しいケースがある ○ 緊急度の高い依頼ではissueのメンションだけではすぐに気づけない ○ 開発に関する質問など2往復ほどのコミュニケーションで終わる内容ならissueにするまでもない依頼を受けやすい体制を整える

Slide 18

Slide 18 text

業務委託メンバーとの関わり方 18 ● 相談窓口を設置する ○ 相談窓口をSlack ワークフローで用意する ○ ワークフローでフォーマットを用意することで依頼内容を明確にし、スレッドに分離することで依頼者とのやり取りに注目しやすくなる依頼を受けやすい体制を整える

Slide 19

Slide 19 text

業務委託メンバーとの関わり方 19 ● 相談窓口に来た依頼の確認も忘れずにやる ○ Slackなので依頼が流れてしまったり、誰かがアサインされたけど日が経ってしまうなどして依頼が完了していないことが起こらないようにリマインドを設定する依頼を受けやすい体制を整える

Slide 20

Slide 20 text

業務委託メンバーとの関わり方 20 ● 相談窓口以外の手段もあるとよりよい ○ 依頼ではない困りごとの共有など ○ 毎日の昼会、スプリントMTG 依頼を受けやすい体制を整える

Slide 21

Slide 21 text

21 まとめ

Slide 22

Slide 22 text

22 まとめ ● チームが大きくなるほど一人ひとりの負荷を減らすような仕組み・環境づくりが求められる ○ 人を増やすだけでは開発はうまくまわらない ○ プロジェクトの規模に合わせてメンバーを再編したり、業務の効率化が必要となる ● 業務委託メンバーとの仕事では、社内エンジニアの仕事とは異なる問題が起こる ○ 業務委託メンバーとの連携には一工夫が必要伝えたいこと

Slide 23

Slide 23 text

23 今後の課題・展望

Slide 24

Slide 24 text

24 今後の課題・展望 ● 上の立場になるほど見えるものが多くなる（権限によるものが大きい） ● 見える範囲のものを全て一人でカバーするのは不可能 ○ 本来自分がすべき業務に取り組めなくなってしまう ● とはいえプロジェクトと関係ない技術的なレビューなどは必要掛け持ち業務はゼロにならない？

Slide 25

Slide 25 text

25 今後の課題・展望 ● チームが抱えるタスクの負荷に気づけるようにする ○ 一つのタスクに時間がかかり過ぎていないか → タスクのCycle Time ○ ふりかえりからタスクの障害となるものがないか → KPTA (Keep, Problem, Try, Action) ● タスクの負荷を下げるような取り組みを継続的に実施する ○ 定型業務の自動化 ○ ドキュメント整備 ○ ドメイン知識を共有するためのペア・モブプロ今後意識したいチームづくりについて

Slide 26

Slide 26 text

26 Thank You! チームをうまくまわしたい！ ⇄ 気持ちよく開発をしたい！