ソフトウェアの無秩序な増加を抑える方法

ソフトウェアの無秩序な増加は、最初は認識するのが難しいことがあります。最初はちょっとした煩わしさから始まり、より優先度の高いものによって脇に追いやられます。しかし、放置しておくと、ソフトウェアの無秩序な増加は開発チームの認知的負荷を高め、チームのやる気を低下させ、疎結合アーキテクチャに伴う利点を損なわせる可能性があります。格言で「木を植えるのに最適な時期は 20 年前だった。その次に良い時期は今である」と言われるように、将来の成功は、ソフトウェアの無秩序な増加が問題になる前に抑えることが前提です。

以下は、ソフトウェアのスプロール化の 3 つの兆候と、すべてのチームの潜在能力を引き出す革新的でダイナミックな環境を作りながら、混乱を克服するためにできることです。

インシデントの根本原因として、上流での変更を示すソフトウェアのスプロール化の初期症状が、複数のインシデント後レビュー (PIR) にあります。マイクロサービスの数が増え、環境内の変更数が増加することによって、開発者のコラボレーションや変更の調整に関して、通常より負担がかかることがあります。最新化された 1 つのアプリケーションの変更頻度がわずかに月次から週次に増加したとしても、1 か月あたりのリリース数はその 100 倍にもなる可能性があります。開発者がコラボレーション方法を適応させる必要があるのは当然です。開発者がハイペースな環境でコラボレーション規範を拡張できない場合、インシデントが、本番環境で発生する可能性が高くなります。

開発者が上流と下流の変更を意識するための押し付けがましくない方法を作ることは、ソフトウェアのスプロール化の影響を抑制する優れた方法です。アトラシアンでは、チームが分散アーキテクチャをナビゲートするのに役立つ開発者ポータルである Compass を使用して、上流と下流のサービスに対する重大な変更について開発チームにアプリ内通知を送信しています。この通知を確認することで、依存サービスを担当するチームが変更を認識していることを、変更開始者に知らせることができます。これにより、何か問題が予想される場合には、その変更に協力する機会を提供し、本番環境での意図しない影響を与える可能性を低減します。インシデントはダイナミックな環境で必ず発生するため、サービスを迅速に復旧させるためには、インシデント発生時の開発者の協力が欠かせません。

上流の変更が根本原因であるインシデント後のレビューでは、問題のある上流の変更と、そのサービスを所有するチームや担当者の特定にかかる時間が、通常サービスの復旧時間に影響を与えます。論理的には、問題のある上流の変更の特定にかかる時間を短縮すれば、徐々に平均復元時間 (MTTR) は短縮されます。このことは、サービスが多くの依存関係階層を持ち、インシデントの根本原因がスタックのどこにでも存在する疎結合アーキテクチャでは、より困難なものになります。従来、インシデント担当者は、ログや変更記録をくまなく調べて、インシデントを引き起こした可能性のある変更を特定する必要がありました。ダイナミック環境において、これは自分を噛んだアリを見つけるためにアリの巣を取り壊すようなものです。

アトラシアンでは、Compass のアクティビティ フィードを使って、MTTR を短縮しています。上流システムのすべてのイベントと、それを所有するチームの詳細が表示されます。これにより、インシデント発生時の開発者のコラボレーションをサポートし、トリアージ時間を大幅に短縮できます。インシデントは発生するものですが、インシデントの根本原因である上流の変更をタイムリーに特定することは、影響を最小限に抑え、サービスを迅速に復旧させるために非常に重要です。

疎結合アーキテクチャへの移行は、チームの生産性と幸福度のための重要な要素の 1 つであり、高いレベルの自律性を持って独立して動くことができるようになることです。ソフトウェアのスプロール化を放置しておくと、せっかくのメリットが台無しになり、忙しくても非生産的で不幸なチームになってしまいます。開発チームと話すと、「他のチームと関わる必要があるまでは、すべてうまくいっている」という苦情がよくあります。これは、ソフトウェアのスプロール化が問題になると、さらに増幅されます。急速に拡大し、変化する環境では、開発者は上流や下流の依存関係を把握することが難しくなり、最終的に開発ペースが低下し、ペースを維持しようとするチームのフラストレーションが蓄積されます。

仮に、アルファ チームとベータ チームが毎週同じ数の課題とストーリー ポイントを Jira の「完了」に移動したとします。アルファ チームは新機能の本番環境への出荷に 90％ の労力を費やし、ベータ チームは 30% を新機能に、70％ の労力を依存する多くの上流サービスとの連携に費やしています。どちらのチームも同じレベルの出力を持っていますが、生産性が高いと考えられるのはアルファ チームだけです。ソフトウェアのスプロール化は、チーム間のコラボレーションの必要性を増大させます。自立したチームがオンデマンドで活動するためのスマートな方法を特定することは、疎結合環境の力を引き出すための鍵となります。

急速に成長するダイナミックな環境では、情報をセルフサービスで提供することは、チームの生産性と幸福度にとって重要です。これを実現する 1 つの方法は、分散管理を使用して集中型ソフトウェア コンポーネント カタログを実装することです。これは、各チームが所有するサービスの作成と更新に責任を持つ集中型カタログです。従来の環境では、特定のチームや機能によって管理される一元化されたカタログが一般的でした。しかし、これでは分散環境の変化のスピードについていけず、誰がどのように関わるかについて、シャドー ウィキを作成するチームが出てくることになります。アトラシアンでは、分散型アプローチにより、チーム間の目に見えない無駄な労力を削減し、セルフサービス機能を向上させ、エンゲージ オンデマンド環境を実現することがわかりました。上流と下流の依存関係に関するセルフサービスの情報を有効にすることで、ソフトウェアのスプロール化を抑えることは、チームの幸福度とエンゲージメントに補完的な効果をもたらし、チームの生産性を向上させる優れた方法です。