チームで、NewsPicksの推薦システム・データ基盤まわりの開発に取り組んでいます。本記事は、私が2022年8月から同組織に入社して現在までの約1年間の長期インターン活動を経て、参加して良かったことと苦戦したことをまとめたものです。企業での長期インターンに興味がある方に向けて、本記事の内容を共有できればと想定しています。はじめにタイトルの通り、私は非情報系なのに推薦システムを独学で勉強していた博士学生です(実は本記事の執筆期間中に博士学生ではなくなりました...!)。博士課程への入学時期に偶然Kaggleをきっかけに推薦システムという分野と出会い、興味を持って論文読んで実装してブログに上げて...みたいな活動を趣味で行っていました。半年ほど経過した後「推薦システムを趣味ではなく仕事として関わりたい」と思い、長期インターン先を探し始めました。様々な理由(私が地方在住であること、非情報系の学生で実務経験がほぼ無いこと、組織が機械学習や推薦システムに注力しない時期であることなど)でなかなか受け入れ先の企業を見つけることができませんでした。その時にふと、かつて他社のポッドキャスト番組で耳にしたユーザベースという企業を思い出し、Wantedlyでユーザベースの求人を必死に探しました。機械学習エンジニアの募集はなく、唯一見つけたグループ会社であるアルファドライブのソフトウェアエンジニアの募集に突撃しました。そこでアルファドライブCTOの赤澤さんとのカジュアル面談にて、私の推薦システムに関する過去の取り組みと挑戦したい旨をダメ元でお喋りしたところ、「残念ながらうちでは募集してないけどNewsPicksならもしかすると...!」という感じで、NewsPicksの技術フェローである高山さんとデータサイエンティストの北内さんに繋いでくださりました。お二人との面談を通して、本当に有難いことに長期インターンとして推薦システムに関わる機会をいただきました。入社直後は、まずNewsPicksでの開発手順に慣れることも兼ねて、データ基盤関連の小さめの移行タスクに取り組みました。チームの先輩方にアドバイスをもらいながらタスクを進めつつ、ソフトウェア開発における基礎的な知識を学び始めました。その後1年ほど入社から約1ヶ月後からは、NewsPicksの記事推薦システム基盤の刷新タスクに取り組みました。ここでいう「基盤の刷新」は、機械学習等による推薦ロジックの改善ではなく、記事推薦に関わる処理の流れの刷新や、機械学習モデルのオンライン学習を動かすシステムの設計の刷新を示しています。本プロジェクトは私が入社する前からチームでコツコツと進めていたプロジェクトです。チームの先輩方と設計・開発方針を適宜相談しながら進め、2023年7月頃に無事に完了しました。以前よりもレガシー度合いとAWSリソースコストが低下するとともに、A/Bテストがしやすくなり、今後の推薦ロジック改善のイテレーションをより高速に回せるような推薦システム基盤に移行することができました。直近2ヶ月ほど現在は、主に記事推薦システムで稼働している機械学習モデルの改善に取り組んでいます。機械学習モデルのオフライン評価方法の改善や、プッシュ通知関連の施策の有効性の評価にも携わっています。約1年がかりで推薦システム基盤を改善できたので、これから推薦ロジックをチームの方と一緒に改善していくぞ!という気持ちです...!長期インターンに参加して良かったことここでは、私が長期インターンを通して成長できたこと、楽しかったこと等を紹介していきます!ソフトウェアエンジニアリングに関する成長機会がたくさんあった私は本インターンをするまで、研究活動で自分一人のためのコードしか書いてきておりませんでした。その結果、かなり読みづらいコードを書いてしまっており、チームの方には「チーム開発/個人開発、研究者/エンジニアに関わらず、コードを書く人は全員、まずリーダブルなコードを書く意識を持った方がよい」と教わりました。NewsPicksでの開発経験を通して、チームの先輩方からアドバイスをもらったり技術書を読んだりしながら、以下のようなソフトウェア開発における基礎的な意識を持つことができるようになりました。Kit(CDK)を用いて管理しているため、自分でCDKを書いてリソースを追加して開発する、という経験ができました。自分が書いたコードを本番リリース後、推薦機能関連でエラー通知が大量に飛んできた際の血の気が引く感覚は、実プロダクトの開発に携わったこその貴重な経験だと思います。サーバサイド、etc.)に専門性を持ったメンバーが揃っています。この特色は一長一短あると思うのですが、私にとっては非常に有益であり、そのお陰で推薦システムに関わる様々な技術領域の開発業務に携わる機会をいただけました!私は元々、機械学習のアルゴリズムに関する論文を読んでオフライン環境で実装する、という推薦システムにおける一部の経験しか持っていませんでした。実プロダクト上で稼働している推薦システムを開発・運用する上では、機械学習モデルを継続的にアップデートするために学習データのパイプラインを用意したり、レイテンシー等を考慮した推論サーバを開発したり、A/Bテストしやすい推薦システム基盤を設計したり、様々な技術領域が関わっています。キャリアの軸が定まっていない私の場合は、インターンでの業務を通して推薦システムに関わるたくさんの技術領域に携わることができ、自分が今後どんな分野で専門性を高めていきたいか考えるきっかけを得ることができました!インターンでも挑戦機会をもらえたこれは要するに、インターンか社員かという条件で挑戦する機会を失ったりはしない、ということで、インターンから見たNewsPicks開発組織の魅力の一つなのかなと思っています:)入社当初は「インターンの身分だから意見を出すのを控えめにしないと...」と思っていましたが、社員の方から「自分がインターンだから」という理由で遠慮する必要はまったくないよというアドバイスをいただきました。Valuesの1つに「迷ったら挑戦する道を選ぶ」「自由主義で行こう」「異能は才能」等があることからも、組織全体的な風潮なんだと思います。実際にチーム内でも挑戦を認めてくれる雰囲気があり、「この技術領域を勉強しているので、プロダクトのこの領域の改善に取り組みたい」という意思を明示的にチームリーダーに示すことができれば、その挑戦を応援してもらえる文化があるように思います。論文読んだシリーズ」というブログ連載を行っており、最近は特に機械学習モデルのオフライン評価に焦点を当てて調べていたことから、チームリーダーと相談し、関連する仕事を担当させてもらう機会をいただきました!インターンでもオーナーシップを持って挑戦できるのは、良かったことの1つだと思います!技術が好きな人が多く勉強会が盛んで楽しかったNewsPicksの開発組織では、AI・機械学習論文読み会やKotlin知見共有会など、様々な勉強会が盛んに行われています。私もいくつか参加しているのですが、皆さん技術が好きそうで楽しく発表してる雰囲気なので、非常に心地良かったです:)また上述の「インターンでも挑戦機会をもらえた」とも関連しているのですが、インターンの私も「発表したい」旨を伝えれば発表機会をもらえて、何度か発表させていただきました!まだ技術&経験ガリガリな自分のお喋りを、技術&経験マッチョな方たちが聞いてくれてコメントもくれる貴重な機会なので非常に感謝しています...!!morinota.quarto.pubmorinota.quarto.pub長期インターンで苦戦したことここでは、私が長期インターを通して苦戦したことと、それに対してどう対応を試みているかを紹介します!リモートでのインターン私は名古屋在住のため、基本的にはフルリモートで就業する形式でした。してもオフィスでの就業よりも私のような新人のキャッチアップが難しかったり、開発効率が低くなってしまう恐れがありました。Loud)一つ目は「Slackの作業スレッドで独り言を呟きまくる」ことです。Data/Algorithmチームでは、各メンバーが毎日の作業経過を共有するために、Slackに作業スレッドなるものを作っています。私の場合は、自分が今どんな作業をしているか、どんなことが分からず調べているか、を積極的に独り言のように作業スレッドに高い頻度で書き込むことを意識しました。チームメンバーの方々は作業スレッドを見れば、私の状況を把握することができ、助けられそうなことがあればコメントしてくれます。30分考えてわからなそうなことはすぐに口頭で質問しにいく」ことです。これは当たり前のことかもしれないのですが、私が働く上で非常に意識していることです。(私の場合は意識しないとすぐにできなくなってしまうので...!)NewsPicks開発組織ではGatherというリモートオフィスツールを使用しているため、いつでもチームメンバーに声をかけにいくことができます。よって分からないことがあればすぐに声をかけ質問することができます。私は独学で推薦システムやプログラミングを勉強していたこともあり、何でもかんでも自分で調べて解決を試みる癖がありました。調べるよりも聞く方が早く解決するケースも多々あるのですが、質問しにいくことで他のメンバーの開発時間が削れてしまうことへの申し訳なさや、「こんなことも知らないの?」と呆れられてしまうことを恐れてしまい、なかなか行動に移せませんでした。”許可をとるより謝罪せよ”の意識を持つ三つ目は「”許可をとるより謝罪せよ”の意識を持つ」ことです。これはメンターの方との1on1で教えてもらった意識なのですが、要するに許可をとってから行動するよりも先に行動してもし不都合があれば謝る方が良い、という考え方です。個人的には、前者よりも後者の方が手順が少なくて済むという事と、「やってみていいですか?」よりも「やってみました!」の方がより積極的に動ける気がしているので意識しています。この意識が有効か否かはケースバイケースです。失敗した際のリスクや影響範囲が大きいケースではおそらく効果的ではありません。一方で、例えば口頭で質問しに行ったり、リファクタタスクのプルリクエストを作ったり、リスクが大きくないケースではこの意識は有効だと考えています。圧倒的な開発・運用経験の不足で意思決定が難しいこれは、まさに現在も直面している課題になります。しやすい機械学習システムってどんな設計にすべきだろう?」や「埋め込みベクトル等の特徴量をどの形式で保存・管理すると運用しやすいだろう?」等の相談をする機会があったのですが、私にはどの方法がbetterなのかの自分の考えを持てず、意思決定に貢献できませんでした。(予想するだけならできそうだが、その予想の確度はかなり低い感じ...!)対応として、機械学習システムのデザインパターンの技術書や他社のMLOpsの事例の論文等を読んで有効そうなフレームワークを学ぶように試みています。チームの長期インターンで取り組んだこと、参加して良かったこと、苦戦したことをまとめました。私は現在、自分が興味を持って熱中している推薦システムに関して、プロの専門家の皆さんと一緒に取り組み、自分が成長したい方向に成長することができています。その業務を通じて、チームや組織に(ひいてはユーザに)貢献できて、報酬を貰える、というとても素敵な生活ができていることを非常に嬉しく思っています。reserved.引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。