要求から成果物へのトレーサビリティ：現場の声からプロセス改善を深掘りする（3）（2/2 ページ）

[清水 祐樹 横河ディジタルコンピュータ株式会社，＠IT MONOist]

トレーサビリティの確保って
実際どのように実施するの？

　自分たちの組織、開発スタイルで、トレーサビリティを保持したい個所が特定できたら、次はトレーサビリティの情報を見える化していきます。

　まずは、実際にどのようにして、関連付けを持たせているのかを参加者に聞いてみました。

			文書成果物と文書成果物の関連を示す資料を、Excelの表で記述している

　今回参加された皆さんの組織では、Excelを用いてトレーサビリティを維持する資料を作成しているとのことで、要件管理ツールや、そのほかの関連を表現できるツールを使用している組織はありませんでした。

　では、Excelでどのように記述しているのでしょうか。

			顧客からの要求がリストとして出てくる。そのリストにある番号と、自分たちが作成する要求仕様書の関連を、Excelに記述し管理している

			仕様書、設計書などの文書成果物は、それぞれの章立ての単位でExcelにマトリクスとして記述している

			設計書とソースコードは、基本的には1対1になるので、ファイル単位で関連付けを行っている

			設計書の各項と、ソースコード内の関数に対して関連付けを行っている

　このように、要求の内容、設計、ソースコードなどの情報を、何らかの粒度で分割する必要があります。その分割した情報と情報を、Excelを用いて対応表やマトリクスなどで表現し管理することになります。その際、分割した情報である文（パラグラフ／センテンス）をそのまま記述する場合もあれば、IDのようなものを採番し、そのIDを記述して管理する場合もあります。

　では、情報はどのような粒度まで分割すればよいのでしょうか。これは成果物（情報）の種類や記述の構成、内容により異なってきます。

			要求が「×××に準拠すること」だけの場合があるので、それは×××を解釈して分解している

			フローが書かれている場合は、フローの1つのオブジェクトで対応付けることもある

などの意見が聞かれました。

　記述方法についての発言にもあったように、仕様書や設計書の文（パラグラグ／センテンス）で分割する場合や、章構成で分割する場合もあるようです。

　トレーサビリティを取るために情報を分割する粒度は、組織の開発スタイルによって異なってきます。結局は自分たちにとって都合のよい粒度、すなわち、目標を達成するために適した粒度になります。まずはその粒度を見つけ出さなければなりません。

　要求や仕様、設計、プログラム構造やテスト項目にも親子関係があり、検討を深めるとブレークダウンされていきます。各フェイズでどこまでブレークダウンするかのゴールを意識して、その末端をトレーサビリティを取るための粒度にすれば、漏れは少なくなると思います。

　トレーサビリティを確保することを前提に、粒度を定義しておく必要がありますが、あまり難しく考えずに、まずは成果物の章立てくらいの粒度でトレーサビリティを確保してみるのがよいかと思います。

　次に、トレーサビリティの確保をどのようなタイミングで、誰が実施しているかを考えてみます。

			できればリアルタイムでトレーサビリティ情報を作成、更新するのが望ましいが、変更などで効率が悪いので、フェイズの区切りに作成している

			プロジェクトの完了時に、それまでに作成したトレーサビリティ情報の整合性をチェックして、メンテナンスを行っている

　トレーサビリティ情報の作成タイミングは、上記が一般的のようです。また、変更が入る場合は、その入り口が、要求であったり設計であったりとまちまちです。どの部分に対する変更要求なのかを判断し、関連するトレーサビリティを更新することになりますが、これは随時メンテナンスされているようです。ただし、変更の範囲が広く、大きく工程が手戻りする場合などは、再作業、トレーサビリティのメンテナンスを再計画し、その完了時や工程移行時にメンテナンスを行うのがよいでしょう。

　では、誰がトレーサビリティ情報を作成しているのでしょうか。

			上位成果物と下位成果物の担当者の共同で作成する。それをフェイズの移行時にレビューしている

			成果物を入力情報として扱う側（後工程側）の担当者が作成している

　やはり、プロジェクトリーダーなどの管理者ではなく、実際の仕様検討者、設計者、実装者、検証者が、それぞれ関連する部分のトレーサビリティ情報を作成しているようです。

トレーサビリティの確保における現状の課題

　トレーサビリティに関する目的やメリット、実際の活動に関して見てきましたが、その中で問題点もいろいろと発生しているのが現状です。一番の大きな問題は以下のようです。

			要求からテスト項目までトレーサビリティを確保しているが、担当者の負荷が大きい

　どうしても、いままで実施していた開発作業に加えて、トレーサビリティ情報を文書化するわけですから、その分の負荷が担当者に掛かってしまいます。

　目的の議論でも挙げたように、組織、開発プロジェクト全体としてのメリットを十分説明し、担当者の作業負荷を考慮して、組織のルール、プロセスを構築し、それに従い開発プロジェクトの計画を策定する必要があります。

　また、できる限りトレーサビリティに関する作業や成果物（トレーサビリティマトリクスなど）のテンプレートを標準化し、担当者の作業負荷を軽減しなければなりません。

　そのほかに以下のような意見も聞かれました。

			トレーサビリティ情報を人手で作成しているので、どうしてもミス、漏れが発生する

			トレーサビリティを維持しているのに、要求から設計に対しての反映漏れが発生してしまう（期待した効果が適切に出ていない）

　1点目に関しては、担当者のスキルに依存してしまう部分かと思います。トレーサビリティ情報を見える化するツールを導入することや、レビューを徹底していく、担当者を教育していくことで補うしかないと思います。

　また、情報の関連付け自体や、2点目の反映漏れは、人が実施しなければならない部分になります。これは上位、または下位の情報（成果物）の分解の粒度が粗い場合に起こる可能性が高くなります。特に1対多、多対多の関連などでは漏れが発生しやすくなります。前項で議論した、情報の分解の粒度に関して、もう一度検討するとよいでしょう。

まとめ

　CMMIやAutomotive SPICE、機能安全などの認証の取得が目的でない場合、トレーサビリティに関する活動は、品質や生産性の向上、開発プロジェクト上における問題点の解決などに対する1つの手段でしかありません。

　トレーサビリティを維持する活動は、現状では前項で議論したように問題点もあり、苦労されている組織もあるようです。しかし、検査フェイズでバグを取っていた組織が、トレーサビリティを維持することにより、比較的上流工程でバグを排除できるようになるなど、大きな効果も期待できます。自分たちの弱み、不足している部分を正確に把握し、その対策として、トレーサビリティの維持が有効かどうかを見極め、ぜひトレーサビリティを確保する活動にチャレンジしてみてください。

　次回のテーマは品質の維持・向上の基本となる「効果的なレビューとそのフォロー」です。即効性が期待できるエリアですので、ご期待ください。（次回に続く）

筆者プロフィール   横河ディジタルコンピュータ株式会社 組込みプロセスシステム事業部（EPS事業部） コンサルティング企画部 清水 祐樹（しみず ゆうき） 金融機関におけるエンタープライズ系開発で、長らくプログラマ、システムエンジニアとして活動後、通信計測器メーカーにてハードウェア・ソフトウェアが連携した開発に従事。現在はCMMIの視点から、組み込みソフトウェア開発、ハードウェアを操作するためのフロントエンドGUI開発などの顧客に対して、プロセス改善の支援に従事。 ▼組込みソフト開発現場が抱える課題の解決を考える勉強会 http://www.yokogawa-digital.com/eSPITS/seminar.html