要求を掘り下げることをどう説明するか

2 July, 2025

要求を掘り下げることをどう説明するか

割とよくある困りごと。

経緯

SaaS を運用している、プロジェクトというより組織に参画するとき。だいたい、立ち上がって数年経った状態。実装ができる技術責任者がいる組織を選んでいる。

技術責任者は経営レベルの知見を持っていたり、営業面のノウハウも持っていて、かつシステムの設計も理解しているので、顧客の要望から一瞬で課題を特定し、最適解を見出す。

エンジニアは技術責任者がブレイクダウンした決定事項から、解決方法を考えて要件を定義し、設計と実装を進める。このフローがは開発体験が非常によく、エンジニア視点ではすごく楽しい。

でも、しばらくプロダクト開発や運用を続けると、ある時に技術責任者がいなくなる。半年か数年か。例外なく開発は停滞し、なにも作れなくなる。

ビジネスサイドへの説明

この状況では、顧客要望がダイレクトにエンジニアに降りてくるようになる。既存設計との親和性が非常に悪いような機能や、確実に莫大な工数がかかるような要望について検討し見積するように要求される。エンジニアは要望の内容を一目見て、費用対効果の悪さを把握できるが、ビジネスサイドへの説明が難しい。

必要な作業

顧客は既存システムの設計はもちろんプロダクトの機能を網羅的に理解していないので、次の視点が足りない。

• その要求を既存機能でカバーできないか
• 既存機能に少し手を加えるだけで実現できないか
• ほんの少し要求を切り捨てると極端に実現コストが下がる部分がないか
• 根本的な問題が他にあるのではないか

また、プロダクト提供側から見て次のような検討が必要になる。

• 既存顧客が混乱したり、既存顧客の業務を妨げないか
• 将来の MRR 獲得につながるか
• 他に優先するべき機能開発はないか
• 技術的負債になるような、無理な規模の開発ではないか

要求を掘り下げて本当の顧客課題を見つける役割が失われている。

苦労していること

上記の必要な作業について、ビジネスサイドへの説明が難しい。どう説明しても、顧客課題を再定義し、プロダクトのビジネス的な側面を設計することと、技術的な設計を混同してしまってうまく伝わらない。特にパートタイムで関わっているときが難しい。

ただ、この状況ではプロダクト開発が止まってしまうので、やむを得ず自分が顧客にヒアリングしたり、現場を確認しに行く。役割が固定されないように期間を決めて対応するが、だいたいその役割が外れることはない。設計と開発がしたくて行動しているのに、どんどんそれができなくなっていく。

展望

時々ならいいけど、この役割が定着すると悲しい。ビジネスサイドでやってほしい。

社員としての参加ならこれも仕方がない気がするけど、だいたいそうではないので困る。