技術的負債のブラックホールから脱出する

技術的負債が見つかると、誰もが困惑することでしょう。私たちもそうです。

Dan Radigan Dan Radigan
トピック一覧

従来のソフトウェアプログラムはフェーズベースの開発方法を採用しています:フィーチャー開発、アルファ版、ベータ版、ゴールデンマスター (GM)。

アジャイルの技術的負債|||アトラシアンアジャイルコーチ

リリースはそれぞれ、新しいフィーチャーを構築するフェーズから始まり、(理想としては) 前回のリリース時に未解決であった問題が解決されています (正直、解決されていることは滅多にありませんが)。各フィーチャーが実装され、テストの準備が整うと、開発サイクルが「アルファ」段階に到達します。バグが十分に解決されてカスタマーフィードバックが可能になると、ベータ段階に到達します。残念ながら、ベータ段階に到達する前にバグが十分に修正されていないと、ここで新しいバグが見つかります。バグをひとつ修正したかと思えば、二つのバグが顔を出す、常にもぐらたたき状態です。最終的に未解決なバグがゼロになると、リリースがゴールデンマスターに到達します。「未解決なバグがゼロ」とは通常、既知の問題を修正して解決済みとなり、残り (ほとんど?) の問題は、次のリリースまで見送りとなります。

ソフトウェアを制作するうえで、修正が必要なバグをそのまま放置し続けることは大変危険です。バグの数が増えるにつれ、解決がますます困難になります – 結果、技術的負債で死のスパイラルの悪循環となります。さらに悪いことに、バグ関連のコーディングが開発を遅らせ、スケジュールが狂い始めます。その間、未修正の障害が原因である不具合を、カスタマーは幾度となく経験します。実際、利用を止めてしまうカスタマーもいるでしょう。

いい方法があります。

アジャイルで技術的負債を減らす

チームはリリースを重ねても一貫した品質レベルを維持できるように、アジャイルは反復型開発アプローチの中に品質の要素を含めています。フィーチャーが満足のいくレベルに達していない場合、リリースしません。信じ難いですか? ここにトリックがあります。「完了」の定義を定義、あるいは再定義するわけです。

今まで「完了」とは、QA を開始するのに十分な状態、だったでしょう。この定義における問題は、バグがリリースサイクルの早い段階で忍び込み、そしてそのまま居座り続けることです。QA を開始するまでには、製品は何層にも及ぶ不具合を抱え込んでしまいます。そこで、アジャイルチームは「完了」を「リリースの準備完了」と定義しています。つまり、開発者は現在のストーリーやフィーチャーが実質的に顧客の手に渡るまで、次のものに着手しません。ことの進行をスピードアップするため、開発者は開発サイクル全般において、フィーチャーブランチングワークフロー、自動化テスト、継続的インテグレーション、といったテクニックを利用します。

コードベースのメイン、master、ブランチは、リリースに向けて常に準備が整っている必要があります。それが第一優先です。新しいフィーチャーは、そのフィーチャー自体のコードと自動化テストを含むタスクブランチから開始します。フィーチャーが完了し、自動化テストをパスすると、ブランチは master にマージされます。品質レベルは常に一定 (高い位置で) なので、技術的負債を制御可能な状態で維持できます。

多くの組織にとって、文化がガラッと変わることでしょう。アジャイルでは、重点をスケジュールから外し、高品質の実証できるソフトウェアに置きます。プロダクト所有者は、品質に妥協するのではなく、リリースのスコープを絞ることで、チームがまずは有益な作業を行えることに重点を置くことができます。

忘れるべからず。バグが長引けば長引くほど、修正に手間がかかります。

チームの負債を管理する

古いコードで作業している場合、技術的負債を継承している可能性があります。下記の記事は、既存の負債を管理し、新しいフィーチャーの開発など、もっと楽しいことに集中できるヒントになるでしょう。

定義する

開発者とプロダクトマネージャーは、時に、技術的負債の内容について意見が一致しないことがあります。ここでは議論はお休みにしましょう。

技術的に近道をすれば納品期限に間に合う!

開発作業側では、構築作業を技術的負債とみなしてしまうことがあります。そうとばかりは言えないかもしれませんが、変更の性質によります (たとえば、近道を「真」のソリューションで置き換える方法をとるか、ひとつの大きなコードベースを複数の小さなサービスに分割する方法をとるか、など)。一方、製品管理では、バグや遅いパフォーマンスの修正よりも、新しいフィーチャーの構築関連に緊急性を感じることが多いでしょう。互いに他のチームの意見に振り回されないためにも、皆が技術的負債や目的とするコードベースのアーキテクチャ変更と、新しいフィーチャーとの違いをしっかり理解することが必要です。開発と製品管理の間で明確にコミュニケーションを取ることが、バックログの優先付けや、コードベースを進歩させるために非常に重要です。

プロからのヒント:

スプリント計画における技術的負債の優先付けは、通常のフィーチャーの優先付けと同様に行いましょう。別のバックログや課題トラッカーに分けて隠したりしないことです。

スプリントやタスクのテストを意識する

元のユーザーストーリーに単独のテストタスクを追加して「完了」、としたい衝動に負けないでください。先延ばしにし、技術的負債だけを扱うのはたやすいことです。元のストーリーやバグの一部となっているテストが完了していない場合、元のストーリーやバグ修正が完了したとは言えません。プログラムで「完了」の定義を厳密に維持し、完全な自動化テストが確実に完了の定義に含まれるようにしてください。手動テストとバグだらけのコードベースほど、チームのアジリティを喪失させるものはありません。

自動的にバグをなくす

ソフトウェアでバグを見つけたら、時間を割いて自動化テストを追加し、実際に実装してください。一旦バグが修正されれば、テストを再開して、確実にパスできるようになります。これはテスト主導型開発の中核であり、アジャイル開発で品質を維持するための昔ながらの方法論です。

スタートポイント

技術的負債の管理方法に関するチーム (および関係者) の方針を変えることは容易ではありません。市場に早く出すため、時に、ビジネスは開発時間を削減する必要もあります。それを念頭に置いて、技術的負債を管理するアクション項目をまとめてみましょう。

  • プロダクト所有者に技術的負債の真の代償を教えます。将来のストーリーに必要である既存の技術的負債の解決策に対し、ストーリーポイントの価値が適しているか確認してください。
  • アーキテクチャーをモジュール化し、アプリケーションの新しいコンポーネントやライブラリに存在する技術的負債について、確固とした姿勢を取ります。チームとビジネスが新しいコンポーネントにアジリティを見いだせるため、自然とコードの他の部分についても実践していくことになります。
  • 自動化テストを作成しましょう。バグの防止に、自動化テストと継続的インテグレーション以上のものはありません。新しいバグが見つかったら、新しいテストを作成してそれを実装し、問題を解決します。バグが再度発生しても、自動化テストを実装すれば、顧客がそれを見つけるより前に見つけることができます。

技術的負債は、すべてのソフトウェアチームにとって現実の問題です。誰も避けて通ることはできません。重要なのは、制御不能なスパイラルに陥らないようにすることです。

次の記事
Testing