ソフトウェアの品質を学びまくる2.0

旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

Sogetiの考える「人工知能のテスト」を調べてみた。

 2018年3月、「AIプロダクト品質保証コンソーシアム」の設立が発表されました。

monoist.atmarkit.co.jp

 略称は「QA4AI」、つまり「AIのためのQA」ですね。前回の翻訳記事は「QAのためのAI」だったので、今回は「AIのためのQA」も含めた話題を紹介します。TPI NEXTやTMapで知られるSogetiによるホワイトペーパー「人工知能のテスト」です。

TPI NEXT? ビジネス主導のテストプロセス改善

TPI NEXT? ビジネス主導のテストプロセス改善

 目次は以下の通り。かいつまんで紹介してみます。

1 Executive summary
2 Setting the scene
3 Testing of Artificial Intelligence
4 AI Quality Engineering Skills
5 Conclusion
6 Acknowledgments

1. 概要

 要点は以下の3点です。

  • 人工知能(AI)が台頭してきて、人々の生活を変え始めている。
  • AIがテストを代替するソフトウェア開発においては、アジャイルやDevOpsの流れで定着してきた2週間といったサイクルでも遅い。
  • テストに関する既存の知識は、AIのためのテスト、AIによるテストにおいても有効だが、新たなスキルも必要になる。

2. 準備

 まず、単語について簡単に説明しています。特徴的なのは以下の2つ。

  • Machine Intelligence: 機械知能。「AI」という言葉を使った途端に、「本当のAIとは」と話が逸らされていくので、AIやMLと同じような意味で使っているとのこと。
  • Cognitive IT: コグニティブIT。知覚と知識に基づいて振る舞うことのできる情報技術。テストや品質保証のためにコグニティブITを使うことを、Sogetiでは「コグニティブQA」と呼んでいます。

 次に、AIを用いたシステムをテストすること(testing OF AI)と、AIを用いてシステムをテストすること(testing WITH AI)の二つを説明しています。 後者は「デジタルテスティング」と表現されてもいます。

3. AIをテストする

6つの軸

 AIの品質の軸として以下の6つを挙げ、目新しいものとして後の3つについて詳述しています。

  1. Mechanical(機械)
  2. Electrical(電気)
  3. Information Processing(情報処理)
  4. Machine Intelligence(機械知能)
  5. Business Impact(ビジネス・インパクト)
  6. Social Impact(社会的インパクト)

 本ペーパーで何度か言及されることですが、テスターに求められる作業として、以下の二つが挙げられています。

  • システムが時間(と学習)につれて変化していくため、システムの出力が満たすべき境界や許容範囲を決め、テスト中も本番環境でも、その範囲に収まっていることを確認する。
  • 入力に対する出力への影響を理解する。また、システムの入力を制限して、出力への影響を限定する。

 入力と出力の両方に注目していることがポイントです。また特に後者については必ずしも開発中の話ではないようです。リリース後にユーザからの入力から学習する前提で、それを継続的にモニターすることを求めています*1
 4章では、Microsoftのチャットボットが起こした問題に言及しつつ、機械がどのように学んでいるのか、入力に対してどのように反応しているのかを理解する必要があるとしています。

www.buzzfeed.com

 また「社会的インパクト」について、新技術が社会や個人にもたらす影響に注意を払う必要があり、社会学や心理学の知見が必要としています。ソフトウェア品質保証の「V&V」では検証(Verification)と妥当性確認(Validation)があり、特に後者では「仕様どおりに」作られていることよりも、その製品が本来求められている要求を満たしているかを確認することが必要になりますが、その範囲が「ユーザ」という個人から、さらに拡張されている感じですね。

AIのテストにおける確認事項

 例に挙げられた確認事項は以下のように、技術的な側面だけでなく、社会的側面、法的側面、倫理的側面についても言及があるのが特徴です。

  • 受け入れ条件は何か
  • 最小工数でその条件をテストするために、テストケースをどうデザインするか
  • トレーニングとテストでデータを分離しているか
  • テストデータは、予想されるデータを適切に代表しているか
  • テストとトレーニングデータは法的なフレームワークに準拠しているか
  • トレーニングデータは偏っていないか
  • モデルの期待出力は何か
  • モデルがオーバーフィット/アンダーフィットしていないか
  • ソリューションは非倫理的ではないか
  • 性能と堅牢性は十分か

4. AI品質保証のエンジニアリング技術

必要となる知識

 テスト技法やテスト管理など、既存のテスト関連技術は今後も応用できる一方で、今後新たに必要になるスキルセットについて言及しています。

  • 機械学習、ビッグデータ解析、クラウドコンピューティング
  • PythonやScalaなどのプログラミング言語、TensorFlowのようなOSS
  • 数学。特に統計・微分積分・線形代数・確率
  • A/Bテスティング、メタモルフィックテスティング
  • ハードウェアアーキテクチャ
  • 機械、電気。ロボットが物理的なものなら。
  • 生物学、経済学、社会科学、心理学。データサイエンティストにとって使い道が多い。
  • 哲学や倫理学。インテリジェントなソフトウェアの世界では重要さを増す。

 A/Bテストやメタモルフィックテスティングについては、以下の動画や記事をご覧ください。


What A/B Testing is & How to Use It www.kzsuzuki.com

セキュリティ、プライバシー

 データポイズニングやAdversarial Examplesといった攻撃手法や、フィルターバブル*2、偏見の増幅による差別の拡大といったビッグデータの課題、顔認識技術の発達によるプライバシーの問題などについて言及しています。たとえばKasperskiのこの記事が参考になるかもしれません。

blog.kaspersky.co.jp

5. 結論

 第5章では、AIのテスト、AIによるテストにおいて求められるスキルが列挙されています。上述の「知識」と重複する部分もありますが、よりマネジメント・ビジネスに近い内容もあるので、ぜひホワイトペーパーをご覧ください。

 また最後の主張として、これらの高度なスキルをすべてもった人間を連れてくるのは困難なので、既存のスキルを備えたメンバーに対し、新たな教育の投資をしていこうと書かれています。前の翻訳記事では「AIによって仕事を失ったりはしないよ!」みたいな論調でしたが、AIをテストしようとする人は、これまで以上にハードな継続的学習が必要になりそうです。とってもげんなりワクワクしますね!

www.kzsuzuki.com

終わりに

 と、それなりに原稿を書いたところで、ソフトウェアテストヒストリアン・辰巳敬三さんのこのツイート・・・。まったく追いつかない・・・。

*1:そのモニターにもまた、AIが使われるであろうという前提で。

*2:「インターネットの検索サイトが提供するアルゴリズムが、各ユーザーが見たくないような情報を遮断する機能」(フィルター)のせいで、まるで「泡」(バブル)の中に包まれたように、自分が見たい情報しか見えなくなること。 via Wikipedia

【翻訳】AIベーステストの6つのレベル - QAのプロにとって恐れるべきものではない

 Gil Tayarさんの「6 levels of AI-based testing: Have no fear, QA pros」という記事がteckbeacon.comで公開されていたので、紹介します。モバイルアプリやWebアプリなど、画面の操作を伴うアプリケーションを前提とした内容になっています。

techbeacon.com

 「6つのレベル」というのは、自動運転の6つのレベルに着想を受けたものですね。
 フォルクスワーゲンのサイトから引用して、元記事の「6つのレベル」と並べてみましょう。

www.volkswagen.co.jp

レベル 自動運転 自律的なテスト
0 ドライバーがすべての操作を行う。 自律性なし
1 ステアリング操作か加減速のいずれかをサポートする。 ドライブアシスタンス
2 ステアリング操作と加減速の両方が連携して運転をサポートする。 部分的な自動化
3 特定の場所ですべての操作が自動化、緊急時はドライバーが操作。 条件付きの自動化
4 特定の場所ですべての操作が完全に自動化される。 高度な自動化
5 あらゆる状況においても操作が自動化。ハンドルもアクセルも不要。 完全な自動化

 それでは、翻訳です。
 誤訳などについてはコメントをお願いします。

翻訳

 あなたは、人工知能(AI)が近いうちに、視覚的なテストをQAチームから奪っていくと心配しているだろうか? その必要はない。自律的なテストツールは助けてこそくれ、あなたの代わりになってはいないだろう。テスターやQAチームは、ビジネス価値について考えることに時間を使うべきだ。つまり、目的を達成するための手段として自動テストを実行することよりも、どうテストし、どう品質保証するかを考えることに力を注ぐべきということである。

 テストには6つのレベルがある。これで、AIテストの革命に不意打ちされることを避けられるだろう。

レベル0: 自律性なし

 おめでとう。あなたはアプリケーションをテストするコードを書き、リリースのたびに何度も実行できるので、実に幸せだ。完璧である。テストにおいてもっとも大事なことーーー考えることに集中できるのだから。

 でも、その自動テストを書くのを手伝ってくれる人はいない。それに、コードを書くこと自体が繰り返しの作業だ。フォームにフィールドが追加されたら、テストを追加しないといけない。ページにフォームが追加されたら、すべてのフィールドをチェックするテストを追加しないといけない。ページが追加されたら、そのページのフォームと部品をすべてチェックしないといけない。
 開発者がアプリケーションに見境なく変更を加えると、テストが多いほど失敗も増える。そして失敗したテストすべてについて、その原因が本当のバグなのか、新しいベースライン*1なのかを確認しなければならない。

レベル1: ドライブアシスタンス

 自律走行車(autonomous vehicle)は、(自律的な)テストのレベルの良いメタファーになる。視覚システムが向上するほど自動車がより自律的になるのと同じように、AIシステムがアプリケーションを「視る」のがうまくなるほど、テストも自律的になる。

 AIはページのDOM(Document Object Model)のスナップショットだけでなく、見た目のイメージ(visual picture)も視られるようになっているべきだ。DOMはイメージの半分に過ぎない。テキスト付きのエレメントがあるからといって、ユーザがそれを見られるとは限らない。ページをわかりづらくするエレメントがあるかもしれないし、ページが正しい位置にないこともある。見た目のイメージがあれば、ユーザが見るデータにフォーカスすることができる。
 テスティングフレームワークが、DOMやスクリーンショットを通じてページを全体的に視られるのであれば、チェック(するコード)を書くのをサポートできるだろう。
 ページのスクリーンショットを取れば、そこにあるフォームのフィールドやテキストを一括してチェックすることができる。各フィールドをチェックするコードを書くかわりに、過去のテストをベースラインとして一気にテストすることができるのだ。

 このレベルのテストを可能にするには、「どの変化が本当の変化で、どの変化が実際には何も変わっていないのか」を判断するためのAIアルゴリズムを、テストツールが備えている必要がある。
 今日のAI技術は、チェックしたいことを人間が書くことで、テストコードの実装をアシストしてくれる。テストの駆動(drive)*2は人間が行わなくてはならないが、AIが一部を自動的にチェックしてくれる。
 AIはテストがパスしたかもチェックできる。しかしテストが失敗した場合は、それを人間に通知しなくてはならない。その失敗が本物(のバグによるもの)なのか、ソフトウェアの適切な変更によるものなのかは、人間が判断するのだ。その変更が適切なものだと確認するか、バグとして拒否しなくてはならない。
 AIがアプリケーションを「視る」というのは、アプリケーションの視覚的側面をベースラインと比べてチェックするということであり、今まで手動テストでしかできなかったことだ。ただし依然として、変化が妥当なものかどうかはすべて、人間が確認しなければならない。

レベル2: 部分的な自動化

 レベル1の自律性に加えて、ベースラインと比較するテストをAIに行わせることで、ページのすべてのフィールドに対するチェックを書くという退屈な作業をテスターは行わなくてよくなる。同じように、ページの視覚的な側面をAIにテストさせることもできる。
 しかしテストが失敗した場合に、その失敗が「良い」失敗なのかバグなのかをすべてチェックするのは退屈である。特に、一つの変更が多くのテスト失敗をもたらしている場合はなおさらだ。AIはその違い*3を、アプリケーションのユーザと同じように理解できる必要がある。つまりレベル2のAIは、意味的に同じ変化を理解することが可能なので、多くのページにおける変化をグルーピングすることができるようになるだろう。(画面の)変化をグルーピングし、変化が同一のものであれば人間にそれを教え、その変化を受け入れるか拒否するかをグループ単位で尋ねることができるのだ。

 要するに、レベル2のAIはベースラインに対して変化をチェックし、退屈な作業を一つのシンプルな作業にまとめるのを手伝ってくれるのだ。

レベル3: 条件付きの自動化

 レベル2においては、失敗したテストや、検出されたソフトウェアの変化をすべて、人間がしっかりと吟味する必要があった。レベル2のAIは変更を解析することができる一方で、ページを視ただけでそれが正しいかどうかを判断することはできない。比較するためのベースラインが必要である。しかしレベル3のAIはそれができるし、ページに対して機械学習の技術を適用することで、もっと多くのことができる。
 たとえば、レベル3のAIはページの視覚的な側面を調査し、アラインメントや余白、色使い、利用フォント、レイアウトなどのデザインの標準ルールに従っているかを判断することができる。

 では、データについてはどうか。レベル3のAIはデータをチェックし、あるフィールドについては特定の範囲に収まっていること、メールアドレスであること、上に並んだ数字の合計となっていることなどを判断することができる。ある特定のページにおいて、テーブルは指定された列でソートされていることを理解している。

 ここでAIは、人間のデザインとデータのルールを理解することによって、人間の仲介なしにページを評価することができる。ページに変化があっても、そのページに問題はなく、人間に確認してもらう必要がないと理解することが可能なのだ。AIシステムは数百のテスト結果をみて、どのように変化してきたかを知ることができる。機械学習の技術を応用することで、変化におけるアノマリーを検出することができるので、人間にはそのアノマリーについてのみ確認を依頼するのだ。

レベル4: 高度な自動化

 ここまでは、AIは自動的にチェックするだけだった。テストの駆動は未だに人間が行っており、(自動化のソフトウェアを使って)リンクをクリックしたりしている*4。レベル4ではAIがテスト自体を駆動する。

 レベル4のAIは、ページを視て人間と同じように理解できるので、ログインページを視たときに、プロフィール、登録、ショッピングカードのページと比べて、それを理解することができる。「ページは、相互作用のフローの一部である」と意味的に理解しているので、テストを駆動することができる。
 ログインや登録といったページが標準的なものであるのに対して、そうではないものもある。しかしレベル4のAIは、これまで視たことのなかったページであっても、ユーザの相互作用をずっと視ていて、それを可視化し、そのページとページを通したフローを理解できる。
 AIがいったんその種のページを理解すると、強化学習(機械学習の一種)などの技術を用いることで、自動的にテストの駆動を始めることができるようになる。テストをチェックするだけでなく、書くことができるようになるのだ。

レベル5: 完全な自動化

 レベル5は、今のところSFである。このレベルに至ると、AIはプロダクトマネージャーと会話し、アプリケーションを理解し、AI自身が完全にテストを駆動することができる。
 しかし、プロダクトマネージャーによるアプリケーションの説明を理解しているものがいなければ、レベル5は人間より賢くなければならない。

現在の最先端

 現状、高度なツールだとレベル1で、レベル2の機能性へと進歩しているところだ。ツールベンダーはレベル2に取り組んでいる。レベル3にはまだ努力が必要だが、可能と思われる。 レベル4のAIは遠い未来だろう。しかし次の10年かそこらで、重い副作用なしの、AIにアシストされたテストに出会うことになりそうだ。
 よって、ソフトウェアテストのすべてをコンピュータが自動化してしまうといって、別の仕事を探し始める必要はない。ソフトウェアテストはいくつかの点で運転と似ているが、人間の複雑な相互作用を理解しなくてはならない分、もっと複雑なのだ。今日のAIは、自身が何をしているかを理解していない。単に、大量の過去データに基づいてタスクを自動化しているだけである。

 あなたの仕事は「自動化すること」であり「自動化されること」ではない。テストチームとQAチームは、新しい働き方を促進するために、新しい自動化技術をさらに活用することができる。仕事が自動化されることで人が自由になって、どうテストし、どう品質を保証するかに集中できるようになれば、ビジネスのために価値を生み出すことでができるようになる。

所感

 この記事を読むと、機械学習の技術を利用したテストを、単純に「自動テスト」と呼ぶと混乱しそうだと感じます。「自動」の中でも特に「自律」であり、駆動にしろチェックにしろ、何をすべきかを人間が明示的に与える必要がないのが「自律」といえるでしょう。

 自律的なテストが進歩していくにあたって、以下の二つのことが気になりました。

 一つ目は、トレーニングデータの量です。
 レベル4では、初見のページであっても、ユーザの操作をずっと観察し続けることでフローを理解できるとしていますが、正確な判定には膨大なトレーニングデータが必要となるはずです。トレーニングのためのこの「ユーザの操作」データはどのように与えるのでしょうか。ページ操作を自動化し、かつ実行ごとに微小な変化・ランダム性を追加することで、大量データを準備するといった方法がある?

 二つ目は、欠陥検出に失敗した際のフィードバックです。
 機械学習の応用でよく指摘される問題として、「なぜそう判定したのかが人間に見えづらい」というものがありますよね。
 手動テストであれ、現在の(判定ロジックを人間が書いている)自動テストであれ、欠陥を見逃してしまった場合はその原因を分析し、以降のテストにフィードバックすることができます。一方、機械学習に基づく自律的なテストにおいて、それは可能なのでしょうか。なぜそれを見逃したかは、よくわからないままになってしまうのではないでしょうか。
 あるいはこういう発想自体がレガシーで、「特定の欠陥を見逃したことより、全体としての検出率が上がっていることが重要」という考え方になるのでしょうか。

 ともあれこの記事が言っているのは、「機械に任せられる部分をどんどん広げて、人間は考えることに力を入れよう」ということです。全般的に「心配するな!」という論調ではありますが、これは皮肉にも見えて、「AIに代替されそうなことばかりやってるとマズいよ」という話にも読めますね。

*1:訳注: 一度「正しい」と判断され、以降のテストにおける結果判定の基準となるものを指しています。

*2:訳注: executeやrunで表される「実行」とは少し違って、何をしなければならないかを自ら判断して動作することを指しているように思います。

*3:訳注: 妥当な失敗とそうでない失敗の違いを指しているものと思います。

*4:訳注: 人間が自動化ツールに明示的に指示している、という意味でしょう。

リバーシ(オセロ)を部分的に実装して、ソフトウェア開発関係者であることを証明する ー その2

 前の記事では、右方向の石置き可否判定を実装しました(Excel関数で)。
 今回は、上下左方向の石置き可否判定について考えていきましょう。

www.kzsuzuki.com

「逆方向」の難しさ

 右方向さえできれば、左方向も本質的には同じ、簡単に実装できそうです。
 しかしここで、Excelの暗黙の前提が効いてきます。Excel関数は基本的に「左から右に」「上から下に」が前提で、その逆を行おうとすると複雑さが増していくのです。

 たとえば、カンマで区切られた2つの単語 apple,orange を、左と右に分けることを考えてみましょう。
 左側は、カンマの位置をFINDで探して、そのすぐ左までをLEFTで切り取ります。

=LEFT(対象セル,FIND(";",対象セル)-1)

 一方右側は、FINDの位置を見つけて対象文字列の長さLENから引いたうえで、RIGHTで切り取ります。ひと手間増えていることがわかりますね。

=RIGHT(対象セル,LEN(対象セル)-FIND(";",対象セル))

 返し判定についても同じで、OFFSETMATCHを逆方向に使うと、一気に複雑になってしまうんですね*1
 ここで少し、発想の転換が必要になります。

盤面を回す

 ジョジョ、それは無理矢理方向を変えようとするからだよ。逆に考えるんだ、『方向は固定、盤面を回しちゃえばいいさ』と考えるんだ。
 ということで、盤面を時計回りに90度回転させます。たとえばセルC4の座標(4, 3)で、回転後は(3, 5)に移動します。一般化すると、座標(x, y)(y, 8-x+1)に移動するわけです。これで、右方向への判定を上方向(-90度方向)に適用することができます。

03

 同じように、180度・270度回転させれば、上下左右方向すべてについて、同じロジックで石置き可否判定ができるようになりますね*2。 これをORで結ぶことで、上下左右のいずれかで返せればTRUE、とすることができました*3
 こんなイメージになります。左から4つの盤面がそれぞれ右・上・左・下方向の判定で、一番右の判定は上下左右方向を合わせた判定です。

04

斜め方向の判定

 さて、次は斜め方向です。普通に考えて、Excel関数で斜め方向に何らかの処理を行うのは、難しさが一気に増しそうです。
 ジョジョ、それは斜めに判定しようとするからだよ。逆に考えるんだ、『盤面を斜めに回しちゃえばいいさ』と考えるんだ。
 ただ90度回転とは違い、斜め回転には少し工夫が入ります。結論を言うと、盤面を分割する必要があります。百聞は一見にしかず、要は、こう。

05

 この分割後の盤面について、最初のロジックで判定すればいいわけです。シンプルな解法ですよね。

力尽きる

 単に石を置けるかどうかだけでこんなに苦労してしまいました。もしかして、Excelワークシート関数で実装するという判断は誤っていたのでしょうか?

 あとはExcel職人の皆さんにお任せしたいと思います!
 それでは良い週末を!

*1:「下」については、右とほぼ同じに作れます。

*2:前記事の条件1でISBLANKを使うと、回転後のセルが空白ではないため、石のないセルでも判定がFALSEになってしまいます。

*3:ORの中にエラーがあると全体がエラーになるので、ISERRORで0にしています。

リバーシ(オセロ)を部分的に実装して、ソフトウェア開発関係者であることを証明する ー その1

 ソフトウェアエンジニアならリバーシ(いわゆる、オセロ)の実装くらいできるだろう、というのが話題になっていたので、やってみることにしました。

 8×8マスの情報を保持するための「配列」、マスの状態を一つ一つ見ていく「繰り返し」、石をおける/おけない、返る返らないの「判定」など、プログラミングの基本概念を知っていれば、実装できそうです。
 では、わたしのような者にとって、ここで選ぶべき「言語」は何でしょう。

 そうです、Microsoft Excelですね。
 あ、いいえ、VBAではありません、Excelワークシート関数です。
 何しろワークシートを方眼紙状にすることで、盤面を即、表現できますから。

 といっても、全部やるほどの週末はないので、「そのセルに黒石をおけるかを判定する」部分を作ってみました。

自然言語で表現する

 あるマスに黒石をおくためには、そのマスの上下左右、斜めの計8方向のいずれかについて、以下の条件を満たしていることが必要です。

  1. 対象の位置に、石がない。
  2. 対象の方向に、黒石がある。
  3. 一番近い黒石との間がすべて白石である。

Excel関数で表現する

前提

 白石を「1」、黒石を「10」で表現します。Excelなら条件付き書式が使えるので、色も変えられますね! 薄い青は、石が置かれていないマスを表現しています。

01

条件1

 これは簡単です。たとえばセルD5であれば、

D5=""

で判定します。いやいやそこはISBLANK関数だろ?と思う方もいると思いますが、ISBLANKを使うと後で詰みます。

条件2

 たとえば右方向に「10」があるかどうかを判定するには、MATCH関数を使えばいいですね。 セルD5について判定するには、

=MATCH(10,E5:$J5,0)

とします。対象セルとすぐ右から一番右端までをチェックしています。第3引数を「0」にしておくと、一番最初に見つけた(つまり一番近い)位置を返してくれます。

条件3

 セルのすぐ右隣のセルと、条件1のMATCH関数で得たセルの間が、すべて白であることを確認します。そのために使うのは、OFFSET関数とSUM関数です。

=SUM(OFFSET(D5,0,1,1,MATCH(10,E5:$J5,0)-1))

 OFFSET関数は、基準となるセルから、第2・第3引数で起点を決め、第4・第5引数で高さと幅を決めることで、領域を指定することができます。わかりづらいですが、ここでは「対象セルのすぐ右のセルから、一番近い黒石のすぐ左のセルまでの領域」を指定しています。これはつまり、「黒と黒で囲まれた領域」ですよね。その領域がすべて白(「1」で表現される)であれば、領域の数字のSUMは、領域のセル数に一致するはずです。3マスなら、3。

 つまり以下のような判定がTRUEであれば、黒と黒にはさまれた領域はすべて白です。

SUM(OFFSET(D5,0,1,1,MATCH(10,E5:$J5,0)-1))=1*(MATCH(10,E5:$J5,0)-1

 なお、黒を「0」や「-1」にしていないのは、この「一致」の判定でしくるだろうなと思ったためです。

判定

 条件1~3をANDで結ぶだけですね。

=AND(
D5="",
MATCH(10,E5:$J5,0),
SUM(OFFSET(D5,0,1,1,MATCH(10,E5:$J5,0)-1))=1*(MATCH(10,E5:$J5,0)-1)
)

 とてもシンプルに表現することができました。

右方向を判定した盤面

 先の結果を、判定用の盤面全64マスに適用します。
 元の盤面は、判定用盤面の対応位置の判定が「TRUE」であれば、黄色に塗ることにしましょう。こんな感じになります。

02

 まだ「右方向」しか判定できないので、ちょっとさみしいですね。
 次回は、「上下左方向」をどう実装していくか見ていきましょう。

データサイエンスが今もなおセクシーだと感じるビッグデータの使い方

 2007年の米国で大規模な景気後退が始まったとき、ストレスにさらされた大人たちによる、児童への虐待が増加するのではないかと危ぶまれました。しかし公式データによると、虐待保護件数はむしろ減少。特に、不景気の影響が大きい州ほど減少の幅が大きかったそうです。
 そんなことがあるのだろうか・・・? 景気後退に伴い、本来報告を行う人が手一杯だったり、失業していたりしていただけではないか。
 Googleの検索データを調べると、「ママがぼくをぶつ」「パパに殴られた」という検索の件数は、景気後退の間に跳ね上がり、失業率データを一致していたというのです。

誰もが嘘をついている ビッグデータ分析が暴く人間のヤバい本性

誰もが嘘をついている ビッグデータ分析が暴く人間のヤバい本性

人々が情報を求める検索は、それ自体が情報なのである。人々が何かの事実、発言、ジョーク、場所、人物、物事、あるいはヘルプについて検索するとき、それは彼らの本当の考え、望み、あるいは恐れについてどんな推測より正確に明かすものとなる。

 本書はこのような事例をふんだんに盛り込んだものです。
 著者は、検索エンジンを「デジタル自白剤」と呼び、伝統的な調査では得られない質・量のビッグデータから、これまで読み取ることのできなかった知見が得られるとしています。

 たとえば2015年にアメリカで起きた、銃乱射事件。数日後のオバマ大統領が受容と寛容を説いた演説の裏で、「イスラム教徒」とともに複合検索されていた言葉は、演説の内容とは正反対のものだったそう。成功と言われたこの演説が、現実には逆効果をもたらしていた可能性が、データ分析からわかっています。

 個人的な感覚では、「データサイエンティストってセクシー!」って言われまくった数年後の今、みんなが機械学習の話をしている感があるのですが、「たくさんのデータ」を相手にするのにデータサイエンスはやはり強力、ということをあらためて思い知らされます。

 ちなみにこちらは、著者が検索データをビッグデータとして扱うきっかけとなった、Googleトレンド。「big data」と「deep learning」の検索の趨勢を比較してみました。

 ビッグデータを用いた斬新な分析に続き、後半では、ビッグデータの限界や、従来の分析との組み合わせ、そして「やってはいけないこと」について言及しています。「やってはいけないこと」は、機械学習の文脈でも似たような話が出てきますね。たとえば「人の趣味や言葉遣いなどのデータを用いて、人材採用や犯罪予測の手がかりにすることは正しいのか」といったものです。

 なお今「後半」と書きましたが、わたしはこの本を最後まで読みました。そのモチベーションは、目次に目を通したときに見てしまった、「ここまで読み通してきた人は何人?」という最終章のタイトルです。こんな皮肉を言われてしまったら、読むしかないでしょう。
 本書最後の文章も、とってもひねくれたものでした。みなさんもぜひ、「ここまで読み通して来た人」になりましょう。ちなみに著者らによると、トマ・ピケティの『21世紀の資本』を読了した人は3%未満、だそうです。読み始めただけでもえらいと思うけれど!

少しばかりの統計学の技術と山ほどの好奇心を持ち合わせているなら、データ分析の世界に足を踏み入れてほしい。

データサイエンティスト養成読本 登竜門編 (Software Design plus)

データサイエンティスト養成読本 登竜門編 (Software Design plus)

  • 作者: 高橋淳一,野村嗣,西村隆宏,水上ひろき,林田賢二,森清貴,越水直人,露崎博之,早川敦士,牧允皓,黒柳敬一
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/03/25
  • メディア: 大型本
  • この商品を含むブログを見る

 こちらは何だか不思議な本で、確かにデータサイエンティストになるために必要な素養を広く紹介してくれてはいるのですが、とても基本的なLinuxコマンドやExcel関数(!)にまで踏み込んだ記述があって、「とりあえず手を動かすために必要な知識を全部ぶっこみました」という感じがとても好きです。