「技術的負債」は避けるべき？ - 割引率を使って考えてみた

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

ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。

「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。

初期開発コストと運用コストのバランス^注1を、どのようにとっていけば良いのでしょう？

同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします^注2。ソフトBは、初期開発工数が10で、維持工数が毎年1かかるとしましょう。ソフトAはPHPファイル１枚に必要な処理をひたすら羅列したクソコード、ソフトBはMVCを念頭にレイヤ分割された、きれいなコードなんてイメージすると、こんな工数感覚になってもおかしくないかと思います。

ソフトAとソフトB、どちらを開発すべきかという問いに対する答えが、そのソフトを使い続ける（改善し続ける）期間によって変わることは、表1を見ずとも明らかだと思います。では、その期間を合理的に見積もる手法が必要になります。

表1. 初期開発と維持工数

年度	ソフトA		ソフトB
	工数（単年）	工数（累計）	工数（単年）	工数（累計）
1	6	6	10	10
2	4	10	1	11
3	4	14	1	12
4	4	18	1	13
5	4	22	1	14

ここで登場するのが「割引率」という概念です。

割引率は一般に、将来の発生する可能性のある利益を現在の価値に変換して評価するために用いられる概念ですが、同様に、将来発生する可能性のある費用を評価する目的でも使うことができます^注3。

たとえば、新規サービスの場合を考えると、２年目も継続してサービスを改善しつづける可能性は決して高くないと思います（仮に改善を続ける可能性が50%だとすると、割引率（１÷改善継続可能性−１）は100%になります）^注4。n年後に改善を続けている可能性が0.5ⁿであるなら、現在価値に修正した累計コストは以下のような表になります。

表2. 初期開発と維持工数（割引率100%）

年度	ソフトA		ソフトB
	工数（単年）	工数（累計）	工数（単年）	工数（累計）
1	6	6	10	10
2	2	8	0.5	10.5
3	1	9	0.25	10.75
4	0.5	9.5	0.125	10.875
5	0.25	9.75	0.0625	10.9375

表からも明らかなように、ソフトAの累計工数がソフトBを上回ることはありません（厳密に言うと、ソフトAの割引後の累計工数が10に収束するのに対し、ソフトBの工数は11に収束する）。この結果はつまり、仮に翌年も継続してサービスを改善しつづける可能性が50%なら、ソフトBのアプローチよりも、ソフトAのアプローチのほうがコスト効率的に優れているということを示しています。

逆に、上場企業の事業の基盤となっているようなソフトウェアについては、割引率が10%を切ることがあってもおかしくないはずですが、仮にn年後に改善を続けている可能性が0.9ⁿ（割引率11%）であるなら、現在価値に修正した累計コストは下表のようになり、今度は逆に、ソフトBのアプローチの方が優れているということになります。

表3. 初期開発と維持工数（割引率11%）

年度	ソフトA		ソフトB
	工数（単年）	工数（累計）	工数（単年）	工数（累計）
1	6	6	10	10
2	3.6	9.6	0.9	10.9
3	3.24	12.84	0.81	11.71
4	2.916	15.756	0.729	12.439
5	2.6244	18.3804	0.6561	13.0951

以上のように、技術選択における正解は割引率の高低によって大きく左右されます。

また、割引率は事業の形態のみならず、ソフトウェアの種類によっても大きく異なります。私個人の経験を振り返っても、サーバサイドの管理用ミドルウェア → データベース等ハードウェアの能力に影響をうけるサーバサイドミドルウェア → クライアントサイドのミドルウェア → アプリケーションの順で割引率が高くなっていく印象があります。

適切な値がいくらか、ということは俄には答えにくい問題かもしれませんが、「割引率」という概念自体は経営層にとっては常識レベルのものなので、経営層と事業継続にかかる感覚値を普段から共有し、技術判断にフィードバックしていくということが、技術責任者に求められる役割なのかな、と思う次第です。

参考リンク：
とあるスタートアップを抜け、CTOを辞めた話。 - nobkzのブログ
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - delirious thoughts

注1: 企業の情報システム投資では、初期コストに保守等のコストを加えた「総所有コスト（TCO）」の極小化を目標とするのが有効なアプローチだと考えられています。
注2: ソフトウェアが陳腐化する外的要因は周辺技術の進歩です。その速度は一定であると置くのが妥当ですから、ソフトウェアの保守コストは毎年一定であると考えるのが正しいことになります。「ソフトウェアの保守が時間とともに難しくなる」と感じられるとしても、それは過去の保守投資が過小であった結果だと解釈すれば良い話です。モデルを無駄に複雑化する理由はありません。
注3: つまり、事前に使用年数を見積もることが困難なシステムがあるなら、通常のTCOではなく、保守を続ける年数を確率分布として修正したTCOを用いてコストを予測すれば良いということです。
注4: 割引率は毎年一定になるとは限らないでしょう。たとえば２年間で資金を使い切る前提でサービスを提供している場合には、２年間は割引率が低く、３年目にがくっと上がる形（失敗するサービスが過半であるという前提を置くなら、それこそ100%を超える値）になると思います。