先のエントリ「もう携帯開発やデジタル家電の開発現場は破綻しているのではないか」を書いたところ、Twitterで教えて頂いた。
私自身、この「技術的負債」という言葉は初耳だったのだが
Martin Fowler's Bliki in Japanese - 技術的負債
技術的負債 - Wikipedia
これらを読んでみると、まさしく先に書いた状況と同じなのではないかと思う。
技術的負債（英: Technical debt）とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。
開発組織は自分たちの負債をコントロールできず、将来的な開発のすべてを利子を払い続けるということに費やさねばならないわけだ。
先々破綻すると分かっていながら負債を抱える方向へ進む、あらゆる物を犠牲にしても「いま」を乗り切らなければならないなど理由は様々あるのだろうが、大抵の場合はその負債を返済することはできずに、そのシステムやソースコードを完全に捨てるまでツケを払っていくのだろう。
- 追加機能の開発でベースの設計・実装の質が悪いため無理矢理な追加実装を行ってしまう
- 開発メンバーがある程度入れ替わったあとで、不意のバグが発生するがソースを読んでも処理が理解できないほど作りに問題がある
- 技術的負債を減らそうと、該当のソースを作り直そうとするが他のモジュールと結合度が高い状態で自担当範囲だけでの作り直しが難しい。かと言って他チーム（大規模開発の場合、多くは他社）に協力を求める事もできず（他社にかかる修正コストの負担が難しい）、十分な作り替えが行えず、悪い実装を引きずる。
ある程度、プラットフォームや全体のシステム設計を入れ替える（リセットする）チャンスがあるようなプロジェクトであれば良いのだろうが、継ぎ足し開発を繰り返す派生開発がメインの、組み込み系などでは一度作ってしまった仕組みを大きく変えるきっかけが非常に限られる。また開発者は今の設計や実装が悪いことは知りつつも、改善する余裕も無いまま次の開発にかからなければならない事がほとんどなので、手つかずになってしまう。
なので、初期バージョンやゼロベースでの開発における設計や実装はとても重要だと思う。あとから修正するチャンスがあれば良いけど、それが今後の派生開発で見込めないときは最初ほど慎重に設計・実装しないと後から首を絞められることになる。そうは言っても、最初に一度全体を作ってしまった後のほうが「別の設計でやったほうが良かったな」などと気づくことが多いので、そう簡単にはいかないのだけど。
