検索
連載

「人身事故での遅延」が裁判沙汰にならない理由から見えた、鉄道会社の律義さ世界を「数字」で回してみよう(34) 人身事故(2/11 ページ)

今回、私は「人身事故に対する怒りを裁判にできないのか」という疑問の下に、裁判シミュレーションを行ってみました。そこから見えてきたのは、日本の鉄道会社の“律義さ”でした。後半では、人身事故の元凶ともいえる「鉄道への飛び込み」以外の自殺について、そのコストを再検討したいと思います。

Share
Tweet
LINE
Hatena

エンジニアには、こう頼む

 エンジニアは、一種の入出力装置、ブラックボックス、もっと簡単に言えば、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.

ページトップに戻る