起こるに関する検索情報
|
[ 92] アンカテ(Uncategorizable Blog) - これから柏崎刈羽で起こるクリティカルなこと
[引用サイト] http://d.hatena.ne.jp/essa/20070814/p1
原子力発電所の中では、想像を絶するような高温高圧の蒸気が、場合によっては何年も連続して駆け回っている。そういう負荷に何十年も耐えなくてはいけない。それを、100%確実に保証しなくてはいけない。大変なことである。
おそらく、部品の製造から設計、施工の各段階で、何に注意して何を優先してどういう検査をしてどういう手順で作業を進めるか、日々の運用から定期点検から突発的な状況での対応方法まで、そこには膨大な体系があるはずだ。
そして、柏崎刈羽のこの体系は、新潟県中越沖地震での想定を超える揺れに耐えて、無事に緊急停止した。格納容器はこれに耐えて、致命的な放射能を放出せずに止まることができた。細かいことは抜きにして、まずこのことを評価すべきである。
しかし、もし、この「想定外の揺れ」を受けた発電所を再稼動するとしたら、この膨大な体系を再構築しなくてはいけない。想定外の揺れに耐え、一回停止する所までは、構築済みのこの体系に含まれている。しかし、想定外のダメージを受けたプラント全体について、その後で、何かを確実に言うことはできないはずだ。
それが不可能だと断言することはできない。初期稼動から何回かの定常運用と定期点検を経て緊急停止までのサイクルは一回は成功したのだから、同じことをもう一度できないはずはない。しかし、古い品質保証の体系を延命してツギハギで運用することと、それと同じレベルの新しい体系を再構築することは別である。今、必要なのは後者であり、後者は前者よりずっと難しい。
プラントは全体として「想定外」のダメージを受けた。これに対し、どこが致命的で一からやり直しであって、どこが修復できる所なのか、それを見極めながら再稼動することは、新規に建設するよりずっと技術的には高度の作業になるだろう。格納容器の中は放射能まみれで、開けて点検するだけでもものすごく高度な作業になる。想定されてないような部品の交換が必要になる可能性も高い。
そしてこの判断は、一つ一つがスケジュールやコストに直結するので、おそらく、これから、東京電力の中では、これまでに無い綱引きが始まると思う。
たぶん、難問ではあるが技術的な答えはある。何が大丈夫で何が問題で何が未確定なのか、技術者はほとんどの課題に正しい答えを出せるだろう。しかし、その正しい答えを組織の中で通せるかどうか、そこを見守らなくてはならない。
文系的なプレッシャーを与えたら、理系の社員には対応できないので、東電の内部では文系の社員がイニシアチブを取ることになる。技術者の正論は押しつぶされ、中古の事故物件のポンコツの原発がヨレヨレで再稼動することになる。
科学的論理的に批判し情報開示を迫り、文系の東電社員を論破して蹴散らさなくてはならない。技術のわかる人間でないと対応できないような種類の強烈なプレッシャーを東京電力にかける必要がある。そして、未確定な部分や確率を含んだ新しい品質保証の体系を引き出さなくてはならない。
この情報戦が文系同士の戦いになったら、嘘とごまかしだらけの計画書がでっち上げられ、その辻褄合わせの為に技術者がこき使われることになる。攻める側も守る側も技術者が先頭に立ち、エンジニアリングの問題として議論すべきである。
東電は、おそらく内部的には再稼動を断念することまで含めて検討しているだろう。反対派は、これを政治的な文脈に乗せることはつつしむべきだ。「柏崎刈羽は廃炉になったのだから他も止めるべきだ」とか、そういう反対派の宣伝文句に使われるとしたら、それに関する技術的検討を開示することはできなくなる。「柏崎刈羽」の問題は、あくまでここの問題として処理すべきである。また、つまらないアラ探しをせずに、緊急停止が設計通りに動いたことを認め、ここまで動いてきた体系を評価すべきである。そこを評価することは、再稼動への技術的検討が不要であるという意味にはならない。
そして、技術者が本音で大丈夫だと言ったら、それを受けいれる覚悟が必要になる。その覚悟が無いと、技術者の本音を引き出すことはできないだろう。
私は、原子力発電は、技術者が理論通りに運用したら安全で最適な発電方法になると考えている。だけど同時に、これだけ政治的な業界で大きなお金の動くプラントが、技術者の手で技術者の思う通りに運用されるわけが無いと考えている。技術者のやる気を削ぐようなことが積み重なって、モラールや品質レベルが低下していき、最後には致命的な大事故を起こすに違いないと思っている。だから原子力発電には反対である。
大事故を起こすことがわかっていたら、他のどんな非効率的な発電手段だって、原子力発電よりは安い。
私はそういう立場であり、長期的な観点ではこの考えを変えるつもりはないが、当面、柏崎刈羽のこの問題については、再稼動絶対反対の立場は取らない。それを言ったら、文系が理系を引きずり回して、何かとんでもないことが起こる。
原子力発電は、離婚も別居も許されない結婚のようなものである。この夫は、一度グレてしまったら、家に金を入れることもなく、際限なく自分の遊びの為の金をせびる(廃炉になって発電を停止しても相当な長期間にわたり維持コストがかかる)。それでいて、別居して知らん顔をすることが技術的に不可能である。一生至近距離で面倒を見なくてはならない。
いくら今の時点で理想的な申し分の無いパートナーに見えても、絶対に離婚が許されないとしたら、結婚には躊躇するだろう。
そんな結婚をするのは正気の沙汰とは思えないが、してしまった以上、このダンナのご機嫌をとって、なるべく悪いことだけはしないようにする工夫も必要であると思う。
”伝えたいものを無理に歪曲しないと「売れない」から根っこの部分を変えるってのは結局、受け手に絶望してるってことだと思う”
”失敗ゼロを目指して最適化していくと、どこかの段階で 「失敗はしないけれども、成功もしない」というところに来てしまう。”
「銀行のATMは、本当に止まってはいけないのか？」、JISA会長の浜口氏が問題提起：ITpro
”タグ的な考えかたが主流になれば 係長の次は課長になって‥‥という これまでの組織論だって、空しくなるでしょう。”
Yahoo!ニュース - 産経新聞 - “専業主夫”米で増加中 高学歴者が転身、公園では疎外感も…
”「売れるもん作らなきゃ売らんぞ」というスーツと、「全力でいいもん作れ、どう売るかは全力で考える」というスーツと、果たしてどちらが優秀でかっこいいのか、と思ってしまう。”
アンカテ(Uncategorizable Blog) - アナーキーになるセカンドライフとグーグルアースによる町おこし
|
|
[ 93] ITmedia News：なぜ起こる？ 「炎上」の力学 (1/2)
[引用サイト] http://www.itmedia.co.jp/news/articles/0609/04/news012.html
前回の連載で説明したように、CGM（Consumer Generated Media：消費者が生成するメディア）には2つの立場が存在します。1つは「CGMプラットフォーム運営者」、もう1つは「CGMプラットフォームを利用して情報発信する個人や企業」です。今回は、後者が向き合う“CGMの力学”について説明します。
「炎上」という言葉は、ネット業界では以前から使われていましたが、最近「ブログが炎上」などと一般的なニュースにおいても聞くようになりました。
ネットの世界での炎上とは、主にブログやSNS（ソーシャルネットワーキングサービス）の日記に批判的なコメントが殺到する状況を指します。私もライブドア事件の影響で、1つの発信について、批判や、それに対する議論のコメントが1000以上付いた経験があります。
私は炎上を、度合いに応じて3つに分けて名づけています。（1）炎上した結果、再び元の状況に戻る「小火（ぼや）」、（2）コメントやトラックバックを閉じ、一方的に情報配信するだけの「1.0型メディア」となってしまう「半焼」、（3）管理人が耐えられなくなり閉鎖してしまう「全焼（または焼け落ちる）」です。
炎上と混同されやすい現象として「荒らし」があります。これはサイトの運営を妨害するだけの目的のもので、私の定義では、炎上により発生する反対意見や批判的な意見とは異なるものです。
反対意見や批判的な意見は、あくまでも貴重な意見であり、妨害ではありません。それを勘違いして荒らしと決め付け、切り捨ててしまうことは、ブログやSNSの目的である情報発信を放棄するに等しいことであり、さらなる炎上を生むか、受信者から見放され、誰も見ない個人的な秘密の日記のようなものになり果てるでしょう。
ブログやSNSで情報発信をしたいと考える人は、なぜ炎上が起こるのかという「炎上の力学」を理解することで、ネットの向こう側にいる人たちと良好な関係を築き、より安全に快適に利用することが出来るでしょう。
今年8月中旬、岩手県内にある大学の学生が、アルバイト先の書店に来店した皮膚病患者を隠し撮りし、中傷した文章を付けてSNSの日記に掲載しました。このことが「2ちゃんねる」などで話題となり、学生の日記のコメント欄や、所属していた部のホームページ（HP）の掲示板が炎上。HPは閉鎖に追い込まれ、学生は学校から厳重注意を受けることになりました。
この炎上は、学生が「ネットに掲載すること＝公に発表すること」だと認識していなかったのか、忘れていたために起きたことだと思われますが、そもそもこのような行為は現実の世界でも非難されることであり、ネットであってもまったく例外はないどころか、より責任をもって発言すべきであることを認識すべきです。
最近ですと、首相の靖国参拝にまつわるエントリーで炎上したブログや、ボクシングの亀田興毅さんのWBA世界ライトフライ級王座決定戦で微妙な判定があったことについて発言し、炎上したブログがありました。
このような微妙な問題に対して、あいまいな知識とノリで意見することは、その問題を真剣に考えている人たちに不快感を与えるため、炎上につながるのだと思われます。
しかし、確固とした考えがあっての意見であれば、発言し、議論し、間違いがあれば正し、それでも正しいと思えば貫くという態度を取れば、炎上することはないと思われます。
あまり他人事のように言えた立場ではありませんが、民主党の永田寿康議員のガセメール事件で前原代表が強気な発言に終始していた時期に、民主党の長島昭久議員がブログで「この勝負絶対勝てる。今日初めてそう確信した。代表や野田国対委員長があくまでも強気である意味が良くわかった」と書き込みました。
しかしこの事件は、永田議員が誤りを認めた形で終わりました。つまり、長島議員が上記のエントリーを書き込んだ時点では勝てるという根拠があいまいだったと考えられます。にも関わらず「絶対勝てる」と断言してしまったため、先のエントリーは炎上してしまいました。その翌日に長島議員が「ブログが炎上した」と追記をしたことで、より炎上が激しくなりました。
しかし長島議員は、ブログに寄せられるコメントの意味を理解し、誤りがあると気が付いた時点で、率直に謝罪をしました。その結果批判的な意見は減少し、その後は炎上する以前よりもコメントやトラックバックの数が増え、むしろ支持者が増えたように見えます。これは炎上をプラスの方向に変えた良い例だと思います。
某電気製品メーカーが、新製品の使用感についてブログを書いていた4人の一般消費者を紹介したのですが、それを見た人達から、「素人のふりをした企業のやらせブログではないか」との疑いを持たれ、ブログのコメントにやらせである根拠や批判的な意見の書き込みが寄せられ、オープン3日で閉鎖に追い込まれたことがありました。
企業が宣伝のためにブログを利用する際、批判的なことが書かれることを恐れるがあまりに、その企業が用意したプロのライターに、何の関係もない素人が書いたように見せかけて書かせることがあるのですが、そのようなものは、やらせであると見破られてしまうとことが多いと思います。
その理由は、ブログの中に、商品やサービスに対する批判の記載がないことが多いためです。どんなことにも長所と短所があるはずなのに、長所だけしか書いていないようではかえってリアリティーがなく、嘘くさく見えてしまいます。
また、企業がSNSを宣伝に使おうとして反感を買った例として、SNSという双方向メディアを使っているのに、オールドメディア的な手法で一方的に情報を配信し、双方向性を拒むような対応したものがあります。これは、コミュニティーの名をかたった「1.0型」モデルの広告に過ぎず、口コミ的な広告効果を期待できるものではありません。
例えば、仲良しのグループの中に突然、自分の意見しか言わず、人の話は一切聞かないという人が入ってきたらどでしょう？ おそらく相手にされず、はじき出されるのが落ちでしょう。
このように炎上の原因は現実の世界と同じで、人に向かって不謹慎な発言をしたり、嘘をついたことが判明すれば、誰かが傷ついたり、怒ったりするということです。ネットの世界でも、目の前に人がいるのと同じ結果が起きる可能性が高いことを理解していなかったことが原因で、特に有名な人ほど炎上のパワーが増大します。
Googleなど大手サイトのcookie転送に問題発覚、認証かわされる恐れGoogle、Microsoft、Yahoo!などの大手サイトに脆弱性が発覚。「サービスとしてのソフトウェア」を提供しているサイトは特に危険だという。
9月のMS月例パッチ、品質問題で1件公開中止Microsoftは当初5件のパッチ公開を予定していたが、品質問題でうち1本の公開を中止した。
純減ドコモ「守りの弱さ」露呈 料金プラン見劣りドコモが9カ月ぶりに純減に転じた。2年の継続利用を条件に基本使用料を半額にする新サービスで巻き返しを狙ったが、顧客流出に歯止めがかからない。ソフトバンクモバイル、auの猛攻をはね返すことができず、“守りの弱さ”を露呈している。
アメリカは今“原発ルネッサンス”――2つの理由と3つの懸念Suica加盟店が2万店、ポイント会員数は24万人を突破キヤノンVSニコン、どちらの株が“買い”か？ビールが似合う有名人、男性1位は香取慎吾、女性1位は……3カ月後、日経平均は2000円上がる？
jobtxt2 += 'ITエンジニア2万人の年齢と年収が一目瞭然隣の芝生（年収）は本当に青いのか？？？';
|
|
[ 94] ヒューマンエラーはなぜ起こる
[引用サイト] http://staff.aist.go.jp/toru-nakata/humanerror.html
この講演資料は、防災ワークショップを行った後にお見せするものです。ワークショップではこんな作業をします。
司会は、参加者の挙げた理由の例を数個取り上げ、全員に、「なぜ、そうなのか？」と、理由の理由を問います。
※司会は、問題の捉え方や解決方法をあからさまに誘導しません。ヒューマンエラーを防ぐテクニックは、先に言うと参加者を強く誘導してしまいます。
ヒューマンエラーとは、人間の過誤（ミス）のことです。人為ミスとも呼ばれます。不本意な結果を生み出す行為や、不本意な結果を防ぐことに失敗することです。
下手や無駄だけど事故にならない操作や、機械設計者の設計ミス（＝操作者以外の人的過誤）は、普通はヒューマンエラーには含めません。
現代の大事故は、ほとんどヒューマンエラーによる事故です。いろいろな統計報告がありますが、事故のおおよそ6〜8割はヒューマンエラーが原因であるというのが相場になっています。
ここでヒューマンエラーのリスクについて考えて見ましょう。リスクとは被害額期待値（＝予想平均被害額値）の意味と考えてください。（人命にかかわるヒューマンエラーの事故も多いですが、さしあたり金銭の例題にします。）
1株を61万円で売るという指示を、61万株を1円で売るという指示にまちがえてしまったとします。「1@610,000」と入力するところを「610,000@1」とタイプしたわけです。このような取り違いは、大雑把ながら1000分の3くらいの確率で生じると言われています。
610,000円で売れるものをたった1円で610,000個も売ったので、損害額は約3億7千万円。リスク値＝（損害額）×（エラー確率）＝11万円となります。つまり「リスク・マネジメント」の理論でいうと、株発注作業1回のリスクは11万円ぐらいと見積もられるわけです。なら11万円程度の対策費を支払おうとなります。
しかしよく考えてみると、たまたま610,000だったわけで、別の事例では8,940,000という数字が登場することだってありえます。リスク値の桁が変わってきてしまいます。リスクの見積もりが全然できません。
ヒューマンエラーリスクのスケールフリー性：「ヒューマンエラーの被害額は、その桁ですら予測できないことが多い。凡ミスでも破滅をもたらすかもしれない」
独立した専門学科を有する大学はごく少数です。ヒューマンエラーの学問は教えにくいという点もあります。何しろ「人間のうっかり」が根本ですから、自然科学のようにすっぱり方程式で考えることができません。心理学の知識を擁した工学部の先生がいればいいのですが、少数です。
かつては、ヒューマンエラーが事故の主要な原因である（と認識される）ことは稀でした。それは、下記のような事故要因の数が圧倒的に多かったからです。
新しい技術が登場しはじめの頃は、技術を使う場面で何が起こっているのか、人々は完全に理解していません。危険なことに気付かず事故を起こします。
ローマ帝国では、鉛の杯でワインを飲むことが流行しました。鉛は甘いのでワインの味が良くなるのです。そして多くの人が鉛中毒の病気になりました。しかし当時の人々にとっては、鉛の毒性は未知で、避けようがありませんでした。（ベートーベンもワインの鉛中毒だったという説あり。）
かといって、未知を恐れすぎると何もできなくなってしまいますから、人類の知らない危険への責任は問わないとされます。
日本の製造物責任法の第四条一号では、「引き渡した時における科学又は技術に関する知見によっては、当該製造物にその欠陥があることを認識することができなかった」ら、製造者は責任を取らなくてよいとなっています。
例えば、電車のドアには、非常時には乗客が開けられるように「非常用ドアコック」が設置されています。国鉄京浜線桜木町列車火災事故(1951年4月24日)で、木造電車が急速に燃え出し、中の乗客は自動ドアが開かず、乗務員にも開けてもらえず、閉じ込められ、焼死したことの反省で設けられました。
このような事態が起こりえるとあらかじめ気付いていれば、もっと早く非常用ドアコックが設置され、事故にはならなかったでしょう。一種の「未知」ともいえます。
（注： 逆に、乗客の脱出が裏目に出た事故も多いです。桜木町事故の前後でも、肥薩線山神第二トンネル事故(1945年8月)、常磐線三河島駅構内三重列車衝突事故(1962年)は、小さな事故の後に線路を歩きだした客を列車が轢くことで大惨事になっています。三河島事故によって、「事故が起きたら安全が確認されるまで、付近の列車も含めて、列車をすぐに止めなければならない」という知見が意識されるようになりました。）
（注2： 「事故が起きたら列車をすぐに止めなければならない」という知見は、1972年の北陸線北陸トンネル内列車火災事故では裏目に出ました。火事を起こしている旅客列車が長大なトンネルで止まったら・・・。「例外として、トンネル内の列車火災ではトンネルを抜けるまで止まるな」、「可燃性の車両を全廃せよ」に知見が改良されました。）
これは部品の故障や制御の失敗などで、道具が人間の言うことをきかなるという事故要因です。昔は、金属材料の生成技術、部品の製造技術、制御工学が発達していませんから、機械の故障・不調・寿命切れは頻繁に起こりました。
そこで「信頼性工学」という学問が現れました。第2次世界大戦では膨大な数の兵器を作り使いました。それぞれの兵器には、これまた膨大な数の部品が使われていました。故障する兵器の数も膨大で、故障は戦力をそぎました。これを何とかするための学問が「信頼性工学」です。
故障しやすい箇所は部品を二重にして片方が壊れても大丈夫にする方法、製品欠陥率が高い工場を割り出す方法、保守点検の間隔を上手く決める方法などが作られました。
かつて、船の難破の原因は、悪天候や暗礁でした。人間が活動する領域を広げていく上で、新しい環境に漕ぎ出すことはやむを得ないことでもありました。
現代は、気象観測網や海図整備が進み、船は人間が活動しても大丈夫な領域の中だけを航行します。「未知の環境を減らす」、「未知の環境には行かない」ことが、人類のとった解決策です。
従来の工学は、こうした事故要因に立ち向かうことで精一杯でした。そしていまだに工学部の活動は、壊れないいい部品や性能のいい機械の作り方に重心を置いたままです。そのかいあって、この手の事故要因は減りました。
事故を教訓にして対策が練られると、2度目の事故は「対策を怠った人間に責任がある」とされます。こうして、次第に人間の責任範囲が広くなっていきます。
御巣鷹の尾根（御巣鷹山）日航機123便墜落事故。全油圧系喪失し操舵不能。「ハイドロプレッシャーオールロス」。ほぼ全員死亡。
ユナイテッドUA232事故。全油圧系喪失。左右のエンジン出力を調整することで方向を制御し、着陸。3分の1強死亡。以降、エンジン左右推力差策（パワーコントロール）が採用される。左右推力差策自体は以前から候補として考えられていたが、さして有効だと思われてなかったらしい。本例でも死者数は多い。
DHL貨物機へのミサイル攻撃。バクダット。油圧系喪失。左右推力差調整による方向制御で全員生還。
JAL123 とUA232の事故は有名。いろいろ本が出ていて、例えば、加藤寛一郎「墜落 第1巻 驚愕の事実」講談社、など。
JAL123便事故へは議論噴出して、公式見解が目立たなくなっています。とはいえ、公式見解の内容は注目に値するものです。
公式見解である航空事故調査委員会の結論によると、JAL123便の事故は、圧力隔壁の修理不良が原因の破壊によるものとされています。
事故機は、1978年に尻もち事故を起こしたため、圧力隔壁を修理しました。その際、隔壁に歪みが生じており、寸足らずになっていました。上の壁板と下の壁板を、２列のリベット（鋲）列で接続させたかったのですが、“重ねしろ”のスペースが、１列分しかありませんでした。１列だけのリベット列では脆弱なのでいけません。
そこで、中継ぎ板を差し挟んでみることにしました。継ぎ板を介すことで、上下の隔壁を安全な２列リベット締結の連携でつなぐことにしたのです。
つまり、中継ぎ板の意味が全く無い修理だったのです。中段のリベット列だけでかろうじて強度を保っていたわけです。
板が切断された理由は不明ですが、切った人が「中継ぎ板」を「切ってもよい板」と誤解していたことは確かです。（あるいは、「切ってもかまわない方向がある」と思ったのかもしれません。短冊切りという、一番強そうに思えるが、この場合には不幸にも一番弱くなる方向に切ってしまったわけです。
映画「学校III」で、寺田農が大竹しのぶに、円筒圧力容器のマンホールの向きの理由を質すというシーンがありました。理由を知ることは大事。）
リベットを打った人は、「リベット列は２列以上でなければならない」という原則を守っていますが、「なぜそうなのか？」は理解していなかったわけです。
これをヒューマンエラーと呼ぶべきか、連絡不徹底と呼ぶべきか、組織運営不良と呼ぶべきか、教育不足と呼ぶべきか？呼び方の問題か？
安全よりまず機能の時代。蒸気機関車のボイラーを大型化を優先 ⇒ 運転手は前方がほとんど見えない。
基礎的作業環境の改善の技術や投資が不足（山があると迂回させられる線路⇒カーブが多くなる）
人間の操縦能力の限界に遭遇。軍用機。兵士が機械の挙動に追付いていけないことがヒューマンエラー。操縦能力の定量化の研究。
飛行機事故発生率が下げ止まる。（人間の問題以外は改良しつくした。）参照：ボーイング社の資料。
安全な装置や材料の普及。酒田大火(1976年)以降、材料に主原因がある大災害はまれになる。人々の安全水準に対する要求も上がる。
スリーマイル島原発事故(1979年)。現在の機械システムの運用では、ヒューマンエラーがボトルネックであることが判明。体系的な対処が始まる。
ホテル・ニュージャパン火災(1982年)。大きなシステムを作ることはできるが、それを安全に運営する人間組織を作ることはむずかしい。「マル適マーク」：安全性が商品価値の前面に出る。
プログラムのシステム検証技術。システムが大きくなりすぎたため、バグの存在を前提として、挙動として問題が無いことを検査する方針に転換。
システムの原子力発電プラントが巨大で、弁や燃料棒を直接に目で見たり手を触れて操作するわけではありません。システムの把握が大変で、実感がわきにくいことによるエラーが議論の中心となりました。作業員の行動はすべてルール化されており、作業員は情報処理の要素としてシステムに組み込まれているという捉え方です。
飛行機は管制を受けながら航行します。勝手な行動は基本的に許されません。管制官と操縦士の意思疎通の失敗がまず議題にあがります。また、複雑な航空機のシステム、特に自動化したシステムとパイロットの意思疎通も問題になります。
海難審判という特別な事故紛争処理制度があることに注目すれば、特殊な業界といえます。海難審判庁は事故分析報告書を発行しており、データの面では整備されています。しかもその報告書をPDF形式で全文Web公開している点は画期的です。
分析書では、海難を引き起こすヒューマンエラーを、割と平凡な不注意・確認不徹底・行為杜撰などで説明して終了しています。裁判なのでそこまででいいのかもしれませんが、「じゃ事故を実際に減らすにはどうする？」という踏み込みが欲しいところです。
工事現場での、事故や「ヒヤリ・ハット」（事故にはならなかったがヒヤリとしたりハッとしたこと）の低減という文脈で議題になります。作業員同士の意思疎通が問題になります。書店に並んでいる「ヒューマンエラー」の本の3〜4割は、建設現場の防災の内容になっています。
事故というより、使いやすさの追求という文脈で、ヒューマンエラーを研究しています。かつては、計算機操作員（オペレータ）を想定していましたが、今は素人ユーザをも想定しなければいけません。
医療の現場でのヒューマンエラーとは、いわゆる“うっかり”のエラーを指す傾向があります。患者の取り違い、薬の種類や量のまちがいなどです。
ただ、定量的な考察と対策、例えば「人員が足りているのか、いないのか？」、「足りないなら何人足りないのか？」、「○人足りないと平均的な病院では年に何件事故が増えるのか？」、「○人足りなくても業務を続けてもいいのか？」、「作業を効率化すれば人員は足りるのか？」という内情分析を明示している病院は見たことがありません。
ところが、病院は、基本的に業務を拒否することが許されない特殊な事業者です。容量を超過しても業務を続行しなければいけない非常事態もありえます。需給計算に優先する社会的要請があるわけです。
この点は、地域医療や大小病院間の連携などの問題もからみますから、一病院の問題に収まらないことも付言しておきます。
“うっかりミス撲滅運動”は、人員不足の解決を半ばあきらめた末の、水際作戦になりがちです。ヒューマンエラー学はややもすると水際作戦担当になってしまいます。医療に限ったことではありませんが。
いわゆる“誤診”はヒューマンエラーというより、かなり高次の倫理的ミスとして語られるようです。どんな病気についても、その検査法・判断基準・治療法・投薬計画は、医学界（＝学会）でこれが標準的で適当であるというやり方が固まっています。標準的やり方を用いて、善管注意義務（＝当然レベルの誠意と努力）を払って患者に接した上で、病気を見逃すことは、医学の限界であって“誤診”とは見なされません。新聞沙汰になる“誤診”は、医学知識が古いとか、雑な仕事をしたなど、善管注意義務が果たされていない場合です。
介護の現場では、医師や看護師のヒューマンエラーだけではなく、介護される人のヒューマンエラーが大きな問題となります。
介護される人は、「これくらい自分でやろう」とする心理が働きやすく、介護者がちょっとの間いなくなった時に、体を動かして、失敗して怪我をすることが多いです。
「身体能力が低下しているのに無理をする」という判断上の問題とされます。うっかりミスではありません。“ヒューマンエラー”と分類する方式は少数派でしょうか。
人間を情報を処理する存在として捉えます。なぜヒューマンエラーが起きたのかを、思考アルゴリズムや感情・心理などから説明しようとします。まちがえにくい教育法・指導法も久しく研究されてきました。
製品企画と設計段階での、操作性向上の優先度が低い傾向にあります。 役割が安定した古参の家電はまだしも、新しい分野の製品には新機能とデザイン（見た目）が最優先。操作性向上の工学的理論が不十分という面もあり、操作性の優先を具体的に行えというのは酷かもしれません。
「ボタンを一直線・等間隔に並べれば綺麗である」という美術手法の乱用。 えてして取扱説明書の「便利な機能」という章に、ごちゃごちゃと書いてあります。
“当然に”成功すべき守備に失敗すること。“当然”の判定基準に主観が入ります。「野球のエラー」のように「ヒューマンエラー」を考える人がいます。しかし、一般の作業では「成功して当然」ではない事態もありえることを忘れてはいけません。
また、結果がプラスだと、エラーにされないことがあります。盗塁の際、むやみやたらにヘッドスライディングすると、相手が悪送球した場合にさらに進塁することが難しくなります。大きなプラスを得られたかもしれないのに、ヘッドスライディングを選択するという過誤によって、小さなプラスしか得られません。本来ならエラーに含めるべきかもしれません。しかし、記録上は盗塁成功になるだけです。
ヒューマンエラーの分類はやっかいな問題です。分類の仕方を分類したくなるほど、いろいろな提案があります。
典型的には、「うっかり」の生じる認知心理的レベルによって分類するというもので、下記のように分けます。
単にスリップとも言う。ある作業動作をしようと思っている状況で、何とはなしに別の作業動作をしてしまうこと。特に「ふと気がつけば、場違いな別の行動をしていた」ことの説明に用いる。
例えば、「恋人」と書くつもりで「変人」と書くことや、普段とは逆方向の電車に乗ろうと駅に行ったら、いつもの電車に乗っていたなど。
行動の可否の判断を取り違えたり、判断形成を待たずに、行動を実行する脳の部署が勝手に作動する現象と説明される。
アクション・スリップは安全装置を無効化するので恐れられています。安全装置の多くは、まちがった手順をとがめるものです。アクション・スリップ自体は、手順は正しい行動の実行なので、とがめられません。
身体動作が悪い。慣れていない。手がふらふらするなど。（不器用は、認知的・思考的なものではないので、このリストに入れないことも多い。）
しかし、やりながら考える、やり始めないと詳細が分からないという状況もあります。また、見まちがい、聞きまちがいなど、「考え方が悪い」わけではないエラーもあります。
例えば、スリーマイル島原発事故では、「弁が開いていることに気がつかない」ことが致命的なエラーでした。しかし、上記の分類には収まっていません。（また、開け放しにした人が悪いのか、気がつかない人が悪いのか、という問題もあります。）
練習問題： 将棋のプロ棋士が頓死のミスをおかすことが、ごく稀ですがあります。長手数のむずかしい局面ならまだしも、たった一手で詰んで負けたということがあります。（例：竜王戦の羽生×木村戦など。）この現象のエラーの分類は何でしょう？ ちなみに私はわかりません。まぁ、選択注意管理不良とでも答えておけばテストではマルでしょうが。
私の見解では、このような作業統制のレベルによるエラー分類は、ややもすると詭弁になりえると思います。ならなら、エラーを防ぐ責任の“数珠繋ぎ構造”をごまかす方便に使いうるからです。
「まぎらわしいボタンをデザインしたのが悪い」、「取扱説明書が悪い」なら機械製造者の責任。（製造物責任）
「安全装置のついた高価な機械に買い換えなかったのが悪い」、「充分な休憩を取らせなかったのが悪い」、「粗雑な人間を雇ったのが悪い」なら経営者（や法人）の責任
とはいえ、倫理責任、刑事罰、損害賠償、労災認定、行政罰、対応責任を、この数珠繋ぎに割り振らねばなりません。個人もいれば、（刑が効かない）法人や組織もいます。責任の所在が微妙な事故だと、捜査や裁判は罰のロシアン・ルーレットになりかねません。
この時、「この事故は作業員のアクション・スリップ現象によるもので、そもそもアクション・スリップとは・・・」という理屈をつけると、なんとなく一件落着な感じがします。
業務上必要な注意を怠り、よって人を死傷させた者は、５年以下の懲役若しくは禁錮又は１００万円以下の罰金に処する。重大な過失により人を死傷させた者も、同様とする。
２ 自動車を運転して前項前段の罪を犯した者は、傷害が軽いときは、情状により、その刑を免除することができる。」
（１）不注意が原因、（２）人的被害の発生、（３）「人を死傷させた者」への刑罰という３つのポイントがあります。
「人を死傷させた者」は現場作業員だけか？ ホテルニュージャパン火災裁判のように経営者に適用されるのか？ この区別の基準は何か？
東武伊勢崎線竹ノ塚駅手動踏切死傷事故（2005年3月）に対する、東京地裁判決(2006年2月)。
踏切保安係に禁錮1年6ヶ月の実刑判決。その一方で、手動踏切の使用や内規を曲げての運用が常態化していたことについて、事故の背景事情ではあるが、主要な原因とはいえないとした。
焼津市上空旅客機ニアミス事故（2001年1月）に対する、東京地裁判決(2006年3月)。
便名の取り違いは不適切ではあるが、ニアミスとは直接関係しないので、実質的危険性はなかったと判断した。（裏を返すと、この事件では便名を取り違えなくてもニアミスが生じた可能性はあった、という判決。）
本事件は、管制官による指示と、飛行機の空中衝突防止警戒装置による指示とが矛盾し、ニアミスに至った。現在では、空中衝突防止警戒装置の指示を優先するよう規則が改正されている。
東京慈恵会医科大付属青戸病院の腹腔鏡手術事件（2002年11月）に対する、東京地裁判決(2006年6月)。
前立腺がん摘出のために、全く不慣れな腹腔鏡を使い、難航。しかし、経験をつむために、延々と腹腔鏡使用を続行した。患者は術後に脳死状態になり、１ヶ月後に死亡。前立腺を摘出する際に助手は「はーい、生まれました。男の子でーす」と言っていた。
病院の管理体制がずさんであったことや、病院が遺族に対して「死因は心不全」と嘘をついていたことを考慮し、当事者の医師達に全面的に責任を負わせるべきではないとした。
時代の状況によって、検討項目や厳しさが変化している。森永ひ素ミルク事件(1955年)の刑事裁判は無罪から有罪まで変化した。
古代ローマ時代の法律家が定めた管理責任の原則。ライオンが檻を抜け出し人を襲った場合、ライオンの管理者が責任を取らなければならないこと。
日本の民法では、715条【使用者等の責任】 ある事業のために他人を使用する者は、被用者がその事業の執行について第三者に加えた損害を賠償する責任を負う。ただし、使用者が被用者の選任及びその事業の監督について相当の注意をしたとき、又は相当の注意をしても損害が生ずべきであったときは、この限りでない。（後略）
718条【動物の占有者等の責任】 動物の占有者は、その動物が他人に加えた損害を賠償する責任を負う。ただし、動物の種類及び性質に従い相当の注意をもってその管理をしたときは、この限りでない。（後略）
自分の行っていることが他人への害になると知っている場合は、やってはいけない。上司の命令であっても、何をしても責任は問われないわけではない。他人のやっていることでも看過してはいけない。（反対語：「ミルグラム効果」。ごく普通の善良な人間であっても、上司の命令であるなら、言われるままに非倫理的なことでもやってしまう心理傾向。）
斉の王様の愛馬を、飼育係（圉人）が死なせてしまった。怒った王様は飼育係に死刑を宣告することにした。大臣の晏子が「その役目、私にやらせてください」と申し出た。晏子は飼育係に向かってこう言った。「王様の愛馬を死なせたことは死に値する。王様が死刑を選ばざるを得ない状況を招いたことも死に値する。そして、王様がこんなことで家来を死刑にする人物であることが天下に知れわたることを招いた。これも死に値する。」これを聞いた王様は死刑を取り消した。
この王様のお話をもう一つ。ある夜、王様は髪を振り乱して馬車を走らせていた。馬車には女を連れていた。要するに夜のラブラブ暴走ドライブである。宮殿から出ようと門に差しかかると、門番から「お前のような者は、我が君では無い」と言われて通してもらえなかった。王様失格であると宣告され落ち込んでいると、晏子は「賢明な王だから直接批判されるのです。愚かな王なら誰も本音を告げません。陰口がはびこるだけです」と褒めたという。
大半のヒューマンエラーは、対策していれば防げる。なので対策至上主義の考え方がある。だが、これは問題に核心ではない。
本当は情報共有が問題である。形骸化と既成事実化こそ事故の根源である。システム設計者、事業管理者、作業管理者の間で、わかったつもりになっていることが、事故の温床となる。個々の事故の形態は偶然の産物にすぎない。
大半のヒューマンエラーの原因は、事故以前に、現場で、危ないな・使いにくいなと気付かれている。（事故が起こる可能性を認識したまま放置することは、責任者は刑事責任を問われる。しかし形式上、責任者でなければ法的には白に近い灰色になる。）
大半のヒューマンエラーの原因は、なあなあで放置される。まじめに防止策を施すことが、面倒くさかったり、コストがかかるので放置される。
安全対策のコストの妥当額の見積もりは難しい。事故の発生確率と被害予測はデータになっていない場合が多い。またデータを使うと非難されることがある。Ａ案ならコストが9億円で年間1人ケガの見込みで、Ｂ案なら1億円で5人ケガの見込みの時、このデータを使って、ケガ人の多いＢ案を選択すると「悪魔の計算」であると非難される。(類例：Ford
大きなコストをかけると事故は急減する。新幹線は踏み切りを排除したため“事故ゼロ”になった。制御して作る安全（制御安全）から、構造的に事故状態がない安全（本質安全）に進化する、転換点がある。しかし財政的には難しいことが多い。ややもすると「悪魔の計算」と見なされかねない。
「悪魔の計算」の存在は政治的に公言できない。工学的には意味があるかもしれないが、不穏当すぎて、組織内で記録・伝承されない。「以前からこうでしたから、これで充分です」になる。
打開策は、中立的な政府機関などが規制の改正によって徐々に安全水準を引き上げて、「計算」する余地を無くすこと。また、ユーザに安全装置のオプションを選ばせることで、「計算」をユーザの自己責任において行わせること。
大半のヒューマンエラーを起こす現場管理者は、「なあなあを止めろ」と言われれば従う。しかし、防災のための自発性は、会議の開催や上司のご出席に気兼ねして発揮しない。自発性は作業のマイスタイル（裏マニュアル）の実行に向けられる。
作業のマイスタイルの規制は、しばしば馬鹿馬鹿しく思われる。形骸化する。（裏マニュアルを作らせないようにするためには、正式マニュアルに説得性が求められる。それぞれの作業について、大局的見地からの目的説明・隣接する危険・注意すべき現象・求められる精度と速さを明記する。マニュアルに、ただ対処手順を書くだけでは理解できないし憶えきれない。）
規則遵守の態度を笑顔でほめ、注意は軽くその場でしてくれるなら、気が楽である。作業の監督は、監督項目がどのように事故防止につながるのか、説明して行わないといけない。従業員の一挙手一投足まで厳しく監督しすぎると、次第に事故防止とは関係の無いことがらまで干渉するようになる。下への責任転嫁が行われ、問題が放置される。
ピラミッド型管理体制では失敗の自己申告はあまり期待できない。中間管理職、部署、班、人員は、互いに競争しがちであり、失敗を隠したりかばったりする。
大半のヒューマンエラーを起こす事業管理者は、現場管理者の従順性に安心する。苦情がないことをよしとする。無情報を好むという落とし穴。
大半のヒューマンエラーを起こす事業管理者は、業務内容の変動が、現場の安全を脅かすとは気付かない。（作業員が、従来の1．2倍のパフォーマンスを発揮することぐらい可能だと思う。）
社長による工場巡視のコースがあらかじめ部下に決められるようになると、終末的である。新しいペンキの臭いがする場所ばかり回っているとアヤシイ。何人もぞろぞろとお供をするのもアヤシイ。少人数で巡視すべし。
事業所単位の利益率（対費用効果）が急減・急増するようになると、事故が起きやすい。（現場が経営状況に追いついていない兆候。）しかし、売り上げベースでは目立たない。
床にゴミが落ちているようになると、事故は目前である。素人にも指摘できる問題点を、プロが露呈する。「売り上げがいいのだから問題なし」という言い訳をされる。
大半のシステム設計者は、システムの現場での使われ方（マイスタイル）を見て、危ないと思う点を発見し、ゾッとする。（バケツでウランを運ぶ程度は普通に起こりえる。）
ヒューマンエラーは、防いだほうがはるかに得である。全員にとって得である。事故や非効率は、企業の存立を危うくし、従業員の所得を押し下げる（「われわれの問題」ではなく「私の問題」である（※1））ことを、理解すべきである。
(この理論には、西岡兄妹「この世の終わりへの旅」にも類例がある。実例ではソウル三豊百貨店の崩壊事件(1995)がよく似ている。)
漫然と言っても寝ているわけではありません。ただ、重要な現象変化を見えていても、深く考えない傾向があります。
脳の前頭葉の活動レベルが低下していると考えられます。この状態でも人間は行動をし続けられます。反射的にできる単純判断ならこなせます。例えば、漫然としながら自転車を漕げるわけです。人の話にも、生返事程度なら返せます。
前頭葉の活動停滞の問題点は、自分を客観視できなくなることに尽きます。具体的には、状況判断と大局的判断ができなくなります。自分はスピード出しすぎではないかとか、現状計画をあきらめたほうがいいのではないかなど、自分の傍らから自分を見る「離見の見」（りけんのけん）の能力が、漫然状態では消滅しているのです。
ユーザに、本作業とは別に知恵を使うタスクをあえて課し、頭を目覚めさせてから本作業をさせる方法です。
大陸横断鉄道は、風景の変化に乏しく、運転士は眠くなります。これを防ぐために、15秒ごとにあるボタンを押さないと列車が減速する装置が備えられています。
また多摩都市モノレールでは、列車の発進のためには、2つのボタンを同時に押さねばなりません。ちょっと知恵を使う作業を付け足しておくことで、不用意な作業実行を防いでいます。
巧妙な方法になると、ユーザが目覚めさせられたと気付かないようにできます。例えば、ギロチン式の紙の大型裁断機では、それぞれ離れた位置にある2つのボタンを同時に押さなければ、ギロチン刃は作動しません。両手が刃の近くにいない状態でしか刃が動かないので、手の切断の事故が成立しなくなるのです。
強制覚醒よりさらに強い目覚ましです。寝ぼけていたり、規則違反をしている人は、小事故を起こすようにする仕掛けを用意します。
speed bump） があります。徐行より速い速度で bump を轢き超えると自動車は大きく跳ね上がり、時として地面とこすれたり、部品が壊れたりします。
住宅街の生活道路を bump で囲んで徐行を厳守させることは、欧州では当たり前ですが、日本では普及していません。理由は、下記のものがあります。
1) 実施の歴史が浅く、bump の形状の設計が下手で安普請。これでは、かなりの徐行していても自動車が傷む。
2) 幹線道路と生活道路との分離を考えていない宅地道路計画。むかしながらの横丁が幹線道路に接続している。
3) 懲罰的に、小事故で自動車が破損することへの嫌悪感。自動車の持つ、高い、ステータスシンボル、自由な運転というイメージ。
とろこで、私の予測ですが、ダブルブッキングの事故は、2月と3月に多いのではないでしょうか。2月と3月は、隣接している上に、日付と曜日が同じなので、取り違えやすくなります。手帳に予定を記入したつもりが、まちがった月に書いていたという事故は、どうしても起こるでしょう。
他の月なら、曜日がちゃんとした補助情報になって、まちがいが少ないと思われます。「なぜ、この予定が日曜日に入いるのか？あっ！別の月のページだった！」。ダブルブッキングになるところを、こうした書きまちがいの小事故で済みます。
作業とは別に、前頭葉が活性化する楽しいことやハラハラすることを、ユーザに提示する方法です。眠気覚まし。
東京湾品川区の長大海底トンネル「臨海トンネル」には、入り口に「ラジオを聴け」という看板があります。おそらく、ラジオで意識レベルを上げて、自分を客観視させ、スピードの出しすぎを抑制させる効果を狙っているのではないでしょうか。
流れ作業など、単純作業の反復がどうしても続くという場合もあります。眠くなるのは明らかです。これには、ファンタジーで頑張るという方法があります。えんやこらと労働歌を歌いながら作業するとか、作業自体を祭りにするなどです。
● 機械の都合だけで、人間にとって無意味な作業（郵便番号は半角で入力してください。住所は全角で入力してください。）
・ 作り手の視点からだけで書いている。工程の説明を材料から始める。「ＡをＢするとＣが得られます」式。ユーザが持っているのは出来上がりのイメージである。「Ｃを得るには、ＡをＢします」と、逆引きに書くべし。
・ 手順の迷子になりえる。（手順前後を許さないや、いちいちサブ画面に移り全体の状況を見渡せない、など。）
典型例が、現金自動預け払い機( Automatic Teller Machine, ATM) の動作です。現金を引き出しの場合、カードが返却され、通帳や伝票が出て、最後の手順で現金が出てきます。
これが先の順番で現金が出るようだと、その時点で客が帰りだし、カードや通帳を取り忘れるエラーが激増します。
例えば、指差し喚呼確認。ちらっと目で見れば視認作業は済みます。そこを敢えて、手を動かし、声に出して言うことで、脳全体を使い、覚醒レベルを上げる方法です。
また、ユーザ単独以外にも、他のユーザが復唱したり、システム側から別チャンネルで信号を出したりする方法もあります。
飛行機の高度が危険なほど低くなると、飛行機システムは警報音を出し、さらに「機首上げろ！」と言語警告を出します。ここまですれば、操縦者は充分覚醒するという仕掛けです。
作業状況をわかりやすく表現するものを、別に用意して、作業員に提示することで、作業状況を把握しやすいようにするものです。
例えば、鉄道のタブレット。単線区間では、うかうかしていると、列車同士が正面衝突してしまいます。うかうかしなければ大丈夫ですが、人間の精神力や記憶力だけに頼るのは危険です。
そこでタブレットと呼ばれる通行票が用いられます。ある単線区間に進入できるのは、タブレットを持った列車だけという規則を作ります。タブレットは1つしか存在しないので、2つの列車が同時に同じ区間を走るという危険な状態を避けられるのです。（注：実際のタブレットや通票の運用方式には、もっといろいろな種類があります。）
飛行機は操縦士が2人ですが、これは2人で作業分担するためというよりも、一人(PF, Pilot-Flying)がやっていることを、もう一人(PNF, Pilot-not-Flying)が「それは何のため？それでいいのか？」と問いただすためです。(航空業界ではこのような人員運用体制をCRMと呼ぶ。）
自動車の速度計は、本当は助手席からも見える配置にした方がよいのです。「スピード出しすぎじゃない？」と言われると、運転手はハッと気付きます。ただ最近の自動車の速度計は、運転手の視線移動と焦点距離変化を出来るだけ少なくするという設計思想のため、助手席からは覗けないようになっています。別途、助手席用に速度計を設置してもらいたいものです。
ソフトウエアの製作では、二人組でプログラムを作る「ペア・プログラミング (pair programing)」という手法が使われます。二人組に与えられる課題は同じなのですが、二人は別々の役目をします。例えば、Ａさんがプログラムのある部分を書いている時に、Ｂさんは「そう書いたのは何のため？」と聞く役をします。Ａさんは答えることになります。頭の中で勘で考えている事柄を、声に出して説明すると、自分を客観視できるわけです。
医薬分業は、複数人が独立にダブルチェックするためのシステムです。大規模病院になると、ダブルどころではなく、医師・看護師・薬局・病棟などなど何重にもチェックします。
操作履歴記録器（フライトレコーダなど）を機械に装備したり、違反検知手段（ネズミ捕りなど）を配置することで、ユーザに無謀・無配慮な操作をすると記録されるという心理的緊張をかけ、慎重にさせる方法です。
二人作業班にくらべて、ついつい装置の存在を忘れてしまいがちです。さらに、事故後にデータが証拠として使われることに嫌われる傾向があります。ネズミ捕り検知装置をわざわざ買って自動車に装置する不心得なドライバが出てくるわけです。（ネズミ捕り検知装置は大手家電量販店でも販売しています。大手企業にしてはあからさまな反社会的な行動ですが、問題視はしていないようです。）
本来なら事故前に、助言・警告・気分転換刺激を出した方がよいのです。今後はこのような装置を増やしていきたいものです。
人々の中で自分が行動していることを気付かせ、安全かつ寛容な操作を促す方法です。自分と相手とを相対的に見させる自己客観視を促します。
各ユーザを、没個性的な状態ではなく、個性・識別性・逆探知可能性（トレーサビリティ）を備えた状態にすることで実現します。
例えば、「赤ちゃんが乗っています」シール。相手が、ただの車ではなく、具体的な生活背景のある人間であることを気付かせます。自動車のオーナーによる個性化（ちょっとしたシールからデコトラまで）は、相手の社会性本能を刺激するでしょう。
非匿名や会員制のWebサイトでは、違反行為は困難になります。これは検挙される危険というより、“恥と外聞”を意識した結果でしょう。誰かを面罵することは、匿名サイトなら簡単ですが、“相手の顔が見える状況”では度胸がいります。
【逆・社会化＝官僚主義】 分業を進めすぎると、作業当事者と、被害を受けかねない人とが、全く顔を合わせない、という状況におちいります。警報が鳴っていても、「警報への対応はお茶の時間の後にしよう」(1984年、インドのUCIL社工場の毒ガス漏洩事故)とか、「酸素は明日に納入されるから、すぐには対処しなくていいだろう」(2005年、長野赤十字上山田病院の酸素切れ事故)と、のんきな心理状態でいられます。
スカンジナビアの国々では、自動車のヘッドライトは始終つけっぱなしにすることに、法律で定められています。このため、ヘッドライトをオンオフするスイッチ自体が、自動車にありません。したがって、つけ忘れのヒューマンエラーが起こりえないのです。
ヘッドライトの常時点灯は、燃料の消費や、バッテリーの負担、エンジンの押しがけがやりにくくなるなどの、多少の弊害がありえます。しかし、薄暮時の交通事故が減るなら、常時点灯を強制することに社会的利益があるわけです。
手紙の郵便料金は、配達の距離によらず均一です。途方もない手間はぶきです。郵便では決済にからむの手間のコストが一番高いことを喝破し、これを免除したその時、近代的郵便制度が誕生したと言えます。飛脚は太古からありました。この発明まで何千年もかかっています。不思議といえば不思議な話です。
あまりに単調な作業は作業者にとってかなりの苦痛になります。身体的にも精神的にも大変です。（単調作業をさせる刑罰「空刑」というものありました。）
このような仕事では離職率が高いため、高給を支払って労働力を維持することが度々行われてきました（Ｔ型フォード生産での「日給5ドル宣言」）。
工場レイアウトの改良、休憩計画の改良、達成感を感じられるセル生産方式の導入など、他に有力手段があります。
ヒューマンエラーの問題を解くときに、すぐに問題に飛びついてはいけない。問題を設定した人間の都合や思い込みが反映されていることがあるから。
字の下手な医師が書いた指示メモを、看護師が読み取ることができなかった。この医師は「これでも読める人には読める」と言う。また看護師は引っ込み思案気味で、何と書いたかを医師に問いただすことができなかった。そして機械の設定をまちがえた。
本が勧める対策。まず、○○法を使って、事故の経過を時系列に分析する。それに基づいて、困難なステップを補強したり迂回する対策案を考える。最終的には、ダブルチェック、写真を使った機械取扱説明書の作成、看護師の教育体制の見直しを行う。だそうです。
私の考える対策。第1点。医師の悪筆を問題の前提条件にして問題を解こうとしている。医師を免責してしまっている。この問題設定をやめる。
第2点。医師と看護師との権威の勾配が強すぎる。これでは権威勾配を背景にした別の事故はまた起こりかねない。
権威勾配の対策としては、目上の人をまちがえをただす体験、あるいは目下の人にただされる体験をする模擬演習をするのが効果的です。とっても偉い先生が、「これからわざといくつかミスをするので、変だと思ったら質問してください。『やれ』と言われても、不審な点があったら従わないでください」と宣言し、芝居を進めます。
第3点。指示の伝達はかなりまちがえやすい作業であることを認識する。手書きを禁止するという対策も考えられるが、キーボード入力式でもまちがえる危険性は残る。歴史を見ても苦心惨憺たるものがあり、復唱させる、ハンコを使う、表を使う、選択肢丸付け方式用紙を使う、カーボン紙を使う、バーコードを使う、トークン（駒）を使う、アイコンを使う、カンバンを使う（＝情報を即物・即課題にする）、チェックディジット（検算用桁）を備えるなどなど、相当の創意工夫・設備投資・労力配分をしている。
【「まさか！」なことほど本当に起こる】 史上最悪の犠牲者数を出した航空機事故は、1977年のカナリア諸島テネリフェ空港の地上正面衝突事故である。機長・副操縦士・航空機関士・管制官・相手機の意思疎通が、用語のニュアンスの違い、勘違い、タイミングの悪さ、念押しの不徹底によって失敗。濃霧の中、離陸への滑走を始めた。その滑走路には、他の飛行機が地上移動しており、正面衝突。
583人死亡。地上事故が史上最悪という、皮肉な結果となった。ヒューマンエラーが主役になったことを象徴する事故である。
病気と疲労と加齢現象。これらをきちんと分けることは難しい。「誰かの価値観では不都合であり治したいと思っていること」と言うしかないようである。これでは物足りないので、以下のような定義例を持ち出すこともあるが、難がある。
病気の定義には価値観が反映する。通常の加齢による能力減退と、病気による能力減退とを分けて考えられるのは、価値観として「ま、気にしてもしかたがない」と思えるからである。
自分のしたいことに関係しないものは病的とは見なされない。力持ちでなくても、それでよい人は気にしない。
人間が何を思っているかに関係なく、それ自体が人間を占領しようとする現象。だが、加齢現象は病気とは見なさないので、この定義に当てはまるから病気とは言えない。
２００６年１２月５日、阪神高速道路神戸線で、トラックから積み荷の鉄の箱が２つ落下し、ひとつは後続車にぶつかり乗客が死傷し、もう一つは高速道路高架から落下して甲子園球場チケット売り場に墜落するという事故があった。
この箱は水上の建設現場で使うものである。大きさは幅2.5メートル、高さ1.5メートル、長さ5.5メートルであった。トラックの荷台からはみ出ていた。
●しなくて済む方法を考えると： そもそも巨大な箱を輸送しない。工事現場で箱を組み立てるようにすればよい。
●やり方の改良を考えると： 荷台から落下しないような固定方法を考案する。箱の大きさをトラックに積載できるものに設計し直す。
●被害抑制とやり直し手段を考えると： 積荷が落下しても大事故にならないように低速移動にする。高速道路を使わない。交通量の少ない夜間に輸送する。
●非常用安全手段を考えると： トラックの後ろに頑丈な自動車を追走させ、衝突しても怪我人がでないようにする。高速道路の側壁を極めて強固なものに変え、積荷の高架からの落下を防ぐ。
●問題現象の有効活用を考えると： この箱の輸送が安全になるようにヒト・モノ・カネ・時間をたっぷりかけ、「我が運送会社では、輸送困難な積荷であっても、我が社独自の特別な方法で安全に輸送する技術を有しています」と宣伝する。
解答例： 送信前に、送付先と本文を読み上げる。送信ボタン押下に、多少の時間を待ってから送信する仕組みにする。
メールアドレスが脆弱すぎるもの問題。一文字まちがえただけで、届かない。そのくせ、ローマ字だったり、ニックネームだったり、ne とか jp と略してある。また、画面表示の小さいこと。
さすがにメールアドレス自体をユーザがタイプすることはなく、普通はアドレス帳を使う。しかし、アドレスの名札が人名だけということもしばしば。Ａ社のタナカさんに送るつもりで、Ｂ社のタナカさんに送るという事故がありえる。
人違いしないように、人名だけでなく、付帯的な情報（所属、役職、自分との関係、性別、最終通信日、顔写真、似顔絵など）を使って、アドレスを探すようにすべき。
五叉路にて。普通の十字路だと思っていると、横切り車線の信号が赤に変わった時点で、次は自分の番だと思い込んで進みだしてしまう。しかしそれはまちがいで、五叉路なので別の道ための順番が間に入る。危険である。どうすべきか？
解答例： たとえば、横切り車線の信号が見えないように工夫する。五叉路であることを明記する。自分の順番まであと何秒かを表示する。
ネット上の売買で、「パソコン1台1円」や「1株1円で売り」といった価格入力まちがいを防ぐ方法を考案せよ。また、本当に1円で売りたい場合はどうするか？
解答例： もし金をかけていいのではあれば、保守主義・復古主義ではあるが、作業に人間を呼び戻すのがよい。
この間に1人増員して、設定価格の連絡を受けて入力する人を入れれば、ダブルチェックになる。あまりに変な価格設定ならば、鵜呑みにせずに異常に気付くだろう。（囲碁でいうところの「岡目八目」）。
また、人と人のコミュニケーションでは、「考えていることを声に出す、しぐさに出す」という“コミュニケーションチャンネルの変換”が生じやすい。これは話し手を自己客観視させるチャンスになる。映画「Ｕボート」を見てみると、上官の指令を部下が復唱しているので、ますます自己客観視できる。
とはいえ、数字入力の際のまちがいは付いて回る。これは現状の入力インタフェースがあまりに粗雑に作られていることがさらに助長している向きもある。異様に小さい数字入力ボックス、小さくてつぶれた数字活字、やたらと横長のボタン、半角と全角の混用に自動対処できない手抜き設計がまかり通っている。（ひどい例では、2006年2月7日の新発十年物国債の異常な値動きのケースがある。おそらく人為ミスによるものと言われている。このシステムでは、相場の値段は画面から消え（なぜ！？）、取引が成立していない注文だけが画面に残されるらしい。危険物しか残さないカラクリになっていた。）
復古主義的に考えると、かつては紙に殴り書きだった。すなわち、紙面を大きく使った（位置を覚えやすい）入力欄、大きな数字、操作実行を実感できる紙の手渡し、漢字コードも問題なし。
また、話し言葉では助数詞を使うので、1という数字が、「1円」のことなのか「1台」のことなのかハッキリ判る。断じて「売 610,000 @ 1」などという粗略な表示を許してはならない。「61万株を単価1円で売り」と表示すべきである。プログラマの手抜きを許してはいけない。
ここまでしても、「61万株を単価1円で売り」が正しいのか、「1株を単価61万円で売り」が正しいのか、すぐには見分けがつきにくい。1円玉の写真を出すとか、枚数分の株券の絵を出すなど、絵解きにする必要がある。
古きよき方式をコンピュータシステムで再現する方法として、大きい入力欄にする、手書き可のペン入力にする、助数詞を求める、ボタンの形状をちゃんと考えて設計する、キー入力なら全角半角問題を克服する、音声入力にするなどが考えられる。
ところで、今はやりの、「普段の操作とはあまりに異なる挙動をユーザが見せた場合、それをシステムが検知して警告を発する」式の方策は、やってもいいが、やや二の次という感がある。実際、2005年12月8日の東証での1円売り事故では、システムが異常に気付き警告を出したが、ユーザはそれを無視している。マウスとキーボードでピコピコポンの状況から抜け出ないと、ユーザは異常に気付かない。（囲碁でいうところの「手拍子」。）
また、警告表示自体も「Quantity, Level 3 Warning」という意味不明な文言で済まされることも多い。なぜ英語なのかと言えば、コンピュータは漢字を扱うことが不得意だからである。（21世紀にもなってそんな馬鹿なとお思いでしょうが、漢字を安全に使うためには、プログラムの費用がかかります。ソフトウエア代を値切られるのでここを手抜き。）
さて、いくら金をかけるべきだろうか？上記の事故では300億円損害が出たといわれるので、せめて3億円は防止策に金をかけてもよかった。（工学は、実写と見まごうばかりのコンピュータグラフィックスを作ることはできるが、全角半角混用問題などの難問はなかなか克服できていない。金にならないと烙印を押されている技術課題は進歩しないものである。）
新車を買おうと思っているとする。Ａ車は速度計がアナログのメータ表示。Ｂ車はデジタル（数字式）表示である。どちらを買うべきだろうか？
高速道路の長旅で速度を一定に調節する課業をこなすには、アナログメータがよい。速度の変化と安定性が見やすい。
山道や首都高都心環状線のように勾配とカーブの多い箇所を走る場合は、デジタル表示がよい。安全にカーブを曲がりきるために、速度をすばやく読み取る必要がある。（この際、速度の変化率はさほど重要ではない。）街中を走る場合も、速度規制の時々刻々の変化に従うためには、デジタル表示ですばやく読めたほうがよい。アナログ表示だと、52km/hを42km/hと読み間違えるなどの、エラーが起こりやすい。
解答例： 見るからに一歩まちがえば危険な状況であり、運転者が責任を感じ安全運転を心がけるから。また、周りの運転者も同様に警戒する。熟練者や安全路線のみに許可しているという制度の効果もある。
客は何分まで待てるか？店内で待つ場合と、店頭に並ぶ場合では、どう違うか？反応の遅いコンピュータに対して、待ちきれないユーザは、どのような行動を取るか？なだめるにはどうすればよいか？
解答例： 店頭に並ぶのなら10分ぐらいなんでもないが、店内に座った状態では待ちきれずにいらいらする。この差は主体性の意識の問題であろう。店頭に並ぶ行為は主体的に行っており、いつでもやめられる。店内に座ると自由が奪われ待つだけとなる。
反応の遅いコンピュータに対してユーザは、再度操作しなおす→でたらめなボタンを押す→強制終了を試みる→たたく→電源を抜くなど、次第に短絡的で破壊的な行動に訴える。なだめるには、何らかの饋還（帰還、フィードバック）を提示するとよい。「あと何分かかります」、「ただいま○○中です」、プログレスバーなど。とはいえ、饋還自体が故障していることもある。一番信用できるのは、ハードディスクのアクセス動作音である。これは故障のときに故障であることがわかるので。
偽造券を真券と見まちがえることもヒューマンエラーである。すかしだけで地紋が無い小切手は、すかしも地紋もある小切手と比べて、ヒューマンエラーにどう影響するか？
解答例： 日本銀行の小切手には地紋がない。なまじ地紋があると、それだけを確認するずさんな検査が横行してしまう。地紋だけなら精巧に偽造することはたやすい。大手新聞社の名刺も、きわめて素朴で、誰でも簡単に偽造できそうである。あえて凝らない証明書類の方が、かえって確認を促し安全と言える。
記憶力の“現実的な”問題。前の問題から、「人間は何文字（何チャンク、何かたまり）まで記憶できるか」と考えてみたくなる。以下は、この問に対する一つの回答である。正しいだろうか？
“朝、出かける際に、出すべき手紙をカバンに入れておいたが、ポストに寄ることを忘れて、目的地まで一直線に行ってしまった。こうしたことはしばしば起こりえる。したがって、人間の記憶容量は1チャンクすら下回っている。”
記録の現象と、再起の現象は、分けて考えるべきだろう。再起はデータの重要度に依存したり、指にこよりを巻きつけるなどデータの刺激性・外在性に依存する。
ありがた迷惑は難問である。雨の日の自動車の運転では、ドアミラーは雨粒にぬれて用をなさない。なので撥水スプレーをかけておく。だが、ガソリンスタンドで、“サービス”として、ふき取られてしまう。「ふき取るな」と書いたシールを貼り付けるのは、かっこわるい。いちいち言うのも面倒である。撥水ガラスの高級車は手が出ない。どうするべきか？
解答例： 解決策として選びうるものを考えると、ふき取りの際に確認を取るガソリンスタンドを選ぶ、サービスの無いガソリンスタンドを選ぶ、面倒でも毎回指示する、シールを貼る、高級車に買い換える、など。どれもパッとしない。
非常出口の扉は外開きに作るべきであるが、空間的事情のため、内開きの扉を設置するしかなかった。パニックになった人が逃げ出す際に、この扉をうまく開けさせるにはどうすればよいか？
解答例： 内側から強く押すと外れる・割れる扉など。パニック状態の人間に「内側から強く押す」以外のことをやらせようとしても無理である。
【向きのまちがい】 折れ曲がりストローの向きをまちがえて、折れるほうをジュースに突っ込んでしまうエラーがある。防止するにはどうすればよいか？
「検知段階の設置」： 紙コップ用キャップをつけ、ストローを刺し通す手順を発生させ、そこで気付かせる。
「エラーモードの排除」： 両方が折れ曲がりになっている“向き無し”の対称形状ストローや、（突飛だが）Ｙ字型などのあからさまな形のストローなどを使っている店はなかった。
向きについてのヒューマンエラーの法則： 向きの違いがあるくせに、形自体で気付かせない部品は、いつか必ずまちがわれる。(ボーイング747機左右エンジン取り違え装着事件。2005年12月21日。エンジンの識別番号で左右を区別させようとしていたらしい。エンジンの左右の向きを無くすのでもなく、かといってどの向きでの装着も許すというのは、中途半端である。)
設計定石＜「向き」「指向性」を無くすこと＞： 向きを無くせるものなら、無くしたほうが良い。電気機関車ＥＦ55は、向きの違いがあるため運用しにくく、お蔵入りした。（そして、ファンには向きの違いがゆえに持てはやされている。）
向きのために被害が大きくなった事故もある。久大本線蒸気機関車ボイラー爆発事故(1930年4月6日)では、都合上、機関車のボイラーが客車に近くなる向きに連結されており、客が蒸気を浴びて死傷している。
【向きのまちがい その2】 エスカレータの乗り方。関東式に右側を空けるか、関西式に左側を空けるかの選択がある。まちがえないようにするにはどうすべきか？境界地帯ではどうするべきか？
解答例： 2人分の幅があるのがまちがいの元である。ありがた迷惑である。1人幅のエスカレータなら、左右の選択がそもそも存在しない。歩くことも困難になる。
とはいえ、1人幅にすると、輸送能力が減って雑踏事故が起きやすくなる、既存のビルには寸法が合わない、天井とベルトの間に首を挟まれた場合に逃げ出しにくい、などの弊害がありえる。
みんなが歩いている現状を認めてしまうなら、指示の看板を出したり踏み板に印を描いたりして、交通整理することは可能であるが。
1） 頻発する。ほとんどすべての場面で、向きの違いという検討項目は存在する。しかし、計画段階で考えもらしやすい。向きのまちがいによる破綻は、頭の中で想像しにくい。模型を作って検討しないと大抵まちがえる。
2） どっちでもいい。選択の理由が乏しい。右側通行だろうが左側通行だろうが、その場の範囲内で統一されているなら、どちらでもよい。そして制度はバラバラに決められる。
3） 数学的に難しい。向きの違いが何通りありえるかを計算することは難しい。「この化学式の物質には、何通りの光学異性体が存在するか？」と、有機化学の問題でよく出される。
4） 被害は無視できないほど大きい。薬と同じ物質に見える光学異性体を飲むと毒になる。自動車なら正面衝突事故になる。
5） 露見が遅い。成功とわずかな差しかないので、途中まではうまくいき、最後の最後になってダメだったとわかる。薬とまちがえて砂を飲むとか、自動車の起動ができないといった、単純なエラーなら露見は早い。
6） 決められたルールを反射的に守るしかない。左側通行か右側通行かと、いちいち考えてもしょうがない。丸暗記するのみ。
7） 指示の二度手間をはぶきたい。向きがあべこべの作業を指示するとき、「〜〜のように行い、左右勝手違いの作業をもう1回行う」と省略したくなる。光学異性体は1つとは限らないのに・・・。
【目的物を支払わないと目的物が得られないシステム】 電話帳を電話番号順に並べ替えるとどうなるか？ビルの案内板を、階・部屋番号順に表記するとどうなるか？この方式のビルの案内板はなぜ多く見受けられるか？駅での電車賃の掲示は、駅名五十音順にすべきか？
項目の並べ方が使いにくさの原因となることがしばしばある。そのことに設計者が気付かず、自分の視点でものごとを考えてしまう。客の視点からすると、分かりにくい並べ方になる。
専門用語では「情報の非対称性の問題」というが、わかりにくく、それこそ情報の非対称性の問題になっている。「要するに、字引きを逆さまに作るを用となさないこと」と言えばわかるが。
自閉症のことを、自分の殻に閉じこもっている精神症状のことだと誤解している人は、わりと多い。なぜこのような呼称になったのだろうか？専門家が名称をつけることに問題はないか？
解答例： 学界は学問の歴史にとらわれやすい。発見者が命名権を持ち、研究が充分進んでいない段階で、後の世で適当でなくなる、表面的な名前を付けてしまうことがありえる。
また、重要である事柄に、別内容や非重要な印象をあたえる名前を付けることは、危険である。2005年10月12日の京浜東北線大森駅付近の学校踏切の事故では、横断者は「こしょう」という表示の真の意味がわからず、線路に立ち入って、電車にはねられた。 踏み切りは「故障」していなかったので、「こしょう」という表示は不適切である。「差しつえる」という意味の「故障」と理解する人は皆無だろう。（パスポートの外務大臣の要請文ではこちらの意味で使われている。）
Shneiderman,1987)によると、表示方法や操作方法には一貫性がなくてはならない。例えば、「はい／いいえ」の選択方法が毎回異なっていたら、それはまちがえやすいだろう。
出口予告標識は「逆さトの字型」の矢印で示される。この表示は一貫している。もうすぐ出口の意味である。
要するに、「出口」と「本線の分岐」によって、予告の看板は絵が異なり、分岐地点では絵が同一である。ややこしい。
しかし、現実の道路の形は、Ｙ字だったり、車線が減る分岐だったり、車線が減らない分岐だったりする。矢印の形を信じてはいけない。
箱崎ジャンクションのように、実際の道路形状に合わせた看板表示もあるが、これでは一貫性がなくなる。
一貫性を尊重しても、例外を認めるべきであろうか？例外に頼らない一貫性の設計は、どう行うべきか？
案内標識の場合、矢印の形状の一貫性を、現実の道路形状よりも優先している点でまぎらわしい。矢印の形状があらわしている内容は、道路形状ではなく、高速道路の出入り（料金や速度規制）に関する情報である。
矢印の形状は、現実の道路形状になるべく近似する方がわかりやすい。「高速を降りる」ことを示すには、別に記号などを使う方が無難である。
一貫性は、例外的状況で守りきれないと危険になる。普段の踏み切りは、列車の進行方向を表示する矢印が表示される。さて、何十分も遮断棹が降りたままで列車は全く来ず、「こしょう」とだけ表示され、矢印が点灯していない場合、通行人はどう思うか。矢印が点灯していないから列車は近くにいないはずであり、渡っても大丈夫かなと思う。実際、何十分も列車が通っていないのだし。こうして通行人がぞろぞろ踏切内に入り込み、運の悪い人が列車に轢かれる。
プラトンの本に「クラテュロス —名前の正しさについて」というものがある。その中で、単語の語感・響きと意味に関係があるかないかを議論している。
スリーマイル島原発事故で、弁が開いていることを示すには赤ランプ、閉じていることを示すには緑ランプを点灯させていた。「緑なら安全」と思い込んでしまう。しかし、弁の開平の妥当性は状況によるものであり、「いつでも閉じてれば安全」ではない。
注意誘導を、色だけに頼るのは工夫が足りない。表示のレイアウトや知覚チャンネルの取り合わせなど、広く考えるべきである。特に、心理的ポップアップ効果は優れた注意誘導を実現するので利用すべきである。これについては後で別に章立てて説明する。
近距離に、紛らわしい呼称がある。（横須賀と横浜。広と広島。豊田市と豊橋）。同一物に別呼称もある（梅田と大阪駅）。これらをまちがえない技法には、どのようなものがあるか？
呼称の方法を変える方法がよく見られる。固有番号を振る（駅番号）。ニックネームや異名を使う。修飾語をつける（大田淵と小田淵）。
解答例： 「新横浜北」がまぎらわしい。聞き手は先頭部分の一致だけで判断する傾向があるようだ。現在は「北新横浜」に改称されている。
パンくずリスト(breadcrumbs list)とは、大がかりなページ群の構成をもつサイトで、案内用に「トップページ＞スポーツ＞野球＞高校野球」と現在位置を示す表示のこと。童話「ヘンゼルとグレーテル」のパンくずによる道しるべからとった名称。皮肉にも、その道しるべは役に立たなかったけど。
ユーザ・インタフェースの論文では、わりと使われる言葉であるが、世間一般では通用してないので意味が分からない。代わりに、トピックパス
(topic path)という用語を使ったほうが無難。さらに言えば、「現在位置表示」で充分である。
また、「＞」や「→」の代わりに「：：」という記号を使うサイトもある。「関東：：東京都：：中野区」という風に使う。プログラム用言語の一種である、C++言語の約束では、「Ａ：：Ｂ」は「Ａの構成要素であるＢ」という意味を持つ。しかし、世間一般でこの意味が定着し通用するとは思えない。
大抵のソフトウエアで、分類しにくいメニュー項目は、「ツール」の「オプション」にごちゃごちゃ入っているのはなぜか？「詳細な設定」は微調整なのか？
「ツール」の意味から外れた奇妙な名称を使うこと。「ツールの中のオプション」という、わざわざ深く隠れた階層に置くこと。その了見がわからない。
解答例： 厳しい言い方をすれば、これでよいと考えている設計者が多いから。より正確には、ソフトウエア業界の慣例がそうなっている。（Linuxなどになると、 usr やら ls-F やら、素人にはわからない符牒を使うことがカッコイイという文化がある。本当に普及を望んでいるのか疑問である。）
かなり大手のソフトウエア会社の製品でも、「ツールの中のオプション」へ、雑多なメニューをごちゃごちゃ放り込んでいる。もはや暗黙の了解、不文律である。
また、分裂も生じる。例えば画面表示に関する設定が、「表示」メニューの中にあるのに、「ツールの中のオプション」の中にもあったりする。
本来なら慣例を大幅に見直す作業が必要である。しかし、ソフトウエアが巨大になると、作業は分担になり、従来品の追加的改良をするしか、現実的な方策がなくなる。慣例を白紙改正することは非常に難しい。（鉄道ダイヤでも、新線開通などの大変化がなければ、めったに白紙改正しない。逆に言えば、大変化がある鉄道ダイヤの方が、ある程度の頻度で白紙改正が行われているともいえる。）
なかには悪意を感じるものすらある。特に電子メールを「HTML形式で送信する」という設定がデフォルト（初期設定）になっているメール用ソフトウエアが多い。危険であるし、データの無駄である。「HTMLで送る人はネット素人」という感じがする。（漢字や欧州文字の文字コードの文字化け問題を解決するためにも、HTML形式にしているのだろうか？）
最近、メール用ソフトウエアを新しいもの（サンダーバード）に変えてみた。HTMLで送信という設定を解除する方法を発見するのに、私は11日かかった。実話である。それは、「編集」プルダウンメニューとか「ツール」とか「ツールの中の編集タブ」とか「詳細な設定」には無くて・・・・。
ソフトウエアの使い方がわからない場合は、最近はネット検索するか、ネットの質問サイトで訊く。こうしたスタイル、つまり普通の言葉での質問を受け付ける「ヘルプ」を備えたソフトウエアもあるにはある。しかし、大抵はトンチンカンな答えしか得られない。なぜかというと、質問文の中の（素人が使う普通の）単語と、「ヘルプ」の文章の中の（設計者側が使用する専門的な）単語との、マッチングをやっているだけであり、うまくいかない。
「実行ボタンを押すと、ウインドウがヒュンっと飛んで消えるのですが、消さないにはどうすればいいですか？」と訊かれても・・・。
要するに、「ヘルプ」文章の（素人に合わせた）質と量が、決定的に不足している。問答集(FAQ)を作るとき、類似の質問はまとめてしまうが、“検索の時代”では、これは避けたほうがいい。「ヒュンっと」と訊かれることもあるし、「パッと」と尋ねられることもある。両方の問答を載せておけば、「ヘルプ」のコンテンツを強化できる。
Windowであると言われる。）使いにくさの原因、「凝り」とは、要するになんだろう？なぜ設計者はそれに気付かないか？
解答例： ソフトウエアを道具として見なしている設計者は、あれもこれもできるように機能を増やしたがる。実際には使われない機能であっても、あるに越したことは無いと思う。
ソフトウエアを特定の課題に対する一解決手段と見なしている設計者は、不急の機能は削るべきことを知っている。大きなソフトウエアは、技術の伝承や、方言的ヴァージョンの管理が困難になる。こうした人間関係上の問題からすると、不急の機能は害がある。
数十万円する高級機種のネットワークプリンタなのに、本体の表示がせいぜい半角カタカナが20文字程度しかないのはなぜか？
解答例： ネットワークプリンタは、ネットにつながったコンピュータから遠隔で印刷注文を出す。そのコンピュータの上では、しっかりした入力用操作盤が表示されるので、これで充分である、ということだろうか。
また、高価格機種は、印刷のプロが購入する。毎日あまり変動しない、定型的な印刷業務をプロが行うのだから、トラブルは少なく、またプロなら対処できるだろう、という想定であろう。
現実には、プリンタの機械的トラブルが生じた場合、半角カタカナ20文字のメッセージだけが診断の手がかりになって、わけがわからない。往生することがよくある。
訊き方を工夫して、用件をつげる前に、「時間がある」という言質をとろうとする戦略は、非常にイライラさせる。（えてして、こういう訊き方をする人は、これが奥ゆかしい訊き方だと思っている。）機械からユーザへの問い掛けも、イライラさせることがある。共通する、イライラ原因とは何だろう？
取り扱い説明書では、カタカナ語を廃止すべきだろうか？廃止派の人はカタカナ語を使わずに、存続派のひとは可能な限り中学英単語を使って（いわゆるひとつの長嶋のように）、回答せよ。
解答例： 万人に理解されることが重要である。原則として日本人には日本語がよい。ただし、定着した外来語や、他に適当な言いかえが無い外来語（ワイシャツの「ヨーク」など）が使ったほうが安全である。最善策は、絵解きを文章と併用することである。これなら固有名詞の意味が見て取れる。
解答例： 人間同士の対面手続きなら、振り込め詐欺にはまっている人の様子や、金額、振込み先口座名称から、検知しやすいだろう。最近では密閉個室型のテレビ手続きブースも登場している。
ATMでは、顧客の様子（呼吸や体の動揺など）をうかがうためのセンサの配置、顧客への声かけ（音声で「事件後にすぐに振り込めと要求するのは詐欺ですよ」と言う）、非正常な取引には窓口取引をすすめるなどが考えられるが、普通の客にとっては無駄な手順となる。
そうは言っても、振り込め詐欺の被害は続いている。これほど報道され話題になっているにも関わらずである。窓口の係員が「振り込んでも大丈夫ですか？」と確認しても、5000万円ごっそり振り込んだという事件も2005年11月にあった。
結局、通知預金のような「大金をすぐには引き出せない預金」に預けるのが最善の防護策だろう。成年後見制度より、カドが立たなくてよい。
かつては、作業の中のひとつの手順をエラーすると、そこで手順が止まり、作業が成立しないだけだった。
先読みする機械では、作業の選択がまちがいであっても、機械が努力して自動的に作業が成立してしまう。
まちがった作業結果であっても、漢字誤変換に代表されるように、生半可な意味を持つ。「根尾谷断層」が「根小田に弾倉」になったりする。かつては、「根屋谷断層」という方式の誤植だったので、無能力な結果であり、突飛にはならなかった。
ある手順は、多少前倒しでやっても、多少後に先送りしても、作業全体には影響がない。では、その作業はいつやるべきだろうか？
例えば、ＡＴＭ（現金自動預け払い機）では、預金引き出しの場合、必ず最後に現金が出る。金を先に出すと、カードや通帳を回収せずに立ち去る客が出現する。
原爆投下準備で忙殺された米国海軍は、かつて花形だった一万噸級重巡洋艦の位置確認を忘却。その間に撃沈される。数日後、乗組員が漂流しているのを、たまたま発見して惨事に気付いた。米国海軍史上屈指の大被害となった。
火災は、火はまず天然に存在しないのだから、ほとんどが人災である。（エラーというわけではないが。）
酒田大火(1976年)と、阪神淡路大震災(1995年)での大火災とは、現象は似ているが、事情や状況経過はかなり異なる。
酒田大火と比較すると、阪神淡路大震災では、建築物の不燃化対策は進んでいたが、消防能力は地震のため混乱かつ減退。
また、火元が複数多発であり、数日後でも引き続いて発生する火災があった。暖房用の電気製品には安全装置が付いているはずであったが、多くの発火源になっている。なぜだろう？
阪神淡路の教訓： 建物を倒潰させてはいけない。電気製品の安全装置は、自分が倒れると電源が切れるという方式のものが多い。製品が倒れなくても、瓦礫が覆いかぶさった場合は火事になる。そもそも消防能力を減退させた最大の原因は、建物の倒潰であろう。
どちらか片方の教訓の実施だけでは不十分である。しかし、現実的には大規模な都市計画のやり直しは難しい。
【安全装置のジレンマ その1： 常用化】電子レンジを止めるために、いきなり扉を開ける人がいる。安全装置が正常であるからいいものの、危険である。安全装置に頼った操作を防ぐには、どうすればよいか？
1）使ってもいいことにする。別に追加の安全装置を備えさせる。この対策は、実現が難しかったり、コストをあげる恐れがある。
2）使いにくくする。大きな音が鳴るとか、機械を部分的に破壊しなければ使えなくするとか、手間が掛かるようにするなど。この対策は、いざというときに使うことをためらったり、使い切れなくなったりする恐れがある。あるいは、安全装置を「殺し」（破壊し）て、「使いやすく」するユーザが現れる危険もある。
3）そもそも危険な状態を無くす。例えば、電子レンジの扉をC字型の回転ドアにする。ドアで電磁波を遮断できるし、瞬時に扉を開けることができないので、より安全になる。
本当の制限より厳しく設定してしまうと、ユーザは「なぜこんなに規制が厳しいのか？」といぶかって、設定ミスが発覚する。これはいい。
だが逆に、本当の制限より甘く設定すると、よほど危険なことをしない限り安全装置が作動しないので、気付かれない。これを防ぐにはどうすべきか？
解答例： 安全装置が、制限内／制限超過の2種類の判別だけではなく、制限内低値／制限内正常値／制限超過と3種類の判定を行って、ユーザにフィードバックするとよい。
また、時間の経過に従って、安全装置が自動的に徐々に制限を厳しくしていき、警告を発するような仕掛けにする。長期間放置すると、制限が厳しすぎて何もできなくなるが、定期点検時に制限設定値を入力しなおせばよい。
大事故のパターンのひとつに、工場の生産ラインなどで、現場の担当者が安全装置を停止させて事故になったというものがあります。
現場担当者：「安全装置の言うとおりに“チョイ停”ばかりしていたら仕事にならない。現場の人間の判断でラインの制御する必要があったし、ずっと公然とやっていた。事故になったのは運が悪かった」
作業の監督者：「正規の作業手順を守らなかった現場担当者張本人が悪い。裏マニュアルなど無い。手順遵守の監督は定期的に行っていた。・・・はず」
生産ラインの設計者：「そんなことなら言ってくれれば調整したのに・・・。え、お前から見に行けって？ 数が多くて見切れないし、設計室から工場は遠くて・・・」
経営者：「現場担当者張本人に責任があり、刑事裁判になった場合の経営者の法的責任はほぼ無い。だが道義的責任は取らされる。さらには経済的な問題。経営者としての能力が疑われてしまう。痛い・・・」
生産工学の学者：「『雑草という名の草はない』というように、チョイ停という名の事故はない。大野耐一の言うように、急がば回れで、原因を徹底的に追究せよ。
この手の不確実性の源は、実にくだらないことが多い。ネジが緩んでいた、ハンダが寿命をお迎えになられていた、部品の取り付け方向が逆だった、潤滑が切れてキーキー鳴っていたが放置されていた、マニュアルが古いままだった、パナマ運河通過中に高温多湿にさらされていた、前工程で部品をカゴに向かって放り投げていた、月曜日に作った部品だった、などなど。原因究明のためにラインを止める権限を現場に与えるぐらいでちょうどいい。」
【結論】 安全装置停止問題は、組織の風通しの問題である可能性が高い。「重大なことの解決策はこれまた重大で金がかかる」のではなく、「小さな基本を日々実践しておけば、大きな問題は自然に防げる」という経験則が成り立つだろう。
携帯電話が普及したためか、待ち合わせにルーズになった人が多い。便利さは人間を堕落させる一面も持つ。堕落させてもいいのはどんな場合だろうか？どう堕落を防ぐべきか？機械はユーザにペナルティを与えるべきだろうか？
解答例： 事態の悪化を伴う堕落は避けるべき。事態が悪くならない堕落は、むしろ「機械のおかげで便利になった」と見なすべきだろう。
携帯電話を使いながらであると、不定時刻に、場所を変えながら、相手を探すことになりがちで、取り決めの回数が増える。「後から決めればいいや」という心理にもなる。
なお、機械がユーザにペナルティを与えると脅して、ユーザをきびきび働かせる方式は、案外存在する。時間売りのサービスの場合は、「あと5分で時間切れです」と圧力をかけられる。
「文章は保存されましたが、音声認識データを保存する十分な空き容量がないため、データは失われました。録音していないときは、必ずマイクをオフにし、ディスクで利用できる記憶域を確認してください。（ＯＫボタン）」
1） 複数の事柄を一度に言う。保存と録音に何の関係があるのか。しかも矛盾している。文書は保存されデータは失われた、とは。
5） 「押せば直る」ボタンがなく、解決策も示していない。どの設定変更を行えばよいのか指示がない。ＯＫボタンだけ。
こうした折衝は難しい。もっと詳細に論じられているのが、ワインバーグ「コンサルタントの秘密 —技術アドバイスの人間学」共立出版。ただしこの本は身体障害に関する差別的表現が多いので注意が必要。
とあるエラーへの対策を行うべきと考えているが、うまい解決策がわからない。また、自分の職掌範囲ではない。関係部署に連絡して、解決策を考えるように頼んでも、特に進展していないようである。どうすべきか？
解答例： 自分で考えるしかない。下手でも気にしない。わが身のこととして望めば、長考に耐えられる。
自分で考え始めた時点で、自分はその問題の第一人者になったと思うこと。走っているのが自分だけなら、トップランナーであるし、嫌でもそうならざるを得ない。結局、技術は必要に迫られた人でないと、取り扱えないものである。
連絡は絶やさず、条件提示を微妙に変化させながら交渉をつづけ、形骸化しないようにする。完全な対策がある方より、組織内で会話がある方が何につけ健全である。
解答例： US Steel 社のスローガンである。もともとは、防災という倫理的な目的で導入された。実施してみると、生産性向上に寄与することが判明。裏を返せば、エラーや事故は経営を強く圧迫するといえる。
【エラーの伝説化】 エラーや事故は、人々の関心を呼び、発生すると詳細に記録される傾向がある。なぜだろうか？
製図用コンパスのことをぶんまわし（分廻）と言うが、この語は「源平盛衰記」で鳥の絵の切り抜き失敗談の中に出てくる。
誤植にも「姦淫聖書」という伝説的な誤植がある。筆名の山本周五郎もエラーが起源。最近では、「みのがしてくれよコーナー」というのもある。
事故によって、部外者にはうかがい知れない内部の実態が暴露される。事故を起こした者は、内情を説明する責任を負う。説明を完結させる必要があり、不都合な情報を隠蔽することが難しい。
「まちがい」と見なされてきた現象が、いざ出現してみると、有効利用され、発明の契機になることも多い。
百九段：高名の木登り。木から下りようとする人を、木登りの名人が監督していた。高くて危ないところでは何も言わず、低い所になってから注意せよと声をかけた。緊張のレベルが高いところでは何も言わなくても自分で気をつける。緊張のレベルが下がる局面で油断が生じ怪我をしやすい。緊張レベルの適正化は、現代のヒューマンエラー学でも重要事項とされている。
百十段：双六（バックギャモン）の名人。勝とうとするな。負けじと打て。劣勢であっても、どの手が一番速く負けにつながるかを考えて、その手を使わず、少しでも負けが遅くなる手を選ぶ。この考え方は数学でミニマックス戦略と呼ばれるものであり、現代的である。Fault Tree Analysis に通じるものがある。事故の渦中では、勝ちを探すのではなく、「負けじ」と行動するのがよい。
百二十七段：改めて益なき事は改めぬをよしとするなり。同じ意味のことわざに、「壊れてなければ手を出すな」（ワインバーグの言う、エンジニアリングの第1原則）。うまくいっている事柄に、なんとなくヒューマンエラー防止策を導入するのは危険。
二百二十九段：よき細工は少し鈍き刀を使ふと言ふ。（短い段なので真意はわからないが、便利な道具や強力な道具は、むしろ作業には向かないことがある、ということか。失敗した時に被害が大きいから。とはいえ、切れ味の鈍い刃物はむしろ危険である。切り込むために大きな力が必要になったり、予想のつかない動きをしたり、刃が折れたりする。）
何が“不本意”になるのかは、意味的で恣意的に決められます。作る機械あれば、壊す機械あり。ユーザの都合に応じて“本意”は変動します。コンピュータのファイルを完全に消すべきか、否か。そんなことを、理論できっちり断言できないはずです。
ちょうどこれは、フィリップ・Ｋ・ディック著『アンドロイドは電気羊の夢を見るか』に出てくるVoight-Kampff
機械は異常に気付いていません。でも、この意味と恣意性が分かるようになれば、機械は立派なパートナーとなって、人間がミスしてみ指摘してくれるようになるでしょう。
例えば、メールの送りまちがいはどうでしょう。メールの宛先・内容（頻出単語）・サイズを確認し、普段とは違うなら、「変ですよ」といってもらいたいものです。（現在、迷惑メールの判定はかなり成功しています。なら、自分のメールの検査もできるのではないでしょうか。）
人間は「しまった」と思うと、脳の前頭葉のある部分にある脳波が出ると言われています。これを Error-Related Negative (ERN)と呼びます。とはいえ、実験室で雑音や妨害になる出来事を排除してようやく測れる脳波です。ERNを使って何か実際の現場での分析に・・・とは、まだいかないようです。
では、精神の方から考えるのはどうなるでしょうか。なんだか哲学的になってしまいましたが、実際に哲学で、フッサールやハイデガーがこれを論じているらしいのですが、ワカリニククテてわかりません。
しかし「必要は発明の母」でして、エラーやら仕様設計ミスに苦しめられてきたソフトウエア業界では、立派な実用書が既に出ているので、こちらをお読み下さい。
ドナルド・ゴース、ジェラルド・Ｍ・ワインバーグ著「ライト、ついてますか 問題発見の人間学」、共立出版。
要点は、「問題が存在していることと、問題がどう見えるかと、問題をどう解くべきかを、分けて整理して考えよう」ということです。
機械が逆命する理由をユーザが理解できない場合は、忠は乱になる。例：中華航空機名古屋空港事故(1994年)。
本質的には相反しないはずなのに、使いやすさと安全性は相反する関係になることが多いです。暴発しにくいものの、何重もの安全装置を解除するのが手間である機械などというものが作られてしまいます。
その原因は、「制御が楽」vs.「作業内容を観察し介入できる」の対立にあります。「ボタン1発」が作業内容の観察の機会を失わせているのです。
本来考えるべきことは別にあります。なぜ事故のきっかけが大事故に発達したか。きっかけは別でも同様の事故は起こりえたか。きっかけは同じでも別の事故結果は起こりえたか。それを防ぐには、各々の職責レベルで、どのような態度を採るべきであったか。責任の所在や因果関係を固定的・限定的に考えない方が公平だと思います。きっかけはしょせん偶然の産物にすぎません。
製造者責任と管理者責任の標準となるような、安全への技術原則を定式化し発信する。（法規制ではないが、裁判での目安にはなる。）
製造物責任を問われるようになった一因は、作業員〜行政の範囲の責任追及してもやっぱり限界があることに世間が気付いたからでしょう。
安全工学の観点から言えば、責任追及より再発防止が人類みんなのため。社会的・経済的に言えば、事故が起これば全員敗者。この観点から安全コンサルタントを行う人材を、大学工学部がろくに育てていないことは大学の責任。
デザイン誘発エラー：操作の仕方が直感にあわないことで引き起こされるエラー。見た目が紛らわしい。ボタンの配置、レバーの向きが変。
このように、本質的でない事柄に細かく指定を出すのは、ＧＵＩ製作者の手抜きである。ちょっとの手間で対処できるのに、手を抜かないと利益が出ないのでしょうか。
ＷＥＢは会社の名刺・看板とも言えるが問題視されていない。かなり有名な企業でも、この程度の恥ずかしいＧＵＩを放置し、問題があったらコールセンターの要員で尻拭いすることで満足していることがほとんどです。
自動車のトランクルームの蓋のちょうつがいの腕。すこし昔の大衆車では、荷室の蓋をささえるアームがむき出しになっていました。このため、荷物の位置が悪いと、蓋を閉めるときにアームが挟まって、荷物が押しつぶされる事故が起こっていました。最近の設計ではアームはむき出しにしていません。
という名言がありますが、大衆車の安さを買う人はあまりいないと思います。安さなら、上級車の中古車でも充分求められます。
新車の大衆車を買う人は、別の目的で買っています。新車ならではの安全性能、車体の妥当な大きさ、乗員数、燃費、保守費用、減価償却、盗難の少なさ、などを買っているでしょう。荷物がつぶされるのを、安いから仕方ないと納得する人は、むしろ稀でしょう。
缶飲料の自動販売機の取り出し口： 照明なし。低い。狭い。痛い。衝撃。地味。防犯上の理由。改良版の問題点（速さ、厚さ、コスト）。
「トラブルシューティング」ボタンを押すと、マニュアルが表示されるだけ。本来なら、直感的に分かるインタフェースで無ければならない。操作具にユーザ誘導能力が少なすぎる。カタカナ語や長熟語の撲滅をすべき。
誤操作しても事故状態にならない工夫。つまり、システムを改良し、臨界状態をなくすこと。安全装置など。
部品が故障しても重大事故状態にならない工夫。つまり、システム、特に部品を改良し、無警告遷移をなくすこと。
デパートのレストラン街が最上階にあるのは、火災による上方階への煙充満と延焼を未然に防ぐためのフェイルセイフ。
模範的操作遷移で臨界状態を通らないといけない ⇒ 危険なシステム。昔は安普請システムならしょうがないとされた。
模範的操作遷移ではないが、臨界状態にたどり着ける ⇒ 危険なシステム。設計者の想定が悪いのか、“ユーザのいたずらが事故原因”なのかは、議論の余地がある。
電球を2個用意する： 片方が切れても、一応の明るさは保たれる。比較的暗くなるので片方が切れたことに気付く。
ダブルフィラメント： 電球を2個設置するスペースが無い場合は、一つの電球の中に2本のフィラメントを入れたものを使えばよい。
少しの違いしかないのに、人間の心理にとっては特に目立つことを、ポップアウト効果(Pop-out)といいます。
情報処理しなくてよい安全装置。スプリンクラでは、80℃で溶けるアマルガムが栓（溶栓）になっている。温度センサがそれ自体でアクチュエータ（栓）になっている。
センサ + 回路 + アクチュエータで安全を管理しているシステム。安全装置設計としては安易の発想。現実には危険なことが多い。停電、計測誤差、保守、アクチュエータの制御、コストなど、難点がある。
「カードの片面が母音のアルファベット（A, I, U, E, O)であるならば、その裏面には偶数が書かれてなければならない。」
と書かれています。さて、規則が守られてるか確かめるには、どのカードをめくって裏面を確かめる必要があるでしょうか？（ヒント：めくるカードの枚数は2枚です。）
未成人は飲酒をしてはいけません。この法律が守られていることを確かめるには、次の4人のうち、誰を検査すべきでしょうか？
具体的問題の方は、正解の自信があるのではないでしょうか。たしかにこんなに当たり前の問題なら、小学校低学年でもまちがえないと思います。
ところで二つの問題は、論理学的には同一で、4つの選択肢の配列も同じなので、具体的問題の答えが正しいとすると、4枚カード問題の正解は、7(酔った人に相当)とE(未成年に相当)なのです。
「4」のカードは、反対側面に何が書かれていてもいなくても規則違反にならないので検査の必要はありません。「7」のカードは、反対側面に母音が書かれていると規則違反になるので、検査すべきです。
抽象的な4枚カード問題の場合、正解率は非常に低く10%程度とWasonは報告しています。ところが同じ人が、具体的問題ではまずまちがえません。
このように、人間の直感的に頼った推論、直感論理学は、問題が具体的なら当たり前でまちがえようが無い一方で、問題が抽象的だとボロボロであるという特徴があります。
【1】 要素的理解： 問題文や登場するものごとの意味が、（個別的であるが）分かる（だけ）。
【2】 説明的理解： ものごと同士の関係、問題が生じた文脈、動機、登場していないものとの関係などを、説明したり推測できる。頭の中にイメージが湧く。解答をまちがえにくい。(ノウハウ (know-how) を超えて“know-why”（ノウホワイ、ノウワイ）、つまり広く背景事情を知っていること。)
また、人間の情報処理を「認知・判断・実行」などとモデルにしてみたところで、それは絵に描いた餅ではないか、と言う事になります。具体的にするとなぜ正解率が激増するのか、そもそも「具体的」とは何か、充分わかっておりません。人間の核心部分はブラックボックスのままなのです。
事故原因の解明主義「どんな悪手にも理由がある」（林海峰）←→不条理主義「個々の事故は確率的現象であって理由は問えない。事故が起きやすい土壌が問題」
ベルトコンベアー作業 ＝ 作業工程の一部しか見られない。前工程と後工程を想像しにくい。 ⇒ 達成感がない。注意すべき点が分からない ⇒ 空刑（無意味な作業を何度もやらせる精神的刑罰）になる。
対策：意味を補強する。工程全体を説明する。達成を具体化する（こなした数だけ点をコインが溜まるなど）。孤独作業を避ける。
健康な成人なら使えるが・・・。子供の手が届かない。視力の弱い人には字が小さくて読めない。ユニバーサルデザイン。
徹底的に不運が重なった場合に起こりえる故障。部品の寿命が一斉に尽きるなど、運の悪さで到達できる事故。正常の設計・製造・運用であっても、確率的には極めて稀だが起こりえる。
現実に起きてしまった深刻な事故。設計時の想定を超えている。必ずしも、未知の新現象が事故の原因とは限らず、ずさんな運用（人間の問題）が原因になっていることが多い。
人間は、危険な行為をわざと行う傾向があります。若者の自動車の危険な運転がその代表と言われています。年齢が若いと、身体能力や習得能力は高いのですが、無謀さによって、事故が多いのです。
【1: 遊びと危険の見積もり】 スリルを味わうことは、遊びやスポーツの、ひとつの典型になっています。ジェットコースターのようなものです。危険に接近したり、眩惑感を感じることが、快感につながると言っていいでしょう。
危険に近づく人は、危険についての主観確率、つまり「これくらいは大丈夫だろう」という見込みを、頭の中で大雑把に計算しています。ゼロでは遊びにならず、100%では自殺行為。ごく小さいがゼロではない確率を推定しています。この見積もりが甘いから、事故を起こすとも考えられます。
あなたはタクシーに乗ったとき、シートベルトを締めますか？ 締めない場合、死に至る主観確率はいくらと見積もっていますか？
【2: 闘争本能】「人はハンドルを持つと性格が変わる」としばしば言われます。危険もありえる状況になると、冷静な判断ができなくなり、上で述べた主観確率そっちのけで、とにかくスリルを味わえるまで乱暴に振舞うわけです。
【3: 自己顕示欲】自己顕示欲による場合もあります。リスクを取りたいわけではないけれど、玄人っぽく、カッコヨクみせたいために、ちょっと危ないやり方をしたいわけです。例えば、文字が書かれていないのっぺらぼうキーボードをわざわざ使う人。何のことやら分からない用語・略語を使う人。「いつものアレ」と省略した（危ない）連絡を使いたがる人。「私は素人じゃない」ということを（他人や自分自身に）示すために、そんな行動をするわけです。
徒然草の「吉田という馬乗り」には、「名人はむしろ臆病で安全第一主義」とあります。「玄人は無駄なリスクを取らない」ということを自覚させることが、事故予防の要点です。企業文化として教育するか、シミュレータなどで事故を体験させ、誤った自覚を矯正するべきでしょう。
人間の視覚は貧弱なものです。視野はそもそも狭いですし、はっきり見えて色も分かる視野範囲はかなり限られています。しかもわりと主要な箇所に盲点があり、その部分は見えていません。（見えているつもりになっているだけです。）また、薄暮になると視力はぐっと落ちます。
要するに、「見なければならない所に注目する」からこそ目が使えているといえます。これを注意制御といいます。
注目を制御するために、聴覚を使っています。聴覚は全方向に対してまんべんなく注意を払えます。音源の位置や、音質、内容について推定できます。視野の外で起こっていること、さらには視野の中で起こっていることに対して、どこを見るべきか、何が起こっていそうかが分かるのです。
では、背後に起こっていることに不注意な人とは、何がいけないのでしょうか。直接的には聴覚に対する関心が足りないことが問題です。考え事をしていたり、目の前のことに過剰に集中していると、周辺に関する関心が落ちます。
すると、「頭の後に目がある人」は、常に周辺聴覚にも気を配っている人と言えるでしょう。このような気配りは訓練によって強めることができます。定期的に、たとえば5秒に1度は、意識を背後に向ける、あるいは意識を重要箇所（メータとか、子供とか）に向ける習慣をつければ、ヒューマンエラーを防げるようになります。
もっとも重要箇所はどこかをあらかじめ知らないといけません。スリーマイル島の原発事故ではこれが問題でした。危機的状況が始まると、警報が乱れ飛ぶことになります。その中で、注目すべき情報、無視しても良い情報、誤報と見なすべき情報（事故中はセンサが狂っていることが多い）を見分けなければいけません。防災訓練では、この段取りを訓練すべきです。
“仕事の設計”の見込み違いはしばしばありえます。仕事の設計とは人員配置、客の誘導、仕事の分配、伝票伝達の分配などの設計のことです。
窓口が急激に混雑したり、道路がたちまち渋滞したり、普通の時とちょっと変化しただけで結果が激変する現象があります。このような急変現象に対抗する“仕事の設計”は非常に難しいものです。
特に典型的な3つのメカニズムを憶えて置いてください。いつか、仕事のやり方を改善する時に役に立つと思います。（本来なら、中学校ぐらいで教えるべき。）
待ち行列とは、窓口などに並んでいる人の列を言います。食堂での料理待ち、コンピュータのサーバの応答待ち、料金所の順番待ちなど、私たちは毎日のように何かの待ち行列に並んでいるわけです。
待ち行列理論とは、平均窓口処理速度と平均来店客数との値から、平均して何分待たされるかを推定する算術です。
（例題1） ある駅の切符販売所は、1分間に平均して6人の客への発券業務をこなせる。また、平日の昼ごろは客は1分間に平均して3人やってくる。客は駅に着いてから切符を手に入れるまで、平均して何秒かかるか？
（答え）待ち行列理論の公式を使うと、(1/6)/(1-6/6) = ∞。 これは、こなしきれずに客がどんどん溜まっていく恐れがあることを意味する。能力に余裕のないギリギリの設備は客を長く待たせるものなのです。
（例題4） その駅で、切符販売機が故障し、処理能力が1分間に平均5人に下がった。客が1分間に平均4人来るとすると、何秒待ちか？
（答え）待ち行列理論の公式を使うと、(1/5)/(1-4/5) = 1分 =60 秒。 たった1台壊れただけなのに、3倍も待たされる！予測しにくい！
自然渋滞の発生のメカニズムのことです。電気の現象と同じメカニズムなので、こう呼ばれます。（空の水道管に水流を通すとき、水道管が水に叩かれでカンカン鳴るというウォーターハンマー現象も同じ。一種の間欠泉です。）
（例） 1車線の道。全ての車は巡航速度で渋滞なく流れている。道の一箇所に登り坂があり、そこにさしかかると自動車の時速はちょっと下がる。すると、後続の車は車間距離を保とうとしてブレーキを少し踏む。その後ろの車は、前の車がブレーキを踏んだので、ますます大きなブレーキをかけて減速する。そのまた後ろの車は、さらに強くブレーキを踏む。中略。最終的には、停車するはめになる車が出現して、渋滞になる。
対策： 高速道路を走るときは、車間距離を広く持とう！（そうすれば少々のことではブレーキは不要になる。）
饋還（フィードバック）とは、結果を見て、やり方の手直しするのことです。結果情報を上流工程に還流させるのでフィードバック（直訳して饋還）といいます。
饋還は素早いに越したことはなく、情報還流に時間がかかりすぎると失敗します。遅すぎる饋還の例：自動車の運転中に、5秒間目を閉じると、たいてい何かに衝突する。
饋還はある程度の力を持っていなければいけません。弱すぎる饋還の例：自動車のの運転中に、小指だけでのろのろハンドルを回していると、たいてい何かに衝突する。また、ハンドルと座席の背もたれが遠いと、力が出せず同様の結果になりやすい。
饋還は強すぎてもいけません。強すぎる饋還の例：自動車のの運転中に、興奮して全力でハンドルを回すと、たいてい何かに衝突する。
海上労働科学研究所編 久宗周二著「海で働く人の改善活動ガイド —船員労働災害分析と対策—」、高文堂出版社、2003.
たらい回し。（職掌上の分類にうまく当てはまらないと、他部署に連絡し、応答を待つ。そのうち、うやむや。）
第一発見者方式： 最初に受け付けた人間が、最後まで見届ける。（コールセンターで、「担当は○○でございました」と名前を言うなど。）
状況統制方式： “ものごと”に情報を集約する。その状況を全員に公開し明示する。（災害時の負傷者トリアージの札。）
精度的余裕が足りない → 治具の使用。下ごしらえ手順の設置。手順の外注化（完成した部品の購入）。増員。要求精度の免除。
予行演習を多く行えない場合は、加速試験（わざと過酷な架空の条件で試験）を行う。（やりすぎると危険ですが。）
「ヒューマンエラー」、「ヒューマンファクター」、「事故」などをネット書店で検索すると実に数多くの書籍が見つかります。最近の流行なのでしょうか。それらの本は互いに重複する内容も多いです。市立図書館や書店で下見して、本の独自性を確認する必要があります。（わりと市立図書館にも専門書が取り揃えてあります。）
また本によって、社員教育向けの訓話、認知心理学の話、事故事例集、事故原因究明本、設計“べからず”集など、役割付けが異なるので、タイトルに惑わされないように。
最も問題なのは、読んでみたところで具体的な解決策が得られない本が多いことです。JCO臨界事故の“分析”を読んでみたところで、「規則違反が原因」という、自明な結論しか書いてない場合があります。ずばっと切り込んで、工場監察部署は社外取締役直轄にして、経営陣から独立させるべし、ぐらいは書いてもらわないと、無駄な読書になります。(理工学書のコーナーへ行って研究書籍を見るより、経営書を読む方がましなことがしばしば。)
「問題が存在するという事実」、「立場による問題の受け取り方」、「問題の解法の適正度」、「問題の発生源」、「問題の解決必要性」をごっちゃにして考えてはいけない。
この本の第3部に「ファインマン氏、ワシントンに行く —チャレンジャー号爆発事故調査のいきさつ— (Mr. Feynman goes to Washinton)」があります。大統領事故調査委員会の委員としてスペースシャトルの爆発事故を調査した際の、簡潔にして詳細な記録になっています。
NASAなので、説明員はワイブル分布 (Weibull Distribution, 故障確率の計算に用いる)などを使って“理論的”に説明しようとするが、「エンジンの故障でロケット打ち上げが失敗する確率は 0 にならざるを得ない」と言われて唖然。
ケラーマン、ヴアン・ウエリー、ウイレムス編、(小林和孝訳)、「人間工学の指針 — 技術者のためのマニュアル —」、日本出版サービス。
事例を徹底的に列挙してあります。ボタンはこう作れ、計器盤はこうデザインせよ、暑さ寒さ、照明、人間の力の限界は・・・、と大抵のことは書いてあります。
トヨタ生産方式はあまりに有名ですが、原典であるこの本を読んで見みると、ヒューマンエラーの抑止、エラーからの回復、ヒト・モノ・情報の円滑な流れの実現が、具体的に書かれてあります。仕事の全体設計を考える人向け。
以下の書籍は、ヒューマンエラーや事故を専門的に研究したい人と、ヒューマンインタフェースの設計者とに役に立つ本です。
設計ミスから操作者のエラーまで、膨大な事例を列挙して分析を加えている。"失敗学"の理論的な考察も含む。
ドナルド・A. ノーマン著、「誰のためのデザイン?―認知科学者のデザイン原論」、新曜社認知科学選書、1988.
認知科学をユーザビリティに適用した金字塔。人間を単純に捉えることを否定し、ユーザの高次の知能を前提として使いやすさを考える。本書を読めば複雑な問題があることは分かるが、解決策が見つからないことも多い。このためノーマンは現在、機械から感じる印象や感情などの研究に転向してしまったようである。
人間の身体寸法から、認知能力、群衆行動まで広く浅くカバーしている。グラフや写真が主体なので、概説を求めるときに重宝する。私の本棚あったこの本を見て、2人の同僚が自分で買いなおしたほどの重宝ぶり。
パイロットによる事故生還事例分析。航空の事情や用語がよく分かる。各社の文庫にはヒューマンエラー関連の著作が多数ある。なまじ工学の書架に行くよりも文庫コーナーを探したほうが良書に出会える。
海難審判庁：「海難分析集」各年度版あり。Webで全文を見ることが出来る（偉い！）。ただ、事故原因は毎年マンネリ気味である。割と凡ミスが多いので、人が犯す凡ミスの実例を知りたい時には読むと良い。
システムの起こしえる様々な故障の様態（故障モード）を列挙し、それぞれの深刻度を評価する手法。深刻度は
Risk Priority Numbers (RPN) と呼ぶ。各故障モードのRPNは、故障影響度、発生確率、事前予知困難度などの積として計算する。
FMEAの目的は、考え漏らしのないように故障モードを列挙することと、深刻な潜在的危険を警告することにある。
人間のエラーの場合は、全く想定外の事故モードがあること、人間の権限による事故実行は影響が大きいなどの難点があるものの、よく使われる。
想定外の事故モードを計算に入れるためには、実地の試運転や、稼動開始後の業務改善体制が必要になろう。
Reason。エラーの分類。スリップ（不注意）、ラスプ（忘れ）、ミステイク（失策）、違反（自覚的自発的な行為ゆえエラーに含めず）。
充分考えつくせば、事故が起きる要件を列挙できたことになる。そこで次の“想定範囲設定”で答申をまとめる。
部品が信頼できるという想定範囲： 部品が設計仕様の通りに製造されていたら、どこまで遡れるか？
人員全員が規則を守るという想定範囲： 自発的行動・対応的行動・作業の質・作業の早さなどが、設定された規則に従って行われるとしたら、事故は起こるか？
その他、例えば悪環境条件の想定範囲： 夜間、停電、断水、火災時、冬のシベリヤ、サハラ砂漠など、過酷な環境では事故は起きやすくなるか？
実際との突合せ： 現実の事故率を、FTAの結果で説明してみる。作業員の読み取りまちがい確率=3％、圧力制御器の精度＝1%などと、数値を入れてみよう。それらの数値のアンドやオアを演算していけば、最終事故率が見積もられる。それは現実の値とどの程度合致するか？
記録する際に、時間軸は伸縮させてはいけない。出来事が何も無い時間であっても、時間表には空白として残す。
レベルごとの解決策（上策、中策、下策）：各解決策の完備度と、そのコスト。マイマネー主義（自腹で対策するなら、どこまで、どう費やすか。自分が社長であると仮想して考える。金に糸目をつけなければ、そりゃぁなんとかなります、という答案では不十分。採用可能性のある上策を磨く。）
対応責任者は一人であるべき。部署や委員会など人間集団の対応責任は、責任が分散され、極めて危険かつ非効率である。
人の手が加えられていないものは、それほどヒューマンエラーを誘発させません。天然物は構造が単純ですし、使う人もそれなりに用心して使います。
エラーを最も誘発するデザイン、それは廃墟です。廃墟といっても古代遺跡ではなく、最近まで使用されていた廃屋など、構造と機能がなまじ残っているものです。
人工物は、「こう使ってください」というメッセージをユーザに発しています。つまり人工物から意味を受け取るわけです。
腐った床を踏み抜いて何メートルも自由落下。部屋に入るときは開けられたドアが、部屋から出るときはノブが壊れて開かず、そのまま監禁。
ところがそうではありません。廃墟とは、人手が加えられず放置された人工物。最初は立派な人工物ででした。保守点検をしない、管理者が曖昧のまま使い続ける、環境の変化に応じて更新しないなど、よくある怠慢が続くと、普通の工業製品、システム、制度も廃墟と化します。
素人でも、操作をまちがえず楽にでき、玄人の求める細かい注文にも応える、そんなヒューマンインタフェースを持った装置。素人向けと玄人向けの二律背反を克服した、そんな都合のいいものがあるのでしょうか。
ここではその例として、メディアアートを挙げたいと思います。メディアアートといっても、テレビゲームなどを思い浮かべてください。
子供向けを前提にしたテレビゲームでは、当然ながら、ユーザへの情報提示と操作方法は、簡単で直感的でなければなりません。
かといって、あまりに単純なゲームは、楽しくありません。複雑な操作や、訓練を要する操作が無いと物足りないです。
もっとも「ドラゴンクエスト」の「復活の呪文」のように、ヒューマンエラー頻発のものもありましたが。
ユーザの意図と結果との連関追随性： 自分の思い通りに、自分の操作の結果が、すぐに反映される。何をどうすればベターから分かりやすいので練習の余地がある。
航空機事故と免責(ASRS報告制度、航空安全報告制度）。1974年のワシントン・ダレス空港着陸時の山頂墜落事故がきっかけ。この事故の直前に、他の航空会社の飛行機で全く同様のヒヤリハットがあった。すぐに、その社内ではヒヤリハット情報が周知された。しかし、会社の違いを超えて、ヒヤリハット情報が伝達されることがなく、大事故にいたる。この反省に立ち、社の違いを超えてヒヤリハット情報を連絡し共有すること、ヒヤリハット情報の公開を促すため報告者の責任を免ずることが制度化された。公益通報者保護法(2006年4月より施行)。内部通報制度と、外部への“内部告発”。
設計ミスが裁判になるとき。設計図だけでは裁判が怖い。何をどう考えたかは、最終図面から読み取りにくい。
廃墟・遺構。廃棄することの利益がないもの。えてして危険物になる。人工物としての意味が変質してしまう。
爆発事故推測の傾向： なぜか大事故・大事件の第一報は、伝言ゲームで“爆発事故”にされてしまう。地下鉄サリン事件(1995年)「築地駅で爆発」、中目黒駅日比谷線脱線事故(2000年)「中目黒駅で爆発」、尼崎福知山線脱線事故(2005年)「福知山線列車で爆発」。
少数派特徴への原因付与。当事者（特に専門職）に女性がいると、「女性管制官」、「女医」、「○○士の女性」と表現されます。
人的被害は把握され制御できているか。大抵の事故では、人的被害以外は急激な悪化を心配する必要が薄い。人間は価値が高く、かつ変化が速い特殊な存在である。
公正中立性： 「Aかもしれないし、ないかもしれない」という段階に煮詰まるまでは、推理的な分析をしない。対立仮説を持ちながら報道すると、本仮説の考え漏れが少ない。
遠因は、必ずしも退嬰的な企業風土であるとは限らない。意外なものかもしれない。事故の発展過程は、倫理性とは別個の問題である。
隠れる情報： 当事者発表に漏れた痕跡、傍観的な立場でひっそり計測していた装置の記録、返品率、労災件数、利益率。証拠の確度は高いが、目立たない。
「企業の危機管理」とよく言われますが、実際に効果があるのでしょうか。そもそも危機管理の目的は何なのでしょうか。上手な記者会見をすれば事故の賠償額が大きく減る、ということはありえません。テクニックに頼っても結果に大差はなく、なまじ頼る方が危険かもしれません。
ごく小さな事故が起きると、上長から「これは不祥事だから他言無用だよ」と一応の箝口令が出されることがよくあります。ありふれたことですが、「不祥事を隠すことが、組織にとっても、個人にとっても、自分の属する部局・班にとっても、最善である」と暗に思い込むようになります。事故を“不具合”などの婉曲表現や隠語で語るようになります。
そのような組織が大事故に直面すると、公開情報の齟齬から、情報隠蔽体質が露呈し、激しい非難を受けます。それは、事故によるダメージ以上に、組織の存立を危うくします。
通常のクレーム処理の手法を、重大な事故対応に流用することも危険です。客のクレームを待って対応する姿勢では不誠実な印象を与える恐れがあります。異常事態に対しては、前例踏襲型の解決、「相場な解決」を目指すことも困難です。ただ、クレーム処理部局以外に人員がいないことも多く、しばしば大事故の対応でこうした失敗が見られます。
では最善の対策は何でしょうか。それは普段からの組織運営にあるでしょう。非常時対応といっても、所詮は普段の体質の延長にしかありえません。
情報隠蔽がしにくい組織作りが望ましいです。例えば、人材の（社内外）流動を奨励したり、工場の顧客への一般公開を主要業務として取り組むなどが考えられます。
「はてな」の人力検索システムを社内に導入して、各自の質問を部署横断的に解決するという手は、なかなか賢い方法です。単なる風通しの良さ以上の、企業の技術力向上の効果が期待できます。
ある嫁は、実父から「離婚に備えて、家計からくすねてヘソクリしておけ」と言いつけられ、こっそり蓄財をした。これが発覚して離縁された。実父は「計画通り役に立ったわい」と得意げであった。防御策も行き過ぎると、破滅の主因となる。
詳しく書いてある本としては、野田正彰『喪の途上にて 大事故遺族の悲哀の研究』、岩波書店、1992年。
悲哀の受け入れに掛かる時間より、事故の事務処理のテンポが速い。事故の記憶の風化がつらい。刑事裁判にせよ、民事裁判にせよ、担当者の量刑と賠償金の決定が主題であって、遺族の意思の反映（事故防止策の徹底など経営的で行政的な内容）や、心情の整理につながらないことがある。民事裁判の目的が、もっぱら賠償金の額の決定となること（心身被害の現金化）に被害者は違和感を感じ、原告弁護人にも信頼を寄せられなくなることがある。裁判以外の情緒的な交渉は難しい。
「四枚カード問題」の現象からわかるように、人間によって問題の“難しさ”とは、問題の具体性によって大きく左右されます。問題の論理学的な構造は、難易度と結びつかないことがしばしばあるのです。
この現象を教育方法に応用することができます。問題をうまく身近な事柄にたとえれば、ムズカシイと思われている問題であっても、誰でも正解できることになります。
問題解決能力を育てる教育は、特定の問題をうまくたとえて教える、さらには生徒が自分でうまいたとえを見つけ出すように支援することを主目的とするべきでしょう。
5 と足して 15 にする。そして 15 – 7 を計算して、一の位は 8 だとわかった。残しておいた
ふつうの学校教育では“手続き主義的な教え方”で教えます。手続き主義は一貫しているので、どんな計算でも通用します。ただ、手続きを完全に暗記し、さらに作業の途中で、どこまで手順が進んでいるのか、忘れないように努力しなければいけません。
“算数が不得意”と判定される生徒は、暗記や手順管理が不十分だっただけで、実際に算数の才能が無いわけではありません。まぁ、悪い点のテストを恥を忍んで家に持ち帰ると、算数は嫌いになるでしょうが。
“難しいことを避けるやり方”は、誤解しやすい作業は後回しにする方法です。この方法を発見できれば、簡単で速く正確に答えが出せます。ただ、いつでも方法が発見できるか不確実です。
電卓の動作方法は、みなさん理解できたでしょうか。電卓は「引き算を全廃する」という革命的発想で作られています。みなさんが電卓に引き算をさせているつもりでも、電卓が実際にやっていることは、“補数の足し算と、その前後のちょっとした手間”の作業です。純粋な意味の引き算をする電卓はありません。足し算だけで済むなら、引き算のための回路を作る必要が無いからです。
学校で引き算を教えるときに、電卓の方法を教えないのはなぜでしょう？ふつうの手続き主義による方法より、手間が少なく、足し算を知っていれば使え、どんな引き算でも使用可能です。けれども、「作業の意味が全然わからない」という致命的な欠点があります。たとえ、電卓法を生徒が習熟しても、それは変な方法を暗記をしただけで、数学的な理解を深めたとは言えないわけです。
であるならば、手続き主義も同じくダメな方法になる恐れがあります。“隣の位から借りる”という作業は、“補数を足す”よりは、具体的でわかりやすい。しかし、”隣のそのまた隣の位から借りて・・・”となってくると、わけが解らなくなります。
ものごと同士の関係、問題が生じた文脈、動機、登場していないものとの関係などを、説明したり推測できる。
少ない訓練でできる。法律のようなものであり、解釈のぶれが少ない。実際の作業では、細かい規則の羅列となって、効率が悪く、まちがえやすくなることが多い。
訓練を要する。一旦、説明的理解してしまえば、頭の中でイメージが浮かぶので、要領よく考えることができ、まちがえにくい。
文章問題のように、数字を具体的な数量にたとえて考える。たとえ方が正しくなるように慣れるまで訓練する。
「たてがA列でよこがB列なら、全体はA×B個」という、表面的意味を理解する。九九を覚える。桁の大きいかけ算の筆算の手順を覚える。
かけ算の登場する現象の共通性を、絵を描いて、理解する。「時速A kmでB時間走るとA×B km移動する」と、「A個実のなる木をB本植えると収穫はA×B個」の絵を描く。
手順で覚える。割る数の分数の分子と分母を入れ替えてかけ算する。あるいは、小数にして、計算をやり通す。
意味をたとえてみる。A個をB人で分けるのより、C個をD人で分ける方が、(A÷B)÷(C÷D)倍多い。すると、AとCの比率が変わると結果はどうなるか。BとDの比率を変えると、どうなるか、いろいろイメージで実験してみる。
囲碁を王銘エン九段の「純碁」で教える。少ないルールを憶えるだけでスタートできる。例外がない。(囲碁は発明が古すぎて、元々の要素的理解が忘れられていた珍しい例。)
要素的理解の方がよいか、説明的理解の方がよいかは、場合によります。それぞれ一長一短があります。また、説明的理解は、うまいたとえを考案しなければ選ぶことができません。
要素的理解では、手間が多く、脳に作業的負担がかかる。また、脳のクセである直感論理学は欠陥だらけであるので（「四枚カード問題」）、手順の長い要素的理解では、まちがえやすい。
連想試験や供述試験は、答えの白黒がつきにくいので、あまりテストでは出されません。しかし、理解状況を知る上では、本来、優れた測定法なのです。採用面接や訓練などで、作業員の理解度を把握しする良い方法になります。
情報を、自分の知識のどこに組み入れ、どのように取り扱えばよいのかわからない。「どこが分からないのかが、分からない」
「成績が悪い」⇒「勉強しろ」⇒「予習や復習をして、ドリルを繰り返しこなせ」と、よく言われます。それは、暗記の定着には効果があっても、理解できる道筋の発展につながるものでしょうか。理解が進まない原因を、上の表のようにじっくり考えてみる必要があります。
手続き主義の解法は、練習を積まないと、まちがえやすいものです。要は慣れの問題です。問題集にはやたらと同工異曲の計算問題が載っていますが、練習して手続き主義の難点を克服しようという発想なのでしょう。さらには計算の速さを重視する教育も見受けられます。
だったら電卓みたいに補数を使えば、最も速く、まちがえにくいと思うのですが・・・。足し算のみなので、数を借りる手間が省けて、速い、と考えてこそ手続き主義ではないでしょうか。
かつては、コンピュータが無く、計算は人手でやっていました。計算を素早く正確にできる人を会社員に採用する必要があったわけです。しかし今はそうではありません。計算が遅くてまちがえても、計算作業のイメージを確実に把握している人、数学的センスのある人が、むしろ求められている人材といえましょう。
数学者カール・フリードリッヒ・ガウスが小学生の時の話です。先生が「1 + 2 + 3 + （中略） + 99 + 100」の計算をしなさいと言いました。ガウスは即座に5050と答えました。正解です。正確に足し算をする訓練をするより、この数式の意味をイメージして、何が起きているのか考えることが、結局は圧倒的に速く正確な答えを出せるのです。
教育現場で、“やさしい”問題から始めて、だんだん“難しい”問題を解かせるというカリキュラム作りが採用されます。
しかし「四枚カード問題」で見たように、難易度は問題のイメージのしやすさが大きく支配していると言えます。問題自体の“難しさ”より、問題文の具体性の差や、生徒のイメージする経験がものを言うでしょう。
難しい問題の方がなぜか具体的な文章題で“応用問題”と称されています。あべこべです。具体的な問題の方が圧倒的にやさしいはずです。それをざわざわ手続き主義の反復訓練のために、無味乾燥な“やさしい”問題から解かせて、生徒を混乱させているとしか、私には思えません。
難関大学を受験する生徒が勉強するいわゆる受験物理では、物理学の始祖のニュートンやライプニッツの言ったとおりの微分方程式を使って問題を解くように指導されます。高校の範囲外ですが、この方法を用いないと難関大学の問題は事実上解けません。予備校で作成する模範解答もこの方法です。暗黙の了解、公然の秘密です。
高校で教えられる物理学は、微分方程式を使ってはいけないので、代わりに“公式”を使います。公式とその利用の手続きを延々と教えられます。内容より手続きの暗記が重視されます。微分方程式は禁句なので、内容の説明は不可能です。
建前上、難関大学の問題も、これら“公式”を使って解ける範囲ではあるのですが、奇奇怪怪な論理になります。むしろ、この方法が使いこなせる人は、一種の天才です。ただし物理学の才能は保証できませんが。
そもそも人間はどのくらい頭がいいのか、人によって頭のよさはどれくらいばらつくのか、について考えてみましょう。
結論から言えば、「人間は全員、個人差や年齢差は問題にならないくらい、とてつもなく頭がいい」といえます。さらには、多くの動物も頭がいいのです。
特に人工知能学者やロボット工学者はそう思うのです。「四枚カード問題」の現象はこの考えの根拠の一つです。他にも、万人が備える、とびぬけた頭のよさを示す証拠はいくらでもあります。
例を挙げます。身の回りを見てください。パソコンがあって、コーヒーカップがあって、机があって、机の一部に汚れあって、紙があって、そこには明朝体で書かれた文章があって、壁があって、壁は青で、壁の幅は3メートルで、云々。
何とはなしに、周辺の状況を認識できると思います。簡単な作業です。特に脳内で複雑で大量の演算したとは思えません。
では、カメラを持ったコンピュータやロボットが、人間と同じように映像を認識できるのでしょうか。人間にとってはすごく簡単な課題でしたから、ロボットでもできそうです。実際、ミンスキーというMITの計算機科学者は昔、簡単だから学生の夏休みの宿題として出したという逸話があります。
現在までのところ、この課題つまり、自分の身の回りに見えているものが何か、そのものの特徴は何かを認識するプログラムは、コンピュータにはできていません。むしろ製作不可能とみなされています。かろうじて、特定の物体しか登場しない部屋の中など、認識の範囲を限定すればプログラムでも可能です。しかし、そのプログラムが、砂漠でも、南極でも、渋谷でも、胃カメラでも、人間並みに認識するようになるには、当面、不可能でしょう。
ハードウエアの面だけでも実現困難で、計算量と記憶装置の量を考えると、巨大な計算機とメモリが必要になると思われます。ましてやソフトウエアをどうやって作ればいいのかわかりません。
動物も頭がいいです。今、窓の外の水溜りで、スズメの群れが水浴びをしています。彼らは、適当な深さであって、周りに敵がいない水溜りを認識できるのです。スズメは、エサであるものを認識します。仲間を認識して群れます。巣を、適当な場所に、組み立てることもできます。
こんなに多様な作業をするための視覚能力は、前述のようにロボットには未だ不可能です。スズメの脳は小さいので、スーパーコンピュータなら量的には対抗できるようになると思われます。ただ、ソフトウエアの作り方は相変わらず難問です。巣作りの方法など絶望的に難しい。
このように、動物やより複雑な人間は、そもそもとてつもなく頭がいいと言えます。朝起きて、夜寝るまでにこなす作業は、論理学的・人工知能学的には途方も無く難解で演算不可能な問題ばかりです。それを苦も無く解けるのは、異常なまでの頭のよさです。誰でもこなしているのですから、頭のよさの個人差など議論している場合ではありません。
この超絶的能力をうまく学校の勉強に適用できれば、誰でも“頭のいい子”に育てられるはずです。ただ、次に述べるように、この方法は手間がかかるのです。
プラトン著の『メノン』という書物は、教育学の元祖ともいうべき古典です。その中でこんな話が出てきます。
ソクラテスはこう考えます。最初から、正解である「面積は4倍になる」ことを“教えて”も、それは教育にはならない。天下りで伝達された知識を理解することは不可能である。人間が“知る”ことができるのは、自分の内側から“知った”時だけである。自分で“これは変だぞ”と思わない限り、本当の知識を獲得する機会はない。天下りではお題目を暗記するだけである。
古代ギリシャで既にこのような教育法が、有名学者のソクラテス先生によって提唱されていました。それにも関わらず、現在の学校教育にて、“効率的”と思われている知識伝達型の教授法が幅を利かせているのは、歴史の皮肉です。
エラーや試行錯誤で問題の本質に気付かせる教育は、深い理解が得られるものの、なんとも効率が悪く、時間もかかります。気付かせる方法は、一定ではなく、題材や生徒に応じて変わるものも難点です。
このような手間のかかる方法は、例えばアルバイトの従業員に機械の操作方法を教えるなどには適しません。人材教育の時間が高くつきます。この場合は、暗記と反復練習で、早くやり方を習得すればそれでよいのです。
かといって、人の健康に関わる重要な作業を行う機械を、アルバイト作業員が操作する場合も、通り一遍の研修だけで済ますのは危険です。事故に備えた訓練が必要になります。
出だしが速いのスタートダッシュ型をとるか、始めはもたつくが遠距離のカリキュラムについていける試行錯誤型をとるかという選択を、安易に行ってはいけません。
しばしば、これらの方法の性能を評価する際に、スタートダッシュ的な、短期での成績向上にのみ注目することがあります。また、学校でのテストも、タイムトライアル的な問題が多く、反復的な訓練を重視する、いわば偏見がかかった“テスト”になっています。
しかし、遠距離競争の観点も当然考えるべきです。年齢が高くなってからの成績が、低学年での成績より、はるかに重要になります。
出だしで成績上位だった生徒が、その後、上位を維持できるか、追跡調査してみるべきでしょう。上位陣だった生徒が、後から下位に転じるような教育方法は、スタートダッシュだけで、性能に問題ありです。
|
|
[ 95] ASP.NET の脆弱性により、情報漏えいが起こる (917283) (MS06-033)
[引用サイト] http://www.microsoft.com/japan/technet/security/bulletin/MS06-033.mspx
セキュリティ情報検索ASP.NET の脆弱性により、情報漏えいが起こる (917283) (MS06-033)公開日: 2006年7月12日 | 最終更新日: 2006年11月30日Top of section概要 :このセキュリティ情報の対象となるユーザー : Microsoft Windows .NET Framework 2.0 をご使用のお客様脆弱性の影響 : 情報の漏えい最大深刻度 : 重要推奨する対応策 : お客様は、セキュリティ更新プログラムをできるだけ早期に適用してください。含まれる過去のセキュリティ更新プログラム : なし警告 :917283 で、この累積的なセキュリティ更新プログラムのインストール時に発生する可能性がある既知の問題に関して説明されています。 また、このサポート技術情報には、これらの問題に対する推奨される解決策に関する説明も記載されています。 詳細情報は、サポート技術情報 917283 をご覧ください。テストしたソフトウェアおよびセキュリティ更新プログラムのダウンロード先 :影響を受けるソフトウェア : PC/ATMU以下のオペレーティング システム バージョン用の .NET Framework 2.0:•Microsoft Windows 2000 Service Pack 4•Microsoft Windows XP Service Pack 1 または Microsoft Windows XP Service Pack 2•Microsoft Windows XP Professional x64 Edition•Microsoft Windows XP Tablet PC Edition•Microsoft Windows XP Media Center Edition•Microsoft Windows Server 2003 または Windows Server 2003 Service Pack 1•Microsoft Windows Server 2003 for Itanium-based systems and Microsoft Windows Server with SP1 for Itanium-based Systems•Microsoft Windows Server 2003 x64 Editionこのマークをクリックして更新プログラムをダウンロードしてください。このマークの付いている更新プログラムは Microsoft Update からインストールすることもできます。Microsoft Update の利用方法については以下のサイトを参照してください。•Microsoft Update 利用の手順http://www.microsoft.com/japan/athome/security/update/j_musteps.mspx影響を受けないソフトウェア:• Microsoft .NET Framework 1.0 • Microsoft .NET Framework 1.1 • Microsoft Windows 98、Microsoft Windows 98 Second Edition (SE)、および Microsoft Windows Millennium Edition (Me)テストした Microsoft Windows コンポーネント影響を受けるコンポーネント :•ASP.NET上記のソフトウェアのテストを行い、この脆弱性による影響を評価しました。それ以外のバージョンに関してはセキュリティ更新プログラムのサポートに含まれていない、または影響を受けるものではありません。ご使用中の製品およびバージョンのサポート ライフサイクルを確認するためには、マイクロソフト サポート ライフサイクルの Web サイト をご覧ください。注: Microsoft Windows Server 2003、Microsoft Windows Server 2003 Service Pack 1 および Microsoft Windows Server 2003 x64 Edition 用のセキュリティ更新プログラムは Microsoft Windows Server 2003 R2 にも適用してください。Top of section詳細要点この更新プログラムは新たに確認され、非公開で報告された脆弱性を解決します。この脆弱性については、このセキュリティ情報の「脆弱性の詳細」の欄で説明しています。この脆弱性により、攻撃者は ASP.NET のセキュリティ設定を無視し、アプリケーション フォルダのオブジェクトの名前を指定して許可されないアクセス権を取得し、この脆弱性を悪用する可能性があります。この脆弱性により、攻撃者は直接コードを実行したり、ユーザーの権限を昇格させたりできませんが、攻撃者はこの脆弱性を悪用し、攻撃に使用する情報を作成し、影響を受けるコンピュータを侵害しようとする可能性があります。マイクロソフトはお客様に、できる限り早期にこの更新プログラムを適用することを推奨します。深刻度および脆弱性識別番号 :脆弱性識別番号脆弱性の影響.NET Framework 2.0.NET 2.0 のアプリケーション フォルダの情報漏えいの脆弱性 - CVE-2006-1300情報の漏えい重要上記の評価はこの脆弱性の影響を受けるシステムの種類、システムの典型的な展開形式およびこの脆弱性がシステムに及ぼす影響に基づいています。注: Microsoft Windows Server 2003、Microsoft Windows Server 2003 Service Pack 1 および Microsoft Windows Server 2003 x64 Edition 用のセキュリティ更新プログラムは Microsoft Windows Server 2003 R2 にも適用してください。注: x86 以外のオペレーティング システムのバージョンについての深刻度は、次の x86 オペレーティング システムのバージョンと同じです。•Microsoft Windows XP Professional x64 Edition の深刻度は、Windows XP Service Pack 2 の深刻度と同じです。•Microsoft Windows Server 2003 for Itanium-based Systems の深刻度は Windows Server 2003 の深刻度と同じです。•Microsoft Windows Server 2003 with SP1 for Itanium-based Systems の深刻度は Windows Server 2003 Service Pack 1 の深刻度と同じです。•Microsoft Windows Server 2003 x64 Edition の深刻度は Windows Server 2003 Service Pack 1 の深刻度と同じです。Top of sectionこのセキュリティ更新プログラムに関するよく寄せられる質問Microsoft Windows NT Workstation 4.0 Service Pack 6a このセキュリティ更新プログラムのインストール時に発生する可能性がある既知の問題にはどのようなものがありますか?サポート技術情報 917283 で、この累積的なセキュリティ更新プログラムのインストール時に発生する可能性がある既知の問題に関して説明されています。 また、このサポート技術情報には、これらの問題に対する推奨される解決策に関する説明も記載されています。 詳細情報は、サポート技術情報 917283 をご覧ください。 •マイクロソフト サポート技術情報 923100: セキュリティ更新プログラム 917283 をインストールするときに、コンピュータが応答を停止するか、エラー コード "0x643" が表示されることがある•マイクロソフト サポート技術情報 923101: Windows Server 2003 を実行しているコンピュータにセキュリティ更新プログラム 917283 をインストールするときに、エラー メッセージ "Error 1324. フォルダ パス 'Program Files' に使用できない文字が含まれています" が表示される•マイクロソフト サポート技術情報 929110: .NET Framework 2.0 用の更新プログラムのインストール後、大文字と小文字が区別されていたファイル システムで、大文字と小文字が区別されなくなる Microsoft Windows NT Workstation 4.0 Service Pack 6a および Windows 2000 Service Pack 2 の延長されたセキュリティ更新プログラムのサポートは 2004 年 6 月 30 日に終了しました。Microsoft Windows NT 4.0 Server Service Pack 6a の延長されたセキュリティ更新プログラムのサポートは2004 年 12 月 31 日に終了しました。Microsoft Windows 2000 Service Pack 3 の延長されたセキュリティ更新プログラムのサポートは 2005 年 6 月 30 日に終了しました。これらのオペレーティングシステムのうちの 1 つを現在でも使用していますが、どうしたらよいですか?Windows NT Workstation 4.0 Service Pack 6a、Windows NT Server 4.0 Server Service Pack 6a、Windows 2000 Service Pack 2 および Windows 2000 Service Pack 3 についてはライフ サイクルが終了しました。今後の脆弱性の影響を受ける可能性を防ぐため、これらのオペレーティング システムを使用しているお客様は、サポート対象のバージョンに移行することを強く推奨します。Windows 製品のサポート ライフサイクルに関する詳細情報は、マイクロソフト サポート ライフサイクル をご覧ください。これらのオペレーティングシステムのバージョンについて、延長されたセキュリティ更新プログラムのサポート期間に関する詳細情報は、マイクロソフト製品サポート サービス Web サイトをご覧ください。これらの製品に関するカスタムサポートが必要なお客様は、担当営業、またはマイクロソフト アカウント チームの担当者、担当テクニカル アカウント マネージャ (TAM)、またはカスタム サポート オプションのマイクロソフト パートナー担当者までご連絡ください。プレミア契約をお持ちでないお客様は、マイクロソフトサポート契約センター （営業時間 9:30-12:00 13:00-19:00 土日祝祭日を除く TEL:0120-17-0196 FAX:03-5388-8253） までお問い合わせください。連絡先の情報は、Microsoft Worldwide Information Web サイト の Contact Information のプルダウン リストから、国を選択し、[Go] ボタンをクリックすると、連絡先の電話番号が表示されます。お問い合わせの際、現地プレミア サポート営業担当にご連絡ください。詳細情報は、Windows オペレーティング システム FAQ をご覧ください。Microsoft Baseline Security Analyzer (MBSA) を使用して、この更新プログラムが必要であるかどうかを確認することはできますか?次の表にこのセキュリティ更新プログラムについての MBSA の検出の概要を記載します。ソフトウェアMBSA 1.2.1ESTMBSA 2.0.NET Framework 2.0不可可可MBSA に関する詳細は、MBSA Web サイトをご覧ください。Microsoft Update および MBSA 2.0 が現在検出しないソフトウェアに関する詳細情報は、サポート技術情報 895660 をご覧ください。Enterprise Update Scan Tool (EST) とは何ですか?セキュリティ情報で提供されるレベルのセキュリティ更新プログラムのための検出ツールを提供するというお約束の一部として、マイクロソフトは、スタンドアロンの検出ツールを提供します。これは Microsoft Baseline Security Analyzer (MBSA) および Office 検出ツール (ODT) が MSRC のリリース サイクルで提供される更新プログラムが検出できない場合のためです。このスタンドアロン ツールは Enterprise Update Scanning Tool （EST） と呼ばれ、企業の管理者向けに設計されています。Enterprise Update Scan Tool のバージョンが、特定のセキュリティ情報向けに作成されると、お客様はそのツールをコマンド ライン インターフェース (CLI) から実行し、XML 出力ファイルの結果を表示することができます。お客様がこのツールをよりよく活用していただけるように、ツールの詳細な説明が提供される予定です。また、SMS 管理者に統合されたエクスペリエンスを提供するツールのバージョンもあります。Enterprise Update Scan Tool (EST) のバージョンを使用してこの更新プログラムが必要であるかどうかを確認することはできますか?はい。マイクロソフトは、この更新プログラムを適用する必要があるかどうかを確認する Enterprise Scan Tool を作成しました。リンクのダウンロードおよび今月リリースの EST のバージョンに関する情報は、次のマイクロソフトの Web サイトをご覧ください。SMS および EST に関する詳細情報は、「よく寄せられる質問」の「Systems Management Server (SMS) を使用して、この更新プログラムが必要であるかどうかを確認することはできますか?」をご覧ください。このツールに関する詳細は「よく寄せられる質問」をご覧ください。Systems Management Server (SMS) を使用して、この更新プログラムが必要であるかどうかを確認することはできますか?次の表にこのセキュリティ更新プログラムについての SMS の概要を記載します。ソフトウェアSMS 2.0SMS 2003.NET Framework 2.0可 (EST を使用)可SMS は MBSA 使用して検出します。このため、SMS は MBSA が検出しないプログラムに関し、このセキュリティ情報に記載されているものと同じ制限があります。SMS 2.0 に関して、Security Update Inventory Tool が含まれている SMS SUS Feature Pack は、セキュリティ更新プログラムを検出するために SMS により使用されます。SMS SUIT は検出のために MBSA 1.2.1 エンジンを使用します。Security Update Inventory Tool に関する詳細は、次のマイクロソフトの Web サイトをご覧ください。Security Update Inventory Tool の制限に関する詳細情報は、サポート技術情報 306460 をご覧ください。また SMS SUS Feature Pack も Microsoft Office アプリケーションに必要な更新プログラムを検出するための Microsoft Office Inventory Tool が含まれています。SMS 2003 に関して、SMS 2003 Inventory Tool for Microsoft Updates は、Microsoft Update により提供されるセキュリティ更新プログラムおよび Windows Server Update Services よりサポートされるセキュリティ更新プログラムを検出するために、SMS により使用されます。SMS 2003 Inventory Tool for Microsoft Updates に関する詳細は、次の Web サイトをご覧ください。また SMS 2003 も Microsoft Office Inventory Tool を使用して Microsoft Office アプリケーションに必要な更新プログラムを検出することができます。SMS に関する詳細情報は、次の SMS の Web サイトをご覧ください。Top of section脆弱性の詳細 .NET 2.0 アプリケーション フォルダの情報漏えいの脆弱性 - CVE-2006-1300:この脆弱性により、攻撃者は ASP.NET のセキュリティ設定を無視し、アプリケーション フォルダ内のオブジェクトの名前を明示的に指定して許可されないアクセス権を取得し、この脆弱性を悪用する可能性があります。この脆弱性により、攻撃者は直接コードを実行したり、ユーザーの権限を昇格させたりできませんが、攻撃者はこの脆弱性を悪用し、攻撃に使用する情報を作成し、影響を受けるコンピュータを侵害しようとする可能性があります。「.NET 2.0 アプリケーション フォルダの情報漏えいの脆弱性」の問題を緩和する要素 - CVE-2006-1300:•アプリケーション フォルダのディレクトリでは、ディレクトリの参照は既定で有効にされていません。攻撃者がファイル名を推測または入手することにより、読み出しまたは表示が試行される可能性があります。•既定で、Visual Studio および ASP.NET Web プロジェクトにより使用されているファイルの拡張子は、aspnet_isapi.dll System.Web.HttpForbiddenHandler にマップされているので、これらの拡張子を持つファイルは脆弱性が悪用され、リモートで読み出し/表示ができない可能性があります。以下は、保護されているファイルの拡張子の完全な一覧です (影響を受けません)。*.asax, *.ascx, *.master, *.skin, *.browser, *.sitemap, *.config (*.exe.config または *.dll.config を除く), *.cs, *.csproj, *.vb, *.vbproj, *.webinfo, *.licx, *.resx, *.resources, *.mdb, *.vjsproj, *.java, *.dd, *.jsl, *.ldb, *.ad, *.ldd, *.sd, *.cd, *.adprototype, *.lddprototype, *.sdm, *.sdmDocument, *.mdf, *.ldf, *.exclude, *.refresh•IIS 6.0 は IIS 6.0 に定義されている MIME マッピングを持たないファイル形式はどれも送信しません。IIS 6.0 はメタベースで許可された MIME マッピングのみを保存します。例えば、.data のファイル拡張子を持つカスタム ファイルの形式が IIS 6 サーバーの「App_Data」フォルダにあり、そのサーバーの IIS または Windows レジストリに定義されている .data ファイルに関連した MIME がない場合、インターネット インフォメーション サービス (IIS) はこの形式のファイルを実行せず、(ファイルがどのフォルダ/ディレクトリにあるかには関わらず) 404 エラー を返します。•URL スキャンを使用しており、ASP.NET の Web アプリケーションを強化するためにサポート技術情報 サポート技術情報 313190 のガイダンスに従っていらっしゃるお客様は、この脆弱性により危険にさられる可能性が低くなります。Top of section「.NET 2.0 アプリケーション フォルダの情報漏えいの脆弱性」の回避策 - CVE-2006-1300:マイクロソフトは次の回避策のテストを行いました。これらの回避策は根本的な脆弱性を修正しませんが、既知の攻撃方法を阻止する手助けとなります。回避策が機能の低下の原因となる場合、下記に示します。•すべての ASP.NET 2.0 のアプリケーションフォルダから「ファイルの読み取り権限」を削除するWeb のコンテンツから「ファイルの読み取り権限」を削除することにより、影響を受けるコンピュータをこの脆弱性の悪用から保護する手助けとなります。Microsoft 管理コンソール (MMC) を使用して IIS5.0 を実行している Windows 2000 の Web コンテンツに対する権限を設定します。1.[スタート] をクリックして [ファイル名を指定して実行] をクリックしてから、%systemroot%\system32\inetsrv\iis.msc と入力します。2.左のウィンドウで「インターネット インフォメーション サービス」の MMC スナップインをロードした際、そのサーバーでホストされている Web サイトの一覧を展開するために、コンピュータ名の横の正符号 (+) をクリックしてください。3.その横にある、正符号 (+) をクリックして、最初の Web サイトを展開してください。4.それぞれの ASP.NET 2.0 のアプリケーション フォルダについて、フォルダを右クリックし [プロパティ] を選択してください。ASP.NET 2.0 の「アプリケーション フォルダ」の完全な一覧は、以下の URL をご覧ください。ASP.NET Web サイトのレイアウト5.[ディレクトリ] または [仮想ディレクトリ] のタブで、[読み取り] チェックボックスのチェックをはずし、[OK] ボタンをクリックします。6.サーバーでホストされているそれぞれの Web サイトおよびアプリケーションに関してステップ 3 を繰り返します。Microsoft 管理コンソール (MMC) を使用して IIS 6.0 を実行している Windows 2003 の Web コンテンツに対する権限を設定します。1.[スタート] をクリックして [ファイル名を指定して実行] をクリックしてから、 %systemroot%\system32\inetsrv\iis.msc と入力します。2.「インターネット インフォメーション サービス」の MMC スナップインがロードを完了したら、左のウィンドウでコンピュータ名の横にある正符号 (+) をクリックします。3.サーバーでホストされている Web サイトの一覧を展開するために、[Web サイト] フォルダの横の正符号 (+) をクリックします。4.その横にある、正符号 (+) をクリックして、最初の Web サイトを展開してください。5.それぞれの ASP.NET 2.0 のアプリケーション フォルダについて、フォルダを右クリックし [プロパティ] を選択してください。ASP.NET 2.0 の「アプリケーション フォルダ」の完全な一覧は、以下の URL をご覧ください。ASP.NET Web サイトのレイアウト6.[ディレクトリ] または [仮想ディレクトリ] のタブで、[読み取り] チェックボックスのチェックをはずし、[OK] ボタンをクリックします。7.サーバーでホストされているそれぞれの Web サイトおよびアプリケーションに関してステップ 4 を繰り返します。回避策の影響: 仮想ディレクトリ上の読み取りアクセスの拒否はリフレクションをブロックするので、リモート デバッグが妨げられます。•ファイルの拡張子の保護を要求する URL を無効にするための設定をしている [DenyUrlSequences] を持つ URLScan を使用する1.URLScan が既にインストールされている場合、次のステップに行く前に URLScan.ini のバックアップ コピーをとっておきます。2.以下の構成で、URLScan.ini (既定で %windir%\system32\inetsrv\urlscan フォルダにあります) の設定をします。3.[Options] のセクションで、「NormalizeUrlBeforeScan」が 1 に設定されていることを確認してください。4.[Options] のセクションで、「VerifyNormalization」が 1 に設定されていることを確認してください。5.[DenyUrlSequences] のセクションで、バックスラッシュ '\' が一覧にあることを確認します。6.IIS を再起動して、変更を反映させます。注: IIS Lockdown Wizard によりインストールされた URLScan のバージョンおよび、すべての URLScan 2.5 のためのスタンドアロン イントールでは、既定で上の設定が有効にされています。注: ASP.NET アプリケーションを実行するために URLScan を設定する詳細情報に関しては、以下をご覧ください。サポート技術情報 815155回避策の影響: 誤った URLScan の設定により、Web アプリケーションが正確に機能しない場合があります。• App_* フォルダでは、ASP.NET にマップされておらず、IIS が使用可能な MIME 形式のマッピングを持たないファイル拡張子のファイルを使用する静的ファイルの拡張子が MIME 形式のマッピングを持たない場合、インターネット インフォメーション サービス (IIS) 6 はそれを実行しません。回避策の影響: なしTop of section「.NET 2.0 アプリケーション フォルダの情報漏えいの脆弱性」のよく寄せられる質問 - CVE-2006-1300:どのようなことが起こる可能性がありますか?この脆弱性により、攻撃者は ASP.NET のセキュリティ設定を無視し、アプリケーション フォルダ内のオブジェクトの名前を明示的に指定して許可されないアクセス権を取得し、この脆弱性を悪用する可能性があります。この脆弱性により、攻撃者は直接コードを実行したり、ユーザーの権限を昇格させたりできませんが、攻撃者はこの脆弱性を悪用し、攻撃に使用する情報を作成し、影響を受けるコンピュータを侵害しようとする可能性があります。何が原因で起こりますか?ASP .NET 2.0 が URL パスを正しく検証しないために、この問題が発生します。ASP.NET とは何ですか?ASP.NET (英語情報） は .NET Framework (英語情報） の中の技術の集合体で、これにより、開発者は Web アプリケーションおよび XML Web サービスを構築することができます。ASP.NET では、静的な HTML およびスクリプトの組み合わせを使用する従来の Web ページとは異なり、コンパイルされたイベント主導のページが使用されます。これにより、開発者は、Visual Basic または Visual C++ などの言語で構築されたアプリケーションに関連した、それらと同じ豊富な機能を持つ Web ベースのアプリケーションを構築することができます。しかし、デスクトップ アプリケーションとは異なり、これらのコンパイルされたページでは、HTML および XML などのマークアップ言語を使用して、クライアント デスクトップまたはブラウザに送信される情報が生成されます。これにより、開発者は、多くのオペレーティング システムを実行するデバイスおよびコンピュータへのユーザー インターフェイスを使用する広範囲な機能を持つアプリケーションを構築することができます。ASP.NET は Web ベースのアプリケーション環境であるため、基本的な HTTP 機能を提供するために基本となる Web サーバーが必要となります。このため、ASP.NET は、Windows 2000 上の IIS 5.0、Windows XP 上のIIS 5.1、Windows Server 2003 上の IIS 6 の上で実行されます。この脆弱性により、攻撃者は何を行う可能性がありますか?攻撃者がこの脆弱性を悪用し、Web サイトの一部へ不正にアクセスする可能性があります。攻撃者が行う可能性がある操作は、保護されているコンテンツによって異なります。どのような人物によりこの脆弱性が悪用される可能性がありますか?この脆弱性の影響を受けるコンピュータに、特別な細工をしたリクエストを送信できる匿名ユーザーが、この脆弱性を悪用する可能性があります。Web ベースの攻撃のシナリオでは、この脆弱性の悪用を意図したアプリケーション フォルダが含まれる Web サイトにアクセスしていることが攻撃者にとっての必要条件となります。この脆弱性により、攻撃者は直接コードを実行したり、ユーザーの権限を昇格させたりできませんが、攻撃者はこの脆弱性を悪用し、攻撃に使用する情報を作成し、影響を受けるコンピュータを侵害しようとする可能性があります。主にどのようなコンピュータがこの脆弱性による危険にさらされますか?インターネットに接続しているコンピュータが、主にこの脆弱性による危険にさらされます。また、ASP.NET を使用して、機密情報を含むデータをホストする内部の Web サイトがこの脆弱性による危険にさらされる可能性があります。この脆弱性がインターネットで悪用される可能性はありますか?はい。攻撃者によりインターネットでこの脆弱性が悪用される可能性があります。この更新プログラムはどのように問題を修正しますか?この更新プログラムは ASP.NET が URL パスを検証する方法を変更することにより、この脆弱性を排除します。このセキュリティ情報の公開時に、この脆弱性は一般に知られていましたか?いいえ。マイクロソフトは信頼のおける情報元からこの脆弱性に関する情報を受けました。マイクロソフトは、このセキュリティ情報が最初に公開された際に、この脆弱性が一般に知られていたという情報は受けていませんでした。このセキュリティ情報の公開時に、マイクロソフトはこの脆弱性が悪用されたという報告を受けていましたか?いいえ。このセキュリティ情報が最初に公開された段階で、マイクロソフトはこの脆弱性が悪用され、お客様が攻撃されたということを示す情報は受けておらず、また、公開された検証用コードのいかなる実例の存在も確認しておりません。Top of sectionTop of sectionTop of sectionセキュリティ更新プログラムに関する情報影響を受けるソフトウェア影響を受けるソフトウェアに関する特定のセキュリティ更新プログラムについての情報は、該当のリンクをご覧ください。Microsoft .NET Framework バージョン 2.0必要条件このセキュリティ更新プログラムは Microsoft .NET Framework のバージョン 2.0 が必要です。Microsoft Windows Installer 3.1 がインストールされている必要があります。 Windows インストーラの最新バージョンをインストールするためには、次の Web サイトをご覧ください。
Windows Installer 3.1 Redistributable (v2)この修正を含む予定のサービスパックこの問題に対する更新プログラムは .NET Framework version 2.0 Service Pack 1 に含まれます。インストールに関する情報このセキュリティ更新プログラムは次のセットアップ スイッチをサポートします。サポートされているセキュリティ更新プログラムのインストールスイッチスイッチ説明/helpインストール メッセージの一覧を表示します。セットアップ モード /quietQUIET モード (ユーザー入力を必要としません。表示もしません。) バックグラウンド モードと同じです。しかし、ステータスあるいは、エラー メッセージは表示されません。再起動オプション /norestartインストールの完了後、再起動しません。/forcerestartインストール後、再起動します。/warnrestart[:<秒数>]必要な場合に自動的に警告を表示し再起動します (既定のタイムアウト時間は 30 秒)。/quiet または /passive スイッチのいずれかと共に使用します。/promptrestart再起動が必要なときに確認メッセージを表示します。特別なオプション /overwriteoem確認メッセージを表示せずに OEM ファイルを上書きします。/nobackupアンインストールに必要なファイルのバックアップを作成しません。/forceappscloseシャットダウン時に他のプログラムを強制終了します。/log:<完全なパス>ログ ファイルを <完全なパス> に作成します。/integrate:<完全なパス>このソフトウェア更新を <完全なパス> に統合します。これらのファイルはスイッチの指定されたパスにあります。/extract:<完全なパス>セットアップを実行せずにファイルを抽出します。/ERエラー レポートの延長を有効にします。/verbose詳細ログを有効にします。 インストール中、%Windir%\CabBuild.log を作成します。このログはコピーされるファイルを詳述します。 このスイッチを使用すると、インストールがさらに遅くなる場合があります。注: これらのスイッチを 1 つのコマンドに組み込むことができます。旧バージョンとの互換性のため、このセキュリティ更新プログラムは、セットアップ プログラムの以前のバージョンによって使用されるセットアップ スイッチもサポートしています。サポートされるインストール スイッチに関する詳細は、サポート技術情報 262841 をご覧ください。Update.exe インストーラに関する詳細情報は、次のマイクロソフト TechNet Web サイトをご覧ください。適用に関する情報ユーザーの操作なしでセキュリティ更新プログラムをインストールするためには、コマンド プロンプトで次のコマンドを使用してください。NDP20-KB917283-x86 /quietNDP20-KB917283-x64 /quietNDP20-KB917283-ia64 /quiet注: /quiet スイッチを使用すると、すべてのメッセージが表示されなくなります。 これは、エラー メッセージを表示しなくなることも含みます。 管理者は /quiet スイッチを使用する場合、インストールが正常に完了したことを確認するためのサポートされている方法の 1 つを使用してください。 また、管理者はこのスイッチを使用する場合、エラー メッセージについて KB917283.log ファイルを確認してください。コンピュータを強制的に再起動せずにセキュリティ更新プログラムをインストールするためには、コマンド プロンプトで次のコマンドを使用してください。NDP20-KB917283-x86 /norestartNDP20-KB917283-x64 /norestartNDP20-KB917283-ia64 /norestartSoftware Update Services でこのセキュリティ更新プログラムを適用する方法に関する情報は、次のマイクロソフトの Web サイトをご覧ください。Microsoft Software Update Services (SUS)再起動の必要性このセキュリティ更新プログラムは再起動を必要としません。インストーラによって、必要なサービスが停止され、更新プログラムが適用され、サービスが再起動します。しかし、何らかの理由により、必要なサービスが停止されない場合、または必要なファイルが使用中の場合、この更新プログラムを適用すると、再起動が要求されます。この動作が起きた場合、再起動するメッセージが表示されます。再起動が必要になる可能性を低減する手助けとするために、このセキュリティ更新プログラムをインストールする前に、すべての影響を受けるサービスを停止し、影響を受けるファイルを使用している可能性のあるすべてのアプリケーションを閉じてください。再起動が必要となる理由に関する詳細情報は、サポート技術情報 887012 をご覧ください。削除に関する情報この更新プログラムを削除するためには、[コントロール パネル] の [プログラムの追加と削除] を使用してください。ファイルに関する情報この更新プログラムの日本語版のファイル属性 (またはそれ以降) は次のとおりです。Microsoft .NET Framework バージョン 2.0:ファイル名バージョン日付時間サイズAspnet_filter.dll2.0.50727.1012006/04/1406:0810,752Windows Server, 2003 Enterprise Edition for Itanium-based Systems、Windows Server 2003, Datacenter Edition for Itanium-based Systems、Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems および Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems 用の Microsoft .NET Framework バージョン 2.0:ファイル名バージョン日付時間サイズAspnet_filter.dll2.0.50727.1012006/04/1404:0334,304Windows Server 2003, Standard x64 Edition、Windows Server 2003, Enterprise x64 Edition、Windows Server 2003, Datacenter x64 Edition、Windows Server 2003 R2, Standard x64 Edition、Windows Server 2003 R2, Enterprise x64 Edition および Windows Server 2003 R2, Datacenter x64 Edition 用の Microsoft .NET Framework バージョン 2.0:ファイル名バージョン日付時間サイズAspnet_filter.dll2.0.50727.1012006/04/1406:0810,752更新プログラムが適用されたかどうかを確認する方法•ファイルバージョンの確認注: Microsoft Windows にはいくつかのバージョンがあるため、次のステップは使用中のコンピュータにより異なる場合があります。その場合、製品の説明書をご覧ください。1.[スタート] をクリックし、次に [検索] をクリックします。 2.[検索結果] のウィンドウの [検索コンパニオン] の下の [ファイルとフォルダすべて] をクリックします。 3.[ファイル名のすべてまたは一部] のボックスで、適切なファイル情報の表からファイル名を入力し、次に [検索] をクリックします。 4.ファイルの一覧で、適切なファイル情報の表からファイル名を右クリックし、次に [プロパティ] をクリックします。 注: インストールされているオペレーティングシステムまたはプログラムのバージョンにより、ファイル情報の表に記載されているファイルで、インストールされないものがある場合もあります。5.[バージョン情報] タブで、適切なファイル情報の表に記載されているバージョンと比較し、コンピュータにインストールされているファイルのバージョンを確認します。 注: ファイルのバージョン以外の属性はインストール中に変更される場合があります。そのほかのファイルの属性をファイル情報の表の情報と比較することは、更新プログラムが正しくインストールされたことを確認する方法としてサポートされていません。また、ファイル名がインストール中に変更される場合があります。ファイルまたはバージョンの情報が存在しない場合、その他の方法によって更新プログラムが正しくインストールされたことを確認してください。Top of sectionTop of section謝辞この問題を連絡し、顧客の保護に協力して下さった下記の方に対し、マイクロソフトは深い謝意を表します。•.NET 2.0 のアプリケーション フォルダの情報漏えいの脆弱性 - CVE-2006-1300 に関して報告して下さった PRISMA Informatik 社の Urs Eichmann 氏他のセキュリティ更新プログラムの入手先 :他のセキュリティ問題を解決する更新プログラムは以下のサイトから入手できます。•セキュリティ更新プログラムはマイクロソフト ダウンロード センターからダウンロードすることができます。「security_patch」 のキーワード探索によって容易に見つけることができます。•コンシューマ プラットフォーム用の更新プログラムは、Microsoft Update Web サイトからダウンロードできます。•本セキュリティ情報及び公開された更新プログラムは、TechNet CD サブスクリプションでも入手可能です。他のセキュリティ情報 :•Microsoft TechNet Security センター では、製品に関するセキュリティ情報を提供しています。•Software Update Services：http://www.microsoft.com/japan/windowsserversystem/sus/susoverview.mspx•Microsoft Baseline Security Analyzer (MBSA) : http://www.microsoft.com/japan/technet/security/tools/mbsahome.mspx MBSA ツールのセキュリティ更新プログラムの検出に関する制限は http://support.microsoft.com/kb/306460 をご覧ください。•Microsoft Updatehttp://update.microsoft.com/microsoftupdate•Windows Update カタログ : http://support.microsoft.com/kb/323166•Windows Update : http://windowsupdate.microsoft.com•Office のアップデート : http://office.microsoft.com/officeupdate/Software Update Services (SUS) :Microsoft Software Update Services (SUS) は、最新の重要な更新プログラムを適用し、Windows ベースのシステムを最新の状態に維持するプロセスを大幅に簡素化する目的で開発されました。SUS により、重要な更新プログラムを Windows 2000 や Windows Server 2003 ベースのサーバー、ならびに Windows 2000 Professional や Windows XP Professional を実行するデスクトップ コンピュータへ迅速かつ確実に配布することができます。Software Update Services に関するより詳細な情報は以下をご覧ください:http://www.microsoft.com/japan/windows2000/windowsupdate/sus/Windows Server Update Services (WSUS):Windows Server Update Services (WSUS) を使用することにより、管理者は Windows 2000 オペレーティング システムおよびそれ以降、Office XP およびそれ以降、Windows 2000 およびそれ以降のオペレーティングシステムに対する Exchange Server 2003 および SQL Server 2000 用の最新の重要な更新プログラムおよびセキュリティ更新プログラムを迅速に、かつ確実に適用することができます。Windows Server Update Services でこのセキュリティ更新プログラムを適用する方法に関する情報は、次のマイクロソフトの Web サイト をご覧ください。Windows Server Update Services 製品概要Systems Management Server (SMS) :Microsoft Systems Management Server (SMS) は更新プログラムを管理するための、構成可能なエンタープライズ ソリューションを提供します。SMS により、管理者はセキュリティ更新プログラムを必要とする Windows ベースのコンピュータを識別し、エンタープライズ全体で、エンド ユーザーへの中断を最小限にして、これらの更新プログラムの制御された適用を実行することができます。セキュリティ更新プログラムを適用するための SMS 2003 の使用方法に関する詳細情報は SMS 2003 セキュリティ パッチ管理 Web サイトをご覧下さい。SMS 2.0 ユーザーもまた、Software Updates Service Feature Pack を活用して、セキュリティ更新プログラムの適用を支援することができます。SMS に関する情報は SMS の Web サイトをご覧下さい。注 : SMS は Microsoft Baseline Security Analyzer および Microsoft Office 検出ツールを活用してセキュリティ情報で提供された更新プログラムの検出と適用について広範なサポートを提供します。これらのツールにより検出されないソフトウェアの更新プログラムもあります。管理者は、特定のコンピュータへの更新プログラムを対象とし、これらの場合に SMS のインベントリ機能を使用することができます。この手順に関する詳細情報は、こちらの Web サイト (英語情報) をご覧下さい。コンピュータの再起動後、管理者権限を必要とするセキュリティ更新プログラムもあります。管理者は、SMS 2.0 Administration Feature Pack の上位権利での展開ツール (SMS Administration Feature Pack (英語情報) および SMS 2.0 Administration Feature Pack でご利用可能です) は、これらの更新プログラムのインストールに使用することができます。サポート :•セキュリティ関連、およびセキュリティ更新プログラムに関するご質問や、ご不明な点などありましたら、マイクロソフト セキュリティ情報センターまでご連絡ください。マイクロソフト セキュリティ情報センター•その他、製品に関するご質問は、マイクロソフト プロダクト サポートまでご連絡ください。マイクロソフトでは、お問い合わせの内容が弊社製品の不具合が原因である場合、無償またはインシデントの未消費にてサポートをご提供いたします。マイクロソフト プロダクト サポートへの連絡方法はこちらをご覧ください。•製品のサポート期間の詳細は、マイクロソフト サポート ライフサイクル Web サイトをご参照ください。製品別情報の詳細は、同様にマイクロソフト サポート ライフサイクル Web サイトの 製品を探すからご確認ください。詳細情報 :•US マイクロソフトセキュリティ情報（MS06-033）http://www.microsoft.com/technet/security/bulletin/MS06-033.mspx•サポート技術情報 （KB） 文書番号 ：917283[MS06-033] ASP.NET の脆弱性により、情報漏えいが起こる更新履歴 :•2006/07/12: このセキュリティ情報ページを公開しました。•2006/07/20: このセキュリティ情報ページの「警告」を更新しました。•2006/07/20 : このセキュリティ情報ページが更新され、「セキュリティ更新プログラムに関する情報」の欄の「Microsoft .NET Framework バージョン 2.0」の「必要条件」および「インストール情報」に関して説明が追加されました。 •2006/11/30: このセキュリティ情報ページの「このセキュリティ更新プログラムに関するよく寄せられる質問 (FAQ)」の欄の「このセキュリティ更新プログラムのインストール時に発生する可能性がある既知の問題にはどのようなものがありますか?」を更新しました。本セキュリティ情報に含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行いません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。（Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。ページのトップへ プロファイル (個人情報) の管理 |お問い合わせ先 |TechNet の情報を無料ニュースレターで入手© 2007 Microsoft Corporation. All rights reserved. 使用条件 |商標 |プライバシー |日本での個人情報の取り扱い
|
|
