自分たちが本当に欲しいサービスを作ることが大切
この失敗から学んだことは何か、それがこれですね。「自分たちが本当に欲しいサービスを作ることの大切さ」ということです。もともと開発の動機がSEOツールという既存の事業があって、そこの収益を維持させたいということにフォーカスしてしまったんですね。その後継ツールを開発するということありきになってしまったのが反省点です。
結局自社ではあまり活用できなかったんですね。自社にはマーケのチームもいてGoogle Analyticsとかもかなり活用できてしまうので、なかなか社内でそういう簡易版のツールやレポートを見ることができずに、ユーザーが何を求めているかっていうのがブレてしまった。
サイト運営者向けなのか、それともWeb制作会社さんがよく担いでいただいていたんですけど、その会社さん向けなのかっていうところが曖昧になってしまって、どちらに向けての機能強化をしていくかっていうのが曖昧になってしまっていました。
そして売上を上げることの大切さ。儲からないサービスっていうのは結局ジリ貧になってしまうんですよね。どんなにいいサービスでもそうです。開発リソースをかけられなくなって、それで他のサービスがどんどん良くなっていって負けていく。
この時は、時代的に『フリー』っていう本が流行っていたりとかで「とりあえず広めれば何とでもなるよ」みたいなことがもてはやされている時代でした。
僕らもとりあえず「まず人気のあるものを作ろうよ」っていうことでフリーばっかり考えていたんですけど、広がったのは良かったんですけどそこから全然有料にならなかった。
フリーで広がってから考えるんじゃなくて、有料化ありきで最初からサービスを設計することが大事だなということを痛感しました。僕らみたいなエンジニアっていいものを作りたいという思いで、儲けるということに結構抵抗感がある人が多いと思うんですけれども、ユーザーのためには収益を上げるっていうことが大切です。
結局収益が上がらないと開発費を投入できなくてサポートもサービスも継続できなくなったり、機能アップもできなくなってユーザーのためにもならなくなってしまうので、ユーザーのためにも自分たちのためにも、収益を上げるっていうことはすごく大切な要素なんだと思っています。
合議制から革新的なアイディアは生まれない
そして失敗した一番の原因ですね。それが、サービス全体の成功にコミットする人やチームが存在しなかったことです。当時のうちの会社の組織として、企画を担当する「企画マーケティング部」という部署があって、開発を担当する「技術部」という部門がありました。
役割として企画は企画を考えて、その企画を技術部が作るという形でやっていたんですけど、そうすると役割は明確になるんですけど、全体に責任を持たなくなってしまうんですね。
うまくいっていればいいと思うんですけど、うまくいかなくなってくると企画は「この機能とこの機能とこの機能が足りない」と言うし、開発としては企画の言うものをどんどん作るようなことってなかなかできないので「もっと成功するものを企画してくれ」と。「企画が悪いから」みたいな形でどんどん険悪になっていくような状況になっていました。
これももう最悪だったんですけど、合議制で機能開発を進めてしまった。5、6人のチームだったので、みんなでミーティングしながらそれぞれ話し合っていったんですけども、やっぱり合議制でやると変な力学が働いてしまうんですね。
「あの人が欲しいこの機能をリリースしたから、じゃあ次はこの人の機能をリリースしようか」っていう全然ユーザー目線になってないような機能開発になってしまって、結局意見がまとまらず議論になってしまい、議論を避けるようになった。
後半は「ここをちょっとよくしようみたいなのは誰も否定できないよね」みたいなリスクの少ない無難なところばっかりがリリースされていく状態になっていってしまいました。合議制で革新的なものは生まれないなというのが反省点です。
自社サービスの一番のユーザーになる
それを踏まえてチャットワークでの取り組みに、どうやって活かしていったかというとですね。「プロダクト開発においてはやっぱり自社で使わないとダメだよね」っていうところで、次に何を作るかって考えた時に、社内で最も使っていたチャット。
スカイプを6、7年前からずっとビジネスで使ってきたんですけど、それをプロダクト化して、もう自社がなくてはならないようなものでなくてはダメだということでやりました。
まずは社内ツールとして自社展開して、社内でも使われないんだったらそもそもプロダクトとしてローンチしないということを徹底してやりました。自社サービスの一番のユーザーになるっていうことが大切なんじゃないかなと思っています。
そしてお金の面ですね。ここはもうすごくシビアにやっていました。大失敗してしまって会社的にもキャッシュが苦しくて、大きなリソースはかけられないよと言われていたので、超最小限のリソースで常に撤退を意識してやっていました。
最初はもう本当に僕1人だけしかリソースがなくてずっと開発をしていたんですけれども、有料化についても、初月でどのぐらい有料になるかということも意識しながらやっていました。前のWeb Analystはフリーでまず出して、半年から1年経ってから有料化を考えたんですけど、今回は初めから有料プランを一緒に出さないとダメだとCEOからも言われていたので、同時にリリースしました。
おかげさまで初月から有料プランの申込もポコポコあって、そこはよかったなあと思っています。シビアに収支を追うっていうことは大切で、広がったら収益になるっていうのはもちろんなんですけど、やっぱり収支を追わないと厳しい面もあるのかなと思っています。
そして大事なのは致命傷を負わないこと。フリーで大きく展開してから後で収益を追おうとしても難しいので、規模が小さいうちに撤退判断をするってことが大切なのかなと思って、致命傷を負わないことが大事だなと思っています。
マトリクス型の組織作りで、意思決定スピードが加速する
そして組織を再編しました。前は企画マーケティング部という企画の部門があったんですけど、そこから企画を取って「マーケティング部」にしました。拡販をするのがマーケティング部で、開発するのは技術部としました。
そして横軸の組織の話なんですが、職能ごとに部門があって、そこに縦軸で事業部というものを作りました。マトリクス型組織と言われているものです。ここにそれぞれマネジメントを置いて管理するという組織になりました。
この事業部っていうのが何をやってるかということなんですけど、事業部の役割として3つ大きくあります。1つがプロデューサーと言われている人で、これは何をミッションとして持っているかというと、サービスの商業的な成否について責任を持つ人です。
こちらは代表の山本ということになっていて、プロデューサーが1年から3年とか5年といった中長期の戦略を考えます。それでマイルストーン、クォーター単位の目標みたいなものを作っていく。
そしてディレクターは僕がやっていますが「サービスのプロダクトとしての品質に責任を持つ」これをミッションとして持っている人です。
もちろん僕も一緒に考えてるんですけども、プロデューサーが考える中長期の戦略に基づいてプロジェクトを立案して実施していって、現実化していくという形になります。これは映画を意識していて、映画のプロデューサーとディレクターが監督みたいな感じですね。
そこにスーパーバイザーという役割の人もいて、この人がサービスの運用オペレーションに責任を持っていて、ユーザーサポートとか決済周りのフローとか、ユーザーが申し込んだ後に支障なくサービス利用できるようにするっていうのをミッションに持っているというようなチームになります。
基本この3人で決裁が何でもできちゃうという状態にして、少数にしました。それぞれミッションがずれているので、この問題だったらこの人、この問題だったらこの人っていうように決裁関係が明らかになるようにして、意思決定のスピードをすごく上げることができました。
大きな失敗をすると社内に閉塞感が漂う
こういった形で、チャットワークでは前回の反省を活かしてうまくやれてきて、何とか成功と言っていいというところまで来たんですけど、失敗からの再起というのは簡単なものではないです。僕らみたいな資金調達もしていないような、小さなベンチャーからすると致命的で、かなり辛い現実が待っていました。
1つ前のサービスを閉じて敗戦処理をして、次のサービスを立ち上げるまでのタイムラグが2、3年、もっとあるかなぐらいあるんですけど、その間はもう新規採用は完全にストップですね。スタッフはどんどん自然消滅していく。バッと辞めたわけじゃないんですけど、ポロポロと数ヵ月に1人という感じで。
辞めるという報告しか人事関係のニュースがないので、かなり社内には閉塞感が漂ってしまいました。ダイエーの創業者の中内功さんの言葉で「売上はすべてを癒やす」という言葉があって。
売上の成長があると多少社内に問題があっても、いつでも成功体験を積めるので大きな問題にならないんです。
だけど逆に言えば、売上の成長が止まった時はその魔法が解けて、それまで自分たちがすごくいい会社だと思っていたところに「こんなに不満持ってたの？」というのが出てきたりとかします。
そういった意味でも、こういった失敗はサービスだけでなく会社組織としても再スタートするというきっかけになって、大変苦しい、もう暗黒の時代をやってきました。
CTOが諦めたらそこで試合終了
こういった失敗はスタートアップにはつきものだと思っていて、避けることはできないと思うんですね。そもそも新規事業というのは失敗確率のほうが高くて避けるべきではないと思うんですけど、失敗した時にそれをどう学びに変えていくかのほうが大切かと思います。
学びのチャンスと捉えて、きちんと総括して次への糧にしましょうということが、自戒を込めてというところですね。
あとはもう致命傷にさえならなければ……。今回かなり痛かったんですけど、会社が潰れるほどではなかったので何とか再起のチャンスを待って、数年間ずっと粛々とやってきました。ようやくチャットワークという新しいプロダクトの準備ができて、チャレンジができるような会社になってきました。
一番大事なことは「諦めないこと」ですね。CTOが諦めたらそこで試合終了かなと思っていて。初日のアンケートで「ぶっちゃけ辞めたいと思ってる」とかあったので心配はしてるんですけど、何かあったらぜひ相談してくれれば、一生懸命できる限りは伝えたいと思います。
ということで、プロダクトの話が中心になりましたけれども、共に頑張ってCTOとしてやっていければなと思っています。ありがとうございました。最近Scalaにスイッチしてるので、Scalaの会社さんぜひ情報交換させてください。
