営業という仕事は、突き詰めれば「売ること」ではなく、相手が意思決定できる状態をつくることなのだと思っています。
もちろん会社としては、受注や売上をつくることが目的です。ただ、営業の仕事そのものを「商品を売り込むこと」だと捉えてしまうと、たいてい歪みが出ます。相手の課題を見つけ、整理し、解決の選択肢を示し、決断を助け、約束を取り付ける。この流れの方が、本来は自然だと思います。
受託開発の営業は、少し特殊
受託開発という範囲に絞って営業を考えると、少し特殊な仕事だと感じています。モノ売りのように「この商品どうですか」と勧めるものではなく、受注した時点ではまだ商品そのものが存在していないからです。
本質は、「まだ形のない案件を、受注できる状態まで具体化する仕事」だと考えています。曖昧な要望を聞き、本当の課題を見つけ、何を作るべきか整理し、予算・納期・体制・リスクを現実に落とし込み、自社で責任を持って遂行できる範囲を見極めたうえで、契約に持っていく。ここまでが営業の仕事です。そう考えると、実はエンジニアが直接担った方が早い部分も多いのではないか、とも思います。
受託営業の実態は、受注対応に近い
一般的な受託営業の実態を見ていると、案件化された相談を受けて社内へつなぐ窓口になっていることが少なくないように見えます。もちろん新規開拓に動いている営業もいますが、紹介や問い合わせ、既存客からの「こんなの作れる？」がきっかけで初めて動くのであれば、それは営業というより受注対応に近いと思います。
そもそも「受託開発」という言葉自体が、最初から主導権を客側に置いています。客が課題を見つけ、システムが必要だと判断し、ベンダーを探し、声をかける。そこでようやく開発会社が登場する。この構造では、技術会社でありながら、一番価値を出せるはずの「何をすべきか」の判断に、最初から参加できていません。
提案開発なら、順序が逆になる
だからこそ、受託開発ではなく提案開発の方が本質的だと考えています。提案開発であれば、「何か作りませんか」ではなく「御社、ここに困っていませんか」から始まります。さらに言えば、「これはシステムを作らなくても解決できますよ」という提案があってもいい。ここまでいくと、営業と開発を分ける意味は、だいぶ薄くなってきます。
全員が課題を見つけられる会社へ
理想の形は、全員が顧客の課題を見つけられて、全員が解決策を考えられて、必要なら自分たちで作れる会社だと思っています。
技術者が客先で「このExcel運用、毎月何時間かかっていますか」と尋ねる。保守担当が「この問い合わせ、毎回ありますけど、画面を変えたら減りませんか」と拾う。経営側が「御社のこの業務、AIを使ったら半分になりますよ」と提案する。そこから案件が生まれる。これなら、案件の発生を営業部だけに依存せずに済みます。
普通の営業会社が「売るもの」を探しているのに対して、開発会社は見つけた課題を自分で解決できる。これは、実はかなりの武器だと思っています。「受託開発」という呼び方より、「課題発見型開発」、あるいは「依頼されて作る会社」ではなく「課題を見つけて提案する会社」と言った方が、実態に近いのかもしれません。
「私たちは、”作る会社”ではありません。」と言いたくなるのは、こういう理由からです。営業部・開発部という縦割り自体が、もう少し前の時代の発想なのかもしれないと思っています。