はじめに
プロダクト基盤本部 SREの藤原です。
heyにおけるSREの大切さ~マルチプロダクト運用の「楽しさ」と「難しさ」および今後の展望~と題してSRE NEXT 2022に登壇しました。
本エントリはその報告と補足説明です。
セッションでは、SREとは何かというところから始まり、heyにおけるSREの楽しさについて述べました。次に成長し続けるプロダクトと組織において、直面するであろう困難について解説しました。最後に困難の部分に向き合うにあたって、どのような活動や取組を進めていきたいかを述べました。
本エントリでは、セッションのスライドと内容を一部振り返りつつ、補足として取り組みの副作用と向き合い方(案)を述べています。
SREってなに？
まず、SREではなくプロダクト開発組織の目的を考えてみましょう。プロダクト開発組織は、顧客に対してあたらしい価値、より高い価値を提供することを主目的としています。つまり、サービスへの機能追加や改善がミッションと言えます。一方でSREがプロダクト固有の機能実装を担うことは多くありません。*1
一方でSREが果たす役割を考えてみます。SREはサイトの信頼性をソフトウェアエンジニアリングと自動化を用いて維持、改善することをミッションとします。ここで述べている信頼性は厳密な信頼性というよりは、非機能品質を表していると考えてください。
SREはリリースエンジニアリングや、システムのアーキテクチャ設計、本番環境の運用改善などに主に取り組みます。もう少し具体的な取り組み内容を説明します。
リリースエンジニアリングでは、SREはプロダクト開発者が実装した機能(≒価値)を、迅速かつ安全にサービスの利用者に届けるための仕組みをプロダクト開発者と協力して構築します。ビルド、テストのための継続的インテグレーション、本番環境に確実に成果物を届けるための継続的デプロイ・デリバリーの仕組みが主な成果物です。場合によっては、ビルド、テスト、デプロイの容易性を高めるためにSREがプロダクトのコードに手を入れることもあります。セッション中では、新たな価値提供に向けたリリースエンジニアリング支援の事例としてSTORES決済におけるインフラストラクチャのリアーキテクチャリング事例を解説しました(事例の詳細はこちらです)。
システムのアーキテクチャ設計は主に構築フェーズでSREが取り組む内容です。プロダクト開発者と議論しながらシステムの可用性や性能、デプロイ容易性などに配慮したアーキテクチャを組み上げます。運用改善は運用フェーズでSREが取り組む内容です。システムを運用していく中で運用観点での継続的な改善に取り組みます。具体的には監視・モニタリング指標の選定やそれら指標の変化に伴う各種対応を担います。
これらの活動は2つに分類でき、これらを実現することがSREのロールと言えます。1つがリリースエンジニアリングを介してプロダクト開発者が創出した価値を届けるための支援(価値提供の支援)です。もう1つが、アーキテクチャ設計や運用改善を通じて提供している価値が毀損されないようにすること(提供価値の維持)です。
つまり、SREとはなにかと聞かれたら、プロダクトにおける価値提供の支援と提供価値の維持を担うロールと言えます。
SREとしての組織成長との向き合い方
プロダクトと組織の成長はビジネスの成功を示すものです。一方でプロダクトと組織の成長に伴って発生する課題も存在します。システム構成やコミュニケーションの複雑化です。これらを放置し続けると、下図のように、エンジニアリング的な創出価値が組織規模に対して逓減してしまいます。このような状況下で、SREが役割を果たす上での困難さを考えてみましょう。
プロダクト組織で実装された機能が利用者に届くには機能をリリースできなければいけません。リリースプロセス構築を主に担うのはSREです。しかし、現時点(2022年)ではSREは採用難易度が特に高いと言われており、組織の規模の拡大と比較してSRE組織の規模拡大は小さなものになるでしょう。
このような条件下では、SREはプロダクトの状況(事業戦略やプロダクトの非機能観点での状態)にあわせてプロダクト横断的に動くことが必要です*2。つまり、SREは少ない人数で複雑化、肥大化し続けるシステムと対峙しなければいけません。SREの絶対数が少ない前提を置いた上で、プロダクト横断で動きやすくするには、どのような方法があるでしょうか。次のような方策が挙げられます。
- 必要となる前提知識の削減(標準化)
- 複雑な内容に耐えられる知識・スキルの習得(教育・自己研鑽)
- 外部のプロフェッショナル人材(外部ナレッジ)の活用
個々の方策を解説していきましょう。
最初に、標準化による前提知識の削減です。プロダクト横断で構成を同じようなものとすることで、必要となる前提知識(≒認知負荷)の総量を減らします。構成が揃っていない場合と比較して、ある程度構成が揃っている場合は、プロダクトAのSREが一時的にプロダクトBの活動に従事するといったことが容易になります。
SREが主に関わる領域はドメイン固有の事情に影響されない領域のエンジニアリングが多く、標準化は進めやすい側面があります。(同様の内容をゲストで参加したSREはソフトウェアコードの再利用性、モジュールの共通化部分に正面切って取り組める【#3 論より動くもの.fm】でも最後に述べています。)SREが関わる領域は、標準化の難易度が相対的に低いこと、SRE自身が標準のメリットを享受できること、プロダクト開発者はSREの介在によって価値創出と改善に注力できます。SREが中心となって関連する部分の標準化を推し進めることは、一定の合理性があるでしょう。
次に知識・スキルの習得です。非常にシンプルな内容で認知負荷が大きくなってもここのエンジニアが耐えられるようにするという単純明快な方策です。基礎的な技術力は高いに越したことはありません。着実に実践的なスキルを習得できるよう、組織的に支援します。これまでの活動例としては、社内外での勉強会、研修参加を通じたナレッジ、スキル習得を会社として支援したり*3、AWSやGCPのサンドボックス環境を提供し、個々のエンジニアが自由に試行錯誤できるようにするといった取り組みがこれに当たります。
最後に外部のプロフェッショナル人材の活用です。 可能であれば内部ですべて済ませてしまいたいという欲求はあるでしょう。しかし、高いスキル、知識が必要かつ、重要な事象でありながらも、組織的にナレッジを蓄積できない程度には低頻度な事象は存在します。また、人に尋ねることですぐに解決策がわかる課題も存在します。このような場合は外部ナレッジを活用したほうが最終的により多くかつ意味のある課題の解決にSREが注力できるでしょう。
(補足)標準化の副作用への対応
組織、プロダクトの拡大にともなう課題への対応として、
- 標準化によって認知負荷を下げる
- トレーニングを通じてより高い認知負荷に耐えられるようにする
- 内部で体系化できない程度に低頻度かつ重要な事象などについては外部のプロフェッショナルに頼る
を挙げました。セッション中では触れていませんが、上記から標準化の副作用にどう取り組むかといった部分を取り上げておきたいと思います。
SREは基本的に人数が少なく、標準化によって認知負荷を下げたいというニーズが高いこと、関わる領域的に標準化を進めやすいことについては先に述べました。次に課題となるのが、仮に標準化がうまくいった場合に、どう変化に対応し続けられるようにするかという部分です。
標準化によって知識の深化は進みます。標準化がうまくはまった場合は特に強烈に進みます。一方でうまくいった標準化とそれに伴う知識の深化はサクセストラップのリスクを呼び込み、環境の大きな変化に対応しきれないリスクが大きくなります。そのような事態を避けるためにも知識の探索に組織として取り組むことが必要です。
この課題に私は具体的な答えが出せていません*4。【#3 論より動くもの.fm】にもあるように"「新しい技術を入れていくことOps」みたいな世界"をどう実現していくかを考えなければいけません。現時点で言えるのは、銀の弾丸は存在せず丁寧な取り組みをしていくことは必要であろうということです。個々のプロダクトやエンジニアがチャレンジする内容とKPIを明確にした上で効果を測定することが重要そうです。その上で標準の追加、変更として取り込むのか、取り込まないのかを判断していくことなどが重要だろうと考えています。
最後に
ここまで読んでいただきありがとうございます。
SRE x 組織の拡大という大きなテーマについて、ここまで明確な形では整理していませんでした。あたらめて自身の取り組みや考えを振り返る機会を与えていただいたSRE NEXT 2022の運営チームの方には感謝しています。
また、セッションに登壇しないかと社内で声をかけてくださったCTO室の上杉さん、各種資料のチェックや撮影機材の準備、動画の編集をしてくれたPXの方々にもお礼申し上げます。本当にありがとうございました。
この記事の公開当日(2022/6/15)に、SREに関連したイベント(【スタンバイ× hey】急成長スタートアップSREのリアル)を開催します。 筆者もスピーカーとして参加予定です。視聴者からのQAも開催予定なのでこの記事に関連した質問などもいただいた場合は出来る限り回答いたします。
*1:仮にプロダクトの機能を実装している場合は、プロダクト開発者を兼務しているとした方が適切でしょう。
*2:または、SREを配置するプロダクトと配置しないプロダクトを選ぶパターンもあります。規模の極端に小さいかつ、プロダクトとしての継続性が保証されていないMVP版のプロダクトなどの場合はSREを置かないといったものです。
*3:ビジネス部門の事例ですが、公開事例としてはビジネス部門のメンバーがProgateで3ヶ月間プログラミング研修を受けてみたがあります。
*4:つい先日、@t_wadaさんに質とスピードについて社内講演いただきました。その際に、知識の探索について質問したところ、学びとその組織への還元を人事評価に反映したりといった形で学びを組織的に支援する仕組みがあっても良いのではないかとのコメントをいただきました。組織として推進したいことであればそれは評価に組み込むべきというのは確かに本筋としての取り組み方だと思います。
