IT関連SIerなどの営業さんとお話しする機会がありますが、まだコンテナ関連の営業トークをするには自信がない方がいらっしゃるように思います。
このBlogでは、そういった営業の方を少しでも支援できるようなトークを分かりやすくご紹介します。第一回目の記事ですが、『お客様にDXの話しを持ち掛けるときどうする？』がテーマです。
第一回記事：「DXを売る」IT営業が気を付けるべき7つのポイント
第二回記事：「DXを売る」”DXに関心を持たせる” 営業トーク 」
第三回記事：「DXを売る」営業の”知ったかぶりコンテナ・トーク”」
第四回記事：「DXを売る」”IT自動化とDX推進を繋げる５つのポイント”
第五回記事：「DXを売る」営業の素朴な疑問 ”コンテナってどこでも動くの？”
第六回記事：「DXを売る」営業の素朴な疑問 ”サイドカーって何モノ？”
第七回記事：「DXを売る」営業の素朴な疑問 ”コンテナ向けOSって何？”
第八回記事：「DXを売る」DX営業”OpenShiftの特徴を説明できる?”（1/2）
第九回記事：「DXを売る」DX営業”OpenShiftの特徴を説明できる?”（2/2）
第10回記事：「DXを売る」DX営業 ”サービスメッシュ” を説明できる?
第11回記事：「DXを売る」DX営業 ”API連携とは何？”を理解する
第12回記事：「DXを売る」DX営業 ”APIマネージメントとは？” を理解する！
第13回記事：「DXを売る」DX営業 ”K8sの機能を理解する”！
第14回記事：「DXを売る」DX営業 ”Podmanを知っている？”
第15回記事：「DXを売る」DX営業 ”Pod”についての理解
お客様がよく抱えている課題とは
これを書いている私、長谷川ですがサイオステクノロジー株式会社でDX Product & Integration Service Line Service Line Headを務めております。定年の歳を超えたシニアです。
電子機器やコンピュータ、ネットワークの企業で営業、マーケティング、事業企画を計35年ほど担当し、今はサイオスでRed Hat製品を中心としたOSSに関する事業企画を担当しています。
私が過去に担当したお客様では、例えば下記のような課題を抱えていらっしゃるケースがとてもよくありました。
今回はこのケースを例に、『お客様にDXを訴求するために営業がすべきこと』を説明したいと思います。
【ポイント１】鉄則
冒頭からあなたの販売したい製品を説明してはいけません。お客様の状況を聴くのが先です。
【ポイント２】お客様が話しやすい環境作り
世間話からスタートし、顧客の関心の高さを知るために、以下のような会話から始めるのがよいでしょう。
＊新型コロナウィルスによるパンデミックは、想定以上のインパクトがありましたよね。
＊顧客の購買傾向が変わったり、購買方法が変わったり、売れているものが売れなくなったり、逆にあまり売れていなかったものが売れたりしていますよね。
＊コロナの影響でキャッシュレスが進んだり、消費者が農家などの生産者から直接購入したり、宅配サービスが増えたり、ペーパーレスが急激に進んだり、自動車メーカーがフェイスシールドを作るなど、今後のNew Normalと言われる将来のイメージが恐らくまだ様々な調査会社自体もわかっていないようで、しばらくの間は安定しない環境が続くのではないかと私は思っています。
【ポイント３】お客様にITシステムの柔軟性が必要であることを認識させる示唆質問
＊御社にとってこのような急激な環境の変化にどのように対応しなくてはならないと思いますか？
＊御社のビジネスは様々な生産設備やそれを支えるITシステム、従業員を支えるITシステム、ビジネス間のITシステム（B2BやB2Cなど）が動いていますよね。
このような環境の変化が今後継続的に発生するとしたら、このITシステムも柔軟に変更していく必要があると思いませんか？
＊現在日本の多くのITシステムは、アプリケーションがモノリシックで一体型のため開発にも数年かかり、変更など改修にも多くの時間がかかることは知られています。このような変更に時間がかかるITシステムは、環境の変化に追従できないですよね？
＊例えば、今回の国からの給付金をすぐに受け取れましたか？急な給付金対応は結局手作業になったり、既存のITシステムが使えなかったりで大変でしたよね。
海外では、1週間程度で給付金を受け取れた国もあったようにニュースで観て驚きました。
＊事業の場合、このような政府のITシステムのような対応では信頼ががた落ちになってしまいますよね
【ポイント4】マイクロサービスと柔軟性を結び付ける
＊マイクロサービスアーキテクチャってご存じですか？
＊簡単に説明すると、先ほどのモノリシックとは異なり、機能ごとに小さなアプリケーションを沢山作ってつなげる方法なんです。もしもこのような小さなアプリケーションの集合体ならば、その小さな単位毎に修正ができますし、小さな単位で機能追加が用意にできます。
このマイクロアーキテクチャを使えば、環境の変化に追従しやすいと思いませんか？
＊例えば、皆さんが普段使っているスマホのアプリケーションなどの多くは、こういったアーキテクチャを使っているのです。頻繁にアップデートして新しい機能がすぐに使えるようになりますよね。
【ポイント5】マイクロサービスとコンテナ、コンテナプラットフォームを繋げる
＊マイクロアーキテクチャが柔軟なITシステムに必要であることをご理解いただきありがとうございます
＊次にマイクロサービスを使うと、各機能毎のアプリケーション同士を繋げなくてはなりません。機能が沢山あればそのネットワークはとても複雑になります
＊そこで、このマイクロサービスをコンテナ技術を使ってコンテナで包んでしまい、それをコンテナプラットフォームでオーケストレーションすれば、これらのネットワークなどのことをアプリケーション開発者は考えなくても済みますし、さらにはアプリケーションが動作するハードウェアプラットフォームを全く意識しなくてもよくなります。
便利だと思いませんか？ 開発言語も自由で機能ごとに変えてもかまいません。
アプリケーション開発者にとっては、開発に集中できるというわけです。
＊コンテナがDockerといわれているものだったり、コンテナプラットフォームがKubernetes（K8s）だったりします。K8sの商用版はRed HatのOpenShiftです。
【ポイント6】お客様のDXに関する考え方や方針などを聞き出す
＊柔軟性が必要であり、これがDXの取り組みのひとつだと考えていますが、御社では既存のシステムをどう改修していく予定がありますか？
＊新規のアプリケーションはどのような考えで開発されていますでしょうか
【ポイント7】適切な提案先の部署を教えてもらう
＊既存システムの改修などをおこなう部署や新規アプリケーションを開発する部署はお教えいただけないでしょうか
