「B2B SaaSエンジニアが語るマネジメント論」米元 智氏×郷田 祥史氏×渋谷 亮氏×戸本 裕太郎氏×曽根田 侑也氏×堀 譲治氏

B2B製品開発における7つの失敗(堀 譲治氏)

登壇資料:B2B製品開発における7つの失敗

井上:それでは、最後に、株式会社シャノン CTOの堀さん、宜しくお願い致します。

堀:シャノンの堀と申します。本日は、「B2B製品開発における7つの失敗」というテーマで発表をさせて頂きます。直前のA1A株式会社さんの発表とは対照的に、凄く「ネガティブ」なことを言います(会場笑)。会社としては、20期目に突入しています。製品自体も15年ぐらいやっていて、数々の失敗を踏んできているので、「皆さんには同じ失敗をして頂きたくない」という思いで、本日は発表させて頂きたいと思います。

まず、私自身についてですが、株式会社シャノンという会社に在籍しています。大学卒業後、日本オラクルに入社しまして、7〜8年くらい働いていたのですが、やはり外資系の日本法人だと、なかなか製品開発に取り組むことが難しい面がありました。ちょうどその時、たまたまシャノンと知り合う機会があって、「自分でサービスを開発したい」と考え、入社を決心しました。私自身は、コーディング自体はそこまでやっていないんですけども、どちらかと言うと、技術のディレクションやプロダクトマネジメントに取り組んでいました。ちなみに、弊社はこのビルの4階にありまして、同じビルつながりで今回のイベントには呼んで頂いている形です。

事業内容としては、「SHANON MARKETING PLATFORM」というソリューションを提供しており、主に、マーケティングオートメーションやイベントマーケティングのサービスとして利用して頂いています。また、付随するコンサルティングサービスや導入サービス、BPOについても提供しています。

本日は、「B2B製品開発における7つの失敗」というお話をさせて頂きます。資料を作成していたら、7つに収まりきらなかったのですが、この点については、ご容赦頂ければと思います。以下、順番にお話させて頂ければと思います。

1. 顧客ごとのカスタマイズを受けてしまう

まず、一つ目ですが、創業期においては良くあるケースかと思われますが、「顧客ごとのカスタマイズを受けてしまう」です。もちろん、顧客ごとに「設定」を変える等であれば良いと思うのですが、「ソースコードの分岐」は基本的には避けたほうが良いと考えています。営業担当からは、「これを取れたら1000万円の受注になります」と言われて、まあ、悩むわけです。しかし、ここは心を鬼にして、カスタマイズは極力受けない方向で、「標準機能のままで設定を変えてもらう」「お客さんにそもそもの要件自体を見直してもらう」等で対応すべきケースが多いように思います。

2.開発はたくさんいるが営業とマーケが少ない

2つ目ですが、「開発はたくさんいるが営業とマーケが少ない」です。もちろん、創業期であれば、それが普通だと思います。しかし、製品が徐々に売れてくると、営業とマーケを採用する必要が出てきます。1000社にアプローチすれば、そのうちの200社が買ってくれるような状況だったとしても、営業・マーケの人員数が少ないと、50社くらいにしかアプローチすることができません。結果、その50社のみからの契約獲得を目指すことになる。そこで、どうなるかと言うと、「開発をたくさんしよう」「少ないお客さんにフィットさせに行こう」という話になりがちです。しかし、一社でもお客さんがいるということは、当然、フィットしている状況があるということなので、「フィットするお客さんをいかにして見つけに行くか」という風に発想を切り替えていく必要がある。もちろん、最初は開発が大事なのですが、その後は、営業とマーケに工数をかけることが必要となります。お客さんの要望に対応するというよりかは、「その製品がフィットするお客さんを見つけ出す」ことに注力する方向に切り替えていかないといけない。このあたりの切り替えの重要性については、私たちも当初は理解できていなくて、「目の前のお客さんに対応していけば良いでしょ」と考えていた時期がありました。これは反省ですね。

3.営業が機能の存在を説明できない

3つ目ですが、「営業が機能の存在意義を説明できない」です。会社/製品レベルでの話であれば、営業担当者がしっかり説明できるものの、機能レベルで落とし込むと、だんだんと怪しくなってくる。組織が小さいフェーズでは、こういうことはあまり発生しないのですが、組織が徐々に大きくなってくると、営業担当者がお客さんの質問に答えられないケースが出てきます。これは開発/企画サイドにも責任がある場合があって、機能に関する説明を社内で十分にしていなかったり、説明資料が作成できていない場合が考えられます。「どのような課題を解決するための機能なのか」について、社内においても、正確に認識を合わせることが重要です。

4.目指すアーキテクチャと組織図がずれている

4つ目ですが、「目指すアーキテクチャと組織図がずれている」です。これも過去に何回か経験したのですが、アーキテクチャというのは、技術的な要素だけで決まるものではなくて、会社の状況/ビジネスの状況で決まる要素も少なからずあると思っています。過去に、弊社においても、Perlベースの古いモジュールがありまして、「Perlでは人を採用できない」ということで、「新しい言語で新しいモジュールを作ろう」と考えていた時期があったのですが、その時にまずかったのは、組織を分けてしまったんですね。弊社が提供する製品としては、ひとつなのですが、組織を分けてしまった。すると、組織を分けた瞬間に、「あっちのチームがAPIを空けてくれない」とか「こっちのプロジェクトの要望に合わせてくれない」という風に、色々な不満が出てきてしまいました。目指すアーキテクチャと組織図を整合させることが重要です。逆に言えば、アーキテクチャというのは、基本的には、組織図の通りにつくられていくので、どちらかというと、「つくりたいアーキテクチャに対して組織図を合わせる」ことが大事かと思います。人は無意識のうちに組織を守るコードを書くものです。

5.重要な課題を解決していない

プロダクトの話に戻りますが、5つ目は、「重要な課題を解決していない」です。これは、日々、プロダクトマネジメントに関わっていて、非常に痛感しています。ご存知のように、 B2Bサービスというのは、非常にスコープが広くて、お客さんからの要望も多種多様です。お客さんも色々なことを言うし、カスタマーサポートも色々なことを言うし、営業部門も色々なことを言います。しかし、それらの要望のすべてに答えようとすると、何も生まれないことが多い。有名な話ですが、マクドナルド社でユーザーにアンケート調査をすると、「ヘルシーメニューが欲しい」「サラダが食べたい」という要望が出るのですが、実際に、ヘルシーメニューを出してみると、全然売れない。このように、お客さんが「言っていること」と「本当に求めていること」は違うんですね。お客さんが「欲しい」と言っている機能でも、「本当にお金を出してまで欲しいですか?」と聞くと、「お金は出せない」という話になることは実は多いです。「その課題はお金を払ってまで解決したい課題なのか」ということまで掘り下げて考えることが大切です。

6.技術的負債に向き合っていない

6つ目は、「技術的負債に向き合っていない」です。弊社では、Google Driveでドキュメント管理を行っているのですが、「技術的負債」というワードで検索してみると、結構、色々と引っかかってきます。13年間も会社をやっていると、「負債」の話が年に1回くらいは出てきます。引き継ぎ資料の中にも「負債」という言葉が入っていて、負債まで引き継がれている(会場笑)。「引き継がれた側は可哀想だな」と思うのですが、これを解決するのはなかなか難しいです。

弊社では、この点について、どのように対応しているかについて説明します。負債には、「大きい負債」と「小さい負債」がありますが、「小さい負債」については、開発のサイクルの中で、出来るだけ解消していくことを意識しています。そして、「大きい負債」については、必ず、「ビジネステーマとセットで返す」ような形を心掛けています。具体的に言うと、「ビジネス的なパフォーマンスが上がる」とか「セキュリティのレベルが上がる」といった風に、ビジネステーマとセットで対応することを常に意識しています。このあたりはなかなか難しいのですが、「ポリシーをセットする」ことも大事かなと思います。もちろん、会社ごとに状況は違うので、「これが正解」ということは一概には言えないですが、「ポリシーをセットする」ことは心掛けるべきかと思います。

7.自動テストがなく、年に一度ビッグバンリリースをしている

7つ目ですが、最近はあまり無いのかもしれませんが、自動テストがなくて、年に一度、大きなリリースをしているケースがあります。弊社の場合でも、初期の頃は、自動テストをうまく作れず、溜め込んだ機能を一度にドーンと出していました。例えば、12個の機能がある場合、毎月一個ずつ出した方が本当は良いのですが、「一年間かけて12個の機能を貯めこんで出す」ようなことをしてしまうと、本当に爆発してしまって、大変なことになります。こうなると、営業担当も説明しきれないですし、カスタマーサポートも本当に大変です。自動テストをしっかり組んで、「毎月リリースしていく」「作ったものからすぐにリリースしていく」ということが重要かと思います。

8.KPIで全社の意思疎通がはかれていない

8つ目ですが、「KPIで全社の意思疎通がはかれていない」です。さすがに「売上」については誰もが意識すると思うのですが、売上のひとつ下の階層のKPIである「解約率」や「一社あたりの獲得コスト」等についても、できうる限り、メンバー全員が意識すべきかと思います。 特に、スタートアップ企業の場合、組織全体を見ることができる状況で仕事ができることもありますし、そのメリットを享受する形で、目の前の実務に取り組みつつ、事業全体についても、しっかり把握する姿勢が大事かなと考えています。

9.仕事を見てるが人を見てない

最後ですが、「仕事を見ているが、人を見ていない」というケースがあります。特に、私も含めてですが、エンジニアって人に興味がないケースが多いのですが、それだと組織は大きくはなりません。「どのようにして人と向き合うのか」「どういう思いで仕事をしているのか」等について考えて、人に向き合いながら、組織を作っていくことが重要だと考えています。

最後に

今回のイベントレポートは以上となる。スマートキャンプ株式会社では、今後も、B2B SaaSエンジニア向けのイベントを定期的に開催していくとのこと。直近では、12/6(金)に「B2B SaaSエンジニアMeetup – Sharing Issues #2」が行われる予定。参加希望の方は、connpassのページから申し込みをすることを推奨する。

執筆者:勝木健太

1986年生まれ。幼少期7年間をシンガポールで過ごす。京都大学工学部電気電子工学科を卒業後、新卒で三菱UFJ銀行に入行。4年間の勤務後、PwCコンサルティング、有限責任監査法人トーマツを経て、フリーランスの経営コンサルタントとして独立。大手消費財メーカー向けの新規事業/デジタルマーケティング関連のプロジェクトに参画した後、大手企業のデジタル変革に向けた事業戦略の策定・実行支援に取り組むべく、株式会社And Technologiesを創業。執筆協力実績として、『未来市場 2019-2028(日経BP社)』『ブロックチェーン・レボリューション(ダイヤモンド社)』、寄稿実績として、『キャリアハック』『Forbes JAPAN』『ダイヤモンド・オンライン』『BUSINESS INSIDER JAPAN』『ITmedia』等がある。Twitterアカウントはこちら