アジャイルの世界におけるコンプライアンスとは

コンプライアンスとは、自分が正しいことをしていること、そして、それを証明できることだ。アジャイルの頻繁なデリバリでは、デリバリプロセス内にコンプライアンスを構築することが必要になる。コンプライアンス義務をDevOpsチームの責務の一部とすることで、その成功の可能性を高めることができる。

Atlassianのリスク未来学者(futurist)であるGuy Herbert氏は、Atlassian Summit Europe 2018で、アジャイルの世界におけるコンプライアンスのあり方について講演した。InfoQではこのイベントについて、Q&Aや要約，記事を通じて紹介している。

すべての組織は何らかの規制的な義務を負っている、とHerbert氏は言う。製品を販売すれば、それに伴うルールが存在する。顧客情報を保有して、それを取引する可能性があるならば、そこにもルールが存在する。Herbert氏は、コンプライアンスとは正しいことをしているという確証のあること、正しいことをしていると知っていること、それを問われた時に証明できることだ、と述べている。

コンプライアンスをデリバリプロセスの中に構築しなければならない、とHerbert氏は主張する。更新が6ヶ月に1回であった過去の時代には、デリバリ直前に“後付けする”ことも可能だったかも知れないが、1日に複数回デリバリしようという現在では、最後になって追加するような手段は存在しないのだ。

頻繁かつ迅速なデリバリにおけるコンプライアンスの確保、DevOpsがコンプライアンスのニーズを解決する方法、既存のコンプライアンスシステムをよりアジャイルにする方法について、Herbert氏と話をした。

InfoQ: 頻繁で迅速なデリバリにおいて、コンプライアンスを確保するにはどうすればよいのでしょうか？

Guy Herbert: 私たちAtlassianでは、リスクとコンプライアンスがデリバリの一部であることを、チームに理解させています。私たちが何をしようとしているのかを伝えて、彼らの作業におけるリスクとコンプライアンスを理解してもらうのです。当社では、変更管理の主要な手段としてピアレビューを使って、ビルド前にテストに合格することを確実にしています。

アジャイル開発チームの大部分は、ピアレビューとテストを使用しています。この方法は、コードに品質を持たせる上で非常に優れているのですが、さらに当社独自の方法として、システムにBitbucketを使うことでピアレビューとテストのパスを義務化しています。

変更はチームに任せていますが、彼らがすべきことは同時に伝えています – 最小限の要件を変更したい場合には報告が必要だが、最小限の要件を満たしたい場合の報告は不要である、といったものです。

その上で、6ヶ月毎に、必要性を合意したコントロール(ユーザ管理や変更管理のプロセスなど)が実施できていることを確認します。私たちが出向いて、直接チェックする場合もあります。自動化可能なコントロール(自動化されたユーザのプロビジョニングや削除など)については、頻繁に確認する必要はなく、適切な設定が行われていることのみチェックします。

InfoQ: コンプライアンスの要件を解決する上で、DevOpsはどのように役立つのでしょう？

Herbert: 一般的なDevOpsには、数多くの遵守義務があります – リスク&コンプライアンスチームには、それらをブレークダウンして、開発や運用の業務を行なっている人たちの作業を可能にすると同時に、その義務を果たすことができるようにすることが求められます。

その一例が変更管理です。変更管理では、コンプライアンス義務の大部分が、コントロールされた変更管理環境に依存しています。この環境を一度実装すれば、すべての義務において利用することができます。つまり、義務ごとに異なる変更管理コントロールを用意する必要はありません。これは簡単な例ですが、他にもたくさんあります。リスクとコンプライアンスは、チームにこれらを課す方法によって、簡単にも、あるいは難しくもなります。

また、DevOpsチームは、エンゲージメントやオーナシップの面で上位レベルにあるので、コンプライアンス義務を自分たちの所有物の一部とすることで、コンプライアンスの成功する可能性を高めることができます。

InfoQ: 既存のコンプライアンスシステムをよりアジャイルにするためには、何ができるのでしょうか？

Herbert: 各チームがどのようなコンプライアンス義務をサポートしているかをよく理解し、彼らがそういった義務にではなく、それをコントロールする行為に集中できるようにすれば、彼らはいつでも必要な時に変化を遂げられるようになります。それによってチームは、実行すべきコントロールアクティビティを理解します – そうなれば、その経験を新たなチームに移行したり、リスク・コンプライアンス担当チームとコントロールアクティビティを変更する可能性について話し合うこともできるようになります。

Atlassianでは、チームが実行するコントロール行動と、組織が実行しなければならないコンプライアンス義務との間に抽象レイヤを形成する、というコントロールの目標について話し合っています。これが実現すれば、デリバリチームは個々のコンプライアンス義務ではなく、自分たちの業務に集中できるようになります。

リスク・コンプライアンス担当チームは、他のチームがコンプライアンス義務をよりよい方法で果たす方法を模索すべきだと思っています。他のチームがすでに実施していることの上で何かを実行するのではなく、彼らがすでに行なっていることで、コンプライアンスに利用可能なものはありませんか？ピアレビューやグリーンビルドはそのよい例になります。