Technical Debt Workshop (リンク)は最近、「技術的負債(リンク)」に対する業界の理解と扱い方の向上に取り組みつづけており、その結果として興味深いアイデアが生まれている。その中で、私たちの問題にたいする見方は「負債」よりも「資産」にフォーカスをあてたものに変わり、あるアイデアは現在 Michael Feathers 氏や Brian Marick 氏といった人々の注意をひきつけている。
カンファレンスを主催している Matt Heusser 氏と Steve Poling 氏は 2 日間にわたるイベントのビジョンを次のように語った。
カンファレンスでは、次の 3 つの主要な問いに答えることが目標とされた。技術的負債についての議論をしっかりと地に足のついたものにするための数値的指標を定めることができれば、会議は成功だ。それは、トラブルを借りるのとお金を借りるのが同じだと言っている私たちの頭が悪いわけではないという証拠をあつめることにもなる（あるいは、別の原動力が働いていると証明できればもっとよい）。負債の管理と返済戦略、そしていつ負債を負うべきかについても提示したい。
- 技術的負債とは何であって、何でないのか？
- どうやって技術的負債とそのインパクトを測定すればよいのか？
- 技術的負債をほかの負債のように管理できるのか？
- 無知: だめなコードは完全な無知か意識的な決定の結果としてかのいずれか、または両方から生まれる。詳しくは Brian Marick 氏によるこの記事を(リンク)読んでほしい。
- バグフィックス: バグは見つけたらすぐに修正しなければならない。stop-the-line （生産中止）の文化を(リンク)育成しよう。
- モラルハザード: チームに対する顧客の適切な影響力が欠けていると、スピーディだけど品質のわるい開発が、有害なかたちでひきおこされる。このコンセプトは Heusser 氏によって導入された(リンク)。
- インピーダンスミスマッチ: 開発タスクの困難さと開発者のスキルのミスマッチがコードの品質におよぼす可能性のあるマイナスの影響。詳しくは Chris McMahon 氏によるこの記事を(リンク)読んでほしい。
- 不安定な資産: たぶん、「技術的負債」という用語は私たちの視点を間違った方向に向けてしまう。逆に、ものごとへの投資という側面（McMahon 氏が最近提唱したように）にフォーカスをあてれば、もっと効果的かもしれない (リンク)。
- アフォーダンス: チームが規定の時間内に技術的負債を減らして「資産を増やす」実験をしてみよう。
たぶん、上述のアイデアのうち、もっとも興味深いが新鮮味のないものは、「資産を増やす」よう努めるという別の視点から技術的負債を考えることだ。会計の基本的な貸借の考え方で言い換えると、負債の減少と資本や利益の増加、どちらにフォーカスをあてることもできるけれど、最終的に理想的なゴールとは単純に資産を増やすことである。
イベントの直前、Michael Feathers 氏は「資産としてのコード(リンク)」というアイデアについて記事を書いた。コードを「資産」という視点から見るという彼の論旨は、人間の本性のより望ましいポイントを刺激し、コード品質を重視し「技術的負債」問題に反応する、というよりよい結果を生むかもしれない。彼によると、人間は性分として「資産」を得ることを好むが、「負債」をなくすことには無頓着なので、この考えはうまくいきそうだという。
Brian Marick 氏は後に議論をつづけ、「豊かな資産(リンク)」という用語をつかい、持続可能な開発におけるコード品質向上にむけた努力を言い表している。彼はガーデニングのたとえをつかい、収穫をつづけるためには土壌を豊かなまま残しておかなければならないが、だからといっていつも絶対的に最高の豊かさが必要なわけではない、それを突き詰めれば収穫などできない、と表現している。プロダクションコードも同じだというのが彼の見解だ。
さらにひとつ、簡潔ではあるけれどかなりおもしろい記事がワークショップから生まれている。その記事も Brian Marick 氏によるもので、技術的負債を減らすタイプの典型的なチームはどういう点が違うのかについて(リンク)、何人かのアジャイリストの発言をとりあげている。
いつものように、リンク先を参照してこの記事でまとめられている情報の全体像を把握したうえで、またこの記事に戻ってきてほしい。そして、これらのアイデアについて思索を深めることのできる別の情報をみなさんの経験の赴くままに探してほしい。
原文はこちらです：