はじめに：データ基盤が歩んだ3年間を振り返る
2026年4月6日でZEN Studyは10周年を迎えました！ ユーザーの皆様・支えていただいている皆様のおかげです。本当にありがとうございます。
現在、技術ブログでは「10年の変遷」を辿る連載企画をお届けしています。第5弾のテーマは、「データ基盤」です。
ZEN Studyの10年の歴史において、データ基盤を取り巻く横断型のセクションが誕生したのは2022年、基盤がリリースされたのは2023年8月のことです。運用期間としてはまだ3年ほどですが、さまざまな挑戦がありました。
本記事では、以下の3つを軸に、私たちの3年間をご紹介します。
立ち上げ期： Google Cloudやデータ活用未経験の状態から、いかにして「プロダクトを理解する土台」を築いたか
設計の進化： 「安全に失敗できる」IaC戦略と、Dataform導入による大学開学への対応
サービスへの価値提供： PoCを繰り返し、項目反応理論（IRT）をベースにした定期テストという本番への投入
少人数の手探りから始まり、今では20名へと成長したチームの軌跡を、技術的な観点で記載いたします。
- はじめに：データ基盤が歩んだ3年間を振り返る
- 〜2023年 立ち上げまで
- 〜2025年4月 Dataform導入と大学対応
- 〜2025年8月 定期テストのリリース
- おわりに：データ基盤のこれからと、次の10年へ
〜2023年 立ち上げまで
なぜデータ基盤？：学習体験の変革を目指した企画開発と密接なデータ基盤の始動
ZEN Studyではリリース当初からアダプティブラーニングなどのデータ活用の構想があり、サーバー側に様々なログが蓄積されていました。
しかし、リリースから数年間は学習の基盤としてプラットフォームを立ち上げることや拡大し続ける事業への対応などを少ない開発メンバーで対応していたことから、データ活用のような「重要だが緊急ではない」ものに手をつけることができませんでした。
2021年頃からプラットフォームとして一定の機能を安定して提供できてきたことや、現状の課題感と照らし合わせ、ZEN Study（当時 N予備校）を学力を向上できるプラットフォームに変革させていこうというプロジェクトが始まりました。
学力を向上させるプラットフォームの構築において、データ活用は不可欠です。 具体的には、 「学力の定量化」や「学習状況の可視化」の実現、さらに「個別最適な学習」のように「正解のない施策の効果検証」 が重要だと考えました。
そのため、コストを投じてでもデータ活用を推進すべきだと考え、2022年に企画開発 x データ分析（ユーザー行動分析・効果検証） x データ活用（機械学習・AI） x データ基盤（基盤構築・運用）専用のセクションを立ち上げ、データ基盤の構築を開始しました。
2021年頃の初期メンバーはZEN Studyのバックエンドとしてサービスを支えてきたメンバーのうち3名でしたが、2026年5月現在では20名となりセクションも分割され、サービスに与えるアウトプットも大きくなってきています。
データ基盤立ち上げ：BigQueryと向き合い、プロダクトを深く知る土台を築く
データ基盤の立ち上げ期ということもあり、当時はまず、初めて触れるGoogle CloudのBigQueryと仲良くなるところから始めていました。少しずつ蓄積するデータを増やしつつ、並行してバックエンドの方々と議論を重ね、ZEN Study などのプロダクト群の仕様とのすり合わせや、データ基盤のあるべき姿を模索していました。
少し立ち上げの話からそれてしまいますが、データ基盤と向き合うこと自体が、結果としてZEN Study などプロダクト群への理解を深める機会にもなっていたように思います。特に企画開発・データ領域のエンジニアはプロダクト開発を直接担当することは少なく、これらへの理解を深める機会を意識的に増やしていく必要があります。だからこそ、「リリース作業を含むデータ基盤のパイプライン追加や修正」を企画開発・データ領域のエンジニアのオンボーディング課題にするなど、チームメンバーの意識をデータ基盤に向けてもらうことを、当時から大切にしていました。データ基盤は、データを支えるだけでなく、私たちのチームがプロダクトへの理解を深め、成長していく土台にもなっています。
データ基盤の構築と時を同じくして進行していたプロジェクトに、学習管理システム ZEN Compassの企画・開発があります。実はZEN Compassで表示される一部指標の計算にもデータ基盤が使われており、これらの指標については特に初期フェーズにおいて、変更を重ねて試行錯誤をしていました。加えてその計算に負荷のかかる集計処理を含むこともあったため、その処理をデータ基盤側に担わせるのが、計算ロジックの修正等も柔軟にできて良いだろうという判断でした。
そんな経緯もあり、データ基盤はZEN Compassと同時期にリリースされました。データ基盤構築において、やるべきことは山ほどある一方、最初のリリースまでにどこまでやるかの決めが難しいように感じます。ZEN Compassのリリースはデータ基盤開発の明確なマイルストーンと確固とした活用事例を同時に与えてくれたプロジェクトでした。リリース以降も開発は継続的に行われており、現在では、新機能・施策の技術検証や問い合わせ対応等を支える業務に欠かせない重要な基盤として、幅広く活用されています。
「安全に失敗できる」設計：PoCの速度と透明性を両立するIaC管理
当チームの立ち上げ時は、データ基盤から分析までを片手で数えられるほどの少人数で担っており、データ基盤に関する知見はおろか Google Cloud を使った開発経験もほとんどないという状況でした。そのため、いざデータ基盤を構築しようとした際に大きく2つの課題に直面しました。
1つ目は、一般的なデータ基盤がどのような要件を持ち、この先にどんなワークロードが待っているのか想像できていなかったことです。正解の構造を知らないまま、巨大なものを作ることはできません。
2つ目は、管理すべき対象が想像以上に多かったことです。マネージドサービスのリソースから、DWH のスキーマ、変換ロジックなど多様なものを作成・管理する必要があります。これらは関心事やステークホルダーが異なるため、モノレポのようにすべてを一箇所で管理することは現実的ではありませんでした。
そこで私たちは、「正解が分からないなら、安全に失敗してやり直せる環境を作ろう」と考えました。
構成の方針として、IaC の原則を崩さず安全に変更できることを最優先としました。具体的には、最終的なリリースを司る「Terraform の実行モジュール」のみを単一の IaC リポジトリとして切り出し、各機能は「Terraform の機能モジュール」として独立してアウトプットする形をとりました。モジュールの責務分割を徹底することで、ステークホルダーごとの管理のしやすさを保ちつつ、「リリースはこの実行リポジトリを変更するだけで完了する」という状態を実現したのです。
なぜこのような方針を採用したかというと、本番環境を含めて安全に失敗できるようにすることで、PoC のイテレーションを高速化することが最大の狙いだったからです。手作業での更新やリソースの変更では、問題が起こった際にそれを追跡して事前の状態を再現することは難しく、イテレーションの速度を著しく低下させる要因になりえます。
結果として、初期構築に時間がかかったり、IaC のストラテジーを策定するといったイニシャルコストの高さはありました。しかし、リソースの管理を透明にしたことで、当初の狙い以外にもコストの適正化や PoC からプロダクションへのスムーズな移行など、多くのメリットがあったと感じています。
このデータ基盤は、コンシューマアプリケーションや分析ニーズの増加などまだまだ成長の余地が残っていますが、これからも様々な変化に柔軟に対応できるような、データプラットフォームを支えるチームであり続けたく思います。
〜2025年4月 Dataform導入と大学対応
データ基盤の安定運用へ：Dataform への技術転換と大学開学への挑戦
2025 年 4 月の ZEN 大学の開学にあたり、データ基盤では ETL パイプラインの技術構成を大きく見直しました。
これまでの高校向けシステムでは BigQuery の Scheduled Query を軸として運用していましたが、処理が多段化するにつれて、テーブル間の依存関係を考慮しながら実行時刻を個別に手動調整し、正しい実行順序を担保し続ける運用負荷が課題となっていました。そこで、より構造が複雑になる大学向けシステムへの拡張を機に Dataform を採用しました。Dataform を導入することで、テーブル間の依存関係をグラフとして管理できるようになり、実行順序の制御を自動化し、データ不整合のリスクを低減したり、障害対応時にスムーズに再実行できたりする体制を整えました。
大学向けデータパイプラインの構築における最大の課題は、大学の開学、新規稼働に間に合わせるため、実データが存在しない段階でパイプラインを構築する必要があった点です。もちろん開発環境にもいくつかのダミーデータは流れていましたが、大学の履修という、高校よりも1段複雑な制度であることや、これまでのパイプライン構築は実データを見ながら実施してきたチームであることなどから、本番や本番相当のデータが一切ない状況でのパイプライン構築に初めは苦戦しました。そのため、データソースとなるマイクロサービスでのインタフェース定義や、そもそも大学が運用される上でどういった概念が取り扱われるのかといったソフト的な面からもきちんと精査しつつ、ロジックの検証を進めました。こうして、実データにアクセスできない制約下でも、中高向けでの運用知見をベースに仕様を読み解き、厳密な設計を行うことで、サービス開始と同時に安定したデータ収集を可能にしました。
ZEN 大学も 2 年目に入り、現在は 100 件以上のテーブルが Dataform で処理されています。これからも中学・高校・大学の全てのステージにおいて、今回構築した堅牢なパイプラインを活かし、ZEN Study をデータの力で裏側から柔軟に支えていくべく、継続的な機能改善に取り組んでいきます。
〜2025年8月 定期テストのリリース
定期テストを支える基盤：項目反応理論（IRT）に基づく学力スコアの提供
対象科目を履修しているN高グループ生全員となる定期テストが2025年8月から開始されました。これに伴い、その結果に応じた学力スコア (ZEN Assessment Score; ZAスコア) や復習教材を含むフィードバック結果を返却する機能も追加されています。ここではその裏側をお話しします。
実は定期テスト実施以前から学習に対してのフィードバックの検証や定期テストで出題する問題の難しさなどを測定するためのプレテストを実施していました。定期テストリリースにあたり、そのプレテストで用いられていたPoC段階の分析パイプラインをベースにして定期テスト向けの分析パイプラインとその周辺を開発しました。
定期テストでは上述のデータ分析基盤上でログやRDB由来データをデータ基盤側でDataformで集計してBigQueryに格納した後、WorkflowsでCloud Run上の分析パイプラインをトリガーし、項目反応理論モデルでの項目パラメタ推定・受験者の学力推定を行いBigQueryなどにデータを書き出します。また、その後段で再度Dataformで集計を行い外部に連携していく仕組みとなっています。
定期テストのリリースにあたり、この仕組みを実現するためには多くの開発項目が存在しましたが、データ基盤に強い人・教育測定に強い人など、それぞれ得意分野の異なるメンバーが集まったチームの尽力により、リリースに漕ぎ着けることができました。また、それぞれの得意分野の異なるメンバーの能力の一部を習得できたため、これまで苦手意識のあった領域についても学び合えるという、喜ばしい側面もありました。
定期テストをリリースした後も、障害発生を早期に検知できる仕組みを組み込むなど、本番運用に強いシステムを構築するための改善を継続しています。
おわりに：データ基盤のこれからと、次の10年へ
3年前、私たちの挑戦は「AWS S3にあるデータベースのダンプをどうにかして持ってくる」という一歩から始まりました。
当時は Scheduled Query ベースのパイプラインで必死にデータを繋いでいた状態でしたが、そこからラボ環境との結合、Dataform への移行、そして大学開学や定期テストの実現まで……。振り返れば、サービスとしても技術的にも、目まぐるしい変化と挑戦の連続でした。
このブログは複数のメンバーで筆を執りました。関連記事には、また別のメンバーもいます。この3年間、私たちは「一丸」となって進んできました。
Webバックエンドエンジニアリング、データエンジニアリング、教育測定、機械学習、プロダクトの企画開発。 それぞれ異なる強みを持つメンバーが集まり、互いの領域を越えて学び合い、補い合う。 心の底から、「この挑戦は、このチームだったからこそ成し遂げられた」と感じています。誰一人が欠けても、今のデータ基盤がこの形になることはありませんでした。
そして今、3年間の挑戦を経て、データ基盤は次のフェーズへと進んでいます。 現在取り組んでいる課題は以下のようなものです。
- PoCを乗り越え本番サービスへの適用に伴い、本番を支える堅牢な仕組みの構築
- 現場でもデータによる効果検証ニーズを支えるための、手軽に使えるようにできる「分析基盤」の確立
- さらに、特に「アダプティブラーニング」のような未知の領域への加速
これからも私たちは、未知の検証を支え、企画開発を推進する基盤であり続けます。 教育事業を横断的に支えるデータ基盤として、これからもチーム全員で、次の10年の「未来の当たり前」の教育をつくっていきます！
