チーム構造によって影響を受けるアプリケーション サービスの展開計画

開発者は本当に違います。 役割や責任から組織構造における配置に至るまで、開発者はしばしば「異質なグループ」となります。 開発チームは IT の一部であるかビジネスの一部であるかの間で揺れ動いているため、必ずしも「IT」という用語に含めることはできません。

DevOps が文化的な変化として定着し始めているにもかかわらず、ほとんどの組織は、IT サイロと呼ばれるほど好意的に呼ばれていない組織に機能的に組織化されたままです。 2019 年のアプリケーション サービスの現状に関する調査では、回答者のほぼ半数 (46%) が依然として「ネットワーク」、「サーバー」、「ストレージ」、「セキュリティ」などの「単一機能チーム」で組織されていることがわかりました。 3 分の 1 以上 (37%) は、DevOps の原則とアプローチを採用してアプリケーションの配信と展開に適用するのに適した統合運用チームで働いていました。 わずか 15% が、事業部門または会社の製品に基づいた小規模な機能横断型チームで働いていました。

構造は、目的と優先順位を部分的に定義するため重要です。 それによって、成功を測る基準が決まります。 サイロ化された組織は、サイロ化された指標を意味します。 昨年の夏に実施したNetOps および DevOps の調査でもそれがわかります。 チームの測定方法は、構造によって大きく異なることがわかりました。 たとえば、すべてのチームタイプと役割で最も一般的な指標は次のとおりです。

1. ネットワーク稼働率（60%）
2. アプリケーションの稼働時間 (56%)
3. プロセス最適化（40％）
4. 解決までの平均時間（39%）

しかし、それを分解してチームの種類に基づいた指標を見ると、より協力的な、つまり、 DevOps のようなチーム構造では、優先順位が変わります。 

さて、測定基準となる指標は、アプリケーション サービスとどのように関係しているのでしょうか? 実のところ、かなりあります。

ネットワークの稼働時間を主な焦点とする場合は、それに向けて取り組み、その目標に役立つサービスを展開することになります。 アプリケーションの稼働時間も同様です。 それが優先事項である場合、展開頻度で評価される人々よりも可用性サービスをはるかに真剣に受け止めることになります。

私たちの調査では、アプリケーション サービスの展開計画において、主に「単一機能チーム」の回答者ベースの影響が見られます。 アプリケーション サービスを、セキュリティ、パフォーマンス、ID/アクセス、可用性、モビリティなど、アプリケーションに提供するものによって分類すると、それがより明確になります。 

これらの結果は、単一機能チームのメトリックの影響を反映しています。 開発者は主に可用性（多くの場合、特定のパフォーマンス目標を含む）に関心があり、可用性とパフォーマンスの両方をサポートするアプリケーション サービスの導入を計画します。 同様に、NetOps は、アプリケーションが依存するネットワーク プロトコルを最適化、拡張、保護することでネットワークの稼働時間をサポートするアプリケーション サービスに重点を置いています。 

チーム構造が重要です。 より協力的な文化を奨励する必要があるからだけではなく、それがテクノロジーの選択を含む意思決定に影響を与えるからです。 多様な目標は摩擦とフラストレーションを生みます。 これは、従来は NetOps によって導入および運用されていた負荷分散などのアプリケーション サービスが DevOps によって継承され、アプリケーションの一部として導入されるようになった理由の 1 つです。 単一機能のチーム構造を持つ組織では、アプリケーションの稼働時間は開発者にとって優先事項ですが、NetOps にとっては優先事項ではないからです。

DevOps を本当に活用するには、チーム構造とそれを測定する指標を、従来の単一機能のチームから、よりコラボレーションを重視したモデルに移行する必要があります。

サイロはITではなく農場に属するものだからです。