技術者倫理

なんかのタイミングで作ったやつがあったので、せっかくなのでアップロードしておく。

Transcript

1. 技術者倫理 （ぎじゅつしゃりんり） Engineering ethics Satoshi MATSUMOTO a.k.a Dominion525(どみにをん525) 2025.06.03
2. 「技術者」とは - 技術的な専⾨性をもち、設計・実装・判断に責任を持つ職能 - 単に「知識がある⼈」ではなく、「社会に影響を与える⼒を持つ⼈」 - インフラ・システム・ツール・ルールなど、社会の仕組みを“形”にす る⽴場 →「技術者」とは、「できること」と「やるべきこと」の間を⾃分で判 断する⼈
3. 「倫理」とは 「⼈として守り⾏うべき道。善悪・正邪の判断において普遍的な規準と なるもの。道徳。モラル。」※ 出典：⼩学館「デジタル⼤辞泉」 → ⼈が社会で⾏動する際の規範や道徳的な判断基準 法律では裁けない“グレーな選択”を⾃律的に判断するための基準 - 「誰にもバレなければOK」を否定する価値観 → 他者・社会・未来に対して責任を持つ姿勢＝「正しさ」を問い続ける 姿勢
4. では「技術者倫理」とは 🔹JABEE（⽇本技術者教育認定機構）の定義: 「公共の安全、健康、福祉、環境を最優先にし、責任をもって技術を⽤ いること」 🔹専⾨家としての社会的責任 - 「技術的に可能」でも「倫理的に正しい」とは限らない - 公共の安全・健康・福祉・環境を守る判断が求められる
5. では「技術者倫理」とは 🔹 なぜ問われるのか？ - 技術の影響⼒が⼤きく、社会に対して不可逆な結果をもたらすことが ある - 判断ミスや黙認が、⼈命・⽣活・環境に直結する可能性がある 🔹 倫理 ≠ 規則 - 法やルールでは裁けない“グレー”な領域での判断が必要 - 「⾔われていないからOK」では済まない問題にどう向き合うか？
6. 近年における「技術者倫理」の扱い - 2000年代以降、⼯学系⼤学のカリキュラムで「技術者倫理」が必修化 される流れに - 特にJABEE（⽇本技術者教育認定機構）の認定を受ける教育プログラ ムでは、倫理教育が評価項⽬として明確に位置づけられている - JABEEは国際的な技術者教育ネットワーク「ワシントン協定」に も加盟しており、「倫理に関する理解と態度」は国際基準でも重 要視されている → 技術者倫理は、単なるモラルの話ではなく「職能としての判断⼒・責 任感」を⽀える教育分野として制度化されている
7. 倫理の三層構造 - 制度倫理（法令や規定を守ること） - 職能倫理（技術職としての責任と知⾒） - 個⼈倫理（⾃らの良⼼に基づく判断）
8. 技術者倫理の“前提”としての個⼈責任 個々⼈が倫理観を持つべき理由 - 専⾨性には責任が伴う - 技術者は“知っている⼈”であり、知らない⼈（上司・営業・顧客）よりもリスクに敏感であ る。 - だからこそ、「わかっていたのに黙っていた」ことがより重く問われる。 組織の判断が倫理的でないことは“ありうる” - 歴史的にも、技術者が正しかったが無視された事例は多数ある - （例：チャレンジャー、ボーイング、原発事故） だからといって「⾃分は指⽰に従っただけ」は通⽤しない - 組織の良⼼が技術者に依存している - 特にスタートアップや中⼩企業では、技術者が唯⼀の専⾨家である場合も多い そのとき“誰も⽌めない”状況を変えられるのは、技術者⾃⾝だけかもしれない
9. 🧭 技術者の倫理は、まず“個⼈”から始まる 法令やマニュアルより前に「これはやっていいのか？」と⾃分に問う⼒ - 技術者は専⾨性を持つゆえに、社会に対する説明責任を負う - たとえ組織が⽿を貸さなくても、「⾃分の判断としておかしい」は ⼤切なブレーキ 🗣 「これは誰のための判断か？」 🛑「上からの命令です」は免罪符にならない 組織がどうあれ、技術者には“専⾨家としての責任”がある - 「⾃分の⼿を通ったものに、責任を持つ」 → 技術者の良⼼は、最後の防波堤
10. 「未熟」が倫理違反になるとき 善意があればそれ⼗分か？―否 - 技術者は、「技術的にできるか」ではなく「それをやって社会がどう なるか」を考える⽴場。 - 想像しなかった。配慮しなかった。壊れるとは思わなかった。 → 結果、⼈が死んだ。冤罪が⽣まれた。⽣活が破壊された。 能⼒がないまま設計・実装・運⽤することは、責任を放棄することと同 じ。 - 技術者の価値は、“知っていることの多さ”ではなく、“知らないこと への備え⽅”で試される
11. 🤔 判断に迷ったとき、何を拠り所にするか？ 現場では、こういう場⾯がある： 「納期が近い」「誰も指摘してない」「まあ、今回はいいか」 → でも、それで“何か”が壊れるのを、私たちは知っている。 組織が倫理的であるとは限らない。 - でも、だからといって“⾃分までそうなっていい”理由にはならない。 判断の根拠を持とう。 - 「これは誰を守る設計か？」「これは本当に⼈のためになるか？」
12. 事例：ガバ設計と不正 - サンディエゴ⽔道過請求問題 2017年、⽶国サンディエゴ市で数千件におよぶ⽔道料⾦の過⼤請求が発⽣した。市⺠からの苦情 により調査が⾏われた結果、メーター読み取りの誤り、推定値の濫⽤、そしてそれを⾒逃したシ ステム設計に多くの問題があることが判明した。 💥直接原因 - メーター読取担当者（⾮技術職）が、携帯端末の⼊⼒チェック機能を意図的にバイパス し、誤った使⽤量を記録。 - 異常値に対してシステムが⾃動で「推定値」を⽣成し、正当化されたかのように処理さ れた。 ⚒ 技術者に関わる根本原因 - ⼊⼒値の検証・バリデーションが不⼗分で、誤⼊⼒や不正を許容するシステム設計。 - 不正な操作や異常値を検知するログ・監査機能が⽋如。 - 作業員の能⼒・モラルに依存した運⽤設計。 - 苦情対応も属⼈的で、データに基づいた分析ができない設計体制。 https://www.10news.com/news/inside-san-diego/inside-san-diego-audit-shows-city-sent-thousands-of-faulty-water-bills
13. 事例：ガバ設計と不正 - サンディエゴ⽔道過請求問題 2017年、⽶国サンディエゴ市で数千件におよぶ⽔道料⾦の過⼤請求が発⽣した。市⺠からの苦情 により調査が⾏われた結果、メーター読み取りの誤り、推定値の濫⽤、そしてそれを⾒逃したシ ステム設計に多くの問題があることが判明した。 💥技術者倫理上の論点 - 「想定外の誤操作」や「意識の低い作業員」は、設計で予防する責任がある。 - 「⾃分たちは悪くない。現場が勝⼿に誤操作した」は通⽤しない。 - 公共インフラに関わるソフトウェア設計では、「最悪の利⽤者」を前提にした安全設計 が必要。 🧠 教訓 - システム設計は「善意のユーザー」を前提にしてはいけない。 - ヒューマンエラーや不正を発⽣させない・検知できる仕組みが倫理的責任。 - ⼊⼒・記録・監査のいずれかが機能しなければ、結果として「社会の信頼」を損なう。
14. 事例： 不具合で⼈⽣を壊す - 英国 Horizon 冤罪事件 1999年以降、英国の郵便局で導⼊された会計ソフト「Horizon」に不具合があり、多くの郵便局員 が実際には存在しない⾦銭の「不⾜」を計上され、不正経理・横領の容疑で起訴・有罪判決を受 けた。少なくとも700⼈以上が冤罪被害に遭い、中には⾃殺者も出た。 💥直接原因 - 会計ソフト「Horizon」が、特定条件下で誤った残⾼を表⽰するバグを含んでいた。 - 郵便局本部（Post Office Ltd）は、システムに問題はないと断定し、局員を信⽤せず⼀ ⽅的に責任を追及。 ⚒技術者に関わる根本原因 - バグの存在をシステム開発者（Fujitsu UK）側は把握していたにも関わらず、黙認。 - 問題報告を受けても「ユーザの操作ミス」として処理し続けた。 - 監査ログ・再現性・エラー検出設計が不⼗分で、技術者⾃⾝が真実を証明できない状態 を招き、数多くの冤罪を⽣んだ。 https://ja.wikipedia.org/wiki/Horizon_(IT%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0)
15. 事例： 不具合で⼈⽣を壊す - 英国 Horizon 冤罪事件 1999年以降、英国の郵便局で導⼊された会計ソフト「Horizon」に不具合があり、多くの郵便局員 が実際には存在しない⾦銭の「不⾜」を計上され、不正経理・横領の容疑で起訴・有罪判決を受 けた。少なくとも700⼈以上が冤罪被害に遭い、中には⾃殺者も出た。 💥技術者倫理上の論点 - 「⾃分の作ったものを無謬だと信じた時点で、技術者は盲⽬になる」 - 異常値が出た際、「⼈間が間違った」と決めつけること⾃体が設計思想として誤ってい る。 - 公共性の⾼いシステムでは、不具合の存在を疑い、ユーザーに不利益を与えない処理優 先の姿勢が必要。 🧠 教訓 - 「不具合があるかもしれない」は常に念頭に置くべき前提。 - システムの出⼒が⼈の⼈⽣を左右する領域では、ログの完全性・可視性・説明責任が技 術者の倫理責任。 - 組織と開発者の沈黙が、700⼈以上の⼈⽣を破壊した。
16. 事例： 警告通知をオフに - ボパール化学⼯場事故 1984年12⽉3⽇未明、インド・マディヤ・プラデーシュ州ボパール市にあるユニオン・カーバイド 社の化学⼯場で、猛毒のメチルイソシアネート（MIC）ガスが⼤量漏出。公式発表で死者3,000⼈ 以上、負傷者50万⼈超（推定死者は実際には2万⼈以上とも）。史上最悪の化学災害とされる。 💥直接原因 - MICタンクに⼤量の⽔が誤って流⼊し、化学反応が暴⾛。 - 安全装置（冷却装置、スクラバー、フレア塔）は停⽌・故障・整備不良で機能せず。 - ガス検知装置も不作動。住⺠への警報も出されなかった。 ⚒ 技術者に関わる根本原因 - 警報が“誤作動が多い”ので⽇常的にOFFにされていた。 - 漏出を知らせる複数の警告・アラームが鳴っていたが黙殺された（疲労・過信・ 習慣化が背景）。 - 予防・監視・対処すべてにおいて設計・運⽤が不備。 - 安全装置は「コスト削減」の名の下に意図的に稼働停⽌。 - 従業員の教育訓練⽔準は低く、安全管理体制も崩壊状態。
17. 事例： 警告通知をオフに - ボパール化学⼯場事故 1984年12⽉3⽇未明、インド・マディヤ・プラデーシュ州ボパール市にあるユニオン・カーバイド 社の化学⼯場で、猛毒のメチルイソシアネート（MIC）ガスが⼤量漏出。公式発表で死者3,000⼈ 以上、負傷者50万⼈超（推定死者は実際には2万⼈以上とも）。史上最悪の化学災害とされる。 ⚖技術者倫理上の論点 - 「コスト削減」の圧⼒に対し、安全を優先すべき技術者が抵抗できなかった。 - 繰り返されるアラームを無視するという判断は倫理というよりも制度的崩壊を⽰唆。 - ⾼リスク物質を扱う設計・運⽤において、最悪を想定した安全対策を講じなかったこと ⾃体が倫理違反。 🧠教訓 - 「安全装置がある」ではなく「安全装置が確実に機能する」ことを保証するのが技術者 の責任。 - アラームを無視して常態化する現場は、設計思想から⾒直さなければならない。 - 技術者は、経済合理性と⼈命の間で葛藤する際、公益の側に⽴つ覚悟が必要。 https://ja.wikipedia.org/wiki/%E3%83%9C%E3%83%91%E3%83%BC%E3%83%AB%E5%8C%96%E5%AD%A6%E5%B7%A5%E5%A0%B4%E4%BA%8B%E6%95%85
18. 事例： むしろ毒？ - 茶のしずくアレルギー被害事件 健康志向商品として⼈気を博していた「茶のしずく⽯けん」の使⽤者において、⼩⻨アレルギーによる アナフィラキシーショックなどの深刻な健康被害が多数発⽣。被害者は全国で2,000⼈超（うち重篤多 数）とされ、製造販売元・販売会社・原料供給元が訴訟対象となった。 💥直接原因 - 原料に使⽤されていた「加⽔分解コムギ末（グルパール19S）」が、⽪膚を通じてアレルゲン として感作され、⼩⻨製品摂取時に重篤なアレルギー反応を引き起こした。 - 被害報告は2009年ごろからあったが、製品回収は2010年末。 - 2011年には使⽤中⽌が勧告されたが、それ以前に深刻な健康被害が多数報告されていた。 ⚒技術者に関わる根本原因 - 「経⽪感作」によるアレルギー誘発のリスクが知られていたにも関わらず、リスク評価を⾏ わずに成分を使⽤。 - 医師・学会などからの警告も無視、被害申告に対する対応が極めて遅れた。 - 原料メーカー・製造業者・販売会社の間で責任のなすりつけ合いが⾏われた。 - 最終的に開発者（元社員）も含めて⺠事・刑事訴訟が提起された。 https://ja.wikipedia.org/wiki/%E6%82%A0%E9%A6%99
19. 事例： むしろ毒？ - 茶のしずくアレルギー被害事件 健康志向商品として⼈気を博していた「茶のしずく⽯けん」の使⽤者において、⼩⻨アレルギーによる アナフィラキシーショックなどの深刻な健康被害が多数発⽣。被害者は全国で2,000⼈超（うち重篤多 数）とされ、製造販売元・販売会社・原料供給元が訴訟対象となった。 ⚖技術者倫理上の論点 - 原新規成分を⽤いた製品に対し、科学的根拠にもとづく安全性評価を怠った。 - 初期被害報告を「想定外」として切り捨て、因果関係調査を先延ばしにした。 - 公益（消費者の健康）より、販売継続・評判維持・損失回避を優先した姿勢は倫理的に極め て問題。 🧠教訓 - たとえ「⾃然由来」「⾷品原料」であっても、安全性は別問題。過信してはならない。 - 消費者の声を軽視せず、リスクに真摯に向き合う姿勢こそ技術者の責務。 - 「知らなかった」では済まない。知るべきだった・調べるべきだったが問われる。 https://ja.wikipedia.org/wiki/%E6%82%A0%E9%A6%99
20. 私たちにできること（実践的視点） 配慮がない、確認しない、壊れると想定しない＝技術者失格 善意ではなく、設計⼒・想像⼒・謙虚さの⽋如が倫理崩壊を招く → 無知・未熟は、悪意よりも多く⼈を傷つける 「これは誰を守る設計か？」「これは使う⼈にとって安全か？」 ログを残す／設計をレビューする／“危ないかも”を共有する → 倫理は、⽇々の開発判断の中にある