はじめに

G-gen の CTO の杉村です。今回はエンジニアの成長の方法について、私なりの考え方を書いてみたいと思います。「できるエンジニア」と銘打って文章を書くのは少しおこがましいかもしれませんが、自分自身への戒めの意味も込めていますのでご容赦いただければと思います。この記事は G-gen のエンジニアや、将来 G-gen に入ってきてくれるであろう方に読んでいただくことを意識して書いたため、少し目を引くようなタイトルにしてみました。

2023 年現在の日本では「2025 年の崖」やコロナ禍でニーズの高まる「デジタルトランスフォーメーション」などの言葉に後押しされて、IT エンジニアは最も夢のある職業として認知されています。SNS で "駆け出しエンジニア" というワードを見ない日はありません。

それもあってか人材市場ではエンジニアが不足していると言われています。その一方で「実はエンジニア自体は市場に溢れている。足りていないのは優秀なエンジニアだ」という声も聞かれます。

求められる優秀なエンジニアとは何か、またエンジニアがそうなるためにはどうすればいいのか、少し考えてみたいと思います。

できるエンジニアって何？

ビジネス要求を IT で実現する人

優秀なエンジニア改め当記事で言う「できるエンジニア」とは何か。それを求めるのが誰かによってその定義は異なると思いますが、以下は概ね共通していると言ってよいと思います。

「(組織内外の) 顧客の要求に応えて "いい感じに" システムを作ってくれること」

エンジニアは専門職です。社外のユーザーや社内の業務部門からすると、IT というよく分からないものを専門的な知識をもって解決してくれる人たちです。その人たちに "いい感じ" な働き、つまりブラックボックス的な働きを期待するのは当然と言えます。

ここで "いい感じに" というあいまいな言葉を掘り下げてみます。エンジニアはつい、要件定義や設計の段階、あるいは実装の段階においてさえ、顧客ヒアリングと称して「ここはどうしたらいいでしょう」とお伺いをたてがちです。ユーザーが本当に必要とするものを実装するのが仕事なのに、(社内外の) 顧客に対して契約を履行する義務だけに注目してしまったり、あるいはプロとしての決断を無意識に回避したくなってしまうために、こういったお伺いをしてしまいます。

IT はビジネスのためのただのツールであり、エンジニアはビジネス要求を汲んでそれを実現する職業です。これを実践できるエンジニアが「できるエンジニア」である、と言えるはずです。

これはエンジニアの所属会社が事業会社であろうと、SIer であろうと、Web 企業であろうと、同じです。アプリ開発者であろうと、インフラエンジニアであろうと、運用オペレーターであろうと同じだと思われます。また、そのエンジニアの目指すキャリアがマネジメント方向であってもスペシャリスト方向であっても、やはり同じだと考えます。

ビジネス側の責任

近年、ビジネス部門員も IT スキル・知識をつけるべきという風潮があり、それには大賛成です。その結果として、設計や実装にも正しい要求やレビューができるビジネスユーザーが増えてきており、歓迎すべき状況です。専門職以外を含む全てのビジネスパーソンが IT の知見を身につけるべきであると、私は考えます。

一方で、それに甘えることなく、ビジネスニーズを理解して実装に落とし込めるエンジニアが「できるエンジニア」であることは変わりません。

要件定義や設計がうまく進まないとき、要件をうまく出せない・決められない顧客側に責任を帰すことを、エンジニアはしがちです。しかし、顧客は IT のプロではないからこそ IT のプロに仕事を依頼しているのだ、ということを忘れたくないものです。

一人でやる必要はない

付け加えると「顧客要求に応えて "いい感じに" システムを作る」を一人でやる必要はありません。そのようなフルスタックなスーパーエンジニアはごく稀です。

エンジニアは通常複数人いるので、チームとして実現できればいいのです。インフラならばインフラ領域で、アプリ開発者ならアプリの領域で、あるいはデータ分析で、のように、チームの一員として働いて成果を出せるような「できるエンジニア」を、私たちは目指せばよいのです。そういったエンジニアの市場価値は高く、報酬も上がりますし、社会に与える貢献も大きいです。

その「できるエンジニアに」になるためには何が必要か、少し考えてみました。以下に 3 つを挙げてみます。

① IT の基礎知識

この言葉、説明できますか？

「できるエンジニア」に必要なモノの一つ目は、基礎知識です。

あなたは、一人の IT エンジニアです。これまで伝統的な日本企業に在籍しており、クラウドに触れる機会は少なかったとします。キャリアとしてはインフラエンジニアであり、物理機器やネットワークの扱いはかなりの経験を積んできましたが、クラウドが当たり前になった今の世の中で、将来のキャリアに危機感を覚えているかもしれません。そして一念発起してクラウドを勉強することを決心します (AWS でも、Google Cloud でも構いません)。

その中で VPC、IAM、Amazon EC2、BigQuery、Organization、Terraform といったクラウドならではの知識に数多く触れることでしょう。もしかしたら、それらの知識がなかなか頭に入ってこず、理解度や学習のスピード感に思い悩むこともあるかもしれません。

なかなか理解が進まないのは、おそらく理解のために必要な基礎知識が抜けているから、かもしれません。

以下のような単語をご存知でしょうか。また、人に説明できるでしょうか。

• データモデリング、ER図、正規化、トランザクション、ACID、排他制御
• キュー、エンキュー、デキュー、スタック
• オブジェクト指向、クラス、インスタンス、メソッド、カプセル化、継承、ポリモーフィズム
• V 字開発モデル、アジャイル
• モジュール分割、モジュール強度と独立性
• セッションハイジャック、SQL インジェクション、クロスサイトスクリプティング

今、「これらはアプリケーションの専門知識だから自分とは無縁な言葉だな」と、インフラエンジニアであるあなたは思ったかもしれません。しかし実は、これらの単語はアプリ開発やデータベースの専門書からではなく、私の手元にある「基本情報技術者試験」の参考書から取ったものです。

そしてこれらはいずれも、クラウドを扱うにあたり避けては通れない言葉たちです。もちろんインフラエンジニアでも、です。なぜなら、クラウドプロダクトのマニュアルはこれらの言葉を理解している前提で書かれているからです。またよくできたクラウドプロダクトはデータモデリングやアルゴリズムの基礎理論に沿って実装されているゆえに、それら基礎理論の理解なしには、プロダクトの理解ができないようになっています (クラウドプロダクトに限らず、全ての情報技術がそうなっているはずです)。

もう一つのモデルケースです。あなたのキャリアがアプリケーションエンジニアだとして、以下の用語はどうでしょうか。聞いたことはあっても、人に説明できるでしょうか。

• OSI 参照モデル、TCP/IP、L2、L3、L4
• サブネット、サブネットマスク、NAT (NAPT)、SDN
• ファイアウォール、IDS/IPS、IPSec、WAF
• HDD、SSD、RAID、スループット、レイテンシ
• 仮想化 (CPU、メモリ、ストレージ、サーバ)

もちろんこれらも、基本情報技術者試験の出題から取っています。

IT 世界の共通言語

これらは IT に関わる全ての人たちが理解しているべき、共通言語と言ってよいと考えています。多くの場面で、これらの言葉は当然知っているものという前提で話が進められます。基本情報技術者試験は日本のものですが、海外でも概ね水準は同じように思います。

Google Cloud のドキュメントを例に取ると、例えば「トランザクションとは何か」について詳細に解説されることはありません。もし学習がうまく進まないことを感じたら、共通言語の知識が抜けていることを疑ってみてください。逆に、こういった共通言語が分かっていれば学習はとんとん拍子に進み、かつ机上だけの知識にとどまらず設計や実装に直結するはずです。基礎力が無いと、ベンダー試験に出る内容しか分からない人になってしまいます (資格を取ることには意味がない、という議論はここに向けたものと思われます)。一方で基礎力がある人は広く応用が効きます。

基本情報技術者試験を一度も勉強したことが無い方、あるいは参考書はとうの昔に後輩に譲ってしまったというような方。改めて Amazon で購入して、読み直してみてはいかがでしょうか。かつては試験に受かるためだけに勉強していたかもしれません (「アルゴリズムやデータベースは捨てよう」「ネットワークのところで点を取ろう」「午後問題は Excel だな」というように) が今回は、全ての単元を丁寧に「理解して、新卒エンジニアに説明できる」くらいまで理解してみるのはいかがでしょうか。即効性のある知識ではないかもしれませんが、この底上げはじわじわ効いてくるように思います。

中堅やベテランと呼ばれる方々にこそ、これをおすすめしたいと思います (逆に、IT 歴 0〜1 年の新人エンジニアがこういった基礎の学習のありがたさを知るのは、もう少し後かもしれません)。

知識の砂山

ここまでで「共通言語」と呼んだものがまさに「基礎知識」という言葉の正体のように思います。

知識は、公園の砂場に作る砂山のようなものだと思っています。

砂で細長く高い塔を作ろうとしても、一瞬で崩れ落ちます。砂山のふもとで基礎が横に広がっていなければ、高く積み上がることは決してありません。

これらの基礎を知らずして AWS や Google Cloud を身につけることはできません。コンテナやサーバレスなどは、夢のまた夢です。

広い知識が必要なのは、スペシャリストと呼ばれる人でも、ジェネラリスト寄りのエンジニアでも同じです。知識の砂山の基礎部分、すなわち「基礎知識」を身につける必要性はキャリアが長くなるに連れて、むしろ増してきます。

基礎知識が広がれば、砂をもっともっと高く積めるようになります。できるエンジニアの方々は、例外なく基礎知識が豊富のように思います。

② 抽象的思考

抽象的思考は考慮漏れを防ぐ

「できるエンジニア」に必要なモノの二つ目は、抽象的思考と考えます。

エンジニアに限らず、知的労働では具体的な思考と抽象的な思考を行ったり来たりして物事を考えることが求められます。

エンジニアはついつい、実装に関わる具体的な事項にのみ目が向きがちです。そのときに起こるのが「考慮漏れ」です。

どういうことか、さらに説明してみます。

例えば、ある Google Cloud 構築案件で IAM の設計を任されたとします。その開発プロジェクトでは主に Compute Engine を使っています。あなたは Compute Engine の IAM の仕組みについて調べ始めました。ドキュメントをしっかり調べ、検証もしたので Compute Engine の VM に対する IAM 設定はバッチリです。

しかしお客様とのレビューで「この環境では Cloud Storage も使っているじゃないか。Cloud Storage のアクセス制御は大丈夫なのか」と指摘を受けてしまいました。あなたはしまったと思い、慌てて Cloud Storage の IAM の設計を始めます。

これは、個別具体の実装を、個々に検討している様子です。このとき、もう少し抽象的な思考をができれば、考慮漏れを防ぐことができます。

思考の抽象度を上げて、IAM という仕組み全体に目を向けてみます。

そうすると、今まで検討していなかった Cloud Logging や、Cloud IAM 自体を管理する IAM まで検討できるようになりました (本当は水平方向に、考慮事項がもっとたくさんありますが省略)。Cloud IAM の上にはさらに線があり、さらに抽象度を上げられそうです。

Cloud IAM は RBAC というアクセス制御の仕組みに基づいており、IAM を正しく理解するためには RBAC の理解が必要そうです。さらに抽象度を上げると...

RBAC の他に ABAC という考え方があるのが見えてきました。さらに抽象度を上げると...

情報セキュリティ全体を検討する必要性があることに気が付きます。Compute Engine で動作するアプリケーションの L7 レベルのセキュリティは検討されているか。また証跡管理は適切に実装されているか。

このように思考の抽象度を上げると、より広い範囲の個別具体事象が検討範囲に入り、考慮漏れを防ぎます。

抽象的思考は上流工程に必要

このような抽象的思考が特に重要なのが要件定義や基本設計といった上流工程です。上流工程においては、考慮漏れを防ぐためにより抽象的な思考が必要になります。

さらに言うと上流工程の難易度が高い理由は「抽象的な思考だけでなく、ある程度具体的なイメージもできないと適切な要件定義はできない」という点です。個別具体的な実装に概ね当たりが付いている状態で、抽象的な思考を駆使しして抜け漏れなく物事を考える必要があるのです。つまり、抽象と具体を行ったり来たりして思考する必要があります。このように上流工程は難易度が高いため、これを適切に行うことができるエンジニアは「できるエンジニア」とみなされますし、市場価値が非常に高いです。

なお、この抽象的な思考をするためには広い範囲の知識が必要ですが、先に述べたような基本情報技術者試験のような IT 基礎知識は、それを補います。意外に思われるかもしれませんが、基本情報技術者試験で求められるようなジェネラルな知識は上流工程にこそ活きます。同試験はエンジニアの初学者に勧められているイメージがありますが、私は中堅・ベテランこそしっかり勉強したほうがいい試験だと考えています。

抽象思考は具体事項の理解を早くする

もう一つだけ、抽象と具体を行き来する事例を紹介させてください。

Bigtable という Google Cloud の NoSQL データベースサービスで「ホットスポット」という概念を勉強したとします。ある程度のカーディナリティがある列を行キーとし、このキーを非連続的な値にしなければ、ストレージの特定の物理ブロックにデータの I/O が集中してしまいパフォーマンスが低下してしまうという現象です。

実は、これは Cloud Spanner でもかなり似た仕様となっています。Bigtable も Cloud Spanner も、いずれも分散アーキテクチャのデータベースであり、特定の列のデータをもとに物理的な割り振り先シャードを決めていることに起因します。

ここまで理解すると、似たようなアーキテクチャの DBMS には、似た仕様があるのでは？という想像がつくと思います。実際に AWS の DynamoDB や、Azure の Cosmos DB でもホットスポットに似た仕様があります。

Bigtable と Cloud Spanner でこの仕様を理解できた時点で、次に DynamoDB や Cosmos DB を勉強したときは従来よりずっと速いスピードで理解が進むでしょう。

このホットスポットという具体的な仕様について「ストレージが分散アーキテクチャであることに起因するんだな」という抽象的な理解をすることで、結局はその後の個別具体仕様の理解に役立った、という例でした。こういった抽象的理解は先述した知識の砂山の基礎として積み上がっていきます。

このように抽象と具体を行き来する思考ができるエンジニアは、新しい事項の学習スピードも速く、実業務でもかなりの速さで仕事をこなすように思います。傍目にはそれが天才的なひらめきに見えるかもしれませんが、実は日頃からそういった地道な思考に慣れているがためにスピードが人より速い、ということのはずです。

③ 知的好奇心

「できるエンジニア」に必要なモノの三つ目は、知的好奇心ではないでしょうか。

本で読んだのか、ネット記事だったか、人から聞いたのかは忘れてしまいましたが、以前どこかで「ここ半年で、どのような本を読みましたか？ただし、あなたの専門分野以外の本で。」という問いを見かけてハッとしました。技術書は読みますが、その他の本 ...自然科学や歴史書などの社会科学、また経営関連の書籍や小説など... は読んでいないことに気が付きました。

良いエンジニアはアンテナが高く、様々な知識を取り込んでいるはずです。一見、役に立たなそうな知識がふとしたときに役に立ちます。

会計やマーケティング、人事などの経営関連知識は、システム要件やシステム間データ連携にダイレクトに役立ちます。

また例えば欧米発の IT 関連書籍には、聖書やヨーロッパ史などから、あるいはスタートレックなどのサブカルチャーからの引用もしばしばです。

知識の積み重ねは、さらなる知的好奇心に繋がります。知識が広がることでそれが次の基礎知識となり、学習スピードも早くなります。

また当然ながら、そういった一般教養的な知識に加え、その上に積み上げる IT 業界の知識というものもダイレクトに仕事に役立ちます。1 日 15 分でも、IT 系 Web メディアを読むことでかなり違いが出てくると思います。ただし Twitter などの SNS だけに頼るのは情報に偏りが生じエコーチャンバーに陥りやすいため、あまりおすすめできません。

アンテナを高くすることで、市場で求められているエンジニアの姿と自らのスキルのギャップに気がつけるかもしれません。それは、自分の市場価値を高めることにも繋がります。ギャップを自覚できれば、これから世の中で求められる IT スキルを身につける方向へ、一歩ずつゆっくりでも進んでいけるはずです。「Linux などの OSS 文化が当たり前であること」「インフラエンジニアでもコードが書けないと生き残れないこと」「アプリエンジニアでもアーキテクチャを考えられないと生き残れないこと」「プログラミング的思考の必要性」などのトレンドから目をそらさず、市場とのギャップを自覚し、軌道修正していくことで、自らの能力と報酬の向上へ着実に繋がるはずです。

さいごに

この記事は G-gen のメンバーや、将来 G-gen に入ってきてくれるであろう方に向けて、私なりの考え方を書いてみました。読む方の専門分野に寄らずできるだけ普遍的な内容としてみたつもりです。

Google Cloud 専業の会社に入ると、ついつい Google Cloud の学習に目が向きがちです。それももちろん大事なのですが、同時にエンジニアとして、またビジネスパーソンとして普遍的で基礎的なスキルにも目を向けていただけると嬉しいです。それが技術力の成長に繋がり、エンジニアとしての市場価値の向上に繋がります。G-gen のメンバーには、どの会社に行っても通用するスキルを身につけてほしいと考えています。転職して欲しいわけではないのですが、結局それがチームの力の底上げになるからです。

G-gen はそれが実現できる場所でありたいと思っています。