巨大クラウドの負債と属人化の解消に挑む。インフラ技術者集団・さくらインターネットの現在地【開発者体験向上Lab】

2023年秋、さくらインターネット社が提供する「さくらのクラウド」がガバメントクラウドに条件付きで認定されました。2025年度末までに技術要件を満たす前提での「条件付き認定」とはいえ、国産サービスでは初の認定というニュースに、業界は大いに盛り上がりました。

そんなさくらインターネットの「開発者体験」を解き明かすべく、同社のエンジニアに取材を申し込んだところ、「2025年度末までのガバメントクラウド認定に挑戦するにあたって、『いつかやろう』とずっと先延ばしにしてきた巨大な課題と向き合うことにした」と語ります。

ガバメントクラウドとして本格的な認定を目指す「さくらのクラウド」を支えるエンジニアたちは、今どんな課題にどう向き合っているのでしょうか。事前に実施した同社エンジニア15名へのアンケート調査の結果を見ながら、クラウド事業本部・バックエンドチームの野村孔命さんと、SRE室の山本和道さんに話を聞きました。

• keyboard_arrow_down 先延ばしにしてきた「技術的負債」「属人化」と向き合うことに
• keyboard_arrow_down 巨大サービスの負債解消を着実にやりきるために、あえてスケジュールは引かない
• keyboard_arrow_down 「職人芸の共有」による属人化の解消を目指す
• keyboard_arrow_down 最新ツール導入のハードルはセキュリティとのバランス
• keyboard_arrow_down 高い心理的安全性を支える「信頼感の貯金」
• keyboard_arrow_down 「良い開発者体験」とは、リリースまでの障壁が少ないこと

——今日はよろしくお願いします。まず、今回のアンケート結果を「バックエンドチーム」「SRE室」の順に見てみましょう。

——結果を見た感想はいかがですか？

野村：「あぁ、そうだよね」と納得しました。

山本：普段の体感と近く、特にギャップは感じませんね。

野村：「成長できる環境」や「心理的安全性」の高さは予想通りですが、実際に数字として表れると嬉しいですね。一方で点数が低い「技術的負債の解消」と「最適なアーキテクチャ」はまさに今、解決に向けて取り組んでいる大きな課題です。

山本：いま、我々が直面している課題は、大きく分けて「サービスの安定性をさらに高めるための技術的負債の解消」と「スケールを見据えた属人化の解消」の2つ。これらの課題は以前からずっと認識していて、「見直さなくちゃ」と話していました。しかし顧客のコアデータを預かるサービスだからこそ、目の前のトラブル対応を優先せざるを得ず、つい先延ばしにしてしまっていました。ガバメントクラウドにも認定され、国を支えるインフラとして、このままではいけない。そうした危機感から、課題の解決に向けて動き出したのです。

——課題について詳しく聞く前に、さくらインターネットの開発組織の体制と、お二人の担当業務について教えてください。

野村：私が所属するクラウド事業本部のバックエンドチームは、約20名のエンジニアが4～5人ずつ4つの小チームに分かれて活動しています。私は、クラウドのコアAPIの改修やイベントログ機能の開発などを行う「クラウドAPI開発チーム」と、ホストサーバやストレージサーバなどクラウドの物理リソースを扱うためのシステムの開発を行う「IaaS基盤開発チーム」に所属しています。

ほかには、新規サービスの開発を中心に行う「ガンマ」、課金周りやデータベースのアプライアンスなどを開発する「ベータ」と呼ばれるチームがあります。

山本：私は、約1年前に発足した、クラウド事業本部のSRE室に所属しています。メンバーは6人で、開発やチーム運営の支援を行ったり、開発基盤の提供などに取り組んだりしています。また、将来的にSLIやSLOを用いたプロダクト運営をするためにオープンテレメトリー対応を進めたり、試験的にスクラムでのチーム運営をしたりもしています。担当領域は人によって違いますが、私自身は「オートスケール」など既存プロダクトやOSSの開発運用、およびベータチームの開発支援を担当しています。

——先ほど挙げていた、今直面しているという「技術的負債の解消」「属人化の脱却」という2つの課題について、順を追ってお聞きしていきます。お話のとおり、バックエンドチームにおいて「技術的負債の解消」の点数が低く出ていますね。

野村：さくらのクラウドは約12年前に誕生したサービスで、これまでにさまざまな機能追加や改修がなされてきました。その間にクラウド上で扱うリソースが増えたり、世の中の技術が発展したりして、当初は最適な設計だと思ってつくっていたアーキテクチャも、必然的に「今の“最適”」とは程遠い姿になってしまっています。

野村：開発当初からひたすら書き連ねられてきたコードは、いまや何がどうなっているのか把握するにも一苦労です。もっと変更容易性の高いコードに整える必要があります。たとえば仮想サーバーを作成するためのスクリプトが、Perlで書かれていて。これをいまGoで書き直していく取り組みを少しずつ進めています。

——具体的にはどのように負債解消を進めているのでしょうか。

野村：メンバーに担当領域を割り振ったうえで、「①調査・現状把握」「②週1の定例MTGで調査結果を報告、返済方針を検討・決定」「③タスク化し実施」のステップをSRE室と一緒に繰り返しながら少しずつ進めています。

サービス全体の負債解消において、「いつまでに何を」といったスケジュールは、あえて立てていません。

というのも、「さくらのクラウド」はものすごく巨大なアプリケーションで、細かいところまでプロダクトのすべてを把握することは困難です。であれば、できるところから少しずつ進めるほうが速いし確実だと考えています。

こうした状況を、僕も今まさに楽しみながら苦しんでいる最中なので、アンケートでも「技術的負債」や「アーキテクチャ」の点数が低く出たのも納得でしたね。

——もう一つの課題として「属人化」を挙げていましたが、どんな取り組みを行っていますか。

野村：アンケートのコメントにもあったとおり、属人化と技術的負債解消のための取り組みとして、「ドキュメントの整備と自動化」を進めています。

クラウドサービスの開発は、ミドルウェアに関してかなりマニアックで深い知識が必要なので、どうしても属人化しやすいんです。これまでは「こういうタスクが来たらこの人」と、その属人化をうまく利用して高速に開発を進めてきました。しかし今後、チームをスケールさせてもっと高速にサービスを改善しようと思うと、個人の職人芸だけに頼り続けるわけにはいきません。知識をいち個人に留めるのではなく、チームの知識として蓄積・共有していくために、ドキュメント化が重要なんです。

山本：とはいえ、開発に関わるメンバー1人ひとりに深い知識が求められるからこそ、メンバー自身も成長を実感しやすいという面もあります。そうした良い点をなくしてしまうのはもったいない。職人芸は活かしつつ、職人の持つ深い知識をあらゆるメンバーと共有できるような環境を整えていきたいですね。

野村：あと、ドキュメントの仕組みづくりにおいて、「こういうときはこれを書く」など厳格にルールは定めていません。

「さくらのクラウド」は顧客の事業にまつわるコアデータを預かるサービスだからこそ、緊急度や重要度が非常に高い対応案件が差し込んで入ることがよくあります。こうした案件に素早く対応しきるためには、どうしてもドキュメント化の優先順位を下げざるを得ない場合もある。そうした状況でドキュメント化を無理に強制すれば、対応速度が落ちて顧客に不利益を発生させかねませんし、エンジニアにとってもストレスです。

ルールを決めて強制する代わりに、エンジニアの皆さんが自ら動いてもらえるよう、意識レベルの底上げに取り組んでいます。「この挙動はイシューに記録し、これは逐一ログを残してください。後でこのような障害が起こった時にこう役立ちます」と、残すべきドキュメントとその意義をうるさいくらいに伝えています。緊急度が高い案件を確実に素早く解決しながら、対応後に必ず自主的にドキュメントを残せるチームになれるよう、地道に取り組んでいるところです。

——SRE室は、具体的にどんな役割を担っているのでしょうか。

山本：SRE室の役割は、開発をスムーズに進められるように基盤を整えることと、そうした取り組みによってサービスの品質や信頼性向上に貢献することです。

たとえば、開発チームが担当領域の開発に集中してスムーズに開発を進められるよう、ドキュメント作成の自動化はもちろん、CI/CDの改善全般もSRE室が担っています。GitHub Actionsを使ってリソースの構築ができる機能を提供し、バックエンドチームをはじめ、E2Eのテスト基盤、Dependabotを使用したサプライチェーンリスクの管理の基盤などにも活用してもらっています。ほかにも、Kubernetesクラスタ基盤やメトリクス収集基盤といったプラットフォームの整備や、IaC（Infrastructure as Code）によるインフラ構築の自動化などにも取り組んでいます。

私個人はベータチームの開発支援を担当しているのですが、担当チームの最近の取り組みをSRE室でも共有し、共通化できるものがあれば、SRE室主導で共通基盤をつくって広く展開したりもしています。

——SRE室のアンケート結果では「最新のツール」の導入に関して点数が低くなっています。これはなぜでしょうか。

山本：お客様のインフラを預かるクラウドには、非常に高いセキュリティレベルが求められるので、外部のツール導入のハードルはどうしても上がります。ガバメントクラウドに採択された今はなおさらそうですね。ISMSやPマーク、SOC2、ISMAPなども取得しており、ツールを導入する際にはこれらの基準を満たす必要もあります。求められるセキュリティレベルと利便性や導入効果のバランスをいかにとるかが、開発ツール導入の難しさだといえます。

特に、社内の承認プロセスがツール導入のボトルネックになり、導入まで時間がかかっているのも事実で、それがアンケート結果に表れているのでしょう。そのため直近では、承認プロセスのスリム化に取り組んでいます。たとえば、承認プロセスの中で手動で行っていた「特権アクセスの動きを監視するためのデータ収集」を自動化するなど、承認までの時間をより短く、手間をより少なくすることで、今よりもスムーズにツール導入の検討を進められるようにしています。

——アンケートでは、バックエンドチームもSRE室も共通して、「心理的安全」の点数が高いですね。

野村：フルリモートだからこそ、組織が健全に機能し価値ある開発を続けるためには、心理的安全性が命綱です。こうして良い結果を出せてほっとしています。

高い心理的安全性を保ち続けるには、「信頼感の貯金」が必要だと思うんです。お互いの考え方や価値観、人となりを伝え合う感情ベースのやりとりがあってこそ信頼感の貯金が貯まる。それによって、事実ベースで無機質な業務上のやりとりなど、貯金を消費するような会話も齟齬なくできるようになるんだと思います。

フルリモートだと、お互いの顔が常に見えるわけではありません。ただ毎日業務をこなして、信頼の貯金を切り崩していくだけでは「この人はどんな人で、何を考えているのか」が分からなくなっていき、やりとりに緊張や変な深読みが生まれてしまいます。その結果、遠慮したり、発言するのを躊躇したりするようになり、業務をうまく進められなくなってしまう。

こうした「貯金の使い切り」を防ぐために、私たちのチームでは、週1で雑談会をしたり、雑談ベースでゆるくペアプロをする時間をとったりして、貯金を貯めています。緊急性の高くないお客様からの問い合わせ対応の際には、原因特定から解決までペアプロ形式で一緒に取り組むこともあります。

そうやって地道に貯金を貯めておくと、シビアな話でも素直に意見を伝え合えます。それに、開発で困ったときSlackで「助けて」と声を上げれば、みんなが「大丈夫？」と助けにきてくれます。こうした雰囲気が「心理的安全性が高い」というアンケート結果につながっているのかなと思います。

山本：そもそも当社が掲げているバリューが心理的安全性の下地になっているのではないかと思います。「肯定ファースト」「伝わるまで話そう」「リード＆フォロー」の3つのバリューは、どれもコミュニケーションに言及しています。コミュニケーションの重要性を理解しているメンバーが集まっているからこそ、「高い心理的安全性」を当社の文化として築いていけているのかもしれませんね。

——お二人は「良い開発者体験」とはどのようなものだと考えていますか？

野村：「開発からリリースまでの障壁の少なさ」だと考えています。

ここでいう障壁は、「技術的障壁」と「コミュニケーションの障壁」の2つを指しています。技術的障壁が少ないというのは、開発プロセスが整備され、テストやデプロイが簡単にできる環境がある、また、必要な人が必要なサーバーに入れるとか、コードの可読性が高くて改修時の認知負荷が低いといったことが挙げられます。こうした環境を整える取り組みは、開発組織内で完結できます。

しかし、コミュニケーションの障壁を、開発組織内の取り組みだけで取り除くことは難しいです。他組織の関係者やステークホルダーと関わりながら開発を進める以上、異なる専門性を持つ関係者同士のコミュニケーションの障壁を取り払うスキルを、メンバー1人ひとりが身につけていくこともまた、良い開発者体験をつくるために必要な要素です。

山本：今後、開発組織がもっと大きくなっていくにあたって、組織の成果を計測し視覚化する必要が生じるでしょう。「技術的障壁」の解消に取り組むSRE室の成果を測る手段のひとつとして、「開発者体験」の計測が挙げられると思います。

ただ、会社として「開発組織の成果」を定義するならば、必然的にそれは「ビジネスとしての成果」となるでしょう。「ビジネスとしての開発組織の成果」を正しく計測し、改善できる体制をつくっていくことがSRE室の役割であり、よりよいサービスをより高い信頼性で届ける開発者のチャレンジをサポートできると考えています。

取材・執筆：古屋恵美子
編集：光松瞳・王雨舟