はじめに
こんにちは！今年の3月に大学院の修士課程を修了し、4月に新卒としてGunosy Tech Lab (GTL) Media MLチームに配属になりました大竹です。本記事は、新卒エンジニアがそれぞれの視点から入社以降の取り組みやエピソードを紹介する新卒ブログの第一弾です。今年エンジニアとして新卒入社した同期は私を含めて4名おり、今後各人によるリレー形式で更新していきます。
GTLという組織・Media MLチームについて
Gunosy Tech Lab (GTL)は、Gunosyにおけるデータ活用の促進や情報推薦の研究を担当する専門組織です。GTLの中でもMedia MLチームは、ニュースアプリの根幹を支えるニュース記事の推薦モデルや記事リストの生成アルゴリズムの開発を担当しています。
入社〜現在までの流れ
Gunosyには内定者インターンと呼ばれる制度があり、4月の入社日以前から配属予定チームにjoinして業務に馴染むことが可能です。私は、大学院に在籍中はなるべく大学院でしかできないことに時間を使いたいという理由で入社前インターンには参加せず、4月の入社日からMedia MLチームに配属となりました。新卒入社の同期はエンジニア職4名、ビジネス職8名の12名です。
4月~6月にかけては新卒研修がありました。 新卒研修は職種を問わず全員で行うものと、エンジニア職のみが行うものがあります。前者は社内の各部門についてのレクチャーや、創業者である関さん、役員の方々からの講義が含まれます。CTOの小出さん、CDOの大曽根さんからはそれぞれソフトウェア開発やデータ分析の基礎に関する講義がありました。ビジネス職のメンバーはソフトウェア開発やデータ分析の基礎を学び、私を含めたエンジニア職のメンバーは営業やマーケティングについて学ぶ非常に良い機会でした。後者については、Udemyを利用して業務で必要となる技術（AWS/Docker/k8s/Goなど）の基礎を学ぶ時間が含まれます。こちらは全員で行う研修と異なり、自分のペースで進めることができるのが特徴です。
これらの新卒研修と並行する形で、徐々に配属チームにおけるOJT（On the Job Training）に割く時間が増えていきました。以下では、私がOJTとして最初に取り組んでいるタスクであるスポーツタブのロジック改善について簡単にご紹介したいと思います。
OJT：スポーツタブのロジック改善
Gunosyアプリには、スポーツやエンタメなど話題のドメインごとにニュース記事が整理されたタブが存在します。
Media MLチームでは現在こうしたタブのロジック（記事リストを生成するアルゴリズム）を見直すプロジェクトに取り組んでおり、私はOJTとしてスポーツタブの改善を担当することになりました。以下、現行のロジックの概要、改善までの道のりという順番でご紹介します。
既存ロジック
現行のスポーツタブでは、ユーザーのクラスタに基づく記事推薦ロジックが使用されていました。詳細は割愛しますが、大まかには以下のステップで記事リストを生成します*1：
ユーザーがクリックした記事を元に、ユーザーをあるクラスタ数に割り当てる
クラスタに所属するユーザーのImpression, Clickを集計しクラスタ毎に記事のCTRを算出
各記事のCTRに時間減衰関数をかけ、時間経過による価値減衰を考慮
ユーザーの所属するクラスタにおいてスコアの高い記事をユーザーに表示する
ニュース記事推薦の特徴として、ニュースの価値は時間に応じて減衰していくという点が挙げられます*2。現行のロジックでは3番目のステップで、時間減衰関数（実際にはガウス関数が使われています）を記事スコアにかけることにより、ニュースの価値が時間に応じて減衰する様子をモデル化していました。
改善までの道のり
ロジックを見直す際に指針となるのは、スポーツタブを訪れるユーザーのユーザーストーリー（エンドユーザーの立場から考えたシステムへの要件）です。今回は社内のスポーツ好きな社員に協力して頂きユーザーストーリーを作成しました。例えば、
- 好きなチームの試合結果が見たい
- 好きなスポーツ選手のインタビュー記事が読みたい
- メジャースポーツ以外でも新記録 (快挙達成) などがあれば知りたい
といったものが含まれます。これらを元に、今回フォーカスして取り組むべき課題として大きく次の2点を整理しました。1つ目はパーソナライズのアルゴリズム。2つ目はニュースの価値が減衰する様子の記事wiseなモデル化です。
（1）パーソナライズアルゴリズム
ユーザーストーリーには「好きなチームの試合結果が読みたい」「好きな選手のインタビュー記事が読みたい」といった要件が含まれていました。こういったユーザーの好みに基づいた記事推薦は、現行ロジックではユーザークラスタに基づいたパーソナライズアルゴリズム（上述）により実現されていました。一方、現在グノシーアプリのトピックタブ（アプリを開いた時に最初に表示されるタブ）では深層学習を使用したモダンな推薦モデルが導入されており*3*4、トピックタブにおけるその有効性も検証済みであることから、この推薦モデルをカテゴリタブにも導入することにしました。
（2）記事wiseな時間減衰
上述したように、ニュース記事の推薦ではニュースの価値が時間に応じて減衰していくという点が特徴的です。既存ロジックでは、この価値減衰をモデル化する時間減衰関数は全ての記事に同じものが使用されていました。しかしこの方法では、記事の種類によって価値の減衰の仕方が異なっていた場合にその異なりを考慮できないという問題があります。
ユーザーストーリーを振り返ると、ユーザーが読みたいと思っている記事にはコラム、試合結果、インタビュー等、様々な種類のものが存在しています。例えば同じ1日前のニュースとして1. 野球の試合予定の記事（注目の選手紹介など）、2. 野球選手が半生を振り返るインタビュー記事、があった場合、これらはどちらも1日の時間経過で同じくらい価値が損なわれるでしょうか？ 1の方は試合が終わると同時に明らかに価値が大きく損なわれますが、2の方は時間が経過しても比較的その価値が損なわれないものと考えられます。今回新たに、こうした記事wiseな時間減衰の様子のモデル化に取り組みました。
具体的な手順を概要のみご紹介すると、まずニュース価値の減衰についてのいくつかの仮説（例：じっくり読まれる記事（ユーザーの読み速度が遅い記事）は価値がゆっくり減衰する）を洗い出しました。次に評価用データとして、手作業で「比較的早く価値が減衰する記事」or「比較的遅く価値が減衰する記事」をニュース記事にアノテーションしたデータセット作成し、このデータセットを用いた実験で洗い出した仮説を検証しました。最終的に最も妥当と定量評価された仮説に基づき減衰関数のパラメータを調節することで、それぞれの記事に異なる時間減衰関数が使われるようにしました。
以下の図2に設計した時間減衰関数のグラフを示しています。例として異なる3つの記事に対する減衰関数を載せており、記事の性質に応じた価値減衰の様子を表現できていることがわかります。
以上2点の工夫を含めた新しいロジックによって、オフラインで記事リストを生成し、何度も定性分析を重ねながら最終的なロジックを決めました。現在は実装に取り組んでいる途中ですが、チームでの開発は初めての経験であり学ぶことが多いです。
学んだこと、気がついたこと
ここからは、入社から今まで、OJTなどを通して学んだことや気がついたことをいくつか挙げていきたいと思います。
コストの意識
大学院で研究をしていた時は「じっくり時間をかけて良い研究をする」という意識が強く働いており、入社後も同様の意識に陥りがちでした。しかしながら、プロダクト開発では新しい機能を早く出すことも重要です。仮に新しい機能がユーザーに何かしらの利益をもたらすとすると、リリースに時間がかかればかかるほど、生み出されるはずだった利益が損なわれてしまいます。また、新しい機能が期待していたような効果をもたらさなかった場合にも、その事実が早い段階で分かることですぐに軌道修正したり撤退したりすることが可能です。CTOの小出さんも同じ観点をdeliveryと呼び以前ブログ記事*5を書かれていましたが、OJTを通してこの時間的なコストの意識を学びました。事前に考え抜いたり、正確・丁寧な検証を重ねることももちろん重要ですが、同じくらい早く・小さく検証することが重要です。
タスク管理
Media MLチームでは5日をスプリントの単位としており、5日に一回その回のスプリントで各メンバーが取り組むタスクとその所要時間の見積もりを行います。私は当初からこの時間見積もりを苦手としており、見積もっていた時間よりもタスク完了までに時間がかかってしまうという事態が頻発していました。取り組むタスクは基本的に初めて触れるものなので、タスクの全体像が理解できていなかったり、どこに時間がかかる可能性があるのかが分かっていなかったりしたことが主な原因でした。この見積もりに関しては現在も試行錯誤を続けているのですが、1on1の機会に相談したり同期と話し合ったりする中で、短いスパンで見積もりを直し、タスクを適切な粒度で細分化することがコツであることが分かってきました。
コミュニケーションの重要性
言い尽くされていることではありますが、入社後に改めて実感したのはチーム内で密にコミュニケーションをとることの大切さです。確認や相談を密に行うことで、ある程度作業が進んだ時点で勘違いが発覚->手戻りが発生するといった事態を減らすことができます。メンターの方に毎朝、またマネージャーの方に週1回1on1の時間を設けて頂いているのですが、これらは雑談の場に加えて困っていることや「わざわざslackで聞くほどではないけど気になっていること」を気軽に聞ける機会になっています。
いわゆる”15分ルール”*6として知られているように、仕事をする上で「自分で少し調べて考えて分からないことがあった時はとにかく人に聞く」ことを強く意識しているのですが、こうした日々のコミュニケーションによって気軽にslackで質問したり通話を繋いだりできる雰囲気が作れているように感じます。
また、社内ではslackのtimesチャンネルという個人チャンネルでとりとめのないことを呟く文化があり、これも（特にリモートワーク下において）非常に良い文化になっています。「〇〇がエラーになって困った」といったことを呟くと親切な方が助けてくれますし、なんとなく思いついたアイディアや簡単な分析結果を共有する場にもなっています。
1つのアプリを運用していくことのすごさ
入社後に非常に印象的だったのは、1つのアプリを運用に関わっている人の多さです。グノシーというアプリ1つとっても、エンジニア、営業、マーケティングなど多くのチームが協働することで動いており、GTLという1つの組織の中でもR&D、BI、Ads ML、DRE、そして私の所属するMedia MLチームなど、様々なチームがグノシーアプリを良いものにするために動いています。大きな企業ではこういった全体像を見ることは簡単ではないと思うので、こうした「どこで、誰が、どんな仕事をすることで1つのアプリが運用されているのか」が見えるのはGunosyの良いところだと思います。
研究で学んだことが生きる場
「大学で学んだことは社会では役に立たない」といった言説は今でも目にすることがありますが、個人的には大学や大学院で特に研究を通して身に付けた力が業務に非常に役に立っていると感じています。もちろん第一に業務内容が大学院で専攻したテーマに直結しているということがありますが、それと同じかそれ以上に「何が問題になっているのか、なぜそれが問題なのかを考える力」や「過去の知見を理解してまとめる力」、「適切に背景を補って過不足ない情報を共有する力」などメタなスキルがとても役に立っています。
まだ入社してからの日は浅いものの、入社後に身についたと思うスキルもいくつかあります。例えばチームで開発を進める上でのコーディングの基本原則や、上述したような時間的なコストの意識、タスク見積もりなどがそれにあたります。今後も自分がどういったスキルを身に付けられたのかを定期的に確認することができるよう、少しだけ高い視座を持って日々の業務に取り組んでいきたいです。
第一回目の新卒ブログは以上になります。次回もぜひご期待ください！
