技術者の社会的責任

第7部の最後に、法律より広い話をします。

法律は「してはいけないこと」の下限を決めているだけです。 合法だが、やるべきでないことは無数にあります。

そして、エンジニアの仕事には 「作れる」と「作ってよい」が一致しない場面があります。

技術的に可能:  解約ボタンを3階層下に隠すことは、実装できる
技術的に可能:  ユーザーの行動を全部記録することは、実装できる
技術的に可能:  センサー1本の値だけで自動制御することは、実装できる

どれも数時間で書けます。そして、そのコードを実際に書くのはあなたです。

企画が決め、上司が承認したとしても、手を動かすのは技術者です。 だから技術者には、他の職種とは違う責任があります。

なぜエンジニアに責任があるのか

理由は単純で、問題に最初に気づけるのが技術者だからです。

企画「離脱率を下げたいので、解約フローを見直したい」
        ↓
実装する人だけが、「これは法的にまずいのでは」と気づける位置にいる

企画「センサーの値で自動補正したい」
        ↓
実装する人だけが、「センサーが1本しかない」ことを知っている

判断材料を持っているのは、あなただけです。 黙っていれば、誰も気づかないまま出ていきます。

実際に起きたこと

抽象論では伝わらないので、実例を挙げます。 どれもソフトウェアが直接の原因になったものです。

Therac-25（1985〜1987年）

放射線治療装置のソフトウェアに競合状態のバグがあり、 通常の100倍以上の放射線が患者に照射される事故が複数発生しました。 少なくとも3人が死亡しています。

背景として、

• 旧機種にあったハードウェアの安全機構が、ソフトウェアに置き換えられていた
• エラーコードが表示されたが、意味が分からず操作者が続行できてしまった
• 「以前から動いているコードだから安全」と考えられていた

ソフトウェアのバグが人を殺すことを、業界が広く認識した事例です。

Boeing 737 MAX（2018〜2019年）

MCAS という自動制御システムが、1本の迎角センサーの値だけに依存していました。 そのセンサーが故障した結果、機体が意図せず機首を下げ、 2件の墜落事故で合わせて346人が亡くなりました。

技術的な論点は、この教科書で扱ってきたものばかりです。

□ 単一障害点（センサーが1本。マイクロサービスの実務・性能と負荷対策）
□ 縮退時の挙動が設計されていなかった
□ 操作する人に、そのシステムの存在が十分に知らされていなかった

Volkswagen 排ガス不正（2015年発覚）

試験環境を検知して、その時だけ排ガス制御を変えるソフトウェアが 組み込まれていました。

重要なのは、この件でエンジニアが実刑判決を受けていることです。 米国では、関与した技術者に対して禁固刑が科されました。

「上司の指示だった」は、免責になりません。

これは、この章で最も覚えておくべきことです。

Knight Capital（2012年）

デプロイの際、8台のサーバーのうち1台に新しいコードが配布されず、 古いコードが動き続けました。しかも、そのコードでは 過去に使われていたフラグが別の意味で再利用されていました。

結果、暴走した自動取引によって、45分ほどで4億ドルを超える損失が発生し、 会社は事実上消滅しました。

□ デプロイの自動化と検証（CI/CD）
□ 古いフラグの再利用（設計の基礎の技術的負債）
□ 異常時に止める仕組みが無かった（性能と負荷対策の負荷制限・停止）

地味な運用手順の不備が、会社を消すことがあります。

Cambridge Analytica（2018年）

ある SNS で、第三者アプリ経由で大量の利用者データが取得され、 政治広告のターゲティングに利用されていたことが問題になりました。

「規約上は取得できた」データが、想定外の目的に使われた事例です。 技術的な侵入ではなく、設計と権限の問題でした。

職業倫理という共通の土台

エンジニアの職能団体は、それぞれ倫理綱領を持っています。

表現は違いますが、共通している原則があります。

1. 公共の利益・安全を、雇用主や自分の利益より優先する
2. 正直であること（できないことをできると言わない）
3. 自分の能力の限界を認め、越える時は助けを求める
4. 他者の権利（プライバシー・知的財産・尊厳）を尊重する
5. 専門知識を、他人を害するために使わない

1 が最初に来ていることに注意してください。 「会社の利益」ではなく「公共の利益」が上位に置かれています。

新人にも実際に起きる場面

大事故だけの話ではありません。次のような場面は、日常的に来ます。

ダークパターン

利用者を、本人が望まない選択に誘導する UI の総称です。

□ 解約ボタンを見つけにくくする / 手順を増やす
□ 「同意する」を目立たせ、「同意しない」を灰色の小さな文字にする
□ 有料プランが既定で選択されている
□ 「あと3人が見ています」という虚偽の緊急性
□ 退会しようとすると、感情に訴える表示を出す（confirmshaming）

依頼として降りてきます。 「離脱率を下げて」「同意率を上げて」という形で。

前章で見たとおり、これは倫理の問題であると同時に、 特定商取引法・景品表示法の問題でもあります。 つまり、断る根拠は「気が進まない」ではなく業務上のリスクとして説明できます。

データの取りすぎ

「後で分析に使うかもしれないから、全イベントを記録しておこう」
「デバッグしやすいので、リクエストの中身を全部ログに出そう」

必要のないデータは、リスクでしかありません（エンジニアと法律のデータ最小化）。 ログに個人情報を出さない（セキュリティ）のも、同じ理由です。

アルゴリズムの偏り

学習データや評価指標に偏りがあると、結果も偏ります。

□ 過去の採用データで学習 → 過去の偏りをそのまま再現する
□ 特定の属性でのみ精度が低い
□ 「精度95%」の残り5%が、特定の人々に集中している

全体の精度だけを見て「うまく動いている」と判断しない—— これは技術的な話であり、同時に公平性の話です。

アクセシビリティ

日本では、障害者差別解消法により、 民間事業者にも合理的配慮の提供が義務づけられています（2024年4月〜）。

HTML と CSSで扱った内容——button を使う、label を付ける、 キーボードで操作できる——は、単なる作法ではありません。

締め切りと品質

「今回はテストを飛ばして、来週書きます」
「セキュリティレビューは、リリース後にやりましょう」

これ自体が常に悪いわけではありません（設計の基礎の意図的な負債）。 問題は、リスクを説明せずに黙って飲むことです。

判断するのは意思決定者ですが、材料を出すのはあなたです。

では、どう行動するか

「おかしい」と思った時、いきなり退職や告発ではありません。 段階があります。

1. 事実と懸念を、記録が残る形で伝える

悪い: 会議で「それはちょっと……」と言って終わる
良い: 「この実装には次のリスクがあります」と書いて、チケット/Slack/PR に残す

口頭だけの懸念は、無かったことになります。 そして、あとで問題が起きた時にあなたを守るのも記録です。

書き方はドキュメントを書くのとおりです。感情ではなく事実と影響で書きます。

【事実】解約フローに、確認ダイアログを3段追加する変更です
【懸念】特定商取引法上、解約を不当に妨げていると判断されるリスクがあります
【影響】行政指導・報道リスク。また既存ユーザーの信頼低下
【提案】まず離脱理由のアンケートで原因を特定する案を検討したいです
【確認したいこと】法務にレビューを依頼してよいでしょうか

2. 代案を出す

反対だけでは物事は動きません。 「やりたいこと（離脱率を下げる）」は正当な要求であることが多いので、 目的を満たす別の手段を提案するほうが通ります。

3. エスカレーションする

チーム内で解決しなければ、上長、さらにその上、 あるいは法務・セキュリティ・コンプライアンス部門へ。

新人が1人で抱える必要はまったくありません。

4. 社内の通報制度を使う

多くの会社には内部通報窓口があります。 そして公益通報者保護法により、 通報を理由とする不利益な取扱いは禁止されています。

5. 断る

最後の手段として、その作業をしないという選択があります。

これは重い判断なので、必ず記録と相談を先に済ませてください。 そして、断るのは人ではなく作業です。

「これって、特商法の解約妨害に当たったりしませんか？
 自分が不勉強なだけかもしれないので、確認させてください」

専門家であり続ける責任

最後に、地味ですが重要なことです。

□ 自分の能力の限界を知り、越える時は必ず助けを求める
□ 「たぶん大丈夫」で本番に出さない
□ 分からないことを、分からないと言う
□ 知識を更新し続ける（セキュリティも法律も変わる）
□ 自分が理解していないコードを、理解したふりで承認しない

最後の項目は、AI を使う時代にとりわけ重要です（AI と一緒に開発する）。 理解していないものを通した時、その責任は通した人にあります。

実務の落とし穴まとめ

1. 「言われたから作った」 — 指示に従ったことは免責にならない
2. 懸念を口頭でしか伝えない — 無かったことになる。記録に残す
3. 反対だけして代案を出さない — 物事が動かず、次から相談されなくなる
4. 1人で抱える — エスカレーション先は必ずある
5. 全体の精度だけを見る — 特定の人々に不利益が集中していないか
6. アクセシビリティを「余裕があれば」にする — 合理的配慮は義務
7. とりあえずデータを集める — 持っているだけでリスク
8. リスクを説明せずに締め切りを飲む — 判断材料を出すのは技術者の仕事
9. 理解していないコードを承認する — 通した人が責任を負う

まとめ

• 「作れる」と「作ってよい」は違う。そして問題に最初に気づけるのは技術者
• 過去の重大事故は、悪意ではなく、締め切り・思い込み・沈黙から生まれている
• 職業倫理の共通原則は、公共の利益を雇用主の利益より優先すること
• 「上司の指示だった」は免責にならない（Volkswagen で技術者に実刑判決）
• ダークパターン・データの取りすぎ・偏り・アクセシビリティは、 新人にも日常的に降りてくる論点
• 行動の段階は、記録に残して伝える → 代案を出す → エスカレーション → 通報制度 → 断る
• 新人でも「これ、大丈夫ですか」と質問の形で聞ける。それで止まる案件がある
• 専門家であり続けるとは、限界を知り、分からないと言い、更新し続けること

公式ドキュメント

迷ったら一次情報に戻ってください。

章末問題

第7部はここまでです。 脆弱性・認証・暗号・設計・法律、そして何を作るべきでないかまで揃いました。

次の第8部では、作ったものを動かし続ける話に入ります。