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にとっての当たり前ではないと気付いた
● 両者の「当たり前」のdiffを埋めるために、
エンジニア側でできる意識がある
● モヤっている⼈が、明⽇から⼩さく実践できそうな
何かを持って帰ってもらうこと
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が / エンジニアが⾒る世界がわかった
○ 両者の「当たり前」にdiffがあることを痛感
Slide 51
Slide 51 text
👀
エンジニア
開発部に抱えていた不満と変化
👀
CS
diff diff
Slide 52
Slide 52 text
ここからは
このdiffを埋めるためのマインドの話
Slide 53
Slide 53 text
おしながき
開発部に抱えていた不満と変化
「勝⼿に諦めない」コミュニケーションの⼤切さ
実践編！対CSコミュニケーションのアンチパターン
1
2
3
Slide 54
Slide 54 text
⾒えるものが異なれば
両者の「当たり前」も異なる
Slide 55
Slide 55 text
このdiffを埋めるために
⼤切なマインド
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
対CSコミュニケーションの
アンチパターン
コミュニケーションとは、
⾃分が話したいことを話す場ではない
それあなたにとっての結論じゃない？
意図の不透明さは右往左往を招く
1
2
3
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
対CSコミュニケーションの
アンチパターン
コミュニケーションとは、
⾃分が話したいことを話す場ではない
それあなたにとっての結論じゃない？
意図の不透明さは右往左往を招く
1
2
3
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
対CSコミュニケーションの
アンチパターン
コミュニケーションとは、
⾃分が話したいことを話す場ではない
それあなたにとっての結論じゃない？
意図の不透明さは右往左往を招く
1
2
3
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
対CSコミュニケーションの
アンチパターン
コミュニケーションとは、
⾃分が話したいことを話す場ではない
それあなたにとっての結論じゃない？
意図の不透明さは右往左往を招く
1
2
3
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
⾔葉を尽くして
伝える努⼒をして
理解する努⼒をしてみたら
Slide 138
Slide 138 text
チームって
Slide 139
Slide 139 text
チームって
組織って
Slide 140
Slide 140 text
チームって
組織って
プロダクトって
Slide 141
Slide 141 text
なんかもっと良い⽅向に
いっちゃうんじゃないの！？
Slide 142
Slide 142 text
コ
ミ
ッ
ト
と
言
葉
を
重
ね
未
来
描
く