株式会社UPSIDERの「支払い.com」でエンジニアリングマネージャーをしている大聖寺谷です。
支払い.comとは請求書の支払いをクレジットカードで支払うことができ、 中小企業や個人事業主の資金繰りの改善を行うことができるサービスです。
リリースから今まで右肩上がりに成長を続けており、最近では累計決済額が700億円を突破しました。
今回のブログでは、支払い.comの成長を支え続ける、開発チームの体制や開発手法について紹介します。
支払い.comの開発チームと開発スタイル
支払い.comの開発チームは全体で10名以下のスモールな開発組織です。
メンバーの居住地はバラバラであり、フルリモートやフルフレックスを中心とした働き方になっています。
そのため開発手法やMTGなどについてもフルリモートかつ時間的に非同期であることを念頭において設計を行っています。
スクラムではなくカンバンで開発する
支払い.comではカンバンのような開発手法を採用しています。エンジニアの手が空いたタイミングでNotionで管理しているプロダクトバックログから優先度の高いタスクをアサインして開発を進めています。
多くの企業で採用されているアジャイル開発のスクラムですが、支払い.comの開発チームでは採用していません。理由としては、総合的に見て現在の支払い.comの開発チーム規模感やフェーズでは適さないと判断しているためです。
一方で、今後さらに人数が増えていった際やスクラム経験が豊富なメンバーがジョインした場合などは、改めて開発方式を検討したうえで、より最適なものを探したいと思っています。
プロダクトバックログ管理はNotionで行う
UPSIDERでは開発チームに限らず全社的にNotionを活用しているため、タスク管理ツールについてもNotionのDBを使っています。
以前はGitHub Projectsで管理していましたが、エンジニア以外 (PdMや事業責任者など)のメンバーがバックログを確認する機会も増えており、Notionに移行して良かったと感じています。
プロダクトバックログは、主に1つのEPIC (例: xxxの機能を開発する ) に複数の具体的なTASK(例: xxxの画面を実装する, xxxのAPIを実装する)が紐づくような形で管理しています。
プロダクトバックログはNotionのProject機能を使っており、EPICがProjectに該当します。
下記はプロダクトバックログの一部となります。
Epicのアイコンは絵文字を活用しており、遊び心も大事にしています
どんなタスクでどのチームが対応する必要があるかが分かるようにタグづけして管理しています。
実装に際しての要件や設計検討したものなどは各EPICに記載するようにしており、タスクアサインされたメンバーがすぐに開発に取り掛かれるようになっています。
下記は実際に今対応中のとあるEPICのキャプチャになります (見せられない箇所が多いのですが 😭)
フォーマットはEPICによってバラバラだったりしますが、課題背景や想定しているユーザーストーリー、想定している対応内容などを記載しています。
タスク管理ツールでありがちなものとして、タスクステータスの更新漏れなどがありますが、NotionとGitHubを連携しており、GitHub PRの状況に応じてタスクステータスが自動で 対応中 → レビュー中 → リリース待ち → リリース完了 と遷移するようになっています。
こういった地道な開発運用改善などはメンバーが積極的に行なってくれています。 (いつもありがとうございます！)
また「今すぐにはやらないけど、いつかはやりたい！」「アイデアベースだけどこんなことやれたら良いかも」といったものは プロダクトバックログとは別の要望DBで管理しています。
要望DBについては開発チーム以外のメンバーもチケット追加が自由に可能なルールとなっており、カスタマーサポートやセールスメンバーを中心に、それぞれ自由に追加しています。
フルリモートを念頭においたコミュニケーションカルチャー
支払い.comの開発チームでは、フルリモート・フルフレックスの働き方を最大限活かしつつ、開発者が集中して作業できる時間を確保するために、定期的な同期ミーティングの機会を少なくしています。
しかし、同期コミュニケーションを完全に排除するわけではなく、週に3回の朝会や週1回の振り返りを行っています。
朝会では、各メンバーが現在の状況やタスクの進捗を共有する場としていますが、それだけではなく、「ひとこと」という欄を設けています。この「ひとこと」では、各自が最近の出来事や趣味（例えば、漫画やゲーム、スポーツなど）について自由に話す場としており、プライベートな雑談を織り交ぜながら運営しています。これにより、各メンバーが自己開示を少しずつできるようにしており、より円滑なコミュニケーションを促進する工夫しています。
さらに、チーム内では、SlackのHuddle機能を使って気軽に質問をしたり、一緒に作業したりするカルチャーも根付いています。
Huddleは、必要に応じてすぐに短時間のミーティングやペア作業ができ、オフィスで少し離れた席のメンバーに相談しにいくような気軽さで話せるのがとても便利だなと感じています。
こういった同期・非同期のハイブリッドなコミュニケーションを行うことで、フルリモートであっても高い生産性を実現できていると感じています。
開発チームとビジネスチームがフラットにそして強固に連携するカルチャーがある
私たちのプロダクトは開発して終わりではなく、ビジネス戦略を考えたり、ユーザーのサポートなどが必要不可欠です。
そこで支払い.comでは、開発チーム以外にも主に以下のようなチームが存在しています。
- セールスチーム
- カスタマーサポートチーム
チームが違っていても、Slackで誰とでもいつでも気軽にコミュニケーションがとれるようになっており、とても距離感が近く、職種に限らず「全員がユーザー志向を持ち、一丸となってプロダクトを磨き続ける」ということができているなと強く実感しています。
これについては以下のインタビュー記事で詳しく話しているので、ご興味をお持ちいただいた方はぜひ以下のnoteコンテンツにつきましても、お読みいただけると嬉しいです！
おわりに
本ブログでは現在の支払い.comの開発手法や体制を中心に紹介させていただきました。
一方で正直なところをお話しすると、まだまだ実現したくてもできていないことがたくさんあります。
このブログだけで全てを伝えることは難しく、もし些細なことでも気になることなどがありましたらお気軽にご連絡くださいませ。
