サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
やろう!確定申告
buildersbox.corp-sansan.com
Contract One Dev グループの井上です。本年もどうぞよろしくお願い申し上げます。 私たちのチームでは、先日、「Contract One Cheat Day」と銘打って社内ハッカソンを開催しました。 社内ハッカソンの内容については、社内ハッカソンを開催したら、止まっていた改善が色々進んだ話: Contract One Cheat Day - Sansan Tech Blogをご覧ください。 本記事では、そんな社内ハッカソンにおける取り組みの一つ、”Zod導入”について書いていきます。 Zodの導入について Yupでいいんじゃない? Zodとは、TypeScriptファーストのスキーマバリデーションライブラリです。類似のライブラリとしては、以前から広く使われているYupが挙げられます。Contract Oneでも、これまでYupを採用してきました。 Zodは比較的新しいライブラリ
こんにちは。技術本部Bill One Engineering Unitの豊田(@helloyuki)です。Bill One 開発 Unit ブログリレー2024 Vol.10、Sansan Advent Calendar 25日目の記事です。実は1pxの微妙な画面上のズレが気になって仕方のないタイプです。 私自身はこれまでのキャリアでは、ほとんどバックエンドエンジニアとして過ごしてきました。正確にはバックエンドを主軸としつつ、多少のフロントエンド、クラウドインフラの構築、データエンジニアリングの経験も含みます。それぞれの領域に詳しい詳しくないは多少ありつつ、世間的にいうフルサイクルエンジニアとしてのキャリアを歩んできました。 Bill Oneでは各チームに配属後、ソフトウェアエンジニアは基本的にはフロントエンド、バックエンド、インフラ関係なく、すべての領域の開発を一通り担当します。私も最近
はじめに Bill One 開発 Unit ブログリレー2024の第7弾になります! 技術本部 Bill One Engineering Unit 兼 情報セキュリティ部 CSIRTグループの茂木です。 現在は「かにかん」という名前のチームに所属しており、PdL1という役割を担っています。 日々プロダクト開発だけでなく、CSIRT2兼務者としてBill Oneのセキュリティ向上にも取り組んでいます。 今回は、セキュリティ向上施策の1つとしてBill OneにDependabotを導入して脆弱性を管理できるようにした話、Bill Oneの技術構成だからこそ起きた問題について紹介します。なお、本記事はSansan Advent Calendar 2024の21日目の記事です。 目次 はじめに 目次 背景 Dependabotとは Dependabot alertsの導入 解決策 1: Depe
こんにちは!技術本部 研究開発部 Architectグループの宮地です。1年ぶりのブログ投稿になります。私は23卒として入社し、気づけば 2年目も終わりに近づいています。月日の流れは本当に早いですね。 さて、最近のトピックスとして、年明けから中部支店に異動となりました!大学時代を愛知で過ごしていたこともあり、地元に戻れるのはとても嬉しいです。 中部支店については、先日のアドベントカレンダーで新井が詳しく紹介していますので、そちらをご覧ください。 buildersbox.corp-sansan.com 今回はDatadogを使ってKubernetes(EKS)のMetricsを取得する際の備忘録をまとめます。Datadogは公式ドキュメントが非常に充実していますが、あちこちに情報が散らばっているため、自分たちの実践例も交えながら一元的に整理しました。 本記事はSansan Advent Ca
2024年10月9日、Sansan株式会社はイベント「VPoEの視点で見る組織の進化 〜組織変革とグローバル連携、次世代リーダー育成の戦略〜」を主催しました。イベント会場となったのは、JR渋谷駅に隣接する渋谷サクラステージ。弊社は2024年9月30日に同所へとオフィス移転したのですが、オフィスでのイベント開催は移転後初でした。オフライン&オンラインのハイブリッド形式で開催いたしました。 本イベントでは、キャディ株式会社とSansan株式会社、株式会社メルペイの3社のVPoEが登壇。それぞれ異なる事業モデルや事業フェーズ、開発組織の構造・規模の中で、マネジメントに向き合う3者が、組織変革やグローバル化、ダイバーシティ推進、次世代リーダー育成における実践や課題などをディスカッションしました。今回は、イベントのレポートをダイジェストでお届けします。 <スピーカー> キャディ株式会社 Drawer
はじめに 開発環境のご紹介 dbt run テスト dbt run によって生成されたデータは一定期間で削除する必要がある 開発の影響があるモデルだけテストしたい GitHub Actions を使いたい まとめ はじめに こんにちは。技術本部研究開発部 Architectグループの田辺です。本記事は Sansan Advent Calendar 2024 の 1日目です。弊チームでは新規dbtモデル開発時に dbt run を検証環境で検証してから本番環境へ反映させていました。検証環境にあるデータ量は少なく、ソースとなるプロダクトデータを模したものも検証用のものであるため、そこで期待通りに動作しても本番環境にリリースしてから期待通りでない動作になることがありました。例えば、エッジケースによるデータの不整合・ファンアウトの発生・実際のデータ量に対してはパフォーマンスの問題があるクエリなどが
Bill One Entry*1の秋山です。 本題へ入る前にお知らせです。12/23、TypeScript を活用した型安全なチーム開発をテーマにイベントを開催します。弊社社員のうち、TypeScript を日々の開発で活用しているメンバーが登壇します。ぜひお気軽にご参加ください。 sansan.connpass.com はじめに モジュラーモノリスとは 保守性が低いとビジネスに悪影響を与える 技術的負債と開発生産性 コード品質とビジネス影響 モジュール分割の方針 方針1:モジュールにDBテーブルを専有させる 補遺:モジュラーモノリスとNoSQL 方針2:モジュール内をレイヤードアーキテクチャとして構成する 方針3:ESLint ルールによって実現する TypeScript 開発にモジュラーモノリスを持ち込む ステップ1:単一のエイリアスを設定する ステップ2:ESLint ルールを設定す
技術本部 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 モデルサイズとメモリ消費量 各モデルのファイルサイズ一覧 メモリ使用量
技術本部 Mobile Applicationグループ所属の大塚です。 名刺アプリ「Eight」のAndroidアプリの開発と、営業DXサービス「Sansan」とEightの両プロダクトをまたぐプロダクト横断チームの一員として、モバイル領域の中長期的な技術的課題の解決や、PoCの開発を担当しています。 今回は、昨年9月にリリースしたEightのタッチ名刺交換機能の品質調査でBigQueryを利用する機会があったため、弊社の事例を参考に分析方法を共有します。 jp.corp-sansan.com タッチ名刺交換とは、Eightのアプリを開いた状態で、同じくEightのアプリを開いた他のAndroid端末やiOS端末と自端末をタッチすることで、デジタル名刺が交換できる機能です。 その際に、Bluetooth Low Energy(以降BLE)を用いたタッチの検出や、デジタル名刺の交換に必要な通
次のページ
このページを最初にブックマークしてみませんか?
『Sansan Tech Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く