こんにちは、スマホアプリ・Webサービスの受託開発の営業・マーケティング職です。
営業という業務・職種についても、技術的に体系化できるんじゃないかと思い、記事を書くに至りました。

ソフトウェア受託開発における営業メソッドみたいな書籍や正解があまりないようなので、IT業界の方が多いメディアを利用して、集合知にしていけると業界の発展に貢献できるのではないかと思っています。

プログラミングのHow toについて書かれている記事ではありませんが、今SEやPMを担当されていて、これから営業にスキルチェンジを検討されているかた・営業が何しているのか興味あるかたなど、何か参考になりましたら幸いです。

はじめに

このエントリーでは、受託開発企業における、「1プロジェクトにおける営業業務」を範囲として考えます。
その上で、営業業務を効果的・効率的に遂行するために必要となる職能 = 営業技術として、紹介するものになります。

今回は、第1回として、営業の価値についてと、いくつか項目レベルで列挙することに留めていますが、今後、実践を通して理解を深めながら、項目毎の体系や関係、そして事例について整理していきたいと思います。（何回続くか今のところわかりません・・・）

ちなみに僕は大企業（あるいは仕組みの整った）SIerでの経験はないので、経験則に基づいたエントリーになる旨はご了承ください。
ご指摘、他の考え方や参考著書などなど、フィードバックいただけると非常に嬉しいです。

営業の価値

まず営業の技術にふれる前に、受託開発会社における営業の価値について解説しておきます。
この価値を発揮するために必要な手段が、まさに営業技術となるからです。

1). 社外的な価値

• 顧客・エンドユーザの満足度の最大化
• 顧客のビジネス課題の解決、持続的な発展へ貢献

言葉にするとキレイ事ですけど、実際そうです。
現代の受託開発のあり方は、旧来の「仕様を満たして納品」だけではなくなっています。
如何に顧客のビジネスに寄り添っているか、コンシューマの生活に寄り添っているか？がテーマとなってきており、アジャイル開発やDevOpsが国内でも発達している事もその背景が関係しています。
つまり初回ヒアリングの段階から、数年を見越した関係性とビジネス、そしてシステム寿命を想定しておく必要があるのです。

2).社内的な価値

• 売上、利益の確保
• エンジニアの成長チャンスの創出

特に、「エンジニアの成長チャンスの創出」は、営業にかかっている価値だと思っています。
受注した案件の中で、どれだけ実践的にチャレンジできるか。この幅の広さで、受託企業の人材成長性は変わってくると考えています。

大切なのは、1),2)を両立するマインドを持つ、ということです。
1)を満たした上で、2)が発生するという順序は原理原則ですが、この2つは循環の関係にあります。
利益が確保できるから採用に投資でき、さらに生み出す価値が大きくなります。
ですので、どちらが優先ということはあまりなく、どちらも重要です。

営業の技術

価値を実現する手段・技（ここでは営業業務）をそのままテクノロジーとして解釈すると、
エンドユーザの満足度を最大化させ、自社の売上(利益)に変換する技術 と言えます。

開発は、要求や仕様を満たすための技術だと思いますが、営業を敢えて対比させるならば、顧客の「欲求」を満たす技術とも言えるのではないでしょうか。

さらに技術という文脈では、基礎技術と応用技術に分かれます。
営業における基礎技術、というものは、ざっくりいうと心理学に基づいていますが、基礎技術については割愛し、応用技術について書きます。
その中でも、特に個人的に重要視しているものを紹介します。

技術力（職能）

1.課題発見フェーズ

対面する顧客の欲求や課題を明らかにし、インプットする段階での技を想定します。
開発サイドに適切に情報共有したり、顧客への提案までの流れをスムーズにするために必要な技術を羅列します。

• 傾聴力と質問力
  • とにかく聴く。「聞く」ではなく「聴く」ということが大切です。
    • 「聴」という漢字には、耳、目、心が書かれています。その文字通り、目線や相手の素振り、相手側関係者のパワーバランスなど深く観察することで、聞く以上の情報を把握すること大切です。
  • 次に、情報を網羅的にするには、適切な質問が必要です。
    • 特に初対面の場合は、質問の意図を先に伝えると、相手は答えやすくなります。
    • オープンクエッション・クローズドクエッションを使いわけましょう。
  • 最終的には8:2〜7:3くらいの割合で、相手にお話しいただくくらいの目安がいいと考えます。
• 共通言語化
  • 自分たちが普段使っている単語と、顧客が放った単語の意味は果たして同じでしょうか？
  • 「要件定義はうちがやりますので」「アジャイルで！」などよく聞きますが、経験のある方が聞くと嫌な予感しかしないと思います。
  • 具体的に何を指しているのか、どんな状態・行動をその名前で呼んでいるのか、予め言語化したものを共通認識にしておきましょう。
• 構造化と可視化
  • 断片的な情報を構造的に理解し、かつ関係者に効率的に共通認識（共通言語化）にさせるため見える化する技術です。
  • 情報は、おおよそMECEに分類することができます。ダブリは許容できますが、モレは極力減らしていきましょう。
  • 図解、マインドマップやアウトライン、Markdownなど、可視化の手法は様々ありますが、適切に使い分けられるといいでしょう。
• 客観視と懐疑力
  • ヒアリングした情報はそのままでは、様々なバイアスがかかっている場合があります。
  • 担当の希望的観測、部門の都合、事実ではない推測、代理店の思惑など、ノイズになります。
  • 主観を排除し、自分自身も含めた個人のバイアスをかけずに情報区別することが重要です。
  • あるいは、そのノイズを分析することで、ステークホルダーを分析する事も可能です。
  • 客観視した情報をさらに深堀りします。
  • 聞いたままの情報が、本当の要求であるとは必ずしも限らず、局地的な要求整理となっている可能性もあります。
  • 「事実 OR 解釈」「エビデンス有り OR 推測・伝聞」等、構造的に可視化することで、情報の信憑性を分ける事ができます。
• QCDバランス
  • プロジェクトには様々な変数が存在し、QCDバランスが特にわかりやすいと思います。
  • Quality（機能の質と量）を上げるとCost（費用）・Delivery（=工期）も膨れるのはイメージしやすいと思います。
  • このようなトレードオフになりやすい、依存性のある情報や条件は、後で交渉材料にすることができます。
  • しかし、この事実を放置している場合があります（あるいは知らんぷりされる）。重要なのは、先にこの事を共通言語化にし、可視化しておくというコンボで対応しましょう。
• 変化を感じ取る
  • 顧客は、他社事例や業界を研究し、ビジネスの改善に常に努力しています。1ヶ月前の言動や優先順位は、あくまで1ヶ月前の意見でしかありません。
  • つまり、QCDバランスも、少しずつ変化していきます。
  • 「相手は変化する」ということを認識し、何故・どのように変わったのかを知る必要があります。
  • 一方で「変わらないもの」が見つかれば、それは真の課題を見つけるヒントかもしれません。

あとがき

今回は営業自体の価値と、課題発見というフェーズにおける営業技術の要素をいくつか紹介しました。
各項目内で、別の項目の言葉が出現していると思いますが、それぞれが相互作用している事がわかります。ちなみにワードセンスが絶望的なので、適切なワードがあったら是非ご指導お願いします。うちの会社だとこんなこと重視してるよーみたいなフィードバックがあれば、是非情報交換したいです。

今回は課題発見フェーズでしたので、次回は問題解決フェーズなど、また別のシーンを想定してまとめていきたいと思います。

最後に、プログラミング同様で、技術は磨くことができるものですので、全て意識的に取り組むことで発達、改善が見込めます。僕は、営業はセンスではなくサイエンスだと思ったりしています。この業界で、営業が変な受注の仕方をして関係者全員不幸になった、といった事がなくなることを願います。