Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Customer Reliability Engineer ー エンジニアとの信頼関係をつくる仕事

missasan
September 07, 2019
6.7k

Customer Reliability Engineer ー エンジニアとの信頼関係をつくる仕事

2019.9.7 DevRel/Japan Conference 2019

missasan

September 07, 2019
Tweet

Transcript

  1. missasan / 三浦美沙 と申します。 ◉ 経歴 ◦ SIerでインフラ系SE ◦ MSPでプリセールス

    ◦ 株式会社はてな Mackerelチーム CRE @mur_ms_ / id:missasan Hello!
  2. CRE とは? ◉ Customer Reliability Engineer ◉ 2017年に Mackerel チームで発足

    ◉ 日本語に直訳すると「顧客信頼性エンジニア」
  3. ケース 1:反応が薄い ◉ 1年以上利用があるユーザー。より踏み込んだサポートがしたい ので利用状況をヒアリングさせてほしいと連絡しても反応がな い。NPS(アンケート)への回答もない。 ◉ 数回の連絡の後、やっと訪問できることに。 ◉ 担当はSREチームのリーダー。

    ◉ 「Mackerelの利用で何か困っていることはありませんか?」という 質問にも「うーん...」とやっぱり反応薄... • 訪問を承諾してくれたのに、反応が薄い。 • あんまり困ってないのにしつこくしちゃったかな。
  4. ケース 2:情報量は多いけど... ◉ それまで目立ったやりとりがなかったユーザーからサポート宛て に、まとめて十数件の機能要望一覧をもらった ◉ 要望の例) ◦ プロトコル(HTTP/HTTPS以外)を指定して外形監視ができない ◦

    内部のネットワーク機器の監視ができない ◦ ダッシュボード上でグラフの表示期間の変更ができない • たくさんのご指摘。ネガティブな印象を持たれている? • 要望にはかなりMackerelに詳しいと思うものもあれ ば、ヘルプに記載があるようなものも多い。 • 一つ一つ丁寧に回答したら解決するのだろうか...
  5. ”真の”課題のヒアリングの 手法と特性 方法 特性 コスト 対象数 テクニカルサポート ユーザーが今直面している具体的な課題がわか る。ただし長期的な課題までは現れにくい。 中

    中 アンケート 低コストで広くユーザーの声を聞ける。ただし、アン ケートの設計やユーザーによって回答品質にばらつ きが出るため、有効な意見を抽出する難易度は高 い。 低 多 インタビュー インタビュー設計によっては踏み込んだ質問ができ る。将来の展望など中・長期的な課題についても聞 ける。 大 少 ワークショップ 分析できていない課題の掘り起こしから。潜在的な 課題を言語化できる。 大 少 特性を生かして&組み合わせてユーザーの真の課題を発見する必要がある。
  6. 課題の解決方法 (CREが切れるカード) 必要なものを、必要なタイミングで。基本的には自走を目指す。カードがなければ用意する。 方法 特性 Mackerel のアップデート (フィードバック) ユーザーが自走できるための根本解決。 テクニカルサポート

    素早い解決、代替案の提示。自走のための力強いアシスト。 ハンズオン・セミナー 全体像や体系立った概念を伝えられる。知識の下地づくり。 ヘルプドキュメント・ブログ すでに蓄積されたノウハウをユーザーが触れやすい状態にする。 (プリセールス) ユーザーが課題にぶつかる前に下準備する。
  7. ケース 1:反応が薄い ◉ 1年以上利用があるユーザー。より踏み込んだサポートがしたい ので利用状況をヒアリングさせてほしいと連絡しても反応がな い。NPS(アンケート)への回答もない。 ◉ 数回の連絡の後、やっと訪問できることに。 ◉ 担当はSREチームのリーダー。

    ◉ 「Mackerelの利用で何か困っていることはありませんか?」という 質問にも「うーん...」とやっぱり反応薄... • 訪問を承諾してくれたのに、反応が薄い。 • あんまり困ってないのにしつこくしちゃったかな。 再掲
  8. ケース 1:反応が薄い  「インタビューでコンテキストの共有」 ◉ ユーザーの背景を探る質問にシフトチェンジした ◦ 最近Mackerelにログインしたのはいつですか? ◦ 最近アラートが鳴ったのはいつですか? ◦

    どういう障害でしたか? ◉ 結果、とてもよく活用いただいていることがわかった ◉ その反面、コミュニケーションがなかった利用初期に特定の機能に 苦手意識を抱いたまま機能の利用を断念していた 参考:UXリサーチの道具箱 ―イノベーションのための質的調査・分析 • その場で不明点を解決しつつ、サポートをもっと気軽に活 用してほしいと案内。期待値を回復。
  9. ケース 2:情報量は多いけど... ◉ それまで目立ったやりとりがなかったユーザーからサポート宛て に、まとめて十数件の機能要望一覧をもらった ◉ 要望の例) ◦ プロトコル(HTTP/HTTPS以外)を指定して外形監視ができない ◦

    内部のネットワーク機器の監視ができない ◦ ダッシュボード上でグラフの表示期間の変更ができない • たくさんのご指摘。ネガティブな印象を持たれている? • 要望にはかなりMackerelに詳しいと思うものもあれ ば、ヘルプに記載があるようなものも多い。 • 一つ一つ丁寧に回答したら解決するのだろうか... 再掲
  10. ケース 2:情報量が多い  「関係者を集めたワークショップで課題を深掘り」 ◉ 訪問してヒアリングしたところ、要望をくれたのは現場の複数の ユーザー ◉ 取りまとめてくれた担当者が、現場へのスキルトランスファーに苦 労していた •

    関係者を集め、ユーザーの監視の課題を洗い出し、 Mackerelでの解決方法を見つける方法を伝えるワークショッ プを開催 • 現場のユーザーが自走できる下地づくりをサポート • 要望で開発が必要なものは背景も踏まえ”目利き”した上で、 プロダクトチームにフィードバック
  11. アンバサダーの位置付け プロダクトチー ム ユーザー CRE OSS Meetup / Drinkup User

    Group Blog Twitter ...etc アンバサダー オーバーラップする部分に アンバサダーがいる