技術的負債を可視化する

はじめに

プロダクトオーナーとして、技術的負債に対処するために貴重な開発時間を費やさなければならないことほどイライラすることはありません。死や税金のように、潜在的な欠陥を解き明かそうとする時間は、決して良い時間ではありません。

プロダクトの拡張性と持続可能性を保つことが不可欠であることは誰もが知っていることでしょう。しかし、主に顧客向けのユーザー機能に焦点を当てているステークホルダーにアップグレードや技術的なプロダクト開発の時間というアイデアを主張するのは困難です。

プロダクトの改善に時間をかけることで、生産性や、持続可能性、拡張性が向上することをステークホルダーに説得しましょう。

この記事では、技術的負債の定義を明確にするために、少し立ち止まってみます。この記事では、技術的負債を可視化することを目的とします。技術的負債を解決するための戦略には触れません。

技術的負債は、確かにコードベースのものかもしれませんが、テスト自働化の欠如や DevOps の課題を意味する可能性もあります。

技術的負債は、未完了の作業ではありません。技術的負債とは対照的に、未完了の作業は、プロダクトバックログに入れることができます。

より詳細な参考文献については、Frances Lash による技術的負債のマネジメントについての記事や、Scrum.org のこの関連トピックに関する価値のあるシリーズを参照してみてください。

訳注: Frances Lash の記事はこの翻訳時点でアクセスできないようです

要するに、どのような定義であっても、技術的負債は計測可能なリスクであるということです。そして技術的負債は、軽減されなければならないことは誰もが同意するところです。

ここでは、より影響力のある方法でステークホルダーとつながる方法を見つけ、技術的負債が引き起こしている影響を示すことをみていきます。

イメージを用いる

データは説得力のあるストーリーを伝えますが、ステークホルダーにとって意味のある方法でデータを可視化するのを支援することで、スピーチやメールや表よりもインパクトが生まれます。私の気に入っているテクニックは、Professional Scrum Trainer の Ryan Ripley が紹介してくれた4つのステップによるソリューションです：

欠陥や技術的負債といったムダのインパクトが透明化されれば、スクラムチームが品質プラクティスを検査する機会が生まれることになります。技術的負債を減らし欠陥を防ぐ適応を行うことで、最終的にプロダクトの総所有コストを下げることができます。それは、プロダクトオーナーにとって喜ばしいことです。

技術をマネージし、技術的負債を可視化するためのヒントについては、Scrum.org の Ian Mitchell の「Using a “Technical Debt Register” in Scrum」を参考にしてみてください。

学びの機会

スプリントレビューのチカラを過小評価してはいけません。これはステークホルダーを戦略的レベルに引き込むためスクラムの正式なフィードバックループなのです。データもよいですが、ストーリーがある方がよいでしょう。予算の観点からインパクトを示すために、失われた作業を時間単位から金額単位に換算して、ビジネスパートナーの言葉で話しをしましょう。スプリントレビューは、チームやプロダクトオーナー、ステークホルダーにとって強力なコーチングの機会となるのです。

これらのヒントが、あなたのチームが技術的負債の削減にとって積極的に役に立つのか教えてください。他の方法を使ったことがありますか？

Julee Everett が Ryan Ripley と共にお届けしました。

技術を磨き、真実を語り、感謝の気持ちを表しましょう