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/

競プロ部で第1回LT会を開催しました

SWEの@tobisatisより、競技プログラミング部の活動報告をお届けします。 部内で、初めてのLT会を開催しました。LTはlightning talkの略で、短い時間のプレゼンテーションを行うことをいいます。 今回は、4名の部員にひとり約10分で発表をしてもらいました。それぞれの発表について、簡単に紹介します。

競プロに特化したIDE

競プロに特化した自作IDEについて発表してもらいました。こちらに公開されています。

https://github.com/fukatani/rujaion

外観はこのようになっており、画面を切り替えず使える並列のレイアウトが印象的です。 発表では、例えば次のような機能について実演してもらいました。

  • サンプルケースの自動実行。手動で入力して目視で出力をチェックする、といった手間が省けます。問題数が多いAtCoder Beginner Contestなどでは特に便利に見えました。
  • 問題文の入力ケースからグラフを可視化する機能。数クリックで頂点とその番号、辺とその重みを描画できます。

上のリンクから、ぜひ他の機能もチェックしてみてください!

開発者fukataniからのメッセージ:

「現在、コード補完に使用しているracer-rustがdeprecatedになったことより、ビルド不能となっておりまして、代わりの補完ライブラリを導入にチャレンジしてくださる方、PRウェルカムです!」

C言語コンパイラ自作に取り組んでいます

C言語のコンパイルについて発表してもらいました。自作したコンパイラの話を通して、コンパイルの仕組みや言語によるパースの難しさの比較などがわかりやすく説明されていました。社内の他の部活の話やChatGPTの話も聞くことができました。

https://docs.google.com/presentation/d/1QK2N86194IaF855MTtSbLb6bdjxUsxszPceyZleOR5U/edit?usp=sharing

1万倍高速化

競プロにおける高速化について発表してもらいました。普段Rubyでコンテストに出られているプレイヤーならではの定数倍高速化の知見が、競プロ典型90問の1問を例に紹介されていました。タイトルは「1万倍高速化」。モノグサではRubyを1万倍高速化できる技術を習得できるかもしれません!

https://docs.google.com/presentation/d/1Oy6jQrn1mle_0iYOIJbpFp8-IU0WZYt76Lzf8B-b4o8/edit?usp=sharing

競プロ作問を支える技術

競プロの作問で活躍されているtsutajさんに、その難しさや便利なツールについて発表してもらいました。コンテストに出場しているだけだとわからない運営の作業を知る貴重な機会でした。

スライドはこちら↓

発表の様子

普段の活動としては、引き続きコンテスト後の感想や解法の共有を行っています。少しずつ部員数も増えていき、より活発になっています。

競プロ部の活動に興味を持たれた方、ぜひ一度採用サイトをご覧くださいませ!

https://careers.monoxer.com/

モノグサQAチームの立ち上げについて

こんにちは!やまもと@テスト番長です。今はモノグサでQAマネージャーをしています。 モノグサに参画してから10ヶ月ほど経ちましたので、これまでのチーム立ち上げについて振り返ってみたいと思います。

モノグサは「記憶を日常に。」をミッションとして掲げ、AI学習アプリを提供している会社です。 EdtechのQA事情については、先日公開したエントリをご覧いただけますと幸いです。

モノグサのQAチーム

モノグサのQAチームは2022年に発足しました。最初のQAEが入社したのが1年ほど前のことになります。 それ以前はSWEが実装からリリースまで全ての責任を負っておりましたが、プロダクトが巨大化・複雑化し開発チームの人数も増え、品質を保ち続けるためにQAEの採用が開始されました。 モノグサではQuality Management という部署の中にQAとE2E Test Automationがあり、QAは現在社員3名と業務委託スタッフ2名の体制で稼働しております。

モノグサにjoinして取り組んだこと

さて、モノグサに入ってまず取り組んだことは実情調査でした。Web開発の現場は色々経験してきておりますが、それぞれの現場の状況を知る事なくして正しいアプローチ戦略は立てられません。

最初の1ヶ月はオンボーディングメニュー(会社のルール説明を聞いたり開発環境を作ったり)を受けつつ、ステークホルダーを芋づる式に教えてもらい1on1を設定してペインポイントのヒアリングを実施しました。先に入社していたQAEメンバーからも色々と情報を教えてもらい、その結果、寄せられたお悩みを集約すると概ね以下のようになりました。

  • 開発者の不具合対応工数を減らしたい
  • QAは開発者個々の裁量に任されており、必ずテストされる仕組みがなく不安
  • ビジネスサイドからは開発の進行状況が分かりにくい

それらを受けて当面の方針案を作成することとしました。

  • リリース作業の巻き取り

開発者の作業負担を減らすためにリリース作業の巻き取りプロジェクトを始めました。Android/iOSアプリは2022年7月時点で巻き取り済みで、WEBとAPIのリリースが新たに対象となりました。システム上の制限とサービスポリシーの観点など調整事項が多かったため、こちらは現在も進行中です。

  • 開発プロセスにQAフェイズを明記する&実施する

開発プロセスのドキュメントにQAフェイズを段階的に追加していきました。

  1. リリース前リグレッションの明記

  2. 影響の大きな変更では着手前に召集してもらうように記載

  3. インテグレーションテストの実施を明記

結果、以前に比べ大きなトラブルは減ってきたようです。(古参スタッフ談) 現在のQAEの人数でカバーできる範囲は自ずと限られているため、体制を整えながら段階的にQAフェイズを拡充していく方針です。 今後は開発者テストとQAテストのレベル感合わせなど細かいところも詰めていくことにしています。

  • リリース情報の伝達フローを整理する

モノグサではリリース内容を事前に確約することはせず、リリースが終わってから周知するスタイルでずっと運営されています。 リリース内容はQAに回ってきた段階でほぼ確定しているので、可能な範囲でなるべく早くビジネスサイドに通知する運用フローを整備しました。 これによって、以前は散発的に発生していたビジネスサイドからのリリースについての問い合わせは減ってきました。

方針案ではエンジニアの負荷軽減を最大のフォーカスポイントと考えました。モノグサには優秀な開発メンバーが多く、工数的な余裕が生まれれば他の様々な問題も連鎖的に解決しそうだったからです。まだまだ十分には軽減出来ていませんが、今後も継続して推進して行きたいところです。

最終的に2023年内までの体制案とロードマップの形に落とし込み、立ち上がりの対応としてはひと段落しました。

新設されたQAチームがやるべきこととは?

既にサービス展開中のプロダクトチームに後からQAが入った場合どう動くべきか? 当たり前のことが多いですが、今回改めて感じたことを整理してみます。

  • リグレッションテストから入ると仕様理解が進む

リグレッションテストがあれば本番環境を最低限正常に動作するようキープすることが出来ます。入社して日が浅くプロダクトの仕様に不慣れなQAチームがシステムの全体像を掴んでいくためにも有効でした。 現在モノグサではリグレッションテストをNotion上で管理しています。かなりライトな管理方法ですが、将来的にE2E自動テスト中心への移行を見越してテスト管理システムなどはあえて入れずにやっています。

  • 負荷軽減を意識する

QAが新設されたということは品質に何らかの懸念があるわけで、その状況下では開発メンバーに相当負荷がかかっているケースが多いように思います。 不具合対応に費やす工数割合が多いと新規開発はなかなか思ったように進みません。市場不具合を減らしていく努力が必要です。 かといって単純にテストの工程を増やすと更に負担を増やしてしまいかねないので、工数を増やさず手戻りを減らせるように意識してプランニングしました。

また、BtoBのビジネスモデルにおいてリリース時期を予告しないスタイルは、顧客対応の難易度が高くなります。可能な限りの事前共有を行うことで、スムーズなサポートが可能になり開発・ビジネスサイド双方の業務負荷が軽減出来るのではと思っています。

  • プロダクトや会社の文化を理解しながらQA文化をデザインする

参画直後はどうしても会社の独自ルールが目につくものです。すぐに色々変えたくなりますが、しかしそれはそれなりの過去の経緯が存在するものなので、改善は慌てずに進めるべきです。 過去の時点の組織においてはそれがベストソリューションだったはず。たとえ標準と乖離していても非難されるべきではないのです。

  • 当たり前の水準を上げる

専任のQAが居なかった頃は検証周りの整備にリソースが割けないため、十分にチェックできる状況が整っていませんでした。 2022年7月時点では、対象OSの幅の広さに対して検証端末の数が少なく、主にエミュレーター上でデバッグすることが多かったようです。 とりあえず最初の3ヶ月で検証端末の台数を倍にしてもらいました。 検証環境のダミーデータも少なく、十分にチェックを行えない状況だったのでQAチームでどんどん作成していきました。 日々の備えがあってこそ、守れる品質の水準が上がります。

モノグサQAは最高に楽しい

モノグサのQAチーム立ち上げ話はいかがだったでしょうか?ここ数年、QAチーム立ち上げや一人QAの情報が多く発信されているようですね。QAの重要性に対する認識が広がってきて活躍の場が増えているのだとしたら、とても良いことだと思います。

モノグサは社員たちのオーナーシップが強く互いにリスペクトする文化があり、働き者が多いです。Valueに「いつでもボードゲームを遊ぶ余裕を持つ」とあるように、いつも誰かしらゲームで遊んでいる人がいる稀有で素敵な会社です。 QAチームの環境だけ見ても、どんなアプローチで品質向上に取り組むかは自由に考えられますし、アプリのリリースタイミングがQA主導であったり、開発者が協力的で検証に困ることがなかったり、かなり働きやすい環境だと思います。

モノグサにおけるQAの取り組みはまだまだこれからですが、今後は更に体制を強化して事業に貢献できるチームになっていきたいと思っています。 QAE絶賛募集中ですので、ご興味のある方はぜひご応募ください!

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

最後に:

記事は状況説明のために一人視点で書いてありますが、これら立ち上げのあれこれはモノグサのQMチーム全員で実現してきたことですので、メンバーのみなさまにも感謝を述べさせていただきたいと思います。 いつも一緒に働いてくれてありがとうございます!