総保有コスト(TCO)は、投資の意思決定やファイナンスの分析で使われる。これをソフトウエアに適用すると、初期の開発コストや、製品が提供停止になるまでのメンテナンスのコストをカバーできる。TCOは設計上の決定や技術的負債の管理をサポートする。
Hans Sassenburg氏はBits&Chips Software Engineeringカンファレンスで、総保有コストの分析について話をした。氏は公演の中で、TCOという概念を"売り込む"のに使える、いくつかのメタファを提示した。技術的負債というメタファはわかりやすいが、氏によれば、製品のライフサイクルで技術的負債の増大を認め、アクションを起こすのは難しい。
InfoQは氏にインタビューをし、ソフトウエア開発を管理するためにTCOという概念を使うことについて、技術的負債の主要な原因と負債削減方法、負債が積み上がらないようにする方法、R&Dの投資とコストを管理すること、ソフトウエア製品の品質の改善について話を聞いた。
InfoQ: 総保有コストについて簡単に教えてください。
Sassenburg: TCOという概念は100年以上前からあります。その起源は20世紀の最初の四半期に求められます。1980年代にガードナーグループが広めました。金融の分析の世界では、TCOは原価基準を提供し、投資の全体の経済価値の決定を支援します。例えば、車を買うとします。TCOは購入した時点からの自動車を保持するコストから、その自動車を手放すまでの利用やメンテナンスに必要なコストを定義します。さまざまなモデルのTCOを比較することで、顧客は必要や予算に最適な自動車を選択することができます。また、TCOはソフトウエア産業にも応用できます。ただし、少し解釈が違います。ソフトウエア製品(スタンドアロンであれ組込みシステムの一部であれ)の全体のコストを考え、初期開発とそれに続くメンテナンスフェーズを区別します。"メンテナンスフェーズ"という概念はここではミスリーディングです。このフェーズではバグ修正をするだけではなく、新しい機能も追加するのですから。要約して言えば、ソフトウエアのTCOとはロケット科学ではなく、ライフサイクル全体で分割されてしまっているトータルのコストの見積もりを考えます。
InfoQ: 最初の製品開発のときの意思決定がどのように製品のライフサイクルコストに影響を与えるのかを教えてください。
Sassenburg: 最初の開発での共通の落とし穴は、提案されたアーキテクチャを評価するための非効率な努力が残ってしまうことです。加えて、妥協が生まれます。時間的な制約があり、提案されたアーキテクチャが複雑すぎて、非数理的な手法で評価ができないからです。そして、最初のアーキテクチャで未知の機能拡張を考慮するのは難しいのです。
アーキテクチャ設計のあと、実装が始まります。ソフトウエアエンジニアは新しい機能を作るのにふたつの異なる選択肢があります。ひとつは、素早く、汚く作る方法。この方法では、将来の変更はとても難しくなります。もうひとつはスマートできれいなやり方で、実装に時間がかかりますが、将来の変更はしやすくなります。汚いコードやテストカバレッジが限られているコードでも、望ましいビジネス価値を提供できていれば、顧客にとって問題ないかもしれませんが、柔軟性のない製品になってしまいます。汚いコードは、信頼性、テスト可能性、メンテナンス性を著しく悪化させます。結果、生産性と品質が損なわれるのです。
InfoQ: 技術的負債の主要な発生源はなんだと思いますか。
Sassenburg: ふたつあります。先の質問に対する回答がそうです。ひとつは設計フェーズでの間違った意思決定と妥協です(設計の負債)。そして、低品質のコード実装で負債が膨れ上がります(コードの負債)。これがふたつめです。
InfoQ: 技術的負債削減方法や負債増加防止策を例示していただけますか。
Sassenburg: 既存の負債をどのようにして削減するか、から話を始めましょう。普通、コードの負債はリファクタリングで削減できます。例えば、汚いコードを再構造化するのです。成功するアプローチは、各リリースでコードの品質を改善するための労力を確保する方法です。加えて、厳しめのコーディング基準を導入し、コードの変更が低品質にならず、新しいコードがコーディング基準を満たすようなルールを強制することです。難しいのは設計の負債です。小さなリファクタリングでは解決できません。その代わり、製品の小さな部分、あるいは大きな部分を再設計する必要があります。これは、コンポーネント、モジュール間のインターフェースに影響を及ぼします。望ましいのは、既存の設計負債を削減するためのリリースを1度以上、スケジューリングすることです。これには、マネジメント/ビジネスサイドのサポートが不可欠です。新しい機能の提供が遅れるかもしれないのですから。
InfoQ: 投資や開発、メンテナンスコストを管理するためのより良い方法を探している、R&Dマネージャにはどのようなアドバイスができるでしょうか。
Sassenburg: 技術的負債を完全に避けれるかどうか、というのが妥当な問いかもしれません。もし、避けられるのであれば、開発もメンテナンスをカバーするライフサイクル全体の総保有コストは最小にできます。投資の視点からは、これは望ましいです。設計の意思決定の場合、形式的な手法を導入して設計を検証するのが良いでしょう。さらに、検証されたモデルからソースコードを自動的に生成できるなら、低品質なソースコードから生まれる技術的負債の削減に一役買うでしょう。公式的手法(Verum Software ToolsのDezyneのような)を使うというポジティブなトレンドがありますが、まだ、広まるまでに時間がかかるでしょう。
公式的な手法の導入が企業にとって早すぎるのなら、ふたつのアドバイスがあります。時間の圧力が強力な場合でも有効です。ひとつは、複数の設計案を評価するのに十分な時間を確保することです。Software Engineering Instituteはこの領域についていくつかの手法を開発し公開しています(例えば、ATAM)。もうひとつのアドバイスは、厳しめおんプログラミング標準とテストカバレッジ(特に単体テストで)を高くすることを強制することです。TIOBE Quality Indicator (TQI)はコードの品質を定義し、マネジメントの観点からモニタリングする方法を示している良い例です。
InfoQ: 製品の品質を管理する上で、より良いコミュニケーションを可能にするために何ができるでしょうか。
Sassenburg: マネージャとエンジニアの間のコミュニケーションを改善する必要があるかどうか、ということだと思います。多くの組織では、R&Dのマネージャに説得力が必要だということではありません。優れたマネージャは技術的負債を管理しなければ、大変な問題になるということを理解しています。
R&Dの外にいるビジネスマネージャの方により問題があるかもしれません。ビジネスマネジメントは、普通、ソフトウエアエンジニアリングのR&Dの重要さを理解していませんし、R&Dの成果に対する貢献を低く見積もっています。R&Dのマネージャは反対の問題に直面します。彼らは、ソフトウエアエンジニアリングの重要さを深く理解していますが、この重要さをビジネスマネジメントに伝えるのは不可能に近いと考えます。そして、彼らが、デリバリの圧力に直面していること、そして、デリバリの成果は、R&Dの外にいるマネージャによって、品質ではなく、納期を基準に評価されるのは、共通の課題です。言い換えれば、R&Dの外と内にいるマネージャの間でのコミュニケーションの余地は大いにあると思います。
この間にある障壁を克服するのにレゴで家を作ることを喩えにする方法があります。設計エクササイズを実施し、間違った基礎(つまり、悪いアーキテクチャ)を選択し、間違った色のブロックを選ぶ(つまり、プログラミングを失敗する)ことが、将来、R&Dだけでなく、ビジネスにも巨大な問題を導くことを示すのです。新しい機能の追加が、次第に高価になり、時間がかかるようになり、顧客のエラーに対する不満は増えます。こんなエクササイズは半日もあればできます。
Bits&Chips Software Engineeringカンファレンスは6月3日にオランダはアイントホーフェンのHigh Tech Campusで開催された。
現代の産業システムにおいて、強靭で信頼性の高いソフトウエアを開発するのは、大きなチャレンジです。ソフトウエアは次第に、ビジネスに競争力をもたらす知的財産であり、成功している多くの成長企業が頼りにする大きな柱になっています。しかし、規律としてのソフトウエアエンジニアリングは組織のニーズに答えることに失敗しています。組織はますますソフトウエアに依存しているにも関わらず、です。
The Bits&Chips Software Engineeringカンファレンスは、リーダーを集め、現在と未来のソフトウエアシステムのエンジニアリングについての官学の知識、アイディア、経験を共有します。
InfoQはこのカンファレンスの模様をニュースや記事で紹介している。先週は下記のインタビューを公開した。