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