「安定性重視の運用チーム」と「機能提供重視の開発チーム」が仲良くできる変更管理の方法：“変更管理”が“変更防止”にならないために

Excelon Developmentのマット・ホイサー氏はWebメディア「TechTarget」にてアプリケ―ションの変更管理について解説した。DevOpsでせっかく連携した運用チームと開発チームが分断しないようにするには何に気を付ければいいのか。

[Matt Heusser，TechTarget]

　Excelon Developmentのマット・ホイサー氏は2020年2月7日、Webメディア「TechTarget」にてアプリケ―ション（以下、アプリ）の変更管理について解説した。

　ソフトウェアエンジニアリングにおいて変更管理とは障害を防ぐための施策で、開発チームがアプリやシステムに変更を加える場合、事前に承認を要求するものだ。だが、この仕組みは“安定性を重視する運用チーム”と“機能を提供することに重きを置く開発チーム”とで対立構造を発生させる可能性がある。

　「組織が運用チームに安定性だけに集中することを義務付けると、“変更管理”はたちまち“変更防止”になり、継続的に更新して新機能を提供することを義務付けられている開発チームが不満を抱くことになる。せっかくDevOpsを導入し、伝統的なITデリバリーモデルから脱却したのに、変更管理はこれまで通りでいいのだろうか」とホイサー氏は投げ掛ける。

その変更管理は本当に有効か

　ホイサー氏は「DevOpsの世界」でも有効な変更管理の方法について幾つかのポイントを挙げる。

何が省略できるかを決める

　一部の低リスクな変更は、形式的な承認プロセスを通す必要がないと判断できる。ホイサー氏によると、多くのDevOpsプロセスは、自動的なロールバックや機能の制御を通じてリスクを減少させることに重点を置いて設計されているという。「変更内容の記録が残されていればデバッグと修正のプロセスが簡単になり、変更管理が不要になる」とホイサー氏は述べている。

　ただし、高リスクな変更については依然として正式な管理が必要だ。「SQLスキーマの移行はどうなっているか」「WebサーバやOSのメジャーアップデートはどうなっているか」「アプリストアを経由しなければならないモバイルアプリに加えられた変更についてはどうするか」「個人情報や財務情報に影響するコードについてはどうか」といった懸念がチームから頻発する場合は従来の厳密な変更管理が必要になるだろう。

責任と権限を結び付ける

　運用チームと開発チームの連携が重要だ。アプリの変更管理のマイナス面は、事態がうまくいかないときに矢面に立たされるのが運用チームだということだ。そうした変更管理の否定的な側面を排除するために、変更を担うチームがその影響に対処する責任を持つようにするといいだろう。

権限ではなく通知を優先する

　開発チームによる変更を、運用チームが一定期間（数時間から数日）確認できるシステムを開発することで、問題が発生したときの解決までの時間を大幅に短縮できる可能性がある。

フィーチャーフラグを活用する

　全ての機能にフィーチャーフラグの仕組みを組み込み、リスクを最小限に抑えながら機能を展開する方法も有効だ。フィーチャーフラグとは機能（変更）のオンとオフを簡単に切り替えられるフラグのこと。これによって「ダークローンチ」という、変更管理を必要としないテストを導入できるようになる。

　ただし、過信は厳禁だ。条件付きのフィーチャーフラグに誤りがあると、本来は公開してはいけない変更を本番環境にデプロイしてしまう可能性がある。また、それを簡単には元に戻せなくなることもあり得る。

変更管理の影響範囲を把握し、分離させる

　変更管理がほぼ全ての関係者に影響するような場合、大規模な回帰テスト、トリアージミーティング、文書化など煩雑なプロセスが必要になる。これはコストの増加とスケジュールの遅延を招く要因になる。これを取り除くために、変更に関連する影響を受けるのは変更を担う責任者（チーム）だけに限定するようにする。そのため、そのチームは変更に関するプロセスを自身で構築する必要がある。

---

　ホイサー氏は「変更管理の面でまだ理想的な状態に達していない企業にとっては、特定の種類の変更に関して徐々に古い管理プロセスを段階的に廃止してみるといいだろう。これらの小さな遷移は、より良い全体的な変更管理システムへと導く小さな勝利だ」と述べている。