トレーサビリティには3種類のユーザーが存在します――要件定義における将来性のあるアーキテクチャの確保
ツールチェーンを接続し、勢いを維持し、要件定義プロセス全体にわたるシームレスな統合を推進しましょう
イアン・カニンガムによるこのミニシリーズの第3部では、トレーサビリティを「画一的な活動」として扱うことが、なぜ信頼を損ない、進捗を停滞させるのかについて解説します。
複雑なシステムを構築するのは、明日の課題を解決するためです。しかし、当初の意図が薄れ、ツールチェーンの連携が切断されると、トレーサビリティは自信の源ではなく、むしろフラストレーションの原因となることがよくあります。エンジニアリングには推測ではなく、明確さが求められます。トレーサビリティを単一の活動として扱うことがなぜ失敗するのかを明らかにし、役割ごとにアーキテクチャと関わる3つの根本的に異なる方法を尊重したアクセス設計の方法を学びましょう。
現在、トレーサビリティに関して最もストレスを感じているのは、それを作成する、使用する、それとも信頼するいずれでしょうか？
前回の記事では、組織内のあらゆる役割に対して単一のインターフェースを用意することが、複雑さを削減するどころか、かえって増大させてしまう理由について考察しました。今後を進める上で、一般的な通念と現実を区別しておくことが役立ちます。トレーサビリティは、しばしば単一の活動として扱われます。しかし実際にはそうではありません。それは、根本的に異なる3つの相互作用から成り立っています。この点が重要なのは、ドリフトを削減する実用的な方法は、1つのアプローチがすべての人に通用すると仮定するのではなく、これら3つの相互作用すべてに対して明示的に設計を行うことにあるからです。
トレーサビリティの3つの主要な相互作用
- 要件エンジニアは、要件、モデル、設計要素間の関係が、ツールや統合環境をまたいで確実に維持されるよう、トレーサビリティのリンクを正確に作成・維持する必要があります。
- 下流のエンジニアリングおよび検証担当者は、変更時の影響と対象範囲を評価する必要があり、トレーサビリティを活用して、何が影響を受けるか、どのテストケースが適用されるか、そして何が未検証のまま残っているかを把握しなければなりません。
- 意思決定者やコンプライアンス関係者は、トレーサビリティが組織の境界を越えて正しい構造と正しいバージョンの両方を反映していると確信し、意図と検証の両方を自信を持って確認する必要があります。
こうした相互作用が明確に理解・支援されていないと、摩擦が増大します。たまにしか利用しないユーザーはシステムを避けるようになります。エクスポートが氾濫します。トレースリンクは古くなったり、大量のスプレッドシートの中に埋もれてしまったりします。その結果、要件エンジニアは再び「最後の頼みの綱」としての役割を強いられ、意図の説明だけでなく、それが実際に検証されたかどうかの説明まで求められることになります。
より根本的なレベルでは、このような状況は本来必要ないはずです。エンジニアリングは、単に意思決定を行うためだけに、繰り返し文脈を再構築することに依存すべきではありません。
これら3つの相互作用が意図的にサポートされるようになれば、レビューは文脈の再構築ではなく、意思決定と意図に焦点を当てることができます。カバレッジが明確になり、検証の証拠も信頼性の高いものとなります。要件エンジニアは、意味を説明したり擁護したりする時間を減らし、それを設計する時間により多くを費やすことができるようになります。重要な示唆は単純です。システムが使用され、信頼されるためには、相互作用ごとにトレーサビリティへのアクセス方法を異なって設計しなければならないということです。
本シリーズのこの段階に至り、根底にあるパターンは明らかになっているはずです。トレーサビリティは、異なる役割が実際にどのようにそれと関わるかを反映して初めて機能します。いかなる解決策も、その現実を反映していなければなりません。
まず第一に、現在の組織において、これら3つの相互作用のうち、どれが最も摩擦を生み出しているでしょうか？
ぜひ議論に参加し、システム設計の未来を共に形作ってください。LinkedInでIain Cunninghamをフォローし、彼のオリジナル記事のコメント欄で皆さんの経験を共有してください。