技術的負債の「会計的」性質 – Ryohei Tsuda – Medium
負債とはなにかについてわたしたちが理解していないという事実そのもの、あるいはこの概念の融通無碍であることそれ自体が、負債の力の基盤である。 デヴィッド・グレーバー 「負債論」 ソフトウェア開発において、欠陥のある未熟な実装によって機能の追加や修正が難しくなることを、借金に喩えて「技術的負債」と呼ぶことがある（Wikipedia）。 現代のソフトウェアはもはや「サービス」に近い製品が多いが、サービスは顧客に受け入れられて初めて収益を生み出すことができる。広く使われているソフトウェアも最初は数少ない機能にたくさんのバグを添えてリリースされ、試行錯誤を経て顧客に受け入れられる。つまり、機能の追加や修正が難しくなることは、それ自体が潜在的な損失と言える。 しかし、私にはこの「技術的負債」という言葉は会計上の「借金」とは随分と異なる意味を持っているようにも思える。というのも極端な話、もし機能の追加や
技術的負債とどうやって戦うか - Qiita
プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」という本には下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで要求はどれも必ずと言っていいほど変わる やるべきことはいつだって与えられた時間と資金よりも多い 以上のことからわかるように、私達の開発には時間が無いということが常だということがわかります。実際、技術的負債が多いプロジェクトほどこの傾向が強いのではないでしょう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
