株式会社スリーシェイク Sreake事業部 部長 手塚卓也氏
技術がプロダクトの足枷に……エンジニア不足が生む負のループ
――まずはこれまでのご経歴や現在の役割について簡単にお聞かせください。
手塚：2016年にインフラ系ベンチャー企業に就職しインフラエンジニアとしてキャリアをスタート、スリーシェイクには2018年に入社し顧客企業へのSRE立ち上げ支援などを行ってきました。現在はSRE総合支援やセキュリティサービスを展開しているSreake事業部の部長としてチーム全体を見ています。
塚越：私はWeb系企業でキャリアをスタートさせ、サーバーサイド開発や運用、iOSアプリケーション開発などに携わりました。その後クラウドベンダーにてコンサルタントやプリセールスを経験し、現在はGoogle Cloudのアプリケーション モダナイゼーション スペシャリストとして、アプリケーション開発者向けにサーバーレスや、マイクロサービス、DevOpsといった領域の技術支援を行っています。
――手塚さんはSRE支援でさまざまな開発現場を見ていると思いますが、最近はどんな課題が多く見られますか？
手塚：まずはエンジニア採用の難しさがあります。もともと難しいうえに、ソフトウェアとインフラ、両方が分かるエンジニアとなると、さらに困難になります。特にスタートアップだと開発と運用が分かれておらず、インフラ専任の担当者がいないケースが多いと思います。するとインフラの運用負荷が高まるような技術選定をしてしまい、プロダクト成長の足かせになってしまうことがあります。
塚越：IaaS系のサービスで運用負荷が高まるというのは聞きますが、サーバーレスやマネージドサービスでも起こりますか？
手塚：私は「FaaS負債」と呼んでいるのですが、FaaSは簡単にデプロイまで持っていけて構築が容易な反面、大量の関数を作ってしまうと運用上のメンテナンスで課題が出ると思います。FaaSのランタイム自体にも、定期的な更新によって特定言語のバージョンサポート終了などもありますので、それを多数の関数に対してガバナンスを効かせて管理するというのはかなり労力が必要な作業なんですよね。
塚越：FaaS負債はどういうケースで起こることが多いですか？ イベントのつなぎ目が増えすぎてしまうとか？
手塚：そうですね。まず大前提として、インフラとアプリの境界線が曖昧になってしまうのが課題点になると思います。例えばKubernetesを使うとき、GKEを作るまではTerraformを使い、その後のアプリケーションレイヤーはKubernetesで管理すればいいですが、FaaSを使うとなるとアプリのコードとインフラ構成管理コードが混在しがちです。最近はコンテナ型で動かす機能も出てきているので改善に向かっていますが、責任境界の曖昧さが複雑さを生む要因になっています。
塚越：インフラエンジニアとアプリケーションエンジニアだとスキルセットが違いますし、混沌とするのも分かる気がします。今は過渡期なのかもしれませんね。昔ながら（オンプレ）のインフラエンジニアとアプリケーションエンジニアがクラウドに移行した時に、そのままの役割分担にはならないと思います。ではクラウドで誰がインフラエンジニアをするのかと考えると、「クラウドエンジニア」と呼ばれる新たなロールが生まれているような。
そのクラウドエンジニアに求められているスキルにはインフラだけではなくて、マネージドサービスも使うアプリケーションのアーキテクチャを考えるとか、両方の知識が求められています。まだそういう人は少ないですよね。だからFaaS負債のようなことが起こるのかも。
手塚：念のため、オンプレのインフラエンジニアのスキルも凄く重要だと強調しておきます。例えば、ネットワーク周りの知見がないとクラウド上で適切な設計を行うのは難しいと思いますし、私が関わったプロジェクトでも、過去にトラブルシューティングした際にはネットワーク周りの知識がないと太刀打ちできなかったケースも非常に多かったです。ただ、一人の人に両方のスタックを期待するとなると難しいので、組織的に解決する事が重要かもしれません。
塚越：ところで、FaaS負債を解決できるような人はいるのでしょうか？
手塚：現実的に解決というのは難しいと私は思うのですが、強いて言うのであれば負債をあらかじめ計算に入れて設計できる人でしょうか。意図せず作りこみ過ぎた結果、負債になるのはよくないと思います。適切に取捨選択ができるかはチームや組織のケイパビリティやキャパシティに依りますし、その中でプロダクトの成長をどう捉えていくかというバランスをきちんと考えないと。
塚越：そのFaaS負債を計算に入れられるのって、どんなスキルセットなのか興味があります。自分の肌感覚だと、データベース中心の設計よりも、ユースケースやビジネスドメイン中心に設計する人のほうが上手にやってるイメージがありますが。
手塚：スキルと言われると難しいですね。だからこそ、こういうケースではGoogle Cloudさんや我々のような手慣れたベンダーに頼っていただくというのもいい選択肢かなと思います（笑）。
真面目な話をすると、サービスの性質や段階にも依るところがあるので。例えば弊社の脆弱性診断自動化ツール「Securify Scan」では、最初は簡単かつ早くリリースすることが重要でしたので、Firebaseを中心としたアーキテクチャを採用していました。しかし今は、大企業向けにきめ細かい権限設計をする必要性がでてきて転換期を迎えています。初期には初期のプロダクトの目的があり、その後の移行の負荷をある程度織り込んだうえで目的達成できる技術選定ができていれば良いと思います。
塚越：早めに出せば、早めに学ぶことができますしね。まだ売れてない状況で最適化しすぎてしまうと、オーバースペックになりがちです。むしろ最小限売れてからスケールさせるほうが健全かと思います。
手塚：どういう技術を選定するかという観点になってしまいがちですが、プロダクトファーストでどう伸ばしていくかという視点が必要ですね。それ自体が非常に難易度が高いものではあるのですが。
