この記事の内容
MTTR（平均修復時間）は、設備の故障後、あらかじめ定義した修理または復旧の過程にかかる時間の平均です。比較可能な復旧完了案件について所要時間を合計し、その案件数で割って求めます。
MTTR = 修理時間または復旧時間の合計 ÷ 完了した案件数
割り算そのものと同じくらい重要なのが、何を「時間」に含めるかです。部品の交換は40分で済んでも、設備が使えない時間は3時間に及ぶことがあります。役に立つ報告書は、この違いが分かるものです。保全部門は改善すべき過程に取り組め、生産部門は実際に使える能力に基づいて計画を立てられます。
MTTRは過去の故障を把握するための指標であり、今起きている故障がいつ直るかを示すものではありません。現在の復旧見込みには保全部門による最新の判断が必要であり、見込みが変われば生産スケジュールにも反映する必要があります。SkyPlannerは、更新された設備の使用可否を共有スケジュールに反映します。関連するすべての作業順序を手作業で組み直さなくても、受注への影響を確認できます。
まず、MTTRで測る時間の範囲を決める
MTTRは平均修理時間、平均回復時間、平均復旧時間などの意味で使われますが、これらが必ず同じ区間を指すとは限りません。IECのディペンダビリティ用語では、MTTRに平均復旧時間（mean time to restoration）を用いています。実際に修理作業を行った時間だけを集計する報告書は、保全担当者や予備部品を待つ時間も含める報告書より、捉える範囲が狭くなります。
本ガイドの製造現場向け計算例では、MTTRを、設備の故障発生から生産に使用できると確認されるまでの経過時間として測定します。対応までの遅れ、診断、待機、修理、試験、さらに設備を再び使用するために必要な使用許可の手続きまで、計時を続けます。実修理時間は別に記録します。
このルールを、対象設備の範囲と集計期間とともに報告書の冒頭に明記してください。社内規定、契約、報告基準で別の測定区間が定められている場合は、その定義に従い、何を測った値かを明示します。測定範囲が一致しないまま、その値を本ガイドの値と比較してはいけません。
3時間の停止でも、実修理時間ははるかに短いことがある
08:00に故障したマシニングセンタが、11:00に生産への使用を許可されたケースを考えてみましょう。この案件の記録を、次の段階に分けます。
| 段階 | 時間帯 | 所要時間 |
|---|---|---|
| 保全対応待ち | 08:00–08:30 | 30分 |
| 診断 | 08:30–08:50 | 20分 |
| 必要な部品の到着待ち | 08:50–09:50 | 60分 |
| 修理作業 | 09:50–10:30 | 40分 |
| 機能試験 | 10:30–10:40 | 10分 |
| 生産への使用許可に必要な確認 | 10:40–11:00 | 20分 |
| 復旧までの総経過時間 | 08:00–11:00 | 180分 |
この例で別途集計する実修理時間には、診断、修理作業、機能試験を含めます。合計は20 + 40 + 10 = 70分です。一方、復旧までの経過時間は180分です。どちらかが誤りなのではなく、それぞれが答える問いが異なります。
この区別によって、どこに手を打つべきかが分かります。40分かかる部品交換を改善しても、部品を待った一時間はなくなりません。逆に、部品の入手性を改善しても、診断の難しさは解消されません。
この例では各段階が順番に進みますが、実際の故障対応では作業が重なることもあります。経過時間を重複して数えてはいけません。2人の保全担当者が一緒に40分作業しても、停止時間が80分になるわけではありません。作業工数は保全コストの分析に役立ちますが、設備の経過時間と置き換えることはできません。
故障と無関係なロスは含めない
案件の終了時点は、設備があらかじめ合意した復旧条件を満たした時点です。後から保全作業指示を完了処理した時点ではありません。11:00に使用可能になっていても、次の受注品の材料が正午までそろわなければ、その一時間は材料待ちです。復旧時間にさらに一時間を加えることはしません。
同様に、計画的な整備、通常の段取り替え、作業者待ちが、そのまま故障修理に当たるわけではありません。停止した時間をすべてMTTRに入れるのではなく、各ロスを適切な区分で記録してください。この報告書が測るのは、定義した設備故障からの復旧時間であり、工場全体のあらゆる停止時間ではありません。
比較条件のそろった復旧完了案件を選ぶ
まずは1台の設備、または設備と故障の種類を実際に比較できるグループを対象にします。小さなセンサーの交換も大規模なオーバーホールも、集計対象として妥当な場合があります。ただし、その内訳を示さずに平均すると、解決すべき問題が見えなくなるおそれがあります。
月次報告では、その月に復旧が完了した案件を対象とする方法が実用的です。前月に発生した故障でも、案件の全所要時間を使います。分母は、それらの復旧完了案件の数です。その月に報告されたすべての故障件数や、保全作業指示に記載された全明細数ではありません。
毎月同じルールを適用し、集計の根拠となる記録を残してください。特に、次の点に注意します。
- 未解決の1件の故障には、1つの案件IDを使います。アラーム、担当者、保全作業指示上の作業が複数あっても、復旧が複数件あったとは限りません。
- 未完了案件も見えるようにします。月末時点で修理が終わっていなければ、最終的な復旧時間はまだ確定していません。現在までの経過時間と状況を別に示し、所要時間0時間の修理完了案件として扱わないでください。
- 記録された時刻を確認します。事務処理上の入力時刻が、故障発生、対応開始、復旧の時刻とは限りません。故障発生時刻が不明なら、それより前の時刻を作り出すのではなく、実際に把握できている検知時刻を明示します。
- 除外内容を明示します。時刻の欠落、取り消された記録、計算対象外とした案件区分を説明してください。平均値が悪く見えるという理由だけで、対象条件を満たす長時間の修理を除外してはいけません。
長期停止が未解決のまま残っていると、完了案件だけの報告では数値が不自然に良く見えることがあります。だからこそ、平均値と併せて未完了案件の一覧を示す必要があります。代わりに期間内に発生した故障を対象とするなら、その一群を復旧まで追跡し、未完了案件の扱いを説明してください。説明せずに2つの集計方法を切り替えてはいけません。
MTTRの計算例
集計対象月に、同じ設備で4件の復旧が完了したとしましょう。各案件には、先ほど定めた経過時間のルールを適用します。違いを説明するために実修理時間の列も残しますが、経過時間には加算しません。
| 復旧完了案件 | 故障発生から使用可能になるまでの経過時間 | 実修理時間 |
|---|---|---|
| A | 90分 | 60分 |
| B：先ほどの08:00–11:00の例 | 180分 | 70分 |
| C | 150分 | 110分 |
| D | 420分 | 240分 |
| 合計 | 840分 | 480分 |
本例の主指標は、次のように計算します。
復旧までの経過時間に基づくMTTR = 840分 ÷ 4件 = 210分（3.5時間）
別に集計する実修理時間の平均は、次のとおりです。
480分 ÷ 4件 = 120分（2時間）
この例で、実作業時間に限った値であることを示さずに「MTTR：2時間」と報告すると、測定した復旧までの総経過時間を過小に伝えてしまいます。一方、定義を添えずに3.5時間と報告しても、何の時間を含めたのか、読み手には分かりません。
時間を合計する前に単位をそろえてください。九十分は1.5時間であり、0.90時間ではありません。対象となる復旧が一件も完了していなければ、その集計対象の平均値は求められません。MTTRを零分とするのではなく、件数を零件、平均値を算出不可として報告します。
複数の設備をまとめて集計する場合は、対象となる各事象の所要時間を合計し、総件数で割ります。設備ごとに修理件数が異なる場合、設備別の平均値を単純に平均してはいけません。また、全体の数値に一部の深刻な問題が埋もれないよう、設備別・故障種類別の内訳も確認できるようにしておきます。
MTTRはどの程度なら良好といえるか？
良好といえるのは、復旧に必要な条件を満たしながら、実務に役立つ一貫した測定方法で復旧プロセスの改善を確認できる場合です。すべての生産設備や故障の種類に当てはまる、一律の目標時間はありません。
同じ設備について、条件が似ているときの基準値と比較してください。平均値が下がった理由を修理能力の向上と判断する前に、故障の種類の構成、各シフトの対応体制、保全方法、報告ルールが変わっていないかを確認します。担当チームが同じように適切に対応していても、単純な故障が数件あった月は、複雑な故障が1件あった月より良い数値になることがあります。
平均値は、件数、損失時間の合計、個々の所要時間、遅れが生じた段階と併せて読み取ります。4件の例で復旧までの経過時間を短い順に並べると、90分、150分、180分、420分です。中央値は165分、平均値は210分となります。最後の長時間を要した事象は調査すべき対象であり、数値をそろえるために除外してはいけません。
また、MTTRだけでは設備がどの程度の頻度で故障するかは分かりません。平均故障間隔（MTBF）は、修理可能な設備の故障1件当たりの稼働時間を表します。短い故障が頻発する場合と、長い故障がまれに発生する場合では、損失時間の合計がたまたま同程度でも、必要な改善策は異なります。
特に重要なのは、3.5時間という平均値は、次の修理の完了までをカウントダウンする値ではないという点です。今起きている故障には、別の部品や専門担当者、確認作業が必要かもしれません。比較可能な過去の実績を検討材料にしたうえで、保全部門に現時点の見立てと次に状況を見直すタイミングを確認してください。
生産再開を実際に妨げている遅れを減らす
対策を選ぶ前に、長時間を要した事象を段階ごとに分けて確認します。最も有効な改善策は、必ずしも実作業を速めることではありません。作業を始めるまでの遅れを取り除くことかもしれません。
初動が遅い場合は、故障の情報が担当者に届くまでの流れと、シフト交代時の対応の引き継ぎ方を見直します。単に「生産が止まった」と伝えるより、設備の識別情報、確認された症状、明確なエスカレーション経路がある方が、保全部門は対応に着手しやすくなります。
診断に時間がかかっている場合は、必要な設備情報や故障履歴、専門知識を得やすくします。繰り返し起きる故障は、保全部門や技術部門と一緒に検討してください。設備のリセットを繰り返すと、記録上の1回当たりの停止時間は短くなっても、原因は解消されないことがあります。
部品待ちが時間の大半を占める場合は、どの部品が必要だったのか、それをどう特定したのか、なぜ入手できなかったのかを調べます。あらゆる部品を在庫するよりも、重要予備品の確保や特定方法に絞って改善する方が有効な場合があります。3時間かかった例では、60分の部品待ちは明らかに調査すべき点です。ただし、それだけで特定の在庫方針が妥当だと判断できるわけではありません。
修理そのものに最も時間がかかっている場合は、事前準備、修理箇所へのアクセス、工具、作業手順、その作業に必要な技能を見直します。試験や生産再開の承認がボトルネックなら、必要な担当者と確認作業をどのように手配しておくかを関係者で決めてください。改善とは、復旧に向けた準備を整えることであり、計測を早く終わらせるために確認を省くことではありません。
選んだ対策には責任者を決め、その後の比較可能な事象で効果を確認します。各段階の所要時間と、復旧までの総時間の両方を確認できるようにしてください。修理の工程が短くなっても、同じ時間が別の待ち時間に移っただけの場合や、不完全な作業が原因ですぐに再停止した場合は、生産上の効果は限られます。
修理の状況変化に合わせて生産計画を最新に保つ
今後の復旧を改善することと、今日の顧客との約束を守ることは、別の課題です。次に何を生産するかを決めるのに、月末の平均値が出るまで待つことはできません。
例えば、保全部門が当初、マシニングセンタの復旧を11:00と見込んでいた場面を考えてみてください。その後の再評価で、復旧見込みが14:00に変わりました。過去のMTTRは変わっていませんが、加工待ちの受注に使える生産能力は変わっています。ある受注は加工後に検査も必要で、代替のマシニングセンタにはすでに別の顧客向けの作業が入っています。
SkyPlanner APSは、この生産能力の変化を、工程間のつながりを反映した生産スケジュールに組み込みます。保全部門が確認した使用不可期間を、リソースの例外として登録します。復旧見込みが変わったら、時間帯を更新して再計算してください。SkyPlannerのスケジューリング用人工知能であるArcturusは、設定されたリソース、工程間の依存関係、優先順位、ロックを用い、登録された生産能力の範囲で、影響を受ける工程のうちスケジュール可能なものを組み直します。その結果の作業順序はガントチャートに表示されます。
復旧が14:00になる場合、待機中の加工作業を進めても、検査と納品に必要な時間を確保できるか確認します。適切な代替リソースに工程を移せる場合は、そのリソースにすでに割り当てられた作業の納期なども確認してください。すでに着手した作業については、別途、再開の判断が必要です。待機中の作業を再スケジュールしても、中断した作業の状態確認の代わりにはなりません。
これにより、相互に依存する作業順序を手作業で組み直す負担が減り、納期判断の根拠も明確になります。現時点の復旧見込みは保全部門が責任を持って判断し、生産の優先順位は生産計画担当者が決めます。設備ごとの作業リストを個別に修正するのではなく、Arcturusが関連する作業全体のスケジュールを計算します。
修理改善の取り組みと併せてSkyPlannerを選ぶ理由は、ここにあります。設備を再び使用できる時期の想定を見直すと、その変更が影響する受注や後工程にも反映されます。不確実な点が残る場合は、次に想定を見直すタイミングを決め、より確かな情報が入り次第、スケジュールを更新してください。
1件の故障の長期化が納期に与える影響を確認する
役立つMTTRレポートからは、何を測定したのか、どの事象から平均値を求めたのか、どこから改善に着手すべきかが分かります。役立つ生産計画からは、今の修理が進む間に何をすべきかが分かります。これらの判断を結び付けることで、適切な保全分析を、実務から切り離された月次の数値で終わらせずに済みます。
SkyPlannerは、公開されたREST APIを通じてあらゆるERPやMESと連携できるため、既存の受注情報や生産情報を活用し、関連する工程をつないだスケジューリングを行えます。
最近の故障事例1件と、見直し後の復旧見込み、そのリソースを使う顧客受注の情報をご用意のうえ、SkyPlannerのデモを予約してください。デモでは、待機中のどの工程の予定が変わるか、後工程にどのような影響があるか、どの受注の納期に注意が必要かを確認したいとお伝えください。まずご自身で操作してみたい場合は、デモデータでSkyPlannerを試すことで、生産能力の変化によってスケジュールがどう変わるかを確認できます。
Jussi Mäntylä
生産計画スペシャリスト、SkyPlanner
