Facebook
RMP FEATURE

RMP FEATUREQuipper

グローバルデザインからマイクロサービス化まで
-スタディサプリを支える試行錯誤の数々とは-

「神授業」で知られるオンライン学習サービス「スタディサプリ」は、いったいどんなメンバーがどんな思いを抱きながら開発しているのか。その裏側を、サービスの開発・運用を担うエンジニアやデザイナーがダイレクトに、時に「エモく」語る「Product Meetup」の第2回が2月8日に開催された。

2019-03-07

登場社員.jpg

多言語、多文化を前提にしたデザインリニューアルのポイント

図2.jpg

スタディサプリは、「世界の果てまで最高の学びを届ける」ことをミッションに掲げ、国内のみならず、海外でも「Quipper」のブランド名で展開されている。2010年にロンドンで立ち上がり、2015年リクルートの仲間になって、今では日本はもちろん、フィリピン、インドネシア、メキシコと、世界各国で多言語で教育サービスを提供し、17年度の累計有料会員数は国内外合わせて74万人を超えるまでに成長してきた。

が、さまざまな要望に応えて機能を追加してきた結果、UXやデザイン面での課題が深刻化していた。「グローバルサービスでのデザインリニューアルプロセス」と題して発表を行った鳥居氏によると、「いろいろな要望に答えて部屋を増やしたは良いが、古い基礎の上に無理矢理建ててしまった結果、どこが入口で、どう移動できるのかが分かりにくい建物のような構造」になっていた。かといって、全てを作り替えるにはコスト的にも時間的にも厳しい――そんな状態だった。

2017年10月に入社後間もなく、このプロジェクトに加わることになった鳥居氏は「各国で(プロダクトを)改善しやすい状態にし、結果としてユーザーの学習効率の向上、学力向上に寄与すること」をリニューアルのゴールに据え、プロジェクトに取り組み始めたという。

とはいえ、グローバルなサービスならではの課題はやはり一筋縄ではいかなかった。国も違えば言葉も違い、文化も違う。動画コンテンツの構造やタイトルの付け方も異なる状況の中、「同時にいろいろ整理して解決したかったが、国ごとの事情がある中では無理だと気付いた。そこで、すべてを作り直すのではなく、今あるものを生かしながら再設計する方向に舵を切った」(鳥居氏)

プロジェクトには日本をはじめフィリピンやインドネシアのメンバーが参加し、GithubやSlack上で英語の議論を交わしながら進めていったそうだ。奇をてらうことなく、まずユーザーストーリーやフローチャートを基に課題を検証。構造を設計し直し、手書きでプロトタイピングを行い、大筋で合意がとれた後に画面設計やモックアップ作成を進める......というベーシックな流れで進めていった。

ただ、鳥居氏自身がQuipperにジョインした直後で、サービスの全体像を把握するのが大変だったことも事実。そこで本来ならばコンポーネントのデザインから始めるべきだったかもしれないが、全体のデザインとコンポーネントを行き来しながら作ったとのこと。
「今回は、デザインデータが仕様のようになってしまい、ページ数が膨大になるという失敗もあった。一方で、Zeplinを用いてコンポーネントを登録・管理したのはうまくいった。登録したコンポーネントがどのページで使われているかがすぐ分かるようになり、作業を進めやすくなった」(鳥居氏)

今回の取り組みを通して鳥居氏は、「学習メソッドのデザインと、サービスプロダクトのデザインは違うとあらためて感じ、学習メソッドをいかにプロダクト上に実現し、知識を知恵に変えていけるかが使命だと思った」と述べた。  

鳥居氏はさらに質問回答で、「教育サービスにおいては、デザインは主張しすぎるべきではないと思っている。『使いづらい』という印象は与えたくないが、あくまでコンテンツや学習プロセスを助けるものでありたい」と語った。

技術的負債への対処とマイクロサービスの関係

図3.jpg

スタディサプリでは、ユーザーの学習状況を表すデータを2種類のデータストアに格納し、活用してきた。しかし、学習データのバックエンドサービスの開発に携わる掛川氏によると、「学習データの柔軟性に問題があった。ユーザーのユースケースに合った検索を行うのが難しいといった課題があり、より信頼性・柔軟性の高いものにしたいと考えた」。

解決に向けて掛川氏が立てた方針は2つ。すなわち「データソースの統一」と「ロジックの集約」だ。「基本的なことだが、それを徹底的にやろうと考えた。そのためのアプローチとして、サービスのコンポーネント化を行っている。ドメイン知識の流出とそれによる実装の乖離を防ぎ、さまざまな利用目的で生成されるデータの信頼性を担保したかった」(掛川氏)

またもう1つのアプローチとして、CQRSとEventual Consistencyというコンセプトに基づき、Event Processorを実装した。「メリットは幾つかある。まず、イベントの処理前にチェックポイントを設けて永続化するため、処理完遂の責務をクライアント側から切り離し、バックエンド側で担保できる。もう一つはデータの一貫性保証で、非同期という点で妥協することによってデータストア間の整合性を比較的シンプルな手段で保つことができる」(掛川氏)

掛川氏らはこうしたコンセプトでバックエンドサービスの開発を進めると同時に、マイクロサービス化の流れを生かして技術的負債の返済にも取り組んでいる。それも純粋に「技術的」な負債だけでなく、「プロダクト」の負債にまで立ち入って返済を試みているそうだ。

「長年にわたるプロダクト開発の末に、仕様やドメイン知識が失われるケースが往々にしてある。例えば『今動いているものが仕様。よくわからないけれどね』というのが典型例だ。これは開発体制に起因する問題でもあるが、負債が溜まっている事実自体にも向き合う必要があると考えている」(掛川氏)

その対策として、モノリス全体よりリスクの小さい「部分的」なリプレイスに取り組んでいるという。「ドメインが本来あるべき姿を再定義、再設計してリプレイスしていく。ある程度のリスクと引き換えに、まとまった量の負債を返済しようというもので、複合的要因でリファクタリングが難しいときの1つの手段になるのではないか」(掛川氏)

一方で、たとえ再設計、再定義したとしても完璧なものを作るのは不可能だし、将来出てくるであろう新たな要求に応えられる保証はないことから、「設計の時点でアーキテクチャを硬直化させてしまうのではなく、進化、成長させていくアーキテクチャが必要となる。システムレベルでもリファクタリングは可能であるべきと考えている」とした。

最後に掛川氏は、マイクロサービスとチームのあり方についてこのように語った。「マイクロサービスは、自己組織化されたチームをスケールさせるための技術基盤だと思っている。マイクロサービスには技術面のメリットはいろいろあるが、時に、そのメリットを上回る複雑さをもたらす。それを受け入れる代わりに、コンウェイの法則を逆手に取って組織の問題を解決しようとする試みではないか」

さらに、AmazonのCTO、Werner Vogels氏の「You build it, you run it」という言葉を引き合いに出し、「マイクロサービスを手がけるチームは、開発・運用がチーム内で完結しているべきではないか。そのために、クロスファンクショナルなチームに成長していかなくてはならない。組織・チームにおける心理的安全性と、チーム開発を通じた学びの機会が重要」と締めくくった。

ログデータの構造を改善し、問い合わせをほぼゼロに

図4.jpg

ユーザーがどの動画を何秒くらい再生し、どの時点で一旦停止しそのまま離脱してしまったのか、あるいは続きから再生したのか。ユーザーのアクティビティを把握し、さらには先生や保護者が視聴(勉強)履歴を把握する上で、スタディサプリの約4万本に上る動画の再生に関するログは非常に重要な役割を果たしている。

だが、「動画視聴ログの実装について」と題して発表を行った長谷川氏によると「時々、視聴済動画が履歴に残っていないという問い合わせをいただくことがあった」そうだ。同氏はその原因究明と改善手法を説明した。

スタディサプリの動画ログは二次元配列構造で記録されていた。動画を再生している間は、順調に再生されていることを示すために20秒おきに記録を行うほか、ポーズやシーク、レジュームといったイベントのタイミングも記録し、サーバに送信していた。が、データが届く順序が保証されていなかったにもかかわらず、各データがイベントの意味を持つことから、送信のタイミングによっては順序が前後し、データのロストが発生していたという。

そこで長谷川氏が取った解決策は2つあった。1つは、データ構造を変更して「冪等」にしたこと。さらにステートレスにすることで、「データが送られる順番が異なっても、クライアントからサーバに届きさえすればデータの整合性を維持できるようになった」(同氏)。副次的な効果として、問題のデバッグや調査もしやすくなったという。

もう1つ、端末がオフライン状態になってログを送信できない場合に視聴履歴が消えてしまう問題についても、データのリトライやローカルストレージへの保持といった工夫を加え、クライアント側でログデータをロストしないようにした。こうした改修を加えた後、「問い合わせはほぼなくなった」と長谷川氏。全体から見れば小さな領域かもしれないが、これもまた立派にサービス品質の改善に寄与した例と言えるだろう。

ないならば作ってしまえ? 動画再生速度変更機能、独自実装の道のり

図5.jpg

スタディサプリが用意した動画は約4万本あり、ある程度理解できた領域ならば早送りしてしまいたいこともあるだろう。そんなニーズに応えるため、スタディサプリでは動画の再生速度を細かく変更できる仕組みを実装しているが、実はその背景には富士氏による試行錯誤があった。

かつてスタディサプリでは、1倍速と1.4倍速の2種類の動画を用意していた。ただ「あらかじめ1.4倍にエンコードした動画を別に用意し、URLを切り替える仕組みだったため、他の速度には対応できない上、リバッファリングが発生して再読み込みに時間がかかるといった問題があった。」(富士氏)

Web版とiOS版はクライアントサイドで変更機能を実装して解決したものの、残るAndroid版が問題だった。そこで、ユーザーの再生環境の変化もにらみつつ選択したのが、オープンソースの動画プレイヤー「ExoPlayer」だったという。だが当時のExoPlayerでは、再生速度の変更機能が実装されていなかった。GitHub上にリクエストが上がってもそのイシューの優先順位が低くなる状態が続き、いつ実装されるかも分からない状態だったため、「独自に再生速度変更の仕組みを実装することに決めた」(富士氏)という。

では、どのように実装を進めたのか。まず「動画プレイヤーの基本は、音声に映像を合わせること。映像が数フレーム飛んでも気にしないが、音声が途切れるととたんに不快に感じる」(富士氏)

この基本に留意しながらExoPlayerオーディオの構造を解析し、やはりオープンソースの音声速度変更ライブラリ「Sonic」を流用してAudio Track Rendererを変更することで対応しリリースに至ったという。

だがこの話にはオチがある。2017年4月になって、ExoPlayer本家でも速度変更が実装されたのだ。富士氏も「心の中で、もう少し早くでていたら...と思った(笑)」そうだが、人知れず重ねられてきたこんな試行錯誤によってスタディサプリの動画コンテンツは支えられている。

☆★Quipperでは一緒に働く仲間を募集しています★☆
 
☆★情報発信中!Quipper Product Team Blogも要チェック★☆
今回のイベント内容も掲載→
Studysapuri Product Meetup #2 を開催しました! #sapurimeetup

記事中で紹介した事業(名称や内容含む)や人物及び肩書については取材当時のものであり、現時点で異なる可能性がございます。

記事中で紹介した事業(名称や内容含む)や人物及び肩書については取材当時のものであり、現時点で異なる可能性がございます。

RECRUITMENT

  • 営業職はこちら

    営業職はこちら

  • 企画・スタッフ職はこちら

    企画・スタッフ職はこちら

  • エンジニア・デザイナー職はこちら

同じカテゴリの特集