こんにちは。LayerX AI・LLM事業部 SREの@shinyorke（しんよーく）と申します。
私はよく書籍を読むエンジニア*1なのですが、SREやクラウドなエンジニアにはクラウドストラテジーという書籍をオススメしています。
名前の通り「クラウドを使う組織・人にとっての戦略の話」メインの書籍ですが、弊社LayerXのようにSaaSそして生成AIプロダクトを提供する企業のエンジニアにとっても非常に学びがたくさんあります。
特にAI・LLM事業部では主力プロダクトである「Ai Workforce」を大企業のお客様に導入していただいている関係上、
- エンタープライズ企業向けのSIおよびOpsが要求される。
- お客様のルールや慣習に合わせて導入する必要がある。
- お客様のシステム部門やCCoE組織に対してご理解とご協力を頂く必要がある。
以上のような背景があり、クラウドストラテジーの考え方・観点を重要視しています。
本記事では、
- クラウドストラテジーの紹介
- LayerX AI・LLM事業部ではどの様にクラウドストラテジーを活かしているか？
以上の内容をご紹介できればと思います。
なお、本ブログの2/3は私の解説*2で、残る1/3は我々AI・LLM事業部ではどうしているか？の話となります。
TL;DR
クラウドストラテジーは「技術」「ビジネス」「組織」側面で「クラウドとは？」を見直すことができるとても良い概念です。
クラウドストラテジーとは
クラウドストラテジーとは、クラウドの導入・利用において押さえておくべき重要なポイントを体系化した考え方です。AWSやAzure、Google Cloudといった特定のプロバイダーに依存せず、エンタープライズ企業や大規模プロジェクトで必要となる戦略的な視点を提供します。
クラウドストラテジーの概要
クラウドストラテジーは「御社もTech Companyとしてクラウド導入でいい感じにしましょう！」...という煽りプレゼンテーションな本ではなく、「技術」「ビジネス」「組織」の三面で変革を促すためのガイドです。
色々な解釈があると思いますが、私は以下のようなピラミッドでクラウドストラテジーを理解しています。
graph TD
A[クラウドストラテジー] --> B[技術的側面]
A --> C[ビジネス側面]
A --> D[組織的側面]
B --> B1[クラウドネイティブ]
B --> B2[マルチクラウド]
B --> B3[ハイブリッドクラウド]
C --> C1[ビジネス活動のデジタル化]
C --> C2[変更容易性]
C --> C3[予実管理]
D --> D1[CoEによる組織化]
D --> D2[リスキリング]
D --> D3[内製化vsアウトソーシング]
上記のピラミッドのみだとわかりにくいと思いますので少しだけ解説します。
技術的側面
クラウド利用のためにアーキテクチャを工夫し、クラウドの使い方を探る。
ざっくりいうと「オンプレミスやちょっと前のシステム構築・運用から一歩前に出てクラウドらしいことをしましょう」ということです。
最もわかりやすいワード・概念としては「クラウドネイティブ（Cloud Native）」があります。
- アプリケーションをContainer化する
- Container化に合わせ、スケール可能な環境でホストする（サーバレス系のサービス、K8sなど）
- インフラ構成のコード化（Infrastructure as Code、いわゆるIaC）
- テストからデプロイまで一気通貫に自動化（DevOps、CI/CD）
読者の方には特に説明不要かと思います、開発のためにやっている「当たり前」の実装（DX Criteriaの項目の殆どが対象）がそのまま対象となります。
また、「どうやってクラウドを使うか」の観点では「マルチクラウド」「ハイブリッドクラウド」の選択なども入ってきます。
| クラウド形態 | 説明 | Pros（利点） | Cons（欠点） |
|---|---|---|---|
| 一つのクラウドのみ使う | 1つのクラウドベンダー（例：AWS、Azure、Google Cloud）に集約して利用する形態 | - 学習・管理コストが低い - セキュリティポリシー等の一貫性が保ちやすい - サービス間連携がスムーズ |
- ベンダーロックインしてしまうリスク - アーキテクチャの陳腐化、他クラウドの強みを活かせない - クラウドベンダー障害時に積む可能性*3 |
| マルチクラウド | 複数のクラウドベンダーを用途に応じて使い分ける形態 | - 各クラウドの得意領域を活用できる - ベンダー依存を回避できる - コンプライアンス・地理要件に柔軟対応*4 |
- 管理・運用・アーキテクチャが複雑化し、学習コストが高い - スキルやチーム体制が分散しやすい - セキュリティ・統制の難易度が高い |
| ハイブリッドクラウド | パブリッククラウドとオンプレミスもしくはプライベートクラウドのどれか2つ（3つ）を統合利用する形態 | - 既存のオンプレ資産を有効活用できる - データ主権やレイテンシ要件に柔軟対応 - 災害対策やBCPに強い*5 |
- ネットワークやセキュリティ設計が高度になる - 初期投資や構成が複雑 - 学習コストが高いかつ、特定の環境・企業でしか使えないスキルになる可能性 |
これらのあり方についてもクラウドストラテジーの中で色々と解説されています。
ビジネス側面
クラウドによる「ビジネスのデジタル化」は避けられない。欲しい時に欲しい物を、いらない時に手放す事が大事。
クラウドの良さは雑に言うと、
といった「変更容易性」にあります（ただしこれをシームレスに実現するには「クラウドネイティブ」である必要がある）。
これは「一度導入したら減価償却するまで使わないといけない」オンプレミスとは違う観点かつ重要なものです。
また、お金の扱いについても、
- オンプレミスやプライベートクラウドは自前でサーバーやデータセンターを用意し運用するので「資産」として扱う（減価償却があるのはそのため）
- パブリッククラウドは利用料を支払うスタイルのため利用料は「費用」となる
といったキャッシュフローの違いがあるため、「予実管理」が重要となってきます。
なお、クラウドストラテジーにおいてビジネス側面の文脈について面白い一文が記載されています。
スピードの経済にとってクラウドは自然である
※第一部「一次微分の中のクラウド思考」より抜粋
個人的にはこの本で好きな章の一つでもあります、気になる方は読んでみるといいかもしれません。
組織的側面
クラウドを戦略的に、適切に利用してValueを出すためには「組織戦略」「成長戦略」が重要。
一言で言うと「今までとはやり方が違うよ」という観点で組織も考えないといけないですし、成長戦略（もっと踏み込んで言うと「再教育」）も必要です。
- オンプレ（もしくはプライベートクラウド）から一足飛びに移行するためには「クラウドネイティブ」な思想と設計、実装が必要
- 欲しい時にいつでも使える（いつでも手放せる）、キャッシュフローが変わる
クラウド以前のオンプレミスから一足飛びにクラウド化と上記のような「昨日までの当たり前が今日から捨てないといけない」という事が発生します。
これらを組織側面でどうするか？という話もクラウドストラテジーで触れられています。
- CCoE（Cloud Center of Excellence）と呼ばれる組織立ち上げによるクラウド化の推進。
- 既存人材をクラウド人材にするためのリスキリング。資格取得、ハンズオン、コミュニティ*8参加etc...
- 外部からの人材登用。採用強化は勿論ですが、ベンダーをクラウド特化の強い会社・人材に変えるなども有用な施策。
CCoEは「チームトポロジー」で言うところの「イネーブリングチーム」に該当するチームで、
- クラウドやDevOpsといった専門ドメインの強者を集めたチーム
- プロジェクトごとに派遣 or 薄く広く関与し、アーキテクチャのレビューやガバナンスを聞かせる
- 資格取得の推進、ハンズオンの開催etc...を通じたクラウド人材の育成
以上を担うようなチームとなっています。
AI・LLM事業部における「クラウドストラテジー」の実践
私の事業部というより「SREチーム担当」の私は「クラウドストラテジー」を以下の課題を解決するため実践しています。
- エンタープライズ企業向けのSIおよびOpsが要求される。
- お客様のルールや慣習に合わせて導入する必要がある。
- お客様のシステム部門やCCoE組織に対してご理解とご協力を頂く必要がある。
より具体的には以下の通りです。
- AI・LLM事業部のお客様、より具体的には「Ai Workforce」のユーザーとなっているお客様とのコミュニケーションで大きく活用
- Ai Workforceを利用していただいている部門の裏側にいるシステム部門の方や関係者との調整を行う前に論点となりえるところをクラウドストラテジーで予習
- 「LayerX AI・LLM事業部のSRE」の言葉ではなく、「お客様がAi Workforceを気持ちよく利用いただく為に伴走するソリューションアーキテクト」としてコミュニケーションを取るための言葉・概念をクラウドストラテジーから拝借
といった形で利用しています。
なおAI・LLM事業部のエンジニアチームで「クラウドストラテジーやろうぜ！」みたいな使い方はしていません。
どちらかと言えば「AI・LLM事業部のエンジニアチーム」と「お客様のシステム部門担当者さま」の間を埋めるコミュニケーションの調味料として、クラウドストラテジーを活用しています。
色々な都合でここに詳細を書けないのが残念ですが、気になる方はOpen Doorや6/16開催のエンジニア向けイベントで会話いただけると幸いです。
いずれも私と直接お話できるので、ご興味ある方はぜひどうぞ。
結び
本記事では「クラウドストラテジー」の紹介および、「AI・LLM事業部ではお客様とのコミュニケーションの一環としてクラウドストラテジーを活用している」お話を紹介しました。
個人的には事業会社、特にAI・LLM事業部のようなチームでは「SREの役割はサイト信頼性エンジニアリングに加えて顧客折衝などの『コミュニケーション』を通じた『事業貢献』が大事」という持論があります（少なくともインフラエンジニアだけできれば良い感じではない）。
本記事ではその雰囲気をお伝えできた気がします。
最後に宣伝ですが、【SREキャリア最前線】AIと共に進化する！SREの新たな役割とキャリア設計というテーマで6/20（金）のFLEXY Meetupに登場するのでお時間ある方はぜひいらしてください、本ブログの質問などもお答え可能です。
また、Xの@LayerX_techアカウントではLayerXの様々な取り組みを発信していますので、是非こちらもフォローしてください。
最後までお読みいただきありがとうございました。
*2:読者のためのお勉強コンテンツぐらいのお気持ちで執筆しています。
*3:マルチリージョン構成などで切り抜けることはできますがDNSなどのグローバル・サービスがコケると終わる危険性があります
*4:単一クラウドでもできますが、リージョン展開などの地理的要件もあるのでマルチクラウドの方が有利
*5:3つの選択肢で最も強いのは事実ですが、オンプレやプライベートクラウドの退避先の戦略・設計を間違うと積む可能性があります
*6:最近は各クラウドベンダー共に特定リージョンのリソース枯渇等があるのでこの条件が加わります
*7:細かいことを言うと利用確約など「前払い」な契約だと手放すことができてもお金がかかることがあります
*8:余談ですが、パブリッククラウドの事業者がすべからくエンタープライズ向けコミュニティを運営しているのはCCoE運営者同士のコミュニティである側面もあったりします。
