#product debt

[dianas]

TBM 36/52: Sinking Ship. Full Steam Ahead.

How do you repair a sinking ship that is sailing full steam ahead? We’ll dedicate 10% of our time to pay off the debt! Unfortunately, this rarely works. Why? It is barely enough time to patch the holes and bail the water, let alone repair the damaged hull—more cracks form. More water rushes in. Realistically, it is +10% time (110% time), which burns people out.

[0-9]

プロダクト負債というもの

root Design Meetup #1 「UX負債への取り組み」 - connpass に参加していてUX負債とは技術的負債に非常に近いものを感じた。

そこから考えてみると、特にUXや技術に関わりなく共通的に負債を概念を考えられるのではないかと思ったので書く。

現状プロダクトを運営していく上で積み重なっていく問題を横断的に指す言葉として、ここでは「プロダクト負債」とする。

当初「サービス負債」としていたが、いくつか検索したところ、「product debt（プロダクト負債）」は既に使われている用語のようなので書き直した。

Googleで検索した範囲では「プロダクト負債」だと数件のヒットがあった。

「product-debt」だとそれなりの件数がヒットするが、いくつかみた範囲ではここで紹介している内容より狭い範囲を想定しているように見えた。 （が、この記事は翻訳ではないため、既存の概念とは一致していない可能性が高い）

前提

自分は開発者なので、基本的に技術的負債から発想している。

プロダクト負債とは

継続的に運営されているプロダクトの中で、それを選択時点と状況が変わったのに、状況に対して修正されていないもの。

なぜ各負債の共通概念が必要なのか？

これまでプロダクト負債の中では主に「技術的負債」という形で技術的な部分が多く語られてきた。

しかし、プロダクトを運営していく過程では技術部分以外にも負債は溜まっていくし、それぞれの負債は相互に連携している場合もある。

各分野が単独で負債の解消を目指した場合、個別最適に陥り効率的な改善につながらない場合もある

また、別の分野からのアプローチで対応が不要になる場合もある。

そして、負債の概念にはあえて負債を積むことによって運営を行う上での時間を購入できる場合もある。

そのため、各負債共通の概念を定義することで、プロダクト全体を見ながら適切に負債に対処したり、場合によっては負債を積むという選択も可能になる。

各分野の負債

技術的負債

一般的によく語られているため省略する。

UX負債

かなり想像して書くが、以下のようなものがあるだろう。

色、サイズの不統一性

ダイアログの多様

戻り先が遷移元と違う

必要画面サイズの拡大（横スクロール）

多言語化時の文字の崩れ

学習の終わったA/Bテストの削除漏れ

ちなみに、既に提唱されているため「UX負債」としているが、自分は以下の記事の中では「デザイン的な負債」という呼び方をしていた。

0-9, 「大規模なUI改修」を行うとどうなるか

ビジネス的負債

主に制作フローから発していない負債を想定してビジネス的負債と呼ぶ。

ビジネス的負債に関しては現状語られているところを知らないため、完全に想像である。

もしかしたら既に別の用語で語られている可能性もある。

特定のクライアントのみの特殊契約

複雑な課金テーブル

個別の請求フロー

古い決済手法への依存

制作フローから発していない負債ではあるが、制作フローに対して影響を及ぼす可能性が高い。

共通する概念

「当初想定されていなかった」、「ここまで（大きく|ひどく|長く）なると思っていなかった」というワードが出る場合、負債である可能性が高い。

基本的には当初は想定しておらず、状況が変わった後も適切な対応が取られていなかったものは負債と表現していいだろう。

どう対応するか

各分野ごとに個別の対応方法はあるが、プロダクト負債に対応する方法としては以下のような方法を提案する。

1. 各分野ごとのメンバーで「負債」の概念に関して認識を合わせる

分野によっては別の用語が用いられている場合もある。

必ずしも「負債」という用語を選択する必要はないが、どういった用語を用いるのかは統一した方がいい。

ただし、以下のような概念は共有した方がいい。

負債は必ずしも悪ではない

負債は全くない状態を目指すものではない

負債は運営をしていく以上避けられないものである

現在の負債状況の確認と継続的な変化の監視は必要である

場合によっては負債の追加を行う方がいい場合もある

負債は多くなればなるほど減らすことが難しくなる

負債が一定以上になると追加、変更は行えても削除ができなくなる（想定外の問題が発生する）状態になる

7の状態を超えると追加は行えても変更ができなくなる（想定外の問題が発生する）状態になる

8の状態を超えるとプロダクト運営が行えなくなる

2. 現状どういった負債があるかを確認する

各分野ごとにどういった負債があるかを確認する。

ここでは、純粋にその分野独自の負債も含める。

この時、可能な限り「どういった経緯で追加、実施されたのか」、「なぜ対応されなかったのか」など、背景も含めて共有する

3. プロダクト運営に対する影響度合いで重み付けを行う

確認した負債ごとにプロダクト運営に対してどの程度影響するかの重み付けを行う。

この項目は非常に難しいことが予想され、実際どういった手法を用いれば良いか自分でもわからない。

ただ、各分野ごとではなく、プロダクト全体としてみることで重み付けが変わる場合もあると考える。

例えば、以下のような状況がありえるかもしれない。

技術的な分野から見ると管理画面のフロントエンド部分で非常に大きな負債が溜まっていると認識しているが、プロダクト全体から見ると今後もほとんど修正が予定されておらず返済価値が低い

ビジネス的な分野から見ると課金設計に非常に大きな負債が溜まっていると認識しているが、プロダクト全体から見ると課金テーブル部分の柔軟性が高いために十分吸収可能なため返済価値が低い

UX的な分野から見るとデザインの古いページに非常に大きな負債が溜まっていると認識しているが、プロダクト全体から見るとそもそもページを破棄しても良いため返済価値が低い

4. 重み付けの高いものから対応方法を検討する

重み付けを行ったらそれぞれの項目に対して対応方法を検討する。

完全にその分野に閉じた負債であればその分野のみで対応することも可能であるが、基本的にはどこかしら連携していることが多い。

例えば、以下のような対応があるかもしれない。

負債返却のためのメンバーを採用する

検索部分の負荷が高いが負債化が激しい場合、価格表から検索機能を分けて特別価格に、検索機能を使えるユーザを制限する

一部のユーザのみ大幅なリソースを使っている場合、運営側からヒアリング、説得、警告を行うことで対応を行う

別言語に対して対応する場合、一部の機能だけを抽出したUIを作成する

個別契約が頻発する場合、個別契約の行われやすい部分を抽出し、設定可能な機能として実装する

5. 振り返りと繰り返し

プロダクト負債はプロダクトを運営していく上で避けられないものである。

そのため、ここで挙げた対応方法を継続的に繰り返し、結果を振り返ることで適切に監視、管理していくことが重要である。

注意しなければならない点として、プロダクトの運営は本来ユーザに対して価値を届けることであって、負債を0にすることではない。

プロダクト負債によってプロダクトの運営に支障が出る状況は避けるべきだが、必要であればプロダクトの拡大のために負債を積むことも必要である。

これらはスクラム等のフローに組み込むことが可能かもしれない。

避けた方がいいこと

基本的に負債の一括返済はお勧めしない。

1. 大規模改修

主にUX負債と技術的負債の一括返済のために大規模改修が計画されることがある。

これに関しては以前書いたが、負債が高くなっている状態での改修はリスクが高い。

0-9, 「大規模なUI改修」を行うとどうなるか

また、一括改修は組織に負債の返却に関しての知見がたまらないため、負債のコントロールが難しくなる。

もし、一度一括返済ができてしまうと、組織的に負債の返却方法として一括返済しか選択できず、毎回大規模改修となってしまう危険性がある。

そして、基本的に大規模改修は失敗するまで大規模化していき、最終的に大規模な失敗となって現れる。

大規模な失敗は社員の退職リスクやプロダクト改善の停滞にも繋がるため避けるべきである。

2. 個人改修

それ以外にも「特定のメンバーが英雄的な行動で一括返済を行う」場合もある。

この場合にも組織的に負債をコントロールする技術がたまらないためお勧めできない。

プロダクトを運営する上でプロダクト負債が貯まることは避けられないが、その負債を運営組織としてではなく個人が解消してしまった場合、その個人が退職した場合などに負債の返済が行えなくなる懸念がある。

また、負債化の原因（もしくはその負債を積むことで最もメリットを得られる人）と、一括返済を行うメンバーが同じ人間の場合には比較的問題は小さいが、多くの場合これは別の人間の場合が多いため、原因と結果のバランスが難しくなる。

どんな負債でも自分以外の人間が知らないうちに返済していると、自分がどの程度の負債を返済可能なのかの見積もりを誤ったり、そもそも負債を積んでいる認識を持てなかったりする。

そのため、基本的に負債は運営しながらの個別返却をワークフローに組み込むべきで、一括返済はお勧めしない。

個人でできること

ここまで上げた内容は組織として負債に対応する方法ではあるが、組織的に負債に対応できない状況もありうる。

ここでは組織的に負債に対応できない場合に、個人としてできることを書く。

1. 組織的に負債に対応できるように働きかける

プロダクトの運営に対して最も妥当と思われる対応。

そもそも技術者以外に負債的な概念を持っていない場合もあり、プロダクト負債的な概念が組織に共有されていない場合もある。

まずはそういった概念の共有から行うことで、組織的に負債に対して向き合っていけるようになっていく場合もある。

2. 負債を返却する

個人、もしくは各専門領域内で負債を返却する。

これまで主に技術的負債と言われるものに対して行われてきていた方法。

「週に1日、機能追加以外を行う日を設ける」、「スプリントに一定の余裕を持たせる」などの方法で行われてきた。

プロダクト全体で対応するより適切な対応が取れない可能性が高いが、プロダクト組織全体での対応より難易度が低い。

3. 負債を無視する

組織的な働きかけをできない、しても効果がなかった場合、個人としてできる対応として負債を無視することがある。

自分の職務領域に負債がある場合、成果を発揮することが難しくなる場合もあるが、それは自分のスキル的な限界として受け入れる。

自分以外のメンバーに対して負債的な発言は行わず、負債を含めた見積もりを行ってタスクをこなしていく。

人によっては不誠実と感じる可能性もあるが、そもそもプロダクト負債は各分野が関連して負債化している場合も多く、単独の分野での解決は難しいか効果的でない場合も多い。

また、そもそも一つの分野からみた負債は、全体から見るとプロダクト運営に対して大きな影響を及ぼさない場合もある。

そのため、現状組織的な課題になっていない場合、一旦負債を無視して作業を進めることはそこまで不誠実ではない場合も多い。

ただし、「（開発速度|クオリティ）を上げる方法」を問われた場合、負債の存在と返済方法について提案するのは良いかもしれない。

4. 負債化を加速させる

専門領域外の負債は一定規模まで大きくならないと認識できないため、自分の専門領域の負債化を加速させることでプロダクト全体で課題化する。

負債化を加速させる場面では時間的なコストが低くなることが多いため、専門領域外から見るとプロダクト運営に積極的に見える可能性がある。

プロダクト運営に支障が出るレベルまで負債化した時点で、組織的に対応せざるを得なくなるか、破綻するかのいずれかになる。

組織的に対応できるようになれば、組織としての対応能力として大きな力になる可能性が高い。

もちろん破綻する場合もあるが、破綻までにはある程度時間があるし、それまでにプロダクトがうまく回れば採用等で対応できる余地が生まれる場合もある。

そもそもプロダクトがうまく回らなければ負債を返却しても意味がないため、状況によっては負債化の加速も正しい対応になる場合もある。

まとめ

ここまで技術的負債をベースにしてプロダクト負債というものの検討を行った。

負債はプロダクト運営を行っている以上避けられないが、必ずしも避けるべきものではなく、場合によっては積極的に取り入れていくべき状況もありえる。

ただし、負債には一定のリスクがあり、状況把握と返済計画のない負債は破綻につながる場合もある。

技術的負債の概念には20年以上の蓄積があるが、プロダクト負債の概念は比較的若い概念のためこれからの蓄積が必要である。

参考

プロダクトが進捗していないと感じた時の戦い方 - hikoharu's PM blog

[product-focus]

Tomasz Tunguz about product debt and how to handle it. With KPIs for defining when a feature has to be removed because it's not worth its maintenance or isn't used by enough customers.

[gabrielgciafdez]

If you’ve spent any amount of time around developers you should be familiar with the term technical debt. Turns out, there’s another kind of debt. Product debt is obvious when you see differences where there shouldn’t be any. Consistency in product design is critical. You need to invest in paying down your product debt on a regular basis.