株式会社Fusic プロダクト部門 sigfy チームリーダー 船越 将一 さん
学校・保護者にもっと大事なことをするための「時間を作る」 連絡サービス『sigfy』のプロダクトマネージャー。元ゲームプランナー・ディレクター。Fusicへは2015年にJOIN。福岡で育ち、福岡に生きる。仕事にも人生にもプロダクトにも愛とわくわくを大切にしている「愛とわくわくの伝道師」。プロダクト筋トレコミュニティの活動が好き。趣味で少しだけユーチューバー
新規プロダクトの失敗談、赤裸々に話します――。
2021年10月21日に開催された、『プロダクトマネージャーカンファレンス2021』のセッションにそう言って登場したのは、Webシステムやスマートフォンアプリの開発などを手掛けるIT系ベンチャー企業、株式会社Fusicの船越将一さんと安河内舜さん。同社は受託開発をメインとしながら、自社プロダクトの開発も手掛けている。
そんなFusicが今年2月にリリースしたのが『frAAAt(ふらっと)β版』。コロナ禍で開催できなくなった「企業展示」「学会」「合同説明会」等のイベントを簡単に開催できるプラットフォームをオンラインで提供するサービスで、導入したクライアントからは好意的な声も寄せられていたという。
しかし、結果は「はっきり言うと失敗。すでにこのサービスはほぼ撤退している」と船越さん。この失敗の背景には、「受託開発に強い会社だからこそ陥った罠があった」と安河内さんも続ける。
二人が打ち明けた失敗談から、プロダクトマネジメント初心者や受託開発企業で働くエンジニアが新規プロダクトの開発に臨む際に心得ておきたいことを教訓として紹介しよう。
株式会社Fusic プロダクト部門 sigfy チームリーダー 船越 将一 さん
学校・保護者にもっと大事なことをするための「時間を作る」 連絡サービス『sigfy』のプロダクトマネージャー。元ゲームプランナー・ディレクター。Fusicへは2015年にJOIN。福岡で育ち、福岡に生きる。仕事にも人生にもプロダクトにも愛とわくわくを大切にしている「愛とわくわくの伝道師」。プロダクト筋トレコミュニティの活動が好き。趣味で少しだけユーチューバー
株式会社Fusic プロダクト部門 360(さんろくまる)チームリーダー 安河内 舜さん
人事系ソフトウェアサービスの事業責任者。また機械学習やIoT案件のビジネス開発にも従事している。生粋の福岡県民であり、アメリカへの留学時代を除いたほぼ全ての時間を福岡で過ごしている
そもそも『frAAAt』の開発が始まったきっかけは、顧客からの要望だった。「コロナ禍で開催できなくなった学会をオンラインで開催したい」という声が同社に寄せられ、ニーズがあると踏んで開発をスタート。
機能をミニマムに抑えて開発し、顧客に素早くツールを提供。実際に学会でも活用された。さらに、「これまで使ったツールの中で一番使いやすかった」というユーザーの声も寄せられたという。
「課題に合ったサービスで、なおかつお客さまにも使いやすいと言っていただけている。これは『いけるぞ』という感覚でスタートしました」(船越さん)
しかし、売上につながる見通しは立たないまま、サービス導入は伸び悩んでしまった。船越さんは、次の三つの罠にはまった結果の失敗だと振り返る。
1.顧客の口から出た、必要な機能の罠
2.ミニマム開発はMVPじゃない罠
3.共同開発という無料提供の罠
一つ目は、「顧客の口から出た、必要な機能の罠」。今回の場合「学会開催ができるような、オンライン会議ツールが欲しい」という顧客の声がプロダクト開発の出発点になっている。
しかし、「お客さまが『こういうのが欲しい』って言っている時点で、世の中にある程度、その機能を有するサービスってあるんですよ」と船越さん。
「なので、お客さまが『欲しい』という機能をそのまま開発しても、自社サービスの独自性にはつながりにくい。しかも、大多数の人が必要とするようなマス向けの機能ばかり追求してしまうと競合が多くなってしまい、市場に新たに入っていくプロダクトは勝ちにくいんですよね。戦略的にレッドオーシャンに飛び込んでいくならいいけれど、何となくそこに行ってしまうのはだめですね」(船越さん)
すでに可視化されている顧客ニーズに応えることを第一にプロダクトを開発した結果、新規性が生まれにくかったという。
二つ目は、「ミニマム開発はMVPじゃない罠」。『frAAAt』の開発にあたっては、「●月●日の学会で使いたい」という明確な締め切りの要望があったため、それに合わせるために「ミニマムな開発」がなされた。
しかし、顧客に必要な最低限の機能だけで構成したツールが出来上がるため、「本当に必要な機能は何か」という顧客の潜在ニーズや、サービスのコアとなる価値を発見するための仮説検証の機会が少なく、結果的にMVP(実用最小限の製品:Minimum Viable Product)にはならなかったと船越さんは言う。
「最低限の機能で作ることを急ぐあまり、顧客の潜在的なニーズやサービスのコアとなる価値を発見することに注力できなかったことが敗因の一つです」(船越さん)
三つ目は「共同開発という無料提供の罠」だ。新規のプロダクトを作ったときには、顧客ニーズに合っているか、改善箇所はないか、さまざまな検証を行うためにできるだけ多くのユーザーにサービスを使ってほしいものだ。
そのため、「少しでも多くのフィードバックが欲しいので、学会でまずは使ってみてください」とFusic側はプロダクトを無償で提供。学会側も「共同開発の気持ちで協力します」という回答で、サービスを利用していた。
ただ、そこに「罠があった」と船越さんは言う。
「当たり前のことですが、無料で使って『満足』って言うのと、高いお金を払って同じものに『満足』と言うかは、全く別問題ですよね。誰しも、金額相応のサービスや体験を求めますから。ですから、無料で使ってもらって『良かったよ』と言ってもらっても、あまり参考にならない。『無料でしか使われない』くらいのニーズだとしたら、そもそもそのプロダクトはマーケットにフィットしていないということになります」(船越さん)
プロダクトの検証は希望する販売価格と近い費用を顧客に支払ってもらった上で提供すること。そうしなければ、その後のプライシングや市場価値の判断がしづらくなってしまう。
また、顧客ニーズに応えた上で「いいもの作ればきっと売れると思い込んでいた」と船越さんは続ける。だが、実際はビルドトラップにはまってしまったという。
・そもそも課題を発見していないのに、プロダクトを作ること自体が目的になっている。
・なぜかプロダクト開発の企画書の期限だけが決まっている(しかもかなりタイトな期間で)
・何を作るか、何を解決するプロダクトか決まっていないのに、使う技術だけが決まっている
また、受託開発と新規プロダクト開発は別物だということも頭に入れておきたいところだ。
「Fusicが得意とする受託開発の場合、目の前に課題があり、課題解決のためのソリューションが分かりやすいことが多い。しかも、目の前の顧客が求めるものをオーダーメイドで素早く作ることが収入、企業にとっての価値となります。
一方で、新規プロダクトを開発する場合は、受託開発ではあまり意識しないところに重要な部分が多い。それは、世界観やビジョンの設定、潜在ニーズの発見、そして真のユーザーは誰か、どういう市場でどのポジションを狙っていくのか、そこに自社で販売チャネル持っているか、など。挑戦と仮説検証をしぶとく繰り返すことが必要です」(船越さん)
既存のソリューションを丁寧に素早く作ったところで、潜在的なニーズをうまく突いた「新しい開発」にはならないし、世の中に価値は生まない。「それでは会社の売上にもつながらないということを、身をもって学んだ」と船越さんは語る。
安河内さんも、『frAAAt』の早期撤退という今回の失敗を経て、受託開発と新規プロダクトの開発は「全然違う」ことを痛感したと言う。
「本当は、自分たちがちゃんとビジョンを描いて、どういう世界を実現したいか、そのために解決しなければいけない課題は何か、そこで必要とされるのはどんなプロダクトか、そこから考えなければいけなかったと思っています」(安河内さん)
正しく顧客のニーズを掴むためには、ユーザーインタビューを重ねるなど、泥臭く「足で稼ぐ」調査も必要だと安河内さん。
「新規プロダクトの開発には生みの苦しみが付き物ですね。トライアルアンドエラーの繰り返しは甘くないし、頑張っていいものを作ったからといって成功できるかも分からない。
だからこそ、大前提として必要なのは、『絶対やる』という覚悟。ある領域の課題を自分たちの力で解決するんだ、という強い気持ちがあるかどうかを問われますね」(安河内さん)
同じ轍を踏まないように、と失敗談を話す二人の表情にはその決意が表れていた。貴重な失敗談から得た教訓を、ぜひ参考にしてほしい。
取材・文/栗原千明(編集部)
NEW!
NEW!
タグ