こんにちは、Sansan Engineering Unitの副部長、笹川 裕人です。今回の「Sansan Tech Talk」では、Strategic Products Engineering Unit（以下、SPEU）という新規事業開発を行っている部門のInfrastructureグループマネジャーを務める水谷 高朗にインタビューしました。この対談では、テックリードたちが直面している技術的な課題や取り組みについて深掘りします。
▼連載記事はこちら
buildersbox.corp-sansan.com
笹川：それでは水谷さん、自己紹介をお願いします。
水谷： SPEUのInfrastructureグループでマネジャーをしている水谷高朗です。ちなみに、来月から業務内容により適した名称にするため、グループ名をSREグループに変更する予定です。
私は10年前にSansan株式会社へ、データ化部門のインフラエンジニアとして入社しました。当時は、サービスがキャンペーンなどのアクセス集中によってダウンしてしまうという課題に直面していました。この問題は、データベースとインスタンスの不適切な使用とチューニングの不足が原因でした。改善の過程でRDSをMySQLからAuroraに移行した際、Auroraの初期ユーザーとしてさまざまなバグを経験したり、Auroraの使い方を勘違いしていたりしたため、Auroraの論文を読んだりしながら対策を講じてきました。その後、新規事業プロダクトの立ち上げサポートを経て、現在のInfrastructureグループの立ち上げと、それをSREグループに進化させるという役割を担っています。
笹川：確かに私が入社した頃、水谷さんの兼務の多さに驚いたのを覚えています。すべての部署に少しずつ関わっているんじゃないかと思っていました（笑）
ここからは、SPEUの技術的な課題と今後の取り組みについて聞いていきたいと思います。SPEUには、契約データベース「Contract One」と、営業DXサービス「Sansan」のいち機能である「名刺メーカー」と、複数の開発組織がありますが、全体として取り組んでいきたいことはありますか？
水谷：IaC（Infrastructure as Code）導入の徹底に向き合いたいと考えています。これは、新規事業の立ち上げサポートを行った際、アプリケーションエンジニアへのIaCの目的やメリットについての説明が不十分だったという反省があるためです。その結果、開発エンジニアは新規事業の迅速な立ち上げを求められる中、Terraformの学習コストをかけるよりも、ドキュメントを参照して直接操作する方が早いと判断し、コンソールでの変更や構築を行ってしまいました。この判断に対して理解はできますが、実は直接操作するよりもTerraformの方が早いんですよね。
笹川：そうですね。トータルでは早くなることが多い肌感はあります。
水谷：そうなんです。しかし、メンバーにTerraformの使用方法や記述方法を十分に教えられなかった結果、メンバーはTerraformの学習を行いながらの変更を適用することが難しかったんだと感じています。
笹川：確かに、導入はされているけれど、何のためかわからない状況での利用は難しいですよね。一般的に、インフラとアプリケーションの知識が分断されている中での導入は、理解が追いつかず、一時的な対処をして済ませたくなるかもしれません。
水谷：そうなんですよね。そのため、IaCの徹底をまずは目標の一つとして取り組もうと考えています。もちろん、IaCをやるのが目的ではなく、それをやることによって得られる効果が実際の目的なので、その目的を開発メンバーに伝えながら、私自身も、Infrastructureグループのメンバーも、開発メンバーも手を動かして、その文化を浸透させていきたいです。
笹川：確かに、コンソールでの構成変更の実施は、レビューされない変更となったり、そもそも実装と、デプロイを同時に実行している状況になるなど、さまざまなリスクはらんでいます。そのため、これらのリスクを効果的に管理するためにも、IaCの導入は積極的に進めていきたいですね。
水谷：次に、オブザーバビリティの強化に取り組みたいと考えています。これは、単なるツールの導入を超えた文化の醸成と浸透が必要だと認識しています。現在、Splunkといったオブザーバビリティツールの導入はほぼ完了していますが、これらを有効活用しているメンバーが限られているという課題があります。開発や運用に追われているメンバーの間で、ツールの活用が不十分であるため、適切な不具合修正やレポーティングができていないという状況になっています。オブザーバビリティツールの有効活用を目指すためには、メンバーに理解と活用を促す必要があります。これは、IaCの徹底と同様に、目的を明確に伝えることから始めるべきだと考えています。
笹川：確かに、ツールの恩恵が分からないと、使わずに済ませてしまうことがありますが、これは避けたいですよね。しかし、ツールがとっつきにくいと感じてしまうのも理解できます。
水谷：困っていないとは言え、それが原因で停滞してしまうのは避けたいです。現状に満足してしまうのはSansanらしくないと思っています。より良いサービスを提供するためには、新規事業の迅速な立ち上げだけでなく、安定した運用も同様に重要です。リリース後のサービスが安定して動作せず、ユーザーからの適切なフィードバックが得られないと、そのサービスがユーザーにどのように響いているのか、あるいは響いていないのかを把握できません。そのため、安定稼働を目指したいです。
笹川：これは、運用の改善やオブザーバビリティの観点に加えて、品質の向上も重要な取り組みとなりそうですね。
水谷：品質の向上も重要で、そのためにはテストの自動化が鍵となっています。これまで、スピードを最優先にしてきたため、すべてのテストが自動化されているわけではありません。ですが、スピードを優先していると言いつつ、手動でのテストに時間がかかってしまっています。そのため、自動テストをすべてのプロダクトに導入し、品質を維持しながらリリースのスピードをさらに向上させたいです。
笹川：そうですね。一般的なテスト戦略としてユニットテストを多用するというメンテナビリティを考慮したアプローチがありますが、最近の傾向としては、ユニットテストに加えて、E2Eテストも重視するというアプローチが見られます。また、ツールの整備も進んできているので、フィーチャーの開発にも良い影響を与えそうですよね。
水谷：あとは、SPEUは若くて元気のあるメンバーが多いんですよ。もちろん技術力もあリますが、経験値はこれからの部分もあるため、QAチームにいるシニアエンジニアたちの知見を借りてテストを拡充していきたいです。
笹川：確かに、昨今採用に力を入れていて、QAチームはえりすぐりの精鋭メンバーが入ってきているので、活躍を期待したいところでありますね。
今IaC、オブザーバビリティ、テストという3つの大きな観点で話してもらいましたが、個々のプロダクトについて、今後の取り組みや向き合いたい課題について具体的に教えていただけますか？
水谷：まず、契約データベース「Contract One」についてお話しします。Contract Oneは、契約書をデータ化し、全社で契約情報を活用できるように一元管理するプロダクトです。一元管理と一口に言っても、一箇所に貯めておけばいいわけではなく、集約された情報を使えないと意味がありません。契約書は文字数も項目も多く、検索条件も多岐にわたります。これらの複雑さを効果的に管理するため、我々は単なるデータの蓄積を超えた、直感的で高度な検索機能の強化に取り組んでいます。この検索機能の強化は、開発メンバーが中心となって進めており、私たちInfrastructureグループが運用面で考慮すべきことを伝えてサポートしながら技術検証を行っています。また、過去に全文検索エンジンの載せ替えを経験したことから、その知見を活かしてElasticsearchの導入とチューニングもサポートしています。さらに、研究開発部門に自然言語処理の専門家がいるので、橋渡しをすることで、順調に検証が進んでいます。
笹川：検索は面白いチャレンジがたくさんありますし、Elasticsearchも技術的に面白いところだと思うので、リリースされた後も楽しみになりますね。さらに先の話になりますが、その後のアウトプットも期待したいですね。
水谷：そうですね。もちろんElasticsearchありきではなくて、別のものも技術検証していきたいと考えています。
次に、もう1つ名刺メーカーという機能についてお話しします。SPEUのサービスはすべてGCPで動いており、これはインボイス管理サービス「Bill One」という急成長中のサービスがGCPで構築されたことがきっかけとなっています。Bill Oneの構築時には、インフラエンジニアが不在だったため、Googleが管理するGAEを活用したかったという背景があります。その後、Bill OneがGCP上で安定して稼働し始めたことから、SPEUの他のサービスもBill Oneでのノウハウを活用してGCP上で構築されていきました。これは、名刺メーカーも該当します。しかし、名刺メーカーのデータをすべてRDBに載せると性能が出ず、アプリケーションを作るのが複雑になってしまうという問題が発生しました。名刺メーカーのデータが複雑なリレーションを必要としないためです。この場面では、キーバリューストアを使えばよかったんだろうなと思いました。
笹川：バリュー側をJSONで持つイメージですかね。この名刺のIDは名刺情報の塊として扱う感じで十分だったということでしょうか。
水谷：十分と思います。そのため、RDBでの複雑なクエリ作成がボトルネックとなっています。この問題を解決するため、来月からSREグループにジョインするメンバーとともに、機能要件の見直しやヒアリングを行いながら改善を進めていく予定です。
笹川：なるほど、ありがとうございます。確かに、データストアの選定はその時々の状況に応じて最適なものを選ぶ必要がありますし、これは一種の永遠のテーマのようなものですよね。特に、RDBに関するノウハウは豊富に存在する一方で、他のデータストアに関する情報は比較的少ないため、安全策としてRDBを選択することはありがちですよね。しかし、これが特定の用途での運用を複雑にすることも確かにあります。
水谷：当時の判断は最適だったんだと思います。作成した人々や当時のメンバーを否定はできません。新規事業であるため、変化が大きいことも事実です。どんな事業も立ち上がりは変化が大きいと思いますが、特に立ち上がり期には、これらの事象が発生するため、変化に適応し続ける必要があります。そこの課題に向き合うのは非常に楽しいですね。
笹川：確かに、名刺メーカーの今後の拡大を考えると、頑張っていきたいところですね。
水谷：そうですね。一見単純な名刺の作成・印刷というタスクを複雑なレベルで処理しているんです。帳票の印刷と同様に、名刺メーカーの印刷もまた、レイアウト、フォント、色の適用など、細かなレギュレーションを考慮する必要があるため、難しいことに向き合っています。これらのレギュレーションは、各社が持つ独自の基準に基づいており、名前の文字数やメールアドレスの長さに応じて、それぞれの名刺に微調整を加える必要があります。名刺メーカーの開発は、これらの複雑な要件を効率的に処理し、印刷会社さんが印刷業務に専念することを可能にするために、これまで個別に設計されていた名刺の微調整を自動化することを目指しています。
名刺メーカーは、テンプレートエンジンを活用して、入力された名刺の名前やEメールなどの項目を、事前に定義されたレギュレーションに従ってレイアウトを決定します。このテンプレートエンジンは、エンジニアがJavaScriptで開発したテンプレートファイルを使用しています。名刺メーカーはフロントエンドとバックエンドの両方でJavaScript、具体的にはTypeScriptを使用しています。名刺の画像はSVG形式で作成され、印刷のためにPDFに変換されます。このプロセスは、JavaScriptを使用して制御されます。名刺メーカーは、各社の異なるレギュレーションに対応するために、一社ごとに個別のテンプレートを作成します。これは、複数の部署や子会社がある大企業も含まれます。そのため、一つひとつのテンプレートを作成する作業は非常に複雑で、運用も大変です。
名刺メーカーの運用は、現在の4人チームだけでは困難であるため、他の部門と協力して効率的に運用できる方法を検討しています。そのため、開発メンバー以外のメンバーも参加できる環境の整備が必要だと考えています。さらに、手作業が多いため、Infrastructureグループはヒアリングを通じて自動化の仕様を詰め、一つひとつの手作業を自動化していくことが求められます。
笹川：うまく開発サイドと協力して、一緒に改善していけるといいですね。
水谷：名刺メーカーが、手作業の多い運用になってしまうのは、一般的な運用方法についての知識にのびしろがあるからだと思います。テンプレート作成に多くの時間を割いているため、他部署の運用を学ぶ機会がなく、この状況が悪循環になっています。そのため、運用が大変すぎるところに自動化するための改善を入れることが大変に思えるかもしれませんが、今改善を優先してやれば、開発時間が取れるということを理解してもらいながら、みんなで改善を進めています。
笹川：大事なことですね。早期に改善しないと、継続的な負担となる可能性がありますからね。効率的な運用を目指してこれからも頑張ってください！
水谷：ありがとうございました！
