# ゴール 1. 定常モニタリング：日々のKPI管理を安定化させる 2. アドホック分析：Build・Measure・Learnを回す # トピック 現場ならではの泥臭い話をたっぷりお届けします。 - モニタリング編 - 非技術者が作った重厚長大なExcelシートをいかに置き換えるか - 「時間を掛けて作ったが誰にも使われない」悲劇をいかに回避するか - モニタリング内容の正しさをいかにテストするか - アドホック編 - 分析経験のないエンジニアチームでいかにデータスキルを装着させるか - システム開発の現場で仮説検証プロセスをいかに組み込むか # アーキテクチャ DWHとしてBigQueryに集約 → Python on EC2 + Jenkins で加工 → 各部署の使いやすいツールに出力 - マーケティング部署の見るExcelシート - ディレクション部署が見るRedash - 開発部署/データ分析部署が見るJupyter - 運用部署に届くSlack通知 # Pythonスクリプトの構成（モニタリング） 日夜改善を続けているので発表時には変わる可能性あり - Controller - Jenkinsが叩くためのエンドポイント - 処理の全体像を記述 → Facadeとして他処理を呼び出す - Enum - Python3.4〜のEnumを活用 - Dictonary型で値を管理 - 使いやすくするメソッドを基底クラスに集約 - Model - 値はpandasで整形 - 中間・最終指標を擬似DataTransterObject(DTO)として代入する - DTOをI/Fする際にはPython3.5〜のTypeHintsを活用 - DTOはBigQueryに反映して、プログラム上ではステートレスに保つ - Query - Python3.6〜のf-stringsを活用してクエリを書く - メソッド切り出し → 値の引き渡しによるスコープ制御 - BigQueryとのシンプルなR/Wに特化 - Interface - 入出力先に応じた接続・変換処理に特化（例：週次売上をmatplotlibで可視化） - .envから環境変数を読み込む（例：Slack連携で本番・開発でチャンネルを分ける） 開発・運用のお試し実行としてはローカルのJupyterNotebookを活用します。 実運用PythonのEnumなどをインポートした上で、検証したい処理のみ差し替えます。 もともとJupyterのみで完結する予定でしたが、定期実行やクラス構成検討で生Pythonの方が都合が良いことが分かりました。 # Jupyter on Github の活用（アドホック分析） - ローカル環境：メインモニタでJupyterNotebook、隣のモニタでアプリケーション本体のソースコード - 分析結果はGithubのプレビュー画面で関係者に共有 - コードの差分は全てコミット履歴で管理