前置き スマートバンクが運営しているB/43事業は2021年のサービス開始から順調に成長し、月間の決済取扱高も数十億円規模を超えております。また、会社としても2024年の末に40.8億円という大きな額の資金調達も行ってきました。 しかし、「お金の悩みを解消し、よりよい人生を送れる未来を創る」というビジョンから逆算すると、ユーザーにとって価値を広げていく領域がまだまだあり、伸び代が大きいと考えています。 特に資産管理や中長期的な融資を含めた家計のサポート、そして非接触決済への対応は非常に重要であり、何としても今年中に機能として形にしようと考えています。このエントリーではスマートバンクだからこそできる、ユーザー中心の金融サービスを継続的に生み出していくために、CTOの @yutadayo がエンジニアと共に達成したい目標について技術的な視点から紹介していきます！ 1. 資産管理プラットフォーム

こんにちは、プロダクトマネージャーのmoretです。 この記事は スマートバンク Advent Calendar 2024 の3日目です。昨日はsugaの「Slackワークフローを使った社内業務連携と可視化」という記事でした。 今日の記事ではスマートバンクが公式HPでもトップに掲げるメッセージである「人々が本当に欲しかったものをつくる。」に関連して、ユーザーインサイトについてとスマートバンクがこのためにやっていることを書いてみました。 インサイトってなに？ プロダクト開発の現場において「人は自分が欲しいものを知らない」「ユーザーの意見を聞くな」などの格言は広く理解されるようになってきました。もし世の中がこのように進化してきていたら、いまごろ人々は通勤通学で駿馬にまたがっており、ドラッグストアでは馬の世話グッズが飛ぶように売れていたことでしょう。Umer Eatsのような馬がご飯を運んでくる

こんにちは。MySQLは秋の季語とする一派が世に存在していることを知り、私もMySQLに関わる記事を書いてみようと筆を取ることにしました。 さて、リレーショナルデータベースをバックエンドとするWebアプリケーション開発において、特定の条件に合致するレコードがN件だけ存在するかどうかを確認するロジックは頻出といえます。プログラマとして一度は書いたことがあるのではないでしょうか？ この記事ではそのような件数カウントを行うためのクエリが引き起こした性能劣化と、その改善アプローチについて紹介していきます。 なお、本記事の内容はMySQLを前提としており、アプリケーションコードの例はRuby on Railsを用いますが特別な前提知識は必要ありません。コードの雰囲気だけ感じ取っていただければと思います。 ありがちなコード if query.count == n の問題 冒頭で述べた通り、特定の条件に

YAPC::Hakodate 2024に参加してきたので感想です。人生初の函館が良かったので観光成分も多め。 YAPCについて 前回のYAPC::Hiroshimaに続いて今回が2回目のYAPC参加です。YAPC::Hiroshimaではプロポーザルが通ったのですが今回は通らずでした。 出したプロポーザルはこちら 3Dセキュア温故知新: Web認証技術の発展が切り拓いた現在地 by ohbarye | トーク | YAPC::Hakodate 2024 #yapcjapan - fortee.jp。同僚の id:yutadayo がクレカ製造技術ネタでめちゃめちゃ強いのを出して大バズしていたので会社としては問題ない...が、個人としては悔しい！ yuta.hatenablog.com 心に残った発表たちの個人的総括 ブース担当したり廊下で人と話したりでセッションは半分ぐらいしか聞けなかった

こんにちは！サーバーサイドエンジニアのkurisuです。 2024年06月に、B/43あとばらいチャージの裏側でサービス提供していただいている事業者の移行を行いました。その際、返済データのリコンサイルバッチの設計と実装を担当しました。 外部サービスとのデータ連携における不整合は、多くのシステムで避けられない問題です。 本記事では、B/43のあとばらいチャージ機能での事例をもとに、リコンサイルの重要性と実装時の検討ポイントをご紹介します。 リコンサイルとは 外部サービス連携における課題と不整合の要因 1. 自社から外部サービスへの通信エラー 2. Webhook通知の不達や遅延 外部サービスにおけるリコンサイルができる条件 リコンサイルバッチの実装時の検討ポイント 前提 1. 外部サービスとのデータの不整合箇所の洗い出し 2. データ量と処理時間/実行頻度 3. 不整合検知時の対応 4. エ

こんにちはスマートバンクでCTOをしております＠yutadayoです。5/15 ~ 17に RubyKaigi 2024 が開催され、スマートバンクはスポンサーをさせていただきました。 私個人としても久しぶりの RubyKaigi の参加でしたが、結論から言うとめちゃくちゃ楽しかったです、セッションを聞くこと、参加者と交流すること、スポンサー活動をすること、どれも楽しく充実した3日間でした。 今回もイベントへのスポンサーを通して様々なコミュニティイベントや広報企画を実施してきました。当日の感想も交えて、今回のスポンサーに関連して行った施策を振り返っていければと思います。 RubyKaigi に参加しスポンサーを行うこと カンファレンスに参加し、スポンサーを行うことには重要な意義がいくつか存在すると思っています。 RubyKaigi は Ruby に関する最も大規模な国際会議の場であり、多く

表題の通りRactorを用いたproperty based testingの並列実行についてRubyKaigi 2024で発表してきました。かつスピーカーとしての参加は初めてで、いろいろ稀有な体験ができて総合的にはめちゃくちゃ楽しかった。 発表内容について "Unlocking Potential of Property Based Testing with Ractor"という題で、property based testing（以下PBT）において発生する小さくて大量のタスクをRactorで並列実行させるというアイデアと仮説検証の結果を報告しました。 日本語のテキストで概要を知りたい方はTechouse社の記事をご参照ください。登壇者の自分が発信したどのテキストよりも丁寧にわかりやすくまとめてくださってます。この場を借りて感謝いたします！ developers.techouse.com

YAPC::Hiroshima 2024

こんにちはスマートバンクでCTOをしております＠yutadayoです。Kaigi on Rails 2023 が開催され、予定していたアフターイベントや各種SNSでの発信なども無事完了することができました。今回はこのタイミングで初スポンサーさせていただいた知見や、取り組んだ事例を振り返ったまとめ記事を紹介していきたいと思います。 想定する読者 テックカンファレンスでスポンサーする上での知見やノウハウなどが知りたい方 エンジニアが技術発信を促進する方法や取り組みについて知りたい方 スポンサーをする意義や効果について知りたい方 テックカンファレンスへのスポンサー背景 実はスマートバンクでは会社をあげてのスポンサー活動は今回が初めてになります。スポンサーする意義は各社様々かと多いますが、スポンサー活動をする前に下記のような課題を感じていました。 採用活動をする中で、スマートバンクや B/43 の

こんにちは！サーバーサイドエンジニアの mitani です。 B/43のサービスの裏側では機械学習を使っている箇所があり、機械学習用のパイプラインとAPIに全てSageMakerを利用しています。今回はなぜSageMakerを採用したのかと、構築時に意識したことについて紹介したいと思います。 インフラ視点でのMLOpsについては @maaaato さんが記事を書いてくれているので、合わせてご覧ください。 Amazon SageMaker StudioでMLOpsを始めました - inSmartBank 機械学習の推論を行う仕組みについて 機械学習の機能をアプリケーションに組み込むためには、大きく分けると3つの仕組みを準備する必要があります。 学習用のデータを作成して何かしらのデータストアに保存する仕組み 学習用のデータを使って機械学習のモデルを訓練し検証する仕組み 訓練済みのモデルを呼び出

イントロ こんにちは！SREを担当してます上平と申します。 このエントリーでは スマートバンクが提供する B/43サービスの裏側のデプロイシステムに関して紹介したいと思います！ 自分自身の振り返りも兼ねてどうして現在のデプロイシステムに至ったのかをお話ししたいと思います、これからデプロイシステムの構築を検討されている方の参考になれば幸いです。 RDBを使用したWebアプリのデプロイ方法を構築する中で、発生した問題にどう対処し、より安定したデプロイを行うようにしてきたかを紹介します。 想定される読者 RDBを用いたWebアプリケーションで Blue/Green デプロイを行なっている方 AWS CodePipeline をどう組むか悩んでいる方 デプロイにおいて実現したかった要件 環境構築当初、デプロイで実現したかった要件をまとめました。 サービスダウンタイム無く、デプロイが行えること 障害

Dependency Injection (DI) とは、オブジェクトに必要な依存関係を外から注入する設計パターンです。 本記事ではiOSアプリの実装をテーマに、DIがなぜ必要なのか、さらにはDI Containerとは何を解決するためにあるのかについて具体的な実装例をもとに解説します。 ※ 本記事は iOS Test Night #12 にて発表した内容を書き起こしたものとなっております。 speakerdeck.com Dependency Injection 依存を内部で初期化する書き方 依存性逆転の原則に従った書き方 DI Containerの基本 Daggerに学ぶ依存のライフタイム管理 SwiftUIアプリにおけるDI Containerの実装例 DI Containerの実装 Viewの実装 まとめ Dependency Injection Dependency Inject

先日開催されたKaigi on Rails 2023に「管理機能アーキテクチャパターンの考察と実践」というタイトルで登壇させてもらいました。発表資料はすでに公開しており*1、本記事で発表内容をそのままなぞっても新規性がないな〜と考え、発表前に行った"余興"や懇親会やXでいただいたフィードバックや質問について回答する記事としてみます。 余興について 本記事で初めて上記の発表を見知った方や、発表をオンラインで見られた方にとっては「余興って何？」という疑問が浮かぶかと思うので説明すると、今回は登壇前の転換時間に"前説"をセルフでやってみました。*2 お笑いの世界には前説というものがあります。 舞台でもテレビの収録でもお客さんがいる場合は、本番に向けて場を温めるために若手芸人やフロアディレクターなどが注意事項を伝えながら簡単なネタを披露することです。 ネタを交えながら注意事項等を説明し客席をいい空

最近エンジニアの異動について軽く議論することがありました。自分はチームの安定性の側面からやや否定的な立場だったのですが、その議論で刺激を受けて周辺領域も含めて考え直したところ、組織の成長という軸で色々な知識がつながって面白かったのでまとめてみます。 議論の前提 異動も含めてエンジニア組織について考える時、まずは外せない前提がひとつあると思います。それは、安定したチームないしバリューストリームを維持することです。「チームトポロジー」の3章では以下の言葉を引用し、複雑なシステムの開発にはチームの効果的なパフォーマンスが欠かせないことを論じています。 ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ。 現代のソフトウェア開発の変化速度や複雑性に対処するには個人では限界があり、チームとしての活動が欠かせません。チームメンバー間で強い信頼関

チームのマネージャーが、自らの責務をジョブディスクリプションとして明文化することは難しい。職務内容や権限を、断片的にしか書けないかもしれない。もしそうなるなら、実務も断片的になっている可能性がある。 チームマネジメント（組織マネジメント）という活動は、個々のマネージャーの経験や関心によって、断片的になりやすいように感じている。断片的とは、マネジメント活動が、責務の一部の領域に偏ってしまっていたり、問題を検知してはじめてその領域がマネジメント範囲であることを知る、といった様子を指している。 このような状態になる背景は、マネージャーにとって、マネジメントが、日々の実務を通して蓄積された経験に基づく活動になっているからではないか。マネージャーは孤独だ。ひとりでその責務を担う。エンジニアとは違い、チームで協働するわけではない。だから、形式知として言語化されず、個人の経験として暗黙知にとどまる。その

こんにちは！SREを担当してます上平と申します。 このエントリーではAurora MySQL5.7互換からMySQL8.0互換への移行を実施した際の流れや学びに関して紹介したいと思います！ B/43 では Aurora MySQL5.7系をサービスリリースから使っており、Aurora MySQL バージョン2のサポート終了日（2024/10/31）が近づいているのもあったので、移行することにしました。 Amazon Aurora バージョン - Amazon Aurora これからAurora MySQL8.0へ移行を検討されている方の参考になれば幸いです。 想定される読者 Aurora MySQL 5.7系を使っていて、アップグレードを検討している方 実際の Aurora MySQL 8.0 への移行手順を知りたい方 AWS インフラに興味がある方 前提 Aurora MySQL5.7互

こんにちはスマートバンクのデザイナーのputchomです。普段は「家計簿プリカ B/43」のプロダクトデザインやデザインシステムの構築を担当しています。 先日、CreatorZineさんでプロダクトデザインに関するスマートバンクの連載記事を書かせていただいたのですが、今回はその中でお伝えしきれなかった「デザイントークンの設計」についてご紹介しようと思います。 デザイントークンとは？ そもそもデザイントークンとは、色、タイポグラフィ、サイズ、不透明度、影などのデザインをするための最小要素のことであり、スマートバンクではデザインの一貫性を保ったり、関わるメンバーがよりデザインに対する共通認識を持てるようにして、プロダクトの価値提供を早くするために定義しています。 まず完成形です。このあと説明する様々な工程を経て、以下のようなデザイントークンをJSONで定義しました。（すべて記述するとかなり長く

こんにちは！スマートバンクでサーバーサイドエンジニアをしている mitani です。 このブログでは、スマートバンクでサーバーサイドエンジニアの技術面接をどのように行っているのか、過去の方法と課題点、そしてアップデートした今の形について紹介したいと思います。 スマートバンクのバリューの一つBe Openに従って、このブログでは皆さんに公開できるギリギリまで我々の採用にかける姿勢をお伝えしようと思います💎 TL;DR スマートバンクの選考フロー 技術面接で確認したいこと 技術面接の流れ 過去のスキルチェックの内容と課題点 アップデートした内容 アップデートしてみて 終わりに TL;DR 技術面接では①仕様を漏れなく正確に理解する力、②仕様を理解しアプリケーションのモデルに落とし込む力の2点を重視しています 過去のスキルチェックのお題と問題点を公開します 限りある時間のなかでお互いのマッチン

章立て はじめに Docker・Container型仮想化とは Docker一強時代終焉の兆し Container技術関連史 様々なContainer Runtime おわりに 1. はじめに Containerを使うならDocker、という常識が崩れつつある。軽量な仮想環境であるContainerは、開発からリリース後もすでに欠かせないツールであるため、エンジニアは避けて通れない。Container実行ツール（Container Runtime）として挙げられるのがほぼDocker一択であり、それで十分と思われていたのだが、Dockerの脆弱性や消費リソースなどの問題、Kubernetes（K8s）の登場による影響、containerdやcri-o等の他のContainer Runtimeの登場により状況が劇的に変化している。本記事では、これからContainerを利用したい人や再度情報