クラウドサービスはエンジニアの失業を増やすか？
どうも、エンジニアのgamiです。
僕はここ数日、7/30に登壇するデブサミの資料作成に追われています。
人生初の40分セッションです。正直に言うとこのnoteを書いている時間も惜しいです。ですが、せっかくデブサミ準備で様々なことへの思考が深まっているので、その一部をnoteにも残しておきます。
今回デブサミで話すのは、わかりやすくいうと「クラウドサービスはエンジニアの仕事をどう変えたか？」についてです。クラウドサービスがシステムの開発や構築に対して与えた影響は凄まじく、一部のエンジニアの役割が縮小したり、逆にエンジニアが新しい役割を担うようになったりしました。さらには、エンジニアと非エンジニアの境界を曖昧にし、誰もがソフトウェア開発やシステム構築できる世の中に近づいています。
クラウドサービスとは何か？
「クラウドサービス」がよくわからんという人に向けて、以前こんなnoteを書きました。
クラウドサービスの重要な一側面をシンプルに整理した、僕の歴代noteの中でも一番好きな記事の1つです。
内容を一言でまとめると、もともと各社が独自にサーバーやシステムを構築していたところが、IaaSでサーバーがシェアされるように、SaaSでその上のシステム（アプリケーション）がシェアされるようになった、ということです。
みんなでサーバーやシステムをシェア利用するからこそ、それらの管理や構築が一元化され、ユーザー企業はただ利用料を支払うだけでサーバーやシステムをすぐに使い始めることができます。
クラウドサービスの登場には、エンジニアにとって重要な要素が2つあります。1つは、サーバーやシステムの構築ハードルを下げたということ。もう1つは、プログラムによって操作できる範囲が増えたということです。
IaaSは、いわゆる「インフラエンジニア」と呼ばれていた人たち以外の普通のソフトウェアエンジニアでも、インフラ構築をできるようにしました。また、サーバーリソースの管理などがAPI経由でプログラムから操作できるようになり、ソフトウェアエンジニアによる自動化の余地が広がりました。
SaaSは、さらにエンジニア以外の職種の人たちだけで自分たちが欲しいシステムを構築できるようにしました。また、エンジニアの力を借りれば複数システムの連携も各SaaSの提供するAPIを使うことで簡単にできるようになりました。
それぞれ詳しく見ていきましょう。
IaaSが無くした役割、生んだ役割
かつては、各社それぞれが物理サーバーを明示的に確保する必要がありました。自社のサーバールームがある場合は、「インフラエンジニア」とか「ネットワークエンジニア」と呼ばれる人たちがサーバー用の巨大なコンピュータを段ボールから出し、サーバーラックに詰め込み、LANケーブルでネットワークにつないでいました。ちなみに、少なくとも日本では自社でインフラエンジニアを抱える会社は少なく、ほとんどの場合はSIerと呼ばれるIT企業に作業が発注されていました。
こうした仕事は、IaaSの登場でかなり少なくなりつつあります。もちろんクラウドサービスを使う場合も、世界のどこかに物理的なサーバーはあります。しかしそれはAWSやMicrosoftのデータセンターの中の話であり、ユーザー企業側がそれを意識する必要は無くなりました。
クラウドサービスを利用したシステム開発では、インフラエンジニアの役割は大きく変わりました。まず、AWSやAzureやGCPなどの各種IaaSへの知識や、仮想化など関連技術への理解が求められるようになりました。また、IaaSの管理やプログラムによって自動化することが一般的になり、プログラミング能力が当然のように要求され始めます。つまり、インフラエンジニアの役割がソフトウェアエンジニアに接近しました。
ちなみに、ソフトウェアエンジニア（Dev）目線でインフラエンジニア（Ops）の役割を再定義した結果生まれた職種が、「SRE」と呼ばれたりします。
IaaSの登場で、物理インフラの知識が無かったソフトウェアエンジニアでもインフラ構築ができるようになりました。これによって逆に、ソフトウェアエンジニアの役割もインフラエンジニアに接近しています。具体的には、ソフトウェアエンジニアにも当然のようにクラウドインフラの知識が求められるようになっています。極端な話をすれば、ソフトウェアエンジニアが1人いればインフラ構築からアプリケーション開発までを一貫してできる世界になっています。夢がありますね。
ちなみに、この辺りの話は「DevOps」とか「SRE」について調べるとより詳しく学べます。ざっくりとイメージを理解するには、このスライドがおすすめです。
SaaSが無くした役割、生んだ役割
業務システムの世界では、IaaSによって起きたのと同様の変化が、SaaSによって起きています。
かつては、各社それぞれが自社サーバーを使って業務システムを構築する必要がありました。情シス部門にいる社内SEがそれを主幹し、日本では多くの場合SIerに開発が外注されました。もちろん各社毎に似たような業務があるため、毎回ゼロから作るということは基本的にはありません。しかし、各業務システムパッケージは各社のサーバーに個別にインストールされるため、個社毎にかなりのカスタマイズが施されていました。
SaaSは、自社サーバーの構築だけではなく、その上に乗るシステムまで提供してくれます。SaaSは多くの会社に共同で利用されるため、個社カスタマイズには向いていません。その代わりに、SaaSベンダーのPdMやエンジニアが知恵を絞って汎用的に使える機能を提供し、カスタマイズ要求を吸収しています。また、多くのSaaSは外部連携のためのAPIを持っているので、足りない機能は他のSaaSを組み合わせて実現することができます。
SaaSを使った業務システムの構築では、社内SEの仕事は大きく変わります。まず、IaaSと同様に物理サーバーに関する業務は無くなります。また、業務に合わせてパッケージ製品をカスタマイズしたりそれを保守したりする仕事も不要になりました。これらの多くはSIerに外注されてきましたが、そもそも外注自体が不要になるケースも増えそうです。社内SEだけで業務を進める場合、世の中のSaaS製品に関する知識、SaaSを組み合わせて業務フローを実現するためのプログラミング能力などが求められます。これまで外注先と社内所管部門との間の調整しかやってこなかった情シス部門は、大きく働き方を見直す必要が出てきそうです。
ちなみに、社内のSaaS選定やSaaS管理の最適化を行うような役割を「SaaS Ops」と呼ぶ動きがあるようです。かっこいいので使っていきたい。
SaaSの登場によって所管部門の非エンジニアでも自分たちが使いたい業務システムを調達できるようになりました。労務部門だけでSmartHRを導入したり、マーケティング部門だけでKARTEを導入したり。これにより、非エンジニアにも自分の業務に関わるSaaSの知識が求められるようになっています。SaaS利用の試行錯誤を各所管部門が自ら回していった方が改善スピードが早くなるので、今使っているSaaSの使い方を見直すとか、よりよいSaaSプロダクトが登場したら乗り換えるとか、そういった意思決定が必要になります。
SaaSに詳しくなるためには、必然的にITとかデジタルとか言われる領域の知識も身に付ける必要が出てきます。ここでは、エンジニアと非エンジニアの境目がどんどん曖昧になっていくでしょう。とはいえ今は過渡期なので、エンジニアが非エンジニアの作業や学習の支援に入るケースもまだまだ多そうです。
クラウドサービスは計算機資源という手段を万人に開放する
ここまで見てきたように、クラウドサービスはサーバーリソースを誰でも使えるようにしました。それは、多くの人が「自分が追求したい価値」に集中できる世界を作りました。ソフトウェアエンジニアはより良いソフトウェアの開発がしたいのであって、その機能がどんな物理サーバーや配線によって実現されるのかにはそこまで興味がありません。各所管部門のメンバーは自分たちの業務を効率化・デジタル化したいのであって、そのためのシステムがどんなプログラミング言語で記述されどのようなインフラ構成になっているのかには関心が無いはずです。IaaSやSaaSは、「自分が追求したい価値」とは直接関係がない部分をまるっと面倒見てくれます。
「IaaSやSaaSが担うようになった役割をかつて担っていたエンジニアたち」は、自分の役割を見直す必要にせまられています。もちろん、ご存知のようにデジタル化の波はあらゆる業界に押し寄せ、エンジニア全体の仕事量は爆発的に増えています。クラウドサービスは短期的には一部のエンジニアを失業させるかもしれませんが、長期的に見れば「より価値に近い仕事」に多くのエンジニアを導いてくれる存在だといえそうです。なによりも、価値を実感できる仕事こそが、楽しい仕事であると僕は考えます。
xOpsエンジニアの広がり
以上が、7/30のデブサミで話そうとしている内容の一部です。本番はこれ以外にもDXの話とかSaaSベンダーの中の話とかもするので、興味がある人はぜひセッションを聞きに来てください！（宣伝）
最後に、マガジン購読者の方に向けてデブサミで話さない内容も付け加えておきます。
上述したように、SaaSの爆発的な増加によってエンジニアと非エンジニアの境界は曖昧になっています。各所管部門がアジリティの高い業務オペレーション（Ops）を構築するには、ITシステムが不可欠になっています。それを高度に実現するためには、各部門の非エンジニアと全社横断のSaaS Opsエンジニアだけでは足りない可能性があります。そこでは、各部門にエンジニアが入り込み、それぞれのOpsを改善する取り組みが増えていくはずです。ここではそんなエンジニア（仮にxOpsエンジニアと呼んでおきます）の可能性について考えます。
思えば、僕自身も今の会社で色々なチームに誘われて、xOpsエンジニアっぽいことをやってきました。
一番関わっているのは、自社プロダクトのCustomer Success Opsです。プロダクトを利用中のユーザーに対するTechTouch施策の実装や、プロダクト利用に関するデータを可視化するためのダッシュボード作成などは今でもやっています。Webサイト上に複雑なアクションを配信するとか、管理画面上から取得するイベントを設計・実装してそのログをSQLで集計するといった作業は、さすがにエンジニアである僕がやった方が早いです。もちろんSaaSを使えば非エンジニアのメンバーだけで実現できることも多いですが、設計上無理があるような実現方法になってしまうリスクが増えます。
また、HR Opsにも一部関わったことがあります。もちろん採用管理用のSaaSは使っているのですが、「現在の採用進捗を職種別にSlack通知したい」などそのSaaS単体では実現できない特殊な要望が社内から出ることがあります。そんなとき、比較的距離の近いエンジニアである僕が呼ばれて実装を頼まれることがあります。このSlack通知に関する要望は、Google Cloud Functionを立てて独自Slack Appとして実装することで対応しました。
より専門的な知識や経験を持ったメンバーが各チームに「入り込んで」仕事をする事例は、様々なケースで増えています。たとえばIaaSの説明で登場したSREも、開発チーム横断のSREとは別に、各チームに入り込んで仕事をする「Embedded SRE」という動き方が生まれています。
これと同じく、SaaS Opsに強いエンジニアが「Embedded SaaS Ops」として各チームに遍在してそれぞれの業務のOpsを現場感を持って改善し続けるという動きは、今後も増えていきそうに思います。
もしかしたら、昨今のNoCodeの流れが高度化したり、開発スキルをもった非エンジニアが増えてきたりすると、xOpsエンジニアも不要になるかもしれません。しかし、NoCodeはまだまだ「幻想」であり、しばらくはエンジニアと非エンジニアが力を合わせて課題に取り組む必要がありそうです。
なお、xOpsについては馬田さんの次のスライドが詳しいです。ぜひ合わせてどうぞ。
ここから先は
仕事を楽しくするデジタルリテラシー読本
【初月無料】デジタル時代の歩き方について考えたことを発信します。ソフトウェアの時代とは何か。エンジニアの頭の中はどうなっているのか。NoC…
サポートをいただけると、喜びドリブンで発信量が増えます！初月無料のマガジン『仕事を楽しくするデジタルリテラシー読本』もおすすめです！