“Continued Delivery of High Values as Systems Age”(システムの年数を重ねながら、高い価値を提供し続ける)という最近の記事において、 Chris Sterling氏がソフトウェアの負債の概念について論じている。“ソフトウェアの負債は、長年にわたってシステムの変わりやすい性質を軽視し、急いで完成させることに注目し続けるときに蓄積していくものだ。”
ソフトウェアの負債は、一般的に技術的負債と言われるもの以上のものだ。
Sterling氏は、ソフトウェアのその他4つの負債も明らかにした。
- 技術的負債: 今はやらないことを選んだが、残ったままだと将来の開発の邪魔になること。
- 品質的負債: システム全体の機能的、かつ、技術的品質を検証する能力を減らすこと。
- 構成管理の負債: 統合とリリース管理がより複雑でリスクを伴うようになり、エラーが発生しやすくなること。
- 設計の負債: 平均サイズの機能を追加する費用が、その機能だけを書くよりも増えること。
- プラットフォーム経験の負債: システムの機能に取り組む人々の能力とコストが制限されるようになること。
Sterling氏は、ソフトウェアの負債がどのようにプロジェクトに入り込むかについて論じている。そして、複雑さが増していく状況において、しばしば熱心に取り組むのが納品ペースを維持することであるために、どうやって徐々に負債が蓄積していくかという見解を述べている。
同様に、Bill Curtis氏はソフトウェアプロジェクトにおけるMuda (「Muda」は、日本語の「ムダ」のこと) について論じている。もっとも一般的なソフトウェアプロジェクトのムダの元は、やり直し、つまり、ソフトウェアの負債の結果だ。
やり直しに関する数少ない調査によると、プロセスの改善で失敗するたいていの組織は、やり直しがプロジェクト努力の30%から50%を占めるという報告がある。やり直しに関する数字は、集めるだけでなく、落ち度を認めるという点で難しい。アプリケーションに対する投資において平均40%を捨てたことを認めたい経営者はほとんどいない。
Sterling氏は、ソフトウェアの負債を管理して減らす方法を提案する。
- 1つの作業リストを維持する
- 品質を重視する
- ツールとインフラを継続的に進化させる
- 常にシステム設計を改善する
- 組織全体で知識を共有する
- もっとも重要なのは、ソフトウェア開発にふさわしい人々を雇うこと!
この記事の中で、Sterling氏はこれらのポイントにそれぞれどのように取り組むかについて助言している。
そして、次のコメントで記事を締めくくった。
システムは年数を経るにつれて、扱うのがより難しくなります。技術的負債、品質的負債、構成管理の負債、設計の負債、プラットフォーム経験の負債を通して、ソフトウェアの負債がシステムに入り込んだとき、ソフトウェア資産は負債になります。
この記事にある6原則を適用することで、小さな変化をもたらすでしょう。これらの小さな変化は、長い間にチームや組織にとって意味のある明確な変化になります。 ソフトウェアの負債を管理する目的は、ビジネスにおけるソフトウェア資産の価値を最大限に活用し、顧客が使うソフトウェアに対する顧客の満足を高めることです。
組織は、どのようにソフトウェアの負債を減らし、ソフトウェアシステムに対する投資を守るだろうか?