品質確保に効果のあった派生開発プロセスの工夫#11
掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。
- 論述対象となるプロジェクト、および開発プロセスの特徴
- ・組込み系の社会インフラを担うミッションクリティカル・システム。
- ・信頼性・成熟性について高い品質が求められている。
- ・稼働直前の総合テストからプロジェクトを引き継ぎ。
- ・母体システムのドキュメントが不足、母体品質も悪い。
- ・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。
エントリ内容の目次
内容はかなり長くなるため、順を追って述べる。
まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。
時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていこうと考えている。
もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。
（１）このレポートの概要と背景について
⇒記事はこちら１部 レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
⇒Ｐａｒｔ１
⇒Ｐａｒｔ２（３）ＸＤＤＰでの問題提起と解決策の概要
⇒記事はこちら（４）当方が遭遇した派生開発の問題と解決策の概要
⇒記事はこちら２部 レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
１．派生開発の課題
⇒ｐａｒｔ１
⇒ｐａｒｔ２
⇒ｐａｒｔ３
２．派生開発のプラクティス、プロセス
⇒ｐａｒｔ１
⇒ｐａｒｔ２
⇒ｐａｒｔ３（本記事が該当）（２）派生開発プロセスの内容
序．品質確保に効果的な派生開発プロセス
１．対処検討プロセス群
２．開発プロセス群
３．検証プロセス群
２部 （２）派生開発のプラクティス、プロセス
前回までは派生開発のプラクティスを見てきた。今回からは、このプラクティスを組み込んだプロセスについて見ていく。
２．２ 派生開発のプロセス
本節では、以上までにみた４つのプラクティスを具体的に実行するためのプロセスを説明する。最上位のプロセスでは、大きく３つのプロセス群に分かれている。
1.対処検討プロセス群
派生開発特有の課題に対応するために、開発工程の前に設けた事前検討を行うプロセス群。４つのプラクティスの全てが含まれる、本派生開発プロセスで特に重要なプロセスである。
2.開発プロセス群
一般的な開発プロセスである。本書ではウォーターフォール・モデルのプロセスを前提としている。ただし、本書は開発プロセスを規定する意図を持たないため、組織やプロジェクトにおいていずれの開発プロセス・開発モデルを採用していても、本派生開発プロセスを適用することが可能である。４つのプラクティスのうち、１つのプラクティス（ドキュメントのトレーサビリティ強化）が含まれる。
3.検証プロセス群
一般的なテスト工程を定めるプロセスである。検証プロセスについても、本書では特段の規定をする意図を持たない。組織やプロジェクトにおいていずれの検証プロセスを採用していても、本派生開発プロセスを適用することが可能である。
プロセス群のうち「2.開発プロセス群」と「3.検証プロセス群」は、理解度向上のために参考までに記載したものであり、本書は開発プロセスや検証（テスト）プロセスを規定するものではない。各プロセス群はさらに詳細なプロセスに分解される。
ここで一旦、派生開発プロセスの全体像を示す。
図2.2-1～2.2-5までに記載されている個々のプロセスや、要素成果物の解説については第２部 （２）派生開発プロセスの内容で行う。
・図表2.2-1 派生開発プロセス全体
・図表2.2-2 派生開発－対処検討プロセス群
・図表2.2-3 派生開発－対処検討プロセス群－スコープ定義
・図表2.2-4 派生開発－開発プロセス群
・図表2.2-5 派生開発－検証プロセス群
２．３ ＸＤＤＰと当派生開発プロセスの相違点
これまで、ＸＤＤＰの特徴と対比する形で、当派生開発プロセスが類似している点を述べてきた。類似する点が多いのならば、ＸＤＤＰをそのまま用いればよいことになる。
しかし当派生開発プロセスを記載したのは、ＸＤＤＰでは対応が難しいと考えられる当該プロジェクトの課題に対応するためである。
そこで、本節ではＸＤＤＰと当派生開発プロセスの相違点を述べる。またＸＤＤＰではどのような点が制約となって、当該プロジェクトでのカスタマイズが必要であると判断したのかについても併せて述べる。
（１）母体の正式ドキュメントの更新タイミングの差分
ＸＤＤＰと当派生開発プロセスとの最も大きな違いは、ＸＤＤＰは設計書を含む母体の正式ドキュメントへの更新タイミングを、案件のテスト工程が完了してから更新する、としているのに対し、当派生開発プロセスでは、テスト前に母体の正式ドキュメントを更新する点である。
ＸＤＤＰで変更要求案件のテストが完了してから更新する理由としては、以下の新規開発崩しを行うことでの課題が挙げられる。
・図表2.3-1 新規開発崩しの問題
- ドキュメントの文字を置き換える作業が中心になるが、文字情報の変更だけでは、変更によって他に影響を与える箇所を特定しにくい
- ドキュメントに変更後の動作だけを記載したのでは、変更仕様（○○という動作を、△△へ変更する）をドキュメントから再度読み取らなければならなくなる
- 変更内容についてレビューが行われていないままに、正式ドキュメントを更新している
- 複数の担当者やチームで、同じドキュメントを更新しようとすると混乱が生じる
１．については当該プロジェクトにも当てはまる問題である。ただし、当派生開発プロセスで述べている４つのプラクティスを実践することで、この問題は解消できる。
２．については、当派生開発プロセスの「対処検討資料」において、変更前と変更後の内容を記載すれば解消できる。
３．については、当派生開発プロセスの「2.開発プロセス群」において、工程ごとにレビューを行うためこのような問題は発生しない。
４．については、どのプロジェクトにも当てはまる問題であるが、マスタ・ファイル自体は更新しない、他の担当者に関連する変更点はレビューで相互に確認する、などのルールを用いることで、混乱は相当程度軽減することが可能だと考える。
それよりも、当派性開発プロセスでテスト前に正式ドキュメントを更新している理由は、これら正式ドキュメントをインプット情報として、テスト項目を漏れなく洗い出すためである。
ＸＤＤＰで定める成果物は、主に変更要求仕様書、変更仕様トレーサビリティ・マトリクス、変更設計書の３点である。
これらはいずれも変更差分のみを示している。これらの成果物をインプットにしてテスト項目を抽出した場合、変更点については漏れなく項目を挙げることができる。しかし派生開発では、直接変更をしていない箇所にも影響を与えていないか（デグレード）を検証しなければならない。
つまり、変更していない部分もテスト項目として抽出する必要がある。このとき、差分のみを表現しているＸＤＤＰの成果物だけで、変更をしていないが影響を受ける処理についても、漏れなくテスト項目を抽出できるのかが疑問である。
こうした課題に対応するためには、母体ドキュメントを更新し、変更点と変更していない点を含めてテスト項目作成のインプット情報とするのがベターだと考えている。
実際ＸＤＤＰではテストプロセスについての提言は特にないため、効果的なテストケースの作成をするためには、各プロジェクトでの工夫が必要になってくる。
（２）レビューアも含めて部分理解の制約がある場合を考慮
ＸＤＤＰでは、“「部分理解」や「納期の圧力」を克服する最大の方法はレビューだ”([1], p86)とされている。
成果物をレビューすることで、レビューアの「気付きを誘発」し、指摘によって品質を確保する。部分理解の制約によって、担当者の理解不足や思い込から発生する勘違いをカバーする方法はレビュー以外にない([1], p307)とも示されている。
ただし我々は、これはレビューアの知識や経験が豊富な場合にだけ有効な手法ではないかと考えている。
当該プロジェクトの場合は、担当者もレビューアも母体システムの理解がほとんどない中でプロジェクトを進めなければならなかった。
こうした場合でも、レビューを実施することで品質の確保が本当に可能なのかが疑問である。
もちろん、経験豊富なレビューアを参加させれば、これまでの類似プロジェクトの経験から効果的な指摘ができる可能性はある。ただ一般的に考えてレビュー効果は低くなるであろう。レビューで指摘ができるかどうかは、レビューアの知識や経験、技量に依存する。
つまりレビューによる欠陥の除去能力はバラツキが大きいということである。そのため、レビューに過度に依存すると欠陥流出のリスクも高まると考える。
また、そもそもレビューはシステムの品質を検証（検査）する活動である。品質の内部測定の１つの手法であり、本質的には品質を作り込むことが目的ではない。
検査で不良品をはじくことが、本質的には品質の作り込みにつながらないことは、誰もが首肯すると考える。
このような理由から、当派性開発プロセスは、レビューで品質を確保するよりも、設計時点で担当者が自分で品質を作り込めることを重視している。
つまり、できるだけ思い込みや理解不足から生じる勘違いが発生しにくい設計プロセスを定めるということである。
そのため、ドキュメントのアカウンタビリティと、スコープ・マネジメントを強化するために、対処検討資料の作成手法として、「要素分解」、「バリエーションの検証」、「マトリクス表記」など、具体的な方法を定義することを重視した。
これらの手法を用いれば、設計時点で設計者本人が設計誤り・設計漏れの発生に気付きやすくなり、設計品質が向上すると考えている。
（３）欠陥是正要求においては、変更要求仕様書だけで変更内容の妥当性を検証することが難しい
ＸＤＤＰでの主要な成果物は、変更要求仕様書、変更要求トレーサビリティ・マトリクス、変更設計書の３点セットであることは述べた。
このうち、変更要求への対応内容（変更内容）を網羅し、かつ妥当であることを保証するドキュメントは、変更要求仕様書である。変更要求仕様書の記載方法は、ＵＳＤＭの書式を用いる。ＵＳＤＭは、変更要求と、要求を詳細にブレイクダウンした仕様とを明確に分けて記述するための記述ルールである。
変更要求仕様書は、要求や仕様を「before/after」を含めて表現することが特徴である。こうすることで、変更前と変更後の内容がイメージできるようになり、その変更の「範囲」を適切に認識できることで、変更の難易度や規模感、必要な変更箇所が把握しやすくなる効果を期待する。
また変更内容の妥当性については、「変更の理由」をＵＳＤＭに記載することで保証している。これらはレビューにおいても、第三者に変更内容の妥当性を検証する方法を提供する。
ソフトウェアやシステムの、ある機能に対するカスタマイズ要求であれば、こうした「before/after」を明確に記載することや、変更の理由を明記することで、変更内容の妥当性について、第三者でも把握ができると考えられる。
ただし、当該プロジェクトで主に扱う変更要求は、欠陥修正の要求である。
欠陥修正の要求に対しては、これらの方法だけでは、変更内容の妥当性を、第三者が理解することが難しいケースが多いと考える。
欠陥是正要求と、仕様変更や機能のカスタマイズ要求との最大の違いは、ソースコードの変更が発生する箇所を、階層的に追跡することが難しい点である。
カスタマイズ要求の場合は、ソフトウェアの機能や処理を認識しやすい。ドキュメントにも記載が残っている可能性も高く、場合によっては、新規開発のときに作成したドキュメントが十分に役立ち、そのドキュメントをアップデートするだけで対応が可能になる場合もあろう。
つまり、変更対象となる機能や処理といった単位が大きいので、比較的認識しやすいという特徴がある。
これに対し、欠陥是正要求の場合は、欠陥が発生している原因となっているソースコードは、ある機能や処理の中のほんの一部分だけであることがほとんどである。
つまり、機能や処理といった構成要素よりも、更に詳細な単位が変更の対象となる。場合によっては、ある関数の中の１命令だけが変更対象となる。これは、変更対象の単位が最も小さいことを意味する。
この結果、カスタマイズ要求への対応の場合は、要求をブレイクダウンして検討することがしやすいが、欠陥是正要求の場合は、変更が必要となる箇所が最も小さい構成要素であることから、要求をそれ以上ブレイクダウンすることが困難（不可能）である。この違いがＵＳＤＭへの適用の容易さに影響を与えていると考える。
ＵＳＤＭは要求を仕様へとブレイクダウンするために、「before/after」の表記を用たり、変更理由を記載したりする。
つまり適用の前提条件として、要求は仕様へとブレイクダウンできるトップダウン型の変更であることを想定している。
これに対し、欠陥是正要求の場合は、変更の対象が機能や処理よりも小さい要素となっているため、それ以上のブレイクダウンが容易ではない。
むしろ、局所的な変更箇所から、その変更への対応を行ったことで、他の処理や機能へ影響を与えないのか（影響箇所の調査）といった観点や、類似する他の問題が混入していないのか（水平展開の調査）といった観点で検討することが求められる。
影響箇所の調査は、ボトムアップ型の調査である。
ある最小の変更点が、他の処理に及ぼす影響を遡って調査するためである。影響箇所の調査は、水平思考型（ラテラルシンキング）の調査でもある。対象となる欠陥に類似する他の欠陥が混入していないのかを調査するものであり、いずれもトップダウン型の調査を行うことが難しい。
これらの特徴の結果、欠陥修正を１つの要求ととらえた場合、ＵＳＤＭを適用してブレイクダウン型に検討を行っても、変更対象となる箇所を把握することは困難になる。
また、どういったものを欠陥修正の「要求」とらえることが妥当なのかも明確ではない。
「ある問題を修正して欲しい」というニーズを欠陥修正における「要求」ととらえるのか、「ある問題を解消することで得られるシステムの振る舞いを実現して欲しい」というニーズを「要求」ととらえるのかで、アプローチも変わってくる（ちなみに、本書では後者のスタンスを取って以降の解説を述べている）。
欠陥修正においてはこうした課題があるため、ＵＳＤＭに従った変更要求仕様書を単純に適用することが困難であり、第三者に対して変更内容の妥当性を示すことも困難であった。
そのため、初めに欠陥の原因調査を実施し、その欠陥を修正することで得られるシステムの振る舞いを実現して欲しい、というニーズに一旦変換してから、トップダウン型での検討を行うというプロセスを採用している。
例えば、ある欠陥によってシステム間の通信が異常切断されるといった問題の場合は、「システム間の通信が異常切断されないようにして欲しい」といった「要求」に変換することで、通信の異常切断が発生する全てのケースを対象として欠陥是正要求に対応する。
こうすることで、他の類似問題にまで検討範囲を水平展開したスコープによって、欠陥是正要求への対応が行えるようになる。
この例であれば、実際の欠陥では、通信が異常切断した原因は１つだったのかもしれないが、それ以外の原因で通信が異常切断しないか、といった検討範囲（スコープ）も「要求」に含むことになる。
このような対応をするための手順や手法についても、本書では記載をしている。
ここまでで、派生開発のプラスティス、プロセスの概要について述べた。
次回からは、派生開発のプロセスの１つ１つを詳細に見ていき、どのような成果物を作成するのか、どのような手法で成果物を作成していくのか、といったところを詳しく説明する。
次回からは実務的な詳細な内容も多く含まれてくる。
