はじめに
こんにちわ、AWS事業部の神保です。
今回、初めて AWS Summit Japan 2024（6/20～6/21） に参加しました。
本記事は、6/21（金）に開催されたセッションである、「なぜ、AWS 活用のメリットを実感できないのか？〜内製化・運用改善の考え方〜」のレポートとなります。
セッション概要
AWS クラウドが謳う「イノベーション」と「スケーラビリティ/アジリティ」の魅⼒。
しかし、これらの恩恵をあまり享受できていないと感じているエンタープライズ企業の⽅もいらっしゃるのではないでしょうか？
本セッションでは、BeeX における事例や実際の取り組み例を踏まえて AWS クラウドのメリットを最⼤化するためのポイントを整理していきます。このセッションに参加頂く事で、継続的なアプリケーション開発/運⽤改善に必要な考え⽅、内製化に向けたパートナ活⽤のポイントを学習することができます。
スピーカー
浅野 佑貴 氏
株式会社ＢｅｅＸ
事業開発室
セッションレポート
サマリ
以下のアジェンダに沿いながら、運用面から AWS のメリットを十分に享受できていない背景を深堀りし、運用の内製化を考える上でのアプローチを説明するという内容でした。
・改めて考えるメリットを実感できない理由
・内製化に向けて考えること
・内製化を成功させる3つのポイント / BeeX による支援アプローチ
ビジネスの変化、AWS のアップデートに運用の実態が追い付いていないという実態に対し、
パートナーの力をうまく使いながら自社での内製化を進めることで、
早いサイクルでの開発要求の実現とイノベーションを行うことを提唱するセッションでした。
（なお、本セッションのスライドは、Summit 公式サイトの資料一覧よりダウンロードすることが可能です。ご興味あればぜひ。）
1. 改めて考えるメリットを実感できない理由
まず、AWS を利用する事業会社がなぜ AWS を利用したいのかに焦点を当てるところからセッションがスタートしました。
当然モチベーションはユーザーにより様々ですが、主として実現したいことは以下2点と述べています。
・スケーラビリティ/アジリティ （変化への追随）
・イノベーション（最新技術の取り込み）
ただし当然、実現のために、時間 / リソース / スキル といったハードルが立ちはだかります。
次に、AWS への移行によって、当初当然削減できると想定していた、
開発＋保守＋その後の追加要件開発 といった負荷やコストが、
想定外の作業や、運用を十分に考慮していなかったことによる不測の事態への対応などによって計画通りに進まないということが見受けられるとの指摘がありました。
そこには AWS のアップデートが想像以上に速く多いため、自社に必要なアップデートが何か見極められず、また、手段であるはずのそれら技術の追随が目的となってしまい当初の目的を忘れられるケースもあるとのこと。
このあたりは、私も以前、情報システム部門に勤めていた時に同様の経験（技術定例などで、とりあえず新技術を発表するだけになっていたなど）があり、まさに共感するところでした。
その後、アップデートの速度に追従できる体制を持つことや、AWS 活用に必要なスキルの考え方が提唱されました。
特に、個人の素養や努力に依存しない体制の大切さ、CCoE 等による組織的なバックアップや、専門家の活用による、面での支援の必要性が強調されました。
第一章のまとめとして、以下の考え方が提示されました。
・ビジネスの変化に伴いシステムも変化する。その継続的な変更や改修のコストやプロセスを確保していない実態。
→ 定常的な運用に対して必要なアップデートを取り込んでいくこと、またそこにコストをかけるという考えを持つことが大切。
・どのような課題を解決するためのアップデートかを考えられていない実態。
→ 運用課題やユースケースを考えることが大切。
2. 内製化にむけて考えること
次の章である内製化では、まず日本とアメリカにおける内製化の考え方の違いがデータとして提示されました。
DX白書のデータによると、非IT企業におけるエンジニアの在籍比率が、アメリカと比較し日本ははるかに少ないということでした。（アメリカ：6~7割 対し日本：2~3割）
確かに、文化や考え方の違いとして、アメリカでは、DIYで自分でやるという考え方が一般的であるという話を聞いたことがあります。
また、前職でも社内エンジニアがサードパーティのインフラやアプリの仕様を深く理解しており、運用を含めて自分なりの主張や考えをはっきり持っていたことことを思い出しました。
社内にエンジニアの少ない日本としては、なかなか内製化までの道のりは険しそうな印象を受けました。
次に、内製化においては、すべてを自社リソースで対応するという一足飛びの発想をする必要はなく、
対象のシステムの領域、どれほど失敗時のリスクを許容できるのかといった観点で内製化する領域（基幹システム、社内システム、PoC等）を分けることで、適切なエリアに効率的に支援を当てるという考え方が提唱されました。
確かに、理想とする状態までに徐々に経験値を積んでいく必要がある以上、リスクやインパクトを考えた上で計画的に内製化を行うということは非常に理にかなっていると感じました。
そして、この章のまとめとして、以下の考え方が提示されました。
・どこまで自社で内製化を行うのかを見極める
・不足する役割やスキルをパートナー活用する
・内製化レベルは段階的に成熟させる
3. 内製化を成功させる3つのポイント / BeeX による支援
そして、最後の章では、内製化を成功させる3つのポイントと、そのための BeeX による支援メニューの紹介が行われました。
まずポイントとしては先の章と関連し以下3点が挙げられました。
・改善のためのリソース（チーム）の確保
・パートナーとの協業（不足する役割やスキルの補強）
・内製化のレベルを段階的に成熟させる
特に、チームが機能するためには会社のカルチャーや仕組みによる支援が大切であることの示唆がありました。
確かに、CCoE 支援の文脈においては、クラウド活用は全社の変化に関わる取り組みであり、カルチャーや組織全体での推進が必要とよく言われるところであるため、説得力のある内容に感じました。
最後に、BeeX の支援メニューとして以下が紹介されました。
・継続的改善サービス with AWS Well-Architected
・FinOps 実践支援サービス
・内製化支援コンサルティング
本記事では詳細は紹介できませんが、いずれも顧客側での運用を通して結果を出すことを伴走して支援する、ということに価値を置いたサービスであり、必要とする顧客も多いのではないかという印象を受けました。
おわりに
以上、「なぜ、AWS 活用のメリットを実感できないのか？〜内製化・運用改善の考え方〜」のセッションレポートでした。
AWS活用につまづく理由や内製化に向けた考え方やアプローチ、支援内容が構造的に整理されており、とても理解の進みやすいセッションでした。
個人的に感じるところは、このセッションの内容も含めて、
AWS Summit のパートナーのセッションやブースでは、運用に焦点を当てた内容も一定数見受けられ、またそれを取り組みの柱と置いているベンダーも一定数いることから、
今後さらにその動きは加速するのではないかという印象を受けました。
当社でも直近、マネージドサービスをはじめとして、運用や伴走支援に力を入れているところではありますが、 顧客側での AWS の活用が進み、AWS 側も日進月歩で進化しているため、顧客側で最適な運用の形をとるための総合的な支援やパートナーの活用が求められていると感じました。
以上、AWS 事業本部の神保がお届けしました。
3
