参加イベント
下記のイベントにブログ枠で参加させていただきました！
第2回 データアーキテクト（データ整備人）を”前向きに”考える会
※2020/03/03 ぶんけいさんのスライドを追加しました
主宰グループ
ShinU さんの運営するconnpassのグループです。
ちなみに当該イベントは下記画像の通り競争率3倍近くになる注目っぷりで、現地はかなり賑わっていました。
会場
株式会社エウレカ様のオフィスのイベントスペース？で開催されました。
壁がすでにおしゃれ
セッションスケジュール
イベントページから抜粋
| スタート時間 | 内容 | 発表者 | テーマ |
|---|---|---|---|
| 19:00 | 開場・受付開始 | ||
| 19:30 | 開会 | しんゆう | 趣旨説明 |
| 19:35 | スポンサートーク | t-kurimura | EurekaのDataPlatform開発状況と"再現性"の実現 |
| 19:45 | Talk1 (15min) | しんゆう | 抽出や集計の依頼を受ける時に気を付けていること |
| 20:00 | Talk2 (15min) | mida | データエンジニアとデータアナリストを兼任して良かったこと |
| 20:15 | Talk3 (15min) | sotaron | データの価値を失わないための Data Reliability Engineeringについて |
| 20:30 | Talk4 (15min) | ぶんけい | 意思決定に繋がる Intelligence とは |
| ~22:00 | 懇親会 | 参加者全員。22:00時まで |
内容・感想
感じたこと、理解したことを記載していきます。
趣旨説明 by しんゆう さん
オープニングは主宰のしんゆうさんから簡単なあいさつと趣旨の説明。
データを整備・抽出・加工したりダッシュボード作ったりとエンジニアとアナリストの間にある「誰かがやらないと別の誰かが困るのに、なぜか誰もやりたがらない役割」であるデータアーキテクト（データ整備人）のスキル・ノウハウ・キャリアなどについて、恨みつらみではなく”前向き”に考えようという会です。
なにかと無茶ぶりやら板挟みにあいやすいデータ整備人、でも前向きに考え方などを共有していこうという位置づけです。
EurekaのDataPlatform開発状況と"再現性"の実現 by t-kurimura さん
スポンサートークとして、会場を提供した株式会社エウレカのt-kurimura(twitter:@t_kurimura)さんより、エウレカ内のDataPlatformの開発状況についてのトーク。
はじめに会社と代表的なプロダクトであるPairsについてのご紹介
Pairs
いわゆる婚活、恋愛のマッチングサービス。
「Pairs」は、日本と台湾、韓国で合計1,000万人以上が利用する、恋愛・婚活マッチングサービスです。25万人からの交際・入籍報告が届いております。業界初の24時間365日オペレーター常駐体制で24時間365日のテキスト・画像投稿監視により、安心・安全に利用することができます。
今や日本国内のみならず、アジアにおいても少子化・晩婚化・非婚化が深刻な社会問題となり、国内の独身男女の「恋人がいない」割合が70%を超える一方で、米国では既婚カップルの3組に1組がオンラインデーティングサービスをきっかけに出会っているというデータがあります。こうした状況を踏まえ、私たちは日本発のマッチングサービスとして、オンラインデーティングを活用したパートナー探しのカルチャー作りに取り組み、1人でも多くの人が自分らしい生き方ができる社会の実現を目指しています。
提供するサービスをよりよくするためにDataplatformを構築しています。
Data platformについて
全体構成
AWSで収集・オーケストレーションし、データ基盤としてはGCP中心といった構成でしょうか。普段Azure使いの私には新鮮に映ります。ナチュラルにハイブリッドクラウド構成
変遷
発足期から繁栄期に至るところで、乱立したViewQueryをAirflowで管理し、「公式化」を実施したそうです。
公式化することにより、分析の再現性を高め、各自のデータ定義・解釈の統一化を図ったと。
必要なときに必要なデータを取り出す、いわゆるデータ価値を高めるための打ち手が公式化なわけですね。
分析開発フロー
そんなわけで、エウレカ様内ではアナリストが要求するデータを取得するためのクエリをViewで簡易的なデータマートとしてから、利用状況などを加味して物理的にデータマート化するようなフローで回しているそうです。
性能はさておきスキーマ変更を柔軟にして分析の要求に答えやすくしてから最終形を模索する、ということですね。私自身も短期にプロトタイプを作成する際には身に覚えのある進め方です。
さて、エウレカ様ではさらに一歩踏み込んでいました。
###GCPの監査ログの活用
簡易データマート→最終形にいたるにあたり、どのような組み合わせ、頻度で提供したViewがクエリされているかを監査ログから分析して決定しているそうです。
まさにデータ駆動な開発で、感銘を受けました。
###UDFの活用
もう1点、面白かったのは、UDFにコードの意味を記載し、ヘルプのような関数を作って、意味がぶれない仕組みを作り、データの再利用を促進している点でした。
また、関数はGitからSQLファイルをあげれば自動デプロイされるようにして、メンバーが関わりやすさについての工夫もされています。
Gitでのコラボレーションがデータディクショナリ的な部分にも使えるというのは非常に面白いです。
しょっぱなからこんな話が聞けるとはと、いい意味で予想を裏切られる思いでした。
発表後の拍手がなんだか温かく感じる雰囲気だったのも面白い
抽出や集計の依頼を受ける時に気を付けていること by しんゆう さん
続いて主催者であるしんゆうさん（twitter:@data_analyst_）のトーク。
フリーランスのデータアーキテクトだとか。どんな感じでお仕事をしているのか非常に気になるお方です。
依頼を受ける際の基本戦術
全体を通して、SEの私にはあるある、わかるの連続となるようなお話でした。
私の理解としては下記の３点でした。
- 顧客の要求の本質を探る
- 緊急度、優先度による納期確認
- 依頼に対してレビュアーとして臨む
####依頼をきちんと聞く
顧客はデータ分析がしたいのではなく、データを使ってなにをしたいかが重要であるということを話していました。
また、相手もこちらの仕事を知らないから無茶ぶりだったり、難しく考えてたりすることもあるというケースでの対応についてはぶっちゃけた意見をまっすぐ発信していたのが印象的でした。
####納期をとにかく確認する
なるはやという言葉が出て、うなづく人が多数おり、この界隈の方々が苦労が垣間見えました。
経験的には「あればうれしいがいつでもいい」はほぼ問題にならない、というなんだか心強い言葉も。
依頼もデータも鵜呑みにしない
これは非常に気をつけたいことです。要求通りに作ってもうまくいかないケースは非常によくあります。
私の感覚では顧客自身もやりたいことを表現しきれないから、ヒアリングがあると思います。（表現できてたらむしろすごい）
結局依頼から結果を出すには要望から要件の抽出、ビジョンの理解が重要と感じました
身近な感覚を素直に言語化する方でした。
最後に分析のためのSQLの勉強サイトを紹介されてましたので、ここでも載せておきます。
DI-SQL データ分析のためのSQL
データエンジニアとデータアナリストを兼任して良かったこと by mida さん
midaさんはJapan Taxi株式会社様の中の人で、エンジニアとアナリストを兼任されているそうです。
会社公式サイト
さて、Japan Taxi様といえば配車アプリですね。ちょくちょくお世話になります。日本版Uberというイメージ。
Japan Taxi様ではアプリ内データおよびタクシー側端末の出力データを分析してサービス改善をされているとか。
Japan Taxi様内にはAIチームとBIチームがありmidaさんはBIチームだそうです。
構成はAzure AWS GCPのハイブリッドです（！）
分析はGCP ストリームはAWS アプリ用DBがAzureというまたもやナチュラルにハイブリッドクラウドな構成。ささっといいとこどりするようなアーキテクチャ組んでてすごいなあ
###それぞれの職務と要求、データの流れ
分析システムにおいて、データは下記のように流れます。
データソース→データレイク→DWH→DM→分析ツール→人
また、分析の要求は逆の流れで下記のようにあがってきます。
データソース←データレイク←DWH←DM←分析ツール←人
その際、それぞれの矢印と対象には
データソース→データレイク→DWH→DM→分析ツール→人
プロダクトのエンジニア-データエンジニア-データアナリスト-意思決定者
といった登場人物が出てきます。
データエンジニアとデータアナリストはそれぞれ得意分野が違うので下記のような状態で問題が発生するとか。
データアナリストにエンジニア力がない
エンジニアリングは本職ではないので、列が足りないとかの際にデータエンジニアに依頼しないと分析ができません。また、その難易度だったり依頼の仕方もエンジニア力が問われる部分かと思います。（ちょっとしんゆうさんの話を思い出しますね）
データエンジニアに分析力がない
逆にエンジニアはビジネスにおけるドメイン知識が浅いために複数のアナリストから依頼を受けた際に、横断的にプロダクトを俯瞰できれば本当はもっといい分析ができる場合であっても気づかないケースが発生します。
なにが起こる
midaさんはこの２者のやりとりにおいて、それぞれの理解しているドメインが違うために、齟齬が起き、手戻りが起こりやすくなり、常態化すると、インパクトの小さい分析は軽視され、企業全体がデータ駆動な仕事ができなくなってしまう危険を指摘していました。
兼任のメリット
midaさんは兼任によって職能の違いによるコミュニケーションロスが減らせるといいます。
さらにそういった立場を続けていると、なにをするにも彼に聞こうというような、分析基盤のエンドポイントとしての地位ができあがるそうです。
これもまた身近な話で、弊社はDWHの構築～可視化のお手伝いをすることが多く、エンジニア寄りの兼任者をすることが多いです。
会社のメンバともこの話をしましたが、データ基盤にかかわる以上は両方のスキルがいるというのは誰もが思うところでした。
兼任のつらさ
ただし、兼任することでウォッチする範囲が広がり、単純に負担が大きくなるのも事実で、midaさんはうまく配分とウェイトを考えているそうです。
組織で動く以上は専門家のチームを組むことになると思うので、それぞれが専門と次点のスキルをもつのが理想なのかなと思ったり。お隣さんと同じプロトコルで話すスキルの重要性を再確認しました。
データの価値を失わないための Data Reliability Engineeringについて by soraton さん
SREならぬDREについてのエウレカ様内での取り組みについての soratonさん(twitter: @__sotaron__)のトーク。
個人的には最もときめく題材でした。トーク内の雰囲気もよかった（謎のアラートが鳴ったり、会社の求人案内が重要といいつつ機材トラブルで映らなかったりのミラクルは全部笑いに変えてました）
スライド
'余談ですが、スライドが海外のプレゼンっぽい構成でかっくいい
SRE
少し前から有名になっているスタイルですね。
サイト・リライアビリティ・エンジニアリング（英：Site Reliability Engineering、略：SRE）は、Google社が提唱、実践しているシステム管理とサービス運用の方法論である[1]。サイト信頼性エンジニアリングと訳される場合もある。また、サイトリライアビリティエンジニアリングを担当するエンジニアをサイトリライアビリティエンジニア（SRE）と呼ぶ。
サイトリライアビリティエンジニアリング
https://speakerdeck.com/tanakarian/detafalsejia-zhi-woshi-wanaitamefalsedata-reliability
DRE
いきなりもってかれたのはDMBOKによるデータの価値について触れていたことでした。データマネジメントガチ勢だ！
まじでニッチな領域だと思ってるので、理論ましてや実際の取り組みの話を聞けるのはこの場しかないんじゃないでしょうか。
データ品質のサービスレベル
さて、簡単にデータの品質について説明があり、具体例として、3つのケースを挙げていました。
-
新機能のA/Bテストで、特定条件下でログが発生しない
データがそろっていないと意思決定のための情報が偏ってしまう例です。否定的な情報だけが欠損していたら、誤った意思決定をしてしまう恐れがあります。 -
ある施策後、関連のデータ処理が遅延した
正当な評価ができず、常態化すればPMからは使えないデータとみなされてしまいます。 -
バッチ処理のエラー対応
深夜にこけたバッチをエンジニアが頑張って直しても、実はアナリスト側はこけることを認識していて、それほど重要なバッチでもない、というケース。つらいですね
soratonさんはこれらはサービスレベルがないから起きる問題だと指摘し、DREの必要性を訴えます。
SRE,DBRE,DRE
既存のSRE,DBREとは似ているが違うとか。たしかにデータの品質という観点ではないですね。
同じ信頼性エンジニアリングなんだけど、データ品質にまつわる信頼性エンジニアリング＝DREなわけですね。
信頼性エンジニアリングを支える仕組みとしてDevOpsもいます。最新のカルチャーをガンガン実際に落とし込んでてどんどん引き込まれます。
Ops（データエンジニア）と、Data/Analyse(データアナリスト)をうまく接続し、アナリストとエンジニアが共同で動く必要があります。データも体制もサイロ化しないように。
DREロードマップ
なにはともあれサービスレベルを設計し、観測な状態にし、監視します。そこからは改善と監視のサイクルが回りだします。
サービスレベル設計
ユーザの使える/使えないをベースにしているそうです。
以下の書籍が参考になるとか。とりあえずポチります。
観測な状態にする（可観測化）
監視のためのツール、構成管理のためのツールを適切に利用して、継続的に観測可能な状態を構築します。
（事業でアプリ開発しているところは本当に技術力が高い。。）
管理 - DataDOG
構成管理 - いわゆるIaC（Terraform、Packer、ANSIBLEなど）
エウレカ様内でのDRE
そんなわけでエウレカ様内ではDREを実践するための知識を整理しつつ実践しています。
重要レポートを中心に移行検証や、更新状態のチェック、DREのための定例MTGをしているそうですが、ここは手探りのようです。
聖典、ほしいですね。。
意思決定に繋がる Intelligence とは by ぶんけい さん
最後はAmazonジャパン様の中の人、ぶんけいさん（twitter:@bunkei_DA）のBIについてのトーク
笑いの絶えないトークでした。。
関係ないけどAmazonの人は無地のニット率が高い気がする。
###冒頭
参加時のアンケートの集計結果を見える化した結果、エンジニアにチェックをつけた人は「なにを持ち帰りたいか？」という質問に対して、ほとんどが無回答であることがわかり、爆笑とともに処刑されました（私もたしか無回答。。）
twitterも初心者とのことで、Follow:Follwer 0:0の状態で参戦表明し、またも笑いを誘っていました
また、余談ですが、ぶんけいさんの当日のセッションについては「なお、このプレゼン内容は個人の見解であり、所属する組織の公式見解ではありません」とのことでしたが、ふしぎなちからによってAmazon社のPRは成功し、セッション後は参加者の皆さんがAmazon社の企業理念を理解していました。
※段ボールの笑顔の裏とは
さて、ぶんけいさんの経歴は興味深く、経産省(Excel)→マーケ（SPSS）→アドテク（BigData）→現BI関連職とのことで、アドテクあたりではじめてBigDataを分析するようになったとか。（記憶ベースで間違ってたらごめんなさい）
スキルとしてはBiz,Eng,Sciの３象限でいうところのBiz寄りの人
Biz観点のデータアーキテクトの話
ということでBiz観点でのお話をしていただきました。
ぶんけいさんのプレゼンのスタイルは数字からはじまることが印象的でした。まさにデータアーキテクトなプレゼンです。
IT人材とデータの増加
IoTなど、テクノロジの進化によりデータ量は飛躍的に増えてるが、日本のIT人材が極めて少ないことを指摘します。
現状の日本のIT人材は社会人全体の約3%であり、組織としてはどうしても小さなものとなり、経営活動の規模も社内では小さいものとして扱われます。
「#TeslaがGAFAに仲間入りする10の理由」を引用して世界的企業はトップがコンピュータサイエンス出身のエンジニアばかりであり、そういった企業ではエンジニア、サイエンティストの意見が取り入れられやすいためにデータ駆動経営が成り立つ背景となっています。（最近のなんかのまとめでもTop10のうち7,8人は工学部というのを見た覚えがあります。）
そのようにデータの価値は認められていますが、日本ではトップは基本的にエンジニアであることは少ないため、需要はあるはずなのに、価値を発揮する機会が少なくなり、組織としての投資が少なくなりがちな状況があります。
###ではどうするか
転職、はおいといて、組織の壁を越えるような働きが必要です。
そこで、目を奪う、人を動かすためのインテリジェンスについてのお話が始まります。
フィクション題材について聴衆に思考させるスタイル。
###フィクションです
よくある話で、万引きによる損失が問題となり、上司から「なんかとりあえず見える化」してみてと振られるケースです。
失敗例
データを様々な軸（商品分類、店舗など）で集計してみる
→「もっとなんかいいのない」
もっとサマリする。もう品目グループだけでかわいい絵をつける
→そぎ落とされ過ぎてなにも洞察（Insight）が得られない・・
これがわかってどうする、という情報の羅列で、Bizサイドからは何も意見や業務ドメインの知識が生かせないわけですね。
####成功例
ある日なんとなしに店舗の情報に規則性があることが指摘されます
→店舗レイアウトを入手し、ヒートマップに落としたところ、突然Biz側から活発な意見が（なぜか立ち上がる、万引きの分析してるのに笑顔まで飛び出す）
そこからはヒートマップを店舗ごとに並べてみるなどして、トイレの近くや、駐車場の近くなど特定の場所に多く発生していることがわかり、警備の巡回を変更するなどの施策が打たれます。
つまり、Bizから分析アイデア、打ち手のアイデアが出たわけです。
この時、分析者が付与した価値は複雑なクエリを書く、やデータの量を増やすなどではなく、泥臭く、
- フロアマップを集めた
- ひもづけ
といったことをしただけです。現地に足をはこんだ数時間の作業はデータ整備の時間に比べると小さなもので、重要なのは表現を工夫（直感に訴えるレポート表現）したことでした。
###Insight+Intuition→インテリジェンス
我々データ分析の人々が価値を出すにはインテリジェンスが必要ですが、インテリジェンスはBIを使えば身につくのではなく、意思決定に寄与して初めて価値が出るというような主旨を感じました。
裏を返せば、意思決定につながらない限り、データ分析の事業は無（低）価値であり、この先も投資をしてもらえなくなるという危機感も。。。
ケーススタディでは、ビジネスをインテリジェンスするという活動において、洞察を行うだけでなく、意思決定者に直感的に訴えるような付与をすることがインテリジェンスを提供することにつながるわかりやすい例が提示されていました。
プレゼン全体はエンターテインメント的で非常に愉快なものでしたが、内容も経営活動を軸にとらえているように感じ、来てよかったなと思える素晴らしいものでした。（あとどこで画像探してるのか聞きたい）
#おわりに
非常にニッチな界隈で戦っている方々の生の話を聞ける貴重な会でした。次回も参加しようと思います。
ゆくゆくは自分のプレゼンにも生かしてなにか還元できたらいいなと思います。
ちなみに懇親会で出たハッピービールすごいおいしかったです。