この記事は、Julee Everett さんと Ryan Ripley さんによる「Making Tech Debt Visible」の翻訳です。翻訳にあたって、Julee さんの承諾をいただいております。誤字脱字、誤訳がありましたらご指摘の協力をお願いいたします。
はじめに
プロダクトオーナーとして、技術的負債に対処するために貴重な開発時間を費やさなければならないことほどイライラすることはありません。死や税金のように、潜在的な欠陥を解き明かそうとする時間は、決して良い時間ではありません。
プロダクトの拡張性と持続可能性を保つことが不可欠であることは誰もが知っていることでしょう。しかし、主に顧客向けのユーザー機能に焦点を当てているステークホルダーにアップグレードや技術的なプロダクト開発の時間というアイデアを主張するのは困難です。
プロダクトの改善に時間をかけることで、生産性や、持続可能性、拡張性が向上することをステークホルダーに説得しましょう。
この記事では、技術的負債の定義を明確にするために、少し立ち止まってみます。この記事では、技術的負債を可視化することを目的とします。技術的負債を解決するための戦略には触れません。
技術的負債をこの記事では、以下のように定義します：
技術的負債： プロダクトの成熟に伴うアジリティ（機敏性）を妨げるもの
技術的負債は、確かにコードベースのものかもしれませんが、テスト自働化の欠如や DevOps の課題を意味する可能性もあります。
技術的負債は、未完了の作業ではありません。技術的負債とは対照的に、未完了の作業は、プロダクトバックログに入れることができます。
より詳細な参考文献については、Frances Lash による技術的負債のマネジメントについての記事や、Scrum.org のこの関連トピックに関する価値のあるシリーズを参照してみてください。
訳注: Frances Lash の記事はこの翻訳時点でアクセスできないようです
要するに、どのような定義であっても、技術的負債は計測可能なリスクであるということです。そして技術的負債は、軽減されなければならないことは誰もが同意するところです。
ここでは、より影響力のある方法でステークホルダーとつながる方法を見つけ、技術的負債が引き起こしている影響を示すことをみていきます。
イメージを用いる
データは説得力のあるストーリーを伝えますが、ステークホルダーにとって意味のある方法でデータを可視化するのを支援することで、スピーチやメールや表よりもインパクトが生まれます。私の気に入っているテクニックは、Professional Scrum Trainer の Ryan Ripley が紹介してくれた4つのステップによるソリューションです：
1) 標準的なスプリントバーンダウンチャートからはじめる
理想線が付いた標準的なスプリントバーンダウンチャートから始めましょう。スプリントバーンダウンチャートは、スクラムの公式な作成物ではありませんが、スプリントゴールに向けた進捗を可視化する上で、開発チームにとっては価値のあるテクニックです。このチャートを作成できるアジャイルツールを用いていない場合は、Excel でも可能です。
2) 日々の進捗をこまめに把握する
日々の進捗をこまめに把握することで、開発チームがスプリントのタイムボックスに対して、作業の進捗を示す経過時間ではありません。各タスクの実際に残っている作業量です。これがチームの真の生産性ラインになります。あなたがパイロットで飛行機を離陸するときに例えてみましょう。残りの滑走路を測定する価値はありますが、あなたがどれくらいの滑走路を走行したかについては誰も気にしません！バーンダウンは、スクラムにおける現実的な差別化要因である説明責任、検査、透明性という経験的プロセスを視覚的に示すのに役立てることができるのです。
3) 技術的負債も同じ見積もりモデルを用いる
すべての技術的負債も、チームが用いている障害復旧やリファクタリング、欠陥修正などの見積もりのモデルを用いて追跡します。見積もりモデルが、ポイントであっても時間であっても一貫性があればよいです。ツールにラベル項目として付加することもできますが、手動で行なってもよいです。
4) 技術的負債の時間を記録する
最後のステップでは、スプリントバーンダウンチャートをベースとして次に示すように、プロダクト開発作業の上に技術的負債に費やした時間を単純に追加していきます。これにより、障害復旧や欠陥修正、システム停止、その他の技術的負債によってどれだけ生産性が低下しているかが明らかになります。
欠陥や技術的負債といったムダのインパクトが透明化されれば、スクラムチームが品質プラクティスを検査する機会が生まれることになります。技術的負債を減らし欠陥を防ぐ適応を行うことで、最終的にプロダクトの総所有コストを下げることができます。それは、プロダクトオーナーにとって喜ばしいことです。
技術をマネージし、技術的負債を可視化するためのヒントについては、Scrum.org の Ian Mitchell の「Using a “Technical Debt Register” in Scrum」を参考にしてみてください。
学びの機会
スプリントレビューのチカラを過小評価してはいけません。これはステークホルダーを戦略的レベルに引き込むためスクラムの正式なフィードバックループなのです。データもよいですが、ストーリーがある方がよいでしょう。予算の観点からインパクトを示すために、失われた作業を時間単位から金額単位に換算して、ビジネスパートナーの言葉で話しをしましょう。スプリントレビューは、チームやプロダクトオーナー、ステークホルダーにとって強力なコーチングの機会となるのです。
これらのヒントが、あなたのチームが技術的負債の削減にとって積極的に役に立つのか教えてください。他の方法を使ったことがありますか？
Julee Everett が Ryan Ripley と共にお届けしました。
技術を磨き、真実を語り、感謝の気持ちを表しましょう
本記事の翻訳者:
長沢 智治 – アジャイルストラテジスト
サーバントワークス株式会社 代表取締役。Helpfeel Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。
『More Effective Agile』、『Adaptive Code』、『今すぐ実践！カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。
Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。
