この記事はClassi developers Advent Calendar 2022の9日目の記事です。
こんにちは！2022年4月に新卒入社し、データAI部でデータサイエンティストをしている白瀧です。
今回は、生徒の成績に応じておすすめ問題を提示するロジックを、プロトタイプを用いて学校で検証した話を紹介します。
ロジックの検証からプロトタイプ作成、学校検証まで実行できた良い経験だったので、まとめてみます。
※この記事ではロジックや検証内容には触れず、準備段階や検証を実施する中での私の気づき・学びを書いていきます。
なお、ここで検証したロジックを組み込んだサービス「学習トレーニング」が2023年5月にリリースされる予定になっています。詳細については、以下のYouTube動画をぜひ見てみてください！ www.youtube.com
学校検証に至るまで
Classiには生徒自身が学びをするための学習機能が存在します。その中で生徒の成績に応じておすすめ問題を提示するロジックの検証を担当することになりました。
当初の予定では、ロジックの検討と妥当性検証を実施する想定でした。
この頃データAI部では社内向けに、Pythonで簡単にWebアプリを開発できるフレームワークであるstreamlitを使って、動くものを見せることでイメージをつけてもらう動きがありました。データサイエンティストがすばやく開発して、すばやく意思決定を支援するためのものでした。
そこで「ロジックの検証のために学校にこのプロトタイプを持っていけば開発前に検証できる！」と考えて実行することになり、プロトタイプであるWebアプリの開発を進めました。
しかし、ここで2つの問題に気づきました。
- 作成したWebアプリは社内アカウントの認証を通しており、社外のユーザーが利用することを想定していなかったこと
- おすすめ問題の解答データを保存する際のセキュリティ観点の考慮漏れ
理想であれば、一定期間生徒に自由にアプリを使ってもらい、解答データも収集したいところでした。しかし今回の検証では、持参した社用PCで操作してもらい（操作時は社員が横にいる）、解答データは収集しないということにしました。
実際に自由に使ってもらうためには、ただ実装しただけでは検証に使ってもらうことはできず、セキュリティ周りを考慮しないといけないことを学ぶことができました。
見せるだけであったり、今回のように目の前で少し触ってもらう程度であれば上記のような考慮は少なく済みますが、実際に自由に使ってもらった方が効果を検証するうえでも、ユーザーのリアルな声を聞くうえでも効果的だと思うので、次回の検証時にはこの辺も考慮に入れて準備を進めなくてはいけないなと思いました。
インタビュー設計
学校検証を実施するうえでもう1つ準備したこととして、インタビュー設計があります。
インタビュー設計では、何を知りたいか、そのためにどのような質問をどのタイミングで聞くかを整理しました。タイミングと聞き方によっては生徒の回答を誘導してしまい、生徒自身が感じたことを聞けないことを懸念したからです。
そこで、インタビューを通して知りたいことを直接聞くのではなく、プロトタイプを見せる前に現在の状態を確認して、プロトタイプを見せた後にどのような差分を得られるのか、また既存のものに代替されるかどうかを深堀って聞くことにしました。
例えば、ユースケースを通学中などの少ない時間で実施する機能を持っていったとします。
そこで、電車で通学している生徒に対して、プロトタイプを見せる前のインタビューでは、通学中での行動を確認します。想定される回答としては、英単語の勉強、ゲーム、LINEを返すなどが考えられます。
プロトタイプを見せた後に通学中の行動に変化はありそうかを質問します。ここで「使う」と回答した生徒に対しては、今やっている行動と時間と照らし合わせて深掘りしていきます。
英単語を勉強している生徒は、代替できるのか？もしくは英単語をやる時間の一部をもらえるのか？や、ゲームをしている生徒はゲームの代わりにできるのか？などを聞いていきました。
これによって、生徒自身も自分の行動と照らし合わせたときにどのように使えそうかをイメージできて、活用をするためのリアルな意見が聞けるのではないかと考えました。
結果的にリアルな声をしっかり吸い上げられたかはわかりませんが、使おうと思える具体的なユースケースやもう少しこうなってほしいという改善要望なども聞くことができたので、期待以上の成果につながったのではないかなと思います。
学校検証を通しての学び
検証での学びを以下の2点に分けて書いていきます。
- 当たり前なことを気づかせてくれる
- プロトタイプを使った検証はスムーズな意思決定につながる
当たり前なことを気づかせてくれる
私はさまざまな仮説を整理し、インタビューで想定される回答を洗い出したうえで学校検証に向かいましたが、言われてみれば当たり前な意見にも気づけていなかったり、ハッとさせられることがありました。学校検証は、こういう気づきをたくさん与えてもらえるとてもよい機会でした。
それと同時に、ユーザーの解像度をまだまだ上げていかないといけないなと思いました。
また実際に問題を解いてもらったため、企画自体の検証だけでなく、解いてもらった問題自体のレベル感について確認できたのもよかった点でした。問題自体の検証は日常的には難しい部分になるので、そのあたりの確認も事前にできたのは良い気づきでした。
プロトタイプを使った検証はスムーズな意思決定につながる
大規模な開発は後戻りが難しい場合があり、特にロジック部分は数多くの事前検証が求められます。
今回の学校現場での検証を通して、ロジック部分の違和感がユーザー視点でないことが確認でき、さらに想定していたこと以外の発見にも繋がりました。
その結果として、企画自体とロジックの確からしさを検証することができ、スムーズな意思決定の支援に繋がりました。
不確実性が高い開発において、プロトタイプを使った素早い検証が素早い意思決定・自信のある意思決定を大きく支援でき、思った以上にインパクトが大きいんだなと感じました。
さいごに
今回の学校検証を通して、こういう企画をやりたいと言ったときに協力してくださる学校がたくさんあり、学校との繋がりの強さは絶大で大きな武器だなと改めて感じました。
私自身、学校とのつながりが強く、現場の課題や悩みの解決につなげられることを一番の魅力に感じて入社した背景があるので、これを入社1年目に実行することできて大変うれしく思います。
今回のような学校検証を重ねて、ユーザーの声を反映したプロダクト作りを意識して実行していきたいと思います。
明日は私の同期であるid:kudoaさんの投稿です。お楽しみに。
