品質確保に効果のあった派生開発プロセスの工夫（その９）
掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。
- 論述対象となるプロジェクト、および開発プロセスの特徴
- ・組込み系の社会インフラを担うミッションクリティカル・システム。
- ・信頼性・成熟性について高い品質が求められている。
- ・稼働直前の総合テストからプロジェクトを引き継ぎ。
- ・母体システムのドキュメントが不足、母体品質も悪い。
- ・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。
エントリ内容の目次
内容はかなり長くなるため、順を追って述べる。
まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。
時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていこうと考えている。
もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。
（１）このレポートの概要と背景について
⇒記事はこちら１部 レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
⇒Ｐａｒｔ１
⇒Ｐａｒｔ２（３）ＸＤＤＰでの問題提起と解決策の概要
⇒記事はこちら（４）当方が遭遇した派生開発の問題と解決策の概要
⇒記事はこちら２部 レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
１．派生開発の課題
⇒ｐａｒｔ１
⇒ｐａｒｔ２
⇒ｐａｒｔ３
２．派生開発のプラクティス、プロセス
⇒ｐａｒｔ１（本記事が該当）（２）派生開発プロセスの内容
序．品質確保に効果的な派生開発プロセス
１．対処検討プロセス群
２．開発プロセス群
３．検証プロセス群
２部 （２）派生開発のプラクティス、プロセス
本章では、派生開発で品質確保に効果のあった４つのプラクティスとプロセスを示す。またこれらのプラクティスやプロセスでは、特有の成果物をアウトプットする。
プラクティスは、品質確保に効果のあった慣行の概要を理解するために、簡潔に表現したタイトルに相当する。タイトルは概要を理解するには適しているが、実際どのようにプロジェクトへ適用するのかは示していない。実務への適用を検討する場合は、４つのプラクティスが組み合わされたプロセスを参照する。４つのプラクティスは、実行するタイミングが異なっている箇所と、互いにオーバラップしている箇所がある。これらの関係がプロセスとして表現されていることで、４つのプラクティスを実務へ適用しやすくなる。
なお固有の成果物についても、派生開発プロセスの記述で併せて解説している。
２．１ 派生開発のプラクティス（part1）
以下に派生開発で品質確保に効果のあった４つのプラクティスを示す。図表2.1-1に概要を示し、その後に１つ１つのプラクティスについて詳述する。
・図表2.1-1 我々の行った派生開発のプラクティス
| 通番 | プラクティス | 概要 |
| １ |
ドキュメントのトレーサビリティ強化 |
・全工程の成果物を横串で通した「対処検討資料」を作成する。 ・各工程の成果物の変更箇所を「要求事項トレーサビリ |
| ２ | フロントローディング強化 |
・検討する対処が妥当だと判断できるまで、下流工程の調査を前倒し実施する。 ・成果物だけで対処の妥当性を確認しなくてもよく、実シ |
| ３ |
ドキュメントのアカウンタビリティ強化 |
・「対処検討資料」には検討の結論だけでなく、結論に至 るまでの過程もドキュメント化する。 |
| ４ |
超上流のスコープ・ マネジメント強化 |
・要求に含まれるスコープを適切にコントロールして、検 討漏れなく開発を行えるようにする。 |
（１）ドキュメントのトレーサビリティ強化
ドキュメントのトレーサビリティ強化で実現したい課題は、１つは既存の工程別の成果物（ドキュメントなど）の間に、適切な追跡可能性を与え、工程間を通じた設計内容の妥当性を確認することである。
２つ目は、工程間で成果物の変更箇所に漏れ・誤りがないことを保証することである。
１つ目の課題への対策は、開発工程に入る前に、対処の検討工程を設け、そこで全工程を横断する形で「対処検討資料」を作成することである。そして、ドキュメントが不足している箇所については、内容を補足するドキュメントを新たに書き起こして補足することである。
そもそもの問題は、母体ドキュメントの基本設計書と詳細設計書で、トレーサビリティが確保できていないことであった。
また、その母体ドキュメントのみを更新していたため、結局ドキュメント間のトレーサビリティが確保できていない状態で設計をしていた。
ドキュメント間（工程間）の断絶をなくすためには、変更要求や欠陥是正要求の対処を検討する場合は、既存のドキュメントを更新するのではなく、「対処検討資料」という独立した資料を書き起こし、そこへ基本設計・詳細設計などの工程を通じた検討内容を記載する。
そしてドキュメントが不足している内容は、リバースエンジニアリングを行って、新たな資料として書き起こす（図表2.1-2を参照）。
・図表2.1-2 ドキュメント間のトレーサビリティ確保
対策前は、設計時に着目するのは対象となる工程のドキュメントのみとなり、前後のドキュメント間のトレーサビリティが取れていない場合はそのままになっていた。
対策後は、前後の成果物の内容を補完する補足資料を作成することで、上流の設計内容が、正しく下流の設計に落とし込まれていることを保証できるようになる。
なお、作成する補足資料をスペックアウトと呼ぶ。スペックアウトはＸＤＤＰにて規定されている、既存のドキュメントでは不足している部分を、ソースコードを調査して作成するドキュメントのことである。本プラクティスでの用途とＸＤＤＰでの用途が同じであったため、ＸＤＤＰの用語をそのまま流用している。
本プラクティスでは検討をさらに一歩進め、工程間での設計の落とし込みを、確実に実現するための資料の作成手法について検討をしている。この手法については派生開発プロセスの節で解説をする（手法は主に、要素分解、バリエーションの検証、マトリクス表記の３つを用いる。詳細は第二部「1.2.2要求仕様の特定」を参照）。
もう１つの課題である、工程間で成果物の変更箇所に漏れ・誤りがないことを保証することへの対策としては、開発工程を実行する前に「要求事項トレーサビリティ・マトリクス」というドキュメントを作成する。「要求事項トレーサビリティ・マトリクス」は、縦軸に要求事項、横軸に工程別に変更を加えた成果物を表形式で記載したものである。
１つの要求事項を達成するために、基本設計工程ではどの成果物を変更したのか、詳細設計工程や製造工程ではどの成果物を変更したのか、といった内容を参照しやすくする（図表2.1-3参照）。
これによって、レビューアが要求事項の実現のために、工程間でどのような変更が加えられたのか、上流の成果物の内容が、下流の成果物に確実に反映されているのかを追跡することが容易になる。
ＸＤＤＰでも類似するマトリクスを用いて、要求事項のトレーサビリティを確保している。ＸＤＤＰのマトリクスは変更要求トレーサビリティ・マトリクスと呼び、記載のルールなども図表2.1-3とは異なる部分がある。
・図表2.1-3 要求事項ＴＭ第１表
（２）フロントローディング強化
フロントローディング強化で実現したい課題は、ドキュメントだけではソフトウェアの制約事項を把握できないことから、下流工程に進むにつれて調査工数が増大する手戻りのリスクを軽減することである。
この対策としては、上流工程で検討を行う際は、検討内容が妥当だと判断できるまで下流工程の調査を先取りして行うということである。
派生開発では既存の詳細設計やソースコードが存在しているため、これらの存在を無視して自由に設計をすることはできない。検討した設計内容が、下流の詳細設計やソースコードを踏まえても妥当だと判断できなければ、絵に描いた餅になってしまう。フロントローディングとは、上流工程で下流工程の作業を前倒しで実施し、上流設計力を強化することを言う。
フロントローディングを行うのは、前述の「対処検討資料」を作成している時点である。「対処検討資料」自体が、工程間をまたぐ設計情報を記載する目的で作られているため、フロントローディングを行いやすい。フロントローディングを行いながら、ドキュメント不足箇所のスペックアウトを作成し、対処の設計を行う。
ＸＤＤＰでは、フロントローディングや、上流工程での設計を重視する記述は見られない。ＸＤＤＰの開発プロセスでは、一般的な開発工程のフェーズが存在しない（図表2.1-4、図表2.1-5を参照）。
・図表2.1-4 ＸＤＤＰ全体のプロセス
・図表2.1-5 「１．変更要求を実現する」を詳細化したプロセス
ＸＤＤＰで想定しているプロセスは、まず変更要求が発生したら、要求に対応する変更箇所（ソースファイルと関数）を特定する。次に、変更が特定された関数の変更設計書（差分設計書に相当するもの）を記載し、最後にソースコードを修正する、というプロセスである。
上流工程の設計書類については、テストが完了してから更新を行う、ということを提唱している。このため、製造工程に相当するプロセスのみの定義となっている。
ただし、ＸＤＤＰでは、変更要求に対応する箇所を特定するためにソースコードの調査を行いながら、ドキュメントの記述が不足している部分をスペックアウトする。
つまり、既存のドキュメントもソースコードも両方参照して、変更箇所を特定する、というプロセスになる。結果的にはフロントローディングと同じく、上流工程のドキュメントも下流工程のソースコードも全て参照して対処を検討するため、この点で共通していると考える。
次回は残りの２つのプラクティスについて見ていこう。
