競合と同じ機能は、自社にも必要？
目次
「競合にはあるのに、なぜ自社にはないのか」。商談や社内会議でこう聞かれると、同じ機能を急いで作りたくなるかもしれません。まず確かめたいのは、その機能がないことで、どの顧客の何ができなくなっているかです。
競合の機能は、顧客の期待を知る手がかりになります。ただし、機能一覧に差があることだけでは、自社で作る範囲や方法は決まりません。この記事では、競合と比べて出てきた要望を、顧客の仕事と利用条件に戻して検討する手順を説明します。
- 競合にあるという事実と、自社の顧客に必要という根拠を分ける
- その機能で終えたい仕事と、今の代替手順を確かめる
- 同じ機能を作る案に加え、小さな対応や見送りも比較する
機能の有無から、できない仕事へ問いを変える
「競合と同じレポート機能が欲しい」という言葉には、いくつかの可能性があります。上司に毎月提出する資料を作りたいのか、担当者ごとの状況を確認したいのか、社外へ共有したいのかによって、必要な内容は変わります。
機能名を聞いたら、「それを使って何を終えたいのか」「今はどうしているのか」「今の方法では何が困るのか」を続けて確かめます。機能の呼び方が同じでも、権限、扱えるデータ、出力形式まで同じとは限りません。
英国政府のサービス設計基準は、先に選んだ技術や解決策ではなく、利用者のニーズを中心にサービスを設計する考え方を示しています。競合の方法を参考にするときも、自社の顧客が完了したい作業を出発点にできます。
競合調査をやめる必要はありません。自社の顧客の課題を確かめる情報と、他社が提供している方法の情報を、別の欄に置いておくと混同を避けられます。
比較表には、出典と利用条件も書く
競合の紹介ページに機能名が載っていても、全プランで使えるとは限りません。公開資料で確認できた事実と、未確認の点を分けます。推測で空欄を埋めないことが大切です。
本記事では、次の項目をそろえることを提案します。
- 競合で確認した内容：公式ページの説明、対象プラン、確認日。
- 顧客がしたい仕事：誰が、どの場面で、何を完了したいか。
- 現在の方法：自社の既存機能、表計算、手作業などでどう対応しているか。
- 残る支障：作業が止まる、繰り返し入力が必要など、具体的に何が起きるか。
- 導入判断との関係：必須の条件か、望ましい条件か、単なる比較項目か。
営業担当から「この機能がなくて失注した」と聞いた場合も、その一言を結論にしません。顧客が実際に伝えた理由、営業担当の見立て、まだ確認できていないことを区別します。価格や導入時期など、ほかの条件が関係していたかも確認してください。
競合の画面を見ただけで、使いやすさや利用実績まで評価しないようにします。自社で検証できていない内容は、顧客へ約束する機能や性能の根拠にはできません。
架空の「自動レポート」要望を検討する
以下は、架空の問い合わせ管理サービスの例です。顧客、機能、判断内容は説明用で、アーコレ！の提供機能や実際の商談ではありません。
導入検討中の顧客から、「競合のように、レポートを自動送信できるとよい」と言われました。担当者は、競合と同じ配信設定画面を作る案を考えています。
背景を確かめると、顧客が終えたい仕事は「毎月の会議で、未対応の問い合わせと担当者別の件数を説明すること」でした。現在は一覧を出力して表計算で整えています。困っているのは、送信操作よりも、毎回同じ項目を選び直す手間でした。
この架空例では、次の三案を比較できます。
- 競合と同じ方向で、自動配信と配信先の管理を新しく作る。
- 会議で必要な項目をまとめた出力方法を用意し、送信は今の手順を使う。
- 既存の出力方法を案内し、困りごとが残るかを追加で確認する。
二つ目が必ず正解ということではありません。別の顧客では、決まった相手へ送る作業そのものが負担かもしれません。例の顧客についても、実際に送信担当者へ確認するまでは「自動送信は不要」と決めないでください。
必須条件と、あると助かる条件を分ける
「欲しい」の強さを言葉だけで比べるより、その機能がない場合に何が起きるかを確かめます。次の問いに答えると、導入や継続に必要な範囲を整理できます。
代替手順で、仕事は成立するか
既存機能と手作業を組み合わせれば終えられる場合でも、その負担を無視しないでください。誰が、どの頻度で、何を補っているかを書きます。担当者が一人で支えている運用なら、その人の不在時に成立するかも確認します。
逆に、代替手順を試したことがないなら、「できない」と「方法を知らない」を分ける余地があります。案内して済む可能性はありますが、説明を読めば誰でも使えると決めつけず、必要な作業を終えられるか確かめます。
自社が対象とする顧客でも必要か
要望を出した顧客の利用目的が、自社の製品方針と合うかを確認します。一社だけの声でも、同じ仕事をする対象顧客に共通する条件があるなら、調べる価値があります。反対に、件数が多くても、別の用途に製品を広げる話なら、追加機能だけで解決するかを慎重に考えます。
顧客像がまだ曖昧な場合は、顧客ニーズを把握する方法を使い、誰の困りごとを調べるかから整理できます。
作ったあとも、無理なく支えられるか
競合の画面に似せるだけでは、運用に必要な範囲を見積もれません。架空の自動配信なら、配信先の変更、送信失敗、閲覧権限、問い合わせへの対応も検討対象です。
この段階では、詳しい技術仕様を一人で作る必要はありません。開発・サポート担当に、利用条件と候補案を渡し、継続的な負担や不明点を確認します。顧客には、調査中の案を確定した予定として伝えないようにします。
結論は、作るかどうかと理由を短く残す
検討の結果は、「競合に追いつくため」だけで終わらせず、どの仕事をどこまで支える判断かを書きます。次の形なら、あとから別の競合機能が出ても比較をやり直しやすくなります。
- 対象の仕事：月次会議で必要な状況を、担当者が報告できること。
- 今回の案：必要項目をまとめて出力する方法を検討する。
- 今回含めないこと：自動配信、配信先管理、定期送信の設定。
- まだ確かめること：送信自体に支障がある顧客が、対象層にいるか。
- 再検討する条件：送信の代替手順では仕事が成立しない例を確認した場合。
このメモも説明用です。実際には、元の発言や公開資料への参照を添えてください。機能を作る必要性が見えてから、ほかの候補との開発優先順位を比べます。競合の公開日を、そのまま自社の開発期限に置き換える必要はありません。
よくある質問
競合にない独自機能を優先したほうがよいですか？
独自かどうかだけでは決まりません。対象顧客の仕事に必要な基本機能も、独自の解決方法も候補になります。どの困りごとを解消するかと、自社で支えられる範囲を確認します。
顧客が競合と同じものを強く希望しています。どう聞き返せばよいですか？
希望を否定せず、『その機能を最後に必要とした場面を教えてください』『今の方法では、どこが難しいですか』と尋ねます。同じ機能が必要だと分かる場合も、別の方法で満たせる場合もあります。
まとめ
競合の機能を検討するときは、公式資料で分かったことと、自社の顧客が困っていることを分けます。機能名から仕事へ戻り、必要な範囲と代替手順を比較して判断してください。
比較表だけなら管理表で始められますが、商談や問い合わせごとの背景が別の記録に散らばると、同じ要望かどうかを確かめる手間が増えます。アーコレ！が紹介する要望整理の仕組みは、集めた顧客の声を検討材料としてまとめる入口になります。競合調査や開発判断そのものとは分けて活用を考えてください。
