技術的負債の解明: 負債のない開発サイクルに向けたアジャイル戦略

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

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

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

いい方法があります。

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

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

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

多くの組織にとって、これは文化をガラッと変えることでしょう。アジャイルでは、スケジュールよりも、高品質で、デモ可能なソフトウェアであるという点を重視します。プロダクト所有者は、品質に妥協するのではなく、リリースのスコープを絞ることで、チームが最も価値のある作業を最初に行えるようにすることができます。

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

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

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

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

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

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

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

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

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

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