トレーサビリティを導入して実践した話

Tweet

みなさまこんにちは。
エコモットの板橋です。
前回は「1文節1仕様を導入してみた」について記載しました。
これは主に、要件定義や設計書に記載する内容について、可能な限り曖昧な記述を排除するための対策として導入した手法でした。
今回は、トレーサビリティに関して書いていきたいと思います。
今まで書いてきた記事の中でも、少し匂わせぶりに書いてきましたが、それは「とっておき」だからではなく、どのように書いたら分かりやすいかなぁ、、、と悩んでいました（苦笑）
では、今回も文章量多めですが、進めていきましょう。

こんなことありませんか

システム開発していると、下記の様な心配事に遭遇したことはありませんか？

• お客様の要求を全て設計に盛り込んだか？
• レビュー指摘を全て反映したか？
• 設計の過程で仕様が変質していないか？
• 設計内容を全てプログラム実装したか？
• 実装した機能を漏れなくテストしたか？

更に、保守・運用をしていると、このようなことを感じたこともありませんか？

• この仕様がお客様のどの様な要望によるものか？
• このプログラム実装がどの仕様に由来したものなのか？

私はいつも心配で胃がキリキリしてきますよ（苦笑）
システム開発では、数多くのお客様の要望に応えるため、要件定義書をはじめとしたドキュメントを作成して要求事項や設計内容を整理して行きますが、先に挙げた不安要素は付きまとうわけです。
数多くの要望を整理し、一つ一つ具体的な設計に落とし込むわけですが、その過程でどうしてもエラー（漏れや変質）は混入してしまうものなのです。
エラーが混入することを前提に、どうやってお客様の要望を正確にシステムの仕様に落とし込む事を担保するのか、機能として実現していくのか。腕の見せ所ですね。

一度整理してみましょう

システム開発は、要件定義→実装→テスト…という具合に順番に工程を進めていきます。（アジャイル開発でも基本は同じ）
また、要件定義や外部設計といったお客様が直接見たり触ったりする部分については、お客様とレビューして合意を取りながら進めていきます。
大雑把な図ですが、成果物であるドキュメントやソースコード等の関連性を確認しておきましょう。

このように、開発フェーズごとに成果物があり、前フェーズの内容を具体化・実装する事で段階的にシステムが出来上がっていきます。
この図をもとに考えると、要件定義の内容が下流工程の内容とつながっており、その関連性を可視化することによってエラー（漏れや変質）の検証を容易にすることができそうです。
また、図の右側や下側にあるように、レビューでの指摘がどこに反映されたか、テストで見つかったバグがどの設計の誤りに由来し、どこまで修正が波及するのかという「双方向のつながり」を追いかけられる状態にすることで検証可能な範囲を広げられそうです。
当然、要件定義の段階で抜けや誤りがあった際に、そのまま下流の工程に流出していくことに変わりはありませんが、要件定義でのお客様とのレビューでしっかりとフォローする事により、このようなエラーを防げる可能性が高まりますね。
このような状態を「トレーサビリティを確保した状態」と言います。

トレーサビリティとは

追跡（トレース）可能な状態を示す言葉です。
先の図で示した通り、工程間で要求や仕様の関連性を明確にすることで、今自分の作業している仕様やプログラムが上流工程のどの要求（仕様）に由来しているのか、漏れや変質が起きていないか確認が容易になります。
また、上流工程の1項目が下流では多数の細かい仕様やプログラムによって実現される事も多いため、これらの関連性を明確に可視化する事はエラーの予防だけではなく、テスト項目の網羅性などシステムの品質にも大きな影響を及ぼします。
仕様とテスト項目のトレーサビリティが確保されていれば、しっかりとテスト実施しているかどうかを目視で確認しながら確認できるのです。

更に、トレーサビリティ導入の効果として見逃せないのが、「担当者だけが理解している」といった属人化の排除にも一定の役割を果たす点です。
仕様や実装間での関連性を可視化していますので、担当者が入れ替えになったとしても、その仕様やプログラムの由来を追跡する事で、背景を理解していくことが可能になります。

仕様の変更があっても大丈夫

システム開発の過程でどうしても避けて通れないのが仕様変更です。
お客様からの仕様確認のメールやレビュー時、バグ修正に伴う仕様の欠陥など、あらゆる状況で仕様変更は起こり得ます。
仕様変更が発生すると、私たちは影響範囲を調べて、関連個所の変更作業に入るわけですが、当然、作業が完了している箇所も影響範囲に含まれるケースもあり、プロジェクトによってはこのような事が何度も発生することも結構あります。
このような状況で、トレーサビリティが「取れている状況」と「取れていない状況」を比較してみましょう。

トレーサビリティが取れていない状況

• 直接の指摘対象となっている要求（仕様）の特定はできる。
• 影響範囲を特定したいが、当時の担当者しか判らない所があり属人化しがち。
• 変更の影響を受ける設計の範囲は特定したが、それで全てだという確証がない。
• 漏れが無いか心配になる（バグ混入のリスク）。
• プログラムやテスト項目を修正する際も、「これで全て確認できたか？」と常に不安が付きまとう。

トレーサビリティが取れている状況

• 直接の指摘対象となっている要求（仕様）の特定はできる。
• 可視化されている関連性（インデックス）に従い、影響を受ける設計の範囲が100%明確化される。
• 設計の範囲が明確なので、プログラムの修正箇所も、関連するテスト項目も機械的に導き出せる。
• 誰がやっても早く正確に影響範囲の特定ができる。

このように、トレーサビリティが取れているかどうかで、仕様変更という「予期しないイベント」をスムーズに乗り越えられるかどうかに決定的な違いが生まれます。
これは、レビュー議事録での指摘反映や、バグ修正による影響範囲の調査など、すべての変更管理において同じことが言えます。
物理的に関連性が明示されているので、影響範囲の抽出が限りなく機械作業になります。
仕様書を漁る時間、作業当時の記憶を思い出す時間、本当に良いか考える時間、、、これらの時間を大きく短縮できるのです。

どうやってやるの？

トレーサビリティの本質は、プロジェクト全体の成果物から要求や仕様の一つ一つを番号や記号などのインデックスで一意に識別でき、それを具体化した下流のドキュメントに繋がっていること。
そのためには、要求や仕様は純度の高い単一の要求（仕様）で記載されていることが特に重要です。そのための取り組みとして、以前記載した「1文節1仕様」のルールを同時に適用しました。そういった経緯もあって、私たちのプロジェクトでは「1文節1仕様1ID」という形にたどり着いたのです。
さて、インデックスに関する取り扱いについては、グループ内で統一されたルールの運用が必要です。
実際に私たちのグループで採用したトレーサビリティのルールは以下の様なものです。

• ドキュメントを個別に識別する為に文書IDを付与する
• 同一文書内で要求（仕様）に4桁の番号を付与
• <会計年度> – <文書ID> – <番号>
• 番号は使い捨てとし発番済みの番号を再利用しない（欠番）
• 番号は連番で並んでいる必要はない
• 要求（仕様）の追加時は未使用の新しい番号を発番する
• 要求（仕様）の変更時の番号変更はケースバイケース（※参照）
• 要求（仕様）の削除時は番号ごと削除する（その番号は欠番となる）

※以下の様な基準で考えると分かりやすい。
A) 軽微な修正であれば記載のみ修正し、下流のドキュメントの記載内容も整合性を取る
B) 大幅な修正の場合は、古い記載を削除し（番号も削除）、新しい記載として追加（番号も新規発行）する。また、下流のドキュメントに対しても同様の方針で変更を加えていく

トレーサビリティの確保は、専用ツールを使用して実施するのが一般的ですが、ライセンスが中々に高価でして……（泣）。今回はプロジェクト予算の都合上、人力でExcelとWordに記載していきました。
人力で適用する関係上、どこまでやるか本質を失わない程度に適用範囲を決めなくてはなりません。
私たちのチームでは、現実的な適用方針として以下のように決定しました。

• ExcelとWordの設計書フォーマットにIDを記載していく形にした
• 上流→下流方向のトレーサビリティに限定する（本来は双方向）
• ソースコードはトレーサビリティの対象外とした（本来は対象）
• レビュー観点としてドキュメント間の整合性のチェックを行う

このような方針で、トレーサビリティとしては比較的ミニマムなルールで実施しました。

具体的にどうなるの？

では、トレーサビリティの具体的な例を出しましょう。
以下に示す例は、実際に私たちのチームで採用した記載方法です。
※同じ色のIDが関連（上流 – 下流の関係）している内容

文書ID：FY26-0101 文書名：要件定義書

※紙面の都合上一部省略していますが、実際は全ての項目を明示的に列挙します。そうすることで、番号の検索性を維持しています。

文書ID：FY26-0201 文書名：外部設計書（ログイン画面）

文書ID：FY26-8003 文書名：第3回外部レビュー議事録

やってみて分かったトレーサビリティの威力

正直に言うと、人力での適用は結構大変でした。特にドキュメント間で整合性を担保するための確認にはそれなりの時間が必要でした。
メンバーの心理としては、ドキュメントに工数をかけて、中々プログラム実装に進めない状況に戸惑ったかもしれません。
「後半の工程で絶対に威力を発揮するから……！」なんてメンバーをなだめながら、何とかやってもらいました（苦笑）
この「導入初期のコスト」が唯一かつ最大のデメリットだったと思います。

しかし、その分、実装やテスト項目作成、バグ修正などプロジェクトの後工程では、比較的スムーズに混乱もなくスルっと済みました（設計にそれだけ時間をかけたので当然といえば当然ですが（笑））。
実際の単体テストフェーズ（総テストケース：3,005件、バグ：95件）での日次実績の推移を載せておきます。（2.5人で実施）
※事情により、テスト実施とバグ修正を分離して進めています

如何でしょうか。
テストによるバグもしっかり出すことができましたが、その修正に伴うプロジェクトの混乱が無く、淡々と進んでいきました。
トレーサビリティによる「関連性の可視化」がもたらす時短効果（影響範囲の調査、関連ドキュメントの特定など）は、前半の苦労を見事に相殺してしまうレベルで実感できたと感じています。

• 仕様とテスト項目がトレースできるのでテスト観点が明確
• テスト観点が明確なのでテスト項目の記載も明瞭
• テスト項目の記載が明瞭なので誰でも実施できる
• バグ票→テスト項目→仕様とトレースできるので修正範囲の把握が確実かつ容易

これらは、トレーサビリティ導入による結果だと考えています。
一般的にトレーサビリティは、コストをかけてでも信頼性が重要と言われるミッションクリティカルな領域（医療・軍事・宇宙航空など）で使われる手法です。
また、セキュリティに関しても、対象機器のセキュリティが正確に担保されていることを論理的に証明するために形式手法と合わせて使用されます。（ISO15408：コモンクライテリア EAL6,7）
その為、導入するプロジェクトによってはオーバーエンジニアリングになってしまうケースもあるでしょう。
だからこそ、私たちが一般のシステム開発で取り入れる際に重要なのは形ではなく、自分たちにとって「メリット > デメリット」な状態を維持できる程度に内容を調整して適用する事です。
トレーサビリティの実施がプロジェクトにとって過大な負担になってしまっては本末転倒ですから、「どこまでやるか」「メンバーがメリットを感じることができるか」という基準で、欲張らずに適用することが大切だと思いました。

まとめ

これまで私が記載してきた対策（バグ分析、1文節1仕様、トレーサビリティ）を実践したことで、プロジェクトのメンバーはシステム開発の過程（仕様が実装になっていく過程、テストなど）を体験し、何かを感じ、「こういう事か！」と、本当の意味での理解ができたことも多かったのではないかと思っています。
品質の高いソフトウェアを開発するための手法として、いろんな局面で、多様な選択肢があることも知ってもらう事も出来たのではないかと思います。
今後、保守運用のフェーズに入っていく訳ですが、自分たちが楽をするために苦労を先取りして、残りの期間を楽に過ごすための糧を身に着けてもらいたいなと思う次第です。

私たちと一緒にモノづくりをしていく仲間を募集しています。 弊社に少しでも興味のある方は、ぜひ下記の採用ページをご覧ください。

• Wantedly
• 募集要項（当社HP）