# プロジェクト概要
自社プロダクトの持つ各種データを集め、データドリブンな意思決定ができる会社にするための基盤となる、Data Management Platform（DMP）を作成するプロジェクト。
直近の目標は以下のデータを収集し、アナリストが分析可能な状態にすること。
- 各種データベースのデータ
- Adobe Analyticsの行動ログ
プロジェクト要員は11名で、メンバーの役割は分析と開発で半々ほど。
# 担当内容
サーバサイドエンジニアの1メンバーとしてプロジェクトに入り、以下を担当してきた。
## プロジェクトの目標設定
私がプロジェクトに参画したタイミングでは、DMPをなんのために作成するのかが定まっていない状態であり、リーダ含め、各人の頭の中にのみやりたいことがある状況で、私がやるべきことすらない状態だった。
そこで、スクラム開発で利用するインセプションデッキの説明をチームに行い、チームでインセプションデッキを作成していくアクションを取ることで、定まっていなかった目標の明文化と、チームでの認識合わせを同時に行った。
その後、プロダクトバックログのテンプレートを作成し、チームに説明、運用サポートを行って、直近のやるべき作業を見える化した。
## チーム教育
リーダがメンバーをサポートできておらず、各人が思い思いの作業をしており、チームの体をなしていない状態だったため、ここでもスクラムの手法を借りつつ、以下のように改善していった。
### デイリースクラム実施
各メンバーの状況共有のため、デイリースクラムを実施した。
これによりタスクの抱え込みや、作業で詰まっているところが発見しやすくなった。
また、デイリースクラムのファシリテータをメンバーでローテーションすることで、チームへの参加意識を持って貰えるように工夫した。
そして、良くも悪くもチームが何の目標に向かって作業しているのかが不明確であることに気付くメンバーが出てくるようになった。
### チームの分割
DMPプロジェクトのメンバーは、以下のような様々なバックグラウンドを持つ集まりで構成されたチームだったため、プロダクトバックログを利用したスクラムのやり方だと、作業の進め方・優先度を統一するのが難しかった。
- エンジニア（サーバサイド、インフラ）
- アナリスト
- データサイエンティスト
- ディレクター
また、同じ作業チームとして動くと意思決定が遅く、プロジェクトが前進しなかったため、分析と開発でチームを分け、それぞれで適した業務実施方法を行うようにした。
各チームはリーダ間で連携し、互いの進捗はスプリントレビューという形で週末にメンバーで共有し合うことで、互いの作業内容に認識齟齬が出ないようにした。
### メンバー教育
報告を聞いているとコードレビューが行われていなかったので、
GitHubのプルリクエストの仕組みを説明しつつ、開発からデプロイまでの開発フローを作成・説明し、コードをチームのものにできるように取り組んだ。
また、データレイク開発中に採用したエンジニアが、開発業務にスムーズに入れるように、毎週1on1を実施し、業務中ではフォローがおざなりになりがちな、気になることや業務上の不安点、キャリアプランへのサポートを行った。
## データレイクの作成
開発チームのリーダが兼務の業務で忙しく、プロジェクトの作業がほぼできない状態となっており、プロジェクトが進まなかったため、開発済みのシステムを保守するチームと、データレイクを基礎としたデータプラットフォームを作っていくチームに更に分け、私とディレクターでデータレイクから作っていくことにした。
### 複数インフラ環境をまたぐシステム設計
当初GCPを想定してDMPのシステムが作られていたが、データを集める場合はAWSのS3が都合が良かったため、収集元データのあるオンプレミスとAWS、分析基盤を予定しているGCPを考慮して、データレイク、DWH、データマートのシステム構成を作成した。
極力開発工数と管理費を抑えたデータレイクの管理システムをAWSに用意するため、以下の工夫を行った。
- AWS Glue、AWS Athenaを使った、データのカタログとチェック機能の提供
- データ配備をLambda関数で定期チェックする機能の提供
### Oracleのデータ収集
数百GBのデータをOracleからデイリーで収集するため、Embulkを利用したシステムをPythonで構築した。
作成後、試しにEC2のt2.mediumで70Gほどのデータ処理を実施したところ、1日では処理が終わらない試算が出た。
そこで、AWS Batchが利用できるよう、システムをコンテナ化し、更にジョブを並列で実施できるようシステムを書き換え、上記処理が2,3分で終わる状態を作った。