リモートワークが普及してきた昨今、業務向けのアプリケーションの中で身近なところであると、SlackやTeams、Google MeetやZoomなどが挙げられます。

SaaSという形で提供しているBtoB向けのプロダクトはここ数年で非常に増えてきており、それは即ちBtoB SaaSが活発に開発されているということでもあります。そして、アプリケーションという形態にて特定のドメインとプラットフォームに基づいてそれを設計することは、考えている以上に難しいと私は感じます（この難しさはBtoB SaaSにおけるプロダクト開発の面白さとも言い換えられるのですが）。

もし4年前の自分が予め知っておけば同じ時間を費やしてももっと良いプロダクトができていたよな〜と思うほどに難しいポイントがそこにはあり、そしてそれは実際に手を動かして仮説検証をする過程の中でしか身を持って実感できないことではあります。

しかし、この先同じ道を歩んでいくかもしれない人たちに何かしらのヒントを残せたらと思い、ここ数年で感じているBtoB SaaSのプロダクト開発における難しさとヒントを書き残しておこうと思います。

属性や性質が大きく異なるセグメントが複数ある

私は「HERP Hire」という採用業務に関するプロダクトを開発し続けています。この採用ドメインにおいて、スタートアップなのかメガベンチャーなのか東証一部上場の大企業なのかなどの企業規模や、どんな業界であるかや採用しようとしている職種は何であるかで、その採用形態や規模、実際に行っている業務フローが大きく異なります。

それは即ち「採用業務」と一口で言えるものに対して無数の業務フローや方法論・慣習・文化があり、それらなるべく多く把握して理解する必要があるのです。

そしてこの業務およびユーザー理解が難しすぎるというわけです。同じ領域の業務を5年以上継続していたりよほど感度が高く無い限り、深い理解をもった業務なんてなかなかありません（私も今の領域でプロダクト開発をするまで採用業務のことなんてほぼわかりませんでした）。

加えて、ユーザーインタビューで特定の企業やユーザーについて個別具体なケースを深堀りしようとしても、前提として高解像度な業務理解がないとそれすらできません。深い業務理解がない状態で行うユーザーインタビューはただ事実の聴取にしかならず、インタラクティブな仮説の更新ができないため時間の無駄と言っても過言ではないレベルです。

そして、何もかもが異なる各セグメントのリアルなインサイトは現場にしかありません。どんな風に業務やデータを処理しているのか、そしてそこに伴う苦労や発見はユーザーのすぐそばにしか存在しません。

何年も同じドメインやプロダクトを開発していても、ユーザーインタビューをしている中で「そんな使い方とかハックあるの！？」とびっくりしたり、何気なく定義していた仕様や機能が実は現場でものすごい価値を持って利用されていたとかザラにあります。

また、セグメントごとに異なる業務フローやインサイトをプロダクト上もしくはカスタマーサクセス上でどううまく吸収するかも難しいです。業務として普遍的に存在するものに対して機能を作るときに、機能だけでどこまでカバーするかの意思決定はそう簡単ではありません。

あるセグメントは必要最低限この要件であればいいが、また別のセグメントではさらに数段リッチな要件でないとそもそも業務に乗るレベルですらないということもあります。これは別にプロダクト上だけで完結させる必要もなく、カスタマーサクセスやDevOpsの中で十分埋められることがあるのでそのバランス感をどうするかステークホルダー全員で考える必要があるのです。

アプリケーション設計の甘さや雑然さが大きく跳ね返ってくる

（解像度は一旦問わず）ある程度の仮説を持ってゼロからプロダクトを設計・開発し続けていると、どうしてもその中でわかってきた業務実態が想定と異なったり、定義していた概念が「違うな〜」となって再定義したりリファクタリングする必要が出てきます（初手で数年先まで正解となる設計をすることは人間には難しすぎる）。

これ自体は、プロダクトの戦略が変わったり開発する中でわかったことやユーザー理解が存在する以上、もうある程度はどうしようもないものです。しかし、あまりに仮説の精度が甘かったり、機能に対する捉え方や思想が雑だと、あとから機能追加・改善するときに開発速度や提供できる価値に対して大きく足枷となります。最悪、現状の設計だとその機能の実装は現実的に無理ですということもあります。

そのため、都度細かく軌道修正しながら強い意志と思想でアプリケーション設計をしないといけません。いわゆるユーザーエクスペリエンスに対する知識と感度、アプリケーション設計におけるアーキテクチャ定義やデータ設計への理解、インターフェースを適切に構築するスキル、上述しているような深いドメイン理解の全てが求められ、そしてそれらを統合して実際に開発していくことは本当に難しいです。

（ターゲットセグメントやユーザーストーリーが定まった上で）必要十分な機能要件の切り出しが難しい

リソースが有限であることもあり、機能はなるべく小さければ小さいほど提供と仮説検証にかかる時間が短くなるため良いとされています。しかしもちろん、小さすぎてもユーザーにとっては機能不足になり、逆に大きすぎるとかけたコストが最悪全て無駄になる可能性も高いのでその塩梅が難しいです。

そもそも、その機能の要件が必要十分であるかどうかの仮説を立てる部分から難しいということもあります（それを継続的に検証していくことがプロダクト開発なのですが）。機能要件の切り出しにおいて確からしい仮説を立てるためにもドメイン理解の重要性はここでも出てきます。

レベニューモデルやその戦略・市場の状況に応じて即時性が求められる

プロダクトを開発するにあたっての大きな意思決定の変数として、市場の状況やどう売っていくかの戦略があり、それに従ってプロダクトバックログの優先順位は大きく変わったりします。

それまでのプロダクトとして積み上げてきたものに対して大きな戦略変更があるとアプリケーションとして秩序と連続性を持って設計・意思決定するのは本当に難しいです。「本当にこれでいいのだろうか？」と自問自答しながら設計しがちになります。

過去の自分、そして未来の開発者へのヒント

つらつらと書いているこの「難しさ」は実際にプロダクト開発していく中でしか本当の意味で理解はできないのかなとは思います。4年前の自分がこれを読んでもおそらく「ふ〜ん」としか思わないでしょう。

しかし、それでも意識していたり守っていたら今以上にもっと良いプロダクトがこの瞬間に生まれていたかもしれないことが確かに自分の中でまとまっているので最後にさらっと書いておきます。過去の自分、そして未来のBtoB SaaSプロダクト開発者へのヒントとなれば幸いです。

・最初からあまりに先を見据えなくてもいいが、予めわかっているくらいの程度までは見据えて柔軟性のある設計（機能として達成できること、entityやschema等の設計）をするべき

・まずはいろいろな手を使ってドメイン理解をする、深いドメイン理解がないなら何も設計とかはじめなくてもいいくらいには大事。実際に存在しているユーザーと同じ目線で話せるくらいにはわかってないとトンチンカンなものを作ってしまう。

・とにかくできるだけ小さくプロトタイピングして開発していく。自分たちが最低限必要でしょと思っていたものが蓋をあけてみたら必要なかったは本当にありがち。

・結局はプロダクトは開発だけで閉じないのでレベニュー側と密にコミュニケーションを取って柔軟にやっていくべし。