開発部に不満を持っていたCSがエンジニアにジョブチェンしてわかった「勝手に諦めない」ことの大切さ

by Sakurai

Embed

Start on current slide

Slide 1

Slide 1 text

開発部に不満を持っていたCSがエンジニアにジョブチェンしてわかった「勝⼿に諦めない」ことの⼤切さ 2024-07-13 大吉祥寺.pm

Slide 2

Slide 2 text

こんにちは！！！ ● さくらい（ : @saku_rye） ● 新卒4年⽬、エンジニア歴は2年ちょい CS → エンジニアに未経験ジョブチェン ● Webアプリ開発のPHPer @⼩⽥原 ● 狂ったようなハイキューオタク劇場版ハイキューを17回リピート中（絶賛上映中！）

Slide 3

Slide 3 text

カンファレンス初登壇もちろん吉祥寺.pmも初登場プロポーザル出してみたいけど怖すぎて無理ぽですめっちゃいーじゃん！！出そうぜ！！！！！ 💪 エネルギッシュな先輩さくらい

Slide 4

Slide 4 text

今⽇のターゲット CS（ユーザー対応部署）とのコミュニケーションで ● モヤったことがある⼈ ● 絶賛モヤモヤ中の⼈ ● これからモヤる予定の⼈

Slide 5

Slide 5 text

ここでの「カスタマーサクセス」とは⾃分がCS出⾝なので便宜的にCSと⾔いますが、 ● ユーザー対応を主業務とする⼈々のこと ● いわゆるビズ側、ユーザー対応部署 ● CSがない場合、置き換えて聞いてください！

Slide 6

Slide 6 text

GOAL & NOT GOAL ● エンジニアにとっての当たり前は CSにとっての当たり前ではないと気付いた ● 両者の「当たり前」のdiﬀを埋めるために、エンジニア側でできる意識がある ● モヤっている⼈が、明⽇から⼩さく実践できそうな何かを持って帰ってもらうこと

Slide 7

Slide 7 text

GOAL & NOT GOAL ● ⾃分がCS時代にモヤった実体験をもとに、元CSエンジニアだからこそ話せることを話します ● 狙っていないこと ○ エンジニアと⾮エンジニアの対⽴を煽ること ○ エンジニアを⾒下す偉そうな新⼈になること

Slide 8

Slide 8 text

おしながき開発部に抱えていた不満と変化「勝⼿に諦めない」コミュニケーションの⼤切さ実践編！対CSコミュニケーションのアンチパターン 1 2 3

Slide 9

Slide 9 text

おしながき開発部に抱えていた不満と変化「勝⼿に諦めない」コミュニケーションの⼤切さ実践編！対CSコミュニケーションのアンチパターン 1 2 3

Slide 10

Slide 10 text

Q. なぜエンジニアになったんですか？

Slide 11

Slide 11 text

A. 開発部に不満があるのに何もできない⾃分が悔しかったから

Slide 12

Slide 12 text

たとえば開発部へあげている機能要望が⼀向に実装されない

Slide 13

Slide 13 text

たとえば開発部へあげている機能要望が⼀向に実装されない開発優先度を聞いても、納得できる回答が返ってこない

Slide 14

Slide 14 text

たとえば開発部へあげている機能要望が⼀向に実装されない開発優先度を聞いても、納得できる回答が返ってこない障害時のユーザー対応、はやく共有してほしい

Slide 15

Slide 15 text

たとえば開発部へあげている機能要望が⼀向に実装されない開発優先度を聞いても、納得できる回答が返ってこない障害時のユーザー対応、はやく共有してほしい刷新要望され続けているUI/UXに、改善の気配がない

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

No content

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

エンジニアになって不満はどう変化した？

Slide 23

Slide 23 text

不満と変化のBefore/After 1. 開発の優先度がわからない 2. 障害時のユーザー対応の有無 3. 新機能の開発‧UI/UXの刷新がされない 1 2 3

Slide 24

Slide 24 text

不満と変化のBefore/After 1. 開発の優先度がわからない 2. 障害時のユーザー対応の有無 3. 新機能の開発‧UI/UXの刷新がされない 1 2 3

Slide 25

Slide 25 text

開発の優先度がよく分からない誰がどう決めてるの？ ● ユーザー要望を開発に上げるだけ ● 要望を溜めておく場所はあるものの形骸化 ● なかなか実現はされない before

Slide 26

Slide 26 text

● クラウド化？PHPのバージョンアップ？ ● 実現したらどうユーザーに喜んでもらえるのか ● なぜユーザーの要望より優先されるのか before 開発の優先度がよく分からない誰がどう決めてるの？

Slide 27

Slide 27 text

● 現場とエンジニアで温度感がチグハグなのでは？ ● もどかしい、モヤモヤ ● でも何も変えられない⾃分が悔しい before 開発の優先度がよく分からない誰がどう決めてるの？

Slide 28

Slide 28 text

エンジニアになった後

Slide 29

Slide 29 text

after ● 数々の「どうしようもない」を理解した ● 開発⼯数‧調査‧検証‧リソースの逼迫‧ 膨⼤な影響範囲‧改修リスク... 開発の優先度がよく分からない誰がどう決めてるの？

Slide 30

Slide 30 text

after ● それでも「どうしようもない」の間隙を縫って⾊々な⼈が、⾊々な⾓度から、タスクの優先度やプロダクトの未来を考えている ● エンジニア的視座の⽅が、⻑期的かつ多⾯的に⾒やすい問題もある（バージョンアップ、クラウド化etc）開発の優先度がよく分からない誰がどう決めてるの？

Slide 31

Slide 31 text

after ● とはいえ、⾮エンジニアにも共有の機会は設けるべきだと今でも思っている ● ロール関係なく全員が、常に⾃信をもってタスク優先度をユーザーに説明できる状態が健全開発の優先度がよく分からない誰がどう決めてるの？

Slide 32

Slide 32 text

不満と変化のBefore/After 1. 開発の優先度がわからない 2. 障害時のユーザー対応の有無 3. 新機能の開発‧UI/UXの刷新がされない 1 2 3

Slide 33

Slide 33 text

障害時のCS対応ユーザー対応の有無を共有してほしい ● 障害対応中のエンジニア is この世で⼀番話しかけづらい存在 ● 邪魔になりたくない VS ユーザー対応が必要なら早めに教えてほしい before

Slide 34

Slide 34 text

● 無関係なユーザーにまで影響が及ぶ可能性があるから ● 業界イベントの有無‧ユーザーごとの特徴を⾒て、最適にアポ‧スケジュールを組んでいる before 障害時のCS対応ユーザー対応の有無を共有してほしい

Slide 35

Slide 35 text

● そこに急遽対応が差し込まれるなら、アポのドタキャンや時間ずらしを防ぐためになるはやで他メンバーとの連携が必須 ● 頼む！ユーザー対応の有無の可能性だけでいいから、もう少し早めに...！！ before 障害時のCS対応ユーザー対応の有無を共有してほしい

Slide 36

Slide 36 text

エンジニアになった後

Slide 37

Slide 37 text

● 頭真っ⽩！変な汗グッチョリ！！ ● 他部署のことまで考えたら、パニックが加速すること間違いなし after 障害時のCS対応ユーザー対応の有無を共有してほしい

Slide 38

Slide 38 text

● 渦中の⼈でなくて⼤丈夫 ● 周囲の冷静な誰か⼀⼈でいいユーザー対応部署のことを思い出してあげて ● 状況と対応⽅針がまとまったら、早めの共有を！ after 障害時のCS対応ユーザー対応の有無を共有してほしい

Slide 39

Slide 39 text

● 弊社の障害時のしくみ ○ マインドではなく仕組みで解決 ○ Slackに半⾃動で障害チャンネルを⽴てる ○ オープンな場に情報を集約 ○ 必要な⼈が必要な情報を得られるしくみ after 障害時のCS対応ユーザー対応の有無を共有してほしい

Slide 40

Slide 40 text

弊社の障害フローに興味をもたれた⽅はこちらの発表をぜひ！

Slide 41

Slide 41 text

不満と変化のBefore/After 1. 開発の優先度がわからない 2. 障害時のユーザー対応の有無 3. 新機能の開発‧UI/UXの刷新がされない 1 2 3

Slide 42

Slide 42 text

● 派⼿な武器ほしくない！？ ● 新規契約獲得‧解約阻⽌の⼤きな武器となる新機能 ● スムーズなオンボーディングを後押しするモダンでカッケェUI/UX before 新機能の開発 UI/UXの刷新がされない

Slide 43

Slide 43 text

● なんか既存機能のアップデートや改修の⽅が多い...？ ● なんかもっとこう、ババンと！でっかいことやりたくない！？！？ before 新機能の開発 UI/UXの刷新がされない

Slide 44

Slide 44 text

エンジニアになった後

Slide 45

Slide 45 text

● エンジニアだってやれるもんならやりたい ● 新しくて、望まれてて、かっこいいモノを作りたい気持ちはみんな同じ after 新機能の開発 UI/UXの刷新がされない

Slide 46

Slide 46 text

● プロダクトとはハウルの動く城のようなもの ● 城の歩みを止めずに一部だけを改築するのは思っているよりずっと大変 ● エンジニアはいつだって「このネジを抜いても城は歩き続けられるか」を考えている after 新機能の開発 UI/UXの刷新がされない

Slide 47

Slide 47 text

● ⾮エンジニアに伝えるようにしている ● 全く関係なさそうな床板の補強が実は超イケてるリフォームの下地になっている、みたいなことは結構あるぞ！ after 新機能の開発 UI/UXの刷新がされない

Slide 48

Slide 48 text

不満と変化のBefore/After 1. 開発の優先度がわからない 2. 障害時のユーザー対応の有無 3. 新機能の開発‧UI/UXの刷新がされない 1 2 3

Slide 49

Slide 49 text

開発部に抱えていた不満と変化まとめ

Slide 50

Slide 50 text

ここまでのまとめ ● 当たり前だけど、エンジニアは敵じゃなかった！ ○ アプローチが違うだけ ○ 同じ⽅向を向いている ● 未経験からエンジニアになったからこそ ○ CSが / エンジニアが⾒る世界がわかった ○ 両者の「当たり前」にdiﬀがあることを痛感

Slide 51

Slide 51 text

👀 エンジニア開発部に抱えていた不満と変化 👀 CS diﬀ diﬀ

Slide 52

Slide 52 text

ここからはこのdiﬀを埋めるためのマインドの話

Slide 53

Slide 53 text

おしながき開発部に抱えていた不満と変化「勝⼿に諦めない」コミュニケーションの⼤切さ実践編！対CSコミュニケーションのアンチパターン 1 2 3

Slide 54

Slide 54 text

⾒えるものが異なれば両者の「当たり前」も異なる

Slide 55

Slide 55 text

このdiﬀを埋めるために⼤切なマインド

Slide 56

Slide 56 text

コミュニケーションで「勝⼿に諦めない」こと

Slide 57

Slide 57 text

勝⼿に諦めない ● 俺が知る必要のないことだと、無意識に諦めてない？ ● 「あれはエンジニアの話だから / CSの話だから」「きっと話しても / 聞いてもわからない」なんてことはない！もったいない！！

Slide 58

Slide 58 text

勝⼿に諦めない ● もちろん開発には開発だけが、CSにはCSだけが知っていればいい難しい専⾨的な話はある ● 本当にユーザーのために動いていることなら、開発もCSも同じ⽅向を向いて同じ⾔語で話せるはず CS/エンジニアには関係ない、わけがない！

Slide 59

Slide 59 text

諦め始めてしまうと同じ⽅向を向いているはずなのにだんだん敵に⾒えてしまう

Slide 60

Slide 60 text

ここまでOK？

Slide 61

Slide 61 text

\ ⽔分補給/

Slide 62

Slide 62 text

では実践編

Slide 63

Slide 63 text

おしながき開発部に抱えていた不満と変化「勝⼿に諦めない」コミュニケーションの⼤切さ実践編！対CSコミュニケーションのアンチパターン 1 2 3

Slide 64

Slide 64 text

ここでの「アンチパターン」とは ● CSのストレスになるコミュニケーション ● 仲間の負担になる振る舞い‧おこない → 抽象化したもの

Slide 65

Slide 65 text

注意書きあくまで経験に基づく⾃戒 ● 結局ケースバイケース ● 絶対こうすべき！という話ではない ● 両者の視野を⼿に⼊れた私が気をつけていること

Slide 66

Slide 66 text

対CSコミュニケーションのアンチパターンコミュニケーションとは、⾃分が話したいことを話す場ではないそれあなたにとっての結論じゃない？意図の不透明さは右往左往を招く 1 2 3

Slide 67

Slide 67 text

Slide 68

Slide 68 text

実践編① 障害対応のフォローを頼むとき問い合わせに回答するとき

Slide 69

Slide 69 text

実践編① 想像してください

Slide 70

Slide 70 text

実践編① CSがこの後ユーザーとどういう会話をするか

Slide 71

Slide 71 text

ひいてはユーザーが知りたい情報は何か実践編①

Slide 72

Slide 72 text

❌ ⾃分が話したいこと ⭕ CSがユーザーと話すために必要な情報実践編①

Slide 73

Slide 73 text

「〇〇という障害が発⽣した」と伝える時「正常な挙動をしないのはなぜか」に回答する時 ↓ ユーザーが知りたいことは？実践編①

Slide 74

Slide 74 text

「〇〇という障害が発⽣した」と伝える時「正常な挙動をしないのはなぜか」に回答する時 ↓ ユーザーが知りたいことは ● イレギュラーな回復作業は必要？ ● 復旧しないなら代替案はある？ ● 再発し得る？実践編①

Slide 75

Slide 75 text

「〇〇という障害が発⽣した」と伝える時「正常な挙動をしないのはなぜか」に回答する時 ↓ ユーザが知りたいのは ● イレギュラーな回復作業は必要？ ● 復旧しないなら代替案はある？ ● 再発し得る？実践編① CSがユーザーと話すために必要な情報

Slide 76

Slide 76 text

聞かれてない仕様や障害の説明は、⾔い訳でしかない ● 聞かれたらもちろん答える ● 説明しやすさが⾼まりそうな時は共有する ○ 判断するのはユーザーと話す⼈ ○ オススメ枕詞「これはユーザーに伝えるかはお任せしますが」実践編①

Slide 77

Slide 77 text

対CSコミュニケーションのアンチパターンコミュニケーションとは、⾃分が話したいことを話す場ではない ● ⾃分とCSの先で発⽣する会話を想像して ● ユーザーが知りたい情報を共有する → 不要なラリー‧モヤモヤが減る 1

Slide 78

Slide 78 text

Slide 79

Slide 79 text

結論が⼤事結論ファースト実践編②

Slide 80

Slide 80 text

当たり前やんけ実践編②

Slide 81

Slide 81 text

じゃあ CSにとっての「結論」とは？実践編②

Slide 82

Slide 82 text

ユーザーが知りたいことユーザーが待っている情報実践編②

Slide 83

Slide 83 text

ユーザーが待っている情報って？実践編②

Slide 84

Slide 84 text

ユーザーが待っている情報＝イレギュラーな作業の有無今⽇の仕事が増えるか実践編②

Slide 85

Slide 85 text

ユーザーが待っている情報 ≠ 原因や仕様の説明実践編②

Slide 86

Slide 86 text

そこで考える「それあなたにとっての結論じゃない？」実践編②

Slide 87

Slide 87 text

例1）ユーザーからの問い合わせに調査‧回答する時実践編②

Slide 88

Slide 88 text

実践編② 〇〇されないのはなぜ？

Slide 89

Slide 89 text

実践編② あなたならどう答えますか？〇〇されないのはなぜ？

Slide 90

Slide 90 text

実践編② あなたならどう答えますか？ ● 〜〜な障害でした ● ⼀時的な不具合でした〇〇されないのはなぜ？

Slide 91

Slide 91 text

それあなたにとっての結論じゃない？実践編②

Slide 92

Slide 92 text

思い出して実践編②

Slide 93

Slide 93 text

CSにとっての「結論」とは？実践編②

Slide 94

Slide 94 text

ユーザーが知りたいことユーザーが待っている情報実践編②

Slide 95

Slide 95 text

実践編② 〇〇されないのはなぜ？

Slide 96

Slide 96 text

実践編② 〇〇されないのはなぜ？ ↓翻訳↓

Slide 97

Slide 97 text

実践編② 〇〇されないのはなぜ？〇〇されないのは困るのだが、ユーザー原因か？こちらでするべき作業‧対策があれば教えて欲しい ↓翻訳↓

Slide 98

Slide 98 text

実践編② ユーザーが知りたいのは ⭕ 影響とネクストアクション ❌ 細かい仕様や設計の説明

Slide 99

Slide 99 text

例2) リリースで障害が発⽣した時実践編②

Slide 100

Slide 100 text

実践編② \ 差し戻しました！ /

Slide 101

Slide 101 text

それあなたにとっての結論じゃない？実践編②

Slide 102

Slide 102 text

思い出して実践編②

Slide 103

Slide 103 text

CSにとっての「結論」とは？実践編②

Slide 104

Slide 104 text

ユーザーが知りたいことユーザーが待っている情報実践編②

Slide 105

Slide 105 text

実践編② 障害時「revertしました！」 ↓

Slide 106

Slide 106 text

実践編② 障害時「revertしました！」 ↓ 「ありがとうございます！......それで？」

Slide 107

Slide 107 text

障害時「revertしました！」 ↓ ● ユーザー連絡の必要はあるのか ● ユーザー側で必要なイレギュラー作業はあるのか ● 再発するのか ○ するなら何に気を付けるよう伝える必要があるか実践編②

Slide 108

Slide 108 text

対CSコミュニケーションのアンチパターンそれあなたにとっての結論じゃない？ ● ユーザーにとっての結論は何か考える ● 1つのイレギュラーの先には、何百何千のユーザーのイレギュラーがあることを考える → モヤモヤが減る伝え⽅ 2

Slide 109

Slide 109 text

Slide 110

Slide 110 text

たとえば設計会実践編③

Slide 111

Slide 111 text

CSに仕様を相談するとき実践編③

Slide 112

Slide 112 text

どんな質問をしてますか？実践編③

Slide 113

Slide 113 text

「〇〇にしたら困りますか？」「〇〇でも⼤丈夫ですか？」実践編③

Slide 114

Slide 114 text

「〇〇にしたら困りますか？」「〇〇でも⼤丈夫ですか？」実践編③

Slide 115

Slide 115 text

やってることこれと⼀緒です

Slide 116

Slide 116 text

要件を先に⾔えやってることこれと⼀緒です

Slide 117

Slide 117 text

相談や質問をする時に知りたい理由‧意図を伝える実践編③

Slide 118

Slide 118 text

「〇〇にしたら困りますか？」「〇〇でも⼤丈夫ですか？」 / WHY????? \ 実践編③

Slide 119

Slide 119 text

「〇〇にしたら困りますか？」「〇〇でも⼤丈夫ですか？」 ↓ なんで？時と場合とユーザーによるが？実践編③

Slide 120

Slide 120 text

「〇〇にしたら困りますか？」「〇〇でも⼤丈夫ですか？」 ↓ 事実と推測をあわせて伝えて判断を仰ぐ実践編③

Slide 121

Slide 121 text

「〇〇にしたら困りますか？」「〇〇でも⼤丈夫ですか？」 ↓ 事実と推測をあわせて伝えて判断を仰ぐ ● 新機能をリリースします。仕様はこうです。 ● 〜〜運⽤中のユーザーに〇〇な影響が出ます。 ● それにより問い合わせが増加する可能性があります。実践編③

Slide 122

Slide 122 text

起きる可能性のあることを⼀緒にイメージする実践編③

Slide 123

Slide 123 text

● CSにどういう仕事が増えるか ● ユーザーにどういう仕事が増えるか実践編③

Slide 124

Slide 124 text

● CSにどういう仕事が増えるか ○ 事前のお知らせ‧個別連絡の必要性は？ ○ どういう問い合わせが増加する？ ○ 急増した時に対応できるキャパはある？ ● ユーザーにどういう仕事が増えるか実践編③

Slide 125

Slide 125 text

● CSにどういう仕事が増えるか ○ 事前のお知らせ‧個別連絡の必要性は？ ○ どういう問い合わせが増加する？ ○ 急増した時に対応できるキャパはある？ ● ユーザーにどういう仕事が増えるか ○ 問い合わせしないと解決できない問題になる？ ○ プロダクトに後遺症は残る？実践編③

Slide 126

Slide 126 text

対CSコミュニケーションのアンチパターン意図の不透明さは右往左往を招く ● 相談する時は知りたい理由‧意図も伝える ● 事実と推測があると判断の正確性が上がる → CSと⼀緒にイメージしながら検討できる → 場が右往左往するのを防げる 3

Slide 127

Slide 127 text

Slide 128

Slide 128 text

実践編おわり

Slide 129

Slide 129 text

おしながきもおわり 1. 開発部に抱えていた不満と変化 2. 「勝⼿に諦めない」コミュニケーションの⼤切さ 3. 実践編！対CSコミュニケーションのアンチパターン 1 2 3

Slide 130

Slide 130 text

本⽇の⼤まとめ

Slide 131

Slide 131 text

明⽇から使えそうな「モヤモヤを解決できそうな何か」は掴めましたか？

Slide 132

Slide 132 text

どの場⾯においても⾔えるのは相⼿の⽴場に⽴って勝⼿に諦めないこと

Slide 133

Slide 133 text

⾔葉を尽くしていますか？勝⼿に諦めていませんか？

Slide 134

Slide 134 text

他部署事だと思って諦めるのはもったいない！！

Slide 135

Slide 135 text

⾔葉を尽くして

Slide 136

Slide 136 text

⾔葉を尽くして伝える努⼒をして

Slide 137

Slide 137 text

⾔葉を尽くして伝える努⼒をして理解する努⼒をしてみたら