こんにちは、Sansan Engineering Unitの部長を務める、笹川 裕人です。今回で6回目となる「Sansan Tech Talk」。この連載ではSansanのテックリードたちが日々直面している技術的な課題や挑戦を深掘りしてお伝えしています。 今回は研究開発部で活躍するWebアプリエンジニアである鷹箸 孝典にインタビューしました。
▼連載記事はこちら
buildersbox.corp-sansan.com
笹川：今回は研究開発部の鷹箸さんにお越しいただきました。では鷹箸さん、自己紹介をお願いします。
鷹箸：はい、よろしくお願いします。研究開発部でエンジニアをしている鷹箸です。私は新卒でSansanに入社し、気づけば丸9年が経ちました。入社当初は研究開発部はわずか5人ほどの小規模な組織で、エンジニアという役割もまだありませんでした。研究開発部は、事業の課題を解決するためにサービスの研究から開発、運用までを行う組織ですが、エンジニアリングの面では他のエンジニア組織と比べて弱い部分がありました。私は最初、画像処理系のタスクを担当し、研究員的な仕事もしていましたが、エンジニアリングの課題に向き合うことが多くなり、その過程で現在のArchitectグループが生まれ、以降はそこに携わっています。
笹川：研究員のキャリアを選択しなかった理由は何かありますか？
鷹箸：そうですね。大学院を修了していたので、そこで培った経験を活かしたいと当初は考えていました。一方で、大学時代にエンジニアリングやアプリケーション開発の経験もあったので、研究開発部に入って課題感が見えてきたとき、そこが自分の強みを活かせる場所だと感じ、注力していきました。
笹川：当時、そういった役割を担っていたのは鷹箸さんが最初だったのですか？
鷹箸：もう一人、研究開発部の最初のメンバーである島さんがいました。彼は研究領域とエンジニアリング領域の両方を担当していました。
笹川：なるほど。そういった背景があって、エンジニアのキャリアに進んでいったわけですね。現在ではエンジニアの数も増えていると思いますが、何人くらいいるんですか？
鷹箸：約20名在籍しています。
笹川：さて、この連載でよく聞いている組織の技術的な課題について伺いたいのですが、最初に思い浮かぶものはありますか？
鷹箸：研究開発部の発足以来、データ入力に関する研究開発に取り組んでおり、継続してサービスの開発・運用を行ってきました。少しずつアップデートは重ねてきたものの、大規模なアップデートはなかなか実現できていませんでした。これが大きな課題の一つだったと思います。
笹川：なるほど。既存サービスのアップデートというのは、精度改善や依存しているライブラリの更新など、かなり課題になっていたのでしょうか。
鷹箸：そうですね。特にインフラ面が課題でした。当時、R&DではC#を採用し、.NET Frameworkで運用していました。基本的にWindowsサーバで運用していたんです。
笹川：なるほど。Sansan本体が.Net Frameworkで作られている経緯ですね。
鷹箸：はい。Sansanのデータ入力の仕組みに、GEESというシステムがあります。そこには名刺のデータ入力自動化に関わる機能が組み込まれています。例えば、スマホで撮影した名刺写真から不要な背景を除去して名刺部分だけを切り出すサービスや、名刺内の名前、会社名、電話番号などの情報を個別に抽出する処理、実際にOCRをかけて文字として取り出すサービスなど、多岐にわたります。
笹川：それらのWindowsで動いていたシステムを、Linuxでコンテナ化するところまで進めたんですか？
鷹箸：そうですね。直近1年ほどで、一部のサービスで取り組みました。もともとはAmazon EC2 Auto Scalingを利用して、スケールさせる仕組みで運用していました。そこからAmazon ECSを使って、より効率的に運用できる環境を整えています。ECS化に当たって、元はWindowsサーバで運用していましたが、Windowsだとスケーリングが遅いという課題がありました。そこで、ECS化するならLinuxに移行し、もとのサービスのパフォーマンスや性能を維持しつつ、より運用しやすい環境を目指してLinux化とECS化を進めました。
笹川：.NET Frameworkからのアップデートはかなりの変更が必要だったと思いますが、その過程で苦労したことはありますか？
鷹箸：そうですね。Windows依存の部分が多かったので、Linuxで動作させるのはかなり大変でした。当時はC#をデファクトスタンダードとして使用していましたが、最近は機械学習や自然言語処理のタスクが増えてきたこともあり、研究員もエンジニアもPythonは扱えるのですが、C#となると苦手な人もいて苦労しました。
笹川：なるほど。では、一部のサービスをPythonでリライトしたりもしたのですか？
鷹箸：いえ、そこまでやっていません。
笹川：とりあえず、C#は維持したままLinuxで動かせる.NET Coreまでアップグレードし、ECS上で動作させることを目標にしたんですね。
鷹箸：そうです。サービスのモダナイズ化という点では、それが重要だと考えました。
もう一点、重要なのは「モダナイズして何が嬉しいのか」ということです。運用が楽になったという点もありますが、それだけではモダナイズ化を進める十分な理由にはなりません。実は、コスト削減効果が大きいんです。WindowsサーバからLinuxサーバに置き換えるだけで、約40%のコスト削減ができました。これはかなり事業に貢献しています。
笹川：それは重要ですね。単なる置き換え以外に、例えばスケーリングでのさらなるコスト削減効果はありましたか？
鷹箸：そうですね。WindowsからLinuxへの移行が大きかったんですが、ECS化によっても恩恵がありました。例えば、夜間など流入が少ない時間帯には、かなり小規模にスケールインできるようになりました。
笹川：そこそこの規模のサーバだから、40%のコスト削減がかなりの額になることはイメージできます。
鷹箸：具体的な数字を挙げると、現時点では全てをECS化できているわけではありませんが、影響の大きい部分から着手して、現在月額約2,000ドルの削減に貢献しています。
笹川：素晴らしいですね。
既存サービスのモダナイズについてお話しいただきましたが、他に大きな技術的課題はありますか？
鷹箸：最近、Sansan事業の要となる独自のOCRを開発しています。NineOCRと呼んでいるのですが、我々エンジニアの課題は、いかに開発サイクルを短縮するかということです。
笹川：開発サイクルは当初かなり重かったんですか？
鷹箸：そうですね。NineOCRは機械学習を用いているのですが、学習に必要なデータを集めるのに非常に時間がかかっていました。先ほど触れたGEESというシステムは別の部署が作っているので、各名刺のデータもそこにあります。NineOCRの学習に使うデータを取得する際、その部署とのやり取りから始まり、具体的にどのデータが必要か検討して収集するので、一つの学習サイクルを回すのに膨大な時間がかかっていたんです。
笹川：なるほど。コミュニケーションコストもあり、データ量も相当あったということで、時間がかかっていたんですね。どのようにして解決や時間短縮につなげたんですか？
鷹箸：私たちは、Feature Storeと呼ばれるものを導入しました。R&D側にデータベースとして用意し、そこからデータを集められるようにしたんです。これにより、他部署のパフォーマンスへの影響を最小限に抑えつつ、必要なデータを効率的に収集できるようになりました。
笹川：Feature Storeの導入は他社の事例でも聞きますが、検討過程をもう少し詳しく教えてもらえますか？
鷹箸：はい。Feature Storeを用意したと言っても、元となるデータ自体は他部署が管理しているので、Feature Store内にデータを蓄積する仕組みを構築する必要がありました。
笹川：その過程はスムーズに進みましたか？組織をまたがない学習サイクルを実現するため、日常的な連携が必要だったと思いますが、その部分が気になりました。
鷹箸：実は、依存するサービスが5つほどありまして、それぞれのタイミングで呼び出す必要がありました。また、お客様からお預かりしているデータを扱っているため、お客様が解約した場合はすべてのデータベースで解約処理を行う必要があるという制約もあります。そういった仕組みも適切に構築する必要があり、考慮すべき点が多くありました。
笹川：なるほど。解約処理は、契約上必要な重要な処理ですね。各部署で実装して自動的に適切に処理されるようにするのは徹底していますが、その対象を1つ増やすということは、相応の対応が必要だったんですね。これは素晴らしい取り組みだと思います。これらの取り組みによって、現時点でリードタイムはどの程度短縮されましたか？
鷹箸：NineOCRの改善、リリース、本番稼働までの過程を考えると、GEESシステムの複雑さもあり、NineOCRの精度向上だけでは不十分です。GEESシステム全体を通じて、NineOCRや他のサービスを経て、最終的に納品されるデータの品質向上が必要です。そのため、改善サイクル全体への影響を現時点で評価するのは難しいですが、NineOCRの性能改善に限って言えば、以前は1カ月に1回程度だったものが、R&D部門内で完結する部分に関しては週1回程度まで短縮されました。
笹川：ざっくり4倍以上リードタイムが改善されたんですね。たしかに、全体として複雑で大規模なシステムだと、一部分の改善だけでは不十分ですが、逆に言えば全体改善の一歩ですし、NineOCRはコア技術なので、その影響は広範囲に及ぶと思います。全体的な効果も測れるといいですね。
鷹箸：そうですね。それは今後の課題だと認識しています。システム全体の評価をR&Dで行える仕組みを構築できれば、R&Dの価値をより迅速に提供できるようになると考えています。
笹川：なるほど。他に技術的な課題はありますか？
鷹箸：先ほどの話は、NineOCRのデータ収集やMLOpsのサイクルにおけるデータ収集の改善についてでしたが、他にも多くの改善点があります。直近で取り組みたいのは、統一されたアノテーションツールの導入と、機械学習モデルの学習における実験管理ツールの導入です。これらによってNineOCRの更なる改善に寄与したいと考えています。
笹川：アノテーションツールは既存のものもあれば、独自開発している企業もあると聞きますが、このツールを導入または開発した場合、主に誰が使用することを想定していますか？
鷹箸：小規模なタスクであれば研究員が自らアノテーションすることもありますが、Sansanにはデータ化をサポートするオペレーターがいるので、主に彼らに使用してもらうことを想定しています。
笹川：なるほど。Sansanの強みである人力でアノテートされたデータの存在は大きいですね。それ自体を目的としてデータを作成するのは、かなりの強みになりそうです。今後期待したいところですね。
鷹箸：そうですね。MLOpsにおいてもさまざまなフェーズがあります。現状では、Feature Store、アノテーションツール、実験管理ツールをそれぞれ個別に用意した段階です。これらがパイプラインとして連携できれば、学習サイクルも効率化できます。例えば、オペレーターがアノテーションを完了し、ボタンを押すだけで自動的に学習が開始され、モデルが生成される。実験管理では複数の学習が同時に行われ、最適なものが自動的に選択されてリリースされる。そんな流れを最終的には実現したいと考えています。
笹川：MLOpsの特定の側面だけがクローズアップされがちですが、本当に重要なのは全体的な改善ですよね。その目標を忘れずにいたいです。Sansan R&Dの機械学習環境について言えば、最近は着実に進展していると思います。キラキラした成果というより、堅実に成果を出しながら、必要なツールを適切に導入し、うまく成長している印象があります。
鷹箸：まさにその通りです。「これを導入したい」とか「世間で流行っているから」といった理由ではなく、Sansanでは事業貢献を重視しています。そのため、事業に効果的なものを慎重に選定して導入しています。
笹川：必要に応じて、コストパフォーマンスよく成長しているのはいいところですね。ここまで技術面の大きな話をしてきましたが、組織面での課題や今後の展望はありますか？
鷹箸：はい。組織の課題で言えば、3、4年前は研究員と研究タスクに携わるエンジニアの比率が約5対1で、研究員が多い状況でした。研究開発部門として事業貢献や価値創出が最重要ですが、この人数比率ではサービス開発に手一杯でした。
最近では、Architectグループが「Circuit」と呼ばれるアプリケーション基盤を開発し、本番環境への展開効率が大幅に向上しました。これにより、以前はサービス開発で手一杯だった状況が改善傾向にあり、次のフェーズに進む必要性を感じています。
笹川：次のフェーズについて、どのようなイメージを持っていますか？CircuitのKubernetesクラスターやモダン化、Feature Storeによるデータ収集などで、サービス貢献がしやすくなったと思いますが、今後取り組みたいことや現在取り組んでいることはありますか？
鷹箸：これまで研究員は各ドメインに特化して課題解決に取り組んでいました。一方、エンジニア組織はより広範囲をカバーしています。主にデータ化の自動化とデータ利活用の二つの領域があり、それぞれにコミットしています。現状では、データ利活用の中にさまざまなドメインが存在し、エンジニアは複数のサービスに広く関わっています。しかし、これでは表面的な関与に留まりがちです。最近少し余裕が出てきたこともあり、エンジニアも各ドメインにより深くコミットできる組織体制を構築したいと考えています。
笹川：つまり、これまでエンジニア側は「データの人」「アプリケーション基盤の人」といった横断的な役割分担だったのを、ドメインごとに再編成して、より深くコミットしていこうという考えですね。
データ活用やML活用などのサービス導入が一段落したので、より深いコミットメントのために組織を再編するというのは、先ほどのMLOps関連の進化と一貫性がありますね。必要に応じて変更を加えたり、次のステップを決定するという姿勢は、組織としても一貫性があって良いと思います。
鷹箸：はい、この方向性を進めていく上では、まだ多くの課題があります。ドメインへの関与を深める方針は決定し、取り組みを開始していますが、今後さらに課題が顕在化すると予想しています。それも一つの楽しみですね。
笹川：なるほど。ありがとうございます。
では今回は、研究開発部の鷹箸さんにお越しいただいて、技術的な話題と、組織変革によってさらなる加速を目指す取り組みについてお聞きしました。
鷹箸さん、ありがとうございました。
鷹箸：ありがとうございました。
