カスタマーサクセスの私が、今もコードを書く理由

お客様から「動かない」と連絡が来たとき、私がまずやりたいのは、自分の手で同じ現象を起こしてみることです。再現できた問題なら、説明ができます。お客様にも、それを直すエンジニアにも。開発者向けプラットフォームで顧客と向き合う仕事は、突き詰めればほとんどが「説明すること」だと思っています。

少し自己紹介をさせてください。私はフロントエンドエンジニアを経て、2021年に、日本語が話せる初めてのカスタマーサクセスとしてVercelに入社しました。その後、カスタマーサクセスマネージャーからアジア太平洋・日本のカスタマーサクセスチームのリードになり、今は暫定カントリーマネージャーとして日本のGo-to-Marketも担当しています。役割が変わるたびに、仕事はコードから離れていきました。それでもコードは書き続けていますし、技術系の会社でカスタマーサクセスやソリューションの仕事をしている人は、みんな書いた方がいいと思っています。

自分で再現する

「本番で古いデータが表示される」というチケットだけだと、原因の候補は十個は考えられます。next build && next startでは起きてnext devでは起きない、という再現リポジトリがあれば、候補は一つか二つに絞れます。エンジニアにとって価値があるのは圧倒的に後者で、しかもスタータープロジェクトを動かせる人なら誰でも作れます。

エスカレーションの前に、私が集めるのは次の4つです。

バージョン。npx next infoを実行すると、Next.js、React、Node.jsのバージョンとOSがまとめて出力されます。そのまま貼り付けます。
どこで起きるか。ローカルの開発サーバー、ローカルの本番ビルド、プレビュー環境、本番環境のどれなのか。「プラットフォームのバグ」の多くは、実は開発モードと本番ビルドの違い、特にキャッシュまわりの違いから来ています。
現象を再現できる最小限のコード。まっさらなスターターに、問題の部分だけを足します。スターターで再現しなければ、スターターとお客様のアプリの差分に答えがあります。
期待する結果と実際の結果。それぞれ一文で、URLとタイムゾーン付きの時刻を添えます。大阪からサンフランシスコまでチームが散らばっていると、「今朝」では何も伝わりません。

コードより先に、設定とログを読む

バグとして報告されるものの多くは、ふたを開けてみると設定の問題です。ソースコードを開く前に、システムがすでに教えてくれていることを読みましょう。

設定。next.config.ts、環境ごとの環境変数、リダイレクトとリライト。プレビューと本番を並べて比べます。
ビルド出力。Next.jsはルートごとに記号を表示します。○が静的、ƒが動的です。お客様が「常に最新であってほしい」と思っているページに○が付いていたら、お客様のコードを一行も読まずに、古いデータの原因が見つかったことになります。
ランタイムログ。ステータスコード、どの関数が動いたか、どれくらい時間がかかったか。毎回同じ秒数で返ってくる504は、たいてい関数のタイムアウトです。

それから、レスポンスヘッダーです。ページがキャッシュから返ってきたかどうかは、コマンド一つで分かります。

curl -sI https://example.com/pricing | grep -iE "^(cache-control|age|x-vercel-cache):"

x-vercel-cache: HITでageが大きければ、そのページはキャッシュから配信されています。どれくらいの間キャッシュされるかは、cache-controlを見れば分かります。ホスティング先によってヘッダー名は違いますが、考え方は同じです。

v0でデモを作る

v0は、プロンプトからReactやNext.jsの画面を生成するVercelのAIツールです。私も国内のイベントで紹介していて、AIと要件定義をテーマにしたウェビナーでもデモをしました。

お客様との打ち合わせでは、動く画面の方がスライドよりずっと伝わります。お客様から聞いた話を、日本語の画面で、実際に扱うようなデータを入れて大まかに形にすると、ふわっとしていた議論が一気に具体的になります。画面を指さして「ここはこうじゃなくて」と言ってもらえたら、それだけ要件定義が速く進んでいるということです。

ルールは一つだけです。デモはあくまでラフだと、毎回はっきり伝えてください。そうしないとお客様は、認証や実データ、権限管理、社内のセキュリティ審査といった難しい部分まで、ボタンの見た目と同じくらい出来上がっていると思ってしまいます。そう思うのも無理はありません。

Next.jsについて、自分の意見を持てるくらいには知っておく

お客様からは「このページは静的と動的のどちらにすべきですか」「このデータはどこで取得すべきですか」「今App Routerに移行する価値はありますか」といった質問が来ます。毎回「エンジニアに確認します」と答えていたら、ただの丁寧な転送係です。そのうちお客様は、あなたを飛ばして直接エンジニアに聞くようになります。

専門家である必要はありません。必要なのは、自分の意見と、その理由と、どれくらい自信があるのかを正直に伝えることです。「このページは1日1回しか変わらないので、静的にしてrevalidate（再検証）をかけるのがいいと思います。ユーザーごとに内容が変わるなら話は別なので、エンジニアにも確認します」。後で訂正が必要になったとしても、こういう答えは役に立ちます。

意見を常に新しく保つ一番安上がりな方法は、同じ技術スタックで、実際に運用しているプロジェクトを自分で持つことです。このサイトもNext.jsで動いていて、Claude Codeを使って自分でメンテナンスしています。アップグレードでつまずくなら、お客様の前ではなく、自分のプロジェクトで先につまずいておきたいものです。

エンジニアの信頼を得る

エスカレーションのたびに、エンジニアは手を止めて頭を切り替えなければいけません。エンジニアが信頼する顧客担当は、チケットを出す時点で切り分けが半分終わっている人です。そのための習慣をいくつか挙げます。

すでに確認したことを書き、同じ調査を繰り返させない。
分かっていることと推測を分ける。「あるバージョンでは再現し、一つ前のバージョンでは再現しない」は事実で、「たぶんデグレ」は推測です。どちらなのかを明記します。
同じ問題を複数の経路でエスカレーションしない。
進捗を聞く前に、リンクされているissueやプルリクエストを読む。
解決したら、お客様にとってどんな結果になったのかをエンジニアにも伝えて、話を締めくくる。

テンプレートがあると楽です。

Summary:   <一文で>
Impact:    <誰に影響があるか、いつから、タイムゾーン付きで>
Env:       <npx next info の出力>
Where:     local dev / local build / preview / production
Repro:     <最小再現リポジトリのリンク>
Expected:  <一行で>
Actual:    <一行で>
Ruled out: <確認済みのこと>
Ask:       <答えてほしい質問そのもの>

エンジニアに引き継ぐタイミング

技術に強いからといって、全部を自分で抱える必要はありません。次のどれかに当てはまったら、エンジニアに引き継ぎましょう。

再現した結果、フレームワークやプラットフォーム自体に原因がありそうなとき。エンジニアには今すぐ必要な情報で、自分がもう半日いじっても修正が遅れるだけです。
セキュリティ、データの消失、障害に関わるとき。専用の手順があるはずなので、それに従います。
お客様があなたの回答をもとにアーキテクチャを決めようとしていて、その回答に賭けられるほどの自信がないとき。
1時間調べても、原因が絞れないとき。

それから、お客様の本番コードを代わりに直すのはやめましょう。該当箇所を示してサンプルを書くところまでにして、コミットはお客様自身にしてもらいます。メンテナンスするのはお客様だからです。技術力は、早くてきれいな引き継ぎのために使うものです。

完璧な英語より「何を作りたいか」

2024年11月のQiita Conference 2024 Autumnで、Vercelのエンジニアの上杉周作さんと「異色のキャリアを経てグローバルベンチャーに入ったふたりが学んだ、日本と世界をつなぐ視点」という基調講演をしました。その中で私が一番大事にしているメッセージは、完璧な英語より「何を作りたいか」の方が大事だということ。そして、王道から外れたキャリアは強みになるということです。（講演は登壇・出演の一覧に載せています。私自身の経緯はこちらの記事に詳しく書きました。）

日本で働いていると、技術力より英語力の方が気になるかもしれません。私は逆だと思っています。最小再現のリポジトリ、ログの抜粋、curlの出力は、東京でもサンフランシスコでも同じように読めます。短い英語でも再現手順がはっきりしていれば、海の向こうのエンジニアに必要な情報が届きます。再現手順のない長くて丁寧な英文は、たいてい届きません。

異色のキャリアについても、同じことが言えます。サポートやマーケティング、翻訳を経験してからコードを覚えた人は、お客様の課題とエンジニアの課題を両方追いかけられます。きれいな経歴より、ずっと珍しい組み合わせです。

CSMやソリューションエンジニアが技術力をつけるには

お客様と同じ技術スタックで、実際に運用するプロジェクトを一つ持つ。お客様がアップグレードを迫られるタイミングで、自分も上げる。個人サイトで十分です。
書く前に、読めるようになる。ビルド出力、設定ファイル、ブラウザのネットワークタブ、レスポンスヘッダー。
面白いと思ったお客様の問題は、全部最小再現リポジトリにして残しておく。1年もすれば、自分だけの既知の問題集ができます。
担当しているプロダクトのリリースノートを毎回読み、お客様から聞かれそうな変更を一つ試す。
AIコーディングツールを使い、差分は必ず全部読む。私も毎日Claude Codeを使っていますが、速くなっているのは、書かれた内容をきちんと確認しているからです。
次の打ち合わせでは、スライドの代わりにv0でデモを作ってみる。

次にお客様から不具合の報告が来たら、転送する前に、まず自分で再現してみてください。