技術的負債、マネージャの視点

作者 Mark Levison , 翻訳者 編集部Ｎ 投稿日 2010年10月21日

セクション

プロセス/プラクティス

トピック

Scrum ,

アジャイル技術 ,

Architecture ,

Agile ,

Refactoring

共有 |

原文(投稿日：2010/09/27)へのリンク

今、イテレーション#10で、プロジェクトのスピードが落ち始めている。この2,3イテレーションでは、チームが以前のようには、多くのストーリーを完成させることができないでいる。更に、最近では、新しいストーリーとレグレッション テストの両方で、もっと多くのバグが出るようになってきた。マネージャは、チームメンバーも変わってないし、同じ時間働いていることも知っている。顧客は、「どうしたんだ？チームは、一生懸命働いているのか？」と聞いてくる。

多くのアジャイル チームが150-500%[1]の生産性の改善を達成しているのに、あなたのプロジェクトは、20-40%の範囲の改善にすぎない。どうしたのか？

１つの大きな問題があるのではない。そうではなく、たくさんの小さな問題があるのである。時々、これらは、急場しのぎの近道であった（開発者がきれいに片付ける時間がなかった、いくつかの変更を）し、またある時は、開発者が言語を知らなかっただけのことである。別の問題は、茂みのように大きくなり、ちゃんと刈り取らなければならないソースコードである。結局これら全ては、技術的負債、ということになる。

技術的負債とは、何か？

それは、全ての「あなたが今は、やらないと決めた内部的 なことで、しかし、そのままにしておくと、将来の開発を妨げるもの」である。[Ward Cunningham]。表面的には、アプリケーションは、高品質で、いい状態にあるように見えるが、これらの問題がその下に隠れている。QAは、アプリケーションは、良い品質で、ほとんどバグが無い、と言いさえするかもしれないが、それでも負債は、存在するのである。もしこの負債を管理せずに、減らしもしないと、コードを書いたり、保守したりするコストが、結局は、顧客への価値を上回ることになる。

技術的負債は、クレジットカードのようなもので、高い利子がつき、チームに未払いの残高を残すだけになる。このような場合、残高は、問題を回避するのに必要な時間と作業である。チームが負債の返済にかかる時間が長ければ長いほど、利子は、ますます嵩み（追加の回避策という形で）、そしてビジネスにそれだけ高いコストがかかることになる。

更に、それは、実際に財政的なコストになる。開発者が技術的負債やその結果起きた問題を処理するのにかける時間は、彼らが組織に価値のある仕事をする時間を奪うのである。技術的負債の根底にある読みにくいコードは、バグを見つけるのをもっと難しくする。そして、コードを理解するために失った時間は、もっと価値のある仕事をする時間を失ったことである。

なぜ技術的負債を増やすのか？

最初、きれいに整理せずに、ユニットテストを欠かずに、テスト駆動開発をせずにコードを書くほうが早いので、チームは、より大量のストーリーをこなす。問題は、普通、すぐには現れない。正しいことをするには、もっと時間がかかる、特に最初の段階では。

それは、どこからくるのか？

• 経験不足の開発者 – あるプロジェクトでは、何のトレーニングも受けずに、あるいはオブジェクト指向プログラミングでは、どうコードを書くべきかを知らない開発者が Java/C#/Rubyで書いている。結果として、彼らは、慣れている言語、すなわち、 Visual Basicなどに相応しい書き方で書き続ける。
• 締切りのプレッシャー – マネージャ層と顧客からの明示的なものと暗黙的なものの両方。「我々は、今回のイテレーション／リリースに以下のストーリーを約束した」。チームは、今回のイテレーション／リリースでの約束を守って納品をすることができないことがわかっていると、急場しのぎのことをする。「終わらせなきゃならない。きれいに仕上げる時間的な余裕はない。もしそれがフィーチャやバグでなければ、やらないことにしよう。」 不幸にして、この考え方は、経営者側がそのコストを理解していないと、彼らから、非常に受けがいい。
• きちんとしていない、読みにくいコード。メソッドやクラスの既存のコードが読みにくいと、それを引き継ぐ、次の開発者は、きれいなコードを書かざるをえない、という気が薄れる。なので、誰かがそのようなコードに触るたびに、小さな乱雑が大きな乱雑になっていく。
• 特殊化 – 考え方になる。悪いコードに見えるが、私がやるところではない。なのでそこを変更することはできない／変更しようとは思わない。更に、特殊化されたコードの世界では、開発者は、変更する資格を持っていない、と感じる。
• 不要な複雑さ – 開発者は、しばしば、必要となる前に、問題へのソリューションを設計したくなることがある。しかし、多くの場合、問題は、違う方向へ行き、何の利益もないコードが書かれる。あるいは、コードは、まったく、ニーズには合わない。問題がよく理解される前にそのコードは、書かれたからである。何れにせよ、行き過ぎた設計は、余計な時間がかかり、使われないか、そのプロジェクトのニーズに合わないコードを生産する。
• 悪い設計 – あるソリューションは、単にひどい設計である。ひどい設計のコードを基に作り上げていくのは、問題を解決するのではなく、ただ悪くするだけである。

問題の解決

一つでこの問題を解決できるものなどない。解決には、数イテレーション以上かかる。そうではなく、あなたには忍耐と多面的なアプローチが必要である。

解決における施策

1. 開発者にプログラミング言語の基礎コースを受けさせ、オブジェクト指向の原理を教え、最低限のことを理解させる。うまくいき、効果的なトレーニングには、数週間以上、その領域に詳しい人からフォローアップとサポートが必要である。
2. 開発者とマネージャーに現在の問題は、ビジネスコストがかかっていることを言う必要がある。このことで、問題を解決する価値が明確になる場合には、そう言うことは、特に重要である。経営者側は、問題に感謝し、負債を支払い始める用意をすることをはっきり言うべきである。このことに対するサポートを定期的に繰り返し、全チームは、このことを信じるようになる。
3. コードの匂い、リファクタリング、ユニットテスト、そしてテスト駆動開発に関するトレーニングを行う。クラースルームでの講義、webベースの教材、そして本を組み合わせて使用する。
4. 開発者には、オフィース時間中に時間をあげて（ゴールを達成するのに必要な最低時間は、1週間に2時間）、学びそして、スキルを磨けるようにする。練習は、自由に試して、実験できるように、捨ててしまうコードでやるべきで、出荷するコードベースでは、やってはいけない。練習と学ぶための時間は、おそらく、推奨する中で最も重要なことである。開発者に時間を与えずに、本当に何がアジャイルで可能なのか、ビジネス側の人たちには理解出来ないだろう。これを体系化するひとつの方法が、コーディング ドージョー（道場）と呼ばれるものだ（詳細は、TDD Randori Session と TDD Randori Workshopを参照）。
5. ツールを使うこと（静的解析、ユニットテスト、継続的結合、自動化された受け入れテスト）で、チームが負債の負担を発見し、減らしそして、測るのを助けるべきである。測定は、チームレベルで実施されるべきで、経営者側と共有されるべきではない。チームは、これらの測定の結果で報奨されたり、罰を受けたりしないことを知る必要がある。もし測定データが経営者側に報告されたり、追跡されたりすると、開発者は、すぐに経営者側を騙す方法を見つけ、ビジネスに本当に価値のあるものを失うことになる。
6. トレーニングを完了して、彼らが獲得したスキルにおいて、最低限の習熟を示した者を報奨すべきである。感謝の念を示すために彼らを報奨するか直接お金には結びつかないような小さな贈り物をあげるべきである。
7. 定期的に2週間に1回のランチで、技術的なことを扱う学習セッションを作ることである。このセッションで、開発者は、議論を活発にするようになるのである。昼食を与えれば、出席者も増える。更に、シニア 経営者層からも時々参加することが重要である。そうすることで、スキルの改善に対して常にサポートのあることがはっきりする。
8. 技術的負債のバッグログをメンテする － 開発者がすぐには処理できない技術的負債に気がついたらいつでも、それを技術的負債カードに書く。開発者は、負債に優先順位をつけて、各スプリントの10-15%の時間をかけて、負債を払うのである。大抵のプロジェクトでは、これより短いと、問題を引き伸ばすことになる。

現状では、あなたのビジネスには問題とチャンスの両方がある。問題: あなたのプロジェクトのコードベースは、技術的負債をどんどん溜め込んでいて、プロジェクトが既にスピードダウンし始めている。この問題には、今日でもビジネスコストがかかっており、顧客が要求する変更やバグ修正をするのがどんどん難しくなってきている。チャンス: 開発者のスキルを改善する。経営者側のサポートとコード品質が改善し、バグ数が減ることを明らかにする。やがて、これによって、開発チームの能力が増す。

[1] RPM Software – by Robin Dymond; Embedded Agile Project by the Numbers With Newbies (2006) - by Nancy Van Schooenderwoert; How Agile Projects Measure Up, and what it means to you (2008) by Michael Mah