データ活用より機能開発に集中した開発初期時代
「AIで、一人ひとりに、最短で『わかる！』を。」をコンセプトに掲げ、塾・予備校を通じて小中高生にAIでパーソナライズされた学びを提供するatama plus（アタマプラス）。学習進度や集中度、学習履歴、習熟度、忘却度、回答時間など多種多様なデータをもとに、AIが得意不得意を把握して「自分専用カリキュラム」を作成するという仕組みだ。診断・講義動画・演習問題・復習などの教材について、1つ取り組むごとにデータがアップデートされるようになっている。川原氏は、そのデータ構造である「Knowledge graph（ナレッジグラフ）」を紹介。知識と知識の依存関係性が示されており、atama plusのサービスのコアとなるアルゴリズムというわけだ。
川原氏は「atama plusでは戦略的にデータを活用し、プロダクト開発速度とデータの組織価値をセットで高めてきた。とはいえ、はじめから確固たる戦略があったわけではなく、日々の開発で模索する中で形を明らかにしてきた」と語る。
事実、開発初期において、データ活用に投資する余裕は「まったくなかった」という。機能開発を最優先として、データ活用への投資はゼロに等しく、必要に応じてDB内にあるデータを加工して間に合わせていた。最低限のデータレイクだけは確保しようと、ログにデータを吐いてAmazonのS3に格納し、Athenaでクエリを実行できるようにしておいた。ただし残すものや形式などについては、開発者の各自判断に委ねられていた。
そのような中で開発が進むうちにロジックが複雑化し、さまざまな課題が増加してきた。例えば、習熟度の推定結果の詳細や推定の根拠、またはロジックを変えたときの影響など、はじめは人が推定していたものが追いきれなくなり、チームでの共有もできなくなっていった。
「推定状態可視化ツール」と「ユーザー状態再現技術」の誕生
そこで登場したのが「推定状態可視化ツール」だ。ローカルマシン上にPythonやJupyter、Graphvizなどを活用して構築し、推定結果や根拠を可視化していった。これによって開発速度は急速に改善されたが、そのうちユーザーが増えてくると段々とバグの報告が増え、対応が難しくなっていったという。
「バグが起きたときのユーザーの状況が複雑で、ユーザーの状況が理解できてもバグの再現が難しい。不幸なパターンとして、再現ができなかった時に、条件や手順が誤っていたり、ユーザーの勘違いだったりということもある。時間もかかり、悩ましく思っていた」と川原氏は振り返る。そうした問題を解決するにあたり、「過去のユーザー状態を再現できたら楽なのでは？」と考え、JSONを活用し、ユーザー状態をスナップショットデータとしてS3に保存できるようにした。入力はスナップショットデータのみ、完全に独立した状態でデータ取得時点とまったく同じロジックの実行・可視化を可能にするアーキテクチャへと変更した。その上で、全ユーザーの履歴をアーカイブとして保存するようにしたという。
仕組みとしては、習熟度の推定やリコメンドを行う「ドメインロジック」と、DBおよびユーザーデータアーカイブからのユーザーデータがWebサービスに提供され、実際の「一人ひとりにあった教材」が表示される。そのポイントの一つは、ユーザーデータはDBに保存されるだけでなく、変更のタイミングに合わせてスナップショットがJSON形式ですべてS3に保存されることだ。そしてもう一つ、「ドメインロジック」はClean Architechtureに準ずる形、つまり「ロジックを他のDBやWebのインターフェースなどに依存しない形で書く」というガイドラインに従って作成している。それを開発者のPCで動かすことで、任意の時点のユーザー状態を再現できるようになった。。
