技術負債について考える。
まずwikipediaから引用：
技術的負債（英: Technical debt）とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である[1]。「設計上の負債(design debt)」とも言う。
そうなんですよ。技術負債は、まず設計とアーキテクチャの話です。
よくみるどう技術負債と戦うかの記事は、
コーディングや負荷や安定性やセキュリティやメンテナンス性や依存性などを細かく運用の話を説明しますが、
そこだけではないですね。
最近聞いた話ですが、ある社内技術負債PJの工数見積もりが出ていて、何万、十何万人月の話が出ていてるらしい。
ありえないなぁと思います。
個人的に、技術負債対応はwaterfallではなく、アジャイルです。
なのでシステムがリリースしたタイミングで、新しい技術負債が生まれたため、技術負債を常に開発目標にしないといけません。
大きな技術負債が存在することは、ある意味では業務怠慢で経営リスクとも言えます。
それでは具体的にどうするかと言うと、「疎結合化」だけです。
プロダクトがリリースされたら、次のスプリントで、じゃ疎結合化の対象がどこかを探すわけです。
次のスプリントと言うのは、プロジェクトによりますが、一週間後のチームもあるし、一ヶ月後のチームもあります。
ですので、一週間や一ヶ月単位で、技術負債のターゲットを決めて、リリースしていくしかないです。
ですので、技術負債のために、PJを立てて、何十万人月の予算を取ることが非効率で、
昔の技術負債を解決できるかもしれないが、永遠に対応できません。
もちろん大きな技術課題もあり、数ヶ月で終わらないシステムがよくあります。
だからこそ重点なシステム脆弱性と認定し、ここにリソースを一気に投入して、疎結合化させないといけません。
アーキテクチャーの設計変更が絶対必要なので、IFの互換性を意識して、
依存関係者が最小限の変更で対応できるようにします。
よく見る失敗は、関係者が多いシステムがダラダラするケースがほとんどですから、開発コストがどんどん膨らむ一方です。
それはダメで、解決には「快刀乱麻」の覚悟が必要です。
でも高いマネジメント力と政治力がないとなかなかできないので、成功できるプロジェクトが稀だと思いますけど。
技術負債の可視化が大事ですね。
AサービスのBシステムのCサブシステムは、結合度couplingがどの位があり、
そこに技術負債になり得る技術要素を
（コーディングや負荷や安定性やセキュリティやメンテナンス性やDBやバックアップやリカバリーやライブラリやベンダーなどなど、詳細まで全部展開したら一冊の本が書けますけど）
負債台帳もしくは負債番付表にして、
関係者全員で定期的に共有及び見直すことがお勧めします。
そういう意味では、技術負債の返済は、1種のリスクマネジメントとも言えるでしょ。
セキュリティ対策はエンドレスであるに書いたように、
技術負債は住宅ローンの返済と違ってエンドレスであります。
ですのでアジャイルが必須で、
プロダクトバックログに負債台帳見直要件を追加し、
スプリントごとに疎結合化の設計タスクを入れるようお勧めします。
注：
ここで言っている疎結合化（英語:decoupling、中国語:解耦、去耦合）の対象は、モジュール間の結合度だけではなく、もっと広い範囲のものを指します。
たとえば特定な開発ベンターや特定なクラウドサービス依存もありますし、特定なライブラリ、場合によって特定なエンジニア依存もあります。
Comments