順番が前後して見えるかもしれませんが、今回は、「⁠そこそこエンジニアでもいいんじゃない？」というお話です。

これまで、入門者向け、オンプレミス環境を知っている技術者向け、つよつよエンジニアを目指したい人向けの提案をしてきました。「⁠つよつよエンジニア」になれることは理想ですが、一方で、幅広く技術を根幹から理解する必要があります。僕は、全員がそこを目指すことは、現実的ではないし、必要もないと考えています。

AWSは、数多くのサービスを提供しており、様々な組み合わせ方があります。同じように、AWSに関わるエンジニアだって、全員がつよつよである必要はないのです。「⁠そこそこ」AWSがわかって、「⁠そこそこ」良いインフラが構築できる人も、需要はたくさんあります。

今回は、AWSの学び方の総論として、「⁠そこそこエンジニアを目指すには」というお話をしていきます。

つよつよエンジニアは遠き道のり……

前回、「⁠つよつよエンジニアになるためには」についてお話するなかで、「⁠AWSつよつよエンジニア」の定義として、「⁠AWSなどを使って『適切な』システムを設計できる人」であると書きました。

これはあくまで僕の定義ですが、AWSに関わるあらゆる知識を身につけ、さまざまなプロジェクトに対して、「⁠最も適切である」システムを設計できることが、いかに難しいことであるかは、現場の皆さんならよくご存じのことでしょう。このように書いている僕にしても、未知の領域（ドメイン）や規模に関するインフラは不勉強なことも多いですし、この世に存在するあらゆるクラウドやオンプレについての知識が完璧であるとは言えません。クラウドベンダーは、3大クラウド（AWS、Microsoft Azure、Google Cloud）以外にも数多くありますしね！しかし、そのような「完璧にあらゆる知識を持ち、使いこなせること」が万民にとって必要なのでしょうか。

たとえば、極論を言えば、「⁠クラウドを使ってはいけない制限付きプロジェクト」において、クラウドの知識を増やしても活かせる機会は少ないですし、顧客が「絶対にAmazon ECS[1]は使いたくない。俺はコンテナアレルギーなんだ」と言い出したら、従う他ありません。それが自社にとっての大口顧客であれば、社内でコンテナを使う機運は上がらないでしょう。

ここまで極端な話でなくとも、業界や、プロジェクトの規模によって、事情は様々です。インターネット上では、どうしても声の大きい人の意見が主流のように見えてしまいますが、誰かにとってのベストが、自分にとってのベストであるとは限りません。

たとえば、偏差値70の大学と偏差値50の大学とでは、勉強の内容が違います。出題される問題も違えば、記述なのか、マークなのか、論文なのか、そうしたスタイルの違いもあります。偏差値70の大学用に作られた参考書をやれば、偏差値50の大学への近道かというとそうでもありません。出題されない内容も多いでしょうし、そもそも、歯が立たなくて、理解できなければ、桜が咲くも咲かないもありません。大は小を兼ねるとは限らないのです。それよりも、志望大学に特化した勉強をする方が、合格だけを考えるのならば近道でしょう。

同じように、プロジェクトのドメインや、規模、性質によって、必要なセットは違います。プロジェクトによっては、物理的・法的・金銭的・文化的制限もあります。大きなプロジェクトの輝かしいチームの実績を、そのまま真似しても、自分のプロジェクトで生きないこともあるのです。

では、どのように「そこそこエンジニア」を目指せば良いでしょうか。

まずは自分のことを自覚する

僕は、このような話の時に「彼を知り己を知れば百戦殆からず」という孫子の言葉を引き合いに出すことにしています。つまり、相手と自分を知ることが大事です。ここでいう相手とは、AWSや、インフラの知識でしょうし、自分とは自社の能力やプロジェクト自体です。

AWSについての話はこれまでしてきていますから、「⁠自分」の探り方を考えてみましょう。

規模や資金など外郭について考える

まずは、自分が関わるサービスの規模について考えてみましょう。

サービスの規模は、ジャンルが違っても、ユーザー数、アクセス量（アクセス頻度とやりとりされるデータ量⁠）⁠、保存するデータ量などから推し量ることができますが、キラキラと語られる「AWSを使った実例」と、自分のプロジェクトとは、どのくらい似ているでしょうか。

AWSは、ちょっとしたことから、大きな規模のインフラまで、使い方のバリエーションが豊かですし、インフラに限らないサービスもあります。プライベートで使うこともあるくらいです。

この連載の第一回で、「⁠AWSとは、ソフトクリームにおけるコーンのようなものだ」というお話をしましたが、ソフトクリームがちょっぴりなのに、コーンばかり大きくては、バランスが悪いですし、逆もまたしかりです。自分のプロジェクトは、どのくらいの規模でしょうか。大きいでしょうか。小さいでしょうか。

また、図解即戦力AWSでも触れていますが、AWSを始めたとしたパブリックのクラウドコンピューティングサービスを使うことは、オンプレミス環境よりもトータルでは高くつくことが多いです。その代わり、インフラを維持する一部の責任をAWSが担ったり、大規模なシステムのスケールを管理しやすかったり、自社のインフラエンジニアの負担が減ったりするなどのメリットがあるのですが、資金的にそれが許される環境なのか。それが生かせる規模なのか。そこを考えねばなりません。

つまり、「⁠サービスの規模」を知ることは「AWSを使って実現できる範囲（ゴール⁠）⁠」を知ることですし、「⁠資金」を考えることは、「⁠AWSを使える範囲（スタート⁠）⁠」を考えることでもあります。

AWSは、構成によって、高くもなれば、安くもなります。「⁠AWS Lambdaを使ってちょっとだけ使いたい」ケースもあれば、「⁠インフラ丸ごと置き換えたい」ケースもあるでしょう。漠然と「AWSを導入したい」ではなく、具体的に「プロジェクトのこの部分にAWSを導入したい」くらいの範囲が見えているべきです。

発想を変えて、「⁠どうしてもAWSを使ってみたいから、どこか自分のプロジェクトで置き換えに向いたところはないか」と探るのも、悪くはありません。大事なのは、具体性です。

サービスの規模も資金も、どちらも物理的な制限と大きな関わりがあります。つまり、プロジェクトの外郭と言える部分です。こうした「自分のプロジェクト」の外郭をしっかりと捉えることで、「⁠自分とAWSとの距離」を図りやすくなります。

ドメインと文化について考える

プロジェクトの外郭について考えたら、次は、その文化についても考えると良いでしょう。これも図解即戦力AWSに書いていますが、AWSはグローバルなサービスなので、日本国内だけでなく、海外にサーバーを置くことも容易です。これは大変便利です。料金を見比べて海外のリージョンを使うこともできます。日本でまだ導入されていないサービスを使うこともできるのです。

しかし、それが「許されるのかどうか」はまた別の話です。

たとえば、公共系など、プロジェクトによっては、海外にデータを置くことが許されないこともありますし、そもそも、パブリッククラウドがNGのケースもあります。

AWSはデータセンターに入れません。それを許されないこともあるでしょう。

逆に、政治的な理由で推奨されて、「⁠AWSありき」のケースもありますし、顧客が「どうしてもAWSを使いたい」と言うかもしれません。

こうなってくると、プロジェクトにとって善し悪しではなく、外的な要因でAWSの導入が決まってしまいます。我々が嫌かどうかは関係ありません。

「だから考えても無駄」と思考停止するのは早計です。そうではなく、これらを材料として、「⁠自分とAWSはいつ頃どのくらい関わりそうか」を考えるべきなのです。

パブリッククラウドは、今後暫くは、なくなるということはありません。シェアは年々拡大しており、どこかのタイミングで使わざるを得ないでしょう。今使っている人は、より幅の広い使い方を求められるようになりますし、深い知識も必要になります。我々とパブリッククラウドとの距離が近くなることだけは間違いないのです。

規模と資金を知ることが、外郭を知ることであるならば、文化を知ることは、変化の加速度を測ることです。こうした加速度を知っておくことで「自分やチームが急いで学習すべきか、そうでもないのか」を図ることができます。

「自分が」何をすべきか考える

プロジェクトの外郭と加速度が知れたところで、「⁠自分が」何をすべきか考えてみましょう。

あなたは、インフラを設計する人でしょうか、それとも、実際に手を動かして構築する人でしょうか。導入コンサルタントの人も居れば、プロジェクトの旗振り役で、顧客に説明する人も居るでしょう。まだまだ新人さんで、議事録を担当するのに、「⁠ちょっと用語を知りたいだけなんだよね」という方もいらっしゃるかもしれないですね。

「あなた」は、どんな知識を身につけるべきでしょうか。設計する人であれば、実際の構築方法よりも、設計の実例を多く学び、サービスの特性についてよく知ることが大事でしょう。一方、構築する人であれば、構築方法をよく学び、セキュリティについても知っておく必要があります。設計する人が万が一間違った場合でも、構築者がセキュリティについて理解があれば、大きな事故が防げますからね。導入を支援したり、顧客に説明したりする人は、見積もりや、メリットデメリットについて詳しく知っている必要があります。

つまり、「⁠あなた」が何者であるかによって、「⁠身につけるべきこと」は違うのです。設計を担当する人が、いくら構築方法に詳しくても、肝心の設計手法がお粗末では仕事になりません。コンサルタントも同じです。

とかく、AWSの学習において、ハンズオンで実際に手を動かすことが賛美されがちですが、AWSは構築が簡単なので、GUIを使ったハンズオンで得られる知識は少ないです。数学で言えば、九九を習ったくらいのレベルです。それよりももっと知るべきことがあります。また、構築者であれば、GUIでの画面でポチポチやるよりも、CLIやIaCの仕組みで構築を自動化することや、ネットワーク・サーバーの知識が求められるでしょうから、もっと先の知識が必要です。

そこそこエンジニアを目指すには

さて、ここまでお話してきたら、なんとなく皆さんも想像が付くのではないかと思うのですが、「⁠AWSそこそこエンジニア」とは、「⁠自分のプロジェクトや、自分の職務において、AWSを正しく使える人」です。つよつよエンジニアほど、多岐にわたった知識はなくとも、自分周辺のことはきちんとできる、そうしたエンジニアも、世の中には少ないものです。あなたがそこそこエンジニアになれれば、自分のプロジェクトで活躍できるのはもちろんのこと、ドメインや職務が変わっても、この経験は生きてくるでしょう。

「彼を知り己を知れば百戦殆からず」百戦対応できるかどうかはわかりませんが、とりあえず、彼と己を知ることは、大きな前進につながります。

次回は、実際の構築例を通して、「⁠自分とAWSとの関わり方」についてお話します。