Title: A method of decreasing human errors due to the safety operation of IT systems

Date: 2006

Author: Matsuo Sawahashi

Type: IBM Professional Paper

Prize: Winner

--------

安定したシステム運用のためのヒューマンエラー低減方法

沢橋　松王1^＊

A method of decreasing human errors due to the safety operation of IT systems

Matsuo Sawahashi^＊

本論文では，ITシステムを安定的に運用するために，ヒューマンエラーを低減させて，重大障害に至らないようにするための手法を提案する．人は様々な要因によって影響を受け，時として間違った判断・行動を伴うことがある．にもかかわらず従来障害が発生すると直接事故を起こした作業者に非難の目が向けられることが多い．ヒューマンエラーを事故の原因として捉えてしまうと，人を変えるという対策しか浮かばなくなってしまい，再発を防止することはできない．そこで正しい原因分析の手法を提供し，論理的に原因を究明し，正しく再発防止策を打てるようにしなければならない．

この手法では，ヒューマンエラーを発生させた要因について，直接要因だけでなく間接要因，潜在要因を詳細に洗い出し，過去に発生した事故事例を分類する．そして「人間が誤って不適切な操作を行っても危険を生じない，あるいは正常な動作を妨害しない」というフールプルーフの考え方をシステム運用にも適用し，ヒューマンエラーそのものを発生させない対策の作り方を提唱する．最後に，「報告は重大なエラーを未然に防ぐための貴重な資源である」ことから，報告者へインセンティブを与え，小さなエラーも拾える仕組みづくりを提案する．

本論文によって，人に起因しない要因分析の手法が理解できるようになり，フールプルーフを意識した対策を考えられるようになる．また小さなエラーを拾える報告システムの構築方法がわかる．これらの手法によって，システム運用におけるヒューマンエラーを低減させ，重大障害の発生件数を抑えることが可能となる．

In this paper, in order to operation IT system stably, human error is reduced and the technique for making it not result in a serious obstacle is proposed. People may be accompanied by the judgment and action which was influenced and was sometimes wrong with various factors. Nevertheless, generating an obstacle turned its eyes of blame to the worker who caused the direct accident in many cases conventionally. If human error is regarded as a cause of the incident, it becomes impossibly only for the measure of changing people to appear, and a recurrence cannot be prevented. Then, the technique of the right cause analysis is offered, a cause is studied logically, and it must enable it to strike a recurrence preventive measure correctly.

By this method, not only direct factor that checks up the factor which generated human error but an indirect factor and potential factor, and the incident example generated in the past is classified. And the view of the foolproof of "not producing danger even if man performs unsuitable operation accidentally, or not blocking normal operation" is applied also to system operation, and how to make the measure which does not generate the human error itself is advocated. Finally, since "reports are the precious resources" for preventing a serious error, an incentive is given to a reporter and the production of structure which can also gather a small error is proposed.

Because of this paper, you can understand the technique of the attribute analysis which does not originate people, you can consider now the measure which was conscious of foolproof, and you can understand the construction method of a report system that a small error can be gathered. It becomes possible for you to reduce the human error in system operation, and to stop the generating number of cases of a serious obstacle by this technique.

Key Words & Phrases ：システム運用，ヒューマンエラー，フールプルーフ，未然防止，問題管理

　　　　　　　　　　 system operation, human error, fool proof, prevent, problem management

1. はじめに

ITが社会全体の基盤になって久しく，ITシステムの停止は一企業の存亡も左右しかねない状況にあるなかで，相変わらずITシステムの運用は人手によって担われている．その一方で，人は必ず間違いを犯す．故意ではなく，意識的でもなく間違いを犯す．これをヒューマンエラーと定義する．

ヒューマンエラーに関する研究は，航空業界や鉄道業界，プラント業界などで盛んに行われてきており，なぜ人が過ちを犯すのかについては議論されている．しかしITシステムの運用に関しては未だに事故の引き金を引いた作業者を責め，「モラルが低い」と決め付ける経営者の多いことに嘆きすら感じる．また同じ業界内での事故事例が横展開されず，再発防止に十分活かされていないと考える．

そこで，本論文では，ITのシステム運用におけるヒューマンエラー低減のための取り組みを提案する．この手法によって，問題が小さいうちに察知して，重大なインシデントにならないように組織的に対応することができるようになる．

以下，なぜヒューマンエラーが発生するのか背景を検証し，事故原因の分析手法について実例を交えて説明する．次にヒューマンエラーを低減させるための対策の施し方を議論する．そして小さな事故も拾えるための報告システムについて言及する．

2. ヒューマンエラーの背景

(1) 事故は些細なことから始まる

ITシステムはオープン化，分散化が進み，複雑な構成，入り組んだネットワーク，対外接続などが絡み合っている．作業員がコマンドのたった一文字を間違えただけで，システム全体があっという間に停止するという怖さが潜んでいる．

(2) モラルの問題

人は様々な要因によって間違いを起こす．どんなに優秀な人間であってもこの事実を免れることはできない．人に影響を及ぼす要因として，航空分野では病理的，生理的，身体的，薬剤，心理的，社会心理的という６つの要因を分類している[1]．例えば，深夜早朝作業時における意識の低下や，家庭事情による情緒不安定，失敗できないという恐怖，慣れすぎによる不注意，など要因はきりが無く，人によって様々な要因が複雑に絡み合っている．うっかりミスも日常生活上は大きな問題にはならないが，システム変更作業中に起こるとシステム停止を伴う重大障害へと発展してしまうのである．

作業員のミスによってシステム障害が発生すると，ほとんどの管理者はその作業者を責める．これは心理学者が基本帰属エラー（fundamental attribution error）と呼ぶものに関係がある．人間の本質に深く根ざすものであり，観測者と行為者の観点の違いに関わっている．誰かがエラーを起こすのを見たり，聞いたりした場合，われわれはそのエラーがその人の性格や能力に起因すると考えたり，その人の個人的な質のせいにしてしまう[2][3]．

事故を防止するためには，ヒューマンエラーをモラルの問題にしてしまうことなく，論理的に原因を究明する必要がある．

(3) 従来の原因分析手法の問題点

従来の事故原因分析の問題点はヒューマンエラーそのものを真っ先に原因に挙げてしまうことである．ヒューマンエラーは誰でも起こし，ゼロにすることは不可能であるにもかかわらず．

原因を分析しなければならない理由は再発を防止することにある．ヒューマンエラーはどんな優秀な人間でも起こすのであるから，それ自体を原因としても再発を防止するという目的は達せられない．ヒューマンエラーの背後にある真の原因を探求していかなければならない．

3. 事故原因の分析

例えば，ある手順に基づいてシステムを変更していたら，何らかの不具合が発生してシステムが停止する，という事故があった．真っ先に責められたのはシステムを変更した作業員であった．しかし原因を追究していくと，組織の要因が不足していて，正しい手順書レビューが行われていないことが判明した．さらに追及していくと，変更を希望している部門の依頼頻度が尋常ではなく，当初想定していた人員ではとても運用しきれない事実が判明した．このように，事故の直接事象から原因，背景を辿っていくと，全く別の問題点が浮かび上がってくる．

(1) PSFを洗い出す

人間の行動は結果であり，行動に至る流れには，様々な要因が影響している．このような，人間の行動に影響を与える要因のことをPSF(Performance Shaping Factors)という[4]．

PSFは階層構造を持っており，PSF同士も関連する（図 1）．

図 1　階層構造をもつPSF

実際に発生した事故からPSFを抽出することによって，真の原因を探ることができるようになる．それではどうやってPSFを抽出すればよいのであろうか．

PSFの分析手法は幾つかある．Man（人），Machine（装置），Media（環境），Management（管理）と言う４つの視点で分析する4M分析手法，Software（手順書），Hardware（装置），Environment（環境），Liveware（作業者と人間関係）で分類するSHELL分析手法などがある．これらの手法は要因（PSF）が偏らないようにするために有効ではあるが，それ自身で完璧な要因が浮かび上がってくるわけではない．要因となるキーワードは業界毎に異なるので，業界別に参照できるPSFテンプレートが必要である．

PSFテンプレートは一朝一夕でできるものではなく，後に述べるPDCAサイクルに従って補完してゆく必要がある．

まずは実際に発生した事故を元に“なぜ”その要因が発生したのか，繰り返し検証してゆき，事故の真の原因，潜在要因まで抽出してゆくのがベストであろう．この手法は品質管理の分野で利用されており，トヨタ生産方式の生みの親である大野[5]も最低五回の“なぜ”を繰り返せ，と説いている．

図 2は筆者があるデータセンターで複数のシステム運用プロジェクトに参画し，多くの事故データからPSFを洗い出したものである．このチャートはそのままPSFのテンプレートとして用いることが可能である．

図 2　PSFの洗い出し

(2) 要因に優先順位をつける

PSFの洗い出しができたら，過去の事故を分析して，重障害，軽微，ヒヤリハット（事故には至らなかったが計画とは異なる行為・結果があった事故）に分類する．実際の事故件数は機密扱いなので開示できないため，サンプルを提供する（図 3）．

図 3　PSFの分類

次に，PSF毎に発生した事故の件数に事故の大きさを表す事故レベルの重みを掛ける．ハインリッヒの法則に合わせて重障害は300，軽微は29，ヒヤリハットは1という重みをつけ，件数に重みを掛けたものを計算する（図 4：サンプル）．重み付けされた点数が最も高いPSFが優先的に対策を検討すべき要因であることがわかる．

図 4　PSFの重み付け

4. ヒューマンエラーの未然防止策

ヒューマンエラーを起こしてもそれが重大障害につながらないようにするために，生産現場や医療現場では様々な防護策が施されている．これらの研究成果をシステム運用で使わない手はない．代表的なものとしてJIS規格[6]にも記載されているフールプルーフという考え方がある．フールプルーフは，「人間が誤って不適切な操作を行っても危険を生じない，あるいは，正常な動作を妨害されないこと」である．中條[7]によると，フールプルーフは次の５つに分類される．

図 5　フールプルーフの分類

これらの原理をシステム運用で考えられる対策にマッピングしてみる．

(1) 排除

ミスの要因そのものを取り除く．サーバー統合による変更箇所の削除する，安定したソフトウェアに変更し修正モジュールの適用回数を削減する，などが考えられる．

(2) 代替化

ミスしやすい作業を人に行わせない．操作に必要な一連のコマンド群をバッチ化する，コマンドをメニュー化し選択するだけにする，などが考えられる．

(3) 容易化

作業をやさしくしてミスしにくくする．これはさらに３つに分類される．

共通化・集中化

作業上の変化や相違を少なくする．作業ディレクトリを同じにする，コマンド名を同じ規則で割り付ける，などが考えられる．

特別化・個別化

異なるものの差を明確にする．ラベルを貼る，間違えそうなコマンド名を工夫する，警告メッセージを出力する，などが考えられる．

適合化

人間の能力に合ったものにする．落ち着いて作業できるように時間を調整する，長いコマンド名を短くする，などが考えられる．

(4) 異常検出

ミスしたら気付くようにする．監視システムを組み込むなどでシステム運用上はよくとられている対策である．しかし変更作業時には監視システムを止めている場合があるので注意が必要である．

(5) 影響緩和

ミスの影響を少なくする．保守ウィンドウで作業する，バックアップしてから作業する，特権で作業しない，再帰オプション[1]を使わない，などが考えられる．

これらのフールプルーフ的思考を使って，ヒューマンエラーを発生させた要因を低減させる対策を検討してゆくことができる．

5. 報告の仕組みづくり

(1) 小さなエラーを拾う仕組み

ハインリッヒの法則によれば，1件の重大事故の影に29件の軽微な事故，さらに事故には至らなかったエラー（ヒヤリハット）が300件も存在する（図 6）．このヒヤリハットという事象を放置していくと重大事故につながることが経験則から実証されている[8]ので，ヒヤリハットを管理していくことが重要である．

図 6　ハインリッヒの法則

しかし障害として表に出ないこの現象をどうやって掴むのであろうか．エラーを起こした作業者は自分や所属組織の評価が下がってしまうことを気にして，なかなか通報してくれないであろう．しかし他の業界でこの課題に取り組んで成功している事例がある．

(2) いかにして報告を上げさせるか

米国航空業界では，問題を起こしてから10日以内に報告を行えば事故の責任を免責される「インシデントレポートシステム」という仕組みがある．この試みはうまくいき，発足当初で月400件の報告があり，今では月2千件以上もの報告がある[3]．

このシステムでは報告を促すために，

懲戒処分を行わないこと

提供者の情報は守られること

の2点を確約している．この担保がないと，報告者は安心して報告を提供できない．

この方式をシステム運用でも使うべきである．通常はシステムが利用できないような状態にならない限り報告することはないが，報告者にインセンティブと保護を与えることによって些細な出来事も報告させることが可能となるのである．

(3) 報告書の雛形

小さなエラーも扱えるインシデント報告書の雛形を図 7に示す．「考えられる要因」という欄を設けて，先に洗い出したPSFから選択できるようにしておくと報告しやすい．

図 7　報告書の雛形

(4) 報告のタイミング

(2)で述べたように報告者を保護しても，能動的に報告を上げてもらうのは容易ではない．そこで，変更管理プロセスに組み込んでしまう方法が考えられる．変更作業が完了した時に，作業内容に問題がなかったかどうか，先の報告書雛形を使って報告させると良いであろう．こうすれば全ての変更に対して何らかの報告が上がることになる．

または，アンケート方式によって無作為に抽出した変更に関して報告を得る方法も考えられる．

(5) 報告へのインセンティブ

運用部門間あるいは作業担当者間で報告件数を競わせてはどうであろうか．報告をより多く上げたものには何らかの賞金を付ける．なぜエラーしたものを酬いらなければならないのか．そこは考え方を百八十度変えていただきたい．軽微なエラーはさらに重大なエラーの発生を未然に防ぐための手段を提供してくれる貴重な資源である，という考え方に改めていただきたい．

6. これまでの取り組みを維持・向上するには

これまで述べてきた要因分析，優先順位付け，報告，対策は一過性のものでは意味がない．品質管理規格であるISO9001や情報セキュリティ管理規格であるISO17799などのマネジメント・システムと同様にPDCA（Plan-Do-Check-Action）サイクルを回して，継続的に事故件数を削減していかなければならない（図 8）．

図 8　PDCAサイクル

(1) Plan

PSFを洗い出す．最初は過去の事例から拾うか，業界のテンプレートを参照して求める．２周名以降は前回の実行結果を考慮してPSFの精度を高めていく．小さな事件も拾えるように報告システムを計画する．

(2) Do

報告を行い，報告を収集する．

(3) Check

PSFの件数を障害影響度に応じて重み付けして，優先的な対策を必要としている要因を割り出す．

(4) Action

対策を施す．例えばフールプルーフの考え方に従って手順を見直したり，システムを更改したりする．

このPDCAサイクルを，１年を目安に回していき，事故件数がどのように推移したかを管理すればよい．

7. 運用フェーズでは防げないもの

ここでは，ヒューマンエラーを低減するPDCAサイクルのなかではコスト面から実現しにくく，システムを構築する以前に決めておかなければならない問題を議論する．

(1) 保守ウィンドウを制定すること

バックアップ時間と作業時間を考慮した保守ウィンドウを必ず確保すること．必要に応じて保守ウィンドウを調整する，というのは問題外の行為である．確実に四半期（長くて半年）に一度は保守ウィンドウを設定することが重要である．ハードウェアやソフトウェアは人が作ったものであり，当然の事ながらヒューマンエラーに満ち溢れている．マイクロコード，オペレーティングシステム，ミドルウェア，それぞれの修正モジュールが頻繁に出荷されている．

保守ウィンドウの長さは，フルバックアップ時間と修正適用時間に加えて，テスト時間，フォールバック[2]時間も考慮すること．ストレージ製品だとTB級の容量があるのでバックアップ時間は十分余裕をもたせること．また保守ウィンドウにはアプリケーションの移行やデータの移行を含めてはいけない．

(2) 並行保守環境の整備

保守ウィンドウの確保がどうしても守れない場合は，並行保守ができるシステム設計が必要となる．本番環境を全て（共用ディスクも）二重化し，片系を保守しているときにもう一方で運転できるように設計すること．

インターネット向けサービスでは24時間365日の連続運転が一般的になっているので，保守ウィンドウを設けるのはたやすいことではない．かといって全部二重化するとなるとコストも相当覚悟しなければならない．しかしこれを避けてあいまいなまま運用すると確実に事故が起こるということは言っておきたい．実際に事故を発生させると，そのフォローで多大なワークロードを取られるので注意すること．2時間の変更作業に失敗して38時間のフォロー時間がかかった例がある[9]．

(3) CFIAの実施

CFIA（Component Failure Impact Analysis）はSPOF（Single Point Of Failure）分析の一種[10]で，システム構成をパーツレベルまで分解し，各パーツが故障したときの業務影響を分析する手法である．この手法をシステム構築前にやっておくことで，コンポーネントレベルで単一障害点を排除することができる．

8. 最後に

以上の対策を単独の部門や単独のプロジェクトだけで実行せずに，組織的あるいは業界横断的に取り組んでいくことで，ヒューマンエラー改善速度の向上が図られる．本論文ではヒューマンエラー削減の取り組みに関する提案を中心としたが，次の機会には実際にPDCAサイクルを回して得た成果についてより詳細に論じてみたい．

[9]沢橋松王，Webホスティング環境におけるシステム変更管理への提言，IBM2003年プロフェッショナル論文入選論文, 2003.11

[10]David Raften, Availability Management Planning Guidelines,

http://www.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130227.pdf, 2006.2

[1] Unixのルートディレクトリでrm –r *を実行すると再帰的にディレクトリを下って削除コマンドが実行され，システム全体を削除してしまう．この-r部分を再帰オプションと呼ぶ．

[2] フォールバック･･･システム変更に失敗したときに元に戻す時間．戻し作業時間（リストア時間含む）と確認時間を考慮する．

2017年8月27日日曜日