ClearBankの成長に伴い、拡大する業務を管理し規制コンプライアンスを確保するためにより構造化されたプロセスを統合しながら、革新的な文化を維持するという課題に直面した。説明責任と責任の範囲内で、チームには自分たちの領域を発展させるためのスペースを与えられ、少しずつ革新し、実験し、継続的に改善しながら、イノベーティブであり続けることができた。
Michael Gray氏は、QCon LondonでClearBankのスタートアップからスケールアップまでの道のりについて語った。
ClearBankは分離したQA機能、セキュリティ、オペレーションがあるソフトウェア・デリバリープロセスの古典的なハンドオフの過程を経験した、とGray氏は語った。QAを例にとると、ソフトウェアは品質保証に引き渡され、その後発見された不具合のリストとともに戻され、欠陥修正された後、再度テストのためにQAに戻された。このような引き渡しはすべてシステム内の無駄であり、持続可能なフローの障害になっていた、と彼は指摘した。
Grayは現在では誰もがエンジニアであると同時にQAであると説明した、ソフトウェアを開発しているチームが品質に対しても責任を持つ。彼らはQA機能を維持しているが、彼らの役割はソフトウェア・デリバリーチームへの継続的なコーチングとスキルアップ、プラットフォームQA能力のメンテナンス、特定の質問についてソフトウェア・デリバリーチームにアドバイスすることだ：
私たちはこの方法でソフトウェアの品質と持続可能なスピードの両方が大幅に向上することを発見しました。これによりチームのフィードバックループが短く頻繁に保たれ、より迅速に調整することが可能になります。
エンド・ツー・エンドのオーナーシップが直接的で迅速なフィードバックループにつながる、とGray氏は述べた。品質の低さの影響をより早く実感するチームは、ソフトウェアがより高い基準を満たすことを確実化することにより誇りを持つようになる；リリースが遅いことに痛みを感じているチームは、遅いリリースを修正するために何かをする可能性が高くなる、と彼は説明した：
これは継続的に改善するための彼らのスペースが確保されている場合にのみ当てはまります。もしそうでなければこのエンド・ツー・エンドのオーナーシップは人々を燃え尽きさせる早道になってしまいます。
Gray氏は、彼らは常に自律性とプロセスのバランスを取ろうと努めており、統制的なプロセスより可能性を広げる制約を提供するプロセスを好むと述べた。これによりチームに悪影響を与えたり邪魔したりするのではなく、彼らのプロセス内で彼らを助けるような意思決定を下すことができる。
組織が成長するにつれて、プロセスや管理、オーバーヘッドをどんどん増やすのは自然な傾向だが、現在のプロセスが機能しているかどうかを見直し、不要になったプロセスや管理を削除することはほとんどない、とGray氏は言う。私たちはプロセスや管理を厳格に見直し、それらが依然として効果的で、邪魔や無駄なオーバーヘッドを生み出すのではなく銀行にとってポジティブな成果をもたらしているかを確認するよう最善を尽くしている、と彼は述べた。
Gray氏はローカライズされた意思決定を可能にするために戦略を3つの主要レベルで伝えていると説明した。
1.ビジネス戦略
2.それを支える製品戦略
3.ビジネスと製品の両方を支える技術戦略
戦略が組織全体で明確に理解されることを担保することで、人々がより多くの情報に基づいた意思決定を行えるようになる、と彼は述べた。
Gray氏は、スケールアップしながらイノベーティブな文化を維持するための2つの側面を挙げた：
ビジョンとミッションを明確に伝えること、および整合性と方向性を確保するためのサポート戦略
戦略に沿っている限り、人々が実験するためのスペースをシステム内に確保すること
多くの組織が犯す間違いは組織を、絶対的な納期予測でチーム時間の100%を締めるような、非常に厳格な成果物/説明責任を持つ機械に変えようとすることだ、とGray氏は言う。私たち全員が私たちの境界線と自分たちの責任／説明責任についてよく理解しているべきだが、ソフトウェア構築とデリバリーは同じものを繰り返し何度も製造することではないし、複雑なシステムを進化させることでもない、それはそれよりもずっと微妙なものだ：
組織を「よく手入れされた機械」に変えようとするとすぐに惰性が生じ、同じようなことを続けもはや改善もイノベートもしなくなります。
InfoQはMichael Gray氏にスケールアップしながらイノベーティブであり続けることについてインタビューした。
InfoQ: プロセスがレビューされ、効果的でなくなった場合は変更または削除されるだろうと言及されていましたが、いくつか例を挙げていただけますか？
Michael Gray氏: 一つの例は、私たちの継続的に進化する開発とリリースのプロセスです。これは私たちが「このプロセスのこのステップはまだ必要で価値を産み出しているか？」といった質問をしながら作業を継続的にレビューしている、テクノロジーに大きく左右されるプロセスです。
もう一つの例は、ソフトウェアのセキュリティレビューの方法です。以前はチームのメンバーが、すべてのソフトウェアリリースをセキュリティの観点からレビューすることを意味する「セキュリティレビュアー」になる必要がありました。私たちはこれをツールで自動化し、ソフトウェアが最低限のセキュリティ基準を満たしていれば自動化によって自動的に承認されるようにしました。現在、すべてのエンジニアがソフトウェアをレビューできるよう、最低限のセキュリティトレーニングを受ける必要があります。これによりソフトウェアをリリースするチームのボトルネックがなくなり、すべてのエンジニアの最低限のセキュリティ意識が向上し、自動化によってプロセスの抵抗が取り除かれ、DORAメトリクスがさらに改善されました。
InfoQ: Clearbankでは、ローカライズされた意思決定をどのようにサポートしていますか？
Gray氏: 意思決定スコープの概念を導入しました。私たちにはエンタープライズ、ドメイン、チームがあります。人々が問うべきことは、この決定は誰に影響するか？です。チームだけに影響する場合は決定を下し、ADR（アーキテクチャ決定記録）を書いて進めます。ドメイン内の他のチームに影響する場合は会話し、合意に達するか達しないか－いずれにせよその結果をADRに記録します。広範囲に影響を及ぼすようなエンタープライズ意思決定については、アーキテクチャーアドバイザリーフォーラムがあります。