データサイエンスレガシーコード

Repro Tech Meetup #7 にて、「データサイエンスレガシーコードに立ち向かう」というタイトルで講演しました。

データサイエンティスト全てというわけではありませんが、データサイエンスのコードは試行錯誤の連続であり、様々な手法を連続して試すことを考えると、最初からきちんとテストを書いた保守性の高いコードを書く、というのはそう簡単ではありません。

しかし、そうした試行錯誤を経て出来上がったデータサイエンスのコードを、「動いているから」という理由でそのまま実戦投入していくケースを目にしたことある人はいるのではないでしょうか。

このような状況に直面したとき、私が思い出したのは、10年前の、あるプロジェクトのことでした。

当時の私はある社内システムの開発に携わったのですが、既存コードには一切テストがなく、かなりの分量の改修が必要で、そして期日が迫っている、という状況でした。

このとき私のバイブルとして助けになったのが、「レガシーコード改善ガイド」でした。

レガシーコード改善ガイド (Object Oriented SELECTION)

まさか10年経ってからこの本を再び開くことになるとは思いませんでした。しかし、そこに書かれている内容は、まさに今の私にとって役に立つ内容ばかりでした。

この本の冒頭には、以下の一文が記されています。

レガシーコードとは、単にテストのないコードです

この一文を読んで、私は「データサイエンスレガシーコード」という言葉を思いつきました。

データサイエンティストの考えたモデルがもし本当に有用であれば、コードはきちんと整備され、あるいは書き直されることになるでしょう。しかし、そうなる前の段階、つまり、データサイエンティストの頭の中から一歩踏み出した状態は、保守性の低い、レガシーコード同様となっていることが多いでしょう。このようなときに、この古い書籍は大変役に立ちます。

とはいえ、この本で取り上げている例やツールは現代から見ればかなり古く、また、コードもJavaやC/C++で書かれているため、私が使うPythonの世界にはそのままでは適用できません。

Pythonでテストを書くための本として、テスト駆動Pythonがあります。この本は2018年に出たばかりの新しい本であり、内容もわかりやすく、Pythonでテストを書くのに慣れていない人にとってはかなり有益な本でしょう。

テスト駆動Python

ソフトウェアエンジニアと違い、短期間のうちに様々な小さいコードを実装しなければいけないソリューリョンアーキテクト(あるいは、プリ・ポスト含む全てのフィールドエンジニア)がよく口にするのは、「テストなんて書いている時間がない」というものですが、テストを書けば、バグ探しや確認作業のための工数が減り、改修作業のときの手戻りを減らし、同僚や他プロジェクトで自分が書いたコードが再利用されるときに発生する質問や支援依頼もぐっと減り、その結果、自分の時間を大きく節約することができます。なので、私は小さなコードであってもなるべくテストは書くべきと考えています。

テストを忌避する理由として考えられるのは、推測ですが、「テストが品質向上のためのものであり、テストを書くには分岐網羅などを全て行った、カバレッジの高いものにしなければいけない」という考えがあるからでは、と思っています。私は、特にソリューションアーキテクトのような立場でコードを書く場合のテストは、単に確認作業の自動化くらいの意味合いで考えれば問題ないと考えています。普段自分が実行しているコマンドや作業を自動化するというくらいの軽い気持ちでテストを書くだけで、必要最低限のテストでの保護は可能となります。そしてそのためのテストコードは数行で書くことができます。

新しいアイデア、素晴らしい機械学習モデル、こうしたものを作ることそのものは確かに誰にもできないことであり、その業績は褒められるべきものです。しかし、せっかくのその傑作を素早く広めていくには、保守性の向上は常に考える必要があります。そのためにも、テストがないコードにテストをかぶせていく手法を学ぶのはとても有益と考えています。

テストの話とは外れますが、こうした発想がソリューションアーキテクトという仕事において有益である、という話を、4/24(水) 開催の SA Night #1 で少しだけ触れますので、興味がある人は是非ご参加ください。

健全な危機感と過剰な成功体験の危険性

先日、あるお客様を訪問しました。そのお客様はかなり先進的な企業で、社員の方達の能力も高く、企業の業績も大変良好なのですが、そのお客様はとても印象深い一言をおっしゃっていました。

「確かに我々は日本では先進的だと言われているようだが、グローバルの企業に比べれば足元にも及ばない。なんとかしないといけない」

この言葉に、私は非常に驚きました。今まで多くの優れた企業の方とお会いしてきましたが、トップ企業の方で、社員レベルでここまでの危機意識を徹底されている会社は多くありません。

もう10年ほど前になりますが、大学のある先輩がある企業に就職した後、一度会う機会があって、そのときに聞いた話を思い出しました。その先輩が勤めている企業は、日本を代表する有名な企業でしたが、デジタル化の波に飲まれて主要事業が急激に縮小するも、新しい事業を次々に創出して生存に成功した企業でした。その先輩と話をしたのは、ちょうどその業績回復で話題になっていた頃でしたが、そのときその先輩はこのような話をしていました。

「とにかく危機感がすごい。誰一人として、このままでいいとか思っていない。新しいことはすぐに始めるし、自分みたいな若手にも仕事はバンバン任せてくれる」

多くの会社では、社内外に向けて鼓舞するようなメッセージを発信します。自分たちはすごい、自分たちはできる、自分たちは偉大だ、といったようなメッセージです。当然ながら、会社というのは常に様々な危機や試練がつきまとうので、士気の向上のために、こうしたメッセージは重要と思います。

では、もし本当にうまくいってしまったら、その後はどうなるのでしょう？自分たちはすごい、ということを本当に証明してしまったら？私はここに一つの落とし穴があるのではと考えました。成功体験に基づく自尊心は、その後の失敗に対して正常に対処できなくなるのでは、と、ふと思いました。

もちろんこれも難しい話で、危機感を煽るばかりだと、「この会社本当にヤバイんじゃないか」と勘違いする人が出てきて、退職者が続出したり、いい人材を採用できなかったり、株価に影響を与えたり、と、ネガティブな効果ももちろん少なくないでしょう。しかし、健全な危機感を抱き続けるというのは、特に予定通りに計画が進まなかった場合に問題解決に柔軟になれるのではないか、と思いました。

では、どうすれば健全な危機感を抱き続けることができるのでしょう？一つは、適切な高いゴールを決めることではないかと思います。ハードルが低すぎては成功体験が過剰になってしまい、ハードルが高すぎては誰も真面目にそのゴール達成を考えなくなるでしょう。しかし、ゴール設定だけでは健全な危機感を持つというのは難しそうな気がします。そもそも、健全な危機感とはどのようなものか、まずこの定義を明確にする必要があるでしょう。いずれにせよ、まだ自分の中で答えの出ていない話です。

関連書籍

こうした、失敗から学ぶという書籍は何冊か読んだことがあります。そのうちの一冊、「名経営者が、なぜ失敗するのか？」は面白い本ではありますが、あくまで経営者視点の話で、現場の意識のような話には言及していません。

国家の失敗というテーマで有名な書籍としては、「失敗の本質」や「大国の興亡」がありますが、いずれも組織論、あるいは大組織に関連する機能についての言及が主体で、やはり現場の意識という観点ではあまり言及はされておりません。(いずれも名著なので本件とは別に読む価値はあります)

転職エージェントの活用法

この記事は pyspa Advent Calendar 2018の10日目の記事です。前日は
放送大学と調べ物と私 - rokujyouhitoma's blog
でした。

私がClouderaを退職し、Luminoso Technologies(日本法人名: ルミノソジャパン合同会社)に転職したことは既に書いた通りですが、この転職は転職エージェントのヘッドハンター経由で行ったものでした。

外資系IT企業のヘッドハンターと言えば、スパムのようにメールを送ってきたり、名前を間違えたり、職場にいきなり電話してきたりと悪評は留まるところを知りませんが、今回利用させていただいた中で活用のメリットというのが見えてきたので、私のエピソードとともに共有します。

ヘッドハンターを活用した転職エピソード

ClouderaがIPOした後、会社としては一区切りもついたことだし、現状に不満は特になかったものの、その先のことも考えなければと思い、面白そうな仕事や技術のトレンドなどをゆっくりと探していました。そんな中、あるヘッドハンターからのメールが目に止まりました。

大半のヘッドハンターが大企業の案件を紹介してくる中、そのヘッドハンターだけは見たことも聞いたこともない企業名を挙げてきました。しかも、北米のスタートアップと書いています。興味が湧いたので、会ってみることにしました。

そのスタートアップ自体は話を聞く限りあまり興味の引かれる案件ではなかったものの、そのヘッドハンターは、海外のスタートアップの案件を持っているそうなので、ものは試しにと思い、好き勝手な条件をつけて、この条件を満たした企業があったら話を持ってきてください、とお願いしました。
主な条件は以下の通りです。

• 自然言語処理に関係があること
• botに関係があること
• 立ち上げ、あるいはそれに準ずるフェーズであること
• 勤務地は東京であること

もともとpyspaの中で俳句botというものを作っていた関係もあり、自然言語処理とbotの世界にはとても興味を持っていました。しかし、自分の知る限りではこの二つを結びつけてビジネスを成功させている企業は一社もなく、とても仕事になるとは思っていませんでしたが、せっかくなので自分のやりたいことを現実性度外視でぶつけてみることにしました。上記以外にも給与等の様々な条件をつけましたが、正直そのヘッドハンターがその条件に合致した案件を持ってくることはあまり期待しておらず、当たればラッキーくらいの軽い気持ちで条件を提示していました。

それから一年後、そんな話をすっかり忘れていた私の元に、一通のメールが届きました。読むと、その会社は自然言語処理に関係があり、botに関係があり、日本での立ち上げメンバーを探している、ということでした。私が提示した条件にほぼ合致していた案件を、そのヘッドハンターは持ってきたのです。

私もこちらが出した条件を満たした案件を持ってきてもらった以上、会わないのでは義理が立たないので、とりあえず会ってみることにしました。

以上が、私が Luminoso と出会った経緯となります。

(余談になりますが、Luminosoはあくまでデータソースの一つとしてchatbotを扱えるというだけで、別にbotの会社ではありませんでした)

ヘッドハンターの活用についての教訓

今回わかったこととしては、未知の業界や未知の分野、未知の職種・職位など、自分が行ってみたいもののツテも何もない、という場合にヘッドハンターを活用することには大きな意味があるということです。ヘッドハンターなしには、私はLuminosoという会社を知ることすらなかったでしょう。
一方、もし既存の技術や職種の延長上での仕事を探したり、よく知った人物と一緒に仕事したいなど、既知の領域での転職を考えているのであれば、ヘッドハンターの活用はあまり有効ではないでしょう。そもそも、全く知らない会社に転職するというのは大きなリスクを伴うものです。私のように、よほど未知の世界に興味がない限りは特に使う必要もないと思います。
また、今すぐにでも転職したい・しなければならない場合などは、一見ヘッドハンター経由だとすぐに仕事見つかりそうな気もしますが、上記の通り全く知人のいない会社への転職はリスクがある上に、転職への焦りからつまらない仕事を選んでしまう可能性もあるため、私としてはあまりおすすめはしません。余裕のあるときに会っておくのが一番いいと思います。

ヘッドハンターの活用法

これはすごく簡単で、以下の3つを実施するだけです。

• 会って話する
• 自分の要望を好き勝手に告げておく
• 放置する

先述の通り、なるべく余裕のあるときに実施しておいた方がいいです。本当にいい案件が来たときだけ話を聞けばよく、そうでなければ普通に現職の業務を続ければいいからです。
要望については、「5000兆円ほしい」でもなんでもいいので、とにかく好き勝手言っといて問題ないです。条件に合致しなければ放置されるだけだし、デメリットは一切ありません。

おまけ: ヘッドハンターとスパムメール

「ヘッドハンターからのメールってテンプレで大量に投げたり、たまに名前間違えて投げてきたりするじゃないですか？あれほとんどの人がスパムフラグ立てて読んでもいないから、もうちょっと丁寧に投げた方がいいと思いますよ」

という話をしたらとても驚いていて、そんな風に扱われているとは知らなかったとショックを受けていました。普段からたくさんの案件を同時並行でやる傍ら大量のメールを送っていて、自分でもそうした問題に悩んでいたのですが、さすがにスパム扱いは衝撃だったようです。

今回の転職活動の中でヘッドハンターの仕事というのも知ることができたし、何より担当したヘッドハンターは素晴らしく協力的で大変助かったという恩もあるので、今後はスパム扱いするのは少し控えようと思いました。

……が。

転職発表してから数時間経たないうちに、もし転職考えてるんだったら話さない？って送ってくるヘッドハンター様各位: 少しくらいプロフィール読んでください

— Sho Shimauchi (@shiumachi) 2018年12月4日

全てのヘッドハンターのメールからスパムフラグを外すのはまだ当分先の話になりそうです。

pyspa Advent Calendar 2018、明日は taichi です。

ルミノソジャパン合同会社に転職しました

2018年12月3日付で、Luminoso Technologies Inc. の日本法人である、ルミノソジャパン合同会社のソリューションアーキテクトとして勤務を開始しました。

この会社は、自然言語理解のためのMITスピンアウトのスタートアップです。まだ全世界で数十名しかおらず、日本では私と代表の2名のみの会社です。

Luminosoを使うことで、お客様のお問い合わせ記録のテキストからお客様の声を抽出したり、口コミなどの解析から迅速な製品の改善に繋げることが可能になります。

これだけ聞くとあまり目新しくないように見えますが、Luminosoの特長としては、こうした結果を、辞書も不要で、かつ少量のデータだけで実現できるということです。NLPの本番導入の大きな壁の一つであった、辞書管理やデータ管理をスキップすることで、導入コストと時間を大幅に削減することができます。

詳細については以下のページをご覧ください。

プレスリリース: https://www.atpress.ne.jp/news/159774
日本語webサイト: https://www.luminoso.jp/

では、なぜこの会社に入社することに決めたのかを説明します。

もう一度ゼロからスタートする

7年半前に入社したClouderaも、入社当初は70人ほどの会社で、日本はまだオフィスすらない状況でした。それから大きくなっていくに従い、会社の規模だけでなく製品の機能や、会社としてできることの数が大きく増えていきました。それはそれで楽しいことでしたが、同時に「このまま成功の波に乗り続けるだけでいいのか」とも考えていました。自分はたまたま運がよかっただけでであり、その幸運の上にあぐらをかいていていいのか、と考えました。そこで、リセットしてもう一度最初から始めてみることにしました。

会社の規模が小さいというだけではありません。自分がNEC時代から含めて8年半以上学んできたHadoopエコシステムの知識や経験も置いてきました。Luminosoでは一切Hadoopは用いていません。その代わりに、これからは自然言語処理の技術を学んでいくことになります。

もともと自然言語処理に興味があり、既に何冊かの本を読んで学んだとはいえ、この分野ではまだ素人同然です。Cloudera時代のように専門家気取りでえらそうなことを話せば、真の専門家達から袋叩きにされることでしょう。初心にかえって、一から勉強し直します。

また、技術だけでなく、自分の築き上げた人脈も置いていきます。通常、外資系の転職の場合、会社が変わっても人間関係を全部変えることは非常に稀で、一般的な日本企業よりも長期にわたって「仲間うち」で仕事する人も多いです。こうした人のつながりも置いてきました。Luminosoには、少なくともLinkedInで調べた限り、元Clouderaの人間は一人もいません。全員が初対面です。

このように、会社規模、技術と経験、人間関係、全てをゼロに戻して最初からスタートすることにしたのが今回の転職です。

データ基盤からデータ活用サイドへ

データ基盤は十分に普及したものの、データの活用方法について悩んでいるというお客様を前職では数多くみてきました。そこで、次はデータを活用する側にとって役立つようなことがしたいと常々考えていました。Luminosoは、データ基盤ではなく、データを活用する側の技術ですので、私のやりたい方向性と合致していました。

オープンソースからオープンデータへ

Luminosoは、もう一つ大きな特徴があります。ConceptNet というオープンデータをメンテナンスし、これをコアコンポーネントとしていることです。

http://conceptnet.io/

10年以上オープンソースで仕事をしてきて、オープンソースビジネスというものの将来性については十分に理解をしていたものの、オープンデータを核として成功した企業というのは聞いたことがありませんでした。これが、私がLuminosoに興味を抱いたもうひとつの理由です。

未来は誰にもわからない

この会社が成功するかどうか、私にはわかりません。入社して早々に買収されるかもしれないし、突然大企業が競合製品を発表して息の根を止めにかかってくるかもしれません。私自身ももしかしたら半年後にクビになるかもしれません。でも、だからこそ挑戦してみたいと思いました。一年後どうなっているか予想できる仕事より、一年後どうなっているのか全くわからない方が、自分には合っています。

まずは第一日目が終わりました。これから自分がどうなっていくのか、本当に楽しみです！

Clouderaを退職しました

2018年11月30日(金)は、Cloudera株式会社への最終出社日でした。2011年4月1日に入社したので、勤続日数は2800日でした。

Clouderaオフィス2011年

Cloudera Japan オフィス 2012年

日本にオフィスも同僚もいない状態からのスタートでしたが、今日、多くの同僚たちに見送られる形で会社を出ることができました。

退職するときは、最後の一人として会社を去るか、自分がいなくても会社が回るようになったときか、そのどちらかにしよう、と決めていました。皆が退職することを惜しんでくれましたが、私がいなくても会社は問題なく続いていくでしょう。私が理想とする結末にたどり着くことができて、本当に嬉しいです。

7年前、ごく一部の人しか知らなかったHadoopは、今や多くの人が知るソフトとなり、Hadoopに限らず、様々なデータ基盤を活用することが当たり前の時代となりました。

この先もきっと、データ基盤の業界は伸びていくことでしょう。そしてClouderaもその中心を担う存在であり続けると信じています。

Clouderaは最高の会社です。この会社で働くことができて、本当に幸せでした。最高のチームとも出会えました。皆と一緒に仕事できなくなるのは本当に寂しいですが、自分の行く道を信じて、新しい旅に出ることにします。

週明けからはまた新たな仕事が始まります。どのような仕事をするのかは次の記事で書くことにしましょう。

Cloudera Japan オフィス入り口 2018年

「女性エンジニア」発言についての私的見解

2018年4月21日に開催されたイベントの一セッションについての書き起こしについて発生した一連の論争について、私の思ったことをまとめます。
まず始めに、セッション発表者に対し攻撃的なツイートを行ってしまったことに対し、謝罪します。私のツイートによって多くの人が声を上げることとなり、それによって発表者の方の反論の機会を奪ってしまいました。
謝罪の証として、以下の事柄について約束します。

• 本件について直接言及していて、かつ発表者に対して攻撃的な内容となっている全てのツイートの削除、及び発表者の方からの指定したツイート削除申請の受諾
• 発表者の方のいかなる反論に対しても、その意見の場を守るための支援

本記事は、上記を踏まえた上で、何が起きたのか、何が問題なのか、なぜ私がここまで問題視しているのか、問題を防ぐためにはどうすればいいのか、について記述していきます。

何があったのか

2018年4月21日に開催されたイベントで、ヤフーの機械学習エンジニアが登壇したセッションの書き起こしが、2018年6月21日に公開されました。

https://logmi.jp/294756

その中の一部の発言について、「問題がある」と話題になりました。
以下がその発言です。(発表者名は伏せています)

エンジニア全員が抱えているもっとも重要な課題っていうのは、言うまでもないと思うんですが「女性エンジニアが少ない」。
実際、情報通信業の男女比を見てみると、男性が74パーセント、女性が26パーセント。
しかも、これはデザイナーさんなども含んでいるので、実際のエンジニアの数で言うと、もっともっと男性のほうが割合が大きいです。そして、これによって生じる問題は、男性エンジニアにとっては、「いいところを見せたい」というやる気が出ない。そして、女性エンジニアにとっては、女子トークができない。これは非常に重要な課題だと思います。
ただ、女性エンジニアを1から育成するっていうのは、非常にコストが大きいんですね。
(中略)
ということで、今回この課題に対して提案したいのは、「数の多い男性エンジニアが女性エンジニアになる」ということを提案したいと思います。

何が問題なのか

エンジニアという職業に従事している人に対して、不必要な性別によるラベリングを行っていることが問題と考えています。
まず、女性エンジニアは、男性エンジニアのやる気を出すために存在しているわけではありません。エンジニアとしての職務を全うするために存在しています。また、全ての女性エンジニアが、女子トークができないことを問題としているわけではありません。さらに、男性側についてもラベリングが行われています。すべての男性エンジニアは、女性エンジニアが少ないことによっていいところを見せたいというやる気がでない、というわけではありません。
特定の集団に対して不必要にラベリングすることは、差別とみなされる場合があります。性別のような、人間が努力によって変えることができない事柄はその代表例であり、本件のように、性別に基づいて、その性向をラベリングすることは、差別であるというのが私の考えです。
このような発言を公の場で行ってしまったことが、本件の問題と考えています。

意見に対するコメント

今回の件について、様々な方が意見を述べていました。何人か直接メンションしてきた方には返信しましたが、それ以外にも数多くのコメントがありましたので、本記事で私の意見を述べることにします。

ただのネタにおおげさでは？

差別の受け取り方は人それぞれです。そして差別は受け取った側がどう感じるかであって、行った側の意図は関係がありません。
むしろ、些細な冗談で言った一言の方が余計に傷つく場合もあります。

女性がいた方がやる気がでるのは事実でしょ？

まず、全員がそうとは限りません。少なくとも私の周囲では、同意しない人は何人もいました。もちろん、女性がいたほうがやる気が出ると答えた人もいます。そういう考え自体は個人の自由なので否定するつもりはありません。いずれにせよ、事実とは断定できません。
仮に事実であったとしても、事実かどうかは差別発言と何も関係がありません。

自分は女性だが、別に不快には思わない

本件のような発言を耳にした場合、どのように捉えるかは人それぞれです。ある女性に話を聞いたところ、「男性が『女性がいるとやる気が出る』と言ってくれると、自分もやる気がでる」という女性もいるとのことでした。一方で、このような発言を聞くと、自分が性の対象として見られている可能性があると感じて不快である、という人もいました。
感情的にどう捉えるかという話ももちろん重要ですが、本件ではこちらはひとまず横に置いておき、性別によるラベリングに起因する性差別の話にのみフォーカスします。

女だってイケメンがいいって言ってるだろ！そちらも同様に批判しないのは差別だ！

以下の記事を引き合いに出して、女性も同様に「差別発言」をしているのでは、という意見がありました。

「職場にイケメンが必要」と回答した女性会社員は83.7%
https://news.mynavi.jp/article/20150810-a094/

心の中でどう思っているかについては個人の自由であり、私はその権利を尊重すべきと思っています。上記の内容をもとに、女性全体に対して差別を指摘することはできないと考えています。上記の記事は、単なる意識調査であり、その事実を伝えることを目的としているため、本件と同列に扱うこと自体が適切でないと思います。この記事の良し悪しについてはまた別の問題です。

この程度のこと、今までいろんな人が普通に言っていたのでは？

過去にもこのような事象はありましたし、それらは実際に問題になっています。2013年の Ruby Kaigi では、「台湾の女の子はKawaii、だからRubyKaigi Taiwanに来るべき」という発言が問題になりました。
https://gist.github.com/yakitorii/5696528

新卒相手にやりすぎでは？

新卒ではなかったらやりすぎではないのでしょうか？私は、新卒であろうがなかろうが、社会人としては同じと考えます。もし、「新卒」というラベルがない人が発言したときに態度を変えるのだとしたら、それは明確に年齢や属性で差別していることになります。
冒頭で私が謝罪したことについて、発表者の方のあらゆる身体的・社会的・精神的属性、すなわち、性別、年齢、人種、宗教、学歴などとは一切関係がないことを強調しておきます。

なぜ問題視しているのか

本件についてなぜ問題視しているのかについて、無意識のバイアス、ダイバーシティ、AIの差別と機械学習エンジニアの倫理観という観点から説明します。

無意識のバイアス

ある集団において、マジョリティが同一コンテキストを前提とした話を進めるのは、マイノリティにとってはかなりプレッシャーとなります。ましてや、マジョリティがマイノリティについて言及するだけでも、かなり緊張します。このような状況下で、マジョリティが「悪気なく」マイノリティについてラベリングするような発言をしたら、私は、自分がマジョリティ・マイノリティどちらに属するかに関係なく、かなり気分を害します。このような発言は、無意識のバイアスに基づく発言の典型例です。
無意識のバイアスとは、人が自分で意識しない状態で、すばやくものごとを判断するための最適化処理の一つです。偏見や先入観は、無意識のバイアスの典型例です。素早く思考するためにはこのような最適化は有益ですが、逆に他者に対して正当でない認識を持ってしまう可能性があります。
無意識のバイアスについては、多くの企業が社員に対して研修を行っています。MicrosoftとGoogleは、無意識のバイアスについての研修を無償で公開しています。参考リンクを参照してください。

IT業界全体のダイバーシティ獲得に向けて

ダイバーシティ(＝多様性)の獲得は、マイノリティからの視点の獲得も含め、一つの業界全体の活性化になくてはならないものです。今回のような発言は、ジェンダーバイアスを助長する行為の一つであると私は考えます。

正直、他の業界の人の発言であれば、他人事としてここまで真剣に考えていなかったかもしれません。今回私が様々な反応を見て気づいたことは、日本のIT業界はまだまだ女性にとって働きにくい社会である、ということでした。
差別に対して、不快に思っても口に出せずにいる人や、影で泣いている人、業界そのものに嫌悪感を抱いて別の道に進んでしまう人が、どれだけいたか、あるいは現在もいるのか、私にはわかりません。ですが、本記事を執筆するにあたり、何人かの女性に話を聞いて気づいたことは、彼女達が皆、男性優位社会についてのある種の「諦め」を抱いていたということです。声を上げていないということは、賛同の意であるとは限らないのです。
いずれにせよ、事実として、現実問題としてIT業界における女性比率は少なく、ダイバーシティがあるとは到底いえません。私は、最低でも本業と関係のない箇所で不快な思いをしないようにしたり、仕事の妨げになるような事柄を極力排除するよう皆で努力することが、ダイバーシティの獲得に重要と考えます。だからこそ今回声を上げることにしました。

AIの差別と機械学習エンジニアの倫理観

あまり他の方からの指摘がありませんでしたが、発表者が「機械学習エンジニア」という点も、本件において大きな問題だったと考えています。ジェンダーバイアスのかかった人間が作った機械学習モデルが、バイアスのかかった結果を返し、そのモデルがあらゆるシステムに組み込まれるとしたら、非常に恐ろしいことになるでしょう。統計でさえ、統計的差別という形で合理的に差別を行ってしまう事象が存在します。
このAIによる差別は、まさに世界のデータサイエンティストや研究者が現在熱心に取り組んでいる課題であり、昨年のIBIS2017ではまさにAIによる差別というテーマで基調講演が行われました。
私は、ITの世界、とりわけ機械学習エンジニアやデータサイエンティスト、データアナリストは、ファクトと個人の意見を区別して考えられ、伝えられる人物であるべきだと思うし、こうした業界でのダイバーシティの確保はより一層重要と考えています。

どうすれば問題を防ぐことができるのか？

公の場で、性別、人種、出自などについて、不必要に言及しないことです。そして、世の中には多様な人間がいて、その人達は自分と異なる価値観や考え方、コンテキストを持っていることを常に忘れないことです。差別とみなされる対象は、性別や人種のような、生来の属性だけでなく、文化、宗教、学歴など、精神的や社会的な属性全てが含まれます。特定の属性を持った集団についての言及は、必要がない限りしないように気をつけるべきです。もちろん、プレゼンの内容的に言及の必要があれば、躊躇する必要はありません。

プレゼンにおける差別発言の禁止については、私が昔書いたプレゼンの記事でも言及しています。(本記事のレビュー時の指摘事項を受けて、元記事の記述を修正しています)

https://shiumachi.hatenablog.com/entry/2017/02/01/082807

差別、人権侵害、宗教、ポリティカルコレクトネスに反する内容
男性のプレゼンでたまに見かけるのですが、「男ならこうあるべき」みたいなことをさらっと言ってしまう人がいます。性別、人種、宗教、セクシャルマイノリティ等、差別発言ととらえられてしまう可能性がある話題に触れる場合は、本当にプレゼンに必要なものであるか考えてから使いましょう。考えた結果、プレゼン内容に不要であれば避けた方がいいでしょう。
逆に、プレゼンとして必要な話題であれば恐れる必要はありません。

参考リンク

「それ差別ですよ」といわれたときに謝る方法

http://yk264.hatenablog.com/entry/2016/10/11/103619

自分が差別だと言われる立場になったときどうするか、という内容が書かれています。

Microsoft: Diversity Training

https://www.microsoft.com/en-us/diversity/training
マイクロソフトが提供する、無意識のバイアスについての無償オンライントレーニングです。
ロールプレイのビデオが非常にわかりやすいです。
個人的には、この手の研修を実施していない企業はすぐにこれを導入していいくらいの素晴らしい内容です。
日本語で提供されているので、英語が苦手な人でも安心です。

Google re:Work - Guide: Raise awareness about unconscious bias

https://rework.withgoogle.com/guides/unbiasing-raise-awareness/steps/introduction/

Googleが提供している、無意識のバイアスについての講義資料です。
講義動画本体はこちらです。

Unconscious Bias @ Work | Google Ventures
https://youtu.be/nLjFTHTgEVU

英語がわかりやすくプレゼンもすごくうまいので、英語の勉強にもとてもいいです。

英語はよくわからない、という人は、自動翻訳で日本語字幕をつけることができます。(PCのみ、iOSアプリは不可)
設定(動画右下の歯車アイコン) → 字幕 → 英語(自動生成) を一度選んでから、設定 → 字幕 → 自動翻訳 → 日本語を選択します。字幕オフにしていると、自動翻訳を選択できないので注意してください。

きちんとトレーニングを受けるならMSのトレーニングを、まず概要を掴みたいという人はGoogleの動画を、という形で使い分けてもいいと思います。
両方まとめて受ける価値は十分にあります。

AIの差別についてのリンク

Discrimination by algorithm: scientists devise test to detect AI bias
https://www.theguardian.com/technology/2016/dec/19/discrimination-by-algorithm-scientists-devise-test-to-detect-ai-bias
AIバイアスを検知する手法について簡単に紹介している記事です。

IBIS2017 基調講演1: Supervised Learning without Discrimination
http://ibisml.org/ibis2017/session1/

上記の記事で言及されている研究者 Nathan Srebro 先生による基調講演がありました。(アブストのみ)

AI is already learning how to discriminate
https://work.qz.com/1227982/ai-and-discrimination-what-tech-companies-can-do/

企業がAI差別に対してどうすべきかについてのガイドラインが提案されています。

謝辞

本記事を公開するにあたり、多数の方のレビューをいただきました。ありがとうございます。
賛成・反対にかかわらず、本件についてコメントしてくれた全ての人に感謝します。
また、発表者の方に対し、あらためて謝罪の意を表明するとともに、私に学ぶ機会を与えてくれたことに感謝します。

修正履歴

2018/07/02 10:27 NIPS2017→IBIS2017と修正

2018年冬休み: 自然言語処理の本5冊読んだ

自然言語処理の本を5冊ほど読みました。

自然言語処理の基本と技術

自然言語処理の技術概要から、ユースケースの紹介まで、この分野における基本的な内容をざっと押さえることができました。
数式や技術的に難解な話はなく、さっと読める本でした。
最初のとっかかりとしてとてもいい本です。
非技術者や、少しだけこの分野をかじっておきたい別分野の技術者ならこれ一冊読めば十分かと思います。

自然言語処理 (放送大学教材)

こちらも入門レベルの本ですが、「自然言語処理の基本と技術」とは異なり、もう少し技術寄りに特化した内容です。
その代わり、扱う技術分野が幅広く、文字コードや言語学分野の話も出てきて、どういう知識が必要なのかを理解するのに役立ちました。
この分野の基本的な知識インデックスを頭に入れたければ上記の本と合わせてこの本まで読めば十分だと思います。

言語処理のための機械学習入門 (自然言語処理シリーズ)

数式も出てきて、実際に手を動かして学ぶ必要のある本です。先の2冊が概要の把握レベルの本であれば、こちらは技術書としての入門書になります。
この本の演習問題では「〜を作れ」といった記述しかなく、おそらく机上レベルでの作成を意図しているのでしょうが、今は scikit-learn という便利なツールがあるため、実際に手を動かしてモデルを作って試しながら読んでました。

入門 自然言語処理

NLTKは既に古いと chezou さんにアドバイスを受けたし、内容も前半部分はPythonの基礎の話や文字列処理やトークナイズの話(つまり、既に自分が理解済みの内容)だし、後半の話も他の書籍で読める内容の上、付録以外は英語ベースの話のため、私の今の興味から外れている内容でした。
ざっと目を通した程度です。
英語の解析をする必要が出てきたら読むかもしれません。

文脈解析- 述語項構造・照応・談話構造の解析 - (自然言語処理シリーズ)

サブタイトルの通り、述語項構造、照応、談話構造の解析に特化した内容です。ほぼ読み物で、演習問題等もなく、これ一冊で何かできるというような内容ではないです。