EC Tech Talk -カラーミーショップとSTORESを支えるチームづくりと開発の裏側 https://pepabo.connpass.com/event/245104/
大きくなるチームを支える技術須田 健太郎 / GMO PEPABO inc.2022.05.26 EC Tech Talk-カラーミーショップとSTORESを支えるチームづくりと開発の裏側-1
View Slide
2自己紹介EC事業部 SCX (Shopping Customer eXperience) チーム2015年 新卒入社須田 健太郎 Kentaro SudaAngularが好きなペパボ新卒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)● タスクの負荷を下げるような取り組みを継続的に実施する○ 定型業務の自動化○ ドキュメント整備○ ドメイン知識を共有するためのペア・モブプロ今後意識したいチームづくりについて
26Thank You!チームをうまくまわしたい！⇄気持ちよく開発をしたい！
ku00
culvert
k1low
leveragestech
track3jyo
k1style
muziyoshiz
neonankiti
niftycorp
poteboy
danielkatz
s2terminal
comucal
akosma
paulrobertlloyd
cromwellryan
eileencodes
productmarketing
keathley
moore
phodgson
kastner
jacobian
holman
maltzj