チームがトレーサビリティのずれを防ぐために試みる3つの方法――要件定義において将来を見据えたアーキテクチャを確保する
ツールチェーンを接続し、勢いを維持しつつ、要件定義プロセス全体にわたるシームレスな統合を推進しましょう
イアン・カニンガムによるこのミニシリーズの第4部では、厳格な規律や硬直的なコントロールを徹底しただけでは、トレーサビリティのずれを防ぐには決して不十分である理由について考察します。
複雑なシステムを構築するのは、明日の課題を解決するためです。当初の意図が薄れ、ツールチェーンの連携が切断されると、組織は善意に基づいた戦略を展開することが多いものの、実際の開発環境ではその効果が不十分になることがよくあります。私たちは、エンジニアリングには推測ではなく、明確さが求められると考えています。規律、コントロール、共有構造が単独では機能しない理由を明らかにし、役割、バージョン、時間を超えて真の検証を支える、将来に耐えうるアーキテクチャの構築方法について学びましょう。
御社では、より厳格なルール、より徹底したコントロール、それともより優れた体制――このうち、どのアプローチを最も重視してきましたか？
このシリーズではこれまで、分離されたシステム間で意図が希薄化してしまう理由、すべてのユーザーに共通の単一ユーザーインターフェイスでは不十分なことが多い理由、そしてトレーサビリティが通常、少なくとも3種類の異なるユーザーに対応する必要がある理由について見てきました。では、トレーサビリティを向上させるために、一般的にどのような対策が講じられるのでしょうか。多くの場合、組織では以下の3つの戦略のいずれかをデプロイメントで導入しています：
トレーサビリティのずれを防ぐための3つの一般的なアプローチ
- トレーサビリティを確保するための規律：チームは、要件、設計、および検証の設計要素間の関連性を維持するために厳格なルールを設定します。当初は効果的ですが、要件が変化するにつれて、特に反復型開発においては、その作業負荷がすぐに耐え難いものになってしまいます。当初は規律として始まったものが、やがて苦役となり、実際のエンジニアリング作業と直接競合することになります。
- ワークフローと承認ゲートによるコントロール：このアプローチは、活動を形式化することでリスクを削減することを目的としています。しかし実際には、進捗を遅らせ、たまにしか利用しないユーザーの関与を阻害してしまいます。検証の証拠は断片化され、一見するとトレーサビリティは完全に見えますが、時間の経過とともに構造と証拠の関連性が切断されるため、信頼性は低いままです。
- 共有構造による一貫性：共通のデータバックボーンを通じて設計要素を接続することは、最も大きな可能性を秘めていますが、それは要件からテストケースへ、そして再び要件へと戻る、完全かつバージョン管理されたチェーンをサポートしている場合に限られます。これがなければ、たとえ構造が整ったシステムであっても信頼することが難しくなります。特に、異種混在のツール環境において、役割ごとに異なるアクセス形態が求められる場合にはなおさらです。
こうしたアプローチでは、実務においてトレーサビリティがどのように使用され、必要とされているかについて十分に考慮されていないため、その結果は予想通りです。信頼は急速に低下します。手戻りが増えます。チームは、何が検証されたかだけでなく、いつ検証されたのか、どのバージョンの要件に対して検証されたのかについても疑問を抱き始めます。その結果、当初のリリース予定日は現実的ではなくなってしまいます。
多くの場合、こうした問題を最初に指摘するのは、文脈を整理するための労力を避けようとする「ライトユーザー」です。要件エンジニアは、本来はすでに明確であるべきことを改めて解釈し、説明することを余儀なくされ、構造、カバレッジ、検証証拠の間のギャップを埋めることになります。
より深いレベルで考えれば、このようなことは本来必要ないはずです。エンジニアリングとは、単に意思決定を行うためだけに、検証の文脈を絶えず再構築する作業であってはなりません。規律やコントロール、構造を単独で適用するだけでは不十分です。トレーサビリティは、役割、バージョン、そして時間を超えて機能するように設計されなければなりません。
次回の記事では、何が失敗しているかを特定することから、何が実際に機能するかを定義することへと話を進めます。トレサビリティのアプローチが実際のデリバリー条件下で成立するかどうかを評価する、シンプルな方法について検討していきます。
ところで、実際の現場ではどのような状況が見られましたか？ 皆さんの環境では、規律、コントロール、一貫性のうち、どのアプローチが最初に導入されましたか？
それは長期的に見て役立ちましたか、それとも単に作業負荷を別の場所に移しただけでしたか？ ぜひ この議論に参加し 、システム設計の未来を共に形作っていきましょう。LinkedInでIain Cunningham氏をフォローし、彼のオリジナル記事のコメント欄で皆さんの経験を共有してください。