InfoQ ホームページ TechnicalDebt に関するすべてのコンテンツ
-
技術的負債を防ぎ、返済する方法：チームと技術リーダー、マネージャーができること
技術リーダー、プロジェクトマネージャー、管理職は、ソフトウェア開発者に多くの時間を与えることで技術的負債を防ぐことができる。さらに、チームがコードを改善できるように、余剰時間やリファクタリングスプリントを計画することができるとNedelcho Nikolov氏は主張する。技術的負債に優先順位をつけるために、開発チームは、今投資すればどれだけの時間を節約できるか、今技術的負債を返済しなければ将来ソフトウェアがどれだけ複雑になるかを示すことができる。
-
機能フラグによるモバイルアプリ内の到達不能コードをどうするか - Uberの場合
Uberが新たにオープンソースとして公開したPiranhaは、Java、Objective-C、Swiftで記述されたAndroidおよびiOS用のモバイルアプリから無効なコードを削除するためのツールだ。実装した機能フラグ(feature flag)を最終的に削除する、というプロセスから生じる技術的負債を確実に解消する目的でこのツールは誕生した、とUberは述べている。
-
Meetupでの技術的負債の取り組み
継続的に製品の健全性を保つには定期的に一番影響のある技術的負債を優先順位付けして、それらを全体的に解消していくことだ。MeetupのCTOであるYvette Pasqua氏は、技術的負債に対する取り組み方を継続的に繰り返し適用することでより大きな成果を生み出すことを推奨している。最も影響の大きい負債から取り組み、その負債を解消したことで生まれる改善について伝える、というのが氏の主張だ。
-
古いシステムと現代的な技術のギャップを埋める
手動で時間のかかるやり方で管理されている、長年動かし続けているプラットフォームはコストがかかる。チームは経営陣に対してビジネスケースを作ることで、繰り返し作業やヒューマンエラーで失われた時間に基づいて、自動化ツールやコンテナのような現代的な技術を導入して改善ができる。結果として、配置作業は予測可能で反復的なプロセスになり、配置も頻繁かつ安全に行えるようになり、人間の介在も最小限になる。
-
モノリスあるいはマイクロサービスの技術的負債を占う水晶玉 - Amam Tornhill氏の考察
QCon LondonでAdam Tornhill氏は、“A Crystal Ball to Prioritise Technical Debt”と題して講演し、技術的負債のメタファがソフトウェア界に浸透したにも関わらず、いまだ大部分の組織が技術的負債の優先的な返済に苦慮している点を指摘した。講演では、“コードの複雑性とチャーン(churn)の‘ホットスポット’を特定するには”、などの話題が取り上げられた。
-
優れたエンジニアリングプラクティスによって"常に出荷可能な製品”を実現する
優れたエンジニアリングプラクティス(Good Engineering Practice)は，アジャイルチームが出荷可能な製品を提供するためのツールだ。効果を証明されたエンジニアリングプラクティスはたくさんあるが，期待されるほど広くは活用されていないのが実情である。結果として，アイスクリームコーン型ソフトウェアテストなどアジャイルのアンチパターン，技術的負債の蓄積，機能的サイロが，リリース可能な製品の提供を妨げているのだ。
-
コード品質の測定と改善
InfoQはBoris Modylevsky氏にインタビューして，コード品質を測定することの重要性，その測定結果を品質改善に利用する方法，継続的インテグレーションへの静的コード解析の統合，テストカバレッジとテストの自動化，統合型コード解析とテストカバレッジを継続的インテグレーションと組み合わせることのメリットについて聞いた。
-
大規模システムの保守における技術的負債とチームのモラル
Agile Testing Days 2015において、Thomas Bradford氏はテストがなく大きな技術的負債のあるモノリシックなJavaベースのシステムの保守に関する経験について語った。 InfoQは、システムを保守する上での問題や作りこまれた技術的負債、なぜ別のアプローチをとったのか、どうやってチームのモラルを向上させたのかについて氏にインタビューした。
-
総保有コストを使った技術的負債の管理
総保有コスト(TCO)は、投資の意思決定やファイナンスの分析で使われる。これをソフトウエアに適用すると、初期の開発コストや、製品が提供停止になるまでのメンテナンスのコストをカバーできる。TCOは設計上の決定や技術的負債の管理をサポートする。
-
組織的負債に対処する
ニューヨーク大学で講師を務めるSteve Blank氏はブログで、技術的負債に似た概念である組織的負債について書いている。成長する組織は組織的負債を認識し解消する方法を理解する必要がある、と氏はいう。
-
"アンヘッジド・コールオプション"はバッドコードに対するメタファとして適当か
バッドコードと技術的負債に関するブログ記事で，Steve Freeman氏は，Chris Matt氏がバッドコードを表す"ヘッジされない(unhedged)コールオプション"というメタファを思い付いた経緯について説明した。この記事が今，RedditとHacker Newsで激しく議論されている。InfoQでは，バッドコードとコードの臭い(code smells)に対するメタファの使用，低品質コードのトレードオフとコスト，コード品質に対する責任などについて，両氏にインタビューした。
-
テスト容易性のためのシステム設計
テスト容易性(Testability)にはシステムで明示的な設計が必要だ，とSiemens AGのPeter Zimmerer氏はいう。テストアーキテクトはテスト容易性を推進すると同時に，優れた設計とエンジニアリングプラクティスを採用するためにシステムアーキテクトや設計者，テスタともコラボレートしなければならない。氏はQA&Test 2014カンファレンスで，組み込みソフトウェアにおけるテスト容易性の設計についてのチュートリアルを実施した。
-
スプリント計画ゲーム "Rocket to Mars"
"ほとんどのチームとそのプロダクトオーナは，より多くのストーリポイントを達成することがチームの唯一の責��だと信じています。しかしこれは，チームとプロダクトオーナの関係を完全に誤解したものだ，と私たちは考えます。" こう語るのはDamien Thouvenin氏とPierrick Revol氏だ。氏らはストーリの創出や問題の調査，技術的負債の削減，およびそれらをトレーニングするための時間的投資を題材としたスプリント計画ゲームを実施した。
-
-
技術的負債のユーザストーリーを作るべきか
アジャイルチームは、技術的負債を扱う仕事のように、純粋に技術的な仕事の計画に難儀する場合がある。このようなタスクは直接的にはシステムを利用する顧客のためにはならないが、問題なく動作するソフトウエアを提供するには避けて通れない仕事だ。このような技術的な仕事や技術的負債を扱う場合にもユーザストーリーを作るべきだろうか。