可視化の基盤を整える
前回は、LINEのリマインダーから学習ページへ直接遷移できるリンクを実装した話を書きました。
完全なマジックリンクではなく、ログイン後に目的の学習ページへ移動する仕組みです。
理想形ではありませんが、まずは小さく作り、生徒が本当にリンクを押して学習につながるのかを確かめることを優先しました。
今回はその続きです。
次に考えたのは、「学習行動の可視化」でした。
1. 本当に知りたかったこと
LINEから学習ページへつながる導線を作ったとしても、それだけでは成功したとは言えません。
私が知りたかったのは、
- 生徒はリンクを押したのか
- 学習ページまで到達したのか
- 実際に問題を解いたのか
- 何日継続したのか
といったことでした。
つまり、導線を作るだけでなく、その導線が本当に機能しているのかを確認したかったのです。
そのためには、生徒の行動を記録し、可視化する仕組みが必要になります。
しかし、そこで一つの問題に気付きました。
2. そもそもログインできる生徒が少なかった
私のシステムでは、生徒に二つの状態があります。
一つは、LINEで名前だけ登録した状態です。
この状態では質問対応機能を利用できます。
もう一つは、メールアドレスまで登録した状態です。
こちらはブラウザからログインできるため、英単語学習や長文学習など、学習コンテンツ全体を利用できます。
つまり、
- LINE利用者
- ログイン利用者
という二段階の構造になっています。
そして学習行動を可視化するためには、当然ながらログイン利用者が増えなければなりません。
ところが実際には、メールアドレス登録まで進んでいない生徒が予想以上に多かったのです。
3. 想像以上に面倒だった登録フロー
当時の登録フローは次のようなものでした。
- 生徒にメールアドレスを用意してもらう
- 講師または管理者へ伝える
- 講師または管理者が登録する
- ログイン可能になる
作った当初は、それほど大きな問題だとは思っていませんでした。
というのも、当時の私は「講師が使い方を説明する」という運用を前提に考えていたからです。
実際、新しい教材や機能を導入する際には、講師が生徒へ説明する場面が少なくありません。
であれば、その流れの中でメールアドレスの登録も行えばよい。
そう考えていました。
少なくとも当時の私には、このフローが特別複雑なものには見えていませんでした。
4. 運用して見えてきた摩擦
しかし実際に運用を始めると、想定していなかった問題が見えてきました。
まず、生徒が自分のメールアドレスを把握していないケースが予想以上に多かったのです。
スマートフォンを持っている以上、何らかのメールアドレスは存在するはずです。
ところが実際に聞いてみると、
「分からない」
という返答がかなりの割合で返ってきました。
メールアドレスを調べる。
あるいは新しく作る。
この時点で、かなりの生徒が止まってしまいます。
さらに問題だったのは、その後の流れです。
仮にメールアドレスを用意できたとしても、それを講師や管理者に伝える必要があります。
しかし生徒は毎日塾に来るわけではありません。
調べたことを忘れる。
伝えることを忘れる。
こうして登録が後回しになっていきました。
5. 生徒だけでなく講師も詰まっていた
最初は、生徒側の問題だと思っていました。
しかし観察しているうちに、別のことにも気付きました。
講師側もまた、このフローで止まっていたのです。
生徒ごとに、
- LINE登録済みか
- メールアドレス登録済みか
- ログインできる状態か
を確認し、必要に応じて声をかける。
これは決して難しい作業ではありません。
しかし、日々の授業や面談の中では優先順位が下がりやすい作業でもあります。
実際、導入直後は登録を促してくれていた講師も、時間が経つにつれて自然と意識しなくなっていきました。
これは誰かが怠けていたわけではありません。
単純に、人は忙しくなると重要度の低い作業から忘れていくというだけです。
6. 今振り返ると見えてくること
今振り返ると、この問題は生徒や講師の問題ではなかったように思います。
当時の私は、生徒が学習しない理由を考える中で、「生徒に頑張ってもらう設計」の問題には気付き始めていました。
しかし一方で、「講師に頑張ってもらう設計」の問題には、まだ十分気付けていませんでした。
メールアドレス登録は、その典型だったと思います。
生徒はメールアドレスを調べる。
講師は登録状況を確認する。
未登録なら声をかける。
メールアドレスを受け取ったら管理画面で登録する。
一つひとつは難しい作業ではありません。
しかし、そのどれもが人の記憶や善意に依存しています。
そして人は忙しくなると忘れます。
これは生徒も講師も同じです。
以前の記事で、「良い教材があれば使われるわけではない」という話を書きました。
今回のメールアドレス登録も、構造としては似ていました。
「講師がきちんと運用してくれれば回る」
という前提で作られた仕組みだったのです。
だからこそ、仕組みで取り除ける摩擦はできるだけ取り除く。
人の頑張りに依存する部分は減らしていく。
今回の改善は、その方向へ一歩進めた作業だったように思います。
一方で、人への依存を減らそうとすると、今度は「強制する」という選択肢も見えてきます。
実際、メールアドレス登録が進まないことに気付いたとき、登録そのものを必須にする案も検討しました。
LINEで名前を登録する段階でメールアドレスも入力してもらえば、未登録の問題はかなり解消できます。
しかし、その案は採用しませんでした。
メールアドレス登録率だけを見れば改善かもしれません。
ただ、それは同時に質問対応機能へたどり着くまでのハードルを上げることでもあります。
私がこれまで作ってきた仕組みは、学習を始めるまでの摩擦を減らすことを目的としていました。
登録率という一つの指標だけを改善した結果、入口の離脱率が上がってしまえば本末転倒です。
今回改めて感じたのは、人への依存を減らすことと、利用者への要求を増やすことは同じではないということです。
必要だったのは登録を強制することではなく、登録しやすくすることでした。
7. LINEだけで完結させる
そこで考えたのが、登録フローそのものを短くすることでした。
講師や管理者を経由しなければならないから摩擦が生まれる。
であれば、その工程をなくせばよい。
そこで実装したのが、LINE経由でのメールアドレス登録機能です。
生徒が特定のメッセージを送ると、メールアドレス登録用のリンクが返ってきます。
生徒はそのリンクを開き、自分でメールアドレスを登録できます。
講師に伝える必要はありません。
管理者に依頼する必要もありません。
LINEだけで登録が完結します。
技術的にはそれほど大きな機能ではありません。
しかし利用者視点で見ると、
「調べる → 伝える → 登録してもらう」
から
「リンクを開いて登録する」
へ変わったことになります。
これは思っていた以上に大きな違いでした。
8. 今回の学び
今回の作業を通して改めて感じたのは、問題は必ずしも目立つ場所にあるとは限らないということです。
私は当初、学習行動を可視化したいと考えていました。
しかし実際に進めてみると、その前提となるログイン利用者そのものが増えていませんでした。
さらに原因を追っていくと、学習機能でも可視化機能でもなく、メールアドレス登録という入口の部分に問題がありました。
そしてもう一つ気付いたことがあります。
以前は、
「生徒に頑張ってもらう設計」
に問題があると考えていました。
しかし今回見つかったのは、
「講師に頑張ってもらう設計」
にも同じ問題があるということです。
生徒が忘れる。
講師が忘れる。
管理者が後回しにする。
これは能力や意欲の問題ではなく、人間である以上避けられない現象です。
また、それと同じくらい重要なのが、「強制することで解決しようとしないこと」でした。
問題が起きると、どうしてもルールを増やしたり、入力を必須にしたりしたくなります。
しかし、それは多くの場合、別の場所に新しい摩擦を生みます。
今回必要だったのは、登録を強制することではありませんでした。
生徒にも講師にも余計な負担を増やさず、自然に登録できるようにすることでした。
人のやる気や善意に依存しないこと。
そして、安易に強制へ逃げないこと。
今回の改善は、その二つの設計方針を改めて確認する機会になったように思います。
次回予告
メールアドレス登録を簡単にしたことで、ようやく学習行動を記録するための土台が整ってきました。
次に考えているのは、生徒の行動をイベントとして記録し、継続日数や達成状況を可視化する仕組みです。
学習ページに到達したのか。
問題を解いたのか。
何日続いたのか。
講師はどのタイミングで声をかけるべきなのか。
次回は、そのための実績機能と行動ログの設計について書いていきます。
