inSmartBank

AI家計簿アプリ「ワンバンク」を開発・運営する株式会社スマートバンクの Tech Blog です。より幅広いテーマはnoteで発信中です https://note.com/smartbankinc

チームのProblemに全員で向き合うチーム作り

あけましておめでとうございます。

駅伝企画第二区走者のmashimaです。

2025年は、4月にスマートバンクに転職し出社頻度が変わった事で働き方が変わったり、子供が保育園に通うようになって「保育園の洗礼」を味わったり、第二子を妊娠したりで公私共に常にドタバタした年になりました。

とはいっても喉元過ぎれば…なタイプなので、振り返ると総じて充実した年になりました。 blog.smartbank.co.jp

自分からはスマートバンクにおけるプロダクト開発チームの動きについて紹介しようと思います。

複数のミッションチームでの開発

対外的に見るとワンプロダクトに見えるワンバンクですが、複数のミッションチームと呼ばれるチームが担当領域について、企画からデリバリー、効果検証を行う体制を取っています。

(スマートバンクのプロダクト開発チームについてはこれらのブログ等々を読んでもらうとわかりやすいと思います) note.com smartbank.co.jp

自分が属するのは「わかる」部分を担うチームに属しています。

「ユーザーが自分のお金の使い方を把握し、自覚的にコントロールできるようにする」を実現出来るようにするためのサポートとして家計簿や、支出の見える化に代表されるような家計管理の機能を作っているチームだとイメージしてもらえるとわかりやすいかもしれません。

三日坊主の典型と言われるほど続かない家計管理で如何にして価値を提供し、使い続けてもらえるかを模索しているチームです。

良いプロダクト、良い事業は良いチームから

ディスカバリーの側面が強いドメインである性質上、仮説検証のサイクルがとにかく短い&早いチームの為、四半期毎にチームの構成や追うKPIは頻繁に変更、更新される事が多いチームであり、そんな中で開発をしていると以下のような問題が顕在化してきました。

  • プロジェクトや案件が複数並行しており、単独かペアで動くケースがほとんどになりチーム感が薄い
  • スケジュールがパツパツでリリースしたモノからの学びを全員が共有する場がないまま、次のプロジェクトに着手している
  • 旧チームから引き継ぎタスクや案件を持ったままのメンバーもおり、注力する戦略の開発にアラインできない

とにかく足並みを揃えるのが難しい状況が3,4ヶ月ほど続いており、チームの性質上の問題かと半ば諦めてた部分もありましたが、PMのmoretさんから「体制やチームに課題をみんなが感じてるなら、開発以外のチームビルディングに時間かけよう」との提案でチームの課題に対して皆でアプローチする体制が取れました。

もちろん上層部に掛け合い、チーム編成を変えてもらうという選択肢もあり得ました。 しかし、ワンバンクを「わかる」プロダクトにしていくうえで、当時のチームはこれ以上分けられない不可分な存在でもありました。 そこで、スマートバンクのバリューである Super Ownership を体現する形で、現場のメンバーからボトムアップにチームビルディングを進めていく流れが、自然発生的に生まれていきました。

実際に行ったチームビルディング

チームで最初に行ったのは「ドラッカー風エクササイズ」でした。

同僚のkoshibaさんに企画とファシリテーションをしてもらい、一緒に働く人たちの価値観、期待値を擦り合わせていきました。

自分自身、ドラッカー風エクササイズは初めてだったのですが、メンバー間の期待値などは日々の仕事で察していく事が多かった自分にはとっても新鮮で、いざやってみると数ヶ月一緒に働いた同僚よりも職能が近いメンバーについての期待が書きやすかったり、チームメンバーへの解像度の濃淡がはっきりわかることが出来、予めこういう期待値を最初に擦り合わせておいた方が中長期的にチーム全体のエンゲージメントに効くなと感じました。

developers.gmo.jp

次にやったことは、チームメンバー全員がチームの課題(Problem)を起票し貯め、早い段階で具体的なアクション(TRY)に起こし解消していく動きを醸成しました。

みんながふわっと抱えているチームの課題を誰でも起票できる場(Notion DB)と、週に1度それらのProblemからTRYに起こすことは可能なのかを話す場を設けました。

そうすることでチームの構成のせいやプロジェクトの性質のせいで片付けず、全員が主体性高くチームのボトルネックを解消していく動きが作れました。

Problemの起票者がTRYのオーナーシップを必ずしも持つとは限らず、チーム内で最適だと思う人か挙手制でアサインになっており、自分だけだと解決困難なProblemでも少しでも疑問を持てば起票しておく事で、全員の集合知で解消される期待も醸成出来たのが良かったです。

印象的なProblemやTRYをいくつか紹介

Problem TRY
チームなりのプロダクト開発プロセスの型を作って育てたい 暗黙知になっている、なんとなくの流れで他チームと合わせてしまっていた企画からデリバリーまでの手順を今のチーム体制に今一度構築し直す
開発フローについてドキュメント整理し認識を合わせる
筋トレと自炊ができていない 仕事に追われすぎてないか、やりたいのにやれてない事がないかメンバーのヘルスチェックを週次で設ける
日々のタスク以外に良いプロダクトとは的な話や家計管理ドメインについてチームで話す場が欲しい 週1でチームメンバー全員で特定のテーマについて話すランチを企画

今まで行ったチームランチのテーマ

・CEOを囲む会
・家計管理におけるバーニングニーズとは?を考える会

筋トレと自炊ができてないはメンバーが冗談半分に起票したものから、「ハードワークし過ぎてやりたい事をやる時間が取れないのは健全ではない」というProblemに昇華させてTRYに起こしたり、大きなものから小さなものまで起票し、チームで重み付けしていきながらTRYに移せたのがよかったです。

チームランチの様子(こんな感じでCEOを物理的に囲みました)

まとめ

今までのチームの状態と明確に違って10~12月でに特に良かったのは、Problemを誰かの責任や構造のせいにせず、「じゃあチームとして何ができるか?」に自然と議論が向くようになったことです。

事業もプロダクトもチームも圧倒的な正解がないスタートアップだからこそ 個々の暗黙知や馬力で乗り切るのではなく、チーム全員でProblemに向き合い続けること が重要だと改めて感じました。

チームビルディングやカルチャーを醸成するのは、AIがアウトプットを高速で生成していく時代に残された大事な人間の役割だとも考えているので、AI活用のような派手さはありませんが、「チームとして考え、学び、前に進む」ための土台が作れたのはとても良かったです。

明日の第三区は同じくモバイルエンジニアのuetyoが出走予定です。

We create the new normal of easy budgeting, easy banking, and easy living.
In this tech blog, engineers and other members will share their insights.