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
開発部に不満を持っていたCSがエンジニアにジョブチェンしてわかった「勝手に諦めない」ことの大切さ
Search
Sakurai
July 13, 2024
Programming
47
26k
開発部に不満を持っていたCSがエンジニアにジョブチェンしてわかった「勝手に諦めない」ことの大切さ
2024/07/13 大吉祥寺.pm
20分レギュラートーク 登壇資料
Sakurai
July 13, 2024
Tweet
Share
Other Decks in Programming
See All in Programming
なまけものオバケたち -PHP 8.4 に入った新機能の紹介-
tanakahisateru
1
120
Symfony Mapper Component
soyuka
2
730
テストケースの名前はどうつけるべきか?
orgachem
PRO
0
130
MCP with Cloudflare Workers
yusukebe
2
220
LLM Supervised Fine-tuningの理論と実践
datanalyticslabo
5
1.2k
バグを見つけた?それAppleに直してもらおう!
uetyo
0
180
htmxって知っていますか?次世代のHTML
hiro_ghap1
0
330
CSC305 Lecture 26
javiergs
PRO
0
140
create_tableをしただけなのに〜囚われのuuid編〜
daisukeshinoku
0
250
これでLambdaが不要に?!Step FunctionsのJSONata対応について
iwatatomoya
2
3.6k
Spatial Rendering for Apple Vision Pro
warrenm
0
110
「Chatwork」Android版アプリを 支える単体テストの現在
okuzawats
0
180
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
A Philosophy of Restraint
colly
203
16k
Into the Great Unknown - MozCon
thekraken
33
1.5k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Optimizing for Happiness
mojombo
376
70k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.3k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
5
450
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Transcript
開発部に不満を持っていたCSが エンジニアにジョブチェンしてわかった 「勝⼿に諦めない」ことの⼤切さ 2024-07-13 大吉祥寺.pm
こんにちは!!! • さくらい( : @saku_rye) • 新卒4年⽬、エンジニア歴は2年ちょい CS → エンジニアに未経験ジョブチェン
• Webアプリ開発のPHPer @⼩⽥原 • 狂ったようなハイキューオタク 劇場版ハイキューを17回リピート中(絶賛上映中!)
カンファレンス初登壇 もちろん吉祥寺.pmも初登場 プロポーザル出してみたい けど怖すぎて無理ぽです めっちゃいーじゃん!! 出そうぜ!!!!! 💪 エネルギッシュな先輩 さくらい
今⽇のターゲット CS(ユーザー対応部署)とのコミュニケーションで • モヤったことがある⼈ • 絶賛モヤモヤ中の⼈ • これからモヤる予定の⼈
ここでの「カスタマーサクセス」とは ⾃分がCS出⾝なので便宜的にCSと⾔いますが、 • ユーザー対応を主業務とする⼈々のこと • いわゆるビズ側、ユーザー対応部署 • CSがない場合、置き換えて聞いてください!
GOAL & NOT GOAL • エンジニアにとっての当たり前は CSにとっての当たり前ではないと気付いた • 両者の「当たり前」のdiffを埋めるために、 エンジニア側でできる意識がある
• モヤっている⼈が、明⽇から⼩さく実践できそうな 何かを持って帰ってもらうこと
GOAL & NOT GOAL • ⾃分がCS時代にモヤった実体験をもとに、 元CSエンジニアだからこそ話せることを話します • 狙っていないこと ◦
エンジニアと⾮エンジニアの対⽴を煽ること ◦ エンジニアを⾒下す偉そうな新⼈になること
おしながき 開発部に抱えていた不満と変化 「勝⼿に諦めない」コミュニケーションの⼤切さ 実践編!対CSコミュニケーションのアンチパターン 1 2 3
おしながき 開発部に抱えていた不満と変化 「勝⼿に諦めない」コミュニケーションの⼤切さ 実践編!対CSコミュニケーションのアンチパターン 1 2 3
Q. なぜエンジニアになったんですか?
A. 開発部に不満があるのに 何もできない⾃分が悔しかったから
たとえば 開発部へあげている機能要望が⼀向に実装されない
たとえば 開発部へあげている機能要望が⼀向に実装されない 開発優先度を聞いても、納得できる回答が返ってこない
たとえば 開発部へあげている機能要望が⼀向に実装されない 開発優先度を聞いても、納得できる回答が返ってこない 障害時のユーザー対応、はやく共有してほしい
たとえば 開発部へあげている機能要望が⼀向に実装されない 開発優先度を聞いても、納得できる回答が返ってこない 障害時のユーザー対応、はやく共有してほしい 刷新要望され続けているUI/UXに、改善の気配がない
None
None
⼒がほしい
不満があるならば ⾃分で解消できる⼒が...!
ならば エンジニアになってしまえ
\ えいっ /
エンジニアになって 不満はどう変化した?
不満と変化のBefore/After 1. 開発の優先度がわからない 2. 障害時のユーザー対応の有無 3. 新機能の開発‧UI/UXの刷新がされない 1 2 3
不満と変化のBefore/After 1. 開発の優先度がわからない 2. 障害時のユーザー対応の有無 3. 新機能の開発‧UI/UXの刷新がされない 1 2 3
開発の優先度がよく分からない 誰がどう決めてるの? • ユーザー要望を開発に上げるだけ • 要望を溜めておく場所はあるものの形骸化 • なかなか実現はされない before
• クラウド化?PHPのバージョンアップ? • 実現したらどうユーザーに喜んでもらえるのか • なぜユーザーの要望より優先されるのか before 開発の優先度がよく分からない 誰がどう決めてるの?
• 現場とエンジニアで温度感がチグハグなのでは? • もどかしい、モヤモヤ • でも何も変えられない⾃分が悔しい before 開発の優先度がよく分からない 誰がどう決めてるの?
エンジニアになった後
after • 数々の「どうしようもない」を理解した • 開発⼯数‧調査‧検証‧リソースの逼迫‧ 膨⼤な影響範囲‧改修リスク... 開発の優先度がよく分からない 誰がどう決めてるの?
after • それでも「どうしようもない」の間隙を縫って ⾊々な⼈が、⾊々な⾓度から、タスクの優先度や プロダクトの未来を考えている • エンジニア的視座の⽅が、⻑期的かつ多⾯的に ⾒やすい問題もある(バージョンアップ、クラウド化etc) 開発の優先度がよく分からない 誰がどう決めてるの?
after • とはいえ、⾮エンジニアにも共有の機会は 設けるべきだと今でも思っている • ロール関係なく全員が、常に⾃信をもって タスク優先度をユーザーに説明できる状態が健全 開発の優先度がよく分からない 誰がどう決めてるの?
不満と変化のBefore/After 1. 開発の優先度がわからない 2. 障害時のユーザー対応の有無 3. 新機能の開発‧UI/UXの刷新がされない 1 2 3
障害時のCS対応 ユーザー対応の有無を共有してほしい • 障害対応中のエンジニア is この世で⼀番話しかけづらい存在 • 邪魔になりたくない VS ユーザー対応が必要なら早めに教えてほしい
before
• 無関係なユーザーにまで影響が及ぶ可能性があるから • 業界イベントの有無‧ユーザーごとの特徴を⾒て、 最適にアポ‧スケジュールを組んでいる before 障害時のCS対応 ユーザー対応の有無を共有してほしい
• そこに急遽対応が差し込まれるなら、 アポのドタキャンや時間ずらしを防ぐために なるはやで他メンバーとの連携が必須 • 頼む!ユーザー対応の有無の可能性だけでいいから、 もう少し早めに...!! before 障害時のCS対応 ユーザー対応の有無を共有してほしい
エンジニアになった後
• 頭真っ⽩!変な汗グッチョリ!! • 他部署のことまで考えたら、 パニックが加速すること間違いなし after 障害時のCS対応 ユーザー対応の有無を共有してほしい
• 渦中の⼈でなくて⼤丈夫 • 周囲の冷静な誰か⼀⼈でいい ユーザー対応部署のことを思い出してあげて • 状況と対応⽅針がまとまったら、早めの共有を! after 障害時のCS対応 ユーザー対応の有無を共有してほしい
• 弊社の障害時のしくみ ◦ マインドではなく仕組みで解決 ◦ Slackに半⾃動で障害チャンネルを⽴てる ◦ オープンな場に情報を集約 ◦ 必要な⼈が必要な情報を得られるしくみ
after 障害時のCS対応 ユーザー対応の有無を共有してほしい
弊社の障害フローに興味をもたれた⽅は こちらの発表をぜひ!
不満と変化のBefore/After 1. 開発の優先度がわからない 2. 障害時のユーザー対応の有無 3. 新機能の開発‧UI/UXの刷新がされない 1 2 3
• 派⼿な武器ほしくない!? • 新規契約獲得‧解約阻⽌の⼤きな武器となる新機能 • スムーズなオンボーディングを後押しする モダンでカッケェUI/UX before 新機能の開発 UI/UXの刷新がされない
• なんか既存機能のアップデートや改修の⽅が多い...? • なんかもっとこう、ババンと! でっかいことやりたくない!?!? before 新機能の開発 UI/UXの刷新がされない
エンジニアになった後
• エンジニアだってやれるもんならやりたい • 新しくて、望まれてて、かっこいいモノを 作りたい気持ちはみんな同じ after 新機能の開発 UI/UXの刷新がされない
• プロダクトとはハウルの動く城のようなもの • 城の歩みを止めずに一部だけを改築するのは 思っているよりずっと大変 • エンジニアはいつだって「このネジを抜いても 城は歩き続けられるか」を考えている after 新機能の開発
UI/UXの刷新がされない
• ⾮エンジニアに伝えるようにしている • 全く関係なさそうな床板の補強が 実は超イケてるリフォームの下地になっている、 みたいなことは結構あるぞ! after 新機能の開発 UI/UXの刷新がされない
不満と変化のBefore/After 1. 開発の優先度がわからない 2. 障害時のユーザー対応の有無 3. 新機能の開発‧UI/UXの刷新がされない 1 2 3
開発部に抱えていた不満と変化 まとめ
ここまでのまとめ • 当たり前だけど、エンジニアは敵じゃなかった! ◦ アプローチが違うだけ ◦ 同じ⽅向を向いている • 未経験からエンジニアになったからこそ ◦
CSが / エンジニアが⾒る世界がわかった ◦ 両者の「当たり前」にdiffがあることを痛感
👀 エンジニア 開発部に抱えていた不満と変化 👀 CS diff diff
ここからは このdiffを埋めるためのマインドの話
おしながき 開発部に抱えていた不満と変化 「勝⼿に諦めない」コミュニケーションの⼤切さ 実践編!対CSコミュニケーションのアンチパターン 1 2 3
⾒えるものが異なれば 両者の「当たり前」も異なる
このdiffを埋めるために ⼤切なマインド
コミュニケーションで 「勝⼿に諦めない」こと
勝⼿に諦めない • 俺が知る必要のないことだと、無意識に諦めてない? • 「あれはエンジニアの話だから / CSの話だから」 「きっと話しても / 聞いてもわからない」
なんてことはない!もったいない!!
勝⼿に諦めない • もちろん開発には開発だけが、CSにはCSだけが 知っていればいい難しい専⾨的な話はある • 本当にユーザーのために動いていることなら、 開発もCSも同じ⽅向を向いて同じ⾔語で話せるはず CS/エンジニアには関係ない、わけがない!
諦め始めてしまうと 同じ⽅向を向いているはずなのに だんだん敵に⾒えてしまう
ここまでOK?
\ ⽔分補給/
では実践編
おしながき 開発部に抱えていた不満と変化 「勝⼿に諦めない」コミュニケーションの⼤切さ 実践編!対CSコミュニケーションのアンチパターン 1 2 3
ここでの「アンチパターン」とは • CSのストレスになるコミュニケーション • 仲間の負担になる振る舞い‧おこない → 抽象化したもの
注意書き あくまで経験に基づく⾃戒 • 結局ケースバイケース • 絶対こうすべき!という話ではない • 両者の視野を⼿に⼊れた私が気をつけていること
対CSコミュニケーションの アンチパターン コミュニケーションとは、 ⾃分が話したいことを話す場ではない それあなたにとっての結論じゃない? 意図の不透明さは右往左往を招く 1 2 3
対CSコミュニケーションの アンチパターン コミュニケーションとは、 ⾃分が話したいことを話す場ではない それあなたにとっての結論じゃない? 意図の不透明さは右往左往を招く 1 2 3
実践編① 障害対応のフォローを頼むとき 問い合わせに回答するとき
実践編① 想像してください
実践編① CSがこの後ユーザーと どういう会話をするか
ひいては ユーザーが知りたい情報は何か 実践編①
❌ ⾃分が話したいこと ⭕ CSがユーザーと話すために 必要な情報 実践編①
「〇〇という障害が発⽣した」と伝える時 「正常な挙動をしないのはなぜか」に回答する時 ↓ ユーザーが知りたいことは? 実践編①
「〇〇という障害が発⽣した」と伝える時 「正常な挙動をしないのはなぜか」に回答する時 ↓ ユーザーが知りたいことは • イレギュラーな回復作業は必要? • 復旧しないなら代替案はある? • 再発し得る?
実践編①
「〇〇という障害が発⽣した」と伝える時 「正常な挙動をしないのはなぜか」に回答する時 ↓ ユーザが知りたいのは • イレギュラーな回復作業は必要? • 復旧しないなら代替案はある? • 再発し得る?
実践編① CSがユーザーと話すために必要な情報
聞かれてない仕様や障害の説明は、⾔い訳でしかない • 聞かれたらもちろん答える • 説明しやすさが⾼まりそうな時は共有する ◦ 判断するのはユーザーと話す⼈ ◦ オススメ枕詞 「これはユーザーに伝えるかはお任せしますが」
実践編①
対CSコミュニケーションの アンチパターン コミュニケーションとは、 ⾃分が話したいことを話す場ではない • ⾃分とCSの先で発⽣する会話を想像して • ユーザーが知りたい情報を共有する → 不要なラリー‧モヤモヤが減る
1
対CSコミュニケーションの アンチパターン コミュニケーションとは、 ⾃分が話したいことを話す場ではない それあなたにとっての結論じゃない? 意図の不透明さは右往左往を招く 1 2 3
結論が⼤事 結論ファースト 実践編②
当たり前やんけ 実践編②
じゃあ CSにとっての「結論」とは? 実践編②
ユーザーが知りたいこと ユーザーが待っている情報 実践編②
ユーザーが待っている情報って? 実践編②
ユーザーが待っている情報 = イレギュラーな作業の有無 今⽇の仕事が増えるか 実践編②
ユーザーが待っている情報 ≠ 原因や仕様の説明 実践編②
そこで考える 「それあなたにとっての結論じゃない?」 実践編②
例1)ユーザーからの問い合わせに 調査‧回答する時 実践編②
実践編② 〇〇されないのはなぜ?
実践編② あなたならどう答えますか? 〇〇されないのはなぜ?
実践編② あなたならどう答えますか? • 〜〜な障害でした • ⼀時的な不具合でした 〇〇されないのはなぜ?
それあなたにとっての結論じゃない? 実践編②
思い出して 実践編②
CSにとっての「結論」とは? 実践編②
ユーザーが知りたいこと ユーザーが待っている情報 実践編②
実践編② 〇〇されないのはなぜ?
実践編② 〇〇されないのはなぜ? ↓翻訳↓
実践編② 〇〇されないのはなぜ? 〇〇されないのは困るのだが、 ユーザー原因か?こちらでするべき 作業‧対策があれば教えて欲しい ↓翻訳↓
実践編② ユーザーが知りたいのは ⭕ 影響とネクストアクション ❌ 細かい仕様や設計の説明
例2) リリースで障害が発⽣した時 実践編②
実践編② \ 差し戻しました! /
それあなたにとっての結論じゃない? 実践編②
思い出して 実践編②
CSにとっての「結論」とは? 実践編②
ユーザーが知りたいこと ユーザーが待っている情報 実践編②
実践編② 障害時「revertしました!」 ↓
実践編② 障害時「revertしました!」 ↓ 「ありがとうございます!......それで?」
障害時「revertしました!」 ↓ • ユーザー連絡の必要はあるのか • ユーザー側で必要なイレギュラー作業はあるのか • 再発するのか ◦ するなら何に気を付けるよう伝える必要があるか
実践編②
対CSコミュニケーションの アンチパターン それあなたにとっての結論じゃない? • ユーザーにとっての結論は何か考える • 1つのイレギュラーの先には、何百何千の ユーザーのイレギュラーがあることを考える → モヤモヤが減る伝え⽅
2
対CSコミュニケーションの アンチパターン コミュニケーションとは、 ⾃分が話したいことを話す場ではない それあなたにとっての結論じゃない? 意図の不透明さは右往左往を招く 1 2 3
たとえば設計会 実践編③
CSに仕様を相談するとき 実践編③
どんな質問をしてますか? 実践編③
「〇〇にしたら困りますか?」 「〇〇でも⼤丈夫ですか?」 実践編③
「〇〇にしたら困りますか?」 「〇〇でも⼤丈夫ですか?」 実践編③
やってることこれと⼀緒です
要件を 先に⾔え やってることこれと⼀緒です
相談や質問をする時に 知りたい理由‧意図を伝える 実践編③
「〇〇にしたら困りますか?」 「〇〇でも⼤丈夫ですか?」 / WHY????? \ 実践編③
「〇〇にしたら困りますか?」 「〇〇でも⼤丈夫ですか?」 ↓ なんで?時と場合とユーザーによるが? 実践編③
「〇〇にしたら困りますか?」 「〇〇でも⼤丈夫ですか?」 ↓ 事実と推測をあわせて伝えて判断を仰ぐ 実践編③
「〇〇にしたら困りますか?」 「〇〇でも⼤丈夫ですか?」 ↓ 事実と推測をあわせて伝えて判断を仰ぐ • 新機能をリリースします。仕様はこうです。 • 〜〜運⽤中のユーザーに〇〇な影響が出ます。 • それにより問い合わせが増加する可能性があります。
実践編③
起きる可能性のあることを ⼀緒にイメージする 実践編③
• CSにどういう仕事が増えるか • ユーザーにどういう仕事が増えるか 実践編③
• CSにどういう仕事が増えるか ◦ 事前のお知らせ‧個別連絡の必要性は? ◦ どういう問い合わせが増加する? ◦ 急増した時に対応できるキャパはある? • ユーザーにどういう仕事が増えるか
実践編③
• CSにどういう仕事が増えるか ◦ 事前のお知らせ‧個別連絡の必要性は? ◦ どういう問い合わせが増加する? ◦ 急増した時に対応できるキャパはある? • ユーザーにどういう仕事が増えるか
◦ 問い合わせしないと解決できない問題になる? ◦ プロダクトに後遺症は残る? 実践編③
対CSコミュニケーションの アンチパターン 意図の不透明さは右往左往を招く • 相談する時は知りたい理由‧意図も伝える • 事実と推測があると判断の正確性が上がる → CSと⼀緒にイメージしながら検討できる →
場が右往左往するのを防げる 3
対CSコミュニケーションの アンチパターン コミュニケーションとは、 ⾃分が話したいことを話す場ではない それあなたにとっての結論じゃない? 意図の不透明さは右往左往を招く 1 2 3
実践編おわり
おしながきもおわり 1. 開発部に抱えていた不満と変化 2. 「勝⼿に諦めない」コミュニケーションの⼤切さ 3. 実践編!対CSコミュニケーションのアンチパターン 1 2 3
本⽇の⼤まとめ
明⽇から使えそうな 「モヤモヤを解決できそうな何か」 は掴めましたか?
どの場⾯においても⾔えるのは 相⼿の⽴場に⽴って 勝⼿に諦めないこと
⾔葉を尽くしていますか? 勝⼿に諦めていませんか?
他部署事だと思って 諦めるのはもったいない!!
⾔葉を尽くして
⾔葉を尽くして 伝える努⼒をして
⾔葉を尽くして 伝える努⼒をして 理解する努⼒をしてみたら
チームって
チームって 組織って
チームって 組織って プロダクトって
なんかもっと良い⽅向に いっちゃうんじゃないの!?
コ ミ ッ ト と 言 葉 を 重
ね 未 来 描 く