IT業界が成長するにつれて、さまざまなツールや技術が登場し、ソフトウェアの生態系はさらに動的に変化しています。 産業とビジネスは、それに合わせてより迅速に変化します。 IT組織は成長するにつれて、分裂と統合を繰り返し、さらに複雑になります。 このような変化の中で、ソフトウェアはMSAとともに小さな単位に分離され、変化するチームによって主を失い、snowflake serverのような状態になってしまいます。
[Googleエンジニアはこう言う]では、成長する組織のためにはチームメンバー一人一人が常に離れることができる状態(Always Be Leaving)を維持しなければならないそうです。 [チームトポロジ]では、テック組織は周期的に6ヶ月~12ヶ月以内に人員を変更しなければならないと述べています。 戦術的な方法なので、このように聞くと手が届かないかもしれませんが、戦略的にこれらの行為は結局、「組織構成員の変更がビジネスに影響を及ぼさない状態を維持する」という共通の目標が見えてきます。 組織構成員の何人が問題になったときにビジネスに影響が出るかについての指標であるBus Factorというものも存在します。
ソフトウェアを開発する人材が変更されても、ソフトウェアの生産性に影響がないようにするには何が必要でしょうか？ まず、人材が変更された時に開発者の生産性が低くなる理由を簡単に考えてみると、変更された人員が担当ソフトウェアに対する知識が既存の人材より少ないためです。 それなら、私たちは意識的にこれらを減らすことができるようにしなければなりません。 ソフトウェア開発に必要な知識を単純に羅列してみると、次のようなものがあると思います。
- ソフトウェアが解決しようとしている問題のドメイン
- ソフトウェアを測定できる指標（技術的であれ、ビジネスの成長であれ）
- ソフトウェアを構成している技術的基盤（言語、フレームワーク、データベース、インフラなど）
上記の内容のうち、ドメインに関する知識を除いては「一貫性」を守ることができる項目です。 ビジネス指標の場合は、ソフトウェアごとに重要視するものが異なる場合がありますが、最小限の一貫したガードレール指標は生成して管理することができます。 技術的な指標の場合、ほとんどのソフトウェアが速度と安定性、最近ではDevOps DORAなどの指標を重要視するでしょう。 最後に、ソフトウェアを構成している技術的な基盤は、テックに関連するガバナンス組織によって管理できます。
それでは、各チームが開発しているソフトウェアは、上記の項目の一貫性をどのように維持させることができますか？ まず、開発者は通常、コードレビューを通じて担当ソフトウェアの一貫性を守ろうとします。 しかし、コードレビューはレビューアーの個人的な力量と状況に非常に依存的な行為で、もしビジネス日程が急迫してレビューができなかったり、レビューが慣れていないレビューアーの場合には、コードレビューの品質が落ちたり、コードレビューにあまりにも多くの費用を支払わなければならないかもしれません。
所属メンバーが一貫したレベルのレビュー/フィードバックを着実に受け、ソフトウェアの一貫性を維持するためには、個人の力量に依存しない方法が必要です。 教育を通じて構成員の力量を全て引き上げるならば、ある程度解消されることができますが、本質的な問題解決ではありません。 つまり、自動化されたシステム構築が必要であり、この自動化されたシステムは、ソフトウェアのアーキテクチャ、コード品質、バグ、セキュリティ、スペックなどの一貫性を守り、維持させることができなければなりません。 そして、このようなことをよく"テスト"と呼びます。