はじめに
突然ですが、この記事を開いたエンジニアの皆さんへ質問です
「あなたは現在クラウドを使っていますか？」
今やこの問いに対して「No」と答える方は少数派だと思います。
特にQiitaを読まれているエンジニアの方々は、ほぼ全員「Yes」と答えると思います。
それではクラウドを使っているあなたへ、さらに質問です
「あなたはそのクラウドの真の価値を、十分に発揮した上で使っていると言えますか？」
この問いに対して「Yes!!」と自信満々に答えられる方はかなり少ないと思います。
私も自信満々には答えられないです。
そんなあなたにこそ、この記事で紹介する本 「クラウドストラテジー: クラウド移行を成功に導く意思決定に基づくアプローチ」 を読んでいただきたいです。
（下記はアフィリエイトリンクではありません）
タイトルから推測できるように、技術的な話が少なめでビジネス・組織の観点からクラウドを考える内容になっています。
全体的に抽象的で難しいのですが、例えも多く書かれているので読みやすいです。
時折辛辣なブラックジョークが出てくるので、読みながら吹き出しそうになります笑
また、非常に本質的な内容になっているので、まさに「全クラウド利用者のための金言集」といった感じの本です。
クラウドをそれなりに使ってきた方であれば、必ずブッ刺さる章、もしくは文章があるはずです。
本記事では、そんな本書の中から独断と偏見で選りすぐった金言をいくつかピックアップして紹介していきたいと思います。
※この記事はPRなどではなく完全に個人的な感想を書いただけの記事です。
本書で最も重要なメッセージ
まず最初に、本書でしきりに取り上げられる重要なメッセージについて書きます
それは、「クラウドを使う上では、今までの考え方を丸っと改めないと十分に活用することはできない」 ということです
エンジニアリングの観点だけではなく、予算管理の方針や組織のあり方、経営方針などあらゆる観点で考え方を改める必要がある 、そのように本書では強調されています。
クラウドコンピューティングは過去のテクノロジーの変化とは大きく異なっています。過去の想定をひっくり返す根本的なライフスタイルの変化が必要なのです。
（冒頭の「日本の読者へ」より引用）
「じゃあそのためには、どんな考え方でクラウドと向き合うべきか？」
そんな疑問に対するアドバイスが、この本にはふんだんに書かれています。
著者のGregor Hohpeさんは、国家レベルでのクラウド戦略策定に関わるなどのご経歴をお持ちの方です。
Gregorさんは現在、AWSでエンタープライズ・ストラテジストとして勤務されており、企業のIT戦略の策定を支援されています。
Gregorさんの豊富な経験をもとにしたアドバイスが非常に多く書かれており、時折辛辣でありながらも説得力がある内容になっています。
金言1つ目：「サーバーは、エネルギーを大量に消費し、三年で陳腐化する高価なハードウェアだ」
これは12章「サーバーを欲しがる人はいない」に登場する文章です。
12章で 「クラウド上でアプリケーションを動かすときにインフラから考え始めてしまってはいけない」 ということを訴求している章です。
オンプレを使ってきた人がクラウドを使うと、まず最初にサーバーとストレージを調達しようとしてしまう。しかし、その考え方はクラウドを十分に活用できないのでやめるべきだと著者は伝えています。
クラウドのメリットはアプリケーションのデプロイ完了までの時間を圧倒的に短縮できることである。クラウドを使えばサーバーが無くてもアプリケーションをデプロイできるのに、なぜわざわざクラウドでもサーバーを用意するのか？
サーバーをわざわざ用意してまで実現したいことは何なのか？
本当にクラウド上でサーバーを用意する必要があるのかどうかをちゃんと考えて欲しい、そんな筆者の気持ちから生まれたブラックジョークです。
サーバーとは一体何なのかを考えてみよう。誤解を恐れずにあえて表現すると、私は「サーバーとは、エネルギーを大量に消費し、三年で時代遅れになる高価なハードウェアである」と定義している。
（P102より引用）
ちなみにこれは私が一番お気に入りの金言で、思わずX(Twitter)にも投稿しました笑
金言2つ目：「サーバーの移行は十分ではない。従業員の移行も必要だ。」
これは8章「従業員のマイグレーションにおける四つのR」のサブタイトルになっている文章です。
この記事を読んでいる方の中には、クラウド移行における「XXつのR」をご存知の方もいると思います。
クラウドへの移行戦略は複数考えられますが、それら全てが「Re~~~」と表現できることから「XXつのR」と言われることがあります。
AWSを例に取り上げると、移行戦略が「7つのR」と定義されています。
定義している組織によって微妙な差はありますが、中身は概ね似た内容になっています。
この移行戦略はあくまでもエンジニアリングの観点で書かれているものですが、本書では 「従業員の移行戦略」 も考えるべきだと訴求しています。
具体的に本書の中では、4つの移行戦略が挙げられています。
- 現状維持（Retain）
- 再教育（Re-Skill）
- 配置転換（Replace）
- 退職（Retire）
それぞれの詳しい説明は割愛しますが、これら4つの重要な共通点は、すでに社内にいる従業員に対する戦略 であるという点だと思います。
実際にこの章の中で、「採用に目を向ける前に、まずはすでにいる従業員を活かしきれているかどうかを考え直すべき」 という旨の主張が書かれています
あなたの人材がシステムによって妨げられていないかどうか、注意深く見てみる必要がある。
（P70）
クラウドに精通し、「DevOps」を取り入れ、ビジネス価値を見失わない人材だけを採用しているように見える「デジタル」型の競合他社に比べて、人材を再教育しなければならないのは大きな投資であり、負担だと感じる組織もあるだろう。しかし、これは典型的な「隣の芝は青く見える」誤りである。
（P71）
いわゆる「つよつよエンジニア」を採用することに躍起になるのではなく、従業員のポテンシャルを発揮できることを目指す。そのために障壁となっているシステムを改善することをまずは考えるべき、そのように主張しています。
加えて、章の最後では従業員のロールを改名することに対して批判的な主張が書かれています。
改名したとしても、既存のシステム（組織構造やインセンティブ制度）がそのままでは意味がないと訴えています。
時間とお金を使う以外にほとんど何も達成できない。組織は、既存の構造をそのままに新しいラベルに貼りかえるだけで変身するわけではない。
（P74）
クラウドを使いこなしたいのであれば、まずは組織構造に目を向けて欲しい。そんな筆者の思いがこもった金言です。
金言3つ目：「ロックインを避けてロックアップされるな」
これは21章のタイトルになっている金言です。
エンタープライズな会社で特によく聞く話ですが、「ロックイン」というワードに非常に敏感で、どうにかロックインされないように避けようとする傾向があると思います。
しかし、正しい判断をしないとロックインを避けるあまり「ロックアップ（身動きが取れなくなる）」される危険性があると著者は主張しています。
ここで大事なのは、ロックインが正しいか誤っているかではなく、ロックインされる程度をコントロールすべき だと主張していることです。
確かにロックインされるとアーキテクチャ上の選択肢が狭まってしまうが、ロックインを全力で避けると複雑性やコストがかさんでしまう。結果として総コストが大きくなってしまう、なんてことが起こりうるので気を付けるべきと主張しています。
ロックインは正しいか間違っているかを白黒つけられるものではない。そしてロックインを減らすのは確かに望ましいことだが、コストもかかるのである。
（P197）
私たちのコンピューターのほとんどはバイナリ（0 or 1、二者択一）で動作しているが、アーキテクチャはそうではないのである。
（P202）
本書の中では、ロックインされることによって受けることができるメリットもあるので、メリデメをアーキテクトの観点で十分に考えるべきと主張しています。
そして、ロックインの程度と複雑性やコストの高さがちょうどいい塩梅な場所を見つけるべきと述べています。
私がこの章を読んだとき、ここで述べられていることはDR戦略を考えるときと似ている考え方だと感じました。
大規模障害の時でも絶対に止まらないシステムができればいいですが、実際に作ろうとすると膨大な労力とコストがかかります。
なので、実際にDR戦略を考える時にはビジネス上許容できるラインを考えた上で、どのDR戦略を採用するかを決定していきます。
ロックインについて考える時も同じで、極端にロックインを怖がるのではなくメリデメを十分理解した上でアーキテクチャを決定するべき、という筆者の気持ちがこもっている金言です。
まとめ
個人的に特にブッ刺さった金言を紹介しましたが、ここに書けたのはほんの一部です。
クラウド移行を考える時のより具体的な考え方や、マルチクラウド戦略における重要な考え方など、本書では更に濃密なことが書かれています。
この記事を読んで少しでも興味を持っていただけたら、ぜひ読んでいただきたいです。
そして読んだ感想を一緒に話し合えたら嬉しいです。
ぜひ読んだら、感想をX(旧Twitter)でシェアしてください！
参考
Gregorさんは2022年のAWS Dev Dayでも登壇されており、ここではアーキテクトとして働く上で重要な考え方について話されています。
こちらも非常に示唆に富んだ内容となっていますので、クラウドアーキテクトとして働いている方、クラウドアーキテクトを目指されている方はぜひ一度ご覧になってください。