Google の SRE 本で「原則」の部の最後に置かれているのは、SLO やトイル、リリースエンジニアリングの章に続く「Simplicity」という短い章です。
章の冒頭には、C.A.R. ホーアがチューリング賞講演で語った「信頼性の代償は、極限までの単純さの追求である」という言葉が掲げられています。
章の全文は、2026年9月時点で Google の公式サイトの Simplicity（Site Reliability Engineering 第9章） で読めます。
設計レビューで「その機能は本当に要るのか」と問う理由を言葉にしたい人には、この章と姉妹編の SRE Workbook にある同名の章が答えになります。
私も SRE を学んでいる途中なので、以下は二つの章の原文を読んで理解した範囲の整理です。
複雑さには、減らせるものと減らせないものがある
SRE 本は、ソフトウェアはもともと変化し続ける不安定なものだという前提から話を始めます。
コードもライブラリも利用者数も凍結すれば完全に安定しますが、それは真空の中でしか成り立ちません。
そこで SRE の仕事は、変化の速さと安定性のバランスを取ることだと書かれています。
その上で章は、ソフトウェアに限っては「退屈」が長所になると述べています。
本番環境での驚きこそが SRE の宿敵で、プログラムには台本どおりの予測できる動きをしてほしいからです。
退屈な技術を選ぶという考え方は、Tech Lead の技術選定の記事で詳しく扱いました。
複雑さを見分ける道具として章が引くのが、フレッド・ブルックスが1986年に書いたエッセイ「No Silver Bullet」の区別です。
本質的な複雑さは問題の定義そのものに含まれていて取り除けないもので、偶有的な複雑さは工学的な努力で解消できるものを指します。
章の例では、Web ページを速く返すことが Web サーバーの本質的な複雑さとされています。
一方で、Java で書いたためにガベージコレクションの影響を抑える工夫が要るなら、それは偶有的な複雑さにあたります。
SRE チームに求められているのは、偶有的な複雑さが持ち込まれたら押し返し、引き受けたシステムからは取り除き続けることの二つです。
書いたコードは1行ごとに負担になる
SRE 本は、24時間止められない Web サービスで考えると、新しく書いたコードの1行1行がある意味で負担になるとまで書いています。
追加や変更した行はどれも、新しい不具合を持ち込む可能性があるからです。
小さなプロジェクトほど理解しやすく、テストしやすく、不具合も少ない傾向があります。
機能が増え続けてソフトウェアが遅く大きくなる傾向は「ソフトウェアの肥大化」と呼ばれ、章は新機能を足したくなったときこそ一度ためらうよう勧めています。
「負のコード行数」という見出しの節では、著者が不要になったコードを一度に何千行も消した作業を、いちばん満足したコーディングの一つに挙げています。
消すことへの抵抗として章が挙げるのは、「後で要るかもしれない」「コメントアウトしておけば戻せる」「消さずにフラグで止めておけばいい」の三つです。
章はこれらをどれもひどい提案だと退けています。
ソース管理があれば変更は簡単に戻せますし、何百行ものコメントアウトはファイルが変わり続けるほど読む人を混乱させます。
そして、常に無効のフラグの裏で眠るコードは、いつ爆発するか分からない時限爆弾にたとえられています。
その実例として挙がっているのが、2012年8月1日に米国の証券会社 Knight Capital で起きた事故です。
米国証券取引委員会（SEC）の命令書によると、同社は何年も前に使わなくなった「Power Peg」という機能のコードを、呼び出せる状態のまま残していました。
新機能のコードはかつて Power Peg を起動していたフラグを流用しており、8台のサーバーのうち1台にだけ新しいコードが配られていませんでした。
そのサーバーでは流用したフラグが古いコードを起動し、約45分で154銘柄に400万回を超える約定が発生しました。
同社はこの間に抱えた意図しない持ち高で、4億6,000万ドルを超える損失を出しています。
SEC の発表は SEC Charges Knight Capital With Violations of Market Access Rule で読めます。
フラグを作るときに消す段取りまで決めておく運用は、リリース戦略の記事で扱いました。
同じ考え方は API にも当てはまります。
章は「付け足すものがなくなったときではなく、取り去るものがなくなったときに完璧になる」というサン＝テグジュペリの言葉を引いています。
API が小さいほうがよいのは、メソッドや引数が少ないほど理解しやすく、残したメソッドを磨くことに力を注げるからです。
小さく単純な API は、問題がよく理解されていることの表れでもあると章は書いています。
リリースも同じで、無関係な変更を100個まとめて出して性能が落ちると、どれが原因かを突き止めるのに大きな手間がかかります。
小さな単位で出せば変更を一つずつ切り分けて理解できるので、かえって速く、自信を持って進められるというのが章の考え方です。
複雑さを測り、減らす仕事に時間を割く
Workbook の章は、単純なソフトウェアほど壊れにくく、壊れても速く直せるとして、シンプルさと信頼性の強い結び付きから話を始めます。
こちらも公式サイトの Simplicity（The Site Reliability Workbook 第7章） で読めます。
コードの単位なら、分岐やループによる実行経路の数を数える循環的複雑度がよく知られていて、分岐もループもないコードの値は1です。
一方でシステム全体の複雑さを測る正式な方法はほとんどなく、Workbook は代わりの目安を五つ挙げています。
- 新しいメンバーがオンコールに入れるようになるまでの時間
- システムの全体像を新しいメンバーに説明し終えるまでの時間
- 似た設定をする方法がシステムの中に何通りあるか
- 本番に出ているバイナリ・バージョン・フラグ・環境の組み合わせが何通りあるか
- システムの年齢
Workbook は、複雑さのコストは持ち込んだ本人ではなく後からそこで働く人が払うとして、経済学でいう外部性にたとえています。
だからこそシステム全体のシンプルさを守る担い手が要り、システムを丸ごと見る SRE がその役に向いているというのが Workbook の主張です。
具体的な手として勧められているのが、システムの構成図を描くことです。
図にすると、何段にも重なったリトライで呼び出しが掛け算で増える「増幅」や、回り回って自分自身に依存する「循環依存」が見つかります。
Google の本番環境の名前解決サービス pDNS は間接的に自分自身に依存しており、全体を一から起動し直せない状態だったと紹介されています。
重要な依存先が増えるほど可用性の上限が下がる話は、可用性の数字の記事で扱いました。
減らす仕事は、放っておいても誰かが片付けてくれるものではありません。
Workbook は、単純化のプロジェクトを機能のリリースと同じように扱い、コードの追加と削除を同じように評価して称えるよう求めています。
Google の社内サイトでは、大量のコードを消したエンジニアに「Zombie Code Slayer」というバッジが表示されると紹介されています。
時間の確保については、たとえばエンジニアリングの時間の10%を単純化のプロジェクトに充てる案が示されています。
シンプルにしようとしてはまる落とし穴
シンプルさを目指したつもりで、かえって複雑さを増やしてしまう例も Workbook には載っています。
一つ目は、汎用的すぎる API です。
章の著者の一人が以前いたスタートアップでは、あらゆる RPC がキーと値を詰めた「袋」を受け取って返す設計で、中核のライブラリは単純で柔軟でした。
ところが、サービスごとにどのキーが入るかはほとんど文書化されず、引数を足したり変えたりするたびに互換性を保つのも難しくなりました。
Protocol Buffers のような型のあるデータ形式は、一見すると汎用の袋より複雑に見えます。
それでも設計と文書化を先に強いるぶん、端から端まで見ると単純になるというのが Workbook の結論です。
単純さは部品ごとに測るものではなく、使う側まで含めた全体で測る必要があります。
二つ目は、絡まったシステムを新しく書き直せば単純になるという期待です。
Google はコンテナ管理の基盤 Borg の後継として、より整理された Omega を作ろうとしました。
しかし開発中も Borg は進化し続け、Omega は動く標的を追いかける形になりました。
数千のサービスにまたがる数百万行の設定を移すのがどれほど手間と時間を食うかも、甘く見ていたと Workbook は振り返っています。
最終的に Google は Omega の考え方の一部を Borg に取り込み、多くを Kubernetes の立ち上げに生かしています。
Workbook は、書き直しの成果を今のシステムと比べず、同じ労力で今のシステムを改善した場合の姿と比べるよう勧めています。
漸進的な改善と全面的な書き直しの分かれ目は、アーキテクチャの進化戦略の記事で詳しく扱いました。
三つ目は、単純化のための時間枠を、残りの時間で複雑さを足してよい許可と取り違えることです。
10%の枠は単純化に向けた努力の取り置きで、残り90%で複雑さを足してよいという意味ではないと Workbook は注記しています。
最後に
SRE 本と Workbook を通して読むと、シンプルさは好みの問題として扱われておらず、信頼性の前提に置かれていました。
偶有的な複雑さを押し返し、使われないコードを消し、減らす仕事を足す仕事と同じように評価することが、その具体的な形です。
SRE 本の章は、機能に「ノー」と言うのはイノベーションを縛るためでなく、気が散るものを環境から除いて本当の工学に集中するためだと結んでいます。
同じ考え方は監視の設計にも出てきて、SRE 本は監視のルールも単純で予測できるものにするよう求めています。
次に機能や設定を足したくなったら、それが本質的な複雑さか偶有的な複雑さかを一度問い直すと、判断の軸がぶれにくくなります。
以上です。
コメントを残す