Skimmer はプールサービス業界をリードする業務・物流管理プラットフォームです。スケジューリングやルーティングから請求までを通して現場チームの動きを支え、ソフトウェアが仕事の妨げにならないようにします。
舞台裏では、分散された .NET アーキテクチャが毎週木曜日のリリースを支えています。Web は React、モバイルは .NET MAUI、さらにデプロイ可能な 24 以上のマイクロサービスで構成されています。約24名のスリムで実践的なエンジニアチームで、前年比 40〜50% の成長を続ける Skimmer にとって、見逃されたバグや修正の遅れは致命的です。特に非同期でキュー中心のフローではなおさらでした。
彼らが必要としていたのは「何が起きた？」をクリックひとつで「なぜ起きたのか」「どこで起きたのか」へと変えられるツールでした。
Skimmer が向き合っているのは、ユーザーが「動かなかった」などと書き込む現実の現場です。しかも処理の多くは、キューやバックグラウンドワーカーを介した非同期ジョブとして実行されます。そのため障害の原因は、エラーが表面化した場所やタイミングとは別のサービス、別の時点に存在することがあります。
「サーバーのシグナルは一箇所、ログは別の場所、クライアント／モバイルのクラッシュはさらに別のところ。エラーを投げない問題は何時間もパターン探しに化けることがありました。」— Gary Osteen（品質・オペレーション担当ディレクター）
調子の良い日なら、彼らはエラーの位置を三角測量のように絞り込めました。けれど普段はサポートチケットの会社IDを手がかりに、ログ、バックエンドのメトリクス、クライアントのクラッシュレポートをつなぎ合わせる作業に追われていました。しかも報告者が本当にそのエラーに遭遇した本人であるという前提に賭けるしかありませんでした。
一方で事業は加速度的に成長していました（前年比 40〜50%）。しかしチーム規模はそれに合わせて倍増していません。リーダー陣は現場主義を保ちつつ、「何を変えるべきか」は明確に把握していました。必要だったのはダッシュボードを増やすことではなく、調査の起点を一本化できる開発者が実際に使う場所にある、情報の参照先を一本化できる「唯一の参照元」でした。
課題起点のコンテキスト vs 複雑なセットアップと限られた MAUI 対応
Skimmer はいわゆる定番の APM ツール群を Sentry と比較しました。各ツールを .NET Framework と .NET（Core）のバックエンド両方に加え、Web の React、モバイルの .NET MAUI にも組み込みました。
従来型APMツールで起きたこと
- 基本を超えるとインストゥルメンテーションが破綻した
「シンプルな例を超えた途端、セットアップが面倒になりました。.NET Framework 4.8 と .NET（Core）でドキュメントの整合性が取れていない上、MAUI 対応は限定的、あるいはロードマップにも載っていませんでした。」 - 既存ツールと共存できなかった
「POC を動かすには、今使っているツールを完全に無効化する必要がありそうでした。これでは段階的な導入が不可能です。」 - 統合の摩擦が大きかった
「ログ基盤（Serilog／.NET logging extensions）がサポートされておらず、キューやワーカーを横断しれコンテキストを引き回す綺麗な方法もありませんでした。そのせいでバックエンドのセットアップが止まり、非同期トレースも途中で崩れてしまいました。」
Sentry が選ばれた理由
- ダッシュボード起点ではなく Issue 起点
エンジニアは「障害が起きている場所」から調査を始められます。Issue ページにはスタックトレース（ソースマップ込み）、アプリのバージョン、そのバージョンが本番に出たタイミング、関連コミットが表示され、さらにトレースやリプレイへのリンクもまとまっています。
「起きていることを教えてくれるツールはたくさんありました。Sentryはなぜ起きたのか、どう直すかを教えてくれます。」— Glenn Burnside（開発担当VP）
- 非同期の処理が1本のトレースとして繋がる
キューやワーカーを横断してもトレースが崩れないため、React のクリックが API 呼び出し → キュー投入 → バックグラウンドハンドラ → DB という流れでも、ひとつのストーリーとして読無事ができます（publish → dequeue → handle → query）。ステップが別サービスで数秒から数分後に実行される場合でも同様です。
「ユーザーのアクションをキューのメッセージングとハンドリングまで関連付けられる。全部ひとまとまりで見ることができます。」— Glenn Burnside（開発担当VP）
- 開発者のための設計（モバイルも含む）
ワークフローが彼らのスタックと習慣に合っていました。 .NET（Framework／Core）、React、.NET MAUI、リリース、ソースマップ、そして Serilog と相性の良いパターンまで、前提として組み込まれています。
「多くのツールは運用（ops）起点に感じました。Sentry は開発者起点で、私たちのやり方に合っています。Issue ページひとつで必要なコンテキストが全部揃う。スタックトレース＋ソースマップ、リリース／バージョン、コミット、環境／デバイス。トレースとリプレイにもワンクリックで飛べる。答えにたどり着くのが速いです。」— Glenn Burnside（開発担当VP）
- オーバーヘッドが小さく、立ち上がりが速い
各要素がつながっているので「全部が1ページにまとまっていて、クリックひとつでどこへでも行けると学習コストが下がる」という実感がありました。
「開発者体験が決め手でした。Issueの情報が明確で、ソースマップとリリースもきちんと連携されている。しかもキューをまたいでもトレーシングが崩れない。チームが『何が変わった？』に何時間もかけず、数分で答えられるようになりました。」— Gary Osteen（品質・オペレーション担当ディレクター）
Sentryの展開（そして 12.7 リリース）
Skimmer は、Sentry を24以上のプロジェクトに組み込みました。Web の React、.NETマイクロサービス（Framework／Core）、そして .NET MAUI のモバイルアプリです。今ではすべてのデプロイにリリース情報とコミットのメタデータが紐づくため、Issue から「本番に出た変更点」を正確に特定できます。ソースマップによりスタックトレースは読みやすくなり、環境タグ（test／prod）によってノイズも切り分けられます。
1本のトレースで解決までが3〜10倍高速化
Skimmer のトラフィックはリクエストスレッド内で完結しません。React のクリックが API 呼び出しになり、キューに publish され、数秒後にバックグラウンドワーカーが DB へ書き込みます。以前はこの一連の流れは推測に頼るしかありませんでした。
今は同じトレース／コンテキストが各ホップを通って流れるため、全体がひとつのストーリーとして読めます（publish → dequeue → handle → query）。分散されたホスト上でエラーが表面化してもエンジニアは元のユーザー操作まで遡れます。たとえ別のサービスで、別のタイミングで起きていたとしてもです。
「React アプリから API への引き継ぎ、メッセージがキューに入るところ、ワーカーが dequeue するタイミング、ハンドラが処理する流れ… 全部がひとまとまりで見えます。」— Glenn Burnside（開発担当VP）
この「つながった視界」によって、調査時間は劇的に短縮されました。以前は原因の筋道を立てるだけで何時間もかかっていた Issue ですが、今は数分で片付くようになり、軽微なものは「数十分」から「数秒」へと縮みました。
「サービスを横断し、しかも“分単位で遅れて起きる処理”のデバッグは本当に難しい。今はトレースを開けば request → queue → worker → DB がひとつのタイムラインで見ることができます。」— Glenn Burnside（開発担当VP）
フロントエンドでも効果がありました。パフォーマンスのシグナル（TTFB、ロングタスク、リソースのウォーターフォール）が同じトレースの横に並ぶため、調査中の流れのままパターンを見つけられます。ある調査では、トレースから「あるクライアント経路が同じエンドポイントを8回連続で叩いている」ことが一目で分かりました。次に何をすべきかも明確でした。
「トレースでクライアント側の経路が同じエンドポイントを8回呼んでいるのが分かりました。小さな変更を入れて、次のリリースで出しました。」
Session Replay で MTTR を約95〜99%短縮し、状況確認の「往復」を大幅削減
サポートには「今日はアプリが動かなかった」といったメールが、追加情報なしで届くことがよくあります。プール清掃の現場に出ている技術者は、そう送ったあとすぐ作業に戻ってしまうのが Skimmer の現実です。以前は再現手順を把握するだけで何日もやり取りが続き、場合によってはディスパッチャー（配車担当）経由になることもありました。どの画面を見ていたのかを知るためだけに、管理者に「Bobにスクリーンショットの撮り方を教えて送ってもらって」と頼むことすらありました。
今ではそうしたチケットには Issue 上に Session Replay が添付された状態で届きます。チームはリプレイを開いて、エラー発生時にユーザーが実際に何をしていたかをそのまま確認できます。追いかけ回す必要も、推測もありません。Gary の言葉を借りれば、これは「顧客課題の解決までの時間を数日から数分へ短縮してくれる」もので、全社ミーティングでデモしたときには「サポートチームが嬉しすぎて泣きそうになった」ほどでした。
12.7 リリース：モバイルの兆候検知が「週遅れ」から「ほぼリアルタイム」へ
転機となったのはモバイルの 12.7 リリース でした。段階的ロールアウトは10%から開始（通常は100%到達まで約7日）。ロールアウト開始から数分で、Sentry がそのリリースに紐づく異常な挙動を検知しました。顧客からの報告を待つ前にチームは Issue を開き、トレースとリリースマーカーを手がかりに変更点まで遡ってパッチを作成。同じ段階的ロールアウトの最中に修正をリリース し、通常より数日早く100%まで展開できました。
「私たちは顧客体験の“先”にいました。こちらで先に気づいて、直して、顧客が遭遇する前にパッチをストアへ出せたんです。」— Gary Osteen（品質・オペレーション担当ディレクター）
約5日後、アプリストアから「通常よりクラッシュ率が高い」というメールが届きました。ありがたいけれど、遅い。修正はすでに本番で動いていました。
「モバイルでは、“1週間遅れ”から“ほぼリアルタイム”になりました。」— Gary Osteen（品質・オペレーション担当ディレクター）
コンテキストの切り替えゼロで扱えるログ
Skimmer が本番環境で Sentry Logs を有効化すると、1週間目の時点でデバッグのやり方がすぐに変わりました。別システムで場当たり的なクエリを組み立てる代わりに、エンジニアはクリック操作だけでフィールド単位にグルーピング／集計でき、数秒でパターンを見つけられます。
導入初日から単純だけれど厄介な原因が浮かび上がりました。2つのサービスが info ではなく debug でログを吐いており、ノイズが膨らんで重要なシグナルが埋もれていたのです。ログがIssue／トレース／リプレイの隣に並ぶようになったことで、トリアージは一箇所で完結するようになりました。
「Issue から直接ログへリンクできるので、調査のために Sentry を離れることがなくなりました。トリアージが速くなり、運用するスタック全体もシンプルになりました。」— Gary Osteen（品質・オペレーション担当ディレクター）
成果
- モバイルの Issue 検知が95%高速化
- モバイル修正のリリースが60%高速化：6〜7日 → 2〜3日
- 顧客チケットの解決が10倍高速化：Session Replayによりサポートの状況確認のやり取りが「数日」から「数分」へ短縮
- パフォーマンス課題のトリアージが90%高速化：パフォーマンスアラート＋「遅いDBクエリ／スパン」を正確に示すトレースにより時間〜日単位 → 数分へ
Original Page: How the #1 pool management system is shipping ~65% faster with 50% YoY growth and 0 extra tabs
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
