Sentryの導入効果をレビューでご紹介(アセンド株式会社-丹羽健)

参考になった

レビュー投稿日の情報になります

アセンド株式会社 / 丹羽健

CTO・VPoE / CTO / 従業員規模: 11名〜50名 / エンジニア組織: 10名以下

最終更新日2024/04/09投稿日2024/04/09

利用プラン	ツールの利用規模	ツールの利用開始時期	事業形態
Team	10名以下	2021年8月	B to B

導入の背景・解決したかった問題

導入背景

2021年の創業期のプロダクト開発初期からSentryを導入していました。当時のエンジニア２名の限られた開発人員でQAが不十分な中で迅速に顧客検証を進めていく上で、実行時エラーの収集をしながら品質も高めていくことも欠かせない状態でした。
エラーは人としてできれば見たくない忌避されやすいものだからこそ、日常的に利用するツール=Slack上で気軽にエラー監視ができる良い開発者体験を文化形成の面でも大切としていました。
トランクベース開発を初期から現在まで実行していますが、エラーはどうしても抜け漏れて発生します。エラーが起きても即座に気がつき、数分で治すことができるという心理的安全性を作ることもエラー監視ツールに求めていました。
プロダクト開発の初期段階から意欲的に導入したため導入以前の状態はなく比較ができませんが、Sentryがなければ検証ユーザーからの問い合わせの電話で初めてエラーを知ることになるため品質改善の面で大きく出遅れていたことは容易に想定されます。

比較検討したサービス

New Relic
Cloud Watch Logs

比較した軸

プロダクト開発の全体体験として情報をSlackに収集することを前提としていました。その上でSlackに通知されるエラー内容が簡潔で見やすいことを重要としていました。

選定理由

Slack通知の体験の良さに加えて、創業期のスタートアップとして料金の安さもポイントでした。

導入の成果

Slack上でのスムーズなエラー監視という点で大きく満足しています。
プロダクト開発の初期からGitOpsで5分以内にデプロイができる開発環境を作っていたことも功を奏した点で、Sentryからエラーが上がって平均で20分以内にエラーを解消することができていたため、プロダクト品質が安定しない頃から顧客から即座に直してくれるという信頼を得ることができ、プロダクトの検証をスムーズに進めることができました。

導入時の苦労・悩み

導入時の苦労は特段なく、フロントとバックエンド含めて１時間の改修でSentryの最低限の導入が完了しました。

社内への展開について

「全員でエラーを見る」という文化の構築を大切にしました。
Slackに通知されたエラーに対して即座にスレッドにコメントをすることやEmojiをつけて、導入担当者として率先的にエラー監視のコミュニケーションを産むことを目指しました。
Slackというコミュニケーションツール上にエラー監視が乗っていることは文化構築の上で不可欠な点であり、また、エラー監視においてオオカミ少年化は避けるべきであるので、ネットワーク状況等のクライアント側の環境に起因するエラーはフィルタリングされるように早い段階で設定を強化しました。

導入に向けた社内への説明

経営陣・上長への説明

CTOの自分自身で導入を決定したため説明コストはありませんでした。Sentryの導入コストは安いため顧客からのコールの対応時間の削減を考えても、費用対効果は簡単に見出すことはできました。

活用方法

プロダクト初期検証を経て製品版として安定したものをリリースしている今でもSentryは欠かせない存在です。今も変わらずトランクベース開発で1日あたり6回デプロイする頻度で開発を進めていますが、Sentryがあることでエラーが抜け漏れても即座に気がつくことができる心理的安全性を生んでおり、現在まで開発生産性を落とすことなく来れました。
導入後にはエラーの可視性を上げるためにReleaseTagの設定、SourceMapのアップロード、ユーザやテナント情報のカスタムタグ設定をしています。

よく使う機能

基本的にはAlertを中心に利用しており、Slackへの通知を起点にSentryの画面からエラーの発生状況・原因の分析をしています。
2023年にリリースされたSession Replayが地味に便利でありがたいです。エラー発生に至るまでのユーザの行動をアニメーションで見ることができるため原因特定に役立つことはもちろんですが、ユーザのプロダクトの操作状況を事細かに見ることができるためプロダクト改善のヒントを得る機会ともなっています。