はじめに

先日、ふと技術者倫理の話が気になったので、先輩のエンジニアにおすすめされた本を読んでみました。

技術者倫理とリスクマネジメント―事故はどうして防げなかったのか? | 中村 昌允 |本 | 通販 | Amazon
https://www.amazon.co.jp/dp/4274068722/
（紙でもKindleでもKoboでも買えます。）

「（サービス開発をする）エンジニア」や「開発者」が「技術者」に含まれるのかは微妙な問題もあると思いますが、参考にできそうな部分が多々ありました。読書記録を兼ねつつ、自分自身が今後気をつけていきたい内容を記事にしていきたいと思います。

なお、この記事中では、「開発者」はアプリケーションやサービスを開発する人（Qiitaを使うような人）を指します。「技術者」は辞書通り、「専門の科学技術を身につけ、それを応用することを職業とする人。技術家。」（明鏡国語辞典第二版）に該当するような人のことを言います。

「エンジニア」はややこしいので「開発者」と呼ぶことにします。（開発者≒エンジニアで読み替えていただいても大丈夫です。）

本文の要約

すごく大まかに要約すると、「やらかさないためには『リスク感性』が必要だ、そのためには色々なケースをみて『仮想体験』を積むことが必要だ。」という発想で、ケーススタディを積み重ねつつ、含意を分析していく内容です。ニュースで見たこと聞いたことのあるような事例が数多く紹介されており、純粋に読み物としても興味深い内容でした。以下、この記事でポイントになる点を三つ紹介します。

技術者の使命

はじめに、技術者の使命は、①新たな技術や製品を生み出すことで人々の役に立つこと（社会に寄与すること）、②技術によって危害が加わることのないようにすること、の二点であると紹介されています。「安全に関する部分で専門性が発揮できなければ、技術者の存在意義はない」というような指摘もありました。

ケーススタディ

以下のような例が紹介されていました。

• スペースシャトル・チャレンジャー号の事故では現場の技術者がどのような行動を取れたのか、経営陣にどのような働きかけができたのか
• 原子力発電所のリスクを地域や国民に対してどのように説明してきたのか、することができたのか、BSE問題で人々はリスクに対してどのような考えを持っていたのか、それにどう対処したのか
• 雪印乳業やJCOの事故において、規定の作業手順や標準に従わなかったことで、どんな問題が起きたのか
• カビ取り剤の事故やシュレッダーの巻き込み事故、こんにゃくゼリー、自動回転ドアの死亡事故などから、製品を出荷・設置する際に何に留意すべきか、どこまで責任があると言えるのか
• 三菱のリコール問題から、サラリーマンでもある技術者がどのような行動をとるべきといえたのか
• ...

これらの事例から引き出される教訓は、開発者にも参考にできるところがあると思います。

技術者倫理とは

最後の章で、「技術者倫理」は、「技術者が業務を行う際に、社会からの期待に応える仕事をし、社会からの批判や制裁を受けることのないようにするため、技術者がもっているべき行動規範」であると説明されています。その行動規範は次の五点です。

• 技術に忠実に判断すること
• 科学技術の限界を知ること
• 結果について洞察すること
• 科学技術者である以前に市民であること
• 原則に忠実に判断すること

開発者がこの本を参考にする必要はあるのか

「技術者」でイメージするものと、「開発者」でイメージするものには多少の違いがあると思います。それでもなぜ、開発者がこの本の内容を参考にすべきと言えるのか、少し考えてみようと思います。

技術者・開発者が向き合っているもの

高度な分業が進む社会の中では、それぞれの個人や職業集団が専門性を発揮しながら、期待に応え、責任を持つ必要があります。その意味では、この記事の内容は、技術者以外のあらゆる集団についても重要な内容だと言えると思います。

しかし、技術者の立場には大きな特徴があります。それは、技術や製品に対する仕事が、誰かに対して直接、時には大規模(and/or)深刻な、危害を加える原因を作る可能性があるということです。そのため、技術者の責任は重大だと言えます。

では、開発者はどうかというと、同様のことが言えると思います。（少なくともそこそこの）専門性が求められる上に、開発したアプリケーションやサービスが問題を起こせば、精神的苦痛、個人情報・重要情報の漏洩、不正アクセス・ウイルス等の被害や、経済的損失・機会損失の発生など、深刻な問題を引き起こすことがありえます。開発者の仕事はコンピュータ内だけで行われる部分が多いですが、それが潜在的に持つ責任の大きさは、化学物質や工業製品の開発製造と比べて、小さなものではないはずです。

開発者の仕事には、「新技術の開発」と呼べるほどの派手さがない部分も正直あると思いますが、だからと言って、その責任の大きさを軽視するわけにはいきません。製品が新たな価値を生み出すだけではなく、何らかの問題を引き起こす可能性がある以上、開発者も「技術者倫理」で議論されているような内容に目を向ける必要があると思います。

開発者特有の問題

開発者の仕事も責任重大だという話をしましたが、開発者の置かれている立場としては次のような特徴もあると思います。

「バグ」の存在

開発においてバグが紛れ込むことは想定済みで、万が一問題が起きたら原因を特定して直ちに修正するということが可能なことが多いと思います。その点、製品の回収やリコールのような話題は、あまり関係がないかもしれません。

「危険なものを無理やり作らされる」なんてことはあるのか

技術者倫理の問題では、技術者が危険意識を持っているのにも関わらず、経営判断や慣行などから、それが蔑ろにされてしまう場合が指摘されています。しかし、開発者がそのような形で「危険な製品を作らざるをえない」という状況に陥ることがあるのかは、疑問が残るところです。技術的負債になるとか、工数の無駄が多いとか、知財関連の問題があるといった問題で対立することのほうが多いかもしれません。

ではどうするか

開発者特有の問題を考慮すると、技術者倫理のうち、開発者の仕事に活かせる部分は一部分と言えるかもしれません。それでも、依然として参考にできる部分はあるはずです。以下では、そのうち数点を詳しくみていこうと思います。

論点と考察

特に役立つ場面がありそうなものを四点紹介します。

「説明責任」「提案」のあり方

なぜこの話を最初に持ってきたかというと、最もはっとするものがあったからです。

本書では、「安全に関する部分で技術者が専門性を発揮するべきだ」という話に加えて、「技術の有益性を示して会社（ひいては社会）の利益に繋げることも技術者の責務だ」と指摘しています。その中で、経営者をはじめとする非技術者に対する提案や、説明のコミュニケーションで何に気をつけるべきかが問題になります。

チャレンジャー号の爆発事故は、「O-リング」という部品が、設計時の想定を超える低温状態において、期待するパフォーマンスを発揮できなかったことが原因だと言われています。開発に携わっていた技術者の一人は、その可能性に気づき、主張していたのにも関わらず、結果として打ち上げは決行されてしまいました。本書は、この技術者（ボイジョリー）の行動を評価する一方で、このときの主張の方法について問題を提示しています。

O-リングの低温下でのパフォーマンスの問題については、技術者集団の中でも見解が別れていたそうです。その原因の一つとして、パフォーマンスの低下を示唆するデータが明確にそう読み取れるものではなかったことがありました。そのため、技術者間で合意に至らず、経営者に対しての説得力に欠けるものになり、打ち上げの決行という経営判断を覆すことができなかったとあります。

ここでの問題には、技術者集団の中で問題意識を共有するために、より確実なデータを集めることはできなかったのか、そのための日頃からの信頼関係はあったのか、技術者の発言力はどの程度あったのか、技術者は最善を尽くしたと言えるのか、といったものがあります。

何らかの重大な問題を発見したとき、製品のことを熟知している以上は、それについて徹底的に論議し、経営者と見解を確実に共有した上で、経営判断も含めて総合的な検討を行う必要があります。単に問題がある可能性があると声高に主張するだけでは不十分で、責務を果たしたとは言えないということです。また、そのために技術者間、技術者経営者間の信頼関係を日頃から構築しておくことが重要と言えます。

そのような重大な問題か判断がつかないとしても、経営者は現場の報告があって初めて意思決定が行えることを考えると、熟知している者の責任として、報告を怠ることはできません。
（原子力発電所高圧配管破裂事故の例ではこの点が指摘されています。）

開発においては、主にセキュリティに関するリスクの評価・共有が問題になりそうです。例えば、設計上防ぎきれない攻撃、事故の可能性や、製品や製品が依存するソフトウェアの脆弱性にどこまで対応するかなどについて、また、それに対する対策にどのような方法があり、費用はどうなのかといったことについて、どこまで認識を共有できているのか、開発者間で問題の深刻さについて論議できる雰囲気があるのか、といった点があると思います。

これは次の「リスクコミュニケーション」の問題にもつながります。

「リスクコミュニケーション」「残留リスク」

上述のように、開発者が危険な製品を無理して作らされるということはあまりないとは思いますが、外の世界まで視野を広げると、リスクの伴うものを「絶対安全」と言ったり、合理的には必要がない場面で100%の安全を担保しようと努力がなされることがあります。これらの問題の根本には、「リスク」の捉え方についての視点の共有がなされていないことがあります。

採用する手法や開発した製品が何らかのリスクを持っている場合は、それがどのようなものなのか評価した上で、それぞれの立場（技術者間・技術者経営者間など）からみて、どこまでのリスクが許容可能なのか合意点を見出していくことが必要となります。これを「リスクコミュニケーション」といいます。リスク評価の基本的な方法としては、重大さと発生頻度から無視可能・軽微・重大・破局的のどれに該当するかを分類する方法があります。

さらに、排除しきれないリスク（「残留リスク」）については情報を公開して、たとえ小さくてもリスクが存在していることを明らかにしておきます。この情報が相手にとって重要かどうかはわかりませんが、こうした姿勢は信頼関係の向上につながるため重要です。

「標準」「規約」と「逸脱の正常化」

雪印乳業の集団食中毒事故や、JCOの臨界事故では、定められていた作業標準からの逸脱が事故の主要な原因の一つでした。

「標準」「規約」「作業手順」がなぜ定められるかというと、簡潔に言うと各々が好き勝手にするのではなくその方法に従ったほうがいいからです。さらに、何か問題が起きたときの責任の所在を明確にすることもできます。これにより、「責任は組織がとり、個人は遵守する」という形をとることができ、ミスや事故の未然防止、被害の緩和や迅速な解決につなげることができます。

本書では「ヒューマンエラー」（人間が期待されたパフォーマンスを発揮できないことに起因する問題）と「ヒューマンファクター」（人間側にある要因）を区別し、次のような分析を紹介しています。

問題が起きたときの状況の分析

1. 標準を知っていたか → NOなら知識量の問題
2. 標準に従う能力があったか → NOなら技能の問題
3. 標準に従うつもりがあったか → NOなら意図的なもの

1, 2, 3のそれぞれでNOの場合は教育により改善を図ることができますが、すべてがYESの場合は「意図しないミス」となり、教育によって防止することができない部分になります。このような点については、制度・仕組みを定めることで解決する必要があります。中には、標準の策定・改訂が必要な場合も出てきます。

「逸脱の正常化」

標準（基準）が定められていても、現場の実際の作業手順や判断基準が、効率性などの事情から乖離していくことがあります。このような例外が特に問題を起こすものでなければ、標準や基準を改める必要がありますが、そうではなく、基準内と「みなす」範囲が拡大され、例外的な状況が常態化してしまうこともあります。これが「逸脱の正常化」です。
（「10km/hのスピード違反は違反じゃない」というのはまさにこれですね。）

もし現場の判断が的確なものであれば問題は生じませんが、実際にはそれが問題の原因になることもあります。作業手順の変更は「変更管理」として、適切な手順によりチェックを受けた上で行われる必要があります。定められた標準から乖離した状態は事故の原因になります。

状況によりけりだとは思いますが、開発者が向き合う現場でも、コードのデプロイや製品のリリースといった場面で規約が定められていることも少なくないと思います。この話は、それらの規約がなぜ定められているのか、そこからの逸脱が常態化しているところはないか、考え直すきっかけになると思います。

「非常識な誤使用」と「想定外の誤使用」

これについては開発の現場で性善説・性悪説としてよく議論されているものに近いかもしれません。

シュレッダーの巻き込み事故では、社会的に個人情報保護が重視される中で、事業所向けの製品が家庭で使用され、小さな子どもが手を触れてしまうことは、想定外の事態とは言えないとして、製造者側の責任が指摘されました。また、ガス給湯器の一酸化炭素中毒事故では、直接の原因が修理業者の改造にあったとしても、それが想定できたのであれば、改造を不可能にするなどの対策が必要だったと指摘されています。

これらから、たとえ正常使用といえないとしても、「想定外の誤使用」にどんなものがありうるのかをはっきりさせて、必要な対策を施すことが求められていると言えます。

開発においては、特に誤操作の防止の観点から、さまざまな工夫がなされていると思いますが、「製品」というくくりで見た場合、このような議論があることは知っておいて損はないと思います。

結論

上述したように、本書では「技術者倫理」は「期待に答え、批判や制裁を受けないための行動規範」とされています。
辞書で「倫理」の項目をみると、「人として踏み行うべき道。道徳。モラル。」とあります。ちなみに「道徳」は「社会生活の秩序を成り立たせるために、個人が守るべき規範。」とあります。（それぞれ明鏡国語辞典第二版。）

ここで倫理や道徳とはなんぞや、という話をすると収拾がつかなくなるのでやめておきますが、ここで言いたいことは次のことです。

「技術者倫理」のように「開発者倫理」というものがあるとすれば、それは「開発者集団がそれを守らなければ、人々から批判や制裁を受けるような、あるいは社会秩序に混乱が生じうるような規範」だと思います。そんな規範が本当にあるのかは分かりません。あるかもしれないし、ないかもしれない。そもそも、開発者という集団（職業）は社会に認知されているのだろうか…？そうじゃなかったら批判を受けることもないのではないか…？という疑問さえも浮かんできます。それなら、「開発者倫理」なんてものはない、と言えるのでしょうか。

この記事の結論は、「あるはずだ」ということです。開発者集団がそれを守ることによって、社会において、少なくとも会社、事業部やチームの内部において、開発者がよりよく期待に答えられるような、批判や制裁を受けなくて済むような、規範とまでは言わなくても、心がけるべきことはあるはずです。それを「倫理」と呼ぶ必要があるのかは分かりませんが、そう呼ばれ得るものだとは言えると思います。

以上のことを踏まえて、自分がどのような立場にいるのか（どのような結果を引き起こし得る立場にいるのか）自覚しておくこと、実際に問題を発見したり、無視できないリスクのある判断をしたりするときに、専門性を発揮してコミュニケーションをとっていくことが、大切なのだろうと思いました。