株式会社スリーシェイク 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を中心としたアーキテクチャを採用していました。しかし今は、大企業向けにきめ細かい権限設計をする必要性がでてきて転換期を迎えています。初期には初期のプロダクトの目的があり、その後の移行の負荷をある程度織り込んだうえで目的達成できる技術選定ができていれば良いと思います。
塚越：早めに出せば、早めに学ぶことができますしね。まだ売れてない状況で最適化しすぎてしまうと、オーバースペックになりがちです。むしろ最小限売れてからスケールさせるほうが健全かと思います。
手塚：どういう技術を選定するかという観点になってしまいがちですが、プロダクトファーストでどう伸ばしていくかという視点が必要ですね。それ自体が非常に難易度が高いものではあるのですが。
増えるエンジニアに求められる役割、「いい塩梅」を実現するには？
――SREに関する開発現場の課題として運用負荷、スキルセットの違い、プロダクトの成長に合わせた技術選定などが出てきました。
手塚：あとは責任分解点をどうしていくか。例えば「APIで会話しろ」というのは、大規模組織であれば、コミュニケーションという最もオーバーヘッドの大きい作業を省略できるため効率がいい方法だと考えます。だからといって小さいチームでこれを実施しようとするのは非現実的ですし、逆にスピード感を下げてしまう要因にもなりうると思います。プロダクトとチームの成長を考えて、意識的に設計していく必要があると考えています。
塚越：「自分が作ったものは自分で運用しなさい」という考え方が広まってきている一方、エンジニアに求められるものが増えてきているとも感じていて、どんなフェーズでどんな選択をするかという意味で「いい塩梅」が大事だと思います。まじめ過ぎるとオーバーヘッドで遅くなってしまうので。
手塚：たしかに、プロダクトの技術選定でも「いい塩梅」って大事ですね。私の領域で言うと、SREにおいて信頼性のレベルを捉えて技術選定を行うことは非常に重要だと思っています。信頼性がないと顧客が離れてしまう可能性が高いためプロダクトは売れません。しかし仮に高度な信頼性を極めたからといってプロダクトが売れるとも限りません。
信頼性や拡張性ばかり意識して技術選定しても、プロダクトが成長するかどうかは別問題。一方で将来のための技術選定がないと後のフェーズで不利になることもあります。その「いい塩梅」を見極めることが大切です。それが難しいところではあるのですが。
――これまで出てきた課題にSRE的なアプローチをすることでどう解決できるでしょうか？
手塚：SREで私が好きなエッセンスはユーザー視点とデータドリブンです。SLO（Service Level Objective：サービス提供側が達成すべき目標）を定義してその数値というデータを基に開発と信頼性を高める活動を進めるやり方はGoogleさんらしいかもしれません。例えば運用負荷の課題に対して、ユーザー視点でSLOを定義して、開発や運用に必要なものを整理していくアプローチは短期では効果はわからないかもしれませんが、長期的に続けていく中で効果が発揮されるものかもしれません。
塚越：まさにそうですね。サービスによりSLOやどこが「いい塩梅」なのかも異なってきます。そこでユーザーを見ずにSLOを設定してしまうと、全く意味がありません。「いい塩梅」を決める際に、ユーザー視点で決めると良いのではないでしょうか。
――「FaaS負債」など、マネージドサービスが増えすぎて運用負荷が上がってしまう場合はどうでしょう？
塚越：個人的にはマネージドサービスを使った設計をする際にDDD（ドメイン駆動開発）を組み合わせると相性がいいと思います。ドメイン単位で機能を閉じていくと、機能を小分けにしやすい。それに伴い、機能に求められるSLOも変わってくるので、1つのサービス下に大量にサービスがあるよりは、ドメインごとに機能がある形にすると多少はマシになるのでは。
手塚：確かにクラウドの恩恵は手軽さと捨てられることに凝縮されると思っています。DDDだとその手軽さを十分に活用できますね。
――技術選定とプロダクトの成長についても、SLOやユーザーストーリーが決め手となりそうですね。責任分解点はどうでしょう？
手塚：繰り返しになりますが、マネージドサービスやサーバーレス系を使うと、アプリケーションとインフラの境界が無くなりますので、そのパラダイムに合わせて組織を設計していく必要があると思います。
塚越：それってコンウェイの法則の発想ですよね。ちょっと本筋からずれてしまいますが、最近はシフトレフトの流れもあると思います。テストにしても、セキュリティにしても、早めに取り組むような流れ。開発が終わってからテストをするのではなくて、最初にテストコードを書いて、早めに失敗して、早めに見直すようなプロセスです。SLOや ユーザーストーリーに加えてこういったことも重要なんじゃないかなと思います。
――組織を変えていくことについては？
手塚：かつて関わったプロジェクトではゼロから組織を立ち上げました。既存組織に手を加えるのではなく新しい箱を作り、そこに合う人を増やして文化を作って行くという方法をとりました。既存の形を変えることは相当に難しいため、新しい箱で新しい風を吹かせたうえでその流れを作ることのほうが大規模な組織の場合には有効に思えます。
塚越：最近大手企業でもよく聞くようになりましたね。一方で、そういう足かせがないスタートアップは有利で、一気に先駆者になることもできるんじゃないでしょうか。
SRE的なアプローチの実践は難しい？ Google Cloudの便利な機能とは
――明日から開発者がマネージドサービスやコンテナを活用する時、Google CloudだとCloud Runなどが相性良さそうに思えるのですが。
塚越：まさにピッタリだと思います。加えて「まずは使ってみて」と言いたいです。本当に難しくないので。一度試したら感覚がつかめるとおもいます。オススメは、まずはサンプルコードのデリバリーを試してみて、少しずつ機能を追加していく。そして、そこにデータベースを追加するという進め方なら覚えやすいと思います。
――便利な機能やおすすめの機能はありますか？
塚越：最近機能がいろいろ追加されています。例えばGitHubのリポジトリがあれば、Cloud Runからリポジトリを指定すれば、5分くらいでCI/CDパイプラインができあがるので自動化を組みやすいと思います。後はSLOモニタリングの機能もついているので簡単にSRE的なアプローチも始めやすいです。
――運用負荷が高まるケースでも役に立ちそうですか？
塚越：フルマネージドサービスなので、コンテナを乗せればスケールします。ミドルウェア以下を気にしなくていいので、開発に集中できるかと。
手塚：元々インフラエンジニアをやっていた身からすると、今までのミドルウェアまでの管理はしんどかったです。Cloud Runだとそれを管理しなくてすむのは圧倒的な差になると思います。あと一通りの監視が入っているところもいいですね。ログもメトリクスも標準で拾ってくれます。もちろんそこからチューニングする必要はあるのですが、60点くらいまでやってくれるのはすごくいいなと思います。
塚越：あとはSLOモニタリングも便利。
手塚：そうですね。2ステップで設定できるので、初めて触るのであればよいのでは。
――ユーザーストーリー観点で便利な機能はありますか？
塚越：アプリケーションデプロイ周辺だと、簡単にロールバックできるようになったことかな。デリバリーして失敗したら、1つ前のリビジョンに戻せばいいので、新しいものをすぐに世の中に出すためにも切り戻しが楽というのはメリットになると思います。
手塚：あと観点が変わってしまいますが、サービス運営で後からつらくなるのがデータ活用分野です。それを考慮しないアーキテクチャでアプリケーションを組んでしまうと後々苦労してしまう。Google CloudならBigQueryが強いので、使いこなせるアーキテクチャにしておくといいですね。
塚越：あとエンジニア育成の観点だと、セキュアなサンドボックスを提供できるといいと思います。最近はConfig ControllerでYAMLを使ってリソース管理がでできるようになってきていて、プロジェクトの払い出しとか、フォルダ作成、ポリシーもYAMLで宣言的に管理できるようになるのです。
エンジニア育成には好きに使える環境を提供することが大事です。好きに作れて、好きに壊せる。しかし仲間と共有していると、下手に壊したら怒られる。だから冒険しない。そうすると学ぶ機会がなくなってしまいます。ですのでポリシーを効かせて、すぐに払い出せるような、セキュアなサンドボックスがあるとエンジニア育成に役立つのではと思いました。
手塚：共有環境でネームスペースとか間違えてしまったら大変ですからね。
――最後に読者にメッセージをお願いします。
塚越：アーキテクチャをデザインする際に、ユーザー視点やユースケースは大事かと思います。当たり前に聞こえるかもしれませんが、技術に集中してると意外と忘れやすいポイントです。あと何よりも、行動することが大事ですね。ぜひCloud Run 動かしてみてください。（笑）
手塚：作業とエンジニアリングは違うということだと思います。技術的な課題を解決することも大事ですが、プロダクトの成長を考え、価値あるエンジニリングをすることも大事です。そうしたことを意識してもらえればと思います。
