モバイルファーストコーディングはもはや最良の方法ではない

ウェブサイトのレスポンシブデザインでは、モバイルファーストコーディングがクールでナウい、ってのが昨今のトレンドとなっています。

モバイルファーストコーディングとは、スマートフォン向けのコードをデフォルトにして、大画面用のレイアウトやデザインはメディアクエリを使って指定する、というコーディング手法のことです。

これが推奨される理由は、

1. スマートフォンでの閲覧の方が多いのだからスマートフォン向けのコーディングを先にやるのは自然なことだ
2. コードの量を減らすことができる。例えば大画面ファーストでfloatでレイアウトした場合、スマートフォン用のコードではfloat:none;の打ち消しコードが必要になるが、モバイルファーストなら打ち消しが不要。

の2点です*1。1番目は主観的な問題ですが、2番目は合理的ですね。特に大規模なサイトの場合、改行コードすらなくしてCSSのファイルサイズを減らそうってくらいシビアですから、無駄をなくす方法として取り入れないわけにはいかないでしょう。

で、問題は主要ページが10ページやそこらの小規模なウェブサイトの制作においてもこれが有効なのか？ってことです。私の主張は「もうモバイルファーストの時代は終わってないか？」ということで、その根拠を以下に述べます。

1　モバイルファーストは非常にやりにくい

私がモバイルファーストを試した時に直面した最初の問題がこれです。他のコーダーにも「やりにくい」という感想をもらったことがあります。とくに場数を踏んでいない人の場合、うまくいきません。

理由としては、「大画面向けのHTML構造の方が複雑であるから」が挙げられます。

モバイル用のデザインは、ほとんどの場合単純な縦並びになります。当然HTMLもシンプルになります。これを大画面用にアップグレードする際に、HTMLの構造にも修正が必要になることが多々あります。

大画面ファーストで組んだ場合でも、CSSを適用したときにHTMLの構造の手直しが必要になることは良くあります。しかし、モバイルファーストだと、大画面でのCSS適用後の確認が後になるため、この手直しの量が一気に増えます。

HTMLは入れ子構造にしなければならないため、修正の際に閉じタグの欠落など、問題が発生しやすくなり、作業効率の低下が避けられません。

2　コード量を減らす効果が現在は小さくなっている

先にモバイルファーストコーディングが推奨される理由の2番目に挙げたコード量を減らす効果ですが、これが言われていたのはCSS3、flexboxレイアウトが使えるようになる前の時代の話です。当時はレイアウトはfloatを使っていたため、この主張がかなり説得力がありました。

しかし、現在はfloatプロパティは本来の役割である「テキストの回り込み」にのみ使うようになっており、レイアウトにはdisplay:flex;を使うようになっています。

そして、flexboxレイアウトはデフォルトが大画面ファーストです。要素にdisplay:flex;のみを指定した場合、子要素はデフォルトで横並びになります。これを使うと、モバイルファーストコーディングでは打ち消しコードが必要になります。

3　表は特にモバイルファーストとの相性が悪い

これはflexと同じで、もともと大画面用がデフォルトの要素なのでモバイルファーストにすると逆にコード量が増えます。（これ当初から存在していた問題なんですが、モバイルファーストを布教していた人たちはこの点どう考えていたんでしょうね？）

列の数が多い表の場合、モバイル向けではth, td にdislplay:block;などを適用して表組を崩しますよね。モバイルファーストでこれをやってしまうと、大画面用のメディアクエリでdisplay:table-cell;を再指定しなければなりません。これではコード量を減らす目的を果たせません。

4　ユーザー数は別に理由にならない

閲覧する人がモバイル端末の方が多くなったからと言って、わざわざやりにくいコーディングを推奨する理由にはなりませんよね。

大事なのは効率（コーディングの効率とデータ量の効率の両方）であって、現在はモバイルファースト一辺倒が最適解とは言えないのなら、その方針は修正した方が良いと思います。

----

以上が、「モバイルファーストコーディングはもはや最良の方法ではない」という理由になります。gridレイアウトが使えるようになったら（つまりIE利用者がいなくなったら）またモバイルファーストもありになるかもしれませんが、直感的に作りやすいのはPCファーストでのコーディングなので、なかなか戻らないのではないかなあと思います。

で、現在の私のコーディングの方法なんですが、レイアウト回りはBootstrapをベースにして作った独自のCSSフレームワーク（ライブラリ？）を使っていて、これはモバイルファーストで組んでいます。レイアウトがfloat, flex両対応なので、モバイルファーストが有効に働きます。

一方、装飾周りのコーディングでは大画面ファーストで作っています。なんでもかんでもモバイルファーストで組むのは試してすぐに捨てました。

モバイルファーストが当然、ってな雰囲気がウェブ界隈にはありますが、金科玉条にすることなく、いい感じにコーディングしていく方が良いのではないかな、と思うのであります。

*1:他にもあるなら教えて

flexの子要素に直接imgを使うとiOSで画像が歪む

というバグに直面したのでメモ。

画像を並べるためにflexプロパティを使う場合、子要素に直接img要素を使うと画像が縦に伸びることがある。

画像はpタグなどでちゃんトラップしてあげる必要がある。

なおこの現象はiOS特有のバグではないかと思う。Apple製ブラウザ（特にiOSのもの）は往年のIEのような厄介者くらいの認識でブラウザチェックしなければならないと思う。

CUD的にヤバい配色を把握する

この記事は、アクセシビリティ Advent Calendar 2019 - Adventar23日の記事です。

皆さん、CUD（カラーユニバーサルデザイン）、してますか？　一流のデザイナーならみんなやっているというCUDですが、一つの壁があります。

それが、これ。

https://www.nig.ac.jp/color/handout1.pdf　図4より。色盲の人に見分けにくい色のシミュレーション

左端がもともとの色。中央と右が緑、あるいは赤を検知する細胞が無い人の色の見え方で、判別が困難になる色の組み合わせを示しています。

CUDを身に着けるために、これらの色の組み合わせを丸暗記するのはなかなか面倒であり、忘れてしまう可能性もあります。これを体系的に理解して身に着けることはできないか？というのが今回の記事の目的です。

とりあえず色盲とか色弱について理解しよう

人間の目は、3種類の細胞を使って色を判別しています。

それぞれ、青、緑、赤の光に対して強く反応し、それぞれの反応の強さによって見ているものの色が分かる、という仕組みになっています。

緑と赤を担当している細胞はもともと同じもので、そのせいなのか、緑と赤の細胞が反応する色がほぼ重複してしまうことがあります。これが色弱です。

https://www.nig.ac.jp/color/handout1.pdf　図2より。光の波長と、それに対して色を検知する細胞がどれだけ反応するかを示した図。

Photoshopなどに搭載されている色覚シミュレーターは、緑、または赤のいずれかの細胞が無い、「色盲」のシミュレーションとなっています。

ここで一つ不思議なのは、「なぜ、赤と緑の場合のみしかシミュレーションしていないのか？　青の細胞がない人のパターンがなぜないのか？」ということです。

実は、人間の目は、青を検知する細胞は感度が低く、色の判別の大半を赤と緑の細胞で行っているとのこと。

青の細胞がない人の場合、青や紫色が暗く見えるものの、色の判別自体は3色持ちの人と大きな差がないそうです。

ちなみに色盲・色弱は「異常」ではない

ここまでしれっと「色盲」とか「色弱」と、ネガティブな印象のある言葉を使ってきましたが、これらの特性を「色覚異常」と認識するのは大きな間違いであることは覚えておかなければなりません。

3色色覚持ち（Ｃ型色覚）が多い理由について、よく言われるのが、「熟した果物を見つけやすいので有利だったのではないか」という説ですが、サルの研究により、2色持ちでも明度の差で熟しているかどうか判別できることが分かっています。（参考：「正常色覚」が本当に有利なのか）

 Ｃ型色覚は、赤と緑を別のものとして認識できる代わりに、コントラストに対してかなり鈍感になっています。赤や緑で、非Ｃ型色覚の人が全く違う色としてみている色を、Ｃ型色覚の人はほとんど判別できないといった逆転現象もあります。

非Ｃ型色覚者が障害を感じるのは、世の中のものがＣ型色覚者向けに作られているからで、左利きの人が不便を感じるのと同じメカニズムに過ぎません。左利きを「異常」という人がいたらその人の知能レベルが疑われます。同じように、2色色覚に対しても「異常」と呼ぶことはできないと言えます。

CUD対応の配色について

実際のところ、CUDには簡単な対応策があります。

使っている色に明度の違いを持たせる、あるいは破線や網掛けパターンなどの模様による差を設けるといったことで対応できます。しかしこれだと、常に色の明度差を気にしなければならず、表現の幅が狭くなります。

そこで、明度差の少ない配色で色を使いたい場合、どの組み合わせに気を付ければよいか考えましょう。

冒頭のカラーパレットをじっくり眺めると、3つのパターンがあることが分かります。

1つ目は、最上段にある青と紫の組み合わせ。水色とピンクは青と紫の明度を変えたパターンであることが分かります。

2つ目は、2段目にある淡色と灰色の組み合わせ。

3つ目は、赤、緑、茶色と、それらの明度を変えた色の組み合わせです。

色相環で確認しましょう。

色相環を色覚シミュレーターを通した画像。内側からＣ型、Ｐ型、Ｄ型の色覚特性を表す

この図は、WikipediaでCCライセンスで公開されているマンセル色相環を使い、Photoshopの色覚シミュレーターを通したものを同心円で並べたものです。これを見ると、Ｐ型、Ｄ型の色は、黄色の5Yと10Yの間あたりから、ほぼ対照的に変化していることと、青と紫の色の変化が少なくなることが分かります。

 色相環の明度を変えるとこのようになります。

色相環の明度上げたパターン

単純に明度を上げた場合がこの図で、対照的な変化は先ほどと同じですが、緑とピンクのあたりから薄い灰色に近いことが分かります。

逆に、明度を下げるとこうなります。

色相環の明度を下げたパターン

こちらも対照的な変化は同様ですが、緑と赤にこげ茶色っぽさが出てきます。

配色パターンとCUD

これで冒頭の、判別しにくい色の組み合わせパターンが、どのような位置にある色なのかが見えてきました。

補色配色では、緑と赤の配色を避けます。

トライアド配色では、緑・オレンジ、青緑・赤紫の組み合わせを避けます。

類似色配色では、青、紫の組み合わせを避けます。

そして、これらの組み合わせを使いたい場合は、明度に差をつけます。

このパターンを把握しておくと、色覚シミュレーターを起動する前に「この配色だとヤバいな」と予測できるので、デザインの手戻りを減らすことができるはずです。

また、「とりあえず色を塗るときには明度差をつける」というルールよりも表現の幅が広がります。

参考文献

ユニバーサルデザインにおける色覚バリアフリーへの提言(pdf)

カラーユニバーサルデザイン

宣伝

本記事と、前回の記事の話をひっくるめたウェブグラフィックデザインの講座を、Udemyで公開しています。2020年1月21日まで割引価格で提供しています。

光感受性発作とポケモンショック、アクセシビリティの話

アクセシビリティ Advent Calendar 2019 - Adventar 17日のエントリーです。

ウェブアクセシビリティ（JIS X 8341-3, WCAG2.0）には、「発作の防止」という項目があります。

2.3.1 3回の閃光、又は閾値以下:   ウェブページには、どの1秒間においても3回を超える閃光を放つものがない、又は閃光が一般閃光閾値及び赤色閃光閾値を下回っている。 (レベル A)  

2.3.2 3回の閃光: ウェブページには、どの1秒間においても3回を超える閃光を放つものがない。 (レベル AAA)

https://waic.jp/docs/WCAG20/Overview.html#seizure

閃光による発作について広く知られるようになった「ポケモンショック」から10年以上が経過し、知らない人や忘れてる人も増えてきたので、ここらでまとめておきたいと思います。

---

 ポケモンショックの発生

 1997年12月16日、テレビアニメ「ポケットモンスター」を見ていた子供たちがてんかんのような発作を起こし、救急搬送されるという事故が発生しました。救急車で運ばれた児童の数は全国で約700人。この数には、家族が自家用車で病院に運んだ数は含まれていません。

この事故の原因となったのが、「パカパカ」と呼ばれる演出。

これはほぼ全画面で赤、青、白を1フレーム毎に入れ替えるもの。ピカチュウの10万ボルトの攻撃を演出する際にほんの数秒間、使われました。

これが光感受性発作を引き起こし、のちに「ポケモンショック」と呼ばれるようになります。

以降、テレビ番組ではアニメ番組の冒頭では「部屋を明るくして、はなれて見てね」との注意喚起がなされるようになり、報道番組では、記者会見の映像でフラッシュに対する注意喚起がテロップで流れたり、コントラストを極端に下げるなどの措置が取られるようになりました。

さて、「光感受性発作」について、以前は「光過敏性てんかん」と呼ばれていたという記憶があります。実際にはてんかんを持っていない人でも発作が起きる、というより発作を起こした人の大半はてんかんじゃない人であることが明らかになっているため、現在は「光感受性発作」あるいは「光過敏性発作」と書かれることがほとんどです。

光感受性発作を引き起こす条件

閃光の周波数が数Hzくらいからリスクが増大し、9～50Hzくらいまでリスクの高い状態が続きます。人の視覚のフレームレートは60Hz前後なので、人の視覚でとらえられる範囲の閃光は大体危ないと言ってよいでしょう。

https://www.tv-tokyo.co.jp/kouhou/kouza.htm　より引用。

ポケモンショックの研究によって、特に危険なのが赤色の閃光であることが明らかになりました。アクセシビリティのガイドラインに「赤色閃光」の文字があるのは、このためだと思われます。

閃光の刺激に対して、光感受性発作を起こすかどうかは、てんかんの有無というよりも、その人の体質による面が大きいようです。乗り物酔いのようなメカニズムがあるのではないかとの推測もなされているようです。

模様に対するリスク

閃光に対して特に敏感な人たちの中には、縞模様や同心円等の「模様」に対しても同じような発作が発生することが知られています。

模様については、視野角 1°に対し1回～4回の繰り返しに対してリスクがあるとのこと。

なお、片手を伸ばして親指を立てた時の親指の幅が大体2°になります。

ピクセル数で言ったらどれだけなんだろうと思った人もいると思いますが（私だ）、ディスプレイの解像度、サイズ、距離によって大きく変わるので、大概の縞模様が条件によっては「危なくなる」。

何とも厄介な話ですが、デザインをする上では、画面の広い範囲を縞模様などで埋めるのは避けるとよいのかなと。あと縞のコントラストをぐっと低くするとリスクが低下します。

ちなみに、模様に対するリスクについては、JIS X 8341-3:2004には記載があるのですが、現在は記載がありません。

ガイドラインとして記載しにくいことは理解できますが、せめて「基準は定められないけど気を付けてね」くらいのことは残してくれてもよかったのではないかと思います。

うっかり加害者にならないために

ウェブアクセシビリティの項目の中でも、光感受性発作の項目は、不特定多数の人を害する可能性があるため、特別な重要性を持つと思います。

テレビの現場ではポケモンショックの教訓は受け継がれていますが、ウェブやゲームなどの制作現場では、あまり認識されていないように思えます。

明文化されているのは「閃光」ですが、明度差のあるシーンの切り替えにも同じリスクがあるので注意が必要です。

一般の人でもYoutubeやTikTokなど動画を気楽に投稿できるようになった今、「チカチカするのはやべぇぞ」という話は広めていかければならないと思っています。

参考資料

1）https://www.tv-tokyo.co.jp/kouhou/kouza.htm

2）http://www.visionsociety.jp/vision/koumokuPDF/06kaisetu/E2005.17.01.05.pdf

3）https://www.mhlw.go.jp/www1/houdou/1004/h0414-2.html

4）http://square.umin.ac.jp/jes/pdf/hikari.pdf

XAMPPでPEAR::DBのインストールができない（解決済み）

Windows10に入れたXAMPPでPHPとMySQLの勉強中なのだけど、教科書に載っているPEAR::DBのインストールでつまづきました。

教科書には「Windows版PHPにはPEARはインストールされていない」という記述がみられるのだけど、XAMPP7.2.7ではデフォルトでPEAR入っているみたいです。

Tar.phpのバグ？

で、PEAR DB入れようとしたらこういうエラーが

Fatal error: Cannnot use result of built-in function in write content in ... Tar.php on 639

ググっていたら次のサイトを見つけたのでやってみました。

You might be tempted to execute the following
pear install Archive_Tar
which will result in the same error.

[FIX] Installing PEAR packages with PHP 7.2 | DotKernel PSR-7 Middleware Applications

「あなたはpear install Archive_Tarを実行したくなるかもしれませんが、同じエラーで失敗するでしょう。」
ハイ、失敗しました。

Go to the line indicated in the error (639 in this case) and replace:
$v_att_list = & func_get_args();
with
$v_att_list = func_get_args();
The above means the func_get_args() isn’t called by reference anymore.

[FIX] Installing PEAR packages with PHP 7.2 | DotKernel PSR-7 Middleware Applications

エラーに示された639行目のコードで、=のあとの&を削除すればよいらしい。
修正を行ってから、もう一度pear DBを実行。

それは今推奨されてないよ、との警告されたあと、DBがダウンロードされました。

さらなるエラー　failed to mkdir

ダウンロードまではうまくいきましたが、インストールは失敗しています。
failed to mkdirのエラーが。

pear.iniをC:\WINDOWS\pear.iniではなくC:\php\pear.iniなどに設置するとパッケージがインストールできないことがある。

PEAR/Config.phpのpear.iniのパスを修正。

PHP
function PEAR_Config($user_file = '', $system_file = '', $ftp_file = false,
$strict = true)
{
$this->PEAR();
PEAR_Installer_Role::initializeConfig($this);
$sl = DIRECTORY_SEPARATOR;
if (empty($user_file)) {
if (OS_WINDOWS) {
// pear.iniを設定
$user_file = 'C:\php-5.4.5\pear.ini';
// $user_file = PEAR_CONFIG_SYSCONFDIR . $sl . 'pear.ini';
} else {
$user_file = getenv('HOME') . $sl . '.pearrc';
}
}
（略）
}

PEARパッケージ インストール | 私的雑録

とのことでこれを試してみたものの、ダメでした。（元に戻しました。）

さらに検索

「failed to mkdir \DB\doc」でGoogle検索。
私が直面しているものとは違うパッケージをインストールしようとした人の記事が見つかりました。

Solution:
I get into the “pear” directory and checked config values set for different pear related directories. All were set to C:\ drive by default. So, we need to change those settings to correct path.

pear config-set doc_dir E:\xampp\php\pear
pear config-set cfg_dir E:\xampp\php\pear
pear config-set data_dir E:\xampp\php\pear
pear config-set test_dir E:\xampp\php\pear
pear config-set www_dir E:\xampp\php\pear

ERROR: failed to mkdir C:phppeartestsPHP_CodeSnifferCodeSnifferCoreFile [Solved] - Subharanjan

「私は "pear"ディレクトリに入り、さまざまなpear関連ディレクトリに設定された設定値をチェックしました。
すべてデフォルトではC：\ドライブに設定されていました。 したがって、これらの設定を正しいパスに変更する必要があります。」
とのこと。
そこでコマンドプロンプトで以下のコマンドを実行しました。

pear config-set doc_dir C:\xampp\php\pear
pear config-set cfg_dir C:\xampp\php\pear
pear config-set data_dir C:\xampp\php\pear
pear config-set test_dir C:\xampp\php\pear
pear config-set www_dir C:\xampp\php\pear

それぞれの入力後、

pear install db

を実行したところ、成功。

ようやくスタートラインに立てました。

差別批判をめぐる状況とエンジニアの良心について

本記事の背景

偏見をベースとしたプレゼンテーションとそれに端を発した議論がありました。
「女性エンジニア少ない問題」を解決するために、機械学習で男性エンジニアを女性に変換する
はてなブックマーク - 「女性エンジニア少ない問題」を解決するために、機械学習で男性エンジニアを女性に変換する - ログミーTech
印象に残ったのは次のブログ記事です。
女性エンジニア少ない問題を解決する話、の何が問題なのか
「女性エンジニア」発言についての私的見解 - 科学と非科学の迷宮

本件の他にも、差別関連のいろいろな騒動・炎上はこれまで何度もありました。
それらを見ている中で、少し図で整理をしたいと思ったのでその結果を記したいと思います。
（なお、以降の議論で「主語がでかい」という批判は受け付けません。分かりやすくするためあえてやってます。）

「差別」に対する一般的な認識

人は皆異なるもので、特定の属性のみでその人の評価を行えるものではありませんが、一方で、遺伝的あるいは文化的、社会的な影響により、一定の集団の属性（カテゴリー）にある程度の傾向が存在することも事実です。またその傾向は既に存在する差別によって作られたものである場合も多いことも気を付ける必要があります。
一方で、既に存在するこの環境により、偏見を持つことを避けることは困難です。

偏見に基づいてその集団に対して悪い印象を持っている場合はその集団に対する蔑視、逆の場合は羨望と言う形で表出することがあります。その蔑視に基づいて不当に低い評価をしたら、それは差別である。これは多くの人が共有できる「差別観」と言えると思います。

多くの人が、偏見に基づく蔑視の言動に対して「差別」として容認しないでしょう。
一方、その背景にある偏見に対しては、（愚かな見解とみなすことはあっても）悪意はないものとして容認しているのではないかと思います。
そこに「悪意」という「人間の意志が介在しているかどうか」がポイントであり、これが愚かな偏見と邪悪な差別を分かつ境界線であると思います。

偏見に基づく行為・羨望も悪なのか？

ところが、「偏見に基づいて褒めるのも差別」という論があります。褒める行為も悪なのか、と戸惑ってしまいます。これはどう考えたらよいのでしょうか。
この点について参考になる記事を挙げます。
褒める差別！？: 有為転変堂
人を属性で褒めるのは褒めてることにならねーよ、と言う話ですね。

偏見に基づく高評価はその偏見に合致しない人にとって不利益となります。偏見に基づく期待から外れた場合、不当に低く評価される恐れがあります。
逆に偏見に合致した場合でも、その属性だからその結果は当然であると思われたのなら、それは本人の努力や才能を不当に低く評価していることになります。

また、偏見に基づく羨望と蔑視は表裏一体とも言えます。おそらく一瞬で反転することもあるでしょう。
褒めてることにならないということも含め、偏見に基づいた評価は良かろうが悪かろうが容認されるべきではない、と言えます。

偏見は差別なのか

ここまでの議論では、偏見を持つことは避けられないし、そこに悪意はないから、と言う理由で容認してきました。
しかし、差別が「偏見」＋「悪意」のタッグで発生するのであれば、その片棒を担いでいる偏見を容認しない、というアプローチは差別防止に有効と言えるでしょう。
悪意とは人の心であり、他人の心のコントロールが不可能であることを考えると、このアプローチしか取れないという面もあります。

そもそも、人を偏見に基づきステレオタイプの認識の枠に押し込めることは、その人の自由を制約する、あるいは自由であろうとする際、余計な努力を強いることになります。
偏見を持つことは、意識しないままその人の自由を侵害することである、と言うこともできるでしょう。意識していないだけに認めたくはありませんが。

また、好意だろうが悪意だろうが、偏見に基づいた評価はよくない、と言うのであれば、差別の本質的な悪は、実は人の意思に関係なく偏見そのものに存在するのではないか、と考えられます。

では、避けられない「偏見を持つ」という行為をどう処理すればよいのでしょうか。

偏見を公の場に出さないという選択肢があります。
特定の集団における一定の傾向は、それまでの差別によって作られたものであることも多いと先に述べました。しかしこれは不正確です。実際には偏見によって作られていることが多いというべきでしょう。

傾向と偏見に再生産の関係があるのなら、偏見の流布を止めることによって偏向の再生産を止めることができます。その傾向が偏見によって作られたものならば、将来的に特定の傾向は消滅し、そこから偏見が発生することもなくなります。
その結果、差別は根本的な解消されるでしょう。

偏見を差別と非難すべきか

冒頭のプレゼンテーションの事例では偏見を土台としたボケに対して差別的であるとの非難がなされました。
偏見を露呈した人に対して「差別」との批判がなされることはこれまでもよくあったように思います。

一般的に「差別は悪意とともにある」という認識がされている中、「差別だ！」という言葉は、「お前は悪人だ！」と同等の意味を持ちます。
そのため、悪意を伴わない偏見に対して「差別」との批判に対しては「そんなつもりはない！言いがかりだ！」との戸惑いや反駁はごく当然の反応です。

偏見を露出してしまった本人は、それに気づいていない、すなわち愚かであっただけです。
愚かな行為に対して「悪人！」と罵ることは不適切と言うべきでしょう。阿呆を捕まえて悪人と罵るのは、罵っている方が阿呆というものです。

一方、自身の中にある偏見を臆面もなく、あるいは無邪気に表現するのは、少なくとも公の場においては行うべきではないでしょう。
偏見とは差別の土台であり、偏見がはびこる社会では差別が発生しやすくなるからです。悪意がない分、何度も繰り返されるたちの悪さがあります。
自身の中にある偏見を露出することは社会における差別を醸成する間違った行為であり、黒歴史にすべき恥とするべきです。

冒頭のプレゼンテーションの事例では、記事がそのまま公開された状態が続いています。偏見の流布を止めるという観点からは、偏見を露出しているところを削除して記事を書き直すのが適切ではないかと思います。*1

エンジニアとして偏見に対する感度を上げる必要性について

冒頭に挙げた記事の中に「AIによる差別」のリスクについて言及しているものがあります。これはかなり重要な事柄だと私は考えます。
「女性エンジニア」発言についての私的見解 - 科学と非科学の迷宮
エンジニアは、世の中に害を及ぼすものを作るべきではありません。技術系の国家資格では関連法令の知識が問われますし、技術士などは高い倫理観を持つことを要求されます。
科学技術は科学の守備範囲を超えて一般の人たちの価値判断に影響を及ぼします。水伝のようなニセ科学を道徳に応用するような“前科”があるのが私たちの社会です。他にも、「野生の動物は自分の食べる分しか殺さないのに人間ときたら…」なんて話もありますよね。ライオンやクマは繁殖のために前の雄の子を惨殺したりするんだけど野生の動物を本当に参考にしていいんですかと。

そして膨大な差別だの偏見だのが存在する中でのAIだのビッグデータだの機械学習だの、と言う状況です。

無警戒に機械にデータを食わせて、出力されるのが統計的差別のように「合理的()」なものだった場合にどうなるか。
人の悪意と言う分かりやすいチェックポイントがない分、差別と判断されにくくなります。
機械を噛ませた段階で差別の状況は隠ぺいされ、出力される結果は偏見を強化し、差別による人権侵害が正当化される状況があっという間に完成するでしょう。ツールが強力なだけに、一度世に出てしまうと修正を拒絶される恐れもあります。
これを阻止できる立場と能力を持っているのが私たちエンジニアです。作る段階で現存する差別状況の影響を排除する責任があります。*2

エンジニアはデータを機械に食わせる前に偏見によるデータの偏りを目ざとく見つけ出し、注意深く取り除く必要があります。

それを実行するためには自分の中と身の回りにある偏見に対する嗅覚を鋭くしなければなりません。面倒と思われるかもしれませんが、これは技術屋の誇りを持って取り組むべき課題です。私たちは誰かを不幸にするためにエンジニアになったわけではないのですから。

*1:技術的にはおもろいんやから普通にくそまじめな技術的な記事にしてしまえばええねん。下手くそなボケが削除されたからと言って記事の技術的価値は損なわれんやろと。

*2:それは玩具を作る際に子供が怪我をしないように角を丸めるような配慮と同じと言えるでしょう。

ユーザーエージェント

PHPで取得したやつをメモ

$ua = strtolower($_SERVER['HTTP_USER_AGENT']);

Chorome

mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/66.0.3359.139 safari/537.36

IE11

mozilla/5.0 (windows nt 10.0; wow64; trident/7.0; touch; rv:11.0) like gecko

IE10（IE11のエミュレータ）

mozilla/5.0 (compatible; msie 10.0; windows nt 6.2; trident/6.0)

IE9（IE11のエミュレータ）

mozilla/5.0 (compatible; msie 9.0; windows nt 6.1; trident/5.0)

IE8（IE11のエミュレータ）

mozilla/4.0 (compatible; msie 8.0; windows nt 6.1; trident/4.0)