内製に加え新たに「パートナー開発」という選択肢も武器に、プロダクト価値の最大化を引き続き追求

スタディサプリのまなびのサイクル「はかる、わかる、いかす」の中で、高校生向けの最初のステップ「はかる」を担うのが到達度テストです。到達度テストはこれまでは紙を使って行われており、結果が「わかる」までに1か月程度のタイムラグが生じていました。到達度テストをCBT（Computer Based Testing）化することで、タイムリーに次の「わかる・いかす」に繋げていくためのプロジェクトを率いたのが、小中高BtoBテクニカルPMグループ（以降、TPMグループ）の卯西寛明さんと畑林一太郎さんです。スタディサプリがこれまで経験したことのない「パートナー開発（開発を外部会社に委託）」という形でプロジェクトを推進していった背景を、お二人に伺いました。

Q：お二人の経歴をお聞かせください。

卯西：私は2011年に大手Webサービス企業に入社し、10年ほどエンジニアとしてアプリ開発をしていました。職場環境には恵まれていたのですが、やはり10年もいるとストレスなく業務ができる、いわゆるコンフォートゾーンに入っていました。そのような背景から違う環境で新しいチャレンジをしたいと考え、転職を考えました。また、エンジニアだけでなくプロダクトマネージャーというキャリアに幅を広げていきたいという思いがあったのも、転職を考えた理由の一つです。

Q：「マネジメントよりもエンジニアとしてのキャリアを極めたい」という方もいらっしゃると思うのですが、ちょっと違うんですね。

卯西：自分は開発そのものを極めることよりも、、ゼロからプロダクトを作り、使ってもらい、フィードバックを得るというプロセスに喜びや達成感を感じます。その意味で、もっと大きな成果を出そうとするなら、エンジニアよりもマネージャーという立場になってチームとして取り組む方が実現に近づくかなと思いました。そういった思いでリクルートに転職し、テクニカルプロダクトマネージャーを務めています。

Q：では、畑林さんも自己紹介をお願いします。

畑林：私は2006年に国内の大手IT企業に入社し、大学向けのビジネスに携わりました。社内で初めてSaaSを作る話が持ち上がったときに、「新しいことにチャレンジするなら若い奴にやらせよう」ということで、入社3年目からSaaSの企画・開発を担当しました。

2017年から初等・中等教育に関するシステムに携わりました。小学校や中学校の教育現場で扱われるシステムは一通り見てきたと思います。

おかげで教育向けSaaSビジネスの横断推進マネージャとして非常に楽しく、充実した経験ができた一方、事業が拡大するにつれ、最前線よりも裏側でサポートする業務も増えていました。わたしとしては、教育の現場に直接資するものを作りたい思いがあったことと、小・中・大は経験したので、まだやっていない高校領域にチャレンジしたいとの想いで、高校生の学びに大きな変革をもたらしているリクルートに転職してきました。

Q：お二人の属しているTPMグループのミッションについて教えてください。

卯西：まず「まなび領域」の中には、BtoCとBtoBという大きく2つの事業があります。自分たちはそのうちBtoB、学校向けのスタディサプリを提供する組織に所属しています。BtoB事業では、ビジネス側の企画者であるプランナーや、学校にプロダクトを販売する営業、そしてプロダクトを開発するエンジニアやデザイナーといったさまざまなステークホルダーがいます。我々TPMグループはプランナーとエンジニアの間に位置し、プランナーの要求を理解したうえで、ユーザー価値を最大化するためにどういった仕様が最適なのか、エンジニアと一緒に具体化していくのが役割です。

Q：学校教育を巡る環境は、コロナ禍を含めこの数年で大きく変わったのでしょうか。

卯西：コロナの感染爆発が始まった時期は、オンライン学習に対するニーズが急激に高まったため、スタディサプリの利用者も一気に数倍の規模に拡大しました。システム負荷も当然ながら、お問い合わせも急増しましたが、学校現場のまなびを止めないため、組織で知恵を出し合って乗り切って来ました。コロナが落ち着いてからも多くの学校様に価値を感じていただき、継続していただいている状態です。

畑林：コロナの以前より文部科学省は「GIGAスクール構想」を推進していました。当初は数年かけて一人一台の学習インフラ整備を徐々に進めていく構想でしたが、コロナをきっかけに急激な速度で整備される事になりました。教育業界全体で、ものすごいスピードでデジタル化に迫られている流れを感じていました。
当時は、皆が教室でアプリを使おうと思ってもネットワークインフラがそこまで整備されていなかったり、端末の操作方法がわからないといった課題もありました。今はそうしたフェーズを乗り越え、ICT活用が当たり前となり、その上で「どうやったら本当にICTを使って価値を最大化できるか」がメインの論点になりつつあります。我々スタディサプリのチームも、使っていただくのは当たり前で、その上でどうやって教育効果を最大化し、先生方の負荷軽減につなげるかといったことを日々議論しながらプロダクトを開発しています。

Q：今回MVPを受賞された到達度テストのCBT化も、そういった背景から浮上したプロジェクトなのでしょうか。

卯西：大きく2つの要因がありました。1つめは市場の流れです。GIGAスクール構想などの流れで一人一台の端末が整備され、Webテストを使ってもらえる環境が整ってきたという背景があります。

もう1つはユーザー価値の観点です。スタディサプリでは学習を「はかる、わかる、いかす」という3つのプロセスで定義し、いかにそのサイクルを最適にかつ高速に回していくかを考えてきました。一方で、我々が自分の学力や立ち位置、理解度を把握する＝「はかる」の部分を担う到達度テストについては、これまでは紙で実施しており、物理的な解答用紙の郵送・採点会社での採点……といった手順を挟むため、テスト実施から結果返却までに一ヶ月以上かかる場合もありました。そのためどうしても、時間が経つに連れてテスト自体の記憶も薄れていく懸念がありました。

学校向けのスタディサプリの価値の１つはこの到達度テストで間違えてしまった問題に紐付く学習コンテンツを個別最適に配信できる仕組みにあります。この個別最適学習をスピーディーに実施していくため、テストの結果返却までの時間短縮が課題、と捉えていました。この課題解決の手段として、CBT化が必要だったのです。また、先生観点でも問題冊子の受け取り、配布業務等がなくなるため負荷軽減に繋がると考えました。

Q：コストも削減できそうですしね。ただ、それを実現する手段として、これまでスタディサプリで主流だった内製開発ではなく、パートナー開発することにしたのはなぜでしょうか。

卯西：確かに内製には、より柔軟に素早く開発し、リリースできるといった利点がありますが、端的に言うと、現状の我々の開発組織にはCBTというサービスを開発、運用保守するケイパビリティがないと判断したからです。CBTという仕組みに関する知見がなかったため、外部の経験を持つ会社に委託して一緒に作っていく方が、よりスピーディーにいいものができると判断しました。

Q：これまで内製でやってきた開発プロジェクトとは異なる課題もいろいろあったのではないでしょうか。

卯西：自分は主に要件定義やパートナー探しといった初期の段階を担当しましたが、正直に言うと、保守運用も含めてパートナー開発した実績がなかったため、どのような契約を結べばいいのか、そもそもどんなパートナーを選べばいいのか誰もわからない状態からスタートしました。

そんな中で意識したのは、CBTをはじめ、「プロダクトは作って終わりではない」ということです。持続可能なサービスにしていく観点を重視し、また我々からのさまざまなカスタマイズの要望も柔軟に受け入れてくれるようなパートナーが望ましいと考え、自社内にエンジニアを抱えて開発しているパートナーを選びました。

畑林：当時ご連絡いただいていたら、逆側の立場にいたかもしれませんね。。採用いただけたかどうかは分かりませんが(笑)。

私は主に設計工程からリリースまでのリードを担当しました。私が担当した実開発のフェーズでは、我々とパートナーさんとの間に開発文化の違いが多くあり、それぞれの成果物をどこまで作りこむのか等、線引きのギャップに苦労しました。

例えば、私の前職の感覚ですと、この要件は実はリクルート側も十分に決めきれていない（＝開発ボリュームが膨らむ）のではないかと捉え、諸々リスクを詰んだ見積もりを作成していたとも思います。そこを、具体的な要件定義や設計工程で潰して、精緻な見積もりを作っていきます。一方、今回ご依頼したパートナーさんはまずはモノを作って、問題点を徐々にアップデートして作りこんでいくとの考え方が強かったように思います。このため、最初のタイミングで作るべきレベルの期待値に差が在り、また、リスクを十分に詰まれていないこともあって、要件が具体になるにつれ、こちらの期待とギャップが生じる事もありました。もちろん契約通りに対応してくださっているのですが、どこまで要求し、どこは呑み込むのか限られた予算の中で常に残り対応可能な余力を先方に確認しながらPJを進めていました。この時に最も意識したのがリスクの管理になります。この先、何がリスクになり得るのかを精度高めに予測して、先手先手で手を打っていくことで、手戻りやトラブル対応に要するコストを最小化し、スケジュール通りに走らせていきました。

私にとって新鮮だったのは、よりよいプロダクトに仕上げていくため、パートナーの技術担当の方から「この仕様をこう変えませんか？ここまでやりませんか？」と提案をいただいたことです。みなさん、今回のシステムに対する当事者意識が高く「こうした方が生徒の皆さんが使いやすいと思うんです」と話をしてくれました。これは嬉しいことではあるのですが、今、そこを直すと広範なテストが必要だし……と、リクルートが逆に要件を減らすコントロールしていくという変わった場面もあったほどでした。総じて、今回開発をご依頼したパートナーのメンバーの皆様には高いプロ意識で参画いただき、大変ありがたかったです。

Q：今おっしゃった「リスク」とは、具体的にどのようなことを指しているのでしょう。

畑林：一番懸念していたのは、品質が基準を満たさないためにリリースが間に合わず、社内に、そしてお客様に約束している納期通りにビジネスが進まないことでした。スケジュールから逆算して、たとえば「この例外的な処理が不足している」「ドキュメントのここの作りが浅く、認識に齟齬が生じる可能性がある」といったクリティカルなリスクになりそうな要因を詰めて、コントロールしていきました。

このプロセスを進める上で、リクルート本体のプロジェクト推進部門には、二人三脚で品質管理をサポートしていただき、本当に助かりました。プロジェクト推進部門の皆さんは、大変だったはずなのですが、我々が適切な判断ができるよう、全体俯瞰でアドバイスをいただきました。我々はいただいたアドバイスを踏まえ、優先度に応じて一部リスクは許容しながら現実的な落とし所を探っていきました。
上記の隙のないアドバイスが今回、プロジェクトを円滑に進められた要因だとも感じています。

併せて、デザイン、コンテンツ作成、お客様サポートのチームには教育業界のプロフェッショナルが集まっていました。こうしたメンバーに頼るべきところを頼りきることが出来た事も、初期開発の成功につながっています。

卯西：プランナーや営業の方々の役割も大きかったですね。現場の先生方と直接話をしているため、とても有用なフィードバックをいただけました。実は最初は、生徒一人一人にIDとパスワードを配ってログインさせる仕組みを考えていたのですが、学生が数百人もいたら絶対に「忘れました、再発行してください」という人が出てくるはずで、運用できないはずだという現場の肌感覚を伝えてもらい、仕様をガラッと変更しています。また、デザインももっとわかりやすいものにしていくため、何回もやりとりをしました。

Q：こうした調整ややりとりを経てリリースにこぎ着けたんですね。今はどのような段階でしょう。

畑林：ちょうど今、初期機能をリリースし、実際に受検いただいています。システムも安定して動いており、先生方も、生徒の皆さんからも「直感的に使える」「すごくレスポンスが早い」と評価をいただいています。初期提供としては良い形でリリースすることが出来たと考えています。ただ、いくつか端末依存の部分で追加の要望も出てきているので、それらに対応しつつ、2024年4月に正式リリースを予定しています。

Q：今回はパートナー開発でプロジェクトをうまく進めた事例となりましたが、内製とパートナー開発、どちらがやりやすいと思いますか？

卯西：自分はこれまで内製開発がメインだったため、内製の方が経験という観点からやりやすさを感じますが、今回の経験を経て、パートナー開発というオプションが増えたのはとてもいいことだと思います。今後は、その時の状況やプロジェクト特性から最適な開発スタイルを選択できればと思います。

畑林：内製の場合、メンバーのアサインが大変ですね。プロジェクトの特性にもよりますが、パートナー開発の場合信頼できるパートナーさんさえいれば、要件を決めて、予算が確保できればその通りに作っていただけるという意味では、やりやすいかもしれません。ただ、専門的なスキルが必要であったり、変則的なプロジェクトをパートナー開発で進めようとすると、費用も高くなっていく傾向があることも事実です。諸々の前提はつきますが、予算が潤沢にあるのならパートナー開発の方が進めやすい場合もあります。

卯西：そうですね、一方、内製で、エンジニアが直接プロダクト開発に携わっているからこそ得られる知見もあると思います。すべてパートナー開発にしてしまうと、ユーザーへの価値提供のスピード感が遅くなってしまうのではないかという懸念がなくもありません。コアなプロダクトについては、現場の先生方からの要望をすぐ開発に反映したり、実際にコードを書いてみてわかる使いづらさやロジック、処理の複雑さやデザインを知ることが重要で、開発しているエンジニアという存在が大事だと思っています。ただ、今回のCBTのように、完全に分離されているプロダクトやシステムなら、パートナー開発という判断はありだと思います。

畑林：内製かパートナー開発かにはいろんな判断要素があるので、一概には言えません。いずれにせよ、我々TPMはしっかり技術を理解しておく必要はあると思います。今回の私たちのように、パートナー開発する場合においても、ちゃんと技術を理解した上でパートナーさんとコミュニケーションを取り、何を重視すべきかといった会話ができることが大事です。内製するにせよパートナー開発するにせよ、そこはベースラインとして持ち続けないといけないと思います。

卯西：そうですね。作って終わりではなく、我々が目指しているのはあくまでプロダクトの成功ですから。そういう意味で、今回畑林さんが加わってくれて、学び領域においてパートナー開発の作法やプロジェクトのリスク管理に関する知見がインプットされ、オプションが増えたと思っています。

Q：では、お二人がこの先チャレンジしたいと思っていることを聞かせてください。

畑林：これまでは、いろいろなビジネスチャンスがあるにもかかわらず、内製のリソースが限られていることがボトルネックとなり、本来やりたいことやチャレンジにブレーキを踏まないといけないようなこともありましたが、外部のリソースを使って開発のスケールを上げていくオプションも選択できるようになりました。「今回のCBTプロジェクトがパートナー開発を使ってうまくいったよね」で終わらせるのではなく、やり方を整理しながら、よりリスクが低い形で進められるような「型化」を進め、まなび領域全体でうまく使っていけるようにしたいと思います。

卯西：まなび組織としてプロダクト価値を最大化するためのオプションを増やしていく取り組みの1つが、今回のCBTだったと思います。組織として、パートナー開発のケイパビリティを完全に獲得することが次のミッションだと思っています。また、内製の開発メンバーとパートナー開発のパートナーやシステムの間でハレーションが起きないようにしながらサービスを運営できる体制作りを継続的に進めることも必要だと思っています。畑林さんのような人をどんどん増やしていくことも必要かもしれませんね。

Q：一人で取り組むことも大事ですが、チームとして取り組むことでもっと大きな価値を作れるということですね。では最後に、この会社で働くことの魅力についても一言お願いします。

卯西：入社して半年の人間に、CBTという重要なプロダクトを任せてもらえる組織はそれほど多くないと思います。年次などに関係なくその人のやりたいことや適性を見て、チャレンジングな仕事を渡してくれるところは一つの魅力だと思います。もちろん、サポート体制の構築もセットなので丸投げされるようなことはありません。

そして教育市場も今、GIGAスクール構想を経てどんどん変化しています。そういった変化に一緒に携わりたい人、ICTを当たり前にしたいと考えている人にとっては楽しい場所だと思います。これからだと思いますよ、教育市場は。

畑林：教育環境はものすごいスピードで変わっていて、我々が子供の頃とは全く違っています。このタイミングで教育プロダクトに携われるのは、とてもやりがいのあることだと思います。また、リクルートにはデザイナーやデータ分析エンジニア、コンテンツの作成者など、国内でも教育業界におけるトップランナーがたくさんいます。そういったメンバーと一緒にどのようにより良い教育の下支えをしていけるかを考えることは幸せですし、刺激的で本当に楽しいですね。

取材時期：2023年4月

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