|
東京電力ヒューマンファクター研究グループの河野龍太郎主幹研究員はヒューマンファクター理解のために良く引用される航空界のSHELLモデルを医療界にも「わかるように」と提案しています。 最後の「パフォーマンス」に関する主張、「ヒューマンエラーを減らすことだけが目的じゃない、ヒューマンパフォーマンスの向上で（チームのパフォーマンスが向上し、） 問題解決能力の向上が目的なのだ」とはまさに私たちが昨年来学んだＣＲＭseminarの主張でもあります。 以下、引用です。
事故が発生すると分析が行われます。この事故分析を行なうと、多くのケースで人間の問題が出てきます。 この人間の問題の解決をめざして体系付けを試みられているのが、ヒューマンファクター工学です。 ３．１ ヒューマンファクター工学の説明モデル まず、ヒューマンファクター工学の説明モデルの一つであるＳＨＥＬモデルを使って、システムを構成するいろいろな要素間の関係の考え方を説明します。 ヒューマンファクター工学では、歴史的にいろいろなモデルが、目的に応じて提案されてきました。 最初は、Ｅｄｗａｒｄｓが、ＳＨＥＬモデルを提案しました[1]。図１は、最初のＳＨＥＬモデルです。要素としてＳｏｆｔｗａｒｅ(S)、Ｈａｒｄｗａｒｅ(H)、Ｅｎｖｉｒｏｎｍｅｎｔ(E)、 そしてＬｉｖｅｗａｒｅ(L)を表現しています。これが原型です。 これで分かる通り、ＳＨＥＬはそれぞれ一つずつしか書かれていませんでした。それぞれの要素を一つにまとめて”ＳＨＥＬ”と記述していたのです。 このオリジナルＳＨＥＬモデルを、より分かりやすく書き換えたのが、ＫＬＭオランダ航空のＨａｗｋｉｎｓ機長でした[2]。彼はオリジナルＳＨＥＬの形を変えました。 Ｌを真ん中に描き、その下にひとつ増やしました（図２）。
真ん中に当事者自身を表わすLivewareがあり、周辺を凸凹したタイルで表現し、そして、この凸凹で人間の諸特性を表わすことにしました。 たとえば、知識の量や質、生理的限界、認知的特性などです。このLivewareをHardwareやSoftware、Environment、そして一緒に働く仲間のLivewareで取り囲む図を使ってこれらの関係を説明しました。 Hardwareも計器の並びとか、システムの特性、スイッチの形などの特性を表わしていますので、周辺を凸凹で表現しました。 この特性は、SoftwareにもEnvironmentにも、一緒に働く仲間であるLivewareにもありますから、すべての要素を、周辺が凸凹のタイルで表現しました。 さらに、ヒューマンエラーは、この中心にあるLivewareの凹凸とそれを取り囲む各要素の凹凸がうまくかみ合っていないところに発生すると考えたのです。 なんらかの原因で、この中心のLivewareの持つ周辺の凸凹と、これを取り囲む各要素の持つ凹凸がうまく合致せず、隙間が空いたところにヒューマンエラーが発生するというメカニズムを説明しています。 筆者は、さらに、m（management）を加えたm-SHELモデル（図3）を提案しました[3]。
３．２ 人間中心のシステム設計 このギャップを埋める方法は二つあると考えられます。一つは、真ん中のLivewareからそれを取り囲む要素の凸凹に合わせるように内側から外に向かってギャップを埋める方法と、 他の一つは、真ん中のLivewareの凸凹にまわりを合わせるという方法です。 これまでの考え方では、たとえば、Hardwareと人間の関係に着目すると、最初に設計者が機械を設計し、その出来上がった機械が人間に提供されました。 与えられた人間は、これを使いこなすことを要求されたのです。つまり、与えられた機械の特性に人間が教育訓練を受け、それを使いこなす努力をして、このギャップを埋めていたのです。 使える人を積極的に選抜したり、不適切な人間を排除したりしていました。このギャップを埋める努力は、まさに、人間に求められていたのです。 しかし、過去に発生した事故をよく調べてみると、人間が使いこなしきれていないために起っているものもあることが次第に分かってきたのです。 そこで、発想を逆にして、もともと人間は生まれながらのある特性をもっているので、その特性を考慮した設計にすれば、使いやすい、エラーを引き起こしにくいものができあがるのではないか、 と考えられるようになってきました。つまり、Livewareの凸凹に合わせて、取り囲む要素を設計するという考え方でした。 たとえば、設計者は、スイッチ類の並びはきれいに一直線に並んでいる方が見た目にきれいだし、作りやすいし、経済的に有利なのでそのような設計をする場合があるのですが、 使う側の人間から見ると、どれも同じような形なので識別をするのが困難である、というようなことが起こるのです。 また、設計者は、システム内部のことをよく理解しているので、 使う人は当然知っているだろうと思って機械を作ることがありますが、しかし、使う人はシステム内部のことをよく理解しているとは限らないし、 また、緊急事態などでは、普通なら何の困難もなく思い出すことができることも、うまく思い出せなかったり、ある特定のものに意識が集中してしまい、その回りのことがよく分からなくなるという 生まれながらの特性が出る場合があるのです。 したがって、設計者はこの機械がどのような場面で使われるかをよく考えて、使う人の立場で設計することが重要なのです。 この考え方は、Hardwareだけではなく、Softwareやもう一つのLivewareとの関係、たとえば、チーム編成などにも同じようなことが言えるのです。 ３．３ Ｐ−ｍＳＨＥＬＬモデル SHELモデルやm-SHELモデルは、主に人間や機械などで構成される産業システムで考案され広く利用されてきましたが、最近、注目をあびている医療システムにおいても利用可能なモデルです。 しかし、医療システムでは、患者の要素が大変大きいと考えられるので、筆者は、従来のm-SHELモデルに患者の要素を加えたP-mSHELLモデル（図４）を医療用に提案しました[4]。 P-mSHELLのPはpatientのPです。また各要素の周辺の凸凹はデザイン上の理由で単純化させました。 そして、いつも質問で出る「なぜ、ｍ-SHELあるいはSHELモデルのスペルはLが１つしかないのですか？」という問いに対して、これまでの歴史的背景を反映しないで、 図４で表わしているようにLが二つあるのでそのままP-mSHELLと記述することを提案します。 モデルの目的は「複雑なものを分かりやすくすること」ですから、記述の面でも図と合わせるようにしたいと考えます。 ３．４ パフォーマンスの向上 一般に、Hardwareである装置やSoftwareである手順や表示のルールは、後から人間が作るものですから、人間の特性を考慮して作ることができます。 しかし、人間の持つ基本的特性の大部分は生まれながらに持っているものですから、教育や訓練で変えることのできる部分はあまりありません。 人間の生まれつき持っている特性を変えるのは極めて難しいのです。たとえば、「緊急時に慌てるな！」と言っても、それは無理か、大変困難です。 また、「注意をずっと維持せよ！」と命令しても、最初の数分はできるかも知れませんが、数時間も維持することは不可能です。 そこで、まず、最初に、人間の特性を明らかにして、しかもそれを素直に受け入れ、それらの特性を考慮したシステム設計が重要となるのです。 この人間の特性に合わせてシステムを設計するという「人間中心のシステム設計」を行なうことこそが、ヒューマンエラー防止対策の理想なのです。 人間中心のシステム設計を実践すると、ヒューマンエラーが起こりにくいどころか、逆に、働きやすいので人間の本来持っている能力が十二分に発揮できるようになります。 すなわち、ヒューマンパフォーマンスが向上すると考えられるます（図５）。 参考文献 [1] E. Edwards : Introductory Overview, Human Factors in Aviation edited by E. L. Wiener & D. C. Nagel, Academic Press Inc., 1988. [2] H. F. Hawkins : Human Factors in Flight, Gower Technical Press Ltd., 1987 (黒田勲監修・石川好美監訳｢ヒューマン・ファクター｣、成山堂書店、1992) [3] 東京電力ヒューマンファクター研究室 : Human Factors TOPICS、1994. [4] 河野龍太郎 : 医療リスクマネージメントセミナーテキスト、テプシス、2002.  図５ 「人間中心のシステム設計」によりパフォーマンスの向上が期待できる | ||||||||||
| [メインページへ] [ＨＦ講座トップへ] [前の章へ] [次の章へ] | ||||||||||
