@ledsun blog

Hのキーがhellで、Sのキーがslaveだ、と彼は思った。そしてYのキーがyouだ。

技術的負債の数え方

技術的負債の数え方に関する与太話。 落ちを先に書くと「シュレディンガーの猫」って言いたかっただけです。

技術的負債とは

Ward Cunningham 曰く

最初のコードを出荷することは、借金をしに行くことと同じである。
小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。
危険なのは、借金が返済されなかった場合である。

品質の良くないコードを使い続けることは借金の利息としてとらえることができる。
技術部門は欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、
立ち尽くす羽目になる

技術的負債 - Wikipediaから引用

要約すると「汚いソースコードは後で直すのが大変。けど、拙速も大事」という話です。

数え方

「技術的負債が借金だとすれば、いくら借りているのか数えられるのでしょうか?」が今日のお題です。

技術的負債を観測する方法

Michael Feathers の話を聞いた安井力さん曰く、 これに対してこんな方法があるようです

機能見積りトレンド (Feature Trend Cards)

ある機能の実装にどのくらい時間がかかるか見積もる。
で、実装しない。定期的に同じ機能を見積もる。
もし見積りが大きくなっていたら、それは負債が増えているということだ。

リファクタリングしてみる (Scratch Refactoring)

やりたいように大規模にリファクタリングをする。
でも保存しない(コミットしない)し、動かなくてもいい。
どんな感じかつかむためで、そこから情報を得る。

こちらはレガシーコード改善ガイドに載っているそうです。

これらの方法に対する疑問は

  • 「機能追加」や「リファクタリング」は実際に起こるのでしょうか?
  • いつまでも見積もれる「機能」は追加しなくてよいのではないでしょうか?

変更しないと技術的負債は観測できない

例えば、インデントが揃っていない、変数名が連番のソースコードがあったとします。

  • 変更を設定で吸収できた場合は、技術的負債は見つかるでしょうか?
  • ソフトウェアが変更されなかったら、技術的負債は見つかるでしょうか?

ソフトウェアを変更してみるまでは、技術的負債は観測できません。

技術的負債はシュレディンガーの猫である

シュレディンガーの猫とは

この実験で箱のなかの猫は、放射性物質のアルファ崩壊という量子力学的な振る舞いにのみ生死が
決定するため、観測者が箱を開けて中を観測しない限り、猫は 量子力学のウィグナーらが唱えた
確率的解釈により生きている猫と死んでいる猫が50:50で重ね合わせで存在している事になる。

つまり箱の中の猫はふたを開けて観測するまで、生きてもいないし死んでもいないのである

シュレーディンガーの猫とは (シュレーディンガーノネコとは) [単語記事] - ニコニコ大百科から引用

技術的負債は、この「シュレディンガーの猫」のような存在に思えます。 変更を加える前は「技術的負債」は有りも無くもしないのです。

「技術的負債」が問題になるソフトウェアの変更は予想できません。 「予想出来る変更」は設定で吸収できるようソフトウェアを設計すれば対応できます。 「技術的負債」は問題になりません。

「技術的負債」は予想できない変更に依存します。 変更を加える前は「技術的負債」は「有る」と「無い」が重なりあった状態です。 変更を開始して「技術的負債」が観測された時に状態が収束します。

この仮説が成り立つなら、量子の観測と同じ方法で定量的に評価できそうです。

量子の観測方法を借りてくる

ソースコードは技術的負債は持たず、技術的負債を発する能力「技術的負債能」を持つと考えます。 *1

具体的には、イテレーション中に「技術的負債」を発見したらカウントアップします。 あるイテレーションでは技術的負債が30発見され、別のイテレーションでは100発見されます。 発見数をグラフ化すればトレンドを見ることができます。 *2

ボウリングの観測方法を借りてくる

イテレーション毎に変更内容は変わります。 イテレーション毎に発見する「技術的負債」数も変わります。 どうすれば異なるイテレーションの「技術的負債」数を比較できるでしょうか?

ボウリングでは、レーンとの相性や体調の変化により1ゲームのスコアに変動があります。 レベルの異なるプレイヤーを集めて大会を開くにはハンディキャップの設定が必要です。 一般的な大会では、ある程度公平なハンディキャップを決めために、 30ゲームのスコアの平均を使っています。 つまり30ゲームのスコアの移動平均でプレイヤーの能力を測っています。

これを真似て、30イテレーション移動平均を取れば有効な数値が取れそうです。

技術的負債にはビジネスが含まれている

この値にはビジネス価値に依る変更箇所の偏り、 ビジネス環境の変化による変更箇所の変動も含まれているはずです。

まとめ?

「技術的負債」はソースコードの属性ではありません。 チームの属性です。 また、ただの技術力の指標ではなくビジネスの予測力を含みます。

*1:放射線放射能のメタファーです。

*2:簡単に書いていますが、変更時にはたいてい技術的負債が見つかります。発見数は単にストーリー数やストーリーポイント数になりそうな気がします。

広告を非表示にする