分析者、意思決定者から見た「理想のデータ整備人」とは？ 2020/5/14 中村仁也（株式会社ゴーガ解析コンサルティング） 第3回 データアーキテクト（データ整備人）を”前向きに”考える会

自己紹介 2 2000 2010 2020 AWS(EC2, S3) Cloud Computing windows95 MapReduce → Hadoop amazon.com amazon.co.jp Google 複雑系 Big Data 流行 iPhone 3GS Google Analytics(Urchin) 2005 2015 GPSケータイ omniture, SiteCatalyst 社会シミュレーション PS2 並列コンピューティング 数学 数値解析, データ分析 大学院 銀行系シンクタンク データ分析コンサルティング 独立 データ分析専業 Google Cloud Platform Google App Engine MS Azure Big Query IOT AR AI, Deep Learning 機械学習 “データサイエンティスト” 年表はテキトーです。 整数論 原子力, CO2, 交通, HPC マーケティングリサーチ, エージェントシミュレーション, 最適化, 数理計画, ・・・ 広告業界, 官公庁, インフラ, 製造業, ・・・ → Big Data後 Big Data前 ←

概要 • 前半 • データ整備人、データエンジニアの定義、データエンジニアとは何か？ • 後半 • 理想のデータ整備人＝データエンジニアとは 3

まず、「データ整備人」の定義 • 「データ整備人」とは？ • しんゆうさんの定義 （ https://speakerdeck.com/shinu/maemuki-data-seibinin01 ） • 私の定義 以下、「データエンジニア」＝「データ整備人」です。 4 システムエンジニア（の役割の一つ） データエンジニア

「データエンジニア」 定義の理由 • データエンジニアの「データ」とは何か • 従来の「システムエンジニア」に対して、「データエンジニア」は何が違うのか？ • わざわざ名称を変える理由は何か？ • システムエンジニアとは？ • 定められたRFPや仕様に対して、“完璧”な情報システムを構築することを目的とする技術者 • 対する「データエンジニア」は？ • データを扱えば「データエンジニア」か？ • 情報システムはそもそも「データを素早く、的確かつ完全に回す」仕組み。 • データエンジニアという言葉が生まれる前から、情報システムは既に大量のデータを扱っている。 • 仕様になってしまえば、それを「データエンジニアリング」とは呼ばない。 • いつごろ生まれた？ • 今世紀に入ってからよく耳にするようになってきた。 • 「データ分析」に高度な情報技術が必要になりはじめてから？ビッグデータ以後？ 5 注：もちろん、初期フェーズではそれを作る仕事もありますが。

今なぜデータエンジニアか？ • ビッグデータ前 • 情報量が少ない時代 • 集めるだけで意思決定に使えた。 • 情報を持っていることが優位。情報落差＝価値。 • 情報を持っている人が、一人で抱え込む傾向。 • 少ないサンプルや実験で意思決定しなければならない。統計学の発達。 • 統計学＝意思決定の数学 • 集めるところに困難が集中する。 • 集めてしまえば意思決定者、分析者のみでほぼ完結できた。 • ビッグデータ後 • 使える情報が爆発的に増加 • 意思決定者や分析者が取り扱えない量、データの多様性、種類の増加 • 高度な情報ツールを使いこなせると、優位に。 意思決定者や分析者の負担を軽減し、組織的にサポートする体制が必要になってきた。 6

データエンジニアの役割 • データエンジニアの役割 • 目的は「データ分析」、及びその後ろにある「意思決定」 • 専業化 ← データの取り扱いに、高度な技術を要するようになってきたから。 7 データ分析 データ分析（Before Big Data） データ データ分析 データ 意思決定 意思決定 紙と電卓, Excel, SQL, … 旧来の情報技術 データ分析（After Big Data） 確認, 集計, 可視化, 加工,… 分析支援 意思決定支援 巨大なデータ, 複雑なデータ データエンジニアの役割

データエンジニアとは？ • システムエンジニア • 仕様があって、それに向かって確実に作る人。 • 分析者、意思決定者 • 目的があって、それに向かって様々なことを考え、試し、または決断する人。 • 仕様はない。分析結果が確実にわかっているならば、それを分析とは呼ばない。 • 正解が確実にわかっている意思決定は、意思決定とは呼ばない。 • 不確実性のある事象に対して、トライ＆エラーを繰り返しながらアプローチする。 • データエンジニア • データ分析や意思決定を、データ及びそのハンドリングの面から支援する人、組織 • データエンジニアリングの本質も、不確実性 • 仕様の無い、柔らかい状態のリクエストに応え、支えるのが、データエンジニアの役目。 • 仕様を確実に実行することが求められているならば、データエンジニアリングでは無い。 8

後半：理想のデータエンジニアとは • データエンジニアの役割は、分析者、意思決定者の支援 • 彼らは何をやっているか？ • 分析者、意思決定者のやっていること • 入力に対して、考えて、意思決定（支援）を行う 9 観察 想像 仮説 検証 探索 入力 意思決定 思考

考えるモードにおいて、最も大切な要素＝スピード • 「スピード」は武器 • 気づきの連鎖を起こすことが、想像力を爆発的に膨らませる方法 • ビッグデータ後 • 膨大多様になったデータから「気づき」を裏付けるデータをすばやく取り出すことが優位性。 • 分析者、意思決定者だけでは困難 • システムエンジニアは目的が異なる。 10 観察 想像 仮説 検証 探索 入力 意思決定 SPEED データエンジニアの出番

スピードアップのための三要素 → 理想のデータエンジニア • データを知る • そのデータを最もよく知るのは、データエンジニア • 日頃からデータに親しみ、すぐに何でも答えられる。 • どこに、どうやって取得された、どんなデータが、どのような状態で、存在するか • どうすれば手に入るか、操作できるか • データを出す • 可視化や加工の方法を熟知し、意思決定者や分析者がほしいものを素早く出す。 • 最新のツールを熟知し、最も速い方法で出す。 • 出したデータの「雰囲気」がわかる。ミスに気づく。 • コミュニケーションとイテレーション • 相手の目的意識を共有し、相手の言葉で話す。 • やわらかいリクエストにすぐ応え、手戻りしながら調整する。 11

（最後に）データエンジニアの活躍シーン 12 データエンジニア 意思決定者 分析者 システム エンジニア 意思決定者の右腕 ・データについて何でも知っている。聞けばすぐ返事が返ってくる。 ・異常事態をいち早く察知し、教えてくれる。 ・会議等で、話題に応じて即座にデータを切って見せてくれる。 分析者のパートナー ・分析者をデータから解放し、統計やモデルに専念させる。 ・意思決定者からの要望を翻訳する。 システムエンジニアとの接続 ・意思決定者や分析者の柔らかい要求を翻訳する。 ・定常的になってきたデータ抽出・加工は、折を見てシステム化する。 データ

（参考）データ分析、データ分析者側の変化 • データエンジニアがいると、データ分析はこう変わる • リードタイムが短くなる。 • 分析の時間の半分は、データ理解とデータ整備に使っている。 • 普段からそのデータに慣れ親しんでいるデータエンジニアがいれば、いろいろ教えてもらえる。 • 多くの案件でデータ分析者の関与が不要になる。 • 集計可視化で十分な案件が多い。 • 「AIで」という前に集計可視化。 • 日々の運用はデータエンジニアが担い、分析はアドホックで調達する。 • 日々やることは沢山ある • データ整備、モニタリング、既存データの理解、あたらしいデータの調達・・・ • データエンジニア自体が目的意識を持っているので、簡単な分析はできる。 13

（参考）意思決定者側の変化 • データエンジニアがいると、意思決定はこう変わる。 • 重要な会議に必ずデータエンジニアが参加する。 • 会議資料にあるすべての表やグラフにはクエリがくっついている。 • データについての疑問にはその場でデータエンジニアが答える。 • 会議中のリクエストに応じてその場でデータを深掘りし、可視化、確認する。 • 日頃から意思決定に必要なデータが整備、モニタリングされている。 • 「あれは？」と言った瞬間に出てくる。 • 指示されたデータだけでなく、関連する、役立ちそうなデータがおさえてあり、短期間で出てくる。 • 異常を感じた場合、アラートを出す。システム的には検知できないアラートも検知する。 • そのために何が必要か？ • 「技術」1/3 • 最新のテクノロジーをキャッチアップし、常にスピードアップ方法を考える。 • 分析者、システムエンジニアとの対話のために、統計やシステムエンジニアリングの勉強を怠らない。 • 「アソビ」1/3 • データに慣れ親しむには、日頃からいろんな角度でデータを見ていなければならない。 • 自分やチームで、「仮説」→「検証」を普段からやっておく。 • 日頃から外部の情報収集に努める。 14