TOPインタビュー「コード全捨て」で覚悟が決まった。Bill Oneチームが“売れない新規事業”を脱却した方法

「コード全捨て」で覚悟が決まった。Bill Oneチームが“売れない新規事業”を脱却した方法

2024年7月26日

Sansan株式会社　VPoE

大西真央

SEとしてエンジニアのキャリアをスタートさせ、2012年以降はアジャイルやDDDなどの開発スタイルを経験。2016年にSansanに入社し、営業DXサービス「Sansan」の大阪開発拠点立ち上げやインボイス管理サービス「Bill One」の立ち上げにプロダクト開発責任者として携わる。2024年4月より現職。

X（@mmmmao0530）
これまでの経歴

新規プロダクトをつくり始めたものの、なかなか売れずに苦しんでいる開発チームも多いのではないでしょうか。Sansan社の2本目の柱として現在急激に売上を伸ばしている請求管理SaaS「Bill One」も、実はそのひとつでした。

Bill One開発チームは、多くのユーザーに必要とされるような「売れるコンセプト」をなかなか見つけられずもがき苦しみ、2度目のピボットでは、それまで積み上げたコードを全部捨てるという大きな決断をしたそう。

この困難を乗り越えるべく開発チームを先導したのは、Bill Oneチーム発足から3カ月後に、エンジニアの責任者としてアサインされた現VPoEの大西さんでした。彼は一体どのようにして、プロダクトを軌道に乗せたのでしょうか。新規プロダクトの開発チームが、苦境を脱するためのヒントをいただきました。

keyboard_arrow_down 「Bill One」も開発当初はカオス状態だった
keyboard_arrow_down 2回のピボットを経て、ようやく定まったコンセプト
keyboard_arrow_down 「コード全捨て」の決断が、Bill Oneのヒットにつながった
keyboard_arrow_down 大胆な意思決定を下すことで、限界を超えて成長できる

「Bill One」も開発当初はカオス状態だった

――今となってはT2D3を超える速度で急成長中のBill Oneですが、そもそもどのような経緯で開発が始まったのですか？

大西：Bill Oneの開発は、経理部門のメンバーが「自分達の業務の課題を解決したい」と社長に直談判し、業務委託のエンジニア1名とともに2019年1月に始まりました。私はその3カ月後にジョインしたのですが、その時の状況はなかなか厳しいものがありました。

当時のBill Oneは経理向けのプロダクトで、請求書を受け取った後の「支払い」を効率化するサービスとして、開発が進んでいました。支払いの作業では一般的に、銀行システムにアップロードすると複数の銀行に一斉支払いができる「ファームバンキングデータ」が広く使われており、当時はそのデータの作成の自動化をプロダクトの価値として売り出していこうとしていました。

ところが当時、Bill Oneには「完成したデータが本当に正しいかどうか」を確認するプロセスが用意されていませんでした。絶対に間違えてはいけない作業で使うデータなのに、出したデータが100％正しいと証明できなかったのです。プロトタイプを使ってくれていた社内の経理部からは「ただでさえ忙しいのに、かえって生産性が落ちる」と不満の嵐でしたし、そういう評価を受けるのは当然でした。

――大西さんがアサインされたのは、まさに「社内炎上」とも言える状況下だったのですね。

大西：そうですね。この状況をなんとか脱するためにと、私が加わることになったのです。それ以降のチーム体制は、発案者である経理出身の事業責任者と、最初からいた業務委託のエンジニア、そして私と、同時期に加わった営業メンバーの4人になりました。社長は、この事業への投資の最終意思決定者として関与していました。

当時は関係者の数が少なかったこともあり、大体1週間ぐらいで全容は把握できたと思います。その後は2～3カ月かけて、社内からハイスキルなエンジニアに異動してもらい、2019年の夏には、エンジニアは僕を含めて3名体制となりました。

――社内異動とはいえ、苦しい状況のプロジェクトに新たに優秀なエンジニアを迎え入れるのは、難しかったのではないでしょうか。

大西：いえ、そこまで苦労はしませんでした。そもそもメンバー異動、つまり、このチームのエンジニアリングを強化すること自体「今後の経営において、Bill Oneを外販できる状態にまで早期に成長させることが重要だ」という社長の意図があってのことで、会社全体として重要度・緊急度の高いトピックでした。あらゆるエンジニアが「異動によりチームのエースが抜ける可能性がある」と心づもりしていたので、異動するメンバーが所属するチームとの交渉はスムーズに進みました。

また、異動する本人に興味を持ってもらうための会話にも力を入れました。私が声をかけた優秀なエンジニアが、チームのメンバーから「まだここにいてほしい」とお願いされることもあるかもしれない。それでも異動してもらうには、異動する本人に「面白そう、やってみたい」と思ってもらわなくてはいけませんから。

そうして2人の優秀なエンジニアがBill Oneに興味を持ってくれた結果、それぞれが所属するチームのリーダーも快く送り出す形で、異動を決断してくれました。

2回のピボットを経て、ようやく定まったコンセプト

――増員後、売れない状況を打破するために、Bill Oneチームは何から取り組んだのでしょうか？

大西：エンジニアには足りない機能を粛々と開発してもらいつつ、私はエンジニアの責任者として、開発に関わりながら、ドメイン知識を補うためのインプットをしていました。一方ビジネスメンバーは、今のコンセプトで本当にニーズがあるかどうか、Sansanのお客様の中から100〜200社に架電ヒアリングをして検証していました。

しかし検証の結果、当社と同じニーズを抱えている企業は見つからなかった。このままこのコンセプトで開発を進めていても誰にも必要としてもらえない、とはっきりわかったので、2019年9月にプロダクトのコンセプトを大きく変えようと決断しました。

――1回目のピボットですね。どのような転換だったのでしょうか。

大西：それまで取り組んできた「支払い」の課題解決から、支払いの前段階に当たる「仕訳」の課題解決へと方針を変えました。

仕訳とは、請求書の内容をもとに、どんな品目にどのぐらいお金を使ったのか整理する作業のこと。仕訳は全企業で行われていて、かつ非常に面倒な作業です。これを楽にしたいというニーズは明らかに大きいので、もし請求書のデータから自動で仕訳をするプロダクトをつくれればきっと売れるはずだ、と考えたのです。

そこで早速、R&Dチームと協力しながら当社の過去の請求書データを使い、現実にその機能を実装できるかどうか検証しました。でも、どんなに試行錯誤を重ねても、残念ながら期待したほどの精度は出せませんでした。仕訳も支払いと同様に間違いの許されない作業なので、100％に近い精度が出せなければ、サービスとして価値はない。

ニーズが明らかで、かつ巨大であっても、技術的にどうしても実現できないこともあると痛感しました。この結果を踏まえて、2回目のピボットをすることに決めたのです。

――ピボットの意思決定は、関係者全員に「今までかけてきたコストを無にしたくない」という思いもありハードな決断となりますが、なぜ短期間に2回ものピボットを、スムーズに実行できたのでしょうか。

大西：ピボットの最終意思決定者である社長と、現場で試行錯誤を繰り返している我々の認識がずれないよう、その時々の見通しを逐一共有してきたからこそ、2回とも全員納得の上でスパッと決断できたのだと思います。

というのも、私が参画してからずっと、社長と、ビジネスサイドの責任者と、エンジニアの責任者である私の3名で、週に1回ミーティングをしていたのです。その中で、1回目のピボット前の「ニーズがなさそう」という状況も、2回目のピボット前の「精度の向上が難しい」という状況も、現場にそのような雰囲気が流れ始めた時点で、社長に共有していました。だから社長と現場の間に認識のずれが生じることなく、関係者全員が「このまま進んではだめだ、ピボットしよう」と納得した上で、コンセプトの抜本的な見直しに進めたのだと思います。

「コード全捨て」の決断が、Bill Oneのヒットにつながった

――2回目のピボットでは、どのようなコンセプトに決まったのですか。

大西：それまで取り組んでいた請求書の仕訳も面倒ですが、それ以前に、いろいろな担当者がバラバラの方法で受け取る請求書をまとめること自体が面倒なはず。そう考え、「請求書の受け取り」自体をオンラインで一元化するというコンセプトに固まりました。それが2020年2月の上旬です。

するとその2週間後ぐらいに、新型コロナ感染対策として緊急事態宣言が発令され、多くの企業がオフィスへの出社を控えることに。請求書の受け取りや処理のために出社しなければならない経理担当者の声にも注目が集まっていました。当時はニーズ調査を始めるタイミングでしたが、緊急事態宣言をきっかけにその必要もないくらい課題が明確になったので、全員が「このコンセプトでいく、機を逃さなければ絶対に売れる」と合意しました。そして「ゴールデンウィーク明けには絶対にローンチする」と決め、開発を始めました。

そのとき、それまでに書いてきたコードを全て捨てる判断をしたのです。

――そうだったんですね。「もしかしたら今後経理向けの機能もつくるかもしれないから、念のため取っておこう」という考えはなかったのでしょうか？

大西：その思いが全くよぎらなかったわけではありません。でも、大きくコンセプトが変わり、かつ、3カ月後にローンチすることを最優先とするなら、サンクコストは無視して全部捨ててつくり直した方がいいと思ったんです。

それに、元々の技術選定にも問題があったと思っていて。私が加わったときからずっとBill Oneの開発にはPythonを使っていました。最初にいたエンジニアがPythonに深い知見を持っていたからです。でも私は「Pythonから静的言語に切り替えたい」と前々から思っていました。そのため、技術スタックの見直しも兼ねて、コードを全部捨てたのです。

その結果、それまでに積み重ねた負債を返済する必要もなくなりましたし、新しいコンセプトに合わせて高速に開発を進められました。

――技術スタックの変更という背景はあったものの、今までつくってきたものを全て捨ててしまうのは、つらくはなかったのでしょうか。

大西：もちろん、つらかったです。そもそもこの1年間ずっと「お給料をもらいながらも、自分が手掛けるプロダクトが全く売れていない」ということ自体、精神的にかなりつらかった。そのうえでコードを全部捨てる、すなわち、必死に取り組んできたアウトプットが「全部無駄だった」という事実を突きつけられるわけです。ものづくりで貢献するべき立場であるエンジニアとしては、心にグサッとくるものがありました。

しかしこのつらさが、私や同チームのエンジニアにとってはプラスにも働きました。売れない1年間と、その間に積み上げたコードを全て捨てる決断を経て「売れないプロダクトをつくるのは、もう絶対に嫌だ」と全員が固く決心していたのです。この思いが、エンジニアの責任者である私にとっては、機を逃さず大胆な意思決定をする勇気につながったし、メンバーにとっては、売れるプロダクトをつくるために職域を超えて必死にコミットするエンジンになっていました。こうしたマインドになれていたからこそ、売れない時期を乗り越えられたんだと思います。

結果として、予定通りゴールデンウィーク明けのローンチもできて、それから約半年でMRR（Monthly Recurring Revenue：月次経常収益）が500万円を超えるなど、「売れるプロダクト」と言えるくらい多くのお客様に必要とされるものをつくることができました。

今となっては、つらい気持ちやサンクコストを惜しむ気持ちに惑わされず「全部捨てる」と決断して、本当に良かったと思っています。