内製化のポイントはビジネスとITの密な連携　AWSが推進する、塩漬けにしないためのBizDevOps

自己紹介とアジェンダ

相澤恵奏氏（以下、相澤）：アマゾンウェブサービスジャパンでパートナーアライアンス統括本部テクニカルイネーブルメント部のリードをしている相澤と言います。

始めのセッションでは、今AWSから企業の内製化がどういうふうに見えているか。お客さま、パートナーさまからどういう声を頂いているかを15分ほどで説明します。よろしくお願いします。

私の部署では、国内のAWSコンサルティングパートナーの内、約300社に対して技術的なサポートをしています。もう1つ特徴的なのが、エンジニアのイネーブルメントもやっています。パートナーさまのエンジニアのイネーブルメントを通じて、どういう育成、イネーブルメントがいいかも少し最後にコメントとして入れたいと思います。

「内製化」という言葉の定義

まず始めに、内製化という言葉の定義をしたいと思います。こちらはIPAが出している『人材白書2020』から取ってきたものになります。非常によくまとまっているので、1回説明します。

ユーザー企業さまへというところで、IPAの中では「IT業務の内製化（企画・設計・上流工程）に向かう動きは活発になっている。それに伴い中途採用による人材獲得・確保やIT人材の『質』の不足の課題が見え始めた」。さらに、「DX推進はビジネスとITの連携が不可欠である。ビジネスとITをつなぐ人材の獲得・確保は多様化し、IT企業や異業種からの流入が活発になっている」というようなことが書かれています。

ここで書かれているデジタルトランスフォーメーションとは、何かITを使って新しいことをしていく、ビジネスを進めていくことをDXと定義した場合、DXを推進するには、ビジネスとITの連携が必要不可欠になっていく。ここが内製化におけるポイントになってくるかと思います。

何かをしようとした時に、ITがついてこない。例えば自分たちが主導権を持っておらず、ITが何をしているかわからない場合、ITをドライバーにしてビジネスすることが非常に難しくなっている。それを妨ぐためにも、内製化を進めていく必要があると考えています。

また、多くのお客さまやパートナーさまからも同じような言葉を聞いています。IPAの『人材白書』は、アンケートに答えればダウンロードして読めます。自分たちの会社の中でどういう戦略を立てるかという時も1つの指針になると思うので、読んでもらうといいと思います。

内製化に苦労する原因は人材不足

この後、もう少しIPAの資料からいくつか特徴的なグラフを説明していきたいと思います。ユーザー企業が社内にITのスキルを溜めて内製化をしているかのアンケートを取ったところ、50パーセントは「内製化をしている」と答えているという現状があります。

そのため、意外と日本では内製化が進んでいるのではというところが、ここから見てとれました。しかし、やはりそんなことはなくて、ユーザー企業が自分たちで内製化を進めていくところに苦労しているのが、AWSの営業や、パートナーさまから聞いている中でもわかってきています。

では「なんでなんだろうか」となった時に、やはり内製化する人材の不足というところになります。実際「ユーザー企業のIT人材の質に対する不足感」というようなアンケートでは、95パーセント近い回答として「不足している」と書かれています。やはり実際に何かを進めていく時に、十分に対応できるエンジニアがいないと言われています。

ユーザー企業のIT人材の質に対する不足感は、調査では昔からずっと言われています。2018年、2019年からも、90パーセントを超えるかたちで「大幅に不足している」「やや不足している」という回答となっています。

アメリカ企業と日本企業の人材流動性の違い

「なぜこういう回答になるのか」も、日本の特徴的なところになってきます。実際、IT企業と呼ばれる企業に、72パーセントのエンジニアが在籍しているのが日本の状況です。そちらに72パーセントエンジニアがいる状況で、ユーザー企業には28パーセントのエンジニアが在籍している状況です。アメリカはこの比率が逆になっていて、65パーセントがユーザー企業にいる状況です。

この状況でどういうことが起きるかというと、アメリカで新しいデジタルトランスフォーメーションのビジネスを立ち上げるとなった時に人材募集をかけると、多くのエンジニアが応募をしてきます。

プロジェクトを2年、3年、5年と決めた時に、そのプロジェクトが終わったタイミングで、エンジニアは次の職場を探すような人材流動が、アメリカではうまくいっていると言われています。日本の場合どうでしょうか。少し考えてみると、人材流動性はやはりまだまだ日本では活発ではなく、1つの企業で長く勤めていくスタイルが一般的なかたちになります。

日本のかたちは非常にすばらしい一方で、内製化に問題が起きているのも事実になります。企業がITエンジニアを募集してもなかなかこないというところで、実際に始めようとした時に「では、システムインテグレーターさまにこの部分をお願いします」と、言葉を悪くすると丸投げしてしまう。

丸投げしてしまうと、どんどんどんどんガバナンスがなくなり、最終的にはシステムインテグレーターさまがよく知っていて、自分たちが知らないシステムが出来上がっている状態が正直数多くあるかと思います。

塩漬けにしないためのDevOps

そこをやはり「そうじゃないでよね」と、デジタルトランスフォーメーションという言葉とともに、内製化という言葉が今大きく出てきています。

DevOpsという言葉は非常によく聞くと思いますが、何かものを作ってサービスを開始した後、それを塩漬けにするのではなく、運用からのフィードバック、Opsからのフィードバックをもらって、またすぐに新しい機能を追加していく、変更していく。

またその運用が乗ってきて変更点があったら、またDevが動いていく。DevとOpsを密に連携させて、新しいものをどんどんどんどん作っていく。塩漬けにしていかないというのがDevOps。簡単に言うとそういうことかと思います。

そこにBiz、ビジネスの部分を加えて、BizDevOpsという言葉も出てきています。ビジネスの部分はいかにマネタイズをするか、いかに効率的にビジネスを運用していくかという部分になってきます。そのため、この部分はユーザー企業さまがオーナーシップを持って対応していくのが当たり前のように聞こえます。しかし現実問題、この部分でさえ、システムインテグレーターに外注してしまっているケースが起きています。

まずBiz、あと一部の最初のDevのイメージを作るところは、やはりユーザー企業がオーナーシップを取るべきではないかというような声も大きく上がってきているので、この部分をAWSでなんとか支援できないだろうかと考え、私のほうで活動を開始しました。

AWSが開始した内製化支援推進のための取り組み

実際、AWSだけでそれをやるのは難しいと思っています。やはり経験の豊富なパートナーさまと連携して、Bizの部分が得意なパートナーさま、またDevOpsが得意なパートナーさまと共に、今まで「すべて丸投げ」のような文化があったとしてもそうではなく、Bizの部分はユーザー企業さまが主導していくかたちを作っていければいいのではないかということを、いくつかのパートナーさまにお声掛けをしました。

また、実際にいくつかのパートナさまはすでにBizDevOpsのサポートをしていたり、内製化支援というメニューを持っていらっしゃったので、そのパートナーさまと共に、内製化支援推進AWSパートナーという取り組みを2021年3月に開始しました。

クラスメソッドさま含め10社の企業さまと一緒に、エンドユーザーさまに対して、AWSパートナーはどういう内製化の取り組みができるだろうかをディスカッションしたり、後で説明する、ANGEL道場というアイデアソン・ハッカソン形式のトレーニングを、ユーザー企業さまに一緒に提供したりなどの取り組みをしています。

クラスメソッドさまはすでに内製化支援サービスのランディングページもあります。非常によいサービスになっているので、一緒に連携していければと思っています。

内製化支援推進AWSパートナーの説明も、ブログに載せているので、ぜひ読んでもらえればと思います。

エンジニア育成のためのトレーニング

2017年から、私のほうでパートナーさま向けにさまざまなトレーニングを提供してきています。（スライドを指して）この一番上の「ものづくりトレーニング」が今回の内製化支援に通ずるトレーニングになっているので紹介します。

先ほどBizDevOpsという話をしましたが、この流れを3ヶ月で一気通貫して学ぶようなアイデアソン・ハッカソンのトレーニングになります。

初めの1ヶ月でBizの部分をアイデアソンみたいなかたちで（実施します）。Working BackwardsというAWSが持っている手法ですが、まずどういうことをしたいのかを、お客さまのサービスを起点に、「何月何日、アマゾンウェブサービスは、このようなサービスをリリースします。対象のお客さまはこれで」というかたちで、お客さま視点のプレスリリースを書いてみます。

そこに対してさまざまなディスカッションをして、イメージが固まった後に、実際にもの作りを2ヶ月間していく。その2ヶ月間のプロトタイプ作成などをAWSがサポートするかたちで、パートナーさまにやってきたものを、今エンドユーザーさまにパートナーさまと一緒に提供するような試みをしています。

このトレーニングに来るエンジニアは、あまり開発経験のないエンジニアです。クラスメソッドさまもトレーニングの生徒として前回参加されましたが、入社2年目以内のエンジニアが、自分たちでペルソナを作り、どういう人たちに向けてサービスを作るかというプレスリリースを書き、それに向けて実装していきました。

クラスメソッドさまはブログが非常に充実しています。このブログを読むだけではなく、読んだものからものを作って実践して、さらにそこに質問をして、Q＆Aを書いてという、ブログを中心にしてより学ぶような仕組みを、自らシステムとして作る『Loop I／O』というサービスを作り、実際にプロトタイプまでやっていった。CI／CDで作っていく、アジャイルで作っていく、新しいサービスを使っていくようなサポートを、この2ヶ月間AWSが実施しました。

6月から9月にかけて、クラスメソッドさまにもサポートいただきながら、ユーザー企業さまに対して「ANGEL道場」ということをやっています。

APN、ネクストジェネレーションエンジニアリーダーを育てるという取り組みです。ユーザー企業さまも1社5名参加して、その5名が毎週のスプリントを使い、自分たちで書いたプレスリリースに向かって今プロトタイプサービスを作っているような取り組みです。

AWSもサポートしていますし、先ほどの10社の内製化支援推進パートナーと共に、ユーザー企業のプロトタイプ作成であったり、内製化支援の文化作りをサポートしている取り組みになります。

こちらも今ブログで定期的に中間報告含めて発信しています。もし「この取り組み、興味あるよ」という方はブログを読んでもらって、どんなことをやっているか見てもらえればと思います。

内製化のポイントはビジネスとITの密な連携

まとめとしてはまず、「ビジネスとITを密に連携していくことが内製化のポイントである」という、BizDevOpsという考え方の説明をしました。

あとは内製化支援推進AWSパートナーということで、今後さまざまな情報を発信していきます。内製化という部分に興味がある方は、我々のブログや、クラスメソッドさまの発信に注目いただければと思います。

デジタルトランスフォーメーションという観点では、座学だけではなく、ものを作っていくトレーニングが非常に重要だと思います。何かをやってみるというところから始めるのが、やはり今までのエンジニアの育成とは大きく違ってきているかなと感じる部分になります。

私のほうからは以上です。