なぜ「1つのツールですべてを賄う」は機能しないのか ― 要求工学における将来を見据えたアーキテクチャ設計
要求工学プロセス全体を通じて一貫性を維持し、シームレスな統合を実現するために、ツールチェーンを連携させましょう。
このミニシリーズ第2回では、Iain Cunninghamが分断されたシステムに対する一般的な解決策について考察します
お客様は、明日の課題を解決するために複雑なシステムを開発しています。設計意図が失われ、ツールチェーンの分断が進むと、多くの組織は「すべての人が使う単一の統合ツール」を求めるようになります。しかし、このアプローチはしばしばチームの負担を増やしてしまいます。私たちは、エンジニアリングに必要なのは推測ではなく明確さだと考えています。なぜ単一のインターフェイスを多様な役割へ一律に適用すると摩擦が生じるのか。そして、個々のワークフローを尊重しながらシームレスな統合を実現する、将来を見据えたアーキテクチャをどのように構築できるのかをご紹介します。
シンプルにするために導入したはずのツールが、実際には作業を複雑にしていると最初に感じたのはどの瞬間だったでしょうか。
本シリーズの第1回では、要求管理、MBSE、設計、検証がそれぞれ別のシステムで管理されている場合に、設計意図がどのように失われていくのか、そしてその影響がなぜ最初に要求エンジニアへ及ぶのかを見てきました。こうした状況に対する組織の典型的な反応は、「正しいツール」を探すことです。すべてを統合する単一の環境。役割や利用目的の違いにかかわらず、全員が同じインターフェイスを共有する世界です。
要求エンジニアにとって、これは魅力的に聞こえるかもしれません。エクスポート作業は減り、手作業による説明も少なくなり、要求、MBSE、設計、実装、さらにはテストや検証に至るまで、より優れたトレーサビリティが期待できます。そして何より、人力でプロセスの隙間を埋めるような会議に参加する必要がなくなります。しかし、この考え方は重要な現実を見落としています。問題は作業量ではありません。本質的な問題はミスマッチにあります。
問題は、人々がツールの利用を拒んでいることではありません。実際の業務の進め方に適していない形で利用を求められていることにあります。要求やトレーサビリティとの関わり方は、役割ごとに本質的に異なります。要求エンジニアは構造と設計意図を維持します。エンジニアやリーダーは変更時の影響を評価します。テスト・検証チームはカバレッジや検証結果を確認する必要があります。意思決定者やコンプライアンス担当者は、要求が定義されているだけでなく、実際に検証されていることを確認する必要があります。
それにもかかわらず、全員に同じユーザー体験を強制すると、その結果は予測可能です。
「１つのツール」アプローチがもたらす影響
- ライトユーザーがインターフェイスの操作に苦労し、レビューが停滞する。
- ステークホルダーの関与が低下し、オフライン版の資料を求めるようになる。
- 技術的にはトレーサビリティが存在していても、チーム全体では活用されなくなる。
- 最終的に質問は要求エンジニアへ集中し、要求エンジニアが唯一信頼できる情報源として扱われ続ける。
時間が経つにつれて、要求エンジニアは人間版トレーサビリティマトリクスのような存在になります。システム間、役割間、そして失われたコンテキストのギャップを埋めることが期待されるようになるのです。しかし本来、このような状況は避けられるはずです。明確さを維持するためだけに回避策へ依存するべきではありません。
規制産業では、これはさらに大きなリスクになります。トレーサビリティはコラボレーションのためだけに存在するわけではありません。各要求がテストケースや検証結果と関連付けられていることを証明するためにも利用されます。これらのリンクが異なるツールへ分散していると、チームは限られた時間の中でカバレッジや検証結果を手作業で再構築しなければなりません。規制対象の開発では、これは任意ではありません。要求が定義されているだけでなく、すべての要求が検証済みであることを証明できなければならない のです。
現代の反復型開発では、この課題はさらに複雑になります。要求、テストケース、検証結果は複数のイテレーションや並行開発ブランチをまたいで変化していきます。そのため、単に「要求は検証されたか」を問うだけでは不十分です。
チームはさらに次の問いに答える必要があります。
- 検証されたのはどのバージョンの要求なのか。
- そのバージョンに対応するテストケースはどれか。
- その検証を裏付ける実行結果は何か。
バージョンを考慮したトレーサビリティがなければ、カバレッジは不明確となり、検証結果の信頼性も損なわれます。そして、この問題の解決は再び要求エンジニアへ委ねられることになります。ここまで読み進めると、一つのことが見えてくるはずです。問題はツールそのものではありません。異なる役割がトレーサビリティとどのように関わるべきかという設計にあります。
振り返ってみてください。お客様の環境で、「すべての人が同じツールを使う」アプローチが機能し始めなくなった最初の兆候は何でしたか？
ぜひ議論にご参加ください。Iain CunninghamのLinkedInをフォローし、元記事のコメント欄でご経験やご意見をお聞かせください。