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

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

Dan Radigan Dan Radigan

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

Agile technical debt | Atlassian agile coach

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

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

いい方法があります。 

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

Agile bakes quality into the iterative development approach so the team can maintain a consistent level quality release after release. If a feature isn't up to snuff, it doesn't ship. Find that hard to believe? Well there's a trick: defining, or redefining, the definition of "done."

For traditional teams, "done" means good enough for QA to begin. The problem with that definition is that bugs creep in early in the release cycle–and continue to creep in. So by the time QA gets their hands on it, the product is saddled with layers upon layers of defects. Agile teams, however, define "done" as ready to release, which means developers don't move on to the next story or feature until their current item is practically in customers' hands. To speed things along, they use techniques like feature branching workflows, automated testing, and continuous integration throughout the development cycle.

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

For many organizations this is a huge cultural change. With agile, the focus away from schedules and towards high-quality, demonstrable software. The product owner is empowered to focus the team on the most valuable work first, reducing the scope of the release instead of compromising on quality.

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

チームの負債を管理する

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

定義する

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

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

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

Pro Tip:

Prioritize technical debt in sprint planning just like normal feature work. Don’t hide it in a separate backlog or issue tracker. 

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

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

自動的にバグをなくす

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

スタートポイント

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

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

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

次の記事
テスト