【BtoB SaaS】スパイダープラスの「&Co.」なものづくり組織とプロセス

久々のnoteです。

この記事では、顧客価値を生み出すための組織の在り方と、スパイダープラス社のアイデンティティである「&Co.」のつながりについてを書いていきます。

スパイダープラスについての理解をしていただきたいのはもちろんのこと、BtoBのSaaS、特にVerticalな（≒業務浸透度の高い）SaaSプロダクトを手掛けている方には参考になることもあるかもしれません。

①BtoB SaaSのものづくりプロセスと「＆Co.」

まず「＆Co.」とは何のことか説明します。

スパイダープラス社の英語表記は「Spiderplus ＆ Co.」です。

この「&Co.」は「Company」のことであり、これは会社という意味だけではなく”仲間・連れ・一団・一隊”などの意味があり、「～とその仲間たち」という意味になります。

詳細は会社のHPに記載されていますが、つまるところスパイダープラスの「パートナーと共に業界の新しい形を創造していく」というアイデンティティを表しています。

さて、この「&Co.」の精神ですが、BtoB SaaSに求められるものづくりのプロセスの真髄を表していると考えています。
なぜならば、顧客のことを理解し、顧客の課題を解決するプロダクトを提供すること自体が、特にVerticalなSaaSにおいては価値そのものになるからです。

それは、以下のBtoB SaaSのものづくりプロセスによって説明できます。

この図はあくまで「機能の役割分担」を表しているため、実際の組織体制とは異なることに注意してください。
例えば、上記のような機能をユニットとして複数作っている会社もあると思います。

重要なのは、

・スタートは常に「顧客理解」
・「顧客の要望に応える≠言われたまま作る」
・営業やマーケティング、開発など複数の機能を一体化させる

というポイントだと考えます。

上記のポイントを押さえたうえで、顧客が真に求めているものを、顧客の期待を上回るクオリティとスピードで提供する組織を作るということが、
そのままBtoB SaaSのプロダクトの価値につながるということです。

では、なぜ「&Co.」という言葉が重要なのか？

これは私の解釈ですが、「ディスラプター（破壊者）であることの否定」だと考えています。

ICT業界ではよく、「破壊的トレンド」といった言葉が表すように、あたかも「既存のビジネスモデルを破壊し、新しい秩序を作り出す」というのが正義であるかのように語られてきました。
しかし、我々はそうであろうとしない、ということです。

建設業という、飛鳥時代から続く伝統産業であり、国や社会を担う基幹産業に対して敬意を払い、
長い年月とともに培ってきた技術や業界システムを十分に尊重しつつ、業界が抱える課題を一緒になって解決していく。
我々が一方的に利益を享受することなく、業界の発展とともに自社が成長していく。
「&Co.」には、そんなメッセージも込められています。

言い換えれば、顧客を理解し、価値のあるものを作っていくのは当然のことであるが、
自社のひとりよがりな視点にならないようにしよう、という戒めでもあると思います。

そんな、徹底的な顧客起点のものづくりのプロセスについて、次項から解説していきたいと思います。

※なお今更ですが、本記事ではシステム開発サイドには触れておらず、ビジネスサイドのものづくりプロセスにフォーカスして書いています。

②顧客理解と要望収集

まずはすべての起点である顧客理解と、要望の収集です。

そもそもSaaSを提供している企業であれば、要望を収集していないということはありえないと思います。
ただ、その要望を顧客の理解と紐づけて把握することが重要です。

例えば「もっとAという操作のクリック数を減らしてほしい」という要望があったとき、
誰が、なぜ言っているのか、その要望に応えると顧客にとって何が起きるのかを理解していないと、プロダクトとして対応する優先順がつけられません。

SaaSビジネスはとどのつまり、限られた開発工数を、いかに事業インパクトのある案件に振り分けられるかの勝負です。
そのため、そもそも事業インパクトを判断できない状態の要望に対応するのはリスクになります。

わかりやすい極端な例で言えば、
大規模な導入をしてくれている顧客の、部長級が、サービスの全社導入のキーファクターとして要望を出しているなら即対応すべきだし、
現場ユーザーの1人からたまたま聞いた程度の要望だと、まだ対応すべきかどうかが判断できないといったイメージです。

では、顧客についてどのくらい理解すればよいのでしょうか？

詳しく書くとそれだけで何本かの記事になってしまうので、プロダクト開発においてよく使っているのは以下の切り口です。

■顧客理解のポイント
A.感情の理解
B.組織の理解
C.業務プロセスの理解

A.感情の理解

よく社内では、「感情で語れるくらい顧客を理解すべし」という話をします。（日経の連載でも書いてました）

「Aという機能が使いづらいことで、ロスする時間は少ないものの、”他社のツールならこんなことないのに！”という気持ちが増幅されるって言ってました」

このように、感情を込めた理解をすることで、チーム全員がその要望の重要度や緊急性を、リアリティをもって理解できます。

逆に、感情で語れないと、どこか薄っぺらい印象を与えます。

「ここが使いづらいって言ってました」というような事実だけをチームにフィードバックしても、
「それは顧客のサービス理解度の問題じゃない？」「その程度の不便さなら優先度は低いよね」というように、
顧客が感じているPainが十分に伝わらなかったりします。

「感情で語れるように理解する」というのは、シンプルかつ非常に付加価値の高い顧客理解につながります。

B.組織の理解

続いては組織の理解です。
これは一言でいうと、「顧客が、なんの論理に従って動いているのかを理解する」という目的になります。

例えば、カスタマイズ要望をたくさん出してくる顧客がいたとします。

営業からすると、本当に使うかどうかもわからないカスタマイズ要望を真に受けていいのかどうか判断がつかず、開発側にも相談できなかったりします。

しかし、実は顧客の意図としては、「DX担当としての社内での示しをつけたいから、自分が何かを実現したという事例を作りたい」という背景があったりします。

そういうときは、顧客の意見に従ってカスタマイズ要望を検討するよりも、
頑張ってオンボーディングして社内のアクティブ率を向上したほうが、本質的に両者ともハッピーだったりします。

そういう、「相手を動かしている論理」を理解しないと、判断を間違えます。
上記の例でいうと、せっかくカスタマイズ対応したとしても、結局は顧客の社内のサービス利用率はあがらなくて、いつか解約されるでしょう。

そういうことにならないためにも、相手の社内の立場やミッションを理解し、どんな部署や人と利害関係があるのかといった、組織の理解がとても重要になるのです。

C.業務プロセスの理解

3つ目は、業務プロセスの理解です。業務プロセスとは、例えば以下のようなものです。
（引用元：https://kashika.biz/carren-kaizen-03-05/）

このように、顧客の業務について「いつ、どんなトリガーで、誰が、何をするか」を表現したものです。

ここまで詳細にするかはともかく、業務プロセスを理解するというのは非常に重要です。

顧客の業務がどんなプロセスになっているのかを理解せずに、個別の要望に応えて開発をしていたりすると、
システムがどんどんツギハギになっていきます。

業務プロセスを俯瞰的に把握できていれば、顧客のユースケースにも汎用的に対応できるうえ、システム構成としてもスッキリしたものを作れるようになります。

よくあるパターンとして、
「顧客にひたすらヒアリングしたけど、具体的なことがわからない」
というのがあります。

例えば「みんな口をそろえて”情報をスムーズに共有したい”と言う」「でも、何を実装すればいいかわからない」といったケースです。

こういうとき、大抵は業務プロセスの可視化ができていないことが要因です。
上記の例でいえば、どんな業務プロセスの、どんなケースで、どんな情報を共有することが多いのかを可視化できれば、顧客にとって価値あるものが提供できます。

特にSIer出身の方などは得意な領域だと思いますが、業務プロセスを理解するというのは、SaaS開発にとって極めて重要なポイントになります。

（補足）
なお顧客理解について、マーケティングで使われるのはもう少しマクロな理解であることが多いです。今回はミクロの話を紹介しました。
マクロな顧客理解については「マーケティング戦略のかなり最低限な作り方入門」もご覧ください

③ユースケースの具体的把握と抽象化

続いてのプロセスは、ユースケースの把握と抽象化です。

ここでいうユースケースとは、「実際にどんな状況で、誰が関わって、どんな業務をしているか」という意味です。
前述した業務プロセスと似ていますが、こちらはより具体的に、「実際に操作する人の役職」や「業務の背景となる細かな事情」なども含めて把握するものだ…などとイメージしてもらえればと思います。

〇ユースケースの具体的把握

システム開発における「ユースケース」の定義とは少し異なりますが、
上記の図のように詳細な背景まで把握できていないと、システム的なユースケースも的外れなものを作ってしまいかねません。

例えば上記の例でいうと、
〇SaaS提供側
「印刷前のプレビュー機能を実装しました！実際の帳票イメージを見ながら確認・修正ができます！」
〇顧客
「プレビューのときは文字の解像度が高いのに、印刷すると潰れてる…。改ページの位置がずれてて意味合いの違う報告書が同じページ内に印刷されちゃってる…ここが正確じゃないと使えないよ」
というような事態が発生するイメージです。

ユースケースを詳細に把握できていないと、せっかく作ったのに「かゆいところに手が届かない」というプロダクトになりやすくなったりします。

〇抽象化

ユースケースが把握できたら、次は「抽象化」です。

抽象化という言葉だけだと何をするかわかりにくいですが、要するに
「この業務は、どんなケースで、何を実現するためのものか」
を定義するということです。

上記のように、顧客の具体的なユースケースを把握したものを、いったん抽象化して要点をまとめます。

なぜユースケースのまま開発をしてはいけないのか？

それは、顧客ごとに異なる業務に対応できなくなる可能性があるためです。

例えば上記の例でいうと、「うちの場合は写真と図面を紐づけないよ」という顧客が想定されていません。
それを考慮せずに開発をしてしまうと、例えば「図面を使わない場合は、1ピクセルの透過PNGを図面データとして登録して使う」といったような、謎の例外対応をしなければいけなくなったりします。

できるだけ幅広い顧客の業務に対応するため、ユースケースをいったん抽象化し、次の「汎用ユースケース化」のステップに進む必要があります。

④汎用的ユースケースへの落とし込みと仕様策定

汎用的ユースケースへの落とし込みというのは、要するに「想定しうる限り広範囲の顧客をカバーできるユースケース」を作るということです。
そこまでやってから仕様策定をすることで、幅広い顧客に価値を提供できるプロダクトになります。

〇汎用的ユースケースへの落とし込み

これは、複数の顧客のユースケースをまとめて、改めて広範囲な顧客をカバーできる具体的なユースケースを作るという作業です。

ここまでくると、「このユースケースをプロダクトに落とし込めば、絶対売れるじゃん！！」という感覚が出てきます。

〇仕様策定

汎用的ユースケースが定義できたら、あとは仕様に落としていきます。

スパイダープラスの場合、まずPMM部の「ディレクター」という役割の人が”要求仕様”をまとめ、
開発チーム（企画推進部）が、”詳細仕様”に落とし込むというフローを取っています。

エンジニア出身のディレクターの方などは、いきなり詳細な仕様を作ることもできると思いますが、
多くの場合、既存のプロダクトへの工数的な影響やメンテナンス性の担保など、技術的なレビューが必要であり、

”要求仕様＝汎用的ユースケースを実現するために必要なもの”と、
”詳細仕様＝実際に開発するために、技術難易度や工数などの視点をふまえて作ったもの”

を、分担したほうが効率が良いと感じています。

⑤成果を出すプロジェクトマネジメント

さて、ここまで来たらあとは開発するだけ・・・とはいきません。

開発リソースは有限なので、数ある案件の開発優先度を決めなければ着手できません。
また、開発工数が大きい案件などは、顧客の温度感をふまえたスケジュールの折衝なども発生します。

営業や開発、顧客など多くのステークホルダーの事情を把握し、各自の要望を可能な限り叶えるように進行する必要があります。
また、その結果として事業が成長するというゴールに向かっているかどうかが最も重要です。

こういった複雑かつ変化していく状況をふまえ、プロジェクト全体を適切にコントロールする機能が必要です。
スパイダープラスのPMM部では、それをPM（プロジェクトマネージャー）と呼んでいます。

上記のように、事業には多くのステークホルダーの事情が複雑に絡み合っています。
それを整理し、事業のゴールから逆算し、最適な結果に導くプロジェクトマネジメントが求められます。

⑥事業・マーケティングとの接続

ここまできても、SaaS事業は開発したら終わりではありません。

プロダクトの進化に合わせた営業やマーケティング、カスタマーサクセス体制の変化が求められますし、
プロダクトのロードマップそのものが、事業戦略の根幹を担います。

プロダクト開発のプロジェクトマネジメントが、そのまま事業やマーケティング活動と接続される必要があるのです。

上記のように、大きなアップデートに連なって営業やカスタマーサクセスの戦略との整合性をとったり、各所の人員増加をする必要があったり、IRとの連携、他には知財など権利関係の確認が発生することもあります。

そういった数多くのプロジェクトと連携し、プロダクト開発の状況を遅滞なく情報共有しつつ、
各部署の戦略への影響などもキャッチアップして対応していくことが求められます。

ちなみに私はマーケティングの責任者（CMO）という立場でありながら、プロダクトのリニューアルの責任者を兼任したりしていますが、
その背景には、プロダクトと事業・マーケティングの接続こそが事業成長の大きな根幹の一つだと認識しているためです。

事業が成長していくほど、こういった「PM」の動きをできる人が必要になってきます。

⑦スパイダープラスのPMM部とは

かなりのボリュームになりましたが、ここまで読んでくださりありがとうございました。

最後になってしまいましたが、私が責任者を務めている、スパイダープラスのPMM部（Product Marketing Management）について説明します。

一言でいえば、この記事で書いた内容がそのままPMM部の仕事になります。

要望の集約から開発計画、全体のプロジェクトマネジメントからマーケティングまでを一貫して担う組織です。

実はPMM部は、2021年5月になって発足した組織です。
それまでは大きく「営業」と「開発」という2つの部門があったのですが、組織の成長スピードを圧倒的に高めていくために、両部門のバランスをとったうえで事業に最適なプロジェクト進行を担う機能が必要になりました。

しかしながら・・・正直なところ、実現したいことに対して、組織がまだまだできあがっていない状況です。
本記事で書いた内容も、現実としては求めるレベルに程遠いと考えています。

スパイダープラスのPMM部では、「PM」「ディレクター」「事業開発」といった職種を随時募集中です。

今回の記事を読んで少しでも興味を持っていただいた方は、私に直接連絡をいただくのでも、公式HPからお問合せいただくのでも構いません。
建設テックの世界を一緒に広げていける仲間をお待ちしています！

※こちらの記事も合わせてお読みください
いま、建設テックがめちゃくちゃ面白い理由

〇三浦のTwitter　※採用の応募DM大歓迎！

〇スパイダープラスの求人一覧

------

（余談）実は今回、noteの書き出しを
「消しわすれたmixiアカウントに残っている昔の痛い日記」テイストで書いてみようかと思っていました。

しかし、ネタにしてもあまりに痛いのでやめました。
途中まで書いた内容は以下。

このような日記が日本中に溢れていた2006年ごろを思い出すと、胸が熱くなりますね。

供養。

------