負のベロシティ: 複雑さの限界を引き上げる方法
ソフトウェア チームが乗り越えるべき組織の複雑さが大きすぎる兆候と、その改善方法
Andrew Boyagi
シニア エバンジェリスト
エンジニアリング組織の最も一般的な目標の 1 つは、高品質のソフトウェアを迅速に提供することです。
CIO や CTO のビジョン ステートメントを見て、彼らの話に耳を傾けてみてください。おそらく、何らかの形でこの目標が追求されています。一般的な目標であるとはいえ、その目標を達成できたチームとソフトウェア デリバリーで行き詰まっているチームの間には幅広いスペクトラムが存在します。インシデントが発生することも顧客に悪影響を与えることもほとんどなく、一貫して新しいコードを本番環境に追加するチームもあれば、四半期に一度のリリースに苦労しているチームもあります。
このパフォーマンスの違いの原因は何でしょうか?
ソフトウェア デリバリーの複雑さが、高品質のソフトウェアを迅速に提供できるかできないかの違いとなります。これは、ソフトウェア デリバリー チームが、毎週リリースに成功して勝利の鐘を鳴らすか、数か月にもわたって最新リリースに取り組んだにもかかわらず 6 つも新しいバグが見つかってロールバックが必要になり、失望してやる気が失せるかの違いです。
スタートアップが新製品や新機能をリリースするスピードと品質を、従来の大企業と比較してみましょう。たとえば、金融業界では、フィンテックの新興企業は、この 10 年間、大手銀行の市場シェアを少しずつ奪ってきました。大手銀行はよく、新興企業は規制監督が少なく、維持すべき従来のモノリシックなアプリケーションの遺産もなく運営している、フィンテックの新興企業の不当な優位性を指摘しています。チームの規模が小さいほど俊敏性が高まり、顧客のニーズに基づいて方向転換できます。基本的に、フィンテックは従来の銀行の複雑さを持っていないため、より迅速かつ少ないリスクで行動できます。ソフトウェア チームのペースを落とす可能性がありますが、複雑さは必ずしも悪いことではありません。
関連資料
分散するソフトウェアを管理する
ソリューションを見る
Compass によってコンポーネントを管理
ソフトウェア デリバリーの複雑さ
複雑さには良い面もあります。難しい問題を解決することは非常にやりがいがあります。困難に立ち向かい、難しい問題に取り組み、業界を一変させようというチームのモチベーションになります。しかし、あるポイントを超えると、複雑さは難しい問題を解決することと無関係になり、ソフトウェア チームにマイナスの影響をもたらすようになります。
組織の複雑さは、ソフトウェア チームの効率を低下させる大きな要因となります。コリンズ辞典では、複雑さを「多くの異なる部分が複雑に相互に接続または関連している状態」と定義しています。具体的に言えば、組織の複雑さとは、ソフトウェア チームが組織の他の部分とやり取りする際に対応する必要のある情報、依存関係、変更、他のチーム、ツール、およびリクエストの集合体です。
組織の複雑さが増すと、当然ながら高品質のソフトウェアを迅速にデリバリーすることが難しくなります。なぜなら、チームは難しい問題の解決よりも組織内の対応に多くの時間を費やすからです。成長中の組織はほどなく、ソフトウェア チームが複雑さの限界に達したことに気づきます。複雑さの限界とは、仕事に対する満足度や、作成されるソフトウェアの品質とスピードに影響が及ぶ前にチームが対応できる複雑さの量です。論理的には、組織の複雑さを軽減すれば、チームは難しい問題の解決に集中し、より高品質なソフトウェアをより早く提供できるようになると考えられるでしょう。これが必ずしも当てはまらない理由を探ってみましょう。
複雑さがソフトウェア チームに与える影響
マイクロサービス アーキテクチャの導入は、複雑さがソフトウェア チームに与える影響の良い例です。「多くの異なる部分が複雑に相互に接続または関連している状態」という複雑さの定義は、マイクロサービス アーキテクチャの説明そのものでもあります。確かに、マイクロサービスのおかげで、チームは独立して動き、より迅速にデリバリーを行い、システムを安全に拡張できます。私はマイクロサービスの大ファンですが、マイクロサービスを導入することにより、明らかに複雑さが増します。
マイクロサービス アーキテクチャを導入するまでの数年にわたる道のりにおけるアトラシアン ソフトウェア チームの効率について考察してみましょう。
アトラシアンがマイクロサービスのジャーニーを始めたばかりの頃は、DORA 指標は素晴らしく見えました。コードのチャンクが小さいのでテストとデプロイが容易になり、チームが安全かつ迅速に行動できるようになり、仕事の満足度も高まりました。この段階では、チームはマイクロサービス アーキテクチャの期待されるメリットを享受していました。複雑さが増しても、チームへの悪影響は見られませんでした。
図 1. マイクロサービスのジャーニーを始めたばかりの頃
メリットを考慮して、より多くの組織がマイクロサービス アーキテクチャを導入し始め、自然と組織の複雑さが増え始めました。自律的なチームが増えるとより多くのコラボレーションが必要になり、マイクロサービスが増えると依存関係も増えます。変化のペースは急上昇しました。すべてソフトウェアのスプロール化の兆候です。複雑さが増すにつれて、変更ベロシティの低下が示すように、ソフトウェア チームの効率が横ばいになり、ソフトウェア チームにとって認知的負荷が課題になってきました。
図 2. 複雑さが限界に近づくにつれ、チームの効率は横ばいとなる
介入しなかったため、最終的に組織は複雑さの限界に達し、ソフトウェア チームの効率は低下しました。マイクロサービスへの移行の初期段階で経験していたスピード、自律性、品質のメリットが逆転し、開発者の満足度が明らかに低下しました。これらの兆候は、組織が複雑さの限界に達したことを示しています。ソフトウェア チームは、難しい問題を解決するよりも、組織の複雑さに対処することに多くの労力を費やしています。これは非効率的です。
図 3. 組織が複雑さの限界に達すると、チームの効率は低下する
複雑さの限界に近づいているかどうかの見分け方
複雑さの限界に達することは避けられないと感じるかもしれませんが、チームが限界に近づいていることを示すいくつかの指標があります。最初に言っておきますが、複雑さの限界にどれだけ近いかを示す絶対的な指標はありません。しかし、これらの指標は、どれだけ近いかを判断するのに役立つ可能性があります。
チームが複雑さの限界に達したことを示す最も明確な指標は、重点的に取り組むべき難しい問題の解決よりも、組織の複雑さへの対応に多くの時間を費やしているということです。DORA の変更のリード タイム (スピード) と変更エラー率 (品質) の指標をトレンド分析すると、チームが時間の経過とともに減速するかスピードアップするかが分かります。これらの指標に影響する要因は他にもありますが、これらはチームの効率を示す良い指標です。
開発者の満足度は、ソフトウェア チームがどのくらい組織の複雑さに対応しているかを示すもう 1 つの指標です。開発者は他のどのロール プロファイルよりも、難しい問題の解決に時間を費やすのが好きですが、邪魔になる不必要なタスクは嫌いです。開発者の満足度が低いということは、組織の複雑さがソフトウェア チームにとって課題となっていることをよく示しています。
シンプル化は負け戦略
企業は、チームが複雑さに溺れていることに気づいたとき、多くの場合、組織のシンプルさを取り戻すことを目的とした「シンプル化プロジェクト」を開始します。シンプル化が負け戦略であるのには 2 つの理由があります。1 つは複雑さが増す速度が速すぎて組織の環境のシンプル化が追いつかないこと、そしてもう 1 つはこれらの「シンプル化プロジェクト」はシンプル化しようとしているまさにその複雑な環境で実行されることです。
シンプル化の一般的な出発点は、アプリケーションを廃止または統合することでアプリケーションの数を可能な限り減らすことです。アプリケーションを廃止するには、チームは、上流と下流のすべての依存関係は何か、アプリケーションのユーザーは誰か、その機能をどのように置き換えるか、データをどこにどのようにアーカイブまたは移行するかについて理解し、この種の作業で発生するその他多くの複雑さに対処する必要があります。残念なことに、この作業に必要な労力に多大な投資をしても、それほど複雑さが軽減されるわけではありません。企業がコア ビジネスやユーザー エクスペリエンスに影響を与えずに廃止できるアプリケーションの数には限りがある一方で、エンジニアが作成できる新しいソフトウェア コンポーネントの数には限りがありません。12 か月かけて 1 つのアプリケーションを廃止しても、その間に、おそらく何百もの新しいマイクロサービスが作成されるでしょう。健全なテクノロジー環境は時間の経過とともに成長するので、複雑さを軽減するために環境を一定の数のアプリケーションやソフトウェア コンポーネントに制限するのは現実的でありません。
シンプル化プロジェクトには通常、組織構造を作り直してコミュニケーション フローの複雑さを取り除くことが含まれます。最もシンプルな組織構造は、全スタッフが同じ場所に配置された大規模な階層型のチームです。最も複雑な組織構造は、小規模かつ分散した、自律的なチームです。コンウェイの法則によると、大規模な階層型のチームはモノリシックなアプリケーションを作成する可能性が高く、小規模な分散型のチームはマイクロサービスのようなモジュール型アーキテクチャを使用してアプリケーションを作成する可能性が高くなっています。高品質なソフトウェアの迅速な生産は、マイクロサービス アーキテクチャなどのモジュール型アーキテクチャ パターンによって実現します。つまり、複雑な組織構造の方が成功につながる可能性が高いのです。組織構造を「シンプル化」すると分かりやすくなりますが、シンプル化プロジェクトの最終目標には逆効果です。
シンプル化は重要で価値がありますが、1 回限りの作業ではなく、ソフトウェア チーム (およびチームのチーム) の継続的な改善として組み込むのがベストです。シンプル化すれば複雑さの限界に達するのを遅らせることができるかもしれませんが、スタートアップ環境で享受していた俊敏な自由さは取り戻せません。
複雑さの限界を引き上げる
ソフトウェア チームの効率を取り戻すには、組織は複雑さの限界を引き上げる必要があります。複雑さの限界を引き上げるということは、本質的に、仕事の満足度やソフトウェア デリバリーの質とスピードに影響が及ぶ前に各チームが対処できる組織の複雑さの度合いを増やすことを意味します。
プラットフォーム エンジニアリングは、組織の複雑さの限界を引き上げるための重要な概念です。強力なプラットフォーム エンジニアリング チームは、組織の複雑さを日常業務から排除することで、ソフトウェア チームの認知的負荷を軽減することに重点を置いています。プラットフォーム エンジニアリングを正しく実装すれば、チームは組織の複雑さへの対応に費やす時間を減らして、難しい問題の解決に多くの労力を振り向けることができます。
図 4. 複雑さの限界を引き上げる
アトラシアンは、まさにこの理由で Compass という開発者エクスペリエンス プラットフォームを開発しました。Compass は、ソフトウェア チームがコンポーネント カタログ、指標、スコアカードを通じて組織の複雑さに容易に対応し、健全なエンジニアリング文化の構築に集中できるようにすることで、複雑さの限界を引き上げるのに役立ちます。ここで注目すべき点は、アトラシアンでは組織の複雑さが減少しなかったということです。実際、マイクロサービス アーキテクチャに移行する組織が増えるにつれて、組織の複雑さは増え続けました。私たちは、ソフトウェア チームがその複雑さに対応するために費やす時間を減らしたのです。これが、シンプル化プロジェクトと複雑さの限界の引き上げの違いです。
アトラシアンには 10,000 人以上の従業員と 17,000 以上のソフトウェア コンポーネントがありますが、当社のソフトウェア チームはほとんどがスタートアップのように自由に稼働しており、高品質のソフトウェアを迅速にリリースしています。私たちの成功の秘訣は、複雑さの限界を引き上げてソフトウェア チームの効率を上げたことです。
複雑さの限界を引き上げるには、次の 2 つを行います。
- DORA 指標を追跡して評価します。あなたのチームの DORA 指標はどうなっていますか? これらの指標をまだ追跡していない場合は、すぐに使える DORA 指標が Compass で提供されています。
- 開発者の満足度を把握して評価します。ソフトウェア チームの開発者はどんな感情を抱いていますか? 多くの組織が従業員満足度調査を実施しています。機能分野別に結果を尋ねて開発者の満足度についてのインサイトを得ましょう。主な質問には、次の記述の評価が含まれます。
- 私は自信を持ってリリースできます
- 仕事のストレスに対処できます
- 私は自分の仕事が会社の目標にどのように貢献しているかを理解しています
あるいは、CheckOps 手順中に Compass でこの情報を収集します。CheckOps では、チームが先週の感想と、改善できる点の詳細を共有します。
複雑さの限界を引き上げるには、ツール、プロセス、手順の組み合わせが必要です。Compass のような開発者エクスペリエンス プラットフォームは、システムの状態を理解し、依存関係をマッピングし、継続的な手順を作成するのに役立ちます。これにより、複雑さの限界が引き上げられ、組織内のソフトウェア デリバリー チームの可能性が解き放たれます。
今すぐ無料で Compass をお試しください。
この記事を共有する
次のトピック
おすすめコンテンツ
次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。
Compass コミュニティ
チュートリアル: コンポーネントを作成する
