InfoQ

News

「技術的負債」に対する新しい見方

作者 Mike Bria, 翻訳者 岡田 英久 投稿日 2008年9月19日 午後12時51分

コミュニティ
Ruby,
Java,
Agile
トピック
アジャイル技術,
Delivering Quality
タグ
Refactoring,
Legacy Code

Technical Debt Workshop (リンク)は最近、「技術的負債(リンク)」に対する業界の理解と扱い方の向上に取り組みつづけており、その結果として興味深いアイデアが生まれている。その中で、私たちの問題にたいする見方は「負債」よりも「資産」にフォーカスをあてたものに変わり、あるアイデアは現在 Michael Feathers 氏や Brian Marick 氏といった人々の注意をひきつけている。

カンファレンスを主催している Matt Heusser 氏と Steve Poling 氏は 2 日間にわたるイベントのビジョンを次のように語った。

技術的負債についての議論をしっかりと地に足のついたものにするための数値的指標を定めることができれば、会議は成功だ。それは、トラブルを借りるのとお金を借りるのが同じだと言っている私たちの頭が悪いわけではないという証拠をあつめることにもなる(あるいは、別の原動力が働いていると証明できればもっとよい)。負債の管理と返済戦略、そしていつ負債を負うべきかについても提示したい。

カンファレンスでは、次の 3 つの主要な問いに答えることが目標とされた。
  1. 技術的負債とは何であって、何でないのか?
  2. どうやって技術的負債とそのインパクトを測定すればよいのか?
  3. 技術的負債をほかの負債のように管理できるのか?
Heusser 氏によるサマリにあるとおり(リンク)、このイベントではいくつかの興味深いアイデアが挙げられた。
  • 無知: だめなコードは完全な無知か意識的な決定の結果としてかのいずれか、または両方から生まれる。詳しくは Brian Marick 氏によるこの記事を(リンク)読んでほしい。
  • バグフィックス: バグは見つけたらすぐに修正しなければならない。stop-the-line (生産中止)の文化を(リンク)育成しよう。
  • モラルハザード: チームに対する顧客の適切な影響力が欠けていると、スピーディだけど品質のわるい開発が、有害なかたちでひきおこされる。このコンセプトは Heusser 氏によって導入された(リンク)
  • インピーダンスミスマッチ:  開発タスクの困難さと開発者のスキルのミスマッチがコードの品質におよぼす可能性のあるマイナスの影響。詳しくは Chris McMahon 氏によるこの記事を(リンク)読んでほしい。
  • 不安定な資産: たぶん、「技術的負債」という用語は私たちの視点を間違った方向に向けてしまう。逆に、ものごとへの投資という側面(McMahon 氏が最近提唱したように)にフォーカスをあてれば、もっと効果的かもしれない (リンク)
  • アフォーダンス: チームが規定の時間内に技術的負債を減らして「資産を増やす」実験をしてみよう。

たぶん、上述のアイデアのうち、もっとも興味深いが新鮮味のないものは、「資産を増やす」よう努めるという別の視点から技術的負債を考えることだ。会計の基本的な貸借の考え方で言い換えると、負債の減少と資本や利益の増加、どちらにフォーカスをあてることもできるけれど、最終的に理想的なゴールとは単純に資産を増やすことである。

イベントの直前、Michael Feathers 氏は「資産としてのコード(リンク)」というアイデアについて記事を書いた。コードを「資産」という視点から見るという彼の論旨は、人間の本性のより望ましいポイントを刺激し、コード品質を重視し「技術的負債」問題に反応する、というよりよい結果を生むかもしれない。彼によると、人間は性分として「資産」を得ることを好むが、「負債」をなくすことには無頓着なので、この考えはうまくいきそうだという。

Brian Marick 氏は後に議論をつづけ、「豊かな資産(リンク)」という用語をつかい、持続可能な開発におけるコード品質向上にむけた努力を言い表している。彼はガーデニングのたとえをつかい、収穫をつづけるためには土壌を豊かなまま残しておかなければならないが、だからといっていつも絶対的に最高の豊かさが必要なわけではない、それを突き詰めれば収穫などできない、と表現している。プロダクションコードも同じだというのが彼の見解だ。

さらにひとつ、簡潔ではあるけれどかなりおもしろい記事がワークショップから生まれている。その記事も Brian Marick 氏によるもので、技術的負債を減らすタイプの典型的なチームはどういう点が違うのかについて(リンク)、何人かのアジャイリストの発言をとりあげている。

いつものように、リンク先を参照してこの記事でまとめられている情報の全体像を把握したうえで、またこの記事に戻ってきてほしい。そして、これらのアイデアについて思索を深めることのできる別の情報をみなさんの経験の赴くままに探してほしい。

原文はこちらです:     http://www.infoq.com/news/2008/08/tech-debt-wkshp

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

ジャンル別一覧

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。

消費者主導契約を使ったサービス指向開発

この論文では、組織のサービス開発能力改善を目指した実用的な提案をします。

スケーラビリティの構築とパフォーマンスの達成:バーチャルパネル

InfoQ.com向けのこのバーチャルパネルでは、大企業やプロジェクトからスケーラビリティやパフォーマンスの著名人を招待し、みんなが夢に描いているような結果を達成するための秘密を明かしてもらいました。

アジリティのためにコンポーネントチームより機能チームを選ぶ

Craig Larman氏とBas Vodde氏は、どのように、そして、なぜ機能チームがうまくいくのかを説明し、この主要な組織の変化が価値あるものであることを主張します。

仮想化とセキュリティ

仮想化にはたくさんの利点がありますが、かと言って、その上に実装するアプリケーションのセキュリティをないがしろにしてはいけないのです。

Rubyのオープンクラス:猿のようにパッチを当てない方法

最近リリースされたRuby 1.8.7のプレビューリリースをウオッチしていたRails開発者はすぐに1.8.7プレビュー1に関してあることに気がつきました。それは、1.8.7プレビュー1がRailsを破壊してしまうということです。