[翻訳] 機械学習のルール（１）概要～フェーズⅠ
原文
Martin Zinkevich氏の記事より
用語集
- Instance（インスタンス）：あなたが予測を行いたいモノ。インスタンスの例としては、「猫に関係している」または「猫に関係していない」を判定するWebページ
- Label（ラベル）：予測タスクからの回答。MLシステムから生成された回答または、学習データに付与されている正しい回答のいずれか。例えば、Webページ（インスタンス）に対するラベルは「猫に関係している」
- Feature（特徴量）：予測タスクを行う際に使用されるインスタンスの性質。例えば、「Webページが”猫”という単語を含んでいる」など
- Feature Column（）：関係する特徴量のセット。例えばユーザーが住んでいる可能性があるすべての国名など。feature columnには1つ以上のfeatureを含む可能性があります。この用語はGoogle特有の用語であり、"namespace"や"field"とVWシステム（Yahoo・Microsoft）では呼ばれます
- Example（例）：特徴量を含むインスタンスとラベル
- Model（モデル）：予測タスクの統計的表現。あなたはモデルを例を通して学習させ、予測を行うためにそのモデルを使用します
- Metric（指標）：あなたが注目する数値。直接的に最適化される場合もあれば、そうでない場合もある
- Objective（目的変数）：機械学習アルゴリズムが最適化する指標
- Pipeline（パイプライン）：機械学習アルゴリズムにまつわるインフラストラクチャ（基盤）。フロントエンドからのデータ収集、学習データファイルへの変換、モデルの学習、稼働システムへのモデルのエクスポートなどを含む
- Click-through Rate（クリック率）：Webページの訪問者のうち、広告をクリックした割合
概要
優れたプロダクトを作るためには、優秀な機械学習のエキスパートのようにではなく、優秀なエンジニアのように機械学習を用います。
直面する問題のほとんどは、実際にはエンジニアリングの問題です。優秀な機械学習のエキスパートのリソースを投入しても、機械学習から得られるメリットのほとんどは、優れたアルゴリズムではなく、優れた特徴量から得られます。したがって、基本的なアプローチは、
- パイプラインが最初から最後まで信頼性があることを確認する
- reasonableなobjectiveから始める
- 常識的な特徴量をシンプルな方法で追加する
- パイプラインが依然として信頼性があることを確認する
このアプローチは長期にわたってうまく機能します。さらに先に進むために、簡単なトリックが存在しない場合のみ、このアプローチから逸脱してください。複雑さを追加すると、将来的なリリースが遅くなります。
もしあなたが簡単なトリックを使い果たしてしまったら、最先端の機械学習のアプローチがあなたの未来を切り開くかもしれません。その場合、フェーズⅢの機械学習のセクションをご覧ください。
この記事は以下のように構成されています。
- 最初のパートは、機械学習システムを構築するのに適切な時期であるかどうかを把握するのに役立ちます
- 2つ目のパートは、最初のパイプラインのデプロイに関してです
- 3つめのパートは、パイプラインに新しい特徴量を追加しながらローンチとイテレーションを回すこと、モデルとtraining/serving skew（モデルの訓練時と推論時の環境の差異に起因して、モデルが不都合な振る舞いをしてしまうこと）の評価を行う方法についてです
- 最後のパートは、プラトー（高原状態）に達したときに何をすべきかについてです
- その後に、関連する作業リストと、このドキュメントでよく使用される事例の背景についてのAppendixがあります
機械学習の前に
ルール1：”機械学習ナシ”のプロダクトをローンチするのを恐れるな
機械学習はCoolですが、データが必要です。理論的にはデータ取得は別問題として、新プロダクトをローンチし、後からモデルを微調整することはできますが、これは基本的なヒューリスティクスを下回ることがあります。もしあなたが機械学習によって100%のブーストがかけられると考えるなら、ヒューリスティクによって50%獲得することができるでしょう。
例えばアプリのマーケットプレイスにて、アプリのランク付けをする場合、ヒューリスティックとしてインストール率やインストール数を使用することができます。スパム検出の場合には、ヒューリスティックとして以前にスパムを送信したことがある発行元を除外することができます。人間による編集も恐れずに使いましょう。連絡先をランキングする場合、最近使用したものを最も高くランク付けするでもよいでしょう（または、アルファベット順にランク付けします）。もしプロダクトに機械学習が必ずしも必要でない場合、データが得られるまで機械学習は使わないでください。
ルール2：まず、Metric（指標）をデザインし実装しろ
機械学習システムが何をするかを決める前に、現在のシステムを可能な限り追跡調査しましょう。これは以下の理由からです。
- 早い段階の方がシステムのユーザーから（指標の実装の）許可を得るのが簡単だから
- もしあなたが将来それがどうなるか気になることがあるならば、それの過去データを今取得するのがよいから
- 指標の実装を念頭においてシステムをデザインすると、将来ものごとがうまく運びます。ログの文字列をgrepして指標を確認するようなことはしたくないでしょう！
- あなたは現行システムの何が変わり、何が変わらないかを認識することができるでしょう。例えばあなたは、1日のアクティブユーザーを直接的に最適化したいとします。しかしながら、システムの初期の段階では、ユーザーエクスペリエンスの劇的な変更を行っても、この指標が大きく変わることはないことに気づくでしょう
Google Plusのチームは、read毎のexpand（記事の展開）、read毎のreshare（再共有）、read毎のplusone（プラスワン≒いいね）、コメント数、ユーザー毎のコメント数、ユーザー毎のreshare（再共有）などを測定します。それらにより、サービス提供時における投稿の"良さ"を計算します。また、ユーザーをグループに分割し、実験結果の統計値を集計できるような、実験のフレームワークも有効です。（ルール12）
より様々なmetric（指標）を収集することで、あなたのシステムの全体像をより幅広く把握できます。問題に気づいたら？それを追跡調査できる指標を追加しましょう！前回のリリースでの定量的な変化に興奮しましたか？それを追跡調査するための指標を追加しましょう！
シンプルなヒューリスティクスはプロダクトを送り出すことができますが、複雑なヒューリスティクスはメンテナンスができません。もしデータを持っていて、あなたが達成しようとしている基本的なアイディアが掴めたら、機械学習に進みましょう。ほとんどのソフトウェアエンジニアリングタスクと同様に、ヒューリスティクだろうが機械学習モデルだろうが、コンスタントにあなたのアプローチを更新することが必要です。そして、機械学習モデルは更新とメンテナンスが簡単であることに気づくでしょう。（ルール16）
機械学習フェーズⅠ：最初のパイプライン
あなたの最初のパイプラインにおけるsystem infrastructureに焦点を合わせます。これからつくる機械学習について想像を膨らませることは楽しいことですが、あなたの最初に作るパイプラインが信頼できないと、何が起きているのかわからなくなってしまいます。
ルール4：最初のモデルはシンプルにとどめ、infrastructureを適切に作れ
最初のモデルはあなたのプロダクトに最も大きなブーストを与えるので、凝ったものにする必要はありません。しかし、あなたが予想するよりはるかに多くのinfrastructureの問題が発生します。誰もがあなたの素晴らしい機械学習システムを利用できるようになる前に、あなたは以下のことを決定する必要があります。
- どのようにexample（例、学習アルゴリズムに与える形式のデータ）を取得するか
- A first cut as to what "good" and "bad" mean to your system.
- モデルをアプリケーションに統合するための方法。モデルをライブで適用するか、もしくはオフラインでモデルで処理した結果をテーブルに保存するといったことができます。例えば、Webページは事前に分類した結果をテーブルに保存しておけますが、チャットメッセージなどはライブで分類を行いたいといったことがあります。
シンプルな特徴量を用いることで、以下のことを確かめることが容易になります
- 特徴量が学習アルゴリズムで正しく機能していること
- モデルが妥当なウェイトを学習していること
- The features reach your model in the server correctly.
これら3つを確実に実行できるシステムができたら、あなたの作業はほとんど完了したようなものです。このシンプルなモデルは、より複雑なモデルをテストするためのベースラインとなるmetric（指標）と振舞いを提供します。”ニュートラルな”スタートを狙っているチームもあります。つまり、機械学習によるメリットを意図的に下げて、本質的なメリットから気が逸れないようにするということです。
ルール5：機械学習とは別にinfrastructureをテストせよ
infrastructureがテスト可能であること、およびシステムの学習部分がカプセル化され、その周辺の全ての機能がテストできるようになっていることを確認してください。特に、
- アルゴリズムへデータを提供する機能をテストします。入力されるべき特徴量が入力されていることを確認します。プライバシーが許されるなら、学習アルゴリズムへのインプットを手動で確認します。可能なら、別の場所で得られたデータからの統計値と、パイプライン内のデータの統計値を比較して確認します。
- 学習アルゴリズムからモデルを提供する機能をテストします。学習環境のモデルが、本番環境のモデルと同じスコアを与えることを確認します（ルール37）
機械学習には予測不能な要素があるため、学習用/本番用の例を作成する部分をテストすることと、稼働環境で学習環境と同じのモデルを使用できることを確認してください。また、データを理解することも重要です。大規模で複雑なデータセットの分析に関する実用的なアドバイスを参考にしてください。
ルール6：パイプラインのコピーの際、dropされるデータに気をつけろ
多くの場合、既存のパイプラインをコピーしてパイプラインを作成します（例：カーゴ・カルト・プログラミング）。過去のパイプラインは、新たに作成するパイプラインに必要なデータをdropしてしまうことがあります。例えば、"Google Plus What's Hot"のパイプラインは、古い投稿を削除します（新しい投稿をランク付けしようとしているため）。このパイプラインは、Google Plus Streamで使用するためにコピーされました。その場合には古い投稿には意味がありましたが、そのパイプラインは古い投稿を削除していました。
ルール7：ヒューリスティクスを特徴量に変換せよ、またはそれを外部で処理せよ
たいていの場合、機械学習が解決しようとしている問題は全く新しいものではありません。ランキング、分類、その他あなたが解決しようとしている問題には既存のシステムがあるでしょう。すなわち、そこには多数のルールやヒューリスティックがあるということです。この同じヒューリスティックは、機械学習に適用した場合にも同様に効果を発揮することができる可能性があります。
ヒューリスティックは、２つの理由から、どんな情報であっても、マイニングする必要があります。1つ目は、機械学習を適用したシステムへの移行がスムーズになるからです。2つ目は、たいていの場合ルールには、あなたが放棄したくないと考えるであろうシステムに関する多くの直感が含まれているからです。既存のヒューリスティックを使用するのに、4つの方法があります。
- ヒューリスティックを前処理に使用します。特徴量が極めて優れている場合には、これ一択です。例えば、スパムフィルタにおいて、送信者がすでにブラックリストに載っているなら、メッセージをブロックしてください。このアプローチは二値分類タスクでとても理にかなっています。
- 特徴量を作成します。ヒューリスティクから特徴量を直接作るのは非常に良いことです。例えば、あなたがヒューリスティックを使用して問い合わせに対する関連性スコアを計算している場合、そのスコアを特徴量として含めることができるでしょう。のちにあなたは、機械学習のテクニックを使用してその値を調整したいと思うかもしれません（例えば、その値を離散化したり、他の特徴量と組み合わせたりするなど）。しかし、まずはヒューリスティックにて得られる生の値を使用してください。
- ヒューリスティックに対する生データをマイニングする。例えば、インストール数/テキスト内の文字数/曜日を組み合わせたヒューリスティックがある場合、まずはこれらを分解して、個別に機械学習に提供するようにしてください。アンサンブルに適用されるいくつかのテクニックがここでも使用できます（ルール40）
- ラベルを書き換える。これは、ヒューリスティックが現在のラベルに含まれていない情報を捉えていると思われる場合における選択肢です。たとえば、あなたがダウンロード数を最大化しようとしているが、quality contentも必要な場合、おそらく解決策は、ラベルにアプリの平均の星の数を掛けることです。これについては様々な自由度があります。"Your First Objective"を参照してください。
機械学習システムでヒューリスティックを使用する場合、複雑さが増すことに注意してください。新しく作る機械学習アルゴリズムで過去のヒューリスティックを使用すると、スムーズな移行に役立ちますが、よりシンプルな方法で同じ効果が得られる可能性も検討してください。
モニタリング
アクションにつながるアラートを出力したり、ダッシュボードページを作るなどにより、適切な監視状態を構築してください。
ルール8：あなたのシステムのfreshness requirements（鮮度要件）を知る
作成後1日経過したモデルは、パフォーマンスがどの程度低下しますか？1週間ならば？3カ月ならば？この情報は、モニタリングの重要性を理解することに役立ちます。もしモデルを1日更新しないと製品の品質が大幅に低下してしまう場合、エンジニアに継続的に監視してもらうほうが良いでしょう。ほとんどの広告配信システムには、毎日処理する新しい広告があり、毎日更新する必要があります。例えば、Google Play検索のMLモデルが更新されない場合、1か月以内に悪影響が発生する可能性があります。Google PlusのWhat's Hotのモデルのいくつかには、post identifier（投稿ID）がないため、頻繁にモデルを更新することができないでしょう。一方、post identifier（投稿ID）を持つモデルは、はるかに頻繁に更新されます。また、特に特徴量列がモデルに新たに追加された/削除された場合などを含め、鮮度要件も時間とともに変化していく可能性があることに注意してください。
ルール9：モデルをエクスポートする前に問題を検知する
多くの機械学習システムは本番環境に向けたモデルをエクスポートする段階があります。もしそのエクスポートされたモデルに問題があれば、それはユーザーが問題に直面することになります。
モデルをエクスポートする直前に、モデルが健全化どうかをチェックします。具体的には、hold-outされたデータに対するモデルのパフォーマンスが妥当であることを確認してください。また、もしデータに対し、lingering concernsがある場合には、モデルをエクスポートしないでください。モデルを継続的にデプロイしている多くのチームは、エクスポートする前にROC曲線（またはAUC）をチェックしています。エクスポートされていないモデルによる問題に対してはメールアラートが必要ですが、ユーザー向けモデルにおける問題ではページ（Webページ？）が必要になる場合があります。したがって、ユーザーに影響を与える前に、待って確認をすることをおすすめします。
ルール10：silent failure（無音の失敗）に気をつけろ
これは特に他のシステムよりも機械学習システムにおいて発生する問題です。結合される特定のテーブルのデータが更新されなくなったとします。機械学習システムはそれにアジャストし、パフォーマンスは適度に良く、徐々に減退していきます。時に、テーブルが1週間更新されていないことに気づき、単純にテーブルを更新するだけで、他のどんなモデル更新よりもパフォーマンスが向上する、といったことがあります。implementation changesにより特徴量のカバー率が変化することがあります。例えば、a feature column could be populated in 90% of the examples, and suddenly drop to 60% of the examples. Google Playは過去に一度、6カ月前のテーブルを使用していたことがあり、そのテーブルをリフレッシュするだけで2%インストール率が向上したといったことがありました。もしデータの統計量をトラックしていれば、もしくは時々手作業でデータをチェックしていれば、こういった失敗を減らすことができたでしょう。
ルール11：特徴量カラムにオーナーとドキュメントを付けよ
もしシステムが大きく、たくさんの特徴量カラムを含むとき、各カラムを誰が作成しメンテナンスしているかを把握しておきましょう。もし特徴量カラムについて知っている人がいなくなっていることに気づいたら、だれか他の把握している人を確認しましょう。特徴量カラムが分かりやすい名前を持っていたとしても、その特徴量が何なのかの詳細な説明、どこから来たか、どのように働くと期待されるかについての詳細な説明（ドキュメント）を持っておくとよいでしょう。
最初の目的変数
あなたは、システムに関する注視すべきたくさんの指標（metric）や計測値を持っているでしょう。しかし、機械学習アルゴリズムはたった一つの目的変数（objective、アルゴリズムが最大化しようとする数値）を必要とします。私は目的変数（objective）と指標（metric）を区別しています。指標（metric）はシステムがレポーティングする数値であり、重要であるものもあればそうでないものもあります。ルール2も見てください。
ルール12：直接最適化する目的変数を考えすぎない
あなたはお金を稼ぎたい、ユーザーをハッピーにしたい、もしくは世界をより良くしたいと思っているでしょう。気になる指標はたくさんあるでしょうし、それらを全て測定する必要があります（ルール2）。しかし、機械学習プロセスの早い段階においては、直接的に最適化されていないものも含め、全ての指標が改善していることに気づくでしょう。例えば、クリック数とサイト滞在時間に関心があるとします。クリック数を最適化すると、サイト滞在時間も増える可能性があります。したがって、全ての指標を容易に改善できるような場合は、シンプルに考え、あまりさまざまな指標のバランスをとることをについて考えすぎないでください。ただし、このルールを行き過ぎないでください。目的変数とシステムの究極の健全性を混同しないようにしましょう（ルール39）。そして、もし最適化した指標を改善できてもローンチできないという判断になった場合、目的変数の修正が必要かもしれません。
ルール13：最初のObjectiveとして、シンプル、観測可能でattributableな指標を選択する
真の目的変数が分からないことはしばしばあります。機械学習の目的変数は、測定することが容易であり、”真の”目的変数の代替（proxy）である必要があります。実際には、”真の”目的変数は存在しません（ルール39参照）。従って、シンプルな機械学習の目的変数を使用して学習し、後から追加のロジック（できれば非常にシンプルなロジック）を加えられる”ポリシーレイヤー”を配置することを検討してください。
モデル化するのが最も簡単なのは、システム内における、直接的に観察されたユーザーの振る舞いです。
- このリンクはクリックされたか
- このオブジェクトはダウンロードされたか
- このオブジェクトは転送/返信/メール送信されたか
- このオブジェクトは評価されたか
- このオブジェクトはスパム/ポルノ/攻撃的とマークされたか
最初は間接的な効果のモデリングは避けてください。例えば：
- ユーザーから翌日訪問があったか
- ユーザーはどのくらいの間サイトに滞在したか
- 日次アクティブユーザーはどの程度か
間接的な効果はとてもよい指標となり、ABテストやローンチ判断の際に役立ちます。
最後に、機械学習には次のようなことfigure outさせようとしないでください。
- ユーザーは製品を満足して使用しているか
- ユーザーは体験に満足しているか
- 製品はユーザーの全体としての健康状態を改善しているか
- その仕組みは会社全体の健康にどのように影響するか
これらは非常に重要ですが、計測することは極めて困難です。その代わり、代替（proxy）を使用してください。例えば、もしユーザーが満足していれば、彼らはサイトに長く滞在するでしょう。もしユーザーが体験に満足したら、彼らは翌日も訪問してくれるでしょう。幸福と会社の健康に関係する限り、機械学習の目的変数と、販売しようとしている製品の性質や事業計画とを結び付けるには、人間の判断が必要になるでしょう。
ルール14：解釈可能なモデルから始めることで、デバッグが容易になる
線形回帰、ロジスティック回帰、ポワソン回帰は、確率モデルによって直接motivateされます。各予測は、確率または期待値として解釈できます。その結果、分類精度やランク付けのパフォーマンスを直接最適化しようとする目的変数（0-1損失やさまざまなヒンジ損失）を用いるよりもデバッグが容易になります。例えば、予測された確率が学習時の確率から大きく逸脱していた場合、そのことによって問題があきらかになる可能性があります。
たとえば、線形、ロジスティック、ポワソン回帰の場合、there are subsets of the data where the average predicted expectation equals the average label (1- moment calibrated, or just calibrated). This is true assuming that you have no regularization and that your algorithm has converged, and it is approximately true in general. If you have a feature which is either 1 or 0 for each example, then the set of 3 examples where that feature is 1 is calibrated. Also, if you have a feature that is 1 for every example, then the set of all examples is calibrated.
シンプルなモデルの場合、フィードバックループを回すのが容易です。多くの場合、確率的予測を使用して私たちは判断します：期待値の降順で投稿をランク付けするなど。しかし、使用するモデルの選択の場面では、モデルから与えられるデータよりも意思決定が重要であることを忘れないでください。
ルール15：Policy Layerでスパムフィルタリングとクオリティランキングを切り分ける
クオリティランキング（質の高いもののランキング）はファインアート（芸術的価値を追求するもの）ですが、スパムフィルタリングは戦いです。高品質な投稿を判別するために使用するシグナルは、システムのユーザーにより明らかにされ、そういった高品質な投稿の性質を持たせるように彼らの投稿は調整されていきます。したがって、クオリティランキングは、誠意のある投稿コンテンツをランキングすることに焦点を当てる必要があります。スパムを上位にランキングさせるようなクオリティランキングを軽視してはなりません。
扇情的なコンテンツはクオリティランキングとは別に対処する必要があります。スパムフィルタリングは別の問題なのです。あなたが生成すべき特徴量は常に変化していくと想定する必要があります。
たいていの場合には、システムに適用できる明白なルールがあります（スパム報告が3件以上ある投稿は表示しない、など） Any learned model will have to be updated daily, if not faster. The reputation of the creator of the content will play a great role.
あるレベルにおいて、これら２つのシステムの出力を統合する必要があります。検索におけるスパムフィルタリングは、Eメールのスパムフィルタリングよりaggressiveであることに注意してください。 This is true assuming that you have no regularization and that your algorithm has converged. これはおそらく一般的に事実です。また、クオリティの予測器に与える学習データからスパムを除外するのが標準的なプラクティスです。
フェーズⅡ以降は（２）に分け、別途記述します。
［翻訳］ Googleでのアナリティクス：データドリブンな意思決定の事例
原文
イントロ
Googleは、ファクトに基づく意思決定がDNAであり、Googler（Googleの従業員）は彼らの文化の一部としてlanguage of dataを話します。Googleでは全ての意思決定がデータ、アナリティクス、そして科学的実験に基づきなされることを目指しています。
Googleについて
Googleは多国籍のインターネットとソフトウェアの会社であり、インターネット検索、クラウドコンピューティング、広告を得意としたカリフォルニアマウンテンビューに本社を置く会社です。Googleのミッションは世界の情報をオーガナイズし、ユニバーサルにアクセス可能で便利にすることです。そしてこのミッションにより、彼らは非常に真剣に意思決定に向けて情報を提示することに取り組んでいます。
意思決定に向けた情報のためのデータ
企業においてデータは最も重要な問いに答えるために収集されるべきであり、あなたが答えるべき問いが明確でない限り、データは全く無用なものです（より詳しくは私のKey Performance Questionに関する記事を読んでください）。今日、Googleではまず問いから始めて、最初に必要な情報について非常にクリアにすることを目指します。CEOのEric Schmidtは言います。「我々は問いで会社を動かしている、答えではなく。したがって戦略プロセスにおいて、我々は自分たちが答えるべき30の問いを定義した。（中略）それを問いとして尋ねます、くだらない答えとしてではなく。それにより刺激され会話が生まれます。会話からイノベーションが生まれます。イノベーションはある日起きたら”イノベーションを起こしたい”と思い立つようなものではありません。問いとして尋ねることでイノベーションの文化が出来上がってくるものだと思います。」Googleがこの考え方を適用したたくさんの素晴らしい事例がありますが、人事部門の良い事例を見てみましょう。
Googleでのファクトベース意思決定
グローバルのHRファンクションにて、人事に関する意思決定をデータに基づき判断することを支援するPeople Analytics Departmentを設立しました。Googleが答えを出したかった１つの問いは、「マネージャーは実際に重要か？」ということでした。これはGoogleが最初から取り組んできた問いであり、創設者はマネージャーの貢献に疑問を投げかけていました。ある時には、すべてのマネージャーを廃止し、全員を個別の貢献者と位置付けましたが、あまりうまくいかずマネージャーは元に戻されたことがありました。
Project Oxygen
People analytics departmentの中でGoogleはinformation Labという、社会科学の研究者で構成されるグループを作り、グーグルの組織の実践を変革するような革新的な研究（問い）を中長期的に取り組む組織を立ち上げました。このチームはProject Oxygenというコードネームで呼ばれる「マネージャーは重要か」という問いに答えるためのプロジェクトに取り組みました。そして目的と必要な情報は明確に定義されました。
どんなデータを使うか？
チームはまず既存のデータに目を向けました。それは（マネージャーに対する上司からの）パフォーマンスレビューと、（メンバーからのレビューである）エンプロイーサーベイでした。チームはこのデータをグラフにプロットすることで、マネージャーは全般的には良いと認識されているということを明らかにしました。データは十分なばらつきを示していなかったので、チームはデータを上位/下位の四分位範囲に分割しました。
分析
回帰分析を行うことで、チームは、チーム生産性、従業員の幸福度、および従業員の離職率に関して、これら2つのグループの間に大きな違いを示すことができました。簡単に言えば、良いマネージャーの元のチームはパフォーマンスが高く、幸福度が高く、離職率が高かったのです。この結果は良いマネージャーは実際に違いを生むということを明らかにしましたが、そのデータでGoogleがアクションを取れるわけではありませんでした。次の彼らが答えるべき問いは、「Googleにおいて何が良いマネージャーを作るか」ということでした。この問いに答えることはより一層有用な示唆を提供するはずです。
新しいデータの収集
チームは2つの新しいデータの収集を行いました。一つは”Great Managers Award"という、従業員が特に良いマネージャーだと思う人をノミネートするものです。ノミネートの際には従業員は良いマネージャーだと感じる行動の例を提供する必要があります。2つ目のデータは上位/下位の四分位範囲のマネージャーに対する、彼らがどのような行動をとっているかについてのインタビューです（マネージャーはどちらの四分位範囲に自分が入っているかは知りません）。インタビューとGreat Manager Awardからのデータはテキスト分析がなされました。この分析によりチームは８つの良いマネージャーの行動と、３つのうまくいかないマネージャーの行動を明らかにしました。もしあなたがこれらについて知りたいならば8 Behavious that make a Great Manager at Google – and 3 that don’tを読んでください。
示唆を活用する
Googleはこの調査結果を新任マネージャーに対するコミュニケーションを含め、関係する人に対し様々な方法でシェアしました。しかし単に示唆をシェアするだけでは十分ではありませんでした。Googleは示唆を基に行動する必要性を感じていたのです。この分析に基づく多くの具体的な行動がありました。以下はいくつかの重要な例です。
- Googleはこれらの行動に関して測定を始めました。そのために年2回のフィードバック調査を開始しました
- GoogleはGreat Manager Awardを継続することを決めました
- Googleはマネジメントトレーニングを改訂しました
Intelligent Company
Googleは、いかに良い意思決定が良いデータとファクトにサポートされるかの良い事例です。Googleは私が書籍"The Intelligent Company: Five steps to success with Evidence-based Management"の中で書いている5つのステップに明確に従っています。
- 目的と必要な情報について定義する
- 適切なデータを収集する
- データを分析しインサイトに転換する
- 情報を展開する
- evidence-basedな意思決定を行う
[翻訳] 機械学習の問題構造化入門
原典
キーワード
- Problem (for machine learning) : (機械学習で取り組むべき）問題
- Problem Framing: 問題の構造化
- Goal: MLモデルの活用により目指す姿
- Outcome: 成果
- Success / Failure Metrics : 成果の定量指標と、成功/失敗と判断するための閾値
- Output: 出力
- Example Output: MLモデルに学習させる例としてのOutput
- pseudocode：模擬的なソースコード
- Objective: 目的変数
以下のセクションでは、機械学習（ML）で取り組むべき問題を構造化する前に考えるべきいくつかのことを整理します。
明白かつシンプルにスタートする
MLモデルに何をしてもらいたいか、簡単な表現で書いてください。
例：MLモデルに、アップロードされたばかりの動画がどれだけ人気になりそうかを予測してもらいたい
この時点では、文章は定性的で構いません。しかし、間接的なゴールではなく、直接的なゴールを捉えていることに気を付けてください。
理想のOutcome（成果）は何ですか？
あなたのMLモデルを、システムに追加することで、望ましいOutcome（成果）が生み出されるはずです。このOutcome（成果）は、モデルの質の評価指標とは異なります。
例：Transcoding（トランスコーディング）
私たちの理想的なOutcome（成果）は、人気ではない動画をトランスコーディングするリソースを削減することです。
※ トランスコーディングとは、ユーザーがアップロードしたコンテンツをYouTubeで表示する上でより効率的なフォーマットに変換することです。1/3以上のYoutubeにアップロードされた動画が、10回未満しか再生されません。もし、そういった動画を特定し、それらに対しては低解像度の動画だけを用意するといったことができれば、多くのリソースを節約することができます。
例：動画レコメンド
私たちの理想的なOutcome（成果）は、ユーザーにとって役に立つ/面白い/見るに値する動画を提案することです。
→どちらの例も、”アップロードされた動画がどれだけ人気になりそうか”を予測するMLモデルのOutcome（成果）になり得る
★ポイント：私たちは、同じMLモデルからの予測値を異なる使い方をすることで、異なるOutcome（成果）を得ることができます。そのため、私たちはプロダクト（MLモデル）に関し、どのようなことが大事なのかについて定義するOutcome（成果）を確認しておくことが必要なのです。
プロダクト（MLモデル）において、これまでよく追及されるようなメトリックに囚われず、その外側にある、あなたのプロダクト/サービスのより大きな目的に照準を当ててください。
Success/Failure Metrics（成功/失敗の判断基準）
定量化しましょう！
あなたのシステムが成功である/失敗であるとどのように判断しますか？
成功/失敗の判断基準は、precision/recall/AUCなどのモデル評価指標とは別に記述する必要があります。代わりに、予想されるOutcome（成果）で記述してください。
例：トランスコーディング
Success Metric（成功の判断基準）はCPUリソース使用率です。成功はトランスコーディングにかかるCPUコストを35%まで減らすことを意味し、Failure Metric（失敗の判断基準）はCPUコスト削減量がモデルの学習とサービス提供にかかるコスト未満になることを意味します。
例：動画レコメンド
Success Metric（成功の判断基準）はモデルにより適切に予測された人気動画の数です。成功はアップロードされてから20日以内の総再生時間で測定した最も人気のある動画の95%をMLモデルが予測することを意味し、Failure Metric（失敗の判断基準）は、正しく予測された動画の数が、現在のヒューリスティックスよりも優れていないことを意味します。
判断基準は測定可能ですか？
”測定可能”な判断基準があることで、現実世界の栄光ある評価のための情報となります。例えば、果樹園の木の健康をモニタリングするシステムの場合、病気で枯れてしまう木の割合を減らしたいとします。しかし、もしあなたが病気の木の数を計測できないならば、それは役に立つ判断基準にはなりません。
以下のような質問を投げてみてください。
- どのように、あなたはその判断基準を測りますか？
- いつ、あなたはその判断基準を測ることができますか？
- あなたのMLシステムが成功か、失敗かを判断するためにどのくらいの時間がかかりますか？
理想的には、あなたは早めに失敗したいはずです。シグナルが弱すぎたり、データが予測にほとんど使えない、といったことに注意してください。早く失敗することで、早く仮説を修正でき、時間ロスを防ぐことができます。
例：あなたはユーザーの位置情報から、どの動画が見られるかを当てることができると考えています。それは可能かもしれません。しかし、実際にそれを試してみるとシグナルが弱すぎたりノイズが大きすぎてうまくいきません。どのくらい長くあなたはその仮説に固執しますか？
長期的なエンジニアリングやメンテナンスコストを考慮してみてください。
他の失敗のシナリオ
成功の判断基準とは関係のない失敗にも注意してください。例えば、”クリックベイト”（ウェブ上の広告や記事などに、ユーザーの興味を引いて閲覧者数を増やすため、煽情的なタイトルをつけること）動画ばかりをレコメンドするシステムは、質の高い視聴体験を提供する上で成功であるとは言えないでしょう。
どのようなOutput（出力）をMLモデルで生成したいですか？
数値/ラベル/クラスター/他、あなたはどのような種類のOutput（出力）を必要としていますか。
★ポイント：あるタイプのOutputでは失敗となるが、別のタイプのOutputでは成功するようなML問題もあります
良いOutputのProperties
Outputは機械で生成できるよう、明確な定義に基づき定量化できることが必要
例：ユーザーは動画を見て楽しんだか？ vs ユーザーは動画をシェアしたか？
ユーザーに質問しない限り、ユーザーが動画を楽しんだかどうかはわかりません。もしユーザーに質問ができないのなら、あなたにはproxy label、つまり真の事象の代替となるラベルが必要です。ユーザーがどのくらいその動画をシェアしたかは非常に良いproxy labelとなります。確かに、動画をシェアすることはユーザーが楽しんだかどうかの完璧な近似にはなりません（例えば、その動画を馬鹿にするためにシェアするといったこともあります）。しかし、シェアは定量的で、トラッキング可能で、ちゃんとした予測のためのシグナルを提供します。
Output（出力）は、理想的なOutcome（成果）と繋がっていることが必要です
MLモデルはOutput（出力）を最適化します。したがって、そのOutputが本当にあなたにとって大事なものであることを確かめてください。理想的なOutcomeを直接図ることはできないことが多いので、proxy labelは頻繁に必要になります。しかし、proxy labelと本当のOutcomeとの関係性が強いほど、私たちは正しい事象を最適化していると自信を持つことができます。
OutputとOutcomeの間に強い関連性があることを確かめてください！
学習データとして利用できるExample Outputsを入手できますか？
何のデータソースからどのように？
教師あり学習はラベル付けされたデータに依存しています。もし、Example outputs（例としての出力）を手に入れることができないのなら、前の段階に立ち戻って機械学習の問題（problem）と目指す姿（goal）を再定義する必要があります。outputはエンジニアリングされる必要があるケースがあります。例えば、上の例では視聴時間をパーセンタイル値に変換しています。
Outputを使う
モデルは次の二つの方法で予測を出力することができます。
- ユーザーの行動に反応して、リアルタイムに（online）
- バッチ実行して、キャッシュ化（offline）
どのようにあなたのプロダクトは使用されますか？いいですか？私たちはMLをdecisionを生むために使用します、予測のためではありません。どのようにあなたはモデルにより予測されたoutputをdecisionに変換しますか？
例：
新しい動画がアップロードされたとき、その動画がどのくらい人気になるかを予測します。そのOutputは動画のトランスコーディングのアルゴリズムの決定（decision）に役立てられます。
実装が擬似的なコードでどのようになるかを考えてみてください。例えば、ユーザーがアプリから送信された通知をクリックする可能性を予測するモデルを構築していて、クリックする可能性のあるユーザーのみに通知を送信したいとします。擬似的なコードは以下のようになるでしょう。
click_probability = call_model(user)
if click_probability > 0.05:
send_notification(user)
上記のステップを行うことは、モデルの予測をdecisionに変換することを考えることに役立つでしょう。
次に、上の擬似的コードが実装されるアーキテクチャがどこか考えましょう。これは次のような重要な問いに答えることにつながります。
- モデルを呼び出す必要がある時に、そのコードはどんなデータにアクセスができますか？
- レイテンシー（通信の遅延時間）に関する要件は何ですか？UI上での遅延を避けるように素早く実行される必要がありますか？それともユーザーの行動を待たずに実行しておくことができますか？
上記の問いに答えることで発見される要件は、あなたのMLモデルが使用できる特徴量に大きな影響を与えます。あなたがMLモデルを呼び出すときに使用できる特徴量でのみ学習できます。そうでなけば、せっかくMLモデルが知識を学習してもサービス提供時に利用できません。さらに、レイテンシー要件を満たす範囲で特徴量が取得できることを確認してください。外部サービスからのデータを使用することはレイテンシーの観点からは、その特徴量は割高になってしまう可能性があります。例えば、現在の気象情報をカメラアプリの中で特徴量として使用したい場合、現在の気象情報を取得するまでの待ち時間が長すぎて、アプリで許容できない速度低下が発生するかもしれません。
最後に、古いデータの使用に注意してください。学習データが数日前のものである場合があることに注意してください。ライブトラフィックで処理している場合には、使用したいデータがまだ取得できない場合があります。おそらくデータベースは30分ごとにユーザーの履歴を更新するので、予測を行うときにユーザーの最新データにアクセスすることはできません。
不適切なObjective（目的変数）
正しくセットアップされたら、MLシステムは目指すObjective（目的変数）を追求していく上で非常に優れています。反対に、MLシステムは間違ったObjectiveが与えられた場合には、意図しない結果を生み出す可能性があります。したがって、システムの目的がどのように、あなたの問題を解決するために機能するかを慎重に考えてください。
先ほどのYouTubeで次に見る動画を予測するモデルのケースを再度考えてみましょう。
- クリック率を最大化する
- ユーザーはクリックはしますが、長く動画を視聴することはないでしょう。これは”クリックベイト”を最適化してしまいます。別の方法を試した方がいいでしょう
- 視聴時間を最大化する
- セッション視聴時間を最大化する
- このモデルも依然として長い動画を選びがちであり、これは問題です。このモデルは、特定の関心を非常にうまく掘り下げます。例えば、ユーザーがLeBron Jamesのダンクシュートの動画を見ると、システムは全てのLeBron Jamesのダンクシュートのビデオを表示します。この動画レコメンデーションシステムはセッション視聴時間を最大化するのは本当に得意ですが、ユーザーエクスペリエンスは低下します。
- 多様性を増やし、セッション視聴時間を最大化する
- このObjectiveからはどのような問題が発生すると思いますか？「計測結果が目標になると、その計測自体が役に立たなくなる」というグッドハートの法則を常に留意してください。
ヒューリスティックス（経験則）
もしMLを使わないなら、どのように問題を解決しますか？もし、あなたが明日プロダクトを納品しなくてはならず、ビジネスロジックをハードコーディングする時間しかないとします。その場合、あなたは次のようなヒューリスティックス（非MLソリューション）を試すことができます。
例：過去に人気動画をアップロードした人による新しい動画も人気になると想定します
このヒューリスティックスは、正解で最高のヒューリスティックスではないかもしれませんが、ベースラインを提供します。ヒューリスティックスに勝てないような、MLモデルは決して使ってはなりません。ヒューリスティックスを作るエクササイズは、MLモデルにおける良いシグナルを特定するのに役立つ場合があります。
非MLソリューションは、MLソリューションより保守が簡単な場合があります。
［翻訳］あなたは悪い意思決定者か
原文
Cassie Kozyrkov氏の記事（2020/5/18）より
decision analysis（意思決定分析）の専門家は、熟練していない意思決定者をかぎ分けるためのトリックを持っています。それを知りたいですか？先週からの質問を調べてください。
クイズタイム！
ヘザーはカナダ人で、親切で、フレンドリーで、頭が良く、動物が大好きです。彼女はサステナビリティのコンサルタントです。大学では彼女は数学と心理学を学びました。彼女は長めの散歩に行くのが好きで、いくつかのハイキングコースの近くに住んでいます。
以下２つのうち、ヘザーはどちらの方が可能性が高いと思いますか？
- ヘザーはPhDを持っている
- ヘザーはPhDを持っており、犬を飼っている
スクロールする前に、あなたの回答を準備してください。
↓
↓
↓
1を選んだあなた、おめでとうございます。あなたはconjunction fallacy（合接の誤謬）を回避しました。２は間違う可能性を高めているため、1の方が正しいです。数学好きのために、P(A) ≥ P(A ∩ B)です。合接の誤謬についての詳細な説明と、ステレオタイプによって過度に複雑な結論に至ってしまう理由について知りたい場合は、私の記事 Don’t fall for the conjunction fallacy! を読んでください。
その記事では、バイアス、ステレオタイプ、科学、そして悪いアナリストにならない方法について述べました。
実際にヘザーは犬を飼っています。
では、ヘザーが犬を飼っていることが分かったとして、以前の選択肢においてあなたの気持ちをよりよく表しているのはどちらですか？（1. ヘザーはPhDを持っている / 2. ヘザーはPhDを持っており、犬を飼っている）
A) 私はもともと1を選んだが、代わりに2を選ぶべきだった
B) 私はもともと2を選んだが、代わりに1を選ぶべきだった
C) 私はもともと1を選んだが、それは賢明な選択であり正しかった
D) 私はもともと2を選んだが、それは賢明な選択であり正しかった
Cを選びましたか？
decision scienceの専門家はC, B, A, Dのように各回答をランク付けするでしょう。つまり"C"以外は"BAD"であると言えます。
優れた意思決定者は、outcome bias（成果バイアス）に陥らない
decision analysisの最初の原則は、outcome bias（成果バイアス）を回避することです。それは授業初日に生徒に教えることです。成果バイアスに対し耐性を持つことは、基本的な意思決定能力の最低要件です。優れた意思決定へ勝ち得で学ぶことはたくさんありますが、この最初のハードルをクリアするまで先には進めません。
成果バイアスとは何か？
心理学において、成果バイアスとは、意思決定を下す時点では知りえなかったことに基づいて意思決定を評価する誤りのことです。成果バイアスと後知恵バイアス（答えを知った後、知らなかったのに「私はその答えを知っていた」と記憶を調整してしまうバイアス）とを混同しないでください。
成果バイアス的な思考の良い例として、スウェーデン政府のCOVID-19に関する意思決定について評価することを考えてみて下さい。一般市民と意思決定のプロの違いは、（成果バイアスを持った）一般市民は「どのような事態になるか」でスウェーデン政府を評価しますが、意思決定のプロはそうはしません。状況の評価はdecision scientistの間で異なる場合はありますが、決定が行われた時点で分かっていたことに基づいて政府を評価するだけです。
成果バイアスは社会的に受け入れられるレベルの集団非合理性であるため、多くの人がこれを聞いて驚くでしょう。ましてや、”結果物事がどうなるか”が意思決定の質を評価する方法であると教わって育った人にとっては、怒りすら覚えるかもしれません。成果バイアスが幻想である理由について知りたい人は、私の記事”The problem with analyzing policy decisions in hindsight"を読んでください。
Decision analysisの基本原則
この記事の目的は次に述べるDecision analysisの基本原則を伝えることです。
意思決定の質は、意思決定時に意思決定者が入手できる情報のみを使用して評価する必要がある。
言い換えれば、後から知った知識で混乱しないようにしてください（特に2020年においては）。
意思決定のエキスパートはいつも、成果から意思決定を分離します
しかし、ヘザーと犬の例に戻りましょう。
各選択肢を回答した人について言えること
C)を選択した人
良い選択です！あなたは最初の質問に対して賢く回答し、その時点で知っていることに基づいてそれが最良の選択であると認識したので、あなたは自分の意思決定プロセスに自信を持っていたことでしょう。
犬の写真を見ても、あなたは成果バイアスに陥りませんでした。トレーニングを受けたDecision Scientistと同様な決定を下したことになります。おめでとう！
（だからと言ってあなたが優れた意思決定者であるというわけではありません。あなたは最初のハードルを越えただけにすぎません。）
B)を選択した人
あなたは間違ってはいましたが、Bを選択するということは、あなたは自分の間違いから正しい方向に学ぶことができる人であるということがわかります。
合説の誤謬に陥ってはいけない理由を理解して、正しく学習しています。あなたはこの記事の中で成長しました！
A)を選択した人
あなたは直感的に最初正しい選択をしましたが、結果的には間違った学習をしました。後から知った知識があなたの意思決定プロセスに間違ったことを教えたのです。間違いから学ぶことは良いことですが、間違ったことを学ばないようにしてください。しばしば、人生はあなたの意思決定レベルとは関係なく、あなたが予期できないランダムなカーブボールを投げます。それが起こった時、あなたの意思決定プロセスをそれに適用させてしまうことは悪い考えです。あなたの考え方は有能なリーダーを後押しし保持する社会の機能を脅かしてしまいます。その理由を知りたければ、こちらを読んでください。
D)を選択した人
あなたはポイントを激しく見逃しており、2倍のバイアスを示しています。”ほらみろ！彼女は犬を飼っていたじゃないか！私は正しかったし、次回も同じようにするさ！”
いいえ、あなたはラッキーだっただけです。あなたは悪い判断をしましたが、たまたまいい結果が得られただけです。あなたは運とスキルの違いが分かっていません。
選択肢Aと同様にこの考えは熟練した意思決定者を社会に送り出すことを否定しますが、他のバイアスと混ざり合って、誤った偏見が長続きします。
意思決定スキルの欠如は偏見を助長する
もしよい意思決定の習慣を身に着けない場合、心理学的には次にあげるようなことを行う可能性が高いと言えます。
1. 利用可能性ヒューリスティック：あなたが感知した事例が起きる可能性を過大評価する
2. 確証バイアス：あなたの固定観念と矛盾する情報などを無視する
3. 合説の誤謬：証拠が示されていないにもかかわらず「正しいと感じる」固定観念に基づいて、見当違いな結論に達する
4. 成果バイアス：自分の意思決定プロセスを無視し、成果にフォーカスしすぎてしまう
5. 自己奉仕バイアス：運よく良い成果が得られた時は自分のおかげだとし、悪い成果が得られた時は他者のせいにする
あなたにはこのフィードバックループが見えますか？
代わりに何をすべきか
1. 利用可能性ヒューリスティックは、不完全な人間の記憶から起きるため、人間よりも優れた記憶力を持つ機械（または鉛筆）に頼るべきでしょう。可能ならば、人間の記憶よりも統計的にバイアスを排除した記録を重視します。
2. 不確実性が存在する場合には、心を開いて、確証バイアスを減らすための対策を講じてください。
3. 証拠が示すよりもややこしい結論にジャンプすることを避けてください（たとえそれが正しそうだと”感じた”としても）。
4. 成果を無視し、意思決定時にわかっていたことだけに基づき意思決定と意思決定者を評価してください。
5. 意思決定を行う前に不確実性を評価し、不確実性の大きさを意思決定者と管轄外の要素の間で分配します。ギャンブルの結果について意思決定者を非難するのではなく、そもそも不適切なギャンブルをしたことについて意思決定者を非難してください、、、たとえ運が良かったとしても。次のようなことを含む場合、意思決定者の意思決定スキル不足を非難してください。
（ⅰ）掛け金よりも少ない努力をした
（ⅱ）過剰なリスクを取った
（ⅲ）利用可能な情報を無視した
（ⅳ）情報を誤って利用した
もし、より深く学びたいなら、私の記事”The problem with analyzing policy decisions in hindsight"を読んでください。
［翻訳］今フォローすべきデータ＆アナリティクスブロガー14名
原文
IDG記事（2021/7/22）より。
データを価値あるビジネス資産に変換することは容易ではありません。しかし急速に進化するテクノロジー環境では、この需要は急速に伸びています。IDGによると、67%の企業がパンデミックによって組織のデータドリブン戦略を加速させたことを認めています。そして現在、34%の企業がデータドリブンプロジェクトの実装またはテストを行っており、残りの13%が今後12カ月でその配備を計画しているとのことです。
マーケターとして、データを使用しデータと分析ソリューションを販売することは、顧客がいかに戦略的に考えてデータを使用するかを理解することを意味します。IDGの調査により、これらの洞察を明らかにすることができます。しかし、ソートリーダーシップを通じて洞察力を高め続けることは、競合をさらに引き離すことに役立つでしょう。そしてあなたの学習の旅を助けるために、私たちはInfoWorldであなたを支援するためのコンテンツページを作成しました。
さらに、以下にブログ、ポッドキャスト、講演イベントなどを通じて専門知識を発揮しいる14人のデータとアナリティクスのソートリーダーをキュレーションしました。
ブロガーに出会う
Jill Dyché
”Data for Good"はJillの執筆活動の中心にあります。彼女は経営幹部に向けて、アナリティクスが競争の優位性である理由について主張しています。Jillの執筆は、Newsweek.com、HBR.org、Computerworld、Forbes.comなどの主要な雑誌、ジャーナルで取り上げられています。彼女のホームページには、魅力的で思慮深い記事があります。Twitterもフォローしてみてください。
Wayne Eckerson
国際的に良く知られたソートリーダーであるWayneは、執筆家、講演者、そしてEckerson Groupの創設者です。彼は、複雑なデータトピックスを消化可能で、すぐに活用できるインサイトに変えるコツを知っています。Wayneの本”The Secrets of Analytical Leaders: Insights from Information Insiders"は、その一例です。彼はまた彼の会社のウェブサイトに積極的に寄稿しています。Twitterもフォローしてみてください。
Laura Ellis
現在はIBM CloudのAnalytics ArchitectのLauraは、データサイエンスとアナリティクスが誰でも利用できるようになることを信じています。彼女のブランド”Little Miss Data"には彼女の個性が詰まっています。彼女の読みやすいブログと、ステップバイステップのビデオチュートリアルで、データのインサイトをスムーズに獲得していけます。Twitterもフォローしてみてください。
Karen Grace-Martin
The Analysis Factorの創設者兼社長であるKarenは、大学生からアイビーリーグの教授、さらには企業から非営利団体まで、様々な人と一緒に働いてきました。Data Analysis with SPSSの共著者であり、彼女の出版物や無料のウェビナーはデータ愛好家に明快で利用が容易な学習の旅を提供しています。Karenと彼女のチームからの最新情報をチェックしてください。Twitteerもフォローして見てください。
Avinash Kaushik
GoogleのデジタルマーケティングエバンジェリストであるAvinashは、Web Analytics2.0とWeb Analytics: An Hour A Dayの2冊のベストセラー本にて、彼の独自のインサイトを公開しています。加えて、彼の人気なブログOccam's Razorで、アナリティクスとマーケティングにおける複雑な課題に対するヒントと最新ソリューションを提供しています。Twitterもフォローしてみてください。
Cassie Kozyrkov
GoogleのDecision Intelligenceの責任者であるCassieの履歴書は本当に息を飲むほどです。彼女は在職中に、アナリティクスの分野で20,000人を超える"Googler"を個人的にトレーニングしたと述べています。しかし、私たちが最も好きなのは、彼女の”Decision Intelligenceの民主化と安全で信頼できるAIに向けた（先導的な）ミッション”が良い力を発揮してきているということです。必ずCassieのブログを読み、Twitterもフォローして見てください。
Ben Lorica
O'Reilly Mediaの元チーフデータサイエンティストであるBenは、業界に関する豊富な知識を蓄えてきました。そしてマーケターにとって幸運なことに、彼は現在、The Data Exchange Podcastを設立しました。それは彼のデータインサイトを実行可能なアドバイスに変換することに焦点を当てたシリーズです。テクノロジーのトレンドからデータと分析の最新ツールまで。さらに彼のブログThe Practical Quantでフォローできます。Twitterもフォローしてみてください。
Lea Pica
Scholastic、Victria's Secret、Prudentialなどの企業向けのデジタル分析手法の構築―Leaの経歴は比類なきものです。しかし、彼女が本当に他の追随を許さないものは、データストーリーテリングの力への継続的なコミットメントです。Leaの活動を通じて、企業はデータを通じて、より深くより価値ある方法で消費者とつながる方法を学ぶことができます。Leaのブログでデータストーリーテリングの将来について学ぶことができます。Twitterもフォローしてみてください。
Gil Press
ビッグデータとは何でしょう？それはGilが毎週のブログで答えている質問です。独自の洞察に満ちた執筆で、彼はデジタルデータのサイズとその伸びを見積もることに非常に精通しています。また、ForbesのSenior Contributorである彼のトピックは、データのトレンドから実用的なスタートアップへのアドバイスまで多岐に渡ります。彼の最新情報をお見逃しなく。Twitterもフォローしてみてください。
Isaac Sacolick
以前は業界をリードするCIOであったIssacの執筆活動は、ビッグデータに関する彼のアイディアを共有するためのプラットフォームとして機能してきました。彼はForbesから、トップ20のSocial CIOとして認定されています。そして、彼は現在CIOとInfo Worldへの寄稿編集者であり、ビッグデータ分析の業界におけるスピーカーの一人です。彼のブログを読んでみてください。Twitterもフォローしてみてください。
Krista Seiden
Google Analyticsとその多くの教材の中の声として、Kristaはデータに関する最も優れたソートリーダーの一人です。最近では彼女は画期的な専門性を、KS Digitalの設立に注ぎ込みました。企業がデジタルマーケティングとアナリティクスのパフォーマンスを向上させることを支援することにむけたミッションを持っています。Kristaのウェブサイトで彼女の最先端のインサイトをフォローできます。Twitterもフォローしてみてください。
Ryan Swanstrom
ソフトウェアエンジニアリングからデータサイエンスのキャリアへの道のりは簡単ではありません。しかしそれがRyanのキャリアです。2012年2月の最初のエントリから、彼はキャリアの過程で学んだ重要なデータに関する教訓を読者と共有してきました。今日では、Ryanはデーサイエンスのディレクターであり、起業家でもあります。彼のブログから彼の旅を学びましょう。Twitterもフォローしてみてください。
Ronald van Loon
Ronaldはビッグデータとアナリティクスにおける世界的なインフルエンサーのトップ10に認定されています。Ronaldはこの分野での教育の発展とソートリーダーシップに取り組んでいます。Twitterには約25万のフォロワーがおり、彼の非常に人気のあるコンテンツはデータドリブンを実践する企業が全く新しいビジネス価値を生み出すのを支援することに焦点を当てています。彼のLinkedInの記事で人気のある記事を見つけてみてください。Twitterもフォローしてみてください。
Nathan Yau
LCLAで統計学の博士号を取得した後、Nathanはデータビジュアライゼーションを専門としています。統計チャートからインフォグラフィック、さらにはデータアートまで、彼はできるだけ多くの人がデータを理解し解釈できるように支援することに取り組んでいます。彼はこのテーマについて人気のある書籍を書き、グラフィックデザインとデータビジュアライゼーションのカテゴリでFastCompanyから表彰されました。彼のウェブサイトで学びましょう。Twitterもフォローしてみてください。
ボーナス：２つの必読コンテンツコミュニティ
Smart Data Collective
ビッグデータとアナリティクスをカバーする最大かつ最も信頼できるコミュニティの一つであるSmart Data Collectiveには、毎日利用可能なコンテンツがロードされています。特定の技術セクターに関するデータインサイトを探している場合でも、新しいツールやトレンドを常に把握する必要がある場合でも、あらゆるニーズに対応する有益なコンテンツがあります。ここで彼らの記事をチェックしてみてください。Twitterもフォローしてみてください。
Towards Data Science
Mediumで合計562,000人を超えるフォロワーを有するTowards Data Scienceは、コンセプト、アイディア、コードを見逃すことはありません。また、世界中に5,000人を超すボランティアのライターがいるため、各投稿にはユニークで多様な視点があふれています。ここで彼らの記事をチェックしてみてください。Twitterもフォローしてみてください。
