SREに必要なことはすべて、ランニングが教えてくれた

著者：

2025-12-23

突然ですが、普段から運動していますか？筆者は週5で数km、月間200km走っています。フルマラソンとウルトラマラソン（100km）にも出場して完走経験もあります。こう書くと、元々走れている人だと思われるかもしれませんが、約2年前まではまったく走れませんでした。典型的なITエンジニアなのでデスクワークで大の運動嫌いです。ジム通いしていましたがコロナ禍でたち消えてしまいました。

そんな私ですが、紆余曲折を経て、今は走ることにハマってしまいました。普段はSRE（たまにデータエンジニアも兼ねる）をしていますが、ふと思ったのです。

「SREと、走ることには通ずるものがあるのではないか」と。

そこで本記事では、SREとランニングの共通項を紹介したいと思います。お察しいただけていると思いますが、ネタ記事です。最後までお付き合いいただけますと幸いです。

前提

「システム = 自身の身体」と見立てています。そして、「マラソンをサービス稼働」という視点で考えていきます。人によって走る目的は異なりますが、今回はマラソン大会の完走やタイム向上を目的とします。つまりは、マラソン大会（サービス）において、システム（自身の身体）をいかに安定稼働させるかをSREの観点で見ていきたいと思います。

この考え方に基づいて、以下のメトリクスも定義しました。

可用性: マラソン大会中における走り続ける時間の比率（走る時間 / (走る時間 + 止まる・歩く時間)）
- GoogleのSRE本では、時間を基にしたメトリクスではなく、リクエスト成功率を採用しているが、今回は稼働時間の比率を可用性の定義とする
レイテンシ: ペース（kmあたりの時間）

次に、SREの原則をランニングの観点で見ていきます。

リスクの許容

極端に高い信頼性を追求することは非効率的です。システムの可用性を100%に近づけるためには、膨大なコストがかかります。例えば、可用性を100%にするために、ゆっくり走る戦略を取るとどうなるでしょうか？なるほど、確かに故障リスクや疲労、ペースダウンは避けられます。しかし、時間というコストが膨大になっていきます。例えば、次のような弊害が考えられます。

タイムが遅くなる
関門時刻（制限時間）に間に合わない可能性がある

目的を達成するためには、ある程度のリスクを許容しなければなりません。どの程度のリスクを許容すべきかは、後述のエラーバジェットで決定されます。

サービスレベル目標

自身のパフォーマンスを次のような指標で定義できます。

SLI（サービスレベル指標）: 心拍数、ペース（分/km）、月間走行距離、VO2Maxなど
SLO（サービスレベル目標）: 「ハーフマラソンを歩かずに完走する」「サブ4（4時間切り）を達成する」といった具体的なターゲット

例として、サブ4を目指す場合を考えてみましょう。

SLOとして重視するのは「5:40/km」のペースを維持すること
エラーバジェットを枯渇しない範囲であれば、どのペースで走ってもいい。ただし、ほかのメトリクス（体力など）に影響しないように配慮する必要がある

システム（自身の身体）にとって、過度なサービスレベル（ハイペース）を求めると、エラーバジェット違反に陥りやすくなります。

トイルの撲滅

トイルとは、手作業で繰り返され、自動化が可能、長期的な価値がない作業のことです。ランニング記録を毎回手入力するなどの作業が該当します。スマートウォッチを活用して記録の自動化が必要です。

また、割り込みで始まり、問題などが生じたことへの対応として行われる作業もトイルです。怪我や病気が該当します。予防しないと、ずっと走れない状態になります。痛みを我慢して走ったとしてもパフォーマンスが悪いし、より悪化する一方です。定期的なストレッチやケアで予防することが重要です。

モニタリング

ランニングにおいて、スマートウォッチを活用したホワイトボックスモニタリング（システム内部の状態を監視すること）が不可欠です。身体の状態を以下のメトリクスを監視することで、オーバートレーニングや怪我の予兆を早期に検出できます。

レイテンシ（ペース）: リクエスト（一歩）に対する応答速度
トラフィック（走行距離・頻度）: システムにかかる需要
エラー（怪我・違和感）: システムの不具合の発生率
サチュレーション（心拍数）: リソース（心肺・筋肉）の限界に対する利用率

自動化

SRE本では、「自動化は万能薬ではなく、能力を増幅するもの」とあります。また、人間が介入しなくてもシステム自身が問題を検出し、自己修復する自律的システムを目指しているとも述べられています。そこには、人間による意志の介入を必要としません。

ランニングは継続が何よりも難しいですが、それは意志の力に頼っているからです。そこで、身体を動かすための「自律的な仕組み」を構築します。たとえば、時間の天引き（朝ランなど）、AIランニングコーチによる練習メニューの作成等です。環境さえ整えておき、脳が判断を下す前に身体が「自動的に」走り出す状態（自己修復・自己駆動）を目指します。意志の力に極力頼らず、身体を自律的に動かすための仕組みを整えることが重要です。

リリースエンジニアリング

マラソン大会の出場を「本番環境へのリリース」と定義します。いきなりフルマラソン（メジャーリリース）に挑むのではなく、まず5km、10km、ハーフマラソン（カナリアリリースやプロトタイプ）で段階的に検証を行い、予期せぬバグ（エネルギー切れや足の痛み）を洗い出します。何度もリリースプロセスを繰り返し実施することで、システムの信頼性を高め、本番環境での安定稼働を目指せます。

ポストモーテム

ランニングやマラソンでは、常に失敗がつきものです。

マラソン大会で失速してタイムが伸びなかった…
完走を目指したけど、途中でリタイヤした…

ポストモーテムで重要なのは、非難しないことです。自分を必要以上に責めずに、間違った判断を下すに至ったシステム上の欠陥やプロセスの不備を特定することに集中します。マラソンの場合では、何が原因だったのか（ペース配分、補給のタイミング、トレーニング不足など）を冷静に分析し、次回の改善につなげることが大切です。

まとめ

SREの原則への適用は、自分自身の身体という「システム」を管理するうえでも有効です。これらの考え方は、ランニングだけでなく、人生のあらゆる場面で応用できるのではないでしょうか。

最後に宣伝です。ランニング経験を基にした、『ランニングプログラマー』という本を執筆しました。
本書では、なぜ走るようになったのか、走ることで身体だけではなく、メンタル、仕事、人間関係など、人生のあらゆる場面で起きた変化などについて紹介しています。
ぜひ、ご一読いただけますと幸いです！