形式ばったトレーサビリティ・マトリックスは、しばしばアジャイルコミュニティから強い反応を引き起こしている。Agile Testingグループでの(source)激しい議論の中で、Jorge Argus氏はアジャイルプロジェクトにおけるトレーサビリティ・マトリックスの必要性に関する興味深いスレッドを立てた(source)。
Brad Appleton氏の意見では(source)、重要な点は、「トレーサビリティ」と「トレーサビリティ・マトリックス」の違いを理解することである。トレーサビリティはプロジェクトに求められる特性であり、重要な情報の透明性や可視性、そしてそれらの相互関係について表現する。他方トレーサビリティ・マトリックスは、トレーサビリティを実現可能なものの一つである。
同じ考え方で、トレーサビリティ・マトリックスの作り方の内容に入る前に、その背景にある理由について疑問を抱くべきである、とMichael Bolton氏は付け加えている(source)。
誰かがトレーサビリティを望んでいるのですか？何のために、どのくらいの頻度で、どのような形式のものを望んでいて、どのような形式のものが受け入れられそうかを質問して下さい－－そしてそれから、コストが価値に見合うかどうかを尋ねてください。
Michael 氏によれば、トレーサビリティ・マトリックスは、本当に価値のあるコーポレート・メモリ（組織の記憶）を失う危険がある場合にのみ必要とされるだろう。それに該当しない場合、トレーサビリティは様々な形で得ることができる。たとえば、会話、ストーリー、戦略的テーマ、履歴、ログ、ジャーナル、ソースコード、自動化されたテスト、設計文書、デイリースクラム、メール等である。
Scott Ambler氏は(source)「Agile Requirements Best Practices(source)」（アジャイル要求モデリングのベストプラクティス）という記事の中で、トレーサビリティ・マトリックスの必要性に異議を唱えている。彼の意見では、トレーサビリティ・マトリックスの適切だと認められる点は、変更された要求の影響分析が簡単に行われることである。マトリックスはその変更で影響を受けるシステムの側面を明らかにするだろう。しかし、これはマトリックスがなくても容易に得られるだろう。なぜなら、プロジェクトにはたくさんの経験豊かな人たちがいて、プロジェクトのすべての側面について詳しく知っているからである。Scott氏は次のように言い添えている。
私の経験では、トレーサビリティ・マトリックスは非常に過大評価されています。こうしたマトリックスを保つためにかかる総所有コスト（total cost of ownership：TCO）は、それを行うための特別なツールがあったとしても、メリットよりずっと重いからです。プロジェクトのステークホルダに実際のコストとメリットを意識させ、そして彼らに決めさせて下さい－結局は、トレーサビリティ・マトリックスは事実上はドキュメントであり、したがって彼らによってなされるべき経営的な意思決定なのです。[...]
実際に法規制を順守する必要がある場合は、私はトレーサビリティを固く信じています。たとえば米国食品医薬品局（Food and Drug Administration：FDA）のCFR 21 Part 11の規定では(source)トレーサビリティが要求されており、明らかにそうした規定に従う必要があります。私が疑問を抱いているのは、単に「素晴らしいアイデアだ」というだけで動機づけられたトレーサビリティです。
Scrum Developmentグループで、Alistair Cockburn氏は(source)調査を引用して(source)論拠を補強している。
あるプロジェクト（企業のITのコンテキスト）で、私たちはトレーサビリティのためのツールのインストールと、情報を最新の状態に保つために人が行う仕事の両方について、慎重にコストを調査しました。コストは信じがたいほどに高かったので、顧客は契約からトレーサビリティに関する要求を削除しました。
重要な点をさらに繰り返して、Brad Appleton氏は(source)、トレーサビリティ・マトリックスを手作業で作成、更新し維持していくのはトレーサビリティを証明する方法では最も時間のかかるものである、と言い添えた。
では、トレーサビリティ・マトリックスを自動的に管理可能であることを保証する方法はあるのだろうか？
Ron Jeffries氏は、最も簡単な方法は、変更をしてどのテストが失敗するかを確認することだ、と述べた(source)。それにより、開発者はどこに影響があるかがわかるだろう。同じ考え方で、Mike Beedle氏は次のように言っている(source)。
アジャイルのパラダイムの中では、コード/設計から要求へのトレーサビリティは単体テストや受け入れテストを通して行われます。テストは要求のトレーサビリティを反映しています。なぜなら、要求を実装した特定のコードを実行するからです。
Brad Appleton氏はブログの中で(source)可能な解決策に言及しており、彼によると、彼はTDDを使用して非常に短いサイクルで仕事をしている。彼のサイクルの中で典型的なタスクは、テストを書き、テストをパスするコードを書き、コードをリファクタリングし、変更をコミットすることである。コミットを行う際、彼はストーリーの名前かIDを関連付けている。彼の意見では、こうした短いサイクルを行うことで、トレーサビリティは自動的についてくる。
「Lean Traceability: a smattering of strategies and solutions(source)」（リーンのトレーサビリティ：いくつかの戦略とソリューション）という記事の中で、CM Crossroadはアジャイルのマニフェストに追加するものがあるとすれば、次のものだろうと述べている。
信頼できる透明性を、うんざりするようなトレーサビリティよりも
この記事によれば、トレーサビリティの考え方は透明性と識別を実現することである。これらを達成するための、形式ばったトレーサビリティ・マトリックスの現実的な代案となるものはある。チームは、アジャイルの原則に従って、リーンのトレーサビリティを達成しようとするべきである。以下の項目は、この記事で言及されている選択肢の一部である。
-
トレーサビリティはトレースではないことを認識せよ
-
バージョン管理ツールや変更をトラッキングするツールを使用せよ
-
バージョン管理と変更トラッキングの基本的な一体化
-
タスクベースの開発（Task-Based Development：TBD）
-
テスト駆動開発（Test-Driven Development：TDD）
-
シンプルなツール：Wiki、Wikiベースの仕様フレームワーク
-
イベントベースのトレーサビリティ（Event-Based Traceability：EBT）
-
イベントベースのトレーサビリティ（Event-Based Traceability：EBT）
-
シンプルな検索ベースのトレーサビリティ（「Googleで検索するだけ！」）
自身の経験に基づき、Alistair氏はメーリングリストで意見を述べている(source)。
私は30年間にわたり、業界や研究の場、そして少しだけ政府でも仕事をしてきましたが、トレーサビリティ・マトリックスで元が取れたのを見たことは一度もありません。
もしあなたが異なる経験をしていたら、マトリックスを使用して、その作成や維持にかかった費用に対する見返りがあったときのことを私たちに教えて下さい。
アジャイルコミュニティの人たちの大部分が考えていることから明らかなように、形式ばったトレーサビリティ・マトリックスの維持は、やり過ぎだろう。チームはトレーサビリティ・マトリックスをもつ理由を探り、トレーサビリティの実現を支援するであろうリーンのアプローチを採用するべきである。
原文はこちらです：http://www.infoq.com/news/2008/06/agile-traceability-matrix