クラウドサービス事業者におけるOSS 〜マネージドサービスとオープンソースSDK〜

この記事は2025年2月21日(金)に行われたオープンソースカンファレンス 2025 Tokyo/Springにおける発表をさくナレ編集部で記事化したものです。

はじめに
さくらのクラウドというパブリッククラウド
パブリッククラウドにおけるサービス、プロダクト
クラウドの実装〜マネージドサービスとOSS〜
クラウドのオープンソースSDK
OSS、クラウドSDK、そしてマネージドサービス
社会を支えるパブリッククラウドを一緒に作りませんか？
おわりに：編集部より

はじめに

さくらインターネットの田籠聡です。今回は「クラウドサービス事業者におけるOSS 〜マネージドサービスとオープンソースSDK〜」というタイトルで話をしていきます。

自己紹介

私は2024年8月にさくらインターネットに入社しました。それ以前も基本的にはずっとソフトウェアエンジニアをやってきました。FluentdやMessagePackなどのメンテナをやっていたり、自分でもいくつかのOSSを作っています。それからISUCONは私がやりたいと思って始めたイベントです。さくらインターネットではクラウド事業本部というところで、さくらのクラウドというパブリッククラウドサービスを作る仕事をしています。ネット上では@tagomorisというアカウント名で活動しています。

ストーリー

本日の内容は「マネージドサービスとオープンソースSDK」ということで、まずはさくらのクラウドがどういうもので、パブリッククラウドを作るというのはどういうことなのかという話をします。それから、クラウドの実装というのはどういうものなのか、マネージドサービスとはどういうもので、それにOSSがどのように関わってくるのかという話をします。さらに、クラウドのオープンソースSDKがどういうものでどういった問題があるのか、OSSとSDKとマネージドサービスの関係について、といった話もしたいと思います。

さくらのクラウドというパブリッククラウド

さくらのクラウドとは

クラウドサービスで一番有名なのはAWSでしょう。あとはGoogleクラウド、マイクロソフトのAzure、オラクルのOCIなどがありますね。さくらのクラウドはそういったもののうちの一つです。日本企業が日本国内の設備でやっていますので国産のクラウドということになります。「国産クラウドで『お客様のやりたいこと』を『できる』に変える」というスローガンを掲げています。

さくらのクラウドは2011年にサービスを開始したもので、サーバ(VM)と、それに伴って必要なストレージやネットワークを提供するというIaaS型のクラウドサービスだった時代がかなり長く続いていました。ところが2023年にガバメントクラウドの条件付き認定をいただきました。条件というのは何かというと、2026年の3月までにガバメントクラウドとして認められるべき条件を全部クリアしたら正式に認定されるというものです。この条件には、認証や統制、いろいろなPaaSを含むマネージドサービスなど、すごく多くの機能が含まれています。それをクリアすることを目指して急ピッチで開発を進めているところです。

ガバメントクラウドとは

このガバメントクラウドとは何かというと、デジタル庁が整備する、政府と地方公共団体で共通利用するクラウドサービス基盤です。といっても、ガバメントクラウドというサービスを新しく作るわけではなく、既存のパブリッククラウドのサービスを活かしてシステム基盤の調達を可能にするための枠組み、これをガバメントクラウドと呼んでいます。今までの政府や自治体のアプリケーション開発は基本的に全部どこかのデータセンターにサーバを設置して、その上でシステムを作ることがほとんどでしたが、やはりそれでは運用性が悪いとか費用対効果が悪いというのがあって、それをクラウドを使った現代的なものにシフトしていこうという試みがガバメントクラウドです。

ガバメントクラウドとして利用できるクラウドサービスはデジタル庁が認定します。認定されるにはデジタル庁から出ている技術要件を満たす必要があります。この技術要件が膨大で、私もさくらインターネットに入社してから資料を読みましたが、最初に一通り目を通すだけで3日かかりました。

内容を見ると、まず大項目が17あり、合計約300件の技術要件があって、これをすべて満たす必要があります。大項目には基本事項、コンピュート(サーバ)、ストレージ、データベース、サーバーレス・コンテナ、API、アプリケーション連携、データ分析、コードリリースなどがあります。要件はデジタル庁のサイトで公開されていて、誰でもダウンロードして見ることができます。

この技術要件から、重要度というよりも興味深いものという観点で抜粋して紹介します。

上記は基本事項です。最初の方は普通です。「外部からネットワーク経由で提供される情報サービスであり」とか、ちょっと硬い言葉でクラウドが何なのかを記述しています。「情報資産はユーザが指示しない限り日本国内に保管されること」などはガバメントクラウドらしい要件ですね。「日本国内のデータセンターで当該クラウドサービスを自らが3年以上運営していること」と書いてあるので、今からパブリッククラウドをやるぞと思って作り始めても3年経たないと応募すらできません。

さらに各機能の要件からいくつか紹介します。「オブジェクトストレージは、99.999999999%以上のデータ耐久性を持ち」と書いてありますが、これはAWSのS3のサービス紹介に書いてあるものと同じです。その次のメッセージングサービスの要件には「ユーザが構築するソフトウェア同士の連携を抽象化し非同期に行うためのメッセージングサービスが利用可能であること」とあり、これはメッセージキューを提供しろという話なのですが、その次の要件を見ると「ユーザが意識せずとも自動的に、概ね無制限にスケーリングすること」とあります。AWSのSQSというサービスの説明に「SQSは無制限にスケーリングします」という記述があり、それがそのまま持ち込まれているのではないかと思われる節があります。他にもCDNの要件には「CDNサービスはグローバル10拠点以上で利用できること」とあり、ガバメントクラウドをグローバルでそんなに使うのかという疑問も湧いてきますが、とにかく要件なのですべて満たす必要があるということです。

パブリッククラウドにおけるサービス、プロダクト

次に、パブリッククラウドにおけるサービスやプロダクトとは何なのかという話をします。

パブリッククラウドのサービスとしての特徴はいろいろありますが、大きな特徴としてはマルチテナント、オンデマンド、システム・オペレーションの構成部品であること、あとはフルスタックというあたりかと思います。これらについて順次見ていきます。

マルチテナント

マルチテナントというのは要するに、あらゆる業種業界の顧客がさくらのクラウドというパブリッククラウドのサービスに同居するということですね。クラウド自体は汎用のものなので、業種業界を選ばず、顧客層も非常に広く分布しています。

そして、クラウドの中にもいろいろなサービスがありますが、それぞれのサービスに多種多様な顧客が同居します。ユースケースとして例えば金融系や保険系や公共系とか、さらに教育とか医療とか、それこそガバメントみたいなものも同居してくるということですね。よって、非常に多様なユースケースがありますし、多様なワークロードがあります。ピーク時間帯もそれぞれ違いますし、ピーク期間も違います。年度末に集中するものもあれば、そうでない時に集中するものもあるという感じです。それから顧客からの要求も、使い方がそれぞれに違うので、それぞれ異なる要求を持つ顧客群ということになってきます。可用性、信頼性、セキュリティなどの各項目に対する要求が、それぞれの顧客ごと、あるいは顧客グループごとに異なることになります。

オンデマンド

パブリッククラウドにはオンデマンドという特性があります。24時間いつでもリクエストされたら即座にサービスを提供するということです。

これには2種類の観点があります。1つはIaaSとしてのものです。これは要するにVMやストレージなどのリソースを作ってくれという要求を受けて、それを即座にセットアップして顧客が使えるように提供します。一方、PaaSやSaaSみたいなものは24時間、常にオンラインで動き続けていて、顧客はそこにいつリクエストを送ってくるかわからないというものです。こちらは常にオンラインなので稼働のピークが一切読めないという性質があります。

システム・オペレーションの構成部品

それから、顧客がパブリッククラウドを使うときにそれ自体を単独のサービスで使うことはまずなく、すべて顧客のシステム、あるいは顧客のオペレーションの構成部品となるのが大きな特徴です。例えば顧客のシステムの動作基盤となるものは、VM、ストレージ、ネットワーク、ロードバランサ、CDNなどです。あるいは顧客がアプリケーションを書くときにそのアプリケーションのコードから呼ばれて、アプリケーションの一部となって組み込まれるというケースもあります。例えばデータベース、キュー、ワークフロー、API Gateway、シークレットマネージャなどです。さらに、顧客のオペレーションの実行基盤となるというケースもあります。例えばバッチ処理のオペレーションの基盤になったり、CI/CDやデプロイといったオペレーションの実行基盤となるものです。認証認可とかバックアップとか、コンテナリポジトリとかKMS(キーマネジメントシステム)みたいなものが、顧客のシステムやオペレーションの構成部品となっています。

フルスタック

最後にフルスタックの話です。データセンターからPaaS/SaaSまでということで下のレイヤーから話をしていくと、まずデータセンターを建てるところから始まるので、場所を探すとか、どうやって建物を作るかとか電気を引いてくるとか、あとは建物に対するセキュリティなどの話もあります。次は回線ですね。拠点間の接続をしたり、インターネットにどうやって接続するかという話です。その上に機器、つまりハードウェアが載ります。サーバー、ストレージ、スイッチ、ルーターなどです。さらにそのサーバの上に我々が開発した仮想化の基盤を乗せるわけです。仮想マシンやストレージやネットワークをすべて仮想化して、顧客が要求した時にリソースとして提供できるように基盤を整えます。

こうすると、アプリケーションを作る人はこのIaaSの仮想化基盤の上で開発することになりますが、最近はそうではなくさまざまなマネージドサービスを使ってアプリケーションを提供することが一般的になってきています。例えばコンテナをpushしてもらうと、それをそのまま実行してサービスを提供するような仕組みがあったりしますし、あるいはデータベースを我々がホストしてマネージドサービスとして提供し、顧客はDBを作ってくれとコントロールパネル上でクリックしたら後はDBに接続しに来るだけというのもあります。キューやワークフローやデータ分析基盤なども同様です。顧客がプラットフォームとして使うものを我々が提供するという形になっています。またSaaSもいろいろあります。セキュリティや認証のようにサービスとして提供するものもあったりします。

このように、拠点からSaaSまですべてを視野に入れてサービス設計、開発、運用をやっていく必要があるというのが、パブリッククラウドのサービスを提供するという話です。

クラウドの実装〜マネージドサービスとOSS〜

それでは、クラウドの実装におけるマネージドサービスとOSSの関係について話をしていきたいと思います。

さくらのクラウドで使われるOSS

上記はさくらのクラウドで使われているOSSを列挙したものです。こうして見ると非常にさまざまなところでOSSが使われています。さくらのクラウドは実装のコアに基本的にプロプライエタリのソフトウェアを使っていません。周辺システムにはなくはないのですが、サービスのコアを提供する部分に関してはすべてOSSをベースに我々が作ったもので提供しています。例えばLinuxのKVMを使って仮想化サーバ(VM)を提供していますし、仮想化されたネットワーク基盤やコンテナオーケストレーションみたいなことをするソフトウェアをあれこれ使っています。また、さまざまな内部システムを実装するのに、歴史的経緯からさまざまな言語を使っています。データベースも我々自身のサービスを提供するためにいろいろなものを使っています。

それから、さくらのクラウドはさまざまなAPIを提供していますが、これは当然ウェブアプリケーションとして作られていますので、そういったものを提供するためのNginxやApacheやDjangoとか、それからIceburgやTrinoといったデータ分析基盤のOSSも使っています。また、ユーザがコントロールパネルを操作して我々のクラウドサービスを使うので、フロントエンドのソフトウェアも使っています。あと、我々が環境のセットアップをするためにTerraformやAnsibleなどを使っています。

マネージドサービス

一方、マネージドサービスというものがあります。ソフトウェアと動作環境をセットにして、我々がすべてセットアップした上で、それを丸ごとサービスとして提供するという類のものです。ソフトウェアのマネジメントを我々が行っているサービスの提供みたいな意味合いですね。

代表的なマネージドサービスとしてはデータベースがあります。さくらのクラウドではMariaDB、PostgreSQL、それから最近リリースされたCassandraを提供しています。これらのRDBやNoSQLのサービスをどうやって使うかというと、ユーザはデータベースへのコネクタを自分が開発しているアプリケーションに組み込んで接続しに来ることになります。これはソフトウェアは基本的にそのままで、それを我々が運用できる形にパッケージングし直して顧客に提供するというものになっていて、かなり直接的にOSSがサービスとして露出しているという例になります。

その一方で現在開発中のモニタリングサービスもあって、これはVictoriaMetricsやOpenTelemetry Loggingなどを使っているんですが、これはどちらかというと体験としてのモニタリングというユースケースを実現して提供するというパッケージングになっていて、ソフトウェアがそのまま露出しているというよりは、こういうプロトコルでデータを送ってくれればあとは我々の方でよしなにやっておきますよというような意味合いが強いものになっています。これはOSSが直接露出しているわけではありませんが、裏側でOSSを使っていて、我々はそれを隠しているわけではありません。

それからパブリッククラウドでは開発や運用系のエコシステムツールチェインを丸ごと抱えているという事象がおそらくほとんどのパブリッククラウドで起きていて、我々もその道に進もうとしています。CI/CDやコンテナのオーケストレーション、あるいは環境のセットアップそのものをやるためのツールと環境を我々自身がホストするという意味で、GitやコンテナレジストリやIaCツールなどを我々自身がマネジメントしてサービスとして提供するという方向になっています。

OSSの体験をクラウドへ

ところで、私はさくらのクラウドのプロダクトマネージャーとして働いています。プロダクトマネージャーは、どういう仕様のプロダクトになっていればシステム開発者の皆さんにサービスを使っていただけるかを考える役職です。それを考えるときに単に機能やソフトウェアを提供すればよいという話ではなく、自分が大事だと思っていることの一つに「OSSの体験をクラウドに持っていく」ことが重要ではないかと考えています。

皆さんもシステム開発をするときにさまざまなOSSを使うと思いますが、よく使われるOSSはすごくよくできていて、あまり不愉快な思いをしないというか、不愉快な思いをするようなソフトウェアからはみんな離れていくので、よく使われているものはやはり手触りや体験がよくできているものが多いと思います。

この「OSSの良い体験」とは具体的には何か？を考えてみたのが上のスライドです。例えばわかりやすいドキュメントがあって、それを読めば最初にやりたいと思った一歩ぐらいは迷わずにできるとかですね。必要十分な機能がそろっていることはもちろんですが、機能が多すぎないことも大事です。機能が多すぎると逆に何をやったらいいのかわからなくなって使うのが面倒になります。あとはAPIに納得感があることですね。今どきXMLRPCでAPIをたたいてくださいと言われてもちょっと待ってよという気分になります。それから既存のOSSとの親和性も大事です。多くの人が使っているソフトウェアと一緒に組み合わせて使えるのは非常に重要だと思います。

これらをまとめると「使ってみた時になんとなく期待したように動く」ものをユーザは期待してるのではないかと考えていて、これを要求仕様に落とし込むのが非常に難しいというのが今の自分の感覚です。

技術主権とOSS

話が変わりますが、技術主権とOSSという話をします。これは簡単に言うと、我々が自分たちの責任で技術を選定して開発して運用するという話です。

テック系メディアなどを読んでいると最近ときどき出てくるのが「ソブリンクラウド」という言葉です。sovereigntyという単語があって、これは日本語では「主権」という意味です。クラウドの開発という観点で重要なのが技術主権という考え方で、OSSを中心とした技術スタックを我々自身が責任を持って選んで使うということです。例えば他社のソフトウェアを使っていて、そのソフトウェアの決定権を他社が握っているとすると、他社の決定に我々のクラウドの未来が左右されてしまいます。このような我々に主権がない状態にならないようにするために、技術主権という考え方が非常に重要です。安定したサービスを我々の顧客に提供するためにも、技術主権を重要視するというのが我々の選択です。

クラウドのオープンソースSDK

続いて、クラウドのオープンソースSDKについての話をします。

フルスタッククラウドと顧客システム

フルスタックのクラウドにはスタックがいろいろあるという話を先ほどしましたが、それと顧客システムの関係は非常に難しいというか、クラウドと顧客のシステムはものすごく密接に絡み合う関係にあります。

上図の一番左側が一番単純な例で、下からデータセンターとネットワークがあってハードウェアがあり、その上に仮想化の基盤があって、その上にLinuxがあります。このあたりまでをクラウドが提供するインフラと考えることができます(図で黒く塗られているのがインフラ)。そのLinux上で我々の顧客がアプリケーションを書いてデプロイして実行します。ただし現代ではデータベースはマネージドサービスを使うことが多いので、上図では緑色になっています。それから、アプリケーションを実行するときにおそらく2台以上のアプリケーションサーバを使うと思うので、そうするとロードバランサが必要になってきます。これもほとんどの顧客は我々が提供するマネージドサービスのロードバランサを使います。位置的にはサーバサイドのアプリケーションの上にロードバランサが乗ります。ロードバランサの上には顧客が書いたフロントエンド、例えばアプリケーションやJavaScriptで書かれたクライアントサイドのコードが設置されます。これが一番単純な例です。

さらにもっといろいろなサービスが入ってくる例がその右側です。ロードバランサの横にオブジェクトストレージがあり、APIゲートウェイがあって、CDNが挟まって静的コンテンツの配信環境があり、その上にUIやクライアントがあるようなケースですね。

また別のパターンがさらにその右側にあります。最近はコンテナランタイムの上でコンテナを用いてアプリケーションをホストするケースが多いです。Linuxの上にコンテナランタイムがあってアプリケーションがあるという構成になります。それから、マネージドサービスの上に非同期のバッチ処理システムやタスクの処理システムを作ろうと思うと、我々が持っているマネージドなワークフローのサービスがコンテナのランタイム上で動くアプリケーションを呼び出す形になったり、それがさらにキューに対してメッセージを投げ、そのメッセージをコンテナランタイム上にあるアプリケーションが取り出してさまざまなワークロードをこなすことになります。

このように考えると、顧客のシステムやアプリケーションと我々のマネージドサービスとの接点はあらゆるところに存在します。上のスライドのオレンジで塗ってあるところが顧客のアプリケーションと我々のマネージドサービスの接点になります。

この接点になっているところに何があるかというと、マネージドサービスを使うためのSDKがあります。あるいはクライアントライブラリと言ってもよいでしょう。クライアントライブラリとSDKの定義は人によっていろいろあると思いますが、今回の話の中での定義としては、クライアントライブラリはアプリケーションとマネージドサービスの接点です。特定のクラウドサービスを呼び出すためのライブラリですね。一般的には各言語向けのライブラリ実装があります。SDKはもう少し広い概念で、クライアントライブラリを含むクラウド環境を整えるためのツールキットを指しているように思います。クライアントライブラリ以外の要素としては、例えばリソースの制御や設定変更をコマンドラインのインターフェースで実行するCLIのツールとか、Terraform Providerのように環境設定を行うツール、それからCI/CDを行うためのツールなどが含まれます。

OSSとしてのSDK

このSDKは、私が知る限り例外なくOSSです。なぜかというと、顧客のアプリケーションやシステムの一部として動くことが宿命付けられているからです。例えばクライアントライブラリは顧客が開発するアプリケーションから呼び出されて動くので、この時にライセンスが面倒なものを使っていると問題になることがあります。よって、そういった危険性のないライセンスを選択してOSSとして提供するのがパブリッククラウドサービスにおけるSDKの大前提になります。あとは顧客のコードの振る舞いを邪魔しない挙動をすることも大切です。例えばメモリやCPUを大量に消費するとか変な副作用を起こすようなことをしてはいけません。

それから、SDKは顧客の運用の一部になります。たとえば環境をデプロイするとか、バックアップ、モニタリング、アラート、バッチ処理などさまざまな制御に使われます。よって顧客にとって透明性の高いものである方が良いので、そういう意味でもOSSにするというのは非常に理にかなった話です。

その一方で、OSSなのでGitHubなどに置いておくのですが、OSSだからissueを立てたりpull-requestを送ったりできるのでは？という発想が当然ながら浮かんできます。SDKに不満があることも普通にあるでしょう。例えばバグがあるとか、挙動に不満があるとか、オプションが足りないとかですね。あとはクラウド側でこの機能が実装されているはずなのにまだSDKではサポートされていないといったケースもあり得ます。

ここでクラウドサービスを提供する我々の視点で考えると、issueを立てられたり、あるいはpull-requestを送られた時にどう対応すべきかはかなり難しい問題です。例えばクライアントライブラリが10並列のリクエストを送ることしかサポートしていないとして、これを1000万並列にしてほしいと言われても、そのリクエストを受ける我々が困ってしまいます。こういったこともあって完全に公平なOSSにはなり得ません。しかしユーザにそっぽを向けられるのも困るので、そうならないように、極めて繊細な判断が求められることになります。

OSS、クラウドSDK、そしてマネージドサービス

最後にクラウドSDKとマネージドサービスの関係についてお話しします。

隙間家具OSS

今年(2025年)の2月に藤原さん(@fujiwara)がさくらインターネットに入社したのですが、彼のインタビュー記事を作る中でいい話を聞いたので、本人の許可を得て引用します。

これは何年も前から藤原さんが言っている言葉ですが「隙間家具OSS」というものがあります。これは何かというと、まずクラウドサービスが出しているマネージドサービスの間には隙間があります。小さめの機能でリリースして、それから成長していくので、どうしてもサービス間の連携機能などが後回しになって隙間ができてしまうのです。この隙間を埋めるためのソフトウェアを自作して使うと運用がすごくよく回るようになり、ハッピーな、自分たちが楽になるサービス運用ができるという話を藤原さんがされています。これを藤原さんが発明した言葉で「隙間家具OSS」と呼んでいます。隙間家具はすごく小さいものなので、サービス事業者がマネージドサービスを提供してきて要らなくなったら取り外します。そういう小さくて取り外し可能なものにしてサービスを維持するという話です。詳しくは藤原さんのスライドを見てください。

隙間はどこに生まれるか

この話を受けて、隙間はどこに生まれるのかを自分なりに考えてみたのが上の図です。

まず一番左の例は、そもそもサービスに機能が足りていない感じで隙間ができるパターンです。自分たちはアプリケーションを乗せる時にぴったりこれに合うものが欲しいと思っているけれども、マネージドサービスの方に機能がなくて隙間があるという話ですね。次のパターンは、サービスBとCはそれぞれ単独で使えばぴったりしているのに、BとCを組み合わせて使うとBに足りないところが見えてくるというものです。その次はDとEのパターンで、これは連携して動いてもらってその上に我々のアプリケーションを載せたいが、なぜか連携してくれないというものです。一番右のパターンは一番左と少し似ていますが、アプリ開発者の視点ではこうなっていてほしいと思っているがサービス側が提供していないというケースです。

隙間家具OSSとクラウド開発

この話題を藤原さんがしたときに出てきた話があって、そもそもサービスというものは、不満があって使いづらいようなところはない方がいいのです。でもクラウドを利用する側にいると不満は出るもので、そこで要望を上げることはできますが、要望の通りに直されるかというとなかなかそうはいきません。しかし藤原さんはさくらインターネットに入り、さくらのクラウドについては自分で直せる立場になったので、直すべきところは直せばいいしそうしていきたいという話をされていました。

ただ、全員にとって使いやすいサービスを作るのはやはり無理があります。なぜかというと、前にも説明したように好みやユースケースが千差万別なので、ユーザそれぞれにとっての隙間は依然として存在するからです。そこをそれぞれのユーザが小さいツールで埋めることは普通にこれからも起きるでしょう、という話をされていました。

何を、どこで、どうやって直す？

先ほども説明した通り、OSSがあり、その上にマネージドサービスがあって、その接点を埋めるSDKみたいなものがありますが、何か問題があった時に、何をどこでどうやって直すかはソフトウェア設計のすごく難しくて面白いところだと思います。ソフトウェアエンジニアとしてのセンスと経験の見せ所です。

我々はクラウドサービスのプロバイダなのでサービスで直すことももちろんできます。しかしサービスで直すことになると、それは本当にあらゆるユースケース、あらゆるワークロードのユーザに対して影響するので、本当にユーザ全員にとってプラスになることかを常に考える必要があります。

一方、SDKで直すことももちろんできます。特定のユースケースや特定のワークロードだけをカバーするようにSDKやクライアントライブラリを直すこともできなくはありません。しかしその一方で、OSSとしてのあり方にものすごく変な歪みを持ち込んでしまう可能性があります。ですので、それは本当にそのライブラリにとって有益かを考える必要があります。

別の考え方として、我々が特定用途のOSSを新たに開発して提供するということも選択肢としてはあるかもしれません。しかしこの場合は、それが本当に運用性を改善するかを考える必要があります。新しいツールを一つ導入することは必ず運用性に複雑さをもたらすので、それが本当に良いことなのか、トータルでプラスになるのかは常に考える必要があります。

このようなことは我々だけでなくおそらくすべてのソフトウェアエンジニアが常に考える必要があるのですが、クラウドを作る側にいると、どこで直すこともできます。選択肢が広くて便利で楽しいです。これまで説明してきたようにパブリッククラウドの開発はものすごく多様なところでOSSと関わっていますので、OSSとの関わり方の一つの選択肢として、パブリッククラウドの開発という仕事が世の中にはあるという話です。

社会を支えるパブリッククラウドを一緒に作りませんか？

というわけで最後に、社会を支えるパブリッククラウドや大規模計算資源インフラを一緒に作りませんか？という話です。最初の方に話しましたがさくらインターネットはフルスタックということで、エンジニア採用のウェブサイトを見ると、データセンターを作るところも募集していますし、そこからソフトウェアスタックをだんだん登っていってソフトウェアのAPIサービスを作るとかクラウドSDKを作るといったところもあります。私が担当しているプロダクトマネージャーの募集もあります。本当に上から下まで、コンピュータサイエンスを全面的にカバーするようにポジションが並んでいますので、興味がありましたらぜひご覧ください。

おわりに：編集部より

今回の発表の資料や映像が公開されていますので、さらに詳しく知りたい方はご覧ください。