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

最近「トレーサビリティ」とよく聞くが……

　「要求から成果物へのトレーサビリティ」をテーマにした第3回勉強会（補足）では、最近よく耳にする“ソフトウェア開発におけるトレーサビリティ”に関して、参加者の皆さんとディスカッションを行いました。

　現状、トレーサビリティに関する活動の実態は、組織により大きなギャップがあるようです。すでにトレーサビリティの見える化、維持を行っている組織では、その活動の中でいろいろな問題点が発生しているとのことです。また一方で、トレーサビリティとよく耳にするが、「いったい何を行うことなの？」「目的は何？」といった組織も多く存在しています。

　それぞれの組織での活動のレベルは幅が広いのですが、参加者の皆さんの誰もが、トレーサビリティに関して大変興味があり、「品質の改善や生産性の向上に一役買うのではないか」と期待を寄せていました。

　今回は、そのような期待の中で、「トレーサビリティに関する目的やメリット、どのような個所にどのように適用するのか、また活動の中で発生している問題点」に関して深掘りしてみました。

トレーサビリティに対する意識

　はじめに、ソフトウェア開発におけるトレーサビリティに対する認識や意識から議論を開始しました。

　まずは、“これから実施してみよう”または“トレーサビリティってどのようなもの”と前向きに考えられている方々の意見から見ていきましょう。

			実施した場合にどのような効果があるのか見えていない

			品質向上にどのように役立つのか？

			要求を満たしているかの判断や、要求・仕様の変更時に役立ちそう

　このようにトレーサビリティに関する認識が、まだまだ浸透していないことが分かります。何となく品質や生産性の向上に役立ちそうだが、本当のところはどうなのか、興味津々のようです。読者の皆さんの組織でもこのように考えられている方は多いのではないでしょうか。

　また、以下のような意見もありました。

			顧客からの要求がないからやらないでは済まないと感じてきた

			「頭の中では取れているのだが……」では、他人が信じてくれない

　最近の日本の製造業（ソフトウェア開発）は、オフショア化や競争のグローバル化、ソースコード作成の自動化の波など、特にV字プロセスの底の部分では、一層のコスト削減、品質向上が望まれています。そのような状況下での、開発者自身の危機感の表れかと思います。

トレーサビリティを維持することの目的は何？

　今度は、実際にトレーサビリティに関する活動を実施している参加者の意見を聞きながら、活動の目的、メリットを探っていきたいと思います。

			要求が設計へ、設計が実装へなど、上流の情報が漏れなく下流の成果物に反映されていることを検証できる

			仕様書や設計書、テスト項目書だけでは納得してくれない第三者への説明に大変効果的である

			要求や設計に変更が発生した場合に、関連する成果物への影響範囲が論理的に分かるようになる

			派生開発や機能の変更時など、どれくらいの変更作業が発生するかの見積もりに有効活用できる

			リリース前に不具合が発生した場合などで、影響範囲を見てこのバージョンで対処するかどうかを考える（致命的な不具合ではない場合）

　このように、いろいろな場面で論理的、客観的な判断ができ、開発プロジェクトの全体にとってメリットがあることが分かります。

　ただし、どの発言もプロジェクトマネージャーやプロジェクトリーダーなどの、どちらかというと管理面に対してのメリットが多いように思います。直接の開発者は、自分の担当部分はある程度関連性を把握しているので、トレーサビリティを維持するための負荷などを考慮する必要があります。このあたりは後半で議論します。

　今回の参加者の皆さんの組織では、すでに実施を開始してから、2、3年が経過している組織が多いようでした。開始のきっかけとしては、

			顧客要求ではなく、自分たちの弱点を克服するために自らやりはじめた

			CMMIの認証を受けるために実施したが、完全に定着した

			ドキュメントとソースコードのずれを解消したかった

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

いったいどの部分のトレーサビリティを取ればよいのか？

　トレーサビリティを日本語に訳しますと“追跡可能性”となり、ソフトウェア開発では、“情報から情報へとその関係が追跡できること”となります。

　情報は、一般的には文書成果物やソースコードとして表現されることになりますが、要求は要件管理ツール上で、テスト項目などはテストの自動化ツールなどに登録され、表現される場合もあります。

　ソフトウェア開発においては、文書成果物やソースコードは、開発のフェイズや機能ごと、組織やチームごとなどで、数多く作成されるのではないでしょうか。

　その中で一体どの部分に対して、トレーサビリティを確保すればよいのでしょうか。Automotive SPICE認証などでは、システム開発の全体で14個のトレースが求められますが、認証が目的でない組織にとっては大変な負荷になります。そのため、効果とコストのバランスを取り、トレース個所を特定してくことが必要になります。その際に考慮すべきことを、参加者に聞いてみました。

			要求仕様と設計の間で、人の考えが入りやすい余地が大きいので、その部分は重点的に実施している

			設計書からソースコードは、そのままコーディングするだけなので、軽く実施している

			開発の入り口と出口に当たる、要求からシステムテストの間は重要と考えている

			公式にレビューを実施している重要な成果物は、その前後をトレースしている

			不具合発生時における、回帰テストの範囲の判断が担当者任せになっていたので、テスト項目に対するトレースを重視している

　このように、同じトレーサビリティでも力を入れる部分と、軽く済ませる部分が存在します。自分たちの開発の中の、どこで不具合が多く混入しているのか、また漏れが発生しているのかを十分に調査し、まずはその部分から取り掛かるのがよいと思います。

　そして、不具合を作り込んでしまう可能性が高いのは、1つ目の意見にある「人の考えが入りやすい部分」になります。このことを重視して、自分たちの組織でトレーサビリティを確保するべき個所を特定してみてください。