データ分析のための組織作りで考慮すべきポイント
社内データ分析チームの位置付けを、gumiの場合は各プロジェクトから独立した共通部門としている。チームを構成するメンバーは、シニアアナリスト、アナリスト、データサイエンティストの3職種。この中で誤解されることの多い「シニアアナリスト」の役割について、今村氏は次のように説明した。
「シニアアナリストに求められるスキルは『高度な分析』ではない。最も重要な役割は、プロジェクトチームとよく話し合って『現場の課題を抽出』し、『方針を決定』すること」
その方針に基づいて実際に分析を行うのがアナリストだ。そして、データサイエンティストはより新しく効率的な分析手法や、より適切な指標などを模索する役割を担う。実際には、シニアアナリストとデータサイエンティストを兼務するケースも多いという。
また、データ分析は決して分析チームだけで行うわけではない。各プロジェクトチームのメンバーはもちろん、データ分析のための仕組みを社内の共通基盤に組み込むために共通基盤エンジニアの協力を仰ぐケースも多い。分析チームをうまく機能させるためには、こうしたさまざまな関係者と連携した取り組みが重要となってくる。
データ分析チームとプロジェクトチームの関係としては、gumiのように各プロジェクトから独立した分析チームを置くパターンのほか、各アナリストが普段からプロジェクトチームと一緒に仕事をするというパターンもある。
前者は分析チームとして標準化を進めやすい反面、各プロジェクトの課題などを把握しにくいため、定期的なヒアリングなどのフォローが必要となる。後者はプロジェクトの状況を理解しやすいが、前者に比べて知見の横展開が難しい。今村氏によれば、「それぞれ一長一短あるので、データ分析チームを立ち上げる際にはどちらも検討する価値はある」とのこと。
gumiの分析チームは各プロジェクトと独立した組織だが、プロジェクトごとに担当者をアサインして定例会議への出席やチャットを活用したプロジェクトメンバーとのコミュニケーションを行うことで、プロジェクトチームとの距離を縮める工夫をしているという。
gumiのデータ分析を支える「ログ収集基盤」と「ダッシュボード」
続いて今村氏は、gumiのデータ分析を支える技術として、データのインプット／アウトプットそれぞれの仕組みを紹介した。
gumiでは当初、Fluentdを使って各アプリケーションサーバに散在するログをAggregatorで収集し、用途に応じたストレージに保存する仕組みを構築していたが、データの欠損やデータ遅延などのトラブルが続発。原因を突き詰めていくと、ログの収集、加工、格納、障害時の一時保存など「Aggregatorが仕事しすぎ」であったことが判明したという。
そこで対策として、ログの収集と格納を分離。収集・障害時の一時保存はAmazon Kinesis、格納・加工はLambdaで行う構成とした。これが、現在活用されているgumiのログ収集基盤だ。
「この構成ではストレージ障害が起きた際にそのログのラインは止まっても、ほかのログは影響を受けずに済む。また、負荷が増大したらKinesisのシャードを増やすことで対応可能。新しいストレージが増えた場合も、Lambdaを追加するだけでよい。インプットの部分については、現在このような仕組みでうまくまわっている」
一方、アウトプットに関してはDomoのダッシュボードを採用しているそうだ。
「分析結果を容易にビジュアライズして見やすく表示できるものであれば、ダッシュボードのツールは何でもかまわない。目的はエンジニアの手を借りなくてもデータ分析ができる、結果を見られる環境を提供すること。最終的にはSQLが必要になるので100％は無理かもしれないが、エンジニアでなくてもできることを少しでも広げていくことが重要」
今村氏は最後にこう呼びかけ、セッションを終えた。
お問い合わせ
gumi
