連載：第四回「DXを売る」”IT自動化とDX推進を繋げる５つのポイント”

はじめに
「DXを売る」シリーズを担当しているサイオステクノロジーの長谷川です。
身近な営業課題として、IT自動化の製品であるAnsibleの営業活動をしてもDXの案件に結び付けられていません。逆にDXの話題からIT自動化ソリューションの提案に結び付いていません。
何故だろうと考えたときに、きっとDXとIT自動化との関連性が抜けているのだろうと仮定し、そのヒントとなるようBlogにしました。お役に立てば嬉しいです。

この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”についての理解

【余談１】IT自動化の目的って何だっけ？

まずIT自動化の定義ですが、Red Hatさんが出しているEブックによれば、
「自動化とは、コスト、複雑性、ミスを削減する目的で、ソフトウェアを使用してタスクを実行することです。」とあります。さらにこう記述されています。「自動化の主な目的は、忙殺されているスタッフが制御 力を取り戻し、単調で決まり切った作業から戦略的な業務へ労力を集中できるようにす ることです。IT 自動化により、スタッフはより良い仕事ができるようになり、満足度が高 まります。」

エンジニアと話していると、夜とか休日にシステム変更作業をするとか聞くことがありますよね。数十台～数百台のサーバーの設定作業や大量のPCの設定、セキュリティ設定をしたりと既存システムにかかる人手はすごく多くかかっているのはご承知のとおりです。

Red HatさんのEブックに記述されている内容から以下のことが言えます。
「IT自動化を適切に推進できれば、運用にかかっていたエンジニアの時間に余裕がでてくる！」

参考までにRed HatのEブックの入手先URLはこちら

【余談２】エンジニア不足の壁

多くの企業は、New Normal時代をどう対応していくのか？　2025年の崖から我が社は落ちないだろうか？DXはどう進めていけばよいのか？　など沢山悩んでいるはずです。これは多くの企業の共通課題です。厚労省によれば、
「IT人材の不足は、2030年までに79万人不足が予測されている」
とあります。

75万人が多いのか？少ないのか？あまりイメージが湧きません。
ITには関係ないですが、東京ドームのコンサート開催時の収容能力は57,000人のようですので、東京ドーム13個分となる人数です。　多いのか少ないのか分かりにくくて申し訳ないです。

【ポイント１】お客様のエンジニア不足をヒアリング

例えばAnsibleの導入を検討しているお客様がいるとします。
運用を担当している部署に行くのも直接的でよいかもしれませんが、エンジニアリソースに余裕がでてきても嬉しいかどうかは不明です。ここでは、DXに絡むエンジニア（CICD関連など）の部署やさらに経営企画などDXを推進させる部署のマネージメントレベルにコンタクトするべきと考えました。なぜなら、エンジニアリソース不足が深刻な問題だからです。
ヒアリングとしては、以下となります。

• DXを推進する上で十分なエンジニアリソースは足りていますか？
• DX関連のエンジニアの採用は順調ですか？
• 外部からの採用と社内エンジニアの転向などの計画はありますか？

エンジニア不足という回答があることを想定し、さらに深くヒアリングするのがよいでしょう。

• 現状のエンジニア数
• 今後採用を見込んでいるエンジニア数
• それでも不足しているエンジニア数

以上、いつまでに何人くらい必要なのかを具体的にしたいところです。

【ポイント２】リソース不足解消できる可能性を示唆質問する

社内のエンジニアリソース転用によりDXエンジニア不足が解消できる可能性について示唆質問をしてみます。

• 事実確認の質問
  「やはり、お客様のところでもエンジニアリソースが課題なんですね」
  「エンジニア採用はどこも苦労しているようですが御社も苦労しているのですね」
  「今の推移では、DX開発計画が大きく遅れる可能性があるっていうことですね」
• 示唆質問
  「もしも社内エンジニアがDXのエンジニアとして使える機会があればリソース不足の問題は解決できると思いませんか？」
  「新聞記事によれば、大手の企業では、社内の人材にデジタル教育を再教育としておこなうことでDXに備えるようですが、既存のエンジニアリソースをDXエンジニアへ転向できたらよいと思いませんか？」
• さらにお客様企業でエンジニアリソースが多くいる部署をヒアリングしてください

以上により、お客様の課題が共有でき、さらに、社内のエンジニアがうまく転用できればDX推進に希望が持てる意識を強く持っていただきます。

【ポイント３】顧客企業の中で味方を作る

ポイント2で把握したエンジニアリソースを多く保有している部署から、IT自動化でリソースが出そうな部署をお客様と打合せをし、ターゲット部署としてリスト化します。
そのリストには、部署の組織と人数や何をしている部署なのかを纏めます。

DXのエンジニアリソースが足りていない部署のマネージャとのリレーションを強化し、IT自動化によるリソース確保のアプローチに対して味方になってくれることを約束してもらってください。

可能ならば、経営企画など企業の中でニュートラルな部署からIT自動化によりエンジニアリソース確保の方針を全社的にだしてもらうのがよいです。

【ポイント４】Target部署へIT自動化ソリューションを提案する

実際に多くのエンジニアリソースを自動化を適切に活用していなそうな部署へIT自動化を提案し、IT自動化により効率が向上し、現状のエンジニアリソースに余裕ができることを認識させてください。
ただし一般的にはリソースが余れば、人員整理などマイナス面を考える場合がありますので、ポイント３で述べたとおり経営企画など事業や部門にニュートラルな立場のセクション、又はもっと上のレベルに協力してもらわないと政治的な問題になるかもしれません。

提案のプロセス案としては以下のとおりです。

1. Ansibleなどを使ったIT自動化ソリューションに関して、一般的なIT自動化について説明
2. 例えばIT運用を担当している部署であれば、以下をヒアリングしましょう
   1. 現状の運用対象の洗い出し
   2. そこに必要なエンジニアリソースの人数
   3. 運用に関する売上、利益、エンジニアコスト
3. 仮にIT自動化を進めた場合の、利益の向上、必要なエンジニアリソース数をシミュレーションして提案します
4. DXエンジニアへ転向可能な人数を想定し、可能ならば転向可能なエンジニア名まで具体的に候補を上げる方がよいです

【ポイント５】エンジニアリソースの転向をより具体化する

具体化にするシナリオは以下のとおりです。

• エンジニアの転向はスキルセットが変わるので、エンジニア本人の意向もあると思いますが、どのようなエンジニアに転向しなくてはならないのかをスキルマップを作成して教育体制を整えます
  • 広範囲なトレーニングをサブスクで提供しているRed HatのLearning Subscriptionはお得で便利です
  • サイオステクノロジーでもコンテナの基礎からK8sの基礎を学べるお手軽なコースがあります
• 誰をいつまでにどのようなエンジニアにするかについてスケジュールを立てて進めます

【まとめ】

1. DX関連でエンジニア不足のセクションにコンタクトし、エンジニアリソース不足の状態を認識する
2. IT自動化によりエンジニアリソースを絞りだす案を合意する
3. 企業の中でニュートラルな立場の部署（経企など）からIT自動化によりエンジニア不足を解消する方針をだしてもらう
4. エンジニアの転向を具体的にする
5. IT自動化の導入提案とエンジニア転向の教育を提案する

今回のBlogの内容はお役に立ちましたでしょうか？
今後のBlog記事に関するご要望や実際のビジネスでのご相談事などございましたらお問合せいただきますようお願いいたします。最後まで読んでいただきありがとうございました。