自動化における制約をガイドとして捉える

自動化の価値は単なる作業の省力化だけではありません。自動化が利用者にとってじゅうぶんに効果的であるとき、その自動化がもつ合理的な制約が、システム全体に対してまた別の価値をもたらすことがあります。

DBインポートツールの制約がシステム構成の標準化を促す

最近、私の同僚が、技術支援を担当している顧客向けに本番データベースから開発環境にデータを取り込むDBインポートツールを開発しました。本番データを抽出し、機密情報をマスキングしたうえで、開発環境にデータを投入する一連の作業を自動化したものです。この作業は元々SREチームが開発チームからの依頼を受けて手動で実施しており、依頼ごとの作業負担が大きいことが問題になっていました。

DBインポートツールの導入後、ツールの利用方法に関する興味深いやり取りがおきました。

きっかけは、開発チームから「DBインポートツールで、本番データを開発環境にあるEC2インスタンス内のMySQLにリストアしたい」という依頼がきたことですが、SREチームは、保守性の観点からこの依頼への対応は見送るべきだと考えていました。DBインポートツールは複製先としてマネージドサービス（RDS/Aurora）を前提にして開発したものです。EC2インスタンス内のMySQLへのリストアをサポートするにはツールの改修が必要ですが、一方でこれは例外的な構成なので、積極的にサポートすることは避けたかったためです。

そこでSREチームは、依頼に対してこのような提案をしました。「DBインポートツールを利用できるように、EC2インスタンス内のMySQLをRDSに移行してもらえませんか」

注目したいのは、この提案がSREチームと開発チームの双方にとってメリットがある内容になっていることです。SREチームは、例外的な構成をサポートするためのツール改修をする必要がなくなり、またシステムを標準的な構成に移行できます。開発チームは、移行に取り組むことでDBインポートツールが使えるようになり、従来SREチームに依頼する必要があった作業をセルフサービスで実施できるようになります。

この出来事は、以前読んだあるブログを連想させました。

自動リファクタリングシステムの制約がコードベースの品質向上を促す（Spotifyの事例）

Spotifyのブログ記事『Fleet Management at Spotify (Part 3): Fleet-wide Refactoring』で紹介されていた事例です。このブログ記事は、Spotifyが抱える何千ものコンポーネント（Fleet: 艦隊）をいかに効率よく管理しているかを紹介するブログシリーズのひとつで、Fleet全体に対する横断的なリファクタリング（Fleet-wide Refactoring）を効果的に行うための仕組みを紹介しています。

Fleet-wide Refactoringの中核を担うのは、任意のリファクタリングをFleet全体にプルリクエストとして展開したうえで自動マージする仕組みです。

注目したいのは、自動マージを有効にするためには、対象のコードベースでテストが十分に整備されていることが条件となることです。これは不適切な変更の混入を防ぐためにプラットフォーム側がかけた制約ですが、同時にコンポーネントの所有チームが自律的にコードベースの品質を改善する強力なインセンティブとしても機能しています。コードベースの品質を改善することで、Fleet-wide Refactoringの恩恵（自動マージによる省力化）を最大限に享受できるためです。

自動化の制約がシステムを望ましい方向に誘導するガイドになる

システムや組織の規模は大きく異なる事例ですが、どちらも自動化がもつ制約がシステム全体を望ましい方向に誘導する役割を担っていたと捉えられます。自動化が利用者にとってじゅうぶん効果的な仕組みであったため、利用者は制約を受け入れる動機がありました。また、その制約はシステムの観点で合理的なものでした。その結果、人々が制約を受け入れることはシステム全体を望ましい方向に向かわせることになりました。

もちろんあらゆるケースでうまくいくようなことではありません。自動化のメリットよりも制約を受け入れるコストが上回る場合には、利用者が制約を受け入れるインセンティブが生まれず、自動化の導入が見送られるでしょう。

制約をシステムを望ましい方向に誘導するガイドとして捉え直し、ガイドが機能するバランスを見極めることが、自動化戦略において重要なひとつの要素になります。