カスタマーサポートから運用までみんなでやってるうちのチームのスクラム

by bayashi

Slide 1

Slide 1 text

カスタマーサポートから運用までみんなでやってるうちのチームのスクラム  Scrum Fest Sapporo 2021  2021/11/6 Kei Ogane 

Slide 2

Slide 2 text

ばやし@bayashimura フォースタートアップス株式会社エンジニア札幌出身、真駒内公園の近くに住んでました（今は東京在住）自己紹介 

Slide 3

Slide 3 text

エンジニア組織テックラボ  CTO PO  STARTUP DB  CTO直下組織  デザイナー  SRE  採用  タレントエージェンシー支援プロダクト   PO  自分 

Slide 4

Slide 4 text

エンジニア組織テックラボ  CTO PO  STARTUP DB  CTO直下組織  デザイナー  SRE  採用  タレントエージェンシー支援プロダクト   PO  自分 

Slide 5

Slide 5 text

今日話す内容  チームでカスタマーサポートから運用まで   全部やっています。  こういうスタイルの  - 良いところ  - 大変なところ  - 大変をどうにかしているところ   紹介します。  仕様検討  設計  開発  試験  リリース  運用  カスタマー  サポート 

Slide 6

Slide 6 text

タレントエージェンシー支援プロダクト  転職を支援する人  （ヒューマンキャピタリスト）   転職したい人  情報を管理したい、  必要なときに必要な   アクションをうちたい   良い求人を紹介してほしい  

Slide 7

Slide 7 text

タレントエージェンシー支援プロダクト  転職を支援する人  （ヒューマンキャピタリスト）   転職したい人  情報を管理したい、  必要なときに必要な   アクションをうちたい   良い求人を紹介してほしい   CRM/SFA  求人表示/応募  タレントエージェンシー   支援プロダクト 

Slide 8

Slide 8 text

仕様検討  設計  開発  試験  リリース  運用  カスタマー  サポート  インフラ担当   QA  開発者  企画  CS 

Slide 9

Slide 9 text

仕様検討  設計  開発  試験  リリース  運用  カスタマー  サポート  インフラ担当   QA  開発者  企画  CS  でもなく 

Slide 10

Slide 10 text

仕様検討  設計  開発  試験  リリース  運用  カスタマー  サポート  なんでもやる人たち 

Slide 11

Slide 11 text

プロダクトオーナーも  メインの開発に携わらないけど、     カスタマーサポートも障害対応も     細かいバグ修正もリリースもやる。  

Slide 12

Slide 12 text

このスタイルのいいところ 

Slide 13

Slide 13 text

それぞれのプロセスでの学びを    プロダクト開発に活かせる 

Slide 14

Slide 14 text

開発と問い合わせ担当が分かれている場合    使いづらい機能  開発者  ユーザ  カスタマーサポート 

Slide 15

Slide 15 text

開発と問い合わせ担当が分かれている場合    使いづらい機能  開発者  ユーザ  カスタマーサポート  大量の問い合わせ 

Slide 16

Slide 16 text

開発と問い合わせ担当が分かれている場合    使いづらい機能  開発者  ユーザ  カスタマーサポート  大量の問い合わせ  フィードバックを受ける人   作った人 

Slide 17

Slide 17 text

運用も同じこと言える  アラート出しまくる機能   開発者  プロダクト  運用担当者  大量のアラート  フィードバックを受ける人   作った人 

Slide 18

Slide 18 text

生のフィードバックが届かない  現実を味わった人  作った人  この機能問い合わせ多いなー   みんな使い辛そうにしてる...   いやー良い機能作ったなー！  

Slide 19

Slide 19 text

開発とカスタマーサポートが    分かれていない場合 

Slide 20

Slide 20 text

自分が出した機能の結果を自分で受ける  使いづらい機能  大量の問い合わせ  現実を味わうのもこの人   作ったのはこの人 

Slide 21

Slide 21 text

接してるから分かること  前作った機能、問い合わせ多いしみんな使いづらそうにしてたな。   ああいう機能ってああ受け取られちゃうんだな...改修しよう   作った人 

Slide 22

Slide 22 text

POも接してるから分かる  プロダクトオーナー  前作った機能、問い合わせ多いしみんな使いづらそうにしてたな。   ああいう機能ってああ受け取られちゃうんだな...改修しよう   作った人  めっちゃわかる。  バックログの一番上   置いとくわ 

Slide 23

Slide 23 text

ユーザにとってのメリットもある  問い合わせ  あれ、何でそうなってるんだろ？   ソースコード確認して...   うわ！条件文間違えてるじゃん。   これ完全にバグだし直さないと。  

Slide 24

Slide 24 text

ユーザにとってのメリットもある  修正して、自動テスト流して...お、もうレビューでOKもらえた！じゃあリリースしよう。 

Slide 25

Slide 25 text

ユーザにとってのメリットもある  迅速な修正完了報告   すみません、バグでした。   もう直っておりますので、   ご確認ください。 

Slide 26

Slide 26 text

  - ユーザからの問い合わせを聞いて、困り事がすぐさま理解できるか     - みんなが全体のソースコードを把握しているか   把握していないところでも読めばわかる状態になっているか     - 修正は容易な状態になっているか     - デグレを検知できる仕組みはあるか     - チームがレビューに献身的か     - エラーの原因が把握しやすい状況になっているか     - すぐにリリースができるか   背後に潜む色んなプロセスの高度化  仕様  開発  設計  試験  レビュー  運用  リリース 

Slide 27

Slide 27 text

カスタマーサポートを良くしようとすると    結局全部良くしていくことになる 

Slide 28

Slide 28 text

〇〇を良くしようとすると  結局全部良くしていくことになる    どこがボトルネックか解像度高く理解しながら  改善していける 

Slide 29

Slide 29 text

全部のプロセスを担当し、開発するスタイル。   ただしんどいことももちろんあって...   仕様検討  設計  開発  試験  リリース  運用  カスタマー  サポート 

Slide 30

Slide 30 text

まとまった時間が全然取れない  ※イメージ図です 

Slide 31

Slide 31 text

まとまった時間が全然取れない  ※イメージ図です  単純にToil多い！ 

Slide 32

Slide 32 text

まとまった時間が全然取れない  ※イメージ図です  単純に多い！  コンテキストスイッチの   切替しんどい！ 

Slide 33

Slide 33 text

Toil  Toilとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業です。   Toilの例  ● 重要性の低いモニタリングアラートの確認   ● ある作業をすれば直るエラーの対応   ● 何度ももらう同じような問い合わせ   https://cloud.google.com/blog/ja/products/gcp/identifying-and-tracking-toil-using-sre-principles  

Slide 34

Slide 34 text

やる範囲多すぎて大変  仕様検討  設計  開発  試験  リリース  運用  カスタマー  サポート 

Slide 35

Slide 35 text

やる範囲多すぎて大変  仕様検討  設計  開発  試験  リリース  運用  カスタマー  サポート  学習せねば！ 

Slide 36

Slide 36 text

まとまった時間を確保する営み 

Slide 37

Slide 37 text

Toilの総量を減らす（問い合わせの例)  社内ユーザ  slackでやり取りしてると情報として  全然蓄積されないな...  slackで問い合わせ  slackで返答 

Slide 38

Slide 38 text

Toilの総量を減らす（問い合わせの例)  社内ユーザ  スタックオーバーフローみたいなやつ立てよう！  slackで問い合わせ  slackで返答 

Slide 39

Slide 39 text

毎週金曜日はToilを減らしましょうDay  Toilの解消は大事。  だけどやっぱり目の前の開発に追われちゃうし、過去の負債多すぎ...   もう曜日を区切って、毎週金曜日はToilを減らすことにみんなで専念。  

Slide 40

Slide 40 text

エラー  チーム全員に通知  問い合わせ  コンテキストスイッチの切り替えを減らす   

Slide 41

Slide 41 text

コンテキストスイッチの切り替えを減らす  あ、ユーザの問い合わせがその間に来たからそれを先にやって...あ、〇〇さんが問い合わせ対応してくれてるから、えっと...   今作ってるやつのテストコケてるけど   なんでコケてるんだろ。調べたいけど、先にさっき発生したエラー対応しなきゃだし...  

Slide 42

Slide 42 text

これじゃあ開発できないよ！    しんどいので週替り問い合わせ担当制度の導入 

Slide 43

Slide 43 text

コンテキストスイッチの切り替えを減らす  エラー/問い合わせ  エラー担当週替り 

Slide 44

Slide 44 text

集中してやる人と並列で回す人を分離する  集中して開発に没頭する人と、   問い合わせやエラー対応を並列で回す人を明確に分けることで、コンテキストスイッチの切替をできるだけ減らす  エラー担当は、メインの開発に参加せず問い合わせやエラーの恒久対応に全力を尽くす    

Slide 45

Slide 45 text

学習する営み 

Slide 46

Slide 46 text

ユーザのこと理解するDay  プロダクトを使っているところ、使っていないところをじっと見つめたり   ランチ行ったり  話を聞いたり 

Slide 47

Slide 47 text

専門家に学ぶ  監視の仕組みイケてないなー   でもどうやっていいかもわからないし...  開発者 

Slide 48

Slide 48 text

専門家に学ぶ  一緒に良い監視の仕組み検討しましょう。私に良いアイディアがありますよ  SRE（高度なインフラ知識を持つ人）   開発者 

Slide 49

Slide 49 text

専門家に学ぶ  専門家に任せずに、一緒に検討、作業する。   その中で学習し、次からは自分たちだけで実施できることを目指す。  すべてを任せると自分たちのプロダクト、プロセスに対してオーナーシップが失われるためできるだけ避けている。 

Slide 50

Slide 50 text

輪読会  週に一回みんなで本を読んでいる。今年読んだ本達。       - UNIXという考え方    - プロダクトマネジメント     - rubyで作るruby    - SQLアンチパターン    - 入門監視 

Slide 51

Slide 51 text

支えているもの 

Slide 52

Slide 52 text

SaaS(とOSS)の最大活用  人数が少ない、出来ることはもっと少ない。   スケールするために、SaaS(とOSS）に任せよう。     - Mackerel  - redash  - CircleCI  - discourse  - rollbar  - AWSの各種サービス   - Sendgrid  - Slack  - etc...   

Slide 53

Slide 53 text

プロダクト中心の人達  Q. 「そんな色んなプロセスやってエンジニアは嫌にならない？」       A. このスタイルが良いプロダクト作りに寄与していると理解しているし、   良いプロダクトを作る能力を得ることをポジティブに捉えている。     幸いなことに程度の差はあれど、みんなそういう考え方をしている。   (そういう人しか採用していない)  

Slide 54

Slide 54 text

最後に  今はソースコードの規模も小さいし、   メインユーザも社内なので、できてる部分は正直ある     ただ海外の事例*などで、もっと大規模なプロダクトでもこのやり方をしているところもあるし、筋は悪くなさそう     ここからはスケールする中で、どこまでこのやり方を継続できるかの勝負ですね   *https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249  

Slide 55

Slide 55 text

No content