「技術的負債」をコントロールする定量評価手法への期待

「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - delirious thoughtsにて、追記でコメントいただけたので、外野として好き放題言わせてください。すばらしいスライドありがとうございます＆いつもすみません。

僕が興味がもつとすると、それは「技術的負債」の定量評価手法についてです。

なぜ、そういう前提を置くかと言うと、それは、たとえばKrutchenによる「技術的負債」の定性評価は、とてもわかりやすいものの、技術を取捨選択するツールとしては使えないからです。

スライドでは、技術評価における将来の不確定性を象徴する問題としてSSDの普及前夜にシャーディングをがんばって実装してしまう例をご紹介いただきましたが、実際、そのような不確実性を織り込んだ正しい決定を我々が日々のエンジニアリングで下すことができているのか疑問に感じることが多いです。思いつくがままに挙げると、例えば以下のようなことを疑問に感じたことがあります。

• ライブラリやフレームワークを採用するにあたり、その将来性を何年程度のスパンで評価すればいいのか
• struts1は「技術的負債」
• node.jsのexpressは技術的負債になろうとしている
• ウェブサービスを開発するにあたり、最初からシャーディングの機能を作り込むことは正しいのか
• それとも、サービスが当たってからシャーディング機能を実装するほうが利益は大きいのか
• プロトタイピングにおいて、きれいな実装を行うべきなのか、それとも汚くても早期に実装できたほうがいいのか
• プロトタイプのコードをサービスインする確率によって答えは変わるはずだが、その確率の閾値はいくらなのか

これらの例からもわかるように、ライブラリ等の部品を選定する際の評価や、規模拡大や拡張を前提とした作り込みの程度を決定するには、「技術的負債」についての定性評価ではなく定量評価が必要です。そして、kentaroさんによる「割引率」という概念の導入は、それを可能にするという点で、僕には興味深く感じられます。

感覚的に言うと、

• 割引率は、ある期間の後にそのソフトウェアをメンテすることになる可能性
• 期間毎の割引率に「技術的負債」の解消に必要なコストを掛けて積分したものが、予測されるTCO
• 予測されるTCOを最小に抑えるのが、正しい技術的選択

のような形として、定量的に評価し、現時点において正しい選択を取るためのツールとして「技術的負債」を使うことが可能になるのではないか。

「これからはnode.jsでしょ」とか「サービスがヒットしたら必要になるから、シャーディング機能は作り込むべき」といった感覚論ではなく、技術的判断をサポートする定量評価手法として「技術的負債」を使えればいいなと思う次第です。


23:37追記: ↓とのことです。ありがとうございます。

スライドでは詳しく書けなかったんですが、彼らは定量評価のためのモデルを提案しています。kazuhoさんの問題意識は僕のそれとも一致していて、そうした観点からは不十分なものなですが、道は開きつつあると思います / “Kazuho's…” http://t.co/jFKPNWJn6R

— kentaro (@kentaro) March 17, 2014