SmartHRでデータ分析基盤とデータマネジメントをはじめて１年がたった件
SmartHRのtakashoです。
12/24の事業推進本部のアドベントカレンダーを担当します。メリクリ！そしてnoteデビューです！
アドベントカレンダーも今年も残りあとわずかとなってきました！
私は全社に向けた意思決定支援のためのデータ分析基盤の開発保守やデータ関連の諸々の仕事しています。今日はこの諸々の部分をお話します。
自己紹介
私は2020年７月にCSのデータアナリストとして入社し、データの可視化、集計、分析に従事しました。2023年9月には全社向けのデータ分析基盤の開発保守を前任者から引き継ぎ、2024年からは軸足がデータエンジニアリングに移りました。
もともと10年以上エンジニアリングの経験があるため技術のキャッチアップは楽しく行えて今年４年ぶりくらいにエンジニア歴が+1されました。
データ分析基盤のと開発体制の変遷
現在のデータマネジメントを語る前に、弊社のデータ分析基盤と開発体制についてご紹介します。これは私が入社した2020年7月を基準にそれぞれの世代にまとめました。
まず第1世代の構成としてはFivetranというETLツールを利用してBigqueryへデータを連携していました。この時代はインフラ担当の方が1人で運用していた時代です。当時としても100を超えるテーブルを捌いていたのでFiveranの優秀さが伺えますね。
第2世代はGCP化がされdatalake層(データを貯める所)とwarehouse層(データを公開する所)が作成されました。データ連携もCloud Composerになり連携処理の自動化が行われ現在の礎となっています。
後々になってこの構成が将来戦える構成だなと感じています。前任者すごい！
第3世代今ここです。第２世代から引き継いで2024年の上期は私とヘルプで手伝ってくれる方の2人体制で、2024年の下期は私とデータエンジニアとして新しく入社してくれた2人を含めた3人体制で構成の拡張を行ってきました。主な開発ポイントは下記3点でした。
集計済みデータを蓄積するdatamart層(集計済みデータを蓄積する所)の追加
データ連携部分のリファクタリング(データ連携方式の変更、環境の分割)
Staging環境の構築
あれよあれよとデータマネジメントをやることに
弊社のデータ分析基盤は前述した変遷を辿って構築・拡張されてきました。私としてもデータ分析基盤自体を引き継いで半年間開発に集中してきて久しぶりの開発ライフでした。
その中で、データ分析基盤への依頼が増え、連携するデータの数が増え、利用者も増え、、、、という状況になっていきました。
2024年下期にはデータエンジニアとして2人の入社が決まりました。期待値としてデータマネジメントという言葉だけもらっていた部分もあり、今期の注力は開発体制の構築とデータマネジメント、スコープの開発の推進という引っ張る系のミッションを持ってスタートしました。最初はデータマネジメントに対しての解像度がぼやけていた部分がありますが上期から関わってくれていたセキュリティ、法務そして今期関わった監査の方と関わる中で自分として進むべき方向がみえたので、自分なりのデータマネジメントの整備の活動をしてみました。
実施したデータマネジメントと感じた所感
データマネジメントどこからやるか問題
正直な話、最初はデータマネジメント is 何というところから理解していくと多くの人がDAMAのDMBOKに行き着くと思います。そして知識体系の重厚さで肩を落とすと思います。私もDMBOKの日本語版を一通り読みましたが「これぜんぶやるのぉ。。。」と昔のPMBOKの書籍を手に取ったときと同じ感想を持ちました。
データマネジメントの始め方としてはできるものから手を出すが良さそうと思いました。
はい、みんなが言っていることですね。サンプル数が1ふえましたよ。
冗談はさておき、「アウトカムが明確でインパクトが大きい」、「周りの熱が高い」のいずれかから始めて良いと感じました。理由を言語化するとどちら他者からの協力が得やすいのが理由です。
データマネジメント自体、すべて定義して文書化したからと言ってすぐに売上が上がる！コストが下がる！みたいな結果がすぐにわかるものではないと解釈しています。たとえばwikipeidaのデータ管理に記載のあるDMBOKの知識体系や経営のためのデータマネジメントにもJDMCの定義として「データをビジネスに活かす事ができる状態を継続的に維持し更に進化させていく組織的な営み」とあることから、データマネジメント自体はデータを貯める、使うというプロセスを安定的に実現させるためのルールであり、様々な部署を巻き込むためには巻き込む先にもモチベートする何かを持っていてもらえるとことが楽に進むのだと感じました。
私の場合は結果論にはなりますがセキュリティと開発体制構築に焦点を当てた形になりました。
ただ、選択しなかったDMBOKの知識領域を軽視するわけではありません。どの会社や現場でも一定水準を自然と保っていたりするケースがあると思うのでその部分は後回しにしても良いと考えています。例えば開発体制の成熟度があればDMBOKにあるデータ開発の一連のプロセスを定義するよりも別の領域の整備をするほうがインパクトが大きいと思います。
セキュリティ・法務との連携
弊社のデータ分析基盤は社内の様々なデータが集まっており、規模、データ量ともに社内有数のものになっております。その中でセキュリティ・データの扱い方についてここ１年色々と連携を行ってきました。温度感が一番高かった領域かも知れません。特に今年はランサムウェア絡みのニュースで自分自身の温度感が高くなりました。
今期通して必要と思った観点は下記になります
データ分析基盤におけるセキュリティとオペレーションの整理
GCPにおける各サービスの携帯性について
一番大きかったのはセキュリティとオペレーションの整理がついたことです。もともと構成管理ツールとしてTerraformを利用していましたが、インフラの変更の多くをTerraformに任せる方向にしています。ロール付与や高レベルなセキュリティを求められる箇所については開発者とセキュリティが一緒になってPRのレビューを行う体制を整理できました。また、Security Command Centerの導入が行われ来期からはセキュリティに対する脅威を通常の開発作業の中で是正をしていく体制もつくれました。
思い返してみればDevSecOpsのような体制のスタートが構築されたと感じています。
また、GCP上に構築するサービスについても携帯性を意識した設計が必要であると感じました。構築が容易であるがゆえ巨大な仕組みになりやすいと感じました。スピードとあるべき姿のトレードオフだとは思いますが、GCPの各サービスもバージョンの更新が容赦なく行われていくので追従が可能な構成を目指すことは必要と感じました。また、何らかの形で別環境への構築が必要になった場合にも迅速に対応ができる設計も合わせて重要だと感じました。
データ分析基盤の開発戦略
2024年の下期から私を含めて3名体制になりました。2024下期の開発スコープを決める中で整理したものとしてデータ連携部分の改修を主な開発スコープとして設定しました。結果的にエラーの低減やメンテナンス性の向上はできたと感じました。改めて2025年上期の開発スコープについても主に現状への最適化に向けて取り組む形になりそうです。
改めて開発スコープの設定するうえで感じたことは、処理の見直しをしやすい体制をいかに作るかは念頭に持ってよいかと感じています。直近で感じるのは過去時点の要件が未来を見ると合わなくなってくる印象を持ちました。社内ではデータ量の増加、データを利用する人数の増加、データの利用方法の多様化が発生し、社外では円安などのコスト変動が発生しました。これらは過去時点では許容されると考えられてきたものが、現時点では許容が難しくなるということかなと感じます。
今後の展望(超個人的見解)
超個人的な見解の今後の展望についてです
データ分析基盤をデータ活用基盤に
「データ分析基盤」という言葉であれば、分析・可視化を行うためのデータを蓄積している場所というような印象が多いと感じています。近年だと蓄積したデータを各サービスに連携するリバースETLやデータサイエンスやLLMを活用するためのMLOpsなど、データ活用における一つのハブになり概念や用途が拡張されてきている様に思えます。そのため分析のみならずより社内の広範囲でデータの活用が可能な世界を作っていけたらと思います。
システムの新陳代謝を加速させる組織、アーキテクチャへ
実際にデータエンジニアリングに触れて感じたことはツールや考え方の流行り廃りやバージョンの更新がWebを作っていた頃よりも早い印象があります。技術については流行りに振り回されないことは大事だと思いつつ有用な概念やアプローチの取り入れは必要だとは思います。単に今が技術の過渡期なだけかも知れませんがある程度枯れた技術を取り入れつつ、バージョンの追従をしつつという形で思ったよりも開発頻度が多くなる印象です。
そのため、リファクタリングによる新陳代謝とそれを回せる業務フロー、手数を低減できるアーキテクチャの設計を意識したシステムと人を一体としたサイクルを作っていく必要があると感じています。
安心安全なデータ利用を社内へ
データ分析基盤を作ったとしてもデータの利用がしづらい状態は作りたくないと思っています。個人的には品質、リスク、コストの切り口は抑えておきたいです。
品質については、データの欠損、誤り等、想定外のデータが出現により利用のハードルを上げたくないと考えています。そのためデータのクリーニングや集計データの蓄積など要望を踏まえたデータの整備は必要と思っており、より整備はすすめたい。
リスクはセキュリティ対応とデータ利用範囲の明確化があると考えています。セキュリティ対応はリスクとなるデータについてはマスキングやそもそも利用ができなくするなど問題になるデータを扱える状態にせずリスクを生まれる前に消し去りたいです。データ利用範囲の明確化はどの範囲でそのデータを使ってよいか？を明確にして意図しない利用からの事故を防止したいです。
コストは最近の円安やデータの増加を強く感じています。不要なコストの低減は常に意識はしても良いかなと感じています。最近ではFinOpsというクラウドリソース効率と価値の最大化と云う考え方を日々のルーチンに取り入れてコスト効率の良い状態を作りだし、データ分析基盤の社内への存在価値を最大化できれば良いと考えております。
終わりに
１年間データ分析基盤の開発を含む、データマネジメントに関わってきてあらためて改めて学びが多かったと感じました。
DMBOKに書いてあることや、自分自身がやってきたことは「当たり前のこと」と感じる部分が多く、「情報」自体もふわっと理解していた部分があり理解も十分ではなかったと思います。
１年走りきったうえで振り返ると、ただのデータの環境を整えるというよりも経営資源としての「情報」を安全、安定的に蓄積し活用できる状態を作るかという解像度が上がりました。来年はデータ分析基盤の開発を含めデータマネジメントの攻めと守りが進んだ形をつくっていきます！
そこでちょっとした宣伝です。
SmartHRでは一緒に働く仲間を募集しています！興味のある方はお気軽にお問い合わせしてみてください！