品質確保に効果のあった派生開発プロセスの工夫#12

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３

（２）派生開発プロセスの内容
　１．対処検討プロセス群
　　　⇒ｐａｒｔ１（本記事が該当）

　２．開発プロセス群
　３．検証プロセス群

（２）派生開発プロセスの内容

１．対処検討プロセス群

今回からは、当派生開発プロセスを１つ１つ詳細に見ていく。説明は、

・プロセスの目的・概要
・プロセスフローの説明
・要素成果物の説明
・個々のプロセスの説明

の流れで行う。

個々のプロセスの詳細な説明になるため、現在位置が分からなくなることもあると思う。その時は、全体プロセスを参照し、現在地を確認しながら参照してもらえるとよろしいかと思う。

今回は「対処検討プロセス群」について解説を行う。

対処検討プロセス群

●プロセスの目的・概要

対処検討プロセス群は、派生開発における欠陥是正要求、変更要求を受け付けて、要求への対応方法を十分に検討し、関係者と協議し、決定を下す一連のプロセスで構成されている。

対処検討プロセス群の目的は、漏れのない対処検討を行うことを保証し、その結果として高い設計品質を確保することである。

対処検討プロセス群には、派生開発プロセスの４つのプラクティスの全てが含まれる。

●プロセス・フロー

対処検討プロセス群は、以下のプロセスで構成されている。

1.1　原因特定

プロジェクト関係者から発行されるソフトウェア変更要求や、ソフトウェア欠陥是正要求を受付け、変更要求が発生した原因や経緯を特定したり、欠陥発生の原因を特定したりするプロセス。

1.2　スコープ定義

原因が特定された変更要求や欠陥是正要求の作業スコープを定義するため、要求のコンセプトを基に要求仕様に細分化を行うプロセス。

1.3　対処案の特定

スコープ定義で明らかになった対処スコープ（要求コンセプトと要求仕様を含む）を基に、要求仕様を満足する対処設計案をいくつか検討しリストアップするプロセス。

1.4　対処案の検証

リストアップされた対処設計案の実現妥当性や、対処方法の詳細設計を行い、対処案を比較して、メリット・デメリットを明確にするプロセス。

1.5　対処決定

検証された対処設計案を基に、関係者と協議を行って採用する対処設計案を決定するプロセス。

これらのプロセスのうち、「1.2スコープ定義」は、より詳細な２つのプロセスに細分化される。

・図表1-1 対処検討プロセス群のプロセス・フロー

●要素成果物

（１）欠陥原因調査結果ソフトウェアの欠陥の事象が引き起こされる原因について、調査によって明らかになった結果を記載した文書。

（２）対処スコープ
「1.2スコープ定義」プロセスを経て明確になった、対処で実現しなければならない要求事項のスコープを記載した文書。対処スコープを満足する対処案を「1.3対処案の特定」プロセスで検討することになる。

（３）対処案のリスト
「1.3対処案の特定」プロセスで検討した対処案のリストを記載した文書。通常は対処スコープを満足する複数の対処案を検討する。

（４）調査アイテムのリスト
対処案の１つ１つを検証する際に、調査しなければならないアイテムのリストをまとめた文書。この調査アイテムのリストを基に「1.4対処案の検討」プロセスを実施する。

（５）調査アイテムの調査結果
調査アイテムのリストに従って調査した結果、および結果を導くまでの検証過程を記載した文書。

（６）検証・評価済み対処案
対処案のリストに従って検証・調査した結果、および結果を導くまでの検証過程を記載した文書。対処案が効果的なのかどうかを検証した結果を含む。

（７）採用された対処
「1.5対処決定」プロセスで採用が決定された対処案を示す文書。

（８）対処検討資料（※「対処検討資料」という呼称は仮とする）
（１）～（７）までの全ての調査結果・調査過程を含めた文書。（１）～（７）までの成果物は、対処検討資料の要素成果物である。

1.1　原因特定

1.1.1 プロセスの目的・概要

原因特定プロセスの目的は、プロジェクト関係者から発行される、ソフトウェアの欠陥是正要求に対応し、欠陥の原因を特定することである。

欠陥の原因調査については特段の手法があるわけではない。ソースコードの調査、ドキュメントの調査、再現試験などの手法を用いて行う。欠陥原因が特定された時点で、本プロセスは完了となる。

場合によっては、欠陥是正要求が発行された時点で、すでに欠陥原因が特定されている場合もある。この場合は本プロセスを実行せずに、「1.2スコープ定義」プロセスに移ってよい。

1.1.2 ツールと手法

本プロセスに特有のツールと手法は特にない。

1.2　スコープ定義

●プロセスの目的・概要

スコープ定義プロセスの目的は、変更要求や欠陥是正要求で扱うプログラムや機能などの範囲（スコープ）を明確にすることである。

スコープを明確にするためには、スコープ境界を明らかにしなければならない。スコープ境界とは、何を含め、何を含めないかの境界線のことである。

境界が不明確な場合はスコープ定義に曖昧さが含まれていることが多い。

一般的には、ある機能や処理の動作可能な条件のみをスコープとして定義することが多いが、それ以外の条件で本当に動作しないこと、またはそれ以外の条件では動作が本当に不要であることを保証・検証できていないケースが多い。

これは「何を含めるか」のスコープのみを定義したためであり、「何を含めないのか」も同時に定義することで、スコープ境界が明らかになり、スコープの検討漏れを防止できる。

本書で提唱する、スコープ境界を明らかにするためのアプローチは、はじめに全体を把握してから、徐々に細分化・具体化を繰り返してスコープを絞り込んでいくという手法である。つまりトップダウンのアプローチを採る。

一旦スコープを最大限に広げてから、必要な部分と不要な部分に切分けることが、境界線を明らかにする唯一の手段である。

逆のアプローチであるボトムアップでは、経験則やひらめきを基に、関連する要素を挙げていくが、その要素が、検討したい内容を全て網羅していることを保証するのが困難な場合がある。

もちろん、ボトムアップ・アプローチでも、トップダウン・アプローチと同様の結論を導く事は可能であるし、本来はそうなる事があるべき姿でもある。

しかし、時間的な制約による検討漏れや、担当者の思い込みによる誤りといった要因をできるだけ排除するには、トップダウン・アプローチを採用して、全体を網羅してから個別具体的な内容にブレイクダウンするほうが、相対的に誤りが少なくなることが多い。

また、ボトムアップ・アプローチは検討すべき事象が漏れやすいという特徴を持つ。これを補うためにレビューなどを通じて、他者の知恵や知識を取り込むことを試みる。

他者の知恵や有識者のアドバイスを適宜得ることは大変重要なプラクティスであるが、場合によっては自分以外に母体ソフトウェアの内容を知っているメンバがいない（場合によっては自分を含めて誰も母体のソフトウェアを知らない）、といった状況も発生するだろう。

こうした場合には、行き当たりばったりの調査や検討を重ねるのではなく、１人でもシステマチックかつロジカルに検討を行えるトップダウン・アプローチのほうが適している。

以上の理由から、スコープ定義ではトップダウン・アプローチを徹底することにしている。

作業スコープをトップダウンで詳細化していくという考え方自体は特別なものではない。

しかし、複雑な処理や影響範囲が大きい処理においてスコープ境界を定義することは、想像するよりも容易なことではない。

また派生開発という特性から、母体システムの理解度が不十分な状態である点も困難さが高まる要因になっている。これらの理由から、スコープ境界の明確化が全ての変更要求・欠陥是正要求において確実に行われていることを保証するプロセスが必要とされる。そのプロセスが、スコープ定義である。

●プロセスの特徴

スコープ定義はプロセスが２つに分れている。１つが「1.2.1要求コンセプトの明確化」であり、もう１つが「1.2.2要求仕様の特定」である。

スコープ定義というプロセス名称だけでは、何についてのスコープを定義するのかが分りにくい。そのため、欠陥是正要求や変更要求に対する作業スコープを定義する、ということが分るように、目的語を付与した２つのプロセスに分割している点が特徴である。

２つのプロセスの詳細は後述するが、本プロセスはソフトウェア開発プロセスでいえば「ソフトウェア要件定義」や「ソフトウェア方式設計」に該当する。

これらの工程との本質的な違いはないため、派生開発プロセスで記載するプラクティスや手法以外にも、通常の開発プロセスにおける手法を活用することが可能であるし、むしろそれを想定している。

プロセスの中にはソフトウェア開発プロセスとオーバラップする部分が存在する。ただし、それがソフトウェア開発モデルや開発プロセスを固定化するものではない。

当派生開発プロセスと、ソフトウェア開発プロセスは相互に補完しあうことができると考えている。

●他のプロセスとの関連

スコープ定義プロセスに関する考え方や手法は、ＰＭＢＯＫのスコープ・マネジメント知識領域とほぼ一致している。本書では、ＰＭＢＯＫで定義する手法を、派生開発の現場に適用できるように更に詳細化・具体化した内容を記載している。

また派生開発プロセスであるＸＤＤＰともオーバラップする内容を含んでいる。ＸＤＤＰでは、本書のスコープ定義プロセスに相当する内容は、「1.1変更要求項目ごとに機能仕様などから変更仕様を抽出する」、「1.2変更要求に対してソース等を調査検討して変更仕様を引き出す」といったプロセスに対応する。

本書のスコープ定義プロセスも、ＸＤＤＰの前述のプロセスも、あいまいな要求事項を具体的な要求仕様へと、トップダウンのアプローチでブレイクダウンする手順をプロセス化している点に違いはない。

ただしＸＤＤＰは変更仕様をブレイクダウンする際に用いる検討手法としては、ドキュメント調査やソースコードの調査を行う、という程度の説明にとどめているのに対して、本書では、どのようにドキュメント調査やソースコード調査をすると漏れのない検討ができるのか、というプロセスに着目し、調査方法を具体的な手法として定義している点が異なる。

この点で設計品質の作り込みがより行いやすくなるように考慮をしている。

また、ＸＤＤＰでは調査で導き出した変更仕様の記述の詳細度や記述のフォーマットを、変更要求仕様書（ＵＳＤＭ）で規定しているのに対し、本書では導き出す要求仕様の記述の詳細度や記述方法については、プロジェクトやシステムの特性を踏まえて別途定義すれば任意の記述が可能であるとし、特別な規定を設けていない点が異なる。

この点から分るように、ＸＤＤＰは派生開発プロセス（開発モデル）そのものを定義しているのに対し、本書は派生開発特有の問題に対処するために有効なプロセスを、開発プロセス（開発モデル）とは独立に切り出して定義しているだけであるという違いがある。

●プロセス・フロー

前述したように、スコープ定義プロセスは以下の２つのプロセスから構成されている。

1.2.1　要求コンセプトの明確化

変更要求や欠陥是正要求のコンセプトを抽出することで、本来行うべき作業スコープを定めるプロセス。

1.2.2　要求仕様の特定

要求コンセプトから要求仕様を導き出し、より詳細で具体的な仕様をまとめていくプロセス。

・図表1.2-1 スコープ定義の詳細プロセス

●要素成果物

（１）要求コンセプト
変更要求や欠陥是正要求が求める内容を抽象化・コンセプト化した文書。一旦要求事項をコンセプト化することで、対処しなければならないスコープを明確にする。

（２）要求仕様
要求コンセプトを実現するために修正を行う必要のある、具体的な変更仕様のこと。要求コンセプトをブレイクダウンして具体化する。

次回から、スコープ定義プロセスに含まれる２つのプロセス、「要求コンセプトの明確化」と「要求仕様の特定」について見ていこう。