はてなブックマーク

技術本部 Quality Assurance グループの杉本です。元々はプロダクト開発を行っていましたが、QAグループに SET（Software Engineer in Test）チームが立ち上がるということで異動してきました。 チーム発足から、Playwrightを使ったEnd to Endテスト（以下、E2Eテスト）の導入と最初の成果についてご紹介します。 目的と目標 SETチームが発足したのは、今から約1年前の2023年6月です。私ともう1人、同じプロダクト開発を行っていた平田さんの2人で始まりました。 当初の目的は、リリースして間もなかった、月次決算を加速する「Bill Oneビジネスカード」のリグレッションテストを自動化するというものでした。修正や機能追加のサイクルが早く、手動でのテストはどうしても時間がかかってしまい、リリースサイクルに追いつかない、開発へのフィードバックが遅

こんにちは。Quality Assuranceグループで、Bill Oneの品質マネジャーをしている秋元真理子です。現在QAグループで取り組んでいる「ナラティブ文化」についてご紹介したいと思います。 アマゾンで経験した「ナラティブ文化」 本題に入る前に、少し私自身の背景などもお話しさせてください。私は2024年4月1日にSansanに入社しましたが、その前はアマゾン・ジャパンに13年間、グローバル・モバイルQAエンジニアやCXプログラム・マネジャーとして勤めていました。 多くの方が既にご存知の「アマゾンではパワー・ポイントは使わない」、「箇条書きはなし」、「ミーティングが始まると、まずは文章を読む」など、「ナラティブ」または「文章」で表現していく文化に長年触れてきました。 QAエンジニアとしては、正式なドキュメントを書く機会はそれほど多くはなかったのですが、QAプロジェクトや障害などに対す

こんにちは、Sansan Engineering Unit 部長の笹川裕人です。今回で7回目を迎える「Sansan Tech Talk」では、Sansanのテックリードが日々取り組んでいる技術的な課題や挑戦を深掘りしてお届けしています。今回は、研究開発部で活躍するWebアプリエンジニアの新井和弥にインタビューしました。 ▼連載記事はこちら buildersbox.corp-sansan.com （写真左から）研究開発部 新井 和弥、Sansan Engineering Unit 部長 笹川 裕人 笹川：今日は研究開発部の新井さんにお越しいただきました。新井さん、自己紹介をお願いできますか。 新井：よろしくお願いします、新井と申します。現在、技術本部研究開発部のArchitectグループにあるML Platformチームでリーダーを務めています。Sansan株式会社には約2年半前に中途入社し

こんにちは。技術本部Sansan Engineering Unit Master Data Groupの古本です。 普段は、営業DXサービス「Sansan」の名刺交換した人や企業に関するニュースを表示し、お知らせする「企業ニュース」や「企業情報」を扱うシステムの開発をしています。 最近、マイクロサービスで作られた企業ニュースのシステムをモノレポ構成に移行しました。 今回はその時に行ったことについて話します。 モノレポ（mono repo）とは 本ブログで類似の記事があったので引用します。 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 マイクロサービスアーキテクチャのリポジトリ構成を漸進的にモノレポに移行した話 今回も複数レポジ

はじめに Eight Androidチームのチームリーダーの山本です。 私たちのチームでは2024年6月から新たにテックリードのポジションを設け、2024年4月入社のメンバーにその役割を担ってもらっています。 それまでEight Androidチームに明確なテックリードのポジションはなく、チームリーダーである自身が暗黙のうちにその役割を兼務している状態でした。今回、新たにテックリードのポジションを設けるに当たり、考えたことをまとめます。 背景 これまでチームでは2つの取り組みでアーキテクチャの検討と、新技術導入や技術的負債の改善を行ってきました。 技術基盤改善 新技術導入や技術的負債の改善を行う 週に1回2時間の時間をかける チーム全員が作業する アーキテクチャ検討会 レビューなどで発生した汎用的な技術的な論点や、大きなアーキテクチャ変更の話題を扱う 週に1回2時間の時間をかける チーム全

こんにちは！ 技術本部 Sansan Engineering Unit Mobile Applicationグループの桑原です。 この度、Sansanモバイルアプリでは開発スピードを加速させるため、実プロダクトにKotlin Multiplatform（以下、KMP）を導入しました！ まずは1画面の導入から始めましたが、今後は既存の画面も順次KMPに移行していく予定です。 この記事では、Androidエンジニアの視点から、SansanアプリにKMPを導入した背景やその成果、さらにKMPの設計についても簡単に紹介します。 KMPの導入背景と成果 導入した理由 導入で感じたメリット 導入で感じたデメリット KMPの基本設計 AndroidでのKMPモジュールの取り込み方法 採用したアーキテクチャ KMPモジュールの構成 エラーハンドリング テスト KMPで使用しているその他ライブラリ 最後に

こんにちは、技術本部Sansan Engineering UnitのNayoseグループでバックエンドエンジニアをしている上田です。 普段はデータの名寄せサービスを開発しています。Sansanの名寄せというのは、こちらのページに記載のとおり、別々のデータとして存在する同じ会社や人物のデータをひとまとめにグルーピングすることを言います。 下記の記事のとおり、前回は名寄せアルゴリズムを定量評価する際に利用する統計的仮説検定において、固定サンプルサイズ検定の課題を解決する逐次検定の手法SPRT（Sequential Probability Ratio Test、逐次確率比検定）を紹介しました。SPRTには別の課題があるため、今回は実務で重宝する特徴をもつGroup Sequential Testという逐次検定について紹介します。 buildersbox.corp-sansan.com この記事の

こんにちは。 名刺アプリ「Eight」でエンジニアをしている鳥山（@pvcresin）です。 最近、ミスタードーナツのミニオンコラボの商品を食べたのですが、 どれも美味しくて見た目もかわいいので最高でした。 特にポン・デ・リングベースのものは、表面のキャンディが口の中でパチパチと弾けて楽しいのでオススメです。 さて今回は、RailsのViewで使う、HTML用ERBファイルのフォーマットを統一した話をします。 ERBとは ERB（eRuby、embedded Ruby）はテキストにRubyのコードを埋め込むための仕様です。 Railsでは特にViewの部分のHTML生成によく利用されます（拡張子は.erb）。 ERBでは、以下のような記法でRubyのコードを埋め込めます。 <ul> <% @features.each do |f| %> <li><%= f %></li> <% end %

こんにちは、研究開発部Architectグループ ML Platformチームの藤岡です。今回はKubernetes上に負荷試験基盤を構築したので、その取り組みについて紹介しようと思います。 目次 目次 背景 負荷試験基盤の要件 負荷試験ツールの選定 負荷試験基盤のシステム概要 シナリオファイルの管理方法 Kubernetes operator pattern の利用 GitHub Actionsの共通化 Slack通知用のAPIを用意 負荷試験の導入 負荷試験シナリオの詳細 負荷試験の実行 負荷試験の結果 おわりに 背景 研究開発部ではマイクロサービスで開発することが多く、各事業部向けにさまざまなシステムをAPI形式で提供しています。 APIを作成した際には負荷試験を行っており、リリース前にAPIのパフォーマンスを確認しています。 しかし現状では、各々のローカル環境で負荷試験を実施してい

Bill One Engineering Unit 共通認証基盤チームの樋口です。 Bill Oneでは昨年までAuth0を認証基盤として利用してきましたが、認証基盤を内製化することでコストを大幅に削減しました。 この認証基盤は、昨年12月に無事リリースされ、Bill Oneの認証を支えています。 今回は認証基盤の内製化に至った経緯と設計、移行プロセスについて紹介します。 Bill Oneについて 認証基盤に関する課題 解決方法の検討 IDaaS（Identity as a Service）について 設計とシステム構成について 認証基盤の設計 システム構成 アカウントの移行について メールアドレス・パスワードでのログインを利用しているユーザーの移行 SSO（Single Sign-On）の移行 振り返りと今後 ドメイン変更による問い合わせの増加 内製化によって体験の改善がスムーズに Bil

技術本部 Sansan Engineering Unit Data Hub グループの光川です。 先日、技術本部総会という、技術本部に所属するメンバーが一堂に集まるイベントの3回目が開催されました。その中のコンテンツとしてOST（オープンスペーステクノロジー）を実施しました。前回、前々回に引き続きOSTの運営に携わったので、レポートを書きます。 過去に実施した、OSTの記事はこちらです。 buildersbox.corp-sansan.com buildersbox.corp-sansan.com 今回の技術本部総会は約250名が現地会場に集まり、任意参加のOSTには約100名が参加してくれました。 新しくやってみたこと 今回のOSTで新しくやってみたことは以下です。 セッションテーマの事前募集をやめて、当日に起票するという、初回のOSTのスタイルに戻した OSTの全体テーマを決めた OS

技術本部Mobile Application Group Eight Androidチームの山本です。今回は雑談が苦手な自分がどう1on1を行ったかという話をします。 自分は雑談が苦手です。目的があって話すことは問題ないのですが、雑談自体が目的化している場が苦手です。 自分がチームリーダーになった後も、メンバーとの1on1はマネジャーにお願いしていました。しかしマネジャーが育休を取得することになり、その期間中は自分が1on1を担当することになりました。この時、自分が採ったやり方について紹介します。 1on1はいろいろなやり方があり、自分の採った方法は推奨されないやり方とされている場合もあります。あくまでこういうやり方もあるという認識でお願いします。 1on1の目的 1on1の目的ですが、今回は「メンバーが1on1という形でしか話せない問題を拾い上げて解決方法を考える」ことにしました。 メン

技術本部Strategic Products Engineering Unit Contract One Devグループの伊藤です。契約データベース「Contract One」の開発に携わっています。 Contract Oneでは、GPTを活用した機能をいくつか提供しています。 今回は、Contract OneのGPTを活用した機能開発のために、LLMOpsの取り組みの一環としてLangfuseを導入し始めた話をします。 なお、本記事は【Strategic Products Engineering Unitブログリレー】という連載記事のひとつです。 buildersbox.corp-sansan.com はじめに Contract Oneでは、GPTを活用した文書内検索 *1 と要約機能 *2 を約1年前にリリースし、現在も提供しています。 GPTは自然言語形式の入力をAPI形式で処理でき

Bill One Engineering Unitの田上です。運用改善と題したプロジェクトによって、エンジニアの運用工数を半年で40%削減することに成功したので、今回はその取り組みをご紹介します。 背景 Bill One のエンジニアリング組織では、フルサイクルエンジアリングで開発と運用を行っており、開発者自身が運用対応（本番環境で発生したエラーの調査・対応、ユーザからの依頼・問い合わせの対応など）を行っています。 エンジニアが自身の開発したプロダクトへのフィードバックを迅速かつダイレクトに受け取れる非常に良い方式ではあるのですが、その対応工数があまりにも多くなりすぎて開発工数が逼迫するようになっていました。 その状況をどうにかするため半年の期限付き特命チームとして運用改善チームを立ち上げることにしました。 立ち上げ 組織内のフラストレーションの高まりを背景に、2名のエンジニアが新たなチー

こんにちは。4月に24新卒として入社しました、技術本部 研究開発部の金髙です。大学院では政治学の研究をしていました。 本記事では、筆者が2024年2月から約1カ月間の内定者インターン時代に取り組んだ内容の一部である「ベイジアン操作変数法を用いたA/Bテスト」について紹介します。 背景 なぜA/Bテストで操作変数法なのか？ Encouragement design One-sided Noncompliance なぜA/Bテストでベイズなのか？ ベイジアン操作変数法 データ生成過程 事後分布 LATEの事後分布推定 シミュレーションしてみる おわりに References 背景 筆者が現在所属している研究開発部のチームでは、データドリブンな意思決定やデータ活用促進を目標に掲げています。その一環として、A/Bテストを積極的に行っており、筆者は中でも「Sansanモバイルアプリ内訴求」に関するA

技術本部 研究開発部の小松です。社内/社外向けのアプリケーション開発や、社内のデータ活用促進、学術研究に取り組んでいます。 本稿では、Sansan社内でデータに基づく意思決定を浸透させるために、A/Bテストの活用を推進しようとしている取り組みについて書きます。「しようとしている」という表現からわかるように、他のテック企業と比べるとSansanでのA/Bテストの活用はまだ定着しているとは言えません。A/Bテストに関する私たちの試行錯誤の過程を公開していくことで、読者の方からフィードバックを得たいという試みです。今後、A/Bテストに関する技術的な記事を発信していく予定ですので、ご期待ください。 なぜA/Bテストを推進するか なぜA/Bテストを推進するかという筆者なりの回答は、以下の2点です。 成功確率のコントロールが難しいことを前提とすると、成功を引き当てるためには多くの実験が必要となる。その

こんにちは、Sansan Engineering Unitの副部長、笹川 裕人です。今回の「Sansan Tech Talk」では、Strategic Products Engineering Unit（以下、SPEU）という新規事業開発を行っている部門のInfrastructureグループマネジャーを務める水谷 高朗にインタビューしました。この対談では、テックリードたちが直面している技術的な課題や取り組みについて深掘りします。 ▼連載記事はこちら buildersbox.corp-sansan.com （写真左から）Strategic Products Engineering Unit Infrastructureグループマネジャー 水谷 高朗、Sansan Engineering Unit 副部長 笹川 裕人 笹川：それでは水谷さん、自己紹介をお願いします。 水谷： SPEUのInfr

Sansan Engineering UnitでSansan Data Hubの開発をしている藤原です。 前回はニッチに深く潜り過ぎたので、今回は（使い古されたネタではありますが）モノレポ化についてお話ししたいと思います。 おさらい：モノレポ（mono repo）とは 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 逆に、複数のリポジトリに分けている状態をポリレポ（poly repo）と言います。 モノレポのメリットとデメリット モノレポ化することで、以下のようなメリットが得られます。 プロダクト全体で統一したい設定、たとえばCIスクリプトやlinter設定などの管理が楽になる。 検索が楽になる。GitHubの検索で事足りること

研究開発部 Architectグループ ML PlatformチームのKAZYこと新井です。 名古屋の中部支店に所属しています。 普段はCircuitというアプリケーション基盤を作っています。 先日、チームメンバーと同じ会議室に集まり、業務とワークショップを行いました。 関西支店に集う 私たちのチームは現在5人です。 東京の本社所属が3人、中部支店が1人、関西支店が1人です*1。 各々が所属拠点に出社することはあれど、実際に顔を合わせて業務を行う機会はほとんどありません。 直近では、新しいメンバーの加入と数ヶ月に渡る育休から復帰*2という2つのイベントがありました。 少しでも早くチームに馴染んでもらえたら、という気持ちで1つの拠点に集まって業務を行う日を作りました。 表参道本社、関西支店、福岡支店、中部支店、Sansan神山ラボ...といくつかオフィスがあります。 今回選ばれたのは関西支店

Node.jsによるReverse Proxy実装をGoでリプレイスした話 技術本部 Bill One Engineering Unit（以下、Bill One EU）の川原です。23卒としてSansan株式会社に入社し、インボイス管理サービス「Bill One」の開発をしています。今回はNode.jsによるReverse Proxy実装をGoでリプレイスした話をします。 リプレイスしたReverse Proxy Bill Oneの機能の1つに、メールで送られた請求書をBill Oneが代理で受領する機能があります。 Bill Oneでは、SendGridという外部サービスを介してメールを受信しており、Cloud Run上のマイクロサービスへリクエストを送っています。 SendGridとCloud Run上のマイクロサービスの間には、SendGridからのWebhookイベントをプロキシす

iOSエンジニアの堤です。先日3月28日に開催された弊社主催のLTイベントで、「WhisperKitがだいぶ良いので紹介する」というタイトルで発表しました。 スライドはこちら： www.docswell.com 本記事は、同発表をベースとしつつ、（LTでは時間が足りないので）発表ではカットした内容を盛り込んで記事として再構成したものになります。 WhisperKitとは iOS/macOSオンデバイスで動く音声認識のすごいやつ デモ：標準の音声認識フレームワークSpeechとの比較 Speech WhisperKit なぜ速いのか - WhisperKitの系譜 OpenAI Whisper whisper.cpp Core ML とは whisper.cpp から WhisperKitへ argmax社とApple モデルサイズとメモリ消費量 各モデルのファイルサイズ一覧 メモリ使用量

こんにちは、Sansan Engineering Unit マスターデータグループの金子です。 私たちが開発しているシステムの中に、MongoDBを採用しているシステムがあります。私自身NoSQLを使用しているシステムの開発に携わるのは初めてなので、毎日いろいろな学びを得ています。 ある時、そのシステムで大量のデータをDBに書き込む処理を行うと、MongoDBのoplog関連のエラーが出てしまったことがありました。今回はその時の原因と対応について紹介し、MongoDBのoplogについて理解を深められた話をします。 環境 MongoDB 5.0 MongoDB Atlas 発生したエラー エラーの文言はこちらです。 PlanExecutor error during aggregation :: caused by :: Resume of change stream was not po

こんにちは、技術本部 Mobile Applicationグループで iOSアプリケーション開発しています。武田です。 2月29日にAppleから発表がありました。それは5月1日からPrivacy Manifestsに対応していないアプリはアップデートができなくなる、という内容です。これに向け、営業DXサービス「Sansan」のiOSアプリでもPrivacy Manifestsに対応中です。本記事ではその対応の詳細と対応中に詰まったことをご紹介します。 やることは大きく次の2つです。 1. アプリでPrivacy Manifests対応をする 2. サードパーティSDKをPrivacy Manifests対応バージョンに上げる*1 Privacy Manifests対応で何をするのか、その調査に関しては以前投稿した記事をご参照ください。 buildersbox.corp-sansan.co

こんにちは、Sansan Engineering Unit の渡邉です🦐 私たちのチームではTypeScriptで開発しており、テストはJestを用いて書いています。ある日からテストが結構な頻度で落ちてしまうように（FLAKY *1に）なっていました...。 そこで、テストがFLAKYになっている原因を深掘り調査したところ、Jestのメモリまわりについて解像度が高まったので、備忘録代わりに残します。 結論 Jestにおけるタイムアウトエラーとメモリエラー（Out Of Memory）を次のオプションを設定し、防止できました。 `jest.config.js` ... testTimeout: 30000, // タイムアウト時間を延長 workerIdleMemoryLimit: '1024MB', // ワーカーが使用できるメモリ上限を制限 maxWorkers: 4, // テストを

こんにちは、Sansan Tech Blog編集部です。今回は2016年に入社し、関西開発拠点の立ち上げを経て新規事業のプロダクト開発責任者となり、4月1日にSansan株式会社のエンジニア組織全体のマネジメント責任者であるVPoE（Vice President of Engineerの略）に就任した大西に、就任の経緯や今後の展望についてインタビューしました。 大西真央のキャリアパスなどの情報を集めたページはこちら sansan-engineering.notion.site ――VPoEに就任したきっかけや経緯を教えてください。 前任の西場がVPoEとして注力してきた評価制度や生産性向上に向けた環境改善、そして採用力の強化等により、技術本部は組織力を高めることができました。次のステップとして、自分の得意領域でもある「強くなった組織を大きくスケールさせる」フェーズに入ったこと、そして自分自

Digitization部 Bill One Entry*1グループの秋山です。 はじめに Domain Modeling Made Functionalというスゴ本 補講：Make Illegal States Unrepresentable バックエンドの処理を抽象化する 手続き型プログラミングの典型例 課題1：制約のないエラーハンドリング 課題2：低い可読性 課題3：エラーハンドリングの低い網羅性 Railway Oriented Programming TypeScriptで型安全にエラーハンドリングする ステップ1：サブ関数の出力はResult型で表現する ステップ2：サブ関数にResult型を入力できるようにする ステップ3：サブ関数を連結する ステップ4：網羅的にエラーハンドリングする おわりに 付録 TypeScriptの全文サンプル はじめに エラーハンドリングは重要な処

はじめに こんにちは！ 技術本部 Bill One Engineering Unit（以下、Bill One EU）の笹島です。 IaC推進チーム（横串チームの1つ）として、CI環境でのTerraform Planの自動化に取り組んできました。 横串チームとは、Bill One EU内の各グループの垣根のない横断チームであり、Bill Oneで抱えている課題を解決するために有志で集まったメンバーによって構成されています。 IaC推進チームとは、文字通りインフラのコード化を推進するチームです。 本記事では、CI環境でセキュアなTerraform Plan自動実行を実現するにあたって直面した課題とその解決策について共有します。 特に、モノレポ環境での複数プロダクト・環境の管理における自動化の課題についても紹介します。 目次 はじめに 目次 前提 ディレクトリ構成とその役割 Workload I

こんにちは！技術本部 Mobile ApplicationグループでiOSエンジニアをしている長﨑です。 Sansanアプリでは自分たちで定義したSwift Macrosを開発に導入し始めています。Swift Macrosについての勉強会も社内で実施しており、せっかくなので勉強会のコンテンツを記事にしてみます。 この記事では、Swift Macrosを開発するに当たって必要となる基礎知識からマクロの実装方法、CocoaPodsを使ったプロジェクトへの組み込み方法について、解説していきます。 Swift Macrosについての基礎知識 Swift Macrosって何？ Swift Macrosの種類 Swift Macrosには独立したモジュールが必要 Swift Macrosを開発してみる Swift Macros Packageを作る Swift Macros Packageの構成 マク