トレーサビリティの保証プロジェクト管理の仕組み（その43）

更新日 2022-08-25

投稿日 2017-07-18

　前回までシステム設計について、その基本の考え方や実施方法について解説してきました。多くの組織で、システム設計は、できる人だけの作業になっており、設計の最上流工程であるにもかかわらず、その妥当性や正当性を検証することは難しい状態になっています。システム設計を担当した人にしかそのアウトプットの意味や背景がわからない状態というのは非常に危険ですから、前回までで紹介した考え方や実施方法を参考に、システム設計のアウトプットの妥当性や正当性を検証する方法を、開発現場に合わせて具体化していただきたいと思い...

　今回のテーマであるトレーサビリティというのも、システム設計と同じように、設計における重要な概念であるにもかかわらず、多くの開発現場で、属人的、そして、暗黙的な作業となっています。どんなにがんばって設計書を書いてレビューをしても、設計の不備による不具合が思ったようには減らないという場合は、設計におけるトレーサビリティが保証されていないことが原因であることが少なくありません。

　トレーサビリティという単語は、BSE問題や産地偽装問題などの事件に関連してニュースなどを通じて馴染みのあるものになりました。この場合は、対象となる物品の流通履歴を確認できることを意味しています。同じ概念ですが、今回テーマとしたい設計におけるトレーサビリティは、要求仕様（要件）が製品として実装されるまでの各工程における入力と出力が正しく変換されているかどうかの性質（追跡可能性）を意味します。

　トレーサビリティが保証されていない設計工程の場合、もともとあがっていた要件が過不足なく回路や機構、ソフトなどに実装されているかどうかを確認する手段は、製品としてくみ上げた後の最終評価だけになってしまいます。設計の途中段階で抜けてしまうと最終評価まで発見できないし、最終評価で発見できなければ市場不具合となってしまうわけです。設計トレーサビリティの保証がない開発現場では、最終評価に多大な時間と人手をかけていることが多いのですが、このような開発源では、最終評価でしか要件や設計の抜け・漏れ・不備を見つけることができないことが原因のひとつになっているのです。

　それでは、設計トレーサビリティについて詳細を見てみましょう。設計工程は図80に示すようにいくつかの工程に分かれており、それらを順々に実施することで製品として製造できるものになっていきます。図80はわかりやすさのためソフトウェア開発をイメージした単語にしていますが、ハードウェア開発でもモジュールを機能ブロックなどと考えれば考え方は同じです。

図80. 開発工程とDepth設計

　図80では、設計工程を、要求定義工程、基本設計工程、詳細設計工程、テスト設計工程から成り立ち、それぞれが順々につながっているものとして表現しています。多少の言葉の違いや工程の数の違いはあるものの、ほとんどの開発現場ではこのような表現ができると思います。それぞれの開発工程では主要な設計要素が決まっており、各々の設計工程での設計作業というのは、その設計要素を詳細化・具体化することです。要求定義工程は、前回までのシステム設計で説明したように FURPS+ を使って機能要件 (F) と非機能要件 (U, R, P, S, +) を詳細化・具体化することで、詳細で網羅的なシステム要件を作るという工程でした。同様に、基本設計工程は機能を詳細化する工程、詳細設計工程はモジュールを詳細化する工程、テスト設計はテストケースを詳細化する工程だということができます。

　次回も、トレーサビリティの保証についての解説を続けます。

◆関連解説『技術マネジメントとは』

　続きを読むには・・・

新規会員登録