パイプラインが組織構造について語ること

DevOps に関連する「法則」の 1 つは、Melvin Conway というプログラマーのものです。 彼の法則は 1967 年に導入され、単に「システムを設計する組織は、これらの組織のコミュニケーション構造のコピーである設計を作成することを余儀なくされる」と述べています。

「システム」という言葉を強調したのは、コンウェイの法則がアプリにのみ適用されることがあまりにも多いからです。 ソフトウェア システムへ。 しかし現実には、「システム」にはアプリから、それらを配信および展開する統合パイプラインまですべてが含まれます。 あなたのパイプライン。

デプロイメント側（つまり本番環境）で DevOps 方法論を採用することについて話すときは、コンウェイの法則などの関連する原則にも注意する必要があります。 なぜなら、その法則は、市場に投入されるアプリと同様に、展開パイプラインの設計にも適用されるからです。

2019 年のapplicationサービスの現状に関する 2 つの質問を覚えているかもしれません。 最初の質問は、IT の組織構造（統合運用、単一機能、または機能横断型チーム）についてでした。 2,000 人を超える回答者のうち、ほぼ半数 (46%) が単一機能チームとして組織されていることがわかりました。 複合作戦は37%で立派な2位となった。 部門横断型チームはあまり一般的ではなく、回答者のわずか 15% がそのような構造で活動しています。

ここで、デプロイメント パイプラインの自動化の状態を調べることが重要になります。 なぜなら、結果は明らかに単一機能チームの優位性を反映しているからです。

ここでのデータは、一貫性のない自動化の取り組みを示しており、これは、デジタル トランスフォーメーションに関して回答者のほぼ半数 (48%) が掲げる目標、つまり、アプリをより迅速かつ頻繁に展開するという目標の実現には役立たないだろう。 IT 内の確立されたこれらのドメイン間の不一致は、コンウェイの法則があらゆる場所のあらゆるシステムに当てはまることの実存的な証拠です。

さらに詳しく調べてみると、10 人に 1 人強 (11%) がこれらのドメインの 1 つだけを自動化していることがわかりました。 4 人に 1 人 (25%) が 2 つまたは 3 つのドメインの自動化に成功しています。 また、5 社中 1 社以上 (21%) が、完全に導入の自動化パイプラインを完了するために必要な 4 つの主要ドメインすべてを自動化しています。

かなりの割合（42%）が、これらのドメインをまったく自動化していません。

デプロイメント パイプライン全体にわたる自動化の不平等は、パイプライン内で手動プロセスが発生するたびに遅延が発生するため、価値実現までの時間のパズルの重要なピースとなります。 この遅延により、価値実現までの時間（または市場投入までの時間）が遅くなります。 割合の違いは、組織が「単一機能チーム構造」のままであることの影響を示しています。これは、パイプラインの残りの部分とどのように相互作用するかをほとんどまたはまったく考慮せずに、個々の「サイロ」が自動化されているのが見られるためです。

このため、複合運用または機能横断的なチーム構造が好まれます。 IT ドメイン間の通信チャネルがピア プロセスとなり、複数の懸念事項にまたがるシステムの設計が容易になるためです。 パイプライン (システム) をチームで設計する場合、パイプラインを複合部分としてではなく、全体として考慮することができます。

自動化の作業自体は、ドメインの専門家によって処理される可能性があります (おそらく、そうすべきです)。 しかし、全体的な設計と統合方法 (API) は、オープンで協力的なチームで設計する必要があります。そうしないと、自動化サイロが生じ、より迅速かつ頻繁に市場に投入するというビジネス目標の達成に役立たない可能性があります。

したがって、生産パイプラインを自動化する試みで遅延や迂回が発生している場合は、一歩下がって、既存の組織構造とそれがパイプラインの設計にどのように影響するかを検討してください。 何かを効果的に自動化する前に、その取り組みをサポートするために、より効果的な組織構造を推進する必要があることに気付くかもしれません。