DevOps時代における運用側の二つ目の役割は、リリース直前への参画だ。もちろん、プロジェクト終了間際の運用テストや受け入れテストに、運用側が参加することはあるだろう。ここでいう参画とは、それよりももっと深くリリース直前に入り込むことを指している。
さくら情報システムでは、運用部門20人から成るCAB（Change Advisory Board：変更諮問委員会）がある。ここに参加する高橋徳光氏（コソーシング本部 業務第2部 決済業務第1グループ 部長）と佐藤多喜江氏（コソーシング本部 業務第1部 第2グループ 給与計算チーム リーダー）らは、リリース直前の“関所”として、チェックリストに基づく運用品質の確保に努めている。
「運用品質が低いままリリースされると、運用部門への負担が大きい。これを水際で食い止めるのがチェックリストの役割」と高橋氏は説明する。CABチェックリストは全155項目から成り、すべての項目をクリアしないと、決してリリースできないという強制力を持つ。
こうしたチェックリストを活用し、リリース直前に品質確認している運用部門は多いかもしれない。だが高橋氏らが活用するチェックリストは、リリース直前だけでなく、要件定義や設計フェーズまで対象にしているのが特徴だ（図1）。
これは、総合テストや運用テストといったリリース直前の品質を検証する工程の成果物やプロセスが、要件定義や設計といった品質を作り込む上流工程の成果物やプロセスと“対”になっていると判断するためだ。「品質を作り込む上流工程を同時にチェックしてこそ、リリース直前のチェックの有効性が保証される」と、高橋氏は説明する。
チェックリストの活用で問題になりやすいのは、確認作業の負担である。だが高橋氏らは「1～2時間という限られた中で、Yes/Noとすぐに判断できるチェック項目にした」ことで負担を軽くしている。
さらに、CABチェックリストを事前に開発側に渡しておけば、各工程で運用品質の考慮漏れを防ぐための設計観点にもなるという。
