「人身事故での遅延」が裁判沙汰にならない理由から見えた、鉄道会社の律義さ：世界を「数字」で回してみよう（34） 人身事故（2/11 ページ）
今回、私は「人身事故に対する怒りを裁判にできないのか」という疑問の下に、裁判シミュレーションを行ってみました。そこから見えてきたのは、日本の鉄道会社の“律義さ”でした。後半では、人身事故の元凶ともいえる「鉄道への飛び込み」以外の自殺について、そのコストを再検討したいと思います。
エンジニアには、こう頼む
エンジニアは、一種の入出力装置、ブラックボックス、もっと簡単に言えば、PCとして取り扱うのが正しいのです。こんな感じで。
（1）お願いがあります。
（2）Gさんに、AさんとCさんとEさんの状況をインタビューして、現時点での状況を、私に教えてください。
（3）私が知っている事実は、以下の3つです。
（a）AさんがBをし、CさんがDをしたという話がある。
（b）これにより、EさんがFという状況になったという話がある。
（c）しかし、Gさんの話からは、上記（a）（b）と矛盾が生じている。
（4）お願いしている理由は、AさんとCさんとEさんの状況が分からないと、次の打ち合わせの内容を決められないからです。
―― と、こんな風に「依頼（目的）」を最初に持ってきて、次に「事実認定」、最後に「背景」を語るという手順で情報をインプットさせることが望ましいです。これは、典型的なテクニカルライティングの作法です。
しかし、このような作法を日常で使用することが、わが国の文化 ―― 遠まわしな表現を重視し、物事を円滑に進めることを特徴とする ―― と適合しない、ということは理解しています。
わが国は、この「婉曲（えんきょく）コミュニケーション」のメソッドで、ここ1000年くらいうまくやってきましたし、これから先の1000年間もうまくやっていくと思います。
意図的に物事をはっきり言わないことによって、対立する観念を、口論や武力行使なく纏めるというコミュニケーション手段は、世界に誇る素晴らしいメソッドだと、エンジニアである私ですら思います。
しかし、私たちエンジニアは、できるだけ多くの情報を取得して、短時間で結論を出すことを、日々期待され、訓練されています。
そして、エンジニアが業務で取り扱う対象、例えば、コンピュータ、製造装置、建築物、配電・排水などの設備、その他は、全て「命令」によって動かすものです。
コンピュータに、背景の説明や自分の気持ちを入力しても、なーんにも答えてくれません。コンピュータは、コマンドプロンプトで命令を待っているだけの、単なるアホな装置です（そして、現時点の人工知能＊）も同様です）。
＊）「Over the AI ――AIの向こう側に」連載バックナンバー一覧
ですから、原則「頭が悪い」エンジニアへの依頼方法は、「アホな」コンピュータへのコマンド入力と同じで良いのです。
私たちエンジニアは、そのように取り扱われることに「慣れている」―― のではなく、そのように取り扱われないと「動けない」ようにできているからです。
この「人身事故」シリーズは、人身事故（の中の特に「飛び込み自殺」）に関しての、調査、事実、データ、分析、シミュレーションと、それに基づく考察だけで構成されています。
結婚、出産、LGBT、そして、人身事故や自殺など、人の死を取り扱うコラムにおいては、「同意する、共感する、心に寄り添う」というコンテクストを期待している人が多いことは、当然に予想できます。
そのような人が、徹底したエンジニア視点から執筆されたこのコラムを読めば、「文章全体が『不快』で読んでいられません」と感じるのは、至極当然だろう ―― と、このひと月の検討から導き出しました。
『そういうささいなことを、わざわざ検討するところが、エンジニアって奴は……』、と言われそうですが、そういうことを言われると、また再検討を始めるのが、エンジニアって奴なのです。
いずれにしても、私たちエンジニアは極めてデリケートな社会の道具（ツール）です。あまり乱暴に取り扱わないでください。
Copyright © ITmedia, Inc. All Rights Reserved.