プロダクトチームにとって最もコストがかさむ要望は、無理難題ではない。むしろ、完全に理にかなった要望こそが厄介なのだ。
私がCOO（最高執行責任者）を務めるSwitcher Studio（スイッチャー・スタジオ）では、教会、非営利団体、クリエイター、小規模ビジネス向けのライブ配信ソフトウェアを開発している。顧客から複数のプラットフォームへ同時に配信したいという要望があった際、私たちはその機能を開発した。それは私たちの既存の事業領域を拡張するものであり、別の事業へと引きずり込まれる心配はなかった。しかし顧客は、寄付者管理、決済ワークフロー、寄付誓約の追跡、フォローアップツールといった、より深い資金調達インフラも求めてくる。これらは切実なニーズだが、私たちが解決すべき問題ではない。
すでに提供しているものを強化する要望もある。それらは開発する価値がある。しかし顧客は、本当に有用だが自社が作るべきではないものも要望してくる。
誘惑は、その需要よりもさらに根深いところにある。私自身もそれを感じたことがある。「もし私たちがこれを開発しなければ、競合他社が開発し、何年もかけて獲得した顧客が離れていく理由になってしまうのではないか」という懸念だ。その恐怖はもっともである。しかしそれこそが、プロダクトチームを窮地に陥れる原因なのだ。
周辺領域での開発は、想像以上にコストがかかる
チームがコアの外側で開発するとき、目に見えるコストは分かりやすい。エンジニアリングの時間、デザインリソース、誰かの継続的な注意力である。これらは確かに実在するコストだが、最も高くつくものではない。
隠れたコスト、それはフォーカス（集中）だ。
プロダクトの周辺領域にある機能はすべて、サポート、改善、ロードマップ上のスペースを、際限なく必要とする。不具合が起これば誰かが修正しなければならない。顧客が改善を求めれば、プロダクトを本当に定義する仕事より優先すべきかを誰かが判断しなければならない。
このような周辺の機能をいくつも開発していくと、多くのことをそれなりにこなすものの、何一つとして卓越していないプロダクトが出来上がってしまう。顧客が本来求めていた機能は、開発当初の目的とは異なるものへと関心が分散されることで、次第にその優位性を失っていく。
これが罠である。短期的には顧客にイエスと言い、長期的にはその顧客に応えることを難しくしてしまうのだ。
承諾しそうになった、ある要望
数年前、教会から「寄付機能の統合」を求められるようになった。彼らはすでにSwitcherを使って礼拝のライブ配信を行っており、視聴者が配信画面から離れることなく、ライブ配信中に寄付できるようにしたいと考えていた。それは合理的な要求だった。私たちはその課題を理解し、要件定義を開始した。
開発する論拠は単純だった。教会の資金調達管理がSwitcherを通じて行われれば、他所を探す理由が一つ減る。しばらくの間、私たちはこの案を退けなかった。
エンジニアリングの見積もりを前に考え込んでいた時のことを覚えている。そこには、コンプライアンス要件、決済インフラ、寄付者管理などが含まれていた。私たちが要件定義していたのは、単一の機能ではなく、一つの会社そのものだったのだ。
他社が何年もかけて完成させてきた仕組みの、劣化版を自社で開発することになり、その一方で、顧客が本来求めているプロダクトから開発チームを遠ざけることになってしまう。そこで私たちは立ち止まった。代わりに、寄付プラットフォームとの提携関係を構築した。恐れていたような悪影響は生じなかった。それどころか、教会との対話はより明快になった。彼らは何のために当社を利用すべきかを理解したのだ。そしてこのアプローチは、自社で開発するよりもはるかに優れた解決策へと私たちを導いてくれた。
より明確な解決策は、多くの場合パートナーシップにある
私たちは顧客からの要望を二つのカテゴリに分けることを学んだ。「作る」か「組む」かだ。要望がコアプロダクトを強化するなら作る。ニーズは本物だが別のカテゴリに属するなら組む。
顧客が高度な寄付ツールを求めた場合、私たちは寄付に特化して構築されたプラットフォームを探す。コミュニティ機能を求められた場合は、コミュニティに特化したツールを探す。自社が提供するものを明確にし、提供しないものについても力になれるよう努めている。
パートナーを選ぶ際、ブランドの知名度よりも「オーディエンスの合致度」が重要であることを私たちは学んだ。もし相手のプラットフォームの顧客がすでに礼拝の配信、資金調達の実施、授業の開講などを行おうとしているなら、それは構築する価値のあるパートナーシップだ。オーディエンスの重なりが緩やかなだけの巨大プラットフォームと提携すると、ターゲット層ではない顧客を引き寄せ、誤った期待を生み出し、最終的には双方に「なぜこの提携がうまくいかなかったのか」という疑問を残す結果になりかねない。
また、双方に必要なのは「明確に定義された成果」だ。これがなければ、両チームがどれほど善意を持って提携を発表したとしても、その後は何の進展もないまま終わってしまう。明確に定義された成果の例としては、「両方のプロダクトを使用する顧客が、これまで手作業で行っていたステップを省略できるようになり、具体的な時間や手間を削減できること」や、「設定された期間内に目標数の顧客がその効果を体験できること」などが挙げられる。その成果が達成されなければ、どれほど素晴らしいプレスリリースを発表したとしても、その提携は機能していないということだ。
コアを構築し、それ以外へとつながる橋を架ける
私たちは現在、要件定義書を作成し始める前に、次の3つの質問を自分自身に投げかけている。
1. これは私たちのコアとなる事業を強化するものか、それとも周辺領域へと引きずり込むものか。
2. もしそれが周辺領域であるなら、異なる方向から同じ課題に直面している顧客を持つパートナーは存在するか。
3. もしそうしたパートナーが存在する場合、双方にとって望ましい成果とは具体的にどのようなものか。
これらの問いによって、「イエス」と答えたくなる圧力が完全に消えるわけではない。しかし、正しいものにイエスと言う助けにはなる。
顧客は、私たちがすべてのことをこなすことを望んでいるわけではない。彼らが私たちを選んだ理由であるその一つの領域において卓越した価値を提供し、それ以外のすべてのことについては適切なツールを見つける手助けをすることを望んでいるのだ。
