技術的負債がスプリントの改善に役立つ3つの方法

「負債」という言葉は、あまり良いものではありません。重荷や負担を思い浮かべ、不安な気持ちになります。技術的負債も同様かもしれません。技術的負債とは、品質目標の未達成、保留中のタスク、終了基準チェックリストでスキップされたポイントなど、ソフトウェアの開発中に発生する余分な作業です。金銭的負債と同様に、技術的負債は、短期的には早くても長期的には損をするような決断をしたときに起こります。

この負債を最小限に抑えようと努力しても、負債は発生します。負債はいつかは返済しなければなりませんが、それを教訓にして、自分自身とプロセスを改善することもできます。技術的負債が最終的に開発の助けになるのであれば、それは必ずしも悪いことではありません。

今回は、技術的負債がスプリントの改善に役立つ3つの方法についてご紹介します。

見積もりの改善

計画どおりにアクティビティを完了できずに初めて技術的負債が発生したときは、気持ちの良いものではないかもしれませんが、結果的に開発チームの見積もりと計画が改善されるはずです。

たとえば、すべてのユーザーストーリーに対する開発者のタスクを作業時間の目安とともに定義し、作成されるすべてのコードに対してピアレビューの実施を義務付けていたとします。しかし、スプリントの終わりに、開発者は開発タスクを完了したとマークしているにも関わらず、チェックイン前にピアレビューを受けたコードはありませんでした。これは、時間がなかったり、オーナーシップがなかったりしたために起こった可能性があります。

次のスプリントでは、開発タスクの中にピアレビューのための別のサブタスクを設けることにし、それぞれのタスクに30分という時間を割り当てました。これにより、開発チームは計画を立て、どのタスクが保留になっているかを明確にし、タスクにどれだけの労力が費やされているかを確認できます。

このように、スプリントの早い段階で技術的負債が蓄積し始めたとしても、その原因を理解し、対策を立てることで、開発チームの全体的なパフォーマンスを向上させることができます。

シーケンスと優先順位の決定

リリースが数スプリント後に迫り、重要度は低いものの未解決の欠陥が多数ある場合、開発チームは新機能を追加するよりもスプリントの未解決の欠陥数を減らすことを選択するかもしれません。欠陥というかたちで発生した技術的負債は、優先順位の見直しと変更を開発チームに促します。

あるいは、リリースサイクルの初めに開発チームが回帰テストを70% 自動化することに合意したが、4回のスプリントを経て、作成したスクリプトがメンテナンス不可能になったり十分にスケーラブルではなかったりする兆候が見られたとします。これは最終的にデリバリーに影響する可能性があるため、「一部のテスターはスクリプトの再作成と新しい自動テストの追加にフルタイムで注力し、他のテスターは機能テストと回帰テストのタスクを担当する」という方法を取ることができます。

以前に私の開発チームであったことですが、5回目のスプリントの終わりに、開発者がコードの静的解析を実行していないことや、スプリントごとに義務付けられているレポートを作成していないことが判明しました。理由はともかく、それらのレポートを実行すると、コードの書式、命名規則、コメントに関するエラーや警告が何百個も発生していたということです。ひとつひとつは小さな問題でしたが、何千行ものコードをすべて修正するために時間がかかりました。

私達はプロダクトオーナーと交渉し、スプリントからユーザーストーリーを1つ削除することで、この負債を完全に取り除くために4日間を確保しました。テスターは、修正されたすべてのコードに対して回帰チェックとサニティチェックを行い、さらにホワイトボックステストを追加することで支援しました。次のスプリントからは、開発者が静的解析を実行して必要なレポートを作成すること以外は、通常どおり作業を続けました。

もちろん、どのような決定もコンテキストとビジネスの意図に基づいてなされるべきです。しかし、技術的負債が原因でこのような問題が発生すると、開発チームの結束が強まります。なぜなら、全員がオーナーシップを持ち、同僚を支援しなければならないからです。また、時間が経つにつれて、この経験によってタスクの優先順位付けもうまくできるようになるでしょう。

ハードニングのイテレーション

理想的ではありませんが、ハードニング（システムの脆弱性を取り除きセキュリティを高めること）のイテレーションは、技術的負債を返済するために利用できます。そのため、最初にハードニングのイテレーションの計画を立てておくことは、たくさんの保留事項を抱えてしまった場合に、最終的に開発チームにとって救世主となります。

ハードニングのイテレーションに実際のアクションプランがなかった場合、最初に見るべき場所は技術的負債です。保留中の自動化タスク、ドキュメントレビュー、ホワイトボックステストのカバレッジ改善、タスクやユーザーストーリーを完了する際に見落とした終了基準などの項目が、最初に目標とすべきものになります。

機能的な回帰テストと自動テストの実行に加えて、このアクションは開発チームにシステムへの信頼感をもたらします。これにより、リリース時のストレスが軽減され、全員の認識を一致させることができます。

技術的負債の最大限の活用

技術的負債は楽しいものではありませんし、決して目標にすべきものではありませんが、開発チームが逆境に立ち向かい、協力して解決する方法について多くの教訓を得ることができます。技術的負債に取り組むことで、開発チームは改善され、時間の経過とともにスプリントをより良いものにすることができます。さあ、深呼吸して、技術的負債に取り組みましょう！

作者について：

Nishi Grover Gargは、企業トレーナーであり、アジャイル愛好家であり、根っからのテスターです。11年以上の業界経験を持ち、現在はSahi Proでエバンジェリスト兼トレーニング責任者を務めています。彼女は、トレーニング、およびテストコミュニティのイベントやミートアップの開催に情熱を注いでおり、数多くのテストイベントやカンファレンスでスピーカーを務めています。彼女のブログ “testwithnishi.com “では、アジャイルとテスト分野の最新の話題を取り上げています。

（この記事は、開発元 Ranorex 社 Blog 「Three Ways Technical Debt Can Actually Help Improve your Sprints」2020年1月16日の翻訳記事です。）