やっぱりデータエンジニアリング
前のテキストが書きかけなのがちょっと気がかりですが。
先日、あるSIerさんとお話をしていて、やっぱりデータエンジニアリングだなと思った話です。
データを分析して、それを仕事に活かす、仕事を効率化したり、売上を上げたり、利益率を高めたりすることって、これまでもずっとやってこられてきたし、これからもずっと無くなりません。昔から「データ分析」と言わないまでも、様々な情報を見て、聞いて、触って、それを電子計算機というコンピューターや、もしくは、「自分の脳みそ」っていうコンピューターに突っ込んで考えて、そしていろんな意思決定をしてきたわけで、何をいまさらデータ分析か、そんなことはずっと昔からやってきた、って方、結構いらっしゃると思います。
じゃあなぜ今、データ分析とか機械学習とかAIとかが流行しているかというと、道具が揃ってきたからなんですよね。特に機械学習やAIはここ数年で道具がものすごく使いやすくなって、これまでは専門のエンジニアを何人も貼り付け、専用のスパコンを並べてやっとできいていた計算が、手元のコンピューターでちょちょっと操作すればできるようになってきた。なぜそれができるようになったかというと、一つはクラウドコンピューティング、もう一つはオープンソースツールです。この二つがここ数年で急速に進化したために、誰もが簡単にデータ分析の「操作」ができるようになりました。
ここで改めて、データ分析に必要なのは、①適切な課題の設定、②その課題を解決するためのデータ集め、③これらを処理する道具とその操作、この三つ。昨今のデータ分析や機械学習、AIの流行は、このうち③がめちゃめちゃ楽になったことに寄ります。
但し、楽になったのは③だけであって、実は分析が簡単になったわけではないです。データを分析する、とは、そのデータをなんらかの意図を持って選り分けたり、そこから何か情報を引き出したりする操作のことで、何をしたいかが明確でないとそもそもデータ分析はできないし、何をすれば目的を達成できるかを知らなければ道具を引っ張り出すこともできません。建築で例えると、ビルを建てるための設計や実際の建築は楽になったのですが、そもそもどんなビルを建てたいのか、そのためにはどんなコンセプトで設計すればいいのか、最終的にどんな付加価値を入居者に提供するのか。データ分析も同じで、そういった大きな道筋は相変わらず誰か人間がセットしなければなりません。
もう一つ難しいのが、②のデータ集めです。データ分析の操作（③）は簡単になって、担当者自ら、もしくはデータサイエンティストを連れてくれば、分析の道筋（①）を立てることはできる。では、データはどうするか。ビル建築で言うところの、材料をどうやって調達するか。実際のデータ分析ではこれが困難を極めます。いくら③の道具が良くなっても、そこに流し込む肝心の②データの品質が悪ければ、どれだけ計算機をぶん回しても目的は達成されません。ですから、データサイエンティストは（①は実施の前提として）②に非常に力を入れるわけです。美しいデータを作れれば、データ分析は終わったも同然です。
では、②には最近の進化はなかったかというと、これが2003年頃から流行したビッグデータです。最近はもうデータがどれだけ巨大になってもビッグデータとは言わなくなってきましたが、バズワードが使われなくなった頃からが本当の価値が見えてくる時期。インターネットで繋がった様々な機器が、人の行動の様々な断面をデータにして送信し、蓄積し続けるので、とにかく大量にデータが集まるようになりました。もう一つ、ビッグデータと並んで最近進化が著しいのがオープンデータです。10年前には考えられなかった量と質のデータが、最近はネット上にごろごろ転がっています。
しかし、これらのデータ、素材のままではゴミと変わりません。どれだけあってもゴミはゴミ。どこかの先生が仰っていた、「garbage in, garbage out.」という言葉が私には非常に印象深く記憶されていますが、ゴミデータをいくら分析にかけてもゴミしか出てきません。そのデータがゴミか、ゴミじゃないかを選り分けるのは、①の課題設定にあります。①適切な課題設定をして、それに必要かどうかという目で②データを選り分けることで初めて、ゴミではない貴重なデータの原石が見つかり、さらにこれをピカピカに磨き上げることで（データクレンジングと言います）、分析のためのデータになります。あとは③のボタンを押すだけです。
ようやくここに辿り着きましたが、データエンジニアというのは主に②を担当する人です。これまではデータサイエンティストが①と②と③を全部まとめてやっていましたが、それでは費用がかかりすぎる（笑）。③がテクノロジーで乗り越えられた（実際には完全に乗り越えられたわけではないです）ので、次は②を乗り越えようと。データサイエンティストは①を中心に、②と③のとりまとめに注力してもらって、もっとも体力のかかるところを専門化して切り出しましょうというのがデータエンジニアのコンセプトです。
もちろん、③と同じように、この②をテクノロジーで乗り越えようとした取り組みはたくさんありました。データ分析プラットホームとか、データウェアハウスのデータ分析版とか、システム開発案件として多くの取り組みが成されたと思います。しかし、それらのどれだけが成功したかというと、成績は芳しくない。それはなぜか。
それは、データ分析が「システム開発」とは異なる価値観の仕事だからです。システム開発は、綿密に設計された仕様書に基づき、完全で堅牢な仕組みを作り上げることが仕事ですが、データ分析はそうではない。なぜなら、データ分析は未知の事象を目的にするから。データ分析の目標がまだ見ぬ未知の事象なのに設計図など書けないし、ましてや仕様書に落とすことなど不可能です。データ分析は常に新しいアイデアを迅速に数式化して試す、上手くいかなかったらまたアイデアをひねり出す、その繰り返しなので、システム開発視点で作られたデータ分析プラットホームが機能するわけがありません。（注：分析された結果を自動化、横展開することを目的としたシステムを「データ分析システム」と呼んでいることはあって、それはちゃんとしたシステム開発なので問題ありません。）
だから、②は道具だけでは乗り越えられません。そこには必ず、人が必要になる。それがデータエンジニアです。データサイエンティストが今まで①も②もやっていた仕事のうち、データを集めてきれいにするところを切り出して担う「人材」として②を考えると、データエンジニアリングという仕事になります。
最初に戻りますが、というわけで、SIerさんと話をすると、データ分析プラットホーム案件をシステム開発として受けてしまうと、結局使われないシステムができてしまうというところで盛り上がりました。作る方だって当然、使われないシステムを作るのは楽しくない。どうせ作るならちゃんと使われて、お客さんにも喜んでもらえるものを作りたい。これはプラットホーム構想自体が間違っているわけではなくて、作り込んでしまうから分析に使えなくなってしまうんです。ということは、システムは作り込まずに、柔軟に対応するところは人手に任せて、それをサポートする部分を機械化すればいいじゃないか、というのがデータエンジニアのポジションになります。