CodeZine(コードジン)

特集ページ一覧

チームとしてのデータサイエンティストを目指そう――現場のエンジニアが実現したデータドリブンな組織とは【デブサミ2018 夏】

【A-2】とあるマーケティング部隊とデータエンジニアのデータドリブンへの道

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2018/08/24 14:00

 マーケティングにおいてデジタルデータを有効に活用するには、データの取得から活用までエンジニアとマーケターがシームレスに連携することが必要と言われる。とはいえ、両者は使っている用語もスキルも全く異なり、なかなか一筋縄ではいかないようだ。一体どのような工夫やマインドセットが必要なのだろうか。実際にマーケティング部門にデータエンジニアとして入り、約3年でデータドリブンな環境を実現させつつあるパーソルキャリアの吉田雅史氏。その取り組みの様子や気付きについて紹介する。

パーソルキャリア株式会社 転職メディア事業部 マーケティング企画統括部 マーケティング戦略部 マーケティングアナリティクスグループ 吉田 雅史氏
パーソルキャリア株式会社 転職メディア事業部 マーケティング企画統括部
マーケティング戦略部 マーケティングアナリティクスグループ 吉田 雅史氏

事業KPIを可視化する「DODA Marketing Dashboardプロジェクト」

 2017年に株式会社インテリジェンスから社名変更した「パーソルキャリア株式会社」。パーソルホールディングスのリクルーティング事業部として、アルバイト求人情報サービス「an」や転職サービス「DODA」など、求職者と企業を対象に幅広くサービスを提供している。

 吉田氏は「DODA」を手がける転職メディア事業部に所属し、その中でデータエンジニアとしてマーケティング活動に取り組んでいる。もともとJavaを用いた勤怠管理アプリケーションの開発を担当しており、ScalaやGroovyなどを好んで使い、DevOpsなどのアジャイル開発や分散処理などにも興味を持って触れてきた。そんな吉田氏の現在の仕事は、部署のデータを「いい感じ」にすることだという。すなわち事業KPIの可視化やExcel帳簿作業からの移行、他部署とのデータ連携の窓口、そして日常業務を改善するためのツール作成などが該当する。

 その中で今回は「DODA Marketing Dashboardプロジェクト」と名付けられた事業KPI可視化プロジェクトについての紹介が行われた。このプロジェクトの始まりは、「前日のKPIを出社してからすぐに見られるようにすること」が目標だったという。2014年にスタートし、4年目を迎える現在も、事業活動のKPIをマーケティングとひもづけることを目標として進行中だ。

初期はエンジニアが牽引。信頼を重ね合い持続的なチームに

 プロジェクトの開始のきっかけは、Excelでデータが管理されていたため、マーケティングデータの閲覧にタイムラグが発生するといった課題だ。それをWeb上に移行してスピーディに閲覧できるようにしようとプロジェクトがスタートした。そこから徐々に範囲を広げて「データドリブン」な環境を実現する施策へと成長・成熟してきたという。その間、組織・エンジニアはどう変化していったのか。

 まずプロジェクトの初期について、吉田氏は「エンジニアがいない組織からエンジニアがいる組織へシフトするには、まずは優秀なエンジニアが必要だった」と語る。トップの意志を理解・共感したエンジニアが参画してこそスムーズなプロジェクト化が可能になるという。しかし、本番は参加してからだ。

 「最初の頃はエンジニアがマイノリティなので負担も重く、作業に没頭しがちになります。しかし、チームの一員としての存在感が希薄になることは決して望ましい状態ではなく、社内調整や業務要件整理など地道な業務も能動的に取り組み、エンジニア以外の人との関係性を密に作ることが重要です。そのためにはチーム内での役割を明確化し、ゴールを共有し、さらに認識の齟齬が生じないよう、確認を密にフィードバックしながら進めることが求められます」

 吉田氏はエンジニアとしてのスタンスについてこのように語り、エンジニア以外の人と連携しながら進めるアジャイル開発に慣れることが不可欠であると強調する。さらに業務の知識を吸収してコードやアプリケーションに反映していくこと、目の前の課題ではなく本質的な課題を一緒に考えること、業務の効率化、解決した先を見据えて動くことなどを役割として挙げた。

 なおスタート時のプロジェクトチームのメンバーは5名程度だったが、当初から内製BIをスクラム開発して用いたという。さらにIT部門や企画部門など社内の他部署との調整、交渉を通じて、プロジェクトを回せることをアピールし、協力を取り付けた。

エンジニア以外の社員と関係性を築くことが重要
エンジニア以外の社員と関係性を築くことが重要

 当時を振り返り、吉田氏は最も大切なこととして、「お互いをよく知ること」を挙げる。そのために、例えば「KPT法」を用いて四半期ごとにプロジェクトの振り返りを実施すること、メンバーの人となりや考え方を知るためにワークショップを開催すること、そして月並みながら部署内の表彰制度を活用することもあったという。

 「エンジニアがいない組織からエンジニアがいる組織へ転換する際に、最終的に最も重要なものは、お互いが信頼し合える『信頼貯金』を増やしておくことだと思います。最初の頃は結果をすぐに出すことが難しいものですが、徐々に信頼貯金を貯めていくことで協力を仰いでいくことができます。できれば個人だけでなく組織としてそうした環境が作れることが望ましいです」

Webエンジニアからデータエンジニアへのシフトチェンジ

 それでは、個人としてWebアプリケーションエンジニアからデータエンジニアへとシフトしていったのか。まずはスキルセットについて、吉田氏は「解決したい課題に合わせて言語を選択すること」に始まるという。

 「なんでもJavaでScalaで、と決まった言語でやるのがいいのかといえば、そうではありません。ExcelならVBAで統計や分析ツールとして使ったり、WindowsでPythonが使えない時はGoLangを使って小さいツールを作ってデータ転送ができるようにしたり、やりたいことに合わせて言語を変えるようにしました」

 もう1つ重要と感じていることが「プロトタイプをすばやく作り、捨てやすいように作ること」だという。どうしてもKPIを設定するには時間がかかるため、早めに失敗する方がよい。そのためには、サクッと作って違ったと思えば容易に捨てられる、そんな環境を作ることが効果的だ。例えば捨てやすいようにモジュール化する設計をあらかじめ行っておくと、自分たちが設計しやすく運用しやすい。そして、早くサイクルを回すために、ワンクリックでデプロイできる環境を作っておくことも有効だ。そうした「足回り」も自分たちでやることで、変化に対応できるようになったという。

 さらに、吉田氏はデータエンジニアとなったことで、当然ながら「データとの付き合い方」が変わったと語る。

 「Webアプリケーションなどでは『とりあえずリリースすることが大切』とされ、フレームワークを使って仮説検証をすばやく行うことが大切でした。しかし、データはアプリケーションよりも寿命が長く、データをしっかりとモデリングし、それを用いて運用できるよう経験やスキルを積んでいくことが重要だと思います」

 他にも、データとしての整合性を担保するため自分たちの作ったデータは自分たちで守る、社内のIT部門に仲間を見つけて依頼できるところはする、本を読んでおきSQLアンチパターンの事例と遭遇しても慌てないようにする、他のシステムと連携するなどを意識していくことがよいという。

 またエンジニアとして新しい技術にも挑戦する必要があるが、リソースが限られる中で、必要なものだけ取捨選択することが不可欠だ。そのためには早いうちに試してみて、失敗することが必要となる。まず自分たちの業務や開発にマッチしているかを試すこと、そして課題をチーム内でシェアし、「スパイク(技術調査)」を有効活用し、成果は随時共有すると同時にだらだらと続けないよう撤退する条件をあらかじめ決めておくようにする。また、必要に応じて新しい言語を習得する場合には、もし有用な言語ならチームで教育を行って共有していくことが必要だという。

スキルを補完し合い、誰もがデータを見られるデータドリブンな組織へ

 エンジニアが組織に入り、個人として力をつけ、その先に吉田氏のチームが目指すのは「データドリブンな組織への変化」だ。吉田氏はデータサイエンティスト協会が設定した「データサイエンティストに求められるスキルセット」を示し、「この3つのスキルセットをすべて持っている人が日本にどれだけいるだろうか」と問いかけた。確かに必要な知識・スキルをすべて1人で担うのはなかなかハードルが高いものがある。

データサイエンティストに求められるスキルセットを、チームで補完する
データサイエンティストに求められるスキルセットを、チームで補完する

 そこで、吉田氏のチームはメンバー全員でカバーし合うことを選択した。データサイエンティストは統計学、機械学習、ビジネス側であれば問題解決スキルやドメイン知識、エンジニアはSQLの書き方やアジャイル開発など、それぞれをそれぞれの分野の担当者に伝播・教育する。

 さらにデータの可視化が成熟していくと、データの民主化が求められる。1つ見えると、次々と見たくなるのが必然であり、それに応える必要がある。マーケティング側でその多くが実際の業務にデータを活用する必要があり、その数は多い。そこで吉田氏のチームは、もっと見たいに応えつつ、見たいものを一緒に考えるといったコンサルティングも社内に対して行った。そして、モニタリングの体制を作って仮説検証を行い、フィードバックループを回すサイクルを確立させたという。

 「単なるデータクレンジングだけでなく、どんなデータがどこにあるのか、どうやったら持ってこられるのか、いわば『魚の釣り方を教える』ようなものと言えばよいでしょう。さらにプロジェクトの初期はとにかく早く見せることが第一でしたが、成熟期になるにしたがって精度や正しさを重視するようになりました」

 とはいえせっかくのスピードを殺さないよう、マネージドサービスの活用、オンプレミスからクラウドへの移行、TableauなどプロプライエタリなBIツールへの移行なども考える必要があるという。そして実際に手を動かす作業が少なくなったところで、自動化、省力化を考え、さらに業務そのものを改善していくという“本来”の仕事へと取り組めるようになる。

 「とはいえ、プロジェクトが長くなり最適化が進むと、自分たちが『何のためにいるのか』『なぜここにいるか』といった問いが生じることがあります。その問いに対して、プロジェクトチームのメンバー全員でインセプションデッキを活用し、改めてゴールや目的の共有を行いました。その上で、挑戦できる組織、環境、文化づくりを行っていくことが大切だと思います」

 最後に吉田氏は、エンジニアがいない組織からいる組織にするためのポイントをまとめ、「今後、分析はAIがやるとされる時代が到来する。その時に限りある人・モノ・金をどのように使うのかを組織として考え、備えておくことが必要になるだろう」と述べ、「その未来に備え、エンジニアだけの問題ではなくチームや組織で一丸となって考えることができれば」と意欲を語った。

お問い合わせ

 パーソルキャリア株式会社

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

All contents copyright © 2005-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5