なぜ「万人向けの単一ツール」は失敗するのか――要件定義における将来性のあるアーキテクチャの確保
ツールチェーンを接続し、勢いを維持し、要件定義プロセス全体にわたるシームレスな統合を推進しましょう
イアン・カニンガムによるこのミニシリーズの第2部では、断片化したシステムに対する一般的な反応について探っていきます。
複雑なシステムは、明日の課題を解決するために構築されます。しかし、当初の意図が薄れ、ツールチェーンの連携が切断されると、組織はしばしば、全メンバーが利用できる単一の統合ツールを求めるようになります。しかし、このアプローチはチームへの負担を増大させることが少なくありません。私たちは、エンジニアリングには推測ではなく、明確さが求められると考えています。多様な役割に単一のインターフェースを強要することがなぜ摩擦を生むのか、その理由を探り、個々のワークフローを尊重しつつシームレスな統合を維持する、将来を見据えたアーキテクチャの構築方法について学びましょう。
物事を簡単にするために設計されたツールが、実はかえって物事を難しくしていることに気づいた最初の瞬間は、いつでしたか？
本シリーズの第1回では、要件、MBSE、設計、検証が別々のシステムに分散していると、当初の意図がいつの間にか薄れていくこと、そしてその結果がまず要件エンジニアに降りかかってくることが多いことについて考察しました。組織としてよく見られる対応策は、「最適なツール」を探すことです。すべてを統合する単一の環境。個々のニーズにかかわらず、すべての役割が利用できる単一の共有インターフェースです。
要件エンジニアにとって、これは魅力的に聞こえるかもしれません。エクスポート作業が減り、手作業による説明も減ります。要件、MBSE、設計、実装、場合によってはテストや検証に至るまで、トレーサビリティが向上します。何より、プロセス上の「つなぎ役」として会議を行う必要がなくなります。しかし、このアプローチでは、重要な現実が見落とされがちです。問題は労力ではありません。それは、ミスマッチなのです。
問題は、人々がこれらのツールを使用いたがらないということではありません。問題は、ツールの実際の仕組みとは異なる方法で、それらを使用するよう求められている点にあります。役割が異なれば、要件やトレーサビリティとの関わり方も根本的に異なります。要件エンジニアは、構造と意図を維持します。エンジニアやリーダーは、変更時の影響を評価します。テストおよび検証チームは、カバレッジと検証の証拠を理解する必要があります。意思決定者やコンプライアンス関係者は、要件が単に定義されているだけでなく、実証的に検証されているという確信を必要としています。
すべての人に単一の体験を強要すると、その結果は予想がつきます。
「ワンツール」アプローチがもたらす目に見える効果
- たまにしか利用しないユーザーがユーザーインターフェイスに戸惑うため、レビューの投稿ペースが鈍ります。
- 関係者は関心を失い、オフライン用のコピーを要求します。
- トレーサビリティは技術的には存在しますが、チームはそれを一貫して使用していません。
- 信頼できる情報源として要件エンジニアが依然として位置づけられているため、質問が彼らに戻ってきます。
時が経つにつれ、要件エンジニアはしばしば「人間によるトレーサビリティマトリックス」のような存在となり、システムや役割、そして欠落した文脈の間のギャップを埋めることが期待されるようになります。より根本的に考えれば、これは本来避けられるべき事態です。エンジニアリングは、単に明確さを保つためだけに、その場しのぎの対応に依存するべきではありません。
規制産業においては、これがさらなるリスクを生み出します。トレーサビリティは、単にコラボレーションのためだけに使用されるものではありません。各要件が、テストケースや検証証拠を含む検証と結びついていることを示すためにも使用されます。もしそれらのリンクがツール間で断片化されてしまうと、チームは時間的プレッシャーの下で、カバレッジや証拠を手作業で再構築することになってしまいます。規制環境においては、これは任意の事項ではありません。すべての要件が単に定義されているだけでなく、検証されていることを示すことができなければなりません。
現代の反復型デリバリーにおいて、この課題は時間とバージョン管理によってさらに増幅されます。要件、テストケース、検証証拠は、複数の反復を経て、しばしば並行する開発ブランチをまたいで進化します。もはや、要件が検証されたかどうかを問うだけでは不十分です。
チームはさらに、次のような質問にも答えなければなりません。
- どのバージョンの要件が検証されたのか？
- そのバージョンにはどのテストケースが適用されるのか？
- どの実行証拠がその検証を裏付けているのか？
バージョンに配慮したトレーサビリティがなければ、カバレッジは不明確になり、証拠の信頼性も失われます。これらの疑問を解決する負担は、往々にして要件エンジニアに降りかかります。本シリーズのこの段階に至り、一つ明確になることがあるはずです。問題はツールそのものではなく、異なる役割を担う人々がトレーサビリティとどのように関わるべきかという点にあるのです。
振り返ってみて、ご自身の環境において「全員共通の単一ツール」というアプローチが機能しなくなってきた最初の兆候は何でしたか？
ぜひ議論に参加し、システム設計の未来を共に形作ってください。LinkedInでIain Cunningham氏をフォローし、彼のオリジナル記事のコメント欄で皆様の経験を共有してください。