2-5)IT営業はAWSをどう扱えばいいのか──全部知らなくていい、正しい向き合い方

ここまでで、

• そもそもクラウドとは何か
• AWSは完成品ではなく、部品の集合体である
• オンプレミスとの違いは判断の話である
• AWSが分かりにくいのは思想の結果である

という前提を整理してきました。

この時点で、IT営業として一番大事な問いはこれです。

じゃあ、実務ではAWSをどう扱えばいいのか？

結論から言います。

全部を理解する必要はありません。正しく“扱える”状態になれば十分です。

AWSは「全部使うもの」ではない

まず、一番多い思い込みを外します。

AWSはたくさんサービスがある→ たくさん使うもの

これは間違いです。

AWSは、

1. 必要な部品だけを
2. 必要な範囲で
3. 組み合わせて使う

ことを前提にしたサービスです。

多くの現場では、使っているのはAWS全体のごく一部というケースがほとんど。

「全部理解してから使う」という発想自体が、AWSの思想と合っていません。

IT営業に求められるAWSの理解ライン

では、IT営業はどこまで理解していれば十分なのか。

営業が理解しておくべきこと

• AWSは「何者」か（完成品ではない）
• 何を提供し、何をしないか
• 業務のどこに関係するか
• 判断の軸（スピード・柔軟性・運用負荷）

営業が無理にやらなくていいこと

• 詳細な構成設計
• サービス単位の深い技術理解
• 料金の正確な試算

営業の役割は、技術を語ることではなく、話を整理すること

ここを間違えないことが大事です。

サービス名から話してはいけない理由

AWSの会話で、一番よくある失敗がこれです。

この話し方をすると、会話はほぼ確実に噛み合いません。

理由はシンプルで、

サービス名は“解決策”の話だから

です。

解決したい課題や業務が整理されていない状態で、解決策の名前を出しても、相手の頭には入りません。

AWS導入の話が噛み合わなくなる瞬間

よくあるズレは、だいたいこの順番で起きます。

1. 顧客：「AWSを導入したい」
2. 営業：AWSの説明を始める
3. 顧客：結局、何が変わるのか分からない

ここでズレているのは、AWSではなく順番です。

営業がやるべきは、

• なぜそう思ったのか
• 何が困っているのか
• どこを変えたいのか

を一度、言語化すること。

AWSは、会話の最後に登場する存在です。

営業が立つべき「整理ポジション」

AWSの話で、営業が一番価値を出せる場所はどこか。

それは、

• 「業務」と「IT」の間
• 「顧客」と「エンジニア」の間

です。

営業は、「詳しい人」になる必要はありません。

「話を翻訳し、整理する人」であればいい。

• 顧客の言葉を構造に落とす
• エンジニアの話を業務に戻す

このポジションに立てる営業は、AWSの知識量に関係なく評価されます。

AWS全体マップという考え方

AWSを扱うときに役立つのが、「全体マップ」 という考え方です。

• すべてのサービスを覚える
  のではなく
• どの役割の部品があるかを把握する

例としては、

• 計算する（コンピューティング）
• 保存する（ストレージ）
• つなぐ（ネットワーク）
• 守る（セキュリティ）

という大枠を押さえる。

これだけで、

• 話の迷子にならない
• 個別サービスの位置づけが分かる

ようになります。

このあと、個別サービスをどう読めばいいか

ここまで来たら、いよいよ個別サービスです。

ただし、読み方にはコツがあります。

• 使う予定のないサービスは読まない
• 役割が分からないものは、まず飛ばす
• 「これは何を担当する部品か？」だけを見る

たとえば、

• EC2
• S3

といった記事も、

「AWSの中で何を担当している部品か」

という視点で読めば十分。

さいごに

AWSは、

全部を知る対象ではなく、正しく付き合う対象

ここまで理解できていれば、IT営業としては十分。

この先は、

• 必要なときに
• 必要な分だけ
• 必要な深さで

AWSを使っていけばいい。