Close

負のベロシティ: 複雑さの限界を引き上げる方法


エンジニアリング組織の最も一般的な目標の 1 つは、高品質のソフトウェアを迅速に提供することです。

CIO や CTO のビジョン ステートメントを見て、彼らの話に耳を傾けてみてください。おそらく、何らかの形でこの目標が追求されています。一般的な目標であるとはいえ、その目標を達成できたチームとソフトウェア デリバリーで行き詰まっているチームの間には幅広いスペクトラムが存在します。インシデントが発生することも顧客に悪影響を与えることもほとんどなく、一貫して新しいコードを本番環境に追加するチームもあれば、四半期に一度のリリースに苦労しているチームもあります。

このパフォーマンスの違いの原因は何でしょうか?


ソフトウェア デリバリーの複雑さが、高品質のソフトウェアを迅速に提供できるかできないかの違いとなります。これは、ソフトウェア デリバリー チームが、毎週リリースに成功して勝利の鐘を鳴らすか、数か月にもわたって最新リリースに取り組んだにもかかわらず 6 つも新しいバグが見つかってロールバックが必要になり、失望してやる気が失せるかの違いです。

スタートアップが新製品や新機能をリリースするスピードと品質を、従来の大企業と比較してみましょう。たとえば、金融業界では、フィンテックの新興企業は、この 10 年間、大手銀行の市場シェアを少しずつ奪ってきました。大手銀行はよく、新興企業は規制監督が少なく、維持すべき従来のモノリシックなアプリケーションの遺産もなく運営している、フィンテックの新興企業の不当な優位性を指摘しています。チームの規模が小さいほど俊敏性が高まり、顧客のニーズに基づいて方向転換できます。基本的に、フィンテックは従来の銀行の複雑さを持っていないため、より迅速かつ少ないリスクで行動できます。ソフトウェア チームのペースを落とす可能性がありますが、複雑さは必ずしも悪いことではありません。

The benefits of SOA

SOA's modularity and standardized protocols enable services to communicate effectively, promoting reusability, interoperability, and scalability. These key benefits translate into tangible advantages for companies:

  • Reusability: Reusing existing services reduces development time and costs and promotes consistency and quality. Companies can accelerate development cycles and improve overall efficiency.
  • Interoperability: Services can communicate and exchange data regardless of their underlying technology or programming language. This facilitates enterprise-wide data integration and collaboration. Interoperability streamlines business processes and helps companies adapt to evolving technologies.
  • Scalability: SOA's modular design enables independent scaling of services to meet fluctuating demands. It ensures applications can handle spikes in traffic or expanding user bases without compromising performance or stability. Companies can adapt their infrastructure to changing needs without costly rewrites or redesigns.

グローバル ネットワーク
関連資料

分散するソフトウェアを管理する

アイコン: 3 つの輪
ソリューションを見る

Compass によってコンポーネントを管理

ソフトウェア デリバリーの複雑さ


複雑さには良い面もあります。難しい問題を解決することは非常にやりがいがあります。困難に立ち向かい、難しい問題に取り組み、業界を一変させようというチームのモチベーションになります。しかし、あるポイントを超えると、複雑さは難しい問題を解決することと無関係になり、ソフトウェア チームにマイナスの影響をもたらすようになります。

組織の複雑さは、ソフトウェア チームの効率を低下させる大きな要因となります。コリンズ辞典では、複雑さ「多くの異なる部分が複雑に相互に接続または関連している状態」と定義しています。具体的に言えば、組織の複雑さとは、ソフトウェア チームが組織の他の部分とやり取りする際に対応する必要のある情報、依存関係、変更、他のチーム、ツール、およびリクエストの集合体です。

組織の複雑さが増すと、当然ながら高品質のソフトウェアを迅速にデリバリーすることが難しくなります。なぜなら、チームは難しい問題の解決よりも組織内の対応に多くの時間を費やすからです。成長中の組織はほどなく、ソフトウェア チームが複雑さの限界に達したことに気づきます。複雑さの限界とは、仕事に対する満足度や、作成されるソフトウェアの品質とスピードに影響が及ぶ前にチームが対応できる複雑さの量です。論理的には、組織の複雑さを軽減すれば、チームは難しい問題の解決に集中し、より高品質なソフトウェアをより早く提供できるようになると考えられるでしょう。これが必ずしも当てはまらない理由を探ってみましょう。

Benefits of microservices

メリットを考慮して、より多くの組織がマイクロサービス アーキテクチャを導入し始め、自然と組織の複雑さが増え始めました。自律的なチームが増えるとより多くのコラボレーションが必要になり、マイクロサービスが増えると依存関係も増えます。変化のペースは急上昇しました。すべてソフトウェアのスプロール化の兆候です。複雑さが増すにつれて、変更ベロシティの低下が示すように、ソフトウェア チームの効率が横ばいになり、ソフトウェア チームにとって認知的負荷が課題になってきました。

複雑さの限界に近づいているかどうかの見分け方


複雑さの限界に達することは避けられないと感じるかもしれませんが、チームが限界に近づいていることを示すいくつかの指標があります。最初に言っておきますが、複雑さの限界にどれだけ近いかを示す絶対的な指標はありません。しかし、これらの指標は、どれだけ近いかを判断するのに役立つ可能性があります。

チームが複雑さの限界に達したことを示す最も明確な指標は、重点的に取り組むべき難しい問題の解決よりも、組織の複雑さへの対応に多くの時間を費やしているということです。DORA の変更のリード タイム (スピード) と変更エラー率 (品質) の指標をトレンド分析すると、チームが時間の経過とともに減速するかスピードアップするかが分かります。これらの指標に影響する要因は他にもありますが、これらはチームの効率を示す良い指標です。

開発者の満足度は、ソフトウェア チームがどのくらい組織の複雑さに対応しているかを示すもう 1 つの指標です。開発者は他のどのロール プロファイルよりも、難しい問題の解決に時間を費やすのが好きですが、邪魔になる不必要なタスクは嫌いです。開発者の満足度が低いということは、組織の複雑さがソフトウェア チームにとって課題となっていることをよく示しています。

Feature

SOA

Microservices

Architectural style

  • Coarse-grained, centralized

Service granularity

  • Larger, more comprehensive services

  • Smaller, focused services

Independence

  • Services are interdependent
  • May share a database for data storage

  • Services are highly independent
  • Decoupled and autonomous

Communication

  • Synchronous, often message-oriented
  • Uses shared data

  • Asynchronous, often RESTful
  • Avoids data sharing

Data storage

  • Centralized data management
  • Services share database

  • Distributed (decentralized) data management
  • Each service is responsible for its own data management

Scalability

  • Horizontal scaling
  • Scaling specific services can be intricate due to shared resources and centralized communication

  • Horizontal and vertical scaling
  • More granular and focused scaling as services operate independently

Deployment

  • Typically involves deploying the entire application as a single unit

Coupling

  • Services exhibit a degree of coupling due to shared resources and centralized communication

  • Loose coupling with minimal dependencies between services

複雑さの限界に近づいているかどうかの見分け方


複雑さの限界に達することは避けられないと感じるかもしれませんが、チームが限界に近づいていることを示すいくつかの指標があります。最初に言っておきますが、複雑さの限界にどれだけ近いかを示す絶対的な指標はありません。しかし、これらの指標は、どれだけ近いかを判断するのに役立つ可能性があります。

チームが複雑さの限界に達したことを示す最も明確な指標は、重点的に取り組むべき難しい問題の解決よりも、組織の複雑さへの対応に多くの時間を費やしているということです。DORA の変更のリード タイム (スピード) と変更エラー率 (品質) の指標をトレンド分析すると、チームが時間の経過とともに減速するかスピードアップするかが分かります。これらの指標に影響する要因は他にもありますが、これらはチームの効率を示す良い指標です。

開発者の満足度は、ソフトウェア チームがどのくらい組織の複雑さに対応しているかを示すもう 1 つの指標です。開発者は他のどのロール プロファイルよりも、難しい問題の解決に時間を費やすのが好きですが、邪魔になる不必要なタスクは嫌いです。開発者の満足度が低いということは、組織の複雑さがソフトウェア チームにとって課題となっていることをよく示しています。

シンプル化は負け戦略


企業は、チームが複雑さに溺れていることに気づいたとき、多くの場合、組織のシンプルさを取り戻すことを目的とした「シンプル化プロジェクト」を開始します。シンプル化が負け戦略であるのには 2 つの理由があります。1 つは複雑さが増す速度が速すぎて組織の環境のシンプル化が追いつかないこと、そしてもう 1 つはこれらの「シンプル化プロジェクト」はシンプル化しようとしているまさにその複雑な環境で実行されることです。

シンプル化の一般的な出発点は、アプリケーションを廃止または統合することでアプリケーションの数を可能な限り減らすことです。アプリケーションを廃止するには、チームは、上流と下流のすべての依存関係は何か、アプリケーションのユーザーは誰か、その機能をどのように置き換えるか、データをどこにどのようにアーカイブまたは移行するかについて理解し、この種の作業で発生するその他多くの複雑さに対処する必要があります。残念なことに、この作業に必要な労力に多大な投資をしても、それほど複雑さが軽減されるわけではありません。企業がコア ビジネスやユーザー エクスペリエンスに影響を与えずに廃止できるアプリケーションの数には限りがある一方で、エンジニアが作成できる新しいソフトウェア コンポーネントの数には限りがありません。12 か月かけて 1 つのアプリケーションを廃止しても、その間に、おそらく何百もの新しいマイクロサービスが作成されるでしょう。健全なテクノロジー環境は時間の経過とともに成長するので、複雑さを軽減するために環境を一定の数のアプリケーションやソフトウェア コンポーネントに制限するのは現実的でありません。

シンプル化プロジェクトには通常、組織構造を作り直してコミュニケーション フローの複雑さを取り除くことが含まれます。最もシンプルな組織構造は、全スタッフが同じ場所に配置された大規模な階層型のチームです。最も複雑な組織構造は、小規模かつ分散した、自律的なチームです。コンウェイの法則によると、大規模な階層型のチームはモノリシックなアプリケーションを作成する可能性が高く、小規模な分散型のチームはマイクロサービスのようなモジュール型アーキテクチャを使用してアプリケーションを作成する可能性が高くなっています。高品質なソフトウェアの迅速な生産は、マイクロサービス アーキテクチャなどのモジュール型アーキテクチャ パターンによって実現します。つまり、複雑な組織構造の方が成功につながる可能性が高いのです。組織構造を「シンプル化」すると分かりやすくなりますが、シンプル化プロジェクトの最終目標には逆効果です。

シンプル化は重要で価値がありますが、1 回限りの作業ではなく、ソフトウェア チーム (およびチームのチーム) の継続的な改善として組み込むのがベストです。シンプル化すれば複雑さの限界に達するのを遅らせることができるかもしれませんが、スタートアップ環境で享受していた俊敏な自由さは取り戻せません。

複雑さの限界を引き上げる


What are the challenges of adopting SOA and microservices?

ソフトウェア チームの効率を取り戻すには、組織は複雑さの限界を引き上げる必要があります。複雑さの限界を引き上げるということは、本質的に、仕事の満足度やソフトウェア デリバリーの質とスピードに影響が及ぶ前に各チームが対処できる組織の複雑さの度合いを増やすことを意味します。

プラットフォーム エンジニアリングは、組織の複雑さの限界を引き上げるための重要な概念です。強力なプラットフォーム エンジニアリング チームは、組織の複雑さを日常業務から排除することで、ソフトウェア チームの認知的負荷を軽減することに重点を置いています。プラットフォーム エンジニアリングを正しく実装すれば、チームは組織の複雑さへの対応に費やす時間を減らして、難しい問題の解決に多くの労力を振り向けることができます。

Can SOA and microservices coexist?

アトラシアンは、まさにこの理由で Compass という開発者エクスペリエンス プラットフォームを開発しました。Compass は、ソフトウェア チームがコンポーネント カタログ、指標、スコアカードを通じて組織の複雑さに容易に対応し、健全なエンジニアリング文化の構築に集中できるようにすることで、複雑さの限界を引き上げるのに役立ちます。ここで注目すべき点は、アトラシアンでは組織の複雑さが減少しなかったということです。実際、マイクロサービス アーキテクチャに移行する組織が増えるにつれて、組織の複雑さは増え続けました。私たちは、ソフトウェア チームがその複雑さに対応するために費やす時間を減らしたのです。これが、シンプル化プロジェクトと複雑さの限界の引き上げの違いです。

アトラシアンには 10,000 人以上の従業員と 17,000 以上のソフトウェア コンポーネントがありますが、当社のソフトウェア チームはほとんどがスタートアップのように自由に稼働しており、高品質のソフトウェアを迅速にリリースしています。私たちの成功の秘訣は、複雑さの限界を引き上げてソフトウェア チームの効率を上げたことです。

複雑さの限界を引き上げるには、次の 2 つを行います。

  • DORA 指標を追跡して評価します。あなたのチームの DORA 指標はどうなっていますか? これらの指標をまだ追跡していない場合は、すぐに使える DORA 指標が Compass で提供されています。
  • 開発者の満足度を把握して評価します。ソフトウェア チームの開発者はどんな感情を抱いていますか? 多くの組織が従業員満足度調査を実施しています。機能分野別に結果を尋ねて開発者の満足度についてのインサイトを得ましょう。主な質問には、次の記述の評価が含まれます。
    • 私は自信を持ってリリースできます
    • 仕事のストレスに対処できます
    • 私は自分の仕事が会社の目標にどのように貢献しているかを理解しています

あるいは、CheckOps 手順中に Compass でこの情報を収集します。CheckOps では、チームが先週の感想と、改善できる点の詳細を共有します。

複雑さの限界を引き上げるには、ツール、プロセス、手順の組み合わせが必要です。Compass のような開発者エクスペリエンス プラットフォームは、システムの状態を理解し、依存関係をマッピングし、継続的な手順を作成するのに役立ちます。これにより、複雑さの限界が引き上げられ、組織内のソフトウェア デリバリー チームの可能性が解き放たれます。

今すぐ無料で Compass をお試しください。

How does each architecture impact deployment and DevOps practices?

Both SOA and microservices deployments benefit from Open DevOps practices. However, the specifics will differ depending on the architecture. 

SOA typically involves monolithic deployments, where teams deploy an entire application as a single unit. This approach requires careful coordination between teams. It can be time-consuming and complex, especially for large applications.

DevOps emphasizes collaboration and automation between development and operations teams to address these challenges. This enables more frequent and reliable deployments. By automating testing, configuration management, and infrastructure provisioning, DevOps can help streamline SOA deployments and minimize errors.

Microservices architecture enables more granular deployments. Teams deploy each microservice independently. 

DevOps principles are also essential for microservices deployments. DevOps practices such as continuous integration and continuous delivery allow teams to automate the process of testing, deploying, and building microservices. This facilitates rapid and frequent releases.


この記事を共有する

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

DevOps のイラスト

Compass コミュニティ

イラスト: 障害の克服

チュートリアル: コンポーネントを作成する

マップのイラスト

Compass を無料で始める

DevOps ニュースレター購読

Thank you for signing up