はじめに
みなさんこんにちは！anyの荒川です。
この記事は、any Product Team Advent Calendar2024 23日目の記事になります。
僕も社会人として7年目ですが、前職のSansanも、フリーランスで関わらせていただいた企業も、現職のanyにおいても、ほぼすべての期間を (Horizontal) B2B SaaS的ビジネスを生業としてきました。
そうした経歴の中で見えてきた活躍できるエンジニアの共通項をいくつか紹介したいと思います。一般論ベースではありますが、なかでは弊社anyの話もところどころ挟みます🙏
顧客への共感にともなう別領域への飛び込み
我々エンジニアは作り手である一方で、自分の開発するサービスのエンドユーザーが自分の関連職種ではないということがほとんどではないでしょうか。
直接的に自分がエンドユーザーでない状況のなかでも、顧客理解をしていかなければ、良いプロダクトは生み出すことができません。エンジニアリング観点においてもDDDなどにおいてもドメインを理解することは設計においては重要なことは言わずもがなです。
顧客視点を持つということは、究極的には顧客に共感すること、であるように思えます。そのユーザが言われたことをただ実装するだけでは受託開発と何も変わりがありません。
顧客のことを知る最も手っ取り早いきっかけは、SlackなどでセールスやCSSメンバーから顧客の声をあげてもらうことがあります。anyにおいても同様でこきゃこまとして、Slack や Flyle に顧客の声を閲覧できる環境があります。似たようなチャンネルが存在する企業も多いのではないでしょうか。
しかし、これらをただ閲覧するだけでは、顧客理解への解像度はあがりにくいです。それらの声を直接的に受け止めずに、なぜそのような要望が起きたのか、どういった使い方をしているお客様なのか、そういった行動の裏に潜む背景を正しく理解する必要があります。本質的にどういう状態を目指したいのかを正しく N=1 から汎用化させていく必要があるのです。
そのためにさらにもう一歩踏み込んで、展示会に参加してみたり、商談などに参加して一次情報を拾いにいく行動が大切です。
私も同じなのですが、顧客の場に出ることを苦手とする人もエンジニアは多いと思います。無理する必要はまったくないですが、一回でもコンフォートゾーンから抜け出して、そういう場に思い切って出てみると、かなり顧客理解への視野が広がります。
またそうした機会をエンジニアが取りに行くと、非常に喜んでくれるのは意外とビジネス側のメンバーだったりします。こういった領域を飛び越える力、学び抜こうとする力や姿勢が非常に肝要でしょう。それらは顧客課題を解決する、プロダクトについて提案をするための言語、コンテキストを獲得することに結びつきます。「あの商談でこうだった」「展示会であの人が何々と言っていた」というエピソードそのものが実は新機能や改善への萌芽なのです。
ただ一つ注意。顧客視点、プロダクト視点が大切と声高に言いますが、エンジニアリング特化で突き抜けられる人を否定するつもりは全くありません🙅♂️
特に研究開発部門などの技術を開発すること自体に価値があるメンバーは、むしろそちらに集中した方が良い場合も多いと思っています。ただあくまでも作り手の罠にはハマらないように、領域に閉じこもらない能力というのは、普遍的にB2B SaaSにおいては重要です。
要件を疑う力とやり切る力と遊び心
Sansan時代にPdMもやっていた経験から、B2B SaaSにおいて要件定義は、特定の仕事内容を効率化させるため、にほぼ収斂されると思います。いわゆるDXというやつです。
したがって機能を作るときに要件をインタビューしたり、前述した声を参考にして詰めていくわけですが、あくまでもその作業が慣例でそうしているだけであることも非常に多いです。要望であがったことを直接そのまま実装する「速い馬が欲しい」状態にならないために、作り手側がしっかりとその仕事内容を精査しなければなりません。
そして業務効率を目指すゆえに、ある業務に合わせたものを作りがちになると、要件が極めて固定化していまいますし、受託開発ではないため、個社対応のような形になってしまいます。しっかりと要件を疑って「それって本当に必要ですか？」を声に出せるエンジニアは非常に強いです。
要件の大半は業務における複雑性ゆえに、泥臭い要件が多いのも事実だと思います。複雑怪奇に絡まり合った権限、フラグ管理、契約プランなどによる条件分岐です。それらをいかに「楽しんでやりきれるか」はB2B SaaSのプロダクト作りをしていくうえでは必要です。ネガティブなことを書いているように思えますが、エンジニアリングは不確実性をいかにコントロールするかが重要なので、設計力や本質を疑う能力は確実に鍛えられます。
一方でエンジニアやデザイナー視点からあがる改善は必須の要件としては明記されないことも多いでしょう。ここはドラッグ&ドロップできたほうがよいよね、などなかなか直接的な要件に上がってこないような、プラスアルファの実装をいかに時間の中で使っていけるかも、やりきる力と思います。
さらに美しいUI/UX、ゲーミフィケーションなどの「遊び心的な要素」をプロダクトに埋め込むことは相対的に少ないという実感があります。anyでは「1.1のラストワンマイル」と呼んだりしています。
プロダクトフィロソフィー
これは完全に個人の意見ですが、私は日本発のB2B SaaSの遊び心が少なすぎるという感覚があります。toCでPMFを達成したのち、エンタープライズに進出してきたSaaSはSlack, Notion, Figmaなどのその製品を触る楽しさを感じさせることが非常に多いです。
ドメイン知識を学び続ける
B2B SaaSのターゲット市場にもよりますが、企業での利用を前提とするため、サービスの知識のみならず、SAMLなどの複雑な認証の設計、階層化されたメンバー権限管理、契約プランの変更対応、監査系のタスク、問い合わせ対応、テナント分離の仕組みづくりなど、対応業務が多岐にわたります。
さらに近年ではコンパウンド戦略をはじめとするマルチプロダクト戦略のなかで、2nd, 3rdプロダクトとのシナジーを生み出していく流れがあります。認証基盤やデザインシステムなどの共通コンポーネントを構築して、既存の技術資産をも流用していくことが必要になります。
顧客に複数年間利用していただくので、プロダクトの息が長く、そのうえで新しい機能をアップデートしていく必要があるため、常に新しいドメイン知識を学び続けなければなりません。
弊社のQastというプロダクトでは、最近のトレンドであるRAGとしての引き合いが増えて来ました。特にドキュメントを自然言語で引き出せることに魅力を感じてもらえていますが、旧来のQastナレッジマネジメントのツールとしてドキュメント管理やQ&A管理として利用される場合とは事情が大きく異なります。
このようにプロダクトの強みがピボットすることもあれば、ドメイン知識も異なるように、学び続け対応していく柔軟性が求められます。既存の勝ち筋に固執し続けない気持ちの強さとも言い換えられるかもしれません。泥臭いながらも学び続け、顧客へ寄り添い続けなければ勝ち残れないのです。
向き合い続ける
おわりに
ここではB2B SaaSの歴も中堅になってきた、いちエンジニアから見たB2B SaaSへの向き合い方でした。こういった領域に共感できる方々であればぜひB2B SaaSの世界に飛び込んできていただきたいです。
弊社anyにおいてもエンジニアを募集しています。ぜひご応募ください。