inSmartBank

B/43を運営する株式会社スマートバンクのメンバーによるブログです

『B/43 TECH TALK 〜 「お金の使いすぎ」を防ぐ新しい家計管理機能開発の裏話〜』を開催しました

Culture Engineering

2024年4月、『B/43 TECH TALK 〜 「お金の使いすぎ」を防ぐ新しい家計管理機能開発の裏話〜』と題してイベントを開催し、約60名の方に参加いただきました。ご参加いただいたみなさま、ありがとうございました！

スマートバンクが3月に発表した「お金の使いすぎを防ぐ新機能」は、週ごとの支出をリアルタイムで管理し、使いすぎに気付けるようにするサポート機能です。

物価上昇が続く中、全体では約5割、20代に至っては約7割の家庭がつけている家計簿ですが、「使った結果を見るツール」になってしまうと使いすぎは防げません。 「週単位で予算や支出を調整できるようにしたい」というB/43ユーザーの声に応え、「使いすぎを防ぐ」家計管理サービスへとアップデートを目指してリリースしたのが今回の新機能です。

▼ プレスリリース

家計簿プリカB/43、お金の使いすぎを防ぐ新機能を提供開始

本イベントでは、新機能開発の裏側を、エンジニアリングとプロダクト開発の両面から深掘りしました。

前半は開発にまつわる技術的な知見をお届けし、後半は開発に携わったPM・エンジニア・リサーチャー・デザイナーのパネルディスカッションを通して、どのように開発を進めてきたのかを話しています。

この記事では、当日参加できなかった方やイベント内容を見直したい方に向けて、アーカイブ動画、LTの資料、トークセッションの内容をご紹介します。

▼ アーカイブ動画を公開しました！当日ご都合が合わなかった方も、ぜひご視聴ください。 www.youtube.com

B/43の「お金の使いすぎを防ぐ新機能」とは？

本来であれば、家計簿をつけることで支出をコントロールしたいはず。 ですが、家計簿利用の実態を見てみると、「お金を使ったあとに眺める」使い方に留まっている様子が見えてきました。

「すべての人が何も考えなくても自然と支出をコントロールできる方法はないだろうか？」

そんな仮説のもと開発したのが、お金の使いすぎを防ぐ新機能です。 具体的には、2つの新機能をリリースしました。

新機能① 支出ペースグラフ

1つ目は、お金を使いすぎるとグラフの色が変わる支出ペースグラフです。 前月や予算に対して、支出が多くなっていることが一目でわかります。

新機能② 使いすぎ通知

2つ目は、支出ペースが早い時に届く使いすぎ通知です。 毎週月曜の朝、使いすぎたカテゴリがあった場合にお知らせが届くようになっています。パートナーにも伝えてくれるので、2人でその週の家計管理ができるようになります。

【LT①】アプリエンジニアに聞く、複雑な要素を持つ支出グラフのUI開発

はじめに、「複雑な構成要素を持つUIとの向き合い方 〜新・支出グラフでの実例〜」と題して、アプリエンジニアのnakamuuuさん（@chickmuuu）がLTを行いました。

これまでも、B/43 には毎月の支出を把握するための「まとめ画面」が存在しましたが、今回のアップデートで「支出画面」としてリニューアルしました。全体の支出をカテゴリごとに区切って見せる円グラフから、予算や前月に対する支出の状況を見せる折れ線グラフへの変更です。

ただ、折れ線グラフになったことで、多くの構成要素が含まれる複雑なグラフになりました。

LTでは、「構成要素の定義」「 データソースの設計」「 インタラクションの整理」に分けて、どのように実装していったのかを紹介しています。

▼ 詳細はぜひLTの資料をご覧ください！

アプリエンジニア・nakamuuu（@chickmuuu） speakerdeck.com

【LT②】サーバーサイドエンジニアに聞く、プロトタイピングの裏側

次に、サーバーサイドエンジニアの大庭さん（@ohbarye）が、「プロトタイピングによる目的不確実性の低減」と題し、プロトタイピングを通じて意思決定を進めた事例を紹介しました。

支出ペースグラフのモックアップ（プロトタイピングに対して、動かない模型のようなもの）だけだと、使いすぎの判定ロジックやユーザー課題を解決するための具体的な要件がわかりません。

そこで、初手として机上でのシミュレーションを行ってみますが、静的な情報だけでは体験の良し悪しを判断できない部分が出てきました。

動くものがなくてわからないなら、「動くもの＝プロトタイプ」をつくればいいということで、CodeSandboxで約300行のコードを書き、プロトタイプをつくりました。かかった時間は半日程度。そこに実データを入れることで実際の動きが見えるようになり、検証の材料を揃えることができました。

▼プロトタイピングでどんな意思決定をしたかは、ぜひLTの資料をご覧ください！

サーバーサイドエンジニア・大庭（@ohbarye） speakerdeck.com

参加者の方からいただいたご質問にもお答えしました。

Q　グラフUIのモックアップがPMやデザイナーから提示された時のファーストインプレッションは？

nakamuuu）アプリエンジニアの頑張りどころなのでテンションが上がりました（笑）ただ、返金や支出がマイナスになるなど、イレギュラーな動きがあったときにグラフが壊れないかという不安があったので、実データを入れて検証しました。

ohbarye）最初に気になったのはパフォーマンス面です。図を描画するためのデータは、B/43のなかでもデータ量がかなり多い取引データをもとに算出します。そのため必要な数字を合理的な時間でちゃんと返せるかが気になっていました。こちらも実データでパフォーマンスの検証をしてクリアしています。

Q　APIのレスポンスデータ構造の設計はどう進めましたか？

nakamuuu）自分でタタキとなる案をつくる→サーバーサイドエンジニア（@ohbarye）に相談→2つのデータ構造を出してもらう→JSONで書いてみる→暗黙的な制約が少ないのはどちらかを議論、という流れで進めました。

ohbarye）僕が出したのは、サーバーサイドの実装が楽になるシンプルなデータ構造のアイデアです。ただ、nakamuuu さんからの指摘で気付いたのが「暗黙的な期待が前提にある」ことでした。たとえば、フィールドAがnullになったらフィールドBもnullになるであろうという期待です。議論を経て、暗黙の前提をなるべく無くしていくことを判断基準にし、最終的な意思決定をしました。

そのような暗黙の前提があると別の人が実装したときに壊れやすくなるだろうと、拡張可能性を考慮し、議論しながら設計を進めました。

Q　どんな内容をどの粒度でドキュメントにしていますか？

ohbarye）これはドキュメントマスターの nakamuuu さんに（笑）

nakamuuu）特別なことはしていないのですが、LTでお話しした構成要素の分解、データソースの表現、インタラクションの整理についてはドキュメントにすべて書き起こしています。

また、実装の際も、Android / iOSともにGitHubのIssueだけ見て進めれば挙動の差がでないくらいまで、細かくタスクを分解して記述しています。

前提として考えなければいけないことはFigmaやNotionを使って整理し、開発する際のチケット管理にはGitHubを使っています。

Q　バックエンドの集計のパフォーマンスは、初手から許容範囲内でしたか？　何か工夫が必要でしたか？

ohbarye）調査をして2つの問題が見つかりました。

一つは、決済データ量がもっとも多いお客様のデータでテストをした時に、データベースに投げて返ってくるまでのクエリ1つに100msくらいかかったことです。本来であれば10~20ms程度を期待していました。自分のデータでは問題ないけれどデータ量の多いユーザーだと問題が起きてしまう原因を調査したところ、インデックスが不足しており計算量の増加が線形だと判明しました。こちらについては適切なインデックスを貼って解消し、過去の決済データ量の多寡は問題にならなくなりました。

もう一つの問題が、一つ目の問題とは別原因で、既存のとあるAPIのレスポンスタイムが今回の改修により20%ほど長くなってしまったことです。ただ、体験上は違和感のない許容範囲内におさまっていたのでまずは様子見してみよう、とそのままリリースしました。リリース後も99パーセンタイル値で見ても許容範囲に収まっていることがわかったので特に対応はしていません。最適化する場合はコードが複雑になるというトレードオフもあったので、コードが簡単で許容範囲に収まる形となりました。

【LT③】スマートバンクの開発風景

「どんな感じで開発を進めているんですか？」

カジュアル面談でもっとも聞かれる質問です。 イベント後半では、この質問にお応えするため、PMのjou（@jouykw）さんがスマートバンクの開発風景を紹介しました。

スマートバンクでは、各案件ごとに、企画・開発・ユーザーコミュニケーションを担う3つのチームが並列で動きます。

▼ 開発の全体像

Kick Offでは、我々がどこを目指しているかの目線合わせや、過去のプロジェクト経験の中で最高・最低だった経験を書き出してもらい、プロジェクト運営で大事にすべき「ワーキングアグリーメント」を策定します。今回は、プロジェクトメンバーが好きなタコスを食べながらエンジニアリングを学ぶ決起会も開催しました。

その後、ユーザーストーリーやFigmaの画面要件をベースに、要件やシステム設計を詰めていきます。

実装は、毎朝実施しているエンジニア朝会でやることを共有・相談しながら進めます。週1回のオフィス出社推奨日には、複雑な設計・実装箇所を対面で議論します。

リリース前にユーザビリティテストを実施し、ユーザーからいただいたフィードバックをもとに対応可否や改善方針を議論します。

無事リリースした後は、ユーザーの反応を定量・定性で見て想定通りの成果が得られたかを検証する流れで進めています。

▼ より具体的に開発風景を知りたい方は、LT資料もご覧ください！

PM・jou（@jouykw） スマートバンクの開発風景 - Speaker Deck speakerdeck.com

Q　要件定義やシステム設計でNotionやFigmaを使う際、両ツールのデータをどのように同期していますか？

jou）Notion側のPRD（＝仕様要件。スマートバンクでは、仕様書 + なぜこの開発をするのかの情報をまとめたものをPRDと呼んでいます）はPM、Figma側の画面要件はプロダクトデザイナーが受け持っています。

仕様が詰めきれていない要決定事項をリスト化したデータベースをPRDに埋め込み、要決定事項の結論が出たらNotionに書き込んでいきます。PRDとFigmaに反映されたらチェックを入れる仕組みにし、仕様要件と画面要件とが常に同期され続けるような運用にしています。

トークセッション

「開発の進め方」「目玉機能グラフのデザイン」「ユーザビリティテストの活用」の3テーマに分けて、トークセッションを行いました。

開発の進め方

はじめに、開発を担当したサーバーサイドエンジニアのkoshibaさん（@chobishiba）とosyoyuさん（@osyoyu）に、スマートバンクの開発裏話を聞きました。

koshibaさんが担当したのは、お金の使いすぎを週次でチェックし、使いすぎていたらプッシュ通知を送る「使いすぎ通知機能」です。開発する中で印象的だったのは、プッシュ通知のメッセージを大きく変更したことだったといいます。

koshiba）最初は、ユーザーの利用状況によって通知の内容を細かく変える想定でした。ただ、お知らせに使う用語についてアンケートを取っていた時、チームメンバーが「”予算達成の目安”という言い方が売り上げや営業の目標値に見えてきた」と言っていたんです。

それを聞いて、確かにプレッシャーと感じる言い方になっているかもしれないと思いました。受け取ったユーザーの目線を忘れていたことに気が付いたんです。

通知のタイミングでは「何かヤバそう」ということが伝わればよいので、どんなケースでも「支出ペースが早いかも？」のメッセージに統一し、何がオーバーしているかは箇条書きで表示することにしました。

被害妄想かもしれませんが、お金を多く使った翌週に「確認しましょう」と言われると怒られているような気がするので……（笑）今の形なら、通知が来ても「どういうことだろう？　アプリ見てみるか」と思えます。

一律で同じ文言にしたので、メッセージの分岐もなくなり、実装もものすごくスッキリしました！

続いて、サーバーサイドエンジニアのosyoyuさんに「特別費の計算外サジェスト機能」について聞きました。

車を買ったり、飲み会の立て替えをしたり、特別費とよばれる「家計に入れるべきでない大きな支出」が発生することがあります。これらを家計管理に組み込んでしまうと、「これがあったから今月は予算オーバーでもOK」という状態が恒常化し、家計管理が崩壊してしまいます。なので、家計管理を維持するために、「これは特別費のようなので計算外として扱ったらどうか？」とサジェストするのがこの機能です。

サジェストするラインとなるしきい値は、ローデータを見ながら愚直に決めていったそうです。また、集計作業をオンライン（アプリの支出画面を開くたびにサーバーサイドで計算する）で行うか、オフライン（日次などでまとめて計算しておく）で行うかの選択にも迫られたそう。

osyoyu）将来的には機械学習を用いたより計算量の多いロジックに作りかえ、しきい値を設定する可能性もあります。そこまで見据えてどうするかの判断に迫られました。結論としては、今回の範囲であればオンラインでも十分に実装が可能で、高頻度に画面を見るわけではないユーザーの使い方をふまえても、オンラインでの実装が望ましいという判断になりました。

目玉機能グラフのデザイン

トークセッション第2部には、プロダクトデザイナーのputchomさん（@putchom）が登場。家計管理機能の目玉である「グラフのデザイン」をテーマに話しました。

一般的な家計管理アプリは、予算オーバーしたことを月末に教えてくれるものが多いですが、本来であれば、月の途中で振り返りや改善ができることがベストです。年間100件以上行っているユーザーインタビューでも「支出ペースを把握して改善したい」というご要望を多くいただいていました。

通常は、ユーザーがたどる体験の各点でUIのモックアップを作りますが、実際は、すべてのユーザーが想定される直線的な体験を通るわけではありません。月間を通してさまざまな状態を持つグラフになるので、その検証が難しかったといいます。

putchom）いろんなユーザーがいろんなタイミングでいろんな状態で見ているのが前提です。なので、ユーザーのセグメント、状態、時間軸など、さまざまな軸でペルソナを作り、それぞれのユーザーが30日間でどのような消費行動をするかを想定しながら、グラフの見え方や通知が届くタイミングを検証していきました。

こうした検証を行なった結果、今まで見えてなかった様々なユーザーに思いを巡らせることができ、体験上の問題点や改善点を洗い出すことができたといいます。筋の良いモックアップは、このような地道な検証から生まれています。

また、SNSでも話題になった、支出が目安や予算を超えた時に札束の絵文字が画面上を舞う表示体験についても聞きました。

putchom）ユーザビリティテストを行った際、「グラフの色の変化だけだとどんなことが起きているか想像しづらい」というフィードバックをいただきました。そこで、グラフの色が変わる瞬間に絵文字を飛ばすことで、どういった変化があるのかをエモーショナルに伝えることにしたんです。

スマートバンクのデザイン原則の一つに「フックを作る」というものがあります。情報が溢れる現代においては、より印象的で伝わりやすいメッセージを発信することが求められます。そのため、「目的と情報と表現が合致しており、なおかつ感情を動かすエモーショナルなデザインやシェアしたくなるような仕掛けを考えましょう」というものです。

ただし、フックを作る部分は、使いやすさやシンプルさの先にあるものです。単純におもしろければいいというものではありません。ですが、ネガティブになりがちなお金の話を少しでもポップに楽しくしていけたらと考え、お札や炎を飛ばす体験を採用しました。

ユーザビリティテストの活用

最後は「ユーザビリティテストの活用について」というテーマで、リサーチャーのHarokaさん（@mawarisuru）とモバイルアプリエンジニアのkanekoさんにお話を聞きました。

Harokaさんとkanekoさんは、ユーザービリティテストの設計と運営を担当。リリース前の約1ヶ月の期間を使い、プロジェクトに関わりの薄い社内メンバーや内定者などを中心に、クリティカルな課題がないかを確認するユーザービリティテストを実施しました。

今回、特に印象に残ったのは支出グラフの利用店舗表示だったといいます。

Haroka）グラフの数値が上がっている時に「何に使ったっけ？」という発話とともにその日の決済を探しにいく様子が見てとれました。ただ、人によってはホーム画面に行ったり、タイムラインをさかのぼったり、最も使っているカテゴリから推測してみたり……。

私たちが大事にしたい体験として「支出行動の振り返り」がありますが、興味は引くものの、理由を探す導線がなめらかではなく、場合によっては満足度にも影響していることがわかりました。

ユーザビリティテストでいただいたフィードバックの内容はNotionのデータベースに保存され、すべてのテストが完了したタイミングで、プロジェクトメンバー全員が参加する振り返り会を行います。リリースの遅延が必要になるクリティカルな課題はありませんでしたが、リリースまでにできる対応がないかを議論し、決めていきました。

kaneko）「支出を振り返る」ための機能案については、プロジェクトメンバーがオフラインで集まる日に、案出し→デザイン起こし→実装とクイックに議論し決めていきました。

最終的には、ユーザーがほしい情報は利用店舗の情報で、かつ、既存のグラフ用データのAPIに加盟店情報を加えるだけならデータ量的にも許容できるだろうということで、グラフ上に利用した店舗名を最大3つ表示する形に改善しました。

Q　QA担当が不在かと思うのですが、誰が責任を持って進めているのでしょうか？

kaneko）普段のアプリリリースではモバイルアプリエンジニアが責任を持つことが多いのですが、今回のような大きい機能だと、職務問わずチーム全員が責任を持っていく形になります。テストケースの作成は、モバイルアプリエンジニアとサーバーサイドエンジニアがそれぞれの観点で作成し、テストはチーム全員で行います。

当日参加してくださった方々の声

アンケート

  • プロダクト開発がしっかり回りアウトカムに繋がっている組織のプロセスを具体的に共有いただけたことは非常にありがたかったです。
  • 具体的な開発プロセスや普段の協業の仕方がイメージできる回でした。参加者からの質問に対してもとても丁寧に回答くださり、本当に学びが多かったです。
  • キックオフから打ち上げまで、とても楽しそうにやっているのが印象的でした！
  • 新機能の実装プロセスの裏話が聞けて面白かったです。特にユーザーの実際の声を聞いてUI改善に生かしている話や、要件を満たすだけではなくフックのあるエモーショナルなデザインを作るプロセスについての話が学びになりました。
  • 開発のプロセスや機能やUIの細かいところまでなぜそうしたのかを参考になったのと同時に自分自身開発時にここまで考えられているかを再考するきっかけになった。

X(旧Twitter)のポスト

▼ アーカイブ動画を公開しました！当日ご都合が合わなかった方も、ぜひご視聴ください。 www.youtube.com

おわりに

『B/43 TECH TALK 〜 「お金の使いすぎ」を防ぐ新しい家計管理機能開発の裏話〜』のイベントレポートをお届けしました。

技術面のケース紹介に加え、開発の裏側を覗き見していただく体験になっていれば嬉しいです。アンケートからも、実際に開発に携わられている方のお役に立てた様子がうかがえて安心しました。

スマートバンクの技術やワンチームで進める開発プロジェクトの動かし方が少しでも参考になれば幸いです。

SmartBankでは、サーバーサイドエンジニアを募集しています！ smartbank.co.jp

B/43の開発についてもっと話を聞いてみたい方は、カジュアル面談もご検討ください。 smartbank.co.jp

We create the new normal of easy budgeting, easy banking, and easy living.
In this blog, engineers, product managers, designers, business development, legal, CS, and other members will share their insights.