2019年6月17日に行われたCTO meetupのテーマは「Edtech～教育にどうテクノロジーを活かすのか～」。各分野でIT化が進み教育×テクノロジーも注目を浴びる一方、Edtech企業には教育業界ならではの乗り越えなければならない壁も数多く存在しています。

今回はそんなEdtechを手がける3社のCTO、VPoPがディスカッション。プロダクトや利用技術の紹介、採用方法、教育業界ならではの課題などを、質疑応答を交えてたっぷり語り合うイベントとなりました。

登壇者のご紹介

多様な形で教育の現場をサポートするEdtech企業

大関：株式会社LEARNieのCTO、大関と申します。以前は株式会社ゆめみで40名ほどの開発チームの責任者を務めていました。私以外全員エンジニアで営業や売上管理、チーム作り、各エンジニアの評価などやっていて案件としては大手アパレルメーカーのグローバルアプリやファストフードのアプリ開発などを経て、2018年の4月からLEARNieのCTOとして参画しています。

当社は子供向けのオンライン英会話教室を運営していますが、実際には教育や人材・組織開発に特化したオンラインソリューションを開発しています。Zoomのようなオンラインのコミュニケーションツールを教育などに特化させたプロダクトをイメージしてください。具体的には、受講者の表情を読み取って感情を解析したり、参加者がどれくらい発言しているのかを可視化して講師にフィードバックするなどといった機能がありブラックボックスだったコミュニケーションを「見える化」しています。本日はどうぞよろしくお願いします。

【ファシリテーター】株式会社LEARNie CTO 大関 隆介さん 新卒でアローズ・システムズに入社。大手飲食店検索サイトの要件定義～運用までを行いPHP・Perlなどのサーバーサイドの開発に従事。その後、株式会社ゆめみ入社。 大手企業を中心としたプロジェクトの統括責任者としてエンジニアリングを行いながら40名のメンバーをマネジメントし、多くのプロジェクトを成功に導いてきた。 2018年4月にLEARNieに参画し8月に取締役に就任。現在はLEARNieの他に株式会社スポットメイトのCTOを行っている。 副業をフル活用したリモート開発で組織マネジメントを含めご活躍中。

中村：株式会社Libry（リブリー）のCTO兼TechLeadの中村と申します。大学在学中に現在の代表と出会い、学生ベンチャーとして起業して以来ずっとCTOを務めています。当時は教育現場にタブレットやPCが普及していなかったこともあり、事業を存続させるために、いたずらに組織拡大せずにほぼ一人でプロダクトを開発していました。その裏では日本マイクロソフトからの受託開発を請け負ったり、某大手企業の教育サービスのレコメンドエンジン開発にコンサルティングから入って携わったりと、さまざまな経験を経てフルスタックエンジニアになりました。現在はCTOとTechLeadを兼任しているということで、経営者と技術者両面の立場を担っています。

企業の目的は、日本の教育水準を高めること。学習履歴を分析することで、現在定性的に扱われている教育や学習をデータドリブンに進化させることを目指しています。 そんな当社のリブリーというサービスは、学習者一人ひとりに個別最適化される学習特化型電子書籍プラットフォームです。教科書・問題集特化型のKindleを想像するとわかりやすいと思います。出版社に教材を提供してもらい、当社がデジタル化します。それを学校や中高生向けに販売を行い、出版社と売上を分配するビジネスモデルです。電子書籍を販売するだけでなく、問題を解いたら、「どの問題を、どれくらいの時間をかけて問いて、どうだったのか」という解いた結果が、学習履歴として保存されます。また、Libry for Teacherという先生用のツールでは、リブリー上で先生から生徒に宿題を出し、解いたものを生徒にアップロードしてもらうことで宿題の提出状況や正答率、その時のノートの写真を見ることができます。サービスは現在ほぼすべての都道府県で利用されていて、急成長中です。

浅野：株式会社コードタクトの浅野と申します。CTOではなくVPoPという役職で、製品開発やプロダクト全般に関わる責任者を務めています。もともとはネットワークエンジニアとしてキャリアを積み、IPSでネットワーク構築をしたり受託開発案件を担当したり、専門学校の非常勤講師としてC言語を教えたり、フリーランスになったりと雑多な経験をしています。刺激を求めてベンチャー企業に転職し、2社目ではCTOも経験しました。その後は株式会社ZUUでエンジニアリングディレクターを務め、お誘いを受けて2年前に現職に入社。エンジニアが10名ほどの組織なのですが、全員フルリモートで仕事をしています。

当社のメインサービスはschoolTaktという授業支援システムで、学校の先生が授業を運営するための方策を立てるのに有意義なツールで、アクティブラーニングや協働学習を支援するものとなっています。具体的には、タブレットなどの端末でschoolTaktを使うことによって生徒が現在どういう課題にどのように取り組んでいるのかをリアルタイムで把握できるというものです。

【ご登壇者】株式会社コードタクト VPoP 浅野 隆文さん 音大浪人中にネットワークエンジニアしてキャリアをスタート。SE/PMとして通信会社や金融機関を中心に、大小様々なプロジェクトに携わる。その後、受託ではなく自社サービスをやりたいという思いからウェブ系のベンチャー企業へ転職。コミュニティサイト運営企業でプログラマ、データセンタ事業者でCTO、フィンテック企業でEngineering Directorを経て現職。2つのプロダクト開発における調停者をやりながら、商用インフラの整備運用、ワークフローの整備、社内システムのおもりまで、スタートアップ特有の仕事の幅を楽しんでいる。

技術紹介と技術選択理由

教材の電子書籍化にはブラウザ版の開発が必須だった

大関：では早速パネルディスカッションに入りたいと思います。まずは各社の技術紹介と技術選定の理由についてお話いただければと思います。中村さんいかがでしょうか。

中村：フロントの特徴は独自ストレージで開発していることと、ガワネイティブで実装していることです。リブリーというサービスを提供するにあたってはハードルが3つありました。1つはブラウザ版でなければならなかったこと。正確に言えば、アプリ版のみでは事業が破綻する恐れがあったことです。2つ目は、書籍の代替物ということでオフライン機能が無いと学校現場で使えないこと。3つ目は大容量のデータを扱わなければならない製品だということです。 特に前者２つについてご説明すると、1つ目は単純に言えば手数料の問題です。アプリ内で課金をすると、プラットフォームの利用料が発生します。最初に説明したとおり、当社のサービスは教材を提供してくれている出版社にも利益分配を行うため、アプリ版のみではほとんど利益が手元に残らなくなってしまう状況でした。そのため、ブラウザ版を前提としたサービス開発をして、アプリ版をビュアーアプリとして提供する必要がありました。

2つ目は、学校のITインフラが十分に整備されていなかったことです。学校現場も、クラス全員が授業の中で同時にサービスが使おうとすると障害が発生してしまう現場がありました。また、普段の学習で利用する教科書などをデジタル化しているため、Wifiがない家庭や帰りの喫茶店など様々な場所で利用できる必要があります。ですから、オフラインでも利用できるようにすることが必要だという判断になりました。

【ご登壇者】株式会社Libry CTO 中村 文明さん 東京工業大学在学中に、代表の後藤と現在のLibry（旧：株式会社forEst）を学生起業する。設立当初より取締役CTOとして、創業期の受託開発や中高生向けデジタル問題集「Libry（リブリー）」の開発チームを牽引する。

新技術も採り入れながら、モノリシックなシステムの分離を進行

浅野：当社のメインプロダクトであるschoolTaktは、Webブラウザがあれば利用できることを売りにしています。Webアプリケーションとしては一般的な技術スタックで開発しているのではないでしょうか。 ただ、もともとschoolTakt自体は、大学のIT未踏プロジェクトに採用されたリアルタイムなラーニングマネジメントシステムがもとになっています。当初からWebで開発されていて、かなりモノリシックな作りになっていました。そのため、モダンなアーキテクチャの採用やユーザーの要求にできるだけ早く対応しようとすると、古いコードを逐一紐解いて直さなければなりません。近代的なフレームワークとの整合性も良くないというデメリットが生まれているので、現在はフロントとバックエンドの分離を進めている最中ですね。

大関：分離は一部が進んでいて移行中という状況ですか？

浅野：いまはRailsのAsset管理の枠組みを使ってビルドされている部分もありつつ、それとは完全に独立してReactで作られている部分ももありつつという形です。裏側は徐々にAPI化していく中で、良さそうな新技術は適宜採り入れています。GraphQLも一度検討はしたのですが、結局Boilerplateが多くなりすぎるなどの理由で導入を断念。最終的に当社のCTO自ら、Railsのモデルの更新をリアルタイムにフロントへ伝搬できるGemを作りました。

大関：自前で作るんですね！

浅野：当社の場合はCTOの技術力が圧倒的で、週末プロジェクトで課題解決してしまうようなことがままあります。

大関：ちなみにサーバーサイドの言語はなんですか？

浅野：サーバーサイドはずっとRubyですね。今のところは問題ありませんが、パフォーマンスなどはあまり良くないので将来的には変更を検討することがあるかもしれません。インフラははAWSがメインです。他社と協業で進めているプロジェクトの場合はAzureなどを使うこともあります。

大関：AWSとAzureを使うとエンジニアがお互い連携できない、ノウハウが共有できないといった影響が出てくることもありますが、その点は大丈夫でしたか？？

浅野：その部分に関してはもともと私がインフラ得意だったということもあるので、早い段階からInfrastructures as Codeを実現しようと取り組んでいますね。

バイナリデータを多用するため、ネイティブアプリでの開発を選択

大関：当社はメインプロダクトとしてMac及びWindowsのデスクトップアプリケーションを開発しています。サーバーサイドはGoとNode、frontendはVueで開発している所です。当初はElectronを使って開発することも視野にいれていたのでNodeも使っている形となります。

デスクトップアプリケーションを開発することになった経緯としては、まず代表から、「オンラインアプリケーションとしてZoomと同じ品質のものを作って欲しい」と言われたことから始まります。当時、エンジニアは私含めて3名しかいなかったので、かなり厳しくなりそうという話を代表ともして出来ることをやろうということにはなりました。

そこでまずは効率化を考えElectronでの開発を検討したのですが、代表のこだわりとしてグループレッスンをすることや表情・発言量の解析をするといった要素があり、バイナリデータを使う部分が多かったんです。サンプルアプリを作って検証していたのですが、複数人数を扱い且つ解析用の映像や音声データを送ったり画面共有をしたりということで負荷が高かったためElectronを断念してパフォーマンス・チューニングが行いやすいネイティブで開発する形になりました。MacOSはバージョンが上がるとカメラのアクセスに失敗する、Windowsは未だに7のシェアが高いことあとは開発できるエンジニアが少ないなど結構辛い部分もありますね。

スピード優先のスタートアップ企業が持つジレンマ

大関：技術に関しての失敗経験はありますか？

中村：アーキテクチャですね。一人で膨大な量をスピード重視で開発しなければいけなかったので、設計している暇がなかったんです。できた部分から組み上げていった形になっています。コード量が多くないのですべて見ればわかるようにはなっていますが、そもそもどのアーキテクチャが良くて…と吟味した開発はできていません。

大関：スピード重視というのはスタートアップではよくあるパターンですね。ただ、それを続けると結果的に事業のスピードが落ちる事態にもなってしまいがちです。

中村：まさにその通りで、なかなか乗り越えられていない部分です。

大関：浅野さんはいかがでしょうか。

浅野：具体的なテクノロジーやアーキテクチャによる失敗はありませんね。ただ、これもスタートアップによくある話ですが、トラフィック特性や需要を無視して組んだ結果としてシステムが立ち行かなくなるものの、メトリクスが無いからどこが問題なのかがわからないという状況はあります。一つひとつ手作業で紐解いていかなければなりません。そういったことをしなくてもいいように、現在はメトリクスを取れるようにしたり、アーキテクチャを一定にしたりしています。

リファクタリングの判断基準は事業メリットの有無

大関：リファクタリングするときに何を更新するのかなどは人によって違うこともありますが、どのように決定していますか？

中村：何を優先して進むかは提示しますが、基本的にエンジニアに任せますね。

浅野：僕も完全に任せていますが、意図しないリファクタリングによって問題が起きると困るので、品質保証の方針をどうするかは最近話し合うようにしています。必要ならリファクタリングの観点などを聞きます。

大関：なるほど。僕はエンジニアがやりたいリファクタリングと、事業スピードを速めるためのリファクタリングがあると感じているので、リファクタリングする時はそれが事業にとって良いかどうかも含めて判断しています。単純に新しいことをやりたいからという理由で実施してしまうと、今やらなくてよいリファクタリングという可能性もあるので、事業にメリットがあるかどうかも実施するための判断基準としています。もちろん、エンジニアが開発しやすいためのリファクタリングは事業にとっても良いことなのでそこは積極的にやっていきたいなとも思っていますが、バランスをみないといけないなと思っています。

費用対効果が高く、デファクトであることが採用技術の基準

大関：ちなみに、今後使っていきたい技術はありますか？

中村：GCPを使ってみたいですね。今はそんなにデータ容量が多くないのですべてMySQLですが、BigQueryでログデータを解析できたらと思っています。

浅野：基本的に新しい技術は各エンジニアが個人で好きに触っていて、プロダクトに導入したいと声を上げる人が多い文化風土があります。なので、費用対効果を見ながら今をより良くしていくという部分にフォーカスして取捨選択していますね。個人的に重視しているのはインフラストラクチャーの抽象化や自動化によって、開発に注ぐリソースを高めることです。

大関：僕はデファクトかどうかも確認しますね。言語を選ぶときもPHPを検討しましたが、PHPをやりたいエンジニアが減っている状況だった且つエンジニアからもやりたくないということだったので選ばなかったです。そのあたりをきちんと見ないと、すぐに技術が枯れてしまったりしますから。逆にデファクトだとわかれば、あとはエンジニアに任せる部分が大きいですね。ちなみに私自身はサクッとかけるのでPHPは好きです。

＞＞後編に続きます。 後編は、教育業界ならではの、テクノロジーの活用の大きな課題とは？を深掘ります。