この記事でわかること
-
クラウドエンジニアを成長させる「良質な環境」の条件
-
転職やキャリア構築において、エンジニアが武器にすべき「ビジネスに資する技術力」
-
オーバーエンジニアリングの罠と、クラウドを学ぶための地道なロードマップ
クラウド技術の一般化、生成AIの台頭といった、エンジニアを取り巻く環境が変化する中、「クラウドエンジニア」としてキャリアを築き、転職などのタイミングで「選ばれる」存在であるためには何が必要なのでしょうか。
独立系SIerからクラスメソッド株式会社へ転職し、AWSのスペシャリストとしてコンテナ技術の推進などを牽引、現在は「製造業DX」という新たなフィールドで活動する「ハマコー」こと、濱田孝治さんに、クラウドエンジニアとしてキャリアを充実させるための考え方を伺いました。
ビジネスとの対話の重要性、クラウドエンジニアにとって必須の知識や技術、そしてAI時代により強く求められる「アウトカムへのコミット」意識など、キャリアを広げるためのヒントが詰まったインタビューをお届けします。
▶エンジニアに求められる「課題の深堀り力」とは？濱田孝治
独立系SIerを経てクラスメソッド株式会社へ転職。AWSのスペシャリスト、ソリューションアーキテクトとして数多くのインフラ構築をリードし、その後、アプリ開発までを一貫して行う「MAD事業部」の立ち上げを牽引した。現在は「製造業DX」領域へと活動の場を移し、顧客のビジネスの最前線に寄り添ったシステム構築に取り組む。数多くのブログ執筆や登壇などを通じ、クラウド関連の有用な知見の発信にも努め、界隈では「ハマコー」の愛称で親しまれる。
【X（旧Twitter）】：@hamako9999
目次
良質な環境＝ビジネスと対話し価値あるシステムを生み出せる環境
ーー濱田さんは、クラウドエンジニアとして第一線で活躍されてきました。クラウドを追求したい、あるいはこれからクラウドエンジニアとしてキャリアを重ねていきたいと考える若手エンジニアにとって、スキルを伸ばし、市場価値を高められる「良質な仕事環境」とは、どのようなものだとお考えですか？
濱田さん：クラウドを取り扱うエンジニアとして最もスキルが伸びる環境は、なによりも「ビジネスサイドと直接対話して、要件定義から関われる環境」だと私は考えています。
クラウドエンジニアというと「インフラ（基盤）を構築する人」というイメージが強く、「EC2やRDSなどの環境をつくっておけばいい」という風に捉えられがちかもしれません。しかし、インフラであれアプリケーションであれ、技術とはビジネス上の価値を生み出すための手段にすぎないはずです。取り組むべきビジネスの目的や背景をあまり理解できないまま、ただ技術だけを突き詰めるような環境は、「価値を生み出すエンジニア」にとって、望ましいものではないと思います。
もう少し具体的に考えてみます。たとえば、お客様から非機能要件を求められたとします。「システムは24時間365日動かし続ける必要があるのか」「土日は止まっていてもいいのか」「障害時の復旧目標はどのくらいか」など、これらはすべて、ビジネスでどのような価値を提供したいかによって変わります。
そして、システム構築における技術的な選択は、ビジネス要件から逆算して初めて最適な判断が下せます。ビジネスと対話を重ねることで、AWSでマルチAZ（複数のアベイラビリティゾーンにまたがる冗長構成）を組むべきかどうか、どこまで冗長化するのかといった判断ができるようになります。ですから「このビジネスにはこの構成が最適だ」と提案し、最適な技術を選択できる環境に身を置くことが、クラウドエンジニアにはとても重要だと考えているんです。
ーービジネス要件を的確にシステム設計に落とし込むためには、クラウドに関する知識以外にも必要なスキルがあるのでしょうか。
濱田さん：まず大事なのは、教科書的な話になってしまいますが、AWSの各サービスの特徴を大まかにでもインデックス的に整理された知識として持っておくことです。AWSには非常に多くのサービスがありますが、ビジネス要件から逆算して設計を考えていった際に、どういったAWSのサービスを設計に組み込むべきかを判断するうえで、こうした知識は必須になります。そして、それら知識と同じように、クラウドに依存しない、より低レイヤーの知識が重要だと思います。
システムはクラウドが提供する基盤だけでは動くわけではなく、基盤の上で動くアプリケーションの特性を理解していなければ、適切なアーキテクチャは選べません。たとえば、RDBとNoSQLの違いやそれぞれの得意・不得意、Webシステムの基本的な仕組み、コンテナとサーバーレスの違いなどの知識です。
もっと具体的に言えば、IPA（情報処理推進機構）のデータベーススペシャリストやネットワークスペシャリストの試験で問われるような、基礎的な知識の土台も有意義です。AWSの認定資格を持っていても、こうした土台となる知識やアプリケーションの知見なくして、お客さまに価値ある設計を提供できません。また、こうした土台の知識がしっかりしていれば、AWSからGoogle Cloudに環境が変わっても、勘所が働きやすく、応用を効かせるうえでも有用だと思います。
▶AWS運用の基本とノウハウをトップエンジニアが語る今後、価値が高まりそうだったから選んだクラウド。「コンテナ」という軸がもたらすもの
ーー濱田さんは独立系SIerから現在のクラスメソッドへと転職されたと聞いています。どのような経緯だったのでしょうか。
濱田さん：独立系SIerにいた頃は、主にアプリケーション開発を行っていました。転職を考えた一番の理由は、非常にシンプルで、「エンジニアとしての市場価値を伸ばし、食いっぱぐれないようにするため」です。
その先のキャリアや市場価値を考えたとき、当時（2017年頃）はクラウド、とくにAWSがものすごい勢いで伸びていて「AWSを取り扱えれば、いくらでも仕事があるだろう」と感じたんです。非常に単純ですね（笑）。自分が世の中に提供できる価値を大きくしたい、と考えたとき、最も可能性が感じられたのがクラウド領域だったんです。
ーー当時、AWSを専門にするクラスメソッドに入社され、ソリューションアーキテクトとして活躍されました。その後、コンテナ技術に注力し、モダンアプリケーション開発事業の立ち上げなども経験されています。
濱田さん：最初はソリューションアーキテクトとしてインフラの構築をメインに行っていました。しかし、当時は「既存のアプリケーションをデプロイしたいので、とりあえずインフラをつくってください」というような、アプリとインフラの接続が見えにくい案件が多かったんです。
元々アプリケーションをつくっていた私としては、アプリケーションの中身がわからないままインフラだけを作ることに、徐々に物足りなさを感じるようになりました。それ以前からコンテナ技術、つまり、インフラのなかでもアプリケーションレイヤーに近い技術にかなり力を入れていたのですが、もっとアプリケーションに近いレイヤーでお客様と対話したいと思うようになったんです。
その後、コンテナやサーバーレスをメインに、インフラ構築だけでなくアプリケーション開発までを一貫して行い、ビジネスに貢献する「MAD（モダンアプリケーション開発）事業部」を立ち上げました。
ーーコンテナ技術をご自身の「武器」としたことは、キャリアにどのような影響を与えましたか？
濱田さん：当時はまだコンテナ技術（AWS Fargateなど）が日本に上陸したばかりで、社内でもそこまで声高にコンテナを推進している人はいなかった記憶があります。ですから「これをやれば差別化できるんじゃね？」という皮算用もありましたね（笑）。
実際に、コンテナに腰を入れて取り組んでみて、「自分はこの技術に詳しいです」と発信（アウトプット）し続けることで、好循環が生まれました。アウトプットを見た人から登壇の依頼が来る。登壇するためにさらに勉強して理解を深める。このサイクルが回り始めたことで、社内外での自分のプレゼンスが高まり、キャリアが広がったと実感しています。なにかひとつ、自分の「名刺代わり」になるようなスペシャリティを持つことは、エンジニアにとって有意義でしょう。
ーー現在、製造業DXの領域に活動の場を移されていますが、これもビジネスへの距離を縮めるための一貫した流れなのでしょうか。
濱田さん：おっしゃる通りです。インフラ、コンテナ、アプリケーション開発と、徐々にドメイン（ビジネス）に寄っていくキャリアを歩んできました。最終的にITはビジネスに生かしてこそ価値があります。現在はITの話よりも、お客様の製造業のドメイン知識について話すことの方が多いですね。周りからは一貫性がないように見えるかもしれませんが、私のなかでは「ビジネスの最前線に寄り添っていく」という、軸は一貫して持っていると思っています。
クラウドエンジニアが避けるべき罠、オーバーエンジニアリング
ーー少し視点を変えて、読者である若手エンジニアが「転職で選ばれる自分」になるためには、どのようなスキルやマインドが必要になるのでしょうか。
濱田さん：知識や技術があることは大前提ですが、評価を受ける場、たとえば採用面接といったシチュエーションを考えると、重視されるのは、「自分の持つ技術や知識を組み合わせて、その会社（転職先）のビジネスにどう貢献できるのかを想像し、自分の言葉で語れる力」だと感じます。
「Reactが上手く書けます」「AWSの〇〇というサービスに詳しいです」といった技術を羅列してプッシュするだけでは、どうしても評価されにくいと感じます。ジュニア層ならともかく、ある程度のキャリアを持ったエンジニアであれば、「この人の技術が、事業にどう貢献するのか」という視点で評価されるように思います。ビジネスに対して自分の技術をどう最適化できるのか、その想像力を持つことが重要ではないでしょうか。
ーー実際の開発現場において、クラウドを取り扱うエンジニアが陥りがちな罠やアンチパターンがあれば教えてください。
濱田さん：私がよく見聞きする中で、一番の罠は「無理なマイクロサービス化」をはじめとするオーバーエンジニアリングですね。
マイクロサービス化自体は、ビジネス価値を出すためのアーキテクチャとして一定のメリットがありますが、「マイクロサービス化＝ただ面倒くさいシステムになっているだけ」というケースは非常に多いです。私自身も過去に、小規模な開発チームなのに、サービスを7つほどのコンテナに分割する設計を求められたことがありました。「面白そうだからやってみよう」と挑戦したものの、機能が半分くらいできあがった段階に入ると、ログのトレースやエラー調査があまりにも複雑なことが露見してしまい……。明確にビジネスのスピードを阻害するシステムにしてしまったと大いに反省しています。
もう一つ、エンジニアにとって重要だと感じる想像力が「人材の冗長性」です。
システムは作って終わりではなく、人が運用していくものです。たとえば、技術的に最適だからといって、市場にエンジニアが少ないマイナーな言語やクラウド環境を採用したとします。その後、その人が辞めてしまったとき、代わりのエンジニアを採用できなければ、システムは運用できなくなり、ビジネスは止まってしまいます。
知的好奇心から、システムに新しい技術を採り入れたくなる気持ちは非常に理解できますが、それを「誰が運用し、改修していくのか」という観点が抜け落ちていると、システムは属人化し、最終的にビジネスを阻害する要因になります。「世の中にそれを扱えるエンジニアがどれくらいいるか」という視点も、アーキテクチャ選定にはとても重要な要素です。
最速の学習プランは「手を動かして、動くものをクラウドにデプロイしてみる」
ーーこれから本格的にクラウドを学ぼうとするエンジニアに対して、濱田さんが考える「最速の学習ロードマップ」を教えてください。
濱田さん：AWS認定資格の勉強や、AWSの各サービスのドキュメントを読み込み、先にお伝えしたように頭の中に知識の「インデックス」を作ることは重要です。しかし、AWSのそれぞれのサービスを「点」として暗記しているだけでは、開発の現場ではなかなか活用できません。
クラウド、とくにAWSは「ビルディングブロック（部品を組み合わせてつくる）」という考え方で成り立っています。システムを構築する際、ひとつの機能要件を実現するために、多くのサービスという部品を組み合わせていくので、「サービスの機能を点で捉えるのではなく、複数のサービスを組み合わせてアーキテクチャのパターンとして『面』で理解する」ことを意識するといいと思います。
具体的な学び方としておすすめなのが、AWSが公開しているアーキテクチャの構成図（「AWS アーキテクチャセンター」に掲載されるパターンなど）を参照することです。「このビジネス要件のときは、このサービス群をこう組み合わせる」という具体的なパターンを知ることで、「この要件ならあのサービスとこのサービスを組み合わせれば実現できそうだな」と、頭の中のインデックスが有機的に結びつき、生きた知識として使えるようになります。
そして何より、「実際に手を動かして、動くものをクラウドにデプロイしてみる」ことをおすすめしたいです。こうしたプロセスでも生きた知識が手に入るはずです。生成AIを使えばアプリケーションのコードは簡単に書ける時代だからこそ、それを本番相当の環境で動かす経験も重要になってきます。
ーー具体的な構築の手順としては、どのようなステップを踏むのが良いでしょうか。
濱田さん：具体的な手順としては、あえて古典的な方法をおすすめします。最初は、 「1つのサーバー（VPSやEC2など）の中に、Webサーバーもデータベースも全て同居させて構築する」 ことから始めるだけでもいいでしょう。
ロードバランサー（ALB）やマネージドデータベース（RDS）を使うのは後回しでも大丈夫です。Linuxのコマンドを叩き、PHPやMySQLなどを自力でインストールする。パブリックサブネットに直接置いてネットワークの設定を甘くしていると、すぐに外部からサイバー攻撃が飛んでくるのを目の当たりにするはずです（笑）。セキュリティがいかに大事か、身をもって学べるでしょう。
一つのサーバーで一通りの構成を学んだら、次のステップとして「データベースだけをRDSとして外出しする」ことに挑戦してみるといいでしょう。すると、「ネットワークのセキュリティグループはこう設定するのか」と、AWSのマネージドサービスがどのような仕組みで動いているのかが、実感とともに理解できるはずです。その次にALBを置くなど、段階的にアーキテクチャを拡張していく。 いまの感覚では、最初から便利なマネージドサービスを組み合わせてしまいがちですが、 こうした基礎的な構築プロセスを経験しているかどうかが、プロダクション環境での障害対応などで差を生むと思います。
AIの実装と検証に見る「泥臭さ」と「覚悟」
ーー現在のクラウド界隈では、やはりAI関連の技術に注目が集まっています。今、エンジニアが投資すべき技術領域として、生成AIはどのように位置付けられますか？
濱田さん：クラウドエンジニアの視点で見ても、AWSの「Amazon Bedrock」やAIエージェントの構築などは、完全にメインストリームになりつつあり、言うまでもなく、注力すべき領域です。
ただ、AIをプロダクションレベル（本番環境）で安定して稼働させることは、現時点ではめちゃくちゃ難しいのが実情です。
ーーどのような難しさがあるのでしょうか。
濱田さん：例えば、Slackから最新の情報を取得して、メールから必要な注文情報を抽出し、システムに自動で登録するようなAIエージェントを組んだとします。これをローカル環境のクライアントで動かす分にはいいのですが、サーバーにデプロイして安定稼働させようとすると、途端にハードルが上がります。
AIが想定外の変な挙動をしたときに、ログを追って原因を特定し、チューニングをする。こうしたプロセスは非常に難しいのが現状です。さらに、AIを業務に組み込むということは、これまで以上に「お客様のビジネスドメイン（業務フロー）」を深く理解していなければ、AIが出した結果の良し悪しを評価することすらできません。インフラやクラウド以上に、AIが関与する領域はビジネス寄りになってきている印象があります。ですから、これまで以上にビジネスを理解し、適切なシステムを提案するという力が重要になってきていると感じています。
ーーより深くビジネス層に入り込み、泥臭い検証とフィードバックのサイクルを回す覚悟が求められるのですね。
濱田さん：インフラを作って引き渡していた時代よりも、さらにアジャイル的に、「つくって、お客さまと一緒に評価して、改善する」というサイクルを高速に回す必要があると思います。
AI時代、エンジニアがあらためて持つべき、アウトカムに向き合う姿勢
ーー生成AIの登場は、エンジニアに大きな変化をもたらしています。クラウドエンジニアの業務において、AIに代替される領域と、人間の価値として残る領域についてどうお考えですか？
濱田さん：クラウドのインフラ構築に関わる領域では、ほぼ全てAIに代替されるのでは、と考えています。 ただし、AIがコードを書き、インフラを自動生成してくれるようになっても、「それが本当にプロダクション（本番環境）の非機能要件に耐えうるか」といった要素を判断するのは、まだ人間の役割ではないかと考えています。
たとえば、セキュリティの担保、データのバックアップとリストア、可用性の設計など、ビジネス要件に密接に関わる部分には、人間のクラウドエンジニアの介在価値があると感じています。AIに「いい感じにつくって」と指示を出しても、裏側でDynamoDB（NoSQL）とAmazon Aurora（RDB）のどちらが選ばれているのか、それがコストや可用性の面でビジネスの要件を満たしているのか、それを評価し、責任を持つのは人間のエンジニアの役割と、現時点では言えます。
ーー最後に、AI時代に「価値あるエンジニア」として生き残り続けるためのマインドセットを教えてください。
濱田さん：最も重要なのは、「自分の作っているシステムが、どのようなビジネスアウトカム（成果）を生み出しているのかに対して、真正面からコミットできること」だと思います。ビジネスと向き合うことから逃げずに、技術で価値を提供していくという姿勢を持てるかどうかが、これからのエンジニアにとって、いままで以上に重要になるだろうと考えています。
ーーありがとうございました！
▶AIを「使う」から「作る」にシフト【最新技術トレンド】
取材・文：はてな編集部
撮影：小野奈那子
マイナビ転職 アンドエンジニア編集部
