BLOG

【インタビュー連載】機械学習チームを率いるダビド・クルナポ, Ph.D. – 研究成果から製品開発へのプロセスとは

Interviews

コージェントラボ、機械学習エンジニアチームを率いるDavid Cournapeau(ダビド・クルナポ)に話を聞くインタビュー連載、第3回です。前回のインタビューでは独自の研究から最終的な製品化に至る製品開発ラインと、その過程で生じる課題について紹介しました。今回のトピックは、彼自身が精通した分野であり、長年にわたり研究とエンジニアリングの接点として関わってきた分野です。

 

トピック2: 研究成果から製品開発への展開

Q: 研究者とエンジニアそれぞれの強みと弱み、また両者の働き方の違いについて教えてください。

研究者や科学者は、ソフトウェアを開発する際、ソフトウェア自体に興味を示しません。彼らにとってソフトウェアは、最終目標ではなく、目標を達成するための手段に過ぎません。彼らが重要視するのはソフトウェアのアウトプットであり、理想のアウトプットを得るためには、何であれいつでも変更したいと考えています。ソフトウェアが完成してしまえば、そこに興味はなくなります。同様に、その製品を使った作業にもあまり関心を持たない場合が多いのです。

一方、エンジニアにとってソフトウェアは生き物です。お客様がソフトウェアを使っている限り、長期間のメンテナンスが必要と考えています。そのため、ソフトウェアを制御し、その動きを制限したいと考えます。研究者とは真逆の考え方と言えるでしょう。

例えば、想像してみてください。毎日の通勤に車を使うとしたら、普通車を使いますか?それともF1カーを使いますか?どちらも同じ車ですが、その用途はまったく違っています。プリウスは大量生産されており、一般の人が簡単に運転できます。一方、F1カーの場合、非常に速いスピードが出せますが、メンテナンスには50人ほどが必要ですし、世界レベルのドライバーが運転しなければなりません。F1カーで通勤自体、意味をなさないと言っていいでしょう。

 

Q: ご自身の経験から、その点でどのような課題があるとお考えですか。

こっちのアプローチが正しくて、もう一つが間違っているという話ではなく、根本的に、研究者とエンジニアは目指すゴールが違うのです。多くの場合、技術的な経験を持たない人は、この点に気がつきません。研究者自身もそれに気づかず、なぜエンジニアは自分たちのやり方に横槍を入れるんだ、と思ってしまうこともあります。このゴールの違いを管理していく必要があると思います。

もちろん、製品開発には、研究者からのインプットが重要です。研究を前進させるためには、製品からもインプットを得られることが望ましいでしょう。しかし、研究と製品開発の時間軸は違います。製品開発は、特に弊社は小さい会社ですので、1日単位で進めています。新機能のスケジュールは、月または週単位です。一方、研究はもっと長い時間単位で進めます。この時間軸の違いを管理してくことが、もう一つ、大きな課題だと思います。

 

Q: こうした課題をどのように乗り越え、研究を製品開発につなげる、またその逆で製品から研究にフィードバックするといったことを可能にしてきたのでしょうか。

研究者とエンジニアが密接に協力できるように取り組んできました。機械学習エンジニアチームは研究者とは物理的に近いところにはいないため、アイディアを交換できるフォーラムを作りました。例えば、エンジニアも参加できる論文発表会を研究者が企画しています。また、機械学習・エンジニアチームの中にも、深層学習を十分に理解しているスタッフを擁することで、必要なセレンディピテ(予想外のものを発見すること)の創出を図っています。

機械学習のエンジニアに対しても、製品に直接関係ない、定義の緩いトピックに取り組むようお願いすることがあります。その場合は、研究者と一緒に作業をしてもらいます。例えば、現在ある研究プロジェクトでは、マシーンラーニング・エンジニア2名が研究者1名と直接協力して作業しています。週に数回ミーティングを実施し、様々な研究や論文に取り組み、密接な議論を重ねています。

またまだ改善しなければならない点はあるのですが、具体的なニーズがある場合には、研究者を製品開発に参加させるという取り組みも行っています。例えば、製品に関してAIや深層学習の側面で拡張が必要な場合、エンジニアよりも深く考えられる研究者をチームに参加させることもあります。

 

Q: コージェントラボでの具体的な製品開発例を教えてください。

弊社の主力製品は、TSF、Tegaki、Kaidokuの3つです。私は主に最初の2製品を担当しています。TSFは、あるクライアント向けの実証実験から始まりました。私が入社する前のことですが、市場データを使って東京証券取引所の取引量を予測できるよう、リサーチエンジニア1名がクライアントと取り組んだ事例です。クライアントからいくつかデータをもらい、クライアントがすでに使っていたものよりも精度の高い予測ができる仕組みを開発するよう依頼されました。その取り組みは成功し、その後、毎日使える製品またはWebサービスの開発を依頼されました。

私が入社したのはそういった時期でした。自社マシーンのオフラインデータで作業する時代ではもはやなく、東京証券取引所に接続し、リアルタイムにデータを受け取るようになっていました。私のほか、そのモデルの一部を作ったリサーチエンジニアと、さらにもう一人エンジニアが加わり、3、4ヶ月間に渡り取り組みました。そのプロジェクトではその段階で、モデリングよりもエンジニアリングの方が大きな課題を抱えていました。

一方Tegakiは、私が入社した時に立ち上がったばかりで、TSFよりも大規模なプロジェクトでした。その当時、少人数のチームとして研究者とエンジニアが一緒に作業にあたっていましたが、あまりうまくいっていませんでした。私自身、何回も目にしてきたパターンでした。また機械学習エンジニアもまだいなかったことから、深層学習を十分理解し、かつ研究者と深い議論ができるソフトウェア・エンジニアのチームを別に作ることにしたのです。

もう一つ、典型的とも言える課題がありました。コードやAIの多くは、もともとは研究者が書いたものであり、その内容を理解できるのは研究者だけだったのです。そこで、他の人もモデルを理解できるよう、機械学習エンジニアに依頼して、コードの構造を理解しやすい内容に変えてもらい、さらに修正や改善が可能なものにしてもらったのです。

 

Q: ご自身の経験から、新製品開発の理想的なプロセスといったものはありますか。または、AIや機械学習製品の使いやすさ、有益性の向上において備えるべき要素などありますか。

まず、これ、というプロセスが一つあるわけではありません。Tegaki、TSF、Kaidokuの開発プロセスはそれぞれかなり違っていました。TSFはビジネス主導でしたし、Kaidokuはそれと真逆で、研究主導でした。一方、Tegakiの場合は、両方の側面があったと思います。

一般的に、小さな会社で複数の製品を展開しようとする場合には、機会を敏感に捉える必要があると思います。プロセスが一つだけではだめなのです。製品の種類に関して言えば、AI関連の製品だけを構築するのは危険だと私は考えます。技術面から始めて、ビジネスの価値があるものを作ろうとするのはリスクがあります。多くの人、特に学術界から最近ビジネス界に入ってきた人たちの多くが、その性質がゆえに犯す間違いです。

これまでのやり方では修正が困難なビジネス上の問題を具体的に考え、それらを解決するには深層学習や機械学習をどう使えば良いだろう、と考える方が、より面白くなると思います。それが解明できれば、ビジネスが成立します。最終的には、AIそのものよりもその価値の提案が重要になるのです。

多くの人が、AIは素晴らしいもの、というイメージを持っていると思います。しかし、想像されているような多くのことを実現するほど、強力なものではまだないのです。具体的に応用するチャンスはたくさんあります。やや陳腐ですが良い例として衛星から送られてくる画像の分析があります。気象パターンの理解を深めたり、ドラッグの栽培を自動的に検出したりするには、どのように分析すれば良いのでしょうか。この分析は既に行われていますが、効率良く進められていないのが現状です。そこにAIを導入すれば、システム的な分析が可能になります。システム的な側面は非常に重要で、そこがまさに、多くの企業がAIを活用できる部分だと思います。あまりにも多くの人が、自動運転車をはじめとする、カッコいいものが多くのお金を生む、と考えているように思えます。しかし、私はそうは思いません。チャンスの多くは、いい表現が思い浮かびませんが、そんなに「セクシー」じゃないけれど、AIが真の違いを生み出せるところにあると思います。

ソフトウェア・エンジニアリングの歴史は長いものの、AIを基礎とした製品づくりは未だ新しい分野です。AIに基づく製品制作を得意とする企業も、まだ方法を解明している段階と言えます。AI製品の制作方法を書いた本などないでしょうし、あったとしても、とても良い本とは言えないでしょう。つまり、まだレシピがないのです。その分自由とも言えますが、そのせいでプロセスがより難しくもなっているとも言えます。だからこそ、コージェントラボのような会社で働くことが面白いのです。

この記事をシェア

RSS