公正のためのエンジニアリング

『Google のソフトウェアエンジニアリング』第4章を読んで理解した内容を、自分の言葉で書き直したもの。本文の引用ではない。節番号は原典を引き直すときの手がかり。

バイアスがデフォルト状態 (§4.1)

誰でもある程度のバイアスを持っている。 これは例外的な状態ではなく初期状態。だから「自分には偏見がない」という前提から始めると必ず外す。

書籍が挙げている実例は、いずれも製品が特定の集団を取りこぼしたケース。

画像認識の件で起きていたことを分解すると、失敗の構造が見える。

結果として、間違いを見つけたのは社内ではなくユーザーだった。製品はユーザーを裏切り、会社は評判を落とした。

対処法の1つは、エンジニアリング組織自体を、製品の対象母集団に似せていくこと。

技術的才能に加えて、何かを作るべきときと作るべきでないときを見分ける識別力が要る。有害な結果をもたらす機能や製品を見分けて、拒絶できることも含む。

自分のバイアスというデフォルト状態を認識できて初めて、見落とされがちなユースケースや利用者に目が向くようになる。

一般的なやり方は、多数派のユースケースを先に作り、エッジケースへの対応を後回しにするというもの。これを退ける。最初からインクルーシブな設計で作る。

利用にあたって余分な困難を抱える人に向けて作られた製品は、結果的に全員にとって良いものになる。

公正なシステムを作るということは、既存のプロセスが不当な結果を生んでいないかを疑うこと。評価制度を例にすると、問うべきはこういうこと。

発達途上での評価は、成績の予測に使える尺度なのか
成績評価に個人的なバイアスは含まれていないか
成績評価の点数は、組織全体で標準化されているのか

実際に調べると、低い評価を受けてチームを移った人が次のチームで好成績を出す確率は、低評価を受けたことがない人と同程度だった。評価が人の能力ではなく環境を測っていた、ということになる。

失敗するのは企業の価値観・意図・投資の段階ではなく、ポリシーを実装するレベル。掲げているかどうかではなく、実際に何が起きたかを見る。

監視、偽情報、ネット上の嫌がらせといった今の問題は、過去に失敗したアプローチや今持っているスキルだけでは解けない。

バイアスと差別によって最も影響を受けるユーザーに、まず配慮する。