みなさんこんにちは。池内です。廃業エントリの中編です。前編は下記 note をご覧ください。

前編では、起業に至るまでの前職での経験と起業の動機、最初の事業立ち上げ未遂までの振り返りを行いました。今回の中編では、次に行った事業の話をメインに振り返りたいと思います。

第二期 : B2B SaaS 事業の立ち上げ 〜 モダン・ヘルプデスク SaaS を求めて

最初に計画した事業が凄い勢いで頓挫したショックから立ち直ったのは、2016年早春のことでした。当時、最初の事業が失敗した理由は以下の2つだったと考えました。

・業界から見ると僕は部外者であり、人脈もなければ仕事をした実績もない。→ 自分の体験に根付いておらず、僕がやる蓋然性が薄かった。
・事業推進の面で、作品をいかに巻き込めるかというビジネス・ディベロップメント側の比率が大きすぎた。→ 自分の強みはプロダクトのつくりこみにあると考えた。

とにかく自分の得意領域に寄せて勝負しようということで、そこで取り組むことにしたのが B2B SaaS としての ヘルプデスク・システム開発でした。

B2B SaaS に狙いを定める

ヘルプデスク・システムは、カスタマーサポート（CS）業務のうち、特に顧客からの問い合わせ管理を支援するツールです。Webフォームやメールといったマルチチャネルの一元管理を行い、情報共有と属人性の排除を促進することでチームの生産性を高めます。この領域では当時もいまも Zendesk が有名なプロダクトの1つです。いまでこそ企業にヘルプデスク・システムやチャットベースの相談窓口が用意されている事例が増えていますが、当時は他社の状況を聞いても、CS業務の効率化が進んでいるとは感じられない組織がそこかしこにありました。

僕が CS の業務効率化に取り組みたいと思った理由は2つありました。前職で開発部門と情報システム部門の業務プロセスを見直す中で、まさに Zendesk を導入して運用した経験がありました。その折に競合ツールのいくつかを比較検討もしていて、いずれも一長一短があり、小規模な組織が気軽に導入するには躊躇する価格になっているといった問題を感じていました。したがってテック・スタートアップ向けのミニマルでモダンなツールがあれば受け入れられる余地があると考えました。

もう1つ、僕のエンジニアとしてのキャリアはレンタルサーバー事業を主軸とする企業でのテクニカルサポートを始まりとしていて、CS分野における課題や苦労を知っていたということがありました。これは自分の体験に根ざしていて、僕が取り組む論拠になると考えました。

↑プロダクトのロゴ。日本版Atlassianをつくるぞという意気込みで、将来はサービスのラインナップを拡充するつもりでいた。

・・・

二度目の正直・プロダクトローンチ

開発したのは「eurie Desk（ユーリエ・デスク）」というプロダクトでした。着手からベータ版リリースまでの開発期間は約4ヶ月、さらに2ヶ月程度の運用期間を経て、正式リリースに至りました。これが起業後に初めてローンチしたサービスとなりました。

↑問い合わせ = チケットの状態を視認しやすいよう、カンバン（風）の UI を取り入れた。

ユーリエ・デスクでは、1人からでも気軽に始められ、組織やプロダクトが大規模になっても高いパフォーマンスで動作するというコンセプトを掲げていました。これからスタートアップを含むスモールチームが CS業務に直面する場面が世界中で増えていくと考えていて、そうしたチームがスケールしていく過程に寄り添ったプロダクトでありたいという想いに基づいたものでした。

チャットツールやプロジェクト管理ツールなど他のサービスとのインテグレーションを念頭に、チームの内部と外部をつなぐコミュニケーション・ハブになることを設計思想としていました。この設計思想を RESTful API ファーストという形で具体的な実装に落とし込めるのは、自分がソフトウェアエンジニアであることの強みだと考えました。

↑公開していた API ドキュメント。必要なすべての操作を API 経由で行えるよう順次拡充していく予定だった（過去形）。

・・・

つくるよりも広めるほうが難しい。売ることはもっと難しい

結論から言うとこのプロダクトはぜんぜん広まりませんでした。プレスリリースを配信した直後（今度はリリース・ファーストではありませんでしたよ！）には幾ばくかお問い合わせをいただき、数社には有料で導入していただけました。しかしそれ以上に広めることができなかった。その理由はたくさんあったと思いますが、そのうちのいくつかを整理してみます。

・地道なセールス活動に力をさかず、スマートにやろうとしすぎた。
・日本語と英語の両方に対応（しようと）し、リソースを浪費したうえに中途半端になった。
・差別性を模索するあまり、使われない不要な機能の実装にコストをかけてしまった。
・自分はユーザーの気持ちをわかっているという過信とバイアスがあった。
・ドッグフーディングができないままに、モチベーションが失われた。

自社プロダクトを客観視する難しさと差別性を求めよという罠

「リーン」の手法については起業以前から知ってはいた、という話は前編でもしました。上述したいくつか、例えば「使われない不要な機能の実装にコストをかけた」などは教科書に載っているような典型的なアンチ・パターンじゃないかと指摘する方もいると思います。それは本当にそうで、実践できなかった以上知っていたと言えるのかどうか疑わしい。しかし、知識としてインプットしたことと実践することの間には大きな隔たりがある、あるんだなと実感しました。他社サービスを品評する目と、自社を見る目はやっぱり違っていた。

使われない機能の実装に力を割いてしまった理由として、既存プロダクトと違う点、即ち "差別性" を目に見える形で "機能" として実装しようと足掻いた結果迷走したということがあります。それはユーザーに寄り添ったものではなく、「このプロダクトは今までと何が違うの？」と説明を求める人々（あるいは自分）に対しての目眩ましのようなものでした。CS や情報システム部門で働いている知人にユーザー・インタビューをしたりもしていましたが、自分の考えを補強するための解釈しかせず、認知バイアスの沼に陥っていました。

なんとなく小綺麗にできてはいるけど、自分以外のユーザー・ペルソナが判然としないぼやけたプロダクト——できあがったのはそういうものでした。

過度の自動化

B2B SaaS の初期フェーズでは、軌道に乗せるまでは本当に地道なセールスが必要とされるんだろうなと思います。まず最初の顧客を見つけて、懐に潜り込んで、業務プロセスを徹底的に分解して改善点を明確にする。スケールを考えるのはその次でよかった。手作業が嫌いだった僕は、深夜にトライアル申込みがあったときに備えて利用開始までのすべてのプロセス——データベースのマイグレーションやサブドメインの発行など——をあらかじめ自動化しておきました。しかし、これは重要なことなんですが、そんな時間に申込みは来ません。

ユーザー・インターフェース（UI）の言語についても同じことが言えます。僕は日本語で日本だけに閉じたサービスを展開することはとても嫌だったので、UI を英語で実装し、ドキュメントは日本語と英語で用意した。したものの、量も質も中途半端になっていました。グローバル展開だ！英語対応だ！といくら息巻いも、それだけで広まったり受け入れられたりということはないんですよね。

↑ 顧客からの問い合わせに対して、登録したテンプレートを組み合わせて返信文を作成する機能。一見すごく便利そうだが、少なくとも MVP としては明らかに不要だったもの（悲）。

・・・

お金ってどうしていたの？

ここで少しだけ、前編で触れなかったお金周りの話をしておきます。

資金繰りについて

出稼ぎに関してですが、技術コンサルティングやアジャイル開発チームにおけるファシリテート役など、時期によっていくつかの仕事をしていました。稼働日数としては週0.5日から2日の間程度です。アジャイルチームに入ってWebアプリを開発したこともありましたが、この間に受託開発は一度もやりませんでした。前編で述べたとおり、プロダクトづくりに焦点を合わせた組織をつくることが今回の起業のテーマでもあったからです。強調したいのは受託開発がすなわち悪という主張ではないことで、実際、いわば受託開発縛りプレイを行っていたために会社解散の時期が早まる結果を招いてしまった面もあったと思っています。

役員報酬について

第一期の役員報酬は 28万円/月 に設定していました。これは明らかに失策でした。最初の役員報酬設定は誰しも悩みながら決めているようですが、28万円という設定はじつに中途半端で、充分に多いとも少ないとも言えず、自分で積んだ資本金が自分の口座に振り込まれる過程で税金分減額されるという意味のわからない（※わからなくはない）フローを生みました。その反省（反動？）から次期からは報酬を10万円/月 に設定することになるのですが、これはこれでよくなかった。法人としてのバーンレートは抑えられますが、個人資産がもの凄い勢いでバーンしていきました。口座残高が純減していくさまを見ると、人の心って摩耗するんですね（悲壮感）。

お金回りの話は、資金調達をはじめとするファイナンスのトピックとあわせて、後編でまた振り返りたいと思います。

ローンチ後の負のスパイラル

閑話休題。プロダクトのローンチ以後、事業拡大のために下記の活動を行う算段でした。

・導入先と導入事例を増やす
・事業拡大のために資金調達をする
・ドッグフーディングをしながらプロダクトを改善し続ける

この事業の結末をすでに述べていますので、いずれも功を奏さなかったことは想像に難くないと思います（哀）。

ネガティブマインドは何よりの敵

まず全体をつうじて、僕が "控え目" になっていたという反省があります。前回の失敗を経て、あまり早いうちから人目に付くのはやめようというマインドセットになっていたんだと思います。強く押して相手に迷惑がかかってもいけないしな、などと考えていると、セールスやアライアンス、ましてやファイナンスなんて良い方向には進まないんですよね。せっかく好意的に見ていただいていた先行導入企業や投資家の方へも、消極的なアプローチを行うにとどまってしまっていました。この時点で敗着だったのかも知れません。

マインドセットの話は前編で触れた「技術者の視点と経営者の視点」にも関係します。一般に、実現できるかどうかもわからない大風呂敷を広げる上役や経営者は内外から批判の対象になりがちですよね。特に内部にいる技術者からすると、最後の工程で巻き取るのは自分たちなので、しわ寄せがくることに対する抵抗感を持ちやすい。僕もかつてそう感じていたタイプでした。ただ結局はバランスというか、誰向けに話をするかという使い分けなんだと思います。投資家向けに現実的な話ばかりをしても仕方がない。技術者としては、不確実なものに対しては「検証してみる必要がある」という態度で臨む必要がある。僕はこの使い分けに最後まで苦労して、自分は経営者には向いてないんじゃないか、と悩む一因になっていました。

バーンするのはお金だけではない

スタートアップの立ち上げフェーズでは、いかにバーンレートを抑えるかが死活を分かつと言われます。それはおもにお金に対してのコンテクストで語られることが多いですが、モチベーションのバーンも実際無視できない。お金が減っていく、商談が止まる、調達が頓挫する、これらはすべてメンタルにのしかかってきます。かたや発動するのは隣の芝は青く見える理論で、SNSやニュースサイトで他社の明るい話題が目に付く。このマインド・ワンダリング感たるや。

誤算だったのは、ドッグフーディングのできなさでした。ドッグフーディングとは、自分たちのプロダクトを自ら徹底的に使い込みながら改善していくことを指す言葉です。当初はこの事業においてもドッグフーディングを行い、問題を見つけて改善していく算段でした。これも誤算というかやる前から分かるんじゃないか案件なんですけど、まったく知名度のないような小さな会社に誰も問い合わせなんてしてこないんですよね...。自社における「ユーリエ・デスク」のおもなオペレーションは、まれに届くスパムのような営業メールに「対応不要」フラグを付け続けるというものになったのでした...。

2017年の春以後、「ユーリエ・デスク」は細々と生命維持をするだけとなり、事実上の撤退となりました。

第二期の振り返り

今回の事業が上手くいかなかった理由の一因として考えられる点を再掲します。

どうすれば良かったかについては、上記の問題をつぶしていくことに他ならないと考えていますが、ドッグフーディングの例などは、自社だけでは限界がありますのでパートナー企業を見つけて一緒に取り組む、というのが解なのかなと思っています。結局ビジネス・ディベロップメントの問題で、そこからは逃れられないというのが最大の学びだったかも知れません。

これら以外のものとして、構想時点での詰めの甘さもあったと思います。ヘルプデスク・システムの領域において既存プロダクトがある中、なぜより良いものを作れると思うのか、コードを書く前にやるべき詰めが甘かった。そのために差別性を小手先の機能に求めるという結果に陥りました。それも踏まえて、総括としてはすごく月並みなんですが、やはりチームが重要で、上述の反省点も、「僕が」頑張ってなんとかするということではなくて、「チームで」カバーし合あうことで解決できたんだろうなという思いでいます。

・・・

今回の振り返りの最後にもうひとつ。

ここまで、僕の振り返りとしてはどちらかと言うとプロセスやメンタリティを反省の中心に据えてきましたが、純粋にプロダクト自体がしょぼかったから売れなかったんじゃないかという意見もあると思います。結果が出なかった以上それは否定できない。しかし、B2B SaaS は永遠の未完成品とも言われるように、ローンチ時点での完成度よりも地道に改善していけることにこそ、価値があると考えています。

2019年10月時点においても、ヘルプデスク・システムが解決しようとしている領域には膨大な課題が残っています。Slack が既存チャットシステムをリプレースしていっているように、テクノロジーで解決できることがまだたくさんある。これは後悔ではなくて、やっぱり僕の力が足りなかったからこうなったし、それは仕方がない。それでも、チームをつくって、受託開発をしてでもいいから資金繰りと気持ちに余裕を持たせ、最高のヘルプデスク・システムをつくろう、そういう志を変えず続けていれば、それが何年後かわからないですけど、違う結末もあったんじゃないか。そんな風に思い出すこともあります。

・・・

あと2プロダクトを残すなか、次で話がまとまるのか。後編に続きます。

<<後編につづく>>

Cover Photo by David Marquis on Unsplash