はじめに

はじめまして。レバレジーズでデータアーキテクトをしている佐藤です。

私はデータアーキテクトではありますが、若年層向けの人材紹介事業を行うハタラクティブ事業部に所属し、データ戦略室とも連携しながら業務を進めています。

今回は、私が事業部所属だからこそ感じたデータアーキテクトの価値と、取り組んでいることを3つご紹介します。

経歴

まず、簡単に私の経歴をお伝えします。

営業職としてレバレジーズに入社し、キャリアアドバイザーとして1年半ほど若年層の就職支援をした後、事業企画部に異動しました。
当初はファシリティ関連の業務や障がい者雇用社員の管理等、様々な業務に従事していましたが、簡単なモニタリング作成をきっかけに徐々にデータアーキテクトの業務に携わるようになりました。
長い間1人で業務を進めてきましたが、縁あって3年ほど前からデータ戦略室と一緒に仕事をしています。

現在は営業・マーケティングに関するKPIモニタリング環境の構築や、データマート等のデータ活用基盤の整備を中心に、自社SFAの設計等にも携わっています。

事業部におけるデータアーキテクトの価値

元営業職であり長く同一事業部内でデータを扱っている私が、特に感じていることを実際の例を交えてご紹介します。

①不整合データを検知し、データの正確性を向上させる

立場上、大きなプロジェクトを動かすよりも、現場から上がってくる依頼や要望に応えて大小のアウトプットを出していくことが多く、その分データに触れる機会もかなり多いです。
その中で、「クエリは合っているはずなのに数値が合わない」ということがあった際、調査をした結果システム内部の挙動に問題があった例がしばしばあります。

例

内容が更新された時、元レコードに削除フラグが立ち新たにレコードが生成されるテーブルにおいて、他施策の影響による不具合で削除フラグが立たず、結果重複したレコードが生成されてしまった
重複応募があった求職者情報の重複対応を行う際に、対応後のIDに置き換える必要のあるテーブルに漏れがあり、一部置き換わっていないことで正しい紐づけがされなくなった

上記は実際にあった例ですが、いずれもシステム側・ユーザー側には何の不具合も起きなかったために、発見されず放置されてしまっていたものでした。
システム設計において考慮しきれなかった部分やDB上の不具合については、何らかのエラーが起きない限り発見することが難しく、実際に運用する中で初めてわかることも多くあります。
これらを見つけ次第、ある程度現状調査を行った上で報告を上げるとともに、理想状態を設計して提案まで行うようにしています。

日常業務の中の副産物的な要素が強いですが、この日常業務自体がある種「データのパトロール」を行っている感覚に近いと感じています。
正しいデータを正しく蓄積していくという目的において、非常に重要な役割を担っていると言えます。

②共通言語を作り、全員が同じ認識で会話できるようにする

部署内の様々な人と会話をする機会がありますが、同じ単語にもかかわらず別の意味で語られているもの、定義が曖昧なためその都度意味の認識合わせをしなければならないもの等、会話は曖昧さで溢れていると感じます。
すり合わせの工数がかかるだけでなく、双方の意図が誤って伝わり意思決定に多大な影響を及ぼすこともあり、決して放ってはおけないものです。

例

同じ「稼働中の求職者数」を集計しているモニタリングの数値に相違があった
- →モニタリングによって「稼働中」の定義に違いがあり、異なるプロセスの求職者を集計していた
「推薦数」という単語が現場で使われているが、toC側とtoB側で別プロセスを指していた
- toC側：社内の企業担当者に対し、企業への求職者の書類送付を依頼すること
- toB側：企業に求職者の書類を送付すること

これらを解消するために、曖昧さのある単語の再定義を行いました。
前者に関しては、企業に求職者を紹介し関わりが発生した段階で「稼働」とし、社内で調整を行っている段階に「稼働準備」という新たな名称をつけることで、明確な区切りを設け改めて定義を意識し定着しやすいようにしました。
後者に関しては、元々存在していたものの定着していなかった「推薦依頼」という単語をtoC側プロセスの名称として、各モニタリングを修正するとともに会話の中で意識的に訂正をするようにしました。

目まぐるしく変化していくサービスの中で、こういった状況は避けられないものです。
誰かが正していかないと自然に改善していくものではないので、事業KPIに関わる単語の意味の統一に責任を持つ人の存在はとても重要です。

③現場のオペレーション/データ蓄積・活用の双方の視点に立ったDB設計

所属部署では営業活動のほぼすべてを自社SFAで管理しているため、SFA開発チームが日々システム改修に励んでくださっています。
その中で、（システム観点では正しい前提で）ユーザー視点に立つと困る場面がありそうだったり、データ蓄積・活用観点だと正確性に欠ける仕様だったりすることがあります。

例

名寄せの際、状況にかかわらず最新の日付を持つレコードを正として扱う
- →営業のオペレーション上、古い方で営業活動が進んでいることがあり、最新のものに名寄せしてしまうと営業活動に支障が生じる恐れがある
新しい概念が追加される際の、正規化の観点を優先した設計
- →クエリを書く際に複数カラムを使用してjoinする必要があり、仕様を知っている人でないと誤った記述になるリスクがある

必ずしもすべての要素を満たせるわけではなく、折衷案を探る必要がある場合も少なくありませんが、システム側だけでなく複数観点から検討できることはメリットが大きいと感じます。
現在はシステム改修施策のレビュー会に参加するようにしていて、現場とデータの観点から意見を出させていただいています。
積極的に設計に関わりにいく中で、開発チームの方々も大きな施策の際にはデータ側のレビューをフローに組み込んでくださっており、部署全体として様々な視点からの最適解を模索する風土ができていることにありがたさを感じています。
様々なポジションの人と関係構築をすることや現場の細かなところに目を配って現状を把握していくことは、データアーキテクトに必要な要素ではないでしょうか。