BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル マイクロサービスアーキテクチャの技術的負債の管理

マイクロサービスアーキテクチャの技術的負債の管理

ブックマーク

キーポイント

  • Technical debt is the set of decisions made during software development that reduce teams' capacity to build features bringing value. If left unchecked, it can lead to the inability to compete successfully in the marketplace or the complete collapse of complex software systems.
  • Making technical debt a community effort helps corporate culture, making engineers feel responsible.
  • Building a Technology Capability Plan systematises the management of technical debt and makes what must be fixed and when clear to all stakeholders, giving negotiating leverage to engineering and promoting long-term thinking.
  • Capturing technological risk as a numeric score in a balanced scorecard makes it visible to management.
  • Alternatives to the TCP, like SLOs with error budgets, promote short-term thinking, make it hard to plan work to fix the technical debt and tend to create antagonistic relationships.

原文(投稿日:2022/02/02)へのリンク

QCon Plus で、Glenn Engstrand 氏は、技術的負債の管理を容易にする方法論について講演しました。ソフトウェア開発に携わるほとんどの人が、プロジェクトの技術的負債の修正に時間を費やすことに、プロダクトやプロジェクトマネージャの同意を得ることに苦労しています。Optum Digital (以前の Rally Health) で Engstrand 氏が使用した方法により、これらの優先順位付けの問題を体系的かつ非対立的な方法で管理できます。

技術的負債とは何か?

広く言われている技術的負債とはソフトウェア開発中に行われる、価値をもたらす機能を構築するチームの能力を低下させる一連の決定です。

次の交渉はおなじみのはずです。プロダクトマネージャは、製品に追加したい次の機能について説明します。開発者は、実装にかかる時間について長時間の見積もりを出しますが、これは長すぎると見なされます。開発者は、理解しにくい多くのコードに変更を加えたり、古いライブラリやフレームワークのバグを回避したりすることの影響に対処する必要があることについて話します。次に、開発者はこれらの問題に対処する時間を求め、製品マネージャは、最初に実装する必要のある要求機能の大きなバックログを示して却下します。

十分に長い間チェックせず放置すると、この悪循環は市場でうまく競争できなくなるか、複雑なソフトウェアシステムが完全な壊滅的崩壊にさえつながることがあります。

それは2つの様子に分類されます。1つは、最良のソリューションではなく、簡単なまたは高速なソリューションを選択することに関するものです。もう1つは、技術スタックの陳腐化または不十分さに関連しています。どちらの様子も、価値を構築したりバグを修正したりする代わりに、偶発的な複雑さに対処するためにエンジニアリング時間を費やす原因になります。

競争力のある速度を維持して機能を提供しながら、技術的負債を返済することは困難な可能性があり、システムアーキテクチャが大きくなるにつれより悪化するだけです。数十または数百のマイクロサービスの技術的負債の管理は、単一のサービスよりもはるかに複雑で、返済しないことに関連するリスクはより速く増大します。

すべてのソフトウェア会社が、技術的負債への対処を避けられないところまで来ています。

Optum Digital では、ポートフォリオ (ソフトウェア製品ラインとも呼ばれます) は、特定のニーズに対応して、組み合わされる製品のコレクションです。複数のチームがそれぞれの製品に割り当てられ、通常はソフトウェアクライアントまたはバックエンドサービスと連携します。複数のポートフォリオにわたって機能する、よりプラットフォーム指向のサービスのためのチームもあります。ほとんどの場合、各チームはさまざまなソフトウェアリポジトリを担当しています。700人以上のエンジニアが数百のマイクロサービスを開発しています。技術的負債が制御不能になるリスクがかなり現実的なため、技術的負債を非常に深刻に受け止めています。

私たちの CTO はモノリスをマイクロサービスに分割してから約2年後の2018年当初からエンジニアリング投資の重要性についてブログに書いていました。

テクノロジ能力計画 (The Technology Capability Plan)

当社のエンジニアは、技術的負債の問題に取り組むためのテクノロジ能力計画 (TCP) を考案しました。

TCP は、技術的負債を返済するための計画を作成するコミュニティベースの方法です。これは、エンジニアリングによってとエンジニアリングのために使用され、長命と適応性を設計するためのテクノロジランドスケープで絶えず変化する要件を収集、整理、およびコミュニケーションすることにより、エンジニアリングと製品の両方への意図を示します。言い換えれば、特定の措置が間に合わない場合、当社がいつ悪化した状況になるかを指摘するために使用することができます。

このコミュニティでは、特定の形式に従って、技術的負債を返済するための計画を作成するように動機付けられています。次に、技術的負債の各領域についてリスクスコアが計算され、そのリスクスコアに基づいて優先順位が設定されます。優先順位付けされた計画は、技術的負債を製品マネージャと積極的かつ実用的に返済するためのエンジニアリング時間を交渉するために使用されます。

エンジニアリングコミュニティ

エンジニアリングコミュニティは、組織に対して横断的に形成されます。つまり、特定のチームや製品に関連付けられません。多くの場合、エンジニアは同じテクノロジーを使用することに情熱を持っているため、これらの実践コミュニティに惹かれます。つまり、コミュニティはオープンで有機的に成長することができます。

ただし、一部のコミュニティに戦略的価値があると見なされた場合、それらを招待専用にすることができます。メンバーシップがキュレートされている場合は、文化の適合性よりも文化の追加に焦点を当てる必要があります。また、代表性と多様性を保証する必要があります。

彼らは通常、進行中の会話とリソース共有のための専用のコミュニケーションリソース (例えば、wiki トピック、チャットチャネルや電子メールリスト) を持っています。

ポリシーは、これらのエンジニアリングコミュニティを通じてボトムアップで設定されます。これは、TCPの有効性と信頼性の鍵です。

毎月のコミュニティミーティングは記録と共有され、その要約はすべてのエンジニアに送信されます。TCP の各コミュニティの部分は、ミーティングの活動に基づいて最新の状態に保たれた生きたドキュメントです。四半期に一度、これらのドキュメントは TCP として内部的に収集および公開されます。

技術的負債を返済するための計画の作成

各コミュニティの計画には、約1ページの説明的なナラティブと、時間の経過に伴う望ましい技術の進化を表す表を含みます。

表の各行は、プログラミング言語、フレームワーク、ライブラリ、またはプラットフォームとしてのサービスに関連するあるテクノロジ固有の推奨 (preferred)、許容 (acceptable)、推奨できない (discouraged) または許容できない (unacceptable) - PADU のバージョンです。それは、当然組織の技術スタックに特有のものです。

各列はある期間 (たとえば、四半期または1年) を表します。表全体は、今後3年間を表すことが目的です。

各表のセルには、列の期間中のテクノロジのバージョンライフサイクルステータス (計画、非推奨、移行、使用や削除) が含まれています。

計画ステータスは、アップグレードを計画する必要があることを示します。非推奨 (D) は、チームがテクノロジバージョンを採用できなくなったことを意味します。移行 (M) ステータスは、各チームが適切なバージョンに積極的に移行する必要があることを示しています。使用 (U) ステータスは、このテクノロジバージョンを使用しているものであることを意味します。削除 (R) ステータスは、その期間中にテクノロジが使用できなくなる可能性があることを意味します。

説明的なナラティブは、各テクノロジを使用しなければならないコンテキストと、計画をフォローしないすべてのチームへの影響または結果を設定します。これらのコミュニティ主導の計画は、古くなったり、安全でなかったり、あるいはサポートされていないテクノロジバージョンの使用に対処する技術的負債の側面を組織が管理するのに役立ちます。

各ポートフォリオは、TCP に含める計画も提出することができます。ポートフォリオ主導の計画は、大規模なコードベースのリファクタリングやモノリシックサービスを多くの小さなサービスに分割するなど、他の形態で技術的負債を返済する意図を示しています。

TCP のコミュニティとポートフォリオのセクションに加えて、計画のビジョンを示す概要と、現在最もリスクが高い製品の分野を説明するセクションもあります。

技術的リスクとは何か?

エンジニアリングコミュニティと主要なポートフォリオエンジニアは、技術的負債を返済する計画を作成します。この結果、エンジニアリング投資の広範なリストが作成されました。既知のリソースの制約から、どのようにリストに優先順位を付けるのでしょうか? エンジニアリングへの投資はそれらからもたらされないので、製品管理は行う方法を知りません。答えは、計画のそれぞれの部分に従わないこととの相対リスクを理解することから得られます。

このリスクは、数値のリスクスコアとして得られます。スコアが高いほど、リスクが高くなるため、優先度が高くなります。使用ステータスのあるテクノロジのスコアは常にゼロです。ゼロ以外のリスクスコアは、テクノロジバージョンが移行、非推奨、または削除ステータスになるたびに増加することになります。

それぞれの計画は下から上に向かっていますが、リスクスコアは上から下に向かっています。計画はコミュニティに参加しているエンジニアからのものであり、そのリストの優先順位付けはエグゼクティブエンジニアリング管理からのものです。

Optum Digital のメトリクスは、バランススコアカードと呼ばれるものに収集されます。これは、ハーバードビジネススクールが最初に開発した戦略パフォーマンス管理ツールです。

さまざまな計画のそれぞれのテクノロジは、その目的のために製品ごとにまとめられています。製品ごとのリスクスコアは、その製品のリスクスコアの合計です。製品のリポジトリの1つでも、非推奨、移行、または削除テクノロジを使用または依存している場合、製品はリスクスコアによってペナルティを受けます。複数のリポジトリが準拠していない場合でも、そのリスクスコアは1回だけカウントされます。これらの製品ごとのリスクスコアの中央値は、バランススコアカードに記録されます。

テクノロジの依存関係を判断する際に、リポジトリで自動化された静的コード分析を使用することは理にかなっています。また、このメトリクスを迅速かつ確実に計算するには、CI/CD、DevOps、および GitOps の適切なサポートが必要になります。

また、各製品のチームが集中できるようにするため TCP リスクスコアを別の方法で計算することもあります。計画からそれぞれのテクノロジは、このメトリクスのリポジトリごとにまとめられます。リポジトリごとのリスクスコアは、このリポジトリのリスクスコアの合計です。

製品のリポジトリの総リスクスコアは、製品自体の総リスクスコアとして合計されます。このようにして、各製品リスクのバーンダウンを追跡したり、TCP リスクに基づいて製品を比較したりできます。

ロードマップへのエンジニアリング投資の獲得

エンジニアといまいましいリーダーシップによって作られた技術的負債を返済するための優先順位づけられた計画ができました。どのようにして計画に資金を提供し、ロードマップに載せるのでしょうか?

まず、エンジニアリングマネージャが製品マネージャと一緒に座って次のスプリントの開発スケジュールを立てるときに TCP なしの場合、通常何が起こるかを確認しましょう。TCP がない環境では、ただエンジニアリングマネージャと製品マネージャがいるだけです。製品マネージャはいつでもセールスを引き合いに出し、道を譲らせることができます。

今度は TCP を使って、同じ交渉を再検討しましょう。製品マネージャは、TCP の重要性と、バランススコアカードで TCP リスクスコアを下げる方法について経営幹部とのミーティングを終えたばかりで、エンジニアリングマネージャと話し合い、次のスプリントのスケジュールを立てます。製品マネージャは3つの機能を求めています。エンジニアリングマネージャは、次のように述べています。「それが私次第であるなら、それら3つの機能すべてを提供するでしょう。残念ながら、すべてのエンジニアと幹部は、今四半期に返済する必要のある非常にリスクの高い技術的負債を特定しました。過去1年間 TCP を追跡していたのですから、このことはすでに知っていたでしょう。」

ダイナミクスがどのように変化したかわかりますか? TCP は、技術的負債とそのリスクに関する企業全体の真のコンセンサスであるため、エンジニアリングマネージャは、怒鳴ったり脅迫したりすることなく、ロードマップにエンジニアリング投資を行うときに、この団体交渉力を利用できます。

万が一、製品マネージャがロードマップへのエンジニアリング投資の許可について柔軟性がないままである場合、エスカレーションのチェーンは最終的にエグゼクティブレベルに到達します。リスクスコアがバランススコアカードの一部であることを覚えていますか? エグゼクティブにとって、バランススコアカードはダッシュボードです。それは彼らが会社がどの方向に向かっているのかを知る方法です。ダッシュボードでそのメトリクスを取得すると、技術的負債が非常に現実的になり、技術的負債の返済などのエンジニアリング投資を選択する可能性が高まります。

TCP に代わるもの

私が知っている技術的負債を管理するための他の唯一の体系的なアプローチは、Googleのサイト信頼性エンジニアリングの本に書かれています。

ここでは、このアプローチについて簡単に説明し、なぜ TCP の方が優れていると思うかを説明します。

最初に、SLO (サービスレベル目標) のリストについてコンセンサスを得ます。システムがこれらの SLO のどれかから外れるたびに、それをエラーとしてカウントします。エラーバジェットと呼ばれる、時間枠ごとの許容可能なエラーの合意された数があります。システムが次の時間枠までにエラーバジェットを超えた場合、これ以上の機能をリリースすることはできなくなります。

この状況を回避するために、製品マネージャは、技術的負債を返済するためにエンジニアリングリソースをより積極的に転用することになっています。

これが、Google の SRE アプローチが非常に不安定だと私が思う理由です。機能とセールスの間の原因と結果は、技術的負債と停止の間の原因と結果よりも、ほとんどの製品マネージャにとってより本物であるように見えます。技術的負債を削減したリリースは常にシステムをより安定させるだろうという仮説があります。それは長期的には真実であることが期待されますが、短期的には真実であるとは限りません。

エラーバジェットからは短期的な思考を促進し、これは製品マネージャがそのようなエンジニアリング投資を承認することを思いとどまらせます。エラーバジェットがいつ超過するかを予測することは困難であるため、エンジニアリング投資時間をいつスケジュールするかを計画することが困難なのです。

このアプローチは、製品マネージャをエンジニアリングと対立する関係に陥らせる傾向があります。この方法は厳格であり、採用するのはリスクが高く、したがって、経営幹部の承認を得るのはより困難です。最後に、このアプローチは技術的負債の返済が政治化する傾向にあります。製品マネージャは、特定の停止をエラーバジェットにカウントしないように、または SLO やエラーバジェットを再交渉してエンジニアリング投資の枯渇の結果を遅らせることによって、システムをゲーム化しようとします。

TCP アプローチは、製品とエンジニアリングの間で真のコンセンサスに到達することに焦点を当てています。TCP 主導の開発はロードマップに関してより予測可能であるため、すべての関係者はストレスの多い驚きを少なくします。

まとめ

テクノロジ能力計画は、エンジニアリングのすべての問題を解決するのでしょうか? もちろん違います。

あなたはまだ技術的負債がありますか? 絶対にそうです。

顧客主導のタイムラインで機能を提供するために、まだショートカットを使う必要がありますか? きっとまたするでしょう。

TCP は、エンジニアリングと製品に、最善を尽くすこと、つまりソフトウェアの作成とリリースを妨げたり制限したりすることを意図したものではありません。TCP は、エンジニアと製品マネージャの両方に、必要なショートカットを使用することは追加のコストがあり、それらのコストを無期限に無視し続けることができないことを通知します。

TCP を使用すると、停止が発生するのを待たずに、技術的負債の返済を開始できます。プロセス、ポリシー、テクノロジ、またはツールは、品質エンジニアリングの賢明な代替手段として機能することはできません。

TCP は、最もリスクの高い技術的負債とは何か、そしてそれをいつ返済することが合理的であるかについて、エンジニア間のコンセンサスを文書化します。TCP が尊重されるためには、その計画に関連性があり、正確で、説得力があり、信頼できるものでなければなりません。それは、コントリビュータが強力なエンジニアリングスキルと誠実さを備えた経験豊富で成熟したプロフェッショナルである場合にのみ起ります。

私たちの TCP ドキュメントからの次の引用はそれを要約していると思います:

長命と適応性のための設計には、今日の現実と明日の可能性の両方を深く理解することが求められます。推進しているテクノロジと市場の力を評価する必要があります。それには、焦点を絞った漸進的な進歩への長期的な取り組みが必要です。

作者について

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT