1 MTTR（平均修復時間）とは
1.1 定義と目的
1.1.1 平均修復時間の考え方
MTTR（Mean Time To Repair／平均修復時間）は、障害や不具合が発生してから復旧するまでに要する時間の平均値を表す指標である。ここでいう「復旧」は、単に作業が完了した状態ではなく、サービス利用者の観点で支障が解消され、定常運用へ戻ったと判断できる状態を指す。平均で示すため、個別の案件ごとのばらつきがある前提で、運用の復旧能力を俯瞰する役割を持つ。
1.1.2 運用改善における位置づけ
MTTRは、障害が起きた後の改善余地を把握するうえで中心的な指標となる。とりわけ、復旧までの時間が長引く原因は、作業そのものよりも検知から診断、承認、部品手配、復旧作業、検証の各段階に潜むことが多い。したがってMTTRは「修理の速さ」のみならず、対応プロセス全体の設計品質を評価するものとして扱われる。
1.2 関連用語との関係
1.2.1 MTBFとの違い
MTBF（Mean Time Between Failures／故障間平均時間）は、障害の発生間隔に関する指標である。対してMTTRは、障害発生後の復旧に焦点を当てる。両者は独立ではないが、改善の打ち手が異なる傾向がある。たとえばMTBFは設計・冗長化・予防保全に寄りやすく、MTTRは検知、手順、体制、復旧作業の最適化に寄りやすい。
1.2.2 MTTDとの違い
MTTD（Mean Time To Detect／平均検知時間）は、異常が検知されるまでの時間を示す。MTTRは検知以降も含めて復旧までの時間を評価するため、MTTR＝（検知から復旧まで）を構成する主要要素としてMTTDが関与する。さらに実務では「検知の遅れ」だけでなく「検知後の診断や承認の遅れ」がMTTRを押し上げる要因になりやすい。
1.2.3 RTOとの関係
RTO（Recovery Time Objective／目標復旧時間）は、業務継続の観点から設定される復旧目標である。MTTRは実績としての平均復旧時間であり、RTOは目標値としての性格が強い。したがって、運用チームはMTTRの改善を通じてRTOの達成度を高めることが多いが、目的はあくまで目標への適合であり、平均のみで評価するとリスク（遅延が発生した場合の影響）を見落とす可能性がある。
2 算出方法とデータ要件
2.1 基本的な計算手順
2.1.1 修復時間の計測開始・終了
検知時刻・復旧確定時刻の定義
MTTR算出では、計測の「開始」と「終了」を組織で一意に定めることが重要である。開始は、異常が正式に認識された時刻（監視アラート発報、有人監視の受領、チケット起票など）に置く。終了は、復旧作業の完了時刻ではなく、合意された検証基準を満たし、サービスが利用可能になったと判定できる時刻（監視指標の回復、疎通確認の完了、顧客申告の解消など）に置く。開始・終了が曖昧だと、集計値が意味を失い、比較も困難になる。
2.2 データ品質と集計条件
2.2.1 障害の範囲（対象設備・影響範囲）
集計対象は、どの設備・どのサービスを「障害」と見なすかで変わる。通信やIT運用では、単一のコンポーネント障害でも利用影響が限定的な場合がある一方、同一機器でも複数の機能に波及することがある。したがって、対象設備の範囲（拠点機器、回線、サーバ、クラウド構成要素など）と、影響範囲（利用者への影響、通信品質、性能劣化の有無）を定義し、同種の案件だけを揃えて平均を計算する。
2.2.2 異常値・打ち切り事象の扱い
極端に長い案件や、途中で方針転換した案件（外部要因で復旧が停止する、作業が期限により打ち切りになる等）をどう扱うかも、計測品質に直結する。実務では、平均値が大きく歪むため、外れ値を別集計とする、打ち切り事象は注記して除外する、あるいは中央値と併用するなどの運用を設けることが多い。目的が「改善の方向性」を掴むことなら、外れ値の内訳を調べ、再現性の有無や要因を分解して扱うのが合理的である。
2.3 分解による分析
2.3.1 切り分け時間
切り分け時間は、検知後に原因を絞り込み、必要な復旧手順に到達するまでの時間である。ログ確認、監視指標の相関、影響範囲の特定、再現の試行などが含まれる。ここが長い場合、観測項目の不足、診断手順の未整備、スキルギャップ、情報伝達の遅れが疑われる。
2.3.2 調達・交換時間
交換に必要な部品・資材の確保、持ち込み可否の確認、ベンダー待ち、輸送、現地作業の手配などが該当する。復旧そのものより「待ち」が支配することがあり、在庫方針、保守契約、交換単位の標準化、代替手段の可用性といった設計に依存する。
2.3.3 手順実行時間
手順実行時間は、復旧手順の実施とその間の作業待機（反映待ち、フェイルバック待機など）を含む。例えば設定変更の反映に時間がかかる、ロールバック条件の確認に時間がかかる、といった事情がある。ここが長い場合、手順の粒度不足、手順の前提条件の不足、検証観点の欠如が原因になり得る。
3 通信技術におけるMTTRの適用
3.1 運用体制と役割設計
3.1.1 監視・一次対応
監視・一次対応は、アラートの受領、影響の初期切り分け、一次診断の実施、チケット登録、優先度付けなどを担う。通信分野では、単なる通信断だけでなく、遅延やパケット損失、経路変更による品質劣化も障害扱いになる場合があるため、一次対応側がどの品質指標を「復旧扱い」にするかも設計対象となる。
3.1.2 二次対応・専門チーム
二次対応では、より深い解析、設定変更、機器交換、ベンダー調整、複数ドメインの整合確認を行う。役割分担が曖昧だと、同じ情報を別チームが確認し直して時間が延びやすい。専門チームへ引き継ぐための情報テンプレート（影響範囲、時刻、実施済み手順、ログ抜粋など）を準備し、復旧判断の前提を揃えることがMTTR短縮に直結する。
3.2 検知から復旧までのプロセス
3.2.1 アラート運用と優先度付け
アラートの過剰通知は作業負荷を増やす一方、見逃しは復旧遅延につながる。優先度付けは、影響範囲、利用者数、品質劣化の程度、SLA要件などを基準に行う。加えて、同時多発時の扱い（どれを先に収束させるか）を事前に決めておくと、診断の無駄な往復を減らせる。
3.2.2 診断手順（ログ・監視指標）
診断では、ログの時系列整合、監視指標の変化点、設定変更履歴、直近の運用作業との関連を確認する。通信では、ルーティング、セッション、伝送品質、認証の状態など複数観測軸があるため、単一データだけで結論に飛ばない運用が望ましい。観測項目が揃っているほど、切り分け時間は短縮されやすい。
3.2.3 復旧手順と検証
復旧手順は、回復操作（設定戻し、切替、再起動、経路変更、交換など）と、動作確認（疎通、品質指標、通信成功率、ログの正常性）から構成される。検証基準は、復旧判定時刻を曖昧にしないための要である。特に、部分的な回復で見かけ上の正常に見えても後で悪化するケースがあるため、利用者影響に近い指標で確認する設計が有効になる。
3.3 ツールと自動化の活用
3.3.1 チケット連携とトレーサビリティ
チケット管理と監視基盤の連携により、事象の履歴を追跡できる。アラートIDとチケットIDの紐付け、実施手順の記録、参照したログや判断理由の保存が揃うと、引き継ぎ時の探索時間が減る。結果として、復旧作業の手戻りも抑えやすい。
3.3.2 自動復旧・ロールバック
自動化は、復旧の初動を速めるだけでなく、再現性を高める。条件を満たした場合に切替や再試行を行い、失敗時には安全側へ戻す設計が望ましい。自動復旧は万能ではないため、誤動作時の影響範囲、監視指標による検証、ロールバック手順の整合が不可欠である。
3.3.3 ナレッジベースの整備
過去の障害から得られた知見を、手順書・判断基準・よくある兆候として整理することで、経験依存を下げられる。ナレッジは「見つけやすさ」と「更新の仕組み」が重要である。古い情報が残ると診断が誤誘導され、MTTRが逆に延びるため、改訂履歴と責任者を明確にする。
4 MTTR改善の進め方
4.1 ボトルネックの特定
4.1.1 ボトルネック指標（待ち時間など）
改善の起点は、分解した時間のうちどこが長いかを特定することである。切り分け停滞、承認待ち、部品待ち、現地手配待ち、検証完了までの待ちなど、「作業していない時間」を可視化する指標が有効になる。特定後は、該当段階の手順、データ、権限設計を見直す。
4.1.2 再現性の低い事象の扱い
原因が一意に定まらず、毎回条件が変わる事象では平均がブレやすい。こうした場合は、共通要素（観測値、発生環境、運用直後の状態など）を抽出して分類し、カテゴリごとの時間分布を確認する。再現性が低いからこそ、学習の観点（観測の追加、仮説検証の設計、手順の分岐）を優先する。
4.2 対応品質の標準化
4.2.1 プレイブック（手順書）の運用
プレイブックは、初動から復旧・検証までの標準手順を定める文書または運用フローである。ポイントは、単なる手順の羅列ではなく、前提条件、確認すべき観測値、失敗時の分岐、復旧判定基準まで含めることにある。運用中に改訂される仕組みも合わせて整えると、現場の判断がブレにくくなりMTTRのばらつきが縮む。
4.2.2 教育・訓練と引き継ぎ
教育・訓練は、技術知識だけでなく、判断の型と記録方法を含めると効果が出やすい。引き継ぎでは「何を見て、何を除外し、次に何を確認するか」を短時間で伝える構成にする。情報の不足は再診断を生み、結果として復旧までの時間を押し上げる。
4.3 継続的改善と学習
4.3.1 インシデント後レビュー
インシデント後レビューでは、時間要素の分解結果、実施手順の適合度、観測データの不足点を整理する。特定の担当者を責めるのではなく、再現条件と判断の前提を明確にし、プロセスの欠陥を特定する。レビューで得た学びは、次のプレイブック改訂や監視項目の追加に接続する。
4.3.2 再発防止策の反映
再発防止策は、技術的対応（冗長化、設定見直し、検知強化）と運用的対応（手順更新、権限整理、訓練）をセットで考える。短期の対処だけではMTTRが一時的に改善しても戻ることがあるため、根本原因と時間要素の対応関係を検証する。
4.3.3 指標のモニタリングと目標設定
目標設定では、単一の平均値ではなく、分布（中央値、上位事象、極端な遅延の割合）も併せて見ることが望ましい。モニタリングは、改善施策がどの段階に効いているか（切り分け短縮か、待ち時間短縮か）を確認するために実施する。これにより、次の打ち手が学習に基づくものになる。
5 よくある課題と実務上の注意
5.1 指標が改善しない原因
5.1.1 計測定義の不一致
組織やチームごとに「復旧の時刻」や「障害の起点」が揃っていないと、改善が実感しづらい。例えば、一次対応完了を復旧とするか、完全にサービスが戻った時刻にするかで数値は変わる。定義の統一と監査（集計ルールの点検）を行わないと、MTTRは改善しているのに観測されないことが起きる。
5.1.2 部品・権限・承認の遅延
復旧が遅れる要因として、部品の調達制約や権限不足、承認フローの長さが挙げられる。技術手順が整っていても、実行に必要な承認が後工程に滞留するとMTTRは短縮されにくい。したがって、例外承認の設計、代替手段の準備、在庫戦略の見直しなど、実行可能性の改善が必要になる。
5.2 誤解を招く運用
5.2.1 「復旧」の基準が曖昧な場合
復旧判定が曖昧だと、作業完了が先にカウントされ、実際の安定性と乖離する。結果として、短期的には数字が良く見えても、再発や後戻りが増える場合がある。復旧基準は、利用者影響に結びついた観測点とセットで明確にする必要がある。
5.2.2 MTTR最適化の副作用
MTTRだけを追うと、原因究明や再発防止の時間が後回しになり、次の障害が早期に発生することがある。さらに、過度な自動化で不適切な復旧操作を増やすと、別の種類の問題が増える可能性もある。改善では、品質（正確性、検証、記録）と安全性（ロールバック、影響範囲管理）を同時に担保する設計が求められる。
6 ユーモアと現場あるある（軽い補足）
6.1 「直ったと思ったらまだ直ってない」問題
復旧確認でよくあるのが、「疎通は通ったからOKだと思ったら、しばらくして別の指標が戻ってくる」パターンである。確認項目の粒度が足りないと、平均値が見かけ上縮んでも、結果として再対応が増えてしまう。
6.2 手順書より先に“勘”で動く夜
緊急時は思考が速くなる一方、勘で進むと記録が薄くなりやすい。あとからチケットを読み返したときに「何を見て判断したか」が残らず、次回の学習が進まない。最終的にそれがMTTRの伸びへつながることがある。
6.3 直すより先に寝落ちしがちな端末確認
現場では、故障箇所に手を出す前に確認するはずの端末が、実は省電力モードで動いていなかったりする。時間が溶けるのは仕方ないが、確認観点を整理していけば、無駄な往復は減らせる。