こんにちは。Analyticsチームの上田健太郎です。

ニーリーはPark Direct (パークダイレクト) というSaaSの提供により、モビリティ分野のDXを推進しています。Park Directは現在も急成長を続けており、データ分析によって大きな成果を得られる可能性が満ちています。そのような中で、Analyticsチームは2023年5月に発足し、データ分析および基盤の構築・運用を担当しています。今回は、Analyticsチームが1年目にどのような取り組みを行ってきたかご紹介します。

ニーリーでデータを分析する面白さ

タイトルの通り、ニーリーはデータ分析の宝庫だと考えています。はじめに、そう考えている理由について述べたいと思います。

1つ目は、Park Directのサービスの特性上、分析の対象が多いことです。Park Directは駐車場の管理会社・駐車場のユーザーの双方にサービスを提供しているため、駐車場の管理会社を対象とした「to Bの分析」、駐車場のユーザーを対象とした「to Cの分析」、自社を対象とした「to Inhouseの分析」の三者が成立します。特に「to Bの分析」と「to Cの分析」の両方を実施できる環境は少ないので、魅力的な点であると考えています。

2つ目は、ニーリーが保有しているデータがユニークであることです。Park DirectのWebサイト上の行動データに加えて、「駐車場の賃料・区画・位置データ」「車両データ」「借主のデモグラフィックデータ」といったリアルワールドのデータも保有しています。私の前職はECサイトの運営会社でしたので、データ分析の対象はもっぱらWeb上のデータでした。ニーリーに入社してからは、リアルワールドのデータも分析対象となり、「周辺駐車場のレコメンド」といった施策を実施できたのは新鮮でした。

3つ目は、Park Directが対象とする月極駐車場業界はデジタル化が始まって間もないため、データ分析のブルーオーシャンである点です。まさにこれからデータに基づく最適化を行っていくという局面のため、要点を押さえさえすれば、単純なクロス集計データだけでも大きな効果を生み出すことができます。早期からデジタル化が行われていた業界では、データに基づく最適化が進んでるが故に効果を生み出しにくいことが多いので、この点は魅力的であると考えています。

チームのミッション紹介

Analyticsチームのミッションは、事業や経営の意思決定を支援するデータ分析結果の創出です。

データ分析の依頼は、Analyticsチームの発足以前にもビジネスチームを中心に寄せられており、開発チームのメンバーがアドホックに対応していました。

しかし、リクエストベースであるが故に、必要最低限のものしか分析できていませんでした。前述の通り、ニーリーには事業成長に繋がる可能性のある膨大な分析対象があるにも関わらず、それらには手が行き届いていなかったのです。

また、組織の拡大と権限委譲に伴い、事業や経営の意思決定に関わるメンバーが増え、データによる意思決定の支援の重要性が高まりました。

以上の経緯を踏まえ、「事業や経営の意思決定を支援するデータ分析結果の創出」をミッションに掲げ、Analyticsチームが発足しました。

チーム発足からこれまでの歩み

Analyticsチームの発足は2023年5月からですが、一部の活動は発足前から始まっていました。概観は下記の線表の通りです。

次に、それぞれの詳細をご紹介します。

Analyticsチーム発足以前

チームが発足する前から、ニーリーではRedash (BIツール) を利用したデータ分析が実施されていました。マーケティングチームなどから寄せられる分析・集計依頼を、開発チームが分担して対応する、という形式です。
自分の入社後に行った具体的な業務としては、前述の分析・集計依頼への対応、マーケティング用の分析ダッシュボードの構築、集客強化のための駐車場のレコメンドの実装などが挙げられます。これらを通じて、分析に関係するデータモデルの把握・社内のデータ分析に関係する課題の把握を進めました。

Analyticsチーム発足

2023年5月にAnalyticsチームが発足し、私が一人目のメンバーとなりました。発足がこのタイミングになった背景には、業務を通してチームのミッションが固まったことと、入社時から所属していたSREチームが成長し、Analyticsチームの立ち上げができる状態になれたことがあります。

データ集計・分析の環境整備を実施

発足から半年ほどは集計・分析クエリの修正にあたっていましたが、それと並行して、修正の効率化、および今後のAnalyticsチームがミッションにより注力できるようにするために、データ集計・分析の環境整備も実施しました。

1つ目は、Redashの運用改善です。Redashはデータ集計・分析だけでなく、決済・会計業務などに用いるデータの抽出にも利用されている重要なツールなのですが、インフラ部分はSREチームによって管理されていた一方で、Redash上のリソース (ダッシュボード・クエリ) については管理者がいない状態でした。それ故に、利用者・利用有無が不明なリソースやRedashに負荷をかけてしまうリソースが増加し、前述の案件のクエリ修正以前にRedashの運用自体が厳しい状況でした。そこで、リソースの利用者・利用有無・処理の重さなどを即時に取得できるダッシュボードを構築した上で、利用者や用途をラベリングし、その情報に基づくリソースの定期的な棚卸しを実施することで、運用を改善しました。

2つ目の取り組みとして、今回のように複数のRedash上リソースの修正が必要になった際の対応を効率化するために、修正の優先度をシステマチックに決定できるルールを定義し、高い優先度のリソースを即時に洗い出せるようにしました。また、修正対象のクエリを効率的にレビューできるよう、GitHub上でクエリを管理・レビューできる環境を構築し、それらのクエリをRedashに自動反映するツールも作成しました。

3つ目の取り組みとして、「データモデルの変更が集計・分析クエリに及ぼす影響を最小化する」「データモデルへの深い理解が無くても集計・分析クエリを書けるようにする」を目的に据え、Viewの整備を行いました。データマートでなくViewを作成した理由は、事前集計によるパフォーマンスの改善よりもデータモデルの変更に柔軟に追従できるようにする方が重要であったためです。まず、モデルを熟知したエンジニアにサポートに入っていただいた上で、効果的なViewを作成するための方針として、主に次を洗い出しました。

• 用途別にViewの構成を変える

  • 分析用・集計用であれば、高頻度にjoinされるテーブルを事前にjoinしたViewを用意する

  • 業務の元データ抽出用であれば、システムの画面と対応するViewを用意する

• 定義が確定している指標を事前に計算する

• カテゴリ値は事前に日本語の意味に置換する (「1 = 契約済み」など)

また、持続的にViewを運用できるよう、作成方法・更新方法・ドキュメントのフォーマットなども検討した上で、Viewを作成していきました。

データ分析を本格化

前述の取り組みと並行して、2023年7月からはAnalyticsチームにデータ分析を依頼する窓口を設置し、依頼対応を開始しました。約1年前からデータ分析の対応をしていたことと、CTOの三宅さんをはじめエンジニアの仲間がビジネスチームに周知してくださったことで、窓口の設置と同時に多数の依頼をいただく形となりました。

特に印象に残っている分析は、オンボーディングに関する分析です。オンボーディングとは、Park Directの導入が決まった駐車場について、区画の利用状況や契約者の情報の管理をPark Directのシステムに移行する作業を指します。分析では、オンボーディングに要する期間を短縮することを目的に、短縮に直結するイベントを仮説・データに基づき明らかにしました。また、そのイベントの実施状況、オンボーディングの実施状況、目標の達成度を可視化するダッシュボードを設計・実装しました。ダッシュボードは依頼元チームがほぼ毎日見て、ご活用してくださっています。

現在の取り組み

2023年10月からは業務委託のメンバーを加えた2名体制で、データ分析基盤の構築に着手しました。背景には、データ分析の対象範囲がPark Directのシステム外まで拡大し、業務支援ツールや広告管理ツールのデータを収集・統合する必要が生じたことが挙げられます。
運用コスト・金額コスト等を総合的に検討した結果、DWHにはBigQuery、データ転送・加工にはtroccoを利用を利用し、BIツールには引き続きRedashを利用することとしました。まだ過渡的な状態ですが、データ分析基盤の構成は下図の通りです。

11月からは第1弾としてZendeskに蓄積された駐車場のユーザーの問い合わせデータを基盤に取り込み、12月からは問い合わせ対応の生産性向上を目的としたデータ分析を開始しました。例えば、問い合わせのカテゴリ毎の対応工数を可視化したダッシュボードを作成し、それに基づき大幅に工数を割いている対応の自動化・機能化を開発チームに依頼する、といった取り組みです。基盤の導入前はZendeskとスプレッドシートによる限定的な分析に留まっていましたが、導入後はRedashで自由度の高い分析が可能になりました。また、データの取り込みも自動化され、分析のリードタイムが大幅に短くなりました。

今後やりたいこと

1つ目は、データ分析・分析基盤提供による業務生産性の向上です。ニーリーでは業務の生産性向上が事業の重要課題となっています。今後は、前述のZendeskの件のようなデータ分析を中心とした取り組みに加えて、分析基盤を用いた複数データソースをまたぐ分析も実施したいと考えています。
例えば、マーケティングチームは管理会社向けに分析レポートを提供しているのですが、それに用いるGoogle AnalyticsのデータとPark Directのデータが統合されていないが故に、作成に多くの工数を要しています。データ分析基盤にデータを統合することで、工数を大幅に削減できると同時に、両者のデータを横断した分析も可能になります。

2つ目は、事業・経営に関する重要KPIの管理体制の強化です。これまでデータ分析・分析依頼を複数のエンジニアで分散して対応してきたが故に、同じKPIの集計クエリが複数個作成され、それぞれの定義が微妙に異なる、という状況が発生しています。こちらについては、View・データマートの充実化やRedash上のリソースの管理体制の強化などによって対処していきます。数値の定義を細かく見直したり整合性を完璧に担保したりと、地道な作業もありますが、投資家への説明などトップ層の議論で必須の材料になるので、チームの中でも重要でインパクトのある業務です。

3つ目は、データ分析を行うメンバーを増やし、チームを拡大していくことです。データ分析の需要が高まっている中で、分析業務を行えるメンバーの少なさがボトルネックになりつつあります。解決のために、Analyticsチームの採用を強化することと共に、テーブルドキュメントの充実化・SQLのレクチャーなどを通じて、データの民主化を図っていきたいと思います。

最後に

今回は、Analyticsチームの1年目の取り組みについてご紹介しました。
ご紹介を通して、ニーリーで働くこと、あるいはAnalyticsチームで働くことの魅力として浮かび上がったのは、主に次の3つです。

• 急成長中のプロダクトをもっており、データ分析によって大きな成果を得られる可能性が満ちていること

• データ分析だけでなく、アナリティクスエンジニア・データエンジニアの領域にもバランスよく取り組めるため、データに関する総合的な人材を目指せること

• 役職・部署を超えてフラットに話し合えるため、シナジーを生み出しやすいこと

ニーリー・Analyticsチームに少しでも興味をもっていただけた方は、ぜひお気軽にお声がけください！

株式会社ニーリー　
プロダクト本部　クライアント・グロース本部　プラットフォームグループ
上田 健太郎　Kentaro Ueda
2017年にECサイト運営企業に新卒入社。複数の事業部を対象に、データ分析・データ分析基盤の整備に2年間従事。2019年からECサイトの開発チームに異動し、WEBアプリケーションおよびAPIのオンプレ→クラウド移行・リアーキテクチャ・データ分析に3年間従事。2022年8月に株式会社ニーリーに入社。

herp.careers P11_アナリティクスエンジニア

株式会社ニーリー

募集要項をみる

herp.careers O01【エンジニア】オープンポジション

株式会社ニーリー

募集要項をみる

■開発メンバーとのカジュアル面談はこちら

・三宅 克英（取締役CTO）
モビリティSaaSのプロダクトグロースについてお話しましょう

・菊地 弘晃
Mobility SaaSを一緒に開発しませんか？