テックリードのポジションを設ける際に考えたこと - Sansan Tech Blog
はじめに Eight Androidチームのチームリーダーの山本です。 私たちのチームでは2024年6月から新たにテックリードのポジションを設け、2024年4月入社のメンバーにその役割を担ってもらっています。 それまでEight Androidチームに明確なテックリードのポジションはなく、チームリーダーである自身が暗黙のうちにその役割を兼務している状態でした。今回、新たにテックリードのポジションを設けるに当たり、考えたことをまとめます。 背景 これまでチームでは2つの取り組みでアーキテクチャの検討と、新技術導入や技術的負債の改善を行ってきました。 技術基盤改善 新技術導入や技術的負債の改善を行う 週に1回2時間の時間をかける チーム全員が作業する アーキテクチャ検討会 レビューなどで発生した汎用的な技術的な論点や、大きなアーキテクチャ変更の話題を扱う 週に1回2時間の時間をかける チーム全
HTML用ERBファイルのフォーマットを統一した話 - Sansan Tech Blog
こんにちは。 名刺アプリ「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 %
インボイス管理サービス「Bill One」の認証を内製認証基盤に置き換えて認証基盤のコストを削減した話 - Sansan Tech Blog
Bill One Engineering Unit 共通認証基盤チームの樋口です。 Bill Oneでは昨年までAuth0を認証基盤として利用してきましたが、認証基盤を内製化することでコストを大幅に削減しました。 この認証基盤は、昨年12月に無事リリースされ、Bill Oneの認証を支えています。 今回は認証基盤の内製化に至った経緯と設計、移行プロセスについて紹介します。 Bill Oneについて 認証基盤に関する課題 解決方法の検討 IDaaS（Identity as a Service）について 設計とシステム構成について 認証基盤の設計 システム構成 アカウントの移行について メールアドレス・パスワードでのログインを利用しているユーザーの移行 SSO（Single Sign-On）の移行 振り返りと今後 ドメイン変更による問い合わせの増加 内製化によって体験の改善がスムーズに Bil
エンジニア運用工数40%削減！Bill One における運用改善のとりくみ - Sansan Tech Blog
Bill One Engineering Unitの田上です。運用改善と題したプロジェクトによって、エンジニアの運用工数を半年で40%削減することに成功したので、今回はその取り組みをご紹介します。 背景 Bill One のエンジニアリング組織では、フルサイクルエンジアリングで開発と運用を行っており、開発者自身が運用対応（本番環境で発生したエラーの調査・対応、ユーザからの依頼・問い合わせの対応など）を行っています。 エンジニアが自身の開発したプロダクトへのフィードバックを迅速かつダイレクトに受け取れる非常に良い方式ではあるのですが、その対応工数があまりにも多くなりすぎて開発工数が逼迫するようになっていました。 その状況をどうにかするため半年の期限付き特命チームとして運用改善チームを立ち上げることにしました。 立ち上げ 組織内のフラストレーションの高まりを背景に、2名のエンジニアが新たなチー
マイクロサービスアーキテクチャのリポジトリ構成を漸進的にモノレポに移行した話 - Sansan Tech Blog
Sansan Engineering UnitでSansan Data Hubの開発をしている藤原です。 前回はニッチに深く潜り過ぎたので、今回は（使い古されたネタではありますが）モノレポ化についてお話ししたいと思います。 おさらい：モノレポ（mono repo）とは 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 逆に、複数のリポジトリに分けている状態をポリレポ（poly repo）と言います。 モノレポのメリットとデメリット モノレポ化することで、以下のようなメリットが得られます。 プロダクト全体で統一したい設定、たとえばCIスクリプトやlinter設定などの管理が楽になる。 検索が楽になる。GitHubの検索で事足りること
terraform planの自動化に向けて直面した課題と解決策 - Sansan Tech Blog
はじめに こんにちは！ 技術本部 Bill One Engineering Unit（以下、Bill One EU）の笹島です。 IaC推進チーム（横串チームの1つ）として、CI環境でのTerraform Planの自動化に取り組んできました。 横串チームとは、Bill One EU内の各グループの垣根のない横断チームであり、Bill Oneで抱えている課題を解決するために有志で集まったメンバーによって構成されています。 IaC推進チームとは、文字通りインフラのコード化を推進するチームです。 本記事では、CI環境でセキュアなTerraform Plan自動実行を実現するにあたって直面した課題とその解決策について共有します。 特に、モノレポ環境での複数プロダクト・環境の管理における自動化の課題についても紹介します。 目次 はじめに 目次 前提 ディレクトリ構成とその役割 Workload I
テックリードによる社内キャリアイベントを開催しました - Sansan Tech Blog
こんにちは。技術本部 Digitization部 Bill One Entryグループでエンジニアをしている大森です。 普段の業務に加えてTech道場というイベントの運営に関わっており、本記事はそのイベントのレポートです。 Tech道場とは、最新の技術や生産性を高める技術、そしてエンジニアの技術力に触れることを目的とした全社員向けの社内イベントです。*1 今回のTech道場では、主にエンジニアをターゲットとした企画として、テックリードによる社内キャリアイベントを開催しました。 イベントの概要 テックリードとして笹川・藤原・黒澤の3人が登壇し、新卒3年目のエンジニア、江川が3人にさまざまな質問を投げかけるパネルディスカッションイベントを開催しました。 ゲストの経歴は次の通りです。さまざまなバックグラウンドを持つメンバーが集まりました。 笹川 裕人 技術本部 Sansan Engineerin
生産性指標をFour Keysから変更した話 - Sansan Tech Blog
技術本部 Mobile Applicationグループの山本です。名刺アプリEightの開発を行っています。 今回はMobile ApplicationグループのEight開発チームの生産性指標をFour Keysからベロシティを含む別の値に変更した話をします。 一般的にはベロシティは生産性指標にすべきではない、Four Keysは生産性指標として適切であるという評価だと思います。もちろんそれは理解した上でこの選択をしています。その理由について説明します。 なお組織全体がこのように考えているわけではないということに御注意ください。例えば同じMobile ApplicationグループでもSansan開発チームはFour Keysを生産性指標にしています。 生産量2倍計画 現在技術本部では中期的な課題として1年で単月の生産量を2倍にするという目標を掲げています。 ポイントとして、技術本部のレ
Sansan Androidチームのライブラリアップデートの取り組みについて - Sansan Tech Blog
こんにちは。 この記事は、技術本部 Mobile ApplicationグループでSansan（※プロダクトとしてのSansan）のAndroid開発を行っている、桑原、小林、鎌田、原田の共著でお届けします。 今回は、アプリで使用しているライブラリのアップデートについて、 Sansanではどのようなポリシーで行っているのか そのポリシーを守るためにしていること そこから見えてくる課題 そして今後について をお話します。 Sansanにおけるライブラリアップデートのポリシー アプリで使用しているさまざまなライブラリは日々更新されており、機能の追加や変更、脆弱性の修正などが行われています。つまりアップデートを長期間放置していると、新機能を使えないことで開発生産性が落ちるなど、重大なセキュリティリスクを抱えることにつながります。 Sansan / Eightでは、お客さまの大切なデータをお預かり
全社横断データ基盤へdbt導入を進めている話 - Sansan Tech Blog
こんにちは。研究開発部 Architectグループの中村です。 本記事は Sansan Advent Calendar 2023 の16日目の記事です。 今回は、私達のチームで開発&運用している全社横断データ分析基盤のデータレイヤの再設計、及びdbtの導入を進めているという事例について紹介します。 既存のデータ基盤に対して、dbtの導入を検討されている方の参考になれば幸いです。 （本稿ではdbtとはについては触れませんので、ご了承ください） TL;DR 歴史的経緯 全社横断データ基盤が生まれる前 全社横断データ基盤 立ち上げ期 課題 立ち上げ期に作られたデータマートがカオスに・・・ 課題の解決に向けて データレイヤの再設計 Transformツールの選定 dbtへの移行戦略 その他dbt移行におけるTips チームでの開発の標準化 Cosmosの導入検証 データカタログのホスティング まと
入社して1年半の間に先輩が5人育休に入った話 - Sansan Tech Blog
自己紹介 こんにちは。名刺メーカーDevグループの伊藤惇です。 私は2022年4月にSansanに新卒として入社して、現在に至るまで名刺データの作成および印刷発注をするサービスの開発に携わっています。 名刺メーカーDevグループでは、偶然タイミングが重なったこともあり、私が入社してからこれまでの間に5人が育児休暇を取得しました。 そうした中で感じた育休に対する考え方の変化を振り返りたいと思います。 なお、本記事はSansan Advent Calendar 2023の14日目の記事です。 名刺メーカー育休スケジュール 名刺メーカーDevグループの規模感 チームの人数やプロダクトのフェーズによっても育休のインパクトが変わってくるので、私が所属する名刺メーカーDevグループの規模感について補足しておきます。 チーム人数 後述するAさん、Bさん、Cさんの育休取得時は約15人ほどのチームでした。そ
自宅ルータの脆弱性検知システムの開発 - Sansan Tech Blog
Sansan 技術本部 情報セキュリティ部 CSIRT グループの川口です。 2023年4月からセキュリティエンジニアで新卒として、Sansan に入社しました。 現在は ログ基盤（SIEM）のログの取り込み部分の機能修正、問い合わせ対応、インシデント対応などの業務に取り組んでいます。 今回は内定者インターンシップで開発した、自宅ルータの脆弱性検知システムについて紹介します。 目次は以下の通りとなります。 開発に至った経緯 作成したシステム 技術的な話 EDR ポートスキャン チケットシステムへの起票 SOAR まとめと今後の課題 開発に至った経緯 新型コロナウイルスの流行に伴い、リモートワークという言葉をよく耳にするようになったと思います。 弊社でも緊急事態宣言下においては、原則リモートワークとなり、現在はオンライン・オフラインを併用した働き方をしています。 ここで問題となってくるのが自
TerraformによるAirbyteを利用したデータ基盤へのデータ連携とCI/CD - Sansan Tech Blog
こんにちは！「Sansan Summer Internship 2023」でインターンをしていた野首侑作です（X, Facebook）。R&D Architectグループに1ヶ月強コミットしていました。今回のインターンで使った技術はこれまで全く触ったことがありませんしたが、チームメンバーのサポートもあり本番環境でも動かせるコードを書くことができました。 今回学んだことの整理と、Sansanのインターンで学べることの多さを共有したいという意味を込めて、社内ブログでアウトプットしようと思った次第です。 目次 目次 はじめに ローカルでAirbyteの立ち上げ 1. DockerによるAirbyte serverの起動 2. Sourceの登録 3. Destinationの登録 4. Connectionの登録 5. 接続確認 TerraformによるIaC IaCとは Terraformとは
TypeScriptプロジェクトにスキーマ駆動開発を持ち込み、より型安全な世界へ - Sansan Tech Blog
Bill One Entry*1グループの秋山です。 本題に入る前にお知らせです。9/12 (火) にTypeScriptを活用した型安全なチーム開発をテーマとしたイベントを開催します。 ぜひ、お気軽にご参加ください！ sansan.connpass.com 1. はじめに 1-1. スキーマ駆動開発とは 1-2. Testing Trophyとの関係性 2. 構成 2-1. 最初の構成と課題 2-2. 最終的な構成 3. バックエンド 3-1. スキーマから型ファイルを作る 3-2. APIハンドラに型を与える 3-3. バリデーターを追加する 3-4. huskyでスキーマ変更を検知する 4. フロントエンド 4-1. スキーマからAPIクライアントを作る 5. パターンマッチングを持ち込む 6. まとめ 1. はじめに 1-1. スキーマ駆動開発とは 詳しい解説は他の記事に譲り、一言
2023年 研究開発部 新卒技術研修 ~ 実践編 ~ - Sansan Tech Blog
こんにちは、研究開発部 Architectグループの藤岡です。 4/26（水）〜 4/28（金）で研究開発部内の技術研修を行ったので、その内容を公開します。 目次 目次 研修の目的 研修の概要 実践編の概要 アプリケーションを作成 バッチを作成 gokartとは パイプラインを実装 APIを作成 FastAPI とは APIを実装 ディレクトリ構成 実行 Webアプリを作成 Streamlitとは Webアプリを実装 Docker化 デプロイ ECRにイメージをプッシュ アプリケーション基盤 Circuitについて アプリのマニフェストを作成 研修終了後 終わりに 研修の目的 この研修の主な目的は、新卒社員がスムーズに業務に入れるようにすることです。 研究開発部にはさまざまなバックグラウンドを持つ研究員が入社するため、チーム開発の経験がない方もいます。 そのため、Gitの操作やプルリクエス
自社OCRエンジン「NineOCR」の学習効率化のため SageMaker Training を導入した話 - Sansan Tech Blog
はじめに NineOCR とは NineOCR が抱える課題 Amazon SageMaker Training とは SageMaker Training の始め方 事前準備 AWS が提供しているコンテナイメージを拡張する方法 独自のコンテナイメージに SageMaker Training Toolkit をインストールする方法 スクラッチでコンテナイメージを作成する方法 まとめ 学習ジョブの実行 学習結果の確認 終わりに はじめに こんにちは、研究開発部の石井です。 本エントリーでは、弊社の OCR エンジン「NineOCR」の開発フローに SageMaker Training を導入した話を紹介します。 NineOCR とは NineOCR は Sansan が独自に開発した名刺特化の OCR エンジンです。 名刺をデータ化するフローの中で実際に活用されており、タスクの高速化・高精
BERTopic で文書のクラスタリングを試す - Sansan Tech Blog
こんにちは。研究開発部の青見 (@nersonu) です。 そろそろ花粉症の季節ですね。週1でしか出社しない私は、なんとか引きこもって数ヶ月しのぎたいところです。 さて、今回は BERTopic という OSS について、さっくりとした手法の解説もしつつ、簡単に文書のクラスタリングを試そうと思います。 github.com 目次 目次 BERTopic とは 文書の埋め込み 文書のクラスタリング トピック表現 手法の概要まとめ BERTopic を試してみる インストール モデルのロード クラスタリングの実行 結果の確認 トピックごとの単語の重要度 トピックごとの文書を眺めてみる 次元削減手法・クラスタリング手法の変更 使ってみての所感 BERTopic とは BERTopic はいわゆるトピックモデリングを行うための OSS です。 トピックモデルは、文書集合から「トピック」は何が含まれ
Sansan Data Hub・Bill Oneアーキテクト対談：事業を支えるシステムの設計方針を公開【前編】 - Sansan Tech Blog
社内に蓄積された顧客データを整理・統合し、マーケティングに最適なデータに進化させる顧客データ統合サービス「Sansan Data Hub」。そして、あらゆる請求書をオンラインで受け取り、請求書受領から月次決算を加速するインボイス管理サービス「Bill One」。いずれも急成長を遂げており、Sansan株式会社の事業の柱になっているサービスです。 これらのサービスは、データの処理効率やシステムの信頼性などを向上させるために、さまざまなアーキテクチャの工夫が行われています。今回は「Sansan Data Hub」と「Bill One」それぞれの開発の中核を担う千田智己と加藤耕太にインタビューし、前後編の2回に分けて記事化。前編では、両サービスのアーキテクチャ設計の工夫や思想について語ってもらいました。 【Sansan Data Hub】アーキテクチャ解説 ――「Sansan Data Hub」
レイヤードアーキテクチャを振り返る - Sansan Tech Blog
こんにちは、Sansanプロダクト開発部の清水です。 ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。 そもそもレイヤードアーキテクチャって何? 概要 一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。
Eight における AWS Backup - Sansan Tech Blog
技術本部 Eight Engineering Unit（社内通称：Eight EU）の秋本です。普段は Eight をインフラ面からお世話することでご飯を食べています。 酷暑が続いていますね。酷暑は人々の健康を害し、健康が害されると稼動可能な人員が減り、人員が減ると業務負荷が増え、業務負荷が増えるとオペミスが発生しやすくなります。オペミスが発生してもバックアップがあれば最悪なんとかできる事が多く、もはや運用作業にはバックアップ取得が欠かせぬものとなっています。 本項では Eight におけるバックアップ取得の前史を述べ、そのうえで AWS Backup を導入していい感じになった風景を述べるものになります。 AWS Backup 導入まで Eight で使用しているデータの置き場所は以下があります。Eight では現状 AWS のみを使用しています： サービス 用途 S3 名刺画像データ、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
