Helpfeel Tech Conf 2026: 膠着したRe: Engineeringにドロップキック — リアーキテクチャを前に進める

2026-09-12(土) Helpfeel Tech Conf 2026 @竹芝
膠着したRe: Engineeringにドロップキック — リアーキテクチャを前に進める

Transcript

1. 膠着したRe: Engineeringにドロップキック リアーキテクチャを前に進める(データエンジニア向け) Sorachi (@contradiction29) 2026-09-12 Helpfeel Tech Conf 2026 1
2. 自己紹介 Sorachi (@contradiction29) - 所属: Helpfeeel Helpfeel開発グループ - -> 磨き上げチーム - -> データエンジニアリングユニット - -> ユニットリード - Helpfeelのデータエンジニア - 趣味: Slackのemojiで遊ぶ 2
3. Helpfeelにおけるデータエンジニアの役割 1. Helpfeelの導入効果の証明、および改善の方向性の算出に活用でき るシステムを構築し、運用すること - 2. 3. 4. 今日のメインの話！！ 集計データを利用するアプリケーションに対し、安定的にデータの提供を 行うこと 社内でデータを利用する業務に協力し、業務改善に貢献すること 社内のデータの利用者のリテラシー向上に貢献すること 3
4. Helpfeelにおけるデータパイプラインの役割 - - - 主な入力データはGoogle Analytics 4からの収集データ - (他にもある) - イベントが発火し、GA4上に蓄積 - 蓄積されたデータがBigQueryにエキスポート BI向けにデータを加工し、集計数値のレポーティングに利用 - Helpfeelを利用する企業向けに提供 - エンドユーザーの利用に関する数値 数値例 - Helpfeelの検索を利用した割合 - 検索クエリのボリューム - 推定自己解決率 ※ 採用資料より引用 4
5. 危機と停滞 - - - 作られて3年経過し、データパイプラインの利用が定着 - (よかったね) - 諸々問題が発生(後述) - アーキテクチャ起因による原因であることが割と明確 リアーキテクチャによる解決策は3年前に提唱 - そして3年間近く前に進まず、膠着 問い: - なぜ状況が停滞したのか？ - 停滞した状況とどう向き合うか？ 今日の話のモチベ - 色々やってきた話を共有したい - 現状苦しんでいるデータエンジニアの力になりたい 5
6. 移行前: 「旧データ基盤」の構造 - - Universal Analyticsの終了に伴い、2022年~23年ごろに構築されたデータパイプライン GA4からBigQueryにエクスポートされたテーブルをBigQueryのスナップショットテーブル経由で論理参照する構造 日付・プロパティ単位の実質的なシャーディング 大体1サイト = 1プロパティ 現在のHelpfeelは900サイト以上ある 1プロパティ = 複数テーブルの構造のため、BI側は長大なSQLで参照を行う 図: 「旧データ基盤」の構造 大量のテーブルを論理参照する一つのデータセットがある 6
7. 旧基盤で起こっていた問題 - - - 図: データソース内に存在する巨大 SQL BIからのレイテンシが悪化 - パーティショニングもクラスタリングも一切効かない - 利用側からのクレームも定期的に発生 持続不可能 - BigQueryのデータセットは50万テーブルが限界 - 1プロパティ・1日で1テーブル使い切る構造になっている - プロダクトの成長に伴い50万テーブルを突破し、崩壊 ロジックの複雑化により拡張性が破綻 - 長大なカスタムSQLだけが利用可能 - 再利用ができないため、ビジネスロジックがデータソースの数だけ 分散 - 取りたい数値が増えるほど論理的に破綻していく - （拡張できないとは言ってない） 7
8. 発足する移行プラン - - BigLakeとdataformにより、加工ロジックを集積する 形で移行プランが発足 教科書的なELTアーキテクチャへの移行 - のちにdataformは御役御免 - dbtへ... 2023年ごろから移行プロセスを開始 したものの.... うまくいかない。原因は？ 図: 移行先のELTベース基盤 1. 2. 3. 局所最適の一致による現状維持 全体像の理解不足による温度感の低下 技術的な方針の混乱 8
9. 局所最適の一致による現状維持 - - - 開発側とビジネス側の二人三脚体制だったわけだが... 開発側は既存基盤の維持に手一杯 専業のデータエンジニアは存在していた 人手不足の常態化により、既存業務と並行してやり切る余力が生まれなかった 技術的な方針混乱（後述）により、移行に割けたはずのリソースが分散した ビジネス側は数字が変わることに抵抗感があった 前提 元の指標算出ロジックには要修正な箇所があった 修正し、正しいロジックに直すと、出てくる値が変わる 変わった数字の説明に追われるのは現場である toBサービスの都合上、顧客とのコミュニケーションが必要になる 数字が変わること自体に対する抵抗感 局所的に利害が一致し、結果として停止へ 9
10. 全体像の理解不足 - - 問題の構造ゆえに全体像の把握が難航 - 具体的にどこのSQLがヤバいのか？ - どの指標定義がヤバいのか？ - そもそもデータソースがいくつあるの？ - どのデータソースを、どのレポートが利用しているのか？ SQLも指標定義もGUI上からしか把握できない - 閉じた構造 誰も全体像を把握できない - 問題を理解していない - 影響範囲がわからず、どのくらいまずい問題なのか定量的に言えない 10
11. 技術的な方針の混乱 - - ※ Studioじゃない方 移行プラン自体が途中で方針変更され、 Lookerが流星の如く襲来 移行に割けたはずの人手が分散される - ビジネス側はキャッチアップや顧客説明に追われる - 開発側は現状把握調査ができなくなる Lookerへの移行計画は極めて難航した - 開発するにも、利用するにも、習熟コストが高い - 付属Web IDEによる開発体験があまりにもアレ - セマンティックレイヤー /Transform Layerとしてはdbtの方が格上 - 非常に高価 - 少人数のチームで扱うにはあまりにもつらすぎる - 致命的: 一番やりたいことが技術的に不可能 11
12. 考え方を変えてみる SQL Writing Time - まずやれることはやる - Lookerを廃止まで持っていく - AIの導入により業務を効率化し、 SQLを手書き する時間をゼロにする - データエンジニアリングユニットを創設し、専業 体制を構築する 問題の全体像をどうやってつかむ？ - ちょうど良い無限労働力が最近できたらしい 囚人のジレンマ的な構造をどう壊すか？ - 政治が足りない 12
13. 問題の全体像をAIで調査する - - - 問題の全体像が理解されていなかったのはなぜか？ SQLはデータソースに紐づく 指標定義はデータソースに紐づく データソースが大量に存在するが、中身の定義は GUI上目視で確認する しかない AIをしばき倒して調査を行う UIを開かせて、 SQLと指標定義をゴリゴリメモらせる そのメモを解析 BIの利用ログを BigQueryに連携 わかったこと 利用中のデータソースが 142個ある(!) 最小必要数の 7倍 テスト用のデータソースが使われている (!!) 過去に消したはずのデータソースがまだ使われている (!!!) どうして 指標定義のヤバそうなところも発見 データソース →レポートの対応関係も把握できた 13
14. 進め方に対する反省点 反省点 向き合い方 技術的なメリットは明快だが、利用側のメリットと結びついてい なかった 「数値が変わってしまうことは望ましくない」 体感の変更コスト > メリット 相手側のメリットを波として利用する 全社的な生産性向上への流れが起こった 生産性向上施策 →改善方法論への型化 →指標定義 の重要性... と結びつける データエンジニアリングの共通化との相性が良い 現状把握が曖昧なまま解決策に飛びつこうとした そもそもどんなデータソースがあるかわからん 指標定義の問題ってどんな問題なのかよくわかっとら んし... AIを利用した徹底的な現状把握 現状把握をガチガチに行う ガチガチの現状把握から、具体的に変化を計算する 理想を言語化してもどうせ伝わらんしな ...と諦めていた 「政治から逃げるな」 今まで関わっていなかった別のステークホルダーと関 わるようにする。味方は意外なところにいるかもしれな い 言語化する。ドキュメントに落とし込み、共有し、 MTG に持ち込む。上司と共有する 技術的に政治をやる 14
15. 政治から逃げるな > エンジニアのほとんどは、「政治」と聞くと、まるでレモンをかじったかのように顔をしかめる。「社内政治とは、ずる賢い出 世主義者が繰り広げる汚いゲームであり、コードを書くのに集中するのが本物のエンジニアである。」我々エンジニアは皆、 そう信じ込まされていた。... 政治に関わることを拒否するエンジニアは、自分たちの会社がひどい技術的な意思決定をした と不満を言うことがある。しかし、その意思決定に影響を与えるために必要なことをしようとはしない。彼らは、技術的なメ リットだけで結果が決まる世界を望んでいる。そんな世界は存在しないし、存在したこともない。 > チームを越えて強固な関係を築き、さまざまな関係者の動機を理解し、合意形成の方法を知ることができれば、政治をし ていることになる。技術的な意思決定を、技術者でない関係者にわかりやすい言葉で時間をかけて説明することも、政治 だ。他のチームの人とコーヒーを飲み、お互いの課題について理解することも、政治なのだ。良い政治とは、良い結果のた めに、人間関係と影響力を戦略的に利用することに過ぎない。 ⽇本語翻訳: 政治から逃げるな - Matheus Lima, https://zenn.dev/contradiction29/articles/1546d090065bf4, @contradiction29 英語原⽂: Stop Avoiding Politics, https://terriblesoftware.org/2025/10/01/stop-avoiding-politics/, Matheus Lima 15
16. 技術的な政治を行い、政治的に技術をやる 前に進まなかったのはなぜか？ - - 政治的な動きを何もしてこなかった 技術的な解決策だけを強調していたから何も前に進まなかった 相手のニーズを理解し、メリットを伝え、Win-Winの関係を築く努力を怠った 技術的に不十分だった 問題の解決のためには、状況理解とソリューションの構築が不可欠 状況を理解し、変更の結果として何が起こるかを正しく把握できていなかった 前に進めるためには？解決策を携えながら政治をやる - 相手の行動原理を理解し 相手のメリットで語る 常に現状と課題を把握し 実行可能なソリューションを準備しておく 16
17. 今後どうする - リアーキテクチャの完結まではあと一歩 確実に終わらせる 今までより早いレスポンス速度、統合されたロジック、拡張可能性を持つとして... 現状の課題感 - - - 改善の方法論の型化・一般化 メトリクスの定義は、極めて政治的な営みになる The Knowledge Journey自体に基づく形での再編成の実施 より自立的な改善サイクルの提供 データを閲覧する手段としてBIが優れているわけではない メトリクスをAIに直接解釈させ、探索過程をアプリケーション化させることは可能 データエンジニアリングが競争優位性に寄与する 人を募集してます！！！！！！！！！ありがとうございました！！ 17
18. データパイプラインの理想と現実 理想 現実 論理的整合性 指標の定義に矛盾がなく、誤差は全て説明 合理的な説明ができない誤差が存在し、指標 可能であって欲しい の定義が十分に説明できない レスポンス速度 探索に使うものだから、膨大なデータを現 実的な時間で分析したい 拡張可能性 - BI利用者からクレームが出るほどにレスポン スが遅い 論理的な整合性を保ちつつ、ニーズに合わ 拡張するほど破綻していく せて機能を追加したい (拡張できないとは言ってない) Helpfeelの場合はパイプラインのアーキテクチャ起因であることが明確 リアーキテクチャによる解決策は早期に提唱されるが ...実際に起こったことは ... 18