DevOpsにおける3つのアンチパターンと対処法とは：IaC、シフトレフト、コンウェイの法則をキーワードに

　マニュエル・パイス氏とマシュー・スケルトン氏は著書『Team Topologies』の中で、このアンチパターンを2つの例で説明している。

• DevOpsチームが成熟し、首尾よく機能していたものの、社内で「構成管理、モニタリング、デプロイ戦略といった個別の知識をひとくくりにし始める」（同書）
• クラウドチームで「Infrastructure as Code」（IaC）が、従来のインフラチームと同じプロセスやコミュニケーションチャネルのもと運用されている。「クラウドチームが単に現在の行動やインフラプロセスを模倣すると、社内ではこれまでと同様に、ソフトウェアデリバリーの遅延やボトルネックが発生する」（同書）

　このDevOpsアンチパターンに対処する戦略の一つは、クラウドネイティブ戦略における「状態を維持する」宣言型のアプローチを活用することだ。DevOpsのCI/CD（継続的インテグレーション／継続的デリバリー）パイプラインを「コードとして」記述できれば、パイプラインは、プルリクエストやバージョン履歴といったGitHubの中核機能を活用できる。また、インナーソース、監督、変更提案が可能であるというチーム内の認識、プルリクエストによるコラボレーションといった恩恵も受けられる。

　DevOpsチームはこの戦略により、イノベーションのボトルネックと見なされることなく、DevOpsの強化に向けて社内に活動を広く展開できるオープンソースコミュニティーを構築できる。

アンチパターン2：不十分なシフトレフト

　「シフトレフト」は業界の流行語になっているが、DevOpsとクラウドネイティブの実現に向けた重要な取り組みでもある。これは、「頻度が難易度を下げる」というDevOpsパターンに関連している。セキュリティテストやガバナンス施策が困難な場合は、できるだけシフトレフトを行い、できるだけ早い段階でCIプロセスの一部として自動化することが望ましい。

　逆に、セキュリティ対策、テスト、ガバナンス施策の実行頻度が低く、デリバリーパイプラインの最後で行われる場合は、DevOpsのアンチパターンが発生する恐れがある。実行がより難しくなり、生産性が低下するためだ。

　セキュリティ対策を早期に実施する方法の一つは、非営利団体「The Open Web Application Security Project」（OWASP）が選定する「OWASP Top Ten」（Webアプリケーションの重大なセキュリティリスクのトップ10）の軽減を、GitHubワークフローで直接実施することだ。

　幾つかの方法を使えば、手動のセキュリティプロセスを自動プロセスに置き換えることができる。これらのプロセスは簡単に拡張でき、そのフローの中で開発者の活動を継続させることができる。

　一方、手作業の比重が高いテストがバリューストリーム（価値の創造から顧客への提供までの流れ）の遅い段階で行われる場合、自動化されたエンドツーエンドのCI/CDパイプラインを作成する価値はほとんどない。単体テストを正しく、あるいは完全に実装しなければ、将来の変更で、リリース前には決して発見されない回帰バグが、いずれは紛れ込むことになる。

　テストを本当にシフトレフトするには、テストツールとGitHub内のコードを統合する必要がある。テストツールとGitHubの統合は、疎結合に基づいていなければならない。

　ガバナンスのレフトシフトは、必ずしもよく理解されていない。だが、ガバナンス、監査可能性、職務の分離、責任の共有が、DevOpsパイプラインの外部の事柄として扱われている場合、チームのバリューフローは、社内の他の部分とやりとりし始めると、急停止してしまうかもしれない。

　まず、前述したOWASP Top Tenのセキュリティリスクの軽減のような対策から着手するとよい。次に、NIST（米国国立標準技術研究所）サイバーセキュリティフレームワーク（Cyber Security Framework：CSF）のような一般的なフレームワークを参照し、プルリクエストによるコードレビューなど、既存のGitHubワークフローに対策をマッピングしていく。

アンチパターン3：ツールの進化に組織が追い付いていない

　これはDevOpsのアンチパターンの中で、最も診断と対処が難しいが、正しく理解することが最も重要なものだ。DevOpsによる多くの変革は、チームがフローの中で快適に働くことの重要性を考慮せず、ツールに焦点を当てているからだ。

　組織が優れたツールを使っていても、チーム体制が昔のウオーターフォール時代から旧態依然のままなら、責任の所在が不明確になってしまうかもしれない。そうなれば、意思決定がうまくいかず、他人の立場に不必要に干渉してしまうこともある。

　このアンチパターンに対処する戦略の一つは、チームにおけるコミュニケーションチャンネルの重要性を認識することだ。「コンウェイの法則」がその参考になる。この法則は基本的に、「ソフトウェアシステムのアーキテクチャは、それを構築した開発チームの組織とそっくりになる」というものだ。つまり、チームがサイロ化した複雑な多層構造で組織され、コミュニケーションを取っていれば、開発したシステムもサイロ化し、多層構造になってしまう。そのために、サイロ化され、過度に複雑で、最適化されていないDevOpsパイプラインを使用する羽目になることもある。

　人間優先のアプローチを取れば、必要なコミュニケーションパターンをより最適化された方法でDevOpsパイプラインに組み込める。例えば、セキュリティチームと開発チームがオープンソースの依存関係についてコミュニケーションを取る必要がある場合「Dependabot」とプルリクエストを使用して、コミュニケーションチャネルを最適化できる。

　もう1つの戦略は、チームの生産性と幸福度を測定する方法を見つけ、チームがフローにとどまることができない場合に、行動できるようにすることだ。

　GitHubでは、開発者の生産性を測定し、開発者の幸福と満足度を確保するために、生産性フレームワーク「SPACE」を使用している。このフレームワークを適用することで、DevOpsパイプラインにとって重要な幾つかの領域（効率やフローなど）を測定できる。

　SPACEを活用すれば、特定のプロセスにおけるハンドオフの数を明らかにし、幾つのチームが関与したかを確認できる。また、労力を削減し、チームの幸福度を向上させ、パイプラインを最適化することもできる。