はじめに
- 営業からこんな要望が出た、よし作ろう、きっと売ってもらえるはずだ
- 重点顧客から「この機能あったらあの工場で使ってもらえそうなんだけどな」と言われた
- あんな機能あったら便利になるよね
ちょっと待ってください。それは本当に今開発が必要な機能でしょうか。
プロダクトマネージャーとして開発対象を選定する身になると、あちこちから開発の要望が出てくるものです。
今回は、自戒をこめ、心を鬼にして開発対象を絞り込むためのざっくりとした考え方を紹介します。
（私自身はどちらかというと機能を作りたがる方なので、抑制してちょうどよいかもしれない）
私の担当する製品の特徴
- BtoB（製造業向け）
- オンプレパッケージソフト
- 弊社が開発、パートナーが営業・導入
- 数を売るというより、１回の顧客に依存しがち
本記事の一部は上記製品特徴に沿った考え方かもしれません。その点はご了承ください。
作ると決める前に一旦とどまって考えてみよう
判断の元となる問いかけをカテゴリ別に整理してみます。判断するための具体的な手法（RICEなど）にはここでは触れません。
製品・競争力
- 我々のコアで、競争力につながる機能か？
- 競合と比較したか？
- その機能の欠如が失注につながっているか？
- その機能は戦略に沿っているか？リリースの結果、戦略に影響を与えるか？
- 優先度が高いものか？
- その要望を踏まえて優先度の見直しをしたか？
- その機能を作ることで、他の機能開発を疎かにすることによる機会損失がないか？
ユーザー・市場
- 本当にユーザーが求めているものか？
- ユーザーヒアリング、アンケート、プロトタイプ検証などを通してユーザーと対話をしたか？
- ユーザーの利用状況をデータとして確認したか？（オンプレだと難しい・・・）
- 広いユーザーに利用されるか
- 特定のユーザーにのみ利用される結果とならないか？
タイミング
- それは今作るべきものか？
- ユーザーがその機能をすぐに利用する状態か？運用できるか、推進する人員がいるか
品質・完成度
- 完璧を目指した結果ではないか？
- 独りよがりな完成度をチームに求めていないか？
- 品質は保てるか？
- 機能追加が製品理解やUI/UXを複雑化し、結果的に現場の作業効率を下げる懸念はないか？
- 機能修正の影響範囲を正しく見積できているか？
コスト・リソース
- コストを考慮しているか？
- 機能が増えると開発コストだけでなく、テストコストや保守コストも増加する。トータルのコストがリターンにマッチするか？
代替手段・パートナーシップ
- 代替手段がないのか？
- ちょっとしたシステム外の工夫で回避できないか？
- 市場の別製品との組み合わせで実現できないか？
- 他社との提携や吸収合併で実現できないか？
- パートナーに受け入れてもらえるか？
- パートナーの開発余地を潰し、売上を下げる結果とならないか？
リスク管理
- 後でその機能を消せるか？
- 「やっぱりこの機能は失敗なので消しますね」を実現する手法やユーザーとの関係性があるか？
- 特にオンプレ製品では、機能削除やバージョンアップの負担が非常に大きいが、そのリスクを許容できるか？
（私は）なぜ機能を作りたがるか
| 背景 | コメント |
|---|---|
| 「売れそう」「売ってくれそう」という根拠のない期待がある | 営業さんとの対話が足らないかもしれない |
| 「便利になる」「製品が成長する」「デザインが美しくなる」という期待がある | 完成度は上がるかもしれないが、投資対効果はないかもしれない |
| 要望を切り捨てた結果、「あの会社は全然対応してくれない」という反応にならないかという不安がある | ユーザーやパートナーと真摯に話す機会が少ないからかもしれない |
| 機能テーマを「切り捨てる」結果、能力・リソース不足だからだと負けた気持ちになる | そのマインドは変えて |
| 顧客が現状業務を変えたがらない | 顧客の業務は顧客が一番熟知しており、外部から変更を提案するには高いハードルがある。顧客のニーズの深堀りや、日頃から業界知識の取得を心がけるなどが重要と思われる （逆にその業務が優れたものであれば、パッケージとして取り込み、世に広めてもよいかもしれない） |
| 開発者の稼働率を上げたい | 戦略テーマ対応、リファクタリング、改善、不具合改修、サポート、インフラなど色々あるし、キャリアの一環として開発以外のタスクも検討してもらってもよいかもしれない |
| 細かい要望なので、優先度をつけるよりやった方が早い | 空いた時間の解消なら良いが、細かい要望の対応を積み重ねる結果、注力対象が疎かになるかもしれない |
「作らないこと」はネガティブな要素だけではない
機能開発を絞り込むと以下のメリットがあります。「作らない」という選択肢もありなのです。
- リソースを集中できる
- シンプルで安定した製品を提供できる
- 製品の競争的要素を明確にできる
「作らない」と決めた後の対応について
「信頼を失わない」「機能は作らない」両方やらなくっちゃあならない
ただ断って終わりにするのではなく、対話を通して課題を何かしら前に進め、関係性を維持することが重要と思います。
説明例
- まず話を聞き、課題感を共有してもらう
- 現在の製品ビジョンや戦略、状況を説明する
- 代替案を提案する
ちょっとしたツールの提供、パートナーによるカスタマイズ、運用提案、事前検証依頼など - フォローアップする
NG例
- 放置
- ただリソース不足を理由に断る
- ただ技術力不足を理由に断る
- 曖昧な先延ばし
- 戦略との合致性の説明無し
まとめ
開発対象を絞り込むことは、プロのプロダクトマネージャーとして開発対象の決定に真摯に向き合うことです。
作るかどうかを決めるために、客観的に問いかけを繰り返すことが重要と思っています。
「作らない」と決めることはネガティブではありません。ただ、「作らない」と決めた後にステークホルダーとの関係性を保つために対話すると良いです。
そして、本当に必要なものはちゃんと作っていきましょう。