下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・個人開発の瓦礫の記録

PyConJPでデータ分析基盤とチーム文化の話をしました #pyconjp

概要

PyCon JP 2017というカンファレンスに参加しました。 Day2の最終セッションにて「SREエンジニアがJupyter+BigQueryでデータ分析基盤をDev&Opsした話」というタイトルで発表しました。

f:id:yuzutas0:20170912194610j:plain

イベントについて

実施風景や発表内容

togetterや他の参加者のブログで良い感じにレポートされているので省略。 「こういう観点の感想もあるのかぁ」といった発見があり、読んでみると結構面白いです。

他の方の発表を聞いて

よかったです! 小学生並みの感想ですが!

  • 分析ネタ系・作ってみた系:やっぱり面白い。ニコニコ学会や自由研究に通じるものがある。こういうの大好き。
  • 足りない機能をハックする系・中身を読み解くぜ系:プログラミング言語を触るってこういうことだよなー、みたいな良さ。

あとLT聞いて思いついたんですけどPythonで実装した彼女とマッチングするWEBサービスを(略)

とまぁ、技術カンファレンスは今回が初参加で、最初はどうしたものかという感じでしたが、想像以上に楽しめました。

発表について

スライド

当日の資料は以下になります。

CfP内容(一部抜粋)

多様な部署・職種が関わる大企業において、どのような目的・用途・制約が与えられ、そのためにどのようなシステム・プロセスを採用したのか共有します。

プロダクト開発におけるデータ活用の指針・参考事例を持ち帰っていただきます。少しでも多くの開発現場がPythonという武器を手に、データを最大限に活用し、世の中に良いプロダクトを提供する助けになれたらと思っています。

https://pycon.jp/2017/ja/proposals/vote/159/

アジェンダ

  • 分析基盤をDev&Opsする
    • データ利用のユースケース
    • 分析基盤が必要となった背景
    • 設計ポリシー・技術選定
    • データフロー(収集>蓄積>加工>活用)
    • 構築プロセス
  • データ駆動文化をチームに装着する
    • Measure:効果測定と開発工程
    • Learn:顧客理解とSECIモデル

いただいたコメントなど

ありがたいことに色々とコメントをいただきました。

「タイトルだけ見てスルーしてた」

「文化の話いいね」

言われてみれば。 タイトルから中身を想像できないですね……。 どういうのが良かったんだろうなー。

「Jupyterはバッチ処理を試すのに相性が良い」

なるほど。 明文化できていませんでした。 確かにそういうことですね!

「朝の何時までにデータを疎通しなければいけない!みたいな話を伺いたい」

サービスレベルとオペレーションレベルを設計・運用しています。 詳しくは以下を参照いただければと。

yuzutas0.hatenablog.com

今回の質問であれば、バッチ処理の機能要件に該当するトピックとなりますね。 このあたりはいわゆるSREトピックとして、他のシステムと同じように運用・改善を行なっています。

SREやDev&Opsとタイトルに付けた割には、構築後の運用保守に対する言及が少なかったのはミスでした。 「それっぽいシステムを作るだけなら誰だってできるよ!大変なのはその先だろうが!」と言われたらそりゃそうだ、という感じです。

まさにGood Questionというやつですね。終了直後にわざわざ話し掛けてくださいました。

補足(蛇足?)

システム面

  • 話を聞いた人は「そこまで大したシステムではない」と思ったはずです。自分でもそう思います。ただ、大したシステムは必要ないと考えています。だからこそ簡単に書けて便利なPythonを技術選定しました。
  • 半年後には違う姿になっていると思います。システムは生き物と同じで日々変わるので。特にワークフローエンジンの運用保守については強い課題意識を持っています。むしろぜひ助言が欲しいくらいです。
  • 「大規模データだ」「他と比べて大変だ」と言うつもりはありません。たかだか数年程度の若いサービスなので。
    • 技術制約として「この規模のデータだとN/Wレイテンシがボトルネックになる」という話はしましたが。
    • 本当にヤバいやつは「みんな死ぬしかないじゃない!」状態だったりしますよね。未踏出身の先輩が20年物のシステムを数年掛けて少しずつ直すのを見て「こういう人たちには敵わないなぁ」と尊敬しております。

プロセス面

  • エンジニア向けなので「システムを直す優先順位が1番低い」と伝えました。実際にそう運用しています。ただ、ビジネスサイドには別の伝え方をすることもあるので悪しからず。「ボトルネック発生時は他作業を止めてシステムを直す」(その頻度は少なくない)という但し書きが伝わるかどうかで切り分けています。
  • 終わってから気付いたのですが、1番リードタイムを費やしたのは(着手前の)「工数確保のための根回し・調整・擦り合わせ」で、要するに社内政治でした。さらに泥臭い話になりますなぁ。そこまでやって初めて「業務」になるわけですからねぇ。
  • 改めて振り返ると「言うは易し行うは難し」だと思いました。今回の構想は、システムもプロセスも文化装着も、1時間のホワイトボードミーティングで描いた戦略がベースとなっているのですが、それを実現するのに半年以上を費やしております。

メイキング裏話

ひたすら試行錯誤

  • 100枚超えのスライドを5回丸々作り直した。
    • 伝わる構成にならなくて苦労した。
    • もともと扱うトピックが広すぎたというのはある。
  • 10回リハーサルした。あのザマでしたが。
  • 20人からフィードバックをもらって細部を修正した。
    • 例:「楽して」が「楽しい」に見えるので「ラクして」に書き直す。

準備面での振り返り

  • 【Keep】スライドが真っ白の時から毎日リハーサルしてフィードバックをもらい続けたこと。
  • 【Problem】スライドに全部書き出してから余計な箇所を削る方式で始めたこと。これは無理があった。物量が多いので修正がキツい。単純にバッチサイズの問題。
  • 【Try】結局は「30秒だったら何を話す?」から考え直して今の構成にした。「じゃあ1分だったら?」「3分だったら?」と広げていった。最初からこのやり方を採用すべきだった。

当日の反省など

反省点多し。マイクに声が入っていない、時間はオーバーする、余計なことを言うの三拍子。 そんな中で最後までお付き合いくださった方々、声を掛けてくださった方々には感謝の気持ちでいっぱいです。

最後に

ベストトークアワードで優秀賞という栄えある評価をいただけました。 私自身の拙い発表というよりは、チームの仕事が認めてもらえたのだと解釈しています。

何はともあれ、運営者・発表者・参加者の皆様、本当にありがとうございました!

PythonユーザのためのJupyter[実践]入門

PythonユーザのためのJupyter[実践]入門