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
カスタマーサポートから運用までみんなでやってるうちのチームのスクラム
Search
bayashi
November 06, 2021
Programming
0
3.1k
カスタマーサポートから運用までみんなでやってるうちのチームのスクラム
Scrum Fest Sapporo2021登壇資料です。
bayashi
November 06, 2021
Tweet
Share
More Decks by bayashi
See All by bayashi
自分がLinc’wellで提供しているプロダクトを理解するためにやったこと
murabayashi
1
240
エンジニアとして関わる要件と仕様(公開用)
murabayashi
0
470
個人事業主型開発からの脱却
murabayashi
14
9.7k
スクラムフェスを支える配信の仕組み
murabayashi
1
970
締切とはなにか、どういう効果があるのか #scrummikawa
murabayashi
0
1.4k
商用アプリケーション開発基本のキ
murabayashi
0
280
(新米)エンジニアリングマネージャーのしごと #RSGT2023
murabayashi
11
11k
Active Recordについてわかったことを説明するよ
murabayashi
0
430
話を聞き出す技術
murabayashi
44
48k
Other Decks in Programming
See All in Programming
開発者への寄付をアプリ内課金として実装する時の気の使いどころ
ski
0
350
WebエンジニアがSwiftをブラウザで動かすプレイグラウンドを作ってみた
ohmori_yusuke
0
170
フロントエンド開発に役立つクライアントプログラム共通のノウハウ / Universal client-side programming best practices for frontend development
nrslib
7
3.9k
大規模アプリのDIフレームワーク刷新戦略 ~過去最大規模の並行開発を止めずにアプリ全体に導入するまで~
mot_techtalk
0
380
そのpreloadは必要?見過ごされたpreloadが技術的負債として爆発した日
mugitti9
2
3k
ポスターセッション: 「まっすぐ行って、右!」って言ってラズパイカーを動かしたい 〜生成AI × Raspberry Pi Pico × Gradioの試作メモ〜
komofr
0
950
After go func(): Goroutines Through a Beginner’s Eye
97vaibhav
0
230
階層構造を表現するデータ構造とリファクタリング 〜1年で10倍成長したプロダクトの変化と課題〜
yuhisatoxxx
3
920
iOSアプリの信頼性を向上させる取り組み/ios-app-improve-reliability
shino8rayu9
0
150
monorepo の Go テストをはやくした〜い!~最小の依存解決への道のり~ / faster-testing-of-monorepos
convto
2
390
LLMとPlaywright/reg-suitを活用した jQueryリファクタリングの実際
kinocoboy2
4
670
Serena MCPのすすめ
wadakatu
4
900
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
139
7.1k
Why Our Code Smells
bkeepers
PRO
339
57k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
54
3k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Code Reviewing Like a Champion
maltzj
525
40k
Thoughts on Productivity
jonyablonski
70
4.9k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
114
20k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
Transcript
カスタマーサポートから運用までみんなで やってるうちのチームのスクラム Scrum Fest Sapporo 2021 2021/11/6 Kei Ogane
ばやし@bayashimura フォースタートアップス株式会社 エンジニア 札幌出身、真駒内公園の近くに住 んでました(今は東京在住) 自己紹介
エンジニア組織 テックラボ CTO PO STARTUP DB CTO直下組織 デザイナー SRE 採用
タレントエージェンシー支援プロダクト PO 自分
エンジニア組織 テックラボ CTO PO STARTUP DB CTO直下組織 デザイナー SRE 採用
タレントエージェンシー支援プロダクト PO 自分
今日話す内容 チームでカスタマーサポートから運用まで 全部やっています。 こういうスタイルの - 良いところ - 大変なところ -
大変をどうにかしているところ 紹介します。 仕様 検討 設計 開発 試験 リリース 運用 カスタマー サポート
タレントエージェンシー支援プロダクト 転職を支援する人 (ヒューマンキャピタリスト) 転職したい人 情報を管理したい、 必要なときに必要な アクションをうちたい
良い求人を紹介してほしい
タレントエージェンシー支援プロダクト 転職を支援する人 (ヒューマンキャピタリスト) 転職したい人 情報を管理したい、 必要なときに必要な アクションをうちたい
良い求人を紹介してほしい CRM/SFA 求人表示/応募 タレントエージェンシー 支援プロダクト
仕様 検討 設計 開発 試験 リリース 運用 カスタマー サポート インフラ担当
QA 開発者 企画 CS
仕様 検討 設計 開発 試験 リリース 運用 カスタマー サポート インフラ担当
QA 開発者 企画 CS でもなく
仕様検討 設計 開発 試験 リリース 運用 カスタマー サポート なんでもやる人たち
プロダクトオーナーも メインの 開 発 に 携 わらないけど、 カスタマーサポートも
障 害 対 応 も 細かいバグ修正もリリースもやる。
このスタイルのいいところ
それぞれのプロセスでの学びを プロダクト開発に活かせる
開発と問い合わせ担当が分かれている場合 使いづらい機能 開発者 ユーザ カスタマーサポート
開発と問い合わせ担当が分かれている場合 使いづらい機能 開発者 ユーザ カスタマーサポート 大量の問い合わせ
開発と問い合わせ担当が分かれている場合 使いづらい機能 開発者 ユーザ カスタマーサポート 大量の問い合わせ フィードバックを受ける人 作った人
運用も同じこと言える アラート出しまくる機能 開発者 プロダクト 運用担当者 大量のアラート フィードバックを受ける人 作った人
生のフィードバックが届かない 現実を味わった人 作った人 この機能問い合わせ多いなー みんな使い辛そうにしてる... いやー良い機能作ったなー!
開発とカスタマーサポートが 分かれていない場合
自分が出した機能の結果を自分で受ける 使いづらい機能 大量の問い合わせ 現実を味わうのもこの人 作ったのはこの人
接してるから分かること 前作った機能、問い合わせ多いしみん な使いづらそうにしてたな。 ああいう機能ってああ受け取られちゃ うんだな...改修しよう 作った人
POも接してるから分かる プロダクトオーナー 前作った機能、問い合わせ多いしみん な使いづらそうにしてたな。 ああいう機能ってああ受け取られちゃ うんだな...改修しよう 作った人 めっちゃわかる。
バックログの一番上 置いとくわ
ユーザにとってのメリットもある 問い合わせ あれ、何でそうなってるんだろ? ソースコード確認して... うわ!条件文間違えてるじゃん。 これ完全にバグだし直さないと。
ユーザにとってのメリットもある 修正して、自動テスト流して...お、もうレ ビューでOKもらえた!じゃあリリースし よう。
ユーザにとってのメリットもある 迅速な修正完了報告 すみません、バグでした。 もう直っておりますので、 ご確認ください。
- ユーザからの問い合わせを聞いて、困り事がすぐさま理解できるか - みんなが全体のソースコードを把握しているか 把握していないところでも読めばわかる状態になっているか
- 修正は容易な状態になっているか - デグレを検知できる仕組みはあるか - チームがレビューに献身的か - エラーの原因が把握しやすい状況になっているか - すぐにリリースができるか 背後に潜む色んなプロセスの高度化 仕様 開発 設計 試験 レビュー 運用 リリース
カスタマーサポートを良くしようとすると 結局全部良くしていくことになる
〇〇を良くしようとすると 結局全部良くしていくことになる どこがボトルネックか解像度高く理解しながら 改善していける
全部のプロセスを担当し、開発するスタイル。 ただしんどいことももちろんあって... 仕様 検討 設計 開発 試験 リリース
運用 カスタマー サポート
まとまった時間が全然取れない ※イメージ図です
まとまった時間が全然取れない ※イメージ図です 単純にToil多い!
まとまった時間が全然取れない ※イメージ図です 単純に多い! コンテキストスイッチの 切替しんどい!
Toil Toilとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増 加する、といった特徴を持つ作業です。 Toilの例 • 重要性の低いモニタリングアラートの確認 • ある作業をすれば直るエラーの対応
• 何度ももらう同じような問い合わせ https://cloud.google.com/blog/ja/products/gcp/identifying-and-tracking-toil-using-sre-principles
やる範囲多すぎて大変 仕様 検討 設計 開発 試験 リリース 運用 カスタマー サポート
やる範囲多すぎて大変 仕様 検討 設計 開発 試験 リリース 運用 カスタマー サポート
学習せねば!
まとまった時間を確保する営み
Toilの総量を減らす(問い合わせの例) 社内ユーザ slackでやり取りしてると情報として 全然蓄積されないな... slackで問い合わせ slackで返答
Toilの総量を減らす(問い合わせの例) 社内ユーザ スタックオーバーフローみたいなやつ立て よう! slackで問い合わせ slackで返答
毎週金曜日はToilを減らしましょうDay Toilの解消は大事。 だけどやっぱり目の前の開発に追われちゃう し、過去の負債多すぎ... もう曜日を区切って、毎週金曜日はToilを減ら すことにみんなで専念。
エラー チーム全員に通知 問い合わせ コンテキストスイッチの切り替えを減らす
コンテキストスイッチの切り替えを減らす あ、ユーザの問い合わせがその間に来た からそれを先にやって...あ、〇〇さんが問 い合わせ対応してくれてるから、えっと... 今作ってるやつのテストコケてるけど なんでコケてるんだろ。調べたいけど、先に さっき発生したエラー対応しなきゃだし...
これじゃあ開発できないよ! しんどいので週替り問い合わせ担当制度の導入
コンテキストスイッチの切り替えを減らす エラー/問い合わせ エラー担当週替り
集中してやる人と並列で回す人を分離する 集 中 して 開 発 に 没 頭 する
人 と、 問い合わせやエラー対応を並列で回す人を明 確に分けることで、コンテキストスイッチの切 替 をできるだけ減らす エラー担当は、メインの開発に参加せず問い合 わせやエラーの恒久対応に全力を尽くす
学習する営み
ユーザのこと理解するDay プロダクトを使っているところ、使っていないと ころをじっと見つめたり ランチ行ったり 話を聞いたり
専門家に学ぶ 監視の仕組みイケてないなー でもどうやっていいかもわからな いし... 開発者
専門家に学ぶ 一緒に良い監視の仕組み検討し ましょう。私に良いアイディアがあ りますよ SRE(高度なインフラ知識を持つ人) 開発者
専門家に学ぶ 専門家に任せずに、一緒に検討、作業する。 その中で学習し、次からは自分たちだけで実施でき ることを目指す。 すべてを任せると自分たちのプロダクト、プロセスに 対 してオーナーシップが 失 われるためできるだけ
避 けている。
輪読会 週に一回みんなで本を読んでいる。今年読んだ本達。 - UNIXという考え方 - プロダクトマネジメント
- rubyで作るruby - SQLアンチパターン - 入門 監視
支えているもの
SaaS(とOSS)の最大活用 人数が少ない、出来ることはもっと少ない。 スケールするために、SaaS(とOSS)に任せよう。 - Mackerel - redash
- CircleCI - discourse - rollbar - AWSの各種サービス - Sendgrid - Slack - etc...
プロダクト中心の人達 Q. 「そんな色んなプロセスやってエンジニアは嫌にならない?」 A. このスタイルが良いプロダクト作りに寄与していると理解しているし、 良いプロダクトを作る能力を得ることをポジティブに捉えている。
幸いなことに程度の差はあれど、みんなそういう考え方をしている。 (そういう人しか採用していない)
最後に 今はソースコードの規模も小さいし、 メインユーザも社内なので、できてる部分は正直ある ただ海外の事例*などで、もっと大規模なプロダクトでもこ のやり方をしているところもあるし、筋は悪くなさそう
ここからはスケールする中で、どこまでこのやり方を継続 できるかの勝負ですね *https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249
None