データ活用より機能開発に集中した開発初期時代
「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で動かすことで、任意の時点のユーザー状態を再現できるようになった。。
エコシステム化で戦略的データ活用を促進
「推定状態可視化ツール」と「ユーザー状態再現技術」が誕生したところで、徐々に応用を考えるようになり、データ活用に対する戦略が固まってきた。しかし、データの提供価値を考える際に、”分析の活用”を起点とすると、問題が分かっても改善までに時間がかかったり、コストや手間を考えて結局取り組まなかったりすることも多い。データの価値を「プロダクト開発速度を向上させるもの」として捉えることが重要だという。
「そこでエコシステムをつくり、自律的にさまざまな使い方の段階的な発展が行えるようにしようと考えた。例えば、データ分析するユースケースが1つしかない場合、その優先度が下がるとデータ活用を推進する力がなくなってしまう。しかし、エコシステムとして、いろいろと活用できるようになれば、誰もが自律的に使えるようになる」と川原氏は語った。
エコシステムの構造としては、コアにユーザーデータアーカイブ、そしてその周りにデータを活用するための「ツール」を配置し、その周りに価値を生む「ユースケース」がうまれることを想定した。
つまり、提供価値を「プロダクト開発速度向上」とし、進化のさせ方として「エコシステムを作る」こと、そしてデータの価値の引き出し方を「ユーザーデータアーカイブをエコシステムのコアに」することを”戦略”とするようになった。その結果、エコシステムを拡大しようという兆しが生まれてきたという。
そもそも「バグに対応する側」も大変だが、「バグを報告する側」についても、複雑なユーザー状態の情報が求められ、ユーザーからのヒアリングも難しいなど、なかなかつらいものがある。そうしたときに、簡単に過去の状況を再現できる技術があるならば、それを活用することで、「バグ報告者も、簡単かつ正確にバグを報告できるようにできるのでは」と考えたという。
そして、作成したのが「ステートリプレイURL」だった。もともと「任意時点のユーザー状態再現技術」としてローカルで再現していたものを、Web上のサービスとして実装。ユーザーIDとタイムスタンプをもとにURLを発行すると、その人の状況が共有できる。つまり、バグを見つけたときにステートリプレイURL付きで報告すれば、誰がどの時点でどうだったかが、URLをたたくだけで分かるというわけだ。
これによって、正確かつ手軽にバグ報告が可能になり、再現にかける手間が不要になっただけでなく、修正確認もその場で確実に行えるようになった。そして、バグの発見、現状確認、報告、再現、修正確認のサイクルが回るようになり、複数のステークホルダーがさまざまなユースケースで、ステートリプレイURLを使うようになり、エコシステムが拡大し、同時にデータの組織的価値が向上していったという。
プロダクト開発速度を提供価値として進化する「データ活用」の可能性
そして、現在のエコシステムは、ユーザーデータアーカイブという「コア」を、プロダクト開発速度という「提供価値」に結びつけるまでの「ツール」と「ユースケース」について、さまざまな要素が生まれてきた。
ツールについては、メインの「ステートリプレイURL」をはじめ、「ドメインロジックのリプレイ技術」や「ユーザー状態の可視化技術」などが加わり、ユースケースについては、「可視化ツールでの挙動解析」「新人のオンボードツール」などが整ってきた。他にも、ユーザーのアクションシーケンス（正解、不正解など）に沿ってデータを入力し、期待値との比較を行う「シナリオテスト」や、マニュアルテストのデータをシナリオテストへ変換することで自動化をはかるなど、さまざまなユースケースが加わったという。また、スナップショットからユーザー状況を復元し、テストを行うといったユースケースも今後実装していく予定だという。
川原氏は「こうしたことが実現したことで、プロダクト開発速度は、挙動解析、バグ報告、自動テスト、ユーザー観察など、さまざまな領域で加速してきている。それに伴い、エコシステム全体もさまざまな領域で進化している」と語り、「進化の仕方が多様なので状況の変化に合わせた進化の仕方ができている。つまり、進化が単一なら、例えばデータ解析が不要となれば進化が止まる。しかし、テストや開発など、いろいろなものに必要となれば、そのニーズに従って多様な進化が予想される」とエコシステムの価値を述べた。
そして、エコシステム化することで、データの価値は至る所で活用され、結果としてデータ周りに対する投資にレバレッジが効くようになり、活用されるほど構造化・規格化が進み、活用のための基盤として進化していく。川原氏は「他のドメインロジックのインプットデータも同様に活用していけるはず」と語り、横展開についても示唆した。
そして、最後のまとめとして提供価値ごとのデータ活用戦略について比較表を提示。提供価値を「ユーザー課題解決」「データ分析・セキュリティなど」「プロダクト開発速度向上」と仮定して比較してみせた。そして、「プロダクト開発速度向上」を主な提供価値として、データの形式を構造化・高規格化し、ドメインロジックのインプットデータ・アーカイブを安価な大容量ストレージに格納することで、エコシステム構築が叶い、自律的進化が可能になることを強調した。
最後に、川原氏は「ドメインロジックのインプットデータアーカイブをコアに、『プロダクト開発速度』を提供価値としてエコシステムを構築すると、プロダクト開発速度もデータの組織的価値も爆上がりする」と総括し、「10年後のデータ活用の主流になるのではないか。ぜひ、トライしてみてほしい」と述べ、まとめの言葉とした。
