技術的負債にどのように取り組むか

 2012/04/14
このエントリーをはてなブックマークに追加

みなさんこんにちは。@ryuzeeです。

定期的にSlideshareをウロウロして良い資料がないかを探しているのですが、技術的負債に関する分かりやすい資料があったのでご紹介します。

Managing Technical Debt - 2011 webinar from BigVisible Higdon

なお、Youtubeに動画もアップされているので、興味あるかたはこちらを参照ください。

以下特徴的なところや役立つところを紹介していきます。

  • 技術的負債とは、現在の進捗のために、将来のキャパシティ(ソフトウェアの開発能力)を犠牲にすることである
  • もうちょっと具体的に言えば、技術的負債とは、ソフトウェアの内部的な問題(見つかっているか見つかっていないかは関係はない)、要求の明確化の欠如、ダメな設計、ビジネスの要求に適していない設計、自動化できるはずの箇所の手動処理などを指す
  • 利子の支払いは時間のムダである。例えば欠陥を直すのに時間を取られる、要求が明確になった後に再度作りなおす、複雑なコードを理解するために余計な時間を取られる、などなど
  • 技術的負債の悲惨なサイクルがある
    • テストを書く時間がない、リファクタリングする時間がない、設計レビューする時間がない、問題の本質を解決しないで表面的に解決する
    • 結果的に品質が下がる。急いで無理やり直して、やはりテストがない。自動化されていない。設計がダメなまま
    • バグがさらに増える。テストされていないコードの増加、重複コード、タコな設計のコード、リファクタリングされていないコード、チームのモラルの低下、健康被害
    • 付け焼刃な対応によるファイル数やコード量の増加。そして最初に戻る
  • 負債の可能性は右の式で表現できる:(変更頻度×複雑度)÷ 品質のコントロールの度合い
  • 技術的負債にどう取り組むか
    • 実際の症状を見つける
    • なぜそれが発生したのか?なにが原因なのかを確認する
    • 根本原因にたどりつくまで「なぜ?」を繰り返す
    • 自分がコントロールできる範囲になったら直す
    • 影響があって手に負えない場合は全体で方針を決める
    • 以降に負債を増やさないように、品質を作りこむ
  • Chris Sterlingの「Technical Debt Mapping」の手法を使って技術的負債をコントロールする手もある
    • まず主要なアプリケーションのコンポーネントをホワイトボードに書き出す
    • ポストイットに技術的負債を書いて、書きだしたコンポーネントの該当箇所に貼る
    • これらの負債を、「品質向上のストーリー」としてINVESTを意識して記述し、プロダクトオーナーに説明する。その際、価値は投資対効果で記述する
    • プロダクトオーナーはROI等を見ながら優先順位を決める

※ここでの品質はソフトウェアの外部品質ではなく、内部品質を指す。

それでは。

 2012/04/14
このエントリーをはてなブックマークに追加