「女性エンジニア」発言についての私的見解
2018年4月21日に開催されたイベントの一セッションについての書き起こしについて発生した一連の論争について、私の思ったことをまとめます。
まず始めに、セッション発表者に対し攻撃的なツイートを行ってしまったことに対し、謝罪します。私のツイートによって多くの人が声を上げることとなり、それによって発表者の方の反論の機会を奪ってしまいました。
謝罪の証として、以下の事柄について約束します。
- 本件について直接言及していて、かつ発表者に対して攻撃的な内容となっている全てのツイートの削除、及び発表者の方からの指定したツイート削除申請の受諾
- 発表者の方のいかなる反論に対しても、その意見の場を守るための支援
本記事は、上記を踏まえた上で、何が起きたのか、何が問題なのか、なぜ私がここまで問題視しているのか、問題を防ぐためにはどうすればいいのか、について記述していきます。
何があったのか
2018年4月21日に開催されたイベントで、ヤフーの機械学習エンジニアが登壇したセッションの書き起こしが、2018年6月21日に公開されました。
その中の一部の発言について、「問題がある」と話題になりました。
以下がその発言です。(発表者名は伏せています)
エンジニア全員が抱えているもっとも重要な課題っていうのは、言うまでもないと思うんですが「女性エンジニアが少ない」。
実際、情報通信業の男女比を見てみると、男性が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冊ほど読みました。
- 作者: グラム・ニュービッグ,萩原正人
- 出版社/メーカー: 翔泳社
- 発売日: 2016/03/02
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
自然言語処理の技術概要から、ユースケースの紹介まで、この分野における基本的な内容をざっと押さえることができました。
数式や技術的に難解な話はなく、さっと読める本でした。
最初のとっかかりとしてとてもいい本です。
非技術者や、少しだけこの分野をかじっておきたい別分野の技術者ならこれ一冊読めば十分かと思います。
- 作者: 黒橋禎夫
- 出版社/メーカー: 放送大学教育振興会
- 発売日: 2015/03/01
- メディア: 単行本
- この商品を含むブログ (1件) を見る
こちらも入門レベルの本ですが、「自然言語処理の基本と技術」とは異なり、もう少し技術寄りに特化した内容です。
その代わり、扱う技術分野が幅広く、文字コードや言語学分野の話も出てきて、どういう知識が必要なのかを理解するのに役立ちました。
この分野の基本的な知識インデックスを頭に入れたければ上記の本と合わせてこの本まで読めば十分だと思います。
- 作者: 高村大也,奥村学
- 出版社/メーカー: コロナ社
- 発売日: 2010/07/01
- メディア: 単行本
- 購入: 13人 クリック: 235回
- この商品を含むブログ (42件) を見る
数式も出てきて、実際に手を動かして学ぶ必要のある本です。先の2冊が概要の把握レベルの本であれば、こちらは技術書としての入門書になります。
この本の演習問題では「〜を作れ」といった記述しかなく、おそらく机上レベルでの作成を意図しているのでしょうが、今は scikit-learn という便利なツールがあるため、実際に手を動かしてモデルを作って試しながら読んでました。
- 作者: Steven Bird,Ewan Klein,Edward Loper,萩原正人,中山敬広,水野貴明
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/11/11
- メディア: 大型本
- 購入: 20人 クリック: 639回
- この商品を含むブログ (44件) を見る
NLTKは既に古いと chezou さんにアドバイスを受けたし、内容も前半部分はPythonの基礎の話や文字列処理やトークナイズの話(つまり、既に自分が理解済みの内容)だし、後半の話も他の書籍で読める内容の上、付録以外は英語ベースの話のため、私の今の興味から外れている内容でした。
ざっと目を通した程度です。
英語の解析をする必要が出てきたら読むかもしれません。
文脈解析- 述語項構造・照応・談話構造の解析 - (自然言語処理シリーズ)
- 作者: 笹野遼平,飯田龍,奥村学
- 出版社/メーカー: コロナ社
- 発売日: 2017/05/25
- メディア: 単行本
- この商品を含むブログを見る
サブタイトルの通り、述語項構造、照応、談話構造の解析に特化した内容です。ほぼ読み物で、演習問題等もなく、これ一冊で何かできるというような内容ではないです。
人生のスナップショット
この記事は pyspa Advent Calendar 2017の22日目の記事です。前日は
資産運用に取り組み始めた - YAMAGUCHI::weblog
でした。
pyspa-botは、Mersenne Twisterという、世界的に実績がある、非常に有名なアルゴリズムをエンジンとして動作する人工知能プログラムです。
語録コマンドを実行すると、過去に登録されたその人の発言を、botエンジンがランダムに1つピックアップして返してきます。
要するにただのrandomコマンドです。
語録の登録における不文律として、「自分以外の人が登録する」というものがあります。絶対ではありませんし、自分で登録するケースもゼロではありませんが、非常に少ないです。
これが何を意味するかというと、語録には常に、「その当人以外の周りの人にとって心に残ったその人の言葉が登録される」のです。
実際語録を開いてみると、その人の声や顔が鮮明に思い浮かべられるくらい、まさにその人という語録ばかりが並んでいます。
その言葉が、その人の生きている姿を鮮明に映し出すのです。
botは、人生のスナップショットなのです。
pyspa Advent Calendar 参加者 + bot作者の moriyoshi の語録から一つピックアップして紹介しましょう。
公開しても問題なさそうなものだけピックアップしていますので、実際にはもっと個人的なネタやNSFWなネタもあります。
語録が存在しない、あるいは上記のような語録しか存在せず公開できない人は載せていません。
moriyoshi
ケツの穴にバリカン突っ込んで複雑な痔にしてやりたい
wozozo
なんか屁がめっちゃくさい...
tokibito
笑ってられるうちはデスマじゃないと思う
torufurukawa
最もイタリア人っぽい男は・・・俺かな
akisute
どうも四時からワイドの男あきすてです
flag_boy
pyspaには真理しかないよ
voluntas
wozozo が焼き肉をおごる会まだー
aodag
デスマかも？なんて思ってるときはデスマじゃないのさ
mururu
ぼくをツモりましょう
kuenishi
おいしまうち、これ買ってこい
isoparametric
にしおかどうかは主観だから、俺がそう思うんならお前はにしおなんだろう、俺の中ではな
drillbits
みんなちがってみんなジャバ
turky
以前、一番嫌な死因について考えた結果、じわじわと圧死が一番嫌という結論になりました。
nikuyoshi
危ない橋は渡ったことないので…
cocoatomo
今日, ふと思ったんだけど, 俺無職になったらそのままダラダラ無職続けてしまいそう
mopemope
卒業とか勝手なこと言ってるけど、もうみんなとっくに卒業してんだよ！！気づけ！マヌケ！
takabow
今日も新橋です
ymotongpoo
素直に「ションベン漏らした！！」っていえよ！！！！
shibu_jp
マイ・リトル・ポニーを見ている方がよっぽど有意義というものだ。
chezou
残念ながらソフトクリーム食べながらR書いてます
hiroki.niinuma.5
肩がこった？いいのかい？俺が本気で揉んじまって
楽天テクノロジーカンファレンス2017でApache Kuduについて発表してきた
楽天テクノロジーカンファレンスに登壇するという貴重な機会をいただいたので、Apache Kuduについて発表してきました。
主催していただいた楽天様、ご聴講いただいた皆様、ありがとうございました。
社外での英語プレゼンだったのでなかなか準備が大変でした。
以下、補足やFAQです。
これ資料英語なんだけど日本語はないの？
この資料そのものの日本語スライドはありませんが、より詳しいスライドが日本語で公開されています。
資料読むのだるいからKuduについて3行でまとめて
- Kuduは、HDFS みたいなシーケンシャルリードの性能と、低レイテンシでのランダムアクセスや更新・挿入が得意なHBaseのようなNoSQLの長所を合わせ持った、新しいOSSのストレージエンジンだよ！
- Kuduを使うと、ラムダアーキテクチャのようなバッチ処理 + ストリーミング処理や、分析クエリ + 更新処理みたいな、今まで複数のコンポーネントを組み合わせないと作れなかったようなシステムがこれ一つでできるよ！
- Kuduの使い道の代表例としては、IoTなどにおけるセンサーデータのリアルタイム分析や、金融ティックデータ分析などのリアルタイムダッシュボード、UPDATE/INSERT文を含む既存DWHからのオフロード・マイグレーションなどがあるよ！(参考)
KuduあればHDFSやHBaseいらなくない？
Kuduはどちらの特徴も備えていますが、性能的にはどちらについても若干劣ります。よって、HDFSやHBaseだけで足りる用途であればそちらを使った方がいいです。
また、Kuduは型を必ず持つので、型を考えずにとりあえず突っ込んでおきたいという場合には適しません。
HDFSやAmazon S3、Azure Data Lake Store のような中央ストレージを持ちつつ、補完のためにKuduを活用していくといいでしょう。
Kuduの性能評価結果を教えて
日本語スライドとしては2015年のスライドのこのページに一応載っていますがちょっと情報古いです。
2017年2月に公開されたCERNによる性能評価が一番新しいと思います。
まとめ
Kuduはリリースされてから2年ほど経って、かなり色々こなれてきた感じがしています。
便利なのでガンガン使っていきましょう！
Kuduについて日本語でもセッション聞きたいという人は、11/7(火)に開催されるCloudera World Tokyo 2017に来てください。私とは別の切り口でのKuduのセッションがあります。
ブラウザ上で簡単にビッグデータを扱えるOSS: Hue についての簡単な紹介
ドワンゴさんの主催でHue Meetupが開催されることになったので、いい機会だから Hue について、自分の復習がてらまとめておきます。
Hue って何？
Hadoopエコシステムを操作するためのWebインタフェースです。
Hadoopエコシステムの多くは、管理Web UIは持っていても、ユーザ用のWeb UIはありません。
ユーザがターミナルからコマンドを叩かなくてもHadoopエコシステムを操作できるようにするのが目的です。
主に、以下のようなことができます。
Hue は誰が使っているの？
Hueは、全ての主要なHadoopディストリビューションに含まれているので、Hadoop触っている人は意識せずとも使ったことある人も多いと思います。
あと、Amazon Athena の UI は間違いなく Hue です。
先日、あるお客様のところに製品紹介にいったときにHueを見せたら、「Athenaみたいですね」と言われました。逆ですから！
EMR Hue の話は、Hue Meetup でミクシィの岩瀬さんが話をしてくれます。
ドワンゴさんはヘビーなHueユーザで、主催者の木浦さんがそのあたりの話をしてくれるはずです。
Hue って何で作られてるの？
Hueは、以下のコンポーネントで作られています。
Hue Meetupでは、@tokibito ことオープンコレクターの岡野さんが、Django開発者という観点からみたHueを説明をしてくれる予定です。
Hueで何ができるの？
色々できます。
ファイルブラウザ
ファイルをアップロードしたり、編集したり、ダウンロードしたりすることができます。
Pigエディタ
一部で根強い人気の残るPigも実行できます。
検索ダッシュボード
Solrと連携して検索ダッシュボードを作成することができます。
(Hue 公式サイトより引用)
まとめ
Hue を使うと、ビッグデータ基盤のWeb UIを簡単に用意することができます。
まだ使ったことない人も、使っているけどもっと色々使いこなしてみたい人も、自分の使い方を共有したい人も、Hue Meetupに参加してみてください。
進捗ヤバいプロジェクトに直面した経験がある人なら（多分）楽しめるカードゲーム「Not My Fault!」
エンジニアがプロジェクトがオンスケであると嘘をつき続けるゲームは盛り上がった pic.twitter.com/aWkKIPtAAS
— Yoshifumi Yamaguchi (@ymotongpoo) 2017年7月30日
@ryushi さんの主催で仲間内で集まってボードゲーム・カードゲームで盛り上がったのですが、その中で @tokoroten が持ってきた「Not My Fault!」というカードゲームが非常に衝撃的でした。
まず、背景設定がすごい。
残り30日で絶対に完成させなければいけないプロジェクトに、プレイヤー達はプロジェクトメンバーとして参加しています。
進捗は絶対に遅れてはいけません。
もし、プロジェクトの進捗が報告されていたよりも進んでいないとしたら？
それはもちろん、進捗を過大報告したヤツの責任です。
監査を入れて、そいつを追い詰めよう！
というのがゲームの設定です。
これを読んで、「あー、そういうのあるよねー」と共感したり、「あー、そんなことあったわ」と遠い目をしたり、「あー、今まさにそんな状況だわ」と暗くなったりということが少しでもあれば、このゲームを手に取ってみるといいと思います。
ゲーム自体はすごくシンプルです。
複数人でプレイし、山札を中心に円になって座ります。
最初に一番目の人が一枚目を引いて、自分の作業の「本当の進捗」を確認します。
その後、自分の目の前の場にカードを伏せて置き、「進捗」を報告します。
二番目以降の人は二つのアクションを取ることができます。
一つは前の人と同様に山札を引き、自分の前に伏せて「進捗」を報告する、もう一つは今までの進捗を「監査」することです。
監査した結果、「本当の進捗」が「今まで報告された進捗」よりも低かったら、前の手番の人は責任を取らされます。
逆に、「本当の進捗」が今まで報告された進捗通りだったら、監査を要請した人は責任を取らされます。
通常は二回責任を取らされるとクビですが、ルールによっては一発でクビ（つまりゲームから退場)することもあります。
誰かが責任を取ったら1ラウンド終了です。
この「進捗カード」は0から6までの数字が振られています。
「本当の進捗」というのは、今まで伏せられた全プレイヤーのカードの合計の数字となります。
例えば、場に0、5、3、1が伏せられていたら、本当の進捗は9となります。
そして、報告する「進捗」ですが、絶対にマイルストーン通りの進捗報告をしなければなりません。
当たり前ですよね？30日で完成するプロジェクトに進捗の遅れなど許されないのですから。
このマイルストーンは、最初がいきなり5日です。
つまり、最初のプレイヤーは、0-6までしかないカードのうちランダムに引いた1枚のみを場に伏せて、「5」と言わなければいけないのです。
しかし、このプロジェクトのプロマネはとても有能かつ広い心の持ち主でした。
どのプロジェクトメンバーも、一度だけなら進捗の遅れを報告しても許されます。
つまり、本来「５」と報告しなければいけないところを、「1」と言っても許されるのです。
二度目は当然ありません。
他にいくつかルールがありますが、基本はこのような感じのルールです。
ルールを見てピンと来た人がいると思いますが、これは要するにトランプのダウトの変形です。
嘘の数字を言って場にカードを伏せ、他のプレイヤーがダウトと宣言して嘘だったら宣言した人の勝ち、本当だったら宣言した人の負け、というのと何ら違いはありません。
このゲームの本当の楽しみ方は、炎上プロジェクトに入った気分になって盛り上がることです！
全く進んでいないのに進捗報告で「オンスケです」と自信満々に報告し、進捗遅れを使う場合は「すいません、ちょっと体調不良で…」などと言い訳する。
監査する場合は「ちょっと進捗報告おかしいんじゃないのかね、君？」と問い詰め、退場することになった場合は「一身上の都合で退職します。今までお世話になりました」と挨拶する。
どう考えてもこんなデスマ案件抜けた方が幸せだろ
要は、「ゲームの勝ち負けよりワイワイ盛り上がって楽しむ」ためのゲームです。
楽しみ方が大分ニッチではありますが、我々のような一部の業界の人にはドンピシャ間違いなしです。
今回はお酒なしでプレイしていましたがそれでも大盛り上がりでした。
飲みながら気軽に楽しむのが一番いいと思います。
私達がプレイしたときは、大体こんな感じのプレイ風景でした。
not my fault、最高だった。
— ところてん (@tokoroten) 2017年7月30日
「すいません、体調が悪くて進捗が１しかありませんでした」
「私は優秀なので、当然オンスケです」
「ところてんくん、きみ進捗ごまかしてるよね」
「いえいえ、過少申告をしていたので実際オンスケ」https://t.co/HBxHdMzmbg
not my faultの謎リプレイ
— ところてん (@tokoroten) 2017年7月30日
「プロジェクトはオンスケです」
「山口さんが進捗を過大報告している疑いがあります。プロジェクト監査をしてください」
「ニ徹して進捗をオンスケに戻しています」
「チームの和を乱してしまい、大変申し訳ありません。本日をもって退職いたします。」
値段は900円(Amazon価格)と大変リーズナブルです。トランプサイズのカードゲームなので持ち運びにも便利です。
是非一度、エンジニア仲間同士でも、プロジェクトチームのメンバーでもいいので、一緒にやってみてください。
作者さんの紹介ページでは作者さんのAmazonアフィリエイトリンクも貼ってますので、そちらから購入してあげましょう。
Twitterでのリプレイ・感想ツイートまとめ (2017/08/01追記)
「Hadoopの時代は終わった」の意味を正しく理解する
Hadoopの時代は終わった、という言説をたまに見かけるようになりました。
もちろん終わってなどいません。しかし、Hadoopとその取り巻く環境が変化したのは事実です。
本記事では、この変化が何なのかを明らかにし、その上で、なぜHadoopの時代は終わったという主張が実態を正しく表していないのかを説明していきます。
DISCLAIMER
私はHadoopを中心としたデータ基盤を取り扱うベンダー、Clouderaの社員です。
中立的に書くよう努めますが、所属組織によって発生するバイアスの完全な排除を保証することはできません。
以上をご了承の上、読み進めてください。
要約
データ基盤は、Hadoopの登場により非常に安価となり、今まででは不可能だった大量のデータを取り扱えるようになりました。
Hadoopは、NoSQLブームの中、処理エンジンであるMapReduceとストレージであるHDFSが一体となっていたため、データ基盤向けのソフトウェアとしての地位を確立していきました。
しかし、2010年代に入ると、ハードウェア、処理エンジン、ストレージの進化により、Hadoopは大規模なデータ基盤として唯一の選択肢ではなくなっていきます。
特に処理エンジンは、MapReduce以外にも優れた処理エンジンが登場してきたため、現在MapReduceはその役割を終えようとし始めています。
一方HDFSは、以前としてオンプレ環境におけるOSSの大規模分散ストレージとして高い地位を占めています。
Hadoopがカバーする範囲も拡大し、新しい処理エンジンやクラウドストレージに対応し、順調に進化を続けています。
よって、Hadoopの時代が終わった、という言葉は正確ではなく、MapReduceの時代が終わった、というのが正しい理解です。
用語の定義
本記事での用語を定義しておきます。
ストレージとは、データを格納する基盤のことを指します。本来はメタデータ(DBスキーマなど)のストアと区別しなければいけないのですが、簡略化のためにストレージとしています。
暗黙的に、その時代における大量のデータを保存することを想定しています。
処理エンジンとは、ストレージからデータを取り出して何らかの処理を行うためのシステムです。ここでは、簡略化のために、SQLなどの、処理エンジンにアクセスするためのインタフェースも処理エンジンの一部として含めて紹介します。
こちらも暗黙的に、その時代における大量のデータを処理することを想定しています。
データ基盤とは、ストレージに格納されたデータを、処理エンジンを利用して、ビジネスにおけるデータ活用を行う基盤のことを指します。バッチ処理、DWH、機械学習など、データを取り扱うものを全て含みます。
なぜ本記事においてビッグデータ基盤と言わないかというと、既に大量のデータを扱うことが当たり前になってきた今日において、ビッグデータブームが始まる前と後で区別することにそれほど意味がないからです。
アプリケーションとは、データ基盤を利用することで新しい価値を提供するソフトウェアを指します。例えば、BIツールやETLツールなどです。ここでは内製ではなく商用ソフトウェアを中心とします。
データ基盤の歴史(1): Hadoopの登場から発展まで(2000年代～2010年代前半)
Hadoop以前(～2006年)
2000年代に入るまで、データ基盤は非常に高価なシステムでした。そのために、本当に重要な一部のデータだけを活用することが常識でした。
データ基盤は、主にメインフレーム、商用RDBMS、商用データウェアハウスなどで構成されていました。
これらは全て、処理エンジンとストレージが垂直統合されていました。
非分散型・スケールアップ型が当たり前の時代だったので、垂直統合しておいた方が効率的だったのです。
しかし、Googleは自社の検索ビジネスにおいて、Webサイトのデータという大量の非構造データを、より安価に処理するための基盤を必要としていました。
そこで開発されたのがMapReduceというアルゴリズムとGFSというストレージシステムでした。
この2つの技術に関する論文をGoogleが発表したのは2003から2004年ですが、これを読んだDoug Cuttingがオープンソースで同様のシステムを実装します。
これが、後のHadoop MapReduce (以下MapReduce)と Hadoop Distributed Filesystem (HDFS) となります。 *1
NoSQLの台頭とHadoop一択の時代(2008～2012年)
Hadoop登場と同時に、NoSQLブームが発生しました。NoSQLをどう定義するかは人によって違いますが、一言でいうと「RDBMSが持っていた機能を限定することで、性能のスケーラビリティを重視したストレージ」です。
処理エンジンを内包したストレージも一部ありましたが、価値の根本部分は「スケーラブルなストレージ」という点になります。
多くの人が、そのNoSQLという文字内容から「これからの時代はRDBMSでもSQLでもないんだ」と勘違いしてしまいましたが、NoSQLはあくまでストレージの進化であり、処理エンジンの進化ではありません。
この時代に成功したNoSQLも数多くありますが、同時期におけるデータ基盤向けストレージの勝者は間違いなくHDFSです。
なぜなら、この時代にほぼ唯一の処理エンジンの選択肢だったMapReduceが、HDFSに密結合していた(ように見えていた)からです。
Hadoopは、MapReduce (処理エンジン) + ストレージ(HDFS) が密結合しているように見えてしまっていたため、ほとんどの人がこれらが一体となっていると思い込んでしまいました。
このことは、この時期においては有効に働きましたが、これこそが今回のテーマである「Hadoopは終わった」論の遠因となっていったと私は見ています。
ともかく、Hadoopは、こうした背景から、大規模なデータ基盤としてのこの時代唯一の選択肢として発展していったのです。
データ基盤の歴史(2): Hadoop一択の時代を超える(2010年代)
2010年代に入ると、当たり前のように大量のデータを扱う時代が到来し、様々なユースケースにおいて大量データの処理が求められるようになってきました。
元々用途を限定して作られたシステムだった当時のHadoopに対し、新しいユースケースに対応した処理エンジンやストレージが登場し始めます。
そして、古き良きHadoop、すなわちMapReduce + HDFSは唯一の選択肢ではなくなっていきます。
この変化には、複数の領域における発展・変化が関係していきます。
ハードウェアの進化
Hadoopが登場した背景には、ハードウェアの進化の限界がありました。
2000年代においてはまだメモリが高価で、CPUもディスクも性能が鈍化していて、データ基盤を構成するにあたって単一のサーバでのスケールアップでは限界があったために、GoogleのMapReduceアルゴリズムとGFSは分散アーキテクチャを採用しました。
しかし、2010年代に入ると、CPUの性能はあまり変わらないものの、メモリが以前よりもはるかに大容量・安価になり、こうしたアーキテクチャの変化を前提にしてインフラ全体が変わっていきました。
処理エンジンの進化
MapReduceが出た当時は、他の技術と比較すると確かにシンプルで理解しやすく、書きやすいと思われていましたが、2010年代に入ると逆に複雑なフレームワークとみなされるようになってきました。
また、MapReduceはバッチ処理に限定したフレームワークである上に、処理手法が効率よく働くケースが限定的でした。
こうした課題を解決するため、Apache Sparkが登場しました。効率のよいメモリ活用による高速化と、格段に書きやすくなった記述形式、そしてバッチ処理だけでなく、ストリーム処理や機械学習などもカバーする幅広い用途により、2012年の登場してから急速に注目が集まり、2014年の1.0リリースから一気に広まっていきました。この普及の背景には、先述のハードウェアの進化によるメモリの大容量・低価格化も大きな一因となっています。
データ基盤におけるデファクトスタンダードのインタフェースであるSQLにも大きな変化が起こりました。
MapReduceを使ったSQLエンジンとしては既に2008年にHiveが登場していました。
しかし、大量の非構造データを処理する性質を備えつつも、既存のRDBMSやDWHのような低レイテンシを満たせるような新しいSQLエンジンが求められるようになっていきました。
そして、2012年にApache Impala(当初の名称はCloudera Impalaだが、2016年にASFに寄贈)が登場したのを皮切りに、様々な新世代のSQLエンジンが登場しました。
2012年には、Google BigQueryのような、クラウド上にしか存在しない処理エンジンも登場してきました。ストレージの選択肢が事実上Googleだけになってしまうという欠点があるものの、クエリ毎の課金という革新的な価格体系と高速性から、GCPを代表するサービスとして広く普及していきました。
このように、2010年代中頃になってくると、MapReduce以外の処理エンジンが増えていき、MapReduceはあくまで処理エンジンの選択肢の一つとなっていきました。
ストレージの進化
2010年代前半に、処理エンジンの選択肢が多様化しても、ストレージとしてはまだまだHDFS一強の時代でした。大量のデータを処理する基盤に適した、安価でスケーラブルなストレージシステムがHDFSしかなかったのです。
Amazon S3 をはじめとしたクラウドストレージを使うと、ストレージシステムの運用から解放され、初期投資が極めて安価でしかも簡単にスケール可能という多くの利点がありますが、2010年代前後はまだ値段も高く、信頼性・実績ともに乏しかったため、メインのストレージにしようという企業はわずかでした。
しかし、クラウドストレージが進化を続け、信頼性の向上と価格の低下が進むと、インターネット系企業を中心にストレージの中核をクラウド上に持つ企業が数多く登場していきました。こうした企業は、もはやHDFSを自前で持つこともなく、クラウドストレージを中心としてデータ基盤を構築していきました。
ストレージのトレンドの変化を受けて、処理エンジンの側にも変化が発生します。
HDFSを持たずにデータ処理を行いたいというニーズに応えるために、処理エンジンもクラウド対応への変化が進んでいきました。
Amazon EMR は S3上のデータを直接 MapReduce で処理することができる、Hadoop をフォークして開発されたサービスですが、後に Apache本家でも別個にAmazon S3への対応が進み、高速にデータを処理できるようになっていきました。
また、Sparkや、Impala / PrestoなどのSQLエンジンもクラウドストレージへの対応が当然のように行われるようになり、オープンソースの処理エンジンはHDFSだけではなくクラウドストレージへ対応することが求められるようになってきました。
RDBMS・DWHの進化
RDBMSやDWHも着々と進化を続け、データ基盤のニーズに応えるよう変化しています。例えば、商用DWHでは既にjsonサポートが当たり前になっており、非構造データへの対応が進んでいます。OSSのRDBMSにおいても、PostgreSQLは2012年(9.2)からjsonをサポートし、続くバージョンでjson対応を強化していっています。また、扱えるデータ量も増えていっており、商用DWHでは1PB以上のデータのサポートは当たり前となっています。
DWHそのものもクラウド化が進みます。Amazon Redshiftはクラウド上で安価に利用できるサービスであり、従来のDWHを購入するだけの予算がなかったような企業でも簡単にデータ基盤を持つことができるようになりました。
現代におけるデータ基盤
現代においては、データ基盤で利用する処理エンジンとストレージの組み合わせは実に多様化しています。
処理エンジンに重きを置く人はまずSparkやBigQueryを前提にストレージエンジンを探すでしょうし、ストレージに重きを置く人はまずHDFSやS3というストレージ選定から始めて処理エンジンを探すでしょう。
あるいは、使っているアプリケーションが対応している処理エンジン・ストレージを選択していくという過程を選ぶ人もいるかもしれませんし、オンプレミスかクラウドか、あるいは両方を使うべきかという、インフラを中心に選択する人もいるでしょう。
そして、これらのうちどれか一つを選ぶのではなく、複数を組み合わせるというのも当たり前になりました。
ストレージとしてオンプレミスのHDFSとクラウドのS3を同時に持つシステムは多数存在しますし、既存の MapReduce ジョブを走らせ続けながら新規開発にはSparkを使い、BIツールからの接続にImpalaを使うという企業はますます増えています。
データ基盤を選ぶのではなく、データ基盤を構成する処理エンジンとストレージの組み合わせを選ぶ時代なのです。
Hadoopの時代は本当に終わったのか？
Hadoopは、MapReduceという処理エンジンとHDFSというストレージの二つを組み合わせたものであることは説明しました。
これらのコンポーネントは、それぞれ異なる変遷を辿っていきます。
処理エンジンは、バッチ処理だけに特化していたMapReduceから、ストリーム処理、低レイテンシなSQL、機械学習など、様々な用途に対応するための処理エンジンが登場してきました。
バッチ処理についても、より高速で書きやすいフレームワークであるSparkの登場により、MapReduceは既存のプログラムへの後方互換という用途以外の役目を終え始めています。
しかし、Sparkを始めとした新しい処理エンジンは、様々なデータ基盤で採用されています。
そして、Hadoopという名称が指す領域は、MapReduceだけでなくだけでなくSparkやSQLエンジン、さらにはSolrなどの検索エンジンに拡大していっています。
HDFSは、クラウドストレージを選択する組織が増えてきたものの、データ基盤のストレージとして依然大きな存在感を持っています。
HDFSほどスケーラブルで、かつ実績のあるオープンソースのストレージシステムは他にありません。
自社に十分なインフラ資源(人・モノ・金全て含む)が整っている場合、クラウドストレージを使うよりも圧倒的に安価になるため、HDFSは有力な選択肢となります。
また、オンプレミスからクラウドに移行する際にも、クラウド上でそのままHDFSを動かしてしまえば、既存のコード資産をほぼ変更せずに移行できるため、処理エンジン同様ポータビリティが高いという特性があります。
こうした利点を考えると、HDFSはまだまだ活用され、発展していくと言えます。
このように見ていくと、MapReduceは確かに新しい処理エンジンにバトンを渡して静かにフェードアウトし始めていますが、新たな処理エンジンとHDFSを携えて、Hadoopそのものは進化を続けていっていることがわかります。
Hadoopの時代は終わってなどいないのです。
では、なぜHadoopは終わったと言われてしまうのでしょう？
私の見解では、HadoopはMapReduce + HDFSがセットになっているというイメージが強すぎて、そこからの転換が進んでいないことが原因と見ています。
多くの人が未だにHadoopはバッチ処理のためだけの基盤だという誤解をしています。
2014年前後に、Google BigQueryやAmazon Redshiftのような、安価なデータ分析のための基盤の普及が進みましたが、そのユーザの多くはHadoopが既にそうしたデータ分析が可能になっていることを知らず、古き良きHadoopとBigQuery/Redshiftの間に大きな知識の断裂があるように感じます。
2010年前後に有利に働いたイメージが、逆に今は足かせになっている、というのが私の意見です。
まとめ
Hadoopの時代は終わった、という言説を見かけますが、MapReduceの時代が終わった、というのが正しい理解です。
Hadoopは、従来のRDBMSやDWHに比べ、大容量かつ非構造データを処理可能でしかも安価な基盤として2000年代後半から2010年代前半にかけて普及しました。
しかし、2010年代中頃には、Sparkを始めとした新しい処理エンジン、クラウドの台頭、ハードウェアの進化、そしてRDBMSやDWHの性能向上に伴い、初期のHadoopのアーキテクチャの必要性が失われていきました。
現在のHadoopは新しい処理エンジンやクラウドへの対応が進んでいるものの、初期のHadoopのイメージが残り続け、Hadoopの時代が終わったという言説につながっていっている、というのが「Hadoopの時代は終わった」という主張の原因と私は推測します。