toC webサービス事業の顧客信頼性エンジニアリング(CRE)について考える

前書き

• 顧客信頼性エンジニア≠顧客信頼性エンジニアリング
• 「ロール」ではなく「エンジニアリング=工学」を考えたい
• webサービス事業の文脈なのでエンジニアリング=ソフトウェアエンジニアが中心に関わる方法論です

「工学」に自分が期待すること

特定の課題領域に対して、

• 体系立てられた知識
• 事象の計測・評価方法
• 適切な抽象化によって一定の再現性がある改善や課題解決へのアプローチ手段

を提供してくれること。
（あくまで「期待」であって、言葉の定義としての正しさではない）

CREの課題領域は何なのか？(why)

サブスクリプション型ビジネスにおけるLTV最適化の文脈で、

• 顧客がサービスに対して持ちうる「サービスの継続利用を阻害する不安」をどのように評価し、どうそれを小さくするか

もしくは、

• サービスをより長く継続利用してもらうために「サービスへの不安を感じない=信頼性が高い」状態をどう実現し、どう継続するか

またメタな課題として、

• 上記課題にソフトウェアエンジニアがどう寄与していくか

と考えた。

toC であって toB でない理由

• Google Cloud Platform Japan 公式ブログ_ Google の新しい専門職 _ CRE が必要な理由
• 〇〇社用みたいなコードは生み出さないように　はてなCREがユーザーからの要望ではなく背景を大事にする理由 - ログミーTech

toB の事例ではエンジニアがカスタマーサクセスの振る舞いを行う合理性が十分に説明されていると感じている。
toC の良い事例が見つけられていないので、思考整理を兼ねて書いています。

CREが取組むべき事柄(what)

自分が現在所属しているチームで顧客不安観点で意識していること、および取り組みたいことを列挙してみた。

• カスタマーサポート領域
  • テクニカルサポート
  • サポート周りの運用改善
  • プロダクト不備の特定とサービス改善
• アプリケーションセキュリティ
  • 脆弱性の検知と除去
  • 最新追従を実現する開発手法
• アプリケーションパフォーマンス
  • Latency遅延エンドポイントの特定と改善
  • Latency不安定なエンドポイントの特定と安定化
• UI・UX毀損の予防、局所化、検知、改善
  • E2E自動テスト
  • 段階的リリースと安全なロールバックの実現
  • エラー検知と改善
  • フロントエンドパフォーマンスの計測、評価、改善

どのように取組むか(how)

具体的なツールや技術要素、求められる振る舞いなどを列挙してみた。

• テクニカルサポート
  • BigQuery・Redashを活用したデータベースレコードやアクセスログの確認、分析
  • プロダクトの仕様とアプリケーション挙動を理解した上での非エンジニアとのコミュニケーション
• サポート周りの運用改善
  • ZendeskやSlackなど外部ツールも含めた運用設計
  • 問い合わせ業務の分析と内製調査ツールの開発運用
• プロダクト不備の特定とサービス改善
  • 問い合わせ内容の咀嚼と顧客要望の抽出
  • プロダクトバックログ起票とプロダクトチームとのコミュニケーション
  • アプリケーション改修
• 脆弱性の検知と除去
  • 脆弱性診断の実施
  • Dependabot Security Updates の定期的なチェック
  • アプリケーション改修
• 最新追従を実現する開発手法
  • Renovate、Dependabotの依存関係更新ツールの活用
  • Unitテスト:PHPUnit, RSpec、E2Eテスト:Cypress, Autify の自動テスト整備
• Latency遅延・不安定エンドポイントの特定と改善
  • Datadog モニタリングツールの活用
  • アプリケーション改修
• E2E自動テスト
  • 網羅的なユースケース整備
  • Cypress, Autify によるユースケーステストの実施
• 段階的リリースと安全なロールバックの実現
  • ECS + CodeDeploy による Blue/Green デプロイメント
  • カナリアリリース
• エラー検知と改善
  • Sentry によるモニタリングとIssueトリアージ
  • アプリケーション改修
• フロントエンドパフォーマンスの計測、評価、改善
  • Sentry Performance
  • アプリケーション改修
  • 仕様からの抜本改善の提案

通常のWebサービス開発運用で普通にやっていくべきことでは？

それは本当にそう。

改めて現時点の見解でCREを表現するならば、

「ソフトウェアエンジニアリングの観点かつ顧客指向で課題発見・課題定義を行い、Webサービス開発運用の全てのライフサイクルで継続的改善に取り組みビジネスへ寄与するための方法論」

と個人的には考えています。そして「全てのライフサイクルで」と書きましたが、これはもうフルサイクル開発者の話を意識しました。

• Netflixにおけるフルサイクル開発者―開発したものが運用する - VOYAGE GROUP techlog

Support = CRE？と短絡的に考えてしまいがちだけど、顧客指向で課題定義すれば Operate, Deploy, Test のライフサイクルでも CRE としてのアクションアイテムがありそうという考えを持ちました。アンドパッド社ではCREチームにQAを内包しているのは興味深い事例だと捉えています。

• アンドパッドのCREチームを紹介します！ - ANDPAD Tech Blog

他組織の事例を知りたい

今ここで書いてある内容は私という1エンジニアの1事業における経験則であって、事業の形や規模・フェーズで様々なCREが定義できそう。他事業ではどうCREが定義されるかがものすごく興味があります。そこらへんのお話できる方がいらっしゃればぜひお話したいなと思います。