ありそうでなかった学習と記憶のデータ

Monoxer Advent Calendar 2023 13日目です。

ごあいさつ

こんにちは。モノグサ株式会社の大橋です。以前の記事でも自己紹介しましたが、現在ソフトウェアエンジニアとしてデータ基盤の構築からデータ解析まで、データと名のつくことは何でもやっています。

この記事を読まれる皆さんの多くは日本の学校を卒業されたかと思いますが、学校での勉強というとどういうものを思い浮かべるでしょうか? 自分はなんだか問題集やプリントをたくさん解かされていたような気がします。

ところで、学校では日々大量の問題演習が行われる割にその効果検証を科学的に行っているという話はあまり聞きません。解いて丸付けしたデータが文字通り捨てられているのです。モノグサはデジタルツールの強みを活かし、創業以来蓄積された38億問以上の採点結果が全て保存されています。今回はこの「ありそうでなかった」データを集計して反復練習の効果について調べてみます。

反復と正解率の関係

単語問題の各回答について、同じ学習者が同じ問題を前に解いた回数を計算し、回数の小さい順に正解率を計算してプロットしたもの。1番左が初見正解率、次が2回目の正解率……

反復して覚えられるというなら、前に同じ問題を解いた回数が多ければ多いほど正解率が高いはずです。このグラフはその仮説を検証するものですが、10回前後までは順調に正解率の上昇が見られるもののそれ以降低下しています。これは反復練習の無意味さを意味するのでしょうか?

未検証ではありますが、私の仮説では正解率が反復効果だけでなく単語の覚えやすさにも依存していることが原因なのではないかと思っています。Monoxerで学習を続けると記憶済みになったものはほとんど出題されず、なかなか覚えられない覚えにくい単語だけが繰り返し出題されるようになります。すると、反復回数が多いことはその単語が覚えにくいことを暗示し、結果として正解率が下がってしまうのです。

1つの問題に固定してこのグラフをプロットすればこの仮説が検証できると思いますが、今回はアドベントカレンダーなので割愛します。気になる人は入社してね! (右肩上がりのグラフが出てくると思っていたので深掘りする作業時間を用意してませんでした……)

接触間隔と正解率の関係

やらないと忘れるという話も調べてみました。これについては、前に同じ問題を解いてからの経過時間が長いほど正解率が低下するという仮説を立てて検証しました。 ディクテーション問題(中難易度の出題形式)の各回答について、同じ学習者が同じ問題を前に解いてからの経過時間を計算し、経過時間の小さい順に20等分。それぞれのグループについて正解率を計算し、左から並べたもの。

上のグラフからわかる通り、経過時間が伸びるほどきれいに正解率が低下しています。この関係はディクテーションだけでなく単語入力や選択問題の形式でも観察されました。1番右(経過時間が最も長い群)の平均経過時間は1ヶ月程度なのですが、2番目に左(平均経過時間11.5秒)の3分の1以下の正解率になっています。

最も左の群の正解率がなぜ低いかは分かりませんが(データ不備でしょうか)、それ以外については予想以上にきれいな減少傾向が見られ、人間は忘れちゃうんだなあという事実を思い知らされます。

ほんとうはこの1番右の群がどういう分布になっていて、この群にいながら正解できる人にはどういう特徴が出るか調べたいのですが(これこそが長期記憶に他ならないのですから!)これも時間の関係で割愛です。やりたい人は入社してください!

エビデンスに基づいた学習体験を作りたい

反復回数や接触間隔が正解率に影響するという直感的には明らかな事実も、実際に裏付けられると今までより自信を持って反復練習を勧められるようになったのではないでしょうか。世の中には根拠が怪しかったり賛否が真っ二つに分かれるような教授法もたまにありますが、モノグサではエビデンスに基づいた学習体験を作ってみなさまにお届けしたいと思っています。

Monoxer Advent Calendar 2023

Monoxer Advent Calendar 2023では、開発、ビジネス、コーポレートの様々な職種のメンバーが毎日1つずつ記事を公開していく予定なので、是非明日以降もチェックしてください!

Monoxerのカレンダーページです。 qiita.com

またモノグサ株式会社では一緒に働く仲間を募集しています。 少しでも興味を持ってくださった方は、ぜひお話しましょう! モノグサ株式会社の採用サイトです。モノグサは「記憶定着」をサポートする学習サービス「Monoxer」を運営する会社です。

採用サイト

careers.monoxer.com

Tech Lead Manager 1年目を振り返ります

Monoxer Advent Calendar 2023 11日目の記事です。

 モノグサ株式会社でCustomer Reliability Engineerとして働いている大野敦です。現在Customer Success and Customer Reliability (CSCR)という領域のTech Lead Manager (TLM)として働いております。

 CSCR領域では「Monoxerの利用における”不安の最小化”(Reliability観点)と、”成果の最大化”(Success観点)の両面から顧客を支援すること」をミッションとし、日々プロダクトの開発からプロダクト外の社内ツールの整備などを行っております。直近の開発では顧客向けCSVデータ出力機能や契約請求関連の社内向けサービスの整備などに取り組み中です。

この1年の振り返り

 2023年の中で一番の環境の変化といえばCSCR領域のTLMとして一定の開発領域に対して責任を持つ立場になったことです。23年の1月時点ではそもそもCSCRという領域が何をMissionに活動するのかさえ不明確であったのが、PdMの助けもあり3月末にはCSCRのMissionが明文化され、そして4月よりCSCR領域のTLMとなりました。

 自分が関わった個別の開発のことも書きたいという気持ちもありつつ、今回はTech Lead Manager 1年目としての振り返りをしたいと思います。

ソルジャーとコマンダー

 TLMとして日々業務に当たるなかでたびたび思い出す昔の出来事を書きたいと思います。私が大学に在籍していたときにお世話になったポスドクの方との雑談の中であった話です。当時のことはあまり鮮明には憶えていない(記憶の会社にいるのですが記憶力は高くない)のですが、一つ鮮明に今でも憶えている出来事です。

 お世話になったポスドクの方が、研究者というのは個人の学問に対する洞察の深さとそれを適切に研究者にわかるように説明できる形で仮説を立て検証する能力が求められる、という話をしてくれました。研究活動の中で自走して研究を続け成果を出し続けられる研究者が限られたアカデミックのポジションを獲得し、また次の新たな研究をしていくのだということで、常に競争にさらされる非常に厳しい世界であるということを話してくれました。一方そのような競争にさらされることは大変ではありつつ、他の環境では出来ないような最先端を見れるからこそ面白いという話であり、おそらくそのポスドクの方は純粋に研究の面白さを話してくれたのだと思います。そしてその分野で実績を残し生き抜いてきた人のことをソルジャーという言い方をしていました。

 一方で、ソルジャーとして大きな成果を出し、その分野におけるポジションを上げていくと研究室のトップとして(わかりやすくは教授として)自分の研究を主導しつつ、組織の運営をしていかなくてはならないという話をしていました。そうなるとソルジャーとしての強さだけではうまく組織を回していけず、組織や人のマネージメントが必要となります。組織や人のマネージメントをしつつ研究を主導していく人のことをソルジャーの対となる表現としてコマンダーという言葉でそのポスドクの方は説明していました。

 そしてソルジャーである人が必ずしもコマンダーとして優れた人であるかというとそういうわけではなく、逆にソルジャーが自分自身のものさしでメンバーを指導してしまい組織としてのパフォーマンスを最大化出来ないということがあるという話をしていました。当時私はソルジャーとしての能力を高めるだけではコマンダーにはなれないのだということを漠然と感じていましたが、この話を聞いたときにやはりどの分野であってもソルジャーの能力とコマンダーの能力には根本的にことなるベクトルのスキルが存在するのだと納得しました。

 私がTLMとしてCSCR領域を担当することになった4月に社内のマネージャー研修がありました。そのモノグサのマネージャー研修ではマネージメントには3つの種類があるという話があり、それは「仕事のマネージメント」「人のマネージメント」「チームのマネージメント」であります。人やチームのマネージメントはおそらくわかりやすいコマンダーの責務だと思います。また仕事のマネージメントと聞くとマネージャー自身が様々な仕事にたいして主導権を握り円滑に進めるというのを想像するかもしれませんが、どちらかといえば仕事を始める前の目標設定やメンバーの業務支援という意味でのマネージメントが詳細の取り組むこととして書かれており、先のソルジャーとコマンダーという話で言えばコマンダー的な責務であります。これまではソルジャーとしていかに新たなことに挑戦し成長していくかという意識がほぼ全てであったのが、このマネージャー研修のタイミングでコマンダーとしての意識を強く持ち合わせなくてはならないと感じたのを憶えています。

モノグサのエンジニアキャリアパス

 モノグサではマネジャーというのは単純なバッジのようなものであるとマネージャー研修で説明されています。すなわち本人がやりたいという意志があり社内における合意が取れればマネージャーになれますし、逆にマネージャーになったけれどもやはりマネージメント以外の業務をより集中して取り組みたいという気持ちになればマネージャーをやめることも可能とされています。

 Product Developmentグループに限定して話をすれば、開発領域ごとにEngineering Manager(EM)、Tech Lead(TL)、Product Manager(PdM)が割り当てられており、TLとして活躍をしていくというエンジニアキャリアパスもあります(他社ではTLとは別にIndividual Contributor(IC)と呼ばれる個人の技術力を高めることで貢献するロールも存在するようです)。モノグサにおいてTLは担当領域の開発を技術的にリードし、Design Docのレビューやコードレビューなどを行い担当領域内のプロダクトやプロジェクトのマネージメントは行いますが、人のマネージメントは行いません。

 私自身は一人のエンジニアとして能力を高めていきたいというのはもちろんですが、組織や人をマネージメントすることで成果を最大化するということについても興味があったため2023年の4月からCSCR領域のTLMとなりましたが、モノグサではTL(や他社でいうIC)として活躍するキャリアパスも存在しますし、実際にTLの方で非常に社内の多くの人からも信頼されているエンジニアも在籍しています。

挑戦できる環境である

 この1年の最大の環境の変化はCSCR領域のTLMになったことであるというのを冒頭に書きましたが、もともとモノグサに入社してすぐのとき(約2年前)にCTOの畔柳さんとの1on1の場で「まずは一人のエンジニアとしてプロダクトを開発する能力を身に着けたい。そのうえでどこかのタイミングでマネージメントも経験したい」と希望を伝えていました。当時考えていたこととしては一人のエンジニアとしてある程度の開発を自走できるようになるには、よく言われる1万時間の法則をふまえると5年くらいかかるのではとおもっており、そのくらいのタイミングでマネージメントにも挑戦することになれば良いと考えていました。

 そしてCSCRのTLMにならないかと声をかけてもらったのが2023年の1月か2月のタイミングでした。最初は自分自身がまだまだエンジニアとしての能力が不足しているのではないかということを感じており、もう少し自分自身の能力を高めて一人のソフトウェアエンジニアとして活躍したいという話をしてマネージメントは時期尚早なのではと思っていました。しかし、CSCR領域のPdMとも話をする中で自分がTLMとなることが自分自身だけでなく周囲にも良い影響を与えることができると思い始め、3月にTLMとしての挑戦をすることを決意しました。

 いま振り返ると挑戦できる環境が整備され挑戦を後押ししてもらえたことは幸運であったと思うと同時に、挑戦するという判断をしてよかったと感じています。

Tech Lead Manager 1年目としての振り返り

 4月から約8ヶ月経過し振り返ってみると様々失敗したことや反省すべきだったことはあります。今回は判断と余裕というキーワードで振り返っていきたいと思います。

 TLMになる前となった後を比べると、プロダクトの開発における技術的リードからチーム・人のマネージメントまで様々な場面で判断することが増えたと感じています。その中で自分自身に余裕があるときには必要な情報を整理し、分からない点や曖昧な点を明確にして判断することが出来たと思います。一方で自分自身に余裕がないときに、それまで必要な情報を整理しその領域について深く把握している状態であっても、瞬発的に視野が狭まりあまり深く思考せずに表面的な情報で判断してしまうこともありました。そして振り返ってみると余裕がない場面での判断は結果的に良くない選択をしていることが多かったと感じています。

 どのようにして余裕を持てばよいのかは、人それぞれやり方があると思いますが、私自身は一つの方法として計画を立てるというのを意識しています。計画を立てることで自分自身が取り組むべきことを明確にすれば、いつ自分が余裕を持てなくなりそうなのかを予測することができると思います。そうなれば事前に関係者に連絡を取っておくなど立ち回ることができますし、自分の状況を正しく周囲に伝えること自体が最終的には自分を助けることにもつながるのではないでしょうか。

 また、この計画を立てるというのは表面的にはいつまでに何をするかを決めること(極端な表現をすると四半期ごとのOKRやKPIを決めるだけ)のように思えますが、重要なのはその計画を完遂するために必要な項目を洗い出し自分に不足していることや事前にやるべきことを明確にし、計画を自分が取り組むべき課題を細分化していくことだと考えています。計画を細分化する作業を進める中では課題の構造的理解が必要となり、単純な一本道での計画の完了とはならない中で関連しあう課題をどのように組み合わせ効率よく進むことができるのかを検討する。その思考を細部にわたって巡らせて自分の取り組むべきことを明確にしておくことで自分の取り組む課題の進捗を管理することができ、素早い判断をする余裕を生み出すことができるのだと思います。

さいごに

 Tech Lead Manager 1年目としての振り返りを行ってきましたが、しばらくは継続してCSCR領域のTLMとして開発を推し進めていくことになります。まだまだ自分自身が一人のエンジニアとして知識・経験が不足していると感じているのでそれらを深めていきたいですし、またマネージメントについても継続してよりよいやり方を模索していきたいです。1年後もTLMのままでいればですが、2年目の振り返りを書きたいとおもいます。

 モノグサ株式会社では一緒に働く仲間を募集しています。 少しでも興味を持ってくださった方は気軽にご連絡ください。

Monoxer Advent Calendar 2023

qiita.com

採用サイト

careers.monoxer.com

Monoxer Intern Report #14_手書き領域のフィードバック改善

自己紹介

モノグサの2023年のサマーインターンに参加させていただきました、北村と申します。(この北村さんとは別人です) 所属は千葉大学大学院の1年で、プログラム検証の研究を行っています。

参加を決めた理由

AtCoder Jobs の求人を拝見して、記憶定着にまつわるサービス開発という革新的なプロジェクトに目を惹かれたのが大きな要因です。 さらに AtCoder や ICPC のスポンサーとなっていたことも認知していたため、競技プログラミングに造詣が深い会社なのだと推察し、応募に至りました。

取り組んだこと

主に手書き領域のフィードバック改善に取り組みました。

当初の手書き形式の問題は学習者がなぜ間違えたのかわからないケースが多く、ユーザビリティの低下を招いていました。

(形が悪い)

(線が1本多い)

手書き文字の評価器は、お手本を元にユーザーの書いた文字を評価し、それぞれの画のスコアと文字全体のスコアを返す仕組みとなっていました。

文字全体のスコアが一定値を超えた場合不正解と判断し、スコアの高い画を赤く表示することでユーザーにどの画の形が悪いかを伝えています。さらにこの際、書き順が異なるなどの画は黄色で表示します(これは正誤に影響しません)。

しかし正解不正解の判定は文字全体のスコアのみで行われる上に、文字全体のスコアが一定以上であることと画のスコアが一定以上であることは同値でないため、なぜ間違いなのかがわかりにくいケースが多々ありました。

そこで、評価器がなぜそのスコアに評価したかの評価理由を返すよう改良しました。これは評価フローにおいてどこの if 文を通ったかなどを見て判断する形で組み込みました。 評価理由はデータの圧縮と実装の軽さの観点から、エラーコードのような数値で表現しています。

それに加え、取得した評価理由とパラメータを用いてアプリ側で適切なフィードバックテキストを表示する機能を追加しました。 フィードバックは吹き出し形式で表示することで視覚的にも情報が得られやすいものとなっています。

※この機能は当記事公開時点では未リリースです。
※画像は開発段階のものであり、リリースされるものと異なる場合があります。

これにより、学習者が不正解の理由を一目で理解できるようになりました。実際に使ってみても、以前と比べて間違えた時の納得感が増えたように感じます。

学び

入社当初は競技プログラミングと簡単な web 開発の経験しかありませんでしたが、実践的な業務を通じて GitHub での PR→レビュー→マージの流れや、仕様変更に強いコード設計の考え方を学びました。 さらに PR の過程でデザイナーさんと方針のすり合わせのためにやりとりすることもあり、組織的な開発プロセスについて多くの知見が得られました。 Kotlin でのコーディングは初めてでしたが、既存の洗練されたコードから学ぶことで強い静的型付けによる型安全性を実感することができました。

インターンの感想

社員さんと交流する機会が多くありましたが、ユニークな方が多く毎日が楽しかったです。それだけでなく、各々がモノグサをより良くしようという意志を持ち、自発的に動いているのを実感しました。 社内の雰囲気が厳しすぎず緩すぎず、まさに「ものぐさで行こう」というバリューを体現しているように感じました。

また、インターンであるにもかかわらずプロダクトの改良に向けてしっかりコードを書かせていただき、多くの学びが得られました。 実際に広く使われているコンテンツに自分の書いたコードが組み込まれていると考えると、不思議な気持ちになります。

非常に価値ある経験をさせていただき、大変感謝しています。

QAエンジニアの技術面接課題を公開します

この記事は Monoxer Advent Calendar 2023 3日目の記事です。

こんにちは!やまもと@テスト番長です。あっという間にもう12月なんですね。 僕はモノグサでQM(Quality Management)チームのマネージャーをさせていただいております。 モノグサのQMチームにはQAとE2E Test Automationの二つのチームがあり、製品の品質を安定させたり、よりスムーズな開発が出来るよう日々活動しています。

今日はモノグサのQAエンジニア用の採用課題を公開しちゃいます。 普段あんまり目にする機会が無いものですので、面白そうですよね?

そんなことして大丈夫なの?

実は最近、採用課題を一部入れ替えました。その結果として使わなくなった古い問題を2つ公開します。採用側から見た解説も併記しますので、そういう問題を出してるんだーとか面接でそんなところ見てるんだーなど何かのご参考になればと思います。

モノグサQAの選考フロー

前提として、簡単にモノグサQAの選考フローをご紹介します。 直接応募やスカウト経由などルートは様々ですが、概ね以下の流れになります。

カジュアル面談

ざっくばらんにモノグサについてお話ししたり、業界話やお悩み相談をしています。ご相談者さまのニーズに弊社がマッチしそうであれば、選考に進んで貰うことをお勧めしたりももちろんします。

書類選考

応募いただいた場合は書類で簡単にご経歴をチェックしています。

1次オンラインテスト

オンラインテストではQA関連の基礎知識を確認させていただきます。 自由回答の記述式なので、割とお人柄が出るテストでもあります。

2次技術面接

オンラインで技術的なスキル面の確認をさせていただきます。 2〜3人の面接官が1時間程度かけて面接します。

最終面接

最後にモノグサのボードメンバーと面接していただきます。 オフィスにお越しいただいてボードゲームも一緒にやります。

オファー面談

見事内定となった方に、条件の提示と詳細の説明や擦り合わせを行います。

今回公開するのは2次の技術面接で使っていた問題です。 スキル面の確認はここが最後になりますので、しっかり見極める必要があり重要な面接です。 では早速、採用課題を見ていきましょう。

課題① デシジョンテーブルを描く (15分)

問題:以下の条件をデシジョンテーブルで表現してください
☆公園の入場料☆
  • 中学生以下(15歳以下)は500円
  • 16~59歳は1000円
  • 60歳以上は800円
  • クーポン利用(全年齢対象):300円割引
解説:

基本的なテスト設計のスキルをお持ちかどうかを確認させていただく問題です。

デシジョンテーブルは日常的に実践する機会が多いテスト技法だと思います。もし実践経験がなくても、年齢3パターン×クーポン2パターンの6通りを作図すれば良いのですが、改めてデシジョンテーブルでと言われると混乱するのか、意外と正解率の低い問題でした。

面接官の目の前で表を描くのはかなりプレッシャーかも?というのと、面接時に回答用スプレッドシートの切り替えがなぜか上手くいかないことが多くて入れ替え対象にしました。

課題② フリマアプリのテスト計画 (20分)

問題:CtoCのフリーマーケットサービスをスマホアプリで提供するとします。現在QAの仕組みは何も整備されていません。あなたならどこから取り組みますか?
解説:

これはシニアレベルの方向けの問題で、自由度の高い条件下で全体的なテスト計画の設計が出来るか確認させていただく問題です。

これまでのご経験がテスト実行中心の方だと、各機能の検証について列挙される場合が多かったです。しかしそれでは「仕組みの整備」としては回答不足ですね。

マネージャークラスorチーム立ち上げのご経験があるなどテスト計画をしたことがある方であれば、前提条件について確認する質問が出てきます。例えば以下のような項目です。

  • テスターの人数や使える稼働工数は?
  • iOSかAndroidか両方か?
  • サービスの事業規模は?

QAの仕組みを整備するとなると以下のような質問も出てくるかなと思います。

  • BTSがあるか、開発プロセスや仕様書の有無は?
  • 本番環境以外の検証環境は使えるか?
  • そもそもこれまでどうやって開発していたのか?

候補者の方の視座が如実に出る問題なので重宝していました。 目をキラキラさせながら、チート、荒らしや海賊版対策、マネロン対策などフリマサービスならではの話が出てくるともう最高ですね。

CtoCのフリマアプリは皆さん使っていてメジャーだろうと思っていたのですが、あまり使わないよ?という方が結構おり、なかなか具体的にイメージしにくいようなので入れ替えることにしました。 でも、このようなテスト計画のご経験を問う問題は今後も使っていくと思います。

モノグサQA募集中です

モノグサQAの技術面接課題、いかがでしたでしょうか? 難しそうにお感じになられたかもしませんが、一方的に回答していただく感じの面接ではなく随時相談しながら進めるスタイルで楽しくやっていたりします。 面白そうだなと思った方は、ぜひご応募ください!

このブログ記事が何かのご参考になりましたら幸いです。

モノグサ株式会社では一緒に働く仲間を募集しています。 少しでも興味を持ってくださった方は、ぜひお話しましょう!

Monoxer Advent Calendar 2023 へのリンク qiita.com

採用サイトへのリンク

careers.monoxer.com

Monoxer Intern Report #13_大量のコンテンツの描画処理最適化

自己紹介

筑波大学大学院修士1年の山﨑昂輔です。大学ではRDFデータを分散処理で効率的に問合せするためのデータ分割手法について研究しています。 モノグサで7月から9月までの3ヶ月間夏季インターンシップに参加していました。

参加を決めた理由

Scalaという言語をより実践的に学びたいということと、実務経験を積みたいということが主な理由です。 私は研究でこのScalaを使用しているのですが、学習のための資料が少ない状況でした。5年以上前のwebページの資料等を参考になんとか学習し、使えるようにはなりましたが、この使い方が本当に正しいのかを知りたいと考えていました。 そこで様々なインターン応募サイトを探していたところ、AtCoder JobでScalaを使用している企業としてモノグサがヒットし、参加を決めました。

取り組んだこと

細かいタスク

Monoxerの業務は様々ですが、私はその中でもマーケットプレイスという領域のタスクに取り組みました。マーケットプレイスは出版社が商品を販売・管理する機能や、利用組織の管理者である学校の先生などが商品を購入・管理する機能があります。詳しくはマーケットプレイス概論を読んでみてください。 マーケットプレイスでの開発は、フロントエンドとバックエンドを触ることになるのですが、私は今回のインターンシップが実務初体験であり、TypeScriptの使い方どころかGitHubの使い方すらわかっていませんでした。そこで初めは軽めのタスクを割り当ててもらいながらどのようなものかを理解していきました。 詳細は省きますが、小さめのタスクは

  • ページネーションの導入
  • ダイアログをトーストに変更
  • 表示のバグの修正

などです。これらのタスクを通して基本的なGitHubの使い方やReactの仕組み、バックエンド処理などについて教わったのち、今回のインターンシップのメインタスクに取り組み始めました。

メインタスク

概要

私のメインタスクは、「マーケットプレイスのコンテンツを大量に購入しているとブラウザが停止してしまう」という問題の解決でした。上述の通り、マーケットプレイスの商品は学校の先生などが購入して利用しますが、先生方が利用するPCのスペックはあまり高くないことも多いです。そしてその場合、購入したコンテンツが増えると一覧表示時等においてそれらを処理することができなくなってしまいます。そこで今回のメインタスクによって、PCのスペックを問わずスムーズな操作の実現を目指しました。

Bookとその統合

今回の問題はBookの統合を行う際に生じていました。 Bookとは、モノグサの商品に含まれているいわゆる問題集のようなものであり、組織は商品を購入し、その問題を児童生徒らに解かせることができます。このBookは単元ごとに分割されていることもあり、組織が商品一覧から複数のBookを選択し統合することで、指導内容に合わせた新たなBookを作成することも可能です。今回の問題は、この統合操作の際に生じていました。

従来の処理

そもそもなぜブラウザが停止してしまうことがあったのかを理解するために、元々どのような処理になっていたのかを説明します。 学校の先生などが購入した商品の一覧を開く際、従来はすべての商品とその商品に含まれるBookの情報を一括で受信し表示していました。さらに、この時デフォルトではアコーディオンが開いており、購入している商品だけでなくその中のBookが全て表示される(図1参照)ことから、商品数の増加に伴い描画コストも増加し、結果としてブラウザが処理しきれずに停止してしまっていたのです。また、商品検索も同様で、大量の商品内での検索は処理コストが高くブラウザ上での処理が困難となってしまっていました。

図1.「Bookの統合」を開いた時の従来の画面

処理の改善

上記の問題に対して、受信・描画するデータ量を削減することによる改善を試みました。 具体的には、

  1. ページネーションを導入し、1ページあたりの商品数を30件に制限
  2. デフォルトではアコーディオンを閉じ、商品名のみの表示(図2参照)
  3. 商品検索をサーバーサイドでの処理に変更

の3つのアプローチを取りました。1と2のアプローチは、描画量の大幅な削減を目的としており、従来は総商品数+総Book数だけ必要だった描画を30件以下に抑制できます。3のアプローチは検索コストの削減を目的としており、サーバー側での処理によって組織のPCのスペックに依存しないスムーズな検索を実現できます。 リリース後には、「挙動が軽くスムーズになった」との声もいただきました。

図2.「Bookの統合」を開いた時の変更後の画面

インターンの感想

実務を行う経験

本インターンシップはインターンシップ専用のプログラムではなく、実際に実務としての開発を行い、会議や社内chat等の閲覧も可能な環境でした。今後就活を控えている身として、どのような人たちがどのようにして働いているのかを知ることができたのはとても良い経験であり、社会での働き方の例として大変参考になりました。プログラミングの面では、そもそもの一般的なコーディングの作法から必須スキルまで、多くのことを経験できたと感じています。特に、命名や責任範囲などは普段の研究でも自分のコードを読むために重要なことであるため、意識して活かしていきたいと思います。

誰かのためにプログラムを書く経験

これまで自身のためのプログラムしか書いたことがなかった私にとって、私がコードを書くことで他の誰かのユーザー体験が改善したという実感はとても新鮮であり、かつ嬉しいものでした。実際に「挙動が軽くなって助かった」という声をいただくことができたのも印象的です。

社内の環境や働き方

先にも書いた通り社内のやり取りの閲覧や自分の意見の発信もできるという中で、社員の方々がモノグサという会社とサービスに誇りを持ち、より良くしていこうと考えていることを感じられました。また、多くのやり取りの中で「ありがとうございます」という言葉が頻繁に出てくるのも印象的でした。私自身、特にインターン開始直後などは自分の考えを発信する際に「こんな初歩的なこと聞いても良いのだろうか」や、「素人意見で大丈夫だろうか」などとドキドキすることもありましたが、「ありがとうございます」と言っていただけることで発言のハードルが下がり、より気楽に発信しやすくなったと感じました。 働き方の面では、勤務時間・勤務形態ともに柔軟であり、授業や課題、研究等とのバランスを取りながら不自由なく勤務できました。また、会社にはフリードリンクや軽いおやつ、ボードゲームなど仕事以外も充実しており出社も楽しかったです。

自身の成長

授業や研究でのプログラミング経験はあったものの実務での経験は0からのスタートだったので最初は不安もありましたが、日を重ねるごとに徐々にいろいろなことを理解していくことができたと感じました。特に、9月に2週間他社のインターンシップにて学生7人でチームを組んでReactを用いたAgile開発を行なった際には、モノグサでインプットしてきた経験や知識を適切にアウトプットでき、これまで自身が教わってきたことが自分のものになっていることを実感しました。とはいえ何度もメンターの加藤さん含めいろいろな方に質問しており、レビューでもたくさんの指摘をいただいているので、まだまだこれからも様々なことを吸収していきたいと考えています。 今後は通年インターンに切り替えて引き続きモノグサで働かせていただけるので、より良いサービス作りに貢献できればと思います。

Monoxer Intern Report #12_タスクの検索性改善

自己紹介

モノグサのソフトウェアエンジニアインターンに参加した山田です。現在は東京大学農学部でイネの研究をおこなう傍ら、ut.code();というプログラミングサークルでWeb開発をしています。

参加を決めた理由

私が今夏のインターンで達成したかった目標は以下の2つです。

  1. 個人開発やサークルでの開発からステップアップし、本格的な開発を学ぶ
  2. ソフトウェアエンジニアとして働くイメージをつけ、今後のキャリアを具体的に決める

モノグサのインターンでは、実際のプロダクト開発に関わる中でこれらの目標を達成し、自身の成長に繋げられると考え、参加することにしました。

取り組んだこと

記憶アプリMonoxerでは、学習者はタスク(課題)を使って学習しています。組織によっては大量のタスクを据え置き型で配信しており、多い場合には学習者あたり1,000件以上のタスクを抱えています。そのため、学習者が特定のタスクを探すには、タスク一覧画面で大量にスクロールをする必要がありました。

そこで本インターンでは、「Deep Link」と「タグ検索」という2つのアプローチでこの問題に取り組みました。

Deep Linkとは、ユーザを特定のアプリに遷移させ、指定したアプリ内コンテンツに誘導するリンクのことです。従来のMonoxerでは、Deep Linkを使ってアプリを直接開くことはできましたが、アプリ内の特定のコンテンツに誘導する機能はありませんでした。

そこで、アプリ側(iOS/Android)で、

という形式のリンクを踏むとアプリが開き、タスク画面に遷移する機能を実装しました。 管理者がDeep Linkを使って学習指示を行う方法としては、以下の2通りを想定しています。

1つは、Web管理画面上で生成したリンクを塾や学校等で用いている外部サービスで共有し、学習者にリンクをタップしてもらう方法です。 もう1つは、Web管理画面上で生成した二次元コードを印刷し、学習者に端末のカメラアプリから読み取ってもらう方法です。二次元コードは、node-qrcodeを使ってフロントエンド側で生成しています。

以前より、URLから直接タスクを開きたいという要望は複数寄せられており、確かなニーズがありました。本機能により、管理者はより簡単に学習指示を行えるようになり、学習者はスクロールせずに特定のタスクにアクセスできるようになりました。

タグ検索

もう1つのアプローチは、管理者がタスクにつけたタグ(例: #8/31日分宿題)を使って絞り込みを行う機能です。従来のMonoxerでは、Web管理画面上ではタグを使ってタスクを管理していましたが、アプリ側ではタグを活用できていませんでした。

そこで、アプリ側(iOS/Android)でもタスクについたタグを使って検索する機能を実装しました。具体的には、検索窓の横にある絞り込みアイコンを押すと、タグで絞り込むための画面が表示され、複数選択でタグを絞り込むことができます。 選択可能なタグ一覧を取得するにあたっては、2つの方法を検討しました。

1つは、APIサーバーにタグを取得するためのAPIエンドポイントを追加する方法です。 もう1つは、APIサーバーからタスク一覧を取得する際に、すべてのタスクからタグを重複なく抽出する方法です。

この判断は悩みましたが、APIエンドポイントをむやみに増やすべきではないこと、学習者あたりのタスク数が最大1,700程度でありパフォーマンスに影響しづらいことなどから、最終的には後者を採用しました。

本記事の執筆時はまだレビュー段階ですが、タグによる絞り込み機能についても根強いニーズがあり、もしリリースされれば、管理者による学習指示のやり方を大きく変えることになるのではないかと考えていて、楽しみにしています。

インターンの感想

本インターンでは、SwiftとKotlinを使う機会が多かったです。どちらもはじめて触れる言語でしたが、既存のコードや公式ドキュメントを読み、詰まったら積極的に質問していたため、思いの外、詰まることはほとんどありませんでした。そのため、未経験の開発言語の募集であっても、恐れずに突っ込んでもよいという学びがありました。

一方で、ソフトウェア開発全般の知識面では困ることがあり、開発効率という点でも、人より手戻りが多かったように思います。この部分に関しては、実務経験というより基本的な理解が不足していることが問題だと認識しています。コードを書けるようになるだけではなく、どうして動くのか、どうしてそう書くのかといった仕組みや原理に近い部分も理解する必要があると感じました。

また、取り組んだテーマの難易度やインパクトの大きさなどから、インターン生ながら責任感とやりがいを感じながら働くことができました。そのおかげで、期間中は終始楽しく開発ができ、あらかじめ設定していた目標も達成でき、非常に充実したインターンとなりました。 貴重な経験をさせていただき、ありがとうございました。

Monoxerに限らず、世の中には解決したい記憶にまつわる苦しみがまだまだたくさんあります。記憶の苦しみを一緒に解決したいという方は、ぜひ採用サイトをご覧ください! モノグサでは職種問わず一緒に働ける方を募集しています! careers.monoxer.com

モノグサキーボードの苦しみを解決した話

ソフトウェアエンジニアの狩野です。 Monoxerでは記憶を定着させるために、様々な形式での学習を提供しています。例えば、いくつかの選択肢の中から正解を選ぶような選択肢形式、問題に対してキーボードから回答を入力するような形式、手書きで漢字を回答するような形式などがあります。今回はその中から、キーボードを使って回答を入力する形式に関するお話です。

Monoxerで提供するキーボード

Monoxerでは回答を入力するために専用のキーボードを用意し提供しています。例えば英単語を入力するような問題では、次のスクリーンショットのようなキーボードが学習者に提供されます。

qwerty配列による英語キーボード
また日本語で回答するような問題に対しては、限定されたキーから回答を入力するようなキーボードが提供されます。
日本語を入力するキーボード
このキーボードは社内では「Monoxerキーボード」や「自由入力キーボード」「日本語入力キーボード」といった名称で呼ばれています。以降、本記事ではこのキーボードを「日本語入力キーボード」と表現します。 「OS標準のキーボードを使わないのか」と疑問に思う方もいるかもしれません。これは利用者の端末や環境に依存せず同じ学習体験を与えるためというのが大きな理由になります。Monoxerでは記憶をするために必要な体験を最適な形で提供しようと試みています。

日本語入力キーボードの苦しみ

日本語入力キーボードでは、正解を構成する文字の他に誤答候補となる単語の文字を配置しています。例えば「りんご」が正解となる問題の時には「りんご」の他に「ぶどう」や「みかん」の文字がキーボードに表示されます。こちらの誤答単語の生成についても非常に深い領域であり、インターン生に取り組んでいただくなどして機能の向上を図っております。詳しくはこちらの記事をご覧ください。 ここで次のスクリーンショットをご覧ください。

今現在は本画面のようにはなりません
同じ形の文字が複数表示されています。それぞれ伸ばし棒の「ー」と漢字の「一(いち)」なのですが、違いが分かるでしょうか? 仕様に詳しい人であれば「カタカナの後ろにあるやつは伸ばし棒のー」「漢字のキーの前にあるやつは漢字の一」だと予測することができるのですが、初見で遭遇した人は混乱してしまいます。もちろん入力するキーを間違えれば不正解となります。結果だけ見るとどこが間違っているか分からなく、納得感がありません。
どこが間違っているのか分からない
余談ですが、ここで取り上げたような似た文字に関する話題はMonoxer以外でも度々見かけられ、頭を悩ませる原因になる事も多いようです。
こんなにある

似た形の文字同士をペアにする

似た形の文字を考えてみると、実はそんなに種類が多くないことが分かります。

  • 伸ばし棒の「ー」と漢字の「一」と全角ハイフン「-」
  • カタカナの「ニ」と漢字の「二」
  • カタカナの「エ」と漢字の「工」
  • カタカナの「カ」と漢字の「力」
  • カタカナの「ト」と漢字の「卜」
  • カタカナの「ロ」と漢字の「口」

そこでMonoxerでは上記問題に対処するために、似た形の文字同士をあらかじめペアとして持つことにしました。その文字が解答に使われる際には、ペアのもう片方の文字をキーボードに採用しないキーのセットに追加します。そうすることで、似た形の文字は同じキーボードに表示されなくなるようになります。 今回は日本語に限定した対処としましたが、将来的に他言語での文字にも対応できるよう拡張しやすいコードを書くことなども行っています。既存のコードもとても拡張しやすいように書かれており、最小限の変更で機能を追加することができました。

これなら間違えようもありません
また余談にはなりますが、似た形の英語には既に対処されていたりします。大文字の「I(アイ)」と小文字の「l(エル)」は見た目上同じ形ですが、Monoxerでは大文字のI(アイ)の表示を変えることで見分けがつくようになっています。
大文字のI(アイ)と小文字のl(エル)の違い

学習の苦しみを解決する

以上のアップデートにより、学習で生じる苦しみが解決されました。モノグサでは、記憶にまつわる本質的な苦しみを100件解決することを2023年度の目標として掲げています。そして本件はその中の1つの事例となりました。 そしてMonoxerではキーボード以外にも、日々様々な領域で記憶にまつわる苦しみの解決が試みられています。そのすべてをこのような形で公開することは難しいですが、Monoxer アップデートブログを見ていただけるとある程度雰囲気が分かるかもしれません。

Monoxerに限らず、世の中には解決したい記憶にまつわる苦しみがまだまだたくさんあります。記憶の苦しみを一緒に解決したいという方は、ぜひ採用サイトをご覧ください! モノグサでは職種問わず一緒に働ける方を募集しています!

https://careers.monoxer.com/