設計意図を守る ― 要求工学における将来を見据えたアーキテクチャ設計
要求工学プロセス全体を通じて一貫性を維持し、シームレスな統合を実現するために、ツールチェーンを連携させましょう。
このミニシリーズ第1回では、Iain Cunninghamがシステム設計に潜む見えにくい課題を考察します。
お客様は、明日の課題を解決するために複雑なシステムを開発しています。しかし、プロジェクトが要求工学のプロセスを経て最終成果物へと近づくにつれ、本来の設計意図は気づかないうちに失われていくことがあります。分断されたツールチェーンは摩擦を生み、進捗を妨げ、チームに終わりのない確認作業を強いる原因となります。私たちは、エンジニアリングに必要なのは推測ではなく明確さだと考えています。設計意図を維持し、データサイロを解消し、開発のあらゆる段階で品質向上を実現する方法をご紹介します。
要求エンジニアとして追求すべきことは一つです。それは、設計意図を変更の中でも失わないことです。その意図は、要求管理リポジトリ、モデル、設計、実装、サプライヤーとの連携、レビューを経て、最終成果物まで一貫して引き継がれるべきです。しかし、実際のプロジェクトでは、問題は目に見える形で発生するとは限りません。単一の障害や重大な設計ミスが原因ではなく、小さな認識のずれが少しずつ積み重なっていきます。ある要求を異なるチームが異なる解釈で理解する。変更内容について議論したにもかかわらず、その影響が関係者に共有されない。あるフェーズが承認された数週間後には、誰も当初の設計意図を思い出せなくなっている。このようなことは珍しくありません。
こうした摩擦は、ツールチェーンが分断されているときに発生します。要求は一つのツールに存在し、システムモデルは別のツールに保存され、物理設計や論理設計の成果物はさらに別の場所に存在します。各チームはそれぞれの環境で慎重に作業を進めていますが、要求・モデル・設計の関係を可視化するのではなく、暗黙の前提として扱ってしまいがちです。ベクターは、エンジニアリングに必要なのは確認作業ではなく継続的な推進力であると考えています。情報が分断されたシステム間を行き来すると、トレーサビリティや文脈が失われ、同じ問いへの回答を何度も繰り返すことになります。
分断されたアーキテクチャがもたらす影響
- チームの信頼性が低下し、レビューに時間がかかる。
- 上流工程の設計意図が失われ、設計判断の見直しが繰り返される。
- 念のためにデータをエクスポートすることで、新たなデータサイロが生まれる。
- サプライヤーが独立したコピーを作成し、プロジェクト全体の整合性が失われていく。
このような乖離を放置すると、要求工学は安心材料を探すための活動になってしまいます。本来であれば革新や品質向上を推進すべき要求エンジニアが、トレーサビリティを人力で維持するために終わりのない会議へ時間を費やすことになります。その代償は、手戻りの発生や納期遅延という形で後から表面化します。
お客様のワークフローでは、最初に設計意図が失われるのはどの工程でしょうか。引き継ぎでしょうか。レビューでしょうか。サプライヤーとの情報連携でしょうか。それとも変更管理でしょうか。
ぜひ議論にご参加ください。LinkedInでIain Cunninghamをフォローし、元記事のコメント欄でご意見やご経験をお聞かせください。