コードは目的ではなく手段。AI機械学習チームで磨かれた「使い分け」の思考力

エムスリーには、新卒で入社したエンジニアでも早い段階から大きな仕事を任される文化があります。実装だけを担当するのではなく、ユーザーや事業の課題に向き合いながら、何を作るべきか、どう進めるべきかを自ら考え、提案し、プロダクトを前に進めていくことが求められます。責任も伴いますが、その分得られる経験の幅は広く、多くのエンジニアが想像以上のスピードで成長していきます。

新卒でエムスリーに入社して6年目、入社3年目からチームリーダーを務める北川は、学生時代に始めたOSS開発を今も趣味として続けながら、仕事では「プログラミングは目的ではなく手段」という考え方に至ったといいます。

なぜ世界で使われるOSSのコミッターでありながら、エムスリーでチームリーダーという選択をするのか。そして、6年間で最も成長したと感じることは何か。リアルな仕事の中身と、これからのキャリアについて聞きました。

コードを書くことが楽しかった。OSSとISUCONに熱中した学生時代

学生時代はどのようなことをされていたんですか？

京都出身で、大学院までずっと京都で過ごしました。現在はAI・機械学習チームのチームリーダーをしていますが、学生時代はとにかくプログラミングが好きで、コードを書くことそのものを楽しんでいました。

大学3年生の頃からWeb開発のアルバイトを始め、ISUCONに参加したり、大学院ではOSS開発に取り組んだりしていました。今でもOSS開発は趣味として続けています。エムスリーで公開している「gokart」や、個人で開発しているBigQuery向けのLanguage Serverなどもその一つです。当時は課題解決というよりも、純粋にコードを書くことそのものが楽しかった時期でした。

エンジニアを目指したきっかけを教えてください

プログラミングに興味を持ったというより、大学に入るまで触れる環境がなかったことのほうが大きいです。親がコンピュータに強い家庭ではなかったので、インターネットに触れる機会がなく、高校まではパソコンもスマートフォンも持っていませんでした。

大学では情報系の学部を選びました。プログラミングに触れてみたかったことと、学問として学ぶのであれば、コンピュータをよく分かっていない親も協力してくれるだろうと思ったからです。

大学1年生の授業で初めてプログラミングに触れ、JavaでHello Worldを表示したときに、とても面白いと感じました。

特に印象的だったのは、目の前で表示されるHello Worldと、世の中にあるゲームやOS、Webサービスがまったく結びつかなかったことです。たった数行のコードを書いているだけなのに、その延長線上に巨大なソフトウェアの世界が広がっている。その距離感に強く惹かれました。

どうやって動いているのかを知りたい。なぜ動くのかを理解したい。そうした好奇心から学び続けるうちに、コンピュータサイエンスそのものの面白さに夢中になっていきました。

ISUCONやOSSにはどのように取り組まれていたんですか？

大学3年生の頃、友人の紹介でWeb開発のアルバイトを始め、その流れでISUCONに出会いました。友人3人で軽い気持ちで参加したところ、初参加ながら本選に進出することができ、それをきっかけに性能改善やボトルネックを見つける面白さにのめり込んでいきました。

大学生の間は学生枠で参加し、大学院進学後は一般枠に切り替わったことで、本選に進めない時期もありました。それでも挑戦を続け、社会人になった今でも大学時代の友人たちと参加しています。2023年には入賞することもできました。

大学院ではOSS開発にも本格的に取り組むようになりました。最初は自分で作ったツールを小さく公開する程度でしたが、徐々にオープンソースとして公開し、改善を重ねていくようになりました。今でもOSS開発は続いています。普段の開発や趣味のコーディングの中で不便だと感じたものを自分で作り、そのままOSSとして公開するスタイルは学生時代から変わっていません。

当時の自分にとってプログラミングは完全に「目的」と考えていました。その感覚は入社後に大きく変わっていきました。

ベンチャーと大企業、両方の「いいところ」を求めて

就職活動ではどのような軸で会社を見ていましたか？

就職活動ではベンチャーとメガベンチャーの両方を見ていました。ベンチャーの「全部自分たちでやる」という働き方には魅力を感じていました。しかし新卒でいきなりベンチャーに飛び込んだ場合に、自分に合わなかったらどうしようという不安もありました。

そのため、働き方はベンチャーに近い一方で、会社としての安定感もある環境はないかという視点で企業を見ていました。実際には大手IT企業や総合系のテック企業なども含め、幅広く検討していました。

会社選びで重視していたのは一緒に働く人です。いわゆる「部署ガチャ」「上司ガチャ」は避けたいと思っていました。どんな仕事をするかと同じくらい、誰と働くかは重要だと考えていたため、実際に働いている人に触れられるインターンには積極的に参加していました。

エムスリーとの出会いについて教えてください

きっかけは逆求人イベントでした。そこで当時のVPoEだった山崎さんと話しました。正直、その時点ではエムスリーという会社をほとんど知りませんでした。

しかし話を聞く中で、エンジニアリングが強い人が前に出ていることや、安定感がありながらも挑戦できる環境があることに興味を持ち、インターンに参加することにしました。

インターンではどのようなことが印象に残りましたか？

一番印象的だったのは、エンジニアが当たり前のようにビジネスの話をしていたことです。他社のインターンでは技術の話が中心になることが多かったのですが、エムスリーでは「このプロダクトはどれくらい利益を生むのか」「どうすればもっと価値を届けられるのか」といった議論が自然に行われていました。

学生だった自分にとっては、とても新鮮な体験でした。プログラミングは自分でも学び続けられますし、ISUCONのような場でも鍛えられます。一方で、ビジネスを学べる環境は限られています。働くのであれば、技術だけでなくビジネスも学びたいと強く思うようになりました。

もう一つ印象的だったのは裁量の大きさです。インターン中に別チームのアーキテクチャについて「こうした方が良いのではないか」とメンターに話したところ、その内容が実際に別チームへ共有され、会議にも参加させてもらうことになりました。

「裁量がある」と言う会社は多いですが、それを実際に体験できたのはエムスリーが初めてでした。この経験が決め手となり、2019年12月に内定を承諾しました。

結果として、ベンチャーのような裁量とスピード感と、大企業としての安定感の両方を併せ持つ、自分が就職活動で探していた環境を見つけられたなと思います。

ギャップがないことがギャップだった

実際に入社してみて、ギャップはありましたか？

一番驚いたのは、インターンの時とほとんどギャップがなかったことです。インターンの段階では、さすがに少しは外向きの顔を見せているのではないかと思っていました。しかし実際に入社してみると、インターンで見ていた雰囲気や文化がそのままでした。

むしろ、「ギャップがないこと」自体が一番のギャップだったかもしれません。インターン中に感じていた裁量の大きさや現場の空気感は、入社後も変わりませんでした。

また、インターン中は制度についてはシンプルだと聞いていましたが、想像以上に整っていて、その点は良い意味で予想が外れました。

入社後、特に印象的だったことはありますか？

意思決定のスピードです。経営層とのミーティングが隔週ペースで行われ、そこで決まった内容がすぐに実装され、次のミーティングではその結果を持ち寄るというサイクルが回っています。入社当初は、このスピード感にかなり驚きました。

もちろん大変な面もあります。短期間で成果を出しながら次の改善を考え続ける必要があり、常に前に進み続けなければいけません。

振り返ると、この文化はAIプロダクトの開発とも非常に相性が良いと感じています。AIを組み込んだプロダクト開発では、長期間かけて完璧なモデルを作り込むよりも、まず世の中に出してデータを集め、改善を繰り返していく方が成果につながることが多いからです。

オフライン検証を重ねるよりも、仮説を形にし、実際のユーザーの反応を見ながら改善していく。そのサイクルを自然と回せる環境は、AI・機械学習チームにとって大きな強みだと思います。

レコメンド開発と、450本のジョブを支える運用

現在はどのような業務を担当しているんですか？

AI・機械学習チームのチームリーダーとして、大きく2つの領域を担当しています。

1つ目は機械学習モデルの開発です。m3.com のトップページに表示される医師向けニュースや臨床記事、医師同士が知見を共有するQ&Aサービスなど、さまざまなレコメンド機能を開発しています。また、広告などのコンバージョン予測なども担当しており、ロジック設計からAPI開発まで一貫して携わっています。

AI・機械学習チームという名前から、機械学習モデルの開発だけをイメージされることもありますが、実際にはそれだけではありません。

もう1つの大きな役割が、機械学習基盤の運用です。現在は16人体制ですが、チームが担当しているプロダクトは50〜60個ほどあり、それらを支えるために約450本の定期実行ジョブが日々動いています。

50〜60のプロダクト、450本のジョブを支えるのは大変そうですね

かなり大変です（笑）。機械学習のジョブはアプリケーション単体で完結するものではなく、外部サービスや外部サイトと連携するケースも多いため、自分たちのコードに問題がなくても外部要因で失敗することがあります。

実際、1日に大量のジョブが失敗することもあります。そのジョブを、失敗直後に復帰させるのが、プロの仕事です。そのため重要なのは「絶対に落ちないシステムを作ること」ではありません。もちろん障害を減らす努力はしますが、現実的にはすべての障害を防ぐことは難しいからです。

むしろ大切なのは「落ちても大丈夫な状態を作ること」です。例えば、ジョブが失敗してもサービスへの影響を最小限に抑える設計にすること、異常が起きたときにすぐ気づける仕組みを整えること、そして複数の障害が同時に発生したときにどれを優先して対応すべきか判断できる状態を作ることなどが挙げられます。

1日30本近く失敗するジョブがある中で、本当に対応すべきものを見極めることも重要です。すべてに同じ優先度で向き合うのではなく、事業やユーザーへの影響を踏まえて判断できる状態を意識しています。

機械学習というとモデル開発やアルゴリズムに目が向きがちですが、実際にサービスとして価値を届けるためには、安定して動き続ける運用基盤も欠かせません。モデル開発と運用の両方に関われる点に、AI・機械学習チームならではの面白さを感じています。

学生時代にISUCONで学んだ性能改善やシステム運用の考え方が、今の仕事にもつながっていると感じています。

あえてAIを使わない。「ハンマーを持つと全部釘に見える」への危機感

AI・機械学習チームでも、あえてAIを使わない場面が多いそうですね

AI・機械学習チームという名前なので、何でもAIで解決していると思われることもありますが、実際にはそうではありません。

サービスによっては、AIが出した結果について「なぜそうなったのか」が分かりやすい方が適しているケースがあります。特に、ユーザーや運営側がフィードバックを返しながら改善していく仕組みでは、AIによる複雑な判断よりもシンプルなルールベースの仕組みの方がうまく機能することも少なくありません。

そのため、AIを使うべき場面では使い、使わない方が良い場面では使わない。その判断自体が、AI・機械学習チームの重要な役割だと思っています。

最近は生成AIの進化もあり、何でもAIで解決しようとする流れがあります。その状況を見ていると「ハンマーを持つと何でも釘に見える」という言葉を思い出します。強力な技術を手にしたことで、本来は別の方法で解決すべき課題までAIで解こうとしてしまう。そうした罠を避けるためにも、AIを使うこと自体を目的にしないことが大切だと考えています。

AI時代において、エンジニアに求められる力は変わってきていますか？

抽象的なレベルでは、大きくは変わっていないと思っています。学生時代に取り組んでいたISUCONであれば、高速化という目的に向かって最適化すればよかったからです。

一方で、仕事においてはシステムを速くすることやAIを使うこと自体が目的ではなく、最終的には事業が成長することやユーザーに価値を届けることが目的になります。この違いは入社してから強く実感し、今の仕事のベースにもなっています。

だからこそ重要なのは、どんな技術が登場しても「本当に解くべき課題は何か」を見極めることだと思います。AIを使うかどうかも含めて、最適な手段を選べるかどうかが問われるようになってきています。

その上で、AIが進化しても変わらないのは基礎的なエンジニアリング力です。生成されたコードを正しく評価し、どこにリスクがあるのかを見極める力は、これからも必要だと考えています。

20年もののレコメンドシステムで、AIではなく分析が成果を出した話

印象に残っている仕事を教えてください

特に印象に残っているのは、20年近く運用されているシステムのレコメンド改善です。長年運用されてきたシステムだったこともあり、レコメンドがどのような仕組みで動いているのかを完全に把握している人がほとんどいない状態でした。

さらに、システムそのものは別チームが担当していたため、AI・機械学習チームだけで完結する仕事ではありませんでした。コンテンツ配信を担当するチームと連携しながら、どのようなロジックでコンテンツを出し分けるべきかを設計し、実装していく必要がありました。

技術的な難しさもありましたが、それ以上にシステム全体を理解しながら複数チームと協力して進めることが難しかったですね。

どのように課題を解決していったのでしょうか？

当初は、レコメンドの精度やアルゴリズムに課題があるのではないかと考えていました。しかし実際にデータを分析していくと、想定とは違う事実が見えてきました。

クリックされない原因を調べる中で、そもそもコンテンツ自体が表示されていないケースが一定数存在していたんです。

さらに詳細を確認すると、表示速度の遅いコンテンツが読み込み途中で離脱されてしまい、ユーザーの画面に表示されていないケースがありました。つまり、レコメンドの精度以前に、配信そのものに課題があったということになります。

そこで実施したのは、AIモデルの改善ではありませんでした。表示速度を計測し、表示が遅いコンテンツを除外するという、非常にシンプルなロジックの導入です。その結果、コンテンツの表示数は約2％向上し、収益改善にもつながりました。

AI・機械学習チームの仕事ということもあり、外から見るとAIを使った改善に見えるかもしれません。しかし実際には、地道にデータを分析し、ボトルネックを特定して改善した結果でした。

この経験から学んだことはありますか？

この仕事は、前の章で話した「AIを使うことが目的ではない」という考え方を象徴する経験だったと思います。もし最初からAIで解決しようとしていたら、本当の課題にはたどり着けなかったかもしれません。

大切なのは、AIを使うことではなく、何が課題なのかを正しく理解することです。その上で、課題解決に最も適した手段を選ぶことだと考えています。

この経験を通じて、技術そのものではなく、事業やユーザーの課題に向き合うことの重要性を改めて実感しました。

6年間で最も成長したのは「プログラミングは手段の一つ」という理解

入社から6年間で、最も成長したと感じる部分は何ですか？

一番大きいのは、プログラミングとの向き合い方が変わったことだと思います。

学生時代の自分にとって、プログラミングは完全に「目的」でした。コードを書くこと自体が楽しく、何かを作ることそのものに価値を感じていました。OSS開発やISUCONに夢中になっていたのも、その延長線上だったと思います。当時は、プログラミングで解決できないことはあまりないと考えていました。

もちろん今でもプログラミングは好きです。ただ、仕事をする中で、それだけでは解決できない課題が多くあることを知りました。例えば、システムの問題だと思っていたものが実は運用の問題だったり、技術的な改善よりも業務フローを見直した方が大きな成果につながるケースもあります。

さまざまなプロダクトや事業に関わる中で、課題解決の手段はプログラミングだけではないと実感するようになりました。

今は、プログラミングは数ある選択肢の一つだと考えています。課題に直面したときに、まずコードを書くのではなく、「本当に解くべき課題は何か」「どの手段が最も効果的か」を考えるようになりました。

学生時代はコードを書くこと自体が目的でしたが、今は事業やユーザーの課題を解決することが目的になっています。その意味では、この6年間で最も大きく変わったのは技術力そのものではなく、物事の捉え方かもしれません。

趣味のOSS開発は今も続けているんですか？

はい。そこは全く変わっていません。むしろ、仕事と趣味でプログラミングの位置づけを使い分けられるようになった感覚があります。

仕事ではプログラミングは課題解決のための手段ですが、OSS開発では今でもプログラミングそのものが目的です。

普段の開発や趣味のコーディングの中で不便だと感じたものを作り、そのままOSSとして公開しています。OSS開発のモチベーションも、人のためというよりは自分のために近い感覚です。自分が欲しいものを作った結果として、それが他の人にも使われる形になっています。

最近は生成AIのおかげで個人開発もしやすくなりました。実装したいアイデアがあっても時間が足りずに諦めることがありましたが、まずAIを使ってプロトタイプを作り、良さそうであれば磨き込んでいくという進め方ができるようになっています。

手札を増やし続けたい。いくつになっても学び続けるエンジニアへ

入社3年目でチームリーダーになられていますが、今後はどのようなことに挑戦していきたいですか？

チームリーダーになったのは入社3年目の1月でした。新卒入社から2年9か月ほどだったので、比較的早いタイミングだったと思います。ただ、個人的にはリーダーになったからといって、仕事の本質が大きく変わった感覚はありません。

当時は「自分にできるだろうか」という不安もありましたが、周囲から言われていた通り、実際にはやっている仕事に後から「チームリーダー」というラベルが付いたような感覚に近かったですね。

今も、事業やユーザーの課題を見ながら最適な手段を考えるという姿勢は変わっていません。その上で、これからは自分の持ち札をもっと増やしていきたいと思っています。

AIという領域については、この数年間でかなり経験を積むことができました。ただ、世の中にはまだ自分が十分に理解できていない領域も多くあります。

最近特に興味を持っているのはデザインです。デザイナーと一緒に仕事をする機会が増える中で、自分には思いつかないようなアウトプットを短時間で形にしていく姿を見て、その専門性の高さに驚かされます。

AI時代だからこそ、エンジニアリングだけでなく、隣接する領域への理解を深めることが重要になると感じています。自分が持っていない手札を増やしていくことで、より良い意思決定ができるようになりたいですね。

直近で力を入れていることはありますか？

Pythonの型付けに力を入れています。実行前にコードの問題を検知しやすくする取り組みで、生成AIを活用した開発が増えている今だからこそ重要性が高まっていると感じています。

AIによってコードを書くスピードは上がる一方で、品質をどう担保するかという課題も出てきています。開発スピードと品質の両立を実現するために、型付けの改善やOSSへのコントリビューションに取り組んでいます。

具体的には、Spotifyが開発しているOSS「Luigi」に15件ほどプルリクエストを送っています。他にもさまざまなOSSプロジェクトにコントリビュートしており、採用されたものもあれば、残念ながら採用されなかったものもあります。

学生時代から続けてきたOSS活動は、今でも自分にとって大切な学びの場になっています。

最後に、一緒に働きたい方へメッセージをお願いします

私自身、入社前はプログラミングが好きなエンジニアでしたが、入社後は技術だけでなく、事業やユーザー価値について考える機会を数多く経験してきました。その結果として、技術を見る視点も大きく変わったと思います。

個人的には、いくつになっても学び続けるエンジニアでいたいと思っています。新しい技術が出てきたときに、最初から否定するのではなく、その良いところと悪いところを理解した上で使いこなせる人でありたい。その姿勢はこれからも大切にしていきたいですね。

技術そのものを楽しみながら、ビジネスやユーザー価値にも向き合っていきたい。そんな人にとって、この環境は挑戦しがいのある場所だと思います。