SSブログ
技術的負債 ブログトップ

技術的負債(6) [技術的負債]

Becoming a Better Programmer: A Handbook for People Who Care About Code

Becoming a Better Programmer: A Handbook for People Who Care About Code

  • 出版社/メーカー: O'Reilly Media
  • 発売日: 2014/10/03
  • メディア: Kindle版

この本の「Chapter 13: A Tale of Two Systems」からの抜粋(p.122)です。

Technical Debt

Technical debt is a term coined by Ward Cunningham that’s widely used in the software industry today. The metaphor leans on the financial world: making a decision to help ship software quickly is like taking on a loan. It can enable you to do something now that you would not otherwise be able to do.

But you can’t ignore that loan—you always have to pay it back. The longer it takes to pay back, the more it costs you. If you fail to make timely repayments, you’ll be stuck paying off interest on the loan, and your purchase power diminishes.

In the software world, that means return to your code to update it, or else your progress will slow as the code bogs down in accrued debt. This is important: in the long run, lower code quality means longer development times, but a responsible short-term loan can speed things up.

Technical debt might be deferred refactoring, design adjustments that reflect what you’ve discovered, waiting to update libraries or toolchains until after the next major release, or rationalising the logging/debugging scaffolding.

This is a colourful metaphor that can be misused: technical debt does not just mean doing something badly. Sometimes writing bad code is justified as being “pragmatic”; there is a difference between a pragmatic choice and a sloppy one.

Consciously managing technical debt is a powerful weapon in your development arsenal. Don’t let debt build up, and keep it visible. Like a real loan, pay back debt as early as possible to avoid suffering excessive interest and charges.
技術的負債に全く関心を払っていないソフトウェア組織が最後はどうなってしまうのかというのも関心事ですが、最近の個人的関心事は、そのような組織で働くことで個々のソフトウェアエンジニアの成長に対して何が起きるのかということです。

書籍『A Practical Approach to Large-Scale Agile Development』(2) [技術的負債]

A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development Series)

A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development Series)

  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2012/11/15
  • メディア: Kindle版

先日紹介したこの本には、技術的負債とういうことはあまり話としてはできてきませんが、日々の開発活動を通して、技術的負債を少なくすることができる開発プロセスの確立とも言えます。

技術的負債に関しては、過去に以下の記事を書いていいます。

技術的負債を残し続けるというのは、長期的に見れば、その開発組織のソフトウェア開発力を徐々に下げて行くことになっていきます。

「技術的負債(3)」では、次のように書いています。
見方を変えると、技術的負債は、将来性のある若手をきちんとしたソフトウェアエンジニアとして成長させる場を奪ってしまうことになります。良いコードを書くという機会もなく、リファクタリングを経験する場もなく、過去に誰かが作った負債と格闘させるだけとなります。そのような状況では、ソフトウェア開発にもともと興味がない人は、負債を膨らませていくだけでしょう。一方、意欲のある若手は、成長できないため会社を辞めていくことになります。その結果、技術的負債に無頓着な人々が開発組織の大半を占めるようになり、会社は負債をますます増大させることになります。
「技術的負債(4)」では、さらに次のように書いています。
さらに、一からシステムを作成した経験がないエンジニアが組織内に増えてしまうことにもなります。製品を出し続けることで技術力があると思っているのは単なる錯覚に過ぎず、画期的な競合製品が出てきた時に、技術の空洞化が起きていて、自社製品開発では追いつけない可能性が高くなります。
1,000万行を超えるソフトウェアを、継続的インテグレーションや継続的デリバリーを達成したアジャイル開発へと移行させるということは、普通の企業ではまねできないことだと思います。
コメント(0) 

技術的負債(5) [技術的負債]

リーンソフトウェア開発と組織改革』の一部を紹介した「技術的負債」でも引用したように、負債が破綻にいたらないように努めながらソフトウェア開発/製品開発を行っていくことが必要です。
技術的負債
成功するソフトウェアは変化している。成功するコードは変更を受け入れやすく書かれている。コードの変更をむずかしくするものはすべて技術的負債である。技術的負債は、ソフトウェアの所有コストを容赦なく引き上げ、いずれその精算を迫られたり、システムが破綻したりする。そんなことはすべてわかっている。けれども現実は・・・・

(途中省略)

技術的負債の本当の姿を知らなければならない。負債が破綻に至らないよう、コスト上の重荷をふだんから取り除いておくべきだ。
技術的負債を軽減しながら、同時にソフトウェア開発/商品開発を進めていくことが重要です。技術的負債を積み上げないように努力をしながらソフトウェア開発を行っている開発組織では、「どのような商品を作るのか」に集中しても、開発そのものが技術的負債を積み上げる可能性は少ないです。しかし、毎年のように技術的負債を積み上げている組織では、技術的負債を返済することを諦めてしまうと、ある時、突然破綻してしまってもおかしくはないかもしれません。

ソフトウェア開発は非常に複雑な活動です。その複雑さにどのようにきちんと取り組んでいくかを考えていかないと、技術的負債は積み上げられて、開発に従事したエンジニアのスキルは向上することはないかもしれません。私個人のソフトウェア開発経験から言うと、技術的負債が積み上げられて、負債を解消することを行っていないソフトウェア開発だけにしか従事したことがないソフトウェアエンジニアで、その経験年数に見合ったレベルのスキルを獲得している人はほとんどいません。単に、XX年の開発経験がありますという程度に過ぎないということです。

技術的負債(4) [技術的負債]

かなり前に「技術的負債」として、3つの記事を書いています。
「技術的負債(3)」では、次のように書いています。
見方を変えると、技術的負債は、将来性のある若手をきちんとしたソフトウェアエンジニアとして成長させる場を奪ってしまうことになります。良いコードを書くという機会もなく、リファクタリングを経験する場もなく、過去に誰かが作った負債と格闘させるだけとなります。そのような状況では、ソフトウェア開発にもともと興味がない人は、負債を膨らませていくだけでしょう。一方、意欲のある若手は、成長できないため会社を辞めていくことになります。その結果、技術的負債に無頓着な人々が開発組織の大半を占めるようになり、会社は負債をますます増大させることになります。
さらに、一からシステムを作成した経験がないエンジニアが組織内に増えてしまうことにもなります。製品を出し続けることで技術力があると思っているのは単なる錯覚に過ぎず、画期的な競合製品が出てきた時に、技術の空洞化が起きていて、自社製品開発では追いつけない可能性が高くなります。

Question: 次の2つの製品は、別物でしょうか?

技術的負債(3) [技術的負債]

企業にとって、技術的負債があっても、商品を出し利益を出して、会社を維持する必要があります。しかし、技術的負債が大きい場合には、若手にとっては、良いコードを読んで学習する機会を与えるのではなく、汚いコードと格闘させるだけとになります。さらに、製品となっているコードは、手作業による膨大なテスト工数を考慮して、リファクタリングして良くする活動もできなかったりします。

見方を変えると、技術的負債は、将来性のある若手をきちんとしたソフトウェアエンジニアとして成長させる場を奪ってしまうことになります。良いコードを書くという機会もなく、リファクタリングを経験する場もなく、過去に誰かが作った負債と格闘させるだけとなります。そのような状況では、ソフトウェア開発にもともと興味がない人は、負債を膨らませていくだけでしょう。一方、意欲のある若手は、成長できないため会社を辞めていくことになります。その結果、技術的負債に無頓着な人々が開発組織の大半を占めるようになり、会社は負債をますます増大させることになります。

技術的負債(2) [技術的負債]

ソフトウェア開発においては、週に1回だけの進捗確認を行っている組織も多いのではないかと思います。そして、その内容といえば、スケジュール通りか遅れているのかだけを報告させて、技術的にきちんとレビューされたのか、妥当な人を入れてレビューしたのかを一切聞かない、あるいは、関心がないような報告会があると思います。

品質の作り込みよりも、一度立てたスケジュールを守っているような報告を行うことが優先されて、結果としてスケジュール通りに開発が進んでいるように見えたりします。しかし、結合テストやシステム全体のテストにおいて、障害が多発して、その対応に追われてしまうことになります。

障害対策は、障害の原因が分かって修正および確認が行われるまでは、「終了」という報告ができません。つまり、このフェーズになるとごまかしがきかなくなってしまいます。そして、最後は、製品開発スケジュールを守ることができなくなってしまいます。仮に、プロジェクトが遅れて完了したとしても、「技術的負債」を最初から埋め込んでしまっていることが多いです。

技術的負債 [技術的負債]

以前、「Technical Debt」と言うことで、英語のまま引用したのですが、日本語版が出たので再度日本語版から引用します。

リーンソフトウェア開発と組織改革

リーンソフトウェア開発と組織改革

  • 作者: Mary and Tom Poppendieck 著、 依田光江 翻訳、 依田智夫 監訳
  • 出版社/メーカー: アスキー・メディアワークス
  • 発売日: 2010/10/09
  • メディア: 単行本(ソフトカバー)

技術的負債
成功するソフトウェアは変化している。成功するコードは変更を受け入れやすく書かれている。コードの変更をむずかしくするものはすべて技術的負債である。技術的負債は、ソフトウェアの所有コストを容赦なく引き上げ、いずれその精算を迫られたり、システムが破綻したりする。そんなことはすべてわかっている。けれども現実は・・・・
  1. 誰が引き継いでも意図が明確に伝わるコードを書こうとせずに、不明瞭なコードがあっても受け入れてしまう。開発者は、特に経験の浅い開発者は、「クリーンなコード」の書き方を訓練されるべきだ。クリーンなコードとは、わかりやすいロジックに基づく、シンプルで素直なコードだ。上級技術者は、不明瞭なコードはたとえテストをパスしたとしても、コードベースに追加させないように気をつけなければならない。
  2. リファクタリングに時間を割かない。既存コードになされた変更をすっきりとまとめるリファクタリングは、イテレーティブ(反復的)な開発には欠かすことができない。既存コードに新しいフィーチャーを追加すると、複雑になったり、あいまいになったり、重複が発生したりする。リファクタリングによって、こうした負債を解消できる。
  3. システムを展開する直前になって回帰テストを実行する。回帰テストは初めのうちは短時間ですむが、コードが追加されるたびに時間はどんどん長くなる。回帰テストで見つかる穴が増えるにつれて、次のリリースまでの間隔も広がる。リリースのオーバーヘッドが増え続ける悪循環から抜け出すには、回帰赤字(regression deficiti: 回帰テストをするたびに発生する結果(負債))を減らすしかない。コードベースが小さいうちに自動テストハーネスを使用し始め、コードベースへの追加と保守を行っておけば、コードへの変更がその日のうちにコードベースに反映させられるはずである。
  4. 技術的負債を生み出す大きな要因は依存性である。それがわかっていながら、膨大な依存性を抱えた古いシステムのリプレースを躊躇する。依存性のなるべく小さいアーキテクチャを開発し、それに移行しなければならない。その方法は以前からよく知られている-情報隠蔽(information hiding)と関心事の分割(separation of concerns)である。
  5. 安易にコードをブランチさせる。たとえば、新規開発を切り離すため、個々のアプリケーションに集中するために、フィーチャーセットを並行して開発するため、などの理由を挙げて。コードを2つにブランチ、それぞれが長くなればなるほど、後でマージするのがむずかしくなる。コードをビルドできるまでの日数が余計にかかり、さらに悪いことに、開発が終わるまでシステムのテストを遅らせる。避ける手立てがすでにあるのに、知ろうとしない。ビッグバン方式は時代遅れなのだ。
技術的負債の本当の姿を知らなければならない。負債が破綻に至らないよう、コスト上の重荷をふだんから取り除いておくべきだ。第2章で、技術的フレームを通したソフトウェア開発を取り上げ、技術的負債を避けるための実用性のあるテクニックについて説明する。
技術的負債を積み上げているソフトウェアの開発組織は、仮に新規にシステムを作り直すことを試みても、最初から技術的負債を積み上げてしまう可能性は高いです。なぜならば、ここに書かれている1から5までの問題をそもそも認識していない訳ですから、新規開発でも、再度同じことを行ってしまうことになるからです。

私自身は、過去10年間に、上記負債を最初から積み上げないようにして新たにシステムを作り直したプロジェクトを見たことがある一方で、負債を最初から積み上げてしまった結果、新たなシステムが日の目を見ないうちに終わってしまったプロジェクトも見てきました。
技術的負債 ブログトップ