Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
大きくなるチームを支える技術 / Technology to support a growin...
Search
Kentaro Suda
May 26, 2022
Technology
0
1.3k
大きくなるチームを支える技術 / Technology to support a growing SCX team
EC Tech Talk -カラーミーショップとSTORESを支えるチームづくりと開発の裏側
https://pepabo.connpass.com/event/245104/
Kentaro Suda
May 26, 2022
Tweet
Share
More Decks by Kentaro Suda
See All by Kentaro Suda
カラーミーショップカートのAngular事情 / Angular circumstances of colorme-cart
ku00
1
2.5k
もう一人の私 / Another I
ku00
0
2k
ゆるふわAngular入門/angular-intro
ku00
2
2.4k
最近の開発でやったLGTMなこと / EC Tech MTG 3
ku00
1
850
Other Decks in Technology
See All in Technology
【新卒研修資料】LLM・生成AI研修 / Large Language Model・Generative AI
brainpadpr
23
17k
Escaping_the_Kraken_-_October_2025.pdf
mdalmijn
0
130
成長自己責任時代のあるきかた/How to navigate the era of personal responsibility for growth
kwappa
3
270
生成AIを活用したZennの取り組み事例
ryosukeigarashi
0
200
KMP の Swift export
kokihirokawa
0
330
GC25 Recap+: Advancing Go Garbage Collection with Green Tea
logica0419
1
410
自動テストのコストと向き合ってみた
qa
0
150
動画データのポテンシャルを引き出す! Databricks と AI活用への奮闘記(現在進行形)
databricksjapan
0
140
M5製品で作るポン置きセルラー対応カメラ
sayacom
0
150
生成AIで「お客様の声」を ストーリーに変える 新潮流「Generative ETL」
ishikawa_satoru
1
310
空間を設計する力を考える / 20251004 Naoki Takahashi
shift_evolve
PRO
3
330
Large Vision Language Modelを用いた 文書画像データ化作業自動化の検証、運用 / shibuya_AI
sansan_randd
0
110
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Code Review Best Practice
trishagee
72
19k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
51k
A Tale of Four Properties
chriscoyier
160
23k
The World Runs on Bad Software
bkeepers
PRO
71
11k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Context Engineering - Making Every Token Count
addyosmani
5
180
Building an army of robots
kneath
306
46k
The Pragmatic Product Professional
lauravandoore
36
6.9k
Automating Front-end Workflow
addyosmani
1371
200k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
Transcript
大きくなるチームを 支える技術 須田 健太郎 / GMO PEPABO inc. 2022.05.26 EC
Tech Talk -カラーミーショップとSTORESを支えるチームづくりと開発の裏側- 1
2 自己紹介 EC事業部 SCX (Shopping Customer eXperience) チーム 2015年 新卒入社 須田
健太郎 Kentaro Suda Angularが好きなペパボ新卒5期生エンジニア。 バックエンドもフロントエンドも両方やります。 最近の趣味は原神の聖遺物厳選とリングフィットア ドベンチャーです。 • GitHub : @ku00 • https://scrapbox.io/ku00/ku00
あらすじ 3 • 自分の所属当初と比べてチームにどのような変化があったか改めて振り返る • エンジニアの視点からチームを支えるための技術・施策について話します 話すこと
チームが大きくなると どんな問題が起こるのか 4
チームが大きくなるとどんな問題が起こるのか 5 • チームのエンジニアの数が5人 → 11人まで増加 ◦ 業務委託メンバーを含む • 機能の開発や施策を実施する数が増加
◦ 現在は5つほどの開発プロジェクトが並行している 所属チームの変化
チームが大きくなるとどんな問題が起こるのか 6 • エンジニアが増えればコーディングの総量が増える? • コーディング量が増えれば、機能の開発や施策の実施の速度も上がる? • そううまくはいかなかった.. チームメンバーが増えるとできることが増える?
チームが大きくなるとどんな問題が起こるのか 7 • コーディング以外の業務の増加 ◦ コードレビュー ◦ 機能の開発や施策の実施に関するMTG ◦ ログ調査依頼
◦ 承認・デプロイ作業の依頼 • プロジェクト管理の複雑化 ◦ スイッチングコストの増加 • 社内外の環境の違いも要因となる ◦ 開発チームに業務委託メンバーが参加している場合 一方で問題も増える
複数のプロジェクトを うまく並行するためには 8
複数のプロジェクトをうまく並行するためには 9 • 業務が増えるほど負担が増加する ◦ コーディング以外の定型業務はその内容が簡単であっても間に挟まると時間を取られる ◦ 複数のプロジェクトを掛け持ちするようになるとその負担はさらに増える プロジェクトの規模に合わせたメンバー編成を実施する コードレビュー
MTG プロジェクトA コードレビュー MTG プロジェクトC コードレビュー ログ調査依頼 プロジェクトB コーディング ログ調査依頼 MTG プロジェクト外の何か
複数のプロジェクトをうまく並行するためには 10 • プロジェクトメンバーを再編し、一人あたりの掛け持ち業務を減らした ◦ スイッチングコストの低減 ◦ 本来注力したい自分の業務に専念できるようになった プロジェクトの規模に合わせたメンバー編成を実施する コードレビュー
MTG プロジェクトA コードレビュー MTG プロジェクトC コードレビュー ログ調査依頼 プロジェクトB コーディング
複数のプロジェクトをうまく並行するためには 11 • プロジェクト関係なく技術的なレビューが必要な場合は誰が見るのか ◦ 引き続き横断的に見ていくしかない ◦ 私の場合はAngularのコードレビューは全て見ている • 人が少ない中で適切なメンバー編成を行うのは難しい
◦ そもそも人が少ない状態で複数のプロジェクトを動かすべきではない.. プロジェクトの規模に合わせたメンバー編成を実施する
複数のプロジェクトをうまく並行するためには 12 • デプロイ作業 → Slack ワークフロー x GitHub Actions
◦ 「Slack ワークフロー × GitHub Actions で何時でも誰でも楽なステージングデプロイを実現する」 ◦ https://tech.pepabo.com/2021/04/09/slack-and-github-actions/ • 議事録作成 → テンプレートから作成 定型業務は自動化して手間を省く
複数のプロジェクトをうまく並行するためには 13 • 一度自動化できれば多くの人の作業時間を削減することができる ◦ 一つひとつは小さな業務でも積もれば大きくなる • 誰でも実行可能になっていることが望ましい ◦ 一部のメンバーが使えるだけだと属人化してしまう
◦ この業務はこの人に頼むという状況をいつまでも解消できない • 自動化した手段が定着するように働きかける ◦ 便利な手段を提供しても使ってもらえなければ意味がない ◦ 提供者が地道に伝えていくしかない 定型業務は自動化して手間を省く
複数のプロジェクトをうまく並行するためには 14 • 業務のほとんどがリモートになっているとプロジェクト外の情報が入ってきづらい ◦ 今のチームは渋谷本社だけでなく鹿児島オフィスなど遠方のメンバーもいるため、気軽に オフラインで会って話すことが難しい • チームのエンジニアが集う「お茶会」を定期開催している ◦
週に2回、30分の枠 ◦ 各々のプロジェクトの進捗・相談などを共有する ▪ 困りごとでなくても気になることがあればその場で拾うようにする ▪ 雑談もOK 定期的な接点を用意する
業務委託メンバーとの関わり方 15
業務委託メンバーとの関わり方 16 • 機能開発のフローのどこかでつまずき支障が出ることがあった ◦ 「環境構築がうまくいきません..」 ◦ 「このPull Requestのデプロイをお願いします..」 •
主な要因として社内エンジニアとの権限の差が挙げられる • 一連の機能開発のフローが滑らかに進むように、ある程度の権限委譲を実施する ◦ 仕様書やリポジトリの共有 ◦ デプロイ・リリース作業 適切な権限の委譲を実施する
業務委託メンバーとの関わり方 17 • 社内システムの全てにアクセスできるわけではないため、社内エンジニアの対応が 一部必要となるケースがある ◦ ログ調査、仕様調査 ◦ ドキュメントやリポジトリへの権限追加 ◦
DBマイグレーション • 依頼内容が多岐にわたるため、issueで一括管理するのが難しいケースがある ◦ 緊急度の高い依頼ではissueのメンションだけではすぐに気づけない ◦ 開発に関する質問など2往復ほどのコミュニケーションで終わる内容ならissueにするまで もない 依頼を受けやすい体制を整える
業務委託メンバーとの関わり方 18 • 相談窓口を設置する ◦ 相談窓口をSlack ワークフローで用意する ◦ ワークフローでフォーマットを用意することで依頼内容を明確にし、 スレッドに分離することで依頼者とのやり取りに注目しやすくなる
依頼を受けやすい体制を整える
業務委託メンバーとの関わり方 19 • 相談窓口に来た依頼の確認も忘れずにやる ◦ Slackなので依頼が流れてしまったり、誰かがアサインされたけど日が経ってしまうなど して依頼が完了していないことが起こらないようにリマインドを設定する 依頼を受けやすい体制を整える
業務委託メンバーとの関わり方 20 • 相談窓口以外の手段もあるとよりよい ◦ 依頼ではない困りごとの共有など ◦ 毎日の昼会、スプリントMTG 依頼を受けやすい体制を整える
21 まとめ
22 まとめ • チームが大きくなるほど一人ひとりの負荷を減らすような仕組み・環境づくりが求 められる ◦ 人を増やすだけでは開発はうまくまわらない ◦ プロジェクトの規模に合わせてメンバーを再編したり、業務の効率化が必要となる •
業務委託メンバーとの仕事では、社内エンジニアの仕事とは異なる問題が起こる ◦ 業務委託メンバーとの連携には一工夫が必要 伝えたいこと
23 今後の課題・展望
24 今後の課題・展望 • 上の立場になるほど見えるものが多くなる(権限によるものが大きい) • 見える範囲のものを全て一人でカバーするのは不可能 ◦ 本来自分がすべき業務に取り組めなくなってしまう • とはいえプロジェクトと関係ない技術的なレビューなどは必要
掛け持ち業務はゼロにならない?
25 今後の課題・展望 • チームが抱えるタスクの負荷に気づけるようにする ◦ 一つのタスクに時間がかかり過ぎていないか → タスクのCycle Time ◦
ふりかえりからタスクの障害となるものがないか → KPTA (Keep, Problem, Try, Action) • タスクの負荷を下げるような取り組みを継続的に実施する ◦ 定型業務の自動化 ◦ ドキュメント整備 ◦ ドメイン知識を共有するためのペア・モブプロ 今後意識したいチームづくりについて
26 Thank You! チームをうまくまわしたい! ⇄ 気持ちよく開発をしたい!