データ分析の主目的は、より良い決定を下すことです。分析結果に基づいた意思決定が必要なければ、そもそも、分析に時間を費やす必要はありません。たとえば、中古車の購入を検討する際に、車の製造年と走行距離を販売店に問い合わせることがあります。
これは、車が販売されてからの経過年数で、その車の潜在的な価値が推測できるからです。走行距離を経過年数で割れば、この車がどれほど頻繁に使用されてきたかがわかります。この後、さらに5年間、この車を使い続けられそうかといった判断ができます。しかし、そもそも車を購入する予定がなければ、このような分析を行う必要はありません。
実際のところ、データというのは、ほとんどの場合、分析と意思決定のために収集されるものです。車の購入時に年数と走行距離を確認するということは、分析のためのデータを収集しているということです。その他にもさまざまな例が考えられます。すべての車には走行距離計が搭載されていますが、これは、中古車の購入以外にも、車の走行距離に基づいて意思決定を行うさまざまな場面があるからです。
たとえば、トランスミッションが壊れた場合、メーカーからの補償は得られるでしょうか？ オイル交換のタイミングは？ このような意思決定に必要となる分析は、それぞれに内容が異なります。しかしながら、いずれの場合も、まずは、走行距離が記録されていることが前提となります。
意思決定のためにデータを収集する際は、そのためのインフラストラクチャやそれを保護するセキュリティに、一定の要件が課せられます。事故の申し立てを受けて、車の価値に応じた保険金を支払う保険会社は、走行距離計が正確であることをどのようにして確認すればよいのでしょうか？ 走行距離計はどのように検査されており、どのような改竄防止策が講じられているのでしょうか？ 走行距離計のキャリブレーション時と異なるサイズのタイヤを取り付けている場合など、一見すると改竄に見える状況が偶発的だった場合はどうなるでしょう？
複数の当事者が関与し、データの所有者と使用者が異なる場合、データの監査は特に重要です。データの正当性が確認できなければ、関係者は手探りの判断に頼らざるを得ません。そこには、最適な決定ができず、市場が混乱に陥るというリスクさえもあります。
なお、すべてのデータ収集が、車の走行距離計と同じくらいにコストがかかるとは限りません。センサーの価格はここ数十年で劇的に下がり、私たちの日々の活動を通じて、膨大なデータが無自覚のうちに収集されるようになりました。データを収集・保存するハードウェアの価格が下がるに従い、明確な目的はなくとも、データは無期限に保存されるようになりました。しかしながら、収集・保存したデータを分析する際は、やはり、そのための目的が必要です。
繰り返しになりますが、データ分析の目的は意思決定です。市場に参入するかしないか？ コミッションを支払うかどうか？ 価格をどれくらい上げるか？ いくつ購入するか？ 今すぐ購入するか、1週間待つのか？ このような意思決定が必要な場面は増え続けていますが、いまやデータはいたる所に存在しますので、もはや荒っぽい経験則に頼る必要はありません。データドリブンな方法で、意思決定ができる時代になったのです。
もちろん、すべての分析や意思決定を自分自身で行う必要はありません。たとえば、走行距離から自動車の価値を推定するという作業は、それ自体をサービスとして提供する企業があるほどに一般的です。走行距離計が正確であることや車が事故を起こしていないことの確認、あるいは、売却希望価格と市場価格の比較などは、そのような企業に依頼できます。
したがって、データ分析の実際の価値は、個々の分析結果というよりは、むしろ、データドリブンな意思決定を体系的に実施して、それを継続的なサービスとして提供することにあります。これにより、それぞれの企業は専門性を持ち、意思決定の正確性を継続的に向上していくことができるのです。
1.1 多くの同様な意思決定
前述のように、センサーやストレージのコストが下がることで、データドリブンな意思決定の支援ができる業界やユースケースは増加しており、このような業界で働く人々、あるいは、起業を考える人々にとって、そのチャンスは広がりつつあります。場合によっては、新たにデータを収集する必要もあるでしょうし、すでに収集されたデータが利用できるとしても、多くの場合、その他のデータを収集して補う必要があります。これらのすべてのケースにおいて、データを分析し、データドリブンな意思決定を体系的に支援できる人は、市場で求められるスキルを持っていると言えるでしょう。
この後、本書では、いくつかの意思決定の例を示します。そこでは、さまざまな統計的手法、あるいは、機械学習を用いて、意思決定に必要な知見を得る方法を紹介します。ただし、それらをただ一度の作業として終わらせるのではなく、より体系的に行う方法を示していきます。最終目標は、この意思決定能力を顧客にサービスとして提供することです。顧客は既知の情報を提供し、私たちは、体系的に収集したデータを補い、組み合わせることで、さらにその先の知見を入手、あるいは、予測するのです。
データを収集する際は、データの安全性も考慮する必要があります。データが改竄されていないことを保証するだけではなく、個人情報の侵害を防止する必要もあります。たとえば、走行距離計から収集したデータが、収集時刻の情報を含んでいる場合、非常に機密性の高い情報になります。車の利用者に関する他の情報（自宅の住所や住んでいる都市の交通パターンなど）をあわせると、その人の行動パターンを推測し、任意の時刻の居場所を特定することができるからです。
このように、一見すると無害なデータにおいても、プライバシーへの影響は想像以上に大きくなることがあります。セキュリティを考慮するならば、データに対するアクセスの制御、そして、誰がデータを参照・変更したかを監査するためのログの収集・管理は必須となります。
単純にデータを収集したり、そのまま使用するだけではなく、データを理解することも重要です。走行距離から車の価値を推定する際は、走行距離計の改竄に関わる問題を理解する必要がありました。これと同様に、データ分析の際は、データをリアルタイムに収集する方法やデータに含まれるエラーの種類を考慮する必要があります。
それぞれのデータに固有の特性を十分に理解することは、データサイエンスの活動において、とても大切な意味があります。データサイエンスの新しいアイデアがうまくいくかどうかは、データの微妙な特性が適切に評価されているかどうか、それらが徹底的に理解されているかどうかによって決まることも少なくありません。
また、意思決定の支援機能をサービスとして提供したいと思った場合、オフラインだけでシステムを構築するわけにはいきません。サービス化にあたっては、想像し得るあらゆる課題が発生します。まずは、データから導かれた意思決定の質そのものに関わる問題があります。その決定はどこまで正確なのか、典型的なエラーの要因は何か、このシステムを適用すべきでないケースはどのようなものかといった疑問に答える必要があります。
次は、サービスの品質に関する問題です。サービスの安定性、1秒間に処理できるリクエスト数、あるいは、データを入手してから意思決定モデルに組み込まれるまでの時間といった考慮点があります。本書では、実際のユースケースを用いて、実践的なデータサイエンスで考慮すべきさまざまな側面を紹介します。
1.2 データエンジニアの役割
「ちょっと待って……」―――ここで、そんな声が聞こえてくる気がします。「WebサービスのQPS（1秒間に処理できる問合せ数）は、私の責任範囲ではありません。私の仕事は、SQLクエリを書いてレポートを作成することです。さきほどの話は、私の仕事に何か関係があるとは思えないのですが」。あるいは、冒頭の話題ですでに困惑している人もいるかも知れません。「ビジネス上の意思決定は、ビジネス側の人々が考えることでしょう。
私の仕事はデータ処理システムの設計・構築、つまり、データ処理基盤を用意して、いま何が起きているかを把握すること、すべてを安全に保つことです。データサイエンスがすごいのはわかりますが、私はエンジニアです。Google Cloud Platformを用いたデータサイエンスの実践といえば、システムの運用方法やアクセス増加時のスケールアウトの方法が聞けるものだと思っていたのですが」。そして、3つ目の反応のパターンはこうではないでしょうか。
「これは本当にデータサイエンスの説明ですか？ さまざまなモデルの違いの説明、統計的推論と評価の手法、それから、数式はいつ登場するのでしょうか。データアナリストやエンジニアではなく、私のための説明をしてください。私は統計学の博士号を持っているのですから」。このような意見はもっともです。私は、組織内のさまざまな人々によって行われる仕事を混同しているように見えるかもしれません。
つまり、あなたは、次のような考えには同意するかもしれませんが、趣味であれ、仕事であれ、これらすべてに1人で取り組む必要があるとは思わないでしょう。
- データ分析は意思決定を支援するためのものである。
- 経験ベースではなく、データドリブンな意思決定の方が優れている可能性がある。
- 意思決定モデルの精度は、適切な統計的手法、もしくは、機械学習によるアプローチの選択に依存する。
- データの微妙な違いによって、モデルがまったく役に立たなくなることがあるため、データの本質的な理解が大切である。
- 意思決定を体系的に支援し、それをサービスとして提供する大きな市場機会がある。
- そのようなサービスは、継続的なデータ収集とモデルの更新を必要とする。
- 継続的なデータ収集には、強力なセキュリティと監査が必要。
- 顧客は、サービスの信頼性、正確性、待ち時間についての保証を必要とする。
しかしながら、Googleでは、技術スタッフ全員をエンジニアと呼ぶことからもわかるように、個々の社員の役割をもう少し広くとらえており、データエンジニアというのは、「データ分析を実行してビジネスで成果を出す」ことができる人とみなしています。データ分析においては、データドリブンな意思決定を支援する統計モデルを構築することから始めますが、その際、SQLクエリやチャート作成ソフトウェアで結果を単純にグラフ化するだけでは不十分です。その結果を解釈し、ビジネス課題に応えるための知見を導き出す統計的なフレームワークを理解する必要があります。
したがって、いま利用している統計的手法がどのような意味を持つのか、そして、分析結果がどのようにしてビジネス課題の解決につながるのかという、2つの要素をとらえる必要があります。つまり、クエリ、レポート、グラフは最終目標ではなく、最も重要なのは、ビジネス課題を解決するために、統計的に有効なデータ分析を実行する能力であり、適切、かつ、検証可能な意思決定にこそ価値があるのです。
また、データ分析は一度だけの仕事ではなく、スケール可能な手法が必要とされます。優れた意思決定プロセスは、反復可能で、あなた以外の多くのユーザーが実行できなければなりません。分析をスケールする方法の1つは自動化です。これにより、データエンジニアは、考案したアルゴリズムを体系的で、反復可能なものにしなければなりません。システムの信頼性を担うエンジニアは、自分自身でコードを修正できるようになるのが理想ですが、それと同様に、統計学や機械学習を理解している人々が、自分自身でモデルをコード化できるようになることが必要です。
Googleでは、データエンジニアは、モデルの構築から自動化までをカバーできると考えていますが、それを実現するには、安全で信頼性が高く、耐障害性があり、スケーラブルで効率的なデータ処理システムの設計、構築、そして、問題発生時のトラブルシューティングが必要です。
データサイエンスを理解したエンジニア、あるいは、コードが書けるデータサイエンティストを必要としているのは、Googleだけではありません。Stitchと呼ばれるスタートアップの創業者であるJake Steinは、ビッグデータの世界で最も需要の多いスキルは、データエンジニアであると求人広告から結論づけています。サンフランシスコの求人データを用いて、同様の分析を行ってみたところ、実際に、データエンジニアの求人はデータアナリストとデータサイエンティストの合計求人数を上回っていました。
サンフランシスコのハイテク企業だけではなく、これは、今後すべてのデータ集約型産業が進む方向です。データに基づいた、反復可能でスケーラブルな意思決定のニーズが高まるにつれて、このトレンドは、ますます加速するでしょう。企業がデータエンジニアを探しているとき、彼らが求めているのは、上記3つの役割をすべてカバーできる人なのです。
しかしながら、このような複数の領域に精通した、完璧な人材を求めるのは現実的と言えるでしょうか？ データベーススキーマの設計、SQLクエリの作成、機械学習モデルの構築、データ処理パイプラインのコーディング、そして、これらすべてのスケールアップの方法を理解できる人物を見つけられる可能性はどのぐらいあるのでしょうか。―――驚くべきことに、これは、とても現実的な選択肢なのです。なぜなら、これらの仕事をこなすために必要な知識の量は、数年前よりもずっと少なくなっているからです。
1.3 クラウドで実現するデータエンジニアリング
クラウドの普及により、データエンジニアは、これまでは4つの異なるスキルセットを持つ人々が行っていた作業を1人でこなせるようになりました。オートスケーリング、あるいは、設定が容易なサーバーレスのマネージドサービスが登場したことで、より多くの人々がスケーラブルなシステムを構築できるようになったからです。
その結果、困難なビジネス課題を解決する、データドリブンなソリューションを構築するデータエンジニアを雇うことは、夢ではなくなりました。このようなデータエンジニアになるには、膨大な知識はもはや必要ありません。クラウド上で、データサイエンスを実践する方法を学べばよいのです。
クラウドがデータエンジニアリングを可能にするというのは、一見無謀に聞こえるかもしれませんが、これは、「クラウド」をどうとらえるかに依存します。社内のワークロードをパブリッククラウドに、そのまま移行するという話ではありません。ここでは、Google Cloud PlatformのGoogle BigQuery、Cloud Dataflow、Cloud Machine Learning Engineなど、インフラストラクチャのプロビジョニング、監視・管理などのサービスを自動化するマネージドサービスについての話をしています。
クラウド上の適切なツール群を活用することで、データ分析、あるいは、データ処理に必要なワークロードのスケーリングと障害対応が自動化され、データサイエンティストのITサポートに対する依存性は、格段に減少することが理解できるでしょう。
また、データサイエンスに必要なツールは、ますます、使いやすく簡単になっています。Spark、scikit-learn、Pandasなどのフレームワークが普及することで、データサイエンスとそのためのツールは、一般的な開発者でも容易に利用できるようになりました。統計モデルを作成する、あるいは、ランダムフォレストなどの機械学習モデルを利用するために、データサイエンスの専門家である必要はなくなりました。より伝統的なITの役割を担う人々にも、データサイエンスの門戸が開かれたのです。
データアナリストとデータベース管理者の関係においても、同じことが言えます。現状では、両者のスキルセットは、大きく異なるかもしれません。データ分析には、SQLの詳しいスキルが必要で、一方、データベースの管理には、インデックスとチューニングに関する深い理解が必要だからです。
しかしながら、BigQueryのように、非正規化されたテーブルを採用し、システム管理のオーバーヘッドが最小限に抑えられたツールが登場することで、データベース管理者の役割は大幅に減少しました。あるいは、企業内のすべてのデータストアと接続する、Tableauのようなビジュアライゼーションツールの利用が増えることで、より幅広い人々がデータウェアハウスと直接対話し、価値の高いレポートとデータに対する知見を得ることが可能になりました。
こういったデータに関わる役割が統合されつつあるのは、インフラストラクチャの問題が緩和されることで、データ分析とモデリングの分野がより多くの人々の関心領域となったからです。あなたが、データサイエンティスト、データアナリスト、データベース管理者、あるいは、システムプログラマのいずれかだとして、このような変化は、喜ばしいことでしょうか、それとも、非現実的なことでしょうか。
これまでに説明したように、参入の障壁が低くなったいま、「自分の責任範囲外の作業が終わるのが待ちきれない」というのであれば、これは喜ばしいことでしょう。あなたが、この新しいデータサイエンスの世界に興奮しているならば、この本は、まさにあなたのためのものです。
このような複数の役割の統合に、まだ懐疑的な方も、もう少しお付き合いください。伝統的なエンタープライズ環境にいる人にとって、インフラストラクチャの管理を必要としないオートスケーリング環境というのは、想像しがたいものかもしれません。「少なくとも自分が引退するまでの間は、そのような劇的な変化は起こるはずもない」―――そんな風に考えるかもしれません。あなたの組織がどれほどの変化を望んでいるかはわかりませんから、その可能性も否定はできません。
しかしながら、これからは、より多くの地域、より多くの産業において、サンフランシスコのハイテク企業と同様の変化が起きるはずです。データアナリストとデータサイエンティストよりも、さらに多くのデータエンジニアが求められる時代となり、その役割は、現在のデータサイエンティストに通じるものとなるでしょう。データエンジニアは、データサイエンスの活動に加えて、そのためのワークロードをパブリッククラウドで実行するための知識を持ち合わせているからです。データサイエンスの用語を理解し、データサイエンスのフレームワークを学ぶことで、あなた自身の価値をより高めることができるのです。
自動化によって利用が容易になることで、新しいものが世の中に広まるというのは、技術の世界では定番の道筋です。昔は、何かを輸送したい場合、馬車で運ぶ必要がありました。そのためには、馬を操る御者と馬の世話をする使用人を雇う必要がありました。これらの作業は、自分1人でできるほど簡単ではないからです。その後、自動車の時代になり、馬に餌をやる作業は、タンクにガソリンを入れるという簡単な作業に置き換わりました。もはや、馬の世話をする使用人は必要ありません。
同じく、御者の仕事も時代遅れになりましたが、もともと御者を雇えなかった人々には、そもそも運転手を雇うという選択肢はありません。つまり、自動車の利用を民主化するには、自分1人で扱えるというシンプルさが必要だったのです。このような民主化によって、仕事が減るのを危惧する人もいるかもしれませんが、運転手を雇う必要がなくなったことで、より多くの人々が自動車を持てるようになったことも事実です。
ただし、そこには、運転が容易であるという前提条件があります。交通渋滞がひどく、その一方で、人件費が安価な発展途上国では、一般の人々が運転手を雇うということもあるでしょう。一方、先進国では、運転に奪われる時間の増大と人件費の高騰があいまって、自動運転車の研究が盛んに行われています。
このような馬車から自動運転車への進化は、データサイエンスのトレンドと本質的に同じものです。インフラストラクチャが簡単になり、手作業が減ることにより、データサイエンスの活動はますます盛んになり、より多くの人々がデータサイエンスの活用を始めようとしています。
たとえば、Googleでは、毎月、約80%の従業員がDremel（Google CloudのBigQueryに相当するツール）を使用しています。ツールの利用方法にはいくらかの違いがありますが、誰もが定期的にデータに触れて、意思決定をしています。誰かに何か質問をすると、BigQueryのビューやクエリへのリンクが返ってきます。「最新の回答を知りたいと思うたびにクエリを実行する」という習慣は、BigQueryを単なるマネージドDWHからセルフサービスのデータ分析ソリューションに昇華させたわけです。
もう1つの例として、企業内の通信手段がどのように発展してきたかを考えてみましょう。かつて、一般企業では、口述された内容をタイピングするための低賃金労働者が大量に雇用されていました。文書のタイピングは手間がかかる一方で、その作業自体は、企業のビジネス活動の中心とはみなされていなかったからです。高給の従業員は、その代わりに、営業活動や新製品の開発に時間を費やしていました。
しかし、この方法は非効率的でした。電子化が進み、ワードプロセッサによって文書作成が容易になると、文書の入力作業はセルフサービスになりました。最近では、企業のほぼすべての役員が、自分自身でタイプしています。それと同時に、作成される文書の量は爆発的に増加しました。これと同じことが、データサイエンスにもあてはまります。
データサイエンスのワークロードにおいても、テストとデプロイが容易になることで、多くのIT関連業務において、データサイエンスに関わる作業がその一部となるはずです。これは、データサイエンスに関わる作業が、ますます容易になっているからです。データサイエンス、あるいは、データを扱うという能力は、限られた業務だけではなく、企業全体へと自然に広がっていくでしょう。
1.4 この本の対象読者
この本の対象読者は、データアナリスト、データベース管理者、データエンジニア、データサイエンティスト、あるいは、システムプログラマなど、データを用いた作業を行うすべての人々です。いま、この本を読んでいるあなたも、近いうちに、データサイエンスに関わるモデルを作り、信頼性とセキュリティを考慮した本番システム上にスケーラブルな形で実装する必要性が生じることでしょう。
データアナリスト、データベース管理者、データサイエンティスト、そして、システムプログラマといった今日の役割分担は、それぞれの領域における深い専門知識を必要とする時代に生まれたものです。しかしながら、この状況は変わりつつあります。データエンジニアの実践的な活動において、他の人々にさまざまな仕事を依頼するということは、なくなっていきます。モデルを作成する人と、それを本番システムに実装する人の役割分担が必要となるのは、それぞれの作業があまりにも複雑だったからです。
一方、今ではオートスケールを備えたマネージドサービス、そして、データサイエンスのためのシンプルなライブラリパッケージの登場により、データサイエンスのワークロードを記述して、スケーラブルな形でクラウドにデプロイすることはとても簡単になりました。つまり、データサイエンティストからすれば、自分が作成したモデルを本番システムにデプロイするために、特別なITスペシャリストのチームは不要になったのです。
一方、データサイエンスそのものもシンプルで簡単なものになりました。よく設計されたライブラリパッケージと簡単に使えるAPIのおかげで、データサイエンスのアルゴリズムを自分自身で実装する必要はなくなりました。それぞれのアルゴリズムの仕組みを理解し、それらを組み合わせて、現実世界の課題を解く方法を学べばよいのです。データサイエンスのワークロードを実装することが簡単になることで、データサイエンスの民主化が進むというわけです。
すべてのIT担当者は、いまの役職が何であろうとも、一定レベルのプログラミング（特にPython）ができて、ビジネスドメインをよく理解しているのであれば、データ処理パイプラインを設計して、ビジネス課題の解決に取り組むことができるのです。
そこで本書では、データエンジニアが関わるであろう、データを用いたサービスに関するさまざまな側面に加えて、統計的モデルや機械学習モデルの開発、さらには、これを本番システムにスケーラブルな形で実装する方法について説明していきます。
