下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・試行錯誤の瓦礫の記録

社内政治を通してデータ分析の精度を上げる

この記事は、データ活用 Advent Calendar 2018 - 13日目の記事です。

最初に結論

ステークホルダーからフィードバックを得ると、様々な因子を洗い出すことができる。 結果として、より筋の良い仮説を立てることができ、データ分析の確度が上がる。 それゆえに社内政治は、データ分析の精度向上の有益な手段となるのではないか!

もくじ

注意点

  • ポエムです。データ分析関連の飲みの場で盛り上がったネタなので投下します。
  • ステークホルダーは最低限の論理的な会話が成り立つ人物であることを前提としています。想像を絶するほど言葉が通じない人間や組織は現実に存在するので、そういう場合は早く逃げたほうがいいですよね。
  • 金融機関のクオンツやアドテクの配信最適化のように、最初から最後までデータだけで完結する世界の仕事には当てはまりません。分析というかデータマイニングですね。その手の仕事であれば社内政治という言葉を使う余地はないんじゃないかなと思います。「社内政治とデータ分析」という言葉にピンと来る人のコンテキストを前提とします。
  • 本来はデータ分析という業務自体が「統計解析に集中する人」「データを整備する人」「分析をディレクションする人」といった感じで役割を分担しうるものなのだろうなとは思います。本エントリーで「統計解析に集中する人」を否定する意図はありません。

前提

データ分析とは

推論と予測とあるけど、まとめると y = ax + b みたいな近似モデルを作ることだと解釈できます。 ある要素と別の要素がどのような関係にあるのかを紐解く行為だと言えます。 どの広告媒体にいくらのコストを投下したら、どのくらいの顧客を獲得して、どのくらいの売上になるのか、といった具合ですね。

社内政治とは

ステークホルダー全員から「それで行きましょう」という合意を得ることだと言えます。 合意形成に失敗すると、必要なデータを得られないとか、分析結果がアクションに繋がらないといった悲劇が起きます。 その辛さを味わった人は「この組織には社内政治が必要だ」と言いたくなってしまうわけです。

足を使わないデータ分析のあり方

手元のデータをこねくり回して統計ソフトを叩くわけですね。 いわば職人のように閉じこもって新事実を発見するサイエンティスト。 データ分析という言葉から多くの人が最初にイメージするのはこの姿ではないでしょうか。

足を使うデータ分析のあり方

必要なデータを得るために関係部署に声を掛ける。 仮説の筋が良さそうか、解釈や予測結果が妥当と言えるか、業務に詳しい人に相談する。 まるで営業のように足繁く現場に通うスタイルです。

分析には仮説と検証が必要

『バッタを倒しにアフリカへ』という本があります。面白いです。 文字通りバッタを研究するためにアフリカに滞在した話です。 極端な例ではありますが、それゆえにこの本から学べることがあります。

科学者(サイエンティスト)が研究する流れは

  • 観察して仮説を立てる(砂漠のバッタは高めの植物にぶら下がっている→天敵から逃げやすいからでは?)
  • 実現可能な検証方法を考える(高い植物がない地域と比較したら?群れで天敵を恐れない状態と比較したら?)
  • 必要なデータを取る(アフリカを走り回って記録)

ということで、いずれも研究室に閉じこもるよりも、現場に出向いたほうが筋の良い結果になるんじゃないかということです。1

バッタを倒しにアフリカへ (光文社新書)

バッタを倒しにアフリカへ (光文社新書)

合意を得るくらい情報収集をする

話を戻します。 データ分析に限らず合意形成を行う際にはステークホルダーの利害関係を確認・調整することになります。

実際に何をやるかというと、内容自体は「研究の進め方」と同じです。 ステークホルダー1人1人の立場や情報を洗い出すのです。 まるでアフリカ中を走り回ってバッタを観察するように。

分析屋は何を分析するのか。 ステークホルダーの誰かがアクションを取るための予測。 あるいはすでに取ったアクションにまつわる推定。 そういうデータ分析をするわけですよね。

手元のデータだけだと y = ax + b という分析結果になる。 だけど担当者にヒアリングすると、新しい情報を入手して y = ax1 + bx2 + c というモデルに刷新できる。 持っている情報量が増えることで、仮説やモデルの精度が(解釈の説得力が)上がるのではないでしょうか。

仮説構築のための情報収集、実現可能なアクションの検討、分析に必要なデータの収集。 サイエンスのステップを踏むためには、業務の担当者へのヒアリングは避けて通れないはずです。 そして情報を引き出すにはそれなりにコミュニケーションを取らざるを得ないのではないでしょうか。

そのコミュニケーションを通して必然的に合意形成ができるのではないかと思います。 筋の悪い仮説にもとづいて分析を進めようとすると、担当者から「それは違う」といったツッコミが入るはずです。 「なぜ違うのか」と深堀ると、新しい事実が見えてくるか、あるいは単に担当者の思い違いであることが可視化されます。 その情報収集を突き詰めていくと「その通りだね」と相手が同意するところに着地するのではないでしょうか。

意外な因子を洗い出す

業務と無関係だと思っていた部署から反対意見が出ることもあるでしょう。 ついつい「これだから社内政治は面倒臭くてクソなんだよ」と言いたくなります。

が、その場合は「関係する因子を洗い出せていなかった」と好意的に解釈できないでしょうか。 予期せぬバッタの行動を目撃するようなものかなと思います。 むしろ「新しい発見のチャンスだ」とポジティブには捉えられないでしょうか。

あらゆる業務は繋がっているものです。 ある部署のアクションが他の部署に影響を与えるのは、よくある話だと思います。 そういう一見して分かりにくい事実を探り当てることは、むしろデータ分析に期待されることの1つだとは言えないでしょうか。2

表面的な分析だからツッコミが入った。 正確なインサイトを得るためには、そっちの部署についても深堀る必要がある。 それならあっちの部署も。 だったらこっちの部署も。 そんなことをやっているうちに、結果として必要なステークホルダーと合意形成はできるのでは、と思うわけです。

まとめ(再掲)

ステークホルダーからフィードバックを得ると、様々な因子を洗い出すことができる。 結果として、より筋の良い仮説を立てることができ、データ分析の精度が上がる。 それゆえに社内政治は、データ分析の精度向上の有益な手段となるのではないか!

だから?

どんどん足を使っていきましょう!!!

最強のデータ分析組織 なぜ大阪ガスは成功したのか

最強のデータ分析組織 なぜ大阪ガスは成功したのか


  1. ちなみに私の指導教授はこのスタイルで、各国の金融機関にヒアリングして実証データを得て論文を書きまくっていたので、私の中では一流の研究者と言うとこのイメージでした……。

  2. まぁ実務上はデータで解析するよりもヒアリングベースで動いたほうがこういうのは早そうだと個人的には思いますけどね。

私の考えた最強のログ&モニタリング設計

この記事はRecruit Engineers Advent Calendar 2018 - 8日目の記事です。

注意点

  • タイトルは煽りです。「新規事業におけるデータエンジニアリングの勘所」の方が正しいかもです。
  • クオリティというか記事の信頼度は、投稿時間がギリギリになってしまったことから察してもらえるとありがたいです。
  • 本エントリーの内容は個人的な見解であり、所属する組織を代表するものではありません。データの取り扱いは非常にセンシティブなトピックでもあるため気軽に発信すべきではないということは重々承知しております。もし誤りや考慮不足だと感じる点があれば、それは全て私個人の力不足によるものですので、どうぞ私個人当てにご指摘のコメントをいただけると幸いです。

もくじ

背景

機械学習を活用した新規事業(WEBサービス)をゼロから立ち上げることになりました。 そこで初期フェーズにおいて、どのようなログ・モニタリング設計が望ましいかを自分なりに整理しました。 なお、大人の事情で詳細は書けないので、曖昧な記述やフェイク情報を交えています。

まだ試している最中なので、確立したプラクティスではありません。 「もっとこうしたほうが良いのではないか」といったご意見をいただければ幸いです。

前提

まず前提情報として体制とシステムを提示します。 ログの取り方はシステムに依存し、そしてシステムのアーキテクチャは体制に依存するからです。

体制

f:id:yuzutas0:20181208233306p:plain

ビジネスチーム、開発チーム、機械学習チームの3つで考えます。 本来ならデザイナーやカスタマーサポートやマーケッターにも言及すべきだとは思いますが、あえてこの体制の切り方で説明します。

特筆すべきは機械学習チームです。 昨今のビジネスにおいて機械学習をどう活用するかはホットなテーマです。 現時点ではスキルがコモディティ化・普及しているとは言えず、体制はどうしても分かれてしまいがちです。1

ログやモニタリングを整備するデータエンジニアは、これら3つのチームと横断で関わる存在です。 可能であれば専任の推進者を1人置くことが望ましいでしょう。 全ての論点を理解できる必要はありませんが、各ステークホルダーの要求を整理できる人材だと話がスムーズです。

f:id:yuzutas0:20181208234012p:plain

ログやモニタリング、データ分析の観点から全体を見ると、要求・要件の抜け漏れや計画の不備に気付くこともあります。 そのときはプロダクトマネージャーならびにプロジェクトマネージャーにアラートを上げることになります。 一気通貫で各論まで踏まえて企画できるPMは普通の企業にはいないので、むしろ自分で大上段を整理するくらいの気概があると良いかもしれません。

f:id:yuzutas0:20181208234150p:plain

通常のシステム開発フローの場合、モニタリングや分析の不備に気付けるのはリリース後、最後の最後です。 専任者を置かず、開発工程の早い段階でデータ設計の品質を担保しないと、後工程に課題を押し付けることになります。 結果としてBuild・Measure・Learnというプロダクト検証サイクルの放棄に繋がります。

システム

f:id:yuzutas0:20181208234224p:plain

フロントのアプリケーション(iOSAndroid、WEB)、それぞれのBFF、バックエンドWebAPI、データストア、インフラ、機械学習サービスWebAPIを構築します。 ただし開発優先度としてモバイルアプリは後回しにします。 また、インフラ(GKE)、モバイルアプリ(Firebase)、データ分析(BigQuery)、マーケティング(Adwards)などのシステム連携観点を踏まえて、フルGCPで構成します。

開発スコープ

初期フェーズではユーザーが使うシステムのみをメインの開発スコープとします。 手間暇かけて内部向けシステムは最初は作り込まないということです。 また、決済システムのように、法的観点で考慮事項が多い機能・高い品質が求められる機能も、初期スコープから外します。

地方の中小企業を支援するECサイトで、売買手数料を取るようなビジネスモデルであれば、DBの売買データをもとにして手動メールで請求書を送るところから始めます。 この手の業務はフローを確立させるために検討しなければいけない事柄が多いです。 時間を掛けてシステムを構築して、いざ運用を始めたら「もっとこうすればよかった」という学びが山ほど出てくるものです。 そのため最初からシステムに全てを反映させず、運用を通して要件を磨き込みます。 ただし業務に必要なデータをBigQueryから取得できる仕組みは担保します。

機械学習WebAPIは分離

ECサイトの商品レコメンドであれば、ユーザーIDを受け取って、おすすめ商品リストを返すようなWebAPIを想定します。 あるいは商品掲載チェックの自動判定(不適切な商品・画像・テキストの登録を弾く)といったWebAPIも考えられます。

前述の通り、WEB開発スキルと機械学習スキルの持ち主は、現時点だと別チームになりがちです。 そのためモノリシックにまとめるのではなく、それぞれのチームが独自に磨き込めるようにシステムを独立させます。 ロジックを切り替えたり、ABテストを実施しやすいというメリットもあります。

最初のWebAPIでは未加工のレスポンスを返すことになるでしょう。 レコメンド機能ならランダムでアイテムを返してI/Oだけ担保する形になります。 というのも初期フェーズにおいては絶対的にデータが足りないため、機械学習が効果を発揮しにくいからです。

強いていうなら、想定される類似データで学習させたり、仮説をもとにしたルールベースのロジックから始めることになります。 プロダクトとしては機械学習の機能がなくても顧客がお金を払う価値や体験デザインを作り込まなければなりません。

ある程度データが溜まってきたらダークローンチを行います。 機械学習WebAPI(未加工レスポンスだけ返す)の本番リクエストログをもとにして、独立環境でシミュレーションを行います。 ユーザーには影響を与えずに、開発者や運営者が裏側で精度を確認します。 問題なさそうなら、まずは10%のユーザーを対象にして、カスタムレスポンスを返すようにします。 あとは徐々にシステムを実稼働させます。

データ基盤設計

こうした体制・システムを踏まえた上で、どのようにログ・モニタリングを整備していくか。 データの流れをもとにして各トピックにおけるポリシーと実行方針を述べていきます。

f:id:yuzutas0:20181208234259p:plain

なお、データレイク(元データのコピー)、データウェアハウス(業務ドメイン知識を反映した中間データ)、データマート(用途向けの加工済みデータ)の概念は区別して考えます。 ただしデータレイク・データウェアハス・データマートは全てBigQueryで管理します。 詳しくは以下のエントリーを参照ください。

yuzutas0.hatenablog.com

全体の設計ポリシー

ビジネスの勝ち筋を模索する初期フェーズにおいて、過剰実装・早すぎる最適化は回避します。 作り込んでしまうとシステムが重厚長大になってしまうため、ビジネスの期待するアジリティを実現できなくなるからです。 俗な言い方をすると「なるべく楽をする」ことが重要となります。 最低限の要求に対して迅速に応えながら、屁理屈をならべて徹底的にシステムをシンプルに保ちます。

データソース(ログ)

ポリシーとしては(無理のない範囲で)「取れるデータはなるべく取る」です。 捨てたログを後から取ることはできません。 ログさえ手元にあれば後からデータレイク(BigQuery)に連携できます。 とにかくログは取っておきましょう。

ということでログ収集のために各ツールを導入します。 特別な理由がない限りはデファクトスタンダードと言えるものを提示します。 開発エンジニアが実装で大変そうだったら、代わりにデータエンジニアがプルリクを出しましょう。

  • モバイルアプリ
    • アクセス解析ログ: Firebase Analytics
    • クラッシュレポート: Firebase Crashlytics
  • フロントエンド
  • バックエンド
    • アクセスログ(ApacheやNginxで吐き出すログ): GKEの場合は Stackdriver Logging にデフォルトで出力される
    • アプリケーションログ・エラーログ: Spring Bootの場合は SLF4J + log4j でプロジェクト用の共通Loggerを設定すると、最終的には Stackdriver Logging に出力される
  • DB: PostgreSQL by CloudSQL などのRDBMS
    • 画面表示などWEBサービスの機能要件を満たすためのデータを保持します
    • データ活用観点で余計なことをやろうとするとアプリケーションを含めてシステムが汚れてしまうので最小限の設計に留めます
    • 常に最新のER構成を確認できるように、MySQL Workbench などのツールでDDLファイルをバージョン管理できると最高です

ログに関する実務上の論点についていくつか補足します。

共通ログ基盤について

独自SDKを入れてフロントエンドでもiOSでもAndroidでも同じログを飛ばすような仕組みを設けているところもあります。 意見が分かれるポイントなのですが、以下2点の理由から、共通ログ基盤は不要かなと私は思います。

  1. 共通基盤部隊がSDKを保守するのは結構大変だから
  2. 特定デバイスだからこそ取れるデータを削ぎ落とすことになりがちだから

データサイエンティストからすると「とりあえず全部データ入れといてくれよ」と言いたくなる場面はよくあります。 入り口であるログの形式を共通化すると、確かに後のデータ結合は楽になります。 しかし、本来はデータウェアハウスで吸収すべきであって、ログ収集時点でジャッジするのは適切とは言い難いのではないでしょうか。 余計なことをせずにデファクトスタンダードのツールをそれぞれ活用してデータを送るのが結果として最適だと思っています。

個人情報保護・通信の秘密

POSTメソッドで送られるリクエストbodyやDBに登録する情報の取り扱いには注意しなければいけません。 データをそのまま垂れ流すわけにはいかないのです。

端的にまとめると以下のジレンマが生じます。

  • 障害対応の文脈では(法令や利用規約やプライバシーポリシーの範囲内で)なるべく詳しい情報まで見られる状態にはしておきたい
  • なるべく手軽にデータを分析・活用するためには、守るべきデータはマスキングしておきたい

つまり「基本的には見せないけどデータとしては後で調査可能にする」必要があります。

フルGCPならセキュア環境(プロダクション)とマスキング環境(分析)の二重構成にするのが妥当ではないかと考えています。 例えばStackdriver Loggingには「除外フィルタ」という機能がありますが、これはログを丸々遮断してしまうようで、障害対応の文脈ではベストとは言い難いです。

なかなか難しいのですが、1つの案としてはログはそのまま出して、後述のデータレイク(BigQuery)の時点で二重構成にしたらどうかというのが今の自分の考えです。 データソースのシステム構成に依存せず、セキュアBigQuery to マスキングBigQuery の受け渡しSQLにおいて、取り扱うデータを制御するのが一番簡単ではないかという案です。

DBに残さないログの取り扱い

サイトの機能としては不要だが、分析としては使いたい、というデータはあります。 例えばUpdateやDeleteの更新履歴を追いたい場合です。 正直なところ実装方針は悩んでいるのですが、いくつか方法はあります。

  • Google Analytics: DBトランザクションの世界から遠すぎるのでNGです
  • DB: 使わないデータを置きたくないのでNGです
  • アクセスログ: 実装方針によります
    • WebAPIがRESTfulかつセキュアデータの管理方法が上記でOKならアクセスログで良さそうですね
    • UpdateやDeleteのエンドポイントをコールして200を返しているログがあれば、それは事実上の差分ログと言えそうです
  • アプリケーションログ: 無難だと思います
    • DBアクセスするRepositoryクラスの共通ロガーのようなものを作れば……
    • トランザクションと完全一致はしないけど、すぐ出来てそこそこの品質にはなる気がします
  • DB差分ログ(MySQLのbinlogなど): 品質としてはベストです
    • ただBigQuery連携で「これを使えばすぐできる!」というツールを今のところ知らないのです
      • Debezium はすごそうだけど Kafka は運用したくないのです
    • マルチマスタ構成のときに素直にbinlogでOKなんだっけ、というのは超絶調査中
    • マルチマスタDBのトランザクション管理は、普通のシステム運用の文脈においても障害対応で色々とハマった記憶があって、さらにそこをデータ基盤向けにハックするのは正直やりたくねぇ
    • 詳しい人がいたらむしろ教えてほしいです

データレイク

ポリシーとしては「流せるデータはBigQueryに流しておく」です。 データに関しては「とりあえずBQを見よう」と言える世界を担保します。

各データソースからの具体的な疎通方針は以下の通りです。

  • Firebase (Analytics / Crashlytics):
    • Braze Plan(従量課金)でBigQuery Exportが利用可能
    • Analytics と Crashlytics だけなら費用は抑えられる
  • Google Analytics:
  • Stackdriver Logging: Logs Export で BigQuery に自動で流す
  • Cloud SQL: GCSにエクスポートしてBigQueryに流す
    • ちなみにGCP以外の場合であればDBはRead Only Replicaからdumpするのが望ましいかなと思います
    • 改修の度に負荷調査や試験の工数が掛かったり、エラーの度にリトライタイミングの調整が必要になるためです

データセット命名規則source__データソース名 とします。 例えば source__dbsource__firebase__ios です。 アンダーバー2つで要素を区切り、必要に応じて source__aaa__bbb といった命名もOKとします。 データソースと1対1の関係になるので名前は機械的に決まるはずです。 意味を解釈する必要はありません。 コスト効率・処理パフォーマンスの観点から、イベント系ログは source__db.event__yyyymmdd のようにパーティションテーブル管理とします。

データの疎通頻度について。 サービスとしてエクスポート機能が提供されているものはその仕様に準じます。 そうでないものは日次のバッチ疎通から始めます。 リアルタイム性が求められるユースケースは、アドテクや人命に関わる機器の温度管理など、一部に限られるだろうという前提のもとです。 将来的には「ECサイトで在庫のない商品をレコメンド」といった機会損失を抑えるためにリアルタイム疎通の仕組みを別途設けることになります。

BigQueryの保存データはScheduled Queryで定期的にGCSバックアップを出力します。 上書き保存ではなくスナップショットを追加し続けます。 権限管理の不備やオペミスで、データレイクに予期せぬ変更が入ったときは、GCSからデータ遡求を行います。

データウェアハウス

初期フェーズでは絶対に作りません。 データマートが肥大化して、データパイプラインを構築した後に検討を開始します。 命名規則warehouse__ビジネスドメイン名 として、意味を解釈します。

データマート

初期フェーズでは原則的に作りません。 ただし後述するモニタリングの運用方法によっては、DataStudioで表示するためのテーブルを作る、といった可能性もあります。

命名規則mart__利用用途名 とします。 利用用途と1対1の関係になるので名前は機械的に決まるはずです。 意味を解釈する必要はありません。

データパイプライン

初期フェーズでは作りません。 単体の定期ジョブがいくつかある状態とします。 Scheduled Query による定期実行で十分管理できるはずです。

データマートが肥大化して、モニタリングの障害が頻発したタイミングで検討を開始します。 ただしその場合もまずは使っていないデータマートの除却から始めます。 不要なマートを除却したら、実際に使っているのは少数のデータだけということは往々にしてあります。 オーバースペックなパイプラインを組むほうが高コストになりかねません。

理想のシステムを作ることを目的化しないように心掛けます。 「具体的に何が課題か」を突き詰めて「データパイプラインを作ることが妥当な打ち手だ」という状況になってから着手します。 その際は Cloud Composer (Airflow on GCP) あたりを使います。

データ活用

主な活用用途として、業務・モニタリング(BI)・機械学習の3つについて述べます。

業務フローにおけるデータ参照

業務フロー上で必要となるデータ参照を洗い出します。 前述の例ですと、ECサイトにおける請求メールが該当します。

BigQuery で Read Only な User を発行して、手順書とSQLをオペレータに受け渡します。

-- イメージです
SELECT
  業者.id,
  業者.名前,
  COUNT(売買.id) AS 売買件数,
  SUM(売買.金額) AS 売買金額,
  手数料率,
  SUM(売買.金額) * 手数料率 AS 請求金額
FROM
  売買__201812* AS 売買 -- ここに請求対象となる年月(2018年12月)を入れてください
INNER JOIN
  売買.業者id = 業者.id
GROUP BY
  業者.id

モニタリング・BI

要件の優先順位をつけて(無理のない範囲で)データを見ます。 モニタリング観点は多々ありますが、ここではプロダクトマネジメントのトライアングル(ビジネス・ユーザー・デベロッパー)を切り口として洗い出します。

f:id:yuzutas0:20181208234400p:plain

引用元:The Product Management Triangle - PRODUCT LOGIC

集客やSEOの磨き込みのためのモニタリング、カスタマーサポートの対応リードタイム、開発チームのベロシティ、機械学習のABテスト結果モニタリングなど、論点は多岐に渡ります。 上記の3要素を徹底的に分解すれば(理屈上は)出てきます。 が、そこまで分解できないという場合は、業務フローをベースにしてKPIを設計すると良いでしょう。 ただし業務フローベースのKPIを過剰に追求しても、業務は回るが利益が伸びにくいこともあります。

これらの指標は全てを重視するというよりは、ウエイトを置くほうが望ましいです。 ECサイトの例ですと、購入実績が1万UUになるまでは体験を磨き込むフェーズとしてカスタマーサポートに力を入れて、そこから10万UUまでは拡大フェーズとして集客やSEOに力を入れる、といった具合です。 限られたリソースで優先順位を付けてモニタリングを整備するということは、コミットするためのKPIを考えるということであり、事業開発を推進するということです。

なお、初期フェーズにおいて無理にデータを繋げて分析する必要はないと考えています。 なぜならデータがそもそも足りていないからです。 ユーザーの元に直接出向いて、実際にサービスを使ってもらう。 その様子を隣で10分ほど観察させてもらう。 データ解析に1日を費やすよりも、より適切なインサイトを得られるでしょう。

また「施策Xと施策Yのどちらを先にやるか」を徹底して考えるよりも「さっさと両方やる」方がROIが高いこともあります。 ABテストをしたほうが効率的に回答を得られることもあります。

1万店舗がECサイトに出品することが当面のゴールだとしましょう。 既存のデータをこねくり回しても勝ち筋は見えないはずです。 100店舗に電話して「それなら出品しますよ」と店舗オーナーに言ってもらう。 そのためのセールストークというか、いわば殺し文句を突き止めることが大事です。 その殺し文句こそが店舗オーナーがこのサービスに抱く期待です。 その期待を満たす・超えるようなサービスにすれば良いはずです。

したがって、初期フェーズにおいてはインサイトを得るためというよりは、キードライバーの仮説を立てた上で数字が伸びているかチェックしたり、明らかな水漏れがないかを確認したり、いわば健康診断としてのモニタリング整備が重要となります。

機械学習のためのログ

前述のように機械学習のWebAPIをダークローンチする場合について述べます。 「精度が妥当か」(計測)と「精度向上のために何ができるか」(アクション)を見極めるためのデータ活用となります。 実務としてはデータレイクからデータをぶっこぬいて Colaboratory(Jupyter Notebook)をこねくり回すことになるでしょう。

レコメンドであればスコアリングを独立環境でシミュレーションします。 空振りであっても機械学習WebAPIをコールして、アプリケーションログとしてI/O(受けたデータ・返す予定のデータ)を垂れ流します。 そのシミュレーション結果を定期的に目視確認して「これなら行けそうだ」とステークホルダーが判断してからのリリースになります。 そして10%リリースから始める。このあたりは既に述べた通りです。

そこまでして初期に機械学習のシステムモジュールを挟むべきでしょうか。 リソースに余裕があるなら(例えば大企業における新規事業なら)初期フェーズからやるべきだと、現在時点では/個人的には思っています。 「こういうログの取り方だとレコメンドAPIには使いにくい」「こういう項目をユーザーから取得できると精度が上がりそうだ」といった、機械学習観点での学びやフィードバックを早期に得ることができるからです。

「うちにはデータがある」と思い込んでいる企業の大多数が、とてもではありませんが実用に耐えられないデータしか持っていません。 クレジングで疲弊するか、もしくは精度向上に寄与しません。 多くのビジネス担当やアプリケーション開発者は「機械学習を使ったサービス」のあり方にまだ慣れていません。

だからこそ、早い段階でデータ活用のフィードバックサイクルを回せるということは、ビジネス・システム・チームが「機械学習を使ったサービス」のあり方を踏まえた適応・進化を加速させることに繋がり、やがては競合優位性になるのではないでしょうか。

まとめ

勝ち筋の定まっていない初期フェーズにおいてはフィードバックサイクルを高速に回すことが求められます。 データ活用という文脈においては「ログはなるべく全部取る」「過剰なシステムを構築しない」の2点に尽きるかなと思います。 そこで浮かせた人的資源を「組織のデータ活用支援」に投下することがポイントかなと思います。


  1. モバイルアプリ開発が参考になるのではないでしょうか。かつてはモバイルアプリとWEBサイトの開発チームは分かれていましたが、今だと一気通貫でやっている開発チームが増えています、。同様に機械学習についても今後コモディティ化はある程度進むのではないかと思います。

マッチングサイトの海外カンファレンス「iDate2018」に参加しました

この記事は 海外 Advent Calendar 2018 - 7日目 の記事です。

f:id:yuzutas0:20181204225915j:plain

マッチングサイトの海外カンファレンス「iDate2018」に参加しました。 http://mobiledatingsummit.com/agenda-miami-2018.php

世界的に伸びているマーケットなので非常に興味深かったです。 事業プレイヤーが何を考え、何を行い、その背景にはどういう力学が働いているのか。 セッション聴講やディスカッションを通して考察することができました。

もくじ

注意点

  • 各国のサービスプロバイターを想定しており、日本国内のマッチングアプリ市場についての内容ではありません
  • 公開セッションを聴講した内容(ならびに登壇者たちとのディスカッションを通した考察)のメモであり、私が所属する組織の見解とは関係ありません
  • 英語圏にお住まいの方であれば何らかの形でアクセス・反証が可能な情報しか載せていないつもりです
  • 情報量が多いため、である調・箇条書き・殴り書きのコメントとなります
  • ノリと雰囲気で書いたので、ノリと雰囲気で読んでください(事実誤認がありそう)

カンファレンス概要

  • 時期:2018年1月
  • 場所:米国フロリダ州マイアミ
    • ビーチから徒歩10分のホテルが会場
  • 期間:プレイベントを含めて約1週間
  • 規模:感覚値だが200人〜300人
    • 日本人は5人:各サービスのCEOたちに日本を代表して婚活市場やマッチングサービスを説明することになった
    • 米国開催だがヨーロッパやラテン系の人たちも多かった
    • ロールとしてはCEO、マーケター、個人事業主が多かった
  • 内容
    • 約30分のスピーチセッションが1日数本
    • その合間にディスカッションタイム:婚活パーティーのように3分話して「はい次の人」という感じで流される
    • ホテルのロビーでコーヒーを飲んでいると非公式ディスカッションに巻き込まれる
  • 資料
    • 分量が多いので割愛します
    • 興味のある方は探してみてください
    • 参加者宛てメールで送られてきたけど、Google検索で見つからない(公開されていない?)資料があるかも

国際市場について

  • 婚姻数
    • 先進国は総じて人口減少・未婚化・晩婚化
    • 日本のグラフよりは緩やか(というか日本が世界TOPでヤバすぎる)
    • 移民や年齢差などの結婚・離婚に関する研究紹介もなされていた
  • マッチングサービス市場
    • アジア・アフリカを除いてマクロ市場の動向は世界的に同じ
    • 全体的に急成長している
      • 特にオンラインが牽引役
      • 我々がメディアで見慣れているスタートアップの伸び率よりは控え目
        • UberAirbnbは例外(極めて異常だからこそ注目されている)
  • ウエイト
    • 売上ベースだと:オフライン > オンライン > カジュアル
    • 利益ベースだと:オフラインとオンラインで同じくらい
    • 過去数年でのオンラインvsオフラインのシェア変動はそこまで大きくない
      • そもそも米国だと最古のマッチングサイトは20年以上前

オフラインのプレイヤーについて

  • マッチメイキング・デーティングコーチと呼ばれる市場
  • 仲人(なこうど)事業
  • 様々なタイプがある
    • 地域密着型
    • 提供サポート豊富型:コーチする、お店選びを手伝う、髪型をセッティングする
    • 高単価・高品質型:どんな相手とマッチングしたいかコーディネーターが3時間掛けてインタビューする
  • オンラインとの違い
    • 写真やプロフィールを見なくても「この人の紹介なら」とデートをOKすることがある
  • 業界コミュニティ
    • 事業者同士がFacebookグループで繋がってディスカッションや質疑応答をしている
    • 事業者のためのセミナー、スクール、研修メニュー、ライセンスがある
      • 統一規格ではない
      • こう言うと失礼だが胡散臭いセミナーのように見えるものもある
  • 担い手
    • いわゆるスピリチュアル系の中年女性が多い印象を受けた
    • ステマチックなレコメンドロジックを持っている人もいる
    • エージェント1人1人の収入はピンキリ
    • 日本でいう「脱サラ・専門学校→下積み→店舗オーナー」のようなキャリアパス
  • 市場としての課題
    • ユーザー需要はあるが、高価格のためアプローチできていない潜在層がいる

オンラインのプレイヤーについて

オンライン > 機能面

  • 総じて横並びのサービスが大量に出ている状況
  • 製品観点の動きは弱い
    • Keynoteセッション「昨年の大きな動きについて」ではTinderデスクトップ版に言及していたが、そこまでインパクトのある内容とは言えなかった
    • というくらいには弾切れ感がある
  • 方向性を模索する動きはある
    • アプリでのマッチングの後工程(デート)にウエイトを置くランチ支援機能
    • Facebookメッセンジャーでの恋愛コーチbot
    • プロフィール画像ではなく動画を投稿
      • 雰囲気が分かる・snow盛りを防止
      • 画像に比べてユーザーが長時間滞在する(ビジネス観点で優位)
      • 閲覧者が反応しやすい→反応を得られる→だから投稿したくなる...というポジティブサイクルが回りやすい
      • snapchatの台頭によって動画投稿・閲覧というUXが一般カスタマーに普及している(土壌がある)
      • 不適切なコンテンツの投稿を予防する仕組みについては、表向きは必要性を述べていたが、実際はプライオリティを高く置いていないように見受けられる

オンライン > UX面

  • カスタマーから文句を言われているプレイヤーが多い
    • それでも顧客は使っている&市場は伸びている
  • トラブルが爆発的に増加している
    • なりすまし・写真の不正利用
    • スパム
    • セクハラ(女性ユーザーの7割が経験している→3割がサービスから離脱している)
    • 暴力
    • 不審者
    • サイバー攻撃(例:アシュレイ・マディソンの個人情報流出)
  • カスタマーサポート・審査自動化の重要度が上がっている

オンライン > データ分析面

  • そこまで高度な行動分析はどこもあまり出来ていないのが実情らしい
  • 成婚までの勝ち筋の科学
    • 継続要因:何がリテンションに効くのか
    • 後工程:マッチ後に恋人になるのか(そもそもデータがない)
  • Match Group は着実に投資している
    • データ統合による横断分析
    • スパム行為検知の自動化
    • ABテストを打つ → ユーザー行動の変化を分析 → 製品・市場の特性を学習 → 次のABテストに繋げる
      • 例:ランディングページの掲載コンテンツは美形モデルよりも一般ユーザーの生の声のほうが効果があったらしい
        • 考察:米国市場において、美形モデルによる認知訴求のフェーズは終わった(=マッチングサービス自体の知名度は十分に高まった)ということ
        • 考察:近い人物が「あなたでも成功できますよ」と訴求するフェーズ(=ユーザーが品質面に対する信頼性を求めている)ということ

オンライン > 経営面

  • 主要プレイヤーがニッチプレイヤーをM&Aする流れがある
    • ニッチプロダクト本体:王道プレイヤーがオペレーションを横展開 → 低コストでニッチプロダクトを磨き込む → グループ会社でマーケットの面を取る
    • ニッチプロダクト創業者:実績と資本を手に入れて、次のチャンスを掴みに行く
      • (後述のSaaSを含めて)金を回すためのエコシステムができている
      • 行動したもの勝ちの世界
  • ニッチプレイヤー
    • 地域やコンテンツの切り口:宗教、同性愛者、HIV保持者などに絞ったマッチングサイト
    • ニッチでも世界全体なら十分な市場規模になる
      • 日本国内で大ヒットだと騒がれているサービスよりも売上の桁が大きい
      • ゲイ専用マッチングサイトは米国シェア7%
        • 市場規模としては普通にデカい(それでもUS基準ではニッチ)
        • オフラインだとゲイをカミングアウトできないので、オンラインと相性が良い
  • BRICsについては、単純に市場規模でかい
    • China > India > USA > Brazil
    • ブラジル市場の覇者は確定
      • 税制が複雑で参入障壁となる
      • ブラジル市場を抑えると、そのままラテン圏全体を抑えることに繋がる
      • カトリックよりもプロテスタントが2倍くらい多い
        • 宗教が異なるとマッチングしにくい
        • カトリック圏でパートナー探しに困っているユーザーはそのサイトに流れる
  • 欧米企業がアジア圏(中国、フィリピン、マレーシア)への展開を本格開始している
    • 日本は市場規模が小さすぎて相手にされていない
  • 施策に投資しやすい
    • 市場規模が大きいので、多少ニッチ向けの機能や施策でも、品質がそこまで高くなくても、一定数のユーザーに響く
    • 日本と同じInvestmentで、日本以上の安定たReturnを得られる(ROIが相対的に高い)
    • イデアベースでも施策のROIを正当化できる → 要するに「やれば伸びる」から「早く投資・執行しよう」と言える → 調査や優先順位検討に掛けるコストが少なく済む → 仮説検証サイクルを高速に回せる → 仮説検証の中で「勝ち筋」を見つける → 収益を得る → その収益をさらに投資する...というポジティブサイクルが回る
  • ネタか本気か分からないがICOビットコインの活用に言及しているところもあった

オンライン > 長期トレンド

  • 新規サービスが既存サービスをリプレイスする際の歴史構造
    • リプレイスのドライバーは基本的にテクノロジー(=データの流れ)
    • 2軸で切ると【アクセス人口】x【工程】(=アカウント登録→プロフィール入力→マッチング→デート)
      • 【人口】観点のリプレイス
        • インターネットの台頭(20年前):オフラインに比べてアクセス人口が爆増した
      • 【工程】観点のリプレイス
        • 現状の覇者はTinder
          • 例:マッチングサイトにプロフィール文を記述する世界観 → Facebook連携で自動的にプロフィール項目が埋まる世界観
          • 例:マッチングサイト上のテキストで好意を伝える世界観 → フリック動作でパチンコのようにいいね!しまくる世界観
          • これがマッチングサイトのあるべき姿だとは言わないが、この思想を体現したTinderが現在時点におけるマーケットの覇者であることは事実
        • 次はどうなるか
          • レコメンド?コーチ?恋愛工程のどこをどう楽にする?
  • 世の中にマッチングサービスが認知されたステップ
    • インパクトのあったイベント(米国)
      • 人気テレビドラマで登場人物がマッチングサイトを使うシーンがあった
      • 芸能人がTinderを利用した
    • フェーズごとに影響力を持ったメディア
      • 1.各社がプレスリリースを少しずつ打っていた
      • 2.マッチングアプリについて解説したオンラインマガジンが複数台頭してコンテンツ供給が増加した = 徐々に市場・ブランドが形成された
      • 3.情報源が増えた結果、キュレーションサイトやコミュニティなどのニュースフィードプレイヤーが台頭した
      • 4.代表的な一部のSNSアカウントが力を持つようになった → レイトマジョリティーがそれらのアカウントをフォローした
      • これは米国事例の分析だが、各国で同様の流れが起きている

サービス提供者が感じている悩み

  • 総論
    • 多くの提供者は「パートナーを見つける最高のソリューション・体験を提供できている」とは思っていない
    • 破壊的プレイヤーが台頭する可能性もあるか?
  • 各論
    • ユーザーが自分のプロフィールを盛りがち(データを見ると正規分布からやや右側にズレる)
    • パレートの法則:一部の人気ユーザーが大多数の好意を独占する一方で、大多数の不人気ユーザーが少数の好意を奪い合う
    • パチンコのようにいいね!を押しまくるユーザー体験
    • 小さな写真と短いプロフィール文を読んで何となくの雰囲気で相手を選ぶ体験
    • 後工程:お見合いのあとにどうなるかまでサービスが責任を持っていない
    • 恋愛で必要な観点(タイミング、ムード、会話の流れ)を支援するようなUXを提供できていない
    • カップル成立=退会=売上が減ってしまうが、どのKPIにフォーカスすべきか
    • カスタマーサポートスタッフはアウトソースにすべきか内部部隊にすべきか

技術的投資

Safety担保と機械学習

  • 手動
    • 問い合わせベースの対応でリアクティブになりがちという課題がある
    • カスタマーサポート部隊のスケールだと、人材品質は逓減してコスト・リスクは逓増してしまう
    • 補足だがコミュニティーオーナー制度をやっているところもある
  • 自動
    • 旧来の施策例:Facebookログインの義務化
      • Facebookがある程度のユーザー品質を保ってくれるだろうという期待
      • たとえばフレンドが何名以上のユーザーだけサービスを使える = 友人がいるならスパムアカウントではないだろうという理屈
      • Facebookユーザー以外を取り逃がすので、ユーザー数上限制約を受け入れる必要がある
      • こうした方法だけではマーケットに限界が来た
    • そこで機械学習への注目
  • 審査観点
    • キーワードによるルールベースで迷惑投稿を見つける:プロフィール文・メッセージ内容(日本と違って国によっては通信の秘密がない)
    • フォトレタッチや他から取ってきた画像ではないかを確認する:プロフィール写真・本人確認書類
    • これらの判定行為を自動化する
  • 盛り上がっている背景
    • 英語(とスペイン語)圏はユーザー数の桁が日本と違うので、自動化のROIが極めて高い
    • ROIが正当化されやすい → 自動化や効率化などの技術的投資ができる → 浮いた工数・コストでさらに攻める取り組みができる → ユーザー獲得・提供価値の拡充 → さらなる自動化・効率化......の成長スパイラル
    • 日本の市場規模だけで考えると「ひとまずは手動運用で対応しましょう」というジャッジがROI最大化に寄与することもあるが、上記スパイラルに乗っているサービスと比べると決定的な差が生じる
    • マッチングサービスに閉じた話ではなく日本国内のあらゆる産業で海外勢に対して構造的なビハインドがある
    • ビジネス(市場)とテクノロジー(技術的投資)をどう捉えるかという経営アジェンダなので、CEOの判断とそれを促すCTOの力量に依存する

機械学習SaaSの活用

  • データ活用例
    • 審査の自動化
      • 例:Basedo
      • 審査の自動化により、精度9割でコスト7割削減
      • 別サイトの不正行為データを横断でSaaSが保持するため、クレジットカードやメールアドレスだけで不正アカウントを検知できる
        • アカウント登録の瞬間に特定が可能
      • 大手サイトの利用実績がある
        • 身近な事例だとメルカリUSが利用
    • レコメンド
      • WebAPIにキーワードをリクエストすると、対象ユーザーリストがオススメ順にソートされてレスポンス
      • 当たり前だが目的変数を最大化させる形で学習する
        • 正しいデータが取れていることが前提
        • 例:マッチングしたか、BANされていないか、デートに漕ぎ着けたか、長期間の交際に繋がったか
      • 導入しても上手くいっていない現場が多々ある
        • そもそも上記データを取れていない
        • データクレンジングの負荷が高い
  • 自前でソリューションを作るよりもROIが高い
    • リターン観点:社内データしか使えない自社サービスよりも、世界中のデータが集まるSaaSのほうが精度が高い
      • 特にクレジットカードの不正利用など
      • 伸びる市場には大量のプレイヤーが参入して、その分野向けのSaaSが提供されるので、それを使う
        • 逆にSaaSが提供されず自前で作らないといけないのは、その時点では伸びていない市場だから(参入が早すぎる)
      • SaaS提供者はそのソリューションを全力で磨きこんでいる
        • そうでないプレイヤーは市場原理で淘汰される
        • 内製ツールを使う場合は市場原理が働きにくい
    • コスト観点:人件費とSaaS利用料の比較になるが、初期構築だけでなく保守運用の手間を考えるとSaaSのほうが望ましい
      • 機械学習ソリューションを作れる希少・高価な人材を地道な保守運用に当て続けるのか
      • その人物が抜けた後に保守運用を続けられるのか
    • 月200〜400万を専門家に支払って機械学習システムを構築・保守するなら、月80万円でSaaSに任せたほうが良いという発想
  • 経営者が「選択と集中」をしている
    • SaaSなどのツールを提供する事業者と、そのツールをフル活用する事業者とで分かれている
      • もし自前でやろうという話になったら、別会社に切り出してSaasを提供する側に回る
    • コンテンツプロバイダーは内製ツールを作ることではなく、サービスの利益向上にコミットする
    • 外部ツールを選定・調達・維持するスキルは、それ自体が1つの専門知識と言える
    • ソリューション構築や調達について「プロジェクトごとにフリーランスを雇う」→「運用フェーズに移管したら契約終わり」の事例が見受けられる
  • こうした環境のほうがスタートアップは成功しやすいのかも
    • 外部ツールを使う力学が働いている
    • SaaS提供側が売りを立てやすい
    • 内製重視の環境に比べると、経済は活性化しやすそう

テクノロジーマーケティングのナレッジ

  • セッションで解説のあった「一般論」は日本で得られる情報と大差ない
    • エンジニアやサイエンティストの個人スキルに対海外劣位はない
    • 日本人でも一部の優秀な人がいて、大多数のそうでない人がいて、海外と言えどそれは同じ
  • 例:マシーンラーニングの仕組みと活用のコツ
    • AIブームは3度目だよ、という話から始まり
    • Courseraで学べるような手法の概要紹介に続き
    • システム保守・UX観点・ワークフロー設計が落とし穴だ!という話に着地する
  • 例:アフィリエイトプログラムの設計ノウハウ
    • アフィリエイターにとってのUXジャーニーを磨き込もう
    • アフィリエイターと連携するためのコミュニティ構築が勝ち筋になる
    • アフィリエイターを育てる視点が大切だ
  • 休憩時間に機械学習エンジニアとディスカッションをした
    • 「6ヶ月でお前のところの業務を全部自動化してやるよ」と煽られた
    • 具体的にやることを聞くと、プロフェッショナルを1人ずつ・案件ごとに専任で張れば、余裕で達成出来る内容だった
    • しかし、国内の多くの現場だと「プロフェッショナルを1人ずつ・案件ごとに専任で張る」ことができていないと思う
    • 専門家の個人スキルの上下ではなく、明らかにマネジメント(というか経営)の差だと感じた

全体的な感想

  • (久々の海外でちょっと不安だったけど)英語力よりもドメイン知識とディスカッション姿勢が大事
    • 知識があれば何となく聞き取れる → 日頃からアンテナを張って担当プロダクト・市場に人一倍詳しくなることが大事
    • 姿勢があれば話を聞いてくれる → 日頃から積極的に発言することが大事
  • 海外プレイヤーの強さに危機感を持った
    • マッチングサイトに限らず産業全体としての感想
    • 製品機能やマーケティング施策に差はないが、経営と市場の構造に圧倒的な違いがある
    • そもそも日本市場は相手にさえされていないけれども
  • 地方のド田舎であれこれ考えたあとに、東京のイベントに参加して全部ひっくり返された、みたいな感覚
    • 自分1人がプレイヤーとして海外でそこそこ活躍できる未来は描けそうだとは思った
    • 自分が起業家・経営者・プロデューサーだとして「国内の特定のプロダクトと組織を圧倒的に成長させたい」と思ったら、どのような未来を描けるだろうか(結構苦しいなと思った)
      • 思いつきでブルーオーシャンを狙うよりも、伸びている市場で確実にシェアを取るという発想は、もっと大事にしてもいいなと思った
      • この手の海外万歳エントリーは大抵が生存バイアスを無視しているものだよと自己批判したくなるのだけど、一方で伸びている市場に乗っかればより少ない努力で生き残りやすいということもまた事実だと思う

まとめ

「市場規模」「フォーカス」は本当に大事なんだなぁと思いました(小学生並みの感想)

ブラウザ操作の記録・自動実行を補助するツールを作ったけど供養します

この記事は、クローラー/Webスクレイピング&RPA Advent Calendar 2018 Advent Calendar 2018 - Qiitaの6日目の記事です。

何を作ったか

リポジトリyuzutas0/sel2pupとなります。

SeleniumIDEというツールを使うと、ブラウザ操作を記録して .side ファイルを出力します。 そのままでは記録しただけです。実行はできません。 そこで、記録ファイルを.js に変換して、Node.jsでブラウザ操作を自動実行できるようにしました。

ちなみに「Selenium Webdriverを使えばいいじゃん」と思った方はアウトです。 私も最初はそう思いましたが、Seleniumは昔のように動作しなくなっております。 後ほど説明します。

前提

私はデータ基盤のProduct ManagerならびにTech Leadに相当するロールを担っています。 データ基盤とは、企業の持つ多様なデータソースと、多様なデータ活用者を結びつけるための基盤です。

f:id:yuzutas0:20181202174229p:plain

解決したい課題

「広告媒体のデータ収集が高コストだ」という課題です。 一般的にデジタルマーケティングと呼ばれる分野のデータです。

GoogleTwitterFacebookなどの有名な広告媒体にはWebAPIが整備されています。 どのキャンペーンやクリエイティブに、どのくらいのコストを消費して、どのくらいのユーザーが見て、どのくらいのユーザーがクリックしたのか。 そういった効果データをWebAPI経由で参照することができます。 そのため、他データと繋げて高度なデータ分析をしたり、媒体横断の定型レポートを自動生成することができます。

しかしマイナーなメディアではWebAPIが提供されていません。 例えば、学生起業家がWordPressで運営しているファッションメディアを想像してください。 そういうマイナーでニッチなメディアには独自の強みがあります。 特定分野に興味のある熱狂的なユーザーがついているのです。 インプレッション(広告表示)の絶対数は少ないですが、コンバージョン(登録や購買)率が高くなる傾向にあります。

費用対効果が極めて高い、魅力的な広告媒体なのですが、いかんせんシステム面が貧弱です。 広告の効果データを自動収集したくてもWebAPIが提供されていません。

一般的な解決策

オペレーションスタッフが、広告コンソール画面を開き、効果レポートのCSVファイルをダウンロードする。 要するに「手動対応」が一般的な解決策とされています。 単純作業かつスケールメリットが効くので、大手広告代理店の場合は、オフショアで相対的に単価の安い国に発注します。 この方法のメリットは作業パフォーマンスが安定することです。

一方でデメリットはデータ活用のパイプライン処理に乗せにくいことです。 効果レポートを出して終わりではありません。 広告の効果データをインプットにして、次の意思決定や機械学習に繋がるはずです。

もう1つ言われる解決策が、スクレイピングによる自動データ収集です。 人間が手作業を行う代わりに、システムが自動的にブラウザを動かして、CSVファイルをダウンロードして、指定のフォルダにファイルを置きます。 少しプログラミングをかじったことのあるマーケッターなら1度は試したことがあるでしょう。 データ活用のパイプライン処理に乗せることができれば、意思決定や機械学習における可能性が広がります。

しかしこの方法には致命的な欠陥があります。 システムの保守が尋常じゃなく大変なのです。 毎日のようにスクリプトが壊れます。 媒体追加も必要になります。 「マーケッターが新規媒体を追加したいスピード」は「エンジニアの対応速度」を常に上回ります。 大手広告代理店を除いて(筆者の観測範囲では)独自で2年以上運用が続いている実績を聞いたことがありません。 1度やったことがある人なら分かると思います。 長期保守は極めて困難です。

打ち手

そこで私が考えたのは手動・自動のハイブリッド案でした。 基本的にはシステムで自動化する。 だけど保守が必要になる。 その保守をオフショア部隊が担う。 という構想です。

もしくはマーケッター自身がエンハンスできるようにする。 それだけで十分だとも思いました。 いわばRPAの保守工程の一部を非エンジニアが担う世界です。

技術的な課題

ブラウザの動作を記録・実行する方法はいくつかあります。

Selenium

昔ながらのエンジニアがよく知っているのは「Selenium」ではないでしょうか。 主に「SeleniumIDE」(記録)と「Selenium WebDriver」(実行)に分かれています。 数年前ならボタンをポチポチやっていれば自動でそれっぽいコードを生成できました。

しかしなんと、こちら主要ブラウザの仕様変更に伴って、記録→実行ができなくなりました。 詳しく説明します。

Selenium WebDriverはJavaをはじめとしたプログラミング言語で使うライブラリです。 昔のSeleniumIDEは .java などのファイルを出力できました。 出力したJavaソースコード上でSelenium WebDriverを使う形になります。

しかしブラウザの仕様変更に伴ってSeleniumIDEが昔と変わってしまいました。 唯一出力できる .side ファイルの実態はjsonです。要するに設定ファイルです。 Selenium WebDriverは設定ファイルを読み込んで実行するわけではありません。

そのため(2018年12月現時点では)SeleniumIDEとSelenium WebDriverの連携ができなくなったのです。

これまでのツールとの互換性や、Selenium WebDriverなどの形式へのエクスポート機能も現状では存在しません。

Webブラウザ自動化ツール「Selenium IDE」の今までとこれから|Qbook+ https://www.valtes.co.jp/qbookplus/509

公式リポジトリにもWIPの記載があります。

This project is a work in progress, a complete rewrite of the old Selenium IDE.

https://github.com/SeleniumHQ/selenium-ide/blob/v3.5.0-alpha.0/README.md

Selenium の現状については『エキスパートが教えるSelenium最前線』の共著者である @poohsunny さんに教えていただきました。 この場を借りてお礼申し上げます。誠にありがとうございます。

エキスパートが教えるSelenium最前線 (CodeZine Digital First)

エキスパートが教えるSelenium最前線 (CodeZine Digital First)

Puppeteer

Seleniumと並び、特に最近有名なのが「Puppeteer」です。 Google Chrome の公式リポジトリで開発されています。 Node.jsやPythonと相性が良く、サーバレス系ソリューション(AWS Lambda や Google Cloud Functions)をはじめとして、モダンな環境で使いやすいという声が目立ちます。

Puppeteer自体はブラウザでの処理実行を責務としています。 代わりにGUIでブラウザを記録するためのツールとして「Puppeteer Recorder」や「segmentio/daydream」が公開されています。

しかし、これらのツールは、今のところ機能面で使い物になりません。 (2018年秋現時点では)クリック処理さえまともに記録できません。

実装

ということで、最低限のレコーディングができるツールとして「SeleniumIDE」を採用しました。 jsonファイルの出力まではやってくれます。 そのjsonファイルの設定内容をもとにして「Selenium WebDriver」もしくは「Puppeteer」向けのスクリプトを生成すればOKです。

両方とも作って実験したのですが、最終的にはPuppeteerを採用することにしました。 まぁぶっちゃけSelenium WebDriverでも特に問題なかったのですが、最後はノリです。

SeleniumIDEでブラウザ動作を記録する。 readmeに沿ってコマンドをぽちぽちと押していく。 必要に応じて設定ファイルを書き換える。 これでPuppeteerのスクリプトを出力します。

なお、機能スコープは最小限に抑えています。

  • 指定したURLにジャンプする
  • ボタンをクリックする
  • フォームにテキストを入力する
  • 新しいブラウザタブに遷移する
  • 元のブラウザタブに遷移する

これらの単純な処理だけが変換対象です。 入り組んだ動作を自動化するにはがっつりプログラミングしないといけません。

テスト

いくつかの広告媒体を対象にしてテスト実施しました。 ある日の手動作業をレコーディングして、スクリプトに変換して、次の日からRPA的に自動実行する。 感覚値ですが7割くらいの精度で動作しました。

SPA(シングルページアプリケーション)でぬるぬる動く系のダッシュボードだと、レコーディングが上手くいかずに多少のコード修正は必要になりました。 そこはさすがに仕方ないですね。 許容範囲かなと思います。

また、このツールを作ったときに同僚のエンジニアに指摘されたのが「独自に作るなら公式にプルリク出せや」というツッコミでした。 そりゃそうだ。 SeleniumやPuppeteerのコミュニティでのやりとりを見ると、方針を決めるためのディスカッションだとか、既存のシステムの構造だとか、なんだか色々と読み解かないといけなそうで、ちょっと尻込みしてしまいました。

なので、このツールは「公式が出るまでの繋ぎの位置づけ」としました!

供養する理由

公式ツールを使えるようになったわけではありません。 ツール自体の良し悪しでもありません。

ツールを使うための目的がなくなってしまったのです。 「デジタルマーケティングのデータ収集」という業務を「手動・自動のハイブリッドRPAで運用する」という打ち手。 あまり上手くいきませんでした。 主に2点の理由があります。

1点目は個々のプレイヤーの問題です。 データ収集RPAを非エンジニアが保守できる世界を目指して、このツールを作りました。 しかし、多くのマーケッターは既存業務で手一杯のため、保守を自分で担うモチベーションを持つわけではありません。 同様に、エンジニアはシステム構築ができても、導入支援を丁寧に行うことが得意ではありません。 つまり「現場が受け入れる土壌」を育てる必要があったのです。

2点目は全体の経営リスクの問題です。 中途半端に内製部隊が作業するよりも、広告代理店に全部お願いしたほうが(短期的には)ROIが最大化できるのです。 サービスを200個くらい持っていて集客予算をガンガン投下している大企業なら、RPA+オフショアの導入でスケールメリットを得ることができます。 そうでない場合は自前で運用するだけの量的メリットはありません。 かといって、そういう大企業は既に広告代理店のお得意様になっています。 わざわざリスクを冒さずとも、既存のやり方を続けておけば無難でしょう。 代理店に莫大な手数料を支払っているとはいえ、安定的に運用できるからです。 つまり「マーケティング内製化」というトップダウンの経営方針なしには実現できないのです。

どちらも突破できる壁だとは思います。 簡単ではないでしょうが、やりがいのあるテーマです。 が、世の中には他にも面白いことは山ほどあります。 ということで、色々と考えたのですが、まぁ、供養します。

データ基盤は色々と大変だ。 めでたしめでたし。

追記

記事のパブリッシュ直前で、少し風向きが変わりました。

ブログ「酒と泪とRubyとRailsと」の運営者である@zyunnosukeさんとお茶したときのことです。 「個人開発で価格比較サイトを2年以上運営している」「技術要素としてはPuppeteerを活用している」という旨の話を伺いました。 ちなみにこの話は「個人開発の事例集」に寄稿していただく予定です。

そしてですね、私は思い至りました。 このツールはデータ基盤のためだけじゃない。 個人開発やアグリゲーションサービスで使えるのではないか。 アフィリエイトサイトでも強いところは商品の口コミを自動収集していたりしますよね。 そういう用途だとまだまだ可能性があるんじゃないかな。

ということで、私の中では供養したつもりだけど、機会があったらがんがん使っていくぞ!

データ基盤をHadoopからBigQueryに移管するときのアンチパターン

この記事は、SRE 2 Advent Calendar 2018 - Qiitaの4日目の記事です。

主張

データ基盤の移管プロジェクトをやるときは、データサイエンティストではなくSRE人材が推進すべきだと思っています。

この記事の概要

SRE人材が介在しないまま、システム全体の運用・保守観点を踏まえずに、データ基盤の移管を進めるとどうなるか。 「データ基盤をHadoopからBigQueryに移管する」というプロジェクトで、とある現場が実際に踏んだアンチパターンをご紹介します。

語句の説明

「データレイク」(元データのコピー)と「データウェアハウス」(加工済みデータ)の概念を分けて考えます。 詳しくは以下のエントリーを参照ください。

yuzutas0.hatenablog.com

元の構成

f:id:yuzutas0:20181203204909p:plain

  • いわゆるレガシーな20年モノのWebシステムで、DBはOracleを使っています。
  • バッチ処理Oracleからデータを取り出してORC形式でHadoopクラスタに疎通します。Hadoopがデータレイクの役割を果たしています。
  • Hadoopクラスタ上でデータ活用のための集計処理を行います。Hadoopがデータウェアハウスの役割を果たしています。

やろうとしたこと

f:id:yuzutas0:20181203204951p:plain

  • 分析環境の技術要素をHadoopからBigQueryに移管することになりました。
  • 方針としてHadoop(データレイク)からBigQueryにデータを流し込もうとしました。

失敗例

f:id:yuzutas0:20181203205146p:plain

  • 実態としては、Hadoop(データレイク)とHadoop(データウェアハウス)の境界が曖昧でした。
  • そのため中途半端に加工済みのデータがBigQueryに流れてしまいました。
  • 最初のDB(Oracle)と比べたときにデータの欠損や不整合が生じました。

何がイケてないか

f:id:yuzutas0:20181203205221p:plain

  • Hadoop(データウェアハウス)からBigQuery(データウェアハウス)への移行プロジェクトだと言っています。
  • しかし実態は、Hadoop(ごった煮)にBigQuery(ごった煮)を継ぎ足して、システムをより複雑にしただけです。

どうすべきだったか(Hadoopを使う案)

f:id:yuzutas0:20181203205240p:plain

  • 素直に考えると、Hadoop(データレイク)とHadoop(データウェアハウス)を明確に分離するのが第一歩と言えます。
  • その上で、Hadoop(データレイク)からBigQueryにデータを流して、Hadoop(データウェアハウス)を除却すれば良さそうです。
  • しかし、技術要素としてHadoopからBigQueryに移そうとしているのですから、Hadoop(データレイク)を残すメリットはありません。

どうすべきだったか(Hadoopを使わない案)

f:id:yuzutas0:20181203205355p:plain

  • OracleのReadOnlyレプリカを立て、純粋なエクスポートファイル(HDFSではなくDump)を吐き出し、そのDumpをBigQueryに読み込ませます。
  • つまり、Hadoop(自称データレイク)に継ぎ足すのではなく、DBのレプリカ&Dump(真のデータレイク)を参照する、という構成です。
  • 最後にHadoopクラスタ自体を除却すれば、技術要素としての「Hadoop → BigQuery」移管が完了します。

なぜこれができなかったか

f:id:yuzutas0:20181203205630p:plain

  • WebサイトのDBは、WEBサイトのエンジニアリング部隊が管理しています。
  • Hadoopクラスタはデータサイエンティスト部隊が管理しています。
  • データサイエンティスト部隊にとっては、HadoopからBigQueryにシステムを移管するならば、自分の見える範囲内でやるのが手っ取り早いです。
  • つまり「コンウェイの法則」が働いたということです。

なぜアンチパターンと言えるのか

2018年現在、多くの組織において「プロダクト」と「分析」の担当者は分かれています。 データの源(ログ)はプロダクト担当者が持っています。 そのため、分析担当者からプロダクト側にアクセスするには、サイロ化した組織の壁を突破する必要があります。

分析担当者に巻き込み力がないと、あるいは経営者・マネジャー・テックリードが全体を見渡して指示できないと、システムを継ぎ足すような選択肢しか選べなくなります。 分析担当者が素早く成果を出そうとすると、わざわざ時間を掛けてシステムの並行稼働・切り替えを行わずに、今あるシステムに継ぎ足すといった局所最適解を選びがちです。

その結果、データ基盤が複雑化して、データモデリングにおける負債が蓄積し、データ活用施策の品質・デリバリーが悪化します。

一般的な組織構造とアーキテクチャを前提としており、多くの現場で容易に再現されうる事象です。 それゆえにアンチパターンだと言えます。

どうすればよかったか

f:id:yuzutas0:20181203205812p:plain

  • 「プロダクト」と「分析」の間を取り持つDataOpsロールが必要です。
  • システム全体を最適化する部隊(つまりSRE)がこのロールを担うことが望ましいです。
  • 要するに、データサイエンティストではなく、SREがデータ基盤を構築・運用すべきです。

備考: DataOpsとは何か

  • 概念としてはDevOpsのデータ版です。つまり DevOps ≒ DataOps です。
  • DevOpsの具体的なプラクティスがSREです。Googleいわく class SRE implements DevOps です。
  • つまり class SRE implements DataOps とも言えます。要するに、鍵を握るのはSREなのです。

詳しくはデブサミの登壇資料をご覧ください。

yuzutas0.hatenablog.com

まとめ

バズワードとしてのビッグデータ・データサイエンティスト・AIが終焉を迎え、より実践的なデータ活用事例が増え始めたフェーズだと認識しています。 そして、データ活用の寄る辺となるデータ基盤の重要度は極めて高くなっています。

しかし、まだまだ「データサイエンティスト採用要件: Hadoop利用経験 n年以上」といった雑なリクルーティング・アサインが多いのも事実です。 結果として本エントリーでご紹介したようなアンチパターンを踏み抜いてしまった、という現場は多いのではないでしょうか。 これからそういう事例がどんどん出てくるのではないかと思います。

データ基盤と言えど、つまるところはITシステムです。 短絡的な視点に基づいて設計・構築・運用をすれば、技術的負債が蓄積していずれ限界を迎えます。 だからこそシステムの信頼性を最適化できるSRE人材が鍵になるのだと思います。

とりあえずデータサイエンティストの採用予算を、データ基盤エンジニアに一部振り替えましょう。

データ基盤のクソコラを供養します

この記事は、クソコラ Advent Calendar 2018 - Adventarの3日目の記事です。

クソコラ

f:id:yuzutas0:20181202194051j:plain

f:id:yuzutas0:20181202194103j:plain

経緯

社内Slackの #ultra_soul チャンネルで、同僚から送られてきました。

活躍

これらの糞コラは以下のイベントで活用されました。

yuzutas0.hatenablog.com

yuzutas0.hatenablog.com

結末

二度と使うことはないと思うので、このエントリーをもって永久に供養します。

めでたし。めでたし。

データ基盤の3分類と進化的データモデリング

この記事は、下書き供養 Advent Calendar 2018 - Adventarの2日目の記事です。 めっちゃ専門的な内容になってしまいました。ごめんなさい。

f:id:yuzutas0:20181202173539p:plain

某Slackでの議論内容をブログに書こうとしたのですが、下書きのまま放置していました。 Wednesday, August 15th と書いてあるので、約半年前の内容となります。

もくじ

はじめに

データ基盤と世間一般で言われるシステムには分類があります。 「データ基盤を担当している」という人であっても、話してみると「意外とこの分類を知らない」「アンチパターンで設計している」と感じることがあります。 そこで私なりに解説してみたいと思います。

なお、ここでは分析基盤ではなくデータ基盤と呼びます。 データ分析だけでなく、集計・レポーティングや機械学習にも使うことを想定するからです。 そのため「分析」の基盤ではなく「データ」を活用するための基盤であることを強調するために「データ基盤」と呼称します。1

「データ基盤の3分類」と「(一般的な)技術要素」

f:id:yuzutas0:20181202171814p:plain

1.データレイク(Data Lake)

元のデータを加工せずそのまま1つのシステムに集約したものです。 データソース(水源)から流れてきたデータをそのまま蓄える場所なのでレイク(湖)と呼びます。

何も加工していない、ただのコピーであることが重要です。 もし加工済みデータしか残っていないと、後から「このデータ加工方法は間違っている」ということが判明したときに直せなくなるからです。 データレイクに元の状態のデータが残っていれば、データの調査やロジック修正が容易になります。 サイエンティストならば、中途半端に用意された加工済データが使い物にならず、元データを寄越せと言いたくなったことは多々あるでしょう。

一般的な技術要素としては、S3やGCSなどのストレージサービスを使うことが多いです。 ログファイルやDB Dumpをコピーしてストレージに配備しているなら、それがデータレイクだと言えます。

2.データウェアハウス(Data Warehouse)

複数のデータを統合・蓄積して、意思決定に活用できるように整理したものです。 大量のデータを意味のある形で管理することからウェアハウス(倉庫)と呼びます。

業務ドメイン知識をデータモデリングに反映することが重要です。 元データをただコピーするだけでは使い勝手が悪く、かといって特定用途に限定すると応用できない、という絶妙だが重要なニーズを満たします。 データエンジニアが「こうすればいいだろう」と安易に設計すると必ず破綻します。 かといって最初から事業ドメイン知識を全て把握できるわけではありません。 継続的に再設計し続けることが求められます。

一般的な技術要素としては、Hadoop(hdfs)やRedshift、BigQueryなどの分散データストアを使うことが多いです。 (適切な語句を知らずに)データレイクやデータマートのことをデータウェアハウスと呼ぶ人もいますので、その点はご注意ください。

3.データマート(Data Mart)

特定の利用者・用途向けにデータを加工・整理したものです。 すぐに使える完成品を取り揃えていることからマート(市場)と呼びます。

ユースケースごとに最適化されていることが重要です。 データマートが整備されていれば、パフォーマンスを気にせずに大量データを処理したり、複雑な集計をせずに対象データを見ることができます。 マーケティング担当ならば、見たい数字はシンプルなはずなのに、やたらと集計が大変で疲弊したことは多々あるでしょう。

一般的な技術要素としては、Re:dashやTableauなどのBIツールを使うことが多いです。 なお、落としたデータを元にExcelで複雑な集計を行っているのであれば、そのExcelシートこそが真のデータマートだと言えます。

私が考えるデータ基盤の定義

この3分類はデータ活用の業務フローのどこかに存在します。

「いや、うちの組織にはそんなものはない!」はダウトです。 偉い人やソフトウェアエンジニアが気付いていないだけで、業務担当者のローカルPCにあるExcelシートが、実はデータ基盤の役割を果たしているかもしれません。 そのExcelを開くと、rawデータをコピーしたシート(データレイク)、集計のためのシート(データレイク)、グラフを表示するためのシート(データマート)が見つかるでしょう。

これら3分類の全てをひっくるめてデータ基盤と呼称するのが妥当です。 どれか1つの役割を担うだけでは、データ基盤ではないと思っています。

業務改善チームみたいな特定の部署が、自分たちにとって使いやすい加工済データを提供したとしても、それはデータ基盤とは言えません。 他の部署にとって使い勝手が悪ければ、それは提供部署にとってのデータマートでしかないのです。 組織横断のデータ基盤とは言えません。

f:id:yuzutas0:20181202174229p:plain

私が考えるデータ基盤の定義は「複数のデータソースと複数の利用者をリボンのように結びつけるもの」です。 ここでいう「複数」は「n=1」の場合を含みます。 この定義に従うと、利用者に結びついていないのであればHadoopでさえデータ基盤とは言えず、利用者が使っているのであれば多重参照だらけの重いExcelシートであってもデータ基盤と言えます。 データソースと利用者を結ぶデータの流れのどこかで、3分類の役割が果たされることになります。

私が考える「あるべき構成」

技術要素を分けるのはアンチパターン

一般的な技術要素の例としては S3(データレイク) → Hadoop(データウェアハウス) → Tableau(データマート)といった構成となります。 しかし、私はこれがベストだとは思いません。 保守観点が欠如しているからです。 いわば「進化的データモデリング」を踏まえていないのです。

ある集計処理・加工後データが3分類のどこに属するのかは時と共に変わります。 例えば10の部署がそれぞれのExcelで同じ加工をしているのであれば、その加工処理は共通化したほうが良いでしょう。 それはもはやデータマートではなくデータウェアハウスとして扱うべきです。

また、データ仕様は日々変わることになります。 プロダクトの機能追加やバグ修正によって、データ反映のタイミングや内容が微妙に変わることもあります。 非エンジニアからは同じ動作のように見えても、データ集計処理に影響を与えていることだってあります。

「複数のデータソースと複数の利用者をリボンのように結びつける」ことの難しさがここにあります。 外的振る舞いを変えなかったとしても、一連のデータの流れの中身を継続的に修正し続けることになるのです。 システム保守と言ってもいいし、リファクタリングと言ってもいいし、現代風にいうなら「進化的データモデリング」と言ってもいいでしょう。 データ基盤におけるデータモデリング設計は継続的な分離・結合を通してドメイン知識を反映していくものとなります。

f:id:yuzutas0:20180530082828p:plain

データレイク(元データを反映したもの)とデータマート(ユースケースを反映したもの)が先に存在して、そこからロジックを共通化したものがデータウェアハウスとなります。 データレイクやデータマートが変わっていくのに合わせて、中間テーブルであるデータウェアハウスを継続的に分離・結合することになります。

しかし、S3(データレイク) → Hadoop(データウェアハウス) → Tableau(データマート) のように別システムで管理していると、あるいは別チームが管理していると、データモデリング修正のコストが高くなり、設計は局所最適化してしまいます。

進化的データモデリングを容易にしよう

そこで私の担当現場では、BigQueryのデータセットを3層構造で管理して、それぞれに対応するという設計思想にしています。 つまりデータレイク、データウェアハウス、データマートを全てBigQueryで管理しています。

f:id:yuzutas0:20181202172823j:plain

f:id:yuzutas0:20181202172835p:plain

加工処理は全てSQLファイルで管理して、一連のデータパイプライン上で実行します。 最初はアナリストがTableauで実験的にデータマートを作り、上手くいったらSQL on データパイプラインにロジックを取り込みます。 命名規則SQLで管理しているため、機械的に影響範囲を洗い出すことができます。2 リファクタリングを通してデータモデリング設計を継続的に進化させることができるのです。

加工ロジックを、S3 → Hadoop → Tableau のように別システムで管理していると、あるいは別チームが管理していると、その分だけ影響調査が困難になります。 上手い仕組みを作れずに、データモデルが汚れてしまい、技術的負債が蓄積されることになるでしょう。 だからこそ私は、同じシステムに寄せるほうがリファクタリングしやすい(=継続進化させやすい)という思想で、技術要素としてBigQueryとSQLを採用しています。

チームとアーキテクチャを選ぶ

私の観測範囲に閉じて言えば、データサイエンティストや機械学習エンジニアはデータレイク重視、経営企画担当やアナリストはデータマート重視になりがちだなぁと感じます。 これらの人材はシステム開発スペシャリストではないので、仕方ないことだと思います。 どちらかというと人材アサインの問題です。 システムの全体像(レイク・ウェアハウス・マート)を見渡し、進化的データモデリングという概念を考慮して、データ基盤を設計・保守する。 これができるのはSRE人材です。インフラ人材ではありません。システムの信頼性にコミットできるSRE人材です。

チームやアーキテクチャは重要です。 仮にアナリストチームがTableauで横断データを整理する役割を担っていたらどうなるでしょうか。 Tableauをメインで使うアナリストにとっては快適なデータモデルになるでしょう。 しかし機械学習エンジニアにとっては最悪です。 わざわざTableauの仕様に合わせてデータを使わないといけないのですから。 コンウェイの法則によって、システムの依存関係は過剰に複雑化します。 だからこそ、SREロール(あるいはデータ基盤専門チーム)が主体となって、BigQuery + SQLのような骨太の技術要素で、全体最適となるシステム設計を推進すべきなのです。

まとめ

一般的には S3(データレイク) → Hadoop(データウェアハウス) → Tableau(データマート) のように別システムで管理することが多いです。 これは「1度作ったら終わり」「異なる部署で管理する」といった従来のコンテキストが背景にあるからだと推察されます。 それぞれのレイヤーで得意なツールに寄せれば初期構築が非常に楽になるのは事実です。

しかし、初期構築(Dev)だけに注目するのではなく、保守運用(Ops)も視野に入れてみてはどうでしょうか。 最適なデータ基盤のあり方は、きっとこれまで世間一般で言われてきたものと違った姿になるはずです。

参考

このエントリーの内容は『10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く』という書籍を参考としています。

余談

このエントリーを読んだ上で、以下の登壇資料を読んでいただけると、理解が深まるはずです。 スライドのp135〜p182が該当箇所となります。

yuzutas0.hatenablog.com

追記

技術要素についてツッコミどころに山ほどコメントをいただきました。 皆様ありがとうございます。一部記事を修正しました。

なお、データベースを正確に分類しようと試みている資料としては@fetarodcさんの「ビッグデータ処理データベースの全体像と使い分け
2018年version」を挙げることができます。前提知識についてはこのスライドを参照ください。


  1. 集計・レポーティングや機械学習も意思決定を支えるので分析の1つだ(だから分析基盤だ)というロジックもアリだと思います。ただ、担当現場によっては、データ分析という言葉を使ってしまうと、リテラシーの低いステークホルダーに対して「何か特別な隠された事実を発見する」ような過剰なニュアンスを期待させてしまうこともあります。

  2. まぁgrepでいちいち洗い出すのも大変なので、ワークフローエンジンである Apache Airflow(Cloud Composer)で前後関係をビジュアル化し、直感的に特定できるようにしています。