以前に下記の記事に新型コロナウィルスにおける自粛要請のときに実施したことのまとめを書きましたが、これはその続きの記事です。誰かに情報を共有したいというよりは、自分の記録として残しておきました。

書き終わって見ても思うのですが、とくに教訓としてのまとめというものはありません。一方で、どのようにチームが機能するのかという記録としては価値があるように思えます。

レッスンのオンライン対応に向けて実施したこと _上記のような状況で、まだまだ課題が残っているのですが、学校関係者の多くがオンライン移行を進めている中で少しでも知見をシェアしたいと思います。_medium.com

以前の記事では、オンライン対応が急務なので、高速にPDCAサイクルを回すことをどのようにやるのか、また緊急時においてもユーザー調査をしっかりと回すことの重要性を書きました。本記事は、その続編ですが、時系列が少し重なりつつも後の話になります。以前の記事は2020/3 ~ 2020/5、今回の記事は2020/4~2020/6くらいまでの話になります。

加えて以前の記事の内容は、開発チームが自社内にいなくてもできる内容でしたが、今回は自社内に開発チームがいるからできるような内容となっています。

時間を少しさかのぼります。2020/3 新型コロナウィルスの情報が広まり、このウィルスの性質を考えたときに長期化することは必然と考えていました。一方で、塾というビジネスモデルは月額で料金を頂いているので、休校は死活問題になります。この緊急時の対応と、長期化する前提でのオンライン化の動きを並行して進めなくてはいけない、ということは当初の考えからありました。

ついては、2020/3 〜 2020/4あたりは緊急対応を第一優先とし、2020/4 ~長期的視点での取り組みをしたいと考えていました。レッスンキャパシティの問題は、2020/3 の施策を動き始めたときから試算しており、把握していましたが、それでも死活問題として、また全員に実施できるまでまつのは非合理なので、一部からでも進めなくてはいけませんでした。

なので、この緊急対応を、長期的な視点ではプロトタイピングと見て、知見を貯めるということを並行して行うように意識していました。具体的には、細かいレッスンのABテストや、NPS の集計などをして、どういったレッスンがオンラインマッチして、そうでないかの調査もしました。これらの動きは開発チームを巻き込まないで、事業サイドのメンバーと進めました。適材適所の考えです。

一方で、事業サイドのメンバーは、長期的なテストと意識はあまり保つ必要はありません。当然のことながら、緊急事態の中での動きとして、まず直面している問題を乗り越えることにフォーカスすべきです。オンラインレッスンでの対応を乗り越えられたのも、事業サイドの尽力によるものが大きいです。

この期間においては、貢献をたたえつつ、長期的視点、いわば第2エンジンへの点火をどのように移行するのかを一つの課題として意識することにしました。

（加えて言うと、ここらは個人の見解もあるのですが、特に、新型コロナウィルスはロックダウンによって完全封鎖できる、インフルエンザのようなものになるという意見を持っているメンバーもいたと思います。僕個人としては、長期化するというスタンスを（いまでも）もっている状態です。なので、第2エンジンへの点火が必要と判断をしています。しかしながら、また、これに関してまだ答えは出ていません。）

では、この間、エンジニアチームは何をしていたかというと、チームとしては長期的視点を持つことを伝えました、その上で、まずは休校にまつわるシステム処理のスクリプトの作成です。通常運営と異なる事業フローによって運用でカバーが大量出ることがわかっていました。

これについて、手動対応で乗り越えることもできるのですが、先程も書いたように、長期化するという前提に立つと、ここは自動化しておきたいところです。ただ、機能改修するかというと、その工数の余裕もありませんし、事業サイドーもカツカツで合意形成の時間も取れないでしょう。

そこで、スクリプトではあるのですが、レビュープロセスをしっかり実施し、安定した自動処理スクリプトを作成していきました。

これについては、東京から自粛要請、福岡エリアの自粛の動き、緊急事態宣言と自体が変わっていく中でとても大きな効果を発揮しました。ここまでが 2020/4くらいまでの動きです。

自動化スクリプトができた段階で、エンジニアの開発はだいぶ手が空きます。（予定していた開発計画は休校対応時に全面ストップをしています）そこでオンライン化に向けてビデオ通話機能の内製に乗り出します。

この時期は、事業サイドが必死に Google Meet を使ったオンラインレッスンの PDCA サイクルを回している時期と重なります。正確には2日ほど、内部での Google Meet をつかったトライアルレッスンをし、レッスンキャパシティーの試算をした段階で、僕個人としては内製化は必要だと判断しました。

ここから少し CTO っぽい動きをするのですが、まず、Saas の APIについてはざっと僕の方で下調べをしています。色々と Twilio などの記事を書いているのはその調査の副産物としてです。

加えて週末に簡単な Twilio API を使ったプロトタイプアプリを作っておきました。意図としては、技術選定のステップをショートカットしたかったからです。おそらく、普段であればチームメンバーに調査も含めてお願いをしていた思います。

これらの情報をまとめた上で、開発チームメンバーに、今度、第2エンジンが必要になること、開発期間は1ヶ月でなんとかしたいことを伝えます。

ここから、更に僕らの開発チームの面白いところなのですが、本当にその要件で足りるのか、の議論が始まりました。その結果、当初チャットもSaas で実装しようとしていたのですが、これは WebScoket （ActionCable）を使った自前実装として別の機能の方が良い（チャットはユーザー体験の阻害要因になる）という結論になります。

こうした結論が出せた理由も、自走するチーム、並行して行っていたPDCAの知見、ディスカッションカルチャーの成果だと考えています。

実際のスケジュールはどうだったかと言うと、開発チームでレビューできる段階まで1ヶ月で行き、デバッグ作業と事業サイドレビューなどにより追加で1ヶ月弱かかります。（つまりは1ヶ月ではリリースはできなかった。一方事業サイドもよく理解してくれているのでお互いが信頼のもとカバーできました）

こうした、経緯を経て、オンライン対応が一通り、レッスンキャパシティーの上限に到達する頃に、新しい機能が出来上がります。動くものを見て、理解することも多くあります。

事業サイドにおいては、どこか頭の片隅にあった、レッスンキャパシティーの課題について、この機能が見えるようになることで希望の光となることがわかりましたと言うようなコメントをもらいました。

こうして、大活躍した Google Meet ですが、その役割を終えて、自社開発したビデオ通話システムでのレッスンに置き換わり、レッスンキャパシティーの問題も概ね解決していくことになります。

現状、ここから更に進んでいて、すべて問題が解決した、と言いたいところなのですが、一つの課題が解決すると、また新たな課題が見つかります。自社開発したビデオ通話システムによって解決できた問題は、まだ6〜7割程度です。

あと面白いのですが、機能を作るだけでは問題解決するわけでありません。機能が来た後は、また事業サイドの動きに統合して行かなくてはいけません。今回ここについては書ききれていません。

また、これまでは基本は守りの動きだったのですが、攻勢に向けても動きを進めたいと考えています。攻勢ということを考えると、新しい課題も山積しています。

つまり課題が特盛、お替りし放題状態ですが、常に課題解決がPMの仕事です。これらの課題に対して前向きに、楽しんで取り組んでいく所存です。（実際、2020/3 以降の動きは大変だったけど充実感もありました）こちらの動きについては、また折を見てまとめられればと考えています。